Gestão de segredos de identidades não humanas para auditorias de 2026

O alerta das 02:13 que ninguém conseguia atribuir

Às 02:13 de uma terça-feira de manhã, o canal de operações de segurança acende-se. Foi iniciada uma exportação de uma base de dados de produção a partir de uma conta interna de automatização. O caminho de acesso é legítimo. O token é válido. O IP de origem pertence a um executor na nuvem utilizado pela equipa de engenharia. Não há malware visível. Não existe qualquer reporte de phishing.

O CISO faz a primeira pergunta óbvia: “Quem é o proprietário desta identidade?”

Silêncio.

O responsável de DevOps recorda que o token foi criado durante uma migração de cliente há dois anos. A equipa de plataforma diz que talvez seja utilizado por uma integração de faturação. O administrador da base de dados afirma que tem acesso de leitura porque, quando foi removido uma vez, interrompeu uma tarefa noturna. O departamento jurídico pergunta se estavam envolvidos dados pessoais. A equipa de conformidade pergunta se isto é um incidente notificável ao abrigo da NIS2, da DORA ou do RGPD da UE. O auditor pede evidência de que as contas de serviço, chaves de API, certificados e segredos de CI/CD estão inventariados, revistos, rodados, monitorizados e revogados.

Às 09:00, a minuta da constatação de auditoria já começa a ganhar forma. Foi descoberta uma chave de API embutida no código, sem rotação, num microsserviço esquecido. A chave concede acesso amplo a uma base de dados de transações de clientes em produção. O programador que a criou saiu há dois anos. O sistema não tem proprietário nomeado, finalidade documentada, registo de rotação nem regra de monitorização.

Este é o problema das identidades não humanas em 2026.

A maioria das organizações melhorou o controlo de acesso humano. Têm MFA, fluxos de admissão-movimentação-desligamento, revisões de acessos privilegiados e registos de eventos do fornecedor de identidade. Mas as identidades de máquina multiplicaram-se mais depressa do que a governação. Contas de serviço, identidades de carga de trabalho, chaves de API, tokens OAuth, chaves SSH, certificados, segredos Kubernetes, tokens de integração SaaS, contas de automatização robótica de processos e credenciais de implementação CI/CD executam agora ações críticas de negócio sem serem “utilizadores” no sentido humano.

Para prestadores SaaS, fintechs, prestadores de serviços geridos, operadores de nuvem e PME com elevada densidade de dados, as identidades não humanas não geridas deixaram de ser um problema de higiene técnica. São um risco de resiliência e conformidade ao nível do conselho de administração. A NIS2 trata o controlo de acesso, a gestão de ativos, a segurança da cadeia de fornecimento, o tratamento de incidentes e a higiene de cibersegurança como medidas essenciais de gestão de riscos de cibersegurança. A DORA coloca o risco das TIC, a resiliência operacional, a notificação de incidentes e o risco de terceiros TIC sob a responsabilidade do órgão de administração das entidades financeiras. O RGPD da UE exige que responsáveis pelo tratamento e subcontratantes protejam os dados pessoais e demonstrem responsabilização.

A parte difícil não é provar que os segredos existem. A parte difícil é provar que cada identidade não humana tem proprietário, finalidade, ciclo de vida, classificação de risco, acesso aprovado, método de armazenamento seguro, regra de rotação, cobertura de monitorização e via de revogação.

Porque é que as identidades não humanas se tornaram o novo problema de acesso privilegiado

Uma identidade não humana, ou NHI, é qualquer identidade digital utilizada por software, infraestrutura ou processos automatizados, em vez de uma pessoa. Na prática, inclui contas de serviço utilizadas por aplicações, chaves de API utilizadas por integrações SaaS, tokens OAuth e refresh tokens utilizados por aplicações de terceiros, chaves SSH utilizadas por automatização, certificados TLS e chaves privadas, segredos de CI/CD, identidades de carga de trabalho na nuvem, strings de ligação a bases de dados, credenciais incorporadas, contas de bots RPA e credenciais de integração geridas por fornecedores.

Estas identidades têm frequentemente três características que preocupam os auditores.

Em primeiro lugar, são duradouras. Um utilizador humano pode rodar credenciais, mudar de função e sair através de um processo formal de desvinculação. Um token de API criado durante uma janela de lançamento pode permanecer ativo durante anos porque ninguém quer correr o risco de interromper a produção.

