Partager via


DevSecOps sur Azure Kubernetes Service (AKS)

Azure Boards
Azure DevOps
Azure Monitor
Azure Pipelines
Azure Policy

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. Voici quelques-uns des avantages de la création de la sécurité dans les pratiques DevOps :

  • Rendre vos applications et systèmes plus sécurisés en fournissant une visibilité sur les menaces de sécurité et en empêchant les vulnérabilités d’atteindre les environnements déployés
  • Augmentation de la sensibilisation à la sécurité avec vos équipes de développement et d’exploitation
  • Intégration de processus de sécurité automatisés dans votre cycle de vie de développement logiciel
  • Réduction des coûts de correction en recherchant des problèmes de sécurité au début des phases de développement et de conception

Lorsque DevSecOps est appliqué à Azure Kubernetes Service (AKS), différents rôles d’organisation peuvent avoir des considérations différentes pour implémenter la sécurité. Voici quelques exemples de ces différents rôles d’organisation :

  • Développeurs qui créent des applications sécurisées s’exécutant sur AKS
  • Ingénieurs cloud qui créent une infrastructure AKS sécurisée
  • Différentes équipes d’opérations qui peuvent régir les clusters ou surveiller les problèmes de sécurité

Cet article est divisé en différentes étapes de cycle de vie DevOps avec des considérations et des recommandations pour incorporer les contrôles de sécurité et les meilleures pratiques de sécurité. Ce guide comprend des processus et des outils courants à intégrer dans des pipelines d’intégration continue et de livraison continue (CI/CD), en optant pour des outils intégrés faciles à utiliser, le cas échéant.

En guise de prérequis pour cet article, nous vous recommandons de consulter build et déploiement d’applications sur AKS à l’aide de DevOps et GitOps.

Flux de processus

Le diagramme d’architecture montre le flux entre le développeur et l’utilisateur final et où DevSecOps peut être utilisé, DevSecOps sur AKS.

Téléchargez un fichier Visio de cette architecture.

Remarque

Bien que cet article référence AKS et GitHub, ces recommandations s’appliquent à n’importe quelle plateforme d’orchestration de conteneur ou CI/CD. Bien que les détails de l’implémentation varient, la plupart des concepts et pratiques mentionnés dans chaque phase sont toujours pertinents et applicables.

  1. L’ID Microsoft Entra est configuré en tant que fournisseur d’identité pour GitHub. Configurez l’authentification multifacteur (MFA) pour fournir une sécurité d’authentification supplémentaire.
  2. 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é.
  3. Les développeurs valident le code d’application dans un dépôt GitHub Enterprise appartenant à l’entreprise et régi.
  4. GitHub Enterprise intègre l’analyse automatique de la sécurité et des dépendances via GitHub Advanced Security.
  5. Les demandes de tirage déclenchent des builds d’intégration continue (CI) et des tests automatisés via GitHub Actions.
  6. Le flux de travail de génération CI via GitHub Actions génère une image conteneur Docker stockée dans Azure Container Registry.
  7. Vous pouvez introduire des approbations manuelles pour les déploiements dans des environnements spécifiques, tels que la production, dans le cadre du flux de travail de livraison continue (CD) dans GitHub Actions.
  8. 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 de configuration et source de votre application.
  9. Microsoft Defender est utilisé pour analyser Azure Container Registry, le cluster AKS et Azure Key Vault pour détecter les vulnérabilités de sécurité.
    1. Microsoft Defender pour conteneurs analyse l’image conteneur pour détecter les vulnérabilités de sécurité connues lors du chargement dans Container Registry.
    2. Vous pouvez également utiliser Defender pour conteneurs pour effectuer des analyses de votre environnement AKS et fournir une protection contre les menaces au moment de l’exécution pour vos clusters AKS.
    3. Microsoft Defender pour Key Vault détecte les tentatives suspectes et dangereuses d’accéder aux comptes de coffre de clés.
  10. Azure Policy peut être appliqué à Container Registry et à Azure Kubernetes Service (AKS) pour la conformité et l’application des stratégies. Les stratégies de sécurité courantes pour Container Registry et AKS sont intégrées pour une activation rapide.
  11. Azure Key Vault est utilisé pour injecter en toute sécurité des secrets et des informations d’identification dans une application au moment de l’exécution, en séparant les informations sensibles des développeurs.
  12. 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.
  13. La surveillance continue du cluster AKS peut être configurée à l’aide d’Azure Monitor et de Container Insights pour ingérer des métriques de performances et analyser les journaux d’application et de sécurité.
    1. Container Insights récupère les métriques de performances et les journaux d’application et de cluster.
    2. Les journaux de diagnostic et d’application sont extraits dans un espace de travail Azure Log Analytics pour exécuter des requêtes de journal.
  14. Microsoft Sentinel, qui est une solution SIEM (Security Information and Event Management), peut être utilisé pour ingérer et analyser plus en détail les journaux de cluster AKS pour toutes les menaces de sécurité basées sur des modèles et des règles définis.
  15. Open-Source outils tels que Zed Attack Proxy (ZAP) (ZAP) peuvent être utilisés pour effectuer des tests d’intrusion pour les applications web et les services.
  16. 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 multi pipelines, notamment GitHub et Azure DevOps.

