Cine poate accesa codul sursă, conducta și mediul de producție?
Controlul accesului în dezvoltarea de software se referă la întrebarea: cine poate executa ce acțiune pe ce parte a liniei dvs. de dezvoltare: cine poate citi codul, cine poate modifica și fuziona codul, cine poate iniția o construire și cine poate implementa o versiune în producție. Aceasta este o întrebare mai specifică decât controlul accesului pentru o organizație în general, deoarece o echipă de dezvoltare lucrează cu mai multe sisteme simultan: un depozit de cod sursă, un mediu de construire și testare, și de obicei un mediu de producție separat în care software-ul funcționează efectiv.
Motivul pentru care acest subiect apare în chestionarele de securitate și în măsurile de diligență din Directiva NIS2 este că o eroare în accesul la linia dvs. de dezvoltare se transmite direct către toți cei care folosesc software-ul dvs. Oricine poate modifica neobservat codul care este apoi implementat nu doar organizația dvs., ci și clienții dvs. De aceea atât un organism de control cât și un achiziitor care se încadrează el însuși sub obligația de diligență, vă întreabă cum ați structurat aceasta.
De ce se referă aceasta specific la codul sursă și conducta
O echipă de dezvoltare are de obicei mai mulți oameni cu drepturi mai largi decât strict necesar, pur și simplu pentru că este practic: toată lumea poate accesa peste tot, nimeni nu trebuie să aștepte nicăieri. Din perspectiva obligației de diligență, acesta este exact punctul în care se pun întrebări suplimentare. Nu pentru că încrederea ar fi greșită, ci pentru că demonstrabilitatea este altceva decât încredere: un organism de control sau un achiziitor vrea să știe dacă puteți arăta cine are acces, nu doar dacă aveți încredere în aceasta.
Întrebările care apar aici se referă de obicei la trei niveluri. Primul este depozitul de cod sursă în sine: cine poate citi, cine poate modifica, și este verificarea obligatorie înainte ca o modificare să fie fuzionată cu versiunea principală. Al doilea este mediul de construire și testare: cine poate iniția o construire, și are acest mediu acces la date sau sisteme care nu sunt destinate scopurilor de testare. Al treilea este mediul de producție: cine poate implementa efectiv o versiune, și este aceasta un alt grup de oameni decât cei care scriu codul.
Separarea dintre scriere și implementare
O distincție recurentă în chestionare este dacă persoana care scrie codul este și cea care implementează versiunea în producție. Dacă aceasta este aceeași persoană, fără o etapă intermediară de cineva altcineva, apare o situație în care o eroare sau o modificare voință rău intenționată ajunge neobservată în producție. Multe organizații rezolvă aceasta cu o revizuire obligatorie a doua cale înainte ca codul să fie fuzionat, și cu un rol separat sau drepturi separate pentru implementarea efectivă. Cum arată aceasta în practică variază foarte mult în funcție de echipă și de scară; Directiva în sine nu prescrie o metodă specifică, dar organismele de control și achizitorii se uită la întrebarea din spatele ei: poate o persoană implementa neverificat modificări care afectează clienții.
Secrete și chei separate de cod
Un al doilea punct pe care chestionarele pun frecvent întrebări suplimentare este unde sunt stocate parolele, cheile API și alte secrete. Secretele care se află în codul sursă în sine sunt vizibile pentru toți cei cu acces la citire la acel cod, ceea ce poate fi un grup mult mai mare decât cei care ar trebui să lucreze efectiv cu acea cheie. O seif separată pentru secrete, cu drepturi de acces proprii separate de depozitul de cod, este o modalitate comună de a separa aceasta. Dacă și cum structurați aceasta este o alegere tehnică; ceea ce este relevant pentru dosar este în principal dacă puteți explica de ce abordarea aleasă este potrivită pentru scara și riscurile a ceea ce construiți.
Ceea ce documentați, nu doar ceea ce configurați
Configurarea tehnică a drepturilor de acces este un lucru; a o putea demonstra este altul, iar în practică, al doilea se uită mai des. O listă cu cine are acces la ce sistem, când i-a fost acordat și pe baza căruia, este exact documentul de probă pe care o chestionar sau un organul de supraveghere îl solicită. Fără acea listă, trebuie să clarificați din nou la fiecare întrebare; cu un registru dinamic alături de fiecare măsură, răspunsul este deja pregătit. citiți explicația pentru fiecare măsură oferă o perspectivă asupra modului în care controlul accesului se raportează la celelalte nouă măsuri din obligația de grijă.
Dacă organizația dvs. cade ea însăși sub obligația de grijă, sau dacă puneți această întrebare pentru că un client o face, poate fi determinat cu câteva întrebări. Pentru cei care se întreabă cât de stricte sunt exact cerințele privind controlul accesului atunci când un client cere dovezi ale ceea ce a fost reglementat, oferă explicația privind protecția și securitatea datelor o perspectivă mai largă asupra sursei acestor tipuri de cerințe.
Pentru situația dvs. proprie, de exemplu dacă o anumită configurare a liniei dvs. de dezvoltare este suficientă pentru obligația de grijă care vă incumbă sau clientului dvs., avocatul sau autoritatea competentă de supraveghere sunt locurile potrivite; secria.eu pregătește documentarea, dar nu face afirmații cu privire la conformitatea individuală.
Doriți să vedeți cum se încadrează controlul accesului în restul dosarului dvs., sau aveți încă întrebări despre ce se înțelege exact prin această măsură? citiți întrebările frecvente răspunde deja scurt la multe dintre acele puncte, iar analiza rapidă gratuită arată în câteva minute unde se află organizația dvs. pe acest subiect.