Em segundo lugar, são poderosas. Um token de implementação pode alterar infraestrutura. Um principal de serviço na nuvem pode criar armazenamento. Uma conta de base de dados pode exportar registos de clientes. Uma chave de assinatura pode comprometer a integridade da cadeia de fornecimento de software.

Em terceiro lugar, são difíceis de atribuir. As identidades humanas estão ligadas a registos de Recursos Humanos. As identidades não humanas estão frequentemente ligadas a scripts, pipelines, fornecedores, projetos esquecidos ou integrações não documentadas.

O Zenith Blueprint: An Auditor’s 30-Step Roadmap da Clarysec Zenith Blueprint assinala isto diretamente na fase Controls in Action, Passo 22:

E não se esqueça das identidades não humanas. É aqui que as auditorias frequentemente descobrem exposição silenciosa. Os tokens de API são rastreados? As contas de integração estão associadas a pessoas ou ficam em limbo? Quando foi a última vez que a string de acesso à base de dados, incorporada num script com décadas, foi rodada?

A gestão de identidades não é glamorosa, mas é estrutural. Sem ela, o seu SGSI é apenas uma coleção de portas trancadas, sem forma de saber com certeza quem detém as chaves.

Essa última frase é o ponto central. Uma empresa pode ter uma política de controlo de acesso bem estruturada e, ainda assim, falhar uma auditoria se as identidades de máquina não forem geridas. Um SGSI que não consegue explicar quem é o proprietário de um segredo, porque existe e quando foi revisto pela última vez ainda não opera como um sistema controlado.

A ISO/IEC 27001:2022 transforma a gestão de segredos em evidência

A ISO/IEC 27001:2022 é eficaz porque não trata a gestão de segredos como uma tarefa isolada de engenharia. Exige um SGSI baseado no risco, com âmbito definido, requisitos das partes interessadas, responsabilização da liderança, avaliação de riscos, tratamento de riscos, seleção de controlos, Declaração de Aplicabilidade e melhoria contínua.

Para identidades não humanas, a organização não deve começar pela compra de uma ferramenta. Deve começar pelo âmbito e pelas obrigações.

Nos termos das cláusulas 4.1 a 4.4 da ISO/IEC 27001:2022, a organização determina questões internas e externas, partes interessadas, requisitos legais, regulamentares e contratuais, interfaces e dependências. No contexto de NHI, o âmbito do SGSI deve identificar ambientes de nuvem, plataformas SaaS, sistemas CI/CD, aplicações de produção, integrações de clientes, subcontratantes responsáveis pelo tratamento de dados, prestadores de serviços geridos e serviços criptográficos onde existam credenciais de máquina.

As cláusulas 5.1 a 5.3 responsabilizam a liderança por política, recursos, papéis e reporte de desempenho. Isto é importante porque a remediação de NHI cria frequentemente tensão operacional. Rodar uma credencial de base de dados de produção, substituir uma conta de serviço partilhada legada ou impor a injeção de segredos a partir de cofres pode interromper fluxos de trabalho frágeis. Sem patrocínio executivo, as equipas adiam a limpeza.

As cláusulas 6.1.1 a 6.1.3 e 6.2 fornecem o motor de controlo. A organização define critérios de risco, identifica riscos de confidencialidade, integridade e disponibilidade, atribui proprietários dos riscos, avalia probabilidade e impacto, escolhe opções de tratamento, seleciona controlos, produz a Declaração de Aplicabilidade e acompanha objetivos mensuráveis.

Em termos práticos, um plano de tratamento de riscos para identidades não humanas deve responder a:

• Que sistemas e serviços de negócio dependem de NHI?
• Que segredos podem aceder a dados pessoais, serviços financeiros regulados, infraestrutura de produção ou serviços críticos de clientes?
• Que identidades são privilegiadas, inativas, partilhadas, geridas por fornecedores ou não geridas?
• Que controlos reduzem o risco, como cofres de segredos, rotação, princípio do menor privilégio, expiração, gestão do ciclo de vida dos certificados, varredura em CI/CD, monitorização e revogação de emergência?
• Que riscos residuais exigem aprovação do negócio?

