APRENDER. PRATICAR. EVOLUIR.Começar pela pessoa e pela decisão
No fecho mensal de um serviço fictício de fundos, o fornecedor pede prolongar uma exceção. Antes de discutir uma ferramenta, identifica a alteração permitida, os dados abrangidos, a duração e quem pode aceitar o risco. Uma aprovação expirada não se renova porque a tarefa continua incompleta. Se a política exige duas pessoas, comparar usernames não chega: a mesma pessoa pode controlar duas contas. Regista a identidade responsável por cada aprovação e verifica combinações de funções proibidas. O exercício não impõe um modelo universal a bancos; parte de condições explícitas para mostrar como uma implementação pode cumprir o formulário e falhar o objetivo do controlo.
Verificar o objeto no caminho efetivo
Uma equipa pode consultar relatórios próprios, mas não os de outra equipa. Desenha a decisão com sujeito, ação, objeto e contexto. A existência de login não responde à relação entre a pessoa e o relatório pedido. Se a interface oculta uma ligação e o endpoint de download aceita qualquer identificador, o caminho direto conserva a falha. Prepara testes positivos e negativos, com objetos de equipas diferentes, e observa a decisão no servidor. Para um header de identidade vindo de proxy, verifica também a origem fiável: um cliente que alcança diretamente o backend não deve poder escolher a identidade que o serviço aceita.
Preparar acesso de emergência utilizável
Uma credencial de recuperação guardada num cofre inacessível sem o IdP avariado pode estar bem protegida e continuar inútil no incidente previsto. Analisa a cadeia de dependências do caminho de emergência, incluindo rede, equipamento e autorização. O desenho deve ser previamente aprovado, limitado e observável. No ensaio, demonstra que consegue recuperar a função necessária durante a falha indicada e que a utilização fica registada. A expiração automática ajuda a evitar acesso permanente por esquecimento. A equipa não deve confundir esta preparação com uma autorização aberta para ignorar controlos em qualquer urgência. As condições de ativação e encerramento fazem parte do próprio mecanismo.
A recuperação também estabelece confiança
Um autenticador resistente a phishing não protege a conta se o processo de recuperação o associa à pessoa errada. Num pedido ao helpdesk, conhecer nome, equipa ou número interno pode demonstrar familiaridade, mas não controlo legítimo da identidade. Usa o método aprovado para o contexto e mantém notificações pelo canal estabelecido. Distingue verificação anterior à associação de deteção posterior de recuperação indevida; uma notificação não substitui a primeira. Durante uma janela de manutenção, pode existir uma pessoa de prevenção alternativa que execute a tarefa com autorização própria. Essa opção evita transformar pressão operacional num motivo para partilhar credenciais ou inventar uma prova de identidade mais fraca.
Assinatura válida não basta para aceitar uma asserção
Uma asserção de federação transporta uma afirmação do fornecedor de identidade para a aplicação que nela confia. A aplicação deve avaliar destinatário, emissor, validade e os controlos do protocolo. No exercício, a mesma asserção só pode ser aceite uma vez pela mesma RP. Verificar novamente a assinatura não deteta uma repetição: o conteúdo assinado pode continuar intacto e dentro do prazo. A proteção contra replay deve ser própria do protocolo e não uma regra improvisada para qualquer token. Não confundas asserções de autenticação com credenciais de API que podem ter semântica diferente. Explicita o objeto e a regra antes de construir o teste.
Uma matriz pequena torna a política verificável
Usa uma matriz sintética: utilizador ativo, pertença à equipa, ação permitida e exceção ainda válida. Muda uma condição de cada vez e escreve o resultado esperado antes de executar o teste. Acrescenta casos em que o portal é contornado, a pessoa perdeu a função ou duas contas pertencem ao mesmo aprovador. O objetivo não é provar segurança total com uma tabela; é tornar visível a regra específica e os contraexemplos que a poderiam violar. Na passagem ao RUN, entrega a matriz com os responsáveis, fontes de atributos e tempo esperado para refletir alterações. O resumo é testar a fronteira real e não apenas o percurso feliz da interface.
Exercício: ativo=true, equipa=FUNDOS-A, relatório=FUNDOS-A, ação=ler permite leitura. Alterar só a equipa do relatório para FUNDOS-B deve negar. Dois usernames com o mesmo responsável não cumprem uma regra de duas pessoas.
Armadilhas comuns
Contar contas como pessoas; aprovar extensões implicitamente; ocultar botões como controlo; guardar recuperação atrás da dependência avariada; tratar assinatura como proteção contra replay.
Tópicos relacionados: IAM e federação · Segregação de funções · Testes de autorização
Uma política fica demonstrada por decisões corretas nos caminhos permitidos e proibidos, com identidade, objeto e duração explícitos.
Referência: Security and Privacy Controls · CISSP outline effective April 15, 2024; current AI guidance consulted 2026-09-29