# Beephish – Gestão de Risco Humano

> Eduque, teste e monitore seus colaboradores contra phishing. +100.000 usuários treinados na plataforma brasileira de Gestão de Risco Humano.

Canonical: https://beephish.com/blog/identidade-privilegios-e-blast-radius

Quando avaliamos risco humano, comportamento costuma ser a informação mais visível. Um usuário clicou em uma simulação de phishing, compartilhou uma informação de forma inadequada ou utilizou uma aplicação não autorizada. Esses eventos são relativamente fáceis de identificar e, por isso, frequentemente acabam tendo grande influência nos modelos de risco.

Existe, entretanto, outra pergunta que precisa fazer parte dessa análise: o que aconteceria se essa identidade fosse realmente comprometida?

A resposta pode variar radicalmente entre duas pessoas que apresentaram exatamente o mesmo comportamento. Uma identidade pode oferecer acesso a poucos recursos corporativos, enquanto outra permite administrar infraestrutura, consultar informações confidenciais, alterar configurações ou alcançar sistemas essenciais para a operação. O evento comportamental pode ser idêntico, mas as consequências potenciais são completamente diferentes.

É nesse ponto que identidade, privilégios e _blast radius_ passam a ter um papel importante em Human Risk Management. Se queremos medir risco, precisamos compreender não apenas a probabilidade de algo acontecer, mas também até onde um atacante poderia chegar caso conseguisse controlar determinada identidade.

## **O comprometimento começa pela identidade, mas raramente termina nela**

Em muitos ataques modernos, a credencial ou sessão de um usuário funciona apenas como ponto inicial. Depois de obter acesso, o atacante procura entender quais recursos aquela identidade consegue alcançar, quais aplicações utiliza, quais grupos integra e quais oportunidades existem para aumentar privilégios ou alcançar outros ambientes.

Por isso, dizer que uma pessoa possui acesso ao Microsoft 365, por exemplo, explica muito pouco sobre seu impacto potencial. Duas identidades autenticadas no mesmo ambiente podem possuir capacidades completamente diferentes. Uma pode acessar apenas seu próprio e-mail e alguns documentos. Outra pode administrar grupos, aplicações, dispositivos ou configurações relevantes.

A mesma lógica existe em praticamente qualquer ambiente corporativo. Sistemas financeiros, aplicações SaaS, infraestrutura cloud, repositórios de código, ferramentas administrativas e bancos de dados possuem diferentes níveis de autorização. A identidade funciona como a chave que conecta a pessoa a esses recursos.

Para avaliar impacto, portanto, precisamos deixar de olhar apenas para a existência da conta e começar a compreender aquilo que essa conta efetivamente permite fazer.

## **Privilégio não é apenas ser administrador**

Quando falamos em privilégio, é comum pensar imediatamente em contas de administrador. Elas certamente são importantes, mas representam apenas uma parte do problema.

Uma pessoa pode não possuir qualquer função formalmente classificada como administrativa e ainda assim ter capacidade de executar operações extremamente relevantes para o negócio. Um profissional financeiro pode autorizar pagamentos. Uma pessoa de RH pode acessar grandes volumes de dados pessoais. Um desenvolvedor pode publicar código ou possuir acesso a ambientes de produção. Um executivo pode aprovar operações ou acessar informações estratégicas.

Do ponto de vista de risco, privilégio precisa ser interpretado de maneira mais ampla: quais ações aquela identidade está autorizada a executar e quais consequências essas ações podem produzir? Isso significa que uma arquitetura de HRM não deveria depender apenas de um atributo dizendo se alguém é ou não administrador. Precisamos compreender grupos, papéis, permissões, aplicações acessíveis e criticidade dos recursos relacionados àquela identidade.

Em outras palavras, não basta saber que existe acesso. Precisamos entender o que aquele acesso permite.

## **Privilégio direto é apenas uma parte da história**

Outro desafio aparece quando começamos a analisar como permissões realmente funcionam. Nem todo acesso relevante está diretamente atribuído ao usuário.

Uma pessoa pode receber permissões por meio de grupos, funções, associações organizacionais ou outras identidades relacionadas. Também pode possuir uma conta administrativa separada da conta utilizada diariamente. Em ambientes cloud e SaaS, permissões podem ainda estar distribuídas entre diferentes serviços e modelos de autorização.

Isso cria uma diferença importante entre olhar para uma lista simples de permissões e compreender a superfície efetiva de acesso daquela pessoa.

Imagine um usuário cuja conta principal possui poucos privilégios. Se essa mesma pessoa também controla uma identidade administrativa capaz de alterar configurações críticas, analisar somente a primeira conta produzirá uma visão completamente equivocada do impacto potencial.

É por isso que a resolução de identidade discutida quando falamos de Human Risk Observability é tão importante. Antes de calcular impacto, precisamos saber quais identidades digitais, contas e privilégios pertencem ou estão relacionados à mesma pessoa.

## **Blast radius ajuda a responder até onde um comprometimento pode chegar**

O conceito de _blast radius_ é bastante útil para representar essa discussão. Em segurança, podemos utilizá-lo para pensar no alcance potencial de um comprometimento: se determinada identidade for controlada por um atacante, quais recursos, informações e operações passam a estar potencialmente expostos?

Uma identidade com pequeno _blast radius_ pode acessar poucos recursos e possuir baixa capacidade de afetar outros componentes do ambiente. Outra pode alcançar sistemas críticos, informações sensíveis ou funções administrativas capazes de ampliar ainda mais o comprometimento.

Isso não significa que precisamos prever exatamente todos os passos que um atacante executaria. O objetivo é compreender o alcance potencial associado à identidade.

Essa análise pode considerar quantidade e criticidade dos sistemas acessíveis, privilégios existentes, informações disponíveis, capacidade de alterar configurações, possibilidade de administrar outras identidades e participação em processos de negócio relevantes.

Quanto maior for esse alcance e mais críticos forem os recursos envolvidos, maior tende a ser a dimensão de impacto associada àquela identidade.

## **Quantidade de acessos não é uma boa medida de impacto**

Uma das armadilhas mais simples seria calcular _blast radius_ contando quantos sistemas uma pessoa consegue acessar. Isso produziria uma métrica fácil de implementar, mas potencialmente enganosa.

Um usuário pode possuir acesso a vinte aplicações de baixa criticidade enquanto outro possui acesso administrativo a apenas um sistema responsável por uma operação essencial da empresa. Contar aplicações faria o primeiro parecer mais relevante, mesmo que o impacto potencial do segundo fosse muito maior.

A criticidade precisa fazer parte do modelo.

Isso exige alguma forma de classificação dos recursos. Sistemas relacionados à operação essencial, informações sensíveis, infraestrutura, identidade, pagamentos ou propriedade intelectual podem possuir impactos diferentes. Da mesma maneira, ler informações, modificá-las, excluí-las ou administrar o sistema são capacidades distintas.

Um modelo mais útil precisa, portanto, considerar pelo menos duas perguntas: **o que a identidade consegue alcançar e o que consegue fazer quando chega lá?**

É a combinação dessas respostas que começa a transformar acesso em impacto.

## **Algumas identidades permitem ampliar o próprio blast radius**

Existe ainda uma categoria especialmente importante: identidades que conseguem modificar o próprio ambiente de acesso ou conceder privilégios a outras identidades.

Se um atacante compromete uma conta que possui capacidade de administrar grupos, criar credenciais, alterar permissões ou controlar outras identidades, o alcance potencial não está limitado aos recursos originalmente disponíveis para aquela conta. O atacante pode utilizar o privilégio inicial para ampliar sua capacidade.

Isso torna determinadas permissões especialmente relevantes para um modelo de impacto. A capacidade de gerenciar identidade, alterar controles de segurança, criar novas credenciais ou administrar infraestrutura pode produzir um efeito multiplicador.

Nesse cenário, analisar apenas os recursos diretamente acessíveis subestima o risco. Precisamos considerar também os caminhos que aquela identidade pode abrir.

Essa perspectiva aproxima o HRM de conceitos já utilizados em Identity Security e análise de caminhos de ataque. Não significa transformar a plataforma de Human Risk Management em uma ferramenta de Attack Path Management, mas utilizar informações produzidas por essas tecnologias para compreender melhor o impacto associado às pessoas.

## **Impacto e probabilidade precisam permanecer dimensões diferentes**

Existe uma razão importante para não transformar imediatamente _blast radius_ em Human Risk Score. Impacto potencial não é sinônimo de risco total.

Um administrador global pode possuir impacto extremamente elevado caso sua identidade seja comprometida, mas utilizar autenticação resistente a phishing, trabalhar em um dispositivo fortemente protegido, apresentar excelente comportamento e possuir baixa exposição externa. Outra identidade pode ter impacto menor, mas apresentar diversos sinais recentes de exposição e comportamento de risco.

Esses cenários precisam permanecer distinguíveis. Uma arquitetura madura deveria ser capaz de representar que determinada identidade possui alto impacto potencial sem afirmar automaticamente que ela é a identidade com maior risco naquele momento.

Essa separação também melhora a explicabilidade. Se um executivo aparece com score elevado, precisamos conseguir dizer se isso aconteceu por comportamento, exposição, privilégios, impacto ou pela combinação dessas dimensões.

Sem essa decomposição, o score perde grande parte de seu valor para tomada de decisão.

## **O contexto organizacional também altera o impacto**

Nem todo impacto pode ser calculado apenas olhando para permissões técnicas. Algumas pessoas possuem capacidade de produzir consequências relevantes por causa da função que exercem. Executivos são um bom exemplo. Um atacante que compromete a identidade de um executivo pode utilizar aquela posição para realizar impersonation, solicitar pagamentos, pressionar colaboradores ou criar comunicações extremamente convincentes. Mesmo quando a conta comprometida não possui privilégios administrativos, a autoridade associada àquela identidade possui valor.

O mesmo acontece em áreas como finanças, compras, jurídico e recursos humanos. Algumas funções participam de processos nos quais confiança e autoridade possuem tanta importância quanto uma permissão técnica.

Isso significa que a dimensão de impacto precisa combinar informações técnicas com contexto organizacional. Cargo, função, área, responsabilidade sobre processos e criticidade do papel podem complementar aquilo que IAM e IGA conseguem mostrar.

Human Risk Management trabalha justamente nessa interseção. A identidade digital possui acessos, mas a pessoa por trás dela também ocupa uma posição dentro da organização.

## **Mudanças de acesso precisam alterar o risco**

Outra consequência importante é que impacto não pode ser tratado como uma característica permanente da pessoa.

Um colaborador pode ser promovido e receber novos privilégios. Pode participar temporariamente de um projeto crítico. Pode mudar de área ou assumir responsabilidade por um sistema. Da mesma forma, privilégios podem ser removidos e acessos desnecessários eliminados. Cada uma dessas mudanças altera o _blast radius_.

Por isso, uma arquitetura dinâmica de HRM precisa conseguir receber sinais de mudanças de acesso e atualizar a avaliação de impacto. Se uma pessoa deixa de possuir um privilégio crítico, isso deveria aparecer como redução de risco. Se recebe acesso administrativo a uma plataforma importante, a mudança também precisa ser percebida.

Essa característica é importante porque mostra novamente a diferença entre Human Risk Management e um simples perfil de usuário. O objetivo não é classificar pessoas uma única vez. É acompanhar como as condições que produzem risco mudam ao longo do tempo.

