Adgangsstyringspolitikken, skrevet ud fra få svar

# Adgangsstyringspolitik: [virksomhed]

Politikejer: [politikejeren] · Godkendt af: [topledelsen]

Skrevet den  med den gratis side på getstandardos.com mod foranstaltningerne i anneks A i ISO/IEC 27001:2022 om adgangsstyring, identitetsstyring, autentifikationsoplysninger, adgangsrettigheder, privilegeret adgang, begrænsning af informationsadgang og sikker autentifikation. Ordlyden er StandardOS' egen.

## 1. Formål og omfang

Denne politik siger, hvordan [virksomhed] giver mennesker og systemer adgang til sine informationer og tjenester, hvordan den adgang beskyttes, gennemgås og fjernes, og hvem der beslutter. Den gælder for hver konto på hvert system inden for ledelsessystemets omfang, uanset om den tilhører en ansat, en ekstern, en leverandør eller en maskine.

## 2. Principper

- Mindst mulige rettigheder: Alle får den adgang, deres rolle kræver, og ikke mere, og adgang tilføjes, når en opgave kræver det, ikke på forhånd.
- Én identitet pr. person: Hver konto tilhører én navngiven person eller ét navngivet system, delte konti findes ikke, og en nødkonto er forseglet, logget og har en ejer.
- Afvis som standard: Et nyt system, en ny person og en ny rolle starter uden adgang, og adgang gives, den forudsættes ikke.
- En ejer for hvert system: Hvert system har en navngiven ejer, der godkender adgang til det og står til ansvar for dets gennemgange.

## 3. Identiteter og nyansatte

Hver person har én identitet i [udfyldes], og hver tjeneste, der kan bruge den, gør det; hvor en tjeneste ikke kan, opretter systemejeren kontoen ud fra samme identitetspost og fører den op imod den. Gruppemedlemskab i identitetsudbyderen er måden, en rolle gives på.

En nyansat får adgang den første dag gennem en anmodning fra sin leder, der nævner rollen; anmodningen, godkendelsen og de oprettede konti registreres, og intet gives mundtligt.

## 4. Autentifikation

Multifaktorautentifikation er slået til for hver konto, der tilbyder det, med en autentifikator-app eller en hardwarenøgle og aldrig via sms, hvor en stærkere faktor findes; en tjeneste uden er en undtagelse efter afsnit 11.

Adgangskoder er lange, unikke, genereret af og opbevaret i virksomhedens adgangskodeadministrator, aldrig genbrugt på tværs af tjenester og aldrig skrevet ind i kode, sager eller chat; hemmeligheder, systemer bruger, ligger i en secrets manager, roteres, når en person med adgang til dem fratræder, og committes aldrig til et repository.

## 5. Adgangsrettigheder og roller

Adgang gives efter rolle. [Navngiv de roller, virksomheden giver adgang efter, hver med de systemer og det adgangsniveau, den bærer; rollekataloget ejes af politikejeren og gennemgås sammen med adgangsgennemgangene.]

Når en person skifter rolle, fjernes den gamle rolles adgang den dag, den nye gives; adgang ophobes aldrig på tværs af roller, og et midlertidigt behov gives med en slutdato, der fjerner det.

## 6. Privilegeret adgang

Administrative rettigheder ligger i separate administratorkonti, der kun bruges til administrative opgaver og aldrig til mail, browsing eller dagligt arbejde; den daglige konto har ingen hævede rettigheder.

Privilegeret adgang gives til navngivne personer af systemejeren, registreres, beskyttes med multifaktorautentifikation, gennemgås ved hver adgangsgennemgang og fjernes, så snart rollen ikke længere behøver den; produktionsdata tilgås ikke med privilegerede rettigheder til udvikling eller test.

## 7. Leverandører og andre tredjeparter

En leverandør, auditor eller partner får kun adgang under en kontrakt, gennem en navngiven konto med en systemejer som sponsor, begrænset til de systemer og den periode, arbejdet kræver, med en slutdato, der fjerner den; tredjepartsadgang gennemgås sammen med adgangsgennemgangene og tilbagekaldes, når kontrakten ophører.

## 8. Adgangsgennemgange

Hvert kvartal gennemgår hver systemejer hver konto og hvert privilegium på sit system mod rollekataloget og personlisten, fjerner det, der ikke længere behøves, og registrerer gennemgangen, fundene og fjernelserne; [politikejeren] kører cyklussen og rapporterer resultaterne til ledelsens evaluering.

## 9. Fratrådte

På en persons sidste dag deaktiveres hver konto, før personen forlader bygningen eller opkaldet, gruppemedlemskaberne fjernes, hemmeligheder, personen kendte, roteres, enhederne afleveres og slettes, og fjernelsen registreres; konti slettes efter den opbevaringsperiode, virksomheden fastsætter.

## 10. Logning

Logins, mislykkede logins, hævning af rettigheder og ændringer i adgangsrettigheder logges på hvert system, der kan logge dem, opbevares i den periode, virksomheden fastsætter, beskyttes mod ændring og læses, når en hændelse eller en adgangsgennemgang kræver det.

## 11. Undtagelser

En undtagelse fra denne politik anmodes om skriftligt, godkendes af [politikejeren] med en slutdato og en kompenserende foranstaltning, opføres i undtagelsesregistret og gennemgås sammen med adgangsgennemgangene; en undtagelse uden slutdato er en konstatering.

Godkendt af [topledelsen] den [dato]; ejet af [politikejeren]; gennemgået mindst én gang om året og hver gang virksomhedens systemer, roller eller identitetsudbyder ændrer sig.

Denne politik er skrevet ud fra de givne svar. Det er ikke certificeringsrådgivning; certificeringsorganet læser politikken for dens regler og udtager derefter stikprøver af konti, gennemgange og fratrådte imod den, og den registrering, det anerkender, er den, virksomheden fører.