Security by Design : la gestion des identités sur AWS

L’importance de la sécurité informatique s’est considérablement accrue ces dernières années : attaques de phishing, malware, ransomware ou vulnérabilité zero day… La montée en puissance de l’IA a également contribué à l’émergence de nouvelles attaques toujours plus sophistiquées (si les entreprises l’utilisent, pourquoi les hackers s’en priveraient-ils ?).

Le modèle de sécurité dit « château fort », historiquement utilisé dans votre propre datacenter n’est pas applicable lorsque vous construisez votre Landing Zone sur AWS.

Dans cette série d’article, nous vous partageons quelques services et bonnes pratiques de sécurité sur AWS. 

AWS et la sécurité

Si vous avez eu l’occasion de participer à un évènement AWS, vous aurez retenu que la sécurité est leur priorité absolue, et cela se démontre par le nombre croissant de services qu’AWS propose année après année, mois après mois, pour améliorer la sécurité des environnements AWS. 

Par défaut, tous les services AWS sont sécurisés (Security by design), mais chaque entreprise porte sa part de responsabilité lors de la mise en place et de l’utilisation.

Il s’agit en effet du modèle de responsabilité partagé. AWS est responsable de la sécurité du cloud, dans les accès aux infrastructures par exemple (même si on parle de cloud, les ressources restent hébergées dans des infrastructure physiques).

Chez AWS, on appelle cela les régions, les zones de disponibilités (AZ) et les emplacements périphériques (Edge Location).  

Enfin, il y a le stockage, les serveurs, le réseau… autant d’éléments physiques qui composent les fondations d’AWS et qui sont sous l’entière responsabilité d’AWS. 

En revanche, les systèmes d’exploitation (Windows / Linux), la configuration réseau (VLAN, règle par feu, antivirus…), les plateformes ou composants que vous utilisez (Java, Dotnet, Apache, Tomcat…), vos applications et leurs dépendances (log4net, log4j…) et leurs accès (Application, ftp, ssh, rdp…) sont de votre responsabilités. Vous êtes donc responsables de la sécurité dans le cloud ! 

D’une manière générale, il faut privilégier l’utilisation de services managés tels que S3, DynamoDB, rds etc. car cela minimisera l’impact sur votre responsabilité. 

Source : https://aws.amazon.com/fr/blogs/industries/applying-the-aws-shared-responsibility-model-to-your-gxp-solution/ 

Les services AWS : IAM, organisation… 

Lorsqu’on parle de sécurité, la gestion des identités et les contrôles d’accès sont l’une des premières étapes à prendre compte. Pour cela, AWS propose de nombreux services, en voici quelques exemples : 

• AWS Identity & Access Management 
• AWS IAM Identity Center (Anciennement AWS SSO) 
• AWS Organizations 

D’autres services sont également disponibles sur AWS mais ne seront pas décrits dans cet article : AWS Directory Service, Amazon Cognito, … 

AWS Organizations 

Peu importe la taille de votre entreprise (startup, PME, ETI, grand groupe) ou de son organisation (local, multinational, multi BU), il est fortement recommandé d’avoir plusieurs comptes AWS. 

Vous pourrez plus facilement cloisonner les accès au sein de votre organisation par domaine (Marketing, Communication, Production…) et par environnement (DEV, PRD, Sandbox…). 

Pour ce faire, le service AWS Organisation est là pour vous aider. 

L’objectif ici n’étant pas de définir les premières étapes de la construction (ou évolution) d’une Landing Zone, mais vous pourrez retrouver ci-dessous un exemple d’organisation avec plusieurs OU et comptes AWS : 

Le niveau le plus haut de cloisonnement sur AWS étant le compte, vous comprenez l’intérêt d’avoir une stratégie multi compte pour cloisonner au mieux vos environnements. 

AWS Organisation vous permettra ainsi de créer vos comptes, vos OU, et enfin, définir des règles sur l’ensemble de vos comptes via les SCP (Service Control Policies) 

