SEC02-BP03 Almacenar y usar secretos de forma segura
Una carga de trabajo necesita una capacidad automatizada para demostrar su identidad a bases de datos, recursos y servicios de terceros. Para ello, se utilizan credenciales de acceso secretas, como claves de acceso a API, contraseñas y tokens OAuth. El uso de un servicio creado específicamente para almacenar, administrar y rotar estas credenciales ayuda a reducir la probabilidad de que dichas credenciales se vean comprometidas.
Resultado deseado: implementar un mecanismo para administrar de forma segura las credenciales de las aplicaciones que logre los siguientes objetivos:
-
Identificar qué secretos son necesarios para la carga de trabajo.
-
Reducir el número de credenciales de larga duración necesarias y sustituirlas por credenciales de corta duración cuando sea posible.
-
Establecer un almacenamiento seguro y una rotación automatizada de las credenciales restantes de larga duración.
-
Auditar el acceso a los secretos que existen en la carga de trabajo.
-
Supervisar de forma continua para verificar que no hay secretos incrustados en el código fuente durante el proceso de desarrollo.
-
Reducir la probabilidad de que las credenciales se divulguen de forma inadvertida.
Antipatrones usuales:
-
Credenciales no rotativas.
-
Almacenar credenciales a largo plazo en el código fuente o en archivos de configuración.
-
Almacenar credenciales en reposo sin cifrar.
Beneficios de establecer esta práctica recomendada:
-
Los secretos se almacenan cifrados en reposo y en tránsito.
-
El acceso a las credenciales se controla a través de una API (es algo parecido a una máquina expendedora de credenciales).
-
El acceso a una credencial (tanto de lectura como de escritura) se audita y registra.
-
Separación de preocupaciones: la rotación de credenciales la realiza un componente independiente, que puede separarse del resto de la arquitectura.
-
Los secretos se distribuyen automáticamente bajo demanda a los componentes de software y la rotación se produce en una ubicación central.
-
El acceso a las credenciales puede controlarse de forma detallada.
Nivel de riesgo expuesto si no se establece esta práctica recomendada: alto
Guía para la implementación
En el pasado, las credenciales que se utilizaban para autenticarse en bases de datos, API de terceros, tokens y otros secretos podían estar incrustadas en el código fuente o en archivos del entorno. AWS proporciona varios mecanismos para almacenar estas credenciales de forma segura, rotarlas automáticamente y auditar su uso.
La mejor manera de abordar la administración de secretos es seguir la norma de eliminar, sustituir y rotar. La credencial más segura es aquella que no se tiene que almacenar, administrar ni manejar. Es posible que haya credenciales que ya no sean necesarias para el funcionamiento de la carga de trabajo y que, por tanto, puedan eliminarse de forma segura.
En el caso de las credenciales que siguen siendo necesarias para el correcto funcionamiento de la carga de trabajo, podría existir la oportunidad de sustituir una credencial de larga duración por una credencial temporal o de corta duración. Por ejemplo, en lugar de codificar una clave de acceso secreta de AWS, considere la posibilidad de sustituir esa credencial de larga duración por una credencial temporal utilizando roles de IAM.
Es posible que algunos secretos de larga duración no puedan eliminarse ni sustituirse. Estos secretos pueden almacenarse en un servicio como AWS Secrets Manager, donde pueden almacenarse, administrarse y rotarse de forma centralizada y periódica.
Una auditoría del código fuente y de los archivos de configuración de la carga de trabajo puede revelar muchos tipos de credenciales. La siguiente tabla resume las estrategias para manejar los tipos comunes de credenciales:
Credential type | Description | Suggested strategy |
---|---|---|
IAM access keys | AWS IAM access and secret keys used to assume IAM roles inside of a workload | Replace: Use Roles de IAM assigned to the compute instances (such as Amazon EC2 or AWS Lambda) instead. For interoperability with third parties that require access to resources in your Cuenta de AWS, ask if they support Acceso entre cuentas de AWS. For mobile apps, consider using temporary credentials through Grupos de identidades de Amazon Cognito (identidades federadas). For workloads running outside of AWS, consider Funciones de IAM en cualquier lugar or Activaciones híbridas de AWS Systems Manager. |
SSH keys | Secure Shell private keys used to log into Linux EC2 instances, manually or as part of an automated process |
Replace: Use
AWS Systems Manager |
Application and database credentials | Passwords – plain text string | Rotate: Store credentials in AWS Secrets Manager and establish automated rotation if possible. |
Amazon RDS and Aurora Admin Database credentials | Passwords – plain text string | Replace: Use the Integración de Secrets Manager con Amazon RDS or Amazon Aurora. In addition, some RDS database types can use IAM roles instead of passwords for some use cases (for more detail, see Autenticación de bases de datos de IAM). |
OAuth tokens | Secret tokens – plain text string | Rotate: Store tokens in AWS Secrets Manager and configure automated rotation. |
API tokens and keys | Secret tokens – plain text string | Rotate: Store in AWS Secrets Manager and establish automated rotation if possible. |
Un antipatrón común es incrustar claves de acceso de IAM dentro del código fuente, los archivos de configuración o las aplicaciones móviles. Cuando se requiera una clave de acceso de IAM para comunicarse con un servicio de AWS, utilice credenciales de seguridad temporales (a corto plazo). Estas credenciales a corto plazo pueden proporcionarse a través de roles de IAM para instancias de EC2, roles de ejecución para funciones Lambda, roles de IAM de Cognito para el acceso de usuarios móviles y políticas de IoT Core para dispositivos IoT. Cuando interactúe con terceros, es preferible que delegue el acceso a un rol de IAM con el acceso necesario a los recursos de su cuenta en lugar de configurar un usuario de IAM y enviar a ese tercero la clave de acceso secreta para ese usuario.
Hay muchos casos en los que la carga de trabajo requiere que se almacenen los secretos necesarios para interoperar con otros servicios y recursos. AWS Secrets Manager se ha creado específicamente para administrar de forma segura estas credenciales, así como el almacenamiento, el uso y la rotación de tokens de API, contraseñas y otras credenciales.
AWS Secrets Manager proporciona cinco capacidades clave para garantizar el almacenamiento y la gestión seguros de credenciales confidenciales: cifrado en reposo, cifrado en tránsito, auditoría exhaustiva, control de acceso detallado y rotación de credenciales extensible. También son aceptables otros servicios de administración de secretos de socios de AWS o soluciones desarrolladas localmente que proporcionen capacidades y garantías similares.
Pasos para la implementación
-
Identifique rutas de código que contengan credenciales codificadas mediante herramientas automatizadas como Amazon CodeGuru
. -
Utilice Amazon CodeGuru para analizar sus repositorios de código. Una vez finalizada la revisión, filtre
Type=Secrets
en CodeGuru para encontrar las líneas de código problemáticas.
-
-
Identifique las credenciales que pueden eliminarse o sustituirse.
-
Identifique las credenciales que ya no sean necesarias y márquelas para eliminarlas.
-
En el caso de las claves secretas de AWS que estén incrustadas en el código fuente, sustitúyalas por roles de IAM asociados a los recursos necesarios. Si parte de su carga de trabajo está fuera de AWS pero requiere credenciales de IAM para acceder a recursos de AWS, considere la posibilidad de usar Funciones de IAM en cualquier lugar
o activaciones híbridas de AWSSystems Manager.
-
-
Para otros secretos de terceros de larga duración que requieran el uso de la estrategia de rotación, integre Secrets Manager en su código para recuperar secretos de terceros en tiempo de ejecución.
-
La consola CodeGuru puede crear automáticamente un secreto en Secrets Manager
utilizando las credenciales descubiertas. -
Integre la recuperación de secretos desde Secrets Manager en el código de su aplicación.
-
Las funciones Lambda sin servidor pueden utilizar una extensión de Lambda agnóstica del lenguaje.
-
Para instancias o contenedores EC2, AWS proporciona ejemplos de código del lado del cliente para recuperar secretos de Secrets Manager en varios lenguajes de programación populares.
-
-
-
Revise periódicamente su base de código y vuelva a analizarlo para verificar que no se hayan añadido nuevos secretos.
-
Considere la posibilidad de utilizar una herramienta como git-secrets
para evitar que se envíen nuevos secretos a su repositorio de código fuente.
-
-
Supervise la actividad de Secrets Manager en busca de indicios de un uso inesperado, un acceso inapropiado a secretos o intentos de eliminar secretos.
-
Reduzca la exposición humana a las credenciales. Restrinja el acceso para leer, escribir y modificar credenciales a un rol de IAM dedicado a este fin, y solo proporcione acceso para asumir el rol a un pequeño subconjunto de usuarios operativos.
Recursos
Prácticas recomendadas relacionadas:
Documentos relacionados:
-
Amazon CodeGuru Introduces Secrets Detector
(El revisor de Amazon CodeGuru presenta el detector de secretos)
Vídeos relacionados:
-
Best Practices for Managing, Retrieving, and Rotating Secrets at Scale
(Prácticas recomendadas para administrar, recuperar y rotar secretos a escala) -
Find Hard-Coded Secrets Using Amazon CodeGuru Secrets Detector
(Encuentre secretos difíciles de descifrar utilizando el detector de secretos de Amazon CodeGuru) -
Securing Secrets for Hybrid Workloads Using AWS Secrets Manager
(Asegurar secretos para cargas de trabajo híbridas utilizando AWS Secrets Manager)
Talleres relacionados: