Proteção contra ataques

O Authio observa cada login com senha, cada pedido de recuperação de senha e cada pedido de login enviado a um celular em busca dos padrões que os ataques deixam, e responde sozinho. Cada resposta mira no atacante, nunca na pessoa atacada, e fica registrada num incidente que você lê em Proteção contra ataques.

Não há nada para ligar nem ajustar. O motor roda em todo realm com os mesmos limites, e o que sobra para uma pessoa é confirmar o que aconteceu, levantar uma medida que pegou tráfego legítimo e decidir se o realm deve ficar mais rígido.

Como funciona

Cada senha errada, cada pedido recusado no celular e cada pedido de recuperação é contado por endereço de origem e por conta, nunca por realm: o tráfego de um realm oscila com a hora e a estação, mas um endereço testando oito contas em dez minutos não acontece por acaso. Quando uma contagem cruza um limite, a plataforma toma uma medida na hora e a registra no incidente do realm para aquele tipo de ataque.

• Mira no ataque, nunca no dono. Uma origem é bloqueada, uma conta passa a recusar endereços em que nunca foi aprovada, um celular para de receber pedidos. A pessoa atacada continua entrando de onde sempre entra, então um atacante não consegue trancar alguém fora da própria conta.
• Toda medida expira sozinha. Bloqueios e pausas duram um tempo definido e acabam por conta própria, e você pode levantar uma antes. Só uma senha tratada como exposta não expira: ela precisa ser trocada.
• Datacenters e saídas Tor têm metade do limite. Pessoas raramente entram de um ou de outro; scripts quase sempre entram. A redução fica registrada entre os motivos da medida.
• Ela nunca trava o login por uma falha própria. O motor conta num cache compartilhado e, quando esse cache não pode ser lido, a tentativa segue como se a proteção não existisse.

O que ela detecta

Todo incidente é de um dos cinco tipos de ataque, e o tipo é o título dele na lista. Uma origem bloqueada é classificada pelo que estava fazendo; as detecções no celular e na recuperação têm tipos próprios.

Uma senha correta vinda de um ataque não é um sexto tipo. Ela é registrada como Senha exposta no incidente do ataque que a trouxe, credential stuffing ou password spraying, e torna esse incidente crítico.

Quando ela age, e por quanto tempo

Estas regras são da plataforma, as mesmas em todo realm, e não podem ser mudadas por realm nem por conta. Cada medida diz os fatores que a dispararam, então um escritório bloqueado pode ser explicado em vez de adivinhado.

Redes compartilhadas

Um endereço que 5 ou mais contas do realm aprovaram é tratado como escritório ou campus. Ele nunca é bloqueado por inteiro, e uma senha correta vinda dele nunca é tratada como exposta. As contas dele continuam travando contra estranhos uma a uma.

O que uma origem bloqueada vê

Uma origem bloqueada é recusada antes de qualquer conta ser procurada, com a mesma resposta de um limite de taxa (TooManyRequests): espere alguns minutos e tente de novo. A resposta é a mesma qualquer que seja o nome digitado e não diz nada sobre a senha, então quem está atrás de um endereço bloqueado não ouve que a senha está errada.

O bloqueio do próprio realm

O Máximo de tentativas malsucedidas e a Duração do bloqueio do realm (Políticas de segurança) continuam valendo ao lado do motor, com uma diferença: uma falha vinda de um endereço em que a conta nunca foi aprovada conta só contra aquele endereço, nunca contra a conta. Depois do número de falhas do realm dentro de uma hora, aquele endereço fica bloqueado para a conta pela duração do realm, enquanto os endereços em que a conta foi aprovada seguem o bloqueio de sempre. Esse bloqueio não abre incidente.

Incidentes

Detecções do mesmo tipo contra um realm entram num único incidente enquanto cada uma chega até 30 minutos depois da anterior, então um ataque espalhado por trezentos endereços aparece como um incidente com trezentas origens bloqueadas. Cada incidente diz o seu realm e o client pelo qual veio a primeira detecção.

Severidade

O incidente guarda a maior severidade que atingiu.

Status

Medidas

Cada medida também diz em quem mira e por quê: os fatores contados, como falhas, contas diferentes, a parcela de contas inexistentes, rede de datacenter ou saída Tor, pedidos recusados no celular ou senha correta. Ela aparece como Em vigor, expira … enquanto vale, Expirada quando o tempo acabou, Levantada … quando alguém a levantou e Troca exigida para uma senha exposta.

A tela de ataques

Proteção contra ataques lê o realm escolhido no seletor de realm, ou todos os realms que você administra em Todos os realms, e um filtro de client restringe tudo ao que veio por um client. Não há nada para configurar nela.

Ler um incidente

Clicar num incidente o abre ao lado da lista:

• O que é aquele tipo de ataque.
• Tentativas recusadas, Origens bloqueadas, Contas protegidas e Senhas expostas: as tentativas que as medidas dele recusaram, as origens que bloqueou, as contas que receberam alguma medida e as contas cuja senha correta chegou a partir dele.
• Início, Última atividade, Encerrado em e Detecções: quando foi detectado pela primeira vez, quando teve a última detecção ou tentativa recusada, quando fechou e quantas detecções entraram nele.
• A leitura do analista de IA, quando a sua conta tem um.
• Medidas tomadas, cada uma com os motivos e a situação, e Levantar nas que ainda estão em vigor.

