Autorização de APIs: controle prático para a nuvem

Uma API pode autenticar corretamente o utilizador e ainda permitir que ele aceda ao recurso errado. O problema afeta aplicações web, serviços móveis, integrações internas e cargas de trabalho na nuvem. A ação prioritária é separar autenticação de autorização, testar cada decisão no servidor e produzir registros que permitam provar quem tentou aceder a qual recurso, em que contexto e com que resultado.

Esse controle não se resolve apenas com um token válido ou com uma rede privada. A equipa defensiva precisa definir a relação entre identidade, recurso, ação e contexto; aplicar essa política em cada operação sensível; e monitorizar falhas, alterações e exceções. A abordagem também reduz o risco de uma conta legítima ser usada para atravessar fronteiras de privilégio dentro da aplicação.

O erro começa no objeto

O caso mais conhecido é a alteração de um identificador na URL ou no corpo da requisição. Um utilizador consulta o próprio pedido, troca o identificador por outro e recebe dados de uma segunda conta. O servidor verificou que o token era válido, mas não verificou se aquela identidade podia executar a ação sobre aquele objeto específico.

O problema pode aparecer em qualquer método: leitura, alteração, exportação, cancelamento ou exclusão. Também pode surgir em identificadores difíceis de adivinhar, porque o atacante pode obter referências por mensagens, relatórios, caches, logs expostos ou respostas de outros fluxos. Trocar números sequenciais por identificadores aleatórios dificulta a enumeração, mas não substitui a verificação de autorização.

A decisão deve ser feita no backend, junto da operação que acessa o recurso. Não confie em campos enviados pelo cliente, em controles escondidos na interface ou em uma regra aplicada somente no gateway. O serviço que lê ou altera o dado precisa comparar a identidade autenticada com o proprietário, o papel, a relação organizacional e o estado do recurso.

A orientação da OWASP sobre riscos de APIs trata falhas de autorização em nível de objeto e de função como problemas distintos. Isso é operacionalmente relevante: uma conta pode estar autorizada a consultar um pedido próprio, mas não a chamar uma função administrativa que usa a mesma API.

Modele a decisão antes do código

Comece por um inventário de recursos e ações, não por uma lista genérica de papéis. Para cada endpoint, escreva qual sujeito pode executar qual ação sobre qual objeto, sob quais condições. Inclua relações como proprietário, membro de equipa, aprovador, operador de suporte e serviço automatizado. Registre também as situações de negação esperada.

Uma matriz simples ajuda a revelar permissões implícitas:

Elemento	Pergunta defensiva	Evidência esperada
Sujeito	Quem faz a chamada?	Identidade verificada e serviço de origem
Ação	O que será executado?	Operação explícita, sem inferência pelo cliente
Objeto	Qual recurso será afetado?	Identificador resolvido no servidor
Contexto	Há condição adicional?	Estado, organização, dispositivo ou aprovação
Resultado	A decisão foi permitida?	Resposta e evento de auditoria correlacionados

A política deve ser negativa por padrão para ações administrativas e dados de terceiros. Evite depender de um papel amplo como administrador quando a operação pode exigir uma permissão específica. Para serviços internos, a identidade da carga de trabalho também deve ser avaliada; estar dentro da rede ou possuir uma credencial de serviço não deve conceder acesso irrestrito.

Na prática, prefira uma função de autorização centralizada ou bibliotecas comuns, mas mantenha a decisão próxima do domínio que conhece o recurso. Um componente central pode validar atributos e políticas; o serviço de negócio deve confirmar se o objeto existe naquela relação e se o estado permite a ação. O objetivo é impedir que uma regra genérica perca detalhes essenciais.

Leve Zero Trust à API

Zero Trust não significa pedir uma nova senha para cada requisição. Significa não conceder confiança implícita apenas porque a chamada vem de uma rede, conta ou aplicação conhecida. A autorização deve considerar identidade, recurso, pedido, postura do dispositivo quando aplicável e sinais de risco disponíveis para aquela operação.

A arquitetura de Zero Trust do NIST organiza esse modelo em componentes de decisão e de aplicação de política. Para uma API, a tradução prática é clara: um componente decide com base em atributos e política; outro impede ou encerra o caminho de comunicação; e o serviço registra o resultado suficiente para investigação.

