> ## 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. # Chaves que outros serviços podem usar > Quais serviços criptografarão seus dados sob uma chave sua e o campo que cada um expõe. ## Chaves que outros serviços podem usar Alguns serviços criptografam seus dados com uma chave sua, em vez de uma gerenciada pela plataforma, o que coloca o kill switch em suas mãos: desative a chave e esse serviço deixará de poder ler o que ele armazenou. Vincule um segredo a uma de suas chaves na criação e cada versão será selada sob ele. Um grupo de log ou configuração de rastreamento leva um `kms_key`; cada lote de ingestão recebe sua própria chave de dados envolta sob a sua. Serviços que suportam sua própria chave usam `kms_key`: um UUID, nome de escopo de conta, ou `crn:kms:::key/` completo. A chave deve pertencer à conta autenticada e à mesma região. As respostas retornam o CRN baseado no nome da chave vinculada. As ligações mantêm a identidade da chave original. Excluir uma chave e criar outra com o mesmo nome não move os vínculos existentes para a substituição. Mantenha uma chave antiga disponível enquanto você ainda precisa de dados criptografados sob ela. Nem tudo o que está criptografado em repouso usa uma chave sua. A chave privada de um certificado, por exemplo, é criptografada sob uma chave regional gerenciada pela plataforma que você não controla. Quando um serviço suporta sua própria chave, ele expõe um campo para ela — se não houver tal campo, não há tal vinculação. 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.