ISO/IEC 27001

ISO 27001 – Vedlegg A.9: Tilgangskontroll

Se hvordan ISMS.online kan hjelpe bedriften din

Se det i aksjon
Av Max Edwards | Oppdatert 14. desember 2023

Vær oppmerksom på at fra oktober 2022 ble ISO 27001:2013 revidert og er nå kjent som ISO 27001:2022. Se den fullstendige reviderte ISO 27001 vedlegg A-kontrollene for å se den mest oppdaterte informasjonen.

Se reviderte vedlegg A kontroller

Gå til emnet

Hva er vedlegg A.9?

Vedlegg A.9 handler om tilgangskontrollprosedyrer. Målet med vedlegg A.9 er å sikre tilgang til informasjon og sikre at ansatte kun kan se informasjon som er relevant for deres arbeid. Denne veiledningen tar deg gjennom alt du trenger å vite om vedlegg A.9.

Vedlegg A.9 er delt inn i fire seksjoner, og du må jobbe deg gjennom hver. De er tilgangskontroller, brukertilgangsadministrasjon, brukeransvar og applikasjonstilgangskontroller.

Få 81 % forsprang med ISMS.online

Dette er en nøkkeldel for å komme rett i reisen din til ISO 27001-sertifisering og en hvor mange selskaper finner de trenger støtte. Hvis du leter etter en forenklet måte å bli sertifisert på, så bestill en plattformdemo, og se hvordan vi gir deg 81 % forsprang fra det øyeblikket du logger på.

Bestill en plattformdemo

Hva er formålet med vedlegg A.9.1?

Vedlegg A.9.1 handler om forretningskrav til tilgangskontroll. Målet i denne vedlegg A-kontrollen er å begrense tilgangen til informasjon og informasjonsbehandlingsfasiliteter.

Det er en viktig del av styringssystemet for informasjonssikkerhet (ISMS), spesielt hvis du ønsker å oppnå ISO 27001-sertifisering. La oss forstå disse kravene og hva de betyr i litt mer dybde.

A.9.1.1 Retningslinjer for tilgangskontroll

En tilgangskontrollpolicy skal etableres, dokumenteres og gjennomgås jevnlig under hensyntagen til virksomhetens krav til eiendelene i omfang.

Adgangskontrollregler, rettigheter og begrensninger sammen med dybden av kontrollene som brukes bør gjenspeile informasjonssikkerhetsrisikoen rundt informasjonen og organisasjonens appetitt på å administrere dem. Enkelt sagt, tilgangskontroll handler om hvem som trenger å vite, hvem som må bruke og hvor mye de får tilgang til.

