Isolation et silos pour les entrepôts de données dans les solutions mutualisées

Dans l'un des articles précédents , nous avons couvert quelques points clés de la configuration d'un cluster Amazon EKS multi- locataire (ci-après multi - locataire ) . En ce qui concerne la sécurité, c'est un sujet très vaste. Il est important de comprendre que la sécurité ne concerne pas seulement le cluster d'applications, mais également le magasin de données. AWS en tant que plate-forme pour les solutions SaaS présente une grande variabilité pour l'entreposage de données. Mais, comme ailleurs, un environnement de sécurité compétent, l'élaboration d'une architecture mutualisée pour celui-ci, la mise en place de différents niveaux d'isolement nécessitent une certaine connaissance et compréhension des spécificités du travail.

Entrepôt de données mutualisé

Il est pratique de gérer les données multi-locataires à l'aide de silos, Silo . La principale caractéristique est la séparation des données de location (ci-après locataire ) dans les solutions SaaS multi- locataires . Mais avant de parler de cas spécifiques, abordons une petite théorie générale.

Un seul locataire doit avoir accès

La sécurité des données est une priorité pour les solutions SaaS . Il est nécessaire de protéger les données non seulement des intrusions externes, mais également de l'interaction avec d'autres locataires . Même dans le cas où deux locataires coopèrent et que l'accès aux données communes est contrôlé et configuré selon la logique métier.

Normes de l'industrie pour le chiffrement et la sécurité

Les normes des locataires peuvent varier selon l'industrie. Certains nécessitent un chiffrement des données avec une fréquence de changement de clé bien définie, tandis que d'autres nécessitent des clés orientées client au lieu de clés partagées . En identifiant les baies de données avec des locataires spécifiques , différentes normes de chiffrement et paramètres de sécurité peuvent être appliqués à des locataires individuels à titre d'exception.

Réglage des performances en fonction de l'abonnement du locataire

Habituellement, les fournisseurs SaaS recommandent un flux de travail commun pour tous les locataires . D'un point de vue pratique, cela peut ne pas toujours être pratique par rapport à une logique métier spécifique. Par conséquent, cela peut être fait différemment. Chaque locataire se voit attribuer un ensemble différent de propriétés et de limites de performance en fonction de la norme TIER . Pour que les clients obtiennent les performances indiquées dans l'accord SaaS , les fournisseurs doivent surveiller l'utilisation de chaque locataire . Grâce à cela, tous les clients bénéficient d'un accès égal aux ressources.

Gestion de données

À mesure que les services SaaS se développent, le nombre de locataires augmente également . Si le client change de fournisseur, il souhaite le plus souvent que toutes les données soient téléchargées vers une autre ressource et que les anciennes soient supprimées. Si le premier souhait peut être contesté, la réalisation du second est garantie par les règles générales de protection des données de l'UE. Pour une exécution correcte des règles, le fournisseur SaaS doit d'abord identifier les ensembles de données des locataires individuels .

Comment transformer un entrepôt de données standard en un multi-locataire

Je voudrais tout de suite noter qu'il n'y a pas de code magique. Vous ne pouvez pas simplement choisir et configurer un bac d'entrepôt de données de locataire . Les aspects suivants doivent être pris en compte:

• Contrat de service;
• Modèles d'accès pour la lecture et l'écriture;
• Conformité aux réglementations;
• Dépenses.

Mais il existe un certain nombre de pratiques généralement acceptées pour séparer et isoler les données. Considérez ces cas en utilisant la base de données relationnelle Amazon Aurora comme exemple .

Partitionner les données des locataires dans des référentiels et des instances partagés

La table est utilisée par tous les locataires . Les données individuelles sont partagées et identifiées par la clé tenant_id . L'autorisation de base de données relationnelle est implémentée au niveau de la sécurité au niveau des lignes . L'accès à l'application est basé sur une politique d'accès et prend en compte un locataire spécifique .



Avantages:

• Ce n'est pas chère.

Moins:

• Autorisation au niveau de la base de données. Cela implique plusieurs mécanismes d'autorisation au sein de la solution: AWS IAM et stratégies de base de données;
• Pour identifier le locataire, vous devrez développer une logique d'application;
• Sans un isolement complet, le contrat de service TIER ne peut pas être appliqué ;
• L'autorisation de la base de données limite le suivi d'accès avec AWS CloudTrail . Cela ne peut être compensé qu'en ajoutant des informations de l'extérieur. Mieux vaut faire le suivi et le dépannage.

Isolation des données sur les instances partagées