A ISO/IEC 27002:2022 fornece então o catálogo de controlos do Anexo A. Os controlos mais relevantes incluem 5.9 Inventário da informação e outros ativos associados, 5.15 Controlo de acesso, 5.16 Gestão de identidades, 5.17 Informação de autenticação, 5.18 Direitos de acesso, 5.19 Segurança da informação nas relações com fornecedores, 5.20 Tratamento da segurança da informação em acordos com fornecedores, 5.21 Gestão da segurança da informação na cadeia de fornecimento das TIC, 5.23 Segurança da informação para utilização de serviços de nuvem, 5.24 Planeamento e preparação da gestão de incidentes, 5.28 Recolha de evidência, 8.2 Direitos de acesso privilegiado, 8.3 Restrição do acesso à informação, 8.5 Autenticação segura, 8.15 Registo de eventos, 8.16 Atividades de monitorização, 8.24 Utilização de criptografia, 8.25 Ciclo de vida de desenvolvimento seguro, 8.26 Requisitos de segurança das aplicações, 8.28 Programação segura e 8.31 Separação de ambientes de desenvolvimento, teste e produção.

O Zenith Controls: The Cross-Compliance Guide da Clarysec Zenith Controls mapeia estas relações da ISO/IEC 27002:2022 de uma forma utilizável por auditores e proprietários dos controlos. Para o controlo 5.16, Gestão de identidades, o Zenith Controls explica a ligação entre identidade e credenciais:

A gestão de identidades define o quem, enquanto a informação de autenticação assegura o como, verificando que a pessoa que reivindica uma identidade é legítima. O 5.16 governa a gestão do ciclo de vida da identidade, enquanto o 5.17 assegura que palavras-passe, tokens, certificados e outras credenciais estão associados de forma segura a essas identidades e são geridos adequadamente para suportar uma autenticação forte.

Essa relação é essencial para NHI. Um token sem proprietário da identidade não é auditável. Uma conta de serviço sem revisão de acessos não cumpre o princípio do menor privilégio. Um certificado sem estado de ciclo de vida não é criptografia controlada. Uma credencial de integração de fornecedor sem termos contratuais não é gestão eficaz do risco de terceiros.

O padrão de controlo da Clarysec: identidade, segredo, privilégio, evidência

A Clarysec implementa a gestão de identidades não humanas e segredos através de um padrão de controlo repetível. Não tratamos “segredos” apenas como uma preocupação de DevOps nem “contas de serviço” apenas como uma preocupação de IAM. Ligamos identidade, segredo, privilégio e evidência.

A camada de política é onde isto se torna exigível.

Para PME, a User Account and Privilege Management Policy-sme da Clarysec User Account and Privilege Management Policy-sme estabelece:

As contas de serviço, utilizadas por sistemas ou aplicações, devem ser documentadas, restringidas a sistemas específicos e nunca utilizadas para autenticações interativas.

Isto evita o antipadrão clássico em que uma conta de serviço se transforma numa autenticação de administrador partilhada. Também dá ao auditor um teste claro: apresentar o inventário de contas de serviço, demonstrar a restrição por sistema e demonstrar que a autenticação interativa está desativada ou tecnicamente impedida.

A Asset Management Policy-sme da Clarysec Asset Management Policy-sme alarga a definição de ativos para incluir:

Credenciais e serviços digitais: nomes de domínio, certificados digitais, chaves de API, contas de correio eletrónico, credenciais de acesso à nuvem

Isto é importante porque muitas organizações inventariam apenas servidores, computadores portáteis e aplicações. Em 2026, uma chave de API pode ser mais sensível do que um computador portátil. A chave privada de um certificado pode ser um ativo de autenticação de produção. Uma credencial de acesso à nuvem utilizada por automatização pode criar exposição de dados regulados. Tratar credenciais como ativos é a base de uma gestão de segredos preparada para auditoria.

Para ambientes empresariais, a User Account and Privilege Management Policy da Clarysec User Account and Privilege Management Policy eleva o nível de evidência:

A organização deve manter um inventário detalhado de todas as credenciais ativas e inativas, contas privilegiadas e contas de serviço ao nível do sistema. Este inventário deve ser atualizado continuamente e revisto trimestralmente.

A revisão trimestral é onde muitas lacunas surgem. Credenciais inativas, principais de serviço órfãos, utilizadores de integração antigos, contas de fornecedores não geridas e tokens de emergência tornam-se visíveis apenas quando alguém compara o registo com os registos reais de IAM, cofres, CI/CD e nuvem.

Segredos são informação de autenticação, não conveniência para programadores

