Le concept principal du cloud AWS est basé sur la notion de VPC “Virtual Private Cloud”. Cette notion correspond littéralement à un groupement de datacenters géographiquement éloignés pour assurer une disponibilité maximale, nommé "Availability Zone". En répartissant vos "workloads" sur ces zones de disponibilité, même en cas de perte de l’une d'entre elles, vos systèmes peuvent continuer à fonctionner. Depuis 2006, AWS est une référence en terme de conception de ces datacenters.
Dans les années 80, lors du développement des services de datacenters “physiques”, la mise en oeuvre de procédures d’exploitation au sein même des datacenters s’est professionnalisée. Citons les normes ISO-27001 & HDS pour les données de santé à caractère personnel. Aujourd’hui, avec la facilité d’utilisation des clouds providers, un nouveau vent de professionnalisation est nécessaire. Au delà de toutes les nouvelles technologies de développement (serverless, containers, IA), la conception d’un SI basé sur une organisation de comptes AWS nécessite une réelle réflexion. C’est à ce moment que le terme de “Landing Zone” est apparue.
Comme maintenant tout est “apifié”, la construction des Landing Zones peuvent se comparer au développement d’une "application" qui va héberger les applicatifs de tout ou partie d’une entreprise. Certains choix de départ peuvent être assez structurants, à l’échelle de votre IT.
C’est avec toutes ces réflexions en tête que j’ai assisté à cette session “Best Practices” dispensée par Sam Elmalak, un "World Wide TechLeader" de chez AWS, dont voici la description :
Landing zone - Les grands principes
Rappelons-en les grands principes :
- Elle se base sur “AWS Organizations”.
- Un master account pour la gestion du paiement.
- Vous organisez vos comptes en créant une arborescence d’OU (Unité organisationnelle).
- Vous appliquez des SCP (Service Control Policy) vous permettant de brider certains services (interdire sur les plateformes de dev de créer des machines c5.12xlarge ou l’utilisation de disque SSD hautement performant !!).
- Au moins 1 compte “sécurité” : récupération de l’intégralité des logs CloudTrail pour les audits, gestion de vos clés de chiffrement et politiques de rotation.
- Au moins 1 compte “Shared” dans lequel vous installerez vos applications de monitoring, vos applications de qualimétrie (Sonar, Gatling, etc …), votre AMI Factory, votre Docker Factory etc ..., potentiellement votre CI/CD même s'il vaut mieux la mettre dans un compte séparé.
Avant d’illustrer ces propos, que risque-t-on à ne pas faire de landing zone ?
Rappelons que par défaut, un compte AWS est bridé avec un nombre important de "Service Limits", souvent de type "soft limit" (un case au support AWS sera alors nécessaire pour étendre cette limite) ou "hard limit". Citons 2 cas pour le domaine du "serverless" :
Concurrent executions : 1000 lambdas en parallèle. Si vous lancez par exemple, des lambdas de traitement de "petits fichiers" résultant du découpage d'un très gros fichier, vous pouvez atteindre facilement la limite de 1000. Ces aspects sont abordés en détail dans l'article de mon éminent collègue Fabien Roussel "AWS Re:Invent 2019 - Du monolithe au serverless, un voyage en plusieurs étapes"
Nb de lambda edge : 100. Ce nombre s'applique par instance de cloudFront.
Best Practices
Evidemment, AWS propose un outil pour mettre en place votre landing zone. Il en avait même deux : AWS Landing Zone & AWS Control Tower. Lors de ce re:invent, Sam Elmalak nous annonce que les 2 produits vont être fusionnés dans AWS Control Tower.
Services Control Policies (SCP)
- Permet de limiter l’accès aux API AWS (<=> les services).
- Les SCP sont invisibles pour tous les utilisateurs des comptes où elles s’appliquent, y compris pour le compte “root”.
- Les SCP sont appliquées pour tous les utilisateurs des comptes où elles s’appliquent, y compris pour le compte “root”.
- Les permissions manipulables dans les comptes où elles s’appliquent correspondront à l’intersection entre les permissions définies dans la SCP et les permissions IAM.
- Définir une SCP est totalement transparent pour les simulateurs de policy IAM.
Les SCP sont définissables via tous les outils "Infra As Code", Ci-joint un exemple en terraform, de la défintion d'une SCP permettant d'interdire des services sur les régions autres que celles vous souhaitez :
resource "aws_organizations_policy" "deny_services_unwanted_regions" {
name = "deny_services_unwanted_regions"
content = <<CONTENT
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "DenyAllOutsideEU",
"Effect": "Deny",
"NotAction": [
"iam:*",
"organizations:*",
"route53:*",
"budgets:*",
"waf:*",
"cloudfront:*",
"globalaccelerator:*",
"importexport:*",
"support:*"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:RequestedRegion": [
"eu-central-1",
"eu-west-1"
]
}
}
}
]
}
CONTENT
}OU (Organizational Units)
Master Account
- Pas de connexion Internet
- Pas de ressource déployée
- Contiendra vos OUs
- Définition des SCP applicables pour chacune de vos OUs
- Coût consolidé de vos consommations. Le tagging de vos ressources sera un élément essentiel pour répartir vos coûts au sein de votre SI.
- Accès Utilisateur Limité
Foundational OUs
Cette OU sera créée pour héberger les composants d’infrastructure et de sécurité sur lesquelles vos autres OUs se baseront. Cette OU contiendra les comptes suivants :
Archive Logs
Ce compte servira dans le cadre de vos audits. L’ensemble des logs d’accès à l’api AWS (CloudTrail) seront déversés ici. Remarquez l’activation de la protection “MFA delete”. Tout objet de ce compte ne pourra être supprimé qu’avec un double facteur d’authentification.
Security Accounts
Ici, 3 sortes de comptes différents :
“Read Only” : ce compte sera dédié aux "humains" à des fins de consultations, dédiés pour les audits.
- “Break Glass” : Alert on Login, Réponse dans le cas d’un incident. Ce compte ne devrait jamais être utilisé ! Ce compte sera également utilisé pour les activités de “Forensic” que les cellules sécurité peuvent avoir à faire lors de certaines attaques.
- “Tooling” : vos outils de sécurité & audit, Amazon Guard Duty, AWS Security Hub, AWS Config agrégation, Définition des “Cross Account Roles”.
Notons ici que n’a pas été abordé la notion de “compte de rebond”. Comme un bastion pour des infrastructures, le compte de rebond servira à vos “ops” à se connecter facilement dans l’intégralité des comptes nécessitant leur expertise.
Shared Services
Comme son nom l’indique, ce compte contiendra l’ensemble des composants communs de votre infrastructure, hors outils de sécurité. Pour information, les "Golden AMI" correspondent à vos images de référence pour vos machines, si vous n'êtes pas encore passés en "serverless" ou en "conteneurs" sur Fargate. Une "AMI Factory" vous sera nécessaire pour assurez des socles stables et patchés en terme de sécurité. De nombreux outils vous permettront de faire çà : AWS Golden AMI Pipeline, Packer couplé avec AWS Code Build ou Ansible.
Network Services
Ce compte hébergera vos connectivités réseau : AWS Direct connect, VPC Transit Gateway, shared VPCs etc ... Ici, ce seront vos ingénieurs réseaux qui maintiendront les différents composants déployés.
Additionnal OUs
Developer Sandbox
L’innovation est un message “fort” et martelé par AWS dans sa communication. Mettre en place des comptes “sandbox” permettant de tester et construire des pocs peut être un accélérateur de croissance phénoménal pour les entreprises.
Si un poc est viable, il pourra alors être déployé dans les comptes de workload “officiels” :
Workloads Dev, Preprod & Prod
Ces comptes serviront à héberger vos applications. On préférera séparer les environnements. Ici, il ne faut pas hésiter à déployer plusieurs comptes. Un compte par "entité" (entité, businessUnit, secteur, etc ...) est complètement envisageable. Le développement de certaines activités peuvent nécessiter un usage intense des lambdas, par exemple, et il serait dommage de pénaliser d'autres activités pour des raisons de "co-localisation" dans le même compte.
PolicyStaging OUs
La mise en oeuvre des SCPs et de leurs tests sera une activité à considérer comme telle dans votre plan de charge. Pour cela, une OU dédiée aux tests de policy sera nécessaire :
Suspended OUs
Les comptes AWS ne doivent pas être supprimés d’une organisation. On le déplace au sein de l’arborescence dans une OU dédiée.
Individual Business User OUs
Certaines entreprises peuvent nécessiter de créer des comptes AWS pour des utilisateurs “business”. Ceux-ci seront créés dans une OU dédiée :
Exception OUs
Malgré toute la préparation possible, les “exceptions” existent toujours. Si un cas se présente et qu’il ne peut pas logiquement se ranger dans les OUs précédemment créés, alors c’est qu’il faudra créer une OU pour ce genre de comptes :
Deployments OUs
Les systèmes de déploiement de vos applicatifs doivent être gérés séparément des comptes où les applications sont déployées. L’accès à ces comptes doit être sécurisé, notamment pour la production, car c’est le seul endroit où un utilisateur mal intentionné pourrait déployer du code malveillant sur vos systèmes.
Big Picture
Voici le diagramme des flux de logs de sécurité :
L’ensemble des logs de tous les comptes sont envoyés sur le compte d’archivage des logs.
Voici le diagramme des flux réseaux :
Les services AWS utilisables
Une synthèse de l’AWS Organizations :
Présentation AWS Control Tower
AWS Control Tower va s’occuper de générer automatiquement un certain nombre de comptes présentés précédemment :
- Compte de Sécurité “Tooling”
- Compte d’archivage des logs
Terminons par présenter la picture que couvre la Landing Zone :
Et maintenant on fait quoi ?
Sam Elmalak termine sa présentation en insistant sur le fait de ne pas multiplier les outils et de mettre en place un “standard”. Ce standard sera désormais géré par un service unique AWS : AWS Control Tower. Du coup, voici ses recommandations sur vos organisations existantes ou pour les nouveaux clients :
Si la génération d’une landing zone est maintenant automatisable, on peut également commencer à se poser la question si on peut avoir plusieurs landing zones. Voici quelques éléments de réflexion :
Et voici pour conclure quelques points importants que Sam Elmalak nous propose d’approfondir en consultant les guidelines disponibles sur le site AWS :
Conclusion
Personnellement, j'ai trouvé cette session la plus intéressante de toutes celles que j'ai pu voir durant cette semaine. Sam Elmalak a cité de nombreux exemples de cas rencontrés pendant sa vie de "AWS baroudeur". Sa présentation est en ligne ici.
Sam Elmalak a conclu sa présentation en nous annoncant que l’intégration de comptes déjà existants dans une organisation générée par Control Tower sera disponible très prochainement.
Pour conclure, quand on voit le nombre de comptes que peut contenir une Landing Zone dans le cas des grosses entreprises, on se rend bien compte qu'une réflexion globale sur les rôles est nécessaire. On privilégiera toujours des solutions utilisant des rôles et non des comptes IAM, beaucoup plus lourds à gérer.
