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.compluss 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.
- Slå på Håndheving. (Før dette er slått på, lagres mønstrene, men de er bare veiledende: nye adresser slippes fortsatt gjennom.)
- 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 (treffereu.acme.com,gb.acme.com, …)- Bare vertsnavn:
*alene eller hele URL-er avvises
- 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:
| Handling | Avvist? |
|---|---|
Legge til en ny e-postadresse på /user/settings/account/email | Ja (forespørselen returnerer 403 med listen over tillatte mønstre) |
| Gjøre en sekundær e-postadresse til primær | Ja |
| 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ående | Nei. 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 tilemail_domains.removed: mønsteret, og hvem som fjernet detemail_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.