--- title: "Como proteger APIs que tratam dados sensíveis ou regulados" description: "Controlos para APIs com dados de banca, energia ou serviços públicos: modelo de ameaças, autorização, privilégio mínimo, minimização, segredos, auditoria." canonical: https://sdk.enterprises/pt/insights/securing-regulated-data-apis language: pt --- # Como proteger APIs que tratam dados sensíveis ou regulados Atualizado a: 2026-09-25 > 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. ## Serviços relacionados - [Segurança de aplicações](https://sdk.enterprises/pt/services/secure-systems)