A frase mais perigosa na gestão de segredos é “chave temporária”.

Chaves temporárias tornam-se permanentes. Credenciais de teste chegam à produção. O código-fonte revela tokens. Registos de compilação expõem palavras-passe. Equipas de suporte partilham certificados através de tickets. Programadores copiam ficheiros de ambiente para chats. Um contratado cria um principal de serviço na nuvem e sai.

O Zenith Blueprint, na fase Controls in Action, Passo 22, descreve a informação de autenticação de forma ampla:

Este controlo não é apenas sobre palavras-passe, embora as palavras-passe façam certamente parte do quadro. Trata-se de todas as credenciais utilizadas para afirmar uma identidade: palavras-passe, PIN, chaves criptográficas, modelos biométricos, cartões inteligentes, tokens, certificados, tokens OAuth, chaves SSH, segredos de API. Estas são as chaves do reino, e o Controlo 5.17 assegura que essas chaves são tratadas com a seriedade que merecem.

Sejamos claros: a má gestão da autenticação continua a ser uma das principais causas raiz de violações. Palavras-passe fracas ou partilhadas. Credenciais embutidas no código-fonte. Autenticações administrativas predefinidas sem alteração em portais de administração. Certificados expirados ou com propriedade desconhecida. Em todos esses casos, não foi a identidade que falhou; foi a falha em proteger e governar o mecanismo utilizado para comprovar essa identidade.

As políticas da Clarysec traduzem isto em regras operacionais.

A Cryptographic Controls Policy-sme Cryptographic Controls Policy-sme estabelece:

As chaves não devem ser armazenadas em texto simples nem incorporadas em código-fonte, documentos ou mensagens de correio eletrónico

A Secure Development Policy-sme Secure Development Policy-sme estabelece:

Sem credenciais ou segredos embutidos no código-fonte

Para equipas empresariais, a Secure Development Policy Secure Development Policy estabelece:

Os segredos não devem ser embutidos no código nem armazenados em texto simples em repositórios.

E a Application Security Requirements Policy Application Security Requirements Policy é ainda mais direta:

O armazenamento de palavras-passe ou chaves criptográficas em texto simples é estritamente proibido.

Estas cláusulas de política criam um trilho de auditoria claro. As equipas de segurança podem testar repositórios, variáveis de CI/CD, imagens de contentores, repositórios de configuração, sistemas de tickets, plataformas de documentação e registos de eventos face a requisitos explícitos. Também suportam a segurança do tratamento prevista no Article 32 do RGPD da UE, porque a exposição de segredos pode conduzir diretamente a acesso não autorizado a dados pessoais.

A governação criptográfica empresarial também exige propriedade. A Cryptographic Controls Policy da Clarysec Cryptographic Controls Policy exige:

Deve ser mantido um Registo de Gestão de Chaves centralizado para registar todas as chaves criptográficas, o respetivo estado do ciclo de vida, custodiantes atribuídos e contextos de utilização.

Para identidades não humanas, esse registo deve ligar chaves de certificados, chaves de assinatura, chaves de API e chaves geridas na nuvem ao registo NHI mais amplo. O auditor deve conseguir rastrear um certificado de produção desde o serviço de negócio, ao proprietário, ao custodiante, à expiração, à evidência de rotação e ao procedimento de resposta a incidentes.

NIS2, DORA e RGPD da UE: um modelo de evidência, muitos reguladores

A governação de identidades não humanas é um problema transversal de conformidade, porque a mesma falha pode desencadear múltiplas obrigações.

Um token de API exposto num prestador SaaS pode causar interrupção de serviços ao abrigo da NIS2, exposição de dados pessoais ao abrigo do RGPD da UE e reporte contratual de incidentes a clientes financeiros no quadro das expectativas de cadeia de fornecimento da DORA. Um segredo de CI/CD comprometido num prestador de serviços TIC pode afetar a resiliência dos clientes, a integridade do software e a continuidade operacional. Uma conta de integração de fornecedor esquecida pode criar acesso a sistemas regulados sem diligência prévia ou controlos contratuais adequados.

