Fondamentaux
Identité et accès
La plupart des incidents finissent par une question d'identité : un compte compromis, trop privilégié, mal surveillé ou réutilisé.
Les grandes notions
| Notion | Question |
|---|---|
| Identification | Qui prétend être l'utilisateur |
| Authentification | Comment il prouve son identité |
| Autorisation | Ce qu'il a le droit de faire |
| Session | Comment l'application le reconnaît ensuite |
| Traçabilité | Ce qui est journalisé |
Ces notions sont liées, mais elles ne veulent pas dire la même chose. Une personne peut être correctement authentifiée et pourtant ne pas être autorisée à accéder à une ressource.
Authentification
L'authentification prouve qui est l'utilisateur. Elle peut utiliser un mot de passe, une clé, un certificat, une application MFA, une biométrie ou un fournisseur SSO.
Bonnes pratiques
- MFA pour les comptes sensibles
- mots de passe uniques via gestionnaire
- blocage ou ralentissement des tentatives
- détection des connexions impossibles
- rotation des secrets techniques
- alertes sur les connexions inhabituelles
- désactivation rapide des comptes inutiles
MFA
Le MFA ajoute un facteur supplémentaire après le mot de passe.
Facteurs courants :
- application d'authentification
- clé matérielle FIDO2
- notification validée
- code de secours
Les SMS sont mieux que rien, mais les clés matérielles et applications dédiées sont généralement préférables pour les comptes sensibles.
Autorisation
L'autorisation décide ce qu'un utilisateur peut faire. Une faille de contrôle d'accès apparaît quand une action ou une ressource est accessible sans droit légitime.
Modèles courants :
| Modèle | Idée |
|---|---|
| RBAC | Droits attribués par rôle |
| ABAC | Droits selon des attributs |
| ACL | Liste de droits par ressource |
Exemples de questions d'autorisation :
- cet utilisateur peut-il voir cette fiche privée
- cet admin peut-il supprimer ce compte
- ce service peut-il lire cette table
- cette clé API peut-elle modifier des données
Sessions
Une session doit être protégée contre le vol, la fixation et l'expiration mal gérée. Les cookies sensibles doivent utiliser HttpOnly, Secure et une politique SameSite adaptée.
Points importants :
- durée de session raisonnable
- renouvellement après connexion
- invalidation à la déconnexion
- protection contre le vol de cookie
- journalisation des connexions sensibles
Comptes techniques
Les comptes techniques servent aux applications, scripts, CI/CD ou services. Ils doivent être encore plus contrôlés que les comptes humains.
Bonnes pratiques :
- secret unique par usage
- droits minimaux
- rotation prévue
- propriétaire clairement identifié
- suppression quand le service disparaît
- journalisation des usages
Moindre privilège
Le moindre privilège consiste à donner uniquement les droits nécessaires, pendant la durée nécessaire, sur le périmètre nécessaire.
Exemples :
- compte utilisateur standard par défaut
- admin séparé du compte quotidien
- accès temporaire pour les opérations sensibles
- droits applicatifs limités côté base de données
- permissions différentes entre lecture et écriture
Journaux utiles
Les événements d'identité doivent être exploitables en cas d'incident.
À journaliser :
- connexions réussies
- échecs de connexion
- changements de mot de passe
- activation ou désactivation MFA
- création et suppression de comptes
- changements de rôle
- utilisation de privilèges élevés
À retenir
L'identité est souvent le nouveau périmètre de sécurité. Protéger les comptes, les sessions et les droits est aussi important que protéger les serveurs.