Capítulo 13 — Identidade e acesso
Mapa da aula
Aula 13 publicada. Mapa, exemplo, EX037.
flowchart TD
N0["13.1 AuthN/AuthZ"]
N1["13.2 Contas de teste"]
N2["13.3 Administradores compartilhados"]
N3["13.4 MFA"]
N4["13.5 Contas de serviço"]
N5["13.6 Desligados"]
N6["13.7 Expirar as contas de teste automaticamente"]
N7["13.8 Contas break-glass"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX037"]
Desenho lógico
flowchart LR
N0["13.1 AuthN/AuthZ"]
N1["13.2 Contas de teste"]
N2["13.3 Administradores compartilhados"]
N3["13.4 MFA"]
N4["13.5 Contas de serviço"]
N5["13.6 Desligados"]
N6["13.7 Expirar as contas de teste automaticamente"]
N7["13.8 Contas break-glass"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]
[13.1 AuthN/AuthZ]
|
v
[13.2 Contas de teste]
|
v
[13.3 Administradores compartilhados]
|
v
[13.4 MFA]
|
v
[13.5 Contas de serviço]
|
v
[13.6 Desligados]
|
v
[13.7 Expirar as contas de teste automaticamente]
|
v
[13.8 Contas break-glass]
|
v
[Exemplo resolvido] --> [Exercício EX037]
Objetivos de aprendizagem
Você vai (1) separar AuthN e AuthZ; (2) aplicar o menor privilégio às contas de teste; (3) mapear contas compartilhadas para a T1078.
13.1 AuthN/AuthZ
Provar identidade versus permitir ações. O IDOR é uma falha de AuthZ depois da AuthN. A autenticação responde quem está fazendo a requisição, por meio de uma senha, passkey ou token. A autorização responde se essa pessoa pode fazer esta coisa específica com este objeto específico. Uma referência direta insegura a objeto acontece quando uma aplicação verifica a primeira e pula a segunda. Um cliente faz login corretamente, depois troca um número de conta na URL de um extrato e recebe o extrato de outra pessoa. No TRB, Sam testa a autorização fazendo login como um cliente sintético e pedindo objetos que pertencem a um segundo cliente sintético; assim, um sucesso prova a falha sem tocar nos dados de nenhuma pessoa real.
13.2 Contas de teste
Nominais, temporárias, guardadas no cofre, com menor privilégio. Cada propriedade evita uma falha específica. Uma conta nominal, como rt-sam-cust01, liga toda ação nos logs a um único testador, o que uma conta compartilhada não consegue fazer. Uma conta temporária expira quando a janela fecha; assim, uma credencial esquecida se torna inútil em vez de virar uma porta dos fundos. Guardar as credenciais no cofre as mantém fora de mensagens de chat e de arquivos de anotações. Menor privilégio significa que a conta tem apenas os direitos de que os testes planejados precisam. Testar uma falha voltada ao cliente com uma conta de administrador não provaria nada sobre o que um cliente pode fazer e acrescentaria risco se a sessão fosse sequestrada.
13.3 Administradores compartilhados
Perda de responsabilização; ATT&CK T1078 Valid Accounts. Quando cinco administradores compartilham uma conta, o log mostra que o admin fez uma mudança, mas não qual pessoa a fez. Isso atrapalha as investigações e deixa os erros sem dono. Credenciais compartilhadas também viajam. Elas são escritas em scripts, documentos de integração e arquivos de configuração, de modo que sobrevivem às pessoas que as conheciam. O ATT&CK lista o abuso de credenciais legítimas como Valid Accounts porque um atacante usando uma senha real de administrador parece administração normal. O achado de Sam para uma conta de administrador compartilhada recomenda contas nominais que possam elevar direitos e registra onde a senha compartilhada foi encontrada armazenada.
13.4 MFA
Verificar pela revisão de configuração, não fazendo phishing com funcionários. A pergunta é se a autenticação multifator está imposta em toda rota que importa, e a configuração do provedor de identidade responde a isso diretamente: quais aplicações a exigem, quais grupos estão isentos e se protocolos legados que a contornam ainda estão habilitados. Enviar e-mails de phishing a funcionários reais para descobrir envolveria pessoas que não consentiram em ser testadas neste engajamento e mediria o comportamento delas, e não o controle. Sam exporta as políticas de acesso condicional e confirma uma isenção com uma conta de teste autorizada. O achado nomeia a lacuna com precisão, por exemplo que um endpoint IMAP aceita senhas sem um segundo fator.
13.5 Contas de serviço
Donos e datas de rotação obrigatórios. As contas de serviço permitem que aplicações falem com bancos de dados e APIs sem uma pessoa presente, o que também significa que ninguém percebe quando são mal usadas. Uma conta sem dono nomeado não pode ser rotacionada com segurança, porque ninguém sabe quais sistemas vão quebrar quando a senha mudar; por isso, ela geralmente nunca muda. A revisão de Sam lista toda conta de serviço com seu dono, a data da última rotação e os direitos que ela detém e, em seguida, sinaliza as que não têm dono, as rotacionadas há mais de um ano e as que têm direitos de logon interativo de que não deveriam precisar. A correção mais comum é tornar a conta não interativa.
13.6 Desligados
Acesso que persiste depois do desligamento no RH é um achado clássico. A lacuna geralmente vem de um processo com várias passagens de bastão. O RH registra a data de saída, a TI desativa a conta do diretório e ninguém remove as contas locais, os logins de SaaS criados fora do single sign-on ou o certificado de VPN. Sam testa isso pegando um registro sintético de desligado e verificando cada sistema a que a função tinha acesso. Encontrar um único login sobrevivente basta para um achado. A recomendação trata do processo, por exemplo dirigir o desprovisionamento a partir do evento do RH e listar todo sistema que fica fora do single sign-on, não só a conta que por acaso foi encontrada.
13.7 Expirar as contas de teste automaticamente
A expiração das contas de teste é imposta por uma rotina que desativa as contas no fim da janela e aciona Sam se a desativação falhar. Os lembretes manuais falharam duas vezes no passado; a rotina agora é um controle, não uma conveniência. O acionamento em caso de falha é a parte importante. Uma rotina que falha em silêncio é pior que nenhuma rotina, porque todos acreditam que as contas estão desativadas. A desativação pode falhar quando o serviço de identidade está em manutenção ou quando uma conta foi renomeada, e cada falha deixa uma credencial funcionando por aí. O acionamento vai para o testador e para o líder de segurança juntos. Nenhum dos dois pode encerrar o engajamento até que ambos confirmem que a conta está desativada.
13.8 Contas break-glass
Os administradores break-glass são monitorados e raros. A revisão de Sam confere que a conta break-glass não foi usada como conta do dia a dia durante a janela. Uma conta break-glass existe para o dia em que o sistema de identidade normal falha. Ela contorna o single sign-on e geralmente a autenticação multifator, o que a torna poderosa e perigosa. Suas credenciais ficam lacradas, e qualquer uso deve produzir um alerta e uma justificativa escrita. O teste é simples: contar seus logins no último trimestre e compará-los com as emergências registradas. Se os logins superam as emergências, alguém está usando a conta por conveniência. O achado então recomenda corrigir o problema de acesso normal que levou as pessoas a ela.
13.9 Confirmar que o cofre nega acesso sem MFA
O acesso ao cofre de credenciais exige MFA. Sam testou a negação sem MFA e registrou a negação como demonstração de um controle positivo. Os controles merecem evidência quando funcionam, não só quando falham. O teste usou uma conta de teste com a senha correta e sem segundo fator e registrou a recusa do cofre junto com sua entrada de log. Registrar essa recusa como um controle positivo significa que a próxima auditoria pode se apoiar em evidência datada, em vez de numa captura de tela da configuração. Isso também define uma referência. Se um teste posterior com a mesma conta tiver sucesso, algo mudou, e o registro anterior mostra exatamente quando se sabia que o controle funcionava pela última vez.
13.10 Uma senha rotacionada encontrada numa impressora
Uma senha de administrador compartilhada no sistema de empréstimos é rotacionada, mas a mesma senha é encontrada depois na configuração de uma impressora. A lista de verificação de desligados e segredos de Sam agora inclui "procurar artefatos de reutilização de senha" depois de qualquer achado de administrador compartilhado. A rotação corrigiu um sistema e deixou o segredo antigo funcionando onde quer que ele tivesse sido reutilizado. Anos antes, alguém tinha configurado na impressora a digitalização para pasta com as credenciais do administrador de empréstimos, e a interface web da impressora mostrava a senha a qualquer pessoa na rede. Uma senha compartilhada geralmente tem uma história; por isso, a busca cobre scripts, tarefas agendadas, configurações de dispositivos e documentação, não só o sistema em que ela foi encontrada primeiro.
13.11 Testar o alerta de break-glass
O uso de break-glass durante uma janela aciona automaticamente o canal do CISO. Sam testou o acionamento com uma conta break-glass de staging e recebeu um telefonema severo, mas correto. O telefonema foi a evidência de que o alerta funciona, porque mostrou que uma pessoa respondeu, e não apenas que uma mensagem foi enviada. Antes do teste, Sam combinou o horário com o líder de segurança e o registrou no log do engajamento, para que a ligação pudesse ser resolvida rapidamente. Quem atendeu ainda seguiu o procedimento completo e perguntou quem estava usando a conta, por que e sob qual autoridade. Esse é o comportamento certo, já que um atacante também poderia alegar estar fazendo um teste.
13.12 Auditar a automação de desligados
Os tickets de desligados se abrem automaticamente a partir dos eventos do RH em até uma hora; Sam audita a automação toda semana. A automação desloca o risco em vez de removê-lo. Se o elo entre o sistema de RH e a ferramenta de tickets quebrar, os desligados param de gerar tickets em silêncio e ninguém vê um ticket ausente. A auditoria semanal compara os desligamentos da semana no RH com os tickets abertos e confere que cada ticket foi fechado com todos os sistemas listados confirmados. Numa semana, as contagens diferiram em três. Uma mudança de esquema na exportação do RH tinha renomeado o campo da data de saída, e a integração pulou esses registros sem relatar erro.
13.13 Procurar segredos nas configurações de dispositivos
As configurações de impressoras agora estão no caminho da busca de segredos, depois do incidente de reutilização. Lugares estranhos escondem senhas. Impressoras, armazenamento em rede, controladores de porta e sistemas de salas de reunião frequentemente se autenticam em servidores, e suas páginas de configuração podem guardar essas credenciais de forma legível. Poucas equipes pensam neles como lugares onde vivem segredos; por isso, raramente são rotacionados ou revisados. A busca ampliada usa exportações de configuração coletadas pelos donos dos dispositivos com permissão, e não logins em cada dispositivo durante o teste. As credenciais encontradas são relatadas aos donos e rotacionadas. O testador não as usa, porque usar uma credencial encontrada num dispositivo testaria um sistema fora dos métodos acordados.
13.14 Manter a busca de segredos dentro do escopo
As ampliações do caminho da busca de segredos são registradas; a expansão de escopo na busca continua sendo escopo. Cada novo local acrescentado à busca, como exportações de impressoras, um espaço da wiki ou um compartilhamento de arquivos, é registrado com a data, o aprovador e o motivo. Uma busca por senhas lê dados que podem conter informações pessoais e segredos de outras equipes; por isso, precisa da mesma autorização que qualquer outro método de teste. O registro também explica os resultados. Um salto repentino nos segredos encontrados num trimestre só tem significado se os leitores souberem se o banco piorou ou se a busca simplesmente olhou em mais lugares.
Exemplo resolvido (TRB sintético)
O administrador compartilhado no sistema de empréstimos vira F1, com pontuação 6 no lab_rank.
Caso sintético — Riverstone Transit Bank (TRB). O banco, Sam Ito, TrackScope/FindingsDesk/PulseMap e todos os números são inventados para fins didáticos.
Erros e limites
Este livro não concede nenhuma autoridade para testar bancos ou sistemas de pagamento reais. Os laboratórios usam apenas endereços de faixas de documentação e dados sintéticos; código de exploit nunca é fornecido.
Exercícios
- EX037 — T1078. Que técnica corresponde a senhas válidas de administrador compartilhadas? Rubrica: 3 = T1078 Valid Accounts; 2 = o nome; 1 = errado; 0 = nada.
- EX038 — Método para o MFA. Como verificar o MFA sem phishing? Rubrica: 3 = revisão de configuração/política sob as ROE; 2 = parcial; 1 = phishing; 0 = nada.
- EX039 — Características da conta de teste. Liste três características de uma boa conta de teste. Rubrica: 3 = nominal, menor privilégio, temporária/no cofre; 2 = duas; 1 = uma; 0 = nada.
Síntese
Os achados de identidade são precisos quanto a AuthN vs AuthZ e nunca exigem fazer phishing com colegas.
Continue estudando — capítulo 13 de 40
← Capítulo 12 (rascunho) · Índice de capítulos do curso · Capítulo 14 (rascunho) →