Prácticas recomendadas de Secret Manager

En esta guía se presentan algunas prácticas recomendadas cuando se usa Secret Manager. La guía no es una 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.

• Limitar la propiedad de la organización a un administrador avanzado seguro cuenta de servicio.

• 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.

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

• Si los Secrets de varios servicios se encuentran en un solo proyecto, usa nivel del Secret Vinculaciones de IAM o IAM Condiciones para limitar el acceso al subconjunto necesario de secretos.

• Recomendador de IAM puede ayudar aún más a identificar vinculaciones de IAM con privilegios.

Se requieren credenciales para autenticarse en la API de Secret Manager. El las bibliotecas cliente usan una estrategia similar para buscar las credenciales a las que como Credencial predeterminada de la aplicación.

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

• 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 identidad de 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 programación

Evita pasar secretos a la aplicación a través del sistema de archivos o las variables de entorno. A continuación, se muestran algunos motivos por los que se usan otros métodos para administrar secretos:

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

• Cuando se consume un Secret a través de variables de entorno, los errores de configuración como habilitar extremos de depuración o incluir dependencias que registran los detalles del entorno podrían 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 anteriores a destruirlos o borrar secretos. Esto ayuda a evitar interrupciones, ya que pone Secret en un estado similar al de destrucción, pero que es reversible. Es decir, puede inhabilitarlo y esperar una semana para asegurarse de que no haya datos dependencias 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 de usar un Secret al que se accedió anteriormente.

• Reduce 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. 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.

Calcula el uso máximo de Secrets (considerando un rebaño de truenos). de solicitudes debido a implementaciones simultáneas de aplicaciones o al ajuste de escala automático de tu servicio) y garantizar que tu proyecto tenga cuota suficiente para controlar un evento de este tipo. Si se aumentó la cuota si necesita un aumento.

Cumplimiento de la residencia de datos

Elige secretos regionales si tienes una residencia de datos estricta y soberanía de los datos. Los Secrets regionales te permiten almacenar datos sensibles en una ubicación geográfica ubicación física, brindando garantías completas en reposo, en uso y en tránsito, que te ayudan a cumplir con de la organización en torno a la residencia de datos.