Capítulo 7 — Fundamentos de identidade e acesso
Mapa da aula
Aula 07 publicada. Mapa, exemplo, EX019.
flowchart TD
N0["7.1 Identificar, autenticar, autorizar"]
N1["7.2 Tipos de conta"]
N2["7.3 O processo de entrada, mudança e saída"]
N3["7.4 A revisão de acessos"]
N4["7.6 Atividade prática: revisão de acessos"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX019"]
Desenho lógico
flowchart LR
N0["7.1 Identificar, autenticar, autorizar"]
N1["7.2 Tipos de conta"]
N2["7.3 O processo de entrada, mudança e saída"]
N3["7.4 A revisão de acessos"]
N4["7.6 Atividade prática: revisão de acessos"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX019"]
[7.1 Identificar, autenticar, autorizar]
|
v
[7.2 Tipos de conta]
|
v
[7.3 O processo de entrada, mudança e saída]
|
v
[7.4 A revisão de acessos]
|
v
[7.6 Atividade prática: revisão de acessos]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX019]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você deve ser capaz de:
- distinguir identificação, autenticação e autorização, e dizer qual controle atua em cada etapa;
- escolher a força da autenticação pelo que uma conta pode fazer, e não por quem a detém;
- gerenciar os quatro tipos de conta encontrados em todo serviço crítico — pessoal, privilegiada, de serviço e de fornecedor — e as contas compartilhadas que não deveriam existir;
- conduzir uma revisão de acessos que compara as contas com uma lista de pessoal oficial e com uma declaração de necessidade.
Nos relatórios de incidentes do Capítulo 5, o acesso é um fio recorrente: acesso remoto com senhas compartilhadas, contas de fornecedores que nunca foram removidas. Para um implementador, identidade não é um produto; é um conjunto de registros e rotinas que precisam continuar precisos à medida que as pessoas entram, mudam de função e saem.
7.1 Identificar, autenticar, autorizar
Identificação é alegar uma identidade ("sou b.lind"). Autenticação é prová-la — com algo que você sabe (uma senha), tem (uma chave de hardware, um aplicativo autenticador) ou é (uma biometria). Autorização é decidir o que essa identidade pode fazer. As diretrizes de identidade digital do NIST descrevem os tipos de autenticador e os níveis de garantia, e recomendam autenticação multifator resistente a phishing para acessos de maior garantia (NIST SP 800-63B). Na prática: todo acesso privilegiado ou remoto a um host do LANTERN exige autenticação multifator (MFA), e o fator deve resistir a phishing onde a plataforma permitir.
7.2 Tipos de conta
- Contas pessoais pertencem a uma pessoa e são o padrão para todo ser humano.
- Contas privilegiadas podem mudar configurações, contas ou parâmetros de segurança. Devem ser separadas da conta do dia a dia da pessoa, exigir MFA e ser poucas.
- Contas de serviço são usadas por software (o relay gravando no historiador). Devem ter apenas as permissões de que o software precisa, nenhum login interativo, e credenciais que são rotacionadas e guardadas num lugar protegido — não num script.
- Contas de fornecedor dão acesso a uma parte externa. Devem ser limitadas no tempo: habilitadas para um trabalho específico, monitoradas enquanto em uso e desabilitadas depois.
- Contas compartilhadas ("opsuser") são usadas por várias pessoas. Elas destroem a responsabilização — o log diz que "opsuser" fez — e as suas senhas vazam a cada pessoa que sai. Onde um dispositivo realmente não suporta contas individuais, controle a credencial compartilhada num cofre que registre quem a retirou, e quando.
7.3 O processo de entrada, mudança e saída
As contas dão errado nas transições. Quem entra recebe acessos copiados de um colega e herda privilégios de que não precisa. Quem muda de função mantém os acessos antigos ao ganhar os novos. As contas de quem sai continuam habilitadas porque ninguém avisou o dono do sistema. A correção é um processo ligado a uma fonte oficial — a lista de pessoal do RH — e uma revisão de acessos periódica que pegue o que o processo deixou passar.
A exportação do Laboratório 7 mostra as três falhas: c.mendes é alguém que saiu e cuja conta continuou habilitada depois de 31 de agosto, d.reyes mantém administração do historiador de que a Engenharia Clínica não precisa, e vendor-kell é um acesso permanente de fornecedor nunca ligado a um ticket.
7.4 A revisão de acessos
Uma revisão de acessos compara três coisas: as contas que existem num sistema (exportadas dele, e não da memória), a lista de pessoal, com as pessoas e a sua situação, e uma declaração de necessidade — quais papéis cada equipe exige em cada sistema. As constatações caem em tipos reconhecíveis: órfãs (contas sem pessoa correspondente), pessoas que saíram e continuam habilitadas (pior se usadas depois da saída), papéis injustificados, acesso privilegiado sem MFA, contas dormentes, contas compartilhadas e acesso permanente de fornecedor.
Para o RLY-01 e o HIST-01, a exportação lista nove contas, e a lista de pessoal diz que f.ito não corresponde a ninguém.
7.5 Exemplo resolvido: revisão trimestral do RLY-01 e do HIST-01 (sintético)
A exportação tem nove contas; o Laboratório 7 encontra nove constatações em cinco delas. Duas exigem ação imediata, e não um ticket no próximo trimestre. c.mendes saiu em 31 de agosto e a conta foi usada em 14 de setembro: isso é um potencial incidente, e não uma arrumação administrativa — preserve os logs, desabilite a conta e pergunte se outra pessoa usou as credenciais (Capítulo 20). vendor-kell é uma conta de administrador permanente no relay, sem MFA, ociosa há 85 dias. As outras constatações são sérias, mas rotineiras: d.reyes tem administração no historiador, de que a Engenharia Clínica não precisa, sem MFA, e não faz login há 224 dias; opsuser é um administrador compartilhado sem MFA; f.ito nem está na lista de pessoal — talvez um terceirizado registrado em outro lugar, talvez uma conta que ninguém consegue explicar.
Note o que o script não sinaliza: svc-relay não tem MFA, o que é normal para uma conta de serviço, mas o armazenamento e a rotação da sua credencial não são visíveis nesta exportação e precisam ser conferidos à parte.
7.6 Atividade prática: revisão de acessos
Laboratório 7 (salve como lab07.py, execute com python3 lab07.py):
# Lab 7 - quarterly access review for the relay and historian (offline, standard library only)
# Synthetic account export and HR roster; "today" is 2026-10-12.
from datetime import date
today = date(2026, 10, 12)
roster = {"a.okafor": ("Water Ops", "active"), "b.lind": ("FSTS Security", "active"),
"c.mendes": ("Water Ops", "left 2026-08-31"), "d.reyes": ("Clinical Eng", "active"),
"e.strand": ("FSTS Platform", "active")}
accounts = [ # name, system, role, last_login, mfa, kind
("a.okafor", "HIST-01", "operator", "2026-10-10", True, "person"),
("b.lind", "RLY-01", "admin", "2026-10-11", True, "person"),
("c.mendes", "HIST-01", "engineer", "2026-09-14", True, "person"),
("d.reyes", "HIST-01", "admin", "2026-03-02", False, "person"),
("e.strand", "RLY-01", "admin", "2026-10-01", True, "person"),
("opsuser", "HIST-01", "admin", "2026-10-11", False, "shared"),
("svc-relay", "HIST-01", "writer", "2026-10-12", False, "service"),
("vendor-kell", "RLY-01", "admin", "2026-07-19", False, "vendor"),
("f.ito", "RLY-01", "operator", "2026-10-05", True, "person")]
need = {("Water Ops", "HIST-01"): {"operator", "engineer"}, ("FSTS Security", "RLY-01"): {"admin"},
("FSTS Platform", "RLY-01"): {"admin"}, ("Clinical Eng", "HIST-01"): set()}
findings = []
for name, sysid, role, last, mfa, kind in accounts:
idle = (today - date.fromisoformat(last)).days
if kind == "person":
if name not in roster: findings.append((name, sysid, "not on HR roster (orphan)"))
else:
dept, status = roster[name]
if status != "active": findings.append((name, sysid, f"leaver ({status}) still enabled; used after leaving" if last > status[5:] else f"leaver ({status})"))
elif role not in need.get((dept, sysid), set()): findings.append((name, sysid, f"role {role} not justified for {dept}"))
if kind == "shared": findings.append((name, sysid, "shared account: no individual accountability"))
if kind == "vendor" and idle > 30: findings.append((name, sysid, f"vendor account standing, idle {idle} d: make time-bound"))
if role == "admin" and not mfa and kind != "service": findings.append((name, sysid, "privileged without MFA"))
if idle > 90 and kind == "person": findings.append((name, sysid, f"dormant {idle} d"))
for f in findings: print(f"{f[0]:<12} {f[1]:<8} {f[2]}")
print("accounts:", len(accounts), "findings:", len(findings), "accounts with >=1 finding:", len({f[0] for f in findings}))
Saída esperada (Python 3.13.5):
c.mendes HIST-01 leaver (left 2026-08-31) still enabled; used after leaving
d.reyes HIST-01 role admin not justified for Clinical Eng
d.reyes HIST-01 privileged without MFA
d.reyes HIST-01 dormant 224 d
opsuser HIST-01 shared account: no individual accountability
opsuser HIST-01 privileged without MFA
vendor-kell RLY-01 vendor account standing, idle 85 d: make time-bound
vendor-kell RLY-01 privileged without MFA
f.ito RLY-01 not on HR roster (orphan)
accounts: 9 findings: 9 accounts with >=1 finding: 5
Ordene as nove constatações pelo que precisa acontecer hoje. c.mendes, usada em 14 de setembro depois da saída em 31 de agosto, vai para o processo de incidentes: preserve os logs de autenticação antes de desabilitar a conta. vendor-kell, um administrador permanente no relay sem MFA e com 85 dias de ociosidade, é desabilitada e reabilitada apenas mediante ticket. d.reyes, opsuser e f.ito viram tickets com responsáveis. Depois procure o que o script não consegue ver, como a forma de guardar a credencial de svc-relay e quando ela foi rotacionada pela última vez.
7.7 Erros comuns e limites
- Revisar contas a partir de uma lista que alguém digitou, em vez de uma exportação do sistema.
- Copiar os acessos de um colega para quem entra.
- Tratar como item de arrumação a conta de quem saiu que foi usada depois da saída.
- Dar às contas de fornecedor acesso permanente "para ganhar tempo numa emergência"; projete, em vez disso, um processo de habilitação rápido e registrado.
- Exigir MFA para as pessoas, mas deixar os segredos das contas de serviço em scripts em texto claro.
- Remover uma conta compartilhada num dispositivo de controle antes de confirmar como os operadores vão fazer login durante uma emergência.
Uma revisão de acessos mostra o estado das contas num momento. Ela não mostra como as credenciais são usadas, o que exige logs (Capítulo 17), e é tão boa quanto a lista de pessoal e a declaração de necessidade.
Exercícios — capítulo 7
EX019 — Priorize as constatações. Objetivo: separar incidentes de arrumação. Entradas: a saída do Laboratório 7. Restrições: três faixas de prioridade: hoje, esta semana, este trimestre. Etapas: (1) ponha cada constatação numa faixa; (2) para cada item de "hoje", escreva as duas primeiras ações, em ordem. Evidência esperada: tabela. Rubrica: 3 = c.mendes usada depois da saída e o administrador permanente do fornecedor sem MFA em "hoje", com "preservar os logs" antes de "desabilitar" para c.mendes e confirmação com a Kell antes de desabilitar onde a operação depender dela; d.reyes e opsuser nesta semana; f.ito investigada nesta semana; 2 = faixas sensatas, ações na ordem errada; 1 = tudo "hoje"; 0 = nada.
EX020 — Acesso de fornecedor limitado no tempo. Objetivo: projetar um processo de habilitação de fornecedor. Entradas: a Kell Instruments precisa de acesso de administrador ao relay cerca de quatro vezes por ano, às vezes com urgência, à noite. Restrições: precisa ser utilizável às 03:00 pelo tecnólogo de plantão; precisa deixar evidência. Etapas: (1) descreva solicitação, aprovação, habilitação, monitoramento e desabilitação; (2) declare o tempo máximo para habilitar; (3) diga qual evidência é mantida. Evidência esperada: procedimento de no máximo dez etapas. Rubrica: 3 = solicitação ligada a um ticket, aprovação do plantão com a operação informada, conta habilitada por uma janela fixa com MFA, sessão gravada ou registrada, expiração automática, revisão no dia útil seguinte; 2 = falta a expiração ou a evidência; 1 = "habilitar quando pedirem"; 0 = nada.
EX021 — Estenda a revisão. Objetivo: acrescentar uma verificação à ferramenta. Entradas: Laboratório 7. Restrições: apenas a biblioteca padrão. Etapas: (1) acrescente uma verificação que sinalize qualquer pessoa com administração tanto no RLY-01 quanto no HIST-01 (uma concentração de privilégio); (2) acrescente uma conta b.lind no HIST-01 como admin, com MFA e a data de hoje como último login; (3) execute e relate a nova constatação. Evidência esperada: código e saída. Rubrica: 3 = verificação implementada sobre a lista inteira de contas, b.lind sinalizada, nenhum falso alarme; também observa que a nova conta é ela mesma injustificada, porque a FSTS Security não tem necessidade declarada no HIST-01; 2 = funciona sem notar a constatação de necessidade; 1 = não executado; 0 = nada.
Síntese do capítulo
Identidade é um conjunto de registros e rotinas. Autentique pelo que a conta pode fazer; separe contas pessoais, privilegiadas, de serviço e de fornecedor, e remova as compartilhadas ou controle-as num cofre; ligue as contas ao processo de entrada, mudança e saída; e revise-as com regularidade contra uma exportação, uma lista de pessoal e uma declaração de necessidade. Algumas constatações da revisão — a conta de quem saiu usada depois da saída — são incidentes, e a evidência vem antes da limpeza.
Continue estudando — capítulo 07 de 30
← Capítulo 06 · Índice de capítulos do curso · Capítulo 08 →
Siga para a próxima lição escrita.