encryption - tipo - que es ec2

¿Cuál es el mejor método para pasar credenciales de AWS como datos de usuario a una instancia de EC2? (5)

Al igual que otros ya han señalado aquí, no es necesario que almacene las credenciales de AWS para una instancia de EC2, mediante el uso de Roles de IAM - https://aws.amazon.com/blogs/security/a-safer-way-to-distribute-aws-credentials-to-ec2/ . Añadiré que puede emplear el mismo método también para almacenar de forma segura las credenciales de NON-AWS para su instancia de EC2, por ejemplo, si tiene algunas credenciales de db que desea mantener seguras. Guarda las credenciales que no son Aws en un S3 Bukcet y usa la función IAM para acceder a ese depósito. puede encontrar información más detallada al respecto aquí - https://aws.amazon.com/blogs/security/using-iam-roles-to-distribute-non-aws-credentials-to-your-ec2-instances/

Tengo una arquitectura de procesamiento de trabajos basada en AWS que requiere que las instancias EC2 consulten S3 y SQS. Para que las instancias en ejecución tengan acceso a la API, las credenciales se envían como datos de usuario (-f) en forma de script de shell codificado en base64. Por ejemplo:

$ cat ec2.sh ... export AWS_ACCOUNT_NUMBER=''1111-1111-1111'' export AWS_ACCESS_KEY_ID=''0x0x0x0x0x0x0x0x0x0'' ... $ zip -P ''secret-password'' ec2.sh $ openssl enc -base64 -in ec2.zip

Se lanzan muchas instancias ...

$ ec2run ami-a83fabc0 -n 20 -f ec2.zip

Cada instancia decodifica y descifra ec2.zip usando la ''contraseña secreta'' que está codificada en un script de inicio. Aunque funciona, tengo dos problemas con mi enfoque.

''zip -P'' no es muy seguro
La contraseña está codificada en la instancia (siempre es ''contraseña secreta'')

El método es muy similar al descrito here

¿Hay un enfoque más elegante o aceptado? Usar gpg para encriptar las credenciales y almacenar la clave privada en la instancia para descifrarlo es un enfoque que estoy considerando ahora, pero no tengo conocimiento de ninguna advertencia. ¿Puedo usar los pares de claves de AWS directamente? ¿Me estoy perdiendo alguna parte muy obvia de la API?

Escribí un artículo examinando varios métodos para pasar secretos a una instancia de EC2 de forma segura y los pros y contras de cada uno.

http://www.shlomoswidler.com/2009/08/how-to-keep-your-aws-credentials-on-ec2.html

La mejor forma es usar perfiles de instancia . La idea básica es:

Crear un perfil de instancia
Crear un nuevo rol de IAM
Asigne una política al rol creado anteriormente, por ejemplo:
{"Declaración": [{"Sid": "Stmt1369049349504", "Acción": "sqs: ", "Efecto": "Permitir", "Recurso": " "}]}
Asociar el rol y el perfil de instancia juntos.
Cuando inicie una nueva instancia de EC2, asegúrese de proporcionar el nombre de perfil de la instancia.

Si todo funciona bien y la biblioteca que utiliza para conectarse a los servicios de AWS desde su instancia de EC2 admite la recuperación de las credenciales de los metadatos de la instancia, su código podrá usar los servicios de AWS.

Un ejemplo completo tomado de la lista de correo de boto-usuario:

En primer lugar, debe crear un documento de política JSON que represente a qué servicios y recursos debe tener acceso el rol de IAM. por ejemplo, esta política otorga todas las acciones de S3 para el depósito "my_bucket". Puede usar cualquier política que sea apropiada para su aplicación.

BUCKET_POLICY = """{ "Statement":[{ "Effect":"Allow", "Action":["s3:*"], "Resource":["arn:aws:s3:::my_bucket"]}]}"""

A continuación, debe crear un perfil de instancia en IAM.

import boto c = boto.connect_iam() instance_profile = c.create_instance_profile(''myinstanceprofile'')

Una vez que tenga el perfil de instancia, debe crear el rol, agregar el rol al perfil de instancia y asociar la política con el rol.

role = c.create_role(''myrole'') c.add_role_to_instance_profile(''myinstanceprofile'', ''myrole'') c.put_role_policy(''myrole'', ''mypolicy'', BUCKET_POLICY)

Ahora, puedes usar ese perfil de instancia cuando ejecutas una instancia:

ec2 = boto.connect_ec2() ec2.run_instances(''ami-xxxxxxx'', ..., instance_profile_name=''myinstanceprofile'')

Me gustaría señalar que ya no es necesario proporcionar ninguna credencial a su instancia EC2. Con IAM, puede crear un rol para sus instancias EC2. En estos roles, puede establecer políticas detalladas que permitan que su instancia de EC2, por ejemplo, obtenga un objeto específico de un segmento S3 específico y no más. Puede obtener más información sobre las funciones de IAM en los documentos de AWS:

http://docs.aws.amazon.com/IAM/latest/UserGuide/WorkingWithRoles.html