O Article 21 da NIS2 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionais. As áreas mínimas incluem análise de riscos, políticas de segurança dos sistemas de informação, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, aquisição, desenvolvimento e manutenção seguros, tratamento de vulnerabilidades, avaliação da eficácia, higiene de cibersegurança, criptografia, segurança de Recursos Humanos, controlo de acesso e gestão de ativos e, quando adequado, MFA ou autenticação contínua. As identidades não humanas atravessam quase todas essas áreas. O Article 23 da NIS2 também cria reporte faseado de incidentes significativos, incluindo alerta precoce no prazo de 24 horas, notificação de incidente no prazo de 72 horas e relatório final no prazo máximo de um mês após a notificação do incidente.

A DORA aplica-se desde 17 de janeiro de 2025 e abrange gestão do risco das TIC, reporte de incidentes graves relacionados com TIC, testes de resiliência operacional, partilha de informação e risco de terceiros TIC. Os Articles 5 e 6 exigem governação, responsabilização do órgão de administração e um quadro documentado de gestão do risco das TIC. O Article 8 exige a identificação de funções de negócio suportadas por TIC, ativos de informação e dependências. Os Articles 17 a 19 exigem gestão de incidentes, classificação e reporte. Os Articles 28 a 30 exigem gestão de risco de terceiros TIC, registos contratuais, diligência prévia, normas de segurança, direitos de auditoria, suporte a incidentes, controlos de subcontratação e estratégias de saída.

O RGPD da UE aplica-se sempre que dados pessoais são tratados no seu âmbito territorial. O Article 5 exige integridade, confidencialidade e responsabilização. O Article 32 exige medidas técnicas e organizativas adequadas para a segurança do tratamento. Se uma conta de serviço ou chave de API puder aceder a dados pessoais, segredos não geridos tornam-se uma falha de controlo de privacidade, e não apenas um problema de TI.

A mesma evidência pode suportar a certificação ISO/IEC 27001:2022, a supervisão NIS2, avaliações DORA e a responsabilização no âmbito do RGPD da UE quando é corretamente estruturada.

O NIST CSF 2.0 pode ser utilizado como camada de comunicação para a mesma evidência. A sua função GOVERN cobre expectativas das partes interessadas, obrigações legais e contratuais, apetite ao risco, responsabilização da liderança, política e supervisão. Os seus resultados operacionais abrangem inventários de ativos, serviços prestados por fornecedores, gestão de identidades e credenciais, princípio do menor privilégio, segurança dos dados, registo de eventos, monitorização, resposta a incidentes e recuperação.

As equipas de garantia ao estilo COBIT 2019 e ISACA olharão normalmente para a governação e a capacidade dos processos. Perguntarão se a responsabilidade está atribuída, se os controlos estão incorporados nos processos operacionais, se as exceções são aprovadas, se as métricas são reportadas à gestão e se a evidência demonstra repetibilidade, e não apenas uma limpeza pontual.

Um sprint prático para criar um registo de identidades não humanas

Um envolvimento prático da Clarysec começa frequentemente com um sprint focado, não com um programa de ferramentas de seis meses. O objetivo é produzir um registo NHI defensável, uma classificação de risco e um plano de remediação que alimentem o plano de tratamento de riscos ISO/IEC 27001:2022 e a Declaração de Aplicabilidade.

Comece por um serviço de negócio, como uma plataforma de faturação de clientes, aplicação de negociação, portal de pacientes ou sistema de gestão de tenants SaaS. Inclua produção, staging, CI/CD, infraestrutura de nuvem, ferramentas de monitorização, bases de dados, integrações SaaS e serviços geridos por fornecedores.

Ligue isto ao Zenith Blueprint, fase Risk Management, Passo 14, onde a Clarysec alinha políticas de tratamento com referências regulamentares cruzadas. Nesse passo, os controlos de desenvolvimento seguro e pipeline incluem ausência de segredos embutidos no código, revisão por pares, análise estática automatizada, varredura de dependências, separação de desenvolvimento, teste e produção, MFA para acesso a pipelines, integridade de artefactos de compilação e registo de eventos de CI/CD.

Recolha identidades e segredos a partir do fornecedor de identidade, IAM de nuvem, cofre de segredos, Kubernetes, variáveis de CI/CD, definições de repositórios, utilizadores de bases de dados, consolas administrativas SaaS, ferramentas de gestão de certificados e documentação de fornecedores.

