Para proteger uma API com dados regulados, modele quem a poderia usar indevidamente, verifique a autorização em cada objeto e em cada campo, recolha e devolva o mínimo de dados possível e mantenha os segredos e os registos de auditoria sob controlo rigoroso. Na prática, as fragilidades que mais pesam são falhas de autorização e respostas que expõem dados a mais, e não uma cifragem quebrada.
Começar por um modelo de ameaças dos dados, não da framework
Antes de escolher ferramentas, escreva o que a API expõe e quem a poderia usar indevidamente. Para um banco, são dados de contas e de transações; para uma empresa de energia ou de serviços públicos, podem ser dados de contagem, contratos de clientes e leituras operacionais da rede.
Um modelo de ameaças útil é curto. Enumera os dados sensíveis, todos os chamadores que lhes conseguem aceder, as ações que cada um deve poder executar e o que acontece se um deles for comprometido. Esse documento orienta depois todos os controlos abaixo, e diz aos revisores o que devem testar.
- Que dados são pessoais, confidenciais ou regulados, e onde estão guardados.
- Todos os consumidores da API: serviços internos, parceiros, apps móveis e administradores.
- O que cada consumidor pode ler, alterar ou desencadear.
- O impacto de um token divulgado, de um utilizador interno mal-intencionado ou de um sistema parceiro comprometido.
Autenticar cada chamador e autorizar cada objeto
Use um protocolo-padrão como o OAuth 2.0 com OpenID Connect para os utilizadores, e tokens de curta duração ou TLS mútuo para as chamadas entre serviços. Evite chaves de API partilhadas e de longa duração, porque ninguém consegue saber que sistema as usou nem revogá-las sem afetar os outros.
A autenticação só prova quem está a chamar. A primeira entrada do OWASP API Security Top 10 é a falha de autorização ao nível do objeto (broken object level authorization): um utilizador válido altera um identificador no pedido e lê o registo de outra pessoa. Verifique no servidor a propriedade ou o tenant de cada objeto, de cada função e de cada campo sensível, e nunca confie num identificador ou numa função enviados pelo cliente.
Dar a cada cliente e serviço apenas o privilégio de que precisa
O privilégio mínimo limita os danos quando algo corre mal. Emita credenciais separadas para cada consumidor, restrinja os tokens a operações específicas e mantenha os endpoints de administração num caminho separado, com verificações mais fortes.
Aplique a mesma regra abaixo da API. A conta de serviço que lê os dados dos contadores não deve poder apagá-los, e uma tarefa de relatórios deve ligar-se com uma função de base de dados só de leitura. Reveja as permissões periodicamente, porque os acessos concedidos para uma tarefa pontual tendem a ficar para sempre.
Recolher menos, devolver menos e guardar durante menos tempo
A minimização dos dados é ao mesmo tempo um princípio do RGPD e um controlo de segurança eficaz: os dados que nunca se guardam não podem ser divulgados. Pergunte, para cada campo, se o serviço precisa mesmo dele, e elimine ou pseudonimize o que não for necessário.
Aplique a mesma disciplina às respostas. Defina esquemas de resposta explícitos em vez de serializar objetos inteiros da base de dados, mascare identificadores como números de conta quando o valor completo não é necessário, e defina prazos de conservação para que os registos antigos sejam apagados. Documente o fundamento jurídico de cada finalidade de tratamento e assine acordos de subcontratação com qualquer fornecedor que trate os dados. Isto é prática de engenharia, não aconselhamento jurídico, por isso envolva o encarregado da proteção de dados ou os consultores jurídicos na avaliação legal.
Validar cada entrada e limitar o que um chamador pode consumir
Trate cada pedido como hostil até ser validado. Imponha um esquema a cada endpoint, rejeite campos desconhecidos e use consultas parametrizadas para que uma entrada nunca se torne parte de um comando da base de dados.
Vários riscos da lista OWASP API vêm da falta de limites e não de mau código. Limite o número de pedidos por cliente, imponha tamanhos máximos de página e de payload, e proteja os fluxos de negócio sensíveis, como pagamentos ou alterações de contratos, contra abusos automatizados. Se a API vai buscar URLs remotos em nome dos chamadores, restrinja os destinos para evitar a falsificação de pedidos do lado do servidor (SSRF).
Manter os segredos fora do código, das imagens e dos registos
As palavras-passe das bases de dados, as chaves de assinatura e as credenciais dos parceiros pertencem a um gestor de segredos dedicado, injetadas em tempo de execução e renovadas periodicamente. Analise os repositórios e as imagens de contentores à procura de segredos no pipeline de compilação, e considere comprometido qualquer segredo que chegue ao controlo de versões.
Separe os segredos por ambiente, para que uma credencial de teste divulgada nunca abra a produção. Restrinja quem pode ler os segredos em produção e registe cada acesso a eles.
Registar para auditoria e desenhar para ter menos incidentes
Os ambientes regulados têm de responder, a posteriori, a uma pergunta simples: quem acedeu a que dados, quando e através de que cliente. Registe essa informação para cada leitura e escrita sensível, guarde os registos onde os operadores da aplicação não os possam alterar, e mantenha os dados pessoais fora das mensagens de registo.
Junte aos registos alertas sobre padrões invulgares, como um cliente que lê muitos mais registos do que o habitual, e um plano de resposta a incidentes testado. Através da Sopra Steria, os nossos engenheiros construíram APIs seguras para dados sensíveis de serviços públicos sob restrições regulamentares e lideraram uma ferramenta de supervisão operacional em que a aplicação de normas de segurança andou a par de menos incidentes em produção. A SDK Enterprises aplica hoje as mesmas práticas aos projetos dos clientes.
Pontos essenciais
- Um modelo de ameaças dos dados, curto e escrito, deve orientar todos os controlos de segurança da API.
- Verificar a autorização no servidor para cada objeto, função e campo sensível, e não apenas no início de sessão.
- O privilégio mínimo aplica-se tanto aos tokens como às contas de serviço e às funções da base de dados.
- A minimização dos dados reduz tanto a exposição ao RGPD como o impacto de qualquer violação.
- Os registos de auditoria têm de mostrar quem acedeu a quê e quando, sem eles próprios exporem dados pessoais.
Perguntas frequentes
O HTTPS chega para proteger uma API?
Não. O TLS protege os dados em trânsito, mas muitas violações de APIs envolvem chamadores autenticados que chegam a dados que não deveriam ver. Continuam a ser necessárias verificações de autorização, validação das entradas, limites de pedidos e registos de auditoria.
O que é a falha de autorização ao nível do objeto (BOLA)?
É uma falha em que a API verifica que o chamador tem sessão iniciada, mas não que o registo pedido lhe pertence. Basta então alterar um identificador no URL ou no corpo do pedido para expor dados de outros utilizadores. A correção é uma verificação da propriedade ou do tenant no servidor, para cada objeto.
O RGPD impõe controlos de segurança específicos para APIs?
O RGPD exige medidas técnicas e organizativas adequadas ao risco em causa, sem impor ferramentas específicas. Controlos como a restrição de acessos, a minimização, a pseudonimização e o registo são formas comuns de cumprir esse requisito, e os seus consultores jurídicos devem confirmar o que se aplica ao seu caso.