Dans l’IT classique, nous devons d’abord faire une différenciation entre la sécurité des infrastructures et la sécurité des applications, chez AWS, il revient au provider de gérer cette sécurité des infrastructures.
Le cloud computing permet de facilement adapter les produits à la demande, mais la sécurité de ces produits est critique et ne doit pas être négligée, pour ce faire les fournisseurs de cloud public proposent un panel d’outils assez complet que l’on peut exploiter.
En fonction de votre choix de provider, vous aurez plus ou moins de services IaaS (Infrastructure As A Service), PaaS (Platform As A Service) ou SaaS (Software As A Service).
(source : http://www.michaelulryck.com/les-modeles-de-service-du-cloud-saas-paas-iaas/)
-- “De toutes façons on va dans le cloud, la sécurité ce n’est plus de notre ressort” Architecte Anonyme --
La citation ci-dessus est bien évidemment fausse. Dans le cas d’AWS, la sécurité des infrastructures est assurée par le provider, mais la sécurité des services dans le cloud reste votre responsabilité.
(source : https://aws.amazon.com/fr/compliance/shared-responsibility-model/)
Chez AWS, vous êtes protégés quant à la maintenance des infrastructures, le patch management des services fournis, l’intégrité des services de stockage ainsi qu’une bande passante minimale assurée entre les différents datacenters et le web. Les niveaux de SLA de chaque service représentent une garantie et un contrat passé entre AWS et vous. Cela vous assure une disponibilité des services Amazon entre les différentes régions présentes dans son catalogue.
Amazon Web Services répond à de multiples certifications et standards de conformité, souvent nécessaires à la mise en place de systèmes critiques touchant aux informations personnelles et financières. Ces certifications assurent un niveau de maitrise des infrastructures intégrant gestion des risques, contrôle de l’environnement,... Ces standards permettent de garantir la confidentialité de vos données par rapport aux employés Amazon.
AWS propose pour chaque région un panel différent de standards adapté à la législation en vigueur (plus d’info ici).
Ce qui vous incombe est la sécurité des applications, la protection des données, la gestion de vos réseaux privés, l’accessibilité à vos services web ainsi que la gestion de vos utilisateurs. Il ne faut donc pas penser que le fait de passer par un provider plutôt que monter son infrastructure “on-premise” nous dispense de mettre en place les leviers permettant une sécurité efficace.
La responsabilité partagée nous oblige donc à appliquer des principes de base qui vont influencer l’architecture de notre nouvelle application. Ces composantes permettent une sécurité accrue et une meilleure gestion des risques.
Nous devons prendre en compte les flux de connexion entre notre système d’information actuel et le cloud, dans les deux sens de circulation, c’est un risque de plus dans le fonctionnement de nos applications vis-à-vis de l’IT traditionnelle.
Par défaut, tout flux doit être fermé, et dans le cas d’un environnement de développement potentiellement plus exposé, il faut faire attention aux flux inter-environnements pour limiter les risques de fuite d’informations de production. Par conséquent, on s’assure que tout flux ouvert fait l’objet d’un audit approfondi.
But : Empêcher l’entrée d’informations malveillantes et leur propagation, ainsi que la fuite d’informations via la compromission d’un système.
Services à utiliser :
AWS VPC, Security groups, Endpoint Services, Network ACLs, Route Tables, AWS WAF.
Dans le cadre des nouvelles lois sur le Règlement Général de la Protection des Données (RGPD), la protection des données est revenue au centre des considérations, il faut donc penser chiffrement.
Chiffrement oui, mais comment ? Il existe deux méthodes de chiffrement des fichiers, le chiffrement au repos qui protège la donnée stockée et le chiffrement en transit. On peut aller plus loin en appliquant un second chiffrement plus fin pour protéger les données sensibles. Par défaut, toute donnée doit être chiffrée.
De plus, il est recommandé d’utiliser le versionnement pour stocker la donnée avec, dans le meilleur des cas, une réplication entre différentes régions. Ces sécurités permettent de durcir la tolérance à la perte de données en cas de mauvaises manipulations.
But : Empêcher l’exploitation de données lors d’une fuite de données dûe à une intrusion.
Services à utiliser :
AWS KMS, Chiffrement des volumes EBS, Chiffrement des données sur S3, Chiffrement des EFS, Chiffrement des instances RDS, Chiffrement des tables DynamoDB, Chiffrement des clusters EMR côté serveur et en transit, Chiffrement des instances AWS Redshift, Chiffrement TLS/SSL en transit via AWS Certificate manager ou par l’import de certificats propriétaires, AWS S3 Cross-Region Replication, AWS S3 versionning, AWS S3 Glacier Vault-lock.
Tout chiffrement implique des clés de chiffrement/déchiffrement. Pour ce faire, une politique de gestion des secrets doit être appliquée. Cette procédure doit aussi s’appliquer aux systèmes d’authentification entre les briques applicatives, aux clés d’API, noms d’utilisateurs et mots de passe. Pour simplifier cette tâche, AWS propose des services qui gèrent cela par défaut ou en option.
La meilleure option est de stocker ces informations critiques dans un coffre-fort qui gère la rotation des clés d’accès ou ayant un contrôle IAM.
But : Eviter l’exfiltration de données d’accès aux systèmes et d’authentification.
Services à utiliser :
AWS KMS, AWS CloudHSM, AWS SSM Parameter store, AWS Secret Manager.
Pour permettre l’interconnexion entre les briques applicatives et l’accès à la plateforme AWS en elle-même, AWS IAM met à disposition un mécanisme de limitation d’accès et d’identité interne à AWS. Cette brique englobe aussi bien les accès des utilisateurs par groupe que les accès par application.
La gestion de ces politiques d’accès doit faire l’objet d’une revue avant attribution, par défaut, la politique de l’accès minimum est recommandé.
Par exemple, si on donne à un utilisateur le droit d’attacher un rôle IAM à un service, il faut spécifier la ressource en question dans la politique de droits; dans le cas contraire, il aura la capacité de s’attribuer lui-même le rôle administrateur et par conséquent modifier sa propre politique.
But : Empêcher toute altération de l’infrastructure en place, mauvaise manipulation ou action malveillante.
Dans le cas d’une entreprise avec un grand nombre d’utilisateurs, la gestion de ces politiques de droits peut vite s’avérer chaotique, AWS facilite la fédération des accès à leur plateforme en passant par l’Active Directory, ou via AWS Organization.
Services à utiliser :
AWS IAM, IAM groups, IAM roles, IAM policy, IAM permission boundaries, AWS SSO, AWS STS.
Pour permettre une auditabilité maximale, nous devons appliquer une forte catégorisation des ressources, une centralisation des logs techniques et applicatifs.
Pour la catégorisation, il est recommandé d’appliquer une nomenclature de nommage suffisamment explicite pour pouvoir effectuer un inventaire des services via leur nom. Ensuite, une politique de tags est nécessaire pour pouvoir plus facilement suivre la facturation de chaque service et pouvoir détecter toute montée en charge anormale.
Quand nous réfléchissons à la traçabilité des actions et des ressources, une fois les conventions de nommage appliquées, nous devons nous atteler à la centralisation de la donnée liée à ces actions. Un système d’ingestion, de stockage et d’interrogation doit être mis en place pour permettre un monitoring efficace.
Pour tracer efficacement les informations, deux composantes sont à prendre en compte, la traçabilité des applications qui nous permettent d’appréhender les erreurs et la traçabilité des mouvements réseaux (VPC et API). En conséquence, l’utilisation d’un SIEM (Security information and event management) est recommandé.
But : être maître des évènements et pouvoir justifier de toute activité sur la plateforme.
Services à utiliser :
AWS Cloudtrail, AWS Config, AWS VPC FlowLogs, AWS SNS, AWS Cloudwatch, AWS Elasticsearch.
Dans cet article nous avons brossé un aperçu des axes de réflexion autour de la sécurité dans le cloud AWS. Ces principes généraux doivent être adaptés à vos cas d’usage et à vos architectures.
Pour aller plus loin, nous pouvons penser à utiliser AWS Cognito, qui permet la délégation de la sécurité applicative et l’authentification des utilisateurs à cette brique permettant notamment de s’interfacer avec un Active Directory .
De plus, AWS propose aussi des systèmes d’audit large comme AWS TrustedAdvisor, qui permet d’avoir un overview rapide de l’état de la plateforme et AWS Inspector qui permet de scanner et détecter des failles de sécurité dans votre infrastucture ou vos applications.
Enfin, pour aller plus loin dans l’élaboration de votre plateforme, il est peut être intéressant de suivre le Framework Well-Architected, dédié à la sécurité dans le cloud AWS.