Funcionamento, riscos, armazenamento, rotação e uso controlado de credenciais estáticas em APIs corporativas
Edição aprofundada - material de estudo e consulta profissional
Por João Ricardo Dutra••Material integral
Três mecanismos de credencial com propriedades muito diferentes
Figura de abertura - Basic, e parecem simples, mas exigem gestão completa de credenciais.
Princípio central
Todos dependem de , gestão de segredo, menor privilégio, rotação e observabilidade para uso seguro.
Edição aprofundada - material de estudo e consulta profissional
Apresentação do capítulo
O capítulo anterior separou autenticação e autorização e mostrou que uma identidade só se torna útil quando existe uma prova, um principal e uma decisão de acesso. Agora o curso aprofunda três mecanismos historicamente importantes e ainda encontrados em corporativas: Basic, e . Eles aparecem em integrações legadas, automações, produtos SaaS, , appliances e sistemas internos que precisam de onboarding simples.
A simplicidade operacional é a principal razão de sua permanência, mas também cria armadilhas. envia uma credencial reutilizável em todas as chamadas e depende totalmente de para confidencialidade. evita transmitir a senha diretamente e utiliza desafio-resposta, porém continua sensível a senhas fracas, mal controlado e limitações de interoperabilidade. identificam aplicações e planos de consumo, mas frequentemente são tratadas como se fossem identidade forte de usuário ou como autorização suficiente para qualquer operação.
Os três mecanismos são credenciais estáticas ou de longa duração quando comparados a curtos. Por isso, segurança não pode se limitar ao formato do . É necessário considerar geração, armazenamento, exposição em , rotação, revogação, escopo, quotas, segregação por ambiente, auditoria e resposta a incidentes. Uma chave forte vazada continua sendo uma credencial válida até que a plataforma a detecte e revogue.
Este capítulo apresenta o de autenticação, o fluxo detalhado de Basic e , a arquitetura de gestão de e a aplicação em . O objetivo é permitir que o leitor reconheça quando esses mecanismos são aceitáveis, quais controles compensatórios são indispensáveis e quando a migração para 2.0, ou identidades de workload deve ser priorizada.
Como estudar este capítulo
Para cada mecanismo, acompanhe a credencial desde a emissão até a revogação. Pergunte onde o segredo existe em claro, quem consegue reutilizá-lo, como o identifica o consumidor, como o recebe contexto e quanto tempo uma exposição permaneceria válida.
Objetivos de aprendizagem
Explicar o de desafios e o papel de 401, e Authorization.
Descrever a codificação de e diferenciar de criptografia.
Analisar riscos de exposição, , compartilhamento e armazenamento de senhas.
Compreender o desafio-resposta do e seus principais parâmetros.
Explicar , , , , , , algorithm e .
Reconhecer limitações práticas e de segurança do em modernas.
Distinguir de identidade de usuário, e assinatura .
Projetar geração, armazenamento, escopo, quota, rotação e revogação de chaves.
Aplicar validação de credenciais em sem propagar segredos ao .
Planejar migração de credenciais estáticas para mecanismos de curta duração ou prova de posse.
Estrutura do capítulo
15.1 Credenciais estáticas no contexto de
15.2 de autenticação
15.3 : formato e fluxo
15.4 não é criptografia
15.5 sobre e intermediários
15.6 Armazenamento de senhas e validação
15.7 Hardening e migração de Basic
15.8 : motivação e desafio-resposta
15.9 Parâmetros e cálculo do
15.10 , , e limitações
15.11 : finalidade e modelo de ameaça
15.12 Geração, formato e distribuição
15.13 Armazenamento, lookup e metadata
15.14 Escopos, quotas e autorização
15.15 Rotação, revogação e detecção de vazamento
15.16 signing e mecanismos relacionados
15.17 Uso em
15.18 Comparação, e estudos de caso
Resumo, checklist, exercícios, glossário e referências
15.1 Credenciais estáticas no contexto de
Uma credencial estática é um valor que permanece válido por um período relativamente longo e pode ser reutilizado em múltiplas chamadas. Senhas e se encaixam nessa categoria. O problema não é apenas duração: como o mesmo valor prova acesso repetidamente, qualquer cópia obtida por , repositório, estação comprometida, ou vazamento de configuração pode ser usada até expiração ou revogação.
Credenciais estáticas oferecem implantação simples. Um consumidor recebe um usuário e senha ou uma chave, adiciona um e chama a . Não há servidor de autorização, fluxo de obtenção de ou renovação. Essa simplicidade pode ser adequada em laboratórios, integrações restritas e sistemas legados, mas transfere responsabilidade para processos operacionais que muitas equipes negligenciam.
Em uma arquitetura segura, cada credencial possui identidade individual, owner, ambiente, finalidade, escopo, data de criação, expiração, último uso, status e histórico de rotação. Compartilhar a mesma credencial entre vários sistemas destrói rastreabilidade e torna a revogação coordenada. O princípio fundamental é que simplicidade de protocolo não pode significar ausência de governança.
Tabela 1 - Credencial estática segura depende de ciclo de vida explícito.
Propriedade
Pergunta operacional
Risco se ausente
Individualização
Qual aplicação ou pessoa controla a credencial?
Impossibilidade de atribuir tráfego e incidente.
Escopo
Quais APIs e operações podem ser usadas?
Comprometimento amplia acesso lateral.
Expiração
Quando o valor deixa de ser aceito?
Segredo abandonado permanece ativo.
Rotação
Como trocar sem indisponibilidade?
Credencial nunca é renovada.
Revogação
Quanto tempo para bloquear um vazamento?
Janela longa de abuso.
15.2 de autenticação
O define um geral de autenticação baseado em desafios. Quando um recurso exige autenticação e o cliente não apresenta credencial aceitável, o servidor pode responder 401 Unauthorized acompanhado de um ou mais . Cada desafio informa o esquema e parâmetros necessários, como . O cliente escolhe um esquema suportado e repete a requisição com Authorization.
O nome 401 Unauthorized é historicamente confuso: na prática, representa ausência ou falha de autenticação. Depois que a identidade é autenticada, uma negativa por falta de permissão normalmente usa 403 Forbidden. Essa separação preserva semântica, facilita e evita que consumidores tentem trocar credenciais quando o problema real é autorização.
Um pode anunciar mais de um desafio ou ocultar detalhes para reduzir enumeração. Em , também é comum receber credenciais preemptivamente, sem o primeiro 401. Mesmo assim, compreender o modelo de desafio é essencial para Basic e , além de ajudar na interpretação de , clientes e bibliotecas.
Figura 1 - Basic e utilizam o de desafio definido pelo .
Basic utiliza um identificador de usuário e uma senha combinados na forma user-id:password. A sequência de bytes resultante é codificada em e enviada no Authorization com o prefixo Basic. O servidor decodifica o valor, localiza a conta e verifica a senha. Em integrações máquina a máquina, o user-id pode representar uma aplicação ou conta técnica, mas isso não transforma automaticamente o mecanismo em identidade forte de workload.
O cliente pode esperar um desafio 401 ou enviar o na primeira chamada. Muitos SDKs e ferramentas escondem esse detalhe. Em ambos os casos, a credencial é transmitida em todas as requisições, inclusive quando conexões diferentes são abertas. Isso aumenta a superfície de exposição em comparação com uma senha usada apenas para obter um de curta duração.
O permite ao servidor indicar o espaço de proteção. Clientes podem usar essa informação para decidir quais credenciais reenviar. Em ambientes com múltiplos hosts, redirecionamentos e , a configuração precisa impedir que o Authorization seja encaminhado para destino não confiável.
Exemplo conceitual de
# Texto lógico antes da codificação
integracao-faturamento:SenhaDeExemplo
# Header HTTP
Authorization: Basic aW50ZWdyYWNhby1mYXR1cmFtZW50bzpTZW5oYURlRXhlbXBsbw==
15.4 não é criptografia
é uma codificação para representar bytes em caracteres seguros para transporte textual. Não utiliza chave, não oferece confidencialidade e pode ser revertida por qualquer pessoa ou ferramenta. Tratar o valor como ou criptografia é um erro grave. Ele protege apenas contra problemas de representação, não contra observação do tráfego.
Por essa razão, só deve ser usado sobre corretamente validado. Sem , usuário e senha ficam expostos a quem captura a comunicação. Mesmo com , a credencial pode aparecer em de debug, dumps de memória, ferramentas de observabilidade, histórico de comandos, variáveis de ambiente e configurações. O canal protegido não corrige vazamento nos ou intermediários terminadores.
A codificação também não impede . Se um atacante obtém o completo, pode reutilizá-lo enquanto a senha continuar válida. A proteção depende de segredo forte, rotação, detecção de anomalia, limitação de tentativas e menor privilégio.
Figura 2 - O único elemento que protege a confidencialidade do no trânsito é o canal .
Regra operacional
Nunca coloque em , , , tickets ou exemplos com credenciais reais. Redações visuais em screenshots não removem o valor de arquivos de configuração ou históricos de terminal.
15.5 sobre e intermediários
Quando existe reverso ou , pode terminar antes do . O trecho cliente- e o trecho - são conexões independentes. Se o repassa o Authorization original ao , a senha continua circulando internamente e pode aparecer em mais pontos de observação. Uma arquitetura melhor valida a credencial na borda e encaminha identidade interna restrita ou de curta duração.
Redirecionamentos também merecem atenção. Clientes seguros evitam encaminhar Authorization para outro host, mas comportamentos variam conforme biblioteca e configuração. Um autenticado não deve responder com redirecionamento para domínio não confiável. Regras de precisam remover externos de identidade antes de inserir contexto validado.
O servidor deve aplicar proteção contra brute force e . por conta, origem e dispositivo, bloqueio progressivo, detecção de senha vazada, monitoramento e alertas ajudam. Bloqueio permanente após poucas tentativas pode causar negação de serviço; a política precisa equilibrar segurança e disponibilidade.
15.6 Armazenamento de senhas e validação
O servidor não deve armazenar senha reversível apenas para comparar com o valor recebido. Senhas de usuários humanos precisam ser protegidas por funções específicas de derivação, com individual e parâmetros de custo adequados. A verificação calcula novamente o derivado e compara em tempo constante. Contas técnicas podem ser migradas para chaves, certificados ou identidades de workload, evitando tratar segredo de aplicação como senha humana.
Basic exige que o servidor obtenha a senha apresentada em cada chamada e a valide. Isso não significa que a senha precise existir em claro no banco. Entretanto, alguns sistemas legados delegam autenticação a diretórios ou armazenam credenciais reversíveis para integração. Esses casos aumentam impacto de comprometimento e devem ter plano de migração.
de autenticação devem registrar identificador, resultado, motivo categorizado, origem, correlação e policy aplicada, mas nunca a senha ou o Authorization. Mensagens ao cliente devem evitar diferenciar usuário inexistente de senha incorreta quando isso permitir enumeração.
Tabela 2 - Armazenamento seguro reduz impacto de vazamento do repositório de credenciais.
Elemento
Prática recomendada
Evitar
Banco de senhas
Salt individual e função de derivação apropriada.
Senha em claro ou criptografia reversível sem necessidade.
Comparação
Rotina constante e biblioteca consolidada.
Comparações caseiras e logs de valores.
Conta técnica
Identidade individual e owner.
Usuário compartilhado por vários jobs.
Observabilidade
Resultado, origem e correlação.
Authorization e senha em log.
15.7 Hardening e migração de
Basic pode ser tolerado em integração controlada quando é obrigatório, a conta é individual, a senha é aleatória e longa, o acesso é limitado e existe rotação. Também deve haver plano de substituição. O mecanismo é inadequado para credenciais humanas em de alto risco ou para aplicações distribuídas que não conseguem proteger segredo estático.
Uma migração comum introduz 2.0 Client Credentials, ou identidade gerenciada. Durante a coexistência, o aceita Basic apenas para consumidores cadastrados, registra uso por client_id e comunica prazo de retirada. O novo mecanismo é ativado paralelamente; depois que a telemetria confirma migração, a senha antiga é revogada.
Não basta trocar Basic por um de longa duração copiado em configuração. O objetivo é reduzir reutilização e superfície: curtos, audience específica, escopo mínimo, emissão auditável e credencial de cliente protegida por vault ou prova assimétrica.
Critério de migração
Priorize consumidores com credenciais compartilhadas, ausência de rotação, acesso privilegiado, execução em dispositivos não confiáveis ou exposição pública. Esses fatores aumentam impacto e probabilidade de comprometimento.
15.8 : motivação e desafio-resposta
foi criado para evitar que a senha fosse enviada diretamente ao servidor em cada requisição. O servidor envia um desafio com , , algoritmo e opções de qualidade de proteção. O cliente combina esses valores com usuário, senha, método e para calcular uma resposta . O servidor realiza cálculo equivalente e compara o resultado.
O é um valor emitido pelo servidor para limitar reutilização. O cliente também pode enviar e contador . Com =auth, método e entram na prova, vinculando a resposta à requisição. Em =auth-int, o corpo da entidade também participa, embora o suporte operacional seja mais complexo.
melhora uma propriedade específica em relação ao Basic: a senha não aparece diretamente no wire. Porém, ele não substitui . Metadados e conteúdo continuam expostos sem criptografia do canal, e ataques de , manipulação ou captura para tentativa offline ainda precisam ser considerados.
Figura 3 - O cliente prova conhecimento de um segredo sem enviar a senha diretamente.
15.9 Parâmetros e cálculo do
O separa espaços de proteção e participa do cálculo. O é gerado pelo servidor; é um valor que o cliente devolve sem interpretar. algorithm informa a função de e possíveis variantes com -sess. seleciona a qualidade de proteção. é o contador de uso do , e é um valor aleatório produzido pelo cliente.
Em uma forma simplificada com =auth, calcula-se a partir de usuário, e senha; a partir do método e -target; e a partir de , , , , e . A implementação deve seguir rigorosamente a especificação e usar bibliotecas testadas. Pequenas diferenças de codificação, , charset ou parâmetros produzem falhas difíceis de diagnosticar.
Algoritmos e parâmetros precisam ser negociados de forma segura. Implementações não devem aceitar silencioso para opções fracas quando a política exige algoritmos mais fortes. Também é importante validar que o cliente responde ao mesmo , e associados ao desafio.
Tabela 3 - Parâmetros de Digest precisam ser validados como um conjunto coerente.
Parâmetro
Origem
Função
realm
Servidor
Define o espaço de proteção e participa do cálculo.
nonce
Servidor
Torna a prova dependente de um desafio e de validade temporal.
opaque
Servidor
Estado opaco devolvido pelo cliente.
qop
Servidor/cliente
Seleciona auth ou outra qualidade suportada.
cnonce
Cliente
Adiciona aleatoriedade controlada pelo cliente.
nc
Cliente
Conta usos do nonce e ajuda a detectar replay.
response
Cliente
Prova hash calculada para a requisição.
15.10 , , e limitações do
Um seguro precisa ser imprevisível ou autenticado, possuir janela de validade e estar vinculado ao contexto necessário. O servidor pode manter estado ou codificar timestamp e MAC no valor. Quando o expira, o desafio pode indicar =true, permitindo ao cliente repetir a operação com novo sem assumir que usuário ou senha estão errados.
O contador deve crescer para cada uso do mesmo e . O servidor pode detectar repetição, mas isso exige estado ou lógica de janela. e distribuídos precisam compartilhar ou validar consistentemente essas informações. Uma implementação que apenas verifica o e ignora contador e validade perde parte importante da proteção contra .
continua sujeito a ataques offline quando um atacante captura desafio e resposta e a senha possui baixa entropia. Ele também não oferece confidencialidade do , não resolve autorização, não substitui e possui interoperabilidade desigual em clientes, e . Em modernas, costuma ser mantido por compatibilidade, não como primeira escolha para novos projetos.
Limite de segurança
protege a senha no trânsito de forma diferente de Basic, mas não transforma senha fraca em credencial forte. A captura de uma resposta pode permitir testar candidatos offline sem interagir novamente com o servidor.
15.11 : finalidade e modelo de ameaça
é um valor atribuído a um consumidor, aplicação, projeto ou assinatura de produto. Ela permite identificar quem está usando a , aplicar quotas, , cobrança, analytics e políticas. Em alguns ambientes também é usada como autenticação de aplicação. Porém, a posse da chave não prova identidade humana nem estabelece, por si só, autorização de negócio.
Uma chave é normalmente : quem conhece o valor pode utilizá-lo. Portanto, não deve ser embutida em JavaScript público, aplicativo móvel distribuído, repositório ou firmware facilmente extraível quando o acesso associado é sensível. Em clientes públicos, a chave pode servir apenas como identificador de produto, sem ser tratada como segredo forte.
O modelo de ameaça inclui vazamento em , query strings, ferramentas de analytics, histórico de navegador, referrer, , , notebooks, mensagens e suporte. Também inclui compartilhamento intencional entre equipes, cópia para ambiente errado e permanência após desligamento do owner.
15.12 Geração, formato e distribuição de
Uma deve ser gerada com fonte criptograficamente segura e entropia suficiente para impedir adivinhação. Formatos legíveis podem incluir prefixo não secreto que identifique produto ou ambiente, seguido de material aleatório. O prefixo facilita roteamento, suporte e detecção de chave de teste usada em produção sem revelar o segredo completo.
A chave deve ser exibida ao consumidor somente no momento de criação ou por canal seguro. Depois, a plataforma armazena uma representação protegida. E-mail, planilha e ticket não são cofres. Aplicações devem receber o valor por , protegido ou mecanismo de bootstrap, e nunca por commit em código.
Chaves de produção, homologação e desenvolvimento precisam ser diferentes. A segregação reduz propagação de vazamentos e permite políticas distintas. A plataforma também pode limitar origem de rede, certificado, host, ou operação, mas esses controles complementam e não substituem a proteção da chave.
Figura 4 - A emissão é apenas o início do ciclo de vida de uma .
15.13 Armazenamento, lookup e metadata
Quando a chave funciona apenas como , o servidor não precisa armazenar o valor em claro. Pode armazenar ou MAC e comparar a apresentação. Para lookup eficiente, formatos com identificador público e segredo separado são úteis: o prefixo localiza o registro e o segredo é validado de forma segura. Isso evita varrer toda a base de a cada requisição.
O registro da chave deve conter owner, aplicação, produto, ambiente, , quotas, estado, criação, expiração, última rotação, último uso e razão de revogação. A metadata permite decisões sem expor o segredo. Também sustenta inventário, relatórios de chaves órfãs e campanhas de rotação.
Se a plataforma precisa recuperar o valor para assinar solicitações em nome do consumidor, a chave deixa de ser apenas verificadora e exige armazenamento reversível em vault ou , com controles de acesso e auditoria mais fortes. Esse caso deve ser distinguido de uma chave usada somente para autenticar chamadas de entrada.
Tabela 4 - Separar identificador, segredo, verificador e metadata melhora operação e resposta a incidentes.
Componente
Conteúdo
Exposição
key id / prefixo _
Identificador público para lookup.
Pode aparecer em logs e portais.
secret
Material aleatório apresentado na chamada.
Só consumidor e processo de validação.
verifier
Hash ou MAC do secret.
Banco protegido; não permite uso direto.
metadata
Owner, escopo, quota, status e datas.
Serviços de gestão e política.
15.14 Transmissão, escopos, quotas e autorização
devem ser transmitidas preferencialmente em dedicado ou Authorization com esquema definido pela plataforma. Colocá-las em aumenta vazamento em access , histórico, analytics, e Referer. permanece obrigatório porque uma chave capturada pode ser reutilizada.
Cada chave deve ter escopo mínimo: produto, , operações, ambiente e, quando possível, dados ou tenant específicos. Quota e limitam consumo e reduzem impacto de abuso, mas não são equivalentes a autorização. Uma chave com quota de mil chamadas ainda pode acessar objeto indevido se o não validar ownership.
Para operações em nome de usuário, a pode identificar a aplicação enquanto outro mecanismo autentica o usuário. Essa separação permite atribuir tráfego a dois sujeitos: cliente técnico e usuário final. O deve preservar ambos no contexto e nos sem confundi-los.
Formas de transmissão de
# Header dedicado
X-API-Key: pk_live_7F2A...segredo...
# Ou esquema de Authorization definido pelo provedor
Authorization: ApiKey pk_live_7F2A...segredo...
# Evitar
GET /v1/clientes?api_key=pk_live_7F2A...
15.15 Rotação, revogação e detecção de vazamento
Rotação sem indisponibilidade normalmente exige período de sobreposição. O consumidor cria ou recebe uma segunda chave, atualiza suas aplicações, valida tráfego com o novo valor e só então revoga a antiga. Plataformas podem permitir duas chaves ativas por assinatura. O prazo de coexistência deve ser curto e monitorado para evitar duplicação permanente.
Revogação precisa ser rápida e global. de devem respeitar status e compatíveis com o risco. Em incidentes, a equipe precisa localizar todos os ambientes e dependências que usam a chave. Isso só é possível quando cada consumidor tem credencial própria e inventário confiável.
Detecção de vazamento pode usar scanners de repositório, padrões de prefixo, monitoramento de origem, aumento súbito de volume, mudança geográfica e uso fora do horário. Honeytokens ou chaves deliberadamente não utilizadas podem gerar alerta imediato quando aparecem no tráfego.
Tabela 5 - A resposta depende de inventário, individualização e capacidade de revogação.
Evento
Ação imediata
Ação posterior
Suspeita de vazamento
Desabilitar ou reduzir privilégio; preservar evidências.
Investigar origem e emitir nova chave.
Rotação planejada
Ativar nova chave em paralelo.
Confirmar uso e revogar antiga.
Owner desligado
Suspender credenciais associadas.
Reatribuir ou remover integração.
Chave sem uso
Confirmar com owner e bloquear em teste.
Eliminar ativo órfão.
15.16 signing e mecanismos relacionados
Assinatura de requisições é diferente de simplesmente enviar uma . O cliente usa um segredo para calcular uma assinatura sobre método, caminho, timestamp, e do corpo. O servidor recalcula e compara. A chave pode identificar o consumidor, enquanto a assinatura vincula a prova a uma requisição específica e reduz quando timestamp e são validados.
Esse modelo é usado por algumas financeiras e de nuvem, mas exige canonicalização rigorosa. Diferenças de encoding, ordem de , normalização de caminho e corpo produzem falhas. A segurança depende de segredo forte, janela temporal curta, comparação segura, proteção do relógio e prevenção de reutilização.
não substitui : sem , conteúdo e metadata continuam visíveis e podem ser manipulados antes da verificação. Também não fornece não repúdio, porque cliente e servidor compartilham o mesmo segredo. Assinaturas assimétricas ou podem ser mais adequadas quando separação de responsabilidade e prova de posse são importantes.
Distinção importante
Uma é normalmente apresentada diretamente. Em signing, o segredo não trafega; ele produz uma assinatura específica para a requisição. Os dois modelos exigem ciclos de vida e controles diferentes.
15.17 Uso em , Axway e Azure
O é um ponto natural para validar Basic, ou , aplicar , registrar consumo e bloquear credenciais revogadas. A política deve ocorrer antes do roteamento ao e precisa distinguir falha de autenticação, chave suspensa, quota excedida e ausência de autorização. O também deve remover credenciais originais antes de encaminhar a requisição, sempre que o não precisar delas.
Em produtos corporativos, a chave pode estar associada a aplicação, contrato, produto ou subscription. O consulta repositório local, ou serviço de gestão. melhoram desempenho, mas tornam revogação dependente de propagação. Para credenciais críticas, o precisa ser curto ou a plataforma deve oferecer invalidação ativa.
A integração com Axway , Azure Management e outros produtos deve ser validada conforme a versão implantada. Policies podem extrair , validar subscription keys, consultar vaults, aplicar quotas e transformar contexto. O desenho precisa impedir bypass direto ao e garantir que de identidade inseridos pelo não possam ser forjados externamente.
Figura 5 - O valida a credencial e encaminha contexto confiável, não o segredo original.
15.18 Comparação entre Basic, e
Os três mecanismos compartilham simplicidade e ausência de fluxo complexo de emissão de , mas resolvem problemas diferentes. Basic transporta usuário e senha. cria prova baseada na senha e em um desafio. identifica uma aplicação ou assinatura com um valor aleatório. Nenhum deles, isoladamente, fornece autorização fina, identidade federada ou consentimento delegado.
A escolha deve considerar onde a credencial pode ser protegida, quem é o sujeito, duração, necessidade de rotação e suporte dos clientes. Para novos serviços de alto risco, credenciais curtas, , 2.0 ou identidades de workload tendem a oferecer propriedades melhores. Basic, e keys continuam úteis quando aplicados com escopo limitado e controles compensatórios claros.
Tabela 6 - Nenhum mecanismo elimina a necessidade de TLS, escopo, rotação e autorização.
Critério
Basic Auth
Digest
API Key
Segredo trafega diretamente
Sim, dentro de Base64 e TLS.
Não como senha, mas há prova reutilizável no contexto.
Sim, normalmente como bearer.
Dependência de TLS
Total.
Continua necessária.
Total.
Sujeito típico
Usuário ou conta técnica.
Usuário ou conta técnica.
Aplicação, projeto ou assinatura.
Replay após captura
Possível enquanto senha for válida.
Mitigado por nonce/nc quando correto.
Possível enquanto chave for válida.
Operação
Simples, mas senha precisa de proteção.
Mais complexa e menos interoperável.
Simples, exige ciclo de vida robusto.
Uso recomendado
Legado controlado e temporário.
Compatibilidade específica.
Identificação e controle de aplicações.
15.19 orientado por evidências
Quando Basic falha, confirme se o chegou ao ponto correto, se foi produzido a partir do charset esperado, se a senha contém caracteres especiais e se ou redirecionamento removeu Authorization. Diferencie 401 por credencial inválida de 403 por falta de permissão e de 429 por quota.
Em , compare , , , algorithm, e método usados no cálculo. Verifique sincronização entre nós, validade do , contador e canonicalização do -target. Falhas intermitentes em frequentemente indicam estado de não compartilhado ou chaves diferentes para autenticar o desafio.
Em , investigue nome do , ambiente, prefixo, status, expiração, escopos, quota e de revogação. Uma chave válida no portal pode falhar no runtime se produto, subscription ou estiverem inconsistentes. Sempre correlacione do , serviço de gestão e .
Tabela 7 - Diagnóstico exige identificar o ponto que produziu a resposta.
Sintoma
Hipóteses
Evidências
Basic retorna 401
senha alterada, Base64 incorreto, realm ou header removido
header mascarado, conta, nó e logs de autenticação.
Digest falha após um tempo
nonce expirado, nc repetido ou stale não tratado
desafio, timestamp, contador e nó do cluster.
API Key funciona em homologação
chave ou produto do ambiente errado
prefixo, metadata, deployment e subscription.
Revogada ainda funciona
cache ou backend acessível diretamente
TTL, invalidação e rota de bypass.
429 inesperado
quota compartilhada ou chave reutilizada
owner, contadores e consumidores por chave.
15.20 Estudos de caso e laboratórios
Caso 1 - senha compartilhada por dez integrações
Dez jobs usam o mesmo usuário Basic. Um segredo aparece em um repositório e a organização não consegue atribuir o uso. A resposta cria contas individuais, restringe escopos, migra para credenciais de aplicação e revoga o usuário compartilhado após telemetria confirmar a transição.
O caso mostra que o maior problema não era , mas ausência de individualização e rotação. Mesmo sobre , o vazamento tinha impacto amplo e baixa rastreabilidade.
Caso 2 - intermitente em
Dois nós emitem com chaves diferentes e o balanceador distribui chamadas sem afinidade. O cliente recebe desafio de um nó e envia a prova ao outro, que rejeita o . A correção compartilha a chave de autenticação do ou usa validação consistente entre nós.
Capturas e mostram 401 sucessivos com diferentes. O erro parecia senha incorreta, mas a causa estava no estado distribuído do mecanismo.
Caso 3 - exposta em
Uma integração envia a chave em query. O valor aparece em de e ferramenta de analytics. A equipe revoga a chave, remove parâmetros dos , muda a transmissão para , adiciona scanners e revisa todos os consumidores.
A investigação também identifica que a mesma chave era usada em produção e teste. A segregação por ambiente reduz o impacto de futuros vazamentos.
Laboratórios sugeridos
Codifique e decodifique um valor Basic de laboratório e observe que é reversível.
Configure um servidor local autorizado com desafio Basic e inspecione 401, e Authorization.
Simule o cálculo de com controlado e altere método ou para verificar a falha.
Modele uma com prefixo público, secret aleatório e armazenado.
Implemente rotação com duas chaves ativas e confirme a revogação da antiga.
Compare de uma chave em e em , usando somente valores fictícios.
Resumo do capítulo
codifica usuário e senha em e envia a credencial em cada chamada. não protege o segredo; , armazenamento adequado, individualização, rotação e limitação de tentativas são indispensáveis. Em , a credencial deve ser validada na borda e removida antes do quando possível.
usa desafio-resposta com , , algoritmo, , e contador. Ele evita transmitir a senha diretamente, mas depende de implementação rigorosa, senha forte, controle de e . Sua complexidade e interoperabilidade fazem com que seja adotado principalmente por compatibilidade.
identificam aplicações, projetos ou assinaturas e suportam quotas e analytics. Como normalmente são , precisam de alta entropia, transmissão em , armazenamento protegido, metadata, escopo, rotação e revogação rápida. Não substituem identidade de usuário nem autorização por recurso.
Mecanismos estáticos devem ser avaliados pelo ciclo de vida completo. Para novos casos de alto risco, curtos, , 2.0 e identidades de workload oferecem propriedades superiores. A migração deve ser baseada em telemetria e coexistência controlada.
Próximo passo do curso
O Capítulo 16 aprofundará 2.0 completo: papéis, grants, authorization code com , client credentials, , , segurança e aplicação em .
Checklist de credenciais estáticas
Basic, e são aceitos somente sobre corretamente validado.
Cada consumidor possui credencial individual, owner e ambiente definidos.
Segredos não aparecem em , , código-fonte, tickets ou analytics.
Senhas são protegidas por mecanismo de armazenamento apropriado e nunca registradas.
possuem validade, integridade e controle de .
Algoritmos e do seguem política explícita e não sofrem silencioso.
possuem entropia suficiente, prefixo seguro e distribuição por canal protegido.
Verifiers e metadata são separados do segredo apresentado.
Escopos, quotas e rate limits não substituem autorização de objeto e domínio.
Rotação permite sobreposição curta e revogação confirmada por telemetria.
de respeitam revogação e não criam janela excessiva.
O não é acessível diretamente para contornar a política do .
Alertas detectam uso anômalo, origem inesperada e chaves órfãs.
Existe plano de migração para credenciais curtas ou assimétricas quando o risco exige.
Exercícios
Explique por que não protege .
Descreva o fluxo 401, e Authorization.
Liste riscos de compartilhar um usuário Basic entre aplicações.
Explique a função de , , , e no .
Descreva como =true altera o comportamento do cliente.
Explique por que ainda precisa de .
Diferencie , e identidade de usuário.
Proponha um formato com key_id público e secret aleatório.
Descreva armazenamento com e metadata.
Crie um plano de rotação sem indisponibilidade.
Compare direta e assinatura de requisição.
Descreva para chave revogada que ainda funciona no .
Glossário
Tabela 8 - Vocabulário essencial do capítulo.
Termo
Definição
API Key
Valor associado a aplicação, projeto, produto ou assinatura de API.
Base64
Codificação reversível de bytes para caracteres textuais.
Basic Auth
Esquema HTTP que transmite user-id e senha codificados em Base64.
cnonce
Nonce criado pelo cliente em HTTP Digest.
Credential stuffing
Uso automatizado de credenciais obtidas em vazamentos anteriores.
Digest
Esquema HTTP de desafio-resposta baseado em hash.
HA1
Valor derivado de usuário, realm e senha no Digest.
HA2
Valor derivado de método e request-target no Digest.
HMAC
Código de autenticação de mensagem baseado em hash e segredo compartilhado.
key id _
Identificador público usado para localizar o registro de uma chave.
nc
Contador de uso de um nonce em Digest.
nonce
Valor usado uma vez ou dentro de janela limitada para reduzir replay.
opaque
Valor do desafio Digest devolvido sem interpretação pelo cliente.
qop
Qualidade de proteção negociada no Digest.
realm
Espaço de proteção anunciado por um desafio HTTP.
Replay
Reutilização não autorizada de uma credencial ou prova capturada.
Secret manager
Serviço para armazenar, distribuir e auditar segredos.
stale
Indicação de que o nonce expirou, não necessariamente a senha.
Verifier
Representação protegida usada para validar um segredo sem armazená-lo em claro.
WWW-Authenticate
Header de resposta que anuncia desafios de autenticação HTTP.
Anexo A - Matriz de decisão
Tabela 9 - A opção adequada depende da capacidade de proteger segredo e do risco da operação.
Cenário
Opção inicial
Condições
Integração legada temporária
Basic Auth
TLS, conta individual, senha forte, vault e prazo de migração.
Equipamento com suporte restrito
Digest
Algoritmo seguro, nonce consistente, TLS e testes de interoperabilidade.
Identificação de aplicação e quota
API Key
Chave individual, escopo, rotação e autorização separada.
Serviço interno moderno
OAuth 2.0 client credentials, mTLS ou federação
Credencial curta, audience e identidade de workload.
Cliente público móvel ou navegador
Não confiar em API Key como segredo
Backend intermediário, autenticação do usuário e controles de abuso.
Requisição que precisa de prova específica
HMAC ou assinatura assimétrica
Canonicalização, timestamp, nonce e proteção de chave.
Referências técnicas
. 9110 - Semantics. 2022.
. 7617 - The Basic Authentication Scheme. 2015.
. 7616 - Access Authentication. 2015.
. 7235 - /1.1 Authentication, posteriormente consolidada no 9110.
. Authentication Cheat Sheet.
. Password Storage Cheat Sheet.
. Security Cheat Sheet.
. Secrets Management Cheat Sheet.
. SP 800-63B - Authentication and Authenticator Management.
Microsoft Learn. Azure Management subscription keys e policies.
Axway Documentation. , Basic e políticas de autenticação no .
Nota de atualização
Protocolos e produtos possuem detalhes de implementação e suporte específicos. Antes de adotar Basic, ou , valide a documentação oficial da versão implantada e execute testes em ambiente autorizado.
