Prácticas recomendadas de Secret Manager

En esta guía se presentan algunas prácticas recomendadas cuando se usa Secret Manager. No es una lista exhaustiva de recomendaciones; Te recomendamos revisar la descripción general de la plataforma para comprender el panorama Google Cloud general y la descripción general de Secret Manager antes de leer esta guía.

Control de acceso

IAM protege el acceso a la API de Secret Manager. Sigue el principio de mínimo privilegio cuando otorgues permisos a los secretos.

• Limita la propiedad de la organización a una cuenta de administrador avanzado protegida.

• Segmenta las aplicaciones y los entornos (etapa de pruebas o producción) en proyectos separados, como se describe en Elige una jerarquía de recursos para tu Google Cloud zona de destino. Esto puede ayudar a aislar entornos con la vinculación de IAM a nivel de proyecto y garantizar 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, usa vinculaciones de IAM a nivel de secreto o condiciones de IAM para limitar el acceso al subconjunto necesario de secretos.

• El recomendador de IAM puede ayudar a identificar mejor las vinculaciones de IAM con privilegios excesivos.

Se requieren credenciales para autenticarse en la API de Secret Manager. Todas las bibliotecas cliente usan una estrategia similar para buscar credenciales denominadas credenciales predeterminadas de la aplicación.

• Cuando desarrolles de forma local, usa gcloud auth application-default login. Esto crea un archivo con credenciales que las bibliotecas cliente seleccionan de forma automática.

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

• En GKE, Workload Identity también proporciona credenciales a través de un servicio de metadatos.

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

Se prefiere exportar todos estos métodos para exportar una credencial de cuenta de servicio porque no requieren el almacenamiento y acceso seguros a un secreto adicional fuera de la API de Secret Manager.

Prácticas de codificación

Evita pasar secretos a tu aplicación a través del sistema de archivos o las variables de entorno. A continuación, se incluyen algunos motivos para usar otros métodos para controlar los secretos:

• Cuando se puede acceder a un secreto en el sistema de archivos, las vulnerabilidades de la aplicación, como los ataques de recorrido del directorio, pueden volverse más graves, ya que el atacante puede obtener la capacidad de leer el material del secreto.

• Cuando un secreto se consume a través de variables de entorno, una configuración incorrecta, como habilitar extremos de depuración o incluir dependencias que registran los detalles del entorno del proceso, puede filtrar secretos.

• Cuando sincronices material de secretos 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 expande el acceso al secreto?

  • ¿Es posible auditar el acceso del secreto?

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

Recomendamos usar directamente la API de Secret Manager con una de las bibliotecas cliente proporcionadas o seguir la documentación de REST o GRPC.

Sin embargo, para algunas integraciones de productos, como las integraciones sin servidores, puedes pasar secretos a través del sistema de archivos o de variables de entorno. Para obtener más información, consulta Usa Secret Manager con otros productos.

Administración

Elige la política de replicación automática cuando crees secretos, a menos que la carga de trabajo tenga requisitos de ubicación específicos (aplicables con 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 actualización existentes. Por lo general, esto significa configurar tu aplicación con una versión secreta específica que se lee en el inicio. Si bien usar el alias más reciente puede ser conveniente, si hay un problema con la versión nueva del secreto, es posible que tu carga de trabajo no pueda usar la versión del secreto. Si fijas un número de versión, la configuración se puede validar y revertir mediante tus procesos de actualización existentes.

Inhabilita las versiones de los secretos antes de destruirlas o borrarlas. Esto ayuda a evitar interrupciones, ya que coloca el secreto en un estado similar al de destruir, pero es reversible. Es decir, puedes inhabilitar y esperar una semana para asegurarte de que no haya dependencias persistentes antes de borrar los datos de forma permanente.

No configures el vencimiento de los secretos de producción, a menos que tengas la certeza de que deberían borrarse de forma irreversible. La función de vencimiento es más adecuada para la limpieza automática de entornos temporales. Considera las condiciones de IAM basadas en el tiempo como alternativa a los secretos vencidos.

Rota tus secretos periódicamente para hacer lo siguiente:

• Limitar el impacto en el caso de un secreto filtrado.

• Asegúrate de que las personas que ya no requieran acceso a un secreto no puedan continuar usando uno al que se accedió previamente.

• Reducir la probabilidad de una interrupción

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

• Ayudar a identificar los secretos de tu organización.

• Identificar los requisitos de no cumplimiento de la organización, como la rotación, la configuración de la encriptación y la ubicación.

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

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

La política de la organización constraints/iam.allowedPolicyMemberDomains se puede usar para limitar las identidades que se pueden agregar a las políticas de IAM para secretos.

Calcula el uso máximo de tu secreto (considera una activación simultánea de solicitudes debido a implementaciones de aplicaciones simultáneas o al ajuste de escala automático de tu servicio) y asegúrate de que tu proyecto tenga cuota suficiente para controlar ese evento. Si se necesita más cuota, solicita un aumento.

Cumplimiento de la residencia de datos

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