Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
DevSecOps, également appelé Secure DevOps, s’appuie sur la pratique de DevOps en incorporant la sécurité à différentes étapes d’un cycle de vie DevOps traditionnel. Créez une sécurité dans les pratiques DevOps pour :
Rendez vos applications et systèmes plus sécurisés, fournissez une visibilité sur les menaces de sécurité et empêchez les vulnérabilités d’atteindre les environnements déployés.
Augmentez la sensibilisation à la sécurité parmi vos équipes de développement et d’exploitation.
Incorporer des processus de sécurité automatisés dans votre cycle de vie de développement logiciel (SDLC).
Réduisez les coûts de correction en recherchant des problèmes de sécurité au début des phases de développement et de conception.
Lorsque vous appliquez DevSecOps à Azure Kubernetes Service (AKS), chaque rôle d’organisation a des considérations de sécurité spécifiques :
Les développeurs créent des applications sécurisées qui s’exécutent sur AKS.
Les ingénieurs cloud créent une infrastructure AKS sécurisée.
Les équipes d’opérations peuvent régir les clusters ou surveiller les problèmes de sécurité.
Cet article organise des conseils par phase de cycle de vie DevOps et fournit des recommandations pour les contrôles de sécurité et les meilleures pratiques. Il couvre les processus et outils courants pour les pipelines d’intégration continue et de livraison continue (CI/CD), avec un focus sur les outils intégrés.
Flux de processus
Téléchargez un fichier Visio de cette architecture.
Note
Cet article fait référence à AKS et GitHub, mais vous pouvez appliquer ces recommandations à n’importe quelle plateforme d’orchestration de conteneur ou CI/CD. Les détails de l’implémentation peuvent varier, mais la plupart des concepts et pratiques de chaque étape s’appliquent toujours.
Microsoft Entra ID est configuré en tant que fournisseur d’identité pour GitHub. Configurez l’authentification multifacteur (MFA) pour fournir une sécurité d’authentification supplémentaire.
Les développeurs utilisent Visual Studio Code ou Visual Studio avec des extensions de sécurité activées pour analyser de manière proactive leur code pour les vulnérabilités de sécurité.
Les développeurs valident le code d’application dans un dépôt GitHub Enterprise appartenant à l’entreprise et régi.
GitHub Enterprise intègre l’analyse automatique de la sécurité et des dépendances via GitHub Advanced Security.
Les pull requests déclenchent des builds d’intégration continue (CI) et des tests automatisés via GitHub Actions.
Le flux de travail de génération CI via GitHub Actions génère une image conteneur Docker et la stocke dans Azure Container Registry.
Vous pouvez ajouter des approbations manuelles pour les déploiements à des environnements spécifiques, tels que la production, dans le cadre du flux de travail de livraison continue (CD) dans GitHub Actions.
GitHub Actions active le CD vers AKS. Utilisez GitHub Advanced Security pour détecter les secrets, les informations d’identification et d’autres informations sensibles dans les fichiers source et de configuration de votre application.
Microsoft Defender analyse Container Registry, le cluster AKS et Azure Key Vault pour détecter les vulnérabilités de sécurité.
Microsoft Defender pour conteneurs analyse l’image conteneur pour détecter les vulnérabilités de sécurité connues lorsque GitHub Actions le charge dans Container Registry.
Defender pour conteneurs peut également analyser votre environnement AKS et fournir une protection contre les menaces d’exécution pour vos clusters AKS.
Microsoft Defender pour Key Vault détecte des tentatives inhabituelles et suspectes d’accès aux comptes de coffre de clés.
Vous pouvez appliquer Azure Policy à Container Registry et AKS pour appliquer la conformité des stratégies. Azure Policy inclut des stratégies de sécurité intégrées pour Container Registry et AKS.
Key Vault injecte en toute sécurité des secrets et des informations d’identification dans une application au moment de l’exécution sans les exposer aux développeurs.
Le moteur de stratégie réseau AKS est configuré pour sécuriser le trafic entre les pods d’application à l’aide de stratégies réseau Kubernetes. Nous vous recommandons Azure CNI propulsé par Cilium comme moteur de stratégie réseau. Il fournit une mise en œuvre étendue du filtre de paquets de Berkeley (eBPF), une politique de couche 7 et un filtrage complet des noms de domaine (FQDN).
Vous pouvez configurer la surveillance continue du cluster AKS à l’aide d’Azure Monitor pour collecter des métriques Prometheus, des journaux de conteneur et des événements Kubernetes. Utilisez des tableaux de bord Azure Managed Grafana pour la visualisation et Log Analytics pour les alertes basées sur des requêtes.
Azure Monitor collecte les mesures de performances via Managed Prometheus et les journaux d'application et de cluster via la collecte de journaux de conteneurs.
Un espace de travail Log Analytics stocke les journaux de diagnostic et d’application pour exécuter des requêtes de journal.
Utilisez Microsoft Sentinel comme gestion des informations et des événements de sécurité centralisée (SIEM) pour mettre en corrélation les données de télémétrie AKS avec les signaux de Microsoft Defender pour Cloud, Microsoft Entra ID et les ressources réseau. Microsoft Sentinel fournit une détection, une investigation et une réponse automatisée aux incidents de sécurité dans l’ensemble de l’environnement AKS.
Les outils open source tels que Zed Attack Proxy (ZAP) peuvent effectuer des tests de pénétration pour les applications et services web.
Defender pour DevOps, un service disponible dans Defender pour cloud, permet aux équipes de sécurité de gérer la sécurité DevOps dans les environnements multipipeline, notamment GitHub et Azure DevOps.
Vue d’ensemble et responsabilités des membres de l’équipe
Envisagez de gérer la complexité de DevSecOps sur les déploiements de solutions basées sur Kubernetes en divisant les responsabilités entre les équipes. Cette section décrit les rôles et responsabilités des développeurs, des opérateurs d’application tels que des ingénieurs de fiabilité de site, des opérateurs de cluster et des équipes de sécurité.
Developers
Les développeurs écrivent le code de l’application et le valident dans le référentiel désigné. Ils créent et exécutent des scripts pour les tests automatisés afin de s’assurer que leur code fonctionne comme prévu et s’intègre au reste de l’application. Les développeurs définissent et scriptent également la génération d’images conteneur dans le cadre du pipeline d’automatisation.
Opérateurs d’application (ingénieurs de fiabilité de site)
La création d’applications à l’aide de conteneurs et kubernetes peut simplifier le développement, le déploiement et l’extensibilité des applications. Mais ces approches de développement créent également des environnements de plus en plus distribués qui compliquent l’administration.
Les ingénieurs de fiabilité du site créent des solutions qui automatisent la façon dont les équipes supervisent les systèmes logiciels volumineux. Ils servent de pont entre les équipes de développement et d’opérateur de cluster. Ils aident à établir et à surveiller les objectifs de niveau de service (SLA) et les budgets d’erreur. Les ingénieurs de fiabilité de site aident également à gérer les déploiements d’applications et à écrire des fichiers yaML (Kubernetes Manifest).
Opérateurs de cluster
Les opérateurs de cluster configurent et gèrent l’infrastructure de cluster. Ils utilisent souvent les meilleures pratiques et cadres d'Infrastructure en tant que Code (IaC) tels que GitOps pour approvisionner et maintenir leurs clusters. Ils utilisent des outils de supervision tels que le service managé Azure Monitor pour Prometheus et Azure Managed Grafana pour surveiller l’intégrité globale du cluster. Ils sont responsables de la mise à jour corrective, des mises à niveau de cluster, des autorisations et du contrôle d’accès en fonction du rôle (RBAC) sur le cluster. Dans les équipes DevSecOps, les opérateurs de cluster collaborent avec des équipes de sécurité pour établir des normes de sécurité et garantir que les clusters répondent à ces exigences.
Équipe de sécurité
L’équipe de sécurité développe et applique des normes de sécurité. Certaines équipes peuvent créer et sélectionner des définitions Azure Policy que vous appliquez dans les abonnements et les groupes de ressources qui contiennent les clusters. Les équipes de sécurité surveillent les problèmes de sécurité et collaborent avec d’autres équipes pour hiérarchiser la sécurité tout au long du processus DevSecOps.
Phases de cycle de vie DevSecOps
Chaque phase du SDLC implémente des contrôles de sécurité. Ces contrôles de sécurité sont centraux pour les pratiques DevSecOps et shift-left.
Téléchargez un fichier Visio de cette architecture.
Phase de planification
La phase de plan a généralement la moindre quantité d’automatisation, mais elle a des implications importantes en matière de sécurité qui affectent les phases ultérieures du cycle de vie DevOps. Cette phase implique la collaboration entre les équipes de sécurité, de développement et d’exploitation. Pour vous assurer que vous devez prendre en compte ou atténuer les exigences de sécurité et les problèmes de sécurité, incluez les parties prenantes de la sécurité dans cette phase.
Bonne pratique : Concevoir une plateforme d’application sécurisée
Pour créer une charge de travail hébergée par AKS sécurisée, vous devez incorporer la sécurité dans le système à chaque couche, en commençant par la plateforme elle-même. La plateforme peut inclure des composants internes au cluster, tels que des agents de sécurité et de stratégie d’exécution, ainsi que des composants externes à AKS, tels que des pare-feu réseau et des registres de conteneurs.
Bonne pratique : Créer une modélisation des menaces dans votre processus
La modélisation des menaces est généralement une activité manuelle qui implique des équipes de sécurité et de développement. Vous pouvez modéliser et rechercher des menaces dans un système pour résoudre les vulnérabilités avant de développer du code ou d’apporter des modifications. Teams effectue une modélisation des menaces en réponse aux modifications logicielles importantes, aux modifications architecturales de solution ou aux incidents de sécurité.
Nous recommandons le modèle de menace STRIDE. Cette méthodologie commence par un diagramme de flux de données et catégorise les menaces à l’aide du mnémonique STRIDE : usurpation, falsification, répudiation, divulgation d’informations, déni de service et élévation de privilèges. Les équipes utilisent ces catégories pour identifier, atténuer et valider les risques. Un outil de modélisation permet de noter et de visualiser les composants système, les flux de données et les limites de sécurité.
La création de la modélisation des menaces dans votre SDLC ajoute une surcharge de processus et vous oblige à maintenir les modèles de menace mis à jour. Toutefois, il traite de la sécurité dès le début du développement, ce qui réduit le coût de la résolution des problèmes découverts ultérieurement.
Bonne pratique : Appliquer Azure Well-Architected Framework
Appliquez les meilleures pratiques de sécurité qui fournissent des conseils pour la gestion des identités, la sécurité des applications, la protection de l’infrastructure, la sécurité des données et DevOps, car elles s’appliquent aux environnements natifs cloud.
Appliquez les meilleures pratiques d’excellence opérationnelle , car elle s’applique à DevSecOps et à la surveillance de vos environnements de production.
Phase de développement
Le déplacement vers la gauche est un élément clé de l’état d’esprit DevSecOps. Ce processus commence avant de valider le code dans un référentiel et de le déployer via un pipeline. Pour résoudre les problèmes de sécurité plus tôt dans le cycle de vie du développement, adoptez les meilleures pratiques de codage sécurisées et utilisez les outils et plug-ins de l’environnement de développement intégré (IDE) pour l’analyse du code pendant la phase de développement.
Bonne pratique : Appliquer des normes de codage sécurisées
Utilisez des bonnes pratiques et des listes de contrôle de codage sécurisées établies pour protéger votre code contre les vulnérabilités courantes telles que l’injection et la conception non sécurisée. La fondation Open Worldwide Application Security Project (OWASP) publie des recommandations de codage sécurisées standard du secteur que vous devez adopter lorsque vous écrivez du code. Ces instructions sont particulièrement importantes lorsque vous développez des applications ou des services web accessibles au public.
Passez en revue les pratiques de codage sécurisées pour vos runtimes de langage de programmation spécifiques, tels que Java et .NET.
Appliquez des normes de journalisation pour protéger les informations sensibles contre la fuite dans les journaux d’application. Les infrastructures de journalisation les plus populaires, comme Apache Log4j et Apache log4net, fournissent des filtres et des plug-ins pour masquer les informations sensibles, telles que les numéros de compte ou les données personnelles.
Bonne pratique : utiliser des outils et des plug-ins IDE pour automatiser les vérifications de sécurité
Les IDE les plus populaires, comme Visual Studio, VS Code, IntelliJ IDEA et Eclipse, prennent en charge les extensions que vous pouvez utiliser pour obtenir des commentaires immédiats et des recommandations pour les problèmes de sécurité potentiels que vous introduisez pendant l’écriture de code d’application.
SonarQube pour IDE est un plug-in IDE pour les langages et les environnements de développement les plus populaires. SonarQube pour IDE fournit des commentaires et analyse automatiquement votre code pour détecter les erreurs de programmation courantes et les problèmes de sécurité potentiels.
D’autres plug-ins gratuits et commerciaux se concentrent sur des éléments spécifiques à la sécurité, comme les 10 principales vulnérabilités courantes d’OWASP. Le plug-in Snyk analyse également votre source d’application et vos dépendances externes et vous avertit s’il détecte des vulnérabilités.
Le plug-in SARIF (Static Analysis Results Interchange Format) pour Visual Studio et VS Code vous permet d’afficher facilement les vulnérabilités provenant d’outils SAST (Static Application Security Testing) populaires et d’interpréter les résultats à partir de fichiers de sortie JSON bruts.
Bonne pratique : Établir des contrôles sur vos référentiels de code source
Établissez une méthodologie de branchement pour la cohérence au sein de votre entreprise. Les méthodologies telles que le flux de mise en production et le flux GitHub ont des instructions structurées sur la façon d’utiliser des branches pour prendre en charge l’équipe et le développement parallèle. Ces méthodologies peuvent aider les équipes à établir des normes et des contrôles pour les validations de code et les fusions dans votre flux de travail CI/CD.
Certaines branches, telles que principale, sont des branches durables qui préservent l’intégrité du code source de votre application. Établissez des stratégies de fusion pour ces branches avant de valider ou de fusionner les modifications. Par exemple, vous pouvez :
Empêchez d’autres développeurs de valider du code directement dans votre branche principale.
Établissez un processus de révision par les pairs et exigez un nombre minimal d’approbations avant de fusionner les modifications dans la branche principale. Configurez et appliquez ces contrôles à l’aide de GitHub. Utilisez GitHub pour désigner des groupes d’approbateurs autorisés si nécessaire pour les environnements contrôlé.
Utilisez des hooks de précommit pour vérifier la présence d'informations sensibles dans le code source de votre application et bloquer les validations lorsqu’elles détectent des problèmes de sécurité.
- Utilisez des hooks précommit intégrés fournis par GitHub. Configurez-les facilement pour des projets spécifiques. Par exemple, certains hooks prédéfinis analysent les secrets, les clés privées et les informations d’identification et bloquent une validation s’ils trouvent ces problèmes.
Établissez RBAC dans votre système de contrôle de version.
Créez des rôles bien définis à l’aide du principe du privilège minimum. Un pipeline CI/CD fonctionne comme votre chaîne logistique pour les déploiements de production.
Appliquez des rôles d’utilisateur ou de groupe établis au sein de votre organisation. Pour regrouper des personnes en fonction de leur rôle et fonction spécifiques dans vos flux de travail CI/CD, créez des rôles tels que l’administrateur, le développeur, l’administrateur de sécurité et l’opérateur.
Activez l’audit de vos flux de travail pour ajouter la transparence et la traçabilité pour la configuration et d’autres modifications apportées à vos pipelines CI/CD.
Bonne pratique : Sécuriser vos images de conteneurs
Utilisez des images légères qui ont une empreinte minimale du système d’exploitation pour réduire la surface d’attaque globale. Considérez des images minimales comme Alpine ou des images sans distribution qui contiennent uniquement votre application et son runtime associé.
Utilisez uniquement les images de base approuvées lorsque vous générez vos conteneurs. Récupérez ces images de base à partir d’un registre privé que vous analysez fréquemment pour détecter les vulnérabilités.
Utilisez les outils de développement pour évaluer les vulnérabilités d’image localement. Trivy est un outil open source qui analyse les vulnérabilités de sécurité au sein de vos images conteneur.
Interdire l’accès de l'utilisateur root ou le contexte pour une image. Par défaut, les conteneurs s’exécutent en tant que superutilisateur.
Pour les conteneurs qui ont besoin d’une sécurité renforcée, envisagez d’utiliser un profil AppArmor ou seccomp au sein de votre cluster Kubernetes pour renforcer la sécurité de vos conteneurs en cours d’exécution.
Phase de compilation
Au cours de la phase de génération, les développeurs travaillent avec des ingénieurs de fiabilité de site et des équipes de sécurité pour intégrer des analyses automatisées de leur source d’application dans leurs pipelines de build CI. Teams configure les pipelines pour activer les pratiques de sécurité à l’aide des outils et extensions de sécurité de la plateforme CI/CD. Ces pratiques incluent SAST, l’analyse de composition logicielle (SCA) et l’analyse des secrets.
Bonne pratique : effectuer saST pour rechercher des vulnérabilités potentielles dans le code source de votre application
Utilisez GitHub fonctionnalités d’analyse avancée de sécurité pour l’analyse du code et CodeQL.
L’analyse du code est une fonctionnalité qui analyse le code dans un référentiel GitHub pour rechercher des vulnérabilités de sécurité et des erreurs de codage. Il affiche les problèmes dans GitHub Enterprise Cloud.
Si l’analyse du code détecte une vulnérabilité ou une erreur potentielle dans votre code, GitHub affiche une alerte dans le référentiel.
Vous pouvez configurer des règles de branche pour les vérifications d’état requises. Par exemple, vous pouvez exiger que les branches de fonctionnalités soient à jour avec la branche de base avant de fusionner le nouveau code. Cette exigence garantit que vous testez votre branche avec le code le plus récent.
Activez Copilot Autofix pour recevoir des suggestions de correctif générés par l’IA pour les alertes d’analyse du code. Copilot Autofix propose une correction directement dans les demandes de fusion, ce qui permet aux développeurs de résoudre rapidement les problèmes de sécurité.
Utilisez des outils tels que kube-score pour analyser vos objets de déploiement Kubernetes. Cet outil effectue une analyse statique du code de vos définitions d’objets Kubernetes. Il génère une liste de recommandations pour rendre votre application plus sécurisée et résiliente.
Bonne pratique : utiliser l'analyse de sécurité des secrets pour détecter les secrets commis accidentellement
Lorsque vous activez l’analyse des secrets pour un référentiel, GitHub analyse le code des modèles qui correspondent aux secrets utilisés par de nombreux fournisseurs de services.
GitHub exécute régulièrement une analyse complète de l’historique Git du contenu existant dans les référentiels et envoie des notifications d’alerte.
Pour Azure DevOps, Defender pour Cloud utilise l’analyse des secrets pour détecter les informations d’identification, les secrets, les certificats et d’autres contenus sensibles dans votre code source et générer la sortie.
Vous pouvez exécuter un scan de secrets dans le cadre de l’extension Microsoft Security DevOps pour Azure DevOps.
Bonne pratique : Utiliser les outils SCA pour suivre les composants open source dans le codebase et détecter les vulnérabilités dans les dépendances
La révision des dépendances vous permet d’intercepter les dépendances non sécurisées avant de les introduire dans votre environnement. Il fournit également des informations sur la licence, les dépendants et l’âge des dépendances. Il affiche les modifications de dépendance par le biais d’un diff enrichi sous l’onglet Fichiers modifiés d’une pull request.
Dependabot effectue une analyse pour détecter les dépendances non sécurisées et envoie des alertes Dependabot lorsqu’un nouvel avis est ajouté à la base de données de conseil GitHub ou lorsque le graphique de dépendances pour un référentiel change.
Bonne pratique : Générer un SBOM pour vos images conteneur
Une liste de matériaux logiciels (SBOM) fournit un inventaire complet des composants, bibliothèques et dépendances qui composent vos images de conteneur. Utilisez des outils de génération SBOM comme Microsoft sbom-tool ou Syft pendant la build CI pour produire un manifeste SPDX ou CycloneDX.
Attachez un SBOM à vos images conteneur stockées dans Container Registry pour permettre l’analyse des vulnérabilités en aval et le suivi de la conformité des licences dans toute la chaîne d’approvisionnement.
Bonne pratique : analyser les modèles IaC pour détecter des configurations incorrectes avant le déploiement
Surveillez de manière proactive les configurations de ressources cloud tout au long du cycle de vie du développement.
Microsoft Defender pour DevOps prend en charge les référentiels GitHub et Azure DevOps et peut analyser les modèles IaC pour identifier les vulnérabilités IaC.
Bonne pratique : analyser vos images de charge de travail dans les registres de conteneurs pour identifier les vulnérabilités connues
Defender pour conteneurs analyse les conteneurs dans Container Registry et Amazon Elastic Container Registry (ERC) pour vous avertir des vulnérabilités connues dans vos images.
Vous pouvez activer Azure Policy pour effectuer une évaluation des vulnérabilités sur les images stockées dans Container Registry et fournir des informations détaillées sur chaque recherche.
Bonne pratique : Créer automatiquement de nouvelles images sur les mises à jour des images de base
- Container Registry Tasks découvre dynamiquement les dépendances d’image de base lorsqu’elle génère une image conteneur. Lorsqu’elle détecte une mise à jour de l’image de base d’une image d’application, vous pouvez configurer une tâche de génération pour reconstruire automatiquement les images d’application qui font référence à cette image de base.
Bonne pratique : Utiliser Container Registry, Key Vault et la notation pour signer numériquement vos images conteneur et configurer le cluster AKS pour autoriser uniquement les images validées
Key Vault stocke les clés de signature utilisées par l’outil de notation . Le plug-in Key Vault de notation (azure-kv) accède à ces clés pour signer et vérifier les images de conteneur et d'autres artefacts. Vous pouvez attacher ces signatures aux images Container Registry à l’aide des commandes Azure CLI.
Les conteneurs signés garantissent que les déploiements proviennent d’une source approuvée et que les artefacts ne sont pas falsifiés après la création. L’artefact signé garantit l’intégrité et l’authenticité avant que l’utilisateur extrait un artefact dans n’importe quel environnement, ce qui permet d’éviter les attaques.
- Ratifie vérifie les métadonnées de sécurité des artefacts et applique des stratégies d’admission avant le déploiement sur des clusters Kubernetes. L’intégrité de l’image AKS utilise Ratify en tant que vérificateur intégré pour valider les signatures d’image et les attestations SBOM avant que les pods ne soient admis dans le cluster.
Phase de déploiement
Pendant la phase de déploiement, les développeurs, les opérateurs d’application et les équipes d’opérateurs de cluster travaillent ensemble pour établir les contrôles de sécurité appropriés pour les pipelines CD. Ces contrôles aident à déployer du code dans un environnement de production de manière sécurisée et automatisée.
Bonne pratique : contrôler l’accès et le flux de travail du pipeline de déploiement
Vous pouvez protéger les branches importantes en définissant des règles de protection de branche. Ces règles définissent si les collaborateurs peuvent supprimer ou pousser de force vers la branche. Ils définissent également les conditions requises pour les envois (push) vers la branche, telles que le passage de vérifications d’état ou un historique de validation linéaire.
Utilisez des environnements de déploiement pour configurer les règles de protection et gérer les secrets.
Utilisez les fonctionnalités approbations et gates pour contrôler le flux de travail du pipeline de déploiement. Par exemple, vous pouvez exiger des approbations manuelles d’une équipe de sécurité ou d’exploitation avant de déployer dans un environnement de production.
Bonne pratique : Sécuriser les informations d’identification de déploiement
OpenID Connect (OIDC) permet à vos flux de travail GitHub Action d’accéder aux ressources dans Azure sans avoir à stocker les informations d’identification Azure comme secrets GitHub de longue durée.
Utilisez une approche basée sur extraction pour CI/CD avec GitOps pour déplacer les informations d’identification de sécurité vers votre cluster Kubernetes. Cette approche réduit la surface de sécurité et de risque en supprimant les informations d’identification de vos outils CI externes. Vous pouvez également réduire les connexions entrantes autorisées et limiter l’accès au niveau de l’administrateur à vos clusters Kubernetes.
Bonne pratique : Exécuter DAST pour rechercher des vulnérabilités dans votre application en cours d’exécution
Utilisez GitHub Actions dans les flux de travail de déploiement pour exécuter des tests de test de sécurité des applications dynamiques (DAST).
Utilisez des outils open source tels que ZAP pour effectuer des tests d’intrusion pour les vulnérabilités courantes des applications web.
Bonne pratique : déployer des images conteneur à partir de registres approuvés uniquement
Utilisez Defender pour conteneurs pour activer le module complémentaire Azure Policy pour Kubernetes.
Configurez Azure Policy pour Kubernetes afin de restreindre les déploiements d’images conteneur aux registres approuvés.
Phase d’exploitation
Au cours de cette phase, effectuez des tâches de surveillance des opérations et de surveillance de la sécurité pour surveiller, analyser et alerter de manière proactive sur les incidents de sécurité potentiels. Utilisez des outils d’observabilité de production comme Azure Monitor et Microsoft Sentinel pour surveiller et garantir la conformité aux normes de sécurité d’entreprise.
Bonne pratique : Utiliser Defender pour Cloud pour analyser et surveiller automatiquement vos configurations de production
Exécutez une analyse continue pour détecter la dérive dans l’état de vulnérabilité de votre application et implémentez un processus pour corriger et remplacer les images vulnérables.
Implémentez la surveillance de la configuration automatisée pour les systèmes d’exploitation.
Utilisez les recommandations de conteneur dans Defender pour cloud (sous Calcul et applications) pour effectuer des analyses de référence pour vos clusters AKS. Defender pour Cloud affiche des problèmes de configuration ou des vulnérabilités dans son tableau de bord.
Utilisez Defender pour cloud et suivez ses recommandations de protection réseau pour sécuriser les ressources réseau de votre cluster AKS.
Effectuez une évaluation des vulnérabilités pour les images stockées dans Container Registry.
- Implémentez des analyses continues pour les images en cours d'exécution dans Container Registry en activant Defender for Containers.
Bonne pratique : Maintenir vos clusters Kubernetes mis à jour
Kubernetes publie fréquemment de nouvelles versions. Conservez une stratégie de gestion du cycle de vie pour que vos clusters restent pris en charge et up-to-date. AKS fournit des outils pour gérer les mises à niveau de cluster. Utilisez les fonctionnalités de maintenance planifiée AKS pour contrôler le moment où des fenêtres de maintenance et des mises à niveau se produisent.
Mettez à jour les nœuds worker AKS fréquemment. Azure publie des mises à jour hebdomadaires du système d’exploitation et du runtime. Appliquez ces mises à jour automatiquement en mode sans assistance ou manuellement via Azure CLI pour plus de contrôle.
Bonne pratique : Utiliser Azure Policy pour sécuriser et régir vos clusters AKS
Après avoir installé le module complémentaire Azure Policy pour AKS, vous pouvez appliquer des définitions de stratégie individuelles ou des groupes de définitions de stratégie, appelés initiatives ou ensembles de stratégies, à votre cluster.
Utilisez des stratégies Azure intégrées pour des scénarios courants, comme empêcher les conteneurs privilégiés d’exécuter ou de restreindre les adresses IP externes à une liste verte. Vous pouvez également créer des stratégies personnalisées pour des cas d’usage spécifiques.
Appliquez des définitions de stratégie à votre cluster et vérifiez qu’Azure Policy applique ces affectations.
Utilisez Gatekeeper pour configurer un contrôleur d’admission qui autorise ou refuse les déploiements en fonction des règles spécifiées. Azure Policy étend Gatekeeper.
Sécuriser le trafic entre les pods de charge de travail à l’aide de stratégies réseau dans AKS.
- Utilisez Azure CNI optimisé par Cilium comme moteur de stratégie réseau. Cilium utilise un plan de données basé sur eBPF et prend en charge les stratégies natives Kubernetes, la stratégie de couche 7 et le filtrage FQDN.
Bonne pratique : Utiliser Azure Monitor pour la surveillance et les alertes continues
Utilisez Azure Monitor pour collecter des logs et des métriques à partir d’AKS. Collectez les métriques Prometheus via le service géré Azure Monitor pour Prometheus, consultez les journaux de conteneur et de plateforme dans Log Analytics, et visualisez l’intégrité du cluster via les tableaux de bord Azure Managed Grafana.
Azure Monitor étend la surveillance continue aux pipelines de mise en production. Utilisez les données de surveillance pour approuver ou annuler des versions. Azure Monitor ingère également les journaux de sécurité et les alertes sur les activités suspectes.
Intégrez vos instances AKS à Azure Monitor et configurez les paramètres de diagnostic pour votre cluster.
Pour plus d’informations, consultez la base de référence de sécurité Azure pour AKS.
Bonne pratique : Utiliser Defender pour cloud pour la surveillance active des menaces
Defender pour Cloud fournit une surveillance active des menaces pour AKS au niveau du nœud (menaces de machine virtuelle) et des charges de travail de cluster.
Utilisez Defender pour DevOps pour obtenir une visibilité complète sur tous les pipelines CI/CD. Il fournit aux équipes de sécurité et d’opérateur un tableau de bord centralisé. Vous bénéficiez en particulier de cette visibilité centralisée lorsque vous utilisez plusieurs plateformes de pipeline comme Azure DevOps et GitHub ou exécutez des pipelines dans des clouds publics.
Defender pour Key Vault détecte des tentatives inhabituelles et suspectes d’accès aux comptes de coffre de clés et peut envoyer des alertes aux administrateurs en fonction de la configuration.
Defender pour conteneurs peut alerter sur les vulnérabilités trouvées dans vos images conteneur stockées dans Container Registry.
Bonne pratique : activer la surveillance centralisée des journaux et utiliser des produits SIEM pour surveiller les menaces de sécurité en temps réel
- Connectez les journaux de diagnostic AKS à Microsoft Sentinel pour la surveillance centralisée de la sécurité en fonction des modèles et des règles. Microsoft Sentinel permet cet accès via des connecteurs de données.
Bonne pratique : activer la journalisation d’audit pour surveiller l’activité sur vos clusters de production
Utilisez les journaux d’activité pour surveiller les actions sur les ressources AKS pour afficher toutes les activités et leur état. Déterminez qui a effectué les opérations sur les ressources.
Activez la journalisation des requêtes DNS (Domain Name System) en appliquant une configuration documentée dans votre ConfigMap personnalisé CoreDNS.
Surveillez les tentatives d’accès aux informations d’identification désactivées.
Intégrez l’authentification utilisateur pour AKS à Microsoft Entra ID. Créez des paramètres de diagnostic pour l’ID Microsoft Entra et envoyez les journaux d’audit et de connexion à un espace de travail Log Analytics. Dans l’espace de travail Log Analytics, configurez des alertes pour les événements de sécurité, tels que les tentatives de connexion à partir de comptes désactivés.
Bonne pratique : activer les diagnostics sur vos ressources Azure
- Activez les diagnostics Azure sur toutes les ressources de votre charge de travail pour accéder aux journaux de plateforme qui fournissent des informations de diagnostic et d’audit détaillées. Vous pouvez ingérer ces journaux dans Log Analytics ou une solution SIEM telle que Microsoft Sentinel pour la surveillance et les alertes de sécurité.
Contributeurs
Microsoft maintient cet article. Les contributeurs suivants ont écrit cet article.
Auteur principal :
- Adnan Khan | Sr. Architecte de solution cloud
Autres contributeurs :
- Ayobami Ayodeji | Gestionnaire de programmes 2
- Ahmed Bham | Sr. Architecte de solution cloud
- Chad Kittel | Ingénieur logiciel principal - Modèles et pratiques Azure
- John Poole | Sr. Architecte de solution cloud
- Bahram Rushenas | Architecte de solution sr.
- Abed Sau | Sr. Architecte de solution cloud
Pour afficher les profils LinkedIn non publics, connectez-vous à LinkedIn.