Isolierung und Silo für Data Warehouses in mandantenfähigen Lösungen

In einem der vorherigen Artikel haben wir einige wichtige Punkte beim Einrichten eines Amazon EKS- Clusters mit mehreren Mandanten (im Folgenden: mehrere Mandanten ) behandelt . In Bezug auf die Sicherheit ist dies ein sehr weites Thema. Es ist wichtig zu verstehen, dass es bei der Sicherheit nicht nur um den Anwendungscluster geht, sondern auch um den Datenspeicher. AWS als Plattform für SaaS- Lösungen weist für Data Warehouses eine große Variabilität auf. Aber wie anderswo erfordert eine kompetente Sicherheitseinstellung, die eine Architektur mit mehreren Mandanten für sie erstellt und verschiedene Isolationsstufen einrichtet, bestimmte Kenntnisse und ein gewisses Verständnis der Besonderheiten der Arbeit.

Multitenant Data Warehouse

Es ist bequem, Daten mit mehreren Mandanten mithilfe von Silos, Silo, zu verwalten . Das Hauptmerkmal ist die Trennung von Mietdaten (im Folgenden Mieter ) in SaaS- Lösungen mit mehreren Mandanten . Bevor wir jedoch auf bestimmte Fälle eingehen, wollen wir eine kleine allgemeine Theorie ansprechen.

Nur ein Mieter sollte Zugang haben

Datensicherheit hat für SaaS- Lösungen Priorität . Es ist notwendig, Daten nicht nur vor externen Eingriffen, sondern auch vor der Interaktion mit anderen Mandanten zu schützen . Selbst wenn zwei Mandanten zusammenarbeiten, wird der Zugriff auf gemeinsam genutzte Daten gemäß der Geschäftslogik gesteuert und konfiguriert.

Industriestandards für Verschlüsselung und Sicherheit

Tenant - Standards können von der Industrie variieren. Einige erfordern eine Datenverschlüsselung mit einer genau definierten Häufigkeit von Schlüsselwechseln, während andere mandantenorientierte anstelle von gemeinsam genutzten Schlüsseln erfordern . Durch die Identifizierung von Datasets mit bestimmten Mandanten können ausnahmsweise unterschiedliche Verschlüsselungsstandards und Sicherheitseinstellungen auf einzelne Mandanten angewendet werden .

Leistungsoptimierung basierend auf dem Mandantenabonnement

In der Regel empfehlen SaaS- Anbieter einen gemeinsamen Workflow für alle Mandanten . Aus praktischer Sicht ist dies in Bezug auf eine bestimmte Geschäftslogik möglicherweise nicht immer bequem. Daher können Sie es anders machen. Jedem Mieter werden basierend auf dem TIER- Standard unterschiedliche Eigenschaften und Leistungsgrenzen zugewiesen . Damit Kunden die in der SaaS- Vereinbarung angegebene Leistung erhalten, müssen Anbieter die Nutzung einzelner Mieter verfolgen . Dies gibt allen Kunden den gleichen Zugang zu Ressourcen.

Datenmanagement

Mit dem Wachstum der SaaS- Dienste steigt auch die Anzahl der Mandanten . Wenn der Client den Anbieter wechselt, möchte er meistens, dass alle Daten in eine andere Ressource geladen und die alten gelöscht werden. Wenn der erste Wunsch bestritten werden kann, wird die Erfüllung des zweiten durch die Allgemeine Datenschutzverordnung der Europäischen Union garantiert. Für die korrekte Ausführung der Regeln muss der SaaS- Anbieter zunächst die Datensätze der einzelnen Mandanten identifizieren .

So verwandeln Sie ein reguläres Data Warehouse in ein Mandantenprogramm

Ich möchte sofort darauf hinweisen, dass es keinen magischen Code gibt. Sie können nicht einfach einen Data Warehouse-Speicher für Mandanten abrufen und konfigurieren . Folgende Aspekte sollten berücksichtigt werden:

• Dienstleistungsvertrag
• Zugriffsmuster zum Lesen und Schreiben;
• Einhaltung von Vorschriften;
• Kosten.

Es gibt jedoch eine Reihe allgemein anerkannter Praktiken zum Teilen und Isolieren von Daten. Betrachten Sie diese Fälle am Beispiel der relationalen Datenbank Amazon Aurora .

Partitionieren von Mandantendaten über gemeinsam genutzte Speicher und Instanzen

Die Tabelle wird von allen Mietern verwendet . Einzelne Daten werden durch den Schlüssel tenant_id getrennt und identifiziert . Relationale Datenbankberechtigung wird bei der implementierten Sicherheit auf Zeilenebene . Der Zugriff auf die Anwendung basiert auf der Zugriffsrichtlinie und berücksichtigt einen bestimmten Mandanten .



Vorteile:

• Es ist nicht teuer.

Minuspunkte:

• Autorisierung auf Datenbankebene. Dies impliziert mehrere Autorisierungsmechanismen innerhalb der Lösung: AWS IAM- und Datenbankrichtlinien;
• Um den Mandanten zu identifizieren , müssen Sie eine Anwendungslogik entwickeln.
• Ohne vollständige Isolation ist es nicht möglich, den TIER- Servicevertrag durchzusetzen .
• Die Autorisierung auf Datenbankebene beschränkt die Zugriffsverfolgung mit AWS CloudTrail . Dies kann nur durch Hinzufügen von Informationen von außen ausgeglichen werden. Besser Tracking und Fehlerbehebung.

Datenisolation auf gemeinsam genutzten Instanzen

