Externaliser le contrôle d'accès

Des autorisations dispersées et difficiles à maintenir

Le code spaghetti des autorisations

Dans une approche traditionnelle, les règles d’autorisation sont dispersées dans le code applicatif :

// Exemple typique de code d'autorisation "en dur"
public Patient getPatient(Long id, User user) {
    Patient patient = patientRepository.findById(id);

    if (user.hasRole("ADMIN")) {
        return patient;
    }

    if (user.getDepartment().equals(patient.getDepartment())) {
        if (user.hasRole("PHYSICIAN") || user.hasRole("NURSE")) {
            return patient;
        }
    }

    if (patient.getCareTeam().contains(user.getId())) {
        return patient;
    }

    throw new AccessDeniedException("Accès refusé");
}

Ce code présente plusieurs problèmes :

• Couplage fort : la logique métier et les règles d’accès sont mélangées
• Duplication : ces vérifications sont répétées à travers l’application
• Rigidité : toute modification nécessite un redéploiement
• Opacité : impossible de répondre à “qui peut accéder à quoi ?”

Les enjeux dans le secteur de la santé

Dans le domaine hospitalier, les exigences sont particulièrement strictes :

• Conformité réglementaire (RGPD, HDS, HIPAA)
• Traçabilité des accès aux données sensibles
• Gestion fine des droits selon les rôles et le contexte
• Procédures d’urgence (“break-glass”)

La solution : l’externalisation avec Big ACL

Architecture externalisée

L’externalisation du contrôle d’accès repose sur le pattern PDP/PEP (Policy Decision Point / Policy Enforcement Point) :

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│   Application   │────▶│   PEP (SDK)     │────▶│   PDP (OPA)     │
│   Hospital      │     │   Big ACL       │     │   Policies      │
└─────────────────┘     └─────────────────┘     └─────────────────┘
                                                        │
                                                        ▼
                                               ┌─────────────────┐
                                               │   PAP (Console) │
                                               │   Big ACL       │
                                               └─────────────────┘

• PEP (Policy Enforcement Point) : intercepte les requêtes et applique les décisions
• PDP (Policy Decision Point) : évalue les règles et prend les décisions
• PAP (Policy Administration Point) : interface de gestion des politiques

Démonstration : l’application Hospital Demo

Notre application de démonstration simule un portail patient hospitalier avec des règles d’accès sophistiquées : accès selon le département, le rôle, l’appartenance à l’équipe de soins, et procédure d’urgence “break-glass”.

Le contrôle d’accès en action

Selon le profil de l’utilisateur, les droits varient automatiquement. Un médecin des urgences voit uniquement les patients de son service, tandis qu’un chef de département a une vue élargie.

Les politiques en Rego

Un langage déclaratif et expressif

Les règles d’autorisation sont définies en Rego, le langage de politique d’Open Policy Agent :

package hospital.authz

# Règle principale d'autorisation
allow {
    input.action == "view"
    is_care_team_member
}

allow {
    input.action == "view"
    same_department
    is_clinical_staff
}

# Un membre de l'équipe de soins peut toujours accéder
is_care_team_member {
    input.subject.id == input.resource.careTeamUserIds[_]
}

# Vérification du département
same_department {
    input.subject.department == input.resource.department
}

# Personnel clinique
is_clinical_staff {
    input.subject.roles[_] == "ROLE_PHYSICIAN"
}

is_clinical_staff {
    input.subject.roles[_] == "ROLE_NURSE"
}

Avantages des politiques déclaratives

1. Lisibilité : les règles sont compréhensibles par les non-développeurs
2. Testabilité : les politiques peuvent être testées unitairement
3. Auditabilité : historique complet des modifications
4. Réutilisabilité : mêmes politiques pour plusieurs applications

Administration avec Big ACL PAP

Console de gestion centralisée

Le PAP Big ACL offre une interface intuitive pour gérer les politiques : édition en temps réel, simulation avant déploiement, et traçabilité complète des décisions.

Les avantages concrets

1. Séparation des préoccupations

Le code applicatif se concentre sur la logique métier :

// Avant : logique d'autorisation mélangée
public Patient getPatient(Long id, User user) {
    // 50 lignes de vérifications...
}

// Après : délégation au PDP
@PreAuthorize("@pdp.check('view', #id)")
public Patient getPatient(Long id) {
    return patientRepository.findById(id);
}

2. Modification sans redéploiement

Les règles peuvent être mises à jour en temps réel via le PAP, sans toucher au code ni redéployer l’application.

3. Conformité simplifiée

• Audit : “Montrez-moi toutes les règles d’accès aux données sensibles”
• Documentation : les politiques servent de documentation vivante
• Certification : preuves tangibles pour les auditeurs

4. Réduction des risques

• Tests automatisés des politiques
• Revue de code séparée pour la sécurité
• Rollback instantané en cas de problème

5. Évolutivité

Les mêmes politiques peuvent être partagées entre :

• Applications web et mobiles
• APIs et microservices
• Batch et traitements asynchrones

Conclusion

L’externalisation du contrôle d’accès avec Big ACL transforme la gestion des autorisations :

Aspect	Avant	Après
Localisation des règles	Dispersées dans le code	Centralisées dans le PAP
Modification	Redéploiement requis	Temps réel
Audit	Manuel et incomplet	Automatique et exhaustif
Tests	Complexes	Unitaires et automatisés
Compréhension	Réservée aux développeurs	Accessible aux métiers

Pour les applications manipulant des données sensibles comme les dossiers médicaux, cette approche n’est plus un luxe mais une nécessité pour garantir sécurité, conformité et agilité.

---

Ressources complémentaires :

• Documentation Big ACL
• Open Policy Agent

Cet article a été rédigé par l’équipe Big ACL. Pour toute question, contactez-nous à contact@big-acl.com