Isolamento e silos para data warehouses em soluções multitenantes

Em um dos artigos anteriores , abordamos alguns pontos-chave da configuração de um cluster Amazon EKS multitenant (doravante multitenant ) . Quanto à segurança, este é um tópico muito extenso. É importante entender que a segurança se aplica não apenas ao cluster de aplicativos, mas também ao armazém de dados. A AWS como plataforma para soluções SaaS tem muita variabilidade para data warehouses. Mas, como em outros lugares, uma configuração de segurança competente, elaborando uma arquitetura multitenant para ela, configurando vários níveis de isolamento requer certo conhecimento e entendimento das especificidades do trabalho.

Data Warehouse Multitenant

É conveniente gerenciar dados multitenantes usando silos, o Silo . A principal característica é a separação dos dados de aluguel (doravante locatário ) em soluções SaaS com vários locatários . Mas antes de falar sobre casos específicos, vamos tocar em um pouco de teoria geral.

Somente inquilino deve ter acesso

A segurança dos dados é uma prioridade para as soluções SaaS . É necessário proteger os dados não apenas contra invasões externas, mas também da interação com outros inquilinos . Mesmo no caso de dois inquilinos cooperarem entre si, e o acesso a dados comuns é controlado e configurado de acordo com a lógica comercial.

Padrões do setor para criptografia e segurança

Os padrões de inquilino podem variar de acordo com o setor. Alguns requerem criptografia de dados com uma frequência de alteração de chave claramente definida, enquanto outros exigem chaves orientadas ao inquilino em vez de chaves compartilhadas . Ao identificar conjuntos de dados com inquilinos específicos , diferentes padrões de criptografia e configurações de segurança podem ser aplicados a inquilinos individuais como uma exceção.

Ajuste de desempenho com base na assinatura do inquilino

Geralmente, os provedores de SaaS recomendam um fluxo de trabalho comum para todos os inquilinos . Do ponto de vista prático, isso nem sempre é conveniente em relação à lógica de negócios específica. Portanto, você pode fazer diferente. Cada inquilino recebe um conjunto diferente de propriedades e limites de desempenho com base no padrão TIER . Para que os clientes obtenham o desempenho declarado no contrato SaaS , os fornecedores precisam monitorar o uso de inquilinos individuais . Graças a isso, todos os clientes recebem acesso igual aos recursos.

Gestão de dados

À medida que os serviços SaaS crescem, cresce também o número de inquilinos . Se o cliente alterar o provedor, na maioria das vezes ele deseja que todos os dados sejam enviados para outro recurso e que os antigos sejam excluídos. Se o primeiro desejo puder ser contestado, o cumprimento do segundo será garantido pelo Regulamento Geral de Proteção de Dados da UE. Para a correta execução das regras, o provedor SaaS deve identificar inicialmente os conjuntos de dados de inquilinos individuais .

Como transformar um Data Warehouse regular em multitenant

Só quero observar que o código mágico não existe. Você não pode simplesmente pegar e configurar uma lixeira do armazém de dados do inquilino . Os seguintes aspectos devem ser considerados:

• Acordo de serviço;
• Padrões de acesso para leitura e escrita;
• Conformidade com regulamentos;
• Despesas.

Mas existem várias práticas geralmente aceitas para separar e isolar dados. Vejamos esses casos usando o banco de dados relacional Amazon Aurora como exemplo .

Particionando dados de inquilino em instâncias e armazenamentos compartilhados

A tabela é usada por todos os inquilinos . Dados individuais são compartilhados e identificados pela chave tenant_id . A autorização em um banco de dados relacional é implementada na segurança no nível da linha . O acesso ao aplicativo é baseado em uma política de acesso e leva em consideração um inquilino específico .



Prós:

• Não é caro.

Minuses:

• Autorização em nível de banco de dados. Isso implica vários mecanismos de autorização na solução: AWS IAM e políticas de banco de dados;
• Para identificar o inquilino, você precisa desenvolver a lógica do aplicativo;
• Sem isolamento completo, não é possível fazer cumprir o contrato de serviço TIER ;
• A autorização do banco de dados limita o rastreamento de acesso com o AWS CloudTrail . Isso só pode ser compensado com a adição de informações externas. E seria melhor rastrear e solucionar problemas.

Isolamento de dados na instância compartilhada

A concessão ( locação ) ainda é rassharivat no nível da instância. Mas, ao mesmo tempo, o armazenamento de dados ocorre no nível do banco de dados. Isso possibilita a autenticação e autorização do AWS IAM.



Prós:

• Não é caro;
• O AWS IAM é totalmente responsável pela autenticação e autorização;
• O AWS IAM permite manter uma trilha de auditoria no AWS CloudTrail sem muletas como aplicativos separados.

Minuses:

