Hvem må tilgå kildekoden, pipelinen og produktionsmiljøet?
Adgangskontrol i softwareudvikling handler om spørgsmålet, hvem der må udføre hvilken handling på hvilken del af din udviklingspipeline: hvem der må læse kode, hvem der må ændre og flette kode, hvem der må starte et build, og hvem der må udbyde en release til produktion. Det er et mere specifikt spørgsmål end adgangskontrol for en organisation generelt, fordi et udviklingsteam arbejder med flere systemer samtidigt: et kildekoderepository, et build- og testmiljø, og normalt et separat produktionsmiljø, hvor softwaren faktisk kører.
Grunden til, at netop dette emne vender tilbage i sikkerhedsspørgsmålslister og i sikkerhedsmålene fra NIS2-direktivet, er, at en fejl i adgangen til din udviklingspipeline skabes direkte hos alle, som bruger din software. Hvis nogen ubemærket kan ændre kode, som derefter udbindes, påvirker det ikke kun din egen organisation, men også dine kunder. Derfor spørger både en tilsynsmyndighed og en kunde, som selv er underlagt sikkerhedskravene, hvordan du har organiseret dette.
Hvorfor dette specifikt vedrører kildekoden og pipelinen
Et udviklingsteam har normalt flere personer med bredere rettigheder end strengt nødvendigt, blot fordi det fungerer praktisk: alle kan få adgang overalt, og ingen skal vente på nogen. Fra sikkerhedskravenes perspektiv er det netop det punkt, hvor der stilles opfølgende spørgsmål. Ikke fordi tillid ville være forkert, men fordi dokumentation er noget helt tredje end tillid: en tilsynsmyndighed eller en kunde vil vide, om du kan vise, hvem der har adgang, ikke kun om du stoler på det.
De spørgsmål, der dukker op her, handler normalt om tre niveauer. Det første er selve kildekoderepository'et: hvem kan læse, hvem kan ændre, og er der obligatorisk kontrol, før en ændring flettes med hovedversionen. Det andet er build- og testmiljøet: hvem kan starte et build, og har det miljø adgang til data eller systemer, som ikke er beregnet til testformål. Det tredje er produktionsmiljøet: hvem kan faktisk udbyde en release, og er det en anden gruppe mennesker end dem, som skriver koden.
Adskillelse mellem skrivning og udbydelse
Et tilbagevendende skel i spørgsmålslister er, om den person, som skriver koden, også er den, som udbyder releasen til produktion. Hvor det er samme person uden et mellemtrin af en anden person, opstår en situation, hvor en fejl eller en ondsindet ændring kommer ubemærket ind i produktion. Mange organisationer løser dette med en obligatorisk anden anmeldelse, før kode flettes, og med en separat rolle eller separate rettigheder for faktisk udbydelse. Hvordan det ser ud i praksis, varierer meget fra team til team og fra størrelse til størrelse; direktivet selv foreskriver ingen specifik arbejdsgang, men tilsynsmyndigheder og kunder kigger på det underliggende spørgsmål: kan én person urettet gennemføre ændringer, som påvirker kunderne.
Hemmeligheder og nøgler adskilt fra koden
Et andet punkt, hvor spørgsmålslister regelmæssigt presser på, er, hvor kodeord, API-nøgler og andre hemmeligheder opbevares. Hemmeligheder, som ligger i selve kildekoden, er synlige for alle med læseadgang til den kode, hvilket kan være en meget større gruppe end dem, som faktisk skal arbejde med nøglen. Et separat lager til hemmeligheder med egen adgangskontrol uafhængig af koderepository'et er en almindelig måde at adskille det. Om og hvordan du organiserer dette, er et teknisk valg; relevant for dossieringen er især, om du kan forklare, hvorfor den valgte fremgangsmåde er passende for omfanget og risiciene ved det, du udvikler.
Hvad du dokumenterer, ikke kun hvad du konfigurerer
Etablering af tekniske adgangsrettigheder er én ting; at kunne demonstrere det er en anden, og det andet bliver i praksis ofte glemt. En liste over hvem der har adgang til hvilket system, hvornår denne adgang blev givet, og på hvilket grundlag, er præcis det bevisstykke, som et spørgeskema eller en tilsynsmyndighed spørger om. Uden denne liste skal De udfinde det forfra ved hvert spørgsmål; med et løbende register ved siden af hver foranstaltning ligger svaret allerede klar. gennemgå forklaringen for hver foranstaltning giver et billede af, hvordan adgangskontrol forholder sig til de øvrige ni foranstaltninger fra pligten til at træffe passende foranstaltninger.
Hvorvidt Deres organisation selv er omfattet af pligten til at træffe passende foranstaltninger, eller om De stiller dette spørgsmål, fordi en klient gør det, kan bestemmes ved nogle få spørgsmål. For dem, der undrer sig over, hvor strenge kravene til adgangskontrol præcist er, når en kunde beder om at demonstrere, hvad der er etableret, giver forklaringen om databeskyttelse og sikkerhed et bredere billede af, hvor denne type krav kommer fra.
For Deres egen situation, for eksempel om en specifik indretning af Deres udviklingslinje er tilstrækkelig til den pligt til at træffe passende foranstaltninger, som gælder for Dem eller Deres klient, er en juridisk rådgiver eller den kompetente tilsynsmyndighed det rigtige sted; secria.eu beredte dokumentationen for, men udtaler sig ikke om individuel overholdelse.
Vil De se, hvordan adgangskontrol passer ind i resten af Deres register, eller har De yderligere spørgsmål om, hvad der præcist betyder for denne foranstaltning? læs de hyppigt stillede spørgsmål giver svar på mange af disse punkter allerede kort, og den gratis hurtigscan viser på få minutter, hvor Deres organisation står på dette område.