APRENDER. PRATICAR. EVOLUIR.Reconstituir o acesso efetivo
Ana-user recebe prepare em payments-prod por uma permissão direta e por payment-makers. Chega a esse grupo através de operations e alternate. Contar associações ou analisar apenas concessões diretas não responde ao que pode fazer. A consulta recursiva SQLite visita pares distintos de tipo e identificador, usando UNION para terminar mesmo quando os grupos têm um ciclo. O resultado agrega a mesma operação no mesmo recurso e mostra g-direct e g-group como origens de concessão. Não enumera todos os caminhos possíveis nem prova que o inventário externo esteja completo. O modelo aceita herança transitiva por escolha didática; não reproduz regras particulares de Active Directory ou Entra. Num sistema concreto, confirma que tipos de grupos, funções e aplicações realmente propagam acesso.
Avaliar combinações por pessoa e contexto
Ana-admin pode approve em payments-prod. Cada conta isolada tem uma função, mas ambas pertencem a Ana: o modelo identifica a combinação prepare/approve na mesma pessoa e recurso. Separar nomes de conta não cria duas pessoas independentes. Bruno tem prepare em payments-prod e approve em payments-test; essa combinação não viola a regra local, porque os recursos são distintos. Define incompatibilidades com finalidade e âmbito, evitando tanto omissões como falsos positivos. O ensaio só deteta a combinação; não implementa bloqueio de transações reais. Uma regra que impede alguém de aprovar o pagamento que criou precisa ainda de contexto da operação e identidade do criador. A separação reduz oportunidades de abuso individual, mas não elimina conluio nem substitui observação e investigação.
Dar ao revisor contexto suficiente
Um revisor recebe o pedido de retirar g-direct de Ana-user. Deve compreender a pessoa associada, função, recurso, atividade relevante, motivo de manutenção e outras origens de acesso. Um clique sem contexto pode confirmar um privilégio desnecessário ou remover uma dependência legítima. No modelo, a política permite apenas reviewer como decisor e impede revisão pelo próprio titular ou dono da conta; estes identificadores são fictícios, não autenticação real. A decisão fica ligada ao snapshot dos dados. Se surgir uma concessão nova antes da aplicação, a transição é recusada até reavaliação. Essa comparação deteta mudança no conteúdo, mas não valida assinaturas ou garante concorrência distribuída. Os controlos e períodos de revisão devem ser definidos pela organização; não se inventa uma frequência universal a partir do exame.
Separar decisão, aplicação e efeito
Registar revoke não apaga g-direct. A aplicação da decisão remove efetivamente essa linha da base sintética, mas prepare continua disponível por g-group. O relatório devolve effectiveAccessStillPresent=true. A execução técnica correspondeu à ação delimitada e, ainda assim, não retirou a capacidade final. Depois de eliminar a associação operations, o caminho alternate continua a conceder acesso. Só a remoção do caminho restante fecha essa permissão no modelo. Repetir a aplicação da mesma revisão é no-op e devolve o resultado histórico, não uma nova prova do estado atual. Em produção, acompanha execução nos conectores, erros, caminhos residuais e validação posterior. Uma decisão retain ou defer não autoriza a transição de remoção implementada neste exercício.
Usar evidência para aceitar o serviço
Prepara uma matriz com pessoa, conta, recurso, operação, origens de concessão, decisão, aplicação e resultado. Inclui permissões legítimas que devem sobreviver: o exercício confirma que batch-service continua a ler relatórios depois da correção de Ana. Uma alteração que remove tudo não satisfaz automaticamente a continuidade necessária. Regista casos não avaliados, fontes desatualizadas e exceções com autoridade e validade. As 43 verificações executadas duas vezes cobrem SQL e política local, sem IdP, RH, LDAP, SCIM, MFA ou propagação de sessões. O resultado não é uma certificação de conformidade. Usa o exercício para preparar critérios de projeto e ensaios representativos, com responsabilidade explícita pela análise de conflitos, revisão e aplicação. A matéria aprofunda CISSP 5.4 e 5.5, com ligações a risco de pessoal e operação.
# Inspect observations in the generated evidence
# initialRights -> two grant sources, one effective permission
# appliedDirectRemoval.result.effectiveAccessStillPresent -> true
# conflicts -> one person, two accounts, same resourceA revisão remove g-direct, mas g-group mantém prepare. O sucesso da operação de remoção não demonstra retirada da capacidade.
Armadilhas comuns
Duas contas como duas pessoas; remoção direta como ausência de herança; ciclos como pesquisa infinita; snapshot como autenticação.
Tópicos relacionados: Ciclo de vida de identidades · Privilégios efetivos e revisão · Separação de funções
Revê a capacidade efetiva e o seu contexto, seguindo cada decisão até ao resultado que o requisito exige.
Referência: Security and Privacy Controls for Information Systems and Organizations · CISSP outline effective April 15, 2024; current AI guidance consulted 2026-09-29