Liste d’autorisation des domaines e-mail
La liste d’autorisation des domaines e-mail est une règle appliquée par organisation qui limite les noms d’hôte des adresses e-mail que les membres peuvent rattacher à leur compte utilisateur fremforge. Lorsqu’elle est activée, seules les adresses correspondant à l’un de vos modèles peuvent être ajoutées, que ce soit depuis la page des paramètres utilisateur ou via l’API Forgejo.
Combinée aux commits signés et au contrôle de propriété existant de Forgejo (vérification par e-mail), elle ferme, lors d’une analyse forensique, le scénario « l’utilisateur ajoute attacker@arbitrary-domain.com, puis s’attribue des commits sous cette identité ».
Quand l’activer
Activez-la pour toute organisation soumise à une réglementation dans laquelle l’auteur d’un commit doit correspondre à une identité d’entreprise connue. Configurations typiques :
- Organisation à domaine unique : modèle
acme.com. Les membres ne peuvent ajouter que des adresses@acme.com. - Groupe à plusieurs domaines : modèles
acme.com,acmecorp.dk,*.acme.com. Couvre une maison mère et quelques filiales. - Organisation uniquement SSO : modèle
acme.com, et connexion OIDC obligatoire via les paramètres SSO. L’adresse de chaque membre est alors à la fois contrôlée dans sa forme ET vérifiée par l’IdP.
Configuration
Administration de l’organisation → Sécurité → Domaines e-mail.
- Activez Application. (Avant cela, les modèles sont enregistrés mais purement indicatifs : les ajouts passent toujours.)
- Ajoutez un ou plusieurs modèles. Chaque modèle est un nom d’hôte en minuscules :
acme.com: correspondance exacte*.acme.com: n’importe quel sous-domaine (correspond àeu.acme.com,gb.acme.com, …)- Noms d’hôte uniquement :
*seul et les URL complètes sont refusés
- Le tableau d’administration liste chaque membre existant dont l’adresse e-mail principale ne correspond à aucun modèle actuel. Régularisez ces cas avant l’activation ; sinon, les membres concernés ne pourront plus modifier leurs paramètres liés à l’e-mail sans d’abord retirer l’adresse non conforme.
La syntaxe des modèles est celle de l’attribut pattern du formulaire HTML. L’expression régulière de validation côté serveur est :
^\*?[a-z0-9]([a-z0-9-]*[a-z0-9])?(\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)+$Ce qui est appliqué
Lorsque l’application est activée, les actions suivantes sont refusées pour une adresse hors modèle :
| Action | Refusée ? |
|---|---|
Ajouter une nouvelle adresse sur /user/settings/account/email | Oui (la requête renvoie 403 avec la liste des modèles autorisés) |
| Faire d’une adresse secondaire l’adresse principale | Oui |
| Inscription initiale (en rejoignant une organisation où la liste est déjà active) | Oui |
| Adresse principale existante laissée en place | Non : les membres existants ne sont PAS exclus automatiquement (la conformité s’applique à la prochaine modification) |
La connexion OIDC est exemptée par conception. Lorsqu’un utilisateur se connecte par SSO (build/oidc/), son adresse provient de la revendication vérifiée email_verified du JWT signé par l’IdP : l’identité est déjà attestée par votre IdP, et la vérification locale par la liste serait redondante. Le tableau des adresses non conformes les signale pour information, sans les bloquer.
Le contrôle de propriété par e-mail de Forgejo intervient ensuite. Même si un client désactive temporairement la liste, la vérification par e-mail (Forgejo envoie un lien de confirmation à la nouvelle adresse, sur lequel l’utilisateur doit cliquer) reste obligatoire pour rattacher l’adresse. L’attaque « s’attribuer les commits de quelqu’un d’autre » reste bloquée par ce contrôle, quel que soit l’état de la liste.
Événements d’audit
Chaque modification émet un événement d’audit, repris par Administration de l’organisation → Journal d’audit et par le transfert vers le SIEM :
email_domains.added: le modèle, et qui l’a ajoutéemail_domains.removed: le modèle, et qui l’a retiréemail_domains.policy_toggled: application activée ou désactivée
Les tentatives refusées émettent aussi un événement (email_domains.rejected) avec l’adresse tentée et le résultat de la correspondance. Un opérateur qui enquête sur une tentative d’hameçonnage retrouve ainsi chaque tentative d’ajout d’un domaine sosie.
Voir aussi
- Politique d’authentification : l’ensemble de règles plus large (clés matérielles, durée de vie maximale des PAT, commits signés obligatoires, SSO uniquement).
- Authentification unique OIDC : si vous préférez ne pas laisser les utilisateurs gérer eux-mêmes leurs adresses e-mail.
- Journal d’audit : où apparaissent les événements d’audit des domaines e-mail.