La mayoría de las aplicaciones web actuales requieren al menos alguna estrategia de seguridad básica. Por ejemplo, sitios que ofrecen contenido protegido con contraseña, sitios con solo un administrador, blogs y revistas personales, sitios de comercio electrónico, intranets corporativas, etc.
El enfoque de diseño más común para crear este tipo de aplicaciones web es integrar la política de seguridad en la lógica empresarial de la aplicación web, donde la aplicación determina si un usuario tiene permiso para acceder a ciertos datos en la base de datos. En este escenario, la función de la base de datos es simplemente almacenar datos y entregarlos cuando se solicite. En otras palabras, si una aplicación web ordena a la base de datos que proporcione información específica, la base de datos ejecuta el comando directamente sin verificar los permisos del usuario.
En este artículo, aprenderá cómo aprovechar las funciones de seguridad integradas de Oracle para hacer cumplir las reglas de seguridad de las aplicaciones a nivel de base de datos para mejorar la seguridad general de su aplicación. Como beneficio adicional, proteger el acceso a los datos directamente en la base de datos no solo mejora la seguridad de las aplicaciones sino que también ayuda a reducir la complejidad.
¿Qué pasa conla necesidad de seguridad en la base de datos
para controlar el acceso a los datos desde las aplicaciones web? En la mayoría de los casos no hay ningún problema; esta es una buena solución, especialmente si los datos involucrados no son de misión crítica ni de alto secreto. Este método se utiliza en muchos libros y recursos en línea. De hecho, un libro popular sobre PHP/MySQL desaconseja explícitamente la creación de más de una cuenta de usuario de base de datos por aplicación porque "usuarios adicionales o permisos complejos pueden requerir más comprobaciones antes de continuar con la información y ralentizar la velocidad de ejecución de MySQL". Esto es cierto; sin embargo, hay algunas cosas que quizás quieras considerar antes de renunciar a la idea de integrar la seguridad en la lógica de tu base de datos. Veamos el siguiente ejemplo.
Digamos que crea un sistema de gestión de contenidos (CMS). Se utiliza una base de datos para almacenar el contenido publicado en el sitio web. La mayoría de los datos son públicos, lo que permite que los usuarios web anónimos los lean; sólo los editores pueden cambiar los datos. Utilice una única cuenta de base de datos para acceder y modificar registros en la base de datos, y controle la seguridad con código PHP protegiendo con contraseña el acceso a páginas exclusivas para administradores.
Si el lado público de una aplicación web sufre un ataque como la inyección SQL en un formulario de búsqueda público (es decir, un formulario que no está lo suficientemente codificado), el intruso puede ejecutar sentencias SQL arbitrarias en objetos de la base de datos que el cuenta pública tiene acceso. Por supuesto, en este caso ejecutar la sentencia SELECT no supone un gran problema porque los datos son públicos. Pero debido a que los derechos públicos y administrativos utilizan la misma cuenta de base de datos, el intruso también puede ejecutar instrucciones ACTUALIZAR y ELIMINAR, o incluso eliminar tablas de la base de datos.
¿Cómo podemos evitar que esto suceda? El método más simple es restringir completamente los permisos de la cuenta de la base de datos pública para modificar datos. Echemos un vistazo a cómo Oracle resuelve este problema.
Descripción general básica de la seguridad de Oracle
Oracle Database proporciona a los desarrolladores web muchas formas de controlar el acceso a los datos, desde gestionar el acceso a objetos específicos de la base de datos, como tablas, vistas y procedimientos, hasta controlar el acceso a los datos en filas o columnas individuales. Obviamente, una discusión de cada característica u opción de seguridad disponible con Oracle está más allá del alcance de este artículo. Aquí, no entraremos en demasiados detalles, sino sólo en los aspectos más básicos de la seguridad del acceso a datos de Oracle:
· Autenticación y cuentas de usuario · Permisos ·
Autenticación de roles y cuentas de usuario. Al igual que con otras bases de datos, cada usuario (cuenta de base de datos) que solicite acceso a Oracle debe estar autenticado. La validación se puede realizar mediante una base de datos, un sistema operativo o un servicio de red. Además de la autenticación básica (autenticación por contraseña), Oracle también admite mecanismos de autenticación sólidos como Kerberos, CyberSafe, RADIUS, etc.
Role. Un rol de Oracle es un conjunto de permisos con nombre. Aunque puede otorgar permisos a cuentas de usuario directamente, el uso de roles puede simplificar enormemente la administración de usuarios, especialmente cuando necesita administrar una gran cantidad de usuarios. Es muy eficaz crear roles pequeños y manejables y luego otorgar a los usuarios uno o más roles según su nivel de seguridad. Sin mencionar lo fácil que es modificar los permisos: simplemente modifique el rol al que está asociado el rol, en lugar de modificar cada cuenta de usuario.
Para simplificar el trabajo inicial de creación de nuevos usuarios, Oracle viene con tres roles predefinidos:
· Rol CONNECT: este rol permite a los usuarios conectarse a la base de datos y realizar operaciones básicas, como crear sus propias tablas. De forma predeterminada, esta función no puede acceder a las tablas de otros usuarios.
·Rol RECURSO: el rol RECURSO es similar al rol CONECTAR, pero permite a los usuarios tener más permisos del sistema, como crear activadores o procedimientos almacenados.
·Rol de DBA: permite al usuario tener todos los privilegios del sistema.
Autorizaciones y permisos en uso
En esta sección, analizamos cómo utilizar la autorización y los permisos de Oracle para mejorar la seguridad del ejemplo simple de CMS analizado al principio de este artículo. Se supone que el contenido proporcionado a los usuarios de la aplicación se almacena en la tabla WEB_CONTENT.
Primero, crea la tabla. Inicie Oracle Database Special Edition e inicie sesión como administrador del sistema. Libere el usuario de recursos humanos de muestra si aún no se ha liberado. Siga las instrucciones de la Guía de introducción incluida con la instalación de la Edición especial. Tenga en cuenta que, de forma predeterminada, a los usuarios de RR.HH. se les asigna la función RECURSO. Aquí, asigne al usuario el rol de DBA para que la cuenta pueda usarse para administrar los aspectos de la base de datos de la aplicación CMS. Por supuesto, la cuenta de usuario de RRHH no se utilizará para el acceso online, sólo para la administración de la base de datos.
Ahora puede crear una nueva tabla utilizando el Explorador de objetos o ejecutando la ventana Comandos SQL. Aquí está el código para crear la tabla:
CREATE TABLE WEB_CONTENT (
page_id NÚMERO CLAVE PRIMARIA,
contenido_página VARCHAR2(255)
);
debido a que la tabla se creó utilizando la cuenta de usuario de Recursos Humanos, la tabla es propiedad de la cuenta de Recursos Humanos y está en el esquema de Recursos Humanos, y otros usuarios no pueden acceder a la tabla hasta que se les conceda explícitamente permiso para acceder a la tabla. Si no lo cree, puede crear un nuevo usuario e intentar utilizar este usuario para acceder a la tabla WEB_CONTENT.
Ahora, crea dos nuevos usuarios, CMS_USER y CMS_EDITOR. Finalmente, a CMS_USER se le otorgarán permisos de solo lectura en la tabla WEB_CONTENT y este usuario se utilizará como la cuenta de base de datos que proporciona contenido como un usuario web anónimo. La cuenta CMS_EDITOR tendrá más permisos en la tabla y se utilizará como cuenta del editor de CMS (la cuenta necesaria para cambiar y mantener los datos en la tabla).
Se pueden crear nuevos usuarios utilizando la interfaz gráfica de XE o ejecutando el siguiente comando:
CREATE USER cms_user IDENTIFIED BY cms_user;
CREAR USUARIO cms_editor IDENTIFICADO POR cms_editor;
(Para simplificar, la contraseña aquí corresponde al nombre de usuario).
Para que ambas cuentas inicien sesión en la base de datos, debemos darles la función CONECTAR. Para hacer esto, seleccione la casilla de verificación CONECTAR en Información de usuario en la sección Administración/Usuarios de base de datos de la interfaz gráfica de XE, o ejecute el siguiente comando:
GRANT CONNECT to cms_user;
GRANT CONNECT to cms_editor
Ahora, si intenta iniciar sesión como usuario CMS_USER o CMS_EDITOR e intenta leer datos de la tabla WEB_CONTENT (seleccione * de hr.web_content;), encontrará el siguiente error:
ORA-00942: tabla o vista no
existe Para acceder a los datos o simplemente ver la tabla, debe otorgar permisos de solo lectura a las cuentas CMS_USER y CMS_EDITOR en la tabla WEB_CONTENT:
GRANT SELECT en hr.web_content a cms_user;
GRANT SELECT en hr.web_content a cms_editor;
el código anterior permite que estas dos cuentas realicen declaraciones SELECT en la tabla WEB_CONTENT. Si intenta ejecutar otras declaraciones, encontrará un error. Por ejemplo, insertar una fila:
INSERT INTO hr.web_content (page_id,page_content) VALUES (1, 'hola mundo');
generará el mensaje de error
ORA-01031: privilegios insuficientes
para permitir que CMS_EDITOR cambie el contenido de esta tabla. se deben otorgar los siguientes permisos:
GRANT INSERT,UPDATE,DELETE en hr.web_content a cms_editor.
De ahora en adelante, la cuenta CMS_EDITOR puede ejecutar instrucciones INSERT, UPDATE y DELETE en la tabla WEB_CONTENT.
¡Mira qué fácil es! Se puede ver que gestionar permisos a través de roles es un método más eficaz. Si la base de datos Oracle utilizada no es XE, se pueden realizar las siguientes operaciones:
Crear un rol:
CREAR ROLE lector;
CREAR ROLE escritor;
Otorgar permisos de rol:
CONCEDER SELECCIONAR EN web_content AL lector;
OTORGAR INSERTAR, ACTUALIZAR, ELIMINAR EN web_content AL escritor
Dar rol de usuario:
OTORGAR lector A cms_user;
GRANT lector A cms_editor (ellos también necesitan leer)
GRANT escritor TO cms_editor;
Tenga en cuenta que si cambia la definición del rol LECTOR, estos cambios afectan a todas las cuentas de usuario con ese rol. Si los permisos se otorgan directamente a los usuarios, cada cuenta de usuario debe actualizarse individualmente.
Después de completar los pasos anteriores, puede configurar su aplicación PHP para usar la cuenta CMS_USER para todas las conexiones de bases de datos solicitadas por usuarios web anónimos y la cuenta CMS_EDITOR para conexiones iniciadas por páginas administrativas protegidas con contraseña. Ahora, incluso si un formulario web público se ve comprometido, el impacto en la base de datos será mínimo porque la cuenta CMS_USER solo tiene permisos de solo lectura.
Conclusión
En este artículo, solo hemos presentado brevemente algunas de las características más básicas de la seguridad del acceso a datos de Oracle. Además, Oracle tiene muchas otras características que llevan la seguridad de sus aplicaciones web al siguiente nivel, incluida la base de datos privada virtual (VPD) y la seguridad de etiquetas.