Classifique o risco das identidades que têm acesso à produção, direitos privilegiados, acesso a dados pessoais, dependência de função crítica ou importante, controlo por fornecedor, tokens duradouros, ausência de proprietário, ausência de rotação, ausência de monitorização ou armazenamento embutido no código. Utilize os critérios de risco da ISO/IEC 27001:2022 para pontuar probabilidade e impacto. Utilize a análise de função crítica ou importante da DORA quando aplicável. Utilize considerações de impacto do RGPD da UE quando dados pessoais estiverem acessíveis. Utilize o impacto em serviços NIS2 quando a interrupção ou dano ao cliente for plausível.

Para cada NHI de alto risco, aplique ações de tratamento. Mova segredos de código-fonte, documentos e variáveis CI/CD em texto simples para um cofre ou repositório de segredos gerido. Substitua contas de serviço partilhadas por identidades de carga de trabalho únicas. Desative a autenticação interativa para contas de serviço. Aplique o princípio do menor privilégio e credenciais específicas por ambiente. Configure rotação, expiração e revogação de emergência. Associe segredos a proprietários e custodiantes. Adicione registo de eventos para autenticação, utilização de tokens e ações sensíveis. Adicione alertas para geografia anómala, horários incomuns, volume anormal ou acesso a novos recursos. Atualize contratos de fornecedores para tratamento de credenciais, suporte a incidentes e direitos de auditoria. Documente exceções com aprovação do proprietário do risco e data de expiração.

A Test Data and Test Environment Policy Test Data and Test Environment Policy suporta a separação de ambientes:

A integração com pipelines de CI/CD deve impor a separação de ambientes e credenciais de autenticação.

Esta cláusula é frequentemente decisiva. Se desenvolvimento, teste e produção partilharem segredos, um ambiente de baixo risco pode tornar-se um caminho para uma violação em produção.

O sprint deve terminar com um pacote de evidência, não apenas com uma lista de constatações. Inclua a exportação do registo NHI, entradas de avaliação de riscos, plano de tratamento, mapeamento da Declaração de Aplicabilidade, referências de políticas, capturas de ecrã do cofre, registos de rotação, aprovações de revisão de acessos, resultados de varredura de segredos em CI/CD, definições de regras de monitorização, matriz de responsabilidades sobre credenciais de fornecedores, runbook de incidente e exceções com proprietários e datas de expiração.

Registo de eventos e deteção: provar que a utilização de identidades de máquina é visível

Uma identidade de máquina bem inventariada mas invisível nos registos de eventos continua perigosa. A deteção faz parte da história de controlo.

A Logging and Monitoring Policy-sme da Clarysec Logging and Monitoring Policy-sme inclui evidência de autenticação:

Registos de autenticação: tentativas de autenticação bem-sucedidas e falhadas, duração das sessões, utilização de MFA

Para NHI, adapte este requisito à autenticação de máquina. Pode não existir utilização de MFA para uma identidade de carga de trabalho, mas devem existir eventos de autenticação, utilização de tokens, utilização de certificados, metadados de chamadas de API, carga de trabalho de origem, serviço de destino, tempo de vida do token, eventos de falha e ações privilegiadas.

No Zenith Controls, o controlo 8.2 da ISO/IEC 27002:2022, Direitos de acesso privilegiado, está ligado ao registo de eventos e à monitorização porque as contas privilegiadas exigem registos detalhados e supervisão. O Zenith Controls também liga o 8.2 à gestão de identidades, aos direitos de acesso, à restrição do acesso à informação e à autenticação segura. Para auditores, isto significa que identidades não humanas privilegiadas devem ser revistas e monitorizadas com a mesma seriedade que administradores humanos, por vezes mais.

Boas perguntas de monitorização incluem:

• Uma conta de serviço autenticou-se a partir de uma carga de trabalho ou intervalo de IP inesperado?
• Uma chave de API acedeu a um novo endpoint ou conjunto de dados?
• Um certificado foi utilizado após substituição?
• Um token de CI/CD implementou fora de uma pipeline aprovada?
• Uma conta só de leitura tentou operações de escrita?
• Uma credencial inativa ficou ativa?
• Uma integração de fornecedor acedeu a dados fora dos horários ou volumes acordados?

Quando o alerta das 02:13 ocorrer, é necessário responder que identidade foi utilizada, que segredo a autenticou, que direitos de acesso foram exercidos, que dados ou sistemas foram afetados, se a atividade era esperada, que proprietário pode validá-la e se os limiares de notificação de incidentes foram atingidos.

A perspetiva do auditor: o mesmo processo, perguntas diferentes