[![](https://kvlbuwxkkllobkgvzsam.supabase.co/storage/v1/object/public/blog-content/inline/1780320814605-15vsqx.png)](#fale-com-especialista)

## **Blast radius também ajuda a priorizar proteção**

Conhecer o impacto potencial de uma identidade não serve apenas para calcular um score. Talvez seu maior valor esteja em ajudar a organização a decidir onde aplicar controles adicionais.

Se sabemos que determinadas identidades possuem grande _blast radius_, podemos priorizar autenticação resistente a phishing, dispositivos mais controlados, políticas de acesso mais restritivas, monitoramento adicional ou revisões de privilégios mais frequentes.

Também podemos direcionar melhor as ações de conscientização. Uma pessoa altamente exposta e com grande impacto potencial pode receber treinamento específico sobre os ataques mais prováveis contra sua função, em vez de participar apenas de campanhas genéricas.

Isso representa uma mudança importante. O Human Risk Score deixa de ser utilizado apenas para descobrir quem “errou” e passa a ajudar a organização a identificar onde uma eventual falha teria consequências maiores.

## **O objetivo não é encontrar as pessoas mais perigosas**

Essa arquitetura precisa ser construída com uma premissa clara: estamos avaliando risco associado a identidades, não o valor, a competência ou a confiabilidade das pessoas.

Uma identidade pode possuir _blast radius_ elevado justamente porque a organização confia naquela pessoa e concedeu a ela responsabilidades importantes. Administradores, executivos e profissionais responsáveis por sistemas críticos naturalmente aparecerão com impacto potencial maior.

Por isso, essa informação precisa ser interpretada corretamente.

Se criarmos um ranking simples mostrando os “usuários mais arriscados” sem explicar as dimensões que compõem essa classificação, podemos transformar uma ferramenta de gestão de risco em uma fonte de interpretações equivocadas.

O modelo precisa conseguir explicar que alguém possui alto impacto porque administra determinados recursos, enquanto outra pessoa possui risco elevado por causa de exposição ou comportamento. A transparência sobre essas diferenças é parte essencial da arquitetura.

## **De acesso para impacto, de impacto para risco**

Quando conectamos todas essas peças, podemos estabelecer uma sequência mais consistente.

Primeiro identificamos a pessoa e relacionamos suas diferentes identidades digitais. Depois compreendemos seus acessos, grupos, papéis e privilégios. Em seguida analisamos quais recursos podem ser alcançados, quais ações podem ser executadas e qual a criticidade desses recursos. Também consideramos caminhos capazes de ampliar o comprometimento e o contexto organizacional daquela pessoa.

O resultado não precisa ser imediatamente um Human Risk Score. O primeiro resultado deveria ser uma representação da dimensão de impacto daquela identidade. Somente depois essa informação deve ser combinada com outras dimensões, como comportamento e exposição.

Essa ordem faz diferença. Um clique em phishing não deveria possuir exatamente o mesmo significado para todas as pessoas. Da mesma forma, possuir privilégios elevados não deveria automaticamente transformar alguém em usuário de alto risco.

Human Risk Management precisa compreender a combinação.

Se uma identidade possui comportamento preocupante, exposição crescente e grande _blast radius_, existe uma condição que merece prioridade. Se possui grande impacto potencial, mas comportamento consistente, baixa exposição e controles fortes, a situação é diferente. Se apresenta comportamento de risco, mas possui impacto limitado, o tratamento também pode ser outro.

É justamente essa contextualização que permite sair de modelos baseados em eventos e começar a trabalhar efetivamente com risco.

No final, a pergunta técnica que precisamos responder não é apenas **“o que essa pessoa fez?”**.

Precisamos também conseguir responder **“se essa identidade fosse comprometida agora, até onde um atacante conseguiria chegar e qual seria o impacto para a organização?”**

Quando conseguimos responder às duas perguntas e correlacionar suas respostas com exposição, contexto e controles existentes, o Human Risk Score deixa de ser apenas uma representação de comportamento.

Ele começa, de fato, a representar risco.

---
Fonte: BeePhish — https://beephish.com