SaaS Factory (A série) — Os segredos de controle de Identidade e Acesso em SaaS

O isolamento do inquilino é um dos tópicos fundamentais que todo software como serviço (SaaS) deve abordar. Como fornecedores independentes de software (ISVs) fazem a mudança em direção ao SaaS e adotar um modelo de infraestrutura compartilhada para atingir custos e custos operacionais eficiência, eles também precisam enfrentar o desafio de determinar como seus multilocatários dos ambientes garantirão que os inquilinos sejam impedidos de acessar os recursos de outro inquilino. Atravessar essa fronteira de qualquer forma representaria um significativo e evento potencialmente irrecuperável para um negócio SaaS.

Autenticação e autorização não são iguais a isolamento — embora seja esperado que você controlará o acesso aos seus ambientes SaaS por meio de autenticação e autorização, ir além dos pontos de entrada de uma tela de login ou uma API não significa você alcançou o isolamento. Esta é apenas uma peça do quebra-cabeça do isolamento e não é suficiente por conta própria.

A imposição de isolamento não deve ser deixada para os desenvolvedores de serviços — enquanto os desenvolvedores nunca esperam que introduzam código que possa violar o isolamento, é irrealista esperar que eles nunca cruzem involuntariamente um limite de inquilino. Para mitigar isso, o escopo do acesso aos recursos deve ser controlado por meio de algum mecanismo compartilhado que é responsável por aplicar regras de isolamento (fora da visão dos desenvolvedores).

Se não houver uma solução de isolamento pronta para uso, talvez você mesmo precise construí-la — existem vários mecanismos de segurança, como o AWS Identity and Access Management (IAM) que pode simplificar o caminho para o isolamento do inquilino. Essas ferramentas tem a integração com um esquema de segurança mais amplo geralmente torna o isolamento um tanto perfeito. No entanto, pode haver cenários em que seu modelo de isolamento não é diretamente abordado por uma ferramenta ou tecnologia correspondente. A ausência de uma solução límpida não deve representar uma oportunidade de reduzir seus requisitos de isolamento mesmo que isso signifique construir algo próprio.

O isolamento não é uma construção em nível de recurso — no mundo da multilocação e isolamento, alguns verão o isolamento como uma forma de traçar um limite rígido entre concreto recursos de infraestrutura. Isso geralmente se traduz em modelo de isolamento onde você pode ter bancos de dados separados, instâncias de computação, contas ou nuvens privadas virtuais (VPCs) para cada inquilino. Embora essas sejam formas comuns de isolamento, elas não são a única maneira de isolar inquilinos. Mesmo em cenários onde os recursos são compartilhados — na verdade, especialmente em ambientes onde os recursos são compartilhados — existem maneiras de alcançar o isolamento. Nesse modelo de recurso compartilhado, o isolamento pode ser uma construção lógica que é imposta pelo tempo de execução políticas aplicadas. O ponto-chave aqui é que o isolamento não deve ser equiparado a ter recursos isolados.

Os domínios podem impor requisitos de isolamento específicos — embora existam muitas abordagens para alcançar o isolamento do inquilino, as realidades de um determinado domínio podem impor restrições que exigirão um sabor específico de isolamento. Algumas indústrias de alta conformidade, por exemplo, exigirão que cada inquilino tenha seu próprio banco de dados. Nestes casos, abordagens compartilhadas e baseadas em políticas para o isolamento podem não ser adequadas.

Conceitos centrais de Isolamento de Locatários

Isolamento Silo

Embora os provedores de SaaS geralmente se concentrem no valor do compartilhamento de recursos, ainda há cenários em que um provedor de SaaS pode optar por ter alguns (ou todos) de seus locatários implantado em um modelo em que cada locatário está executando uma pilha de recursos totalmente isolada. Alguns diriam que esse modelo full-stack não representa um ambiente SaaS. No entanto, se você cercou essas pilhas separadas com identidade compartilhada, integração, medição, métricas, implantação, análise e operações, então ainda diríamos que isso ainda é uma variante válida de SaaS que troca economias de escala e eficiência operacional por conformidade, negócios ou considerações de domínio. Com esta abordagem, o isolamento é uma construção de ponta a ponta que abrange toda uma pilha de clientes. O diagrama a seguir fornece uma visão conceitual dessa visão de isolamento.

*Isolamento full-stack*

Isolamento Pool

É muito fácil ver como o modelo de silo de isolamento mapeia muito bem para muitas empresas de SaaS. Ao mesmo tempo, muitas empresas que estão migrando para SaaS estão buscando eficiência, agilidade e benefícios de custo de poder fazer com que seus inquilinos compartilhem alguns ou todos de sua infraestrutura subjacente. Essa abordagem de infraestrutura compartilhada, que é chamada como um modelo de pool, adiciona um nível de complexidade à história de isolamento. O diagrama a seguir fornece uma ilustração do desafio associado à implementação do isolamento em um modelo agrupado.

