Perguntas frequentes

Esta seção fornece respostas às perguntas mais comuns sobre a implementação do controle de acesso e autorização da API em aplicativos SaaS multilocatários.

P: Qual é a diferença entre autorização e autenticação?

R. A autenticação é o processo de verificar quem é um usuário. A autorização concede permissões aos usuários para acessar um recurso específico.

P: Qual é a diferença entre autorização e isolamento de inquilinos em um aplicativo SaaS?

R. O isolamento de inquilinos se refere a mecanismos explícitos usados em um sistema SaaS para garantir que os recursos de cada inquilino, mesmo quando operando em infraestrutura compartilhada, sejam isolados. A autorização multilocatária se refere à autorização de ações de entrada e à prevenção de que elas sejam implementadas no inquilino errado. Um usuário hipotético pode ser autenticado e autorizado, mas ainda pode acessar os recursos de outro inquilino. Nada sobre autenticação e autorização necessariamente bloqueia esse acesso, mas o isolamento do inquilino é necessário para atingir esse objetivo. Para obter mais informações sobre esses dois conceitos, consulte a discussão sobre isolamento de inquilinos no whitepaper AWS SaaS Architecture Fundamentals.

P: Por que preciso considerar o isolamento de inquilinos para meu aplicativo SaaS?

R. Os aplicativos SaaS têm vários inquilinos. Um inquilino pode ser uma organização cliente ou qualquer entidade externa que use esse aplicativo SaaS. Dependendo de como o aplicativo foi projetado, isso significa que os locatários podem estar acessando APIs, bancos de dados ou outros recursos compartilhados. É importante manter o isolamento do inquilino, ou seja, construções que controlem rigorosamente o acesso aos recursos e bloqueiem qualquer tentativa de acessar os recursos de outro inquilino, para impedir que os usuários de um inquilino acessem as informações privadas de outro inquilino. Os aplicativos SaaS geralmente são projetados para garantir que o isolamento do inquilino seja mantido em todo o aplicativo e que os inquilinos possam acessar somente seus próprios recursos.

P: Por que preciso de um modelo de controle de acesso?

R. Os modelos de controle de acesso são usados para criar um método consistente de determinar como conceder acesso aos recursos em um aplicativo. Isso pode ser feito atribuindo funções a usuários que estejam estreitamente alinhadas com a lógica de negócios, ou pode ser baseado em outros atributos contextuais, como a hora do dia ou se um usuário atende a uma condição predefinida. Os modelos de controle de acesso formam a lógica básica que seu aplicativo usa ao tomar decisões de autorização para determinar as permissões do usuário.

P: O controle de acesso à API é necessário para meu aplicativo?

R. Sim. As APIs devem sempre verificar se o chamador tem o acesso apropriado. O controle de acesso generalizado à API também garante que o acesso seja concedido apenas com base nos inquilinos, para que o isolamento apropriado possa ser mantido.

P: Por que mecanismos de políticas ou PDPs são recomendados para autorização?

R. Um ponto de decisão de política (PDP) permite que a lógica de autorização no código do aplicativo seja transferida para um sistema separado. Isso pode simplificar o código do aplicativo. Ele também fornece uma interface easy-to-use idempotente para tomar decisões de autorização para APIs, microsserviços, camadas de Backend for Frontend (BFF) ou qualquer outro componente do aplicativo.

P. O que é um PEP?

R. Um ponto de fiscalização de políticas (PEP) é responsável por receber solicitações de autorização que são enviadas ao PDP para avaliação. Um PEP pode estar em qualquer lugar em um aplicativo em que os dados e os recursos devem ser protegidos ou onde a lógica de autorização é aplicada. Os PEPs são relativamente simples em comparação com os PDPs. Um PEP é responsável somente por solicitar e avaliar uma decisão de autorização e não exige que nenhuma lógica de autorização seja incorporada a ela.

P: Como devo escolher entre Amazon Verified Permissions e OPA?

R. Para escolher entre permissões verificadas e Open Policy Agent (OPA), tenha sempre em mente seu caso de uso e seus requisitos exclusivos. As Permissões Verificadas fornecem uma maneira totalmente gerenciada de definir permissões refinadas, auditar permissões em todos os aplicativos e centralizar o sistema de administração de políticas para seus aplicativos, ao mesmo tempo em que atende aos requisitos de latência do aplicativo com processamento em milissegundos. O OPA é um mecanismo de políticas de uso geral de código aberto que também pode ajudá-lo a unificar a política em toda a sua pilha de aplicativos. Para executar o OPA, você precisa hospedá-lo em seu AWS ambiente, normalmente com um contêiner ou AWS Lambda funções.

O Verified Permissions usa a linguagem de política de código aberto Cedar, enquanto o OPA usa o Rego. Portanto, a familiaridade com um desses idiomas pode fazer com que você escolha essa solução. No entanto, recomendamos que você leia sobre as duas linguagens e depois resolva o problema que está tentando resolver para encontrar a melhor solução para seu caso de uso.

P: Existem alternativas de código aberto para permissões verificadas e OPA?

R. Existem alguns sistemas de código aberto que são semelhantes às Permissões Verificadas e ao Open Policy Agent (OPA), como a Common Expression Language (CEL). Este guia se concentra nas Permissões Verificadas, como um serviço de gerenciamento de permissões escalável e de autorização refinado, e na OPA, que é amplamente adotada, documentada e adaptável a diversos tipos de aplicativos e requisitos de autorização.

P: Preciso escrever um serviço de autorização para usar o OPA ou posso interagir diretamente com o OPA?

R. Você pode interagir diretamente com a OPA. Um serviço de autorização no contexto desta orientação se refere a um serviço que traduz solicitações de decisão de autorização em consultas OPA e vice-versa. Se seu aplicativo puder consultar e aceitar respostas de OPA diretamente, não há necessidade de introduzir essa complexidade adicional.

P: Como faço para monitorar meus agentes de OPA para fins de disponibilidade e auditoria?

R. O OPA fornece registro e monitoramento básico do tempo de atividade, embora sua configuração padrão provavelmente seja insuficiente para implantações corporativas. Para obter mais informações, consulte a DevOps seção Monitoramento e registro anterior neste guia.

P: Como posso monitorar as permissões verificadas para fins de disponibilidade e auditoria?

R. O Verified Permissions é um serviço AWS gerenciado e pode ser monitorado quanto à disponibilidade por meio do AWS Health Dashboard. Além disso, o Verified Permissions é capaz de fazer AWS CloudTrail login no Amazon CloudWatch Logs, no Amazon S3 e no Amazon Data Firehose.

P: Quais sistemas operacionais e serviços da AWS posso usar para executar o OPA?

R. Você pode executar o OPA no macOS, Windows e Linux. Os agentes OPA podem ser configurados em agentes do Amazon Elastic Compute Cloud (Amazon EC2), bem como em serviços de conteinerização, como o Amazon Elastic Container Service (Amazon ECS) e o Amazon Elastic Kubernetes Service (Amazon EKS).

P: Quais sistemas operacionais e AWS serviços posso usar para executar as Permissões Verificadas?

A. O Verified Permissions é um serviço AWS gerenciado e é operado pela AWS. Nenhuma configuração, instalação ou hospedagem adicional é necessária para usar as Permissões Verificadas, exceto pela capacidade de fazer solicitações de autorização para o serviço.

P: Posso executar o OPA em? AWS Lambda

R. Você pode executar o OPA na biblioteca Lambda as a Go. Para obter informações sobre como você pode fazer isso com um autorizador Lambda do API Gateway, consulte a postagem do AWS blog Criando um autorizadorLambda personalizado usando o Open Policy Agent.

P: Como devo decidir entre uma abordagem de PDP distribuída e uma abordagem de PDP centralizada?

R. Isso depende da sua aplicação. Provavelmente, será determinado com base na diferença de latência entre um modelo PDP distribuído e centralizado. Recomendamos que você crie uma prova de conceito e teste o desempenho do seu aplicativo para verificar sua solução.

P: Posso usar o OPA para casos de uso além das APIs?

R. Sim. A documentação do OPA fornece exemplos para Kubernetes, Envoy, Docker, Kafka, SSH e sudo e Terraform. Além disso, o OPA pode retornar respostas JSON arbitrárias às consultas usando regras parciais do Rego. Dependendo da consulta, o OPA pode ser usado para responder a muitas perguntas com respostas JSON.

P: Posso usar permissões verificadas para casos de uso além das APIs?

R. Sim. As permissões verificadas podem fornecer uma DENY resposta ALLOW ou para qualquer solicitação de autorização recebida. As permissões verificadas podem fornecer respostas de autorização para qualquer aplicativo ou serviço que exija decisões de autorização.

P: Posso criar políticas em Permissões verificadas usando a linguagem de política do IAM?

R. Não. Você deve usar a linguagem de política do Cedar para criar políticas. O Cedar foi projetado para oferecer suporte ao gerenciamento de permissões para recursos de aplicativos do cliente, enquanto a linguagem de política AWS Identity and Access Management (IAM) evoluiu para oferecer suporte ao controle de acesso aos AWS recursos.