Kes tohib lähtekoodi, torule ja tootmiskeskkonnale pääseda?
Juurdepääs tarkvara arenduses käsitleb küsimust, kes tohib teostada milliseid toiminguid teie arenduskanali millistel osadel: kes tohib koodi lugeda, kes tohib koodi muuta ja ühendada, kes tohib buildi käivitada ja kes tohib väljaande tootmisse paigutada. See on konkreetsem küsimus kui üldine organisatsiooniline juurdepääs, sest arendusteam töötab mitme süsteemiga üheaegselt: lähtekoodi hoidlaga, build- ja testkeskkonnaga, ja tavaliselt eraldi tootmiskeskkonnaga, kus tarkvara tegelikult käib.
Põhjus, miks see teema ilmneb turvalisuse küsimustikes ja NIS2-direktiivi hooldusmeetmetes, on see, et viga teie arenduskanali juurdepääsus avaldab otseselt mõju kõigile, kes teie tarkvara kasutavad. Kes saab märkamatult koodi muuta, mis seejärel juurutatakse, mõjutab mitte ainult teie organisatsiooni, vaid ka teie kliente. Seetõttu küsib nii järelevalvija kui ka klient, kes ise hooldusmeetmete alla kuulub, kuidas te seda olete korraldanud.
Miks see konkreetselt puudutab lähtekoodi ja tordu
Arendusteamil on tavaliselt rohkem inimesi, kellel on laiem pääsemise õigus kui rangelt vajalik, lihtsalt sellepärast, et see on praktikas mugav: kõik pääsevad kõikjale, keegi ei pea kusagil ootama. Hooldusmeetmete seisukohalt on see täpselt punkt, milles järgi küsitakse. Mitte sellepärast, et usaldus oleks vale, vaid sellepärast, et tõendatavus on erinevalt usaldusest: järelevalvija või klient soovib teada, kas te saate näidata, kellel on juurdepääs, mitte ainult seda, kas te seda usaldage.
Küsimused, mis siin tekivad, käsitlevad tavaliselt kolme kihti. Esimene on lähtekoodi hoidla ise: kes saab lugeda, kes saab muuta, ja kas on kohustuslik kontroll, enne kui muudatus ühendatakse põhiversiooniga. Teine on build- ja testkeskkond: kes saab buildi käivitada, ja kas selel keskkonnal on juurdepääs andmetele või süsteemidele, mis ei ole testeerimiseks mõeldud. Kolmas on tootmiskeskkond: kes saab tegelikult väljaannet juurutada, ja kas see on erinev inimeste rühm kui need, kes koodi kirjutavad.
Lahutamine kirjutamise ja juurutamise vahel
Korduvalt küsimustikes esinev eristus on see, kas isik, kes koodi kirjutab, on ka see, kes väljaannet tootmisse paigutab. Kui see on sama isik, ilma teise isiku vahepealseta, tekib olukord, kus viga või pahatahtlik muudatus satub märkamatult tootmisse. Paljud organisatsioonid lahendavad seda koodi ühendamise eelse kohustusliku teise ülevaatusega ja eraldi rolli või eraldi õigustega tegeliku juurutamise jaoks. Kuidas see praktikas välja näeb, erineb väga palju meeskonna ja ulatuse järgi; direktiiv ise ei kirjelda konkreetset tööviiside, kuid järelevalvijad ja kliendid vaatavad siiski aluslikku küsimust: kas üks isik saab kontrollimatult muudatusi viia läbi, mis mõjutavad kliente.
Saladused ja võtmed eraldi koodist
Teine punkt, mille üle küsimustikud regulaarselt arutlevad, on see, kus salasõnad, API-võtmed ja muud saladused hoitakse. Saladused, mis on lähtekoodi sees, on nähtavad kõigile, kellel on lähtekoodi lugemisõigus, mis võib olla palju suurem rühm kui need, kes selle võtmega tegelikult töötada peaksid. Eraldi hoidla saladuste jaoks, omade juurdepääsu õigustega lahus koodihoidlast, on tavapärane viis selle eraldamiseks. See, kas ja kuidas te seda korraldada, on tehniline valik; dokumendile asjakas on eelkõige, kas te saate selgitada, miks valitud lähenemine on sobiv teie suuruse ja selle, mida te ehitate, riskide järgi.
Mida te dokumenteerite, mitte ainult mida te seadistate
Juurdepääsuõiguste tehniline seadistamine on üks asi; nende tõendamine on teine, ja see teine osa ununetakse praktikas sageli. Loend sellest, kellel on juurdepääs millise süsteemiga, millal see juurdepääs anti ja millisel alusel, on täpselt see tõendmaterjal, mida küsimustik või järelevalveasutus küsib. Ilma selle loendita peate iga küsimusele vastamisel uuesti otsima; kui teil on elav register iga meetme kõrval, siis vastus on juba valmis. selgitused iga meetme kohta läbi vaadata annab ülevaate sellest, kuidas juurdepääsukontroll seostub üheksa muud kohustusliku meetmega.
Kas teie organisatsioon kuulub ise kohustusliku meetme alla, või saate te selle küsimuse seetõttu, et teie tellijal on kohustus, saab kindlaks teha mõne küsimusega. Neile, kes küsivad, kui ranged on täpselt nõuded juurdepääsukontrollile, kui klient küsib tõendada, mis on korraldatud, annab andmekaitse ja turvalisuse selgitus laiema ülevaate sellest, kus sellist sorti nõuded pärinevad.
Oma olukorra kohta, näiteks kas teie arendusliini konkreetne seadistamine on piisav kohustusliku meetme jaoks, mis kehtib teie või teie tellijale, on jurist või pädev järelevalveasutus õige koht; secria.eu valmistab ette dokumenteerimise, kuid ei tee väiteid üksikute nõuete täitmise kohta.
Kas soovite näha, kuidas juurdepääsukontroll sobib teie ülejäänud dosseesse, või teil on küsimusi selle kohta, mida täpselt selle meetmega mõeldakse? sage küsimused üle lugeda annab paljudele neistest küsimustest juba lühikese vastuse, ja tasuta kiirulatus näitab paar minutiga, kus teie organisatsioon selle teema osas seisab.