Kas turi priėjimą prie šaltinio kodo, konvejerio ir gamybos aplinkos?
Prieigos kontrolė programinės įrangos kūrime susijusi su klausimu, kas kokį veiksmą gali atlikti kurioje jūsų kūrimo konvejerio dalyje: kas gali skaityti kodą, kas gali keisti ir sujungti kodą, kas gali pradėti daryti ir kas gali išleisti laidą į gamybą. Tai yra konkretesnis klausimas nei prieigos kontrolė organizacijai iš viso, nes kūrimo komanda vienu metu dirba su keliais sistemomis: šaltinio kodo saugykla, darymą ir tikrinimo aplinka, ir dažniausiai atskira gamybos aplinka, kurioje programinė įranga iš tikrųjų veikia.
Priežastis, kodėl šis klausimas nuolat iškyla saugumo klausimynuose ir NIS2 direktyvos priežiūros pareigose, yra ta, kad klaida jūsų kūrimo konvejerio prieigos kontrolėje tiesiogiai veikia kiekvieną, kuris naudoja jūsų programinę įrangą. Kas gali nepastebėtai keisti kodą, kuris vėliau bus diegtas, pažeidžia ne tik jūsų organizaciją, bet ir jūsų klientus. Todėl tiek priežiūros institucija, tiek pirkėjas, kuris pats yra nustatytas priežiūros pareigoms, nori žinoti, kaip jūs tai sutvarkėte.
Kodėl tai konkrečiai susijusi su šaltiniu kodu ir konvejeriu
Kūrimo komanda paprastai turi daugiau žmonių, kuriem suteiktos plačiau teisės nei griežtai būtina, tiesiog todėl, kad tai praktiškiau veikia: visi gali nueiti visur, niekam nereikia laukti. Iš priežiūros pareigos požiūrio, tai yra tiksliai taškas, kuriame toliau klausiama. Ne todėl, kad pasitikėjimas būtų klaidingas, bet todėl, kad atskaitomybė yra kažkas daugiau nei pasitikėjimas: priežiūros institucija arba pirkėjas nori žinoti, ar galite parodyti, kas turi priėjimą, o ne tik ar tą pavertat.
Šiame kontekste iškylantys klausimai dažniausiai liečia tris lygius. Pirmasis yra pati šaltinio kodo saugykla: kas gali skaityti, kas gali keisti, ir ar yra privalomas patikrinimas prieš susijungiant pakeitimą su pagrindine versija. Antrasis yra darymą ir tikrinimo aplinka: kas gali pradėti daryti, ir ar šioje aplinkoje yra prieiga prie duomenų arba sistemų, kurios nėra skirtos testavimo tikslams. Trečiasis yra gamybos aplinka: kas iš tikrųjų gali diegti laidą, ir ar tai yra kita žmonių grupė nei tie, kurie rašo kodą.
Atskyrimas tarp rašymo ir diegimo
Nuolat pasikartojantis skirtumas klausimynuose yra tai, ar asmuo, kuris rašo kodą, yra ir tas, kuris diegia laidą į gamybą. Kai tai yra tas pats asmuo, be tarpinio žingsnio iš kito asmens, susidaro situacija, kurioje klaida ar piktavalingai atliktas pakeitimas nepastebėtai patenka į gamybą. Daugelis organizacijų tai sprendžia privaloma antrąja peržiūra prieš surenginėjant kodą, ir atskira vaidmeniu ar atskiromis teisėmis diegimui. Kaip tai praktikoje atrodo, labai skiriasi priklausomai nuo komandos ir jos dydžio; pati direktyva nenurodo jokios konkrečios darbo būdo, bet priežiūros institucijos ir pirkėjai tikrai žiūri į pagrindinį klausimą: ar vienas asmuo gali nekontroliuojamai atlikti pakeitimus, kurie paveiktų klientus.
Paslaptiškumas ir raktai atskirai nuo kodo
Antrasis punktas, kuriame klausimynus dažnai papildo, yra tai, kur saugomi slaptažodžiai, API raktai ir kiti paslaptiškumai. Paslaptiškumai, kurie yra pačiame šaltinio kode, yra matomi visiems, turintiems skaitymo priėjimą prie to kodo, o tai gali būti daug didesnė grupė nei tie, kurie turėtų iš tikrųjų dirbti su tuo raktu. Atskira slaptažodžių saugykla su savomis prieigos teisėmis, atskirai nuo kodo saugyklos, yra dažnas būdas tai atskirti. Tai, ar ir kaip jūs tai sutvarkysite, yra techninė pasirinkti; dossier atžvilgiu svarbiausia yra tai, ar galite paaiškinti, kodėl pasirinktas metodas yra tinkamas jūsų kūrinio apimties ir rizikos atžvilgiu.
Ką jūs nustatote, ne tik ką jūs sutvarkote
Techninis prieigos teisių nustatymas yra viena dalis; jos įrodymasis yra kita, ir ta antroji dalis praktikoje dažniau pamiršama. Sąrašas, kuriame nurodyta, kas turi prieigą prie kurios sistemos, kada ji buvo suteikta ir pagal kokias priežastis, yra būtent toks įrodinėjimo dokumentas, kurio prašo klausimynai arba priežiūros institucijos. Be to sąrašo kiekvienas kartą atsakydami į klausimą turėsite tai iš naujo sužinoti; turint gyvą registrą šalia kiekvieno priemonės, atsakymas jau yra paruoštas. peržvelkite paaiškinimą pagal kiekvieną priemonę parodo, kaip prieigos kontrolė susijusi su kitomis devyniomis priemonėmis iš atsargumo pareigos.
Ar jūsų organizacija pati priklauso atsargumo pareigos sritims, ar tą klausimą gaunate todėl, kad tai daro jūsų užsakovas, galima nustatyti užduodant porą klausimų. Tiems, kurie domisi, kokios tiksliai yra reikalavimų prieigos kontrolei griežtumas, kai klientas prašo įrodyti, kas sutvarkyta, pateikia paaiškinimas apie duomenų apsaugą ir saugumą platesnį vaizdą apie tai, iš kur kyla šio tipo reikalavimai.
Dėl konkrečios jūsų situacijos, pavyzdžiui, ar konkretus jūsų programavimo kelio tvarkymas yra pakankamas atsargumo pareigai, kuri gali tekti jums arba jūsų užsakovui, kompetentingas advokatas arba atitinkama priežiūros institucija yra atitinkama vieta; secria.eu paruošia registraciją, tačiau nesuteikia nuomonės dėl individualaus atitikimo.
Norėtumėte pamatyti, kaip prieigos kontrolė atitinka likusią jūsų bylą, arba turite klausimų dėl to, ką tiksliai reiškia ši priemonė? perskaityti dažniausiai užduodamus klausimus jau trumpai atsakoma į daugybę šių punktų, o nemokama greita patikra per kelias minutes parodo, kokią padėtį jūsų organizacija šiuo klausimu užima.