Aborder le cloud, c’est parler de beaucoup plus qu’une « simple » solution technique. C’est aussi et surtout s’attaquer à l’ensemble de nos flux de datas et d’informations. Il s’agit finalement de faire des choix de structuration et d’architecture de notre environnement. Dans une telle approche, les notions de permissions et sécurité deviennent des valeurs cardinales de tout système cloud.
Voici l’objet de cette communication : comment sécuriser un environnement cloud ?
Tous les grands items de sécurité sont représentés dans la matrice ‘Defense in Depth’ de Debra Shinder. (https://download.microsoft.com/download/1/6/0/160216AA-8445-480B-B60F-5C8EC8067FCA/WindowsAzure-SecurityPrivacyCompliance.pdf)
D’une manière concrète et pratique, je vous propose ici ma checklist de sécurité pour un abonnement Azure qui se concentre sur une partie de ces briques de sécurité.
Trusted Cloud: Microsoft Azure Security, Privacy, Compliance, Reliability/Resiliency, and Intellectual Property
1 — Sécuriser l’accès au portail Azure
Il est d’abord nécessaire de chercher à limiter ou à bloquer l’accès au portail et par extension aux API depuis internet (privilégier l’accès depuis le réseau interne) avec du conditional access par exemple.
Et on active le MFA.
Alex Weiner: “Your password doesn’t matter, but MFA does! Based on our studies, your account is more than 99.9% less likely to be compromised if you use MFA.”
2 — Segmenter les souscriptions par application et par type d’environnement (production/hors production)
On anticipe ainsi le point 9 🙂 mais pas seulement. Cette segmentation sera également très utile dans le cadre d’audit des logs.
https://docs.microsoft.com/en-us/azure/cost-management-billing/manage/create-subscription
3 — Ne pas autoriser les services non nécessaires
On n’active que les fournisseurs/services dont on a besoin et on s’assure d’avoir durci (voir point 11) les services que l’on va utiliser avant de les déployer.
4 — Utiliser private link
Pour l’accès aux services en particulier les services de data (base de données, …), on privilégiera ‘private link’, ‘vnet injection’ et ‘service endpoint’ quand ce dernier est supporté.
Si le design de votre application nécessite d’exposer un public endpoint, alors on va s’assurer de disposer de tous les items de sécurité nécessaires (Firewall, waf, NSG, …).
Il est nécessaire d’utiliser le service bastion pour se connecter aux vms si pas de possibilité de passer par une jumpbox on-prem.
On déploie une policy pour auditer ou enforcer le ‘deny’ des IP publiques sauf sur les app gateway ou les load balancers par exemple.
https://docs.microsoft.com/en-us/azure/private-link/private-link-overview
5 — Encryption at Rest et double encryption
Cette étape d’Encryption est de plus en plus proposée by design dans les services.
Quant à la double encryption, on va s’appuyer sur Azure policy pour s’assurer que toutes les options d’encryption disponibles pour les services sont bien mises en place.
https://docs.microsoft.com/en-us/azure/security/fundamentals/encryption-atrest
https://docs.microsoft.com/en-us/azure/security/fundamentals/double-encryption
6- HTTPS only
Pour faire simple, voici l’essentiel sur le sujet :
7 — Sécuriser les ressources compute
Il s’agit, à ce stade, d’utiliser des images OS/containers durcies, d’appliquer les updates de version, de mettre en place une gestion des vulnérabilités, de déployer des antivirus, antimalwares. Dans cette logique de sécurité, il est recommandé d’utiliser le just-in-time pour se connecter aux vms.
8 — Utiliser Privilège Identity Management + Just In Time
Ce choix a un coût mais contribue pleinement à la sécurisation du cloud. A minima, il s’agit ici de faire une revue des comptes dans l’Azure Active Directory.
9 — Utiliser les built-in role
‘Least privilege’ oui mais le RBAC Azure avec ces 120 built-in roles sans parler des permissions et des ‘customs roles’ peut nous faire prendre certains raccourcis…Dans ce cas, n’abusez pas du rôle contributeur et si cela doit être le cas, assurez vous de lui retirer certains droits, comme celui de modifier les ‘policies’ par exemple en créant … un ‘custom role’ 🙁 .
https://docs.microsoft.com/fr-fr/azure/role-based-access-control/
10 — Activer les activity logs et diagnostic logs sur plusieurs mois (limiter la rétention pour rester conforme RGPD) et les exporter en dehors du tenant.
Le mot d’ordre est la traçabilité en conservant les logs du control plane et du data plane.
On utilisera la fonctionnalité ‘daily cap’ pour maîtriser le volume si la facture s’avère trop conséquente.
https://docs.microsoft.com/en-us/azure/azure-monitor/platform/platform-logs-overview
11 — Deny ‘move’ de ressource
C’est pas parce que quelqu’un a les droits de le faire qu’on a envie qu’il le fasse.
On est dans l’approche de la mitigation du risque : ‘si … alors comment je limite le risque ou du moins comment je rends la chose moins aisée à réaliser …’
Le ‘deny move’ ici est un exemple, bloquer la fonctionnalité n’empêchera pas un ‘contributeur’ de la souscription de copier la ressource et de la coller ailleurs mais cela lui rendra la tâche plus compliquée.
Sans parler de framework de sécurité et d’analyse de risque, cette approche est efficace pour définir et mettre en œuvre le niveau de sécurité attendu pour chaque service utilisé.
Cela se traduira concrètement par le déploiement de policies qui vont auditer ou ‘enforcer’ des paramètres de sécurité ou l’utilisation de fonctionnalités.
12 — Utiliser les identités managées pour les ressources Azure
Anciennement nommé Managed Service Identity, c’est une identité système administrée automatiquement dans Azure AD.
Pour la gestion des secrets, on utilisera key vault.
https://docs.microsoft.com/fr-fr/azure/active-directory/managed-identities-azure-resources/overview
https://docs.microsoft.com/en-us/azure/key-vault/general/overview
13 — Activer le back-up
Sauvegarder vos données mais aussi votre code.
Nativement sur les bases de données en PaaS, la sauvegarde par défaut est de 7 jours. A mon sens, quand on ne fait pas d’exploitation en 24/7, 7 jours ce n’est pas suffisant.
Et comme le précise Microsoft dans la documentation, la sauvegarde est embarquée par le service donc pensez à sécuriser le service contre une suppression via un ‘lock’ par exemple ou faire un dump de votre base.
https://docs.microsoft.com/en-us/azure/backup/backup-architecture
14 — Utiliser soft delete
Attention à la compatibilité avec vos déploiements via Infra As Code mais très utile contre les ransomwares et autres menaces
https://docs.microsoft.com/en-us/azure/key-vault/general/soft-delete-overview
https://docs.microsoft.com/en-us/azure/storage/blobs/soft-delete-blob-overview
15 — N’autoriser la création de ressources que dans certaines régions
Conformité RGPD oblige.
Une built-in policy permet de faire cela simplement.
https://docs.microsoft.com/fr-fr/azure/governance/policy/samples/built-in-policies#general
16 — Privilégier les instances dédiées
Ne pas utiliser les plans de pricing proposant du share infra et en plus ils sont souvent sans SLA.
17 — Supprimer les ressources non utilisées
C’est plus facile de sécuriser quelque chose qui n’existe pas !
Au besoin, on redéploie, ce n’est que du code 🙂
18 — Utiliser Azure Policy
J’en parle depuis le début mais oui il faut déployer des policies pour contrôler son environnement.
Et comme on se laissera déborder par le mode ‘audit’, on privilégiera le mode ‘deny’.
https://docs.microsoft.com/en-us/azure/governance/policy/overview
19 — Déployer Sentinel
Vaste sujet mais oui il faut traiter les logs collectés sinon cela n’a que peu de sens en terme de réactivité.
https://docs.microsoft.com/fr-fr/azure/sentinel/overview
20 — Utiliser le Security Center
Avoir un tableau de bord “clean” dans le security center. C’est du ‘run sec’, contraignant, chronophage mais indispensable.
https://docs.microsoft.com/en-us/azure/security-center/security-center-introduction
21 — Utiliser Azure Monitor
En complément de la métrique, utile aussi pour faire le tracking des changements sur vos settings
https://docs.microsoft.com/en-us/azure/azure-monitor/overview“
22 — Déployer l’initiative ‘Azure Security Benchmark’ dans Azure Policy
Connaître ses faiblesses et surtout lister tous les items de sécurité non présentés dans cet article ….
https://docs.microsoft.com/en-us/azure/security/benchmarks/overview
Un autre lien avant de s’embarquer dans l’aventure : Azure Top 10 Security Best Practices
Tous ces points de sécurité n’ont un sens que s’ils sont intégrés dans une approche plus globale de la sécurité. Microsoft met en avant le Cloud Framework Adoption dans lequel on retrouve le process de sécurité qui consiste à partir de l’analyse de risque pour mettre en place des policies afin de gérer la compliance de notre environnement azure.
Cette approche fera très prochainement l’objet d’un meetup, suivez les news de Cloudreach France !
This post was originally available on Medium from 27/10/2020.
