Überlegungen zu Mehrmandantenfähigkeit

Möglicherweise möchten Sie Anwendungen für die Verwendung durch mehrere Kunden entwickeln – Unternehmen, die Ihre Anwendung nutzen, oder Mandanten – und sie in Amazon Verified Permissions integrieren. Bevor Sie Ihr Autorisierungsmodell entwickeln, entwickeln Sie eine Multi-Tenant-Strategie. Sie können die Richtlinien Ihrer Kunden in einem gemeinsam genutzten Richtlinienspeicher verwalten oder jedem einen Richtlinienspeicher pro Mandanten zuweisen.

1. Ein gemeinsam genutzter Richtlinienspeicher

   Alle Mandanten teilen sich einen einzelnen Richtlinienspeicher. Die Anwendung sendet alle Autorisierungsanforderungen an den freigegebenen Richtlinienspeicher.

2. Richtlinienspeicher pro Mandanten

   Jeder Mandant verfügt über einen dedizierten Richtlinienspeicher. Die Anwendung fragt verschiedene Richtlinienspeicher nach einer Autorisierungsentscheidung ab, je nachdem, welcher Mandant die Anforderung stellt.

Beide Strategien erzeugen ein relativ höheres Volumen an Autorisierungsanforderungen, die sich auf Ihre AWS Rechnung auswirken könnten. Wie sollten Sie dann Ihren Ansatz entwerfen? Im Folgenden finden Sie allgemeine Bedingungen, die zu Ihrer Multi-Tenancy-Autorisierungsstrategie für Verified Permissions beitragen können.

Isolation von Mandantenrichtlinien

Die Isolierung der Richtlinien jedes Mandanten von den anderen ist wichtig, um Mandantendaten zu schützen. Wenn jeder Mandant seinen eigenen Richtlinienspeicher hat, verfügt er über seinen eigenen isolierten Richtliniensatz.

Autorisierungsablauf

Sie können einen Mandanten, der eine Autorisierungsanforderung stellt, mit einer Richtlinienspeicher-ID in der Anforderung identifizieren, mit Richtlinienspeichern pro Mandanten. Bei einem freigegebenen Richtlinienspeicher verwenden alle Anforderungen dieselbe Richtlinienspeicher-ID.

Vorlagen und Schemaverwaltung

Ihre Richtlinienvorlagen und ein Richtlinienspeicherschema fügen in jedem Richtlinienspeicher einen zusätzlichen Design- und Wartungsaufwand hinzu.

Verwaltung globaler Richtlinien

Möglicherweise möchten Sie einige global eRichtlinien auf jeden Mandanten anwenden. Der Aufwand für die Verwaltung globaler Richtlinien variiert je nach gemeinsam genutzten und pro Mandanten verwendeten Richtlinienspeichermodellen.

Mandanten außerhalb des Onboardings

Einige Mandanten tragen Elemente zu Ihrem Schema und Ihren Richtlinien bei, die für ihren Fall spezifisch sind. Wenn ein Mandant in Ihrer Organisation nicht mehr aktiv ist und Sie seine Daten entfernen möchten, variiert der Aufwand je nach Isolationsgrad anderer Mandanten.

Service-Ressourcenkontingente

Verified Permissions verfügt über Kontingente für Ressourcen und Anforderungsrate, die sich auf Ihre Entscheidung für mehrere Mandanten auswirken könnten. Weitere Informationen zu Kontingenten finden Sie unter Kontingente für Ressourcen.

Vergleich von freigegebenen Richtlinienspeichern und Richtlinienspeichern pro Mandanten

Jede Überlegung erfordert ein eigenes Maß an Zeit und Ressourcennutzung in gemeinsam genutzten und mandantenspezifischen Richtlinienspeichermodellen.

Überlegungen	Aufwandsebene in einem freigegebenen Richtlinienspeicher	Aufwandsebene in Richtlinienspeichern pro Mandanten
Isolation von Mandantenrichtlinien	Mittel. Must include tenant identifiers in policies and authorization requests.	Niedrig. Isolation is default behavior. Tenant-specific policies are inaccessible to other tenants.
Autorisierungsablauf	Niedrig. All queries target one policy store.	Mittel. Must maintain mappings between each tenant and their policy store ID.
Vorlagen und Schemaverwaltung	Niedrig. Must make one schema work for all tenants.	Hoch. Schemas and templates might be less complex individually, but changes require more coordination and complexity.
Verwaltung globaler Richtlinien	Niedrig. All policies are global and can be centrally updated.	Hoch. You must add global policies to each policy store in onboarding. Replicate global policy updates between many policy stores.
Mandanten außerhalb des Onboardings	Mittel. Must identify and delete only tenant-specific policies.	Niedrig. Delete the policy store.
Service-Ressourcenkontingente	Hoch. Tenants share resource quotas that affect policy stores like schema size, policy size per resource, and identity sources per policy store.	Niedrig. Each tenant has dedicated resource quotas.

So wählen Sie aus

Jede Multi-Tenant-Anwendung unterscheidet sich. Vergleichen Sie sorgfältig die beiden Ansätze und ihre Überlegungen, bevor Sie eine architektonische Entscheidung treffen.

Wenn Ihre Anwendung keine mandantenspezifischen Richtlinien erfordert und eine einzelne Identitätsquelle verwendet, ist ein gemeinsam genutzter Richtlinienspeicher für alle Mandanten wahrscheinlich die effektivste Lösung. Dies führt zu einem einfacheren Autorisierungsablauf und einer globalen Richtlinienverwaltung. Das Abbinden eines Mandanten mit einem freigegebenen Richtlinienspeicher erfordert weniger Aufwand, da die Anwendung keine mandantenspezifischen Richtlinien löschen muss.

Wenn Ihre Anwendung jedoch viele mandantenspezifische Richtlinien erfordert oder mehrere Identitätsquellen verwendet, sind Richtlinienspeicher pro Mandanten wahrscheinlich am effektivsten. Sie können den Zugriff auf Mandantenrichtlinien mit IAM Richtlinien steuern, die jedem Richtlinienspeicher Berechtigungen pro Mandanten gewähren. Beim Off-Onboarding eines Mandanten müssen Sie seinen Richtlinienspeicher löschen. In einer shared-policy-store Umgebung müssen Sie Tenant-spezifische Richtlinien finden und löschen.