• As instâncias básicas do banco de dados são compartilhadas entre o inquilino ; portanto, é possível uma saída de recursos, o que não permite cumprir totalmente o contrato de serviço TIER .

Isolamento da instância de banco de dados para inquilino

O diagrama mostra a implementação de um banco de dados de inquilino para isolamento da instância. Hoje, essa é provavelmente a melhor solução que combina segurança e confiabilidade. Há AWS IAM , auditoria do AWS CloudTrail e isolamento total do inquilino .



Prós:

• O AWS IAM fornece autenticação e autorização;
• Há uma auditoria completa;
• tenant.

:

• tenant — .

multitenant

Garantir que os aplicativos tenham acesso correto aos dados é mais importante do que armazenar dados em um modelo de inquilino que atenda aos requisitos de negócios. Não é difícil se você usa o AWS IAM para controle de acesso (veja os exemplos acima). Os aplicativos que fornecem acesso de inquilino aos dados também podem usar o AWS IAM . Isso pode ser visto no exemplo do Amazon EKS .



Para fornecer acesso ao IAM no nível do pod no EKS , é perfeitamente adequado o OpenID the Connect (OIDC) , com anotações para considerar o Kubernetes . Como resultado, o JWT será trocado porSTS , que criará acesso temporário para aplicativos aos recursos de nuvem necessários. Com essa abordagem, você não precisa inserir permissões estendidas para os nós de trabalho básicos do Amazon EKS . Em vez disso, você pode configurar apenas permissões do IAM para a conta associada ao pod . Isso é feito com base nas permissões reais do aplicativo que está sendo executado como parte do pod . Como resultado, obtemos controle total das permissões de aplicativos e pods .





A integração do IAM oferece suporte a um sistema abrangente de autorização para o acesso do inquilino aos armazenamentos de dados. Nesse caso, o acesso ao banco de dados é controlado apenas por autenticação, o que significa que outro nível de segurança deve ser introduzido.

O Amazon EKS acessa o AWS DynamoDB de vários participantes

Uma análise mais detalhada do acesso multitenant , tanto um aplicativo em execução no EKS da Amazon , obtém acesso ao banco de dados multitenant DynamoDB da Amazon . Em muitos casos, os processos com vários locatários no Amazon DynamoDB são implementados no nível da tabela (na proporção de tabelas e inquilino 1: 1). Como exemplo, considere o princípio do AWS IAM ( aws-dynamodb-tenant1-policy ), que ilustra perfeitamente o padrão de acesso, no qual todos os dados estão associados ao Tenant1 .

{
   ...
   "Statement": [
       {
           "Sid": "Tenant1",
           "Effect": "Allow",
           "Action": "dynamodb:*",
           "Resource": "arn:aws:dynamodb:${region}-${account_id}:table/Tenant1"
       }
   ]
}

A próxima etapa é associar essa função a uma conta de cluster EKS que usa o OpenID .

eksctl utils associate-iam-oidc-provider \
      --name my-cluster \
      --approve \
      --region ${region}

eksctl create iamserviceaccount \
      --name tenant1-service-account \
      --cluster my-cluster \
      --attach-policy-arn arn:aws:iam::xxxx:policy/aws-dynamodb-tenant1-policy \
      --approve \
      --region ${region}

Uma definição de pod que contenha a especificação serviceAccountName necessária ajudará você a usar a nova conta de serviço tenant1-service-account .

apiVersion: v1
kind: Pod
metadata:
 name: my-pod
spec:
serviceAccountName: tenant1-service-account
 containers:
 - name: tenant1
…

Embora a conta e a política de inquilino do IAM sejam focadas, estáticas e gerenciadas por ferramentas como Terraform e Ansible , a especificação do pod pode ser configurada dinamicamente. Se você estiver usando um gerador de modelos como Helm , serviceAccountName poderá ser definido como uma variável para as contas de inquilino do serviço apropriadas . Como resultado, cada inquilino terá sua própria implantação dedicada do mesmo aplicativo. De fato, cada inquilino deve ter um espaço para nome dedicado onde os aplicativos serão executados.

Conclusão

Para serviços SaaS , é importante pensar cuidadosamente sobre como os dados serão acessados. Considere os requisitos de armazenamento, criptografia, desempenho e gerenciamento de inquilino . No multitenant, não há uma maneira preferida de compartilhar dados. A vantagem de executar cargas de trabalho com vários locatários na AWS é o AWS IAM , que pode ser usado para simplificar o controle sobre o acesso aos dados do inquilino. Além disso, o AWS IAM pode ajudá-lo a configurar o acesso de aplicativos aos dados dinamicamente.



As características e técnicas descritas que podem ser úteis abordaram uma pequena teoria. Mas em casos especiais, é sempre necessário analisar independentemente as informações de origem e criar uma solução personalizada.