Capítulo 13 — Identidade e acesso | Graduação Inteligência de ameaças e OSINT

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, EX037.

flowchart TD
  N0["13.1 A identidade como perímetro"]
  N1["13.2 Autenticação multifator"]
  N2["13.3 Relatos de exposição de credenciais"]
  N3["13.4 Contas de serviço e de fornecedores"]
  N4["13.5 Medir o efeito do controle"]
  N5["13.6 Menor privilégio e revisões"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX037"]

Desenho lógico

flowchart LR
  N0["13.1 A identidade como perímetro"]
  N1["13.2 Autenticação multifator"]
  N2["13.3 Relatos de exposição de credenciais"]
  N3["13.4 Contas de serviço e de fornecedores"]
  N4["13.5 Medir o efeito do controle"]
  N5["13.6 Menor privilégio e revisões"]
  N6["Síntese"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX037"]

[13.1 A identidade como perímetro]
    |
    v
[13.2 Autenticação multifator]
    |
    v
[13.3 Relatos de exposição de credenciais]
    |
    v
[13.4 Contas de serviço e de fornecedores]
    |
    v
[13.5 Medir o efeito do controle]
    |
    v
[13.6 Menor privilégio e revisões]
    |
    v
[Síntese]
    |
    v
[Exemplo resolvido] --> [Exercício EX037]

Objetivos de aprendizagem

Você vai (1) explicar por que as credenciais são um alvo privilegiado; (2) ligar a inteligência de identidade aos controles; (3) tratar com responsabilidade os relatos de exposição de credenciais; (4) reconhecer, no nível conceitual, a fadiga de MFA e o roubo de sessão.

13.1 A identidade como perímetro

E-mail na nuvem e acesso remoto significam que uma senha válida pode alcançar sistemas clínicos de qualquer lugar. Valid Accounts (T1078) e Phishing (T1566) muitas vezes se combinam: o phishing captura a credencial e depois o atacante faz login. Por isso a CTI sobre phishing de credenciais leva a controles de identidade, e não só a filtros de e-mail. Amara acompanha um relatório de phishing do HSSC até seu efeito provável no HCHT: uma senha roubada usada para entrar no e-mail na nuvem a partir do exterior. As ações recomendadas vão para a equipe de identidade, além dos administradores de e-mail, e o relatório nomeia os padrões de login a vigiar, para que cada equipe saiba o que deve conferir.

13.2 Autenticação multifator

A MFA bloqueia a maioria dos ataques que dependem só da senha. Os adversários respondem disparando solicitações repetidas até que o usuário aprove uma, ou roubando tokens de sessão depois do login. A inteligência de que esses métodos estão ativos no setor justifica solicitações com correspondência de números e acesso condicional. Amara redige a recomendação com a equipe de identidade, explicando que métodos foram vistos no setor e como cada mudança responde a um deles. A correspondência de números dificulta muito a aprovação às cegas de solicitações repetidas, e o acesso condicional pode recusar logins de dispositivos não gerenciados. A equipe planeja uma implantação em etapas, para que os funcionários clínicos em estações compartilhadas não fiquem bloqueados no meio de um plantão.

13.3 Relatos de exposição de credenciais

Às vezes um parceiro relata endereços de e-mail e senhas do HCHT encontrados em um vazamento público. Trate-os como dados pessoais: restrinja o acesso, nunca cole senhas em chamados, force as redefinições por meio da equipe de identidade e informe o encarregado de proteção de dados. O papel de Amara é repassar o relato pelo canal combinado e registrar que ele foi recebido, e não testar se as senhas ainda funcionam. A equipe de identidade confere as contas e força as redefinições; o encarregado decide se a exposição precisa ser notificada. Uma nota curta registra a fonte, a data e as ações tomadas, sem nenhuma senha.

13.4 Contas de serviço e de fornecedores

Contas compartilhadas de fornecedores são difíceis de atribuir e muitas vezes ficam isentas de MFA. A inteligência sobre comprometimento de fornecedores no setor deve disparar primeiro uma revisão dessas contas. Amara ajuda a compilar uma lista das contas de fornecedores com seus responsáveis, os sistemas que alcançam, se a MFA se aplica e quando cada uma foi usada pela última vez. Várias contas não são usadas há meses e são desativadas depois de conferência com seus responsáveis. As contas que precisam continuar compartilhadas ficam restritas a endereços nomeados e são registradas com mais detalhe, para que seu uso ainda possa ser conferido.

13.5 Medir o efeito do controle

Depois de agir com base na inteligência, confira se o padrão de risco diminuiu: menos logons bem-sucedidos a partir de países novos, menos solicitações repetidas aprovadas. Amara compara as quatro semanas antes e depois da mudança, usando as mesmas consultas e anotando quaisquer outras mudanças que poderiam explicar a diferença, como um período de feriados com menos logins. Se o padrão não diminuiu, a inteligência ou o controle precisa de nova análise. Seu relatório curto inclui as contagens, o período e as limitações, e vai para a equipe de identidade e para o formulário de feedback do HSSC.

13.6 Menor privilégio e revisões

Revisões periódicas de acesso removem as contas de quem saiu e os direitos que não são mais necessários. A inteligência de que atacantes no setor estão reutilizando contas inativas transforma uma revisão de rotina em prioridade: as contas privilegiadas inativas são desativadas primeiro, e os responsáveis confirmam as que precisam continuar. Amara ajuda a equipe de identidade a preparar a lista e registra cada decisão. Os responsáveis têm duas semanas para confirmar que uma conta ainda é necessária; as contas não confirmadas são desativadas e podem ser restauradas a pedido. A revisão se repete a cada trimestre, e o número de contas privilegiadas inativas é acompanhado como medida de progresso.

Exemplo resolvido

O HSSC alerta para uma campanha que envia solicitações falsas de MFA a funcionários da saúde. Amara confere os logs de login com a equipe de identidade: uma enfermeira aprovou uma solicitação às 02:14 a partir de uma localização desconhecida. A conta é redefinida, as sessões são revogadas e a enfermeira é contatada com gentileza, sem culpa. O HCHT ativa a correspondência de números.

Caso sintético. A campanha e o login são inventados.

Erros e limites

Os dados de localização são imprecisos; viagens e VPNs causam marcações falsas. Um tratamento sem culpa mantém os funcionários relatando.

Exercícios

EX037 — Técnicas combinadas. Que duas técnicas do ATT&CK se combinam no phishing de credenciais seguido de login?
Mostrar critérios de avaliação
Rubrica: 3 = T1566 e T1078, na ordem; 2 = os nomes; 1 = uma; 0 = nenhuma.
EX038 — Tratamento do vazamento. Liste três passos de tratamento seguro para um relato de vazamento de credenciais.
Mostrar critérios de avaliação
Rubrica: 3 = restringir o acesso, nenhuma senha em chamados, redefinições pela equipe de identidade/informar o encarregado; 2 = dois; 1 = um; 0 = nenhuma.
EX039 — Conferência do controle. Como o HCHT pode saber se a correspondência de números ajudou?
Mostrar critérios de avaliação
Rubrica: 3 = medir as solicitações suspeitas aprovadas/logons de risco bem-sucedidos antes vs depois; 2 = vago; 1 = supor; 0 = nenhuma.

Síntese

Trate a identidade como o perímetro, transforme a inteligência sobre credenciais em controles de identidade e trate as credenciais expostas como dados pessoais.

Continue estudando — capítulo 13 de 40

← Capítulo 12 (rascunho) · Índice de capítulos do curso · Capítulo 14 (rascunho) →