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 que revises la descripción general de la plataforma para comprender el panorama general de Google Cloud 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 la zona de destino de Google Cloud. 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 una función seleccionada con los permisos mínimos necesarios o crea una función personalizada 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 plataformas de procesamiento de Google Cloud, como las funciones de Cloud Run, 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 Workload Identity, 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 la aplicación a través del sistema de archivos o las variables de entorno. A continuación, se incluyen algunas razones 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.

Administración

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. Aunque 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 estés seguro 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 de forma periódica 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.

• 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 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. Habilitar esto a nivel de carpeta o de 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 mediante la configuración de 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 con el fin de limitar las identidades que se pueden agregar a las políticas de IAM para secretos.

Estima el uso máximo de tu secreto (considera una gran cantidad 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 en 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, regulatorios o organizativos relacionados con la residencia de datos.