Vue d’ensemble et responsabilités des membres de l’équipe

Envisagez de gérer la complexité des déploiements de solutions basées sur Kubernetes en tant que séparation des préoccupations. Quelle équipe dans un environnement d’entreprise doit être concernée par chaque aspect du déploiement ? Quels outils et processus une équipe doit-elle utiliser pour atteindre au mieux ses objectifs ? Dans cette section, nous allons passer en charge les rôles courants des développeurs, des opérateurs d’applications (ingénieurs de fiabilité de site), des opérateurs de cluster et des équipes de sécurité.

Développeurs

Les développeurs sont responsables de l’écriture du code d’application. Ils sont également responsables de la validation de leur code dans le référentiel désigné. L’une des responsabilités importantes des développeurs inclut également la création et l’exécution de scripts pour les tests automatisés afin de s’assurer que leur code fonctionne comme prévu et s’intègre en toute transparence au reste de l’application. Ils définissent également et scriptent 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 sur le cloud à 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 pour automatiser la supervision des systèmes logiciels volumineux. Ils servent de pont entre les équipes de développement et d’opérateur de cluster et aident à établir et à surveiller les objectifs et les budgets d’erreur au niveau du service. De cette façon, ils aident à gérer les déploiements d’applications et écrivent souvent des fichiers de manifeste Kubernetes (YAML).

Opérateurs de cluster

Les opérateurs de cluster sont responsables de la configuration et de la gestion de l’infrastructure de cluster. Ils utilisent souvent l’infrastructure en tant que bonnes pratiques et infrastructures iaC telles que GitOps pour approvisionner et gérer leurs clusters. Ils utilisent différents outils de supervision tels qu’Azure Monitor Container Insights et Prometheus/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 sur le cluster. Dans les équipes DevSecOps, ils garantissent que les clusters répondent aux exigences de sécurité de l’équipe et collaborent avec l’équipe de sécurité pour créer ces normes.

Équipe de sécurité

L’équipe de sécurité est chargée de développer des normes de sécurité et de les appliquer. Certaines équipes peuvent être responsables de la création et de la sélection d’Azure Policy appliquées dans les abonnements et les groupes de ressources contenant les clusters. Ils surveillent les problèmes de sécurité et, avec les autres équipes, veillent à ce que la sécurité soit mise à l’avant-garde de chaque étape du processus DevSecOps.

Phases de cycle de vie DevSecOps

Les contrôles de sécurité sont implémentés dans chaque phase du cycle de vie du développement logiciel (SDLC). Cette implémentation est un élément clé d’une stratégie DevSecOps et de l’approche décalée vers la gauche.

Le diagramme d’architecture montre le flux entre le développeur et l’utilisateur final et où DevSecOps peut être utilisé, DevSecOps sur AKS.

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 ont un impact significatif sur les phases de cycle de vie devOps ultérieures. Cette phase implique la collaboration entre les équipes de sécurité, de développement et d’exploitation. L’inclusion des parties prenantes de la sécurité dans cette phase de conception et de planification garantit que les exigences de sécurité et les problèmes de sécurité sont pris en compte ou atténués de manière appropriée.

Meilleure pratique : concevoir une plateforme d’applications plus sécurisée

La création d’une plateforme hébergée par AKS plus sécurisée est une étape importante pour vous assurer que la sécurité est intégrée au 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) et des composants externes à AKS (tels que des pare-feu réseau et des registres de conteneurs). Pour plus d’informations, consultez AKS dans une zone d’atterrissage d’application, qui inclut des zones de conception critiques telles que la sécurité, l’identité et la topologie réseau.

