As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Implementando uma PDP usando as permissões verificadas da Amazon
O Amazon Verified Permissions é um serviço de autorização e gerenciamento de permissões escalável e refinado que você pode usar para implementar um ponto de decisão política (PDP). Como mecanismo de políticas, ele pode ajudar seu aplicativo a verificar as ações do usuário em tempo real e destacar permissões excessivamente privilegiadas ou inválidas. Ele ajuda seus desenvolvedores a criar aplicativos mais seguros com mais rapidez ao externalizar a autorização e centralizar o gerenciamento e a administração de políticas. Ao separar a lógica de autorização da lógica do aplicativo, as Permissões Verificadas oferecem suporte ao desacoplamento de políticas.
[Ao usar Permissões Verificadas para implementar uma PDP e implementar privilégios mínimos e verificação contínua nos aplicativos, os desenvolvedores podem alinhar o acesso aos aplicativos com os princípios do Zero Trust.](https://aws.amazon.com/security/zero-trust/) Além disso, as equipes de segurança e auditoria podem analisar e auditar melhor quem tem acesso a quais recursos em um aplicativo. O Verified Permissions usa o [Cedar](https://www.cedarpolicy.com/en), que é uma linguagem de política de código aberto criada especificamente e que prioriza a segurança, para definir controles de acesso baseados em políticas com base no controle de acesso baseado em funções (RBAC) e no controle de acesso baseado em atributos (ABAC) para um controle de acesso mais granular e sensível ao contexto.
As Permissões verificadas fornecem alguns recursos úteis para aplicativos SaaS, como a capacidade de habilitar a autorização de vários locatários usando vários provedores de identidade, como Amazon Cognito, Google e Facebook. Outro recurso de permissões verificadas que é particularmente útil para aplicativos SaaS é o suporte para funções personalizadas por inquilino. Se você estiver projetando um sistema de gerenciamento de relacionamento com o cliente (CRM), um inquilino pode definir a granularidade do acesso por oportunidades de vendas com base em um conjunto específico de critérios. Outro inquilino pode ter outra definição. Os sistemas de permissões subjacentes nas Permissões Verificadas podem suportar essas variações, o que o torna um excelente candidato para casos de uso de SaaS. As permissões verificadas também oferecem suporte à capacidade de criar políticas que se aplicam a todos os locatários, portanto, é fácil aplicar políticas de proteção para evitar o acesso não autorizado como provedor de SaaS.
![\[Usando as permissões verificadas da Amazon para implementar uma PDP\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp.png)
**Por que usar permissões verificadas?**
Use Permissões verificadas com um provedor de identidade, como o [Amazon Cognito, para](https://aws.amazon.com/cognito/) obter uma solução de gerenciamento de acesso mais dinâmica e baseada em políticas para seus aplicativos. Você pode criar aplicativos que ajudem os usuários a compartilhar informações e colaborar, mantendo a segurança, a confidencialidade e a privacidade de seus dados. As permissões verificadas ajudam a reduzir os custos operacionais, fornecendo um sistema de autorização refinado para impor o acesso com base nas funções e atributos de suas identidades e recursos. Você pode definir seu modelo de política, criar e armazenar políticas em um local central e avaliar solicitações de acesso em milissegundos.
Em Permissões verificadas, você pode expressar permissões usando uma linguagem declarativa simples e legível por humanos chamada Cedar. As políticas escritas no Cedar podem ser compartilhadas entre as equipes, independentemente da linguagem de programação usada pelo aplicativo de cada equipe.
**O que considerar ao usar permissões verificadas**
Nas Permissões verificadas, você pode criar políticas e automatizá-las como parte do provisionamento. Você também pode criar políticas em tempo de execução como parte da lógica do aplicativo. Como prática recomendada, você deve usar um pipeline de integração contínua e implantação contínua (CI/CD) para administrar, modificar e rastrear versões de políticas ao criar políticas como parte da integração e provisionamento de inquilinos. Como alternativa, um aplicativo pode administrar, modificar e rastrear versões de políticas; no entanto, a lógica do aplicativo não executa inerentemente essa funcionalidade. Para oferecer suporte a esses recursos em seu aplicativo, você deve projetar explicitamente seu aplicativo para implementar essa funcionalidade.
Se for necessário fornecer dados externos de outras fontes para chegar a uma decisão de autorização, esses dados devem ser recuperados e fornecidos às Permissões Verificadas como parte da solicitação de autorização. Contexto, entidades e atributos adicionais não são recuperados por padrão com esse serviço.
# Visão geral do cedro
O Cedar é uma linguagem de controle de acesso baseada em políticas flexível, extensível e escalável que ajuda os desenvolvedores a expressar permissões de aplicativos como políticas. Administradores e desenvolvedores podem definir políticas que permitam ou proíbam que os usuários atuem nos recursos do aplicativo. Várias políticas podem ser anexadas a um único recurso. Quando um usuário do seu aplicativo tenta realizar uma ação em um recurso, seu aplicativo solicita autorização do mecanismo de políticas do Cedar. A Cedar avalia as políticas aplicáveis e retorna uma decisão `ALLOW` ou`DENY`. O Cedar suporta regras de autorização para qualquer tipo de principal e recurso, permite controle de acesso baseado em função (RBAC) e controle de acesso baseado em atributos (ABAC) e oferece suporte à análise por meio de ferramentas de raciocínio automatizadas.
O Cedar permite que você separe sua lógica de negócios da lógica de autorização. Ao fazer solicitações a partir do código do seu aplicativo, você chama o mecanismo de autorização do Cedar para determinar se a solicitação está autorizada. Se for autorizado (a decisão é`ALLOW`), seu aplicativo pode realizar a operação solicitada. Se não for autorizado (a decisão é`DENY`), seu aplicativo pode retornar uma mensagem de erro. As principais características do Cedar incluem:
+ **Expressividade** — O Cedar foi desenvolvido especificamente para apoiar casos de uso de autorização e foi desenvolvido pensando na legibilidade humana.
+ **Desempenho** — O Cedar suporta políticas de indexação para recuperação rápida e fornece avaliação rápida e escalável em tempo real com latência limitada.
+ **Análise** — O Cedar oferece suporte a ferramentas de análise que podem otimizar suas políticas e verificar seu modelo de segurança.
Para obter mais informações, consulte o [site da Cedar](https://www.cedarpolicy.com/).
# Exemplo 1: ABAC básico com permissões verificadas e cedro
Neste cenário de exemplo, as Permissões Verificadas da Amazon são usadas para determinar quais usuários têm permissão para acessar informações em um microsserviço fictício de folha de pagamento. Esta seção inclui trechos de código do Cedar para demonstrar como você pode usar o Cedar para processar decisões de controle de acesso. Esses exemplos não pretendem fornecer uma exploração completa dos recursos fornecidos pelo Cedar e pelo Verified Permissions. Para uma visão geral mais completa do Cedar, consulte a documentação do [Cedar](https://docs.cedarpolicy.com/).
No diagrama a seguir, gostaríamos de aplicar duas regras gerais de negócios associadas ao `viewSalary` `GET` método: *os funcionários podem ver seu próprio salário e os funcionários podem ver o salário* *de qualquer pessoa que se reporte a eles*. Você pode aplicar essas regras de negócios usando políticas de permissões verificadas.
![\[Exemplo de uma implementação básica de ABAC com Amazon Verified Permissions e Cedar para implementar uma PDP\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-1.png)
*Os funcionários podem ver seu próprio salário.*
Em Cedar, a construção básica é uma *entidade*, que representa um principal, uma ação ou um recurso. Para fazer uma solicitação de autorização e iniciar uma avaliação com uma política de permissões verificadas, você precisa fornecer um *principal,* uma *ação*, um *recurso* e uma *lista de entidades.*
+ O principal (`principal`) é o usuário ou função logado.
+ A ação (`action`) é a operação que é avaliada pela solicitação.
+ O recurso (`resource`) é o componente que a ação está acessando.
+ A lista de entidades (`entityList`) contém todas as entidades necessárias para avaliar a solicitação.
Para satisfazer a regra de negócios, *os funcionários podem ver seu próprio salário*, você pode fornecer uma política de permissões verificadas, como a seguinte.
```
permit (
principal,
action == Action::"viewSalary",
resource
)
when {
principal == resource.owner
};
```
Essa política avalia `ALLOW` se o `Action` é `viewSalary` e o recurso na solicitação têm um proprietário de atributo igual ao principal. Por exemplo, se Bob for o usuário conectado que solicitou o relatório salarial e também for o proprietário do relatório salarial, a política será avaliada como. `ALLOW`
A solicitação de autorização a seguir é enviada às Permissões verificadas para ser avaliada pelo exemplo de política. Neste exemplo, Bob é o usuário logado que faz a `viewSalary` solicitação. Portanto, Bob é o principal do tipo de entidade`Employee`. A ação que Bob está tentando realizar é `viewSalary,` e o recurso que `viewSalary` será exibido é `Salary-Bob` com o tipo`Salary`. Para avaliar se Bob pode visualizar o `Salary-Bob` recurso, você precisa fornecer uma estrutura de entidade que vincule o tipo `Employee` com um valor de `Bob` (o principal) ao atributo proprietário do recurso que tem o tipo`Salary`. Você fornece essa estrutura em um`entityList`, em que os atributos associados `Salary` incluem um proprietário, que especifica um `entityIdentifier` que contém o tipo `Employee` e o valor`Bob`. As permissões verificadas comparam o `principal` fornecido na solicitação de autorização com o `owner` atributo associado ao `Salary` recurso para tomar uma decisão.
```
{
"policyStoreId": "PAYROLLAPP_POLICYSTOREID",
"principal": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
},
"action": {
"actionType": "PayrollApp::Action",
"actionId": "viewSalary"
},
"resource": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"attributes": {
"owner": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
}
}
}
},
{
"identifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
},
"attributes": {}
}
]
}
}
```
A solicitação de autorização para Permissões verificadas retorna o seguinte como saída, em que o atributo `decision` é `ALLOW` ou`DENY`.
```
{
"determiningPolicies":
[
{
"determiningPolicyId": "PAYROLLAPP_POLICYSTOREID"
}
],
"decision": "ALLOW",
"errors": []
}
```
Nesse caso, como Bob estava tentando ver seu próprio salário, a solicitação de autorização enviada para Permissões verificadas é avaliada como. `ALLOW` No entanto, nosso objetivo era usar as Permissões Verificadas para aplicar duas regras de negócios. A regra de negócios que afirma o seguinte também deve ser verdadeira:
*Os funcionários podem ver o salário de qualquer pessoa que se reporte a eles.*
Para satisfazer essa regra de negócios, você pode fornecer outra política. A política a seguir avalia `ALLOW` se a ação é `viewSalary` e se o recurso na solicitação tem um atributo `owner.manager` igual ao principal. Por exemplo, se Alice for a usuária conectada que solicitou o relatório salarial e Alice for a gerente do proprietário do relatório, a política será avaliada como. `ALLOW`
```
permit (
principal,
action == Action::"viewSalary",
resource
)
when {
principal == resource.owner.manager
};
```
A solicitação de autorização a seguir é enviada às Permissões verificadas para ser avaliada pelo exemplo de política. Neste exemplo, Alice é a usuária logada que faz a `viewSalary` solicitação. Portanto, Alice é a principal e a entidade é do tipo`Employee`. A ação que Alice está tentando realizar é`viewSalary`, e o recurso que `viewSalary` será exibido é do tipo `Salary` com um valor de`Salary-Bob`. Para avaliar se Alice pode visualizar o `Salary-Bob` recurso, você precisa fornecer uma estrutura de entidade que vincule o tipo `Employee` a um valor de `Alice` ao `manager` atributo, que deve então ser associado ao `owner` atributo do tipo `Salary` com um valor de`Salary-Bob`. Você fornece essa estrutura em um`entityList`, em que os atributos associados `Salary` incluem um proprietário, que especifica um `entityIdentifier` que contém o tipo `Employee` e o valor`Bob`. As permissões verificadas primeiro verificam o `owner` atributo, que avalia o tipo `Employee` e o valor`Bob`. Em seguida, as Permissões verificadas avaliam o `manager` atributo associado `Employee` e o comparam com o principal fornecido para tomar uma decisão de autorização. Nesse caso, a decisão é `ALLOW` porque os `resource.owner.manager` atributos `principal ` e são equivalentes.
```
{
"policyStoreId": "PAYROLLAPP_POLICYSTOREID",
"principal": {
"entityType": "PayrollApp::Employee",
"entityId": "Alice"
},
"action": {
"actionType": "PayrollApp::Action",
"actionId": "viewSalary"
},
"resource": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Alice"
},
"attributes": {
"manager": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "None"
}
}
},
"parents": []
},
{
"identifier": {
"entityType": "PayrollApp::Salary",
"entityId": "Salary-Bob"
},
"attributes": {
"owner": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
}
}
},
"parents": []
},
{
"identifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Bob"
},
"attributes": {
"manager": {
"entityIdentifier": {
"entityType": "PayrollApp::Employee",
"entityId": "Alice"
}
}
},
"parents": []
}
]
}
}
```
Até agora, neste exemplo, fornecemos as duas regras de negócios associadas ao `viewSalary` método: *os funcionários podem ver seu próprio salário e os funcionários podem ver o salário* *de qualquer pessoa que se reporte a eles*. As permissões verificadas são políticas para satisfazer as condições de cada regra de negócios de forma independente. Você também pode usar uma única política de Permissões Verificadas para satisfazer as condições de ambas as regras de negócios:
*Os funcionários podem ver seu próprio salário e o salário de qualquer pessoa que se reporte a eles.*
Quando você usa a solicitação de autorização anterior, a política a seguir avalia `ALLOW` se a ação é `viewSalary` e se o recurso na solicitação tem um atributo `owner.manager` igual ao `principal` ou um atributo `owner` igual ao`principal`.
```
permit (
principal,
action == PayrollApp::Action::"viewSalary",
resource
)
when {
principal == resource.owner.manager ||
principal == resource.owner
};
```
Por exemplo, se Alice for a usuária conectada que solicita o relatório salarial e se Alice for a gerente do proprietário ou a proprietária do relatório, a política será avaliada como. `ALLOW`
Para obter mais informações sobre o uso de operadores lógicos com políticas do Cedar, consulte a documentação do [Cedar](https://docs.cedarpolicy.com/policies/syntax-operators.html).
# Exemplo 2: RBAC básico com permissões verificadas e Cedar
Este exemplo usa Permissões Verificadas e Cedar para demonstrar o RBAC básico. Conforme mencionado anteriormente, a construção básica do Cedar é uma entidade. Os desenvolvedores definem suas próprias entidades e, opcionalmente, podem criar relacionamentos entre entidades. O exemplo a seguir inclui três tipos de entidades: `Users``Roles`, `Problems` e. `Students`e `Teachers` podem ser consideradas entidades do tipo `Role,` e cada uma `User` pode ser associada a zero ou a qualquer uma das`Roles`.
![\[Exemplo de uma implementação básica de RBAC com Amazon Verified Permissions e Cedar para implementar um PDP\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-2.png)
Em Cedar, essas relações são expressas vinculando o `Role` `Student` ao `User` `Bob` como seu pai. Essa associação agrupa logicamente todos os usuários estudantes em um grupo. Para obter mais informações sobre agrupamento no Cedar, consulte a documentação do [Cedar](https://docs.cedarpolicy.com/overview/terminology.html#term-group).
A política a seguir avalia a decisão `ALLOW` da ação `submitProblem,` para todos os diretores vinculados ao grupo lógico `Students` do tipo. `Role`
```
permit (
principal in ElearningApp::Role::"Students",
action == ElearningApp::Action::"submitProblem",
resource
);
```
A política a seguir avalia a decisão `ALLOW` da ação `submitProblem` ou`answerProblem`, de todos os diretores vinculados ao grupo lógico `Teachers` do tipo. `Role`
```
permit (
principal in ElearningApp::Role::"Teachers",
action in [
ElearningApp::Action::"submitProblem",
ElearningApp::Action::"answerProblem"
],
resource
);
```
Para avaliar solicitações com essas políticas, o mecanismo de avaliação precisa saber se o principal referenciado na solicitação de autorização é membro do grupo apropriado. Portanto, o aplicativo deve passar informações relevantes de associação ao grupo para o mecanismo de avaliação como parte da solicitação de autorização. Isso é feito por meio da `entities` propriedade, que permite que você forneça ao mecanismo de avaliação do Cedar dados de atributo e associação ao grupo para o principal e o recurso envolvido na chamada de autorização. No código a seguir, a associação ao grupo é indicada pela definição `User::"Bob"` de ter um pai chamado`Role::"Students"`.
```
{
"policyStoreId": "ELEARNING_POLICYSTOREID",
"principal": {
"entityType": "ElearningApp::User",
"entityId": "Bob"
},
"action": {
"actionType": "ElearningApp::Action",
"actionId": "answerProblem"
},
"resource": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "ElearningApp::User",
"entityId": "Bob"
},
"attributes": {},
"parents": [
{
"entityType": "ElearningApp::Role",
"entityId": "Students"
}
]
},
{
"identifier": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"attributes": {},
"parents": []
}
]
}
}
```
Neste exemplo, Bob é o usuário logado que faz a `answerProblem` solicitação. Portanto, Bob é o principal e a entidade é do tipo`User`. A ação que Bob está tentando realizar é`answerProblem`. Para avaliar se Bob pode realizar a `answerProblem` ação, você precisa fornecer uma estrutura de entidade que vincule a entidade `User` a um valor de `Bob` e atribua sua associação ao grupo listando uma entidade mãe como`Role::"Students"`. Como as entidades do grupo `Role::"Students"` de usuários só podem realizar a ação`submitProblem`, essa solicitação de autorização é avaliada como. `DENY`
Por outro lado, se o tipo `User` que tem um valor de `Alice` e faz parte do grupo `Role::"Teachers"` tentar realizar a `answerProblem` ação, a solicitação de autorização será avaliada`ALLOW`, pois a política determina que os diretores do grupo `Role::"Teachers"` tenham permissão para realizar a ação `answerProblem` em todos os recursos. O código a seguir mostra esse tipo de solicitação de autorização que avalia a. `ALLOW`
```
{
"policyStoreId": "ELEARNING_POLICYSTOREID",
"principal": {
"entityType": "ElearningApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "ElearningApp::Action",
"actionId": "answerProblem"
},
"resource": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "ElearningApp::User",
"entityId": "Alice"
},
"attributes": {},
"parents": [
{
"entityType": "ElearningApp::Role",
"entityId": "Teachers"
}
]
},
{
"identifier": {
"entityType": "ElearningApp::Problem",
"entityId": "SomeProblem"
},
"attributes": {},
"parents": []
}
]
}
}
```
# Exemplo 3: Controle de acesso multilocatário com RBAC
Para detalhar o exemplo anterior do RBAC, você pode expandir seus requisitos para incluir a multilocação de SaaS, que é um requisito comum para provedores de SaaS. Em soluções multilocatárias, o acesso aos recursos é sempre fornecido em nome de um determinado inquilino. Ou seja, os usuários do Locatário A não podem visualizar os dados do Locatário B, mesmo que esses dados estejam logicamente ou fisicamente colocados em um sistema. O exemplo a seguir ilustra como você pode implementar o isolamento de inquilinos usando vários [repositórios de políticas de permissões verificadas](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/policy-stores.html) e como você pode empregar funções de usuário para definir permissões dentro do inquilino.
Usar o padrão de design do Per Tenant Policy Store é uma prática recomendada para manter o isolamento do inquilino e, ao mesmo tempo, implementar o controle de acesso com permissões verificadas. Nesse cenário, as solicitações do usuário do Locatário A e do Locatário B são verificadas em relação a repositórios de políticas separados `DATAMICROSERVICE_POLICYSTORE_A` e`DATAMICROSERVICE_POLICYSTORE_B`, respectivamente. Para obter mais informações sobre as considerações de design de permissões verificadas para aplicativos SaaS multilocatários, consulte a seção Considerações sobre design de [permissões verificadas para vários locatários](avp-design-considerations.md).
![\[Exemplo de controle de acesso multilocatário com RBAC, Amazon Verified Permissions e Cedar\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-3.png)
A política a seguir reside no repositório de `DATAMICROSERVICE_POLICYSTORE_A` políticas. Ele verifica se o diretor fará parte do grupo `allAccessRole` do tipo`Role`. Nesse caso, o diretor poderá realizar as `updateData` ações `viewData` e em todos os recursos associados ao Locatário A.
```
permit (
principal in MultitenantApp::Role::"allAccessRole",
action in [
MultitenantApp::Action::"viewData",
MultitenantApp::Action::"updateData"
],
resource
);
```
As políticas a seguir residem no repositório `DATAMICROSERVICE_POLICYSTORE_B` de políticas. A primeira política verifica se o principal faz parte do `updateDataRole` grupo do tipo`Role`. Supondo que seja esse o caso, ele dá permissão aos diretores para realizar a `updateData` ação nos recursos associados ao Locatário B.
```
permit (
principal in MultitenantApp::Role::"updateDataRole",
action == MultitenantApp::Action::"updateData",
resource
);
```
Essa segunda política determina que os diretores que fazem parte do `viewDataRole` grupo do tipo `Role` devem ter permissão para realizar a `viewData` ação em recursos associados ao Locatário B.
```
permit (
principal in MultitenantApp::Role::"viewDataRole",
action == MultitenantApp::Action::"viewData",
resource
);
```
A solicitação de autorização feita pelo Locatário A precisa ser enviada ao repositório `DATAMICROSERVICE_POLICYSTORE_A` de políticas e verificada pelas políticas que pertencem a essa loja. Nesse caso, isso é verificado pela primeira política discutida anteriormente como parte deste exemplo. Nessa solicitação de autorização, o principal do tipo `User` com um valor de `Alice` está solicitando a execução da `viewData` ação. O principal pertence ao grupo `allAccessRole` do tipo`Role`. Alice está tentando realizar a `viewData` ação no `SampleData` recurso. Como Alice tem o `allAccessRole` papel, essa avaliação resulta em uma `ALLOW` decisão.
```
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "viewData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "allAccessRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": []
}
]
}
}
```
Se, em vez disso, você visualizar uma solicitação feita pelo Locatário B por`User Bob`, verá algo parecido com a seguinte solicitação de autorização. A solicitação é enviada para o repositório de `DATAMICROSERVICE_POLICYSTORE_B` políticas porque é originária do Locatário B. Nessa solicitação, o principal `Bob` deseja realizar a ação `updateData` no recurso. `SampleData` No entanto, não `Bob` faz parte de um grupo que tenha acesso à ação `updateData` nesse recurso. Portanto, a solicitação resulta em uma `DENY` decisão.
```
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE_B",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Bob"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "updateData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Bob"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "viewDataRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": []
}
]
}
}
```
Neste terceiro exemplo, `User Alice ` tenta realizar a `viewData` ação no recurso`SampleData`. Essa solicitação é direcionada ao repositório de `DATAMICROSERVICE_POLICYSTORE_A` políticas porque a diretora `Alice` pertence ao Locatário A. `Alice` faz parte do grupo `allAccessRole` do tipo`Role`, o que permite que ela execute a `viewData` ação nos recursos. Dessa forma, a solicitação resulta em uma `ALLOW` decisão.
```
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE_A",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "viewData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "allAccessRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": []
}
]
}
}
```
# Exemplo 4: Controle de acesso multilocatário com RBAC e ABAC
Para aprimorar o exemplo de RBAC na seção anterior, você pode adicionar atributos aos usuários para criar uma abordagem híbrida RBAC-ABAC para controle de acesso multilocatário. Esse exemplo inclui as mesmas funções do exemplo anterior, mas adiciona o atributo de usuário `account_lockout_flag` e o parâmetro de contexto`uses_mfa`. O exemplo também adota uma abordagem diferente para implementar o controle de acesso multilocatário usando o RBAC e o ABAC, e usa um repositório de políticas compartilhado em vez de um armazenamento de políticas diferente para cada inquilino.
![\[Exemplo de controle de acesso multilocatário com RBAC, ABAC, Amazon Verified Permissions e Cedar\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-4.png)
Este exemplo representa uma solução SaaS multilocatária na qual você precisa fornecer decisões de autorização para o Locatário A e o Locatário B, semelhante ao exemplo anterior.
Para implementar o recurso de bloqueio de usuário, o exemplo adiciona o `account_lockout_flag` atributo à `User` entidade principal na solicitação de autorização. Esse sinalizador bloqueia o acesso do usuário ao sistema e concede `DENY` todos os privilégios ao usuário bloqueado. O `account_lockout_flag` atributo está associado à `User` entidade e está em vigor `User` até que o sinalizador seja revogado ativamente em várias sessões. O exemplo usa a `when` condição para avaliar`account_lockout_flag`.
O exemplo também adiciona detalhes sobre a solicitação e a sessão. As informações de contexto especificam que a sessão foi autenticada usando a autenticação multifator. Para implementar essa validação, o exemplo usa a `when` condição para avaliar o `uses_mfa` sinalizador como parte do campo de contexto. Para obter mais informações sobre as melhores práticas para adicionar contexto, consulte a [documentação do Cedar](https://docs.cedarpolicy.com/auth/entities-syntax.html).
```
permit (
principal in MultitenantApp::Role::"allAccessRole",
action in [
MultitenantApp::Action::"viewData",
MultitenantApp::Action::"updateData"
],
resource
)
when {
principal.account_lockout_flag == false &&
context.uses_mfa == true &&
resource in principal.Tenant
};
```
Essa política impede o acesso aos recursos, a menos que o recurso esteja no mesmo grupo que o `Tenant` atributo do principal solicitante. Essa abordagem para manter o isolamento de inquilinos é conhecida como abordagem de *um repositório de políticas compartilhado para vários locatários*. Para obter mais informações sobre as considerações de design de permissões verificadas para aplicativos SaaS multilocatários, consulte a seção Considerações sobre design de [permissões verificadas para vários locatários](avp-design-considerations.md).
A política também garante que o diretor seja membro `allAccessRole` e restringe as ações de `viewData` e. `updateData` Além disso, essa política verifica se `account_lockout_flag` é `false` e se o valor do contexto de é `uses_mfa` avaliado como. `true`
Da mesma forma, a política a seguir garante que o principal e o recurso estejam associados ao mesmo inquilino, o que impede o acesso entre inquilinos. Essa política também garante que o diretor seja membro `viewDataRole` e restringe as ações a. `viewData` Além disso, verifica se o `account_lockout_flag` é `false` e se o valor do contexto para é `uses_mfa` avaliado como. `true`
```
permit (
principal in MultitenantApp::Role::"viewDataRole",
action == MultitenantApp::Action::"viewData",
resource
)
when {
principal.account_lockout_flag == false &&
context.uses_mfa == true &&
resource in principal.Tenant
};
```
A terceira política é semelhante à anterior. A política exige que o recurso seja membro do grupo que corresponde à entidade representada por`principal.Tenant`. Isso garante que tanto o principal quanto o recurso estejam associados ao Locatário B, o que impede o acesso entre inquilinos. Essa política garante que o diretor seja membro `updateDataRole` e restringe as ações a. `updateData` Além disso, essa política verifica se o `account_lockout_flag` é `false` e se o valor do contexto para é `uses_mfa` avaliado como. `true`
```
permit (
principal in MultitenantApp::Role::"updateDataRole",
action == MultitenantApp::Action::"updateData",
resource
)
when {
principal.account_lockout_flag == false &&
context.uses_mfa == true &&
resource in principal.Tenant
};
```
A solicitação de autorização a seguir é avaliada pelas três políticas discutidas anteriormente nesta seção. Nessa solicitação de autorização, o principal do tipo `User` e com um valor de `Alice` faz uma `updateData` solicitação com a função`allAccessRole`. `Alice`tem o atributo `Tenant` cujo valor é`Tenant::"TenantA"`. A ação `Alice` que está tentando executar é `updateData,` e o recurso ao qual ela será aplicada é `SampleData` do tipo`Data`. `SampleData`tem `TenantA` como entidade controladora.
De acordo com a primeira `` política no repositório de políticas, `Alice` pode executar a `updateData` ação no recurso, supondo que as condições na `when` cláusula da política sejam atendidas. A primeira condição exige que o `principal.Tenant` atributo seja avaliado`TenantA`. A segunda condição exige que o `account_lockout_flag` atributo do principal seja`false`. A condição final exige que `uses_mfa` o contexto seja`true`. Como todas as três condições foram atendidas, a solicitação retorna uma `ALLOW` decisão.
```
{
"policyStoreId": "DATAMICROSERVICE_POLICYSTORE",
"principal": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"action": {
"actionType": "MultitenantApp::Action",
"actionId": "updateData"
},
"resource": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"context": {
"contextMap": {
"uses_mfa": {
"boolean": true
}
}
},
"entities": {
"entityList": [
{
"identifier": {
"entityType": "MultitenantApp::User",
"entityId": "Alice"
},
"attributes": {
{
"account_lockout_flag": {
"boolean": false
},
"Tenant": {
"entityIdentifier": {
"entityType":"MultitenantApp::Tenant",
"entityId":"TenantA"
}
}
}
},
"parents": [
{
"entityType": "MultitenantApp::Role",
"entityId": "allAccessRole"
}
]
},
{
"identifier": {
"entityType": "MultitenantApp::Data",
"entityId": "SampleData"
},
"attributes": {},
"parents": [
{
"entityType": "MultitenantApp::Tenant",
"entityId": "TenantA"
}
]
}
]
}
}
```
# Exemplo 5: filtragem de interface do usuário com permissões verificadas e Cedar
Você também pode usar as Permissões verificadas para implementar a filtragem RBAC dos elementos da interface do usuário com base em ações autorizadas. Isso é extremamente valioso para aplicativos que têm elementos de interface de usuário sensíveis ao contexto que podem estar associados a usuários ou inquilinos específicos no caso de um aplicativo SaaS multilocatário.
No exemplo a seguir, `Users` dos não `Role` `viewer` estão autorizados a realizar atualizações. Para esses usuários, a interface do usuário não deve renderizar nenhum botão de atualização.
![\[Exemplo de filtragem de interface de usuário com Amazon Verified Permissions e Cedar\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-example-5.png)
Neste exemplo, um aplicativo web de página única tem quatro botões. Os botões visíveis dependem `Role` do usuário que está atualmente conectado ao aplicativo. À medida que o aplicativo web de página única renderiza a interface do usuário, ele consulta as permissões verificadas para determinar quais ações o usuário está autorizado a realizar e, em seguida, gera os botões com base na decisão de autorização.
A política a seguir especifica que o tipo `Role` com um valor de `viewer` pode visualizar usuários e dados. Uma decisão de `ALLOW` autorização para essa política exige uma `viewUsers` ação `viewData` or e também exige que um recurso seja associado ao tipo `Data` ou`Users`. Uma `ALLOW` decisão permite que a interface do usuário renderize dois botões: `viewDataButton` e. `viewUsersButton`
```
permit (
principal in GuiAPP::Role::"viewer",
action in [GuiAPP::Action::"viewData", GuiAPP::Action::"viewUsers"],
resource
)
when {
resource in [GuiAPP::Type::"Data", GuiAPP::Type::"Users"]
};
```
A política a seguir especifica que o tipo `Role` com um valor de só `viewerDataOnly` pode visualizar dados. Uma decisão de `ALLOW` autorização para essa política exige uma `viewData` ação e também exige que um recurso seja associado ao tipo`Data`. Uma `ALLOW` decisão permite que a interface do usuário renderize o botão`viewDataButton`.
```
permit (
principal in GuiApp::Role::"viewerDataOnly",
action in [GuiApp::Action::"viewData"],
resource in [GuiApp::Type::"Data"]
);
```
A política a seguir especifica que o tipo `Role` com um valor de `admin` pode editar e visualizar dados e usuários. Uma decisão de `ALLOW` autorização para essa política exige uma ação de `updateData``updateUsers`, `viewData,` ou`viewUsers`, e também exige que um recurso seja associado ao tipo `Data` ou`Users`. Uma `ALLOW` decisão permite que a interface do usuário renderize todos os quatro botões: `updateDataButton``updateUsersButton`,`viewDataButton`, e. `viewUsersButton`
```
permit (
principal in GuiApp::Role::"admin",
action in [
GuiApp::Action::"updateData",
GuiApp::Action::"updateUsers",
GuiApp::Action::"viewData",
GuiApp::Action::"viewUsers"
],
resource
)
when {
resource in [GuiApp::Type::"Data", GuiApp::Type::"Users"]
};
```