Al albur del último encuentro e-tic celebrado sobre la seguridad, es sin duda un buen momento para haceros partícipes de una reflexión sobre la seguridad de nuestros datos almacenados, con la intención de que nos hagan pensar sobre el estado de nuestros sistemas de bases de datos y por lo tanto ponernos en marcha para implementar las mejoras pertinentes, que nos lleven a una mejor protección de nuestros datos, que en el fondo son el principal activo de nuestras empresas.
Con esta reflexión pretendo dejar en el lugar que le corresponde a la seguridad implementada en el motor de base de datos contra la implementada en el lado de la aplicación.
Independientemente de la tecnología y arquitectura usada para el desarrollo de la aplicación, la base de datos es el último bastión de la seguridad de nuestros datos y siempre surtirá el efecto deseado. Todos los motores de bases de datos incorporan elementos de seguridad suficientes para cualquier escenario, desde el modelo clásico, privilegios sobre tablas, vistas, columnas ó procedimientos y funciones, concedidos a los usuarios o roles, con la posibilidad de denegación -SQL Server- lo que nos lleva a roles “maximalistas” o sin esta posibilidad -Oracle- que nos lleva a roles “minimalistas”, pasando por la implementación jerárquica de la seguridad en la base de datos -SQL Server 2005 ó superior- lo que simplifica la gestión de los privilegios ya que privilegios concedidos en niveles superiores se heredan dinámicamente en los elementos de los niveles inferiores de la jerarquía formada por servidor - Base de datos – esquema – tablas, vistas, procedimientos y funciones. Oracle a partir de 8i implementa las “Virtual Private Databases” de forma que la misma consulta devuelve información distinta en función del usuario que la realiza, en función del entorno definido para el usuario, lo que representa un salto cualitativo, ya que la seguridad se aplica a nivel de fila, en lugar de tabla, de manera transparente al código de la aplicación.
La seguridad en el lado de la aplicación, normalmente es por ocultación -una concepción muy débil de la seguridad-, de opciones de menú en base a un usuario de la aplicación, pero no de la base de datos, accediendo a la base de datos mediante un único usuario de base de datos, generalmente con grandes privilegios -System ó dbo-, para todos los usuarios con acceso, con los problemas que ello conlleva tanto a nivel de acceso, inyección de código sql, “bugs” de la aplicación así como la imposibilidad de trazabilidad, en los acceso a la base de datos, tam importante en algunos sectores como el bancario o el sanitario.
Muchos argumentarán que la implementación de la seguridad del lado del motor de base de datos es más costosa, cuando en mi opinión es un problema de método, si la seguridad es una prioridad durante el desarrollo es muy fácil y económica su implementación, una vez desarrollada la aplicación no es ya momento del diseño de esta y lo único que nos queda es la huida hacia delante de la seguridad en el lado de la aplicación.
Por último y a modo de conclusión, comentar que en un altísimo porcentaje de las bases de datos sobre las que he trabajo, tanto Oracle como SQL Server, quizás el 85% ó el 90%, la seguridad está implementada solo y exclusivamente en el lado de la aplicación, tanto para aplicaciones comerciales como propias. Creo que ante estos números es evidente que debemos invertir, que no gastar, bastante más en la seguridad de nuestras bases de datos, o mejor dicho de nuestros datos, que al fin y al cabo son nuestro activo, tanto para protegerlos de miradas indiscretas como para evitar la manipulación incorrecta en base al principio de mínimos privilegios, haciendo accesible la información solo a aquel que realmente tiene la necesidad de conocerla.
Fermín de la Sierra Moreno, es administrador de bases de datos certificado para Oracle y Sql Server además de formador en el área de base de datos en Avante Formación
Con esta reflexión pretendo dejar en el lugar que le corresponde a la seguridad implementada en el motor de base de datos contra la implementada en el lado de la aplicación.
Independientemente de la tecnología y arquitectura usada para el desarrollo de la aplicación, la base de datos es el último bastión de la seguridad de nuestros datos y siempre surtirá el efecto deseado. Todos los motores de bases de datos incorporan elementos de seguridad suficientes para cualquier escenario, desde el modelo clásico, privilegios sobre tablas, vistas, columnas ó procedimientos y funciones, concedidos a los usuarios o roles, con la posibilidad de denegación -SQL Server- lo que nos lleva a roles “maximalistas” o sin esta posibilidad -Oracle- que nos lleva a roles “minimalistas”, pasando por la implementación jerárquica de la seguridad en la base de datos -SQL Server 2005 ó superior- lo que simplifica la gestión de los privilegios ya que privilegios concedidos en niveles superiores se heredan dinámicamente en los elementos de los niveles inferiores de la jerarquía formada por servidor - Base de datos – esquema – tablas, vistas, procedimientos y funciones. Oracle a partir de 8i implementa las “Virtual Private Databases” de forma que la misma consulta devuelve información distinta en función del usuario que la realiza, en función del entorno definido para el usuario, lo que representa un salto cualitativo, ya que la seguridad se aplica a nivel de fila, en lugar de tabla, de manera transparente al código de la aplicación.
La seguridad en el lado de la aplicación, normalmente es por ocultación -una concepción muy débil de la seguridad-, de opciones de menú en base a un usuario de la aplicación, pero no de la base de datos, accediendo a la base de datos mediante un único usuario de base de datos, generalmente con grandes privilegios -System ó dbo-, para todos los usuarios con acceso, con los problemas que ello conlleva tanto a nivel de acceso, inyección de código sql, “bugs” de la aplicación así como la imposibilidad de trazabilidad, en los acceso a la base de datos, tam importante en algunos sectores como el bancario o el sanitario.
Muchos argumentarán que la implementación de la seguridad del lado del motor de base de datos es más costosa, cuando en mi opinión es un problema de método, si la seguridad es una prioridad durante el desarrollo es muy fácil y económica su implementación, una vez desarrollada la aplicación no es ya momento del diseño de esta y lo único que nos queda es la huida hacia delante de la seguridad en el lado de la aplicación.
Por último y a modo de conclusión, comentar que en un altísimo porcentaje de las bases de datos sobre las que he trabajo, tanto Oracle como SQL Server, quizás el 85% ó el 90%, la seguridad está implementada solo y exclusivamente en el lado de la aplicación, tanto para aplicaciones comerciales como propias. Creo que ante estos números es evidente que debemos invertir, que no gastar, bastante más en la seguridad de nuestras bases de datos, o mejor dicho de nuestros datos, que al fin y al cabo son nuestro activo, tanto para protegerlos de miradas indiscretas como para evitar la manipulación incorrecta en base al principio de mínimos privilegios, haciendo accesible la información solo a aquel que realmente tiene la necesidad de conocerla.
Fermín de la Sierra Moreno, es administrador de bases de datos certificado para Oracle y Sql Server además de formador en el área de base de datos en Avante Formación
No hay comentarios:
Publicar un comentario