Meilleure 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. Il est utilisé pour modéliser et rechercher des menaces au sein d’un système afin que les vulnérabilités puissent être traitées avant tout développement de code ou modification d’un système. La modélisation des menaces peut se produire à différents moments, déclenchées par des événements tels qu’une modification logicielle importante, un changement architectural de solution ou des incidents de sécurité.
  • Nous vous recommandons d’utiliser le modèle de menace STRIDE. Cette méthodologie commence par un diagramme de flux de données et utilise les catégories de menaces stride mnemonique (usurpation, falsification, divulgation d’informations, répudiation, déni de service et élévation de privilèges) pour permettre aux équipes d’identifier, d’atténuer et de valider les risques. Il inclut également un outil de modélisation pour noter et 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 vos processus SDLC introduit de nouveaux processus et plus de travail pour maintenir les modèles de menace mis à jour. Mais elle permet de s’assurer que la sécurité est en place tôt, ce qui permet de réduire le coût potentiel de la gestion des problèmes de sécurité détectés dans les phases de SDLC ultérieures.

Bonne pratique : appliquer Azure Well Architect Framework (WAF)

  • Appliquez les meilleures pratiques de sécurité WAF qui fournissent des conseils sur la gestion des identités, la sécurité des applications, la protection de l’infrastructure, la sécurité de date et DevOps, car elles s’appliquent aux environnements natifs cloud.
  • Appliquez les meilleures pratiques opérationnelles WAF telles qu’elles s’appliquent à DevSecOps et à la surveillance de vos environnements de production.

Phase de développement

« Déplacer vers la gauche » est un locataire clé de l’état d’esprit DevSecOps. Ce processus commence avant que le code soit même validé dans un référentiel et déployé via un pipeline. L’adoption de bonnes pratiques de codage sécurisées et l’utilisation d’outils et de plug-ins IDE pour l’analyse du code pendant la phase de développement peuvent aider à résoudre les problèmes de sécurité plus tôt dans le cycle de vie du développement lorsqu’ils sont plus faciles à résoudre.

Bonne pratique : appliquer des normes de codage sécurisées

  • En utilisant des bonnes pratiques et des listes de contrôle de codage sécurisées établies, vous pouvez aider à protéger votre code contre les vulnérabilités courantes telles que l’injection et la conception non sécurisée. La fondation OWASP publie des recommandations de codage sécurisées standard du secteur que vous devez adopter lors de l’écriture de code. Ces instructions sont particulièrement importantes lors du développement d’applications web ou de services web accessibles au public.
  • Outre les meilleures pratiques de sécurité générales, vous devez également examiner les pratiques de codage sécurisées pour vos runtimes de langage de programmation spécifiques, comme Java et .NET.
  • Vous pouvez appliquer 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, telles que log4j et 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, Visual Studio Code, IntelliJ IDEA et Eclipse, prennent en charge les extensions que vous pouvez utiliser pour obtenir des commentaires et des recommandations immédiats pour les problèmes de sécurité potentiels que vous avez introduits lors de l’écriture de code d’application.

  • SonarLint est un plug-in IDE disponible pour les langages et les environnements de développement les plus populaires. SonarLint fournit des commentaires précieux 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 sont axés sur des éléments spécifiques à la sécurité, comme les 10 principales vulnérabilités courantes de OWASP. Le plug-in Synk , par exemple, analyse également votre source d’application et vos dépendances tierces et vous avertit si des vulnérabilités sont détectées.
  • Le plug-in SARIF (Static Analysis Results Interchange Format) pour Visual Studio et Visual Studio Code vous permet d’afficher facilement les vulnérabilités des outils de test de sécurité des applications statiques (SAST) populaires de manière intuitive et facile à lire par rapport à l’interprétation des 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 branche pour qu’il existe une utilisation cohérente de la branche dans l’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 dont les branches doivent être utilisées 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. Ces branches doivent avoir établi des stratégies de fusion avant que les modifications puissent être fusionnées ou validées. Voici quelques bonnes pratiques :
    • Empêchez d’autres développeurs de valider du code directement dans votre branche principale.
    • Établissez un processus d’examen par les pairs et exigez un nombre minimal d’approbations avant que les modifications puissent être fusionnées vers une branche principale. Vous pouvez facilement configurer et appliquer ces contrôles avec GitHub. GitHub vous permet également de désigner des groupes d’approbateurs autorisés si nécessaire pour les environnements contrôlé.
  • Utilisez des hooks de pré-validation pour rechercher des informations sensibles dans le code source de votre application et empêcher une validation de se produire si un problème de sécurité est détecté.
    • Utilisez les hooks prédéfini fournis par GitHub qui peuvent être facilement configurés pour un projet spécifique. Par exemple, il existe des hooks prédéfinis pour rechercher des secrets, des clés privées et des informations d’identification, et empêcher une validation si l’un de ces problèmes est détecté.
  • Établissez un contrôle d’accès en fonction du rôle au sein de votre système de contrôle de version.
    • Créez des rôles bien définis à l’aide du principe des privilèges minimum. Un pipeline CI/CD est votre chaîne d’approvisionnement pour les déploiements de production.
    • Appliquez des rôles d’utilisateur ou de groupe établis au sein de votre organisation. Les rôles tels que l’administrateur, le développeur, l’administrateur de sécurité et l’opérateur doivent être créés pour regrouper des personnes en fonction de leur rôle et de leur fonction spécifiques concernant vos flux de travail CI/CD.
  • Activez l’audit de vos flux de travail afin que la transparence et la traçabilité de la configuration et d’autres modifications soient apportées à vos pipelines CI/CD.