Puede almacenar las credenciales en la máquina (o transferirlas, usarlas y luego eliminarlas).

Puede transferir las credenciales a través de un canal seguro (por ejemplo, usando scp con autenticación no interactiva, por ejemplo, par de claves) para que no tenga que realizar ningún cifrado personalizado (solo asegúrese de que los permisos estén configurados correctamente en 0400 en el archivo de clave) veces, por ejemplo, establezca los permisos en los archivos maestros y use scp -p )

Si lo anterior no responde su pregunta, proporcione detalles más específicos. cuál es tu configuración y qué estás tratando de lograr. ¿Se deben iniciar acciones EC2 en múltiples nodos desde una ubicación central? ¿Está SSH disponible entre los múltiples nodos y la ubicación central? Etc.

EDITAR

¿Ha considerado la parametrización de su AMI , requiriendo que aquellos que instancian su AMI llenen primero los datos de usuario ( ec2-run-instances -f user-data-file ) con sus AWS? Su AMI puede recuperar dinámicamente estos parámetros por instancia desde http://169.254.169.254/1.0/user-data .

ACTUALIZAR

OK, aquí va una comparación de mentalidad de seguridad de los diversos enfoques discutidos hasta ahora:

Seguridad de los datos cuando se almacenan en los user-data AMI sin cifrar
- bajo
- los datos de texto sin formato son accesibles para cualquier usuario que logre iniciar sesión en el AMI y tenga acceso a telnet , curl , wget , etc. (puede acceder al texto claro http://169.254.169.254/1.0/user-data )
- usted es vulnerable a ataques de solicitud de proxy (por ejemplo, un atacante le pregunta al Apache que puede o no ejecutarse en el AMI para obtener y reenviar el texto claro http://169.254.169.254/1.0/user-data )
Seguridad de los datos almacenados en los user-data AMI y encriptados (o desencriptables) con clave fácilmente obtenible
- bajo
- la clave fácil de obtener (contraseña) puede incluir:
  - clave codificada en un script dentro de un ABI (donde el atacante puede obtener el ABI)
  - clave codificada en una secuencia de comandos en la propia AMI, donde la secuencia de comandos es legible por cualquier usuario que logre iniciar sesión en la AMI
  - cualquier otra información fácilmente obtenible, como claves públicas, etc.
  - cualquier clave privada (su clave pública puede obtenerse fácilmente)
- Dada una clave fácil de obtener (contraseña), se aplican los mismos problemas identificados en el punto 1, a saber:
  - los datos descifrados son accesibles para cualquier usuario que logre iniciar sesión en el AMI y tenga acceso a telnet , curl , wget , etc. (puede acceder al texto claro http://169.254.169.254/1.0/user-data )
  - usted es vulnerable a los ataques de solicitud de proxy (por ejemplo, el atacante le pide al Apache que se ejecute o no en el AMI para obtener y reenviar el http://169.254.169.254/1.0/user-data encriptado, descifrado ulteriormente con la información fácilmente obtenible) llave)
Seguridad de los datos cuando se almacenan en los user-data AMI y encriptados con clave difícil de obtener
- promedio
- los datos encriptados son accesibles para cualquier usuario que logre iniciar sesión en el AMI y tenga acceso a telnet , curl , wget , etc. (puede acceder a los http://169.254.169.254/1.0/user-data )
  - un intento de descifrar los datos encriptados se puede hacer usando ataques de fuerza bruta
Seguridad de los datos cuando se almacenan en la AMI, en una ubicación segura (sin valor agregado para que se cifre)
- mayor
- los datos solo son accesibles para un usuario, el usuario que requiere los datos para poder operar
  - por ejemplo, archivo propiedad del usuario: usuario con máscara 0600 o 0400
- el atacante debe ser capaz de suplantar al usuario en particular para obtener acceso a los datos
  - capas de seguridad adicionales, como negarle al usuario el inicio de sesión directo (tener que pasar por la root para la suplantación interactiva) mejora la seguridad

Por lo tanto, cualquier método que implique los user-data AMI no es el más seguro, ya que obtener acceso a cualquier usuario de la máquina (punto más débil) compromete los datos.

Esto podría mitigarse si las credenciales S3 solo fueran necesarias durante un período de tiempo limitado (es decir, solo durante el proceso de implementación), si AWS le permitió sobrescribir o eliminar el contenido de user-data del user-data cuando finalizó (pero esto no aparece) para ser el caso.) Una alternativa sería la creación de credenciales S3 temporales durante la duración del proceso de implementación, si es posible (comprometiendo estas credenciales, a partir user-data de user-data , después de que se complete el proceso de implementación y las credenciales hayan sido invalidadas con AWS , ya no representa una amenaza a la seguridad).

Si lo anterior no es aplicable (p. Ej., Credenciales S3 necesarias para los nodos desplegados indefinidamente) o no posible (p. Ej., No se pueden emitir credenciales S3 temporales solo para la implementación), el mejor método sigue siendo morder y scp las credenciales a los distintos nodos, posiblemente en paralelo, con la propiedad y los permisos correctos.