Identidade, contexto, políticas, enforcement, prova de posse, microsegmentação e decisões adaptativas por requisição
Edição aprofundada - material de estudo e consulta profissional
Por João Ricardo Dutra••Material integral
Apresentação do capítulo
A arquitetura tradicional de segurança foi construída em torno de fronteiras de rede. Usuários, servidores e aplicações localizados dentro de uma rede corporativa recebiam, de forma explícita ou implícita, um nível maior de confiança. Esse modelo perdeu eficácia à medida que passaram a conectar nuvens, parceiros, dispositivos móveis, fornecedores, aplicações , datacenters e workloads efêmeros. A origem de uma conexão continua relevante como sinal, mas já não é suficiente para decidir se uma operação deve ser autorizada.
é um conjunto de princípios e uma estratégia arquitetural baseada na eliminação de confiança implícita. Recursos são protegidos individualmente ou em grupos pequenos; sujeitos e dispositivos são identificados; decisões de acesso usam políticas e informações atuais; comunicações são protegidas; e a telemetria é utilizada para aperfeiçoar continuamente a postura. O objetivo não é desconfiar de pessoas de forma genérica, mas evitar que localização, propriedade ou uma autenticação passada produzam autorização ampla e permanente.
são um ponto natural para aplicar porque já materializam operações, identidades, dados e políticas. Um pode atuar como Policy Enforcement Point na borda, enquanto service meshes aplicam controles entre workloads. Provedores de identidade emitem credenciais e ; mecanismos de postura fornecem contexto; motores de política tomam decisões; e observabilidade registra o que ocorreu. Entretanto, comprar um , ativar ou exigir não cria, isoladamente, uma arquitetura .
Este capítulo conecta os fundamentos de identidade, ,,, policies, service mesh, Kubernetes e observabilidade estudados anteriormente. O foco é técnico e operacional: como modelar sujeitos e recursos, como avaliar cada requisição, como limitar privilégios, como reduzir movimentação lateral, como tratar falhas dos componentes de decisão e como evoluir a implantação sem interromper integrações críticas.
Como estudar este capítulo
Para cada fluxo, identifique: sujeito, recurso, ação, contexto, fonte de identidade, motor de decisão, ponto de enforcement e evidência registrada. Essa decomposição transforma o termo em arquitetura verificável.
Objetivos de aprendizagem
Explicar sem reduzi-lo a produto, , ou autenticação multifator.
Relacionar os princípios do SP 800-207 ao desenho de corporativas.
Distinguir ,, Policy Enforcement Point, , e .
Modelar identidades humanas, aplicações, workloads, dispositivos e sessões.
Aplicar autorização contextual e menor privilégio a operações e dados de .
Compreender , vinculados, e no contexto de redução de .
Projetar controles em , service meshes e Kubernetes.
Combinar , egress controlado, proteção de dados e observabilidade.
Definir estratégias de disponibilidade, , e para decisões de política.
Planejar uma jornada de maturidade com métricas, testes, governança e resposta adaptativa.
Estrutura do capítulo
35.1 O que é e o que não é
35.2 Princípios e componentes lógicos
35.3 Recursos, sujeitos e superfícies protegidas
35.4 Decisão por requisição e confiança dinâmica
35.5 Identidade humana, aplicação, workload e dispositivo
35.6 , e prova de posse
35.7 Autorização granular e arquitetura de políticas
35.8 como pontos de enforcement
35.9 Service mesh, Kubernetes e tráfego
35.10 , egress e proteção de dados
35.11 Telemetria, risco e resposta adaptativa
35.12 Disponibilidade, governança, maturidade e
Resumo, checklist, exercícios, glossário e referências
35.1 O que é e o que não é
é um modelo de segurança, um conjunto de princípios de projeto e uma estratégia coordenada de gestão. Sua premissa é que ameaças podem existir dentro e fora das fronteiras tradicionais e que nenhum elemento deve receber confiança implícita apenas por localização, propriedade ou relacionamento organizacional. A proteção se desloca de segmentos amplos de rede para usuários, dispositivos, workloads, aplicações, dados e recursos específicos.
O termo não significa bloquear tudo, reautenticar o usuário manualmente a cada clique ou eliminar completamente redes privadas. Significa que cada acesso precisa estar apoiado em identidade, política e contexto suficientes para o risco daquela ação. Uma requisição de leitura de dados públicos e uma operação financeira irreversível não exigem necessariamente a mesma , o mesmo conjunto de sinais ou o mesmo tempo de validade da autorização.
Também não existe um produto único chamado . Identity providers, , service meshes, EDRs, motores de política, catálogos de dados, SIEMs e plataformas de observabilidade podem participar da arquitetura. O valor surge da integração coerente entre esses componentes, da qualidade das políticas, da cobertura dos recursos e da capacidade de medir e reagir a desvios.
Uma rede interna ainda pode reduzir exposição, e um firewall continua útil. O erro é transformar a presença nessa rede em prova suficiente de identidade e autorização. Da mesma forma, autentica as pontas de um canal, mas não define sozinho se o serviço A pode executar a operação X sobre o recurso Y em nome do usuário Z.
Tabela 1 - deve ser compreendido como arquitetura e processo, não como marca de produto.
Afirmação
Avaliação
Explicação
é ausência total de confiança.
Incorreta.
A confiança deixa de ser implícita e passa a ser explicitamente avaliada e limitada.
implementa .
Incompleta.
cria conectividade; não garante autorização granular nem avaliação contínua.
é suficiente.
Incorreta.
Autentica pares, mas precisa de políticas, identidade de negócio e controles de dados.
Toda requisição deve ser avaliada.
Correta como princípio.
A avaliação pode usar decisões locais, seguro e sinais atuais conforme o risco.
35.2 Princípios e componentes lógicos
O SP 800-207 descreve princípios que podem ser aplicados diretamente a : recursos e serviços são tratados como ativos; toda comunicação é protegida independentemente da localização; o acesso é concedido por sessão e com menor privilégio; decisões consideram identidade, estado do ativo, comportamento e contexto; e a organização coleta informações para melhorar continuamente a postura.
Na arquitetura lógica do , o toma a decisão de conceder, negar ou revogar acesso. O executa essa decisão, por exemplo configurando ou encerrando uma sessão. O Policy Enforcement Point habilita, monitora e termina a conexão entre o sujeito e o recurso. Em uma plataforma de , o , um de mesh, um ou o próprio podem exercer o papel de enforcement.
A terminologia de autorização usada em arquiteturas de software frequentemente complementa esse modelo com ,, e . O Policy Decision Point avalia a política; o Policy Information Point fornece atributos; o Policy Administration Point administra políticas; e o Policy Enforcement Point aplica a decisão. Os nomes variam entre produtos, mas as responsabilidades precisam permanecer claras para evitar pontos cegos e decisões conflitantes.
Uma decisão pode ser binária, porém arquiteturas avançadas também geram obrigações: exigir step-up, mascarar campos, reduzir limite transacional, ativar reforçado, impor específico ou encaminhar a operação para aprovação. Essas obrigações precisam ser suportadas pelo enforcement e auditadas como parte do resultado.
Figura 1 - A decisão e o enforcement são funções distintas, alimentadas por múltiplas fontes de sinais.
35.3 Recursos, sujeitos e superfícies protegidas
começa pela identificação dos recursos que realmente precisam de proteção. Em , o recurso não é apenas o hostname ou o . Pode ser uma operação, um registro, um campo sensível, um conjunto de dados, uma fila, um segredo, uma chave de assinatura ou uma função administrativa. Quanto mais precisa for a classificação, mais granular pode ser a política.
O sujeito também precisa ser modelado corretamente. Uma mesma requisição pode carregar a identidade do usuário final, da aplicação cliente e do workload intermediário. Em fluxos delegados, o precisa distinguir quem está agindo e em nome de quem. Perder essa distinção produz genéricos, incompletos e privilégios excessivos.
A superfície protegida inclui interfaces públicas, integrações B2B, internas, administrativos, canais de mensageria e dependências externas. O inventário deve relacionar owner, dados processados, método de autenticação, exposição, consumidores, criticidade e políticas. desconhecidas, antigas ou de teste são difíceis de inserir em uma estratégia porque não possuem contexto de risco ou ciclo de vida governado.
A classificação de dados influencia a decisão. Um consumidor autenticado pode receber campos básicos, mas não dados financeiros completos. Um workload autorizado a ler um cadastro pode não ter permissão para exportar milhares de registros. O princípio do menor privilégio precisa alcançar volume, finalidade, horário, contexto e propriedades do objeto.
Identidades distintas participam da mesma chamada
Figura 2 - A identidade efetiva de uma chamada é composta por várias camadas, não apenas pelo usuário.
35.4 Decisão por requisição e confiança dinâmica
Em uma , a unidade prática de decisão é normalmente a requisição ou uma sessão curta associada a um conjunto limitado de operações. O identifica o sujeito, valida a credencial, extrai , consulta atributos quando necessário e avalia a política aplicável ao método, caminho, recurso e contexto. A autorização não deve ser inferida apenas porque uma conexão anterior foi aceita.
Confiança dinâmica significa que o resultado pode mudar quando os sinais mudam. Um usuário autenticado com pode perder acesso se o dispositivo ficar comprometido, se a localização se tornar incompatível, se o for revogado ou se o risco da sessão aumentar. Em aplicações críticas, ações sensíveis podem exigir nova autenticação, prova adicional ou confirmação fora de banda.
A avaliação contínua não implica que cada chamada dependa de dezenas de serviços remotos. Políticas podem ser compiladas e distribuídas para PDPs locais; atributos podem ter TTLs curtos; decisões de baixo risco podem ser armazenadas em ; e eventos de revogação podem invalidar estado. O desafio é equilibrar atualidade, disponibilidade, latência e segurança.
O desenho precisa especificar o comportamento quando sinais estão indisponíveis. Uma de consulta pública pode operar de forma degradada, enquanto uma transferência de alto valor deve negar acesso se o , o serviço antifraude ou a confirmação de postura não puderem ser consultados. e são decisões por classe de operação, não opções globais.
Figura 3 - A autorização é uma sequência de identificação, avaliação contextual, decisão e enforcement.
35.5 Identidade humana, aplicação, workload e dispositivo
Identidade humana costuma ser estabelecida por um provedor de identidade com autenticação multifator e políticas de risco. O resultante deve possuir issuer, subject, audience, escopos, tempo e nível de autenticação adequados. Grupos corporativos são úteis, mas frequentemente amplos demais para autorização fina; atributos de função, unidade, relacionamento e contexto podem complementar a decisão.
A aplicação cliente também é um sujeito. Em , o client_id identifica o software registrado e o tipo de cliente influencia os controles disponíveis. Clientes confidenciais autenticam-se no ; clientes públicos dependem de e proteção do ambiente. Em integrações B2B, a identidade da organização e do sistema parceiro deve ser separada da identidade do usuário final.
evita credenciais estáticas compartilhadas entre serviços. Certificados de curta duração, SPIFFE IDs, managed identities e projetados para contas de serviço permitem vincular a chamada à instância ou ao serviço executante. Em Kubernetes, ServiceAccounts e federação de identidade com a nuvem reduzem a necessidade de segredos permanentes em Pods.
O dispositivo fornece sinais adicionais: registro, integridade, versão, criptografia, postura de EDR e conformidade. Esses sinais não devem ser confundidos com a identidade do usuário. Uma pessoa válida em um dispositivo não gerenciado pode receber acesso limitado; um workload válido em um nó comprometido pode exigir quarentena. Políticas maduras combinam as dimensões sem transformar uma delas em confiança absoluta.
Tabela 2 - combina identidades e sinais sem presumir que um único atributo seja suficiente.
Identidade
Exemplos de evidência
Uso em política
Usuário
sub, acr, amr, grupos, risco.
Ações permitidas, step-up e segregação de funções.
Aplicação
clientid, certificado, software statement.
Consumidor, canal, quotas e escopos.
Workload
SPIFFE ID, , ServiceAccount.
Chamadas entre serviços e acesso a .
Dispositivo
registro, postura, EDR, versão.
Acesso adaptativo e redução de privilégio.
35.6 , e prova de posse
são utilizados por quem os possui. Se forem copiados de , memória, browser ou canal comprometido, podem ser reutilizados até expirar ou serem revogados. Por isso, precisam de transporte protegido, armazenamento seguro, audience restrita, escopos mínimos e vida curta. não elimina , mas reduz sua abrangência e assume que vazamentos são possíveis.
Sender-constrained vinculam o uso do a uma chave criptográfica. No , pode associar o ao certificado cliente, enquanto usa uma prova assinada no nível da aplicação e vincula o a uma chave pública. O resource server valida não apenas o , mas também a demonstração de posse da chave correspondente.
é especialmente adequado a integrações servidor-servidor, workloads e ambientes com operacional. pode ser usado por clientes que não conseguem apresentar certificados de forma conveniente. Ambos reduzem o valor de um roubado, porém não impedem uso indevido por um cliente legítimo comprometido nem substituem autorização e proteção contra da própria operação.
Em de alto risco, a prova de posse deve ser combinada a idempotência, assinatura de mensagens quando necessária, audience específica e detecção de anomalias. amplos, longa duração e propagação indiscriminada entre microsserviços contradizem menor privilégio, mesmo que estejam criptograficamente vinculados.
Figura 4 - Vincular o a uma chave adiciona uma condição criptográfica para seu uso.
Tabela 3 - Prova de posse melhora a resistência a de , mas exige validação e operação corretas.
Mecanismo
Prova apresentada
Uso típico
Cuidado
Apenas o .
gerais e fluxos comuns.
Proteção rigorosa contra vazamento.
Certificado cliente no .
B2B e workloads com .
Ciclo de vida de certificados e terminação .
de prova assinado por requisição.
Clientes de aplicação e .
Validação de htm, htu, iat, jti e quando usado.
35.7 Autorização granular e arquitetura de políticas
é útil para responsabilidades estáveis, mas raramente é suficiente sozinho para complexas. permite combinar atributos do sujeito, recurso, ação e ambiente. ReBAC representa relações, como titular, representante ou membro de uma organização. Políticas podem combinar esses modelos, desde que permaneçam compreensíveis, testáveis e auditáveis.
A arquitetura precisa definir onde a decisão ocorre. Um pode consultar um central, usar policy-as-code local ou combinar decisões. O continua responsável por regras que dependem de estado de negócio e por impedir acesso direto que contorne o . Em service mesh, autorização entre workloads pode ocorrer no , enquanto autorização de objeto permanece na aplicação.
PIPs fornecem atributos de diretórios, CMDB, inventário de dispositivos, classificadores de dados, risco e contexto. O administra as políticas e seu ciclo de vida. Para produção, políticas precisam de versionamento, revisão, testes unitários, simulações com tráfego histórico, aprovação, rollout gradual e .
O resultado da decisão deve ser explicável. não precisam expor a política inteira, mas devem registrar identificador da decisão, versão da política, sujeito, recurso, ação, resultado e motivo principal. Essa evidência é essencial para auditoria, e investigação de incidentes.
Figura 5 - A autorização depende de enforcement não contornável e de uma cadeia governada de política e atributos.
O é um natural para tráfego . Ele pode terminar , validar , verificar certificados, consultar PDPs, aplicar rate limits, remover credenciais externas, propagar identidade controlada e registrar decisões. Sua posição central facilita consistência, porém não autoriza transformar o em único componente de segurança.
O deve validar issuer, audience, assinatura, tempo, tipo do e obrigatórios. Policies genéricas baseadas apenas em presença de geram falsa sensação de proteção. A rota precisa estar associada a uma política de autorização explícita, e administrativos devem possuir controles ainda mais restritivos.
A identidade propagada ao precisa ser protegida contra . internos devem ser removidos da requisição externa e recriados pelo ; o canal até o deve ser autenticado; e o serviço precisa aceitar esses apenas de fontes autorizadas. Alternativamente, o pode trocar o por outro de audience específica ou usar credenciais de workload.
Alta disponibilidade exige avaliar dependências do : introspection, ,, KPS, diretórios e serviços de risco. têm de respeitar expiração, revogação e versionamento. Métricas devem separar falhas de autenticação, negações de política, indisponibilidade do , erro de e bloqueios por limite.
Tabela 4 - O precisa produzir diagnósticos por etapa, sem devolver detalhes sensíveis ao consumidor.
Etapa no
Controle
Falha que deve ser diferenciada
/
Canal protegido e identidade do peer.
Certificado inválido, , ou revogação.
Issuer, audience, assinatura, tempo e cnf.
inválido, expirado ou não vinculado.
Política
Sujeito + ação + recurso + contexto.
Negação legítima ou indisponível.
Propagação
ou interno controlado.
, audience errada ou excesso de .
35.9 Service mesh, Kubernetes e tráfego
A segurança de borda não impede movimentação lateral se serviços internos confiarem em qualquer origem da rede. Um service mesh pode fornecer automático, identidade de workload e autorização L4/L7 entre serviços. Cada chamada passa a ser associada à identidade do workload, independentemente do efêmero ou do nó em que o Pod está executando.
No Kubernetes, a identidade pode partir de ServiceAccounts e ser federada com provedores de nuvem. Pods não devem compartilhar credenciais estáticas de longa duração. controla ações na do , enquanto policies de mesh e NetworkPolicies controlam comunicações de workload. Esses mecanismos atuam em planos diferentes e precisam ser projetados em conjunto.
A policy de mesh pode restringir quais workloads chamam qual serviço, porta, método ou caminho. Para autorização em nome do usuário, o pode avaliar propagados, mas é preciso garantir origem e integridade. O continua necessário para decisões baseadas em objetos, saldos, relacionamentos ou estado de negócio.
A adoção gradual deve evitar a crença de que modo permissivo é estado final. Primeiro, inventaria-se o tráfego; depois, habilita-se e identidade; em seguida, políticas explícitas substituem permissões amplas. A telemetria ajuda a detectar dependências ocultas antes do bloqueio.
Figura 6 - A malha reduz confiança implícita entre workloads e permite enforcement próximo ao serviço.
35.10 , egress e proteção de dados
limita caminhos de comunicação para reduzir a superfície de ataque e o raio de impacto. Em , a segmentação pode usar identidade de workload, , domínio, sensibilidade e finalidade, em vez de depender apenas de endereços . NetworkPolicies, políticas de mesh, firewalls e internos podem cooperar, desde que ownership e precedência estejam definidos.
Egress controlado é parte importante do modelo. Um workload comprometido não deve conseguir acessar qualquer destino da Internet, de nuvem ou serviço interno. de saída, allowlists por nome e identidade, controlado, e monitoramento ajudam a limitar exfiltração e . Regras devem considerar resolução, redirects, IPs privados, protocolos e alterações de destino.
é orientado a recursos e dados. Criptografia em trânsito e em repouso é necessária, mas políticas também precisam controlar minimização, mascaramento, finalidade, retenção e exportação. Uma que retorna campos desnecessários ou permite paginação ilimitada pode violar menor privilégio mesmo com autenticação forte.
Segredos, chaves e certificados devem ter escopo, rotação e trilha de uso. O acesso pode ser mediado por identity-aware , secret stores e managed identities. Credenciais compartilhadas entre serviços impedem atribuição e revogação seletiva, aumentando o raio de impacto de um comprometimento.
Tabela 5 - é apenas uma das camadas de uma estratégia orientada ao recurso.
Camada
Objetivo
Exemplo de controle
Rede
Reduzir caminhos possíveis.
NetworkPolicy, firewall e egress .
Identidade
Vincular chamada a sujeito verificável.
, e .
Aplicação
Restringir ação e objeto.
, ReBAC e autorização por recurso.
Dados
Minimizar exposição e impacto.
Mascaramento, classificação e limites de exportação.
35.11 Telemetria, risco e resposta adaptativa
Decisões adaptativas dependem de telemetria confiável. ,, mesh, ,, SIEM e aplicação produzem sinais que podem indicar anomalia: mudanças de localização, volume incomum, enumeração de objetos, falhas repetidas, device posture degradada, novo certificado ou acesso fora do padrão. Esses sinais precisam ser normalizados, correlacionados e avaliados com latência compatível com o caso de uso.
A resposta não precisa ser apenas bloquear. A arquitetura pode exigir , reduzir escopos, limitar taxa, desabilitar exportação, marcar a sessão para revisão ou revogar credenciais. A escolha deve considerar impacto e confiança do detector. Controles excessivamente agressivos sem feedback geram indisponibilidade e incentivam exceções permanentes.
Observabilidade de precisa registrar decisões, não apenas tráfego. Métricas úteis incluem taxa de allow/deny por política, latência do , hit, decisões sem atributos, falhas de propagação, uso de credenciais antigas, cobertura de , fluxos não inventariados e tempo de revogação. ajudam a identificar qual ou tomou a decisão final.
Privacidade e segurança dos próprios sinais precisam ser consideradas. de autorização podem conter identificadores, grupos, risco e contexto. A coleta deve ser minimizada, protegida por acesso e retenção, e nunca incluir completos, chaves privadas ou dados sensíveis desnecessários.
Verificação contínua não é vigilância indiscriminada
A coleta deve ser proporcional, finalística e protegida. exige sinais suficientes para decisões e investigação, mas não justifica registrar credenciais, sensíveis ou atributos sem necessidade operacional.
35.12 Disponibilidade e falhas dos componentes de confiança
Uma arquitetura adiciona componentes críticos ao caminho: ,, introspection, ,, serviço de risco e infraestrutura de certificados. Cada dependência precisa de , redundância, ,, fallback e runbook. Uma política segura que torna todas as indisponíveis por falha simples é operacionalmente incompleta.
de chaves públicas costuma ser seguro quando respeita rotação e identificadores. de decisões é mais delicado porque atributos e risco podem mudar. O deve incluir sujeito, recurso, ação, contexto relevante, versão da política e . Eventos de revogação podem invalidar decisões antes do vencimento.
pode ser aceitável para operações públicas ou de baixo impacto, desde que o modo degradado seja explícito e monitorado. é apropriado para operações financeiras, administrativas ou de dados sensíveis. Entre os extremos, a organização pode oferecer leitura limitada, congelar alterações ou exigir um canal alternativo.
A recuperação precisa ser testada. Rotação de certificados, indisponibilidade do , de policy, perda do e mudança de issuer são cenários de continuidade. Exercícios controlados mostram se a equipe consegue distinguir negação legítima de falha de infraestrutura.
Tabela 6 - Disponibilidade e segurança precisam ser modeladas juntas.
Dependência
Risco
Estratégia
/
Chave indisponível ou rotação incorreta.
, sobreposição de chaves e monitoramento.
Latência ou indisponibilidade.
Instâncias locais, e política de degradação.
/ risco
Atributo ausente ou desatualizado.
, qualidade do sinal e decisão conservadora.
Falha de login ou emissão.
Redundância, sessões curtas existentes e plano de continuidade.
35.13 Governança e jornada de maturidade
A adoção de é uma jornada de transformação, não um projeto isolado. Um ponto de partida prático é inventariar recursos, identidades, fluxos e políticas; remover credenciais compartilhadas; centralizar identidade; proteger comunicações; tornar decisões explícitas; e expandir a observabilidade. A ordem exata depende do risco e da capacidade da organização.
Modelos de maturidade ajudam a organizar o trabalho em pilares. O CISA Maturity Model 2.0 trabalha com identidade, dispositivos, redes, aplicações e workloads, dados, visibilidade/analytics e automação/orquestração. Para , esses pilares se traduzem em identidade forte, postura, , políticas de , proteção de dados, telemetria e resposta automática.
Exceções precisam de owner, justificativa, escopo, prazo e compensações. Policies e atributos devem possuir catálogo, versionamento e evidência de teste. Métricas de maturidade devem medir cobertura e resultado: percentual de inventariadas, de audience restrita, workloads sem credenciais estáticas, tráfego , políticas explícitas, tempo de revogação e incidentes de acesso indevido.
A estratégia deve evitar big bang. Um modo de observação identifica fluxos; políticas são aplicadas a grupos controlados; negações são analisadas; e a cobertura cresce por domínio. Resultados de segurança precisam ser combinados a métricas de latência, disponibilidade e experiência dos consumidores.
Evolução de maturidade: de controles isolados a decisões adaptativas
Figura 7 - A maturidade cresce por coordenação entre pilares, não pela otimização isolada de um produto.
35.14 e investigação
Uma negação pode nascer em múltiplas camadas: certificado, , postura, policy, , mesh ou regra de negócio. O começa identificando o que respondeu, o decision_id e o estágio da falha. O consumidor deve receber uma resposta segura; os detalhes permanecem em protegidos.
Em autenticação, verifique cadeia de certificados, issuer, audience, assinatura, tempo, e binding. Em autorização, compare sujeito, ação, recurso, contexto, atributos fornecidos e versão da política. Em mesh, confirme identidade de workload, modo e regra aplicada. Em Kubernetes, valide ServiceAccount, labels, e NetworkPolicy.
Relógios incorretos, antigos, rotação incompleta, removidos, audiences erradas e atributos ausentes produzem incidentes intermitentes. distribuídos devem preservar correlação sem propagar . Quando um externo participa, sua latência e resultado precisam aparecer como span ou evento.
A investigação deve evitar desabilitar controles amplos como primeira tentativa. Um bypass temporário precisa ser mínimo, aprovado, monitorado e removido. Caso contrário, a organização transforma em criação de dívida de segurança.
Figura 8 - A investigação segue a cadeia de identidade, contexto, política, enforcement e recurso.
Tabela 7 - A resposta é apenas o sintoma final; a evidência precisa localizar a decisão.
Sintoma
Hipóteses iniciais
Evidência
401 após rotação
antigo, incorreta ou clock skew.
kid, cadeia, , datas e do .
403 apenas em uma rota
Policy/escopo/audience ou autorização de objeto.
decisionid, policyid, e recurso.
Falha intermitente
regional, , sinal de risco ou propagação.
latência por instância e completo.
Serviço interno bloqueado
Identidade de workload ou policy de mesh.
SPIFFE ID, certificado, labels e regra L7.
35.15 Estudos de caso e laboratórios
Caso 1 - integração B2B: um parceiro utiliza Credentials com . O possui audience específica e escopos mínimos; o valida o certificado e o binding do ; o recebe uma identidade interna controlada. A rotação ocorre com sobreposição de certificados e telemetria identifica consumidores ainda presos ao material antigo.
Caso 2 - microsserviços em Kubernetes: workloads recebem identidades curtas e comunicam-se por service mesh com . Policies permitem apenas os fluxos necessários e NetworkPolicies limitam caminhos de rede. A identidade do usuário final é propagada de forma verificável apenas onde necessária; decisões de objeto permanecem no serviço de domínio.
Caso 3 - operação financeira adaptativa: uma transferência comum é autorizada com sessão válida, dispositivo conforme e limite diário. Quando o risco aumenta, o exige step-up e reduz o valor máximo. O resultado, os sinais e a versão da política são auditados sem registrar o ou o completo.
Laboratórios sugeridos
1) Modele sujeito, recurso, ação e contexto para três . 2) Implemente uma policy em ambiente de teste. 3) Compare e /. 4) Configure autorização de workload em service mesh. 5) Simule indisponibilidade do e valide o modo degradado. 6) Construa um de cobertura, decisões e latência.
Resumo do capítulo
elimina confiança implícita baseada apenas em rede, propriedade ou autenticação passada. A proteção concentra-se em recursos e decisões explícitas. Em , isso significa identificar sujeitos, classificar dados, validar credenciais, avaliar contexto, aplicar autorização por ação e objeto e observar continuamente o resultado.
, service meshes e exercem papéis complementares de enforcement. autentica peers; vinculados reduzem ;, e ReBAC expressam políticas; substitui segredos estáticos; reduz ; e telemetria sustenta resposta adaptativa. Nenhum controle isolado implementa .
A arquitetura precisa ser disponível, governável e explicável. Policies, atributos e possuem ciclo de vida; dependências críticas exigem e fallback; negações devem ser investigáveis; e a adoção precisa avançar gradualmente por risco e domínio. A maturidade é medida pela cobertura e pela redução efetiva do privilégio e do raio de impacto.
Próximo passo do curso
O próximo capítulo aplica os fundamentos de , identidade, segurança e governança ao ecossistema de Open Finance e Open Banking Brasil, no qual confiança federada, consentimento, certificados, e alta disponibilidade são requisitos centrais.
Checklist para
, operações, dados, owners e consumidores estão inventariados e classificados.
Nenhuma localização de rede é usada como prova suficiente de autorização.
Usuário, cliente, workload e dispositivo são identidades separadas e correlacionáveis.
possuem audience, escopo e vida útil mínimos; credenciais estáticas são exceções controladas.
ou é aplicado onde a redução de justifica o custo operacional.
Policies avaliam sujeito, ação, recurso e contexto e possuem quando apropriado.
PEPs são não contornáveis e os mantêm autorização de negócio e de objeto.
Workloads usam identidades curtas; service mesh e NetworkPolicies reduzem .
Egress, segredos, dados e exportações são controlados por finalidade e menor privilégio.
Decisões, policy_id, versão, latência e motivos são observáveis sem registrar segredos.
Falhas de ,,, e possuem modo de degradação e runbook testado.
A jornada de maturidade possui métricas de cobertura, prazo, owner e remoção de exceções.
Exercícios
Explique por que uma rede privada não deve conceder autorização automática a uma .
Mapeie , e em uma arquitetura com e service mesh.
Diferencie identidade do usuário, aplicação, workload e dispositivo em uma única chamada.
Compare , e do ponto de vista de e operação.
Projete uma policy para consulta e alteração de dados financeiros.
Defina comportamento , e degradado para três classes de operação.
Proponha e egress controlado para uma em Kubernetes.
Descreva quais sinais devem ser registrados para explicar uma decisão de acesso.
Monte um plano de migração de credenciais estáticas para .
Defina indicadores de maturidade para uma plataforma corporativa de .
Glossário
Tabela 8 - Vocabulário essencial do capítulo.
Termo
Definição
Uso recorrente de sinais atuais para manter, limitar ou revogar acesso.
Postura em que acessos não explicitamente permitidos são negados.
Mecanismo de prova de posse no nível da aplicação.
Comportamento que nega acesso quando a decisão segura não pode ser obtida.
Comportamento que permite acesso em falha, aplicável apenas a riscos explicitamente aceitos.
Restrição granular dos caminhos de comunicação para reduzir .
Ponto responsável por administração e ciclo de vida de políticas.
Componente que avalia a política e produz uma decisão de autorização.
Componente que aplica a decisão de acesso ao tráfego ou recurso.
Fonte de atributos e contexto usados pela decisão.
Componente que executa a decisão do e estabelece ou encerra acesso.
Componente lógico que decide conceder, negar ou revogar acesso.
cujo uso exige prova da posse de uma chave vinculada.
Exigência de autenticação mais forte para ação ou risco elevado.
Identidade atribuída a software, serviço ou instância de execução.
Arquitetura que elimina confiança implícita e protege recursos com decisões explícitas.
Referências técnicas
SP 800-207 - . 2020.
SP 800-207A - A Model for Access Control in Cloud-Native Applications in Multi-Location Environments. 2023.
CISA - Maturity Model, Version 2.0. 2023.
SP 800-204B - Attribute-based Access Control for Microservices-based Applications Using a Service Mesh. 2021.
SP 800-204C - Implementation of DevSecOps for a Microservices-based Application with a Service Mesh. 2022.
6750 - Usage.
8705 - Mutual- Authentication and Certificate-Bound .
9449 - Demonstrating Proof of Possession at the Application Layer ().
OpenID Foundation - Core e especificações relacionadas.
SPIFFE Project - SPIFFE e SPIRE specifications and documentation.
Kubernetes Documentation - Service Accounts, , Network Policies e Pod Security.
Istio Documentation - Security, PeerAuthentication e AuthorizationPolicy.
Nota de atualização
é uma estratégia evolutiva e depende da versão dos produtos, do modelo de ameaça e do contexto regulatório. Antes de aplicar os exemplos, valide as especificações oficiais, o suporte do , da malha, do provedor de identidade e da plataforma implantada.