Bonne pratique : sécuriser vos images conteneur

  • Utilisez des images légères avec une empreinte minimale du système d’exploitation pour réduire la surface d’attaque globale de la surface d’attaque. Considérez des images minimales comme Alpine ou même des images sans distribution qui contiennent uniquement votre application et son runtime associé. Mariner, la distribution Linux open source Microsoft, est une distribution légère et renforcée conçue pour AKS afin d’héberger des charges de travail conteneurisées.
  • Utilisez uniquement les images de base approuvées lors de la création de vos conteneurs. Ces images de base doivent être récupérées à partir d’un registre privé qui est fréquemment analysé pour les vulnérabilités.
  • Utilisez les outils de développement pour évaluer les vulnérabilités d’image localement.
    • Trivy est un exemple d’outil open source que vous pouvez utiliser pour analyser les vulnérabilités de sécurité dans vos images conteneur.
  • Empêcher l’accès/le contexte de l’utilisateur racine pour une image. Par défaut, les conteneurs s’exécutent en tant que racine.
    • Pour les conteneurs qui ont besoin d’une sécurité renforcée, envisagez d’utiliser un profil AppArmor au sein de votre cluster Kubernetes pour renforcer la sécurité de vos conteneurs en cours d’exécution.

Phase de génération

Pendant la phase de génération, les développeurs travaillent avec les ingénieurs de fiabilité du site et les équipes de sécurité pour intégrer des analyses automatisées de leur source d’application dans leurs pipelines de build CI. Les pipelines sont configurés pour activer des pratiques de sécurité telles que SAST, SCA et l’analyse des secrets à l’aide des outils et extensions de sécurité de la plateforme CI/CD.

Bonne pratique : effectuer une analyse de code statique (SAST) pour rechercher des vulnérabilités potentielles dans le code source de votre application

  • Utilisez les fonctionnalités d’analyse De sécurité avancée GitHub pour l’analyse du code et CodeQL.
    • L’analyse du code est une fonctionnalité que vous utilisez pour analyser le code dans un référentiel GitHub pour rechercher des vulnérabilités de sécurité et des erreurs de codage. Tous les problèmes identifiés par l’analyse sont affichés 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 également configurer des règles de branche pour les vérifications d’état requises, par exemple pour appliquer qu’une branche de fonctionnalité est à jour avec la branche de base avant de fusionner tout nouveau code. Cette pratique garantit que votre branche a toujours été testée avec le code le plus récent.
  • Utilisez des outils tels que kube-score pour analyser vos objets de déploiement Kubernetes.
    • kube-score est un outil qui effectue une analyse statique du code de vos définitions d’objets Kubernetes.
    • La sortie est une liste de recommandations de ce que vous pouvez améliorer pour aider à rendre votre application plus sécurisée et résiliente.

Bonne pratique : effectuer l’analyse des secrets pour empêcher l’utilisation frauduleuse de secrets qui ont été commis accidentellement dans un référentiel

  • Lorsque l’analyse des secrets est activée 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 également 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 votre sortie de build.
    • L’analyse des secrets peut être exécutée dans le cadre de l’extension Microsoft Security DevOps pour Azure DevOps.