Le bail ( location ) est toujours rassharivat au niveau de l'instance. Mais en même temps, le soutage de données se produit au niveau de la base de données. Cela rend l'authentification et l'autorisation AWS IAM possibles.



Avantages:

• Ce n'est pas chère;
• AWS IAM est entièrement responsable de l'authentification et de l'autorisation;
• AWS IAM vous permet de conserver les journaux d'audit sur AWS CloudTrail sans béquilles en tant qu'applications séparées.

Moins:

• Les instances de base de données de base sont partagées entre les locataires , par conséquent, une sortie de ressources est possible, ce qui ne permet pas de se conformer pleinement au contrat de service TIER .

Isolation d'instance de base de données pour le client

Le diagramme montre une mise en œuvre d'un locataire base de données lorsque des instances d' isolement. C'est probablement aujourd'hui la meilleure solution alliant sécurité et fiabilité. Il y a AWS IAM , et l'audit d' AWS CloudTrail , et l'isolement complet du locataire .



Avantages:

• AWS IAM fournit à la fois l'authentification et l'autorisation;
• Il y a un audit complet;
• tenant.

:

• tenant — .

multitenant

Il est plus important de garantir que les applications disposent d'un accès correct aux données que de stocker des données dans un modèle de client qui répond aux exigences de l'entreprise. Ce n'est pas difficile si vous utilisez AWS IAM pour le contrôle d'accès (voir les exemples ci-dessus). Les applications qui fournissent un accès aux données au locataire peuvent également utiliser AWS IAM . Cela peut être vu dans l'exemple d' Amazon EKS .



Pour fournir un accès IAM au niveau du pod dans EKS , OpenID Connect (OIDC) est parfait , avec les annotations de compte Kubernetes . En conséquence, le JWT sera échangé avecSTS , qui créera un accès temporaire des applications aux ressources cloud nécessaires. Avec cette approche, il n'est pas nécessaire d'introduire des autorisations avancées pour les stations de travail principales Amazon EKS . Au lieu de cela, vous pouvez configurer uniquement les autorisations IAM pour le compte associé au pod . Cela se fait en fonction des autorisations réelles de l'application qui s'exécute dans le cadre du pod . En conséquence, nous obtenons un contrôle total des autorisations des applications et des pods .





L' intégration IAM prend en charge un système d'autorisation complet pour l'accès des locataires aux magasins de données. Dans ce cas, l'accès à la base de données est contrôlé uniquement par authentification, ce qui signifie qu'un autre niveau de sécurité doit être introduit.

Amazon EKS accède à AWS DynamoDB multi-locataire

Un examen plus approfondi de l' accès mutualisé , à la fois une application exécutée sur EKS d'Amazon , permet d'accéder à la base de données multi-locataire DynamoDB d'Amazon . Dans de nombreux cas, les processus multi - locataires dans Amazon DynamoDB sont implémentés au niveau de la table (dans un rapport table / locataire 1: 1). À titre d'exemple, considérons le principe AWS IAM ( aws-dynamodb-tenant1-policy ), qui illustre parfaitement le modèle d'accès, où toutes les données sont associées à Tenant1 .

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

L'étape suivante consiste à associer ce rôle à un compte de cluster EKS qui utilise 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}

Une définition de pod qui contient la spécification serviceAccountName requise vous aidera à utiliser le nouveau compte de service tenant1-service-account .

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

Bien que le compte et la stratégie du locataire IAM soient orientés, statiques et gérés avec des outils tels que Terraform et Ansible , la spécification du pod peut être configurée dynamiquement. Si vous utilisez un générateur de modèle tel que Helm , serviceAccountName peut être défini en tant que variable pour les comptes de locataire de service appropriés . En conséquence, chaque locataire aura son propre déploiement dédié de la même application. En fait, chaque locataire devrait avoir un espace de noms dédié où les applications s'exécuteront.

Conclusion

Pour les services SaaS , il est important de bien réfléchir à la manière dont les données seront accessibles. Considérez le stockage, le cryptage, la performance et locataire exigences de gestion . Dans les locataires multiples, vous avez l'une des méthodes préférées de partitionnement des données. L'avantage de l'exécution de charges de travail mutualisées sur AWS est AWS IAM , qui peut être utilisé pour simplifier le contrôle de l'accès aux données des locataires. En outre, AWS IAM peut vous aider à configurer l'accès des applications aux données de manière dynamique.



Les caractéristiques et techniques décrites qui peuvent être utiles ont touché un peu de théorie. Mais dans des cas particuliers, il est toujours nécessaire d'analyser indépendamment les informations source et de créer une solution personnalisée.