> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basaltic.sh/llms.txt
> Use this file to discover all available pages before exploring further.

# Criptografia sob sua própria chave

> Vinculação de um segredo a uma chave KMS sua, o que isso muda e por que as versões não podem se mover entre chaves.

<a id="encrypting-under-your-own-key" />

## Criptografia sob sua própria chave

Por padrão, as versões de um segredo são criptografadas sob uma chave gerenciada pela plataforma. Vincule o segredo a uma de suas próprias chaves [KMS](/pt/kms) na criação para usar essa chave:

<Tabs>
  <Tab title="Console">
    Em **Create Secret**, abra o cartão **Encryption** e escolha uma chave em **Encryption key** em vez de **Platform-managed key (default)**.

    O seletor oferece suas chaves simétricas habilitadas (`aes-256`) com o uso de `encrypt_decrypt` na região selecionada.
  </Tab>

  <Tab title="API">
    ```bash theme={null}
    POST /v1/secrets
    {
      "name": "prod/api/stripe-key",
      "value": "c3VwZXItc2VjcmV0LXZhbHVl",
      "kms_key": "crn:kms:sa-saopaulo-1:acme:key/secrets-key"
    }
    ```
  </Tab>

  <Tab title="CLI">
    <Note>The CLI does not yet support creating a secret with `kms_key`.
    Use the Console or API for this operation.</Note>
  </Tab>

  <Tab title="Go">
    <Note>The Go SDK does not yet support creating a secret with `kms_key`.
    Use the Console or API for this operation.</Note>
  </Tab>
</Tabs>

A chave deve ser uma de suas, na mesma região, `enabled`, e fixada em `encrypt_decrypt`. Passe seu UUID, CRN completo ou nome de escopo de conta em `kms_key`. A associação mantém a identidade da chave original, mesmo que seu nome seja reutilizado após a exclusão. Uma chave de substituição não pode descriptografar o segredo original.

<Warning>
  Ele também deve ser **simétrico — `aes-256`**. Uma chave RSA com o uso de `encrypt_decrypt` é recusada com `400 KMS_INVALID_KEY_SPEC`, porque cada versão é selada com a identidade do segredo vinculada como contexto de criptografia e o RSA-OAEP não tem onde transportar um. Aceitar a chave deixaria cair essa ligação silenciosamente, então ela é recusada na criação.
</Warning>

<a id="what-it-changes" />

### O que isso muda

Vinculando um segredo à sua chave não muda a superfície da API — as leituras e gravações de `value` parecem idênticas. O que muda é que **a tecla se torna um controle que você segura**:

* Desative a chave e as leituras começam a falhar com `409 KMS_KEY_DISABLED`. Esse erro viaja para você como ele mesmo, não como um `500` — o estado da chave é seu, e reativar a chave restaura as leituras.
* Agendar a chave para exclusão e leituras falha com `409 KMS_KEY_PENDING_DELETION` para toda a janela.
* Deixe essa janela passar e **cada versão de cada segredo sob essa chave é permanentemente ilegível.** O texto cifrado ainda está no banco de dados; nada pode abri-lo.

<Note>
  A ligação é fixa para a vida do segredo. `kms_key` é aceite apenas na criação, e `PATCH` edita apenas `description` e `tags` — mover um segredo para uma chave diferente significa re-enrolar cada versão, por isso crie um novo segredo e retire o antigo.
</Note>

<a id="versions-are-bound-to-their-secret" />

### As versões estão ligadas ao seu segredo

Qualquer que seja a chave usada, o texto cifrado de cada versão é selado com a conta do segredo e o id secreto como contexto de criptografia. Um blob armazenado, portanto, só descriptografa como a versão do segredo para o qual foi escrito — ele não pode ser retirado do banco de dados e reproduzido como o valor de um segredo diferente, mesmo um criptografado com a mesma chave.

Se uma chave vinculada for permanentemente excluída, as leituras de metadados ainda retornarão o recurso com `kms_key_unavailable: true` e sem `kms_key_crn`. Isso não remove a vinculação de criptografia nem seleciona uma chave de substituição. As operações que exigem a chave excluída falham.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.