Gå til hovedinnhold

Tillatelsesliste for e-postdomener

Tillatelseslisten for e-postdomener er en regel per organisasjon som avgrenser hvilke vertsnavn i e-postadresser medlemmene kan knytte til fremforge-brukerkontoene sine. Når den er slått på, kan bare e-postadresser som samsvarer med et av mønstrene dine, legges til via siden med brukerinnstillinger eller via Forgejo-API-et.

Sammen med signerte commits og Forgejos eksisterende eierskapskontroll med bekreftelse per e-post stenger dette veien der «brukeren legger til attacker@arbitrary-domain.com og så utgir seg for å være den som laget commits som angriperen» under en kriminalteknisk gjennomgang.

Når du bør slå den på

Du vil ha dette på for enhver regulert kunde der forfatterskapet til commits må kunne knyttes til en kjent bedriftsidentitet. Typiske oppsett:

  • Kunde med ett domene: mønsteret acme.com. Medlemmer kan bare legge til @acme.com-adresser.
  • Konsern med flere domener: mønstrene acme.com, acmecorp.dk, *.acme.com. Dekker et morselskap og noen datterselskaper.
  • Kunde med bare SSO: mønsteret acme.com pluss påkrevd OIDC-innlogging via SSO-innstillingene. Hvert medlems e-postadresse blir da både formkontrollert OG bekreftet av IdP-en.

Oppsett

Organisasjonsadministrasjon → Sikkerhet → E-postdomener.

  1. Slå på Håndheving. (Før dette er slått på, lagres mønstrene, men de er bare veiledende: nye adresser slippes fortsatt gjennom.)
  2. Legg til ett eller flere mønstre. Hvert mønster er et vertsnavn med små bokstaver:
    • acme.com: nøyaktig treff
    • *.acme.com: et hvilket som helst underdomene (treffer eu.acme.com, gb.acme.com, …)
    • Bare vertsnavn: * alene eller hele URL-er avvises
  3. Tabellen i administrasjonen lister alle eksisterende medlemmer med en primær e-postadresse som ikke samsvarer med et gjeldende mønster. Rydd opp i dem før du slår på regelen. Ellers kan de berørte medlemmene ikke endre e-postrelaterte innstillinger uten først å fjerne adressen som bryter regelen.

Mønstersyntaksen tilsvarer pattern-attributtet i HTML-skjemaet. Regex-en for validering på serveren er:

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

Dette håndheves

Når håndhevingen er på, avvises disse brukerhandlingene for en e-postadresse utenfor mønstrene:

HandlingAvvist?
Legge til en ny e-postadresse på /user/settings/account/emailJa (forespørselen returnerer 403 med listen over tillatte mønstre)
Gjøre en sekundær e-postadresse til primærJa
Første registrering (når man blir med i en organisasjon som allerede har listen på)Ja
Eksisterende primær e-postadresse som blir ståendeNei. Eksisterende medlemmer blir IKKE kastet ut automatisk (kravet slår inn ved neste endring)

OIDC-innlogging er unntatt med vilje. Når en bruker logger inn via SSO (build/oidc/), kommer e-postadressen fra den bekreftede email_verified-claimen i JWT-en som IdP-en har signert. Identiteten er allerede bekreftet av IdP-en din, så den lokale sjekken mot tillatelseslisten ville vært overflødig. Tabellen over adresser som ikke samsvarer, markerer disse for oversiktens skyld, men blokkerer dem ikke.

Forgejos eierskapskontroll med bekreftelse per e-post kjøres i tillegg. Selv om en kunde slår av tillatelseslisten midlertidig, kreves fortsatt bekreftelsen per e-post (Forgejo sender en bekreftelseslenke til den nye adressen, og brukeren må klikke på den) for å knytte adressen til kontoen. Angrepet der noen gjør krav på andres commits, forblir blokkert av denne kontrollen uansett om tillatelseslisten er på eller av.

Revisjonshendelser

Hver endring sender en revisjonshendelse som vises i Organisasjonsadministrasjon → Revisjonslogg og sendes videre til SIEM-videresendingen:

  • email_domains.added: mønsteret, og hvem som la det til
  • email_domains.removed: mønsteret, og hvem som fjernet det
  • email_domains.policy_toggled: håndheving på/av

Avviste forsøk sender også en hendelse (email_domains.rejected) med e-postadressen det ble forsøkt med og om den samsvarte, slik at en operatør som jakter på et phishingforsøk, kan finne hver hendelse der noen prøvde å legge til en forvekslingsadresse.

Relatert

  • Autentiseringspolicy: den bredere policypakken (maskinvarenøkler, maksimal levetid for PAT, påkrevde signerte commits, bare SSO).
  • Single sign-on med OIDC: når du helst ikke vil la brukerne administrere e-postadressene selv i det hele tatt.
  • Revisjonslogg: der revisjonshendelsene for e-postdomener vises.