DICT: token bucket contra varredura de chaves Pix

01 · CONTEXTO

Quando consultar é o ataque

O DICT, o Diretório de Identificadores de Contas Transacionais, é a base das chaves Pix. O Banco Central é o mantenedor da base, e os participantes, com acesso direto ou indireto, são os requisitantes das consultas.

1. O diagrama mostra a pessoa usuária, o app do participante e o DICT.

2. Os participantes consultam o DICT como requisitantes, enquanto o Banco Central mantém a base.

3. Um ataque de leitura pode partir de um usuário ou de um invasor que usa a estrutura do participante.

A norma define ataque de leitura como a captura de vínculos existentes no DICT para propósitos distintos de realizar pagamentos. Ele pode ser rápido e intenso, em poucas horas, ou lento, ao longo de dias ou meses.

Para conter esse abuso, o DICT limita as consultas de chave Pix com base em dois indicadores: as consultas sem ordem de pagamento e as consultas inválidas, isto é, feitas para chaves não registradas no DICT.

02 · O BALDE DE FICHAS

Como o DICT conta as consultas

O mecanismo de limitação usa o algoritmo Token Bucket, o balde de fichas. Para contar, o participante informa no header PI-PayerId quem origina a consulta, e todas as consultas de um mesmo usuário final por aquele participante levam o mesmo identificador. Assim, o DICT controla as consultas tanto por usuário final quanto por participante.

1. O DICT controla as consultas por usuário final e por participante, cada um com o seu balde.

2. Cada consulta válida de chave tira uma ficha do balde.

3. Cada consulta inválida, a uma chave não registrada, tira vinte fichas do balde do usuário.

4. Para o participante, a consulta válida tira uma ficha e a inválida tira três.

5. Após o SPI receber a ordem de pagamento, o balde recebe de volta fichas por consulta de chave.

6. Com o balde vazio, a consulta recebe erro de limitação, código HTTP 429, e fica bloqueada até a reposição de fichas.

03 · PARÂMETROS PUBLICADOS

Pessoa natural, pessoa jurídica e participante

Para a pessoa natural, o balde de consultas por telefone celular ou e-mail tem tamanho máximo de cem fichas, e o tamanho do balde para consultas por CPF, CNPJ ou chave aleatória é definido em separado. Em cada balde, a consulta válida tira uma ficha e a inválida tira vinte.

Para o participante, o tamanho máximo do balde e o incremento por minuto dependem da categoria. O Banco Central enquadra cada participante em uma das categorias, de A a H. Cada consulta válida tira uma ficha do balde do participante e cada inválida tira três.

04 · O EXEMPLO DA NORMA

Quando uma consulta inválida cria dívida

Quando o balde já está vazio, quem consulta recebe o erro de limitação, com código HTTP 429, e fica sem poder consultar até a reposição de fichas. O próprio manual traz um exemplo resolvido para a pessoa natural.

1. A pessoa natural do exemplo tem apenas cinco fichas no balde e faz uma consulta.

2. A chave consultada não está registrada: o DICT responde NOT FOUND, código HTTP 404, com penalidade de vinte fichas.

3. O balde passa a ter saldo devedor de quinze fichas.

4. Novas consultas só terão sucesso após oito minutos, com a reposição de duas fichas por minuto.

O exemplo deixa visível a assimetria de custos: a consulta válida custa uma ficha e a inválida custa vinte.

05 · DEFESA EM CAMADAS

O que o participante faz antes de o DICT dizer não

A norma exige que cada participante tenha uma política interna de limitação de consultas igual ou mais restritiva que o Token Bucket do DICT. Essa política é uma camada de proteção anterior, que limita o envio excessivo de requisições, e o controle pode ficar na aplicação ou na infraestrutura.

1. O diagrama mostra o caminho da consulta no participante: limitação interna, cache, checkKeys, DICT e monitoramento.

2. A política interna do participante é igual ou mais restritiva que o balde do DICT.

3. O participante não repassa ao DICT a consulta que ultrapassaria o limite do usuário ou do participante, o que previne o erro de limitação.

4. Consultas a chaves de pessoa jurídica podem ter a resposta cacheada, por no máximo cento e oitenta segundos, para diminuir a carga no DICT.

5. Sugere-se usar o checkKeys para confirmar a existência de chaves antes das requisições, o que evita altas quantidades de consultas inválidas.

6. O monitoramento acompanha as requisições dos usuários, e verificada fundada suspeita de uso indevido o participante deve bloquear de imediato o usuário.

O monitoramento tem duas razões. A primeira compara as consultas ao DICT com as ordens enviadas ao SPI: espera-se um valor ligeiramente acima de um, e valores próximos de dois ou maiores são tipicamente indicativos de anomalia, embora o limiar possa variar. A segunda compara as chaves não registradas com as encontradas, e a norma observa que essa relação é afetada pela jornada e pelo comportamento dos usuários.

A norma dá, usualmente, referências para suspeita: percentuais de chaves não registradas acima de sete por cento para o participante e acima de vinte por cento para usuários que tenham feito no mínimo cem consultas nas últimas vinte e quatro horas.

06 · LEITURAS PARA O DESENHO

O que levar para uma entrevista

Três ideias resumem o caso. O custo de uma consulta depende do resultado dela, pois a inválida custa muito mais que a válida. O crédito de fichas depende do pagamento, já que a ordem recebida pelo SPI devolve fichas ao balde. E a defesa tem camadas, porque o participante limita antes do DICT.