2010-02-24 17 views
8

Estoy buscando encriptar algunos datos confidenciales en SQL Server, como números de cuenta bancaria y números de seguridad social para cumplir con las nuevas leyes estatales. Estoy usando SQL Server 2008 como mi base de datos con el código .NET. He usado .NET para encriptar contraseñas, pero para esto estoy pensando en utilizar el cifrado integrado de Microsoft cifrando las pocas columnas de datos que necesito con un simple Cifrado de clave simétrica. Si utilizo el cifrado de SQL Server, puedo descifrar los datos de las herramientas de informes externas y no solo dentro de mi aplicación .NET. Aquí está el ejemplo que estoy usando: http://blog.sqlauthority.com/2009/04/28/sql-server-introduction-to-sql-server-encryption-and-symmetric-key-encryption-tutorial-with-script/Cómo controlar lo que los usuarios pueden descifrar SQL Server Cifrado de clave simétrica

Se utiliza un certificado creado por SQL Server y entonces la función DecryptByKey para descifrar los datos, pero estoy tratando de determinar qué tan seguro que esto realmente es? ¿Cómo controlo qué usuarios pueden descifrar datos o alguien puede hacerlo si abren la clave simétrica y usan la función de descifrado?

Respuesta

10

tiene dos alternativas:

  1. de control criptográfico. Con esto, solo los usuarios que conocen la contraseña pueden descifrar los datos. La desventaja es que el usuario debe ingresar la contraseña de descifrado cada vez que accede a los datos. Un informe debe contener un parámetro de contraseña para que el usuario que ejecuta el informe rellene con la contraseña de acceso a datos. La aplicación debe solicitar la contraseña del usuario. Los sitios web deben solicitar la contraseña del visitante. Y así sucesivamente

  2. Control de acceso. Los datos están encriptados con una clave a la que SQL Server tiene acceso (en última instancia, la cadena de codificación va hasta la Clave maestra de servicio y está encriptada usando DPAPI). Esto no le brinda mayor protección que la de otorgar y denegar SELECT: el tiene acceso al control, no al control criptográfico. Tal esquema protege únicamente contra la pérdida accidental de medios (alguien encuentra un disco con su base de datos, o pierde una computadora portátil con la base de datos). Puede lograr lo mismo utilizando Transparent Data Encryption o encriptación de nivel de archivo (BitLocker).

El escenario de cifrado de datos común es para cifrar los datos con una clave simétrica, y luego encryt la clave simétrica con una clave asimétrica (por lo general la clave privada de un certificado). La clave asimétrica se cifra a su vez con una contraseña, y esta contraseña debe presentarse cuando se intenta acceder a los datos. La razón principal de esta indirección de dos niveles es el cambio de contraseña: cuando se compromete una contraseña o una clave privada, la clave simétrica se vuelve a cifrar con una clave asimétrica diferente o la clave asimétrica se vuelve a cifrar con una contraseña diferente. De esta forma, la contraseña de acceso ha cambiado sin necesidad de volver a cifrar todos los datos. Si el acceso se otorgaría directamente a la clave simétrica, un compromiso de contraseña posiblemente requeriría volver a encriptar todos los datos , posibles terabytes de datos.

Donde los dos escenarios que presento difieren es si la clave asimétrica también está codificada con la clave maestra de la base de datos o no. Caso 1) no es, caso 2) lo es. Todo esto se explica en Encryption Hierarchy.

+0

+1 Creo que esto merece al menos otros 5 ~ 10 votos favorables. – Sung

+0

Ahora sé POR QUÉ necesitamos cifrar la clave simétrica con la clave asimétrica (aparte del problema de rendimiento). Básicamente, puedo dar la contraseña a un DBA para hacer una inserción de datos a granel. Una vez que haya terminado, puedo cambiar la contraseña sin afectar el cifrado, y nadie puede descifrarlo excepto yo. Puedo repetir este proceso cuantas veces sea necesario. ¿Estoy en lo cierto? –

Cuestiones relacionadas