mysql - seguro - Almacenamiento de números de seguridad social
que pasa si presto mi numero de seguro social (11)
Bueno, no has dado ninguna información sobre lo que vas a hacer con estos números. Si alguna vez necesita recuperar un SSN, básicamente no tiene sentido hacer nada con esto, guárdelo en claro. Cualquier forma de encriptación en la que tenga el texto cifrado y la clave en el mismo lugar solo ralentizará un poco al atacante. Esto solo le importa a los atacantes que no pueden tomar grandes cantidades de datos, o que no pueden simplemente tomar toda su computadora, o que no son competentes para unirse a los puntos. Si se trata de este último caso, el control de acceso real en primer lugar es bastante más importante.
Sin embargo, si obtiene un SSN externamente y desea averiguar de quién es la cuenta, podría usar un hash de dirección única para hacerlo.
El departamento de recursos humanos de la empresa en la que trabajo actualmente me ha pedido que proporcione un sistema para almacenar los números de seguridad social de los empleados en la base de datos de nuestra compañía. La razón de esto es simplificar la finalización de la nómina, ya que usamos el software interno para las hojas de horas trabajadas de los empleados, pero tenemos que integrarlo con un software de terceros para nuestro sistema de nómina actual. Esta es una empresa relativamente pequeña (20-30 empleados), y solo almacenaremos los SSN de los empleados actuales (por lo que una violación solo tendría un impacto limitado), pero aún así me gustaría obtener seguridad.
Me gustaría saber si existe alguna convención para almacenar información tan delicada como los números de la seguridad social. No soy muy hábil en encriptación, y entiendo que hay varias técnicas de encriptación a las que podría recurrir, pero me preguntaba si había una forma en particular que fuera más adecuada para este tipo de situación. ¿Sería AES mi mejor apuesta?
En cuanto al software actual, estamos ejecutando MySQL y nuestra interfaz web está escrita en PHP y se ejecuta en un servidor IIS.
Hay varios documentos actuales que establecen políticas como el memorando de la Casa Blanca y el informe GAO de la GAO .
Más allá de eso, hay encryption , vpn y PKI para seguridad.
Mi recomendación sería confiar en limitar el acceso. Solo tiene una sola cuenta capaz de leer (y si es necesario escribir) la tabla donde se almacenan los SSN. Use esa cuenta desde su aplicación para acceder a la base de datos y bloquear el acceso desde cualquier otra cuenta.
Mi recomendación: almacene sus datos de MySQL en discos encriptados, para que en el caso de una mala colocación de la computadora portátil, etc., no se puedan recuperar los datos.
Si la aplicación de la base de datos está comprometida, por supuesto, nada puede ayudar, ya que la aplicación en sí misma usa los SSN. Tal vez ese es un error de diseño que puede corregir. Tiendo a pensar en términos de una aplicación pequeña y limitada que mapea el SSN a una clave (que no es SSN) y luego utiliza esa nueva clave como la "identificación de usuario" en su base de datos en lugar del SSN. Evitaría la proliferación del SSN a toda costa.
MySQL tiene una serie de funciones de encriptación que puede usar para codificar / decodificar. Deberían ser suficientes para una aplicación interna.
No estoy seguro de si puede hacer esto en MySQL, pero podría tener un desencadenador de inserción / actualización en la tabla que encripta los datos mientras se guardan en la base de datos, y luego tiene una vista en la tabla que descifra automáticamente el SSN.
Tenga en cuenta que esto solo se trata de encriptar los datos en el disco ; también querrá examinar el cifrado de la capa de transporte para proteger los datos en el cable (de nuevo, si MySQL lo admite).
Editado para agregar: Después de leer la respuesta de Marcin, me di cuenta de que no mencioné el problema de la administración de claves. Cualquiera que tenga acceso a las definiciones de desencadenante o vista también tiene acceso a la clave de cifrado, por lo que si MySQL tiene la capacidad de ocultar las definiciones de desencadenante y ver, también querrá analizar eso. Por supuesto, incluir la clave de cifrado con los datos encriptados es intrínsecamente inseguro en primer lugar, por lo que esta no es una solución perfecta .
No lo mencioné en ninguna parte, pero ¿es necesario que esta información esté en línea? De lo contrario, aseguraste una gran vía de ataque simplemente al tener esta información almacenada en una base de datos en una computadora que no está conectada a Internet. O bien, si puede salirse con la suya almacenado en su LAN en alguna parte (para que HR pueda tener acceso a él, o lo que sea), a diferencia de los servidores de producción, eso todavía es un paso en la dirección correcta.
Mencionaste que estás en una empresa relativamente pequeña, pero parece que una inversión en hardware barato no sería demasiado difícil para convencer a los que toman las decisiones, dado el beneficio de almacenar este tipo de información confidencial fuera de línea. Y salvo una gran cantidad de contrataciones en el futuro cercano, no necesita una computadora de clase servidor para almacenar información personal en ~ 30 empleados de ninguna manera.
Donde sea que lo almacene, aún consideraría algún tipo de encriptación. AES 256 es el estándar de seguridad actualmente en la mayoría de las aplicaciones y es ampliamente compatible. No parece que sea el tipo de aplicación bajo ningún tipo de carga, así que, de nuevo, no hay problema en comprar un tamaño de clave más grande junto con el hardware barato.
En lo que respecta a la implementación, si se siente cómodo con MySQL, quédese con eso, tienen las herramientas que necesita para hacer lo que desea: http://dev.mysql.com/doc/refman/5.0/en/encryption-functions.html
Al final, la seguridad se trata de capas, ninguna solución única va a ser la solución mágica, pero puede recorrer un largo camino agregando algunas medidas de seguridad bastante simples y de sentido común.
Editar: después de leer lo que dijo Graeme, creo que debo agregar que la mayoría de las brechas de seguridad son un trabajo interno: asegúrese de proteger sus datos a nivel de disco, a través de la base de datos y por cable.
No use el SSN como clave principal ni prolifere sus valores más de lo necesario. Use los números de identificación de los empleados u otros identificadores únicos generados. Esto reducirá la complejidad del problema.
Si es posible, mantenga los SSN en una instancia de base de datos completamente diferente y no permita que las funciones cotidianas de la aplicación externa la accedan.
Una vez que haya aislado el SSN, puede usar cualquiera de los métodos sugeridos para encriptar los datos. Encriptar las tablas físicas y cifrar los campos almacenados dificultará que alguien robe los archivos de la base de datos física o vea los SSN usando el acceso básico de SQL.
La principal preocupación es limitar el acceso a la tabla SSN a través de mecanismos DB, limitar el acceso al sistema operativo y asegurar la máquina físicamente. A través del DB, use los permisos más restringidos posibles. No permita el acceso a la web, en línea u otras cuentas "compartidas" a la mesa si es posible. En el acceso al sistema operativo, limite los inicios de sesión y el acceso al directorio a una lista conocida de usuarios. Active cualquier auditoría posible. En cuanto a la seguridad física, la máquina debe estar en un lugar cerrado / seguro.
Siga las pautas de la NSA sobre seguridad informática donde se almacenan los SSN y cualquier máquina que tenga acceso a esa máquina.
Dado que usted es solo una empresa pequeña, no necesita preocuparse demasiado por mantener los suministros de correo y los fondos / seguros para el control de la identidad en caso de incumplimiento. Las organizaciones con un gran número de empleados y / o clientes han enfrentado desafíos significativos para cumplir con los requisitos legales para la notificación de incumplimiento. Encontrar 26 millones de sobres con poca antelación no es fácil.
Si desea utilizar algún tipo de cifrado reversible, cuanto más fuerte mejor, y agregue algo de sal al SSN. Agregar sal hará que sea más difícil para un pirata informático revertir el cifrado con solo los datos de la base de datos. La sal debe ser numérica para mezclarse con el SSN.
El mejor método que he visto para almacenar datos confidenciales es el cifrado de clave pública y el almacenamiento de la clave privada en algún lugar que no sea la base de datos (por ejemplo, a través de una aplicación disponible solo para el director de Recursos Humanos y el CEO):
Luego comenzamos a almacenar las tarjetas de crédito de las personas ... pero en el sitio web las encriptamos inmediatamente con una clave pública. ...
En el back-end, teníamos la clave privada, y con la contraseña correcta podíamos descifrar temporalmente [la clave privada], luego usar [la clave privada] para descifrar una tarjeta de crédito y cargarla en un DVD.
Los números de Seguro Social caen bajo " PII " (información de identificación personal) ... y debe encriptarlos, pero no es obligatorio. Entonces, sí AES está perfectamente bien ... realmente, cualquier cosa que hagas es una ventaja.
Los números de tarjetas de crédito caen bajo el cumplimiento de "PCI" (Industria de tarjetas de pago), y eso es un desastre. Pero en tu caso, estás bien.
Por cierto: AES 128 se considera perfectamente lo suficientemente bueno para Visa, Amex, Discover, etc. (PCI).