Modifier

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 l’établissement de la sécurité dans les pratiques DevOps :

  • Rend vos applications et systèmes plus sûrs en offrant une visibilité sur les menaces de sécurité et en empêchant les vulnérabilités d’atteindre les environnements déployés
  • Augmente la sensibilisation à la sécurité avec vos équipes de développement et d’exploitation
  • Incorpore des processus de sécurité automatisés dans votre cycle de vie de développement de logiciels
  • Réduit les coûts de correction en recherchant les 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 l’implémentation de la sécurité. Voici quelques exemples de ces différents rôles d’organisation :

  • Les développeurs qui créent des applications sécurisées s’exécutant sur AKS
  • Les ingénieurs cloud générant une infrastructure AKS sécurisée
  • Les 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 du cycle de vie DevOps avec des considérations et des recommandations pour l’incorporation des contrôles de sécurité et des meilleures pratiques de sécurité. Ce guide comprend des processus et des outils courants à incorporer dans les 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.

Comme prérequis à cet article, nous vous recommandons de consulter Créer et déployer des applications sur AKS à l’aide de DevOps et GitOps.

Flux de processus

Schéma architectural montrant le flux du développeur à l’utilisateur final et où DevSecOps peut être utilisé, DevSecOps sur AKS.

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

Notes

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

  1. Microsoft Entra ID est configuré comme 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 à la recherche de failles de sécurité.
  3. Les développeurs valident le code de l’application dans un référentiel GitHub Enterprise détenu et régi par l’entreprise.
  4. GitHub Enterprise intègre une 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 workflow de build 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, comme la production, dans le cadre du workflow de livraison continue (CD) dans GitHub Actions.
  8. GitHub Actions active le déploiement continu sur AKS. Utilisez GitHub Advanced Security pour détecter les secrets, les informations d’identification et d’autres informations sensibles dans vos fichiers de configuration et de source d’application.
  9. Microsoft Defender est utilisé pour analyser Azure Container Registry, le cluster AKS et Azure Key Vault à la recherche de failles de sécurité.
    1. Microsoft Defender pour les conteneurs analyse l’image conteneur à la recherche de failles de sécurité connues lors de son chargement dans Container Registry.
    2. Vous pouvez également utiliser Defender pour les conteneurs pour effectuer des analyses de votre environnement AKS et fournir une protection contre les menaces au moment de l’exécution de vos clusters AKS.
    3. Microsoft Defender pour Key Vault détecte les tentatives dangereuses et inhabituelles d’accès aux comptes Key Vault.
  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 tenant les informations sensibles hors de portée des développeurs.
  12. Le moteur de stratégie réseau AKS est configuré pour vous aider à 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 les 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 (Gestion des informations et des événements de sécurité), peut être utilisé pour ingérer et analyser plus en détail les journaux de cluster AKS à la recherche de menaces de sécurité en fonction de modèles et de règles définis.
  15. Des outils open source comme Zed Attack Proxy (ZAP) (ZAP) peuvent être utilisés pour effectuer des tests d’intrusion pour les applications et les services web.
  16. Defender pour DevOps, un service disponible dans Defender pour le cloud, permet aux équipes de sécurité de gérer la sécurité DevOps dans les environnements à plusieurs pipelines, dont GitHub et Azure DevOps.

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