Tilgangskontroller kan være av digital og fysisk natur, f.eks. tillatelsesbegrensninger på brukerkontoer samt begrensninger på hvem som kan få tilgang til bestemte fysiske steder (tilpasset vedlegg A.11 Fysisk og miljømessig sikkerhet). Retningslinjene bør ta hensyn til:

  • Sikkerhetskrav til forretningsapplikasjoner og samsvar med informasjonsklassifiseringsskjemaet som er i bruk i henhold til A.8 Asset Management;
  • Avklare hvem som trenger tilgang til, vite, hvem som trenger å bruke informasjonen – støttet av dokumenterte prosedyrer og ansvar;
  • Administrering av tilgangsrettigheter og privilegerte tilgangsrettigheter (mer kraft – se nedenfor) inkludert tilføyelse av endringer i livet (f.eks. superbrukere/administratorkontroller) og periodiske gjennomganger (f.eks. ved regelmessige interne revisjoner i tråd med krav 9.2.
  • Adgangskontrollregler bør støttes av formelle prosedyrer og definerte ansvarsområder;

Tilgangskontroll må gjennomgås basert på endringer i roller og spesielt under utgang, for å tilpasses vedlegg A.7 Human Resource Security.

A.9.1.2 Tilgang til nettverk og nettverkstjenester

Prinsippet om minst tilgang er den generelle tilnærmingen som favoriseres for beskyttelse, snarere enn ubegrenset tilgang og superbrukerrettigheter uten nøye vurdering.

Som sådan bør brukere kun få tilgang til nettverket og nettverkstjenestene de trenger å bruke eller vite om for jobben sin. Politikken må derfor adressere; Nettene og nettverkstjenestene i omfanget av tilgang; Autorisasjonsprosedyrer for å vise hvem (rollebasert) som har tilgang til hva og når; og ledelseskontroller og prosedyrer for å forhindre tilgang og overvåke den i livet.

Dette må også vurderes under onboarding og offboarding, og er nært knyttet til selve tilgangskontrollpolicyen.


Hva er formålet med vedlegg A.9.2?

Vedlegg A.9.2 handler om administrasjon av brukertilgang. Målet i denne vedlegg A-kontrollen er å sikre at brukere er autorisert til å få tilgang til systemer og tjenester, samt forhindre uautorisert tilgang.

A.9.2.1 Brukerregistrering og avregistrering

En formell brukerregistrerings- og avregistreringsprosess må implementeres. En god prosess for administrasjon av bruker-ID inkluderer å kunne knytte individuelle IDer til ekte personer, og begrense delte tilgangs-IDer, som skal godkjennes og registreres der det gjøres.

En god på- og utgangsprosess knytter seg til A7 Human Resource Security for å vise rask og tydelig registrering/avregistrering sammen med unngåelse av gjenutstedelse av gamle IDer. En jevnlig gjennomgang av ID-er vil illustrere god kontroll og forsterker den løpende ledelsen.

Dette kan knyttes til de interne revisjonene nevnt ovenfor for tilgangskontrollrevisjoner og periodiske gjennomganger av eierne av informasjonselementet eller behandlingsapplikasjonen.

A.9.2.2 Provisionering av brukertilgang

En prosess (uanset enkel og dokumentert) må implementeres for å tildele eller tilbakekalle tilgangsrettigheter for alle brukertyper til alle systemer og tjenester. Godt gjort det henger sammen med punktene ovenfor, så vel som det bredere HR-sikkerhetsarbeidet.

Prosessen med tildeling og tilbakekalling bør inkludere; Tillatelse fra eieren av informasjonssystemet eller tjenesten for bruk av informasjonssystemet eller tjenesten; Verifisere at tilgangen som er gitt er relevant for rollen som utføres; og beskytte mot klargjøring før autorisasjonen er fullført.

Brukertilgang skal alltid være forretningsledet og tilgang basert på virksomhetens krav. Dette kan høres byråkratisk ut, men det trenger ikke å være det, og effektive enkle prosedyrer med rollebasert tilgang fra systemer og tjenester kan løse det.

A.9.2.3 Forvaltning av privilegerte tilgangsrettigheter

A.9.2.3 handler om å administrere vanligvis kraftigere og høyere "privilegerte" tilgangsnivåer, f.eks. systemadministrasjonstillatelser kontra vanlige brukerrettigheter.

Tildeling og bruk av privilegerte tilgangsrettigheter må kontrolleres nøye gitt de ekstra rettighetene som vanligvis overføres over informasjonsressurser og systemene som kontrollerer dem. For eksempel muligheten til å slette arbeid eller fundamentalt påvirke integriteten til informasjonen. Den bør samsvare med de formelle autorisasjonsprosessene ved siden av tilgangskontrollpolicyen.

Det kan inkludere; system for system klarhet om privilegerte tilgangsrettigheter (som kan administreres inne i applikasjonen); tildeling etter behov for bruk, ikke en generell tilnærming; En prosess og oversikt over alle tildelte privilegier bør opprettholdes (sammen med informasjonsaktivumet eller som en del av A.9-beviset; og kompetansen til brukere som er tildelt rettighetene må gjennomgås regelmessig for å samsvare med deres plikter.

Dette er nok et bra område å inkludere i internrevisjonen for å demonstrere kontroll.

En av de største medvirkende årsakene til feil eller brudd på systemer er upassende og generell bruk av systemadministrasjonsprivilegier med menneskelige feil som fører til mer skade eller tap enn om en tilnærming med "minst tilgang" ble tatt.

Annen god praksis knyttet til dette området inkluderer atskillelse av systemadministratorrollen fra den daglige brukerrollen og å ha en bruker med to kontoer hvis de utfører forskjellige jobber på samme plattform.

A.9.2.4 Håndtering av hemmelig autentiseringsinformasjon for brukere

Hemmelig autentiseringsinformasjon er en inngangsport for å få tilgang til verdifulle eiendeler. Det inkluderer vanligvis passord, krypteringsnøkler osv., så det må kontrolleres gjennom en formell administrasjonsprosess og må holdes konfidensielt for brukeren.

Dette er vanligvis knyttet til ansettelseskontrakter og disiplinære prosesser (A.7) og leverandørforpliktelser (A13.2.4 og A.15) ved deling med eksterne parter.

Det bør etableres prosedyrer for å bekrefte identiteten til en bruker før ny, erstatningsinformasjon eller midlertidig hemmelig autentiseringsinformasjon oppgis. All standard hemmelig autentiseringsinformasjon gitt som en del av en ny systembruk bør endres så snart som mulig.

A.9.2.5 Gjennomgang av brukerrettigheter

Eiendelseiere må gjennomgå brukernes tilgangsrettigheter med jevne mellomrom, både rundt individuell endring (ombordstigning, endring av rolle og avslutning) samt bredere revisjoner av systemtilgangen.

Autorisasjoner for privilegerte tilgangsrettigheter bør gjennomgås med hyppigere intervaller gitt deres høyere risiko. Dette samsvarer med 9.2 for internrevisjon og bør gjøres minst årlig eller når store endringer finner sted.

A.9.2.6 Fjerning eller justering av tilgangsrettigheter

Som skissert ovenfor må tilgangsrettigheter for alle ansatte og eksterne brukere til informasjons- og informasjonsbehandlingsfasiliteter fjernes ved oppsigelse av ansettelsesforholdet, kontrakten eller avtalen, (eller justeres ved endring av rolle om nødvendig).

En god exit-policy og prosedyrer som samsvarer med A.7 vil også sikre at dette oppnås og demonstreres for revisjonsformål når folk drar.

Få et forsprang på 81 %

Vi har gjort det harde arbeidet for deg, og gir deg 81 % forsprang fra det øyeblikket du logger på.
Alt du trenger å gjøre er å fylle ut de tomme feltene.

Bestill en demonstrasjon

Hva er formålet med vedlegg A.9.3?

Vedlegg A.9.3 handler om brukeransvar. Målet i denne vedlegg A-kontrollen er å gjøre brukere ansvarlige for å beskytte sin autentiseringsinformasjon.

A.9.3.1 Bruk av hemmelig autentiseringsinformasjon

Dette handler ganske enkelt om å sørge for at brukerne følger retningslinjene og vil derfor knyttes til A7 Human Resource Security for kontrakter, brukeropplæring for bevissthet og etterlevelse, samt sunn fornuftspraksis.

Disse inkluderer: Hold all hemmelig autentiseringsinformasjon konfidensiell; Unngå å holde oversikt over det som kan nås av uautoriserte parter; Endre den når det er noen antydninger om mulig kompromiss; velg kvalitetspassord med tilstrekkelig minimumslengde og -styrke til å følge bredere passordpolicykontroller i vedlegg A.9.4.


Hva er formålet med vedlegg A.9.4?

Vedlegg A.9.4 handler om system- og applikasjonstilgangskontroll. Målet i denne vedlegg A-kontrollen er å forhindre uautorisert tilgang til systemer og applikasjoner.

A.9.4.1 Begrensning av informasjonstilgang

Tilgang til informasjon og applikasjonssystemfunksjoner må være knyttet til tilgangskontrollpolicyen. Viktige hensyn bør inkludere:

Disse inkluderer:

  • Rollebasert tilgangskontroll (RBAC);
  • nivåer av tilgang;
  • Design av "meny"-systemer innen applikasjoner;
  • Lese, skrive, slette og utføre tillatelser;
  • Begrense produksjonen av informasjon; og
  • Fysiske og/eller logiske tilgangskontroller til sensitive applikasjoner, data og systemer.

Revisor vil kontrollere at det er tatt hensyn til å begrense tilgang innenfor systemer og applikasjoner som støtter tilgangskontrollpolicyer, forretningskrav, risikonivåer og oppgaveseparering.

A.9.4.2 Sikker påloggingsprosedyrer

Tilgang til systemer og applikasjoner må kontrolleres av en sikker påloggingsprosedyre for å bevise brukerens identitet.

Dette kan gå utover den typiske passordtilnærmingen til multifaktorautentisering, biometri, smartkort og andre krypteringsmetoder basert på risikoen som vurderes.

Sikker pålogging bør utformes slik at den ikke lett kan omgås og at all autentiseringsinformasjon overføres og lagres kryptert for å forhindre avlytting og misbruk.

ISO 27002-veiledning er viktig rundt dette emnet, i likhet med spesialistorganer som National Cyber ​​Security Center (NCSC). Ytterligere tips inkluderer:

  • Påloggingsprosedyrer bør utformes slik at de ikke lett kan omgås og at all autentiseringsinformasjon overføres og lagres kryptert for å hindre avlytting og misbruk.
  • Påloggingsprosedyrer bør også inkludere en skjerm som sier at tilgang kun er for autoriserte brukere. Dette er designet for å støtte nettsikkerhetslovgivning som
  • Computer Misuse Act 1990 (Storbritannia).
  • Både en vellykket og mislykket på- og avlogging bør logges på en sikker måte for å gi rettsmedisinsk bevisevne, og varsler om mislykkede forsøk og mulige lock-out bør vurderes.
  • Avhengig av systemets art bør tilgang begrenses til bestemte tider på dagen eller tidsperioder og potensielt til og med begrenses i henhold til plassering.

I praksis bør virksomhetens behov og informasjon som er i fare, drive påloggings- og avloggingsprosedyrene. Det er ikke verdt å ha 25 trinn å logge på, deretter ha raske timeouts osv. hvis personalet da ikke klarer å gjøre jobben sin godt og bruker uforholdsmessig mye tid i denne sløyfen.

A.9.4.3 Passordbehandlingssystem

Formålet med et passordbehandlingssystem er å sikre kvalitetspassord som oppfyller det nødvendige nivået og brukes konsekvent.

Passordgenerering og administrasjonssystemer gir en god måte å sentralisere tilgangen på, og de tjener til å redusere risikoen for at folk bruker samme pålogging for alt, som illustrert i denne lille historien om hva som skjer når en kunde kontakter teamet vårt angående et glemt passord !

Som med enhver kontrollmekanisme, må passordgenerering og -administrasjonssystemer implementeres nøye for å sikre tilstrekkelige og forholdsmessige beskyttelsesnivåer.

Der det er mulig bør brukere kunne velge sine egne passord, da dette gjør dem lettere å huske enn maskingenererte, men det må være opp til et visst styrkenivå.

Det er mange motstridende synspunkter på passordbehandlingssystemer og passordpolicyer, så vi oppfordrer organisasjoner til å se på de ofte endrede beste praksisene og ta i bruk tilnærminger basert på risikoviljen og kulturen i organisasjonen.

Som nevnt ovenfor, er NCSC et bra sted å gå gjennom den nyeste praksisen eller bare be oss om å introdusere deg for en av våre partnere for å få hjelp.

A.9.4.4 Bruk av Privileged Utility-programmer

Verktøydataprogrammer som kan være i stand til å overstyre system- og applikasjonskontroller, må administreres nøye.

Kraftige system- og nettverksverktøy kan skape et attraktivt mål for ondsinnede angripere, og tilgangen til dem må begrenses til det minste antallet personer. Siden slike hjelpeprogrammer lett kan lokaliseres og lastes ned fra internett, er det også viktig at brukere begrenses i deres evne til å installere programvare så mye som mulig veid opp mot forretningskrav og risikovurdering. Bruk av hjelpeprogrammer bør logges og overvåkes/gjennomgås med jevne mellomrom for å tilfredsstille revisorforespørsler.

A.9.4.5 Tilgangskontroll til programkildekode

Tilgang til programmets kildekode må begrenses. Tilgang til programkildekode og tilhørende elementer (som design, spesifikasjoner, verifikasjonsplaner og valideringsplaner) bør kontrolleres strengt.

Programkildekoden kan være sårbar for angrep hvis den ikke er tilstrekkelig beskyttet og kan gi en angriper et godt middel til å kompromittere systemer på en ofte skjult måte. Hvis kildekoden er sentral for bedriftens suksess, kan tapet også ødelegge forretningsverdien raskt.

Kontroller bør inkludere hensyn til:

  • Så få personer som mulig har tilgang
  • Holde kildekoden utenfor operasjonelle systemer (kun kompilert kode)
  • Tilgang til kildekoden er så begrenset som mulig (nekte-som-standard)
  • Tilgang til kildekode som logges og loggene gjennomgås med jevne mellomrom
  • Sterke og strenge prosedyrer for endringskontroll
  • Hyppige revisjoner og gjennomganger

Hvorfor er vedlegg A.9 viktig?

Vedlegg A.9 er sannsynligvis den mest omtalte klausulen i hele vedlegg A, og noen vil hevde at den er den viktigste.

Dette er fordi hele Information Security Management System (ISMS) er basert på å sørge for at de rette personene har tilgang til riktig informasjon til rett tid. Å få det riktig er en av nøklene til suksess, men å gjøre det feil kan ha stor innvirkning på virksomheten din.

Tenk om du ved et uhell ga tilgang til konfidensiell informasjon om ansatte til feil personer, som å avsløre hva alle i bedriften får betalt for eksempel.

Konsekvensene av å få denne delen feil kan være betydelige, så det er verdt å bruke nok tid på å tenke gjennom det hele.

Forenkle prosessen med ISMS.online

Det er her plattformen vår virkelig kan hjelpe. Den følger hele strukturen til ISO 27001 og lar deg ta i bruk, tilpasse og legge til innholdet vi tilbyr, noe som gir deg et stort forsprang. For å finne ut mer hvorfor ikke bestille en demo?

Bestill en plattformdemo

Få et forsprang på 81 %

Vi har gjort det harde arbeidet for deg, og gir deg 81 % forsprang fra det øyeblikket du logger på.
Alt du trenger å gjøre er å fylle ut de tomme feltene.

Bestill en demonstrasjon

ISO 27001 krav


ISO 27001 vedlegg A kontroller


Om ISO 27001


ISMS.online støtter nå ISO 42001 – verdens første AI Management System. Klikk for å finne ut mer