Prévisions Amazon est un service entièrement géré basé sur la même technologie que celle utilisée pour les prévisions sur Amazon.com. Forecast utilise l'apprentissage automatique (ML) pour combiner des données de séries chronologiques avec des variables supplémentaires afin de créer des prévisions très précises. Forecast ne nécessite aucune expérience en ML pour démarrer. Il vous suffit de fournir des données historiques et toutes les données supplémentaires susceptibles d'avoir une incidence sur les prévisions.
Les clients se tournent vers l'utilisation d'un modèle de logiciel en tant que service (SaaS) pour la livraison de solutions multi-locataires. Vous pouvez créer des applications SaaS avec une variété de modèles architecturaux différents pour répondre aux exigences réglementaires et de conformité. Selon le modèle SaaS, des ressources telles que Forecast sont partagées entre les locataires. L'accès aux données de prévision, la surveillance et la facturation doivent être pris en compte par locataire pour le déploiement de solutions SaaS.
Cet article explique comment utiliser Forecast dans une application SaaS multi-locataire à l'aide de Contrôle d'accès basé sur les attributs (ABAC) en Gestion des identités et des accès AWS (IAM) pour fournir ces fonctionnalités. ABAC est une approche puissante que vous pouvez utiliser pour isoler les ressources entre les locataires.
Dans cet article, nous fournissons des conseils sur la configuration des politiques IAM pour les locataires à l'aide des principes ABAC et des prévisions. Pour illustrer la configuration, nous avons configuré deux locataires, TenantA
et les TenantB
, et montrez un cas d'utilisation dans le contexte d'une application SaaS utilisant Forecast. Dans notre cas d'utilisation, TenantB
ne peut pas supprimer TenantA
ressources, et inversement. Le schéma suivant illustre notre architecture.
TenantA
et les TenantB
avoir des services exécutés en tant que microservice dans Service Amazon Elastic Kubernetes (Amazon EKS). L'application locataire utilise Forecast dans le cadre de son flux d'activité.
Prévoir l'ingestion de données
Forecast importe les données du locataire Service de stockage simple Amazon (Amazon S3) au compartiment S3 géré par Forecast. Les données peuvent être chiffrées en transit et au repos automatiquement à l'aide de clés gérées par Forecast ou de clés spécifiques au locataire via Service de gestion des clés AWS (AWS KMS). La clé spécifique au locataire peut être créée par l'application SaaS dans le cadre de l'intégration, ou le locataire peut fournir sa propre clé gérée par le client (CMK) à l'aide d'AWS KMS. La révocation de l'autorisation sur la clé spécifique au locataire empêche Forecast d'utiliser les données du locataire. Nous vous recommandons d'utiliser une clé spécifique au locataire et un rôle IAM par locataire dans un environnement SaaS multilocataire. Cela permet de sécuriser les données locataire par locataire.
Vue d'ensemble de la solution
Vous pouvez partitionner les données sur Amazon S3 pour séparer l'accès des locataires de différentes manières. Pour cet article, nous discutons de deux stratégies :
- Utiliser un compartiment S3 par locataire
- Utiliser un seul compartiment S3 et séparer les données des locataires avec un préfixe
Pour plus d'informations sur les différentes stratégies, consultez le Stockage de données multi-locataires sur Amazon S3 Repo GitHub.
Lorsque vous utilisez un compartiment par locataire, vous utilisez une stratégie IAM pour restreindre l'accès à un compartiment S3 de locataire donné. Par exemple:
Il existe une limite stricte au nombre de compartiments S3 par compte. Une stratégie multi-comptes doit être envisagée pour dépasser cette limite.
Dans notre deuxième option, les données des locataires sont séparées à l'aide d'un préfixe S3 dans un seul compartiment S3. Nous utilisons une stratégie IAM pour restreindre l'accès dans un préfixe de compartiment par locataire. Par exemple:
Pour cet article, nous utilisons la deuxième option consistant à attribuer des préfixes S3 dans un seul compartiment. Nous chiffrons les données des locataires à l'aide de CMK dans AWS KMS.
Intégration des locataires
Les applications SaaS s'appuient sur un modèle fluide pour introduire de nouveaux locataires dans leur environnement. Cela nécessite souvent l'orchestration de plusieurs composants pour provisionner et configurer avec succès tous les éléments nécessaires à la création d'un nouveau locataire. Ce processus, dans l'architecture SaaS, est appelé intégration des locataires. Cela peut être initié directement par les locataires ou dans le cadre d'un processus géré par le fournisseur. Le diagramme suivant illustre le flux de configuration de Forecast par locataire dans le cadre du processus d'intégration.
Les ressources sont étiquetées avec des informations sur les locataires. Pour cet article, nous étiquetons les ressources avec une valeur pour locataire, par exemple, tenant_a
.
Créer un rôle de prévision
Ce rôle IAM est assumé par Forecast par locataire. Vous devez appliquer la stratégie suivante pour autoriser Forecast à interagir avec Amazon S3 et AWS KMS dans le compte client. Le rôle est balisé avec la balise locataire. Par exemple, consultez le code suivant :
Créer les politiques
Dans cette étape suivante, nous créons des politiques pour notre rôle de prévision. Pour ce post, nous les avons scindés en deux politiques pour plus de lisibilité, mais vous pouvez les créer selon vos besoins.
Règle 1 : accès en lecture seule aux prévisions
La stratégie suivante accorde des privilèges pour décrire, répertorier et interroger les ressources Forecast. Cette stratégie limite Forecast à un accès en lecture seule. La condition de validation de balise de locataire dans le code suivant garantit que la valeur de la balise de locataire correspond à la balise de locataire du principal. Se référer au code en gras pour les détails.
Stratégie 2 : stratégie d'accès Amazon S3 et AWS KMS
La stratégie suivante accorde des privilèges à AWS KMS et l'accès au préfixe de locataire S3. La condition de validation de balise de locataire dans le code suivant garantit que la valeur de la balise de locataire correspond à la balise de locataire du principal. Se référer au code en gras pour les détails.
Créer une clé spécifique au locataire
Nous créons maintenant une clé spécifique au locataire dans AWS KMS par locataire et la balisons avec la valeur de la balise de locataire. Alternativement, le locataire peut apporter sa propre clé à AWS KMS. On donne les rôles précédents (Forecast_TenantA_Role
or Forecast_TenantB_Role
) accès à la clé spécifique au locataire.
Par exemple, la capture d'écran suivante montre la paire clé-valeur de tenant
et les tenant_a
.
La capture d'écran suivante montre les rôles IAM qui peuvent utiliser cette clé.
Créer un rôle d'application
Le deuxième rôle que nous créons est assumé par l'application SaaS par locataire. Vous devez appliquer la stratégie suivante pour permettre à l'application d'interagir avec Forecast, Amazon S3 et AWS KMS. Le rôle est balisé avec la balise locataire. Voir le code suivant :
Créer les politiques
Nous créons maintenant des stratégies pour le rôle d'application. Pour ce post, nous les avons scindés en deux politiques pour plus de lisibilité, mais vous pouvez les créer selon vos besoins.
Politique 1 : accès aux prévisions
La stratégie suivante accorde des privilèges pour créer, mettre à jour et supprimer des ressources Forecast. La stratégie applique l'exigence de balise lors de la création. De plus, il limite la list
, describe
et une delete
actions sur les ressources au locataire respectif. Cette politique a IAM PassRole
pour permettre à Forecast d'assumer le rôle.
Le tenant
La condition de validation de la balise dans le code suivant garantit que la valeur de la balise du locataire correspond au locataire. Se référer au code en gras pour les détails.
Stratégie 2 : Amazon S3, AWS KMS, Amazon CloudWatch et accès aux groupes de ressources
La stratégie suivante accorde des privilèges pour accéder aux ressources Amazon S3 et AWS KMS, ainsi que Amazon Cloud Watch. Il limite l'accès au préfixe S3 spécifique au locataire et à la clé CMK spécifique au locataire. La condition de validation du locataire est en code en gras.
Créer un groupe de ressources
Le groupe de ressources permet à toutes les ressources balisées d'être interrogées par le locataire. L'exemple de code suivant utilise le Interface de ligne de commande AWS (AWS CLI) pour créer un groupe de ressources pour TenantA
:
Prévoir le flux d'applications
Le diagramme suivant illustre notre flux d'application Forecast. Le service d'application assume le rôle IAM pour le locataire et, dans le cadre de son flux métier, appelle l'API Forecast.
Créer un prédicteur pour TenantB
Les ressources créées doivent être étiquetées avec l'étiquette de locataire. Le code suivant utilise l'API Python (Boto3) pour créer un prédicteur pour TenantB (reportez-vous au code en gras pour les détails):
Créer une prévision sur le prédicteur pour TenantB
Le code suivant utilise l'API Python (Boto3) pour créer une prévision sur le prédicteur que vous venez de créer :
Valider l'accès aux ressources Forecast
Dans cette section, nous confirmons que seul le locataire respectif peut accéder aux ressources Forecast. L'accès, la modification ou la suppression de ressources Forecast appartenant à un locataire différent génère une erreur. Le code suivant utilise l'API Python (Boto3) pour montrer que TenantA tente de supprimer une ressource TenantB Forecast :
Répertorier et surveiller les prédicteurs
L'exemple de code suivant utilise l'API Python (Boto3) pour interroger les prédicteurs de prévision pour TenantA à l'aide de groupes de ressources:
L' Framework AWS Well-Architected explique, il est important de surveiller les quotas de service (également appelés limites de service). Les prévisions ont des limites par compte ; pour plus d'informations, voir Lignes directrices et quotas.
Le code suivant est un exemple de remplissage d'une métrique CloudWatch avec le nombre total de prédicteurs :
Autres considérations
Les limites et la limitation des ressources doivent être gérées par l'application entre les locataires. Si vous ne pouvez pas accueillir le Limites des prévisions, vous devez envisager une configuration multicompte.
Les API de la liste des prévisions ou la réponse du groupe de ressources doivent être filtrées par application en fonction de la tenant
valeur de la balise.
Conclusion
Dans cet article, nous avons montré comment isoler l'accès aux prévisions à l'aide de la technique ABAC dans une application SaaS multi-tenant. Nous avons montré comment limiter l'accès à Forecast par locataire à l'aide de la balise de locataire. Vous pouvez personnaliser davantage les politiques en appliquant davantage de balises ou appliquer cette stratégie à d'autres services AWS.
Pour plus d'informations sur l'utilisation d'ABAC comme stratégie d'autorisation, voir Qu'est-ce qu'ABAC pour AWS?
À propos des auteurs
Günjan Garg est un ingénieur principal en développement logiciel au sein de l'équipe AWS Vertical AI. Dans son rôle actuel chez Amazon Forecast, elle se concentre sur les problèmes d'ingénierie et aime créer des systèmes évolutifs qui offrent le plus de valeur aux utilisateurs finaux. Dans son temps libre, elle aime jouer au sudoku et au dragueur de mines.
Matias Battaglia est responsable de compte technique chez Amazon Web Services. Dans son rôle actuel, il aime aider les clients à toutes les étapes de leur parcours vers le cloud. Pendant son temps libre, il aime construire des projets AI/ML.
Ramadas de Rakesh est un architecte de solutions ISV chez Amazon Web Services. Ses domaines d'intervention incluent l'IA / ML et le Big Data.
- accès
- Compte
- Action
- Supplémentaire
- AI
- Amazon
- Prévisions Amazon
- Amazon Web Services
- api
- Apis
- Application
- applications
- architecture
- autorisation
- AWS
- facturation
- construire
- Développement
- la performance des entreprises
- le cloud
- code
- conformité
- Courant
- Clients
- données
- accès aux données
- Décrypter
- page de livraison.
- Développement
- ingénieur
- ENGINEERING
- Environment
- flux
- Focus
- gratuitement ici
- GitHub
- Réservation de groupe
- Comment
- How To
- HTTPS
- IAM
- Identite
- Impact
- d'information
- IT
- ACTIVITES
- clés
- Kubernetes
- apprentissage
- Gamme
- Liste
- machine learning
- gestion
- ML
- modèle
- Stack monitoring
- Onboarding
- Option
- Autre
- politiques
- politique
- projets
- Python
- Exigences
- ressource
- Resources
- réponse
- REST
- pour le running
- SaaS.
- Série
- Services
- set
- mise
- commun
- étapes
- Logiciels
- développement de logiciels
- Solutions
- scission
- j'ai commencé
- Déclaration
- storage
- de Marketing
- Système
- Technique
- Technologie
- fiable
- transit
- Mises à jour
- utilisateurs
- Plus-value
- web
- services Web
- dans les