Práticas recomendadas

Esta seção lista algumas das conclusões de alto nível deste guia. Para discussões detalhadas sobre cada ponto, siga os links para as seções correspondentes.

Selecione um modelo de controle de acesso que funcione para seu aplicativo

Este guia aborda vários modelos de controle de acesso. Dependendo do aplicativo e dos requisitos comerciais, você deve selecionar um modelo que funcione para você. Considere como você pode usar esses modelos para atender às suas necessidades de controle de acesso e como suas necessidades de controle de acesso podem evoluir, exigindo mudanças na abordagem selecionada.

Implemente um PDP

O ponto de decisão política (PDP) pode ser caracterizado como um mecanismo de políticas ou regras. Esse componente é responsável por aplicar políticas ou regras e retornar uma decisão sobre se um determinado acesso é permitido. Um 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 microsserviços APIs, camadas de Backend for Frontend (BFF) ou qualquer outro componente do aplicativo. Um PDP pode ser usado para impor os requisitos de locação de forma consistente em um aplicativo.

Implemente PEPs para cada API em seu aplicativo

A implementação de um ponto de fiscalização de políticas (PEP) exige determinar onde a fiscalização do controle de acesso deve ocorrer em um aplicativo. Como primeira etapa, localize os pontos em seu aplicativo onde você pode incorporar PEPs. Considere esse princípio ao decidir onde adicionar PEPs:

Se um aplicativo expõe uma API, deve haver autorização e controle de acesso nessa API.

Considere usar Amazon Verified Permissions ou OPA como um mecanismo de política para seu PDP

As permissões verificadas da Amazon têm vantagens em relação aos mecanismos de política personalizados. É um serviço de autorização e gerenciamento de permissões escalável e refinado para os aplicativos que você cria. Ele suporta políticas de escrita na linguagem declarativa de código aberto de alto nível Cedar. Como resultado, implementar um mecanismo de políticas usando permissões verificadas exige menos esforço de desenvolvimento do que implementar sua própria solução. Além disso, as Permissões Verificadas são totalmente gerenciadas, para que você não precise gerenciar a infraestrutura subjacente.

O Open Policy Agent (OPA) tem vantagens sobre os mecanismos de política personalizados. A OPA e sua avaliação de políticas com a Rego fornecem um mecanismo de políticas flexível e pré-construído que suporta a redação de políticas em uma linguagem declarativa de alto nível. Isso faz com que o nível de esforço necessário para implementar um mecanismo de políticas seja significativamente menor do que para criar sua própria solução. Além disso, o OPA está rapidamente se tornando um padrão de autorização bem suportado.

Implemente um plano de controle para DevOps OPA para monitoramento e registro

Como o OPA não fornece um meio de atualizar e rastrear alterações na lógica de autorização por meio do controle de origem, recomendamos que você implemente um plano de controle para executar essas funções. Isso permitirá que as atualizações sejam distribuídas mais facilmente aos agentes do OPA, especialmente se o OPA estiver operando em um sistema distribuído, o que reduzirá a carga administrativa do uso do OPA. Além disso, um plano de controle pode ser usado para coletar registros para agregação e monitorar o status dos agentes OPA.

Configure os recursos de registro e observabilidade nas Permissões verificadas

As permissões verificadas fornecem acesso fácil aos recursos de observabilidade. Você pode configurar o serviço para registrar todas as tentativas de acesso a grupos de CloudWatch registros da Amazon AWS CloudTrail, buckets S3 ou fluxos de entrega do Amazon Data Firehose para permitir uma resposta rápida a incidentes de segurança e solicitações de auditoria. Além disso, você pode monitorar a integridade do serviço por meio do AWS Health Dashboard. Como o Verified Permissions é um serviço gerenciado, sua integridade é mantida por AWS, e você pode configurar seus recursos de observabilidade usando outros serviços AWS gerenciados.

Use um pipeline de CI/CD para provisionar e atualizar repositórios e políticas de políticas em Permissões verificadas

O Verified Permissions é um serviço gerenciado, portanto, você não precisa gerenciar, configurar ou manter planos de controle ou agentes para realizar atualizações. No entanto, ainda recomendamos que você use um pipeline de integração contínua e implantação contínua (CI/CD) para administrar a implantação de repositórios de políticas de Permissões Verificadas e atualizações de políticas usando o SDK. AWS Esse esforço pode eliminar o esforço manual e reduzir a probabilidade de erros do operador ao fazer alterações nos recursos de permissões verificadas.

Determine se os dados externos são necessários para decisões de autorização e selecione um modelo para acomodá-los

Se um PDP puder tomar decisões de autorização com base apenas nos dados contidos em um JSON Web Token (JWT), geralmente não é necessário importar dados externos para auxiliar na tomada dessas decisões. Se você usa Permissões verificadas ou OPA como PDP, ele também pode aceitar entradas adicionais passadas como parte da solicitação, mesmo que esses dados não estejam incluídos em um JWT. Para Permissões verificadas, você pode usar um parâmetro de contexto para os dados adicionais. Para OPA, você pode usar dados JSON como entrada de sobrecarga. Se você usa um JWT, os métodos de entrada de contexto ou sobrecarga geralmente são muito mais fáceis do que manter dados externos em outra fonte. Se forem necessários dados externos mais complexos para tomar decisões de autorização, a OPA oferece vários modelos para recuperar dados externos, e as Permissões Verificadas podem complementar os dados em suas solicitações de autorização referenciando fontes externas com um serviço de autorização.