Autorização SaaS multilocatário e controle de acesso à API: opções de implementação e melhores práticas

Tabby Ward, Thomas Davis, Gideon Landeman e Tomas Riha, da Amazon Web Services ()AWS

Maio de 2024 (histórico do documento)

A autorização e o controle de acesso à API são um desafio para muitos aplicativos de software — em particular, para aplicativos de software como serviço (SaaS) multilocatários. Essa complexidade é evidente quando você considera a proliferação de APIs de microsserviços que devem ser protegidas e o grande número de condições de acesso que surgem de diferentes inquilinos, características do usuário e estados do aplicativo. Para resolver esses problemas de forma eficaz, uma solução deve impor o controle de acesso em várias APIs apresentadas por microsserviços, camadas de Backend for Frontend (BFF) e outros componentes de um aplicativo SaaS multilocatário. Essa abordagem deve ser acompanhada por um mecanismo capaz de tomar decisões de acesso complexas com base em muitos fatores e atributos.

Tradicionalmente, o controle de acesso e a autorização da API eram tratados pela lógica personalizada no código do aplicativo. Essa abordagem estava sujeita a erros e não era segura, pois os desenvolvedores que tinham acesso a esse código podiam alterar acidentalmente ou deliberadamente a lógica de autorização, o que poderia resultar em acesso não autorizado. Foi difícil auditar as decisões tomadas pela lógica personalizada no código do aplicativo, porque os auditores precisariam mergulhar na lógica personalizada para determinar sua eficácia na manutenção de qualquer padrão específico. Além disso, o controle de acesso à API geralmente era desnecessário, porque não havia tantas APIs para proteger. A mudança de paradigma no design de aplicativos para favorecer microsserviços e arquiteturas orientadas a serviços aumentou o número de APIs que devem usar uma forma de autorização e controle de acesso. Além disso, a necessidade de manter o acesso baseado em inquilinos em um aplicativo SaaS multilocatário apresenta desafios adicionais de autorização para preservar a locação. As melhores práticas descritas neste guia oferecem vários benefícios:

• A lógica de autorização pode ser centralizada e escrita em uma linguagem declarativa de alto nível que não é específica de nenhuma linguagem de programação.

• A lógica de autorização é abstraída do código do aplicativo e pode ser aplicada como um padrão repetível a todas as APIs em um aplicativo.

• A abstração evita alterações acidentais dos desenvolvedores na lógica de autorização.

• A integração em um aplicativo SaaS é consistente e simples.

• A abstração evita a necessidade de escrever uma lógica de autorização personalizada para cada endpoint da API.

• As auditorias são simplificadas porque um auditor não precisa mais revisar o código para determinar as permissões.

• A abordagem descrita neste guia oferece suporte ao uso de vários paradigmas de controle de acesso, dependendo dos requisitos de uma organização.

• Essa abordagem de autorização e controle de acesso fornece uma maneira simples e direta de manter o isolamento dos dados do inquilino na camada de API em um aplicativo SaaS.

• As melhores práticas fornecem uma abordagem consistente para integrar e desembarcar inquilinos em relação à autorização.

• Essa abordagem oferece diferentes modelos de implantação de autorização (agrupados ou em silos), que têm vantagens e desvantagens, conforme discutido neste guia.

Resultados de negócios desejados

Esta orientação prescritiva descreve padrões de design repetíveis para controles de autorização e acesso à API que podem ser implementados para aplicativos SaaS multilocatários. Essa orientação é destinada a qualquer equipe que desenvolve aplicativos com requisitos de autorização complexos ou necessidades estritas de controle de acesso à API. A arquitetura detalha a criação de um ponto de decisão política (PDP) ou mecanismo de política e a integração de pontos de aplicação de políticas (PEP) nas APIs. Duas opções específicas para criar uma PDP são discutidas: usar Amazon Verified Permissions com o Cedar SDK e usar o Open Policy Agent (OPA) com a linguagem de política Rego. O guia também discute a tomada de decisões de acesso com base em um modelo de controle de acesso baseado em atributos (ABAC) ou modelo de controle de acesso baseado em função (RBAC), ou uma combinação dos dois modelos. Recomendamos que você use os padrões e conceitos de design fornecidos neste guia para informar e padronizar sua implementação de autorização e controle de acesso à API em aplicativos SaaS multilocatários. Essa orientação ajuda a alcançar os seguintes resultados comerciais:

• Arquitetura padronizada de autorização de API para aplicativos SaaS multilocatários — Essa arquitetura distingue entre três componentes: o ponto de administração de políticas (PAP), onde as políticas são armazenadas e gerenciadas, o ponto de decisão de política (PDP), onde essas políticas são avaliadas para chegar a uma decisão de autorização, e o ponto de aplicação de políticas (PEP), que impõe essa decisão. O serviço de autorização hospedado, Permissões verificadas, serve como PAP e PDP. Como alternativa, você mesmo pode criar seu PDP usando um mecanismo de código aberto, como Cedar ou OPA.

• Desacoplamento da lógica de autorização dos aplicativos — a lógica de autorização, quando incorporada ao código do aplicativo ou implementada por meio de um mecanismo de fiscalização ad hoc, pode estar sujeita a alterações acidentais ou maliciosas que causam acesso não intencional aos dados entre inquilinos ou outras violações de segurança. Para ajudar a mitigar essas possibilidades, você pode usar um PAP, como Permissões verificadas, para armazenar políticas de autorização independentemente do código do aplicativo e aplicar uma governança sólida ao gerenciamento dessas políticas. As políticas podem ser mantidas centralmente em uma linguagem declarativa de alto nível, o que torna a manutenção da lógica de autorização muito mais simples do que quando você incorpora políticas em várias seções do código do aplicativo. Essa abordagem também garante que as atualizações sejam aplicadas de forma consistente.

• Abordagem flexível para modelos de controle de acesso — Controle de acesso baseado em função (RBAC), controle de acesso baseado em atributos (ABAC) ou uma combinação dos dois modelos são todas abordagens válidas para controle de acesso. Esses modelos tentam atender aos requisitos de autorização de uma empresa usando abordagens diferentes. Este guia compara e contrasta esses modelos para ajudá-lo a selecionar um modelo que funcione para sua organização. O guia também discute como esses modelos se aplicam a diferentes linguagens de política de autorização, como OPA/Rego e Cedar. As arquiteturas discutidas neste guia permitem que um ou ambos os modelos sejam adotados com sucesso.

• Controle estrito de acesso à API — Este guia fornece um método para proteger as APIs de forma consistente e abrangente em um aplicativo com o mínimo esforço. Isso é particularmente valioso para arquiteturas de aplicativos orientados a serviços ou microsserviços que geralmente usam um grande número de APIs para facilitar as comunicações entre aplicativos. O controle rígido de acesso à API ajuda a aumentar a segurança de um aplicativo e o torna menos vulnerável a ataques ou exploração.

Isolamento de inquilinos e autorização de vários inquilinos

Este guia se refere aos conceitos de isolamento de inquilinos e autorização de vários inquilinos. O isolamento do inquilino se refere aos mecanismos explícitos que você usa em um sistema SaaS para garantir que os recursos de cada inquilino, mesmo quando operam em uma infraestrutura compartilhada, sejam isolados. A autorização multilocatária se refere a autorizar ações de entrada e impedir que elas sejam implementadas no inquilino errado. Um usuário hipotético poderia ser autenticado e autorizado e ainda acessar os recursos de outro inquilino. A autenticação e a autorização não bloquearão esse acesso. Você precisa implementar o isolamento do inquilino para atingir esse objetivo. Para uma discussão mais ampla sobre as diferenças entre esses dois conceitos, consulte a seção Isolamento de inquilinos do whitepaper Fundamentos da Arquitetura SaaS.