# Glossário de A a Z — letra K > 20 termos. Glossário compacto: https://conota.dev/glossario/llms-full.txt --- # Keep-alive HTTP > Keep-alive HTTP é o mecanismo que mantém aberta a conexão entre um cliente e um servidor depois de uma requisição, permitindo reaproveitá-la para as próximas. Em vez de abrir uma conexão nova a cada chamada, o sistema economiza tempo de negociação de rede e de segurança, reduzindo a latência em integrações com muitas requisições, como APIs fiscais. **Também conhecido como:** Conexão persistente HTTP, HTTP persistent connection, Reuso de conexão HTTP, Keepalive HTTP, HTTP keep-alive **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é keep-alive HTTP, em palavras simples? Sempre que um sistema conversa com uma API, ele precisa primeiro estabelecer uma conexão com o servidor. Isso funciona como uma ligação telefônica: antes de falar, é preciso discar, esperar atender e confirmar que a linha está boa. Sem keep-alive, o sistema desliga a ligação ao fim de cada pedido e precisa discar de novo para o próximo. Com keep-alive, a linha continua aberta por algum tempo, e os pedidos seguintes passam pela mesma conexão, sem repetir toda a preparação. ## Como funciona o keep-alive no HTTP? No HTTP/1.0, o cliente precisava pedir explicitamente a conexão persistente, usando o cabeçalho Connection: keep-alive. A partir do HTTP/1.1, as conexões passaram a ser persistentes por padrão, e quem quiser encerrá-las deve enviar Connection: close. Alguns servidores também informam, pelo cabeçalho Keep-Alive, por quanto tempo uma conexão ociosa será mantida e quantas requisições ela aceita. No HTTP/2, a ideia vai além: uma única conexão transporta várias requisições ao mesmo tempo, recurso chamado multiplexação. Na prática, quem cuida disso costuma ser a biblioteca HTTP usada pelo sistema, por meio de um pool de conexões: um conjunto de conexões abertas que são emprestadas e devolvidas a cada chamada. ## Para que serve o keep-alive em uma API fiscal? Chamadas a APIs fiscais usam HTTPS, o que exige, além da conexão de rede, uma negociação de segurança TLS. Essa etapa consome tempo e processamento. Reaproveitar a conexão evita repeti-la a cada documento emitido, consultado ou baixado. O ganho aparece principalmente em volumes altos: um ERP que emite centenas de NF-e, um marketplace que gera NFS-e para muitos vendedores ou um sistema que consulta status de documentos com frequência. Menos tempo gasto abrindo conexões significa respostas mais rápidas e menor carga nos dois lados. ## Quais cuidados são necessários ao usar keep-alive? Conexões ociosas não ficam abertas para sempre. Servidores, balanceadores de carga e proxies encerram conexões paradas após um período. Se o cliente tentar usar uma conexão que já foi fechada do outro lado, pode receber erros como conexão reiniciada ou fechada inesperadamente. Para evitar isso, recomenda-se configurar no cliente um tempo de ociosidade menor que o do servidor, limitar o tamanho do pool de conexões e ter uma política de retry segura. Em emissões fiscais, o retry deve vir acompanhado de idempotência, para que uma nova tentativa não gere documento duplicado. ## Qual a diferença entre keep-alive HTTP e keep-alive TCP? O keep-alive HTTP trata do reaproveitamento da conexão para várias requisições. Já o keep-alive TCP é um recurso da camada de rede que envia pequenos sinais periódicos para verificar se a outra ponta ainda está ativa em uma conexão parada. Os nomes são parecidos, mas os objetivos são diferentes: um busca eficiência entre requisições; o outro detecta conexões que caíram sem aviso. Eles podem ser usados juntos. ## Exemplos de Keep-alive HTTP - Um ERP que emite notas em lote mantém um pool de conexões abertas com a API fiscal, enviando cada NF-e pela mesma conexão em vez de abrir uma nova para cada documento. - Uma plataforma de serviços que gera NFS-e para vários prestadores reduz o tempo médio de resposta ao ativar keep-alive na biblioteca HTTP do seu backend. - Um sistema que faz polling do status de documentos recebe erros intermitentes de conexão fechada e resolve o problema reduzindo o tempo de ociosidade do pool para um valor menor que o do servidor. - Um serviço de transporte que emite CT-e e MDF-e ao longo do dia configura o cliente HTTP para reaproveitar conexões e repetir automaticamente chamadas que falham por conexão encerrada. ## Perguntas frequentes ### Preciso ativar o keep-alive manualmente? Geralmente não. No HTTP/1.1 e no HTTP/2 a conexão persistente já é o comportamento padrão, e a maioria das bibliotecas HTTP mantém um pool de conexões automaticamente. Vale apenas conferir as configurações de tempo de ociosidade e tamanho do pool. ### O keep-alive deixa a emissão da nota mais rápida? Ele reduz o tempo gasto para abrir conexões, o que diminui a latência total das chamadas. O processamento do documento pela autoridade fiscal, porém, não muda. O ganho é mais perceptível quando há muitas requisições seguidas. ### Keep-alive afeta a segurança da comunicação? Não reduz a segurança. A conexão continua protegida por TLS durante todo o tempo em que permanece aberta, e cada requisição segue enviando suas próprias credenciais de autenticação. ## Termos relacionados - [HTTP](https://conota.dev/glossario/http.md) - [HTTPS](https://conota.dev/glossario/https.md) - [TLS](https://conota.dev/glossario/tls.md) - [Latência da API fiscal](https://conota.dev/glossario/latencia-da-api-fiscal.md) - [Timeout na emissão fiscal](https://conota.dev/glossario/timeout-na-emissao-fiscal.md) - [Retry na integração fiscal](https://conota.dev/glossario/retry-na-integracao-fiscal.md) --- Fonte: [Keep-alive HTTP](https://conota.dev/glossario/keep-alive-http/) · Atualizado em 2026-10-22 --- # Key Agreement > Key Agreement, ou acordo de chaves, é um método criptográfico em que duas partes, como um sistema e um servidor, combinam uma chave secreta compartilhada sem enviá-la pela rede. Cada lado contribui com uma parte do cálculo, e só eles chegam ao mesmo resultado, usado depois para cifrar a comunicação com segurança. **Também conhecido como:** Acordo de chaves, Estabelecimento de chaves, Troca de chaves, Key exchange, Key Agreement **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é Key Agreement, em palavras simples? Key Agreement é a forma de dois computadores combinarem um segredo em comum mesmo conversando por um canal que qualquer pessoa poderia observar, como a internet. O detalhe importante é que o segredo final nunca viaja pela rede: cada lado o calcula sozinho. Uma analogia comum é a das tintas. Duas pessoas partem de uma cor pública, e cada uma mistura uma cor secreta só sua. Elas trocam as misturas e acrescentam de novo a própria cor secreta. No fim, as duas têm exatamente a mesma cor, mas quem viu apenas as misturas trocadas não consegue reproduzi-la. ## Como funciona o acordo de chaves? Cada participante gera um par de chaves: uma privada, que fica guardada, e uma pública, que é enviada ao outro lado. Combinando a própria chave privada com a chave pública recebida, os dois chegam ao mesmo valor secreto. Esse valor passa por uma função de derivação e vira a chave usada para cifrar os dados da conversa. Os algoritmos mais conhecidos são o Diffie-Hellman e sua versão com curvas elípticas, chamada ECDH. Em muitas conexões modernas, as chaves são efêmeras, ou seja, criadas só para aquela sessão e descartadas depois. Isso dá uma proteção chamada sigilo futuro (forward secrecy): mesmo que uma chave de longo prazo vaze no futuro, conversas antigas continuam protegidas. ## Qual a diferença entre key agreement e key transport? No key transport (transporte de chave), um dos lados cria a chave secreta sozinho, a protege com a chave pública do outro e a envia. Ou seja, a chave viaja, ainda que cifrada. No key agreement, nenhum dos lados escolhe a chave sozinho e ela não é enviada: ambos contribuem e cada um a calcula localmente. Por isso o acordo de chaves combina bem com chaves efêmeras e com o sigilo futuro, sendo a abordagem preferida nos protocolos de segurança mais recentes. ## Onde o key agreement aparece na emissão fiscal por API? Sempre que um ERP ou plataforma de vendas chama uma API fiscal por HTTPS, o protocolo TLS por trás da conexão normalmente realiza um acordo de chaves logo no início. É ele que gera a chave usada para cifrar o envio dos dados da nota, do XML, dos tokens de autenticação e das respostas com status e PDF. O mesmo acontece na comunicação entre o emissor e os webservices dos órgãos fiscais. O acordo de chaves também pode aparecer em tokens cifrados no padrão JWE, que oferece algoritmos baseados em ECDH para proteger o conteúdo de uma mensagem. Na prática, quem integra raramente implementa isso à mão: bibliotecas e servidores cuidam do processo automaticamente. ## O acordo de chaves garante sozinho a segurança da comunicação? Não. O key agreement garante que só os dois participantes conheçam o segredo, mas não prova quem é o outro lado. Sem uma verificação de identidade, um intermediário malicioso poderia fazer um acordo com cada ponta e ler tudo no meio do caminho, o chamado ataque man-in-the-middle. Por isso o acordo de chaves é sempre combinado com autenticação, geralmente por certificados digitais e assinaturas. No TLS, o certificado do servidor confirma sua identidade e, em alguns casos, o cliente também apresenta um certificado, como o certificado digital A1 usado por empresas emissoras. Proteger bem as chaves privadas, por exemplo com HSM ou gerenciamento de segredos, completa essa segurança. ## Exemplos de Key Agreement - Um ERP envia os dados de uma NF-e para uma API fiscal por HTTPS; no início da conexão, cliente e servidor fazem um acordo de chaves ECDHE e passam a trocar o JSON da nota cifrado com a chave combinada. - O emissor se conecta ao webservice de autorização usando o certificado A1 da empresa para se identificar, enquanto o acordo de chaves do TLS gera a chave temporária que protege o XML assinado em trânsito. - Uma plataforma gera um token JWE com o algoritmo ECDH-ES para entregar a outro sistema um dado sensível, de modo que só o destinatário, dono da chave privada correspondente, consiga abrir o conteúdo. - A equipe de segurança revisa a configuração do servidor de integração fiscal e desativa conexões sem chaves efêmeras, garantindo sigilo futuro para o tráfego de documentos fiscais. ## Perguntas frequentes ### Key agreement e troca de chaves são a mesma coisa? São usados quase como sinônimos. Troca de chaves (key exchange) é o termo mais amplo para estabelecer uma chave entre duas partes; key agreement é o tipo específico em que ambas contribuem e a chave final não é transmitida. ### Preciso implementar key agreement na minha integração fiscal? Normalmente não. Ao usar HTTPS com bibliotecas atualizadas, o acordo de chaves acontece automaticamente. O cuidado do integrador é manter versões seguras de TLS, validar certificados e proteger credenciais e chaves privadas. ### O certificado digital A1 é usado no acordo de chaves? O certificado A1 serve principalmente para autenticar a empresa e assinar documentos. Na conexão TLS, ele comprova a identidade, enquanto a chave que cifra a sessão costuma vir de um acordo de chaves com chaves temporárias. ### O que é Diffie-Hellman? É o algoritmo clássico de acordo de chaves, base para variações modernas como o ECDH, que usa curvas elípticas para obter a mesma segurança com chaves menores e cálculos mais rápidos. ## Termos relacionados - [HTTPS](https://conota.dev/glossario/https.md) - [Geração de chave criptográfica](https://conota.dev/glossario/geracao-de-chave-criptografica.md) - [JWE](https://conota.dev/glossario/jwe.md) - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [HSM](https://conota.dev/glossario/hsm.md) - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) --- Fonte: [Key Agreement](https://conota.dev/glossario/key-agreement/) · Atualizado em 2026-10-22 --- # Key compromise > Key compromise é a situação em que uma chave criptográfica privada, como a de um certificado digital ou de uma credencial de API, passa a ser conhecida, copiada ou usada por alguém não autorizado. Quando isso acontece, a chave deixa de ser confiável e precisa ser revogada e substituída rapidamente para evitar fraudes. **Também conhecido como:** Comprometimento de chave, Comprometimento da chave privada, Vazamento de chave privada, Chave comprometida, Key compromise **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que significa key compromise na prática? Em português, key compromise significa comprometimento de chave. Toda assinatura digital depende de uma chave privada, que deve ficar sob controle exclusivo do seu dono. Se outra pessoa obtém essa chave, ela consegue se passar pelo titular. O termo vale tanto para a confirmação de um vazamento quanto para a simples suspeita. Em segurança da informação, quem não tem certeza de que a chave continua secreta deve tratá-la como comprometida. ## Por que o comprometimento da chave é grave na emissão fiscal? Na emissão de NF-e, NFC-e, CT-e, MDF-e e, em muitos casos, NFS-e, o XML é assinado com o certificado digital da empresa, geralmente do tipo A1. Essa assinatura comprova ao fisco que o documento foi emitido pelo CNPJ indicado. Com a chave privada em mãos, um invasor pode assinar documentos fiscais em nome da empresa, acessar serviços que exigem o certificado e realizar outras operações com validade jurídica. A empresa pode precisar explicar ao fisco notas que não reconhece. ## Como uma chave pode ser comprometida? As causas mais comuns são simples: arquivo PFX enviado por e-mail ou aplicativo de mensagens, senha do certificado anotada em local visível ou guardada junto ao arquivo, cópias esquecidas em computadores de ex-funcionários e chaves gravadas diretamente no código-fonte de um sistema. Também há casos técnicos, como invasão de servidores, repositórios de código públicos por engano, backups sem criptografia e logs que registram credenciais por descuido. ## O que fazer quando há suspeita de key compromise? No caso de certificado digital, o primeiro passo é pedir a revogação à Autoridade Certificadora que o emitiu, informando o motivo de comprometimento da chave. Depois de revogado, o certificado deixa de ser aceito em novas assinaturas. Em seguida, emite-se um novo certificado, com um novo par de chaves, e ele é cadastrado nos sistemas que emitem documentos fiscais. Vale também consultar os documentos emitidos no CNPJ para identificar notas desconhecidas. Se o comprometimento envolver uma API Key ou token de acesso, a regra é a mesma: invalidar a credencial, gerar outra e atualizar as integrações que a utilizam. ## Como prevenir o comprometimento de chaves? Boas práticas incluem guardar certificados e chaves em ferramentas de gerenciamento de segredos ou em HSM, limitar quem tem acesso, nunca colocar senhas no código e criptografar backups. Em empresas que emitem por API, centralizar o certificado em uma infraestrutura fiscal reduz o número de cópias espalhadas. Trocar credenciais periodicamente e remover acessos de quem deixou a equipe também diminui o risco. ## Qual a diferença entre key compromise e certificado vencido? Um certificado vencido apenas chegou ao fim do prazo de validade; a chave continua segura, mas não pode mais ser usada para assinar. Já no key compromise o certificado pode estar dentro da validade, porém não é mais confiável porque a chave saiu do controle do titular. Por isso, o vencimento pede renovação, enquanto o comprometimento exige revogação imediata. ## Exemplos de Key compromise - Um funcionário envia o arquivo PFX e a senha do certificado A1 por e-mail para um prestador de serviço. A empresa trata o caso como key compromise, solicita a revogação e instala um novo certificado no emissor. - Um desenvolvedor publica sem querer, em um repositório público, o código de integração com a API Key de emissão fiscal. A equipe revoga a chave, gera outra e atualiza o ERP. - Ao consultar os documentos fiscais do CNPJ, a empresa encontra NF-e que não emitiu, suspeita de comprometimento do certificado e pede sua revogação à Autoridade Certificadora. - Um notebook com cópia do certificado digital é furtado. Mesmo sem prova de uso indevido, o certificado é revogado por precaução. ## Perguntas frequentes ### Trocar a senha do certificado resolve um key compromise? Não. A senha protege apenas o arquivo; se alguém já copiou a chave privada, ela continua utilizável. O correto é revogar o certificado e emitir outro, com novo par de chaves. ### Notas emitidas antes da revogação perdem a validade? Em geral, documentos assinados quando o certificado era válido continuam válidos. A revogação impede novas assinaturas. Documentos fraudulentos emitidos por terceiros devem ser analisados com o contador e tratados junto ao fisco. ### Key compromise só se aplica a certificados digitais? Não. O conceito vale para qualquer segredo criptográfico ou credencial, como API Keys, tokens, chaves de assinatura de webhooks e chaves usadas em JWT. ## Termos relacionados - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [Autoridade Certificadora](https://conota.dev/glossario/autoridade-certificadora.md) - [Arquivo PFX](https://conota.dev/glossario/arquivo-pfx.md) - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) - [HSM](https://conota.dev/glossario/hsm.md) - [API Key](https://conota.dev/glossario/api-key.md) --- Fonte: [Key compromise](https://conota.dev/glossario/key-compromise/) · Atualizado em 2026-10-22 --- # Key de API > Key de API é uma sequência única de caracteres, parecida com uma senha longa, que um sistema envia a uma API para provar quem está fazendo a requisição. Em APIs fiscais, ela identifica a conta do cliente e autoriza ações como emitir, consultar ou cancelar notas fiscais, devendo ser mantida em segredo. **Também conhecido como:** API Key, Chave de API, Chave de acesso à API, API key **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é uma Key de API, em palavras simples? Uma Key de API funciona como o crachá de um sistema. Quando um ERP, uma loja virtual ou um software de gestão conversa com uma API, ele precisa se identificar. Em vez de digitar usuário e senha, o sistema envia essa chave junto com cada pedido. A expressão mistura português e inglês e é a mesma coisa que API Key ou chave de API. Normalmente a chave é um texto longo e aparentemente aleatório, gerado pelo próprio provedor da API, difícil de adivinhar. ## Para que serve uma Key de API na emissão fiscal? Em uma API fiscal, a chave diz ao serviço qual conta está pedindo a emissão de uma NF-e, NFS-e, NFC-e, CT-e ou MDF-e. Com isso, a plataforma sabe quais empresas emissoras, certificados e franquias pertencem àquele cliente e impede que outra pessoa acesse esses dados. Ela também permite controlar o que cada integração pode fazer. Dependendo do provedor, uma chave pode ter permissão apenas para consultar documentos, enquanto outra pode emitir e cancelar. Esse mesmo controle vale quando agentes de inteligência artificial acessam o serviço via MCP, com ações limitadas e registradas para auditoria. ## Como funciona uma Key de API na prática? O cliente gera a chave em um painel ou console do provedor e a configura no seu sistema. A cada requisição, o sistema envia a chave, geralmente em um cabeçalho HTTP (header de autenticação), por uma conexão segura HTTPS. A API recebe o pedido, confere se a chave existe, se está ativa e se tem permissão para aquela ação. Se estiver tudo certo, a operação é executada; caso contrário, a resposta é um erro de autenticação ou de permissão, e nada é processado. ## Qual a diferença entre Key de API e certificado digital? São coisas diferentes que costumam aparecer juntas. A Key de API autentica o seu sistema perante o provedor da API, como o Conota. Já o certificado digital A1 identifica a empresa emitente perante a SEFAZ ou a prefeitura e é usado para assinar o XML do documento fiscal. Em resumo: a chave abre a porta da plataforma de emissão; o certificado dá validade jurídica à nota. Perder uma não substitui a outra, e as duas precisam ser protegidas. ## Como guardar uma Key de API com segurança? A chave dá acesso real a operações fiscais, então deve ser tratada como senha. Ela não deve ficar escrita no código-fonte, em repositórios, em planilhas ou em mensagens. O ideal é armazená-la em variáveis de ambiente ou em ferramentas de gerenciamento de segredos, como um key vault. Também é boa prática usar chaves separadas para homologação e produção, dar a cada integração apenas as permissões necessárias e trocar a chave periodicamente (key rotation). Se houver suspeita de vazamento, a chave deve ser revogada e substituída imediatamente. ## Exemplos de Key de API - Uma software house que vende um ERP configura a Key de API no servidor do sistema; sempre que um cliente fatura um pedido, o ERP envia os dados da NF-e à API fiscal com essa chave no cabeçalho. - Um marketplace cria uma chave para o ambiente de homologação, faz todos os testes de emissão de NFS-e e só depois gera uma chave de produção para emitir notas com validade fiscal. - Após um desenvolvedor sair da equipe, a empresa revoga a Key de API que ele usava e gera uma nova, atualizando o segredo no servidor sem interromper as emissões. - Uma empresa cria uma chave apenas de leitura para que um agente de inteligência artificial consulte o status de documentos via MCP, sem permissão para cancelar notas. ## Perguntas frequentes ### Key de API e API Key são a mesma coisa? Sim. Key de API, API Key e chave de API são nomes diferentes para o mesmo conceito: um código secreto que identifica e autoriza um sistema a usar uma API. ### Posso usar a mesma Key de API em homologação e produção? Em geral, não é recomendado. Usar chaves separadas evita que testes gerem documentos fiscais reais e facilita identificar qual ambiente fez cada requisição. ### O que fazer se a Key de API vazar? Revogue a chave no painel do provedor o quanto antes, gere uma nova, atualize o sistema que a utiliza e revise os registros de acesso para verificar se houve uso indevido. ### A Key de API substitui o certificado digital? Não. A chave autentica seu sistema na plataforma de emissão. O certificado digital continua necessário para assinar os documentos fiscais e identificar a empresa perante o fisco. ## Termos relacionados - [Token de autenticação](https://conota.dev/glossario/token-de-autenticacao.md) - [Header de autenticação](https://conota.dev/glossario/header-de-autenticacao.md) - [Permissão de acesso à API](https://conota.dev/glossario/permissao-de-acesso-a-api.md) - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) - [Key rotation](https://conota.dev/glossario/key-rotation.md) - [Bearer token](https://conota.dev/glossario/bearer-token.md) --- Fonte: [Key de API](https://conota.dev/glossario/key-de-api/) · Atualizado em 2026-10-22 --- # Key Derivation Function > Key Derivation Function (KDF) é um algoritmo criptográfico que transforma um segredo, como uma senha ou uma chave mestra, em uma ou mais chaves criptográficas seguras. É usada para proteger senhas armazenadas, cifrar arquivos sensíveis, como certificados digitais, e gerar chaves diferentes para cada finalidade a partir de um único segredo. **Também conhecido como:** Função de derivação de chave, Função de derivação de chaves, Derivação de chave, KDF, Key Derivation Function **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é uma Key Derivation Function, em palavras simples? Uma Key Derivation Function, ou função de derivação de chave, é uma espécie de máquina que recebe um segredo e devolve uma chave pronta para ser usada em criptografia. Esse segredo pode ser uma senha digitada por uma pessoa ou uma chave mestra guardada por um sistema. A ideia central é que senhas humanas costumam ser curtas e previsíveis, e não servem diretamente como chaves de cifragem. A KDF converte esse material em uma chave com o tamanho e o formato corretos, além de dificultar que alguém descubra o segredo original. ## Como funciona uma KDF? A KDF combina o segredo com um valor aleatório chamado salt (sal). O salt garante que duas pessoas com a mesma senha obtenham chaves diferentes e impede o uso de tabelas pré-calculadas de senhas comuns. Nas KDFs feitas para senhas, o cálculo é repetido muitas vezes ou exige bastante memória de propósito. Para um usuário legítimo, essa demora é quase imperceptível, mas para um atacante que tenta milhões de senhas por segundo ela torna o ataque muito mais caro. No final, a função entrega uma chave do tamanho desejado. Com os mesmos dados de entrada (segredo, salt e parâmetros), o resultado é sempre igual, o que permite recriar a chave quando necessário sem precisar armazená-la. ## Para que serve uma KDF em sistemas de emissão fiscal? O exemplo mais próximo do dia a dia fiscal é o arquivo PFX do certificado digital A1. A senha do arquivo não cifra a chave privada diretamente: uma KDF transforma essa senha na chave que protege o conteúdo do arquivo. Plataformas que guardam certificados de vários CNPJs, como uma API fiscal, podem usar KDFs para derivar chaves de cifragem específicas para cada empresa a partir de uma chave mestra. Assim, mesmo que uma chave derivada seja exposta, as demais continuam protegidas. KDFs também protegem as senhas de acesso a consoles e painéis de gestão: em vez de guardar a senha, o sistema guarda apenas o resultado da derivação, que não pode ser revertido facilmente. ## Qual a diferença entre KDF e hash comum? Funções de hash comuns, como as usadas para gerar o hash de um documento fiscal, foram feitas para ser rápidas e verificar integridade. Essa velocidade é ótima para conferir arquivos, mas ruim para proteger senhas, pois facilita ataques de tentativa e erro. Uma KDF pode usar hashes internamente, mas acrescenta salt, repetições e parâmetros ajustáveis de custo. Além disso, ela produz chaves no tamanho exato exigido por um algoritmo de cifragem, algo que um hash simples não foi pensado para fazer. ## Quais são as KDFs mais conhecidas? Para senhas, as mais citadas são PBKDF2, bcrypt, scrypt e Argon2. As três últimas foram projetadas para ser mais resistentes a ataques com hardware especializado, exigindo mais memória ou processamento. Para derivar várias chaves a partir de um segredo que já é forte e aleatório, como uma chave mestra, é comum usar a HKDF, baseada em HMAC. Ela é rápida porque não precisa compensar a fraqueza de uma senha humana. ## Quais cuidados tomar ao usar uma KDF? Use sempre algoritmos padronizados e bibliotecas consolidadas, nunca uma fórmula criada internamente. Gere um salt aleatório e único para cada senha ou chave, e escolha parâmetros de custo compatíveis com as recomendações atuais, revisando-os com o tempo. Quando a KDF parte de uma chave mestra, essa chave deve ficar protegida em um HSM ou em uma solução de gerenciamento de segredos, pois quem a obtiver consegue recriar todas as chaves derivadas. ## Exemplos de Key Derivation Function - Ao importar um arquivo PFX, o sistema usa a senha informada pelo cliente em uma KDF para obter a chave que decifra a chave privada do certificado digital A1. - Uma plataforma de emissão fiscal deriva, com HKDF, uma chave de cifragem diferente para cada CNPJ cadastrado a partir de uma chave mestra guardada em um HSM. - Um ERP armazena as senhas dos usuários do seu módulo fiscal usando Argon2 com salt individual, em vez de guardar as senhas em texto puro. - Uma equipe de segurança aumenta o número de iterações do PBKDF2 usado para proteger backups de certificados A1 depois de avaliar que o hardware dos atacantes ficou mais rápido. ## Perguntas frequentes ### KDF é a mesma coisa que criptografia? Não exatamente. A KDF não cifra dados: ela produz a chave que será usada por um algoritmo de criptografia. É uma etapa anterior, que transforma um segredo em uma chave adequada. ### É possível descobrir a senha a partir da chave derivada? Não diretamente, pois a KDF é uma função de mão única. O atacante só pode tentar adivinhar senhas e repetir o cálculo, e a lentidão proposital da KDF torna isso caro, especialmente com senhas fortes. ### O salt precisa ser secreto? Não. O salt pode ser armazenado junto com o resultado, pois sua função é tornar cada derivação única e impedir tabelas pré-calculadas. O que precisa ser secreto é a senha ou a chave mestra. ### Preciso implementar uma KDF para integrar com uma API fiscal? Normalmente não. A API e as bibliotecas de certificados já aplicam KDFs internamente. O integrador deve apenas usar senhas fortes, proteger credenciais e seguir boas práticas de gerenciamento de segredos. ## Termos relacionados - [Geração de chave criptográfica](https://conota.dev/glossario/geracao-de-chave-criptografica.md) - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) - [Arquivo PFX](https://conota.dev/glossario/arquivo-pfx.md) - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [HSM](https://conota.dev/glossario/hsm.md) - [HMAC em webhooks](https://conota.dev/glossario/hmac-em-webhooks.md) --- Fonte: [Key Derivation Function](https://conota.dev/glossario/key-derivation-function/) · Atualizado em 2026-10-22 --- # Key Encipherment > Key Encipherment é uma das permissões de uso que podem constar em um certificado digital, dentro da extensão Key Usage do padrão X.509. Ela indica que a chave pública do certificado pode ser usada para cifrar outras chaves, como chaves de sessão temporárias, protegendo a troca segura de informações em conexões criptografadas. **Também conhecido como:** keyEncipherment, Cifragem de chave, Cifração de chave, Uso de chave para cifragem de chaves, Key Encipherment **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que significa Key Encipherment em um certificado digital? Todo certificado digital no padrão X.509, como os emitidos na ICP-Brasil, pode trazer uma lista de usos permitidos para a sua chave. Essa lista fica em um campo chamado Key Usage (uso da chave). Key Encipherment é um dos itens dessa lista. Em termos simples, quando o certificado tem Key Encipherment, ele está dizendo: a chave pública deste certificado pode ser usada para trancar (cifrar) uma outra chave secreta, que depois só o dono da chave privada consegue destrancar. Não se trata de cifrar documentos inteiros, e sim de proteger a entrega de uma chave. ## Como funciona o Key Encipherment na prática? Criptografar grandes volumes de dados com chaves públicas é lento. Por isso, os sistemas costumam criar uma chave simétrica temporária, chamada chave de sessão, que é rápida para cifrar os dados. O problema é como entregar essa chave ao outro lado sem que ninguém a intercepte. É aí que entra o Key Encipherment: quem envia cifra a chave de sessão com a chave pública do certificado do destinatário. Só quem possui a chave privada correspondente consegue recuperá-la. A partir daí, as duas partes conversam usando a chave de sessão. Esse mecanismo, conhecido como transporte de chave, é típico de algoritmos como o RSA em protocolos de comunicação segura e em e-mails cifrados. ## Qual a diferença entre Key Encipherment e Digital Signature? Digital Signature é outro item do Key Usage e autoriza a chave a gerar assinaturas digitais, ou seja, provar quem produziu ou aprovou um conteúdo e garantir que ele não foi alterado. Key Encipherment, por sua vez, autoriza a chave a proteger o envio de outras chaves, com foco em sigilo. Um certificado pode ter os dois usos ao mesmo tempo, apenas um deles ou outros, como Non Repudiation (não repúdio) e Data Encipherment (cifragem direta de dados). Cada sistema que recebe o certificado verifica se o uso pretendido está autorizado antes de aceitá-lo. ## Key Encipherment importa para a emissão de notas fiscais? Na emissão de NF-e, NFC-e, CT-e, MDF-e e NFS-e, o uso mais importante do certificado da empresa é a assinatura digital do XML, que depende de Digital Signature. A comunicação com os servidores do fisco também usa o certificado para autenticar o emissor em conexões seguras. Mesmo assim, é comum que certificados de pessoa jurídica, como o e-CNPJ do tipo A1, tragam Key Encipherment entre seus usos. Para quem integra sistemas fiscais, conhecer esse campo ajuda a diagnosticar erros quando uma biblioteca ou servidor rejeita um certificado por uso de chave incompatível, situação que costuma ocorrer com certificados emitidos para outra finalidade. ## Como verificar se um certificado tem Key Encipherment? No Windows, basta abrir o certificado, ir à aba de detalhes e procurar o campo Uso da chave (Key Usage). Em ferramentas de linha de comando, como o OpenSSL, os usos aparecem na seção de extensões do certificado. Bibliotecas de programação em Java, JavaScript e outras linguagens também permitem ler esse campo para validar o certificado antes de usá-lo em uma integração. ## Exemplos de Key Encipherment - Ao conferir o e-CNPJ A1 recém-adquirido, o desenvolvedor abre o arquivo PFX e vê no campo Key Usage os itens Digital Signature, Non Repudiation e Key Encipherment. - Um servidor que usa troca de chaves RSA recebe do cliente uma chave de sessão cifrada com a chave pública do seu certificado, o que só é possível porque o certificado permite Key Encipherment. - Durante a integração com uma API fiscal, uma rotina de validação verifica o Key Usage do certificado enviado e alerta quando falta Digital Signature, já que Key Encipherment sozinho não permite assinar o XML da nota. - Um sistema de e-mail corporativo usa o certificado do destinatário, que tem Key Encipherment, para cifrar a chave que protege uma mensagem com documentos fiscais anexados. ## Perguntas frequentes ### Key Encipherment serve para assinar a nota fiscal? Não. A assinatura do XML depende do uso Digital Signature. Key Encipherment autoriza a chave pública a cifrar outras chaves, com foco em sigilo na troca de informações, e não em comprovar autoria. ### Posso alterar os usos de chave de um certificado? Não. O Key Usage é definido pela Autoridade Certificadora no momento da emissão e faz parte do conteúdo assinado do certificado. Se os usos não atendem à sua necessidade, é preciso obter um novo certificado adequado. ### Key Encipherment e Data Encipherment são a mesma coisa? Não. Key Encipherment permite cifrar chaves, como chaves de sessão. Data Encipherment permite cifrar dados diretamente com a chave pública, uso bem menos comum, porque cifrar dados por chave pública é lento. ## Termos relacionados - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [Assinatura digital do XML](https://conota.dev/glossario/assinatura-digital-do-xml.md) - [Geração de chave criptográfica](https://conota.dev/glossario/geracao-de-chave-criptografica.md) - [Cadeia de certificação digital](https://conota.dev/glossario/cadeia-de-certificacao-digital.md) - [ICP-Brasil](https://conota.dev/glossario/icp-brasil.md) - [HTTPS](https://conota.dev/glossario/https.md) --- Fonte: [Key Encipherment](https://conota.dev/glossario/key-encipherment/) · Atualizado em 2026-10-22 --- # Key escrow > Key escrow é um arranjo de segurança em que uma cópia de uma chave criptográfica fica guardada com um terceiro de confiança, que só pode liberá-la em situações previamente combinadas, como perda da chave original, auditoria ou ordem de autoridade competente. O objetivo é permitir a recuperação do acesso sem que o custodiante use a chave no dia a dia. **Também conhecido como:** Custódia de chaves, Depósito de chaves, Chave em custódia, Escrow de chaves, Key escrow **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é key escrow, em palavras simples? Imagine deixar uma cópia da chave de casa com um vizinho de confiança, com a regra de que ele só pode entregá-la em uma emergência combinada. Key escrow é a mesma ideia aplicada ao mundo digital: uma chave criptográfica, que protege ou assina informações, tem uma cópia guardada por um terceiro. Esse terceiro, chamado de agente de custódia ou escrow agent, não deve usar a chave por conta própria. Ele apenas a mantém protegida e a libera quando as condições previstas em contrato ou política de segurança forem atendidas. ## Para que serve o key escrow? A principal finalidade é evitar a perda definitiva de acesso. Se uma chave usada para criptografar dados some, por falha de hardware, saída de um funcionário ou esquecimento de senha, as informações protegidas por ela podem ficar inacessíveis para sempre. Com uma cópia em custódia, é possível recuperá-las. Também é usado para atender exigências de auditoria e conformidade, permitindo que pessoas autorizadas acessem dados cifrados de uma organização sob regras claras e registradas. ## Como funciona o key escrow na prática? Quando a chave é criada, uma cópia é enviada de forma protegida ao custodiante. Ele a armazena em ambiente seguro, muitas vezes em um HSM ou em um cofre de segredos com controle de acesso rigoroso. Para liberar a chave, normalmente se exige um processo formal: solicitação justificada, aprovação de mais de uma pessoa e registro de quem pediu, quando e por quê. Alguns modelos dividem a chave em partes guardadas por custodiantes diferentes, de modo que nenhum deles consiga reconstruí-la sozinho. ## Key escrow pode ser usado com certificados de assinatura digital? Aqui é preciso cuidado. Chaves usadas para criptografar dados costumam ser boas candidatas a escrow, porque perdê-las significa perder informações. Já a chave privada de assinatura, como a de um certificado digital usado para assinar notas fiscais, tem outra lógica: a assinatura deve comprovar que só o titular poderia tê-la feito. Se um terceiro tem cópia da chave de assinatura, essa garantia de autoria fica enfraquecida. Por isso, a boa prática é não depositar chaves de assinatura em escrow para fins de recuperação. Em caso de perda, o caminho recomendado é revogar o certificado e emitir um novo. ## Qual a diferença entre key escrow e guardar o certificado em uma plataforma de emissão fiscal? No key escrow, o custodiante apenas guarda a cópia e não usa a chave, salvo em situações excepcionais. Em uma API fiscal, o cliente envia seu certificado digital A1 para que a plataforma assine os documentos em seu nome, de forma autorizada e contínua. Isso é uso delegado da chave, não escrow. Em ambos os casos, porém, os cuidados são parecidos: armazenamento criptografado, acesso restrito, trilha de auditoria e possibilidade de o titular substituir ou remover o certificado quando quiser. O backup do arquivo PFX feito pela própria empresa também não é escrow, pois a cópia continua sob controle do titular. ## Exemplos de Key escrow - Uma empresa que criptografa os arquivos XML fiscais armazenados em seus servidores mantém a chave de criptografia em custódia com uma área de segurança independente, para recuperar os arquivos caso o servidor principal falhe. - Um ERP que guarda dados sensíveis de clientes divide a chave mestra de criptografia em três partes, entregues a três responsáveis diferentes, exigindo pelo menos duas delas para restaurar o acesso. - Ao avaliar um fornecedor de API fiscal, o time técnico pergunta se o certificado A1 enviado ficará em key escrow ou se será usado ativamente para assinar documentos, e quais controles de acesso protegem essa chave. - Após a saída de um administrador de sistemas, uma empresa usa a cópia em custódia da chave de criptografia de backups para continuar acessando cópias antigas que só ele sabia abrir. ## Perguntas frequentes ### Key escrow é a mesma coisa que backup de chave? Não exatamente. O backup é uma cópia que continua sob controle do próprio dono. No key escrow, a cópia fica com um terceiro de confiança, que só pode liberá-la em condições definidas previamente. ### Devo colocar meu certificado A1 em key escrow? Em geral, não é recomendado para chaves de assinatura, pois enfraquece a garantia de autoria. Se o certificado for perdido, o mais seguro é revogá-lo e emitir um novo. Faça backup protegido do arquivo PFX sob seu controle. ### Key escrow é seguro? Depende de como é feito. A segurança vem do custodiante confiável, armazenamento protegido, divisão da chave entre responsáveis e registro de cada acesso. Sem esses controles, a cópia vira um ponto extra de vulnerabilidade. ## Termos relacionados - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) - [HSM](https://conota.dev/glossario/hsm.md) - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [Backup de certificado A1](https://conota.dev/glossario/backup-de-certificado-a1.md) - [Geração de chave criptográfica](https://conota.dev/glossario/geracao-de-chave-criptografica.md) - [Arquivo PFX](https://conota.dev/glossario/arquivo-pfx.md) --- Fonte: [Key escrow](https://conota.dev/glossario/key-escrow/) · Atualizado em 2026-10-22 --- # Key fingerprint de certificado > Key fingerprint de certificado é uma sequência curta de letras e números, calculada por uma função de hash a partir do certificado digital ou de sua chave pública, que funciona como sua impressão digital. Serve para identificar e conferir um certificado de forma rápida e segura, sem precisar abrir ou comparar o arquivo inteiro. **Também conhecido como:** Fingerprint do certificado, Impressão digital do certificado, Thumbprint, Certificate thumbprint, Hash do certificado, Fingerprint da chave, Certificate fingerprint **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é o fingerprint de um certificado, na prática? Um certificado digital, como o Certificado digital A1 usado para emitir NF-e, NFS-e e outros documentos fiscais, é um arquivo com muitas informações: dados da empresa, validade, chave pública, assinatura da autoridade certificadora. Comparar dois certificados olhando tudo isso seria trabalhoso. O fingerprint resume o certificado em um código curto e único. Ele costuma aparecer em formato hexadecimal, às vezes separado por dois-pontos, como 3A:7F:B2:… Quando calculado com SHA-1, tem 40 caracteres hexadecimais; com SHA-256, tem 64. Se dois fingerprints calculados com o mesmo algoritmo são iguais, trata-se do mesmo certificado. ## Como o fingerprint é calculado? O fingerprint é obtido passando o conteúdo do certificado por uma função de hash, um cálculo matemático que transforma qualquer volume de dados em um resultado de tamanho fixo. Os algoritmos mais comuns são SHA-1, ainda exibido por muitos sistemas por compatibilidade, e SHA-256, considerado mais seguro. Esse cálculo tem duas características importantes. Qualquer alteração mínima no certificado gera um fingerprint completamente diferente. E não é possível reconstruir o certificado a partir do fingerprint: ele serve apenas para identificar e conferir, não para recuperar o conteúdo. ## Qual a diferença entre fingerprint do certificado e fingerprint da chave? O fingerprint do certificado é calculado sobre o certificado inteiro. Já o fingerprint da chave é calculado apenas sobre a chave pública que está dentro dele. Na maioria das telas e ferramentas, o termo fingerprint ou impressão digital se refere ao certificado inteiro. A diferença aparece na renovação. Um certificado novo sempre tem um fingerprint de certificado diferente, porque validade e número de série mudam. O fingerprint da chave só permanece igual se o mesmo par de chaves for reaproveitado, o que normalmente não acontece na renovação de um certificado A1, já que um novo par costuma ser gerado. Também não se deve confundir fingerprint com número de série: o número de série é atribuído pela autoridade certificadora, enquanto o fingerprint é calculado a partir do conteúdo. ## Para que serve o fingerprint na emissão fiscal? Em integrações de emissão fiscal por API, o fingerprint ajuda a confirmar qual certificado está carregado para cada CNPJ. Em plataformas que gerenciam várias empresas emissoras, ele permite verificar rapidamente se o certificado enviado é o certo, sem expor o arquivo nem a senha. Ele também é útil após uma renovação: comparar o fingerprint do novo arquivo com o que aparece no sistema confirma se a troca foi feita. Em logs e trilhas de auditoria, registrar o fingerprint em vez do certificado permite rastrear qual certificado assinou determinado XML. Em conexões com mTLS, alguns sistemas usam o fingerprint para aceitar apenas um certificado específico. ## O fingerprint é uma informação sigilosa? Não. O fingerprint é derivado de dados públicos do certificado e não permite assinar documentos nem se passar pela empresa. Ele pode aparecer em logs, telas de gestão e conversas com o suporte técnico. O que precisa de proteção é a chave privada e a senha do certificado A1. Essas devem ficar guardadas em local seguro, como um keystore ou um serviço de gerenciamento de segredos. ## Como descobrir o fingerprint de um certificado? No Windows, ao abrir um certificado instalado, a aba de detalhes mostra o campo Impressão digital. Navegadores também exibem o fingerprint ao visualizar certificados de sites. Com a ferramenta OpenSSL, para um certificado em formato PEM, o comando openssl x509 -in certificado.pem -noout -fingerprint -sha256 exibe o fingerprint SHA-256. Ao comparar valores, use sempre o mesmo algoritmo, pois SHA-1 e SHA-256 geram códigos diferentes para o mesmo certificado. ## Exemplos de Key fingerprint de certificado - Um ERP envia o novo certificado A1 de um cliente pela API fiscal e, em seguida, compara o fingerprint exibido no painel com o calculado localmente para confirmar que o arquivo correto foi carregado. - Uma empresa com dez CNPJs percebe rejeições de assinatura em uma filial; ao conferir os fingerprints, descobre que essa filial ainda usa o certificado vencido. - O log de integração fiscal registra o fingerprint SHA-256 do certificado usado em cada emissão, permitindo auditar qual certificado assinou cada XML sem armazenar dados sensíveis. - Um time de suporte pede ao cliente apenas o fingerprint do certificado, em vez do arquivo .pfx e da senha, para identificar qual certificado está em uso. ## Perguntas frequentes ### O fingerprint muda quando renovo o certificado A1? Sim. Um certificado renovado é um novo certificado, com outra validade e outro número de série, então seu fingerprint será diferente. Por isso, após a renovação, vale conferir se o novo fingerprint aparece no sistema emissor. ### Posso compartilhar o fingerprint do meu certificado? Sim. O fingerprint não permite assinar documentos nem recuperar o certificado. O que nunca deve ser compartilhado é o arquivo com a chave privada e sua senha. ### Por que o mesmo certificado aparece com fingerprints diferentes em ferramentas distintas? Provavelmente cada ferramenta usa um algoritmo diferente, como SHA-1 e SHA-256. Também pode variar a formatação, com ou sem dois-pontos e letras maiúsculas ou minúsculas. Compare sempre usando o mesmo algoritmo. ## Termos relacionados - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [Keystore de certificados digitais](https://conota.dev/glossario/keystore-de-certificados-digitais.md) - [Key pair na assinatura digital](https://conota.dev/glossario/key-pair-na-assinatura-digital.md) - [Assinatura digital do XML](https://conota.dev/glossario/assinatura-digital-do-xml.md) - [Hash de documento fiscal](https://conota.dev/glossario/hash-de-documento-fiscal.md) - [Key rotation](https://conota.dev/glossario/key-rotation.md) --- Fonte: [Key fingerprint de certificado](https://conota.dev/glossario/key-fingerprint-de-certificado/) · Atualizado em 2026-10-22 --- # Key Identifier no certificado > Key Identifier no certificado é um campo de extensão do certificado digital padrão X.509 que funciona como uma espécie de etiqueta da chave pública. Existem dois tipos: o Subject Key Identifier, que identifica a chave do próprio certificado, e o Authority Key Identifier, que aponta para a chave da autoridade que o emitiu, ajudando a montar a cadeia de certificação. **Também conhecido como:** Identificador de chave, Subject Key Identifier, Authority Key Identifier, Identificador de chave do requerente, Identificador de chave de autoridade, Identificador da chave do titular, SKI / AKI, Key Identifier **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é o Key Identifier em um certificado digital? Todo certificado digital, como o e-CNPJ usado para emitir notas fiscais, carrega uma chave pública e uma série de informações extras chamadas extensões. O Key Identifier, ou identificador de chave, é uma dessas extensões. Ele é um código curto, geralmente exibido como uma sequência de letras e números em hexadecimal, que representa uma chave específica. Na prática, ele funciona como um apelido da chave. Em vez de comparar chaves públicas inteiras, que são longas, os sistemas comparam esses identificadores curtos para saber rapidamente de qual chave se está falando. ## Qual a diferença entre Subject Key Identifier e Authority Key Identifier? O Subject Key Identifier (SKI) identifica a chave pública do próprio certificado, ou seja, do titular. Se você abrir o certificado A1 de uma empresa, o SKI se refere à chave daquela empresa. O Authority Key Identifier (AKI) identifica a chave da Autoridade Certificadora que assinou aquele certificado. Ele aponta para cima na hierarquia: o AKI do certificado da empresa deve ser igual ao SKI do certificado da autoridade emissora. É essa correspondência que liga um certificado ao outro. ## Para que serve o Key Identifier na cadeia de certificação? Para confiar em um certificado, o sistema precisa reconstruir o caminho até uma raiz confiável, como a AC Raiz da ICP-Brasil. O Key Identifier ajuda nessa montagem: o sistema lê o AKI do certificado da empresa, procura o certificado intermediário cujo SKI tenha o mesmo valor, e repete o processo até chegar à raiz. Isso é especialmente útil quando uma autoridade possui mais de um certificado com o mesmo nome, por exemplo após uma renovação. O nome pode ser igual, mas a chave muda, e o identificador permite escolher o certificado correto sem ambiguidade. ## Como o Key Identifier é gerado? O padrão X.509 não obriga um único método, mas o mais comum é calcular um hash da chave pública, frequentemente com o algoritmo SHA-1. O resultado é um valor que muda sempre que a chave muda. Por isso, ao renovar um certificado A1 com um novo par de chaves, o novo certificado terá um Subject Key Identifier diferente do anterior, mesmo pertencendo ao mesmo CNPJ. ## Qual a diferença entre Key Identifier, número de série e thumbprint? O número de série é atribuído pela Autoridade Certificadora e identifica o certificado dentro daquela autoridade. O thumbprint, ou impressão digital, é um hash do certificado inteiro, então qualquer alteração no certificado gera outro valor. Já o Key Identifier se refere apenas à chave pública, não ao certificado como um todo. Assim, dois certificados diferentes emitidos com a mesma chave teriam thumbprints e números de série distintos, mas poderiam ter o mesmo Subject Key Identifier. ## Por que isso importa na emissão de documentos fiscais? Ao emitir NF-e, NFC-e, CT-e, MDF-e ou NFS-e, o XML é assinado com o certificado da empresa, e o órgão autorizador valida se esse certificado pertence a uma cadeia confiável da ICP-Brasil. Se a cadeia não puder ser montada, a assinatura pode ser recusada. Em integrações por API, o Key Identifier ajuda sistemas a identificar qual certificado está cadastrado para cada CNPJ, conferir se o arquivo PFX enviado contém os certificados intermediários corretos e diagnosticar problemas quando um certificado novo substitui o antigo. ## Exemplos de Key Identifier no certificado - Ao abrir o certificado A1 de uma empresa no visualizador do sistema operacional, o analista encontra o campo Identificador de Chave de Autoridade e confirma que ele bate com o Identificador de Chave do Requerente do certificado intermediário da Autoridade Certificadora. - Um ERP que emite notas para vários CNPJs registra o Subject Key Identifier de cada certificado cadastrado para saber, após uma renovação, que a chave mudou e que o certificado antigo deve ser desativado. - Durante a investigação de uma rejeição por falha na cadeia de certificação, o time técnico compara o AKI do certificado da empresa com os SKIs dos intermediários disponíveis e descobre que o PFX foi exportado sem o certificado intermediário. - Uma plataforma que recebe certificados em Base64 via API extrai o Key Identifier para exibir ao usuário uma identificação técnica do certificado ao lado da data de validade. ## Perguntas frequentes ### O Key Identifier muda quando renovo o certificado A1? Normalmente sim. Na renovação é gerado um novo par de chaves, e como o Subject Key Identifier é derivado da chave pública, ele passa a ter outro valor. O Authority Key Identifier só muda se a autoridade emissora usar outra chave. ### O Key Identifier é um dado secreto? Não. Ele é público e aparece em qualquer visualizador de certificados. Ele deriva da chave pública, não da chave privada, e não permite assinar documentos nem acessar o certificado. ### Preciso informar o Key Identifier para emitir notas fiscais? Em geral, não. O campo já vem dentro do certificado e é lido automaticamente pelos sistemas durante a validação da cadeia. Ele é útil principalmente para conferências técnicas e diagnóstico de problemas. ### Key Identifier e thumbprint são a mesma coisa? Não. O thumbprint é um hash do certificado inteiro, enquanto o Key Identifier representa apenas a chave pública. Certificados diferentes com a mesma chave têm thumbprints diferentes, mas podem compartilhar o mesmo Subject Key Identifier. ## Termos relacionados - [Cadeia de certificação digital](https://conota.dev/glossario/cadeia-de-certificacao-digital.md) - [Hierarquia de certificados digitais](https://conota.dev/glossario/hierarquia-de-certificados-digitais.md) - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [Autoridade Certificadora](https://conota.dev/glossario/autoridade-certificadora.md) - [AC Raiz da ICP-Brasil](https://conota.dev/glossario/ac-raiz-da-icp-brasil.md) - [Assinatura digital do XML](https://conota.dev/glossario/assinatura-digital-do-xml.md) --- Fonte: [Key Identifier no certificado](https://conota.dev/glossario/key-identifier-no-certificado/) · Atualizado em 2026-10-22 --- # Key length em criptografia > Key length em criptografia é o tamanho de uma chave criptográfica, medido em bits, que indica quantas combinações possíveis existem para essa chave. Quanto maior o key length, mais difícil é descobrir a chave por tentativa e erro. Esse tamanho é sempre definido junto com o algoritmo, como RSA de 2048 bits ou AES de 256 bits. **Também conhecido como:** Tamanho da chave, Comprimento da chave, Tamanho de chave criptográfica, Key size, Key length **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que significa o tamanho da chave na prática? Uma chave criptográfica é, no fundo, um número muito grande usado para cifrar, decifrar ou assinar informações. O key length diz quantos bits esse número tem. Cada bit a mais dobra a quantidade de chaves possíveis, então uma chave de 128 bits não é apenas o dobro de uma de 64 bits: ela tem trilhões de trilhões de vezes mais combinações. Uma comparação simples é a senha de um cadeado com segredo. Um cadeado de 3 dígitos tem mil combinações. Um de 6 dígitos tem um milhão. Na criptografia, a lógica é a mesma, só que em escala muito maior, a ponto de testar todas as combinações se tornar impraticável com a tecnologia atual. ## Por que um tamanho maior nem sempre significa mais seguro? O tamanho da chave só pode ser comparado dentro do mesmo tipo de algoritmo. Algoritmos simétricos, como o AES, usam a mesma chave para cifrar e decifrar, e 128 ou 256 bits já oferecem segurança muito alta. Algoritmos assimétricos, como o RSA, usam um par de chaves (pública e privada) e precisam de chaves bem maiores, como 2048 ou 4096 bits, para alcançar um nível de proteção comparável. Já a criptografia de curvas elípticas (ECC) consegue segurança equivalente à do RSA com chaves bem menores. Por isso, dizer que uma chave de 2048 bits é mais segura que uma de 256 bits não faz sentido sem saber qual algoritmo cada uma usa. ## Como o key length aparece nos certificados digitais e na emissão fiscal? Os certificados digitais usados para emitir NF-e, NFC-e, CT-e, MDF-e e, em muitos municípios, NFS-e contêm um par de chaves assimétricas. A chave privada é usada para gerar a assinatura digital do XML, que comprova quem emitiu o documento e que ele não foi alterado. Os certificados emitidos dentro da ICP-Brasil seguem tamanhos mínimos de chave definidos pelas normas da infraestrutura, e é comum encontrar chaves RSA de 2048 bits em certificados de usuário final. Para quem integra um sistema a uma API fiscal, o key length normalmente já vem definido pelo certificado contratado. O cuidado principal é proteger a chave privada, por exemplo guardando o arquivo PFX em local seguro e usando gerenciamento de segredos, já que uma chave grande não ajuda nada se o arquivo vazar. ## Quais tamanhos de chave são considerados adequados hoje? De forma geral, chaves RSA de 1024 bits são consideradas insuficientes para usos novos, e o mínimo recomendado passou a ser 2048 bits. Para AES, 128 bits é considerado seguro e 256 bits é usado quando se quer margem extra. Em curvas elípticas, chaves de 256 bits são bastante comuns. Essas recomendações mudam com o tempo, à medida que computadores ficam mais rápidos e surgem novas técnicas de ataque. Por isso, órgãos de padronização e infraestruturas como a ICP-Brasil revisam periodicamente os requisitos mínimos. ## Existe desvantagem em usar chaves muito grandes? Sim. Chaves maiores exigem mais processamento para gerar, assinar e verificar. Em sistemas que emitem grande volume de documentos, isso pode aumentar o tempo de resposta e o consumo de recursos. Também há limites de compatibilidade: alguns sistemas e equipamentos aceitam apenas determinados tamanhos. Por isso, a escolha costuma equilibrar segurança, desempenho e compatibilidade, seguindo o tamanho exigido pelo padrão ou pela autoridade certificadora em vez de simplesmente escolher o maior número disponível. ## Exemplos de Key length em criptografia - Ao abrir os detalhes de um certificado digital A1 no computador, o analista vê no campo de chave pública a indicação RSA (2048 bits), que é o key length usado para assinar as notas fiscais da empresa. - Um ERP que armazena dados sensíveis de clientes cifra essas informações com AES de 256 bits antes de gravá-las no banco de dados. - A equipe de segurança de um marketplace decide não aceitar mais chaves RSA de 1024 bits em integrações internas e exige no mínimo 2048 bits para novos certificados. - Um desenvolvedor configura um HSM para gerar um par de chaves com o tamanho exigido pela autoridade certificadora antes de solicitar a emissão do certificado da empresa. ## Perguntas frequentes ### Key length e senha do certificado são a mesma coisa? Não. O key length é o tamanho da chave criptográfica, definido na geração do certificado. A senha do arquivo PFX apenas protege o acesso a essa chave. Uma senha fraca pode expor até uma chave muito grande. ### Posso aumentar o tamanho da chave de um certificado que já tenho? Não. O tamanho é definido quando o par de chaves é gerado e faz parte do certificado. Para usar outra chave, é preciso gerar um novo par e emitir um novo certificado. ### Preciso escolher o key length para emitir notas por API? Normalmente não. O tamanho vem do certificado digital emitido pela autoridade certificadora, que já segue os requisitos da ICP-Brasil. A integração apenas usa esse certificado para assinar os documentos. ### Por que o RSA usa chaves tão maiores que o AES? Porque são algoritmos de natureza diferente. O RSA é assimétrico e sua segurança depende de problemas matemáticos que exigem números muito grandes. O AES é simétrico e atinge alta segurança com 128 ou 256 bits. ## Termos relacionados - [Geração de chave criptográfica](https://conota.dev/glossario/geracao-de-chave-criptografica.md) - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [Assinatura digital do XML](https://conota.dev/glossario/assinatura-digital-do-xml.md) - [ICP-Brasil](https://conota.dev/glossario/icp-brasil.md) - [HSM](https://conota.dev/glossario/hsm.md) - [Cadeia de certificação digital](https://conota.dev/glossario/cadeia-de-certificacao-digital.md) --- Fonte: [Key length em criptografia](https://conota.dev/glossario/key-length-em-criptografia/) · Atualizado em 2026-10-22 --- # Key management service > Key management service é um serviço especializado em criar, guardar, proteger, usar e controlar chaves criptográficas de forma centralizada. Em vez de deixar chaves espalhadas em arquivos ou códigos, ele mantém essas chaves sob regras de acesso, registro de uso e rotação, reduzindo o risco de vazamento de dados sensíveis. **Também conhecido como:** Serviço de gerenciamento de chaves, Serviço de gestão de chaves criptográficas, Gerenciador de chaves, KMS, Key management service **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é um key management service, em palavras simples? Pense em um cofre com porteiro. As chaves criptográficas, que servem para embaralhar e desembaralhar dados, ficam guardadas nesse cofre. Quem precisa usá-las não leva a chave para casa: pede ao porteiro que execute a operação e devolva só o resultado. Esse é o papel de um key management service, também chamado de KMS. Ele concentra a gestão do ciclo de vida das chaves, que vai da criação ao descarte, e garante que cada uso seja autorizado e registrado. ## Para que serve um key management service em sistemas fiscais? Sistemas que emitem documentos fiscais lidam com informações sensíveis: certificados digitais A1, senhas desses certificados, dados de clientes, XMLs autorizados e credenciais de acesso a APIs. Se qualquer um desses itens vazar, alguém pode emitir notas em nome da empresa ou acessar dados protegidos. Um KMS ajuda a criptografar essas informações quando estão armazenadas, de modo que, mesmo que um banco de dados seja copiado indevidamente, o conteúdo continue ilegível sem a chave. Em plataformas com muitas empresas emissoras, ele também permite separar chaves por cliente, reforçando a segregação de dados. ## Como funciona um key management service na prática? Normalmente, o KMS guarda uma chave mestra que nunca sai dele. Quando a aplicação precisa proteger um dado, ela pede ao serviço que criptografe ou gere uma chave de dados temporária. Essa técnica, conhecida como criptografia em envelope, evita que a chave principal circule pela aplicação. Cada pedido passa por verificação de permissão: só determinados serviços ou pessoas podem usar determinada chave. Todas as operações ficam registradas, o que facilita auditorias e investigações. Muitos KMS também oferecem rotação automática, trocando chaves periodicamente sem interromper o sistema. ## Qual a diferença entre key management service, key vault e gerenciamento de segredos? O foco do KMS são chaves criptográficas e as operações feitas com elas, como criptografar, descriptografar e assinar. Um key vault costuma ser um cofre mais amplo, que pode guardar chaves, certificados e segredos. Já o gerenciamento de segredos trata de valores sensíveis em geral, como senhas, tokens e API Keys. Na prática, essas soluções se complementam e muitas vezes aparecem juntas em um mesmo produto. Uma arquitetura comum usa o KMS para proteger as chaves que, por sua vez, criptografam os segredos guardados em outro serviço. ## Quais cuidados são importantes ao usar um key management service? Conceda o mínimo de permissão necessário: cada aplicação deve acessar apenas as chaves de que realmente precisa. Ative a rotação de chaves, monitore os registros de uso e defina alertas para acessos fora do padrão. Também é preciso planejar o descarte. Excluir uma chave torna ilegível tudo o que foi criptografado com ela, então essa ação deve ser feita com cuidado, especialmente quando há obrigação de guarda de documentos fiscais por longos períodos. ## Exemplos de Key management service - Uma plataforma de emissão fiscal criptografa o arquivo do certificado digital A1 de cada cliente com uma chave gerenciada por um KMS antes de salvá-lo no banco de dados. - Um ERP integrado ao emissor fiscal guarda a API Key de emissão criptografada e só a descriptografa, via KMS, no momento de chamar o endpoint de emissão. - Uma equipe de segurança configura a rotação automática das chaves usadas para proteger XMLs fiscais armazenados, sem precisar alterar o código da aplicação. - Durante uma auditoria, a empresa consulta os registros do KMS para comprovar quais serviços usaram a chave que protege a senha dos certificados digitais. ## Perguntas frequentes ### Key management service guarda o certificado digital A1? Depende da solução. Muitos KMS guardam apenas chaves criptográficas usadas para proteger o certificado, que fica armazenado criptografado em outro local. Alguns produtos, mais próximos de um key vault, também armazenam certificados diretamente. ### Uma pequena empresa precisa de um KMS? Se ela desenvolve um sistema próprio que guarda certificados, senhas ou dados de clientes, um KMS é uma boa prática de segurança. Se usa uma plataforma pronta, a responsabilidade costuma ficar com o fornecedor. ### O que acontece se a chave do KMS for apagada? Os dados criptografados com ela deixam de poder ser lidos. Por isso, muitos serviços exigem um período de espera antes da exclusão definitiva, permitindo cancelar a ação em caso de erro. ## Termos relacionados - [Key vault](https://conota.dev/glossario/key-vault.md) - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) - [Key rotation](https://conota.dev/glossario/key-rotation.md) - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [Keystore de certificados digitais](https://conota.dev/glossario/keystore-de-certificados-digitais.md) - [Trilha de auditoria fiscal](https://conota.dev/glossario/trilha-de-auditoria-fiscal.md) --- Fonte: [Key management service](https://conota.dev/glossario/key-management-service/) · Atualizado em 2026-10-22 --- # Key pair na assinatura digital > Key pair na assinatura digital é o par de chaves criptográficas formado por uma chave privada, usada para assinar documentos, e uma chave pública, usada para conferir essa assinatura. Na emissão fiscal, esse par fica no certificado digital da empresa e garante que o XML de uma NF-e, por exemplo, veio dela e não foi alterado. **Também conhecido como:** Par de chaves, Par de chaves criptográficas, Par de chaves pública e privada, Chaves assimétricas, Key pair **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é um key pair, em termos simples? Key pair significa par de chaves. São dois códigos matemáticos gerados juntos e ligados entre si: a chave privada e a chave pública. O que uma faz, só a outra consegue conferir. Uma boa comparação é um carimbo exclusivo e um molde para conferi-lo. A chave privada funciona como o carimbo: só o dono deve tê-la. A chave pública é o molde que qualquer pessoa pode usar para verificar se a marca no papel foi feita por aquele carimbo. O molde não serve para carimbar, então divulgá-lo não traz risco. ## Como o key pair funciona na assinatura de uma nota fiscal? Quando um sistema emite uma NF-e, uma NFC-e, um CT-e ou um MDF-e, ele primeiro calcula um resumo do XML, chamado hash. Em seguida, usa a chave privada da empresa para assinar esse resumo. O resultado é inserido no próprio XML, junto com o certificado que contém a chave pública. Ao receber o documento, a SEFAZ usa a chave pública para validar a assinatura e recalcula o resumo do XML. Se tudo bater, ela sabe duas coisas: o documento foi assinado pelo dono daquele certificado e nenhum dado foi alterado depois da assinatura. Se algo não confere, o documento é rejeitado. ## Onde fica o key pair no certificado digital? No certificado digital A1, a chave privada e o certificado com a chave pública ficam reunidos em um arquivo, normalmente com extensão .pfx ou .p12, protegido por senha. É esse arquivo que a empresa instala no sistema emissor ou envia para uma API fiscal. No certificado A3, a chave privada fica guardada em um dispositivo físico, como token ou cartão, e em geral não pode ser copiada. Por isso, integrações em servidores e APIs costumam usar o modelo A1, que permite assinar automaticamente sem alguém conectar um dispositivo. ## Qual a diferença entre key pair e certificado digital? O key pair é apenas o par de chaves. O certificado digital é o documento eletrônico, emitido por uma autoridade certificadora, que liga a chave pública a uma identidade, como o CNPJ da empresa, e define um prazo de validade. Sem o certificado, a SEFAZ teria a chave pública, mas não saberia a quem ela pertence. Quando o certificado é renovado, normalmente um novo par de chaves é gerado, e o sistema emissor precisa passar a usar o arquivo novo. ## Por que a chave privada precisa ser tão protegida? Quem tem a chave privada e a senha do certificado consegue assinar documentos fiscais em nome da empresa. Um vazamento pode permitir a emissão de notas indevidas, com consequências fiscais e jurídicas. Por isso, boas práticas incluem não guardar o arquivo do certificado em repositórios de código, não enviar a senha por e-mail ou chat, restringir quem tem acesso e usar ferramentas de gerenciamento de segredos, como cofres de chaves, para armazená-lo de forma criptografada. ## Como uma API fiscal usa o key pair da empresa? Em uma emissão fiscal por API, a empresa cadastra seu certificado A1 uma vez, geralmente enviando o arquivo convertido em Base64 junto com a senha. A partir daí, a API usa a chave privada para assinar cada XML antes de transmiti-lo à SEFAZ ou à prefeitura. No Conota, os certificados de cada CNPJ ficam reunidos no Console, o que facilita acompanhar quais empresas estão com certificado válido e trocar o arquivo quando ele for renovado, sem alterar a integração do ERP ou da plataforma de vendas. ## Exemplos de Key pair na assinatura digital - Um ERP envia os dados de uma venda para a API fiscal, que usa a chave privada do certificado A1 da loja para assinar o XML da NF-e antes de transmiti-lo à SEFAZ. - A SEFAZ rejeita uma nota porque o XML foi modificado depois de assinado; ao conferir com a chave pública, o resumo do documento não bateu com a assinatura. - Um marketplace que emite notas para vários vendedores mantém um key pair diferente para cada CNPJ, já que cada empresa só pode assinar os próprios documentos. - Ao renovar o certificado digital, a equipe de TI substitui o arquivo .pfx na plataforma fiscal, pois o novo certificado traz um novo par de chaves. ## Perguntas frequentes ### Posso compartilhar a chave pública sem risco? Sim. A chave pública serve apenas para conferir assinaturas e já vai dentro do XML assinado. Ela não permite assinar documentos. O que nunca deve ser compartilhado sem controle é a chave privada e a senha do certificado. ### O que acontece se o certificado vencer? A SEFAZ e as prefeituras passam a rejeitar documentos assinados com ele. A empresa precisa adquirir um novo certificado, que normalmente vem com um novo par de chaves, e atualizá-lo no sistema ou na API de emissão. ### Uma empresa com várias filiais precisa de vários key pairs? Depende do certificado usado. Em muitos casos, o certificado da matriz pode assinar documentos das filiais com o mesmo CNPJ base, mas convém confirmar as regras aplicáveis a cada documento e órgão autorizador. ### Key pair é o mesmo que API Key? Não. A API Key identifica o sistema que chama a API. O key pair assina o documento fiscal em nome da empresa emitente. São credenciais diferentes, com finalidades diferentes, e ambas precisam ser protegidas. ## Termos relacionados - [Assinatura digital do XML](https://conota.dev/glossario/assinatura-digital-do-xml.md) - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [Keystore de certificados digitais](https://conota.dev/glossario/keystore-de-certificados-digitais.md) - [Key fingerprint de certificado](https://conota.dev/glossario/key-fingerprint-de-certificado.md) - [Hash de documento fiscal](https://conota.dev/glossario/hash-de-documento-fiscal.md) - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) --- Fonte: [Key pair na assinatura digital](https://conota.dev/glossario/key-pair-na-assinatura-digital/) · Atualizado em 2026-10-22 --- # Key rotation > Key rotation é a prática de substituir periodicamente chaves, senhas e outras credenciais de acesso por novas versões, desativando as antigas. Em integrações fiscais por API, ela se aplica a API Keys, tokens e segredos usados para emitir documentos, reduzindo o risco de uso indevido caso uma credencial seja vazada ou esquecida em algum lugar. **Também conhecido como:** Rotação de chaves, Rotação de credenciais, Rotação de segredos, Troca periódica de chaves, Key rotation **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que significa key rotation? Key rotation, ou rotação de chaves, é trocar uma credencial de acesso por outra nova de tempos em tempos ou sempre que houver suspeita de problema. A chave antiga deixa de funcionar e passa a valer apenas a nova. Pense na troca do segredo de um cofre: mesmo que ninguém tenha descoberto o código atual, mudá-lo regularmente diminui a chance de alguém usá-lo sem permissão. No mundo das APIs, o cofre é o acesso ao sistema e o código é a chave de API, o token ou outro segredo. ## Para que serve a rotação de chaves em uma API fiscal? Uma chave de API fiscal permite emitir, cancelar e consultar notas em nome de uma empresa. Se ela vazar, alguém poderia emitir documentos indevidos ou acessar dados sensíveis de clientes e operações. A rotação limita o tempo em que uma chave exposta continua útil. Ela também ajuda em situações comuns do dia a dia, como a saída de um desenvolvedor da equipe, a troca de um fornecedor ou a descoberta de uma chave salva por engano em um repositório de código ou em um log. ## Como funciona a rotação de uma API Key na prática? O processo costuma seguir alguns passos: gerar uma nova chave no painel ou console do serviço, atualizar essa chave nos sistemas que fazem as chamadas (ERP, plataforma de vendas, servidores), confirmar que as requisições com a nova chave estão funcionando e, por fim, revogar a chave antiga. Muitos serviços permitem manter duas chaves ativas ao mesmo tempo por um período curto. Essa sobreposição evita que a emissão de notas pare enquanto todos os sistemas são atualizados. Depois da troca concluída, a chave anterior deve ser desativada para que a rotação tenha efeito real. ## Com que frequência as chaves devem ser trocadas? Não existe um prazo único obrigatório. Cada empresa define sua política conforme o risco, as regras internas de segurança e as exigências de clientes ou auditorias. O importante é ter uma rotina definida, e não trocar apenas quando algo dá errado. Além da troca programada, a rotação deve ser imediata quando houver suspeita de vazamento, quando alguém com acesso deixar a empresa ou quando uma chave aparecer em local inadequado, como e-mails, planilhas ou mensagens de chat. ## Qual a diferença entre rotação de API Key e renovação do certificado digital? A API Key identifica o sistema que está chamando a API do emissor. Já o certificado digital A1 identifica a empresa perante a SEFAZ ou a prefeitura e é usado para assinar o XML dos documentos fiscais. São credenciais diferentes, com finalidades diferentes. O certificado digital tem prazo de validade e precisa ser renovado antes de vencer, senão a emissão é bloqueada. A rotação da API Key, por outro lado, é uma decisão de segurança da empresa. Em ambos os casos vale a mesma lógica: substituir a credencial com planejamento para não interromper a operação. Outros segredos fiscais, como o CSC da NFC-e, também podem ser substituídos seguindo esse cuidado. ## Como fazer key rotation sem interromper a emissão de notas? O primeiro passo é não deixar a chave espalhada pelo código. Guardá-la em um cofre de segredos ou em variáveis de ambiente facilita a troca, porque basta atualizar um único lugar. Ferramentas como key vault e serviços de gerenciamento de chaves ajudam a automatizar esse processo. Também é recomendável testar a nova chave no ambiente de homologação antes de aplicá-la em produção, acompanhar os logs logo após a troca para identificar falhas de autenticação e registrar quem fez a rotação e quando, mantendo uma trilha de auditoria. ## Exemplos de Key rotation - Uma software house que integra o ERP de seus clientes a uma API fiscal define que todas as API Keys de produção são trocadas a cada seis meses, mantendo a chave antiga ativa por alguns dias até que todos os servidores estejam atualizados. - Um desenvolvedor publica por engano uma chave de API em um repositório público. A equipe gera imediatamente uma nova chave no console do emissor, atualiza o sistema de vendas e revoga a chave exposta. - Um marketplace que emite NFC-e e NF-e para vários lojistas armazena as chaves em um cofre de segredos, o que permite fazer a rotação sem alterar o código da aplicação. - Uma empresa que libera um agente de inteligência artificial para consultar documentos fiscais via MCP cria uma credencial exclusiva para ele e a substitui periodicamente, revisando as permissões a cada troca. ## Perguntas frequentes ### Key rotation é obrigatória para emitir notas fiscais? Não há obrigação fiscal de trocar API Keys. Trata-se de uma boa prática de segurança. A obrigação existente é manter o certificado digital válido para assinar os documentos, o que é um assunto diferente. ### A troca da chave cancela ou altera notas já emitidas? Não. Notas autorizadas continuam válidas, pois foram assinadas com o certificado digital da empresa. A rotação da API Key só muda a credencial usada nas próximas chamadas à API. ### O que acontece se eu revogar a chave antiga antes de atualizar os sistemas? As requisições feitas com a chave antiga passam a ser recusadas por falha de autenticação, e a emissão pode parar até que a nova chave seja configurada. Por isso se recomenda um período de sobreposição. ### Posso usar a mesma chave em vários sistemas? É possível, mas dificulta a rotação e o controle. Usar uma chave por sistema ou ambiente permite trocar ou revogar uma delas sem afetar as demais e facilita identificar a origem de cada requisição. ## Termos relacionados - [API Key](https://conota.dev/glossario/api-key.md) - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) - [Key vault](https://conota.dev/glossario/key-vault.md) - [Key management service](https://conota.dev/glossario/key-management-service.md) - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [Trilha de auditoria fiscal](https://conota.dev/glossario/trilha-de-auditoria-fiscal.md) --- Fonte: [Key rotation](https://conota.dev/glossario/key-rotation/) · Atualizado em 2026-10-22 --- # Key Usage no certificado digital > Key Usage no certificado digital é uma extensão do padrão X.509 que indica para quais operações a chave do certificado pode ser usada, como assinar documentos, cifrar chaves ou assinar outros certificados. Sistemas que validam o certificado consultam esse campo e podem recusá-lo quando a operação pretendida não está autorizada nele. **Também conhecido como:** Uso da chave, Extensão Key Usage, Finalidade da chave do certificado, KeyUsage, Key Usage **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é Key Usage em um certificado digital? Todo certificado digital moderno segue o padrão X.509, que permite incluir campos extras chamados extensões. Key Usage, ou uso da chave, é uma dessas extensões. Ela funciona como uma lista de permissões que diz o que o dono do certificado pode fazer com sua chave. Pense em um crachá de empresa que libera a entrada no prédio, mas não no almoxarifado. O certificado pode ser legítimo e estar dentro da validade, mas, se o Key Usage não permitir determinada operação, o sistema que faz a verificação pode rejeitá-lo para aquela finalidade. ## Quais são os valores possíveis do Key Usage? O padrão define um conjunto fixo de usos. Os mais comuns são: digitalSignature (assinatura digital de dados), nonRepudiation, também chamado contentCommitment (garante que o signatário não possa negar a autoria), keyEncipherment (cifrar chaves, usado em conexões seguras), dataEncipherment (cifrar dados diretamente) e keyAgreement (combinar chaves entre duas partes). Há também usos reservados para autoridades certificadoras, como keyCertSign (assinar outros certificados) e cRLSign (assinar listas de certificados revogados). Um certificado de empresa comum não deve ter esses dois usos, pois eles são próprios de quem emite certificados. ## Por que o Key Usage importa na emissão de notas fiscais? Na emissão de NF-e, NFC-e, CT-e e MDF-e, o certificado é usado para duas tarefas principais: assinar o XML do documento e estabelecer uma conexão segura com os servidores da SEFAZ. A assinatura do XML depende da permissão de assinatura digital, e a conexão segura costuma depender também dos usos ligados a autenticação e troca de chaves. Certificados e-CNPJ e e-CPF emitidos dentro da ICP-Brasil para pessoas e empresas já vêm, em geral, com os usos necessários para essas tarefas. Problemas aparecem quando se tenta usar um certificado de outro tipo, como um certificado de servidor web ou um certificado gerado fora da cadeia oficial, que pode não ter as permissões adequadas. ## Qual a diferença entre Key Usage e Extended Key Usage? Key Usage descreve operações criptográficas básicas, como assinar ou cifrar. Extended Key Usage, ou EKU, é outra extensão que descreve finalidades de aplicação, como autenticação de cliente, autenticação de servidor ou proteção de e-mail. As duas se complementam. Um certificado pode permitir assinatura digital no Key Usage e, no EKU, indicar que serve para autenticar um cliente em conexões seguras. Sistemas fiscais podem verificar ambas as extensões, então um erro de certificado nem sempre está no Key Usage, mas pode estar no EKU. ## Como verificar o Key Usage de um certificado? No Windows, basta abrir o certificado, ir à aba de detalhes e procurar o campo Uso da chave. Em sistemas com OpenSSL, é possível extrair o certificado do arquivo PFX e exibir suas extensões em texto, onde aparece a seção X509v3 Key Usage. Em integrações por API, o próprio serviço de emissão costuma validar o certificado no momento do envio e informar se ele não é compatível. Isso evita descobrir o problema apenas quando a SEFAZ ou a prefeitura rejeita o documento. ## Exemplos de Key Usage no certificado digital - Uma empresa envia seu certificado A1 a uma API fiscal e a verificação mostra os usos Assinatura Digital, Não Repúdio e Cifragem de Chave, compatíveis com a assinatura do XML da NF-e. - Um desenvolvedor tenta usar um certificado SSL de servidor web para assinar NFC-e e recebe erro, porque esse certificado não pertence à cadeia da ICP-Brasil e tem usos voltados à autenticação de sites. - Um analista de suporte abre o arquivo PFX de um cliente, confere o campo Uso da chave e confirma que o certificado é de pessoa jurídica e serve para emissão fiscal antes de cadastrá-lo no console. - Em uma auditoria de segurança, a equipe verifica que nenhum certificado de empresa possui o uso keyCertSign, que deveria existir apenas em certificados de autoridades certificadoras. ## Perguntas frequentes ### Posso alterar o Key Usage de um certificado que já tenho? Não. O Key Usage faz parte do conteúdo assinado pela autoridade certificadora. Qualquer alteração invalida o certificado. Se os usos não atendem à necessidade, é preciso solicitar um novo certificado do tipo correto. ### O certificado A1 da empresa serve para assinar notas fiscais? Em geral, sim. Certificados e-CNPJ A1 da ICP-Brasil costumam incluir os usos de assinatura digital e não repúdio exigidos para assinar documentos fiscais. Ainda assim, vale conferir o campo Uso da chave em caso de rejeição. ### O que significa a marcação de extensão crítica no Key Usage? Quando a extensão é marcada como crítica, o sistema que valida o certificado é obrigado a entendê-la e respeitá-la. Se não conseguir interpretá-la, deve rejeitar o certificado em vez de ignorar a restrição. ## Termos relacionados - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [Assinatura digital do XML](https://conota.dev/glossario/assinatura-digital-do-xml.md) - [Cadeia de certificação digital](https://conota.dev/glossario/cadeia-de-certificacao-digital.md) - [ICP-Brasil](https://conota.dev/glossario/icp-brasil.md) - [Arquivo PFX](https://conota.dev/glossario/arquivo-pfx.md) - [e-CNPJ](https://conota.dev/glossario/e-cnpj.md) --- Fonte: [Key Usage no certificado digital](https://conota.dev/glossario/key-usage-no-certificado-digital/) · Atualizado em 2026-10-22 --- # Key vault > Key vault é um cofre digital usado para guardar, de forma protegida e centralizada, informações sensíveis como chaves de API, senhas, tokens e certificados digitais. Em vez de ficarem espalhados no código ou em arquivos, esses segredos são acessados apenas por sistemas e pessoas autorizados, com registro de cada uso. **Também conhecido como:** Cofre de chaves, Cofre de segredos, Vault de segredos, Keyvault, Key vault **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é um key vault, em termos simples? Pense em um key vault como um cofre de banco para dados que não podem vazar. Em vez de guardar dinheiro, ele guarda segredos digitais: a chave que dá acesso a uma API, a senha de um banco de dados, o arquivo de um certificado digital e a senha que o protege. O nome vem do inglês e significa literalmente cofre de chaves. Na prática, é um serviço ou software especializado que armazena esses itens de forma criptografada e só os entrega a quem tem permissão, deixando registrado quem pediu, quando e o quê. ## Para que serve um key vault na emissão fiscal por API? Um sistema que emite notas fiscais por API lida com dois segredos muito valiosos: a chave de acesso à API fiscal e, muitas vezes, o certificado digital A1 da empresa emissora, com sua senha. Quem tiver esses dados pode emitir ou cancelar documentos em nome da empresa. Guardar esses itens em um key vault evita que fiquem expostos no código-fonte, em planilhas, em mensagens internas ou em arquivos de configuração copiados entre servidores. Isso reduz o risco de vazamento e facilita cumprir exigências de segurança e auditoria. Para ERPs, marketplaces e plataformas que atendem muitos CNPJs, o cofre também ajuda a organizar dezenas ou centenas de certificados e chaves, separando o que pertence a cada cliente. ## Como funciona um key vault? Primeiro, o segredo é cadastrado no cofre, que o armazena criptografado. Depois, cada aplicação ou pessoa recebe uma identidade e permissões específicas, por exemplo, apenas ler a chave da API fiscal, sem poder alterá-la. Quando o sistema precisa emitir uma NF-e, ele se autentica no cofre, busca a chave no momento do uso e a envia no header de autenticação da requisição. O segredo não fica gravado no código, e cada acesso gera um registro que pode ser consultado depois. Muitos cofres também permitem versionar segredos e trocá-los periodicamente, prática conhecida como key rotation, sem precisar reinstalar a aplicação. ## Qual a diferença entre key vault, key management service e keystore? O key vault é o cofre de uso geral para segredos: senhas, tokens, chaves de API e certificados. O key management service é focado em criar e controlar chaves criptográficas usadas para cifrar e decifrar dados, muitas vezes sem que a chave saia do serviço. Já o keystore é um arquivo ou repositório que guarda certificados e chaves privadas em um formato específico, como o arquivo de um certificado A1. Um keystore pode, inclusive, ficar guardado dentro de um key vault. ## Quais boas práticas ao usar um key vault? Conceda o menor acesso possível: cada sistema deve ler apenas os segredos de que realmente precisa. Separe segredos de homologação e de produção, para que um teste nunca use a chave real da empresa. Troque chaves periodicamente e sempre que houver suspeita de vazamento, acompanhe os registros de acesso e evite copiar o segredo para logs ou mensagens de erro. Também vale controlar a validade dos certificados guardados, para que não expirem sem aviso. ## Exemplos de Key vault - Um ERP guarda a chave da API fiscal em um key vault e a busca no momento de enviar o payload de emissão, em vez de deixá-la escrita no código. - Uma plataforma que atende vários lojistas armazena o certificado A1 e a senha de cada CNPJ em um key vault, com acesso restrito ao serviço responsável pela emissão. - Após um desenvolvedor deixar a empresa, a equipe gera uma nova chave de API, atualiza o valor no key vault e todos os serviços passam a usar a nova versão sem alterar código. - Na auditoria interna, a equipe consulta o registro do key vault para verificar quais aplicações leram a chave de produção da API fiscal no último mês. ## Perguntas frequentes ### Preciso de um key vault para integrar uma API fiscal? Não é obrigatório, mas é altamente recomendado. Sem um cofre, chaves e certificados tendem a ficar espalhados em arquivos e códigos, aumentando o risco de vazamento e de emissões indevidas em nome da empresa. ### Key vault serve só para guardar senhas? Não. Ele guarda vários tipos de segredos: chaves de API, tokens, senhas, strings de conexão e certificados digitais com suas chaves privadas, sempre com controle de acesso e registro de uso. ### Variáveis de ambiente substituem um key vault? Não totalmente. Variáveis de ambiente evitam colocar segredos no código, mas não oferecem, sozinhas, criptografia centralizada, controle fino de permissões, versionamento nem registro de quem acessou cada segredo. ## Termos relacionados - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) - [Key management service](https://conota.dev/glossario/key-management-service.md) - [Key rotation](https://conota.dev/glossario/key-rotation.md) - [Keystore de certificados digitais](https://conota.dev/glossario/keystore-de-certificados-digitais.md) - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [API Key](https://conota.dev/glossario/api-key.md) --- Fonte: [Key vault](https://conota.dev/glossario/key-vault/) · Atualizado em 2026-10-22 --- # Key wrapping > Key wrapping é a técnica de criptografar uma chave criptográfica usando outra chave, chamada chave de encapsulamento (ou KEK), para que ela possa ser armazenada ou transmitida com segurança. No contexto fiscal, é usada para proteger chaves privadas de certificados digitais e segredos de integração, evitando que fiquem expostos em texto aberto. **Também conhecido como:** Encapsulamento de chave, Envelopamento de chave, Empacotamento de chave, Wrap de chave, Key wrapping **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que significa key wrapping, em palavras simples? Key wrapping pode ser traduzido como encapsulamento de chave. A ideia é guardar uma chave secreta dentro de um cofre que também é protegido por outra chave. Quem tem acesso ao cofre vê apenas um conteúdo embaralhado, inútil sem a chave que o abre. Na criptografia, a chave que está sendo protegida costuma ser chamada de chave de dados (DEK, do inglês data encryption key), e a chave que a protege é a chave de encapsulamento (KEK, do inglês key encryption key). A KEK fica guardada em um local mais seguro e controlado, como um HSM ou um serviço de gerenciamento de chaves. ## Como funciona o key wrapping? Primeiro, o sistema gera ou recebe a chave que precisa ser protegida. Em seguida, aplica um algoritmo específico de encapsulamento, que usa a KEK para transformar essa chave em um bloco cifrado. Esse bloco pode então ser salvo em banco de dados, arquivo ou enviado pela rede sem expor o segredo original. Quando a chave for necessária, o processo inverso, chamado unwrapping, usa a mesma KEK para recuperá-la. Algoritmos de encapsulamento, como o AES Key Wrap, também verificam a integridade: se o bloco cifrado tiver sido alterado, a recuperação falha, em vez de devolver uma chave corrompida. ## Para que serve o key wrapping na emissão de documentos fiscais? Para emitir NF-e, NFC-e, CT-e, MDF-e e, em muitos casos, NFS-e, o XML precisa ser assinado com a chave privada do certificado digital da empresa, geralmente um certificado A1 em arquivo PFX. Uma plataforma de emissão por API armazena esses certificados para assinar documentos automaticamente, o que exige protegê-los muito bem. Com key wrapping, a chave usada para cifrar os certificados guardados não fica solta no banco de dados: ela própria é encapsulada por uma chave mestra mantida em ambiente protegido. Assim, mesmo que um backup ou uma tabela vaze, o invasor não consegue usar os certificados para emitir notas em nome da empresa. ## Qual a diferença entre key wrapping e criptografia comum? A criptografia comum protege dados em geral, como textos, arquivos ou registros. O key wrapping é um caso específico, voltado a proteger outras chaves, e usa algoritmos desenhados para esse tamanho de dado e com verificação de integridade embutida. Os dois costumam trabalhar juntos em um modelo chamado criptografia de envelope: os dados são cifrados com uma chave de dados, e essa chave de dados é encapsulada com a KEK. Isso permite trocar a chave mestra sem precisar recriptografar todos os dados, apenas reencapsular as chaves de dados. ## Onde o key wrapping aparece no dia a dia de uma integração? Ele está presente em HSMs e serviços de gerenciamento de chaves na nuvem, que oferecem operações de wrap e unwrap sem que a chave mestra saia do equipamento. Também aparece no padrão JWE, usado para cifrar tokens e mensagens em JSON, que prevê algoritmos de encapsulamento da chave de conteúdo. Para quem integra um ERP ou marketplace a uma API fiscal, o key wrapping costuma ser invisível: é responsabilidade da plataforma que guarda os certificados. Ainda assim, entender o conceito ajuda a avaliar se o fornecedor trata certificados e credenciais com o cuidado adequado. ## Exemplos de Key wrapping - Uma plataforma de emissão fiscal recebe o arquivo PFX de um cliente, cifra o certificado com uma chave de dados e encapsula essa chave com uma chave mestra guardada em HSM antes de salvar no banco. - Um ERP que mantém certificados A1 de vários CNPJs usa um serviço de gerenciamento de chaves para fazer o wrap das chaves de cada empresa, separando o acesso por cliente. - Uma equipe de segurança faz a rotação anual da chave mestra e apenas reencapsula as chaves de dados existentes, sem precisar recriptografar todos os certificados armazenados. - Um sistema envia um token JWE em que a chave de conteúdo foi encapsulada com a chave pública do destinatário, garantindo que só ele consiga ler os dados. ## Perguntas frequentes ### Key wrapping é o mesmo que senha do certificado PFX? Não. A senha do PFX protege o arquivo do certificado. O key wrapping é uma camada adicional usada por sistemas que armazenam chaves, cifrando-as com uma chave mestra mantida em ambiente seguro, como um HSM. ### Preciso implementar key wrapping para usar uma API fiscal? Normalmente não. Quem guarda e usa o certificado para assinar os documentos é a plataforma de emissão. Se o seu próprio sistema armazena certificados ou chaves, aí sim vale adotar a técnica ou um serviço de gerenciamento de chaves. ### O que acontece se a chave de encapsulamento for perdida? As chaves encapsuladas por ela ficam irrecuperáveis, e os dados protegidos também. Por isso a KEK deve ter backup seguro e controle de acesso rigoroso, geralmente dentro de um HSM ou serviço de gerenciamento de chaves. ## Termos relacionados - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) - [HSM](https://conota.dev/glossario/hsm.md) - [Geração de chave criptográfica](https://conota.dev/glossario/geracao-de-chave-criptografica.md) - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [Arquivo PFX](https://conota.dev/glossario/arquivo-pfx.md) - [JWE](https://conota.dev/glossario/jwe.md) --- Fonte: [Key wrapping](https://conota.dev/glossario/key-wrapping/) · Atualizado em 2026-10-22 --- # Keystore de certificados digitais > Keystore de certificados digitais é um repositório protegido, em arquivo ou em serviço, que guarda certificados digitais e suas chaves privadas. Na emissão fiscal, ele armazena o certificado A1 da empresa para que o sistema possa assinar o XML das notas e se autenticar com segurança junto à SEFAZ e às prefeituras. **Também conhecido como:** Repositório de chaves, Repositório de certificados, Armazenamento de certificados digitais, Cofre de certificados, Key store, Keystore **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é um keystore de certificados digitais? Um keystore, ou repositório de chaves, é um lugar seguro onde ficam guardados certificados digitais junto com as chaves privadas que pertencem a eles. Pense nele como um cofre: o certificado é a identidade digital da empresa, e a chave privada é o que permite usar essa identidade para assinar documentos. Esse cofre pode ser um simples arquivo protegido por senha, como os arquivos .pfx ou .p12 do padrão PKCS#12, um formato específico de uma linguagem de programação, como o JKS do Java, ou um serviço especializado de armazenamento de chaves na nuvem ou em servidores da própria empresa. ## Para que serve o keystore na emissão de notas fiscais? Para emitir NF-e, NFC-e, CT-e, MDF-e e, em muitos casos, NFS-e, o XML do documento precisa ser assinado digitalmente com o certificado da empresa emitente. Além disso, a comunicação com os servidores da SEFAZ costuma exigir que o sistema se identifique com esse mesmo certificado durante a conexão segura. O keystore é de onde o sistema emissor tira o certificado e a chave privada no momento exato em que precisa assinar ou se conectar. Sem ele, ou com ele mal configurado, a emissão simplesmente não acontece. ## Como funciona o keystore com o certificado A1? O certificado A1 é entregue à empresa como um arquivo, normalmente no formato .pfx ou .p12, protegido por uma senha. Esse arquivo já é, por si só, um pequeno keystore: ele contém o certificado público e a chave privada correspondente. Na prática, o sistema abre esse arquivo usando a senha, lê a chave privada e a utiliza para gerar a assinatura do XML. Em integrações por API, é comum enviar o arquivo convertido em Base64, junto com a senha, para que o emissor o armazene de forma segura e passe a usá-lo nas emissões daquela empresa. ## Qual a diferença entre keystore e truststore? O keystore guarda as credenciais que identificam você, ou seja, seu certificado e sua chave privada. O truststore guarda os certificados de terceiros em quem você confia, como os das autoridades certificadoras que validam os servidores com os quais seu sistema conversa. Na emissão fiscal, o keystore serve para provar à SEFAZ quem é a empresa emitente, enquanto o truststore ajuda o sistema a confirmar que está falando com o servidor oficial, e não com um impostor. ## Quais cuidados de segurança o keystore exige? A chave privada é o item mais sensível do keystore. Quem tem acesso a ela e à senha pode assinar documentos fiscais em nome da empresa. Por isso, o arquivo e a senha nunca devem ficar em código-fonte, planilhas, e-mails ou repositórios públicos. Boas práticas incluem guardar senhas em ferramentas de gerenciamento de segredos ou cofres de chaves, limitar quem pode acessar o certificado, registrar cada uso em logs de auditoria e acompanhar a data de validade para trocar o certificado antes que ele expire. ## Como empresas com vários CNPJs organizam seus keystores? Plataformas que emitem notas para muitas empresas, como ERPs, marketplaces e softwares de gestão, precisam lidar com um certificado por CNPJ. Nesse cenário, o keystore deixa de ser um arquivo isolado e vira uma estrutura organizada, em que cada certificado fica associado à sua empresa, separado dos demais. Um emissor fiscal por API pode assumir essa responsabilidade, armazenando os certificados de forma segregada, avisando sobre vencimentos e usando automaticamente o certificado certo em cada emissão, sem que o sistema do cliente precise manipular as chaves a cada nota. ## Exemplos de Keystore de certificados digitais - Um ERP envia por API o arquivo .pfx do certificado A1 de um novo cliente, convertido em Base64, junto com a senha; o emissor guarda esse material em seu keystore e passa a assinar as NF-e daquele CNPJ automaticamente. - Uma equipe de desenvolvimento em Java carrega o certificado da empresa em um keystore do tipo PKCS#12 para assinar o XML de NFC-e e estabelecer a conexão segura com o servidor da SEFAZ. - Um marketplace que emite notas para centenas de vendedores mantém um certificado separado por CNPJ, com alertas de vencimento, para evitar que um certificado expirado bloqueie as emissões de um vendedor. - Uma transportadora troca o certificado A1 vencido no Console do emissor fiscal, e as próximas emissões de CT-e e MDF-e passam a usar o novo certificado sem mudanças no sistema interno. ## Perguntas frequentes ### O arquivo .pfx do certificado A1 é um keystore? Sim. O arquivo .pfx ou .p12 segue o padrão PKCS#12 e funciona como um keystore: reúne o certificado e a chave privada em um único arquivo protegido por senha. ### Posso guardar a senha do certificado junto com o arquivo? Não é recomendado. Arquivo e senha juntos dão acesso total à identidade digital da empresa. O ideal é guardar a senha em um cofre de segredos ou serviço de gerenciamento de chaves, com acesso restrito e registrado. ### O que acontece se o certificado do keystore vencer? As emissões passam a ser rejeitadas, pois a assinatura e a conexão com a SEFAZ deixam de ser aceitas. É preciso adquirir um novo certificado e substituí-lo no keystore ou no emissor fiscal. ### Certificado A3 também fica em keystore? O A3 fica em token ou cartão físico, e a chave privada não sai desse dispositivo. Por isso, ele é menos adequado para emissão automatizada em servidores, onde o A1 é o mais usado. ## Termos relacionados - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [Assinatura digital do XML](https://conota.dev/glossario/assinatura-digital-do-xml.md) - [Key pair na assinatura digital](https://conota.dev/glossario/key-pair-na-assinatura-digital.md) - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) - [Key vault](https://conota.dev/glossario/key-vault.md) - [mTLS](https://conota.dev/glossario/mtls.md) --- Fonte: [Keystore de certificados digitais](https://conota.dev/glossario/keystore-de-certificados-digitais/) · Atualizado em 2026-10-22 --- # KMIP no gerenciamento de chaves > KMIP no gerenciamento de chaves é o uso do Key Management Interoperability Protocol, um padrão aberto que define como sistemas conversam com servidores de chaves criptográficas para criar, guardar, buscar, rotacionar e destruir chaves. Ele evita dependência de um único fornecedor e facilita a proteção de chaves, como as de certificados digitais usados na emissão fiscal. **Também conhecido como:** Protocolo KMIP, Key Management Interoperability Protocol, Protocolo de interoperabilidade de gerenciamento de chaves, KMIP **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é KMIP, em palavras simples? KMIP é um protocolo, ou seja, um conjunto de regras de comunicação. Ele padroniza a forma como um aplicativo pede algo a um gerenciador de chaves: "crie uma chave nova", "me entregue esta chave", "desative aquela chave antiga". É mantido pela OASIS, uma organização que publica padrões abertos de tecnologia. Uma boa analogia é a tomada elétrica padronizada: qualquer aparelho compatível funciona em qualquer tomada do mesmo padrão. Com o KMIP, qualquer sistema compatível consegue conversar com qualquer servidor de chaves compatível, sem adaptações específicas para cada marca. ## Para que serve o KMIP no gerenciamento de chaves? Empresas usam muitas chaves criptográficas: para cifrar bancos de dados, backups, discos, comunicações e para assinar documentos. Sem um padrão, cada sistema guarda suas chaves do próprio jeito, o que gera espalhamento, falta de controle e risco de vazamento. O KMIP permite centralizar essas chaves em um único servidor de gerenciamento, muitas vezes apoiado por um HSM, e fazer com que diferentes sistemas as utilizem pelo mesmo protocolo. Isso simplifica auditoria, rotação periódica, revogação e descarte seguro das chaves. ## Como funciona a comunicação via KMIP? O sistema que precisa da chave atua como cliente e o gerenciador de chaves atua como servidor. As mensagens trafegam por uma conexão TLS com autenticação mútua, em que cliente e servidor apresentam certificados digitais para provar quem são. A porta padrão registrada para o protocolo é a 5696. As mensagens usam um formato binário compacto chamado TTLV (tag, tipo, tamanho e valor), embora o padrão também preveja representações em JSON e XML. Cada objeto gerenciado, como uma chave simétrica, um par de chaves ou um certificado, tem um identificador único e atributos como estado, data de ativação e uso permitido. ## Qual a relação entre KMIP e HSM? O HSM é o equipamento físico ou serviço que gera e protege as chaves dentro de um ambiente resistente a violações. O KMIP é a linguagem usada para conversar com esse ambiente. Muitos HSMs e gerenciadores de chaves oferecem uma interface KMIP justamente para que vários sistemas consigam usá-los de forma padronizada. Ou seja, não são alternativas: o HSM cuida da segurança da chave e o KMIP cuida da comunicação e do ciclo de vida dela entre aplicações e o cofre. ## Por que o KMIP importa para quem emite documentos fiscais? A emissão de NF-e, NFC-e, CT-e, MDF-e e, em muitos municípios, NFS-e exige assinatura digital do XML com um certificado ICP-Brasil, geralmente do tipo A1. A chave privada desse certificado é um ativo sensível: quem a obtém consegue assinar documentos em nome da empresa. Plataformas que gerenciam certificados de muitos CNPJs, como ERPs, marketplaces e infraestruturas de emissão por API, precisam guardar essas chaves com rigor. Um gerenciador de chaves acessível via KMIP ajuda a manter as chaves fora do código e dos servidores de aplicação, com controle de acesso e trilha de auditoria. ## Qual a diferença entre KMIP e gerenciamento de segredos? Gerenciamento de segredos é um conceito mais amplo, que cobre senhas, tokens, API Keys e chaves. O KMIP é um protocolo específico, focado em objetos criptográficos e no ciclo de vida deles. Ferramentas de gerenciamento de segredos podem ou não oferecer suporte a KMIP, dependendo de sua finalidade. ## Exemplos de KMIP no gerenciamento de chaves - Um ERP que emite NF-e para centenas de clientes guarda as chaves privadas dos certificados A1 em um HSM e recupera, via KMIP, apenas a referência necessária para assinar cada XML, sem salvar o arquivo PFX em disco. - Uma equipe de infraestrutura configura o banco de dados que armazena XMLs fiscais para cifrar os arquivos com chaves obtidas de um servidor KMIP, facilitando a rotação periódica dessas chaves. - Um software de backup de documentos fiscais usa KMIP para solicitar a chave de cifragem ao gerenciador central, permitindo trocar de fornecedor de cofre de chaves sem reescrever a integração. - Ao desligar um cliente, a plataforma envia um comando KMIP para revogar e destruir as chaves associadas àquele CNPJ, registrando a operação para auditoria. ## Perguntas frequentes ### KMIP é obrigatório para emitir notas fiscais? Não. A legislação fiscal exige assinatura com certificado ICP-Brasil, mas não define como a chave deve ser armazenada. O KMIP é uma boa prática técnica para quem gerencia muitas chaves, não uma exigência do fisco. ### KMIP substitui o certificado digital? Não. O certificado continua sendo necessário para assinar documentos. O KMIP apenas padroniza como a chave privada e o próprio certificado são guardados, acessados e controlados dentro da infraestrutura da empresa. ### KMIP é uma API REST? Não exatamente. É um protocolo próprio que normalmente trafega em formato binário sobre TLS. Algumas soluções oferecem também APIs REST, mas o KMIP em si segue suas próprias regras de mensagem. ### Pequenas empresas precisam se preocupar com KMIP? Raramente. Ele faz mais sentido para plataformas que lidam com muitas chaves e certificados, como emissores por API e ERPs multiempresa. Quem usa um serviço especializado geralmente delega essa proteção ao fornecedor. ## Termos relacionados - [HSM](https://conota.dev/glossario/hsm.md) - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) - [Geração de chave criptográfica](https://conota.dev/glossario/geracao-de-chave-criptografica.md) - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [Arquivo PFX](https://conota.dev/glossario/arquivo-pfx.md) - [Assinatura digital do XML](https://conota.dev/glossario/assinatura-digital-do-xml.md) --- Fonte: [KMIP no gerenciamento de chaves](https://conota.dev/glossario/kmip-no-gerenciamento-de-chaves/) · Atualizado em 2026-10-22 --- # Kubernetes na infraestrutura de APIs > Kubernetes na infraestrutura de APIs é o uso de uma plataforma de orquestração de contêineres para executar, escalar e manter disponíveis os serviços que compõem uma API. Ele distribui a carga, reinicia componentes com falha e permite atualizações sem interrupção, o que é útil para APIs fiscais que precisam operar continuamente. **Também conhecido como:** K8s, Kubernetes em APIs, Orquestração de contêineres em APIs, Kubernetes for API infrastructure **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é Kubernetes, em termos simples? Kubernetes é um sistema de código aberto que gerencia aplicações empacotadas em contêineres. Um contêiner é como uma caixa que leva o programa junto com tudo o que ele precisa para rodar, de forma igual em qualquer servidor. Em vez de alguém ligar e desligar servidores manualmente, o Kubernetes recebe uma descrição do estado desejado, por exemplo "quero sempre três cópias do serviço de emissão rodando", e trabalha sozinho para manter esse estado. ## Para que serve o Kubernetes em uma API? Uma API costuma ser formada por vários serviços: um que recebe as requisições, outro que valida dados, outro que processa filas, outro que gera arquivos. O Kubernetes coordena todos eles, decidindo onde cada um roda e quantas cópias são necessárias. Os principais benefícios são alta disponibilidade, escalabilidade automática quando o volume de chamadas cresce, recuperação automática de falhas e atualizações graduais, que trocam versões aos poucos sem derrubar o serviço. ## Como o Kubernetes ajuda em uma API fiscal? Emissão fiscal tem picos previsíveis e imprevisíveis: fechamento de mês, datas promocionais no varejo, grandes lotes de notas enviados por um ERP. Com Kubernetes, os serviços que processam a fila de emissão podem ganhar mais cópias nesses momentos e voltar ao tamanho normal depois. Ele também usa verificações de saúde, conhecidas como healthchecks, para detectar um componente travado e substituí-lo. Assim, uma falha isolada em um processo não impede que NF-e, NFC-e ou NFS-e continuem sendo enviadas para autorização. Informações sensíveis, como senhas e chaves usadas pela aplicação, podem ser entregues aos serviços por mecanismos próprios, como o Kubernetes Secret, em vez de ficarem gravadas no código. ## Quais são os principais componentes do Kubernetes? O pod é a menor unidade de execução e contém um ou mais contêineres. O deployment define quantas cópias de um pod devem existir e como atualizá-las. O service dá um endereço estável para acessar um conjunto de pods, distribuindo as requisições entre eles. Há ainda o namespace, que separa ambientes ou equipes dentro do mesmo cluster, e o ingress, que controla a entrada do tráfego externo, normalmente via HTTPS. O cluster é o conjunto de máquinas gerenciadas pelo Kubernetes. ## Quem integra uma API fiscal precisa conhecer Kubernetes? Não. O Kubernetes é um detalhe interno de quem opera a API. Para quem integra um ERP ou uma plataforma de vendas, o que importa é o contrato da API: endpoints, autenticação, formatos de resposta, limites de requisições e o comportamento em erros. Ainda assim, entender o conceito ajuda a interpretar situações como janelas de manutenção, respostas temporárias de indisponibilidade e a importância de implementar retry com backoff exponencial e idempotência do lado do cliente. ## Qual a diferença entre Kubernetes e Docker? Docker é uma tecnologia para criar e rodar contêineres individualmente. Kubernetes é a camada que orquestra muitos contêineres ao mesmo tempo, em várias máquinas. Em geral, as imagens construídas com ferramentas de contêiner são as que o Kubernetes executa. ## Exemplos de Kubernetes na infraestrutura de APIs - Durante o fechamento do mês, o número de pedidos de emissão de NF-e aumenta e o Kubernetes cria automaticamente mais cópias do serviço que consome a fila de emissão, reduzindo a latência. - Um processo responsável por consultar o status de documentos na SEFAZ para de responder ao healthcheck, e o Kubernetes o reinicia sem intervenção humana. - A equipe de engenharia publica uma nova versão do serviço de geração de DANFE com atualização gradual, substituindo os pods antigos aos poucos, sem interromper as chamadas dos clientes. - Os ambientes de homologação e de produção da API rodam em namespaces separados, com configurações e segredos distintos. ## Perguntas frequentes ### Kubernetes garante que a API nunca fique fora do ar? Não garante. Ele reduz o impacto de falhas de componentes e máquinas, mas indisponibilidades ainda podem ocorrer por erros de configuração, problemas de rede ou instabilidade em serviços externos, como os autorizadores fiscais. ### Preciso usar Kubernetes para me integrar a uma API fiscal? Não. A integração é feita por chamadas HTTP à API. Seu sistema pode rodar em qualquer infraestrutura, desde um servidor simples até um cluster próprio. ### Kubernetes resolve picos de emissão sozinho? Ajuda bastante com escalabilidade automática, mas depende de configuração adequada, filas bem desenhadas e limites definidos. Também não acelera o tempo de resposta dos órgãos autorizadores, como SEFAZ e prefeituras. ## Termos relacionados - [Kubernetes Secret](https://conota.dev/glossario/kubernetes-secret.md) - [Healthcheck de API](https://conota.dev/glossario/healthcheck-de-api.md) - [Observabilidade da API fiscal](https://conota.dev/glossario/observabilidade-da-api-fiscal.md) - [Fila de emissão fiscal](https://conota.dev/glossario/fila-de-emissao-fiscal.md) - [Janela de manutenção da API](https://conota.dev/glossario/janela-de-manutencao-da-api.md) - [Latência da API fiscal](https://conota.dev/glossario/latencia-da-api-fiscal.md) --- Fonte: [Kubernetes na infraestrutura de APIs](https://conota.dev/glossario/kubernetes-na-infraestrutura-de-apis/) · Atualizado em 2026-10-22 --- # Kubernetes Secret > Kubernetes Secret é um objeto do Kubernetes usado para guardar informações sensíveis, como senhas, tokens, chaves de API e certificados digitais, separadas do código da aplicação. Ele permite que os programas em execução no cluster acessem esses dados quando precisam, com controle de quem pode lê-los, sem deixá-los expostos em arquivos de configuração comuns. **Também conhecido como:** Secret do Kubernetes, Segredo do Kubernetes, K8s Secret, Kubernetes Secret **Glossário:** [Glossário de A a Z](https://conota.dev/glossario/) · **Letra:** K ## O que é um Kubernetes Secret, em termos simples? O Kubernetes é uma plataforma que organiza e executa aplicações em contêineres, muito usada para manter APIs e sistemas no ar. Dentro dele, um Secret funciona como um cofre pequeno: um lugar específico para guardar dados que não devem aparecer no código-fonte nem em arquivos de configuração compartilhados. Em vez de escrever a senha do banco de dados ou a chave de uma API fiscal diretamente no programa, a equipe cadastra essa informação em um Secret. A aplicação recebe o valor apenas no momento em que roda, e quem lê o código não tem acesso ao conteúdo sensível. ## Como funciona um Kubernetes Secret? O Secret é criado no cluster com um nome e um conjunto de pares chave e valor, por exemplo, uma chave chamada API_KEY com o token correspondente. Os valores ficam armazenados no banco de dados interno do Kubernetes, chamado etcd. Para usar o Secret, a aplicação pode recebê-lo de duas formas principais: como variável de ambiente, que o programa lê ao iniciar, ou como arquivo montado em uma pasta dentro do contêiner. A segunda opção é comum para arquivos inteiros, como um certificado digital. O acesso é controlado por permissões do próprio Kubernetes, conhecidas como RBAC. Assim, é possível definir que apenas determinada aplicação ou equipe consiga ler um Secret específico, dentro de um namespace específico. ## Para que serve um Kubernetes Secret em uma integração fiscal? Sistemas que emitem documentos fiscais lidam com credenciais muito sensíveis. Um ERP que se conecta a uma API fiscal precisa guardar a API Key ou o token de autenticação; quem assina documentos diretamente precisa do certificado digital A1 e de sua senha; quem emite NFC-e lida com o CSC. Todos esses dados são bons candidatos a ficar em um Secret. Com isso, o mesmo código pode rodar em ambiente de homologação e em ambiente de produção, mudando apenas o Secret usado em cada um. Também fica mais simples trocar uma credencial expirada ou comprometida sem precisar alterar e publicar uma nova versão da aplicação. ## Kubernetes Secret é seguro por padrão? Não totalmente. Por padrão, os valores de um Secret são apenas codificados em Base64, o que não é criptografia: qualquer pessoa com acesso ao conteúdo consegue decodificá-lo facilmente. A proteção real depende de como o cluster é configurado. Boas práticas incluem ativar a criptografia em repouso dos Secrets no etcd, restringir permissões de leitura ao mínimo necessário, evitar salvar os arquivos de definição dos Secrets em repositórios de código e fazer rotação periódica das credenciais. Muitas equipes também integram o Kubernetes a um key vault ou serviço de gerenciamento de chaves externo para reforçar a segurança. ## Qual a diferença entre Kubernetes Secret, ConfigMap e key vault? O ConfigMap também guarda configurações no Kubernetes, mas é pensado para dados não sensíveis, como a URL de um endpoint ou o fuso horário usado na emissão. Já o Secret é destinado a dados confidenciais e recebe tratamento diferenciado de acesso. Um key vault, por sua vez, é um serviço dedicado ao gerenciamento de segredos, geralmente com recursos mais avançados, como criptografia forte, auditoria detalhada e rotação automática. É comum usar os dois juntos: o key vault guarda a fonte oficial do segredo e o Kubernetes Secret entrega o valor à aplicação. ## Exemplos de Kubernetes Secret - Um ERP hospedado em Kubernetes guarda a API Key de produção da API fiscal em um Secret chamado credenciais-fiscais e a lê como variável de ambiente ao iniciar o serviço de emissão. - Uma plataforma de vendas monta o arquivo do certificado digital A1 e sua senha a partir de um Secret em uma pasta do contêiner, usada pelo módulo que assina os XMLs. - Uma software house mantém Secrets separados para homologação e produção, garantindo que testes nunca usem por engano a credencial real de emissão. - Após a renovação do certificado digital de um cliente, a equipe atualiza apenas o Secret correspondente e reinicia os pods, sem alterar o código. ## Perguntas frequentes ### Base64 em um Kubernetes Secret protege os dados? Não. Base64 é apenas uma forma de codificação, facilmente revertida. A proteção vem da criptografia em repouso no cluster, de permissões de acesso bem definidas e, se possível, da integração com um key vault. ### Posso guardar um certificado digital A1 em um Kubernetes Secret? Sim. O arquivo do certificado e sua senha podem ser armazenados em um Secret e montados como arquivo no contêiner. É importante restringir quem pode ler esse Secret e controlar a data de vencimento do certificado. ### Existe limite de tamanho para um Kubernetes Secret? Sim. Cada Secret é limitado a cerca de 1 MiB. Isso é suficiente para tokens, senhas e certificados, mas não para arquivos grandes. ### Devo salvar o arquivo do Secret no repositório de código? Não é recomendado, porque qualquer pessoa com acesso ao repositório veria as credenciais. Prefira ferramentas que cifram o Secret antes de versioná-lo ou que o buscam de um gerenciador de segredos externo. ## Termos relacionados - [Kubernetes na infraestrutura de APIs](https://conota.dev/glossario/kubernetes-na-infraestrutura-de-apis.md) - [Gerenciamento de segredos](https://conota.dev/glossario/gerenciamento-de-segredos.md) - [Key vault](https://conota.dev/glossario/key-vault.md) - [Certificado digital A1](https://conota.dev/glossario/certificado-digital-a1.md) - [API Key](https://conota.dev/glossario/api-key.md) - [Key rotation](https://conota.dev/glossario/key-rotation.md) --- Fonte: [Kubernetes Secret](https://conota.dev/glossario/kubernetes-secret/) · Atualizado em 2026-10-22