Mise en place d'une architecture de sécurité Zero Trust pour applications d'entreprise avec Keycloak et Spring Security

Mise en place d'une architecture de sécurité Zero Trust pour applications d'entreprise avec Keycloak et Spring Security

Cet article présente une approche pratique et structurée pour implémenter une architecture Zero Trust pour des applications d'entreprise, en s'appuyant sur Keycloak comme fournisseur d'identité (IdP) et sur Spring Security pour la protection des APIs et des services. Nous couvrons les principes, un schéma d'architecture, des extraits de configuration et les bonnes pratiques opérationnelles.

Principes Zero Trust appliqués aux applications

Principe fondamentaux

Zero Trust signifie « ne jamais faire confiance, toujours vérifier ». Les principes clefs adaptés aux applications sont :

• Identification forte : utiliser l'authentification multifactorielle (MFA) et des identités robustes.
• Moindre privilège : limiter les droits via RBAC/ABAC et tokens avec portée minimale.
• Vérification continue : évaluer le contexte (risque du device, géolocalisation, etc.) à chaque requête.
• Sécurité des communications : chiffrer tout (TLS), envisager mTLS pour service-to-service.
• Micro-segmentation : découper le réseau et contrôler accès par service et API.

Architecture cible

Composants principaux

Une architecture Zero Trust typique avec Keycloak et Spring Security inclut :

• Keycloak : gestion des realms, clients, utilisateurs, rôles et mappers OIDC/JWT.
• API Gateway / Ingress : point d'entrée central pour enforcement, throttling et routage.
• Microservices Spring Boot : configurés en tant que Resource Servers (validation JWT) et/ou OAuth2 clients.
• Service-to-Service identity : certificats ou tokens courts (mTLS + JWT).
• Observabilité et audit : logs d'authentification, traces distribuées, et alerting.

Flux d'authentification simplifié

Exemple de flux : l'utilisateur s'authentifie auprès de Keycloak (Authorization Code + PKCE). Keycloak émet un ID token et un access token (JWT). L'API Gateway valide le token ou le transmet au microservice qui utilise Spring Security pour vérifier la signature via JWKS (issuer-uri).

Exemples de configuration

Configuration Keycloak (haut niveau)

Dans l'interface Keycloak :

• Créer un realm dédié à l'environnement.
• Créer un client pour l'application (type confidential pour backends, public pour SPA/mobile).
• Configurer les mappers pour inclure rôles et claims nécessaires (groups, department, etc.).
• Activer tokens courts, MFA et accès admin restreint.

Spring Boot - Resource Server (validation JWT)

Fichier de configuration : application.yml

spring: security: oauth2: resourceserver: jwt: issuer-uri: https://keycloak.example.com/auth/realms/mon-realm

Configuration Java (Spring Security 5.7+) :

import org.springframework.security.config.annotation.web.builders.HttpSecurity; import org.springframework.security.web.SecurityFilterChain; @Bean public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception { http .authorizeHttpRequests(auth -> auth .requestMatchers("/admin/**").hasRole("ADMIN") .anyRequest().authenticated() ) .oauth2ResourceServer(oauth2 -> oauth2.jwt()); return http.build(); }

Spring Boot - OAuth2 Client (Authorization Code)

Pour les applications server-side qui doivent initier des flux utilisateur :

spring: security: oauth2: client: registration: keycloak: client-id: my-client client-secret: ${KEYCLOAK_CLIENT_SECRET} authorization-grant-type: authorization_code redirect-uri: "{baseUrl}/login/oauth2/code/{registrationId}" provider: keycloak: issuer-uri: https://keycloak.example.com/auth/realms/mon-realm

Bonnes pratiques opérationnelles

Gouvernance et cycle de vie

Gestion des clés JWKS : configurez la rotation automatique et surveillez les erreurs de signature. Limitez la durée de vie des tokens (access tokens courts) et utilisez des refresh tokens avec caution.

Renforcement des contrôles

Activez MFA, examinez les claims JWT pour appliquer des politiques ABAC, et externalisez les décisions complexes à un PDP (ex. OPA) si nécessaire. Utilisez l'API Gateway pour filtrer les requêtes et appliquer des quotas et WAF.

Sécurité inter-services

Pour le service-to-service, privilégiez mTLS ou des tokens mutuellement vérifiables. Limitez l'attaque de replay en utilisant des nonces et l'horodatage sur les communications sensibles.

Observabilité et réponse

Mettez en place une journalisation centralisée des événements d'authentification et d'autorisation. Corrélez les logs avec les traces distribuées pour détecter les anomalies et automatiser les réponses (blocage, re-authentication).

Conclusion

Associer Keycloak et Spring Security permet de construire une architecture Zero Trust robuste : Keycloak joue le rôle d'IdP central et fournisseur de tokens, tandis que Spring Security gère la validation, l'autorisation et l'intégration avec le code applicatif. En combinant des tokens courts, des contrôles contextuels, mTLS et une gouvernance stricte, on obtient une posture de sécurité moderne et adaptée aux environnements distribués.