Esse desenho é útil em ambientes híbridos. Um gateway pode validar credenciais, limitar taxa e bloquear padrões conhecidos, mas não deve ser tratado como substituto da autorização no serviço. Um serviço de faturamento, por exemplo, conhece o vínculo entre cliente, contrato e operação de estorno melhor do que um proxy genérico.

Também defina o que acontece quando um sinal necessário está indisponível. Para ações de alto impacto, a falha de uma consulta de risco, de uma confirmação de dispositivo ou de uma aprovação deve resultar em bloqueio ou numa etapa adicional, não numa permissão automática. Exceções de emergência precisam de prazo, responsável e revisão posterior.

Teste abuso, não só sucesso

Os testes de autorização devem começar com uma identidade válida e tentar operações indevidas. Crie casos para leitura cruzada entre contas, acesso entre organizações, mudança de papel, chamadas administrativas por utilizadores comuns e uso de um recurso depois de revogado. Teste também variações de método, formato, codificação, campos omitidos e identificadores presentes em respostas anteriores.

No pipeline, mantenha dados de teste que representem relações reais do domínio. Um teste que usa apenas um utilizador e um objeto não encontra falhas de isolamento. Cada caso deve declarar o sujeito, a ação, o objeto, o contexto e o resultado esperado. Quando uma autorização é corrigida, transforme o caso em regressão permanente.

Separe testes de contrato, integração e abuso. O primeiro verifica que o endpoint exige os atributos previstos. O segundo confirma a interação entre gateway, serviço e base de dados. O terceiro tenta ultrapassar a fronteira de privilégio. Falhas desse último grupo devem bloquear a promoção quando atingem dados ou ações sensíveis.

Não confunda uma resposta de erro com proteção comprovada. Compare o corpo, os cabeçalhos, o tempo de resposta e efeitos laterais. Uma API pode responder com erro e ainda revelar dados por mensagens, contagens, diferenças de tempo ou eventos assíncronos. Verifique também se uma tentativa negada deixou alterações parciais.

Registre decisões úteis

Um log de autorização deve permitir reconstruir a decisão sem copiar segredos ou dados desnecessários. Registre uma referência pseudonimizada do sujeito, serviço, recurso, ação, resultado, motivo da política, correlação da requisição e momento sincronizado. Para dados pessoais, use minimização, retenção definida e controles de acesso ao próprio sistema de logs.

Os registros precisam cobrir tanto permissões quanto negações. Uma sequência de negações contra vários objetos pode indicar enumeração; uma permissão fora do padrão pode revelar abuso de uma conta legítima. Crie alertas para alterações de política, elevação de papel, uso de exceções e desativação de telemetria.

O guia de gestão de logs do NIST destaca que o ciclo inclui gerar, transmitir, armazenar, acessar e eliminar dados de registro. Isso evita o erro de tratar logging como uma simples opção de depuração. A equipa deve monitorizar a saúde da coleta, proteger o transporte, controlar alterações e testar a recuperação dos eventos.

Uma regra de detecção só é confiável se a equipa souber o que fazer depois do alerta. Defina o proprietário, a fonte de confirmação, o limite de severidade e a ação de contenção. Em suspeita de abuso de autorização, preserve eventos correlacionados, suspenda a credencial conforme o risco, revise alterações de política e identifique recursos acessados.

Plano de execução

Priorize o trabalho pelo impacto dos recursos. Primeiro, mapeie endpoints que expõem dados pessoais, dinheiro, administração, segredos ou operações irreversíveis. Depois, implemente verificações de objeto e função no servidor, elimine permissões herdadas sem necessidade e adicione testes negativos ao pipeline. Por fim, valide a cobertura dos logs com uma chamada permitida e uma negada em ambiente controlado.

Na revisão semanal, compare a matriz de autorização com as rotas efetivamente implantadas. Procure endpoints sem proprietário, regras duplicadas, exceções sem data de expiração e serviços que aceitam tokens destinados a outro público. A equipa não precisa esperar um incidente para descobrir que uma permissão foi definida apenas na documentação.

O resultado esperado é uma decisão demonstrável: a identidade certa executou a ação certa sobre o recurso certo, dentro do contexto permitido, e a organização consegue explicar por que permitiu ou bloqueou a chamada. Quando essa cadeia não pode ser testada nem observada, a superfície de API deve ser tratada como risco aberto.