Kdo má přístup ke zdrojovému kódu, lince a produkčnímu prostředí?
Řízení přístupu ve vývoji softwaru se týká otázky, kdo smí provádět jakou činnost na jaké součásti vaší vývojové cesty: kdo smí číst kód, kdo smí kód měnit a slučovat, kdo smí spustit build a kdo smí uvést release do produkce. Je to specifičtější otázka než řízení přístupu v organizaci obecně, protože vývojový tým pracuje s více systémy současně: s úložištěm zdrojového kódu, s build a testovacím prostředím a obvykle se zvláštním produkčním prostředím, kde software skutečně běží.
Důvod, proč se právě toto téma vrací v dotaznících zabývajících se bezpečností a v opatřeních k zajištění péče podle směrnice NIS2, spočívá v tom, že chyba v přístupu k vaší vývojové cestě se přímo projeví na všech, kdo váš software používají. Pokud někdo bez povšimnutí změní kód, který se následně nasadí, dotkne se to nejen vaší organizace, ale také vašich zákazníků. Proto se jak dohledávacího orgánu, tak nákupčího, který sám podléhá povinnosti péče, ptají na to, jak jste to zorganizovali.
Proč se to konkrétně týká zdrojového kódu a linky
Vývojový tým obvykle má více lidí s širšími právy, než je nezbytně nutné, jednoduše proto, že to v praxi funguje: všichni mají přístup všude, nikdo na nic nečeká. Z hlediska povinnosti péče je to právě bod, na kterém se dále ptá. Není to proto, že by důvěra byla špatná, ale protože dokazatelnost je něco jiného než důvěra: dohledávací orgán nebo nákupčí chce vědět, zda si můžete ukázat, kdo má přístup, ne pouze to, že tomu věříte.
Otázky, které se zde vrací, se obvykle týkají tří vrstev. První je samotné úložiště zdrojového kódu: kdo může číst, kdo může měnit a existuje povinná kontrola předtím, než se změna sloučí s hlavní verzí. Druhá je build a testovací prostředí: kdo může spustit build a má toto prostředí přístup k datům nebo systémům, které nejsou určeny pro testovací účely. Třetí je produkční prostředí: kdo může skutečně nasadit release a je to jiná skupina lidí než ti, kdo píší kód.
Oddělení psaní a nasazení
Opakující se rozlišení v dotaznících je, zda osoba, která píše kód, je také tou, která nasadí release do produkce. Pokud to bez mezikreslení někoho jiného dělá stejná osoba, vzniká situace, ve které chyba nebo záměrná změna bez povšimnutí skončí v produkci. Mnoho organizací to řeší povinnou druhou kontrolou předtím, než se kód sloučí, a s oddělením role nebo oddělením práv pro skutečné nasazení. Jak to v praxi vypadá, se velmi liší podle týmu a rozsahu; samotná směrnice neklade předpisy pro specifický postup, ale dohledávací orgány a nákupčí se podívají na základní otázku: může jedna osoba nekontrolovaně provádět změny, které se dotknou zákazníků.
Tajemství a klíče odděleně od kódu
Druhý bod, na kterém se dotazníky často dále ptají, je, kde se uchovávají hesla, API klíče a další tajemství. Tajemství, která jsou v samotném zdrojovém kódu, jsou viditelná pro všechny, kdo mají přístup pro čtení k tomuto kódu, což může být mnohem větší skupina, než jsou ti, kdo by měli s tímto klíčem skutečně pracovat. Oddělená trezor pro tajemství, s vlastními přístupovými právy nezávisle na úložišti kódu, je běžný způsob, jak to oddělit. To, zda a jak to zorganizujete, je technická volba; pro dossier je relevantní především to, zda si dokážete vysvětlit, proč je zvolený přístup vhodný pro rozsah a rizika toho, co budujete.
Co zaznamenáte, ne jen co nastavíte
Technické nastavení přístupových práv je jedna věc; jejich dokazatelnost je věc druhá, a právě ta druhá se v praxi často zapomíná. Seznam toho, kdo má přístup k jakému systému, kdy byl přístup udělen a na základě čeho, je přesně ten důkazní materiál, který se vyskytuje v dotaznících nebo kterého se ptají dohledávající orgány. Bez tohoto seznamu si musíte odpověď na každou otázku znovu vyhledat; máte-li živý registr vedle každého opatření, odpověď je již připravena. projít si výklad pro každé opatření poskytuje představu o tom, jak se řízení přístupu vztahuje k devíti dalším opatřením z povinnosti péče.
Zda vaše organizace sama podléhá povinnosti péče, nebo zda tuto otázku dostáváte proto, že ji má zadavatel, lze určit několika otázkami. Pro ty, které se zajímají o to, jak přísné jsou požadavky na řízení přístupu v okamžiku, kdy si zákazník chce ověřit, co bylo dojednáno, poskytuje výklad o ochraně údajů a bezpečnosti širší pohled na to, odkud tyto požadavky pocházejí.
Pro vaši vlastní situaci, například zda je specifické nastavení vaší vývojové linky dostatečné pro povinnost péče, která spočívá na vás nebo na vašem zadavateli, je právník nebo příslušný dohledávající orgán tím správným místem; secria.eu připravuje dokumentaci, ale nevyslovuje se o individuálním dodržování.
Chcete-li vidět, jak se řízení přístupu vejde do zbytku vašeho spisu, nebo máte otázky o tom, co se přesně rozumí tímto opatřením? přečíst si často kladené otázky již na mnoha z těchto bodů poskytuje krátkou odpověď a bezplatná rychlá kontrola ukáže během několika minut, kde se vaše organizace v tomto tématu nachází.