Práticas recomendadas para criar um modelo de autorização

Ao se preparar para usar o serviço Amazon Verified Permissions em um software, possivelmente será difícil começar a escrever declarações de política imediatamente. Isso seria semelhante a iniciar o desenvolvimento de outras partes de um aplicativo escrevendo SQL declarações ou API especificações antes de decidir totalmente o que o aplicativo deveria fazer. Em vez disso, você deve começar com uma experiência de usuário, buscando compreender claramente o que os usuários finais verão ao gerenciar permissões na interface do usuário da aplicação. Em seguida, trabalhe com base nessa experiência para chegar a uma abordagem de implementação.

Ao realizar esse trabalho, você se perguntará, por exemplo:

• Quais são meus recursos? Eles se relacionam entre si? Por exemplo, os arquivos residem em uma pasta?

• Quais ações as entidades principais podem realizar em cada recurso?

• Como as entidades principais adquirem essas permissões?

• Você quer que seus usuários finais escolham entre permissões predefinidas, como “Administrador”, “Operador” ou “”, ou eles deveriam criar ReadOnly declarações de política ad-hoc? Ou ambos?

• As permissões devem ser herdadas entre recursos, como arquivos que herdam permissões de uma pasta pai?

• Quais tipos de consultas são necessárias para renderizar a experiência do usuário? Por exemplo, você precisa listar todos os recursos que uma entidade principal pode acessar para renderizar a página inicial desse usuário?

• Os usuários podem se privar acidentalmente de seus próprios recursos? Isso precisa ser evitado?

O resultado final desse exercício é chamado de modelo de autorização; ele define as entidades principais, os recursos, as ações e como eles se relacionam entre si. A produção desse modelo não requer conhecimento exclusivo do Cedar ou do serviço Verified Permissions. Ela é antes de mais nada um exercício de design de experiência do usuário, como qualquer outro, e pode se manifestar em artefatos como modelos de interface, diagramas lógicos e uma descrição geral de como as permissões influenciam o que os usuários veem no produto. O Cedar foi projetado para ser flexível o suficiente para atender aos clientes em um modelo, em vez de forçar o modelo a se curvar de forma anormal para estar em conformidade com a implementação do Cedar. Como resultado, obter uma compreensão precisa da experiência desejada do usuário é a melhor maneira de chegar a um modelo ideal.

Esta seção fornece orientação geral sobre como abordar o exercício de design, pontos a serem observados e uma série de práticas recomendadas para usar o Verified Permissions com sucesso.

Além das diretrizes apresentadas aqui, lembre-se de considerar as práticas recomendadas no Guia de referência da linguagem de política Cedar.

Não existe um modelo canônico “correto”

Quando você cria um modelo de autorização, não há uma resposta única e exclusivamente correta. Aplicações diferentes podem usar diferentes modelos de autorização para conceitos semelhantes, e está tudo certo. Por exemplo, considere a representação do sistema de arquivos de um computador. Quando você cria um arquivo em um sistema operacional semelhante ao UNIX, ele não herda automaticamente as permissões da pasta principal. Por outro lado, em muitos outros sistemas operacionais e na maioria dos serviços de compartilhamento de arquivos on-line, os arquivos herdam as permissões de sua pasta pai. Ambas as opções são válidas, dependendo das circunstâncias da otimização da aplicação.

A exatidão de uma solução de autorização não é absoluta, mas o que deve ser avaliado é se ela oferece a experiência que seus clientes desejam e protege os recursos da maneira esperada. Se o seu modelo de autorização cumprir isso, ele será bem-sucedido.

É por isso que começar seu design com a experiência de usuário desejada é o pré-requisito mais importante para a criação de um modelo de autorização eficaz.

Concentre-se em seus recursos além das API operações

Na maioria das aplicações voltadas para o consumidor, as permissões são modeladas com base nos recursos compatíveis com a aplicação. Por exemplo, uma aplicação de compartilhamento de arquivos pode representar permissões como ações que podem ser executadas em um arquivo ou uma pasta. Esse é um modelo bom e simples que abstrai a implementação subjacente e as operações de back-endAPI.

Por outro lado, outros tipos de aplicativos, especialmente serviços da Web, frequentemente criam permissões em torno das próprias API operações. Por exemplo, se um serviço web fornece um API nomecreateThing(), o modelo de autorização pode definir uma permissão correspondente ou um nome action createThing in Cedar. Isso funciona em muitas situações e facilita a compreensão das permissões. Para invocar a operação createThing, você precisa da permissão de ação createThing. Parece simples, não é?

Você descobrirá que o processo de introdução no console de Permissões verificadas inclui a opção de criar seus recursos e ações diretamente de umAPI. Essa é uma linha de base útil: um mapeamento direto entre seu repositório de políticas e o API que ele autoriza.

No entanto, essa abordagem API focada pode ser menos do que ideal, porque APIs são apenas um indicador do que seus clientes estão realmente tentando proteger: os dados e os recursos subjacentes. Se vários APIs controlam o acesso aos mesmos recursos, pode ser difícil para os administradores raciocinar sobre os caminhos para esses recursos e gerenciar o acesso adequadamente.

Por exemplo, considere um diretório de usuários que contém os membros de uma organização. Os usuários podem ser organizados em grupos, e uma das metas de segurança é proibir a detecção de associações a grupos por partes não autorizadas. O serviço que gerencia esse diretório de usuários fornece duas API operações:

• listMembersOfGroup

• listGroupMembershipsForUser

Os clientes podem usar qualquer uma dessas operações para detectar a associação a grupos. Portanto, o administrador de permissões deve se lembrar de coordenar o acesso às duas operações. Isso é ainda mais complicado se você optar posteriormente por adicionar uma nova API operação para tratar de outros casos de uso, como os seguintes.

• isUserInGroups(uma novidade API para testar rapidamente se um usuário pertence a um ou mais grupos)

Do ponto de vista da segurança, isso API abre um terceiro caminho para descobrir associações de grupos, interrompendo as permissões cuidadosamente elaboradas pelo administrador.

Recomendamos que você ignore a API semântica e, em vez disso, se concentre nos dados e recursos subjacentes e em suas operações de associação. Aplicar essa abordagem ao exemplo de associação a um grupo levaria a uma permissão abstrataviewGroupMembership, como a que cada uma das três API operações deve consultar.

APINome	Permissões
listMembersOfGroup	requer a permissão viewGroupMembership no grupo
listGroupMembershipsForUser	requer a permissão viewGroupMembership no usuário
isUserInGroups	requer a permissão viewGroupMembership no usuário

Ao definir essa permissão, o administrador controlará perpetuamente o acesso à detecção de associações a grupos. Como contrapartida, cada API operação agora deve documentar as possíveis permissões necessárias, e o administrador deve consultar essa documentação ao criar permissões. Essa pode ser uma compensação válida quando necessário para atender aos seus requisitos de segurança.

A autorização composta é normal

A autorização composta ocorre quando uma única atividade de usuário, como clicar em um botão na interface da aplicação, requer várias consultas de autorização individuais para determinar se essa atividade é permitida. Por exemplo, mover um arquivo para um novo diretório em um sistema de arquivos pode exigir três permissões diferentes: a capacidade de excluir um arquivo do diretório de origem, a capacidade de adicionar um arquivo ao diretório de destino e, possivelmente, a capacidade de tocar no próprio arquivo (dependendo da aplicação).

Se você é iniciante na criação de um modelo de autorização, talvez pense que cada decisão de autorização deve ser resolvida em uma única consulta de autorização. Mas isso pode resultar em modelos excessivamente complexos e declarações de política complicadas. Na prática, o uso de autorizações compostas pode ser útil para ajudar você a produzir um modelo de autorização mais simples. Uma das medidas de um modelo de autorização bem projetado é que, quando você tem ações individuais suficientemente decompostas, suas operações compostas, como mover um arquivo, podem ser representadas por uma agregação intuitiva de primitivas.

Outra situação em que a autorização composta ocorre é quando várias partes estão envolvidas no processo de concessão de uma permissão. Considere um diretório organizacional em que os usuários possam ser membros de grupos. Uma abordagem simples é dar permissão ao proprietário do grupo para adicionar qualquer pessoa. Mas, e se você quiser que seus usuários primeiro deem consentimento antes serem adicionados? Isso introduz um acordo de handshake no qual tanto o usuário quanto o grupo devem consentir com a associação. Para fazer isso, você pode introduzir outra permissão vinculada ao usuário e especificar se o usuário pode ser adicionado a qualquer grupo ou a um grupo específico. Quando um chamador tentar adicionar membros a um grupo posteriormente, a aplicação deverá aplicar os dois lados das permissões: que o chamador tenha permissão para adicionar membros ao grupo especificado e que o usuário individual que está sendo adicionado tenha as permissões para ser adicionado. Quando existem handshakes de N direções, é comum observar N consultas de autorização composta para aplicar cada parte do contrato.

Se você se deparar com um desafio de design em que há vários recursos envolvidos e não estiver claro como modelar as permissões, isso poderá ser indício de que você tem um cenário de autorização composta. Nesse caso, a solução pode ser a decomposição da operação em várias verificações de autorização individuais.

Considerações sobre multilocação

Talvez você queira desenvolver aplicativos para uso por vários clientes — empresas que consomem seu aplicativo ou locatários — e integrá-los às Permissões Verificadas da Amazon. Antes de desenvolver seu modelo de autorização, desenvolva uma estratégia multilocatária. Você pode gerenciar as políticas de seus clientes em um repositório de políticas compartilhado ou atribuir a cada um um repositório de políticas por inquilino.

1. Um repositório de políticas compartilhado

   Todos os inquilinos compartilham um único repositório de apólices. O aplicativo envia todas as solicitações de autorização para o repositório de políticas compartilhadas.

2. Armazenamento de políticas por inquilino

   Cada inquilino tem um repositório de políticas dedicado. O aplicativo consultará diferentes repositórios de políticas para obter uma decisão de autorização, dependendo do inquilino que fizer a solicitação.

Nenhuma das estratégias cria um volume relativamente maior de solicitações de autorização que podem ter um impacto na sua fatura. AWS Então, como você deve projetar sua abordagem? Veja a seguir condições comuns que podem contribuir para sua estratégia de autorização de multilocação de Permissões Verificadas.

Isolamento das políticas do inquilino

O isolamento das políticas de cada inquilino das demais é importante para proteger os dados do inquilino. Quando cada inquilino tem seu próprio repositório de políticas, cada um tem seu próprio conjunto isolado de políticas.

Fluxo de autorização

Você pode identificar um inquilino fazendo uma solicitação de autorização com um ID do repositório de políticas na solicitação, com repositórios de políticas por inquilino. Com um repositório de políticas compartilhado, todas as solicitações usam o mesmo ID do repositório de políticas.

Gerenciamento de modelos e esquemas

Seus modelos de políticas e um esquema de armazenamento de políticas adicionam um nível de sobrecarga de design e manutenção em cada repositório de políticas.

Gerenciamento de políticas globais

Talvez você queira aplicar algumas políticas globais a cada inquilino. O nível de sobrecarga do gerenciamento de políticas globais varia entre os modelos de armazenamento de políticas compartilhados e por inquilino.

Desembarque do inquilino

Alguns inquilinos contribuirão com elementos para seu esquema e políticas que são específicos para o caso deles. Quando um inquilino não está mais ativo na sua organização e você deseja remover seus dados, o nível de esforço varia de acordo com o nível de isolamento de outros locatários.

Cotas de recursos de serviço

O Verified Permissions tem cotas de recursos e taxas de solicitação que podem influenciar sua decisão de multilocação. Para obter mais informações sobre cotas, consulte Cotas para recursos.

Comparando repositórios de políticas compartilhados e repositórios de políticas por inquilino

Cada consideração exige seu próprio nível de comprometimento de tempo e recursos em modelos de repositório de políticas compartilhados e por inquilino.

Consideração	Nível de esforço em um repositório de políticas compartilhado	Nível de esforço em repositórios de políticas por inquilino
Isolamento das políticas do inquilino	Médio.Deve incluir identificadores de inquilinos nas políticas e solicitações de autorização.	Baixo. O isolamento é o comportamento padrão. As políticas específicas do inquilino são inacessíveis para outros inquilinos.
Fluxo de autorização	Baixo. Todas as consultas têm como alvo um repositório de políticas.	Médio. É necessário manter mapeamentos entre cada inquilino e seu ID do repositório de políticas.
Gerenciamento de modelos e esquemas	Baixo. Deve fazer com que um esquema funcione para todos os inquilinos.	Alto. Esquemas e modelos podem ser menos complexos individualmente, mas as mudanças exigem mais coordenação e complexidade.
Gerenciamento de políticas globais	Baixo. Todas as políticas são globais e podem ser atualizadas centralmente.	Alto. Você deve adicionar políticas globais a cada repositório de políticas na integração. Replique as atualizações de políticas globais entre vários repositórios de políticas.
Desembarque do inquilino	Médio. Deve identificar e excluir somente as políticas específicas do inquilino.	Baixo. Exclua o repositório de políticas.
Cotas de recursos de serviço	Alto. Os inquilinos compartilham cotas de recursos que afetam os repositórios de políticas, como tamanho do esquema, tamanho da política por recurso e fontes de identidade por armazenamento de políticas.	Baixo. Cada inquilino tem cotas de recursos dedicadas.

Como escolher

Cada aplicativo multilocatário é diferente. Compare cuidadosamente as duas abordagens e suas considerações antes de tomar uma decisão arquitetônica.

Se seu aplicativo não exigir políticas específicas para inquilinos e usar uma única fonte de identidade, um repositório de políticas compartilhado para todos os locatários provavelmente será a solução mais eficaz. Isso resulta em um fluxo de autorização mais simples e no gerenciamento global de políticas. Excluir um inquilino usando um repositório de políticas compartilhadas exige menos esforço porque o aplicativo não precisa excluir políticas específicas do inquilino.

Mas se seu aplicativo exigir muitas políticas específicas para inquilinos ou usar várias fontes de identidade, é provável que os armazenamentos de políticas por locatário sejam mais eficazes. Você pode controlar o acesso às políticas de inquilino com IAM políticas que concedem permissões por inquilino a cada repositório de políticas. Excluir um inquilino envolve a exclusão de seu repositório de políticas; em um shared-policy-store ambiente, você deve encontrar e excluir políticas específicas do inquilino.

Quando possível, preencha o escopo da política

O escopo da política é a parte de uma declaração de política do Cedar após as palavras-chave permit ou forbid e entre os parênteses de abertura.

É recomendável que você preencha os valores para principal e resource sempre que possível. Isso permite que o Verified Permissions indexe as políticas para uma recuperação mais eficiente e, portanto, melhore o desempenho. Se você precisar conceder as mesmas permissões a várias entidades principais ou recursos diferentes, recomendamos que você utilize um modelo de política e o anexe a cada par de entidade principal/recurso.

Evite criar uma política grande que contenha listas de entidades principais e recursos em uma cláusula when. Isso provavelmente fará com que você se depare com limites de escalabilidade ou desafios operacionais. Por exemplo, para adicionar ou remover um único usuário de uma lista grande em uma política, é necessário ler toda a política, editar a lista, escrever a nova política na íntegra e lidar com erros de simultaneidade se um administrador substituir as alterações de outro. Por outro lado, com o uso de várias permissões refinadas, adicionar ou remover um usuário é tão simples quanto adicionar ou remover a política que se aplica a elas.

Todos os recursos residem em um contêiner

Quando você cria um modelo de autorização, cada ação deve estar associada a um recurso específico. Com uma ação como viewFile, o recurso ao qual você pode aplicá-la é intuitivo: um arquivo individual ou talvez uma coleção de arquivos em uma pasta. No entanto, uma operação como createFile é menos intuitiva. Ao modelar a capacidade de criar um arquivo, a qual recurso ele se aplica? Não pode ser ao arquivo em si, pois o arquivo ainda não existe.

Esse é um exemplo do problema generalizado da criação de recursos. A criação de recursos é um problema de bootstrapping. Deve haver alguma maneira de conceder permissão para criar recursos mesmo quando esses recursos ainda não existirem. A solução é reconhecer que cada recurso deve existir em algum contêiner, e é o próprio contêiner que atua como ponto de ancoragem para as permissões. Por exemplo, se uma pasta já existe no sistema, a capacidade de criar um arquivo pode ser modelada como uma permissão nessa pasta, pois esse é o local em que as permissões precisam estar para instanciar o novo recurso.

permit (
    principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d",
    action == Action::"createFile",
    resource == Folder::"c863f89b-461f-4fc2-b638-e5fa5f79a48b"
);

Mas e se não houver nenhuma pasta? Talvez se trate de uma nova conta de cliente em uma aplicação na qual ainda não existam recursos. Nesse caso, ainda há um contexto que pode ser entendido intuitivamente por meio da pergunta: onde o cliente pode criar novos arquivos? Você não quer que eles criem arquivos em uma conta de cliente aleatória. Em vez disso, há um contexto implícito: o limite da conta do próprio cliente. Portanto, a própria conta representa o contêiner para criação de recursos, e isso pode ser explicitamente modelado em uma política semelhante ao exemplo a seguir.

// Grants permission to create files within an account,
// or within any sub-folder inside the account.
permit (
    principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d",
    action == Action::"createFile",
    resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b"
);

Mas, e se não houver contas? Você pode optar por criar o fluxo de trabalho de inscrição do cliente para que ele crie novas contas no sistema. Nesse caso, você precisará de um contêiner para manter o limite externo no qual o processo pode criar as contas. Esse contêiner de nível raiz representa o sistema como um todo e pode ser chamado de “raiz do sistema”. No entanto, decidir se isso será necessário ou não e como nomeá-lo é de sua responsabilidade, o proprietário da aplicação.

Nesse exemplo de aplicação, a hierarquia de contêineres resultante teria, portanto, a seguinte aparência:

Esse é um exemplo de hierarquia. Outros exemplos também são válidos. É importante lembrar que a criação de recursos sempre acontece no contexto de um contêiner de recursos. Esses contêineres podem estar implícitos, como um limite de conta, e podem ser facilmente ignorados. Ao projetar seu modelo de autorização, não deixe de observar essas suposições implícitas, para que elas possam ser formalmente documentadas e representadas no modelo de autorização.

Separe as entidades principais dos contêineres de recursos

Quando você está projetando uma hierarquia de recursos, uma das inclinações comuns, especialmente para aplicações voltadas para o consumidor, é usar a identidade do usuário do cliente como contêiner de recursos em uma conta de cliente.

É recomendável que você trate essa estratégia como um antipadrão. Isso ocorre porque há uma tendência natural nas aplicações mais avançadas de delegar acesso a usuários adicionais. Por exemplo, você pode optar por introduzir contas “familiares”, nas quais outros usuários podem compartilhar recursos de conta. Da mesma forma, às vezes, os clientes corporativos desejam designar vários membros da força de trabalho como operadores para partes da conta. Talvez você também precise transferir a propriedade de uma conta para outro usuário ou mesclar os recursos de várias contas.

Quando uma identidade de usuário é usada como contêiner de recursos para uma conta, torna-se mais difícil obter os cenários anteriores. O mais alarmante é que, se outras pessoas tiverem acesso ao contêiner da conta nessa abordagem, elas poderão inadvertidamente receber acesso para modificar a própria identidade do usuário, como, por exemplo, alterar as credenciais de e-mail ou login de Jane.

Portanto, quando possível, uma abordagem mais resiliente é separar as entidades principais dos contêineres de recursos e modelar a conexão entre eles usando conceitos como “permissões de administrador” ou “propriedade”.

Quando há uma aplicação que não consegue seguir esse modelo desacoplado, recomendamos que você o simule o máximo possível ao criar um modelo de autorização. Por exemplo, uma aplicação que tenha um único conceito chamado Customer, que encapsula a identidade do usuário, as credenciais de login e os recursos que elas possuem, pode mapear isso para um modelo de autorização que contenha uma única entidade lógica para Customer Identity (contendo nome, e-mail etc.) e uma entidade lógica separada para Customer Resources ou Customer Account, atuando como nó pai de todos os recursos que elas possuem. Ambas as entidades podem compartilhar o mesmo Id, mas com um Type diferente.

Usando atributos ou modelos para representar relacionamentos

Há duas formas principais de expressar relações entre recursos. Quando usar um ou outro depende se a relação já está armazenada ou não no banco de dados do aplicativo e usada por outros motivos, como conformidade. Se for, adote a abordagem baseada em atributos. Caso contrário, adote a abordagem baseada em modelos.

Relacionamentos baseados em atributos

Os atributos podem ser usados como uma entrada para a decisão de autorização para representar uma relação entre um principal e um ou mais recursos.

Esse padrão é apropriado quando o relacionamento é rastreado e gerenciado para fins além do gerenciamento de permissões. Por exemplo, é necessário registrar o titular da conta principal para conformidade financeira com as regras do Know Your Customer. As permissões são derivadas desses relacionamentos. Os dados do relacionamento são gerenciados fora do sistema de autorização e obtidos como entrada ao tomar uma decisão de autorização.

O exemplo a seguir mostra como um relacionamento entre um usuário Alice e várias contas nas quais ela é a principal titular da conta pode ser representado:

// Using a user attribute to represent the primary account holder relationship 
{
  "id": "df82e4ad-949e-44cb-8acf-2d1acda71798",
  "name": "alice",  
  "email": "[e-mail]",  
  "primaryOnAccounts": [
    "Account::\"c943927f-d803-4f40-9a53-7740272cb969\"",
    "Account::\"b8ee140c-fa09-46c3-992e-099438930894\""
  ]
}

E, posteriormente, usando o atributo em uma política:

// Derived relationship permissions
  permit (
    principal,
    action in Action::"primaryAccountHolderActions",
    resource
  )when {
    resource in principal.primaryOnAccounts
  };

Por outro lado, o mesmo relacionamento pode ser representado como um atributo no recurso chamado primaryAccountHolders que contém um conjunto de usuários.

Se houver vários tipos de relacionamento entre principais e recursos, eles devem ser modelados como atributos diferentes. Por exemplo, se as contas também puderem ter signatários autorizados e essas pessoas tiverem permissões diferentes na conta, isso será representado como um atributo diferente.

No caso acima, também Alice pode ser um signatário autorizado em uma terceira conta. O exemplo a seguir mostra como isso pode ser representado:

// Using user attributes to represent the primary account holder and authorized signatory relationships 
{
  "id": "df82e4ad-949e-44cb-8acf-2d1acda71798",
  "name": "alice",  
  "email": "[e-mail]",  
  "primaryOnAccounts": [
    "Account::\"c943927f-d803-4f40-9a53-7740272cb969\"",
    "Account::\"b8ee140c-fa09-46c3-992e-099438930894\""
  ],
  "authorizedSignatoryOnAccounts": [
    "Account::\"661817a9-d478-4096-943d-4ef1e082d19a\""
  ]
}

A seguir estão as políticas correspondentes:

// Derived relationship permissions

  permit (
    principal,
    action in Action::"primaryAccountHolderActions",
    resource
  )when {
    resource in principal.primaryOnAccounts
  };
  permit (
    principal,
    action in Action::"authorizedSignatoryActions",
    resource
  )when {
    resource in principal.authorizedSignatoryOnAccounts
  };

Relacionamentos baseados em modelos

Se a relação entre os recursos existir exclusivamente para fins de gerenciamento de permissões, é apropriado armazenar essa relação como uma política ou modelo vinculado a um modelo. Você também pode pensar nesses modelos como funções atribuídas a um recurso específico.

Por exemplo, em um sistema de gerenciamento de documentos, o proprietário do documentoAlice,, pode optar por conceder permissão a outro usuárioBob,, para contribuir com o documento. Isso estabelece uma relação de contribuição entre o documento de Bob e Alice. O único propósito desse relacionamento é conceder permissão para editar e comentar no documento e, portanto, esse relacionamento pode ser representado como um modelo. Nesses casos, a abordagem recomendada é criar um modelo para cada tipo de relacionamento. Nos exemplos a seguir, há dois tipos de relacionamento Contributor eReviewer, portanto, dois modelos.

Os modelos a seguir podem ser usados para criar políticas vinculadas a modelos para usuários individuais.

  // Managed relationship permissions - Contributor template
  permit (
    principal == ?principal,  
    action in Action::"DocumentContributorActions",
    resource in ?resource
  );
    
  // Managed relationship permissions - Reviewer template
  permit (
    principal == ?principal,  
    action in Action::"DocumentReviewerActions",
    resource in ?resource
  );

Os modelos a seguir podem ser usados para criar políticas vinculadas a modelos para grupos de usuários. A única diferença dos modelos para usuários individuais é o uso do in operador em vez do==.

  // Managed relationship permissions - Contributor template
  permit (
    principal in ?principal,  
    action in Action::"DocumentContributorActions",
    resource in ?resource
  );

  // Managed relationship permissions - Reviewer template
  permit (
    principal in ?principal,  
    action in Action::"DocumentReviewerActions",
    resource in ?resource
  );

Em seguida, você pode usar esses modelos para criar políticas, como as seguintes, representando permissões de relacionamento gerenciadas sempre que o acesso é concedido a um documento.

  //Managed relationship permissions
  permit (
    principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798",  
    action in Action::"DocumentContributorActions",
    resource in Document::"c943927f-d803-4f40-9a53-7740272cb969"
  );

  permit (
    principal in UserGroup::"df82e4ad-949e-44cb-8acf-2d1acda71798",
    action in Action::"DocumentReviewerActions",
    resource == Document::"661817a9-d478-4096-943d-4ef1e082d19a"
  );

  permit (
    principal in User::"df82e4ad-949e-44cb-8acf-2d1acda71798",
    action in Action::"DocumentContributorActions",
    resource in Folder::"b8ee140c-fa09-46c3-992e-099438930894"
  );

As Permissões Verificadas da Amazon podem lidar com eficiência com muitas políticas individuais e refinadas durante a avaliação e modelagem de autorizações. Dessa forma, as Permissões Verificadas mantêm um registro completo de auditoria de todas as AWS CloudTrail decisões de autorização.

Prefira permissões refinadas no modelo e permissões agregadas na interface do usuário

Uma estratégia da qual os designers geralmente se arrependem é criar um modelo de autorização com ações muito amplas, como Read e Write, e perceber depois que são necessárias ações mais refinadas. A necessidade de maior granularidade pode ser motivada pelo feedback dos clientes sobre controles de acesso mais granulares ou por auditores de conformidade e segurança que incentivam permissões com privilégios mínimos.

Se as permissões refinadas não forem definidas antecipadamente, possivelmente será necessária uma conversão complicada para transformar o código da aplicação e as declarações de política em permissões de usuário mais refinadas. Por exemplo, o código de aplicação previamente autorizado com base em uma ação granulada precisará ser modificado para usar as ações refinadas. Além disso, as políticas precisarão ser atualizadas para refletir a migração:

permit (
    principal == User::"6688f676-1aa9-456a-acf4-228340b54e9d",
    // action  ==  Action::"read",              -- coarse-grained permission -- commented out
    action in [                       //        -- finer grained permissions
        Action::"listFolderContents", 
        Action::"viewFile"
    ],
    resource in Account::"c863f89b-461f-4fc2-b638-e5fa5f79a48b"
);

Para evitar essa migração dispendiosa, é melhor definir permissões refinadas com antecedência. No entanto, isso pode resultar em uma desvantagem se os usuários finais forem posteriormente forçados a entender um número maior de permissões refinadas, especialmente se a maioria dos clientes estiver satisfeita com controles granulados, como Read e Write. Para obter o melhor dos dois mundos, você pode agrupar permissões refinadas em coleções predefinidas, como Read e Write, usando mecanismos como modelos de políticas ou grupos de ação. Ao usar essa abordagem, os clientes veem somente as permissões granuladas. Mas, nos bastidores, você preparou sua aplicação para o futuro ao modelar as permissões granuladas como uma coleção de ações refinadas. Quando clientes ou auditores solicitam, as permissões refinadas podem ser expostas.

Considere outros motivos para consultar uma autorização

Normalmente, associamos as verificações de autorização às solicitações dos usuários. A verificação é uma forma de determinar se o usuário tem permissão para realizar essa solicitação. No entanto, você também pode usar dados de autorização para influenciar o design da interface da aplicação. Por exemplo, talvez você queira exibir uma tela inicial que mostre uma lista somente dos recursos que o usuário final pode acessar. Ao visualizar os detalhes de um recurso, talvez você queira que a interface mostre somente as operações que o usuário pode realizar nesse recurso.

Essas situações podem gerar desvantagens no modelo de autorização. Por exemplo, a forte dependência de políticas de controle de acesso (ABAC) com base em atributos pode dificultar a resposta rápida à pergunta “quem tem acesso ao quê?” Isso ocorre porque, para responder a essa pergunta, é necessário examinar cada regra com base em cada entidade principal e recurso, a fim de determinar se há uma correspondência. Como resultado, um produto que precisa ser otimizado para listar somente os recursos acessíveis pelo usuário pode optar por usar um modelo de controle de acesso (RBAC) baseado em funções. Com o usoRBAC, pode ser mais fácil iterar todas as políticas anexadas a um usuário para determinar o acesso aos recursos.