Vem får tillgång till källkoden, pipelinen och produktionsmiljön?
Åtkomstkontroll i mjukvaruutveckling handlar om frågan vem som får göra vilken åtgärd på vilken del av er utvecklingspipeline: vem som får läsa kod, vem som får ändra kod och slå samman ändringar, vem som får starta ett bygge och vem som får distribuera en version till produktion. Det är en mer specifik fråga än åtkomstkontroll för en organisation i allmänhet, eftersom ett utvecklingsteam arbetar med flera system samtidigt: en källkodsrepository, en bygge- och testmiljö, och oftast en separat produktionsmiljö där programvaran faktiskt körs.
Anledningen till att just detta ämne återkommer i säkerhetsfrågelistor och i skyldigheterna enligt NIS2-direktivet är att ett fel i åtkomsten till er utvecklingspipeline direkt påverkar alla som använder er programvara. Om någon kan ändra kod utan att upptäckas, som sedan distribueras, påverkar det inte bara er organisation utan också era kunder. Därför frågar både en tillsynsmyndighet och en kund som själv omfattas av skyldigheterna, hur ni har organiserat detta.
Varför just källkoden och pipelinen är relevanta
Ett utvecklingsteam har vanligtvis fler personer med bredare rättigheter än vad som är absolut nödvändigt, helt enkelt för att det fungerar praktiskt: alla kan komma åt allt, ingen behöver vänta på någon. Enligt skyldigheterna är det just denna punkt som granskas. Inte för att förtroende skulle vara fel, utan för att verificerbarhet är något annat än förtroende: en tillsynsmyndighet eller en kund vill veta om ni kan visa vem som har åtkomst, inte bara om ni litar på det.
De frågor som återkommer här gäller vanligtvis tre nivåer. Den första är själva källkodsrepository: vem kan läsa, vem kan ändra, och finns det en obligatorisk granskning innan en ändring slås samman med huvudversionen. Den andra är bygge- och testmiljön: vem kan starta ett bygge, och har den miljön åtkomst till data eller system som inte är avsedda för testning. Den tredje är produktionsmiljön: vem kan faktiskt distribuera en version, och är det en annan grupp människor än de som skriver koden.
Separation mellan kodskrivning och distribution
En återkommande skillnad i frågelistor är huruvida personen som skriver kod också är den som distribuerar versionen till produktion. När det är samma person, utan ett mellanchecksteg från någon annan, uppstår en situation där ett misstag eller en illasinnad ändring kan hamna i produktion utan att upptäckas. Många organisationer löser detta med en obligatorisk andra granskning innan kod slås samman, och med en separat roll eller separata rättigheter för faktisk distribution. Hur det ser ut i praktiken varierar mycket mellan team och storlek; direktivet själv föreskriver ingen specifik arbetssätt, men tillsynsmyndigheter och kunder tittar på den underliggande frågan: kan en enskild person ohämmat genomföra ändringar som påverkar kunder.
Hemligheter och nycklar separat från koden
En andra punkt som frågelistor ofta granskar är var lösenord, API-nycklar och andra hemligheter lagras. Hemligheter som finns i själva källkoden är synliga för alla med läsåtkomst till den koden, vilket kan vara en mycket större grupp än de som faktiskt bör arbeta med den nyckeln. En separat valv för hemligheter, med egna åtkomsträttigheter skilda från koddepositionen, är ett vanligt sätt att skilja på det. Huruvida och hur ni arrangerar detta är ett tekniskt val; vad som är relevant för dossiären är framför allt att ni kan förklara varför er valda metod är lämplig för storleken på och riskerna med vad ni bygger.
Vad ni dokumenterar, inte bara vad ni konfigurerar
Att tekniskt konfigurera åtkomsträttigheter är en sak; att kunna påvisa det är en annan, och den andra glöms ofta bort i praktiken. En lista över vem som har åtkomst till vilket system, när den beviljades och på vilken grund, är exakt det bevis som en enkät eller en tillsynsmyndighet frågar efter. Utan den listan måste du lösa det på nytt för varje fråga; med ett levande register vid sidan om varje åtgärd ligger svaret redan klart. gå igenom förklaringen per åtgärd ger en bild av hur åtkomsthantering förhåller sig till de övriga nio åtgärderna från försiktighetskravet.
Oavsett om er organisation själv omfattas av försiktighetskravet, eller om ni får denna fråga för att en uppdragsgivare gör det, kan det fastställas med några få frågor. För den som undrar hur strikt kraven på åtkomsthantering egentligen är när en kund frågar om att påvisa vad som är ordnat, ger förklaringen om dataskydd och säkerhet en bredare bild av var denna typ av krav kommer från.
För er egen situation, till exempel om en specifik inriktning av er utvecklingsväg är tillräcklig för det försiktighetskrav som vilar på er eller er uppdragsgivare, är en jurist eller den behörig tillsynsmyndigheten rätt adress; secria.eu förbereder dokumentationen men ger ingen bedömning av individuell efterlevnad.
Vill ni se hur åtkomsthantering passar in i resten av er dokumentation, eller har ni ytterligare frågor om vad som exakt menas med denna åtgärd? läsa igenom de vanliga frågorna ger svar på många av dessa punkter redan, och den kostnadsfria snabbkontroll visar på några minuter var er organisation står för detta ämne.