Le modèle de sécurité traditionnel basé sur la périmètre, souvent visualisé comme une architecture de château-fort, est obsolète. Dans les environnements cloud-natifs modernes, les charges de travail sont éphémères, les limites du réseau sont floues et les menaces proviennent de l’extérieur comme de l’intérieur du réseau. Ce changement nécessite une transition vers l’Architecture Zero Trust (ZTA). Dans ce contexte, « ne jamais faire confiance, toujours vérifier » n’est pas seulement un slogan, mais une exigence fondamentale d’ingénierie.
D’une approche centrée sur le réseau à une approche centrée sur l’identité
Historiquement, le contrôle d’accès reposait sur les adresses IP et les zones réseau. Si une requête provenait du LAN de l’entreprise, elle était considérée comme fiable. Dans un environnement de microservices, cette approche échoue. Les conteneurs s’étendent horizontalement, les pods éphémères changent d’IP constamment et les services communiquent à travers des réseaux publics et privés.
Le Zero Trust déplace l’accent du réseau vers l’identité de l’entité qui effectue la requête. Qu’il s’agisse d’un utilisateur, d’une application ou d’un autre service, celle-ci doit être authentifiée, autorisée et continuellement validée avant tout accès aux données. Ce concept, souvent appelé « Proxying Aware Identity » ou « Mutual TLS (mTLS) », garantit que même si un service est compromis, l’attaquant ne peut pas facilement pivoter vers d’autres services car il ne dispose pas des identifiants appropriés.
Le rôle du Service Mesh
Implémenter le Zero Trust manuellement pour chaque microservice est sujet aux erreurs et non évolutif. C’est ici que les service meshes comme Istio ou Linkerd deviennent des composants d’infrastructure critiques. Un service mesh fournit une couche d’infrastructure dédiée pour la communication entre services, gérant le chiffrement, l’authentification et l’autorisation de manière transparente, sans nécessiter de modifications du code de la logique applicative.
Le mécanisme central de la sécurité centrée sur l’identité dans un service mesh est le mutual TLS (mTLS). Contrairement au TLS standard, où seul le serveur prouve son identité au client, le mTLS exige que les deux parties présentent des certificats. Dans un écosystème de microservices, ces certificats sont généralement émis par une Autorité de Certification (CA) gérée par le plan de contrôle du service mesh.
Mise en œuvre pratique avec Istio
Examinons comment appliquer une politique mTLS stricte dans un service mesh Istio. Par défaut, de nombreux clusters fonctionnent en mode « PERMISSIVE », qui autorise à la fois le trafic en clair et le trafic TLS. Pour une posture Zero Trust réelle, nous devons imposer le mode « STRICT ».
La configuration YAML suivante définit une politique PeerAuthentication qui s’applique à l’ensemble du namespace, exigeant que tout le trafic entrant et sortant soit chiffré et authentifié :
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default
namespace: production
spec:
mtls:
mode: STRICT
De plus, pour garantir que les services ne communiquent qu’avec des pairs autorisés, nous mettons en œuvre une AuthorizationPolicy. Cela empêche les mouvements latéraux en refusant tout trafic qui ne correspond pas explicitement aux règles définies.
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: require-jwt
namespace: production
spec:
selector:
matchLabels:
app: frontend-service
action: ALLOW
rules:
- from:
- source:
requestPrincipals: ["cluster.local/ns/default/sa/backend-service"]
Dans cet exemple, le frontend-service n’acceptera les requêtes que si elles proviennent du compte backend-service, vérifié via un JWT signé. Toute autre source est refusée, même si elle se trouve dans le même cluster Kubernetes.
Vérification continue et identités à courte durée de vie
Une mise en œuvre robuste du Zero Trust va au-delà de l’authentification initiale de la poignée de main. Elle implique une vérification continue de la confiance. Les architectures modernes centrées sur l’identité utilisent des certificats à courte durée de vie (par exemple, valides pendant 1 à 2 heures) émis par une CA distribuée. Cela minimise l’impact d’un certificat compromis. Si une clé privée est divulguée, elle expire rapidement, limitant la fenêtre d’opportunité pour un attaquant.
De plus, l’intégration avec des fournisseurs d’identité externes (IdP) permet un contrôle d’accès fin basé sur les attributs des utilisateurs, les rôles et le contexte. Cela est particulièrement important pour les passerelles API qui exposent les microservices internes aux consommateurs externes.
Conclusion
Implémenter le Zero Trust dans les microservices est un voyage, pas une destination. Cela nécessite un changement culturel vers une défense en profondeur et l’adoption d’outils centrés sur l’identité tels que les service meshes. En imposant le mutual TLS, des politiques d’autorisation strictes et des identifiants à courte durée de vie, les organisations peuvent réduire considérablement leur surface d’attaque et empêcher les mouvements latéraux. Alors que nous avançons davantage dans l’ère du calcul distribué, faire de l’identité le nouveau périmètre n’est plus une option, c’est une nécessité pour une architecture logicielle résiliente.