Prácticas recomendadas de Secret Manager

En esta guía se presentan algunas prácticas recomendadas para usar Secret Manager. La guía no es una lista exhaustiva de recomendaciones. Te recomendamos que consultes el resumen de la plataforma para entender el panorama general y el resumen de Secret Manager antes de leer esta guía. Google Cloud

Control de acceso

El acceso a la API Secret Manager está protegido por la gestión de identidades y accesos. Sigue el principio de mínimos accesos al conceder permisos a los secretos.

• Limita la propiedad de la organización a una cuenta de superadministrador segura.

• Segmenta las aplicaciones y los entornos (de staging o de producción) en proyectos independientes, tal como se describe en la sección Decidir una jerarquía de recursos para tu Google Cloud zona de aterrizaje. Esto puede ayudar a aislar los entornos con la vinculación de gestión de identidades y accesos a nivel de proyecto y asegura que las cuotas se apliquen de forma independiente.

• Elige un rol seleccionado con los permisos mínimos necesarios o crea un rol personalizado si es necesario.

• Cuando los secretos de muchos servicios se encuentran en un solo proyecto, utiliza enlaces de gestión de identidades y accesos a nivel de secreto o condiciones de gestión de identidades y accesos para limitar el acceso al subconjunto de secretos necesario.

• El recomendador de IAM también puede ayudar a identificar las vinculaciones de IAM con privilegios excesivos.

Se necesitan credenciales para autenticarte en la API Secret Manager. Todas las bibliotecas cliente usan una estrategia similar para buscar las credenciales a las que se hace referencia como credenciales predeterminadas de la aplicación.

• Cuando desarrolles de forma local, usa gcloud auth application-default login. De esta forma, se crea un archivo con credenciales que las bibliotecas de cliente detectan automáticamente.

• En Compute Engine y otras Google Cloud plataformas de computación, como las funciones de Cloud Run, las bibliotecas de cliente obtienen las credenciales a través del servidor de metadatos de instancia.

• En GKE, Identidad de carga de trabajo también proporciona credenciales a través de un servicio de metadatos.

• En otras plataformas, como Amazon Web Services o Microsoft Azure, puedes configurar la federación de identidades de cargas de trabajo, que usa mecanismos de identidad para autenticarse en las APIs de Google Cloud .

Se recomienda usar estos métodos en lugar de exportar una credencial de cuenta de servicio, ya que no requieren almacenar ni acceder de forma segura a un secreto adicional fuera de la API Secret Manager.

Prácticas de programación

No envíes secretos a tu aplicación a través del sistema de archivos ni de las variables de entorno. A continuación, se indican algunos motivos para usar otros métodos para gestionar secretos:

• Cuando se puede acceder a un secreto en el sistema de archivos, las vulnerabilidades de las aplicaciones, como los ataques de recorrido de directorios, pueden ser más graves, ya que el atacante puede obtener la capacidad de leer el material secreto.

• Cuando se usa un secreto a través de variables de entorno, las configuraciones incorrectas, como habilitar endpoints de depuración o incluir dependencias que registren detalles del entorno del proceso, pueden filtrar secretos.

• Cuando sincronices material secreto con otro almacén de datos (como los secretos de Kubernetes), evalúa los controles de acceso que proporciona ese almacén de datos. Ten en cuenta lo siguiente:

  • ¿El almacén de datos amplía el acceso al secreto?

  • ¿Es posible auditar el acceso al secreto?

  • ¿El almacén de datos cumple los requisitos de cifrado de datos en reposo y regionalización?

Te recomendamos que uses la API Secret Manager directamente con una de las bibliotecas de cliente proporcionadas o siguiendo la documentación de REST o GRPC.

Sin embargo, en algunas integraciones de productos, como las integraciones sin servidor, puedes transferir secretos a través del sistema de archivos o de variables de entorno. Para obtener más información, consulta [Usar Secret Manager con otros productos](/secret-manager/docs/using-other-products).

Administración

Elige la política de replicación automática al crear secretos, a menos que tu carga de trabajo tenga requisitos de ubicación específicos (que se pueden aplicar mediante la restricción constraints/gcp.resourceLocations).

Haz referencia a los secretos por su número de versión en lugar de usar el alias más reciente. Implementa actualizaciones en los números de versión mediante tus procesos de lanzamiento. Normalmente, esto significa configurar tu aplicación con una versión secreta específica que se lee al iniciarse. Aunque usar el alias más reciente puede ser práctico, si hay algún problema con la nueva versión del secreto, es posible que tu carga de trabajo no pueda usar la versión del secreto. Al fijar un número de versión, la configuración se puede validar y revertir mediante los procesos de lanzamiento que ya tengas.

Inhabilita las versiones de secretos antes de eliminarlas o de eliminar los secretos. De esta forma, se evitan las interrupciones, ya que el secreto se pone en un estado que parece igual que el de eliminación, pero que se puede revertir. Es decir, puedes inhabilitar la función y esperar una semana para asegurarte de que no haya dependencias antes de eliminar los datos de forma permanente.

No definas la fecha de vencimiento de los secretos de producción a menos que tengas la certeza de que deben eliminarse de forma irreversible. La función de caducidad es la más adecuada para limpiar automáticamente los entornos temporales. Como alternativa a los secretos que caducan, puedes usar condiciones de IAM basadas en el tiempo.

Rota periódicamente tus secretos para hacer lo siguiente:

• Limitar el impacto en caso de que se filtre un secreto.

• Asegúrate de que las personas que ya no necesiten acceder a un secreto no puedan seguir usando un secreto al que hayan accedido anteriormente.

• Reduce la probabilidad de que se produzca una interrupción.

Supervisa los secretos de tu organización con Cloud Asset Inventory por los siguientes motivos:

• Ayudar a identificar secretos en toda tu organización.

• Identifica las no conformidades con los requisitos de la organización, como la rotación, la configuración del cifrado y la ubicación.

Habilita los registros de acceso a datos para obtener y analizar la información de las solicitudes AccessSecretVersion. Habilita esta opción a nivel de carpeta u organización para aplicar el registro sin tener que configurarlo en cada secreto o proyecto.

Además de los controles de gestión de identidades y accesos, puedes limitar el acceso a la API Secret Manager con controles basados en la red configurando un perímetro de Controles de Servicio de VPC para tu organización.

La política de organización constraints/iam.allowedPolicyMemberDomains se puede usar para limitar las identidades que se pueden añadir a las políticas de gestión de identidades y accesos de los secretos.

Estima el uso máximo de secretos (teniendo en cuenta una avalancha de solicitudes debido a implementaciones simultáneas de aplicaciones o al autoescalado de tu servicio) y asegúrate de que tu proyecto tenga suficiente cuota para gestionar este tipo de eventos. Si necesitas más cuota, solicita un aumento.

Cumplimiento de la residencia de datos

Elige secretos regionales si tienes requisitos estrictos de residencia y soberanía de los datos. Los secretos regionales te permiten almacenar datos sensibles en una ubicación geográfica concreta, lo que te ofrece garantías completas de protección de los datos en reposo, en uso y en tránsito, y te ayuda a cumplir los requisitos legales, normativos o de la organización relacionados con la residencia de datos.