¿Qué es una buena refutación para los usuarios que desean cifrar todos los datos DENTRO DE Db?

4

Estoy creando una aplicación en VB.NET (WinForms) utilizando SQL Server 2008 R2 como Backend.

La aplicación es para rastrear el dinero de los empleados que aplazan cada cheque de pago, o mes, para depositar en cuentas separadas de "fondos". (Piense en ello como poner $ 200 de su cheque semanal en algunas acciones diferentes).

El lado comercial dice "¡TODOS LOS DATOS DEBEN ESTAR CIFRADOS!" lo que no tiene sentido para mí y hace que las consultas básicas ( Especialmente para las fechas) sean inutilizables. Eso hace que la utilización de un RDMS sea inútil .

Los campos solo que considero necesarios para cifrar serían:

  • Información del empleado (nombre, fecha de nacimiento, fecha de contratación, dirección, etc.)
  • Información del beneficiario del empleado (nombre, dirección del SSN)
  • Número de cuenta interno que podría estar vinculado a un empleado mediante nómina

Nada más encriptado (en mi opinión) no considera que la información de estas personas esté en riesgo.

¿Qué puedo decirle a los usuarios de negocios para que realmente me hagan oír y me crean? Estos son ejecutivos / funcionarios dentro de la compañía, ¡por lo que se agradecería un tono respetuoso!

* Editar: * La información debe cifrarse para que los DBA no puedan verla, incluso si tienen acceso a ella. Ya he tratado de abrir TDE. No es una opción .

    
pregunta Mark LaREZZA 26.02.2014 - 14:09
fuente

3 respuestas

2
  

Estoy creando una aplicación en VB.NET (WinForms) utilizando SQL Server 2008 R2 como Backend.

     

* Editar: * La información debe cifrarse para que los DBA no puedan verla, incluso si tienen acceso a ella.

Bueno, eso restringe las cosas, suponiendo que los DBA tengan acceso completo a las comunicaciones que entran y salen del servidor de la base de datos, esto indica que para cumplir con el requisito, el cifrado debe realizarse antes de la llegada de los datos a la base de datos. y el descifrado debe realizarse después de la salida de la base de datos.

Por lo tanto, podemos considerar lo siguiente:

  • Alguna aplicación o capa de middleware debe manejar el cifrado y el descifrado.
    • ¡Habla con los DBA! Vea lo que ellos piensan al respecto.
      • Si están de acuerdo con usted en que es una mala idea, entonces trabaje con ellos para comunicar sus inquietudes compartidas a la gerencia.
    • Tenga en cuenta que el cifrado no impide que los índices sean útiles para búsquedas en igualdad de condiciones: un índice de base de datos es tan útil para buscar "Bob" o "1 de enero de 2010" como para buscar "51hsnGL58Uz" o " n8DfUp9vvJJECT ". Son las operaciones de desigualdad las que se convierten en:
      • No puedo hacerlo de manera efectiva / eficiente
      • Genere una lista de todas las opciones dentro del rango / desigualdad, cifre cada una de ellas y luego realice una operación de igualdad usando índices.
      • Descargue el conjunto de datos completo a la aplicación (guárdelo en caché si hay suficiente RAM disponible), descifre, guárdelo todo en caché si tiene RAM, luego realice la operación localmente.
      • Tener tablas / dimensiones de datos agregados que la aplicación mantiene actualizadas "con la frecuencia suficiente" para ese tipo de consultas / informes basados en rango (fecha).
  • Si es posible, ayude a los DBA a establecer una prueba de concepto, y quiero decir que realmente los ayude.
    • También trabajen juntos para cargar con la cantidad "esperada" de datos que verá en 2-3 años, y luego trabajen juntos para hacer pruebas de estrés de rendimiento.
      • O tienes razón, y no manejará la carga (probablemente así), o te equivocas, y no tienes nada de qué preocuparte.
  • Sea claro acerca de las limitaciones de los datos totalmente encriptados que no se le permite ver en el negocio.
  • Sea claro acerca de las limitaciones de los datos totalmente encriptados que no se le permite ver en los DBA para la empresa (es decir, no necesita más ayuda de ellos para resolver problemas, encontrar datos incorrectos o corregir datos incorrectos).
  • Sea claro acerca de los costos agregados, el tiempo agregado para el proyecto y el riesgo agregado, incluido pero no limitado a la recuperación de desastres, la restauración de las copias de seguridad, la necesidad de cambiar las claves de cifrado cuando se filtran / los DBA los encuentran / los requisitos cambian / alguien que Teniéndolos ya no está empleado, etc.
    • El cifrado realizado correctamente significa que si las claves se pierden / corrompen y no se realiza una copia de seguridad, sus datos desaparecen. Esto significa que la administración de claves es un asunto muy importante.

