Credenciales en instancias EC2
Si alguna vez has desarrollado alguna aplicación web con cierto grado de complejidad te habrás dado cuenta de que en algún momento también necesitas almacenar credenciales, tokens, secretos e información sensible en estas aplicaciones.
En un entorno AWS, estas aplicaciones suelen ejecutarse en instancias EC2, que son máquinas virtuales creadas por Amazon bajo una serie de parámetros que nosotros decidimos. En otros casos, podrían estar ejecutándose en contenedores, o haber sido creadas por Kubernetes, y esto abriría un amplio abanico de ataques que dejaremos para otro white paper. Por ahora, analicemos cómo asegurar los secretos de las aplicaciones en instancias EC2.
En primer lugar, echemos un vistazo a las principales formas que utilizan los atacantes para acceder a información sensible en este contexto:
1- Acceso root: Un acceso root a una cuenta AWS implica un acceso sin restricciones a la información contenida en ella. El usuario Root en sistemas Linux otorga el mismo nivel de privilegios y acceso. Si un atacante es Root, ya sea en linux o en AWS, se acabó el juego.
2 - Malas prácticas a la hora de almacenar información sensible: El uso de URL públicas, objetos públicos en buckets de S3 o la codificación rígida de credenciales en el código fuente de la aplicación, implican formas fáciles para que los atacantes accedan a nuestros datos.
3 - Escalada de privilegios: Aquí se encuentran todas las técnicas de escalada de privilegios mencionadas en nuestra última edición (“Los 5 mejores consejos de seguridad: Infraestructura en la nube de AWS”), en la sección “Principio del menor privilegio”. Si una técnica de escalada es posible, cualquier atacante con privilegios mínimos tendrá acceso a las instancias EC2 y podrá leer cualquier información que contengan.
4 - Datos del usuario: AWS nos da la opción de utilizar el campo user-data, disponible en la API de metadatos de AWS, a través de la URL http://169.254.169.254/1.0/user-data. Si colocamos secretos ahí, cualquier aplicación que abra un socket en esa dirección tendrá acceso a nuestra información sensible. Esto incluye, por supuesto, atacantes que exploten un error SSRF en la aplicación, configuraciones erróneas de Firewall y/o proxy inverso, y atacantes con acceso limitado a AWS, pero con el privilegio de leer metadatos de EC2.
Estos son algunos de los posibles vectores de ataque.
¿Cómo podemos evitarlos? Hay varias opciones disponibles, pero ninguna de ellas es una solución de oro: cada una tiene ventajas e inconvenientes y requiere un análisis más profundo:
1. Uso de roles IAM.
2. Codificación del secreto en la imagen AMI.
3. Codificar el secreto en una URL pública/autenticada.
4. Utilizando objetos S3 privados y proporcionando la URL tú mismo.
5. Envío de secretos en el tiempo de despliegue de la instancia.
6. Envío del secreto a través de datos de usuario.
7. Uso de AWS Secrets Manager.
8. Utilización de un sistema de gestión de secretos y cifrado basado en la identidad.
Como vemos, las opciones son múltiples. Cada una de ellas es útil para un contexto específico.Sin embargo, estaría bien disponer de algunas soluciones generales. En este artículo, veremos soluciones que podemos aplicar en la mayoría de los casos con los menores vectores de ataque posibles.Con este concepto en mente, proporcionaremos dos recomendaciones técnicas que se pueden utilizar para compartir secretos en instancias EC2.La primera técnica para compartir secretos de servicios AWS nos permitirá no almacenar secretos en ningún momento.Simplemente utilizaremos el sistema de roles IAM en conjunción con la API de metadatos de AWS EC2 para obtener acceso y realizar las acciones requeridas sobre los servicios que necesitemos.
1. Compartir “secretos” o accesos a los servicios de AWS: Roles de AWS IAM
Si necesitamos dar acceso a toda la gama de servicios que proporciona Amazon AWS, la mejor opción en términos de seguridad es -sin duda- utilizar el sistema de Roles que ofrece IAM.
En lugar de enviar o almacenar Claves de Acceso y Claves Secretas que luego serán utilizadas por SDKs o interfaces Cli-mode para acceder y operar con los servicios que deseemos, tenemos la opción de habilitar credenciales temporales. Estas cambian al cabo de un par de minutos y pueden ser utilizadas por los SDKs de forma nativa o a través de interfaces CLI, sin necesidad de exponer las credenciales o claves de acceso permanentes de un usuario concreto.
Las ventajas de esta técnica son:
-Soporte nativo en los SDK de AWS.
-Una vez definidos e implementados los roles en el código, todo lo demás lo gestiona AWS.
-Proporciona credenciales temporales, por lo que si la instancia EC2 se ve comprometida y estas credenciales temporales se filtran, los atacantes solo tendrán acceso a los servicios del rol durante un par de minutos. Después, tendrán que obtener una nueva credencial temporal.
- Permite una gestión más granular de los privilegios concedidos y un mejor control/auditoría de los mismos, fomentando el principio del “menor privilegio”.
Si quieres saber cómo implementar roles IAM en instancias EC2 a nivel técnico, consulta estos enlaces:
Una forma más segura de distribuir las credenciales de AWS a EC2 | AWS Security Blog
2. Compartir secretos no nativos de AWS: Administrador de secretos de AWS
Hablemos de lo que ocurre si necesitamos dotar a nuestras instancias EC2 de secretos que no son nativos de AWS, como por ejemplo:
-Credenciales de la base de datos.
-Credenciales de aplicación.
-Tokens de autenticación.
-Claves de interfaz de programación de aplicaciones (API).
Habitualmente, cuando desarrollamos una aplicación que necesita información de una base de datos o una API, las credenciales o secretos son hard-coded para poder acceder a esa información en la propia aplicación, exponiendo el código fuente a posibles filtraciones, revelando los secretos y obstruyendo su rotación. Para rotar el secreto, necesitaríamos actualizarlo en cada instancia utilizada en nuestra aplicación. Por ello, la práctica de rotación de secretos que se suele encontrar en las aplicaciones auditadas es muy baja o prácticamente nula.
Utilizando AWS Secrets Manager, podemos almacenar y suministrar de forma segura estos secretos en nuestras instancias EC2 o cualquier script/aplicación que lo requiera utilizando una llamada API a Secrets Manager para obtener dicho secreto de forma programática.
Además de mantener nuestro código libre de secretos, nos ayuda automáticamente rotándolos según un conjunto de reglas que podemos definir, reduciendo los riesgos de información comprometida.
Una de las mejores características de esta solución es su integración con AWS Identity and Access Management (IAM), que nos permite adjuntar políticas de permisos a usuarios, grupos y roles para permitir/denegar el acceso a secretos específicos. De esta forma, podemos tener un control preciso y granular sobre quién tiene acceso a qué, reduciendo la superficie de exposición a ataques y/o filtraciones.
Si quieres saber cómo implementar Secrets Manager en instancias EC2 a nivel técnico, consulta estos enlaces:
Administrador de secretos de AWS
Mover secretos codificados a AWS Secrets Manager
Configurar la rotación de usuario único para AWS Secrets Manager
