Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
O Secret Manager é um serviço de gerenciamento de segredos e credenciais
que permite armazenar e gerenciar dados sensíveis, como chaves de API, nomes de usuário, senhas, certificados e muito mais.
Um secret
é um recurso global que contém uma coleção de metadados e versões de secrets. Os metadados podem incluir
rótulos, anotações e permissões.
Uma versão do secret
armazena os dados reais do secret, como chaves de API, senhas ou certificados. Cada versão é
identificada por um ID ou carimbo de data/hora exclusivo.
Com o Secret Manager, é possível fazer o seguinte:
Gerenciar reversão, recuperação e auditoria usando versões: as versões ajudam a
gerenciar lançamentos graduais e reversão de emergência. Se um segredo for alterado acidentalmente
ou comprometido, você poderá reverter para uma versão anterior conhecida como boa. Isso minimiza
possíveis períodos de inatividade e violações de segurança. A versão mantém um registro histórico
das mudanças feitas em um segredo, incluindo quem fez as mudanças e quando. Ele ajuda a
auditar dados confidenciais e acompanhar tentativas de acesso não autorizado. É possível fixar versões
secretas em cargas de trabalho específicas e adicionar
apelidos para
facilitar o acesso a dados secretos. Também é possível
desativar ou
destruir as versões
de segredos que você não precisa.
Criptografar dados confidenciais em trânsito e em repouso: todas as informações confidenciais são
criptografadas por padrão, tanto em trânsito usando TLS quanto em repouso com chaves de criptografia
AES-256 bits. Para quem precisa de mais controle granular, é possível criptografar dados confidenciais
com chaves de criptografia gerenciadas pelo cliente (CMEK). Com a CMEK, você pode gerar novas chaves de criptografia ou importar as existentes
para atender aos seus requisitos específicos.
Gerencie o acesso a segredos usando condições e papéis granulares do Identity and Access Management (IAM):
Com as permissões e papéis do IAM,
é possível conceder acesso granular
a recursos específicos do Secret Manager. É possível separar as responsabilidades de acesso,
gerenciamento, auditoria e rotação de secrets.
Garantir alta disponibilidade e recuperação de desastres com a replicação de segredos: é possível
replicar segredos
em várias regiões para garantir alta disponibilidade e recuperação de desastres para seus aplicativos,
independente da localização geográfica. Você pode escolher entre as seguintes políticas de replicação:
Replicação automática: o Google decide as regiões considerando a disponibilidade e a latência. Você só vai receber cobranças por um local.
Replicação gerenciada pelo usuário: é possível
selecionar um conjunto personalizado de regiões, dependendo dos seus requisitos. A cobrança é feita por local.
Gire segredos automaticamente para atender aos requisitos de segurança e compliance:
Gire segredos
para se proteger contra acesso não autorizado e violações de dados. A mudança regular de secrets reduz o risco
de secrets desatualizados ou esquecidos e garante a conformidade com muitos frameworks regulamentares
que exigem a rotação periódica de credenciais sensíveis.
Aplicar a residência de dados usando segredos regionais:
a residência de dados
exige que determinados tipos de dados, geralmente pertencentes a indivíduos ou
organizações específicos, sejam armazenados em um local geográfico definido. Você pode criar
segredos regionais
e armazenar seus dados confidenciais em um local específico para obedecer às leis e regulamentações de soberania de dados.
Gerenciar parâmetros operacionais dos seus aplicativos usando o
Gerenciador de parâmetros:
o Gerenciador de parâmetros
é uma extensão do serviço do Secret Manager que pode ser usada para armazenar e gerenciar
configurações de aplicativos, como strings de conexão de banco de dados, flags de recursos, nomes de ambientes, números de porta para escutar e configurações de recursos do aplicativo. Também é possível
criar referências a secrets
armazenados no Secret Manager nas suas configurações de parâmetros. Para usar o Gerenciador de parâmetros,
ative a API Parameter Manager e conceda aos usuários as
funções do IAM necessárias.
Diferença entre o gerenciamento de secrets e o gerenciamento de chaves
O gerenciamento de secrets e de chaves são componentes essenciais da segurança de dados,
mas têm finalidades distintas e lidam com diferentes tipos de informações sensíveis.
A escolha entre o gerenciamento de secrets e o gerenciamento de chaves depende das suas necessidades específicas.
Se você quiser armazenar e gerenciar dados confidenciais com segurança, um sistema de gerenciamento de secrets
é a ferramenta certa. Se você quiser gerenciar chaves de criptografia e realizar operações criptográficas,
um sistema de gerenciamento de chaves é a melhor escolha.
Use a tabela a seguir para entender as principais diferenças entre o Secret Manager e um sistema de gerenciamento de chaves, como o Cloud Key Management Service(Cloud KMS).
Recurso
Secret Manager
Cloud KMS
Função principal
Armazene, gerencie e acesse segredos como blobs binários ou strings de texto.
Gerenciar chaves criptográficas e usá-las para criptografar ou descriptografar dados.
Dados armazenados
Valores reais do secret. Com as permissões adequadas, é possível conferir o
conteúdo do secret.
Chaves criptográficas. Não é possível visualizar, extrair ou exportar os segredos criptográficos (os bits e bytes) que são usados para operações de criptografia e descriptografia.
Criptografia
Criptografa segredos em repouso e em trânsito usando
Google-owned and managed keys ou chaves gerenciadas pelo cliente.
Oferece recursos de criptografia e descriptografia para outros serviços.
Casos de uso típicos
Armazenar informações de configuração, como senhas de banco de dados, chaves de API ou
certificados TLS necessários para um aplicativo no ambiente de execução.
Processar grandes cargas de trabalho de criptografia, como a criptografia de linhas em um banco de dados ou
criptografia de dados binários, como imagens e arquivos. Também é possível usar o Cloud KMS
para executar outras operações criptográficas, como assinatura e verificação.
Criptografia de secrets
O Secret Manager sempre criptografa os dados secretos antes de serem mantidos
no disco. Para saber mais sobre as Google Cloud opções de criptografia, consulte
Criptografia em repouso.
As chaves de criptografia do servidor são gerenciadas pelo Secret Manager para você por meio dos mesmos sistemas de gerenciamento de chaves com aumento da proteção que usamos nos nossos dados criptografados. Isso inclui auditoria e controles estritos de acesso por chave. O Secret Manager
criptografa os dados do usuário em repouso usando AES-256. Não é necessário realizar qualquer
configuração ou estabelecer definições. Também não é necessário acessar o serviço de outra maneira e não há impacto visível
no desempenho. Os dados do secret são descriptografados de maneira automática e
transparente quando um usuário autorizado os acessa.
A API Secret Manager sempre se comunica por uma conexão HTTP(S) segura.
Quem precisa de uma camada extra de proteção pode ativar o CMEK e usar as próprias
chaves de criptografia armazenadas no Cloud Key Management Service para proteger os segredos armazenados no
Secret Manager. Consulte a documentação do CMEK
para saber como configurar e usar chaves de criptografia gerenciadas pelo cliente.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-08-18 UTC."],[],[],null,["# Secret Manager overview\n\nSecret Manager is a secrets and credential management service\nthat lets you store and manage sensitive data such as API keys, usernames, passwords,\ncertificates, and more.\n\nA [*secret*](/secret-manager/docs/creating-and-accessing-secrets)\nis a global resource that contains a collection of metadata and secret versions. The metadata can include\nlabels, annotations, and permissions.\n\nA [*secret version*](/secret-manager/docs/add-secret-version)\nstores the actual secret data, such as API keys, passwords, or certificates. Each version is\nidentified by a unique ID or timestamp.\n\nUsing Secret Manager, you can do the following:\n\n- **Manage rollback, recovery, and auditing using versions** : Versions help you\n manage gradual rollouts and emergency rollback, If a secret is accidentally changed\n or compromised, you can revert to a previous, known-good version. This minimizes\n potential downtime and security breaches. Versioning maintains a historical record\n of changes made to a secret, including who made the changes and when. It helps you\n audit secret data and track any unauthorized access attempts. You can pin secret\n versions to specific workloads and add\n [aliases](/secret-manager/docs/assign-alias-to-secret-version) for\n easier access to secret data. You can also\n [disable](/secret-manager/docs/disable-secret-version) or\n [destroy](/secret-manager/docs/destroy-secret-version) secret\n versions that you don't require.\n\n- **Encrypt your secret data in transit and at rest** : All secrets are\n encrypted by default, both in transit using TLS and at rest with AES-256-bit encryption\n keys. For those requiring more granular control, you can encrypt your secret data\n with [Customer-Managed\n Encryption Keys (CMEK)](/secret-manager/docs/cmek). Using CMEK, you can generate new encryption keys or import existing ones\n to meet your specific requirements.\n\n- **Manage access to secrets using fine-grained Identity and Access Management (IAM) roles and conditions** :\n With [IAM roles and permissions](/secret-manager/docs/access-control),\n you can [provide granular access](/secret-manager/docs/manage-access-to-secrets)\n to specific Secret Manager resources. You can segregate responsibilities for accessing,\n managing, auditing, and rotating secrets.\n\n- **Ensure high availability and disaster recovery with secret replication** : You\n can [replicate your secrets](/secret-manager/docs/choosing-replication)\n across multiple regions to ensure high availability and disaster recovery for your applications\n regardless of their geographic location. You can choose between the following replication policies:\n\n - [Automatic replication](/secret-manager/docs/choosing-replication#automatic): Google decides\n the regions considering availability and latency. You are only charged for one location.\n\n - [User managed replication](/secret-manager/docs/choosing-replication#user-managed): You can\n select a custom set of regions depending on your requirements. You are charged per location.\n\n- **Rotate secrets automatically to meet your security and compliance requirements** :\n [Rotating your secrets](/secret-manager/docs/rotation-recommendations)\n protects against unauthorized access and data breaches. Regularly changing your secrets reduces the risk\n of stale or forgotten secrets and ensures compliance with many regulatory frameworks\n that require periodic rotation of sensitive credentials.\n\n- **Enforce data residency using regional secrets** :\n [Data residency](/architecture/framework/security/meet-regulatory-compliance-and-privacy-needs#control_data_residency)\n requires that certain types of data, often belonging to specific individuals or\n organizations, be stored within a defined geographic location. You can create\n [regional secrets](/secret-manager/docs/create-regional-secrets)\n and store your sensitive data within a specific location to comply with data sovereignty laws\n and regulations.\n\n- **Manage operational parameters for your applications using\n Parameter Manager** :\n [Parameter Manager](/secret-manager/parameter-manager/docs/overview)\n is an extension to the Secret Manager service that you can use to store and manage\n application configurations such as database connection strings, feature flags, environment names,\n port numbers to listen on, and settings for application features. You can also\n [reference secrets](/secret-manager/parameter-manager/docs/reference-secrets-in-parameter)\n stored in Secret Manager within your parameter configurations. To use Parameter Manager,\n you must enable the Parameter Manager API and grant your users the\n [required IAM roles](/secret-manager/parameter-manager/docs/access-control).\n\nDifference between secrets management and key management\n--------------------------------------------------------\n\n- Secrets management and key management are both critical components of data security, but they serve distinct purposes and handle different types of sensitive information. The choice between secrets management and key management depends on your specific needs. If you want to securely store and manage confidential data, a secrets management system is the right tool. If you want to manage encryption keys and perform cryptographic operations, a key management system is the better choice.\n- You can use the following table to understand the key differences between Secret Manager and a key management system, such as [Cloud Key Management Service(Cloud KMS)](/kms/docs).\n\nEncryption of secrets\n---------------------\n\n- Secret Manager always encrypts your secret data before it is persisted to disk. To learn more about Google Cloud encryption options, refer to [Encryption at rest](/docs/security/encryption/default-encryption).\n- Secret Manager manages server-side encryption keys on your behalf using the same hardened key management systems that we use for our own encrypted data, including strict key access controls and auditing. Secret Manager encrypts user data at rest using AES-256. There is no setup or configuration required, no need to modify the way you access the service, and no visible performance impact. Your secret data is automatically and transparently decrypted when accessed by an authorized user.\n- The Secret Manager API always communicates over a secure HTTP(S) connection.\n- Those who require an extra layer of protection can enable CMEK and use their own encryption keys stored in Cloud Key Management Service to protect the secrets stored in Secret Manager. See the [CMEK documentation](/secret-manager/docs/cmek) for details on how to configure and use customer-managed encryption keys.\n\nWhat's next\n-----------\n\n - Learn how to [create a secret](/secret-manager/docs/creating-and-accessing-secrets).\n - Learn how to [add a secret version](/secret-manager/docs/add-secret-version).\n - Learn how to [edit a secret](/secret-manager/docs/edit-secrets).\n - Learn about [quotas and limitations](/secret-manager/quotas).\n - Learn about [best practices](/secret-manager/docs/best-practices)."]]