Envisagez de gérer la complexité de DevSecOps sur les déploiements de solutions basées sur Kubernetes comme une séparation des problèmes. 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 abordons les rôles courants des développeurs, des opérateurs d’application (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 de l’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 comprend également la création et l’exécution de scripts pour des tests automatisés afin de s’assurer que leur code fonctionne comme prévu et s’intègre parfaitement au reste de l’application. Ils 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 dans le cloud à l’aide de conteneurs et de Kubernetes peut simplifier le développement, le déploiement et la scalabilité 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é de 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 de niveau de service et les budgets d’erreur. De cette façon, ils aident à gérer les déploiements d’applications et écrivent souvent des fichiers 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 les meilleures pratiques et frameworks d’infrastructure en tant que code (IaC) comme GitOps pour approvisionner et gérer leurs clusters. Ils utilisent différents outils de supervision comme 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 du cluster, des autorisations et du contrôle d’accès en fonction du rôle sur le cluster. Dans les équipes DevSecOps, ils s’assurent que les clusters répondent aux exigences de sécurité de l’équipe, et ils travaillent avec l’équipe de sécurité pour créer ces normes.

Équipe de sécurité

L’équipe de sécurité est responsable du développement des normes de sécurité et de leur application. Certaines équipes peuvent être responsables de la création et de la sélection de stratégies Azure Policy qui sont appliquées dans les abonnements et les groupes de ressources contenant les clusters. Ils surveillent les problèmes de sécurité et, en collaboration avec les autres équipes, veillent à ce que la sécurité soit au premier plan de chaque étape du processus DevSecOps.

Phases du 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 shift-left.

Schéma architectural montrant le flux du développeur à 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 planification a généralement le moins d’automatisation, mais elle a des implications de sécurité importantes 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 correctement pris en compte ou atténués.

Meilleure pratique : Concevoir une plateforme d’application plus sécurisée

La création d’une plateforme hébergée par AKS plus sécurisée est une étape importante pour garantir 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 (comme des agents de stratégie et de sécurité d’exécution) et des composants externes à AKS (comme des pare-feu réseau et registres de conteneurs). Pour plus d’informations, consultez Accélérateur de zone d’atterrissage AKS, qui inclut des domaines de conception critiques, comme la sécurité, l’identité et la topologie réseau.

Meilleure pratique : Intégrer la 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. Elle est utilisée 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’un changement logiciel important, un changement d’architecture 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 mnémoniques STRIDE (Spoofing, Tampering, Info Disclosure, Repudiation, Denial of Service, et Elevation of Privilege - usurpation d’identité, 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 permettant de noter et de visualiser les composants système, les flux de données et les limites de sécurité. La création d’une modélisation des menaces dans vos processus SDLC introduit de nouveaux processus et davantage de travail pour maintenir les modèles de menaces à jour. Toutefois, cela garantit 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 ultérieures de SDLC.

Meilleure pratique : Appliquer Azure Well Architect Framework (WAF)

  • Appliquez les meilleures pratiques des piliers de sécurité WAF, qui fournissent des conseils pour des choses comme la gestion des identités, la sécurité des applications, la protection de l’infrastructure, la sécurité des données et DevOps, dans le cadre des 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

Le « Shift Left » est un principe clé de l’esprit DevSecOps. Ce processus commence avant même que le code soit validé dans un référentiel et déployé via un pipeline. L’adoption des meilleures pratiques de codage sécurisé et l’utilisation d’outils et de plug-ins d’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, quand ils sont plus faciles à corriger.

Meilleure pratique : Appliquer des normes de codage sécurisé

  • En utilisant les meilleures pratiques et listes de contrôle de codage sécurisées établies, vous pouvez protéger votre code contre les vulnérabilités courantes, comme l’injection et la conception non sécurisée. La fondation OWASP publie des recommandations de codage sécurisé standard que vous devriez adopter lors de l’écriture de code. Ces lignes directrices sont particulièrement importantes lors du développement d’applications ou de services web accessibles au public.
  • Outre les bonnes 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 les fuites dans les journaux d’application. Les frameworks de journalisation les plus populaires, comme log4j et log4net, fournissent des filtres et des plug-ins pour masquer des informations sensibles, comme les numéros de compte ou les données personnelles.

Meilleure pratique : Utiliser des outils et plug-ins d’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 des extensions que vous pouvez utiliser pour obtenir des retours et des conseils immédiats pour les problèmes de sécurité potentiels que vous avez peut-être introduits lors de l’écriture de code d’application.

  • SonarLint est un plug-in d’IDE disponible pour les langages et environnements de développement les plus populaires. SonarLint fournit des commentaires précieux et analyse automatiquement votre code à la recherche d’erreurs de programmation courantes et de 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 d’OWASP. Le plug-in Synk, par exemple, analyse également la source de votre application et les 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) de manière intuitive et facile à lire au lieu d’interpréter les résultats des fichiers de sortie JSON bruts.

Meilleure pratique : Établir des contrôles sur vos référentiels de code source

  • Établissez une méthodologie de branchement pour une utilisation cohérente des branches au sein de l’entreprise. Des méthodologies comme 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 le développement parallèle et en équipe. Ces méthodologies peuvent aider les équipes à établir des normes et des contrôles pour les validations de code et les fusions dans votre workflow CI/CD.
  • Certaines branches, comme la branche primaire, sont des branches durables qui préservent l’intégrité du code source de votre application. Ces branches doivent avoir des stratégies de fusion établies avant que les modifications puissent être fusionnées ou validées. Voici quelques-unes des meilleures pratiques :
    • Empêchez d’autres développeurs de valider du code directement dans votre branche primaire.
    • Établissez un processus d’examen par les pairs et exigez un nombre minimal d’approbations avant que les modifications puissent être fusionnées avec 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és.
  • 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 de pré-validation intégrés 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 un problème lié est détecté.
  • Établissez un contrôle d’accès en fonction du rôle dans votre système de gestion de version.
    • Créez des rôles bien définis en utilisant le 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. Des rôles comme Administration, Développeur, Administrateur de sécurité et Opérateur doivent être créés pour regrouper les personnes en fonction de leur rôle et de leur fonction spécifiques concernant vos workflows CI/CD.
  • Activez l’audit de vos workflows afin d’assurer la transparence et la traçabilité de la configuration et des autres modifications concernant vos pipelines CI/CD.

Meilleure pratique : Sécuriser vos images conteneur

  • Utilisez des images légères avec un encombrement minimal du système d’exploitation pour réduire la surface d’attaque globale. Considérez des images minimales comme Alpine ou même des images distroless qui contiennent uniquement votre application et son runtime associé. Mariner, la distribution Linux open source de 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 des 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é à la recherche de vulnérabilités.
  • Utilisez les outils de développement pour évaluer les vulnérabilités des images localement.
    • Trivy est un exemple d’outil open source que vous pouvez utiliser pour analyser les vulnérabilités de sécurité au sein de vos images conteneur.
  • Empêchez l’accès/le contexte 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 build

Pendant la phase de build, 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é comme SAST, SCA et l’analyse des secrets à l’aide d’extensions et outils de sécurité de la plateforme CI/CD.

Meilleure pratique : Effectuer une analyse du code statique (SAST) pour détecter les vulnérabilités potentielles dans le code source de votre application

  • Utilisez les fonctionnalités d’analyse de GitHub Advanced Security pour l’analyse du code et CodeQL.
    • L’analyse du code est une fonctionnalité que vous utilisez pour analyser le code d’un référentiel GitHub afin de trouver des failles 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 dépôt.
    • Vous pouvez également configurer des règles de branche pour les vérifications d’état requises, par exemple, pour appliquer le fait qu’une branche de fonctionnalité doit être à 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 comme 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 rendre votre application plus sécurisée et résiliente.

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

  • Lorsque l’analyse des secrets est activée pour un référentiel, GitHub analyse le code à la recherche de 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 for Cloud utilise l’analyse des secrets pour détecter des informations d’identification, des secrets, des 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.

Meilleure pratique : Utiliser des outils d’analyse de la 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épendants et l’âge des dépendances. Elle fournit une visualisation facilement compréhensible des changements de dépendances avec des différences enrichies sous l’onglet « Fichiers modifiés » d’une demande de tirage.
  • Dependabot effectue une analyse pour détecter des dépendances vulnérables, et envoie des alertes Dependabot quand un nouvel avis est ajouté à la base de données GitHub Advisory ou au graphique de dépendance d’un dépôt.

Meilleure pratique : Activer les analyses de sécurité des modèles d’infrastructure en tant que code (IaC) pour réduire les erreurs de configuration du cloud qui atteignent les environnements de production

  • Surveillez de façon proactive les configurations des 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.

Meilleure pratique : Analyser vos images de charge de travail dans les registres de conteneurs pour identifier les vulnérabilités connues

  • Defender pour les conteneurs analyse les conteneurs dans Container Registry et Amazon AWS Elastic Container Registry (ECR) pour vous avertir de la présence de vulnérabilités connues dans vos images.
  • Azure Policy peut 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 découverte.

Meilleure pratique - Générer automatiquement les nouvelles images sur la mise à jour de l’image de base

  • Azure Container Registry Tasks découvre dynamiquement les dépendances des images de base lorsqu’il 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 build préconfigurée, Container Registry est capable de reconstruire automatiquement chacune des images d’application faisant référence à l’image de base.

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

  • Azure Key Vault est utilisé pour stocker une clé de signature qui peut être utilisée par notation avec le plug-in de notation Key Vault (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 d’assurer que les déploiements sont générés à partir d’une entité approuvée et que l’artefact n’a pas été falsifié depuis sa création. L’artefact signé garantit l’intégrité et l’authenticité avant que l’utilisateur n’extrait un artefact dans n’importe quel environnement et évite les attaques.
    • Ratify 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 les éléments conformes à une stratégie d’admission que vous créez.

Phase de déploiement

Pendant la phase de déploiement, les développeurs, opérateurs d’application et équipes d’opérateurs de cluster travaillent ensemble à 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.

Meilleure pratique : Contrôler l’accès et le workflow 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) à la branche. Ils définissent également des exigences pour tous les envois (push) vers la branche, comme la transmission 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 workflow 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 dans un environnement de production.

Meilleure pratique : Sécuriser les informations d’identification de déploiement

  • OpenID Connect (OIDC) permet à vos workflows GitHub Action d’accéder aux ressources dans Azure sans avoir à stocker les informations d’identification Azure en tant que secrets GitHub à longue durée de vie.
  • En utilisant des environnements pour le déploiement, vous pouvez configurer des environnements avec des règles de protection et des secrets.
    • Une approche du CI/CD basée sur le tirage avec GitOps vous permet de déplacer les informations d’identification de sécurité vers votre cluster Kubernetes. En évitant de stocker les informations d’identification dans vos outils de CI externes, vous réduisez la surface de risque et gagnez en sécurité. Vous pouvez également réduire les connexions entrantes autorisées et limiter l’accès de niveau administrateur à vos clusters Kubernetes.

Meilleure 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 workflows 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 détecter les vulnérabilités courantes des applications web.

Meilleure pratique : Déployer des images conteneur à partir de registres approuvés uniquement

  • Utilisez Defender pour les conteneurs pour activer le module complémentaire Azure Policy pour Kubernetes.
  • Activez Azure Policy afin que les images conteneur ne puissent être déployées qu’à partir de registres approuvés.

Phase d’exploitation

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

Meilleure pratique : Utiliser Microsoft Defender pour le cloud afin d’activer l’analyse et la surveillance automatisées de vos configurations de production

  • Effectuez une analyse continue pour détecter les dérives dans l’état de vulnérabilité de votre application et mettez en place un processus pour corriger et remplacer les images vulnérables.
  • Implémentez la supervision de la configuration automatique pour les systèmes d’exploitation.
    • Utilisez les recommandations relatives aux conteneurs de Microsoft Defender pour le cloud dans la section Calcul et applications afin d’effectuer des analyses de base de référence pour vos clusters AKS. Recevez une notification dans le tableau de bord de Microsoft Defender pour le cloud lorsque des problèmes de configuration ou des vulnérabilités sont détectés.
    • Utilisez Microsoft Defender pour le 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 les images en cours d’exécution dans Container Registry en activant Defender pour les conteneurs.

Meilleure pratique : Maintenir vos clusters Kubernetes à jour

  • De nouvelles versions de Kubernetes sont fréquemment déployées. Il est important d’avoir une stratégie de gestion du cycle de vie en place pour vous assurer de ne pas prendre du retard et de ne pas perdre la prise en charge. AKS est une offre managée qui vous offre des outils et la flexibilité pour gérer ce processus de mise à niveau. Vous pouvez utiliser les fonctionnalités de maintenance planifiée de la plateforme AKS pour mieux contrôler 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 hebdomadaires du système d’exploitation et du runtime, qui peuvent être appliquées automatiquement via le mode sans assistance ou via Azure CLI pour plus de contrôle et des mises à jour complètes.

Meilleure pratique : Utiliser Azure Policy pour sécuriser et régir vos clusters AKS

  • Après l’installation du 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 (aussi appelées ensembles de stratégies) à votre cluster.
  • Utilisez des stratégies Azure intégrées pour des scénarios courants, comme l’interdiction de l’exécution de conteneurs privilégiés ou l’approbation d’adresses IP externes autorisées uniquement. 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 attributions 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écurisez le trafic entre les pods de charge de travail avec des 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 du 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.

Meilleure pratique : Utiliser Azure Monitor pour la surveillance et les alertes continues

  • Utilisez Azure Monitor pour collecter les journaux et 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 permettant de surveiller l’intégrité de votre solution et d’épingler rapidement toute activité anormale.
    • La surveillance continue avec Azure Monitor s’étend aux pipelines de mise en production afin de réguler ou restaurer les mises en production sur la base des données de surveillance. Azure Monitor ingère également les journaux de sécurité et peut alerter en cas d’activité suspecte.
    • Intégrez vos instances AKS à Azure Monitor et configurez les paramètres de diagnostic de votre cluster.

Meilleure pratique : Utiliser Microsoft Defender pour le cloud pour la surveillance active des menaces

  • Microsoft Defender pour le cloud fournit un monitoring actif des menaces sur AKSe 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érateurs un tableau de bord centralisé pour tous vos pipelines CI/CD. Cette fonctionnalité est particulièrement utile si vous utilisez des plateformes multipipeline comme Azure DevOps et GitHub, ou si vous exécutez des pipelines sur des clouds publics.
  • Defender pour Key Vault peut être utilisé pour détecter les tentatives inhabituelles et suspectes d’accès aux comptes de coffre de clés et peut alerter les administrateurs en fonction de la configuration.
  • Defender pour les conteneurs peut alerter en cas de vulnérabilités détectées dans vos images conteneur stockées sur Container Registry.

Meilleure 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 une surveillance centralisée de la sécurité basée sur les modèles et les règles. Sentinel permet cet accès en toute transparence via des connecteurs de données.

Meilleure 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 afin d’afficher l’ensemble de l’activité et des états. Déterminez quelles opérations ont été effectuées sur les ressources et par qui.
  • Activez la journalisation de requête DNS en appliquant la configuration documentée dans votre ConfigMap personnalisé CoreDNS.
  • Surveiller les tentatives d’accès à des informations d’identification désactivées.
    • Intégrer l’authentification utilisateur pour AKS avec Microsoft Entra ID. Créez des paramètres de diagnostic pour Microsoft Entra ID en envoyant les journaux d’audit et de connexion vers un espace de travail Azure Log Analytics. Configurez les alertes souhaitées (par exemple, lorsqu’un compte désactivé tente de se connecter) au sein d’un espace de travail Azure Log Analytics.

Meilleure 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 dans une solution SIEM comme Microsoft Sentinel pour la surveillance de la sécurité et les alertes.

Contributeurs

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

Auteur principal :

Autres contributeurs :

Étapes suivantes