Log ind sikkert
Foranstaltning: Teknologisk
Hvad det betyder
Brug godkendelsesteknologi og -procedurer, der svarer til adgangsbegrænsningerne, med MFA hvor det betyder noget.
Sådan kontrollerer StandardOS det
Forbundet skrivebeskyttet, efter en plan. Et bestået tjek holder en bevispost frisk; et fejlet lader den udløbe, så en tilbagegang kommer frem i stedet for at vente på auditten. Hver integration, og hvad hver legitimationsoplysning kan se.
- AWSStandardOS læser om alle med konsoladgang bruger MFA, bortset fra service principals med kun nøgler, som ikke kan have det.
- Microsoft Entra IDStandardOS læser om multifaktorgodkendelse kræves, via sikkerhedsstandarder eller betinget adgang.
- GitHubStandardOS læser tofaktorgodkendelse i hele organisationen eller på selve kontoen, hvor koden ligger under en personlig konto.
- Google WorkspaceStandardOS læser totrinsbekræftelse på hver aktiv konto, uden de suspenderede, så en sovende konto ikke lader en levende foranstaltning fejle.
- OktaStandardOS læser udelukkede konti, hvilket er foranstaltningen, der virker, ikke en, der fejler.
- Microsoft Entra IDStandardOS læser om ældre godkendelse er blokeret af sikkerhedsstandarderne eller en politik, om en politik dækker katalogroller med MFA, og om hver administrator har en anden faktor registreret.
- OktaStandardOS læser om hver superadministrator har en aktiv faktor registreret.
- Google WorkspaceStandardOS læser om totrinsbekræftelse håndhæves ved politik for hver aktiv konto og ikke kun er aktiveret.
- Jamf ProStandardOS læser hvilke administrerede Macs der automatisk logger en bruger ind ved opstart, så ingen adgangskode står mellem maskinen og den, der holder den.
Risici, denne foranstaltning håndterer
Fra det startrisikoregister, StandardOS foreslår ved opsætningen. I beholder, redigerer eller sletter hver enkelt; dette er dem, der nævner A.8.5 som håndtering.
- Phishing fører til kompromitterede legitimationsoplysningerBrugerkonti
Hvad kunder spørger om ved denne foranstaltning
Sikkerhedsspørgeskemaer bruger ikke foranstaltningsnumre. Dette er de spørgsmål, som kunder stiller dem, der lander på A.8.5. Hvert af dem besvares ud fra de samme fire registreringer: SoA-status, den godkendte politik, dateret bevis og et levende tjek. Det fulde kort over de tredive emner.
Gennemtvinger I multifaktorgodkendelse for alle brugere?
MFA, single sign-on, adgangskoderegler · også A.5.17
Hvordan opbevares og roteres API-nøgler og andre hemmeligheder?
Hemmeligheder, API-nøgler, vaults · også A.8.24
Hvor dette hører til under NIS2
A.8.5 er en del af det, artikel 21, stk. 2, litra j), Access control
, kræver. At implementere det én gang tæller for begge, og det er hele grunden til, at NIS2-kortlægningen findes.
Foranstaltninger, der arbejder sammen med denne
De optræder sammen i samme risiko eller samme politik, så de implementeres som regel også sammen.
- A.5.15Afgør hvem der må nå hvilke systemer og data
- A.5.16Styr konti og identiteter gennem hele deres liv
- A.5.17Håndtér adgangskoder, nøgler og andre hemmeligheder
- A.5.18Tildel, gennemgå og fjern rettigheder
- A.6.3Lær folk at arbejde sikkert
- A.8.2Begræns administratoradgang
- A.8.23Filtrér adgang til risikable websteder
- A.8.3Begræns hvad den enkelte kan åbne
Hvad ISO 27001-certificering koster. Auditdagene er fastlagt i ISO/IEC 27006, så I kan regne jeres eget tal ud. Eller se hvilke afsnit StandardOS dækker, også dem det ikke dækker.
Det, StandardOS holder klar for A.8.5 på auditdagen
En beslutning om anvendelighed og et udkast til begrundelse, forudfyldt ud fra en profil med syv spørgsmål og markeret som udkast, indtil I har gjort det til jeres eget. En implementeringsstatus. Daterede bevisposter, der udløber, så den eksport, jeres auditor læser, viser, hvad der var sandt og hvornår, arkiveret under denne reference.