Capítulo 13 — Identidade e acesso | Graduação Segurança de infraestrutura crítica e setores

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 13 publicada. Mapa, exemplo, EX025.

flowchart TD
  N0["13.1 Três perguntas"]
  N1["13.2 Fatores e acesso remoto"]
  N2["13.3 Papéis e segregação de funções"]
  N3["13.4 O ciclo de vida das contas e as revisões"]
  N4["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX025"]

Desenho lógico

flowchart LR
  N0["13.1 Três perguntas"]
  N1["13.2 Fatores e acesso remoto"]
  N2["13.3 Papéis e segregação de funções"]
  N3["13.4 O ciclo de vida das contas e as revisões"]
  N4["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX025"]

[13.1 Três perguntas]
    |
    v
[13.2 Fatores e acesso remoto]
    |
    v
[13.3 Papéis e segregação de funções]
    |
    v
[13.4 O ciclo de vida das contas e as revisões]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX025]

Objetivos de aprendizagem e conexão

Depois deste capítulo, você consegue (1) distinguir identificação, autenticação e autorização; (2) comparar fatores de autenticação e explicar por que métodos resistentes a phishing importam para o acesso remoto a sistemas críticos; (3) projetar o acesso baseado em papéis com segregação de funções; e (4) conduzir uma revisão de acessos que encontre contas órfãs, inativas, compartilhadas e com combinações tóxicas. O capítulo se apoia no Capítulo 6 (conjuntos) e no Capítulo 11 (privilégio) e prepara o Capítulo 16 (arquitetura) e o Capítulo 24 (controles).

13.1 Três perguntas

A identificação responde a "quem você diz ser?" (um nome de usuário). A autenticação responde a "prove" — com algo que você sabe (uma senha), tem (um token ou celular) ou é (uma impressão digital). A autorização responde a "o que você pode fazer?" — as permissões ligadas à identidade autenticada. Os erros em cada etapa diferem: uma autenticação fraca deixa entrar a pessoa errada; uma autorização excessiva deixa a pessoa certa (ou quem roubou a sessão dela) fazer coisas demais. As diretrizes de identidade digital do NIST definem requisitos para os autenticadores e recomendam opções resistentes a phishing para níveis de garantia mais altos (SP 800-63B).

13.2 Fatores e acesso remoto

As senhas são adivinhadas, reutilizadas e capturadas por phishing. Os códigos de uso único enviados por SMS ou digitados a partir de um aplicativo acrescentam um segundo fator, mas podem ser repassados por uma página de login falsa convincente. Os autenticadores resistentes a phishing ligam o login criptograficamente ao site genuíno, de modo que um site falso não recebe nada utilizável. Para o acesso remoto à TO e a outros sistemas críticos — o caminho do alerta da CPN no Capítulo 5 —, a autenticação forte é necessária, mas não suficiente: a sessão deve cair num jump host controlado, ter tempo limitado, ser aprovada sessão a sessão para fornecedores e ser gravada.

13.3 Papéis e segregação de funções

No controle de acesso baseado em papéis (RBAC), as permissões se ligam a papéis ("scada-operator", "payments-approve") e as pessoas recebem papéis. Os papéis tornam as revisões viáveis: confere-se cinquenta papéis, e não cinquenta mil permissões individuais. A segregação de funções proíbe certas combinações: quem cria um pagamento não pode aprová-lo; o engenheiro que altera a lógica de controle não deveria controlar também o firewall que registra a alteração. Expressa com conjuntos (Capítulo 6), uma combinação tóxica $T$ é violada quando $T \subseteq \text{roles}(u)$.

O Laboratório 7 codifica as duas regras como conjuntos TOXIC e sinaliza chloe, que tem payments-create e payments-approve, e dev, que tem scada-engineer e firewall-admin e, além disso, está inativo há 214 dias.

13.4 O ciclo de vida das contas e as revisões

As contas são criadas quando as pessoas entram (admissão), alteradas quando elas mudam de função (movimentação) e removidas quando saem (desligamento). As falhas se acumulam em cada etapa: quem muda de função mantém os papéis antigos ("acúmulo de privilégios"), as contas de quem saiu permanecem, as contas de fornecedores são criadas para um projeto e nunca removidas, e as contas compartilhadas de operadores tornam as ações não rastreáveis. Uma revisão de acessos compara as contas com uma fonte autoritativa (o sistema de RH, o registro de contratos de fornecedores) e com o uso.

O Laboratório 7 mostra cada falha: ben saiu, mas manteve a sua conta, vendorx não tem dono no RH e não faz login há 304 dias, e ops1 é compartilhada. Os dados de uso importam tanto quanto a situação no RH: dev está ativo no RH, mas inativo há 214 dias num papel privilegiado.

13.5 Exemplo resolvido e Laboratório 7 (sintético)

