reviewing-security-architecture

Architecture d'authentification

Gestion des tokens

Examinez ces aspects de l'authentification basée sur les tokens :

Gestion des sessions

• Les sessions côté serveur doivent avoir des délais d'expiration absolus (durée maximale de session) et des délais d'inactivité
• Les identifiants de session doivent être cryptographiquement aléatoires et suffisamment longs (128+ bits d'entropie)
• Régénérez l'ID de session après les changements d'état d'authentification (connexion, escalade de privilèges)
• Liez les sessions aux propriétés du client si possible (plage IP, user agent) pour la détection d'anomalies

Stockage des identifiants

• Les mots de passe doivent être hashés avec une KDF moderne : Argon2id (préféré), bcrypt, ou PBKDF2 avec un facteur de travail élevé et un salt unique
• Ne jamais utiliser seules les fonctions de hash cryptographiques brutes pour le hachage de mots de passe (trop rapide, pas de salt par défaut)
• Les salts doivent être uniques par identifiant pour prévenir que les rainbow-tables n'accélèrent les attaques par force brute

Motifs d'autorisation

Contrôle d'accès basé sur les rôles (RBAC)

// CORRECT — vérification de rôle explicite au niveau de la couche API
[Authorize(Roles = "Admin")]
public async Task<IActionResult> DeleteUser(Guid userId)

// FAUX — vérification du rôle en logique métier avec comparaison de chaîne
if (currentUser.Role == "admin") // Fragile, sensible à la casse, facile à contourner

Autorisation au niveau des objets

// FAUX — fait confiance au userId de la route, aucune vérification de propriété
public async Task<Cipher> GetCipher(Guid cipherId) {
    return await _cipherRepository.GetByIdAsync(cipherId);
}

// CORRECT — vérifier que l'utilisateur demandeur possède la ressource
public async Task<Cipher> GetCipher(Guid cipherId) {
    var cipher = await _cipherRepository.GetByIdAsync(cipherId);
    if (cipher.UserId != _currentContext.UserId)
        throw new NotFoundException();
    return cipher;
}

Principes d'autorisation

• Vérifier à chaque couche. Contrôleur API, couche de service et accès aux données doivent tous appliquer l'autorisation. Ne vous fiez pas à un seul point de contrôle.
• Privilège minimal. Accordez les permissions minimales nécessaires. Refusez par défaut.
• Échec en fermé. Si une vérification d'autorisation échoue ou lève une exception, refusez l'accès. Ne basculez jamais en ouvert.
• Ne faites pas confiance à l'autorisation côté client. Les contrôles de visibilité de l'UI sont de l'UX, pas de la sécurité. Appliquez toujours côté serveur.

Protection des données

Chiffrement au repos

• Tous les données sensibles doivent être chiffrées au repos en utilisant AES-256 ou équivalent
• Les clés cryptographiques NE DOIVENT JAMAIS être stockées directement accessibles dans une base de données, sans être enveloppées par une autre clé
• Utilisez le chiffrement par enveloppe : données chiffrées avec une clé de chiffrement de données (DEK), DEK chiffrée avec une clé de chiffrement de clés (KEK) dans un système de gestion des clés
• Le chiffrement de bout en bout de Bitwarden garantit que les données du coffre sont chiffrées avant de quitter le client

Chiffrement en transit

• TLS 1.2 minimum, TLS 1.3 préféré
• Désactivez les anciens protocoles (SSL 3.0, TLS 1.0, TLS 1.1)
• Utilisez des cipher suites forts (ECDHE pour l'échange de clés, AES-GCM pour le chiffrement)
• Certificate pinning pour les applications mobiles le cas échéant
• La communication service-à-service interne doit aussi utiliser TLS

Classification des données

Lors de l'examen de l'architecture, classifiez les données :

Limites de confiance

Une limite de confiance existe partout où les données traversent des composants avec différents niveaux de confiance. Chaque traversée doit être validée.

Limites de confiance communes

Client ←→ API Gateway         (contrôlé par l'utilisateur → contrôlé par le serveur)
API Gateway ←→ Backend Service (exposé à internet → interne)
Backend Service ←→ Database    (application → stockage de données)
Service ←→ External API        (interne → tiers)
Browser ←→ Browser Extension   (contexte de page → contexte d'extension)
Main Thread ←→ Web Worker      (contextes d'exécution différents)

Validation aux limites de confiance

À chaque traversée de limite :

1. Validez toutes les entrées — type, format, plage, longueur. Ne faites pas confiance à la validation en amont.
2. Authentifiez l'appelant — vérifiez l'identité avant de traiter les requêtes.
3. Autorisez l'action — vérifiez que l'appelant a la permission pour cette opération spécifique.
4. Sanitisez la sortie — encodez/échappez les données selon le contexte de destination.
5. Journalisez la traversée — les traversées de limites pertinentes pour la sécurité doivent être auditables.

Principes Zéro-Confiance

• Ne faites pas confiance à la localisation réseau interne comme proxy pour l'authentification
• Chaque appel service-à-service doit être authentifié et autorisé
• Supposez que le réseau est compromis — chiffrez toutes les communications internes
• Validez les données des services internes aussi rigoureusement que les entrées externes

Matériel de référence

Pour des tableaux de consultation détaillés et des exemples de code, consultez :

• references/crypto-algorithms.md — Tableau de sélection d'algorithmes (recommandés vs. dépréciés) et exemples de code d'anti-motifs cryptographiques courants
• references/architectural-anti-patterns.md — Anti-motifs d'architecture de sécurité courants (confiance implicite, points de défaillance unique, paramètres par défaut non sécurisés, authentification monolithique) avec correctifs

Connexion à la modélisation des menaces

L'examen de sécurité architecturale alimente directement le processus de modélisation des menaces :

• L'identification des limites de confiance informe où tracer les limites dans les diagrammes de flux de données
• Les faiblesses architecturales deviennent des menaces dans le catalogue de menaces
• Les propriétés de sécurité (auth, chiffrement, contrôle d'accès) correspondent aux objectifs de sécurité dans les définitions de sécurité
• Les anti-motifs trouvés deviennent des candidats pour le modèle d'engagement de Bitwarden Phase 1 évaluation initiale de la sécurité

Lors de la réalisation d'un examen architecturale, considérez si les constatations justifient l'engagement de l'équipe AppSec (#team-eng-appsec) pour une session complète de modélisation des menaces.