A posição de auditoria mais forte não é “cumprimos tudo”. É “operamos um processo controlado que produz evidência para múltiplas obrigações”. Auditores diferentes inspecionarão esse processo de formas diferentes.

Em todas essas perspetivas, as constatações recorrentes são previsíveis: inexistência de um inventário NHI único, ausência de proprietário para identidades de máquina, segredos armazenados em código ou documentação, credenciais partilhadas entre ambientes, ausência de rotação ou expiração, credenciais geridas por fornecedores fora das revisões de acessos, monitorização que cobre humanos mas não máquinas e runbooks de incidente que ignoram fugas de segredos.

Cada constatação mapeia-se naturalmente para controlos, políticas e modelos de remediação da Clarysec. Mais importante ainda, cada uma pode ser convertida em evidência mensurável dentro do SGSI.

Como a Clarysec ajuda a preparar a sua organização para auditoria

A abordagem da Clarysec é prática porque começa pela evidência que os auditores irão solicitar e trabalha em sentido inverso até aos controlos, políticas e rotinas operacionais.

No Zenith Blueprint, fase Controls in Action, Passo 19, a Clarysec fornece orientação direta para autenticação máquina-a-máquina:

Para autenticação máquina-a-máquina, como contas de serviço ou chamadas de API, chaves, certificados e tokens devem ser protegidos com o mesmo rigor. Evite incorporar credenciais no código. Utilize sistemas de gestão de segredos ou cofres para as armazenar e rodar de forma segura.

Um fluxo de trabalho típico da Clarysec para identidades não humanas inclui descoberta de NHI em nuvem, SaaS, CI/CD, repositórios, cofres e bases de dados; avaliação de lacunas de política face a conjuntos de políticas PME ou empresariais da Clarysec; avaliação de riscos e mapeamento de tratamento ISO/IEC 27001:2022; atualizações da Declaração de Aplicabilidade; mapeamento de evidência para NIS2, DORA, RGPD da UE e NIST CSF; conceção do registo NHI; alinhamento com o Registo de Gestão de Chaves; varredura de segredos; processos de revisão de acessos; matrizes de responsabilidade sobre credenciais de fornecedores; runbooks de incidente; e pacotes de auditoria com capturas de ecrã, exportações, registos de eventos, aprovações e registos de exceções.

Para PME, a abordagem é proporcional. Um prestador SaaS com 70 pessoas não precisa da mesma pegada tecnológica que um banco global, mas precisa de propriedade, política, tratamento de riscos e evidência. Para entidades financeiras reguladas e prestadores TIC, o mesmo modelo escala para mapeamento de funções críticas DORA, governação de risco de terceiros e testes de resiliência.

Se a sua próxima auditoria é em 2026, não espere que o auditor descubra as identidades não humanas por si. Comece por um serviço crítico e faça cinco perguntas:

1. Conhecemos todas as contas de serviço, chaves de API, tokens, certificados e segredos de CI/CD utilizados por este serviço?
2. Cada NHI tem um proprietário nomeado, custodiante, finalidade e classificação de risco?
3. Os segredos estão em cofres, são rodados e estão protegidos contra código-fonte, documentos, mensagens de correio eletrónico e armazenamento em texto simples?
4. As identidades de máquina privilegiadas são revistas, monitorizadas e impedidas de utilização interativa?
5. Conseguimos produzir evidência para ISO/IEC 27001:2022, NIS2, DORA e RGPD da UE a partir de um único processo controlado?

Utilize o Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint para estruturar a sua jornada de implementação do SGSI. Utilize o Zenith Controls: The Cross-Compliance Guide Zenith Controls para ligar os controlos ISO/IEC 27002:2022 de identidade, autenticação, privilégio, registo de eventos, criptografia, desenvolvimento seguro e fornecedores à evidência regulamentar. Utilize a biblioteca de políticas PME e empresariais da Clarysec, incluindo a User Account and Privilege Management Policy-sme User Account and Privilege Management Policy-sme, a Cryptographic Controls Policy Cryptographic Controls Policy, a Secure Development Policy Secure Development Policy e a Application Security Requirements Policy Application Security Requirements Policy, para converter boas intenções em requisitos exigíveis.

O alerta das 02:13 vai acontecer algures. A questão é se a sua organização consegue responder, com evidência, quem detinha a chave, o que ela abria, porque existia e quão rapidamente a consegue tornar segura.