python security google-app-engine rsa sha

python - Protección de datos en el almacén de datos del motor de aplicaciones de Google



security google-app-engine (3)

Nuestra aplicación de motor de aplicaciones de Google almacena una buena cantidad de información de identificación personal (correo electrónico, ssn, etc.) para identificar a los usuarios. Estoy buscando consejos sobre cómo proteger esos datos.

Mi estrategia actual

Almacene los datos confidenciales en dos formas:

  • Hashed - usando SHA-2 y una sal
  • Encriptado - usando clave pública / privada RSA

Cuando tenemos que hacer búsquedas:

  • Haga búsquedas en los datos de hash (hash de la PII en una consulta, compárelos con la PII de hash en el almacén de datos).

Si alguna vez necesitamos volver a hacer un hash de los datos o tratarlos de otra manera:

  • Descifrar la versión encriptada con nuestra clave privada. Nunca lo almacene en forma sin procesar, simplemente procéselo, vuelva a codificar y vuelva a cifrarlo.

Mis preocupaciones

Mantener nuestro secreto de sal de hachís.

Si un atacante se hace con los datos en el almacén de datos, así como nuestra sal de hachís, me preocupa que puedan forzar la información confidencial. Algo de eso (como SSN, un número de 9 dígitos) no tiene un espacio clave grande, por lo que incluso con un algoritmo hash moderno, creo que podría hacerse si el atacante supiera la sal.

Mi idea actual es mantener la sal fuera del control de código fuente y en su propio archivo. Ese archivo se carga en GAE durante la implementación y la aplicación lee el archivo cuando necesita hash datos entrantes.

Entre las implementaciones, el archivo de sal vive en una llave USB protegida por un oso enojado (o una caja de seguridad).

Con la sal solo viviendo en dos lugares.

  1. La llave usb
  2. Implementado en aplicaciones de google

y con la descarga del código permanentemente inhabilitada, no se me ocurre una manera de que alguien pueda obtener la sal sin robar esa llave USB. ¿Me estoy perdiendo de algo?

Manteniendo en secreto nuestra clave RSA privada

Menos preocupado por esto. Será raro que tengamos que descifrar la versión cifrada (solo si cambiamos el algoritmo de hash o el formato de datos).

La clave privada nunca tiene que tocar el servidor GAE, podemos bajar los datos cifrados, descifrarlos localmente, procesarlos y volver a cargar las versiones cifradas / cifradas.

Podemos mantener nuestra clave privada RSA en una memoria USB protegida por un oso Y un tigre, y solo sacarla cuando la necesitemos.

Me doy cuenta de que esta pregunta no es exactamente específica de las aplicaciones de Google, pero creo que GAE hace que la situación sea algo única.

Si tuviera el control total, haría cosas como bloquear el acceso a la implementación y el acceso al visor del almacén de datos con autenticación de dos factores, pero esas opciones no están disponibles en este momento (tener una contraseña específica de GAE es bueno, pero me gusta teniendo tokens RSA involucrados).

Tampoco soy un experto en GAE ni un experto en seguridad, por lo que si falta un agujero o algo que no estoy pensando en algo específico de la plataforma, me encantaría escucharlo.

Al decidir sobre una arquitectura de seguridad, lo primero en su mente deben ser los modelos de amenaza. ¿Quiénes son tus potenciales atacantes, cuáles son sus capacidades y cómo puedes defenderte de ellos? Sin una idea clara de su modelo de amenaza, no tiene forma de evaluar si las medidas de seguridad propuestas son suficientes o incluso si son necesarias.

A partir de su texto, supongo que está tratando de protegerse contra un subconjunto de los siguientes:

  1. Un atacante que compromete los datos de su almacén de datos, pero no su código de aplicación.
  2. Un atacante que obtiene acceso a las credenciales para acceder a la consola de administración de su aplicación y puede implementar un nuevo código.

