Amazon-Prognose ist ein vollständig verwalteter Dienst, der auf derselben Technologie basiert, die für die Prognose bei Amazon.com verwendet wird. Forecast verwendet maschinelles Lernen (ML), um Zeitreihendaten mit zusätzlichen Variablen zu kombinieren und hochgenaue Prognosen zu erstellen. Die Prognose erfordert keine ML-Erfahrung, um loszulegen. Sie müssen nur historische Daten und zusätzliche Daten angeben, die sich auf Prognosen auswirken können.
Kunden wenden sich der Verwendung eines SaaS-Modells (Software as Service) für die Bereitstellung mandantenfähiger Lösungen zu. Sie können SaaS-Anwendungen mit einer Vielzahl unterschiedlicher Architekturmodelle erstellen, um die gesetzlichen Anforderungen und Compliance-Anforderungen zu erfüllen. Abhängig vom SaaS-Modell werden Ressourcen wie Forecast von Mandanten gemeinsam genutzt. Der prognostizierte Datenzugriff, die Überwachung und die Abrechnung müssen für die Bereitstellung von SaaS-Lösungen pro Mandant berücksichtigt werden.
In diesem Beitrag wird erläutert, wie Sie Forecast in einer mandantenfähigen SaaS-Anwendung verwenden Attributbasierte Zugriffssteuerung (ABAC) ein AWS Identity and Access Management and (IAM), um diese Funktionen bereitzustellen. ABAC ist ein leistungsstarker Ansatz, mit dem Sie Ressourcen mandantenübergreifend isolieren können.
In diesem Beitrag geben wir Anleitungen zum Einrichten von IAM-Richtlinien für Mieter unter Verwendung der ABAC-Prinzipien und -Prognosen. Um die Konfiguration zu demonstrieren, haben wir zwei Mandanten eingerichtet: TenantA
und TenantB
und zeigen einen Anwendungsfall im Kontext einer SaaS-Anwendung mithilfe von Forecast. In unserem Anwendungsfall TenantB
kann nicht löschen TenantA
Ressourcen und umgekehrt. Das folgende Diagramm zeigt unsere Architektur.
TenantA
und TenantB
haben Dienste, die als Microservice ausgeführt werden Amazon Elastic Kubernetes-Service (Amazon EKS). Die Mandantenanwendung verwendet Forecast als Teil ihres Geschäftsflusses.
Prognose Datenaufnahme
Forecast importiert Daten vom Mandanten Amazon Simple Storage-Service (Amazon S3) Bucket zum Forecast Managed S3 Bucket. Daten können während der Übertragung und im Ruhezustand automatisch mit Forecast-verwalteten Schlüsseln oder mandantenspezifischen Schlüsseln verschlüsselt werden AWS-Schlüsselverwaltungsservice (AWS KMS). Der mandantenspezifische Schlüssel kann von der SaaS-Anwendung im Rahmen des Onboarding erstellt werden, oder der Mandant kann mithilfe von AWS KMS einen eigenen kundenverwalteten Schlüssel (CMK) bereitstellen. Durch das Widerrufen der Berechtigung für den mandantenspezifischen Schlüssel wird verhindert, dass Forecast die Daten des Mandanten verwendet. Wir empfehlen die Verwendung eines mandantenspezifischen Schlüssels und einer IAM-Rolle pro Mandant in einer SaaS-Umgebung mit mehreren Mandanten. Dies ermöglicht die Sicherung von Daten auf Mandantenbasis.
Lösungsüberblick
Sie können Daten in Amazon S3 partitionieren, um den Mandantenzugriff auf verschiedene Arten zu trennen. In diesem Beitrag diskutieren wir zwei Strategien:
- Verwenden Sie einen S3-Eimer pro Mieter
- Verwenden Sie einen einzelnen S3-Bucket und trennen Sie Mandantendaten mit einem Präfix
Weitere Informationen zu verschiedenen Strategien finden Sie in der Speichern von mandantenfähigen Daten in Amazon S3 GitHub Repo.
Wenn Sie einen Bucket pro Mandant verwenden, verwenden Sie eine IAM-Richtlinie, um den Zugriff auf einen bestimmten Mandanten-S3-Bucket zu beschränken. Beispielsweise:
Die Anzahl der S3-Buckets pro Konto ist streng begrenzt. Eine Multi-Account-Strategie muss in Betracht gezogen werden, um diese Grenze zu überwinden.
In unserer zweiten Option werden Mandantendaten mithilfe eines S3-Präfixes in einem einzelnen S3-Bucket getrennt. Wir verwenden eine IAM-Richtlinie, um den Zugriff innerhalb eines Bucket-Präfixes pro Mandant einzuschränken. Beispielsweise:
Für diesen Beitrag verwenden wir die zweite Option zum Zuweisen von S3-Präfixen innerhalb eines einzelnen Buckets. Wir verschlüsseln Mandantendaten mit CMKs in AWS KMS.
Mieter Onboarding
SaaS-Anwendungen basieren auf einem reibungslosen Modell, um neue Mieter in ihre Umgebung einzuführen. Dies erfordert häufig die Orchestrierung mehrerer Komponenten, um alle Elemente, die zum Erstellen eines neuen Mandanten erforderlich sind, erfolgreich bereitzustellen und zu konfigurieren. Dieser Prozess wird in der SaaS-Architektur als bezeichnet Mieter Onboarding. Dies kann direkt von Mandanten oder als Teil eines vom Anbieter verwalteten Prozesses initiiert werden. Das folgende Diagramm zeigt den Ablauf der Konfiguration der Prognose pro Mandant als Teil des Onboarding-Prozesses.
Ressourcen sind mit Mandanteninformationen versehen. Für diesen Beitrag kennzeichnen wir Ressourcen mit einem Wert für den Mandanten, z. tenant_a
.
Erstellen Sie eine Prognoserolle
Diese IAM-Rolle wird von Forecast pro Mandant übernommen. Sie sollten die folgenden Richtlinien anwenden, damit Forecast mit Amazon S3 und AWS KMS im Kundenkonto interagieren kann. Die Rolle ist mit dem Tag-Mandanten gekennzeichnet. Siehe zum Beispiel den folgenden Code:
Erstellen Sie die Richtlinien
In diesem nächsten Schritt erstellen wir Richtlinien für unsere Prognoserolle. Für diesen Beitrag haben wir sie zur besseren Lesbarkeit in zwei Richtlinien aufgeteilt. Sie können sie jedoch entsprechend Ihren Anforderungen erstellen.
Richtlinie 1: Prognostizieren Sie den schreibgeschützten Zugriff
Die folgende Richtlinie gewährt Berechtigungen zum Beschreiben, Auflisten und Abfragen von Prognoseressourcen. Diese Richtlinie beschränkt Forecast auf den schreibgeschützten Zugriff. Die Tenant-Tag-Validierungsbedingung im folgenden Code stellt sicher, dass der Tenant-Tag-Wert mit dem Tenant-Tag des Principals übereinstimmt. Siehe die fettgedruckter Code für Einzelheiten.
Richtlinie 2: Zugriffsrichtlinie für Amazon S3 und AWS KMS
Die folgende Richtlinie gewährt AWS KMS Berechtigungen und Zugriff auf das S3-Mandantenpräfix. Die Tenant-Tag-Validierungsbedingung im folgenden Code stellt sicher, dass der Tenant-Tag-Wert mit dem Tenant-Tag des Principals übereinstimmt. Siehe die fettgedruckter Code für Einzelheiten.
Erstellen Sie einen mandantenspezifischen Schlüssel
Wir erstellen jetzt einen mandantenspezifischen Schlüssel in AWS KMS pro Mandant und kennzeichnen ihn mit dem Mandanten-Tag-Wert. Alternativ kann der Mandant seinen eigenen Schlüssel zu AWS KMS bringen. Wir geben die vorhergehenden Rollen (Forecast_TenantA_Role
or Forecast_TenantB_Role
) Zugriff auf den mandantenspezifischen Schlüssel.
Der folgende Screenshot zeigt beispielsweise das Schlüssel-Wert-Paar von tenant
und tenant_a
.
Der folgende Screenshot zeigt die IAM-Rollen, die diesen Schlüssel verwenden können.
Erstellen Sie eine Anwendungsrolle
Die zweite Rolle, die wir erstellen, wird von der SaaS-Anwendung pro Mandant übernommen. Sie sollten die folgenden Richtlinien anwenden, damit die Anwendung mit Forecast, Amazon S3 und AWS KMS interagieren kann. Die Rolle ist mit dem Tag-Mandanten gekennzeichnet. Siehe folgenden Code:
Erstellen Sie die Richtlinien
Wir erstellen jetzt Richtlinien für die Anwendungsrolle. Für diesen Beitrag haben wir sie zur besseren Lesbarkeit in zwei Richtlinien aufgeteilt. Sie können sie jedoch entsprechend Ihren Anforderungen erstellen.
Richtlinie 1: Prognosezugriff
Die folgende Richtlinie gewährt Berechtigungen zum Erstellen, Aktualisieren und Löschen von Prognoseressourcen. Die Richtlinie erzwingt die Tag-Anforderung während der Erstellung. Darüber hinaus schränkt es die list
, describe
und delete
Maßnahmen auf Ressourcen an den jeweiligen Mieter. Diese Richtlinie hat IAM PassRole
damit Forecast die Rolle übernehmen kann.
Das tenant
Die Tag-Validierungsbedingung im folgenden Code stellt sicher, dass der Tenant-Tag-Wert mit dem Tenant übereinstimmt. Siehe die fettgedruckter Code für Einzelheiten.
Richtlinie 2: Zugriff auf Amazon S3, AWS KMS, Amazon CloudWatch und Ressourcengruppen
Die folgende Richtlinie gewährt Berechtigungen für den Zugriff auf Amazon S3- und AWS KMS-Ressourcen sowie Amazon CloudWatch. Es beschränkt den Zugriff auf das mandantenspezifische S3-Präfix und das mandantenspezifische CMK. Die Mandantenvalidierungsbedingung ist in fettgedruckter Code.
Erstellen Sie eine Ressourcengruppe
Mit der Ressourcengruppe können alle markierten Ressourcen vom Mandanten abgefragt werden. Der folgende Beispielcode verwendet die AWS-Befehlszeilenschnittstelle (AWS CLI) zum Erstellen einer Ressourcengruppe für TenantA
:
Anwendungsfluss prognostizieren
Das folgende Diagramm zeigt unseren Prognoseanwendungsablauf. Der Anwendungsdienst übernimmt die IAM-Rolle für den Mandanten und ruft im Rahmen seines Geschäftsablaufs die Prognose-API auf.
Erstellen Sie einen Prädiktor für TenantB
Die erstellten Ressourcen sollten mit dem Mandanten-Tag versehen werden. Der folgende Code verwendet die Python (Boto3) -API, um einen Prädiktor für TenantB zu erstellen (siehe fettgedruckter Code für Einzelheiten):
Erstellen Sie eine Prognose für den Prädiktor für TenantB
Der folgende Code verwendet die Python (Boto3) -API, um eine Prognose für den soeben erstellten Prädiktor zu erstellen:
Überprüfen Sie den Zugriff auf Prognoseressourcen
In diesem Abschnitt bestätigen wir, dass nur der jeweilige Mandant auf Prognoseressourcen zugreifen kann. Der Zugriff auf, das Ändern oder Löschen von Prognoseressourcen, die einem anderen Mandanten gehören, löst einen Fehler aus. Der folgende Code verwendet die Python (Boto3) -API, um zu demonstrieren, wie TenantA versucht, eine TenantB-Prognoseressource zu löschen:
Prädiktoren auflisten und überwachen
Der folgende Beispielcode verwendet die Python (Boto3) -API, um Prognoseprädiktoren für TenantA mithilfe von Ressourcengruppen abzufragen:
Da die AWS Well-Architated-Framework erklärt, es ist wichtig, Servicekontingente zu überwachen (die auch als bezeichnet werden) Servicelimits). Die Prognose hat Limits pro Konto. Weitere Informationen finden Sie unter Richtlinien und Quoten.
Der folgende Code ist ein Beispiel für das Auffüllen einer CloudWatch-Metrik mit der Gesamtzahl der Prädiktoren:
Andere Überlegungen
Ressourcenlimits und Drosselung müssen von der Anwendung mandantenübergreifend verwaltet werden. Wenn Sie das nicht unterbringen können Prognosegrenzensollten Sie eine Konfiguration mit mehreren Konten in Betracht ziehen.
Die Prognoselisten-APIs oder die Ressourcengruppenantwort müssen nach Anwendung basierend auf dem gefiltert werden tenant
Tag-Wert.
Zusammenfassung
In diesem Beitrag haben wir gezeigt, wie der Prognosezugriff mithilfe der ABAC-Technik in einer mandantenfähigen SaaS-Anwendung isoliert wird. Wir haben gezeigt, wie der Zugriff auf Prognosen durch Mandanten mithilfe des Mandanten-Tags eingeschränkt werden kann. Sie können Richtlinien weiter anpassen, indem Sie weitere Tags anwenden oder diese Strategie auf andere AWS-Services anwenden.
Weitere Informationen zur Verwendung von ABAC als Autorisierungsstrategie finden Sie unter Was ist ABAC für AWS?
Über die Autoren
Gunjan Garg ist Senior Software Development Engineer im AWS Vertical AI-Team. In ihrer aktuellen Position bei Amazon Forecast konzentriert sie sich auf technische Probleme und baut gerne skalierbare Systeme auf, die den Endbenutzern den größten Nutzen bieten. In ihrer Freizeit spielt sie gerne Sudoku und Minesweeper.
Matthias Battaglia ist ein technischer Account Manager bei Amazon Web Services. In seiner derzeitigen Position hilft er Kunden gerne in allen Phasen ihrer Cloud-Reise. In seiner Freizeit baut er gerne AI / ML-Projekte.
Rakesh-Ramadas ist ein ISV Solution Architect bei Amazon Web Services. Seine Schwerpunkte sind AI / ML und Big Data.
- Zugang
- Konto
- Action
- Zusätzliche
- AI
- Amazon
- Amazon-Prognose
- Amazon Web Services
- Bienen
- APIs
- Anwendung
- Anwendungen
- Architektur
- Genehmigung
- AWS
- Rechnungs-
- bauen
- Building
- Geschäft
- Cloud
- Code
- Compliance
- Strom
- Kunden
- technische Daten
- Datenzugriff
- Entschlüsseln
- Lieferanten
- Entwicklung
- Ingenieur
- Entwicklung
- Arbeitsumfeld
- Fluss
- Setzen Sie mit Achtsamkeit
- Frei
- GitHub
- Gruppe an
- Ultraschall
- Hilfe
- HTTPS
- IAM
- Identitätsschutz
- Impact der HXNUMXO Observatorien
- Information
- IT
- Wesentliche
- Tasten
- Kubernetes
- lernen
- Line
- Liste
- Maschinelles Lernen
- Management
- ML
- Modell
- Überwachung
- Einsteigen
- Option
- Andere
- Politik durchzulesen
- Datenschutzrichtlinien
- Projekte
- Python
- Voraussetzungen:
- Ressourcen
- Downloads
- Antwort
- REST
- Laufen
- SaaS
- Modellreihe
- Lösungen
- kompensieren
- Einstellung
- von Locals geführtes
- Einfacher
- Software
- Software-Entwicklung
- Lösungen
- gespalten
- begonnen
- Erklärung
- Lagerung
- Strategie
- Systeme und Techniken
- Technische
- Technologie
- Zeit
- Transit
- Aktualisierung
- Nutzer
- Wert
- Netz
- Web-Services
- .