*Modelo Pool*

Isolamento Bridge

Enquanto o silo e o pool têm abordagens muito distintas para isolamento, a paisagem de isolamento para muitos provedores de SaaS é menos absoluta. Ao observar problemas reais de aplicativos e você decompor nossos sistemas em serviços menores, muitas vezes você descobrirá que sua solução exigirá uma mistura dos modelos de silo e pool. Este modelo misto é o que nós referir-se-ia como um modelo bridge de isolamento. O diagrama na figura a seguir fornece uma exemplo de como o modelo bridge pode ser realizada em uma solução SaaS.

*Modelo Bridge*

Isolamento baseado em Tiers

Embora a maior parte de nossa discussão sobre isolamento se concentre na mecânica de impedir o acesso entre inquilinos, também há cenários em que o nível de sua oferta pode influenciar sua estratégia de isolamento. Nesse caso, é menos sobre como você está isolando os inquilinos e mais sobre como você pode empacotar e oferecer diferentes tipos de isolamento para inquilinos diferentes com perfis diferentes. Ainda assim, esta é outra consideração que poderia determine quais modelos de isolamento você precisará oferecer suporte para abordar todo o espectro de clientes que você deseja envolver. O diagrama a seguir fornece um exemplo de como o isolamento pode variar entre os níveis.

*Isolamento baseado em Tiers*

Identidade e Isolamento

Embora o escopo de sua discussão seja limitado ao isolamento, é importante observar como identidade se conecta ao modelo de isolamento. A realidade é que, se você está planejando isolar inquilinos, você deve ter alguma forma de representar e identificar o inquilino que está acessando os recursos do nosso ambiente SaaS. Em muitos casos, a identidade será usada em combinação com outras construções para adquirir as políticas e regras de escopo que estão em o núcleo de um esquema de isolamento. A forma como essas políticas são definidas e aplicadas irá variar para cada um dos modelos e serviços de isolamento que você está consumindo.

*Conectando isolamento e identidade*

Isolamento baseado em políticas do IAM

A maior parte de nossa atenção até agora tem sido em estratégias para usar o IAM como a base de nosso modelo de isolamento agrupado. E, embora o IAM geralmente represente uma ótima opção para isolar recursos, também pode haver cenários em que o IAM pode não suportar o tipo de isolamento que seu aplicativo requer. É aqui que você pode ter que recuar e procurar na introdução de outras estruturas ou ferramentas para controlar o acesso ao pool de recursos de seu aplicativo.

O isolamento imposto pelo aplicativo geralmente inclui algum modelo em que você expressa políticas (assim como você faz com o IAM). Essas mesmas estruturas geralmente incluem a aplicação de políticas mecanismos que ficarão entre você e seus recursos, autorizando seu acesso a os recursos. O diagrama na Figura 19 fornece uma visão conceitual de alto nível do partes móveis que podem fazer parte de um modelo de política aplicado por aplicativo.

*Isolamento baseado em políticas*

Neste diagrama, você verá que temos um microsserviço que precisa acessar alguns recursos downstream (bancos de dados, buckets S3, etc.). Este microsserviço foi implantado em um modelo agrupado, o que significa que ele processará solicitações de vários inquilinos. O trabalho desse microsserviço é garantir que, ao processar essas solicitações, ele aplique restrições que impeçam os inquilinos de cruzar um limite para outro recursos do inquilino. No diagrama, você verá que nosso microsserviço alcança o gerenciador de isolamento para adquirir um contexto de escopo que é usado para controlar as interações com e recursos que são acessados ​​pelo código em execução neste microsserviço.

*Scoping com políticas IAM*

Conclusões

Depois de revisar os conceitos de isolamento descritos aqui, você deve ter um bom senso de que o cenário de opções de isolamento que você precisará considerar ao criar um SaaS solução na AWS. Exploramos vários padrões-chave aqui, destacando diferentes modelos de implementação de isolamento que são diretamente influenciados pelo domínio, conformidade, operações e perfil de desempenho de seu aplicativo SaaS. Nós focamos grande parte dessa discussão sobre os modelos de isolamento de silo e pool, explorando as nuances de como esses modelos são realizados em diferentes modelos SaaS. Também vimos como o seu as estratégias de isolamento podem ser influenciadas pelos serviços da AWS usados ​​para criar seu ambiente SaaS.

No próximo post, falaremos como implementar a arquitetura geral de Identidade e Acesso em soluções de software como serviço na AWS.

SaaS Factory (A série) — Como construir soluções de Software como Serviço na AWS

Até lá! =)