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á.
# Considerações sobre o design multilocatário do Amazon Verified Permissions
Há várias opções de design a serem consideradas quando você implementa a autorização usando Amazon Verified Permissions em uma solução SaaS multilocatária. Antes de explorar essas opções, vamos esclarecer a diferença entre *isolamento* e *autorização* em um contexto SaaS multilocatário. O [isolamento de](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html) um inquilino evita que os dados de entrada e saída sejam expostos ao inquilino errado. A autorização garante que o usuário tenha as permissões para acessar um inquilino.
Em Permissões verificadas, as políticas são armazenadas em um repositório de políticas. Conforme descrito na [documentação de Permissões verificadas](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/design-multi-tenancy-considerations.html), você pode isolar as políticas dos inquilinos usando um repositório de políticas separado para cada inquilino ou permitir que os inquilinos compartilhem políticas usando um único repositório de políticas para todos os inquilinos. Esta seção discute as vantagens e desvantagens dessas duas estratégias de isolamento e descreve como elas podem ser implantadas usando um modelo de implantação em camadas. Para obter mais contexto, consulte a documentação de permissões verificadas.
Embora os critérios discutidos nesta seção se concentrem nas permissões verificadas, os conceitos gerais estão enraizados na [mentalidade de isolamento](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/isolation-mindset.html) e na orientação que ela fornece. Os aplicativos SaaS devem sempre considerar o [isolamento do inquilino](https://docs.aws.amazon.com/whitepapers/latest/saas-architecture-fundamentals/tenant-isolation.html) como parte de seu design, e esse princípio geral de isolamento se estende à inclusão de permissões verificadas em um aplicativo SaaS. [Esta seção também faz referência aos principais modelos de isolamento de SaaS, como o modelo SaaS em [silos e o modelo SaaS](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html) em pool.](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html) Para obter informações adicionais, consulte os [principais conceitos de isolamento](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/core-isolation-concepts.html) no AWS Well-Architected Framework, SaaS Lens.
As principais considerações ao projetar soluções SaaS multilocatário são o isolamento e a integração de inquilinos. O isolamento do inquilino afeta a segurança, a privacidade, a resiliência e o desempenho. A integração de inquilinos afeta seus processos operacionais no que se refere à sobrecarga operacional e à observabilidade. Organizações que passam por uma jornada de SaaS ou implementam soluções multilocatárias devem sempre priorizar como a locação será tratada pelo aplicativo SaaS. Embora uma solução SaaS possa se inclinar para um modelo de isolamento específico, a consistência não é necessariamente necessária em toda a solução SaaS. Por exemplo, o modelo de isolamento escolhido para os componentes de front-end do seu aplicativo pode não ser o mesmo que o modelo de isolamento escolhido para um microsserviço ou serviços de autorização.
**Topics**
+ [Integração de inquilinos e registro de inquilinos de usuários](avp-design-onboarding-registration.md)
+ [Armazenamento de políticas por inquilino](avp-design-per-tenant-store.md)
+ [Um repositório de políticas compartilhado para vários locatários](avp-design-shared-store.md)
+ [Modelo de implantação hierárquica](avp-design-tiered.md)
# Integração de inquilinos e registro de inquilinos de usuários
Os aplicativos SaaS observam o conceito de [identidades SaaS](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/saas-identity.html) e seguem a melhor prática geral de [vincular uma identidade de usuário a uma identidade de inquilino](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/general-design-principles.html). A vinculação envolve armazenar um identificador de inquilino como uma declaração ou atributo para o usuário no provedor de identidade. Isso transfere a responsabilidade de mapear as identidades dos inquilinos de cada aplicativo para o processo de registro do usuário. Cada usuário autenticado então tem a identidade correta do locatário como parte do JSON Web Token (JWT).
Da mesma forma, a seleção do repositório de políticas correto para uma solicitação de autorização não deve ser determinada pela lógica do aplicativo. Para determinar qual repositório de políticas uma solicitação de autorização específica deve usar, mantenha um mapeamento dos usuários para os repositórios de políticas ou dos inquilinos para os repositórios de políticas. Esses mapeamentos geralmente são mantidos em um armazenamento de dados, como o Amazon DynamoDB ou o Amazon Relational Database Service (Amazon RDS) ao qual seu aplicativo faz referência. Você também pode fornecer ou complementar esses mapeamentos por dados em um provedor de identidade (IdP). O relacionamento entre inquilinos, usuários e repositórios de políticas geralmente é fornecido a um usuário por meio de um JWT que contém todos os relacionamentos necessários para uma solicitação de autorização.
Este exemplo mostra como o JWT pode aparecer para o usuário`Alice`, que pertence ao locatário `TenantA` e usa o repositório de políticas com o ID do repositório de políticas `ps-43214321` para autorização.
```
{
"sub":"1234567890",
"name":"Alice",
"tenant":"TenantA",
"policyStoreId":"ps-43214321"
}
```
# Armazenamento de políticas por inquilino
O modelo de design do repositório de políticas por inquilino no Amazon Verified Permissions associa cada inquilino em um aplicativo SaaS ao seu próprio armazenamento de políticas. Esse modelo é semelhante ao modelo de isolamento de [silos SaaS.](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/silo-isolation.html) Ambos os modelos exigem a criação de infraestrutura específica para inquilinos e têm vantagens e desvantagens semelhantes. Os principais benefícios dessa abordagem são o isolamento de inquilinos imposto pela infraestrutura, o suporte a modelos de autorização exclusivos por locatário, a eliminação de preocupações [ruidosas com vizinhos](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/noisy-neighbor.html) e um escopo reduzido de impacto de falhas nas atualizações ou implantações de políticas. As desvantagens dessa abordagem incluem processos, implantações e operações mais complexos de integração de inquilinos. O armazenamento de políticas por inquilino é a abordagem recomendada se a solução tiver políticas exclusivas por inquilino.
O modelo de armazenamento de políticas por inquilino pode fornecer uma abordagem altamente isolada para o isolamento de inquilinos, se seu aplicativo SaaS exigir. Você também pode usar esse modelo com [isolamento de pool](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/pool-isolation.html), mas sua implementação de Permissões Verificadas não compartilhará os benefícios padrão do modelo mais amplo de isolamento de pool, como gerenciamento e operações simplificados.
Em um repositório de políticas por inquilino, o isolamento do inquilino é obtido mapeando o identificador do repositório de políticas do inquilino para a identidade SaaS do usuário durante o processo de registro do usuário, conforme discutido anteriormente. Essa abordagem vincula fortemente o armazenamento de políticas do locatário ao usuário principal e fornece uma maneira consistente de compartilhar o mapeamento em toda a solução SaaS. Você pode fornecer o mapeamento para um aplicativo SaaS mantendo-o como parte de um IdP ou em uma fonte de dados externa, como o DynamoDB. Isso também garante que o diretor faça parte do inquilino e que o repositório de políticas do inquilino seja usado.
Este exemplo mostra como o JWT que contém a `policyStoreId` e `tenant` de um usuário é passado do endpoint da API para o ponto de avaliação da política em um AWS Lambda autorizador, que encaminha a solicitação para o repositório de políticas correto.
![\[Modelo de armazenamento de políticas por inquilino nas permissões verificadas da Amazon\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-per-tenant.png)
O exemplo de política a seguir ilustra o paradigma de design do repositório de políticas por inquilino. O usuário `Alice` pertence ao `TenantA.` The também policyStoreId `store-a` é mapeado para a identidade do inquilino `Alice,` e impõe o uso do repositório de políticas correto. Isso garante que as políticas de `TenantA` sejam usadas.
**nota**
O modelo de armazenamento de políticas por inquilino isola as políticas dos inquilinos. A autorização impõe as ações que os usuários podem realizar em seus dados. Os recursos envolvidos em qualquer aplicativo hipotético que usa esse modelo devem ser isolados usando outros mecanismos de isolamento, conforme definido na documentação do [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/saas-lens/core-isolation-concepts.html), SaaS Lens.
Nesta política, `Alice` tem permissões para visualizar os dados de todos os recursos.
```
permit (
principal == MultiTenantApp::User::"Alice",
action == MultiTenantApp::Action::"viewData",
resource
);
```
Para fazer uma solicitação de autorização e iniciar uma avaliação com uma política de permissões verificadas, você precisa fornecer o ID do repositório de políticas que corresponde ao ID exclusivo mapeado para o inquilino,. `store-a`
```
{
"policyStoreId":"store-a",
"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":{},
"parents":[]
},
{
"identifier":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"attributes":{},
"parents":[]
}
]
]
}
}
```
O usuário `Bob` pertence ao Locatário B e também policyStoreId `store-b` é mapeado para a identidade do locatário`Bob`, o que impõe o uso do repositório de políticas correto. Isso garante que as políticas do Locatário B sejam usadas.
Nesta política, `Bob` tem permissões para personalizar os dados de todos os recursos. Neste exemplo, `customizeData` pode ser uma ação específica somente para o Locatário B, portanto, a política seria exclusiva para o Locatário B. O modelo de armazenamento de políticas por inquilino suporta inerentemente políticas personalizadas por inquilino.
```
permit (
principal == MultiTenantApp::User::"Bob",
action == MultiTenantApp::Action::"customizeData",
resource
);
```
Para fazer uma solicitação de autorização e iniciar uma avaliação com uma política de permissões verificadas, você precisa fornecer o ID do repositório de políticas que corresponde ao ID exclusivo mapeado para o inquilino,. `store-b`
```
{
"policyStoreId":"store-b",
"principal":{
"entityType":"MultiTenantApp::User",
"entityId":"Bob"
},
"action":{
"actionType":"MultiTenantApp::Action",
"actionId":"customizeData"
},
"resource":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"entities":{
"entityList":[
[
{
"identifier":{
"entityType":"MultiTenantApp::User",
"entityId":"Bob"
},
"attributes":{},
"parents":[]
},
{
"identifier":{
"entityType":"MultiTenantApp::Data",
"entityId":"my_example_data"
},
"attributes":{},
"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 por inquilino\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/cognito-per-tenant.png)
Em um nível operacional, o armazenamento de políticas por inquilino tem uma vantagem de auditoria, porque você pode consultar facilmente a [atividade registrada de forma](https://docs.aws.amazon.com/verifiedpermissions/latest/userguide/monitoring-overview.html)AWS CloudTrail independente para cada inquilino. No entanto, ainda recomendamos que você registre métricas personalizadas adicionais em uma dimensão por inquilino na Amazon. CloudWatch
A abordagem de armazenamento de políticas por inquilino também exige muita atenção a duas [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. Essas cotas são *repositórios de políticas por região por conta* e *IsAuthorized solicitações por segundo por região por conta*. Você pode solicitar aumentos para ambas as cotas.
Para um exemplo mais detalhado de como implementar o modelo de armazenamento de políticas por inquilino, consulte a AWS postagem no blog [Controle de acesso SaaS usando Amazon Verified Permissions com um](https://aws.amazon.com/blogs/security/saas-access-control-using-amazon-verified-permissions-with-a-per-tenant-policy-store/) armazenamento de políticas por inquilino.
# Um repositório de políticas compartilhado para vários locatários
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.
# Modelo de implantação hierárquica
Ao criar um modelo de implantação em camadas, você pode isolar locatários de “nível corporativo” de alta prioridade do volume potencialmente maior de clientes de “nível padrão”. Nesse modelo, você pode implementar todas as alterações implantadas nas políticas nos repositórios de políticas separadamente para cada nível, o que isola cada nível de clientes das alterações feitas fora do nível. No modelo de implantação em camadas, os repositórios de políticas geralmente são criados como parte do provisionamento inicial da infraestrutura para cada nível, em vez de serem implantados quando um inquilino é integrado.
Se sua solução usa principalmente um modelo de isolamento em pool, você pode precisar de isolamento ou personalização adicionais. Por exemplo, você pode criar um “nível Premium” em que cada locatário teria sua própria infraestrutura de nível de inquilino, o que cria um modelo em silos ao implantar uma instância em pool com apenas um inquilino. Isso pode assumir a forma de infraestruturas de “Locatário A de Nível Premium” e “Locatário de Nível Premium B” que são completamente separadas, incluindo repositórios de políticas. Essa abordagem resulta em um modelo de isolamento em silos para o mais alto nível de clientes.
No modelo de implantação em camadas, cada repositório de políticas deve seguir o mesmo modelo de isolamento, embora seja implantado separadamente. Como há vários repositórios de políticas sendo usados, você precisa aplicar uma maneira consistente de compartilhar o identificador do repositório de políticas associado ao locatário em toda a solução SaaS. Assim como no modelo de armazenamento de políticas por locatário, é uma boa prática mapear o identificador do inquilino para a identidade SaaS do usuário durante o registro do usuário.
O diagrama a seguir mostra três camadas: `Standard Tier``Enterprise Tier`, e. `Premium Tier 1` Cada camada é implantada separadamente em sua própria infraestrutura e usa um repositório de políticas compartilhado dentro da camada. Os níveis Standard e Enterprise contêm vários inquilinos. `TenantA`e `TenantB` estão no`Standard Tier`, e `TenantC` e `TenantD` estão no nível Enterprise.
`Premium Tier 1`contém somente`TenantP`, para que você possa atender ao inquilino premium como se a solução tivesse um modelo de isolamento totalmente isolado e fornecer recursos como políticas personalizadas. A integração de um novo cliente de nível premium resultaria na criação de uma `Premium Tier 2` infraestrutura.
**nota**
O aplicativo, a implantação e a integração de locatários no nível premium são idênticos aos níveis padrão e corporativo. A única diferença é que o fluxo de trabalho de integração de nível premium começa com o provisionamento de uma nova infraestrutura de nível.
![\[Modelo de implantação hierárquica de permissões verificadas\]](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/saas-multitenant-api-access-authorization/images/avp-tiered-deployment.png)