O Painel mostra a mesma proteção dos últimos 30 dias no bloco Proteção contra ataques, com Abrir proteção contra ataques. Na página de uma pessoa, em Usuários, Senha exposta em um ataque continua visível enquanto a senha atual dela ainda for a que um ataque comprovou.

Levantar uma medida ou dispensar um incidente

As duas ações exigem permissão para alterar realms (realm:update); sem ela, a tela é só de leitura. Não existe bloqueio manual: toda medida foi tomada pela plataforma.

Cada medida levantada e cada dispensa ficam registradas na trilha de mudanças como alteração, em nome de quem as fez.

O analista de IA

Quando o seu plano inclui o consultor de IA e o realm deu consentimento, um analista de IA lê cada incidente e escreve no painel lateral dele o que concluiu. Ele lê só os números do incidente, sem endereços nem nomes, e nunca fica no caminho de um login: o motor decide quando a tentativa chega, o analista lê depois, e um analista lento ou fora do ar não muda nada sobre quem entra.

Para ativar, abra o realm em Realms, escolha Consultor de IA e ligue Permitir que o consultor de IA analise este realm; veja Authio AI. Sem o plano ou sem o consentimento, o painel lateral simplesmente não mostra análise. O consentimento é conferido de novo quando cada leitura roda.

Quando ele lê

As leituras são agendadas a cada 5 minutos, cada uma das três no máximo uma vez por incidente, e uma conta recebe no máximo 12 leituras por dia UTC, então um atacante não consegue inflar a conta abrindo incidentes. As leituras anteriores ficam recolhidas sob a mais recente. Uma leitura que falhou pode ser pedida de novo com Tentar de novo.

O que uma leitura diz

• Classificação: um dos cinco tipos de ataque, Pico legítimo, Configuração errada ou Inconclusivo, com o grau de confiança.
• O que aconteceu, O que já foi feito e Senhas expostas.
• Ajustes recomendados para o realm.
• Na leitura de fechamento, o Relatório pós-incidente.

Ajustes recomendados

Uma leitura traz até três mudanças, e cada uma só pode deixar o realm mais rígido. Cada uma mostra a mudança, o valor atual do realm e o que os seus usuários vão notar. Elas mudam as regras de conta do próprio realm:

• Aplicar pede confirmação e muda o realm para toda aplicação que entra por ele. Se a mudança ainda deixa o realm mais rígido é conferido de novo nesse momento; uma que o realm já atende aparece como Já está assim.
• Desfazer volta o valor anterior a partir do mesmo incidente, desde que o realm ainda tenha o valor aplicado. Uma mudança que alguém fez depois fica como está.
• Aplicar e desfazer ficam registrados na trilha de mudanças, como qualquer alteração do realm.

Relatório pós-incidente

A leitura de fechamento acrescenta um relatório no formato que a ANPD pede para a comunicação de um incidente de segurança (Resolução CD/ANPD nº 15/2024): Natureza do incidente, Dados e titulares afetados, Riscos, Medidas e Comunicação. Copiar relatório o leva para a área de transferência com as datas e os números do incidente.

Notificações e webhooks

A plataforma avisa os operadores da conta, os webhooks do realm e a pessoa cuja senha foi exposta, sem ninguém precisar abrir a tela.

• Em Preferências, o dono da conta decide se Ataques detectados também sai por e-mail e por webhook, ou se nem é gerada. Veja Notificações.
• A mesma conta é avisada no máximo uma vez por hora. Uma lista repetida contra o realm continua sendo recusada a cada tentativa, mas o incidente, a notificação, o webhook e o e-mail não se repetem.
• Só endpoints do realm recebem os eventos de ataque. O que cada um carrega está em Webhooks.

Leia e aja pela API administrativa

Os incidentes estão na API administrativa, chamada com um segredo de API no header x-api-key. Os caminhos são relativos a /api/v1/admin, e as listas são paginadas com pageNumber e pageSize.

curl 'https://authio.api.hyperio.tech/api/v1/admin/threat-incidents?incidentStatus=Active&pageNumber=1&pageSize=20' \
  -H "x-api-key: $AUTHIO_API_KEY"

Responder a um incidente

Quando você olha, a plataforma já agiu. A sua parte é confirmar o que foi, cuidar das senhas expostas e decidir se o realm deve ficar mais rígido.

1. 1

   Veja o que foi

   Abra o incidente em Proteção contra ataques e leia o tipo e a descrição: é um ataque ou tráfego seu?

2. 2

   Leia as medidas

   Em Medidas tomadas, veja quais origens estão bloqueadas e por quê, e se aparece alguma Senha exposta.

3. 3

   Cuide das senhas expostas

   Cada dono já recebeu o pedido de troca, mas as sessões que estavam abertas continuam abertas até serem encerradas. Se a conta pode ter sido usada nesse meio-tempo, encerre as sessões dela em Sessões.

4. 4

   Rastreie a origem

   Abra Auditoria › Acessos e busque o endereço bloqueado para ler cada tentativa que ele fez, inclusive as bem-sucedidas.

5. 5

   Decida

   Se era tráfego legítimo, use Dispensar: não era ataque. Se era real, leia as recomendações do analista de IA e aplique as que fizerem sentido.

6. 6

   Guarde o registro

   Quando o incidente fechar, copie o relatório pós-incidente se precisar comunicá-lo.

Permissões

Com os papéis da conta, um Auditor lê tudo aqui mas não age; um Desenvolvedor, Administrador ou Dono também age.

Próximos passos