Avant de vous décrire ce que sont les SCP, si vous n’êtes pas familiarisés avec AWS, une petite présentation d’IAM (Identity Access Management) est nécessaire. 

IAM – AWS Identity Access Management  

AWS Identity Access Management est le service de gestion des accès aux ressources AWS et d’identité, il permet à vos utilisateurs d’avoir accès aux ressources AWS (Console ou programmatique) mais également à vos applications. 

Sur la base du schéma, un utilisateur ou une application se voit attribuer un rôle, responsable de la sécurité des systèmes d’informations (RSSI) pour un utilisateur par exemple, qui lui donne un droit de visualisation sur vos ressources et le rapport d’audit via les politiques qui ont été accordées au rôle. De nombreuses politiques sont disponibles par défaut et mises à jour automatiquement par AWS : 

Si on prend l’exemple de la politique « ViewOnlyAccess », celle-ci permet un accès complet en lecture aux ressources AWS : 

Vous avez donc accès à toutes les ressources AWS, y compris les buckets S3 qui peuvent parfois contenir des informations que vous ne souhaitez pas partager, même au profil ViewOnlyAccess. 

Pour ce faire, si vous souhaitez interdire l’accès à certaines ressources, vous pouvez créer votre propre politique qui va interdire l’accès à ces ressources. 

La documentation AWS étant très riche, vous pourrez retrouver des exemples sur le site d’AWS : 

https://docs.aws.amazon.com/AmazonS3/latest/userguide/tagging-and-policies.html

Le premier niveau d’isolation étant le compte AWS, cette règle d’attribution et plus particulièrement d’interdiction s’applique unitairement sur l’ensemble de vos comptes. 

L’usage d’AWS Organisation avec une stratégie multi compte vous impose donc de dupliquer vos règles sur l’ensemble de vos comptes. 

C’est ainsi qu’AWS via les SCP a répondu à cette problématique. 

Politiques de contrôle de service (SCP) 

Les politiques de contrôle des services (SCP) s’appliquent au niveau de votre Organisation. 

Ils n’ont pas pour objectif d’attribuer des permissions mais au contraire, de les restreindre à l’ensemble de vos comptes AWS ou à quelques comptes. 

Quelques exemples de SCP régulièrement utilisées : 

• Désactiver les régions AWS que vous ne souhaitez pas utiliser 
• Limiter le type d’instance ec2, rds sur vos environnements bac à sable (Sandbox) 
• Interdire la désactivation de certains services : cloudtrail, vpc flowlogs…  
• Interdire l’usage de certains services 
• Interdire l’accès à certaines ressources 

Dans l’exemple précédent, la politique ViewOnlyAccess permet à vos utilisateurs (ou application) d’avoir un accès en lecture à toutes les ressources AWS. 

Si vous avez mis en place une SCP qui interdit certaines régions, même si des ressources sont présentes, vous n’aurez aucun accès ! 

AWS IAM Identity Center 

Comme décrit précédemment, IAM vous permet de gérer les accès aux ressources AWS pour vos applications, mais également vos utilisateurs. 

Vos environnement (AWS Account) AWS étant cloisonné, la gestion des accès doit se faire sur chaque compte ! 

Pour vous simplifier la tâche, le service AWS Identity Center (anciennement AWS SSO) va vous permettre de gérer et centraliser les accès depuis une interface unique : 

La gestion des identités et des accès sur AWS n’est plus un secret pour vous, si vous débutez sur AWS ou non, vous avez désormais connaissances des principaux services à utiliser. 

Enfin, nous avons rappelé à plusieurs reprises que les comptes AWS sont par défaut cloisonnées (responsabilité AWS), mais plusieurs méthodes permettent de les faire communiquer via les VPC, Rôle IAM entre compte, RAM… (responsabilité client).

Si vous avez apprécié cet article, les suivants sur le contrôle, la détection, la réponse sur incident devraient vous plaire !