Gå til hovedindhold

Tilladelsesliste over e-maildomæner

Tilladelseslisten over e-maildomæner er en regel pr. organisation, der begrænser, hvilke værtsnavne i e-mailadresser medlemmerne kan knytte til deres fremforge-brugerkonti. Når den er slået til, kan kun e-mails, der matcher et af dine mønstre, tilføjes via siden med brugerindstillinger eller via Forgejos API.

Sammen med signerede commits og Forgejos eksisterende ejerskabskontrol med bekræftelse via e-mail lukker det vejen, hvor en bruger tilføjer attacker@arbitrary-domain.com og derefter, under en forensisk gennemgang, påstår, at commits stammer fra den angriber.

Hvornår du skal slå den til

Du vil have den slået til i enhver reguleret tenant, hvor forfatterskab af commits skal kunne knyttes til en kendt virksomhedsidentitet. Typiske opsætninger:

  • Tenant med ét domæne: mønsteret acme.com. Medlemmer kan kun tilføje @acme.com-e-mails.
  • Koncern med flere domæner: mønstrene acme.com, acmecorp.dk, *.acme.com. Dækker et moderselskab og et par datterselskaber.
  • Tenant kun med SSO: mønsteret acme.com plus krav om OIDC-login via SSO-indstillingerne. Hvert medlems e-mail bliver så både formkontrolleret OG verificeret af IdP’en.

Opsætning

Administration → Sikkerhed → E-maildomæner.

  1. Slå Håndhævelse til. (Inden da er mønstrene i tilladelseslisten gemt, men kun vejledende: tilføjelser går stadig igennem.)
  2. Tilføj et eller flere mønstre. Hvert mønster er et værtsnavn med små bogstaver:
    • acme.com: præcist match
    • *.acme.com: ethvert underdomæne (matcher eu.acme.com, gb.acme.com, …)
    • Kun værtsnavne: * alene eller fulde URL’er afvises
  3. Tabellen i administrationen viser alle eksisterende medlemmer, hvis primære e-mail ikke matcher et aktuelt mønster. Ret dem, før du slår håndhævelsen til. Ellers kan de berørte medlemmer ikke ændre deres e-mailrelaterede indstillinger uden først at fjerne den adresse, der bryder reglen.

Mønstersyntaksen svarer til HTML-formularens pattern-attribut. Det regulære udtryk, serveren validerer med, er:

^\*?[a-z0-9]([a-z0-9-]*[a-z0-9])?(\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)+$

Hvad der håndhæves

Når håndhævelsen er slået til, afvises følgende brugerhandlinger for en e-mail uden for mønstrene:

HandlingAfvises?
Tilføj en ny e-mail på /user/settings/account/emailJa (forespørgslen returnerer 403 med listen over tilladte mønstre)
Gør en sekundær e-mail til primærJa
Første tilmelding (når man bliver medlem af en organisation, der allerede har tilladelseslisten slået til)Ja
Eksisterende primær e-mail, der bliver ståendeNej. Eksisterende medlemmer bliver IKKE automatisk smidt ud (reglen træder i kraft ved næste ændring)

Login via OIDC er undtaget med vilje. Når en bruger logger ind via SSO (build/oidc/), kommer e-mailen fra det verificerede email_verified-claim i den JWT, IdP’en har signeret. Identiteten er allerede bekræftet af din IdP, så den lokale kontrol mod tilladelseslisten ville være overflødig. Tabellen over afvigende medlemmer markerer dem for overblikkets skyld, men blokerer dem ikke.

Forgejos ejerskabskontrol med bekræftelse via e-mail kører bagefter. Selv hvis en kunde midlertidigt slår tilladelseslisten fra, kræves bekræftelsen via e-mail stadig for at knytte adressen til kontoen (Forgejo sender et bekræftelseslink til den nye adresse, og brugeren skal klikke på det). Angrebet, hvor man gør krav på en andens commits, forbliver blokeret af e-mailbekræftelsen, uanset om tilladelseslisten er slået til.

Revisionshændelser

Hver ændring udløser en revisionshændelse, som vises i Administration → Revisionslog og sendes videre af SIEM-forwarderen:

  • email_domains.added: mønsteret, og hvem der tilføjede det
  • email_domains.removed: mønsteret, og hvem der fjernede det
  • email_domains.policy_toggled: håndhævelse til/fra

Afviste forsøg udløser også en hændelse (email_domains.rejected) med den e-mail, der blev forsøgt tilføjet, og om den matchede. En operatør, der efterforsker et phishingforsøg, kan dermed finde hver eneste hændelse, hvor nogen forsøgte at tilføje et domæne, der ligner dit.

Relateret

  • Godkendelsespolitik: den bredere samling af politikker (hardwarenøgler, maksimal levetid for PAT’er, krav om signerede commits, kun SSO).
  • Single sign-on med OIDC: når du helst ikke vil lade brugerne selv administrere deres e-mails.
  • Revisionslog: hvor revisionshændelserne for e-maildomæner vises.