Este caso é sintético. Uma revisão conjunta das contas do sistema de controle da CPN e do sistema de pagamentos da Calder Mutual (combinados aqui só para fins didáticos) usa a situação no RH, o último login e duas combinações tóxicas.

# Lab 7 - access review: orphans, dormant accounts and toxic combinations (synthetic, offline)
from datetime import date
TODAY = date(2026, 10, 1)
HR = {"ana": "active", "ben": "left", "chloe": "active", "dev": "active"}
ACCOUNTS = [  # user, roles, last login, shared?
    ("ana",   {"scada-operator"},                       date(2026, 9, 30), False),
    ("ben",   {"scada-engineer"},                       date(2026, 5, 2),  False),
    ("chloe", {"payments-create", "payments-approve"},  date(2026, 9, 29), False),
    ("dev",   {"scada-engineer", "firewall-admin"},     date(2026, 3, 1),  False),
    ("ops1",  {"scada-operator"},                       date(2026, 9, 30), True),
    ("vendorx", {"remote-support"},                     date(2025, 12, 1), False),
]
TOXIC = [{"payments-create", "payments-approve"}, {"scada-engineer", "firewall-admin"}]
for user, roles, last, shared in ACCOUNTS:
    issues = []
    if user not in HR: issues.append("no HR owner")
    elif HR[user] != "active": issues.append("owner has left")
    if (TODAY - last).days > 90: issues.append(f"dormant {(TODAY - last).days} d")
    if shared: issues.append("shared account")
    issues += ["toxic: " + "+".join(sorted(t)) for t in TOXIC if t <= roles]
    print(f"{user:8} {', '.join(issues) if issues else 'ok'}")

Saída esperada:

ana      ok
ben      owner has left, dormant 152 d
chloe    toxic: payments-approve+payments-create
dev      dormant 214 d, toxic: firewall-admin+scada-engineer
ops1     no HR owner, shared account
vendorx  no HR owner, dormant 304 d

Ações: desativar ben agora (desligamento); remover um dos papéis de pagamento de chloe; remover os papéis privilegiados inativos de dev e perguntar se ele precisa de algum deles; ops1 é um login compartilhado da sala de controle — comum em operações 24/7, em que uma troca de turno rápida importa —, então substitua-o por logins individuais e troca rápida de usuário ou, no mínimo, registre quem está no turno; vendorx deve ser desativada e reativada a cada sessão de suporte, sob um patrocinador nomeado. Note o que o script não consegue ver: se o papel de ana ainda corresponde ao trabalho dela.

13.6 Erros comuns e limites

Igualar "autenticado" a "autorizado".
Revisões que confirmam que as contas existem, e não se elas são necessárias.
Remover contas compartilhadas numa sala de controle sem uma alternativa viável, de modo que a equipe passa a compartilhar senhas.
Esquecer as contas de serviço e de fornecedores, que não têm registro no RH.

No Laboratório 7, o script confirma que a conta de ana está "ok" só no sentido de que ela está ativa e não inativa; se ela ainda precisa de scada-operator exige a gestora dela. Remover ops1 de uma vez levaria a sala de controle a compartilhar a senha de uma pessoa, o que é pior. E ops1 e vendorx aparecem ambas com "no HR owner", que é o sinal de que as contas de serviço e de fornecedores precisam de outra fonte autoritativa, como o registro de contratos.

Exercícios — capítulo 13

EX025 — Projete os papéis. Objetivo: aplicar o menor privilégio e a segregação de funções. Entradas: o CEDC precisa de atendentes, despachantes, supervisores, um administrador do CAD e um engenheiro de suporte do fornecedor. Etapas: defina cinco papéis com as permissões principais e duas combinações tóxicas. Evidência esperada: tabela de papéis e combinações. Rubrica: 3 = papéis sensatos de menor privilégio, pares tóxicos justificados (por exemplo, administrador do CAD + administrador do log de auditoria; suporte do fornecedor + acesso permanente); 2 = papéis sem combinações; 1 = vago; 0 = nada.

EX026 — Estenda a revisão. Objetivo: acrescentar uma regra. Entradas: Laboratório 7. Etapas: acrescente uma verificação que sinalize qualquer conta com um papel privilegiado (scada-engineer, firewall-admin, payments-approve) que não tenha sido reaprovada em 180 dias, dado um novo campo approved (uma data). Escolha as datas de modo que pelo menos uma conta seja sinalizada e mostre a saída. Evidência esperada: código e saída. Rubrica: 3 = lógica correta, dados de teste escolhidos para mostrar casos sinalizados e não sinalizados; 2 = funciona, teste fraco; 1 = erro de lógica; 0 = nada.

Síntese do capítulo

A identidade responde a três perguntas diferentes. Use autenticação forte e resistente a phishing para o acesso remoto crítico, conceda permissões por meio de papéis, proíba combinações tóxicas e revise as contas contra fontes autoritativas e o uso real. As contas compartilhadas e de fornecedores precisam de alternativas viáveis, e não apenas de proibições.