Seguridad Base de Datos

[miguec04]

hola amigos escribo este tema porque ya no me aguanto la curiosidad de expertos que trabajan a diario como uds, bueno una forma de manejar los usuarios por ejemplo que es lo mas común que veo en software web ya desarrollado como joomla es hacer una tabla llamada usuarios y otra roles que supuesta-mente es con lo que voy a medir los permisos, pero platicando y platicando con una profe mía de oracle, me decía que eso es regalar la información Por que? porque las validaciones en los permisos nosotros lo vamos a hacer mediante programacion en el lenguaje X que utilicemos mientras el usuario DE LA INFORMACION que realmente es lo importante que es el usuario del manejador de base de datos que en el caso de MYSQL es root en el caso de postgres es postgres etc... ese verdadero usuario tienen todos los privilegio por lo tanto el que pudiese hacer injection o lo que sea necesario para enviar una consulta una sentencia sql por medio de este usuario podría hasta borrar la base de datos por lo tanto la información no estaría protegida...

Entonces la idea es o mejor la Pregunta es:

Cual es la mejor forma de proteger la información??? por medio de una o dos o tres o x tablas nosotros mismos programar los permisos en nuestro lenguaje que utilicemos, o hacerlo mejor con usuarios directamente del manejador de base de datos.

Segunda pregunta:

si es la segunda opción que para mi es la mas obvia que es utilizar los usuarios del manejador de base de datos COMO PORQUE MUCHAS APLICACIONES POR NO DECIR TODAS SIEMPRE MANEJAN LOS USUARIOS POR MEDIO DE TABLAS?.

es un defecto de nosotros los desarrolladores? o de algunos por lo menos?? que esta pasando?.

Gracias por sus opiniones.

Un amigo mas

Miguel Carmona.

[gnzsoloyo]

En primer lugar, tanto tu profesora, como tu, y eventualmente los que diseñan en Joomla o cualquier cosa se están olvidando es que MySQL no tiene un único usuario. Tiene o puede tener tantos usuarios como se creen en él, por lo que decir que es inseguro es por lo menos absurdo: MySQL es tan seguro como tú mismo lo manejes.
El problema es que muchas personas manejan con liviandad la administración de usuarios y permisos en MyQL, como si supusieran que se trata de algo superfluo. Eso sí es un error.
MySQL, tiene por default un sólo administrador (el root), pero es precisamente el root el que no debe usarse para acceder en páginas web. Es únicamente para administración de las bases.
Lo que corresponde es crear los usuarios que necesites para usar la web, pero con los permisos adecuados (restrictivos) para ello, pero no permisos amplios.
El problema, a nivel de hosting, es que los administradores del host no suelen ser muy generosos a la hora de darte usuarios, por lo que muchos de ellos gestionan los usuarios de la web internamente, accediendo con un único usuario general. Eso también es un error. Cada usuario, si lo quieres hacer más o menos bien, es conveniente que se certifique doblemente: Contra MySQL y contra la web...
Per esto implica mucha más programación, por lo que también influye el factor humano: La mayoría es demasiado ociosa para hacer algo de ese nivel... Y luego pagan con inseguridad.

Respecto a el sql-injection, eso se administra de otras formas, y no tiene relación específica u obligatoria con los permisos de los usuarios (al menso en cuanto a la creación de sentencias seguras). Se puede manejar programáticamente, o por medio de recursos de la base.
Eso depende de ti.

Sintetizando:
¿Cuál es el motivo de usar tablas propias para administrar usuarios?:

1) Falta de acceso a creación de usuarios. Los administradores de hosting no te dan muchos, y no suelen ddarte permisos para crearlos.

2) Ocio. Programar con certificación contra el DBMS es más complejo.

3) Desconocimiento. Muchos de los que usan estos recursos no están verdaderamente entrenados en seguridad informática, y menos en seguridad de bases de datos.

4) Estructuras predefinidas. Muchas aplicaciones que crean bases sobre modelos prefijados ya traen módulos simples de administración de usuarios. Serán ineficientes, pero están allí y no hay que hacer nada.

5) ...muchas otras razones.

Elige tu el orden y las razones.

[miguec04]

1. Yo no dije que mysql fuese malo, es pesimo en sus versiones antiguas ahora ultimo es que me acepta constraint entre otras restricciones... no mencione anteriormente cual era mejor que cual pero ya que tu mencionas mysql como forma de reclamo te respondo esto.

2. Si es un error fatal porque la informacion queda a plenitud del usuario que ingrese, igual si creara 1 o 5 usuarios adicionales de los administradores por defecto de cada manejador, no seria mejor crear uno por cada usuario que tenga el sistema?, esto se puede hacer igual si uno valida los usuarios desde tabla tambien puede volver algo seguro el ingreso, pero no igual de seguro a si entráramos a modificar la informacion en el manejador con nuestro propio usuario del manejador, porque si lo hacemos desde tabla solo estamos diciendo si existe x registro dejeme ver que puedo hacer según lo que el desarrollador haya realizado mas no segun los privilegios que el manejador de base de datos me deje. porque el usuario yo ya lo tengo creado con los privilegios completos que voy a utilizar.

[gnzsoloyo]

Lo siento, no era un reclamo sino una forma de expresar mis observaciones sobre lo que me parecía una visión reduccionista del problema.

Si es un error fatal porque la informacion queda a plenitud del usuario que ingrese, igual si creara 1 o 5 usuarios adicionales de los administradores por defecto de cada manejador, no seria mejor crear uno por cada usuario que tenga el sistema?

Esa es precisamente la forma correcta de hacerlo: Un user por cada usuiario de la página, con permisos permisos restrictuivos para acceder a las tablas de la base.
Y atención, estoy hablando de acceder a las tablas y no de acceder a la base.
Esa es precisamente la ventaja de los DBMS, y que, garantizo, MySQL maneja muy bien.

esto se puede hacer igual si uno valida los usuarios desde tabla tambien puede volver algo seguro el ingreso,

En realidad no, porque con el user y algún trabajo puedes acceder a la base por fuera de la aplicación, por lo que la seguridad implementada por medio de tablas propias dependerá de lo finamente programado de la aplicación misma.
No es lo mismo.

Te cuento algo de las experiencias en la empresa en que trabajo:
En uno de los proyectos que usamos tenemos un usuario que tiene permisos sólo para ver una tabla, porque es en esa sola tabla donde está la información que grabará. Esa misma tabla se usa luego para habilitarlo como user de la base (restringido a tres tablas solamente), pero la tarea de darle alta sólo la tiene otra categoría de usuario del sistema y nadie más. Y no es una tarea On-Line.
Todo esto permite que si el user entrase por fuera de la página, sólo podría ver esa tabla, que de todos modos tiene información encriptada, y es transitoria...

A otro nivel, otro de los proyectos (multiusuario y de acceso remoto, tiene implementada la seguridad de usuarios en varios niveles.

Por un lado, sólo dos categorías de usuarios peuden crear usuarios, y ninguno puede crear un superusuario. Y los usuarios que pueden crear tienen perfiles fijos, y no se pueden modificar por fuera del sistema (tienen cuádruple certificación).

Por otro lado, sólo el root puede crear esos dos usuarios, y sólo a través de la interfase programada, porque el algoritmo de encriptación no es de MySQL.

Además, la mayoría de los usuarios no tienen permisos para acceder más que a una tabla (sesiones), y sólo pueden ver sesiones dentro de la interfase (están encriptadas); el resto de las tareas se realizan por stored procedure, por lo que no tienen acceso al código, ni pueden hacer nada que el SP no contenga.

El sistema es suficientemente restrictivo para el acceso a datos de modo que ni accediendo a la misma tabla, dos personas pueden llegar a leer la misma información si no pertenecen a la misma categoría del mismo lugar de trabajo.

Como estas tareas son por SP, y dentro de la aplicación está todo creado por parámetros (no hay invocaciones a tabas ni a sentencias), el sql-injection no hace efecto porque cualquier cosa que le quieras insertar sólo genera errores, y si quieres reemplazar el nombre del SP por una sentencia, también, porque el objeto creado es un StoredProcedure y no un string...

O sea, hemos tratado de hacer el sistema lo mas impenetrable posible, y creemos haber hecho un buen trabajo, aunque nos ha llevado casi dos años afinarlo, porque el requisito esencial era que debía estar creado en MySQL...

Ojalá hubiese sido en otra cosa, no hubiésemos tenido que crear tantas cosas.

[miguec04]

osea, creo que lo que me dices es, si existen 100 o mas o menos usuarios del sistema es mejor crear para cada uno un usuario en el manejador de base de datos y guardar el registro de ese usuario en una tabla con el rol o niveles que tenga como informacion sobre el manejo de usuarios... cierto?.

[gnzsoloyo]

A mi entender, si.
En todo caso, en una web pública, como un foro, puedes trabajar con un mismo usuario con conexiones ilimitadas, pero ese mismo usuario debe tener permisos bastante restringidos, y deberás manejar buena encriptación en todas aquellos datos críticos.. Más aún: Ese usuario sólo debe poder funcionar por medio de la aplicación.
Un uso simple de eso es recordar que como el usuario en un foro, en realidad está trabajando en localhost (los scripts de php operan solamente en servidor), ese usuario debe tener permiso sólo para localhost y no para login remoto...