Obtenez un aperçu de la manière dont vous pouvez mettre en œuvre des microservices sécurisés pour votre organisation, en vous concentrant sur quatre piliers clés.
L’architecture microservices décompose les applications en plusieurs services indépendants qui communiquent entre eux via des interfaces définies.
Il s’agit d’une approche populaire pour le déploiement d’applications cloud natives, car elle vous permet de faire évoluer chaque élément individuellement, sans affecter les autres composants.
Les applications en bloc traditionnelles sont souvent difficiles à exploiter car leurs composants logiques fonctionnent comme une seule unité, un seul service fournissant l’ensemble des fonctionnalités de votre application, de l’authentification au paiement des clients.
La séparation de ces éléments en deux microservices permet une utilisation plus efficace des ressources lorsque de nombreux utilisateurs se connectent mais que relativement peu de paiements sont effectués.
Vous pouvez ainsi faire évoluer votre service d’authentification sans modifier la plate-forme de paiement.
Si l’exploitation de votre application à l’aide de microservices apporte une flexibilité accrue, elle s’accompagne également d’exigences uniques en matière de sécurité : De multiples composants signifient de multiples actifs à protéger.
Mais sécuriser vos microservices ne doit pas être difficile, si vous adoptez une approche proactive basée sur les meilleures pratiques.
L’importance de la sécurité des microservices
Les microservices sont des applications autonomes qui assemblent collectivement les fonctionnalités de votre système destinées aux utilisateurs.
Sans microservices, les systèmes sont mis en œuvre sous la forme d’un seul composant (bloc) responsable de chaque fonctionnalité.
En revanche, avec une architecture de microservices, vous déployez les composants individuellement, vous les rendez responsables de sous-systèmes particuliers et vous introduisez un réseau interfacé pour que les services puissent se contacter.
Votre application Web appelle ensuite votre service d’authentification, votre plate-forme de paiement et d’autres composants en utilisant les API fournies par ces microservices.
Points d’entrée multiples (entrypoints)
Le modèle des microservices crée de multiples points d’entrée possibles dans votre système, chacun d’entre eux pouvant exposer des vulnérabilités.
Un plus grand nombre de voies à exploiter par les attaquants signifie une surface d’attaque plus grande.
Pour sécuriser votre système, il faut donc protéger les microservices individuels et leurs interconnexions.
Si vous ne le faites pas, une attaque contre une voie d’accès (par exemple, votre API Web ou votre service d’authentification) pourrait permettre un mouvement latéral vers d’autres services non liés.
Mass scale
Un autre défi pour la sécurité des microservices est l’échelle que peuvent atteindre les systèmes distribués.
En réalité, la plupart des systèmes auront d’autres services que l’API Web, le fournisseur d’authentification et la plate-forme de paiement mentionnés précédemment.
En tant que tel, vous devez introduire autant de divisions de services que possible afin de profiter réellement des avantages de l’architecture microservices.
Aujourd’hui, il n’est pas rare que les systèmes comprennent des centaines de composants individuels, chacun étant déployé en tant que microservice autonome.
Avec autant de pièces mobiles, les risques d’erreur sont plus grands. Il est donc impératif que chaque service soit correctement sécurisé.
Comment sécuriser les microservices
Lorsqu’il s’agit de sécuriser un microservice, il y a quatre domaines fondamentaux à prendre en compte :
- Accès aux microservices : Les microservices doivent être isolés des réseaux externes, sauf s’ils sont spécifiquement destinés à l’accès des utilisateurs finaux. Même si votre API, votre site web et votre CDN doivent être ouverts, les utilisateurs publics ne doivent pas pouvoir accéder directement à votre service de paiement ou à l’hôte de votre base de données.
- Accès entre microservices : Le blocage de l’accès entre les microservices est tout aussi important, car il réduit le rayon d’action en cas de compromission d’un service. Les services qui ne s’appellent pas les uns les autres doivent être physiquement isolés. Ainsi, si un attaquant accède à votre couche d’authentification, il ne sera pas en mesure d’envoyer un ping à votre système de paiement.
- Contenu des conteneurs de microservices : Tous les efforts déployés pour renforcer votre architecture de microservices seront vains si les charges de travail contenues dans vos conteneurs présentent des vulnérabilités. Un audit régulier des listes de paquets, l’utilisation d’outils d’analyse automatique des dépendances et la mise à jour des meilleures pratiques en matière de sécurité des conteneurs contribueront à atténuer le risque de compromission des conteneurs.
- Environnement de déploiement : La sécurité de vos microservices dépend de votre hygiène de sécurité globale et de la sécurité de votre environnement de déploiement. Les charges de travail critiques ne doivent être déployées que sur des clouds robustes qui répondent aux normes de sécurité et de conformité que vous attendez. Ne négligez pas non plus votre propre responsabilité : La protection de vos comptes au moyen d’une authentification multifactorielle, la mise en place d’un contrôle d’accès basé sur les rôles et la rotation régulière des clés et des certificats sont également essentielles avec le modèle des microservices.
Il n’existe pas de méthode unique pour renforcer vos microservices ou garantir la protection de vos applications. Mais si vous vous concentrez sur les quatre principes présentés ci-dessous, il sera plus facile de repérer rapidement les vulnérabilités potentielles.
1. Contrôler l’accès aux microservices (nord-sud)
Dans la plupart des cas, les microservices que vous créez sont des microservices internes qui alimentent des composants spécifiques de votre système. Ils ne doivent pas être accessibles en dehors de votre cluster Kubernetes ou de votre environnement cloud.
En bloquant l’accès à tous les services publics, sauf ceux qui sont essentiels, vous réduirez la probabilité que des vulnérabilités dans les API de service soient découvertes et exploitées.
Cette couche de protection, appelée sécurité “north-south”, sécurise le périmètre de vos services en créant une barrière qui sépare votre système du réseau public.
Si des mesures de protection nord-sud efficaces empêchent les attaquants de pénétrer dans votre système, elles ne doivent pas être votre seule ligne de défense.
UsingAPI gateways
Les passerelles API constituent un moyen fiable de mettre en œuvre une sécurité nord-sud, la passerelle étant placée entre vos utilisateurs et les services derrières qu’elle protège.
Pour utiliser correctement une passerelle, vous devez configurer votre réseau de manière à ce que la passerelle traite toutes les demandes externes.
Le logiciel évalue alors chaque demande à l’aide des règles que vous avez définies. Ces règles détermineront si l’accès doit être accordé et achemineront ensuite le trafic vers le service approprié.
Le type de passerelle le plus simple est un proxy inverse qui achemine le trafic vers des points d’extrémité (endpoints) figurant sur une liste blanche.
Vous pouvez utiliser un logiciel reconnu et populaire tel que NGINX pour en configurer un. Les contrôleurs d’entrée Kubernetes comptent également comme des passerelles, car ils acheminent automatiquement le trafic vers les services spécifiques que vous choisissez.
Le fait de placer tous vos services derrière une passerelle cohérente permet une surveillance centralisée et une visibilité claire des points d’extrémité accessibles au public. En revanche, il serait risqué de ne pas utiliser de passerelle, car vous pourriez exposer involontairement des services qui devraient être privés.
Mise en œuvre de la limitation des taux
La limitation du débit protège contre l’utilisation abusive de vos services. Les attaquants peuvent tenter de submerger votre infrastructure en utilisant des méthodes de force brute, telles que les informations d’identification ou les endpoints communs comme /auth et /admin.
De même, les attaques par déni de service (Dos) se produisent lorsque des acteurs malveillants envoient un nombre excessif de requêtes, empêchant ainsi le trafic légitime d’être traité.
La limitation du débit offre une protection contre ces deux méthodes d’attaque en suivant le nombre de requêtes effectuées par chaque adresse IP cliente.
L’envoi d’un trop grand nombre de demandes au cours d’une période donnée entraîne l’abandon des demandes suivantes pour cette adresse IP.
La surcharge liée au traitement de la vérification de la limitation de débit est bien inférieure à ce qu’elle serait si la demande était autorisée à atteindre son serveur de destination sans entrave.
Les passerelles API et la limitation de débit se complètent donc mutuellement.
L’application de la limitation de débit dans votre passerelle API garantit qu’elle sera appliquée globalement, avant que le trafic n’atteigne les endpoints de votre microservice.
La limitation de débit peut également être intégrée directement dans des services spécifiques pour une configuration plus fine et une protection interservices améliorée.
2. Contrôler les communications internes entre les microservices (est-ouest)
Alors que la sécurité nord-sud sécurise votre périmètre, le plan est-ouest traite du trafic circulant entre vos services.
Chaque composant doit être isolé, sans possibilité de se connecter à d’autres services ou de les découvrir, même s’ils sont déployés de manière adjacente.
Vous pouvez créer des exceptions pour faciliter les communications interservices légitimes de votre application en désignant les composants qui peuvent appeler un service (par exemple, un générateur de factures qui fait des demandes à votre “payment layer”).
Ce modèle “blocked-by-default,” et “enabled-on-demand” vous oblige à être intentionnel lorsque vous ouvrez des interfaces.
Permettre à des services non liés de s’accéder les uns aux autres ouvre des voies aux acteurs de la menace pour se déplacer dans votre système.
Par conséquent, le fait de n’autoriser qu’un nombre minimal de connexions à chaque composant ralentira les attaquants et atténuera les dommages éventuels.
Si des acteurs malveillants parviennent à compromettre un système à faible risque, ils ne devraient pas avoir l’occasion d’organiser des menaces contre des systèmes plus sensibles.
Les mesures de sécurité est-ouest concernent la manière dont vos microservices sont isolés et connectés individuellement.
Grâce à ces protections, il est plus difficile pour une attaque contre un service de se propager à d’autres services.
“East-west” vous aide également à atteindre un modèle de sécurité robuste à confiance zéro (zero trust) en reconnaissant la faillibilité potentielle de la passerelle API, ainsi que les risques que les services individuels représentent les uns pour les autres.
Protection des services avec autorisation
L’autorisation au niveau des services permet de mettre en œuvre des politiques de contrôle d’accès spécifiques pour chaque application de votre “stack”.
Cela peut prendre plusieurs formes différentes, notamment des approches centralisées et décentralisées de la gestion des politiques.
Decentralized vs. centralized authorization
L’autorisation décentralisée intègre les décisions et l’application des politiques dans le code de vos microservices.
Chaque service définit les règles, les attributs et les contrôles d’application dont il a besoin pour vérifier si une demande particulière est autorisée à être traitée.
Cette approche est idéale lorsque vos services ont des exigences d’autorisation très spécifiques.
Les modèles d’autorisation centralisés placent vos politiques et leurs routines d’évaluation dans un référentiel distinct avec lequel les microservices peuvent interagir.
Le code de votre microservice communique avec le système d’autorisation en utilisant une API qu’il fournit.
Le microservice devra fournir l’identité de l’utilisateur et tout attribut pertinent pour le “target endpoint”.
Le fournisseur d’autorisations évalue les informations et produit une réponse “d’accept” ou de “reject”.
La centralisation n’est pas aussi souple, mais elle peut être plus facile à mettre en place et à maintenir, car il existe un endroit central pour définir les politiques d’autorisation, mettre en œuvre leurs routines d’application et enregistrer les associations d’utilisateurs.
Elle fonctionne bien avec les solutions de fédération d’identité telles que OAuth et SAML.
Authorization tokens
Les microservices s’authentifient généralement entre eux en incluant un jeton d’autorisation “token” signé dans leurs demandes HTTP.
Chaque jeton doit comprendre l’identité du service appelant et les autorisations qui lui ont été accordées.
Des normes telles que les JSON Web Tokens (JWT) permettent au service destinataire de vérifier si le jeton est authentique.
Les jetons peuvent toutefois être difficiles à déployer dans de nombreux services.
Mutual TLS (mTLS) est une méthode alternative qui fonctionne au niveau du transport.
Avec mTLS, les microservices se voient attribuer leurs propres paires de clés publiques/privées qui leur permettent de s’authentifier auprès d’autres services via le protocole mTLS.
Cela permet de garder les communications réseau secrètes tout en facilitant l’autorisation intégrée.
Cependant, vous devrez toujours émettre des certificats pour chaque service avant que l’autorisation mTLS puisse être vérifiée.
Activer la sécurité au niveau du transport
Les communications entre les services doivent également être sécurisées au niveau du réseau .
TLS peut être utilisé pour chiffrer le trafic de votre cluster, empêcher les écoutes clandestines et vérifier l’identité des appelants.
TLS peut être activé pour les microservices déployés sur Kubernetes en garantissant que tout le trafic transite par des services protégés par vos propres certificats.
L’ opérateur cert-manager est le moyen le plus simple d’automatiser la configuration TLS dans votre cluster.
Il vous permet de provisionner de nouveaux certificats en créant des objets Certificate.
Le certificat est une définition de ressource personnalisée incluse avec l’opérateur.
Les maillages de services dédiés comme Istio facilitent encore d’avantage la mise en réseau sécurisée de nombreux services différents.
Ceux-ci complètent les orchestrateurs de conteneurs tels que Kubernetes, offrant une meilleure prise en charge de la gestion du trafic, des autorisations et de la sécurité interservices.
Mise en œuvre des politiques de mise en réseau Kubernetes
Les règles de mise en réseau sont un outil Kubernetes spécifique pour la mise en œuvre de la sécurité est-ouest.
Vous pouvez définir des critères par pod qui définissent quels autres pods sont autorisés à communiquer avec la cible.
Cette politique simple stipule que les pods avec l’ étiquette component=payment ne sont accessibles que par d’autres pods avec l’ étiquette component=api :
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: payment-access
spec:
podSelector:
matchLabels:
component: payment
policyTypes:
- Ingress
- Egress
ingress:
- from:
- podSelector:
matchLabels:
component: api
egress:
- to:
- podSelector:
matchLabels:
component: api
Les champs d’entrée et de sortie peuvent configurer un comportement distinct pour le trafic entrant et sortant, respectivement.
Les politiques de réseau permettent un contrôle précis des flux de trafic.
L’exemple suivant autorise le trafic entrant à partir de pods dans une plage d’adresses IP spécifique :
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: payment-access
spec:
podSelector:
matchLabels:
component: payment
policyTypes:
- Ingress
ingress:
- from:
- ipBlock:
Les politiques de réseau sont donc l’un des principaux moyens de mettre en œuvre la sécurité est-ouest dans les clusters Kubernetes.
3. Auditez vos microservices avant le déploiement
La sécurité est aussi bonne que le maillon le plus faible de la chaîne.
Une porte dérobée dans un package utilisé par l’un de vos services pourrait être exploitée pour permettre le mouvement vers d’autres services.
Un audit approfondi de vos conteneurs avant de les déployer dans votre environnement contribuera à atténuer ces risques.
De plus, l’utilisation d’ images de base renforcées ou l’assemblage de vos propres images à partir de zéro vous aidera à vous assurer qu’il n’y a rien de dangereux qui se cache à l’intérieur.
Des techniques de test de sécurité automatisées telles que DAST, SAST et IAST peuvent être utilisées pour détecter d’éventuelles failles dans votre code.
De même, les scanners de vulnérabilité peuvent aider à identifier les packages redondants et obsolètes dans vos images de conteneur.
Les scanners modernes couvrent à la fois les dépendances utilisées par votre code et les bibliothèques de système d’exploitation installées avec les gestionnaires de packages système.
L’adoption d’un état d’esprit sécurisé dès la conception signifie que les développeurs, les opérateurs et les chefs de projet doivent donner la priorité à la sécurité et incorporer des modifications de conception pour remédier à toute faiblesse.
Conformément à cette approche, vous devez renforcer vos microservices au fur et à mesure que vous les créez.
Les microservices sont dynamiques, complexes et assemblent des systèmes à grande échelle.
Il est donc important de planifier à l’avance et d’établir une sécurité solide au niveau des conteneurs comme première ligne de défense.
Numérisation d’images de conteneurs
Les packages tiers inclus en tant que dépendances logicielles peuvent être obsolètes ou héberger des vulnérabilités et des CVE de type zero-day.
Vous pouvez identifier ces risques avant de déployer en scannant vos images de conteneur avec des outils tels que Trivy :
$ trivy image ubuntu: dernière
La commande produit une liste des vulnérabilités trouvées dans les packages du système d’exploitation de l’image et les dépendances du code source :
ubuntu:latest (ubuntu 22.04)
============================
Total: 16 (UNKNOWN: 0, LOW: 12, MEDIUM: 4, HIGH: 0, CRITICAL: 0)
┌──────────────┬────────────────┬──────────┬──────────────────────────┬───────────────┬──────────────────────────────────────────────────────────────┐
│ Library │ Vulnerability │ Severity │ Installed Version │ Fixed Version │ Title │
├──────────────┼────────────────┼──────────┼──────────────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ bash │ CVE-2022-3715 │ MEDIUM │ 5.1-6ubuntu1 │ │ bash: a heap-buffer-overflow in valid_parameter_transform │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2022-3715 │
├──────────────┼────────────────┼──────────┼──────────────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ coreutils │ CVE-2016-2781 │ LOW │ 8.32-4.1ubuntu1 │ │ coreutils: Non-privileged session can escape to the parent │
│ │ │ │ │ │ session in chroot │
│ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2016-2781 │
├──────────────┼────────────────┤ ├──────────────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ gpgv │ CVE-2022-3219 │ │ 2.2.27-3ubuntu2.1 │ │ gnupg: denial of service issue (resource consumption) using │
│ │ │ │ │ │ compressed packets │
...
Toutes les conclusions ne seront pas nécessairement applicables au contexte dans lequel vos services sont déployés.
Mais résoudre autant de problèmes que possible avant le déploiement , en mettant à jour les packages concernés ou en sélectionnant des alternatives plus sûres, réduira le risque que du code compromis atteigne la production.
Intégrer la sécurité dès la conception
La sécurité est déplacée vers la gauche en en faisant une partie intégrante de votre stratégie, de la conception au code et aux opérations.
Au fur et à mesure que les chefs de projet définissent les services et que les développeurs commencent à les créer, les deux équipes doivent anticiper les nouveaux risques de sécurité avant qu’ils ne soient introduits.
Lorsque vous exécutez des centaines de services faiblement couplés, le modèle de sécurité hérité après coup ne suffira tout simplement pas.
La sécurité basée sur les risques est une autre stratégie efficace pour naviguer dans l’environnement actuel des menaces.
Des analyses automatisées et des examens réguliers des développeurs peuvent aider à identifier les risques .
Les données des nouveaux risques sont ensuite combinées avec des informations plus anciennes pour déterminer les priorités.
Cela permet de remédier plus rapidement aux menaces critiques et d’éliminer la fatigue liée à l’alerte.
Les développeurs aussi jouent un rôle central dans la sécurité des microservices.
Le respect de pratiques de codage sécurisé aide à prévenir les failles de sécurité et réduit le temps de correction.
L’éducation et la formation des développeurs, l’analyse de simulation et une suite complète de tests de sécurité contribueront également à assurer un cycle de vie de développement logiciel plus sécurisé .
4. Renforcez votre environnement cloud
Le renforcement de l’environnement qui héberge votre déploiement est le dernier élément de la sécurité des microservices.
Les mesures d’hygiène de base en matière de sécurité du cloud (par exemple, limiter les privilèges des utilisateurs et faire pivoter régulièrement les tokens d’accès) sont essentielles, mais il existe également des bonnes pratiques spécifiques pour les systèmes distribués comme Kubernetes.
Configurer Kubernetes RBAC
Le système Kubernetes RBAC doit être utilisé pour configurer l’accès pour chaque utilisateur et compte de service dans votre cluster.
Restreindre les comptes aux privilèges minimaux que leurs fonctions exigent améliorera également votre posture de sécurité.
En plus d’atténuer le risque en cas de perte ou de vol d’informations d’identification, cela offre également une protection si les tokens de compte de service sont compromis par des violations des systèmes tiers auxquels ils ont été distribués .
RBAC est configuré en créant des objets “Role” qui permettent chacun un ensemble d’actions dans votre cluster.
Les rôles sont liés aux utilisateurs et aux comptes de service par des objets “RoleBinding”.
“Role” et “RoleBinding” se rapportent à des ressources avec espace de noms ; les similaires ClusterRole et ClusterRoleBinding traitent des interactions avec les fonctions au niveau du cluster.
Vous trouverez ci-dessous un exemple de rôle permettant de répertorier et de créer des pods :
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: demo-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "create"]
Grant the role to a user called demo-user by adding the following RoleBinding:
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: demo-role-binding
subjects:
- kind: User
name: demo-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: demo-role
apiGroup: rbac.authorization.k8s.io
L’utilisateur demo-user est désormais autorisé à exécuter ces commandes :
kubectl run nginx --name nginx:latestkubectl get pod demo-podkubectl get pods
D’autres commandes, telles que kubectl delete pod demo-pod , entraîneront une erreur d’authentification.
Cela empêche les utilisateurs et les comptes de service d’effectuer des actions qu’ils n’ont aucune raison légitime d’effectuer.
Encrypting secrets
La distribution standard de Kubernetes ne chiffre pas les “Secrets data at rest”.
Au lieu de cela, les mots de passe sensibles, les clés API et les certificats que vous stockez dans les objets secrets sont conservés en texte brut dans l’instance etcd du cluster. Cela pourrait potentiellement permettre une exfiltration facile par des attaquants.
Vous pouvez configurer le chiffrement de ces données en configurant le serveur d’API Kubernetes pour utiliser l’un des fournisseurs de chiffrement disponibles.
Cela repose sur un objet EncryptionConfiguration qui définit la norme de chiffrement et la clé secrète à utiliser.
Tout d’abord, créez votre manifeste EncryptionConfiguration. Cet exemple utilise le fournisseur aesgcm :
apiVersion: apiserver.config.k8s.io/v1
kind: EncryptionConfiguration
resources:
- resources:
- secrets
providers:
- aesgcm:
keys:
- name: secret-key
secret: <YOUR_SECRET_HERE>
To generate your secret, run the following command:
$ head -c 32 /dev/urandom | base64
Ensuite, vous devez modifier le manifeste de votre pod kube-apiserver afin qu’il utilise votre nouvelle configuration de chiffrement au démarrage.
Pour les clusters gérés par Kubeadm, le manifeste du pod est disponible à l’adresse : /etc/kubernetes/manifests/kube-apiserver.yaml .
Recherchez le champ spec.containers.command et ajoutez l’ indicateur encryption-provider-config pour référencer le chemin d’accès à votre manifeste EncryptionConfiguration :
...
spec:
containers
...
- command:
- kube-apiserver
...
- --encryption-provider-config=/path/to/encryptionconfiguration.yaml
...
Redémarrez le serveur d’API après avoir effectué cette modification.
Les secrets nouvellement stockés seront désormais chiffrés, mais les valeurs existantes ne seront pas affectées.
Vous pouvez chiffrer les secrets que vous avez déjà créés en itérant dessus et en mettant à jour leurs valeurs.
Utilisez la commande Kubectl suivante :
$ kubectl get secrets –all-namespaces -o json | kubectl remplacer -f –
Scanner votre cloud
Les scanners de sécurité cloud offrent un moyen pratique de détecter les erreurs de configuration et les faiblesses de sécurité.
L’ utilisation régulière d’outils tels qu’Amazon Inspector , le scanner de vulnérabilités d’Oracle OCI ou le scanner intégré de Google Cloud peut vous alerter des vulnérabilités de vos déploiements et de votre infrastructure de gestion.
Même si un résultat positif ne garantit pas une protection complète, ces outils peuvent vous aider à découvrir efficacement des opportunités d’amélioration.
Par exemple, Amazon Inspector analyse en permanence vos charges de travail AWS pour les vulnérabilités connues, en sondant vos machines virtuelles, vos conteneurs, vos règles de mise en réseau et d’autres actifs pour identifier les menaces en temps réel.
Il émet ensuite un score de risque de sécurité qui vous tient informé de votre posture de sécurité.
Les autres fournisseurs de cloud offrent des fonctionnalités similaires dans leurs propres outils.
Ces méthodes vous donnent des résultats rapides et précis sans aucune intervention manuelle.
Sécurisez les microservices et déployez-les en toute confiance
Les microservices sont une partie essentielle du développement cloud natif moderne mais avec autant de composants formant un réseau complexe de connexions, la sécurisation de vos microservices peut être une tâche ardue.
Une seule vulnérabilité dans votre réseau de services, vos packages de conteneurs ou votre environnement cloud pourrait être exploitée pour enchaîner une attaque plus importante.
Bien qu’une architecture de microservices efficace puisse faciliter le développement et le déploiement, même les meilleures implémentations peuvent contenir des failles de sécurité.
Mais la mise en œuvre des techniques abordées dans cette série pour renforcer votre environnement vous permettra de déployer des services en toute confiance.
La plateforme de gestion des risques Vulcan Cyber® vous permet de hiérarchiser et de corriger les vulnérabilités de manière transparente, afin que vous puissiez gérer les risques à grande échelle.
Obtenez votre essai gratuit dès aujourd’hui et commencez à prendre vos risques en main.
Source : Vulcan Cyber