Para el primero, es probable que el cifrado o hashing de los datos de su almacén de datos sea suficiente (pero vea las advertencias más adelante en esta respuesta). Protegerse contra esto último es más difícil, pero mientras sus usuarios de administración no puedan ejecutar código arbitrario sin implementar una nueva versión de la aplicación, el almacenamiento de sus claves en un módulo que no esté registrado en el control de código fuente, como sugiere, debería funcionar bien , ya que incluso con acceso de administrador, no pueden recuperar las claves, ni pueden implementar una nueva versión que les revele las claves. Asegúrese de desactivar la descarga de la fuente, obviamente.

Con razón, tiene en cuenta algunas preocupaciones sobre el hash de datos con una cantidad limitada de entropía, y tiene razón en preocuparse. Hasta cierto punto, las sales pueden ayudar con esto al prevenir ataques de precomputación, y el estiramiento de las teclas, como el empleado en PBKDF2, scrypt y bcrypt, puede hacer que la vida de su atacante sea más difícil al aumentar la cantidad de trabajo que tienen que hacer. Sin embargo, con algo como el SSN, su espacio de teclas es simplemente tan pequeño que ninguna cantidad de estiramiento de la clave lo ayudará, si el hash de los datos y el atacante obtiene el hash, podrán determinar el SSN original.

En tales situaciones, su único enfoque viable es cifrar los datos con una clave secreta. Ahora su atacante está obligado a forzar la fuerza bruta para obtener los datos, un desafío que es mucho más difícil en órdenes de magnitud.

En resumen, mi recomendación sería cifrar sus datos utilizando un cifrado estándar (clave privada), con la clave almacenada en un módulo que no está en control de origen. El uso de hash, en cambio, solo debilitará sus datos, mientras que el uso de criptografía de clave pública no proporciona una seguridad apreciable contra cualquier modelo de amenaza plausible que no tenga al usar un cifrado estándar.

Por supuesto, la primera forma de proteger los datos de sus usuarios es no almacenarlos, en primer lugar, si puede. :)

Puede aumentar la seguridad de su algoritmo de hash mediante el uso de HMAC, una clave secreta y una sal única por entrada (sé que la gente no estará de acuerdo conmigo en esto, pero mi investigación me dice que ayuda a evitar ciertos ataques). También puede usar bcrypt o scrypt para hacer hash, lo que hará que revertir el hash sea un proceso extremadamente lento (pero también tendrá que tenerlo en cuenta al tiempo que le toma a su aplicación calcular el hash).

Al deshabilitar las descargas de código y mantener su clave secreta protegida, no puedo imaginar cómo alguien puede obtenerla. Solo asegúrese de que su código se mantenga protegido por guardias de seguridad similares o que elimine la clave secreta de su código durante el desarrollo y que solo lo saque para desplegarlo. Supongo que mantendrás tu clave secreta en tu código (he escuchado a muchas personas decir que deben estar en la memoria para que sean ultra seguras, pero dada la naturaleza de AppEngine y las instancias, esto no es posible).

Actualización: asegúrese de habilitar la autenticación de 2 factores para todas las cuentas de Google que tienen derechos de administrador en su aplicación. Google ofrece esto, por lo que no estoy seguro si su restricción para habilitar esto fue impuesta por una fuerza externa o no.

Un enfoque interesante para cifrar los datos en un almacén de datos. Después de pasar por esto, una pregunta que me viene a la mente es cómo consultar datos en sus hashes. ¿Está utilizando la comparación de dos hashes o más hashing de grano fino? Nuevamente, ¿cómo realiza operaciones como mayor que valor, menor que valor después de hash y cifrar los datos en su tabla?

Significado de hashing de grano fino , hash bytes consecutivos de un flujo de datos para obtener el hash acumulado. es decir, hash (abcd) = hash (a, b) + hash (b, c) + etc. Este tipo de hashing diría qué tan similares son los datos subyacentes en lugar de una coincidencia.