Ki férhet hozzá a forráskódhoz, a folyamathoz és a termelési környezethez?
A szoftfejlesztésben a hozzáférés-kezelés azt az alapkérdést vizsgálja, hogy ki milyen műveletet hajthat végre a fejlesztési folyamat mely összetevőjén: ki olvashat kódot, ki módosíthat és összevonhat kódot, ki indíthat buildot, és ki tehet közzé egy kiadást a termelésben. Ez konkrétabb kérdés, mint a szervezeti szintű hozzáférés-kezelés, mert egy fejlesztőcsapat egyszerre több rendszerrel dolgozik: egy forráskód-adattárral, egy build- és tesztkörnyezettel, valamint általában egy külön termelési környezettel, ahol a szoftver valójában fut.
Az oka annak, hogy ez a témakör visszatérően felbukkan a biztonsági kérdéssorokban és a NIS2-irányelv cybervédelmi intézkedésekben, az, hogy a fejlesztési folyamathoz való hozzáférésben elkövetett hiba közvetlenül érinti szoftverét használó mindenkit. Ha valaki észrevétlenül módosíthat kódot, amelyet később telepítenek, az nem csak a saját szervezetét érinti, hanem az ügyfeleit is. Ezért kérdez rá mind a felügyelet, mind az olyan megrendelő, aki saját maga is cybervédelmi kötelezettség alatt áll, hogy ezt hogyan szervezték meg.
Miért éppen a forráskód és a folyamat?
Egy fejlesztőcsapatnak jellemzően több ember rendelkezik tágabb jogosultságokkal, mint ami szigorúan szükséges, egyszerűen azért, mert így praktikus: mindenki mindenhová férhet hozzá, senki sem kell, hogy várjon. A cybervédelmi kötelezettség szempontjából éppen ez az a pont, ahol mélyebb kérdések merülnek fel. Nem azért, mert a bizalom téves volna, hanem mert az ellenőrizhetőség más, mint a bizalom: a felügyelet vagy egy megrendelő tudni akarja, hogy meg lehet mutatni, ki férhet hozzá, nem csak azt, hogy erre jellemzően hagyatkozunk.
Az ezzel kapcsolatos kérdések jellemzően három szintet érintenek. Az első maga a forráskód-adattár: ki tud olvasni, ki módosíthat, és van-e kötelező ellenőrzés, mielőtt egy módosítás az alaptörténettel összevonódik. A második a build- és tesztkörnyezet: ki indíthat buildot, és van-e hozzáférése ennek a környezetnek olyan adatokhoz vagy rendszerekhez, amelyek nem tesztcélokra szánt. A harmadik a termelési környezet: ki tehet közzé valóban egy kiadást, és ez más embercsoportnak adott-e jogosultságot, mint akik a kódot írják.
Az írás és a közzététel szétválasztása
A kérdéssorokban visszatérő megkülönböztetés az, hogy aki kódot ír, ugyanez a személy-e, aki a kiadást a termelésbe helyezi. Amikor ugyanez a személy végzi el mindkét feladatot, közbenső lépés nélkül más által, olyan helyzet alakul ki, amelyben egy hiba vagy gonosz szándékú módosítás észrevétlenül kerül a termelésbe. Sok szervezet ezt kötelező második áttekintéssel oldja meg, mielőtt a kódot összevonnák, és külön szerepkörrel vagy jogosultságokkal a tényleges közzétételhez. Ennek gyakorlati megvalósulása erősen különbözik a csapatok és a méret függvényében; az irányelv maga nem ír elő konkrét eljárást, de a felügyelet és a megrendelők az alapvető kérdésre figyelnek: egy személy ellenőrzés nélkül végigviheti-e az ügyfeleket érintő módosításokat.
Titkok és kulcsok a kódtól elkülönítve
Egy másik pont, amelyre a kérdéssorok gyakran rákérdeznek, az az, hogy hol tárolnak jelszavakat, API-kulcsokat és más titkokat. A forráskódban tárolt titkok láthatók mindenki számára, aki hozzáféréssel rendelkezik az adott kódhoz, amely sok nagyobb csoport lehet, mint akik valójában jogosultak a kulcs használatára. Egy külön tár a titkokhoz, saját hozzáférési jogosultságokkal az adattártól elkülönítve, egy gyakori módszer ennek szétválasztására. Hogy és hogyan szervezi ezt, technikai választás; a dosszié szempontjából lényeges főleg az, hogy meg tudja-e magyarázni, miért megfelelő az alkalmazott megközelítés az építette dolog mérete és kockázatai szempontjából.
Mit rögzít, nem csupán mit állít be
A hozzáférési jogok technikai beállítása az egyik dolog; annak igazolása egy másik, és ezt az utóbbit a gyakorlatban gyakrabban elfeledik. Egy lista arról, hogy ki férhet hozzá mely rendszerekhez, mikor kapta meg a hozzáférést, és milyen alapon, pontosan az a bizonyíték, amelyre egy kérdőív vagy egy felügyelet ügynök rákérdez. E lista nélkül minden kérdésre újra rá kell keresnie; egy életbenlevő nyilvántartás mellett minden mérték mellett a válasz már készen áll. végigmegy a mérték szerinti magyarázaton képet ad arról, hogy a hozzáférési jogok kezelése hogyan viszonyul a gondossági kötelezettség másik kilenc mértékéhez.
Az, hogy az Ön szervezete maga tartozik-e a gondossági kötelezettség alá, vagy azt a kérdést kapja-e, mert egy megrendelő igen, az néhány kérdéssel meghatározhatóvan. Aki azt kérdezi, milyen szigorúak pontosan a hozzáférési jogok kezelésére vonatkozó követelmények, ha egy ügyfél azt kéri, hogy mutasson be a megtettekről, az adatvédelem és biztonság magyarázata tágabb képet ad arról, hogy honnan erednek az ilyen követelmények.
A saját helyzethez, például ahhoz, hogy egy adott fejlesztési sor felépítése elegendő-e az Önre vagy megrendelőjére vonatkozó gondossági kötelezettséghez, egy jogász vagy a illetékes felügyeleti hatóság az alkalmas hely; a secria.eu felkészül az rögzítésre, de nem nyilatkozik az egyéni megfelelésről.
Szeretné-e látni, hogyan illeszkedik a hozzáférési jogok kezelése a dosszié többi részéhez, vagy még kérdése van arról, hogy mit értünk pontosan ezalatt a mérték alatt? olvassa végig a gyakran feltett kérdéseket sok ilyen ponton már rövid választ ad, és az ingyenes gyorselemzés néhány perc alatt megmutatja, hogy a szervezete ezen a tárgyban hol áll.