APRENDER. PRATICAR. EVOLUIR.Definir a identidade que permanece durante a transição
Num serviço fictício de processamento de pagamentos, Ana tem uma conta de trabalho e outra administrativa. O nome apresentado no diretório não é suficiente para relacioná-las com segurança: nomes podem coincidir ou mudar. Define identificadores estáveis e regras de associação entre pessoa, contas e sistemas. O exercício guarda pessoas e contas separadamente, com restrições SQL para impedir identidades de conta duplicadas ou referências a pessoas inexistentes. Isso testa a coerência da fixture, não a identidade real de ninguém. Num projeto de IAM, pede evidência da origem do vínculo e de como são resolvidas correspondências ambíguas. Contas de serviço precisam de identidade própria e responsabilidade de gestão; não devem ser transformadas artificialmente em colaboradores para caber numa importação de RH.
Tratar entrada, mudança e saída como estados verificáveis
Na entrada, confirma o vínculo autorizado e os acessos necessários à função antes de provisionar. Numa mudança, compara os acessos antigos e os novos: acrescentar o novo grupo sem rever os anteriores pode acumular privilégios incompatíveis. Uma sobreposição temporária para passagem de conhecimento precisa de finalidade, responsável e prazo explícitos. Na saída, identifica todos os sistemas e credenciais envolvidos, incluindo caminhos que não dependem do diretório central. O laboratório representa Carla como departed, mas a sua conta continua enabled na tabela de estado observado. A política local recusa a utilização e a reconciliação mantém uma ocorrência por resolver. A recusa calculada não executou a desativação num fornecedor externo. O handover deve distinguir evento recebido, trabalho enviado, alteração aplicada e resultado observado.
Conservar incerteza na reconciliação
O vínculo de Duarte está unknown porque a fonte não forneceu estado utilizável. O modelo não converte esse valor em active. Também não o declara despedido: a ocorrência pede esclarecimento da fonte e decisão segundo a política aplicável. Um sistema real precisa de definir como reage a dados ausentes, atrasados ou contraditórios, equilibrando exposição e continuidade com autoridade explícita. Guarda origem, instante da observação e erros de integração. A diferença entre RH e aplicação pode resultar de atraso, associação errada ou falha de execução; não escolhas a causa só pelo número de registos divergentes. Compara a população esperada com a população observada, mantém contas não associadas visíveis e evita excluir silenciosamente as linhas que não conseguiram ser processadas.
Separar os vários prazos de acesso
Eva tem uma conta temporária até às 12:00 UTC, uma associação a grupo até às 11:00 e uma permissão direta de leitura até às 11:30. Às 11:00 deixa de poder preparar pagamentos pelo grupo, mas ainda pode ler relatórios pela permissão independente. Às 11:30 essa leitura expira; às 12:00 a própria conta deixa de ser elegível. O exercício usa a convenção local início não modelado e fim exclusivo: no instante de fim, o acesso correspondente já não está ativo. Instantes com offsets diferentes são normalizados para comparação; valores sem fuso horário são rejeitados. Estes prazos são fictícios e não são limites universais NIST. Testa cada camada e confirma se a aplicação usa estado atual ou uma sessão ou cache anterior. O laboratório não mede essa propagação distribuída.
Gerir identidades de serviço sem interromper por suposição
Batch-service lê relatórios e tem Bruno como responsável; não tem um person associado como se fosse um utilizador humano. Quando Bruno passa a departed, a fixture assinala service-owner-not-active e deixa de considerar a conta elegível na sua política local. Isto demonstra uma lacuna de responsabilidade, não recomenda desligar automaticamente um batch de produção quando o seu dono muda. A organização precisa de um processo para transferir responsabilidade, rever finalidade, credenciais, privilégios e dependências, e decidir medidas proporcionais. Uma conta sem dono não deve desaparecer do inventário nem ser atribuída a uma pessoa ao acaso. Para APS, entrega a lista de consumidores, o procedimento de rotação e recuperação e a evidência de que o dono sucessor aceitou a responsabilidade. Define também quem acompanha falhas de provisionamento fora de horas.
python3 content/labs/cissp-identity-lifecycle/run.py --output /tmp/cissp-identity.json
# In-memory SQLite only; no HR, directory or production account changes.Às 11:00 UTC, Eva perde preparação por grupo, mas mantém leitura direta até às 11:30. São permissões e prazos distintos.
Armadilhas comuns
Nome como identidade; unknown como active; ticket concluído como desativação; conta de serviço tratada como colaborador.
Tópicos relacionados: Ciclo de vida de identidades · Privilégios efetivos e revisão · Separação de funções
Uma transição está demonstrada pelos estados relevantes e pelos acessos observados nos sistemas abrangidos.
Referência: Security and Privacy Controls for Information Systems and Organizations · CISSP outline effective April 15, 2024; current AI guidance consulted 2026-09-29