View a markdown version of this page

Stratégie de compte et de sécurité pour la plateforme de données sans serveur - Stratégie de compte et de sécurité pour la plateforme de données sans serveur

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Stratégie de compte et de sécurité pour la plateforme de données sans serveur

Date de publication : 21 décembre 2020 (Historique du diagramme)

Une stratégie multi-comptes constitue une bonne pratique pour isoler les ressources et la sécurité. Une architecture analytique exige une gouvernance des données assortie de normes de sécurité élevées. Vous devez accorder des niveaux d'accès corrects aux utilisateurs de plusieurs comptes.

Cette architecture montre comment organiser les AWS comptes pour une plateforme de données sans serveur. Il aborde la sécurité, la gouvernance et le contrôle d'accès dans tous les environnements.

Schéma de stratégie de compte et de sécurité

Multi-account architecture de sécurité pour une plate-forme de données sans serveur sur AWS.

Les étapes suivantes décrivent l'architecture :

  1. Le compte root est le compte le plus critique dans AWS. Appliquez des politiques d'accès restrictives pour protéger ce compte.

  2. Le compte de sécurité maintient la posture de sécurité globale. Utilisez-le pour rechercher les vulnérabilités de tous les comptes.

  3. Les connexions réseau centralisées depuis les locaux sont partagées avec d'autres comptes. Contrôlez la communication entre les comptes avec AWS Transit Gateway.

  4. Les utilisateurs interagissent avec les données et développent des modèles d'apprentissage automatique (ML) avec une sécurité et un accès aux données appropriés. Publiez les modèles finaux grâce à SageMaker l'IA.

  5. Des journaux centralisés surveillent tous les comptes pour auditer les activités. À utiliser CloudWatch pour une journalisation unifiée.

  6. Utilisez tous les outils dont vos clients ont besoin pour présenter leurs données. Il s'agit notamment d'outils ou de AWS services tiers tels que Quick.

  7. DevOps les flux déploient du code en tant que service et des artefacts sur les comptes d'ingestion et d'analyse.

  8. Les utilisateurs qui ont besoin de développer et de tester des modèles d'analyse travaillent avec une sécurité et une gouvernance des données appropriées.

  9. Les services de données centralisés assurent la gouvernance et la gestion des API. Exécutez des requêtes sur des pétaoctets de données dans Amazon S3 via Amazon Redshift Spectrum. Transformez les données avec Amazon EMR. Référentiels sécurisés avec Lake Formation.

  10. Contrôlez l'ingestion par lots ou par flux qui alimente le lac de données. Utilisez Kinesis pour diffuser des données en temps réel.

  11. Les services courants partagés avec d'autres comptes incluent les AMI Golden et la gestion du DNS.

Suggestions de lecture

Pour plus d'informations, consultez les ressources suivantes :

Historique du diagramme

Pour recevoir des mises à jour concernant ce schéma d'architecture de référence, abonnez-vous au fil RSS.

ModificationDescriptionDate

Publication initiale

Schéma d'architecture de référence publié pour la première fois.

21 décembre 2020

Obligation d'abonnement RSS

Pour vous abonner aux mises à jour RSS, un plug-in RSS doit être activé pour le navigateur que vous utilisez.