Allowlist für E-Mail-Domains
Die Allowlist für E-Mail-Domains ist eine Durchsetzungsregel pro Organisation, die festlegt, welche Hostnamen in E-Mail-Adressen Mitglieder an ihre fremforge-Benutzerkonten hängen dürfen. Ist sie eingeschaltet, lassen sich über die Seite der Benutzereinstellungen oder die Forgejo-API nur E-Mail-Adressen hinzufügen, die zu einem deiner konfigurierten Muster passen.
Zusammen mit signierten Commits und der bestehenden Eigentumsprüfung von Forgejo per Bestätigungsmail schließt das bei einer forensischen Prüfung den Weg „Nutzer fügt attacker@arbitrary-domain.com hinzu und beansprucht dann Commits als dieser Angreifer“.
Wann du sie einschalten solltest
Du willst sie für jeden regulierten Mandanten, bei dem die Urheberschaft von Commits einer bekannten Unternehmensidentität zugeordnet sein muss. Typische Konfigurationen:
- Mandant mit einer Domain: Muster
acme.com, Mitglieder können nur Adressen mit@acme.comhinzufügen. - Gruppe mit mehreren Domains: Muster
acme.com,acmecorp.dk,*.acme.com, deckt eine Muttergesellschaft und einige Tochtergesellschaften ab. - Mandant nur mit SSO: Muster
acme.comund zusätzlich die Pflicht zur OIDC-Anmeldung über die SSO-Einstellungen. Dann wird die E-Mail-Adresse jedes Mitglieds sowohl in ihrer Form geprüft ALS AUCH vom IdP verifiziert.
Konfiguration
Organisationsverwaltung → Sicherheit → E-Mail-Domains.
- Schalte Durchsetzung ein. (Vorher werden die Muster der Allowlist zwar gespeichert, sind aber nur empfehlend: Hinzufügen funktioniert weiterhin.)
- Füge ein oder mehrere Muster hinzu. Jedes Muster ist ein Hostname in Kleinbuchstaben:
acme.com: exakte Übereinstimmung*.acme.com: jede Subdomain (passt aufeu.acme.com,gb.acme.com, …)- Nur Hostnamen:
*allein oder vollständige URLs werden abgelehnt
- Die Admin-Tabelle führt jedes bestehende Mitglied auf, dessen primäre E-Mail-Adresse zu keinem aktuellen Muster passt. Kläre diese Fälle vor dem Einschalten, sonst können betroffene Mitglieder ihre E-Mail-bezogenen Einstellungen erst ändern, wenn sie die unzulässige Adresse entfernt haben.
Die Syntax der Muster entspricht dem pattern-Attribut des HTML-Formulars. Der reguläre Ausdruck der serverseitigen Prüfung lautet:
^\*?[a-z0-9]([a-z0-9-]*[a-z0-9])?(\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)+$Was durchgesetzt wird
Ist die Durchsetzung an, werden folgende Aktionen für eine E-Mail-Adresse außerhalb der Muster abgelehnt:
| Aktion | Abgelehnt? |
|---|---|
Neue E-Mail-Adresse unter /user/settings/account/email hinzufügen | Ja (die Anfrage gibt 403 mit der Liste der erlaubten Muster zurück) |
| Eine sekundäre E-Mail-Adresse zur primären machen | Ja |
| Erstregistrierung (beim Beitritt zu einer Organisation, in der die Allowlist schon aktiv ist) | Ja |
| Bestehende primäre E-Mail-Adresse bleibt unverändert | Nein: Bestehende Mitglieder werden NICHT automatisch entfernt (die Regel greift bei der nächsten Änderung) |
Die OIDC-Anmeldung ist bewusst ausgenommen. Meldet sich ein Nutzer per SSO an (build/oidc/), stammt seine E-Mail-Adresse aus dem verifizierten Claim email_verified im vom IdP signierten JWT. Die Identität ist also bereits von deinem IdP bestätigt, und die lokale Prüfung gegen die Allowlist wäre überflüssig. Die Tabelle der nicht konformen Adressen markiert diese Fälle zur Übersicht, blockiert sie aber nicht.
Die Eigentumsprüfung von Forgejo per Bestätigungsmail läuft als Zweites. Selbst wenn ein Kunde die Allowlist vorübergehend abschaltet, ist der Bestätigungs-Handshake (Forgejo schickt einen Bestätigungslink an die neue Adresse, den der Nutzer anklicken muss) weiterhin nötig, um die Adresse hinzuzufügen. Der Angriff „die Commits eines anderen beanspruchen“ bleibt durch diese Prüfung blockiert, unabhängig vom Zustand der Allowlist.
Audit-Ereignisse
Jede Änderung erzeugt ein Audit-Ereignis, das in Organisationsverwaltung → Audit-Log und im SIEM-Forwarder ankommt:
email_domains.added: Muster, wer es hinzugefügt hatemail_domains.removed: Muster, wer es entfernt hatemail_domains.policy_toggled: Durchsetzung an/aus
Abgelehnte Versuche erzeugen ebenfalls ein Ereignis (email_domains.rejected) mit der versuchten Adresse und ob sie passte, sodass ein Operator, der einem Phishing-Versuch nachgeht, jedes Ereignis „wollte eine ähnlich aussehende Adresse hinzufügen“ findet.
Verwandte Themen
- Authentifizierungsrichtlinie: das umfassendere Richtlinienpaket (Hardware-Schlüssel, maximale PAT-Laufzeit, Pflicht zu signierten Commits, nur SSO).
- OIDC Single Sign-on: wenn du Nutzer ihre E-Mail-Adressen gar nicht selbst verwalten lassen willst.
- Audit-Log: wo die Audit-Ereignisse zu E-Mail-Domains erscheinen.