Bonne pratique : utiliser des outils d’analyse de composition logicielle (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 et fournit des informations sur la licence, les dépendances et l’âge des dépendances. Il fournit une visualisation facilement compréhensible des modifications de dépendances avec un différentiel enrichi sous l’onglet « Fichiers modifiés » d’une demande de tirage.
  • 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 : activer les analyses de sécurité des modèles d’infrastructure en tant que code (IaC) pour réduire les erreurs de configuration cloud atteignant des environnements de production

  • Surveillez de manière proactive les configurations des ressources cloud tout au long du cycle de vie du développement.
  • Microsoft Defender pour DevOps prend en charge les dépôts GitHub et Azure DevOps.

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 AWS Elastic Container Registry (ERC) pour vous avertir s’il existe des vulnérabilités connues dans vos images.
  • Azure Policy peut être activé pour effectuer une évaluation des vulnérabilités sur toutes les images stockées dans Container Registry et fournir des informations détaillées sur chaque recherche.

Bonne pratique : générer automatiquement de nouvelles images sur la mise à jour des images de base

  • Azure Container Registry Tasks découvre dynamiquement les dépendances d’image de base lorsqu’elle génère une image conteneur. Par conséquent, il peut détecter quand l’image de base d’une image d’application est mise à jour. Avec une tâche de génération préconfigurée, les tâches Container Registry peuvent régénérer automatiquement chaque image d’application qui fait référence à l’image de base.

Bonne pratique : utiliser Container Registry, Azure Key Vault et la notation pour signer numériquement vos images conteneur et configurer le cluster AKS pour autoriser uniquement les images validées

  • Azure Key Vault stocke une clé de signature qui peut être utilisée par notation avec le plug-in Key Vault de notation (azure-kv) pour signer et vérifier les images conteneur et d’autres artefacts. Container Registry vous permet d’attacher ces signatures à l’aide des commandes Azure CLI.
  • Les conteneurs signés permettent aux utilisateurs de s’assurer que les déploiements sont générés à partir d’une entité approuvée et vérifient qu’aucun artefact n’a été falsifié depuis sa 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.
    • La ratification permet aux clusters Kubernetes de vérifier les métadonnées de sécurité des artefacts avant le déploiement et d’admettre pour le déploiement uniquement ceux qui sont conformes à une stratégie d’admission que vous créez.

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 sur l’établissement des contrôles de sécurité appropriés pour les pipelines de déploiement continu (CD) afin de déployer du code dans un environnement de production de manière plus 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 forcer l’envoi (push) 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.
  • En utilisant des environnements pour le déploiement, vous pouvez configurer des environnements avec des règles de protection et des secrets.
  • Vous pouvez tirer parti de la fonctionnalité Approbations et Portes 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 un déploiement vers 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.
  • En utilisant des environnements pour le déploiement, vous pouvez configurer des environnements avec des règles de protection et des secrets.
    • Une approche basée sur les tirages (pull) de CI/CD avec GitOps vous permet de déplacer les informations d’identification de sécurité vers votre cluster Kubernetes, ce qui réduit la surface de sécurité et de risque en supprimant les informations d’identification d’être stockées dans 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 des tests de sécurité des applications dynamiques (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.
  • Activez Azure Policy pour que les images conteneur puissent uniquement être déployées à partir de registres approuvés.

Phase d’exploitation

Pendant cette phase, les tâches de surveillance des opérations et de surveillance de la sécurité sont effectuées pour surveiller, analyser et alerter de manière proactive les incidents de sécurité potentiels. Les outils d’observabilité de production tels qu’Azure Monitor et Microsoft Sentinel sont utilisés pour surveiller et garantir la conformité aux normes de sécurité d’entreprise.

Bonne pratique : utiliser Microsoft Defender pour le cloud pour activer l’analyse et la surveillance automatisées de 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 Microsoft Defender pour cloud (sous la section Calcul et applications ) pour effectuer des analyses de référence pour vos clusters AKS. Recevez une notification dans le tableau de bord Microsoft Defender pour Cloud lorsque des problèmes de configuration ou des vulnérabilités sont détectés.
    • Utilisez Microsoft Defender pour cloud et suivez ses recommandations de protection réseau pour sécuriser les ressources réseau utilisées par vos clusters AKS.
  • Effectuez une évaluation des vulnérabilités pour les images stockées dans Container Registry.
    • Implémentez des analyses continues pour l’exécution d’images dans Container Registry en activant Defender pour conteneurs.

Bonne pratique : maintenir vos clusters Kubernetes mis à jour

  • Les versions de Kubernetes sont déployées fréquemment. Il est important d’avoir une stratégie de gestion du cycle de vie en place pour vous assurer que vous ne vous trouvez pas en retard et en dehors du support. AKS est une offre managée qui vous offre des outils et une flexibilité pour gérer ce processus de mise à niveau. Vous pouvez utiliser les fonctionnalités de maintenance planifiée de la plateforme AKS pour avoir plus de contrôle sur les fenêtres de maintenance et les mises à niveau.
  • Les nœuds Worker AKS doivent être mis à niveau plus fréquemment. Nous fournissons des mises à jour de système d’exploitation et d’exécution hebdomadaires, qui peuvent être appliquées automatiquement via le mode sans assistance ou via Azure CLI pour des mises à jour plus complètes et 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 (également appelées 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 d’approuver uniquement les adresses IP externes autorisées. 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 que ces affectations sont appliquées.
  • 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.
    • Installez le moteur de stratégie réseau et créez des stratégies réseau Kubernetes pour contrôler le flux de trafic entre les pods dans AKS. La stratégie réseau peut être utilisée pour les nœuds et pods Basés sur Linux ou Windows dans AKS.

Bonne pratique : utiliser Azure Monitor pour la surveillance et les alertes continues

  • Utilisez Azure Monitor pour collecter des journaux et des métriques à partir d’AKS. Vous obtenez des insights sur la disponibilité et les performances de votre application et de votre infrastructure. Il vous donne également accès aux signaux pour surveiller l’intégrité de votre solution et repérer l’activité anormale tôt.
    • La surveillance continue avec Azure Monitor s’étend aux pipelines de mise en production pour contrôler ou restaurer les versions en fonction des données de surveillance. Azure Monitor ingère également les journaux de sécurité et peut alerter sur les activités suspectes.
    • Intégrez vos instances AKS à Azure Monitor et configurez les paramètres de diagnostic pour votre cluster.

Bonne pratique : utiliser Microsoft Defender pour cloud pour la surveillance active des menaces

  • Microsoft Defender pour Cloud fournit une surveillance active des menaces sur AKS au niveau du nœud (menaces de machine virtuelle) et des éléments internes.
  • Defender pour DevOps doit être utilisé pour une visibilité complète et fournit aux équipes de sécurité et d’opérateur un tableau de bord centralisé pour tous vos pipelines CI/CD. Cette fonctionnalité est particulièrement utile si vous utilisez des plateformes multi pipelines telles qu’Azure DevOps et GitHub ou exécutent des pipelines dans des clouds publics.
  • Defender pour Key Vault peut être utilisé pour détecter des tentatives inhabituelles et suspectes d’accès aux comptes key vault et peut alerter les administrateurs en fonction de la configuration.
  • Defender pour conteneurs peut alerter sur les vulnérabilités trouvées dans vos images conteneur stockées sur Container Registry.

Bonne pratique : activer la surveillance centralisée des journaux et utiliser les 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. Sentinel permet cet accès en toute transparence 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 les opérations effectuées sur les ressources et par qui.
  • Activez la journalisation des requêtes DNS 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 à l’ID Microsoft Entra. Créez des paramètres de diagnostic pour Microsoft Entra ID, en envoyant les journaux d’audit et de connexion à un espace de travail Azure Log Analytics. Configurez les alertes souhaitées (par exemple, lorsqu’un compte désactivé tente de se connecter) dans un espace de travail Azure Log Analytics.

Bonne pratique : activer les diagnostics sur vos ressources Azure

  • En activant les diagnostics Azure sur toutes les ressources de votre charge de travail, vous avez accès aux journaux de plateforme qui fournissent des informations de diagnostic et d’audit détaillées pour vos ressources Azure. Ces journaux peuvent être ingérés dans Log Analytics ou une solution SIEM comme Microsoft Sentinel pour la surveillance et les alertes de sécurité.

Contributeurs

Cet article est géré par Microsoft. Il a été écrit à l’origine par les contributeurs suivants.

Auteur principal :

Autres contributeurs :

Étapes suivantes