Um fornecedor de plataforma de serviços financeiros havia implementado uma segurança abrangente no nível do banco de dados: acesso baseado em funções, criptografia no nível de coluna para campos sensíveis, políticas de segurança no nível de linha e registros de auditoria abrangentes. Sua API RESTful, que ficava à frente do banco de dados e era o principal mecanismo de acesso de todas as integrações de clientes, havia sido criada por outra equipe, com outro foco de segurança. A API autenticava os chamadores corretamente: a validação das chaves de API era robusta. Após a autenticação, no entanto, a API retornava objetos completos de registros de clientes, independentemente dos campos de que a integração de fato precisava. Uma integração que exigia apenas o número da conta e o saldo recebia o registro completo, incluindo data de nascimento, número do seguro social e histórico de transações. A API não tinha nenhuma capacidade de filtragem no nível de campo: retornava o que o banco de dados continha para o objeto solicitado. A API também não tinha limitação de taxa nos endpoints de consulta, o que significava que um chamador com uma chave de API válida poderia obter todo o banco de dados de clientes por enumeração sistemática em questão de horas. O banco de dados tinha segurança no nível de campo. A API a contornava por desenho: foi criada para retornar registros completos, e foi o que fez.
Qual é, de fato, o problema do risco de acesso a dados via API?
As APIs tornaram-se a principal interface pela qual os dados circulam entre sistemas: o mecanismo pelo qual integrações de fornecedores, aplicativos móveis, conexões com parceiros e serviços internos acessam os dados mantidos por bancos de dados e sistemas de aplicação. Essa mudança de arquitetura tem uma implicação de segurança significativa: os controles de acesso que governam os dados nos sistemas de banco de dados (segurança no nível de linha, criptografia no nível de coluna, restrições de acesso no nível de campo) aplicam-se ao acesso direto ao banco de dados, que é cada vez menos comum nas arquiteturas modernas. A camada de API que faz a intermediação entre os chamadores e os bancos de dados tem sua própria postura de segurança, que pode ou não aplicar restrições de acesso equivalentes.
O problema do retorno excessivo é o risco de acesso a dados via API mais disseminado. A maioria das APIs retorna representações completas de objetos quando um registro é solicitado (o registro completo do cliente, o objeto de transação completo, o perfil inteiro da conta), independentemente dos campos de que a integração chamadora de fato precisa. Esse desenho é conveniente para os desenvolvedores de API e para os consumidores de API: um único endpoint retorna tudo, e os desenvolvedores das integrações pegam o que precisam. A implicação de segurança é que todo chamador da API recebe o conjunto completo de dados, quer sua integração precise de tudo ou não, e dados que deveriam ser restritos a tipos específicos de integração ou a casos de uso específicos são retornados a qualquer chamador autenticado que solicite o objeto.
A lacuna de limitação de taxa amplia o risco de retorno excessivo, transformando-o em uma capacidade de exfiltração sistemática. Uma consulta ao banco de dados que retorna todos os registros de clientes seria controlada pelos controles de acesso do banco de dados, e poucos usuários teriam esse nível de acesso. Um endpoint de API que retorna registros de clientes um a um, sem limitação de taxa, fornece os mesmos dados a qualquer chamador autenticado por meio de enumeração sistemática, um processo que exige apenas uma chave de API válida e paciência para fazer solicitações sequenciais. Os controles do banco de dados impedem o acesso em massa. A API oferece acesso em massa por meio de solicitações sequenciais de registros individuais, no ritmo que o chamador estiver disposto a sustentar.
Os riscos de acesso a dados via API concentram-se em cinco lacunas de controle específicas:
- Retorno do registro completo sem filtragem de campos: endpoints de API que retornam representações completas de objetos a todos os chamadores autenticados, independentemente dos campos de que a integração precisa ou que está autorizada a receber
- Nenhuma limitação de taxa nos endpoints de obtenção de dados: endpoints de consulta da API acessíveis com taxas de solicitação ilimitadas, permitindo a enumeração sistemática de todo o conjunto de dados
- Autorização insuficiente no nível da API: a autenticação da API confirma a identidade do chamador sem uma autorização no nível da API que restrinja quais chamadores podem acessar quais categorias de dados ou subconjuntos de clientes
- API que contorna a segurança no nível do banco de dados: a camada de API descriptografa e retorna dados que a camada de banco de dados restringe, contornando na prática os controles de banco de dados no nível de campo e de linha
- Cache de respostas de API sem controle de acesso: respostas de API armazenadas em cache compartilhadas entre chamadores, independentemente da autorização de cada chamador
Por que isso importa
O acesso a dados via API é relevante para TPRM porque as APIs são o mecanismo real de acesso a dados em praticamente todas as integrações com fornecedores, e os controles de segurança da camada de API determinam a proteção de dados que as integrações de fato recebem, independentemente dos controles no nível do banco de dados que as avaliações de governança normalmente examinam. Um fornecedor com excelente segurança de banco de dados e segurança de API deficiente oferece uma proteção de dados fraca a todos os chamadores que acessam dados pela API, ou seja, à maioria dos chamadores, na maior parte do tempo.
O problema do escopo das integrações é particularmente relevante. Uma integração criada para acessar números de conta e saldos pode receber registros completos de clientes, incluindo dados sensíveis de que a integração não precisa, porque a API retorna objetos completos. O DPA do fornecedor especifica os dados que a integração trata. A API retorna mais do que o DPA prevê. O princípio da minimização de dados é violado na camada de API por uma escolha de desenho anterior à integração específica: a API foi criada para retornar registros completos antes que a integração do cliente fosse desenhada com requisitos específicos de escopo de dados.
Para profissionais de TPRM, a avaliação do acesso a dados via API exige examinar a API como uma camada de segurança distinta, sem inferir sua postura de segurança a partir dos controles do banco de dados subjacente. A capacidade de filtragem de campos, a configuração de limitação de taxa, o escopo de autorização e o desenho das respostas são questões de segurança no nível da API que a avaliação do banco de dados não responde.
Onde a maioria das equipes erra
A falha mais recorrente é avaliar a segurança do banco de dados e presumir que ela governa o acesso via API. A segurança de API é uma disciplina distinta da segurança de banco de dados: a camada de API tem seus próprios mecanismos de autenticação, sua própria lógica de autorização, seu próprio desenho de respostas e suas próprias configurações de limitação de taxa. Os controles do banco de dados protegem os dados no banco de dados. Os controles de API protegem os dados enquanto circulam pela API. Os dois são independentes, e a fragilidade em qualquer uma das camadas cria exposição, independentemente da solidez da outra.
A segunda falha é não perguntar sobre a filtragem de respostas da API no nível de campo. A maioria das avaliações de API pergunta se a API é autenticada e se usa HTTPS. Raramente pergunta se a API pode retornar respostas com filtragem de campos que correspondam aos campos específicos de que uma integração precisa, ou se todo chamador autenticado recebe o mesmo registro completo, independentemente do seu escopo de autorização específico.
- Tratar a segurança do banco de dados como equivalente à segurança da API: são duas camadas de segurança independentes
- Nenhuma avaliação de filtragem de campos: se a API pode retornar subconjuntos de campos específicos por integração
- Limitação de taxa não avaliada: taxas de solicitação ilimitadas que permitem a enumeração sistemática
- Profundidade da autorização da API não avaliada: autenticação versus autorização para categorias de dados específicas
- Contorno dos controles do banco de dados pela API não avaliado: a API descriptografa o que o banco de dados criptografa
Como é uma boa prática
Programas maduros de segurança de API aplicam, na camada de API, controles de acesso no mínimo tão restritivos quanto os controles do banco de dados subjacente, implementando filtragem de campos que retorna apenas os campos autorizados para cada integração, limitação de taxa que impede a enumeração sistemática e lógica de autorização que restringe o acesso aos dados às categorias específicas que cada chave de API está autorizada a receber.
- Filtragem de respostas no nível de campo: respostas da API filtradas para retornar apenas os campos autorizados para cada chave de API ou tipo de integração
- Limitação de taxa em todos os endpoints de obtenção de dados: limites de solicitações por minuto, por hora e de volume acumulado aplicados por chave de API
- Autorização no nível da API: restrições por categoria de dados e por subconjunto de clientes aplicadas na camada de API, independentemente da autenticação
- Desenho de respostas com o mínimo necessário: endpoints de API que retornam os dados mínimos exigidos para a finalidade declarada, em vez de objetos completos
- Testes de segurança de API: filtragem de campos, contorno de limites de taxa e escopo de autorização avaliados como objetivos explícitos de teste
Ferramentas
Governar o acesso a dados via API exige plataformas de gateway de API que apliquem filtragem de campos, limitação de taxa e autorização na camada de API.
Gateway de API com aplicação de políticas: AWS API Gateway, Azure API Management, Kong, Apigee
As plataformas de gateway de API oferecem aplicação centralizada de limitação de taxa, autenticação e políticas de acesso em todos os endpoints de API, aplicando controles consistentes independentemente de como cada endpoint é implementado. O AWS API Gateway oferece planos de uso por chave com limites de taxa de solicitações e de picos. O Apigee oferece uma governança abrangente de API, incluindo a transformação de respostas, que permite a filtragem de campos. Para profissionais de TPRM, perguntar se o fornecedor usa um gateway de API com limitação de taxa e aplicação de políticas de acesso constitui uma pergunta específica sobre a arquitetura de governança de API.
Testes de segurança de API: 42Crunch, StackHawk, Salt Security
As plataformas de testes de segurança específicas para API testam a autorização no nível de campo, a aplicação de limites de taxa e a restrição de escopo como objetivos explícitos, indo além dos testes de autenticação para avaliar a profundidade do controle de acesso da camada de API. Para profissionais de TPRM, perguntar se os testes de segurança de API incluem a validação da filtragem de campos e testes de contorno de limites de taxa constitui a pergunta específica sobre o escopo dos testes de controle de acesso de API.
Desafios de governança
O desafio de governança do acesso a dados via API é que as decisões de desenho de API (inclusão de campos, limites de taxa, escopo de autorização) são tomadas por equipes de desenvolvimento que otimizam a conveniência da integração e a experiência do desenvolvedor, e não a minimização de dados. O retorno do objeto completo é a escolha padrão de desenho de API porque reduz o esforço de desenvolvimento das integrações. A limitação de taxa costuma estar ausente porque cria atrito para integrações legítimas de alto volume. Esses padrões de desenho criam os riscos de acesso a dados que os programas de governança precisam tratar a posteriori.
- Perguntar sobre a filtragem de respostas da API no nível de campo: se as integrações podem receber respostas com filtragem de campos
- Perguntar sobre a configuração de limitação de taxa: limites por chave que impeçam a enumeração sistemática
- Perguntar se os testes de segurança de API incluem o escopo do controle de acesso: filtragem de campos e profundidade da autorização
- Incluir o escopo de campos da API nas disposições do DPA, especificando quais campos a integração está autorizada a receber
- Perguntar se a API contorna os controles no nível do banco de dados, descriptografando o que o banco de dados criptografa
Se você faz parte de uma equipe pequena
Faça aos seus fornecedores de integrações de API de maior risco duas perguntas que a maioria das avaliações nunca alcança. Primeira: a sua API retorna registros completos a todos os chamadores autenticados ou pode retornar respostas com filtragem de campos, limitadas aos campos específicos que cada integração está autorizada a receber? Segunda: existe um limite de taxa no endpoint de API que retorna os registros usados pela nossa integração, e qual é o número máximo de registros que podem ser obtidos por hora com uma chave de API válida? Essas duas perguntas revelam os riscos de retorno excessivo e de enumeração que definem a governança do acesso a dados via API.
- Perguntar se a API permite respostas com filtragem de campos por integração
- Perguntar qual é o limite de taxa nos endpoints de obtenção de dados
- Perguntar se os testes de segurança de API incluem autorização de campos e contorno de limites de taxa
- Incluir a especificação do escopo de campos nas disposições do DPA relativas a integrações de API
O que exigir
Pergunte diretamente:
“A sua API retorna objetos completos de registros de clientes a todos os chamadores autenticados, ou permite respostas com filtragem de campos que limitam cada integração aos campos específicos que ela está autorizada a receber?”
“Existe um limite de taxa nos endpoints de API que retornam registros de clientes? Qual é o número máximo de registros que uma chave de API válida pode obter por hora antes que a limitação de taxa seja aplicada?”
“Os seus testes de segurança de API avaliaram especificamente se chamadores autenticados conseguem acessar categorias de dados além do escopo de autorização pretendido, e o escopo de autorização no nível de campo é um objetivo de teste definido?”
O que esperar como evidência
- Confirmação da capacidade de filtragem de campos: escopo de campos por integração ou retorno do registro completo
- Configuração de limitação de taxa: limites por chave nos endpoints de obtenção de dados
- Confirmação do escopo dos testes de segurança de API, incluindo testes de autorização de campos e de enumeração
- Descrição do desenho de autorização da API: autenticação versus profundidade da autorização no nível de campo
Um fornecedor que responde à pergunta sobre filtragem de campos com “o acesso à API é autenticado e seguro” descreveu a autenticação. Pergunte especificamente se os chamadores autenticados recebem registros completos ou respostas com filtragem de campos. A autenticação é o portão. A filtragem de campos é o que limita o que passa pelo portão depois que ele se abre.
Como comprovar
A segurança de API é tratada no OWASP API Security Top 10, nos requisitos do PCI-DSS para a segurança de API de pagamento e no princípio de minimização de dados do GDPR aplicado ao escopo das respostas de API. Demonstrar a devida diligência exige evidências de que os controles de acesso da camada de API foram avaliados de forma independente dos controles no nível do banco de dados.
- Registros de avaliação de fornecedores que documentam as perguntas sobre filtragem de campos, limitação de taxa e escopo de autorização da API
- Confirmação do escopo dos testes de segurança de API, incluindo a autorização de campos
- Especificação do escopo de campos no DPA para integrações de API
- Evidências da configuração de limitação de taxa
Principal conclusão
Os controles do banco de dados governam o banco de dados. Os controles da API governam o que as integrações de fato recebem. Nas arquiteturas modernas, praticamente todo acesso a dados acontece por meio de APIs, e os controles da camada de API são os que determinam a realidade do acesso a dados em cada integração, cada conexão com parceiros e cada aplicativo móvel que o fornecedor opera. Uma API que retorna registros completos a todo chamador autenticado oferece, para os campos de que o chamador não precisa, controles de acesso equivalentes a nenhum controle de acesso. Pergunte se a API filtra. Pergunte se a API limita a taxa. Pergunte se a camada de API é governada com o mesmo rigor que a camada de banco de dados abaixo dela. O banco de dados é o cofre. A API é a porta. Os dois precisam de fechadura.