Puede y debe preguntar a la empresa sobre:

  • Los objetivos comerciales que se pretende que cumpla con este requisito (es decir, el modelo de amenaza @ColinCassidy mencionado).
  • Cómo interactúan esos objetivos con otros objetivos comerciales que pueden afectar, como el rendimiento, es decir, la prioridad y los recursos.
  • Requisitos legales, cumplimiento normativo, requisitos de auditoría o estándares de la industria que pueden estar impulsando esto.
    • Si lo hay, pida referencias a los requisitos originales; léalos cuidadosamente, porque son importantes.
  • Usted, como desarrollador, o bien podrá ver los datos desencriptados, ya que tendrá las claves, o no tendrá las claves y no podrá investigar de manera efectiva los posibles datos incorrectos. en producción.
    • es decir, "¿Por qué el fondo de Bill tiene $ 520.15? ¡Eso está mal!" obtiene respuesta con "No puedo ver los datos, ni los DBA. Lo siento; por favor, repítalo en un entorno de prueba donde yo o los DBA puedan ver los datos".

En una nota de política de la oficina, o estás lidiando con problemas de cumplimiento legal o regulatorio (en cuyo caso es lo suficientemente normal), o los DBA y tú deberías actualizar tu currículum, en caso de que simplemente no confíen en ti. gente.

    
respondido por el Anti-weakpasswords 27.02.2014 - 04:47
fuente
4

Mira lo que tienes allí es una solución que busca un problema.

Deberías comenzar preguntando a la empresa qué problema es si en realidad están tratando de resolverlo. lo más probable es que desee encuadrar la respuesta en términos de CIA (Confidencialidad, Integridad, Disponibilidad).

Si se siente realmente valiente, intente que la empresa realice un modelo de amenaza en el sistema, es posible que la confidencialidad de los datos no sea necesariamente su mayor riesgo.

Una vez que tenga esa información, puede llegar a mitigaciones reales del problema real que no necesariamente incluyen el cifrado de toda la base de datos. p.ej. Para la confidencialidad puede usar buenas listas de control de autorización / acceso. Para la integridad de los datos, puede considerar el uso de hashes de datos o MAC (también debería considerar una auditoría sólida para ver quién está usando / cambiando los datos). Para Disponibilidad, está buscando soluciones de TI típicas para esto, copia de seguridad y restauración de datos, redundancias de servidores, etc.

    
respondido por el Colin Cassidy 26.02.2014 - 16:41
fuente
0

Pídales que clasifiquen una lista de requisitos en orden de importancia. Incluya requisitos de seguridad, tales como:

  

# 1. Los DBA no pueden ver la identidad del empleado (nombre, DOB).

     

# 2. Los DBA no pueden ver los detalles de la transacción (fecha, monto).

y requisitos de rendimiento:

  

# 3. Responda a la consulta de búsqueda de la forma a en b segundos.

     

# 4. Responda a la consulta de búsqueda de la forma c en d segundos.

Si clasifican los requisitos en el orden anterior, dibuje una línea debajo del # 2 y dígales que eso es todo lo posible.

Si ponen cualquier requisito de rendimiento antes del # 2, dibuje la línea arriba del # 2.

Entonces es su responsabilidad decidir si hay que comprometerse. Si aún deciden que el # 2 es más importante que cualquier desempeño razonable, cámbielo y mantenga toda la evidencia de que eso es lo que pidieron.

    
respondido por el Jonathan Giddy 26.02.2014 - 16:24
fuente

Lea otras preguntas en las etiquetas