He leído algunos temas sobre la seguridad de la base de datos. Ahora tengo dos preguntas sobre la confidencialidad y la violación de integridad. Gracias a todos los que me responden:
1) Si consideramos que conocer la disponibilidad de datos es un tipo de confidencialidad?
Sí, saber que la disponibilidad de datos es un tipo de violación de confidencialidad. Un ejemplo es un mensaje de error que revela si existe un nombre de usuario o no en la base de datos.
2) ¿Cuál es el problema de integridad referencial en la seguridad de la base de datos?
Para que los elementos de la base de datos se sincronicen consistentemente, varias tablas que segregan datos sobre un solo atributo deben vincularse correctamente. En otras palabras, no debería existir ningún conjunto de datos deshonestos.
Supongamos que tengo una aplicación con dos tablas de base de datos user_credentials & user_activity .
user_credentials tiene las columnas user_name y user_passwd .
user_activity tiene user_name & user_lastlogintime .
La integridad referencial es la propiedad por la cual ambas tablas tienen exactamente los mismos valores en el campo user_name . Esto garantiza la coherencia al acceder o eliminar los elementos de la tabla.
3) ¿La violación de la confidencialidad puede llevar a una violación de la integridad?
Es posible. Pero ambos tienen que ser considerados por separado. Considere un escenario donde se usa un algoritmo de hashing roto con una colisión conocida. El conocimiento sobre el algoritmo roto se puede utilizar para omitir las comprobaciones de integridad. Pero desde una perspectiva de seguridad de la información, la violación de la integridad ocurre debido al uso de un algoritmo roto, aunque es el resultado de un compromiso de confidencialidad.
"¿Puede la integridad referencial divulga la disponibilidad de datos en la base de datos y conlleva a una violación confidencial"
Es posible. En un ejemplo simple, un intento de eliminar un registro de cliente puede fallar si hay un pedido o un registro de pago que pertenece al cliente. Sin embargo, esto solo funciona si hay circunstancias en las que se permite la eliminación. A menudo, los elementos de datos nunca se 'eliminan' (eliminados), sino que simplemente se marcan como 'eliminados', 'archivados' o 'inactivos'.
En la otra dirección, la inserción de un registro de pago puede rechazarse si el cliente no existe. Pero si los identificadores son arbitrarios, el atacante a menudo no podría intentar esto sin conocer el identificador del cliente. Es más probable que puedan hacer estimaciones del número de empleados, clientes, facturas, etc. en el sistema.
Es más probable que las restricciones de singularidad lleven a una fuga de información (por ejemplo, la tarjeta de crédito, el número de teléfono o la dirección de correo electrónico ya están en el sistema).
Lea otras preguntas en las etiquetas databases confidentiality integrity