Leasing ( Mietverhältnis ) ist auf Instanzebene immer noch rassharivat. Gleichzeitig kommt es jedoch auf Datenbankebene zu Datenbunkern. Dies ermöglicht die AWS IAM-Authentifizierung und -Autorisierung.



Vorteile:

• Es ist nicht teuer;
• AWS IAM ist vollständig für die Authentifizierung und Autorisierung verantwortlich.
• Mit AWS IAM können Sie Überwachungsprotokolle in AWS CloudTrail ohne Krücken als separate Anwendungen führen.

Minuspunkte:

• Grundlegende Datenbankinstanzen werden von Mandanten gemeinsam genutzt . Daher ist ein Ressourcenabfluss möglich, der die vollständige Einhaltung des TIER- Servicevertrags nicht ermöglicht .

Datenbankinstanzisolation für Mandanten

Das Diagramm zeigt die Implementierung einer Mandantendatenbank zum Beispiel Isolation. Heute ist dies wahrscheinlich die beste Lösung, die Sicherheit und Zuverlässigkeit kombiniert. Es gibt AWS IAM und Audit von AWS CloudTrail sowie eine vollständige Isolierung der Mandanten .



Vorteile:

• AWS IAM bietet sowohl Authentifizierung als auch Autorisierung.
• Es gibt eine vollständige Prüfung;
• tenant.

:

• tenant — .

multitenant

Es ist wichtiger sicherzustellen, dass Anwendungen den richtigen Zugriff auf Daten haben, als Daten in einem Mandantenmodell zu speichern, das den Geschäftsanforderungen entspricht. Es ist nicht schwierig, wenn Sie AWS IAM für die Zugriffskontrolle verwenden (siehe Beispiele oben). Anwendungen, die Mandantenzugriff auf Daten ermöglichen, können auch AWS IAM verwenden . Dies ist am Beispiel von Amazon EKS zu sehen .



Um IAM- Zugriff auf Pod- Ebene in EKS bereitzustellen , ist OpenID Connect (OIDC) zusammen mit Kubernetes- Kontoanmerkungen perfekt . Als Ergebnis der JWT werden ausgetauscht mitSTS , das temporären Zugriff für Anwendungen auf die erforderlichen Cloud-Ressourcen erstellt. Bei diesem Ansatz müssen Sie keine erweiterten Berechtigungen für die grundlegenden Amazon EKS- Worker-Knoten eingeben . Stattdessen können Sie nur IAM- Berechtigungen für das podbezogene Konto konfigurieren . Dies erfolgt basierend auf den tatsächlichen Berechtigungen der Anwendung, die als Teil des Pods ausgeführt wird . Dadurch erhalten wir die volle Kontrolle über die Anwendungs- und Pod- Berechtigungen .





Integration IAM unterstützt ein umfassendes Autorisierungssystem für den Mandantenzugriff auf Data Warehouses. In diesem Fall wird der Zugriff auf die Datenbank nur über die Authentifizierung gesteuert. Dies bedeutet, dass Sie eine andere Sicherheitsstufe eingeben müssen.

Amazon EKS greift auf die AWS DynamoDB-Datenbank mit mehreren Mandanten zu

Bei näherer Betrachtung des Multitenant- Zugriffs, einer Anwendung, die auf Amazon EKS ausgeführt wird , wird Zugriff auf die Multitenant- Datenbank Amazon DynamoDB gewährt . In vielen Fällen werden mandantenfähige Prozesse in Amazon DynamoDB auf Tabellenebene implementiert (im Verhältnis von Tabellen und Mandant 1: 1). Betrachten Sie als Beispiel das AWS IAM -Prinzip ( aws-dynamodb-tenant1-policy ), das das Zugriffsmuster, bei dem alle Daten an Tenant1 gebunden sind, perfekt veranschaulicht .

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

Der nächste Schritt besteht darin, diese Rolle einem EKS- Clusterkonto zuzuordnen , das OpenID verwendet .

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}

Die Pod- Definition , die die erforderliche serviceAccountName- Spezifikation enthält , hilft Ihnen bei der Verwendung des neuen Dienstkontos tenant1-service-account .

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

Obwohl das IAM-Mandantenkonto und die Richtlinie fokussiert, statisch und von Tools wie Terraform und Ansible verwaltet werden , kann die Pod- Spezifikation dynamisch konfiguriert werden. Wenn Sie einen Vorlagengenerator wie Helm verwenden , kann serviceAccountName als Variable für die entsprechenden Service- Mandantenkonten festgelegt werden . Infolgedessen verfügt jeder Mandant über eine eigene dedizierte Bereitstellung derselben Anwendung. Tatsächlich sollte jeder Mandant über einen dedizierten Namespace verfügen, in dem Anwendungen ausgeführt werden.

Fazit

Für SaaS- Dienste ist es wichtig, sorgfältig darüber nachzudenken, wie auf die Daten zugegriffen wird. Sollte Speicheranforderungen, Verschlüsselung, Leistung und Verwaltung des Mandanten berücksichtigen . In Multitenant gibt es keine bevorzugte Möglichkeit, Daten gemeinsam zu nutzen. Der Vorteil der Ausführung von Workloads mit mehreren Mandanten in AWS ist AWS IAM , mit dem die Kontrolle über den Zugriff auf Mandantendaten vereinfacht werden kann. Darüber hinaus kann Ihnen AWS IAM dabei helfen, den Anwendungszugriff auf Daten dynamisch zu konfigurieren.



Die beschriebenen Funktionen und Techniken, die sich als nützlich erweisen können, haben eine kleine Theorie berührt. In besonderen Fällen ist es jedoch immer erforderlich, die Quellinformationen unabhängig zu analysieren und eine personalisierte Lösung zu erstellen.