Conception de l'unité d'exploitation : phase 1

Pour la société pharmaceutique multinationale, dans notre exemple, la conception initiale des organisations a suivi de AWS Organizations près les AWS recommandations de mise en place AWS Control Tower. OUs À titre d'exemple, consultez l'accélérateur de zone d'atterrissage activé AWS pour le secteur de la santé. AWS Control Tower a initialement fourni une structure d'unité d'organisation simple avec des bases communes OUs, comme décrit dans le billet de blog Best Practices for Organizational Units with AWS Organizations, y compris l'unité d'organisation de sécurité, l'unité d'organisation d'infrastructure de plate-forme et l'unité d'organisation spécifique à l'entreprise. OUs

Conception de l'architecture

Le schéma suivant montre l'architecture initiale de l'unité d'organisation.

UO de sécurité

L'UO de sécurité regroupe Comptes AWS de manière générale les fonctionnalités de sécurité et utilise deux comptes (Audit et Log Archive) pour stocker les données opérationnelles de sécurité afin de centraliser la journalisation et l'audit de l'accès à l'environnement. AWS services de sécurité de base tels qu'Amazon GuardDuty et AWS Security Hub résidant dans le compte d'audit.

Plateforme d'infrastructure OU

L'unité d'organisation de la plate-forme d'infrastructure regroupe des groupes Comptes AWS qui constituent la base de l'infrastructure. Les composants réseau centraux (passerelles, pare-feux, hub réseau central et services similaires) sont initialement déployés au sein de cette unité d'organisation. Comptes AWS  

Supplémentaire OUs

D'autres, spécifiques à l'entreprise OUs (comme une unité d'organisation clinique), renforcent les bases au OUs sein d'une hiérarchie de bas niveau. Les charges de travail sont mises en œuvre avec une structure multi-comptes et avec des environnements distincts au sein de celles-ci. OUs

Plusieurs considérations ont motivé cette conception initiale :

• Nested n' OUs était pas disponible à ce moment-là AWS Control Tower et nécessitait une personnalisation approfondie.

• Les charges de travail initiales destinées au cloud se concentraient sur des aspects particuliers de l'entreprise tels que les essais cliniques ou l'analyse des équipements de fabrication (vues fonctionnelles).

• L'entreprise fait la distinction entre cinq environnements de charge de travail (développement, validation, intégration, formation et production). L'entreprise avait besoin d'un terrain de jeu pour développer des applications sans la gouvernance stricte par les AWS contrôles qu'exigeaient les charges de travail de production. OUs Des développements tels que l'UO Manufacturing-Dev ont été assignés à cette fin.

• L'automatisation de la charge de travail faisait partie de l'écosystème de chaque application et ne nécessitait pas de séparation.

• Les processus de qualification de l'infrastructure (IQ) et de conformité aux normes GxP ne nécessitaient pas de distinction entre AWS les contrôles au niveau de l'UO.