Entradas, mudanças e saídas: mantenha os acessos sob responsabilidade

As alterações de acessos são um problema de coordenação, além de um problema técnico. Uma plataforma de identidades não consegue remover a conta de um prestador externo se ninguém disser ao responsável que o contrato terminou. Do mesmo modo, uma comunicação atempada dos recursos humanos não prova que todas as aplicações deixaram de aceitar as credenciais da pessoa.

As entradas, mudanças e saídas precisam de um processo que ligue um evento de negócio a um estado de acesso aprovado, execute as alterações necessárias e verifique o resultado. Na perspetiva da liderança técnica, a questão importante não é saber se existe uma lista de verificação de saída. É saber se o processo cobre os sistemas que as pessoas realmente utilizam, trata as falhas e deixa evidências do que mudou e quando.

Defina o ciclo de vida e as suas passagens de testemunho

Trate cada evento do ciclo de vida como uma alteração aos acessos autorizados de uma pessoa, e não simplesmente como um ticket para criar ou desativar uma conta. O registo do evento deve identificar a pessoa, a situação laboral ou contratual, o gestor ou patrocinador, a data e hora de efeito e a função afetada. Utilize um identificador estável, em vez de confiar apenas em nomes ou endereços de e-mail.

Os recursos humanos iniciarão frequentemente os eventos relativos a colaboradores. Um responsável de compras, um gestor de projeto ou um patrocinador interno podem iniciar os eventos relativos a prestadores externos. Escolha uma fonte autorizada para cada população e defina como as correções, as entradas canceladas, as prorrogações de contratos e as saídas urgentes chegam às TI.

Separe quatro responsabilidades, mesmo quando uma equipa pequena atribui várias à mesma pessoa:

Designe substitutos e uma via de escalamento. Uma saída programada não pode depender da disponibilidade de um único administrador. Nas alterações sensíveis, um revisor independente proporciona uma verificação útil; quando a dimensão da equipa o impede, documente a solução adotada e recorra a uma revisão posterior.

Defina critérios de conclusão para cada evento. Uma entrada está pronta quando os acessos aprovados e os controlos de dispositivo exigidos estão verificados. Uma mudança está concluída quando tanto os acréscimos como as remoções foram verificados. Uma saída está concluída quando as vias de acesso foram revogadas e as questões pendentes relativas a ativos, dados ou credenciais têm responsáveis explícitos.

Estas são recomendações práticas de desenho de controlos, não prazos legais universais. Num SGSI ISO 27001, os controlos de acesso devem refletir o âmbito e o tratamento do risco da organização. Consulte o Anexo A da ISO 27001 na prática para o contexto de controlo mais amplo.

Estabeleça a cobertura antes de automatizar alterações

Comece pelo inventário de aplicações. Para cada sistema, registe o responsável, a fonte de identidade, o método de aprovisionamento, o método de autenticação, as ações de revogação suportadas e o método de verificação. Inclua tanto as aplicações geridas centralmente como as que têm contas locais.

O single sign-on não significa necessariamente uma gestão completa do ciclo de vida. Uma aplicação pode autenticar através do fornecedor de identidade e manter administradores locais, chaves de API, sessões ativas ou opções de recuperação. Um conector de aprovisionamento pode desativar um utilizador sem remover todas as permissões. Documente o que cada mecanismo faz realmente.

Inclua estas vias de acesso menos visíveis:

• Contas privilegiadas separadas da conta de uso diário da pessoa.
• Acesso por VPN, certificados, chaves SSH e ferramentas de suporte remoto.
• Tokens de acesso pessoais, credenciais de API e palavras-passe de aplicações.
• Credenciais partilhadas que a pessoa conhecia ou conseguia obter.
• Contas de convidado, espaços de colaboração externos e ambientes geridos por clientes.
• Identidades de serviço cujo responsável ou custodiante de credenciais está a mudar.

Não desative automaticamente todas as identidades de serviço associadas a um colaborador que sai: podem estar a executar uma carga de trabalho de produção. Em vez disso, transfira a responsabilidade, reveja as permissões e renove as credenciais expostas quando adequado. O objetivo é remover o acesso da pessoa sem provocar uma indisponibilidade evitável.

Reconcilie periodicamente o inventário com exportações de identidades, registos de dispositivos, registos de compras e declarações das equipas. Nenhuma fonte isolada revelará necessariamente todas as aplicações. As descobertas não geridas devem entrar no processo do ciclo de vida, em vez de permanecerem como exceções informais.

Entradas: aprovisione um estado inicial controlado

Construa perfis base por função com exceções delimitadas

Defina pacotes de acesso em torno de responsabilidades, e não apenas de títulos de funções. Um analista de suporte pode precisar de acesso aos tickets de clientes, mas não às exportações de faturação. Um engenheiro de software pode precisar de repositórios de código e ambientes de desenvolvimento sem receber, por omissão, a administração de produção.

Cada perfil base deve ter um responsável, uma versão, os grupos ou permissões incluídos e uma data de revisão. Registe que versão foi aplicada a cada entrada. Caso contrário, uma atualização posterior da função torna difícil reconstruir decisões de acesso históricas.

Peça os acessos adicionais separadamente. O pedido deve indicar a finalidade de negócio, o responsável pelo sistema ou pelos dados que aprova, o nível de permissão e, quando adequado, a data de expiração. Evite copiar o conjunto completo de permissões de um colaborador existente: isso pode reproduzir exceções acumuladas e privilégios de funções anteriores.

Prepare as contas antes da data de entrada quando for útil, mas controle a ativação. Uma contratação cancelada deve desencadear a limpeza das contas preparadas, dos dispositivos enviados e dos convites. Os prestadores externos devem ter um patrocinador interno e uma data de fim ou de revisão; as prorrogações devem exigir uma decisão afirmativa, em vez de se tornarem silenciosamente acessos permanentes.

Estabeleça a base de dispositivo e de autenticação

Registe o identificador do dispositivo, a pessoa a quem foi atribuído, a data de entrega e a inscrição na gestão de dispositivos. Verifique a base relevante antes de conceder acessos sensíveis: sistema operativo suportado, estado das atualizações, cifragem do disco, bloqueio de ecrã, proteção de endpoints e uma configuração de autenticação aprovada.

Estas são opções de implementação baseadas no risco, não a afirmação de que todas as organizações têm de utilizar definições idênticas. Para dispositivos pessoais, defina explicitamente os acessos permitidos e o tratamento dos dados, em vez de os tratar como equivalentes a portáteis geridos.

Utilize observações datadas dos sistemas de gestão de dispositivos quando disponíveis. Um inventário manual pode continuar a ser útil se for reconciliado e sustentado por evidências; um inventário em tempo real também precisa de escrutínio quando um dispositivo deixou de reportar. Preserve as horas das observações, para que um estado saudável antigo não seja confundido com uma garantia atual.

Verifique a inscrição na autenticação e a entrega inicial das credenciais. Quando a sua política exigir autenticação multifator, confirme que está ativa antes de o acesso começar, em vez de registar apenas que foi enviado um convite de inscrição. Mantenha as credenciais e os códigos de recuperação fora dos tickets do ciclo de vida.

Mudanças: remova a função antiga, e não apenas acrescente a nova

As transferências são muitas vezes os eventos do ciclo de vida mais difíceis, porque a pessoa continua empregada e a sua conta existente continua a funcionar. Os novos acessos recebem atenção, porque a falta de permissões interrompe o trabalho. Os acessos antigos podem persistir sem qualquer sintoma visível.

Trate a mudança como uma comparação entre três estados: os acessos atuais, o novo perfil base aprovado e as exceções aprovadas que se mantêm. Determine que permissões devem ser acrescentadas, mantidas, reduzidas ou removidas. Verifique as atribuições diretas, além dos grupos, das pertenças aninhadas, das funções administrativas e das permissões locais das aplicações.

O gestor anterior deve ajudar a identificar as responsabilidades que terminaram. O gestor que recebe a pessoa confirma as novas funções, enquanto os responsáveis pelos sistemas ou pelos dados aprovam os acessos sensíveis. Isto impede que um novo gestor autorize implicitamente a manutenção do acesso a informação de outro departamento.

Um período de transição pode ser legítimo. Alguém que sai da área financeira pode precisar de acesso limitado para concluir uma passagem de pasta. Registe a permissão específica, a justificação, o responsável que aprova e a data de expiração. Sempre que possível, substitua o acesso amplo de escrita por um acesso mais restrito ou só de leitura. Inscreva a expiração numa tarefa executável ou numa definição do sistema, e não apenas num comentário.

As alterações podem também afetar dispositivos, caixas de correio partilhadas, a responsabilidade por dados e funções privilegiadas. Passar para uma função administrativa não deve converter automaticamente a conta de uso diário numa identidade privilegiada.

Após a execução, compare o conjunto real de acessos com o resultado pretendido. Numa transferência entre departamentos, conceder a nova função pode ser fácil. A verificação importante é saber se permanecem acessos antigos à área financeira, a clientes ou administrativos. Uma amostra de mudanças que verifique apenas o novo aprovisionamento não deteta esse risco.

Saídas: coordene a revogação, os ativos e a continuidade do negócio

Defina o momento em função do risco e das circunstâncias

Registe uma hora de revogação efetiva, incluindo o fuso horário. “Último dia” é demasiado ambíguo para equipas distribuídas e para automatização agendada. Distinga uma saída planeada de uma cessação urgente, de um comprometimento suspeito ou de uma ausência inesperada que exija suspensão temporária.

Acorde o momento com os recursos humanos e com a gestão relevante. Restrinja os pormenores sensíveis da cessação a quem deles precisa, assegurando ao mesmo tempo que quem executa recebe informação suficiente para agir. As saídas de alto risco podem exigir ação imediata coordenada; as saídas de rotina podem permitir uma passagem de pasta planeada antes de o acesso terminar.

Não permita que a transferência de dados ou o envio de dispositivos atrasem a revogação. Estas atividades podem ter datas de conclusão e responsáveis separados. Se um evento chegar tarde, registe a hora de corte pretendida, a execução real e o intervalo de exposição, em vez de alterar a documentação para que o evento pareça atempado.

Feche todas as vias de acesso relevantes

Desative a identidade principal e execute as ações específicas de cada aplicação a partir do inventário. Trate, conforme aplicável, as sessões ativas, os tokens de atualização, as contas locais, as contas privilegiadas, o acesso remoto, os certificados e as credenciais pessoais. A desativação de uma conta central não prova que todas as sessões existentes ou credenciais emitidas de forma independente se tornaram inutilizáveis.

Renove, em função do risco, os segredos partilhados a que a pessoa tinha acesso e verifique que a renovação não perturba os sistemas dependentes. Remova os métodos de recuperação ou as permissões delegadas que possam repor o acesso. Quando estiverem envolvidos ambientes de clientes ou de fornecedores, peça a revogação ao respetivo responsável e conserve a confirmação.

Registe os resultados individuais. Um tempo esgotado de um conector não é um encerramento bem-sucedido só porque a tarefa global terminou. Encaminhe as falhas para um interveniente designado, utilize uma alternativa aprovada e verifique o estado final. Os acessos urgentes por resolver devem entrar no processo de escalamento de segurança.

Recupere os dispositivos sem presumir que os comandos remotos tiveram êxito

Acompanhe cada ativo atribuído ao longo da devolução, da inspeção e da reposição ou eliminação aprovadas. Para trabalhadores remotos, registe as condições de envio e a custódia por resolver. Remova o acesso físico e recupere tokens ou chaves quando relevante.

Se a devolução atrasar, utilize os controlos de bloqueio ou de apagamento disponíveis, de acordo com a política e o risco. Distinga a emissão de um comando da confirmação e conclusão do mesmo pelo dispositivo. Um portátil offline pode não receber o comando. Avalie a exposição residual com base no estado da cifragem, nas credenciais locais, nos dados em cache e nas restrições de rede disponíveis, em vez de tratar “apagamento em fila” como prova de eliminação.

Preserve os dados necessários e recupere as licenças

Atribua um sucessor para os documentos de negócio, os repositórios, os fluxos de trabalho partilhados e a responsabilidade por serviços. Utilize mecanismos de transferência administrativa autorizados, em vez de pedir a alguém que se faça passar pelo antigo colaborador. Delimite o acesso à caixa de correio ou aos ficheiros, registe a finalidade e limite as pessoas que o recebem.

Separe a revogação de acessos, a recuperação de licenças, a conservação e a eliminação. A remoção de uma licença pode afetar a disponibilidade dos dados de forma diferente em cada aplicação. Verifique os requisitos de conservação e qualquer obrigação de preservação para fins jurídicos antes de uma limpeza irreversível.

No caso dos dados pessoais, o artigo 5.º do RGPD estabelece a limitação da conservação; não cria um prazo universal de eliminação das contas de colaboradores. Defina prazos de conservação justificados e responsabilidades de limpeza. O artigo 32.º exige medidas de segurança adequadas ao risco, pelo que deve documentar o raciocínio subjacente aos controlos de saída, em vez de tratar uma lista de verificação como conformidade legal por si só.

Conserve evidências da alteração efetiva

O registo útil liga a decisão autorizada ao resultado observado. Conserve o evento, a aprovação, os sistemas afetados, as horas de execução, os resultados da verificação e o tratamento das exceções. Inclua a hora de efeito pretendida, para que os revisores possam avaliar a atempabilidade.

Um pacote de evidências prático contém:

• Um identificador estável da pessoa e do evento, com a fonte que o iniciou.
• O perfil base aprovado e quaisquer permissões mantidas ou adicionais.
• Ações, resultados, marcas temporais e referências de registos relevantes por sistema.
• Verificação que mostre o estado de acesso resultante.
• Resultados relativos a ativos, transferência de dados e licenças, quando aplicável.
• Ações falhadas e exceções com responsável, prazo e evidências de encerramento.

Uma política demonstra intenção. Um ticket demonstra coordenação. Um resultado de aplicação ou uma exportação de acessos ajuda a demonstrar a implementação. Nenhum deles deve substituir os outros. As capturas de ecrã podem ser úteis quando não existem exportações mais robustas, mas devem incluir contexto suficiente para identificar o sistema, o sujeito e a hora da observação.

Proteja estes registos: contêm informação laboral e pormenores sensíveis do ponto de vista da segurança. Aplique restrições de acesso e um calendário de conservação e evite recolher palavras-passe, relatos desnecessários sobre a cessação ou caixas de correio inteiras como evidências. Os registos históricos devem continuar compreensíveis mesmo depois de as contas operacionais terem sido eliminadas.

Exemplo prático: uma transferência seguida de uma saída

Considere uma empresa ilustrativa com um fornecedor de identidade central, portáteis geridos e uma aplicação financeira com permissões locais. Suponha que uma colaboradora passa das operações financeiras para o sucesso do cliente a 1 de junho, precisa de cinco dias úteis de passagem de pasta e sai mais tarde, a 30 de setembro. Estas datas e condições são pressupostos de exemplo, não prazos prescritos.

Na mudança, as TI registam as permissões atuais. O acesso ao sucesso do cliente é aprovado, o acesso de escrita à área financeira é removido na hora de efeito e um acesso restrito de leitura à área financeira é mantido até ao fim da passagem de pasta. O responsável pela área financeira aprova essa exceção. Como a aplicação financeira mantém permissões locais, o seu administrador executa e verifica a alteração separadamente da atualização de grupos no fornecedor de identidade.

Na data de expiração, a verificação deteta que permanece uma permissão local de exportação. O registo da mudança mantém-se aberto, o administrador remove a permissão e o revisor regista o estado final. A lição é concreta: a alteração de função teve êxito a nível central, mas o modelo de permissões da aplicação exigiu uma ação adicional.

Na saída posterior, o processo define uma hora de corte precisa, transfere os ficheiros de negócio para um sucessor aprovado, desativa as identidades, revoga as sessões e tokens aplicáveis e verifica diretamente a conta na aplicação financeira. O portátil ainda não chegou por estafeta. A sua devolução permanece como exceção de ativo, com as ações de contenção e as observações do dispositivo registadas separadamente da revogação da conta.

As evidências resultantes mostram tanto as alterações bem-sucedidas como a falha original na remoção. Ocultar a falha faria perder a informação necessária para melhorar o fluxo de trabalho.

Teste a cobertura e concretize a próxima melhoria

Teste por amostragem eventos reais do ciclo de vida face ao inventário de aplicações. Inclua prestadores externos, utilizadores privilegiados, trabalhadores remotos, mudanças com sobreposição temporária e aplicações fora do fornecedor de identidade. As revisões de acessos devem também examinar se as permissões atuais continuam a corresponder às responsabilidades de cada pessoa; complementam as alterações motivadas por eventos, em vez de as substituírem.

Teste os percursos de falha, além da execução normal: um evento dos recursos humanos não comunicado, um conector que falha, um administrador indisponível, uma devolução de dispositivo atrasada ou uma entrada cancelada. Verifique se os alertas chegam a um interveniente e se as novas tentativas ou ações manuais produzem resultados verificáveis.

Medidas úteis incluem o atraso da revogação face à hora de corte acordada, as ações falhadas que aguardam resolução, os acessos temporários em atraso e os eventos encerrados sem verificação. Defina o que cada medida contabiliza. Uma boa média pode esconder uma exceção privilegiada de longa duração. Utilize as conclusões para atualizar os perfis base por função, o comportamento dos conectores, as responsabilidades e as regras de escalamento.

A Secani pode apoiar o registo de controlo passível de revisão, ligando requisitos a sistemas, responsáveis, evidências e decisões. Mantenha as alterações de contas nos sistemas operacionais de identidades e de dispositivos; utilize o espaço de trabalho de conformidade para preservar o âmbito, os resultados carregados, as exceções e as decisões de revisão. Os revisores humanos devem validar quaisquer conclusões sobre evidências assistidas por IA antes de confiarem nelas.

Comece com uma equipa representativa e com uma entrada, uma mudança e uma saída recentes. Siga cada evento desde a comunicação até ao estado real dos sistemas. Corrija a primeira passagem de testemunho ou via de acesso não coberta, atribua-lhe um responsável e volte a testá-la antes de alargar o processo.