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á.

# Um repositório de políticas compartilhado para vários locatários
<a name="avp-design-shared-store"></a>

O modelo de design de um repositório de políticas multilocatário compartilhado usa um único repositório de políticas multilocatário no Amazon Verified Permissions para todos os inquilinos na solução SaaS. O principal benefício dessa abordagem é o gerenciamento e as operações simplificados, principalmente porque você não precisa criar repositórios de políticas adicionais durante a integração do inquilino. As desvantagens dessa abordagem incluem um maior escopo de impacto de qualquer falha ou erro nas atualizações ou implantações de políticas e uma maior exposição aos efeitos [ruidosos da vizinhança.](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html) Além disso, não recomendamos essa abordagem se sua solução exigir políticas exclusivas para cada inquilino. Nesse caso, use o modelo de armazenamento de políticas por inquilino para garantir que as políticas do inquilino correto sejam usadas.

[A única abordagem compartilhada de armazenamento de políticas multilocatário é semelhante ao modelo de isolamento agrupado de SaaS.](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html) Ele pode fornecer uma abordagem agrupada para o isolamento de inquilinos, se seu aplicativo SaaS exigir. Você também pode usar esse modelo se sua solução SaaS aplicar [isolamento em silos aos microsserviços](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html). Ao escolher um modelo, você deve avaliar os requisitos de isolamento de dados do inquilino e a estrutura das políticas de Permissões Verificadas que são necessárias para um aplicativo SaaS de forma independente.

Para impor uma forma consistente de compartilhar o identificador do locatário em toda a sua solução SaaS, é uma boa prática mapear o identificador para a identidade SaaS do usuário durante o registro do usuário, conforme discutido anteriormente. Você pode fornecer esse mapeamento para um aplicativo SaaS mantendo-o como parte de um IdP ou em uma fonte de dados externa, como o DynamoDB. Também recomendamos que você mapeie a ID do repositório de políticas compartilhadas para os usuários. Embora o ID não seja usado como parte do isolamento do inquilino, essa é uma boa prática porque facilita futuras mudanças. 

O exemplo a seguir mostra como o endpoint da API envia um JWT para os usuários `Alice` e`Bob`, que pertencem a diferentes locatários, mas compartilham o repositório de políticas com o ID `store-multi-tenant` do repositório de políticas para autorização. Como todos os locatários compartilham um único repositório de políticas, você não precisa manter o ID do repositório de políticas em um token ou banco de dados. Como todos os locatários compartilham uma única ID do repositório de políticas, você pode fornecer o ID como uma variável de ambiente que seu aplicativo pode usar para fazer chamadas para o repositório de políticas.

![Modelo de design compartilhado com permissões verificadas](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-shared.png)


O exemplo de política a seguir ilustra o paradigma de design de uma política compartilhada para vários locatários. Nessa política, o diretor `MultiTenantApp::User` que tem o pai `MultiTenantApp::Role` `Admin` tem permissões para visualizar os dados de todos os recursos.

```
permit (
    principal in MultiTenantApp::Role::"Admin",
    action == MultiTenantApp::Action::"viewData",
    resource
);
```

Como um único repositório de políticas está em uso, o repositório de políticas de Permissões Verificadas deve garantir que um atributo de locação associado ao principal corresponda ao atributo de locação associado ao recurso. Isso pode ser feito incluindo a política a seguir no repositório de políticas, para garantir que todas as solicitações de autorização que não tenham atributos de locação correspondentes no recurso e no principal sejam rejeitadas.

```
forbid(
    principal, 
    action, 
    resource
)
unless {
    resource.Tenant == principal.Tenant
};
```

Para uma solicitação de autorização que usa um modelo de repositório de políticas multilocatário compartilhado, o ID do repositório de políticas é o identificador do repositório de políticas compartilhado. Na solicitação a seguir, o acesso `User` `Alice` é permitido porque ela tem um `Role` de`Admin`, e os `Tenant` atributos associados ao recurso e ao principal são ambos`TenantA`.

```
{
   "policyStoreId":"store-multi-tenant",
   "principal":{
      "entityType":"MultiTenantApp::User",
      "entityId":"Alice"
   },
   "action":{
      "actionType":"MultiTenantApp::Action",
      "actionId":"viewData"
   },
   "resource":{
      "entityType":"MultiTenantApp::Data",
      "entityId":"my_example_data"
   },
   "entities":{
      "entityList":[
         {
            "identifier":{
               "entityType":"MultiTenantApp::User",
               "entityId":"Alice"
            },
            "attributes": {
                {
                    "Tenant": {
                        "entityIdentifier": {
                            "entityType":"MultitenantApp::Tenant",
                            "entityId":"TenantA"
                        }
                    }
                }
            },
            "parents":[
               {
                  "entityType":"MultiTenantApp::Role",
                  "entityId":"Admin"
               }
            ]
         },
         {
            "identifier":{
               "entityType":"MultiTenantApp::Data",
               "entityId":"my_example_data"
            },
            "attributes": {
                {
                    "Tenant": {
                        "entityIdentifier": {
                            "entityType":"MultitenantApp::Tenant",
                            "entityId":"TenantA"
                        }
                    }
                }
            },
            "parents":[]
         }
      ]
   }
}
```

Com as Permissões Verificadas, é possível, mas não obrigatório, integrar um IdP a um repositório de políticas. Essa integração permite que as políticas referenciem explicitamente o principal no repositório de identidades como o principal das políticas. [Para obter mais informações sobre como se integrar ao Amazon Cognito como um IdP para permissões verificadas, consulte a documentação de permissões verificadas e a documentação do [Amazon](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) Cognito.](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-authorization-with-avp.html)

Ao integrar um repositório de políticas a um IdP, você pode usar somente uma [fonte de identidade](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/identity-providers.html) por repositório de políticas. Por exemplo, se você optar por integrar as Permissões Verificadas com o Amazon Cognito, precisará espelhar a estratégia usada para o isolamento de locatários dos repositórios de políticas de Permissões Verificadas e dos grupos de usuários do Amazon Cognito. Os repositórios de políticas e os grupos de usuários também precisam estar nos mesmos Conta da AWS.

![Integração de permissões verificadas com o Amazon Cognito em um modelo de design compartilhado](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/cognito-shared.png)


Do ponto de vista operacional e de auditoria, o único modelo de armazenamento de políticas multilocatário compartilhado tem a desvantagem de que a [atividade registrada AWS CloudTrail](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/monitoring-overview.html) exige consultas mais complexas para filtrar a atividade individual do inquilino, porque cada chamada registrada CloudTrail usa o mesmo repositório de políticas. Nesse cenário, é útil registrar métricas personalizadas adicionais em uma dimensão por inquilino na Amazon CloudWatch para garantir um nível adequado de capacidade de observação e auditoria.

A abordagem compartilhada de armazenamento de políticas multilocatário também exige muita atenção às [cotas de permissões verificadas](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/quotas.html) para garantir que elas não interfiram nas operações de sua solução SaaS. Em particular, recomendamos que você monitore as *IsAuthorized solicitações por segundo por região por cota de conta* para garantir que suas limitações não sejam excedidas. Você pode solicitar um aumento dessa cota.