Separación por tablas

La separación por tablas parece una buena idea, especialmente si puede estimar la importancia de las tablas para su seguridad. Por ejemplo, una tabla con nombres de usuario y contraseñas es bastante importante, mientras que una tabla con comentarios de blog es menos importante. Si tiene un usuario de base de datos diferente para esas tablas importantes, una inyección en, por ejemplo, una consulta que selecciona comentarios podría no ofrecerle al atacante ninguna ventaja real, ya que no pueden acceder a los datos relevantes (lo máximo que podrían hacer es reflejar XSS).

La separación del blog y el sitio web también parece razonable (al menos desde el punto de vista del diseño del sistema), pero les daría a cada uno de ellos una base de datos separada (realmente no parecen pertenecer entre sí, por lo que es lógico sentido, y también sería más fácil de manejar).

Separación por lectura / escritura

No estoy seguro de que valga la pena separar por escritura y leer (¿cuál sería el hilo real contra el que defiende? Creo que principalmente un atacante que inyecta una entrada de blog), y probablemente será difícil de cumplir. Por ejemplo, si tiene un usuario administrador que puede editar la base de datos a través de una interfaz web:

• el atacante puede leer: el atacante puede leer la contraseña del administrador y, por lo tanto, escribir (a través de la interfaz web)
• el atacante puede escribir: el atacante puede agregar una contraseña de administrador y leer (a través de la interfaz web)

La administración de los privilegios por el prefijo de la tabla tampoco parece ser una buena idea. Considera esto (esto podría ser un poco exagerado, pero es solo un ejemplo de cómo omitir tus reglas):

• website_read tiene derechos de selección en website_*
• global_write tiene derechos de escritura en website_* y blog_*
• blog_read tiene derechos de selección en blog_*
• el atacante tiene acceso a global_write y blog_read (por ejemplo, a través de una inyección) y quiere leer website_users (para el que no tienen derechos)
• el atacante cambia el nombre de la tabla website_users a blog_users con global_write [*], y la lee con blog_read .

_{[*] Si esto está realmente permitido dependería de tu sistema concreto, pero generalmente, cambiar el nombre es una actividad de escritura. Por ejemplo, MySQL requiere ALTER, DROP, CREATE e INSERT a los que llamaría escribir. derechos.}

Debe distinguir entre la cuenta utilizada para conectarse a la base de datos y la cuenta del usuario original:

• la cuenta de servicio utilizada para conectar la aplicación a la base de datos debe usarse para restringir el acceso a aquellos esquemas y tablas a los que se va a acceder. La cuenta de servicio debe centrarse en aspectos de seguridad, como la prevención DROP o CREATE TABLE, los tipos de acciones de SQL que normalmente no se requieren en una operación diaria
• la cuenta (o identidad) del usuario original: no es práctico crear una cuenta en la base de datos para todos y cada uno de los usuarios que potencialmente usarían la base de datos. Sin embargo, aún desea controlar el acceso a los datos (tenga en cuenta el acceso a los datos en sí, no a la base de datos en sí). A nivel del usuario, también podemos preocuparnos por controlar en qué celdas / filas / tablas específicas puede realizar un usuario las acciones de CRUD.

Tomemos tu ejemplo de blog. Tenemos una tabla llamada blog_post. Desea implementar la siguiente lógica de autorización:

• todos los usuarios autenticados pueden ver cualquier publicación de blog.
• un usuario con el rol de aprobación puede cambiar el estado de una publicación de blog del borrador

Hay varias maneras de lograrlo:

• configure la autorización detallada utilizando las herramientas de su base de datos, por ejemplo.
  • Oracle VPD (Virtual Private Database)
  • IBM DB2 RCAC (control de acceso de fila y columna)
• configure la autorización precisa usando un proxy frente a sus bases de datos
  • IBM Guardium
  • Filtro de acceso a datos axiomáticos MD (ADAF MD)

Lo que esto te permite hacer es

1. desacoplar la autorización de la base de datos en sí. En lugar de tener que crear tablas, roles y cuentas de usuario artificiales, puede expresar una lógica precisa utilizando las herramientas disponibles en VPD, DB2 o Axiomatics.
2. Implemente el control de acceso basado en atributos (como definido por NIST ) y la seguridad centrada en los datos.

El enfoque de proxy también permite la externalización completa de la lógica de control de acceso.

Algunos de los beneficios incluyen:

• enfoque no intrusivo: no necesita cambiar nada en su base de datos. Eso definitivamente hará feliz a tu sysdba
• reutilizable para otros niveles, por ejemplo, el nivel de aplicación o incluso el nivel de presentación
• más fácil de mantener y auditar. ABAC utiliza atributos (pares clave-valor, por ejemplo, rol == administrador) y políticas.

HTH