Kas var piekļūt primkodام, konveijeram un ražošanas videi?
Piekļuves kontrole programmatūras izstrādē ir jautājums par to, kas drīkst veikt kādu darbību ar kurām izstrādes konvejera daļām: kas drīkst lasīt kodu, kas drīkst mainīt un sapludināt kodu, kas drīkst sākt būvējumu un kas drīkst izlaist versiju uz ražošanu. Tas ir konkrētāks jautājums nekā piekļuves kontrole organizācijai kopumā, jo izstrādes komanda strādā ar vairākiem sistēmām vienlaikus: primkoda repozitoriju, būvējuma un testēšanas vidi, un parasti atsevišķu ražošanas vidi, kur programmatūra faktiski darbojas.
Iemesls, kāpēc šis temats atgriežas drošības jautājumiski un NIS2 direktīvas aprūpes pienākuma pasākumos, ir tas, ka kļūda jūsu izstrādes konvejera piekļuvē tiešā veidā ietekmē ikvienus, kas izmanto jūsu programmatūru. Kurš nemanāmi var mainīt kodu, kas pēc tam tiek izplatīts, skar ne tikai jūsu pašas organizāciju, bet arī jūsu klientus. Tāpēc gan uzraugs, gan pircējs, kurš pats pakļauts aprūpes pienākumam, vēlas zināt, kā jūs to esat organizējis.
Kāpēc tieši primkods un konvejers
Izstrādes komandai parasti ir vairāk cilvēku ar plašākām tiesībām, nekā stingri nepieciešams, vienkārši tāpēc, ka tas praktiski darbojas: ikviens var visvietā, nevienam nav jāgaida. No aprūpes pienākuma viedokļa tas ir tieši punkts, uz kuru tiek jautāts sīkāk. Ne tāpēc, ka uzticība būtu nepareiza, bet tāpēc, ka pierādāmība ir atšķirīga no uzticības: uzraugs vai pircējs vēlas zināt, vai jūs varat parādīt, kam ir piekļuve, nevis tikai vai jūs tam uzticaties.
Jautājumi, kas šeit atgriežas, parasti attiecas uz trim slāņiem. Pirmais ir pats primkoda repozitorijs: kas var lasīt, kas var mainīt, un vai ir obligāta pārbaude, pirms izmaiņa tiek sapludināta ar galveno versiju. Otrais ir būvējuma un testēšanas vide: kas var sākt būvējumu, un vai šai videi ir piekļuve datiem vai sistēmām, kas nav paredzētas testēšanas nolūkiem. Trešais ir ražošanas vide: kas faktiski var izlaist versiju, un vai tā ir cita cilvēku grupa nekā tie, kuri raksta kodu.
Atdalīšana starp rakstīšanu un izlaišanu
Atkārtojams atšķirums jautājumiski ir tas, vai persona, kas raksta kodu, ir arī tā, kas izlaiž versiju uz ražošanu. Ja tas ir viens un tas pats cilvēks bez starpposmiem no kāda cita, rodas situācija, kurā kļūda vai ļaunprātīga izmaiņa nemanāmi nonāk ražošanā. Daudzi uzņēmumi to atrisina ar obligātu otro pārbaudi, pirms kods tiek sapludināts, un ar atsevišķu lomu vai atsevišķām tiesībām faktiskai izlaišanai. Tas praktiski izskatās dažādi atkarībā no komandas un apjoma; direktīva pati par sevi nepieņem nekādu konkrētu metodi, bet uzraugi un pircēji tomēr skatās pamatjautājumam: vai viens cilvēks var nekontrolēti ieviest izmaiņas, kas skar klientus.
Noslēpumi un atslēgas atsevišķi no koda
Otrais punkts, uz kuru jautājumiski regulāri fokusējas, ir tas, kur paroles, API atslēgas un citi noslēpumi tiek glabāti. Noslēpumi, kas atrodas pašā primkodā, ir redzami ikvienam, kam ir lasīttiesības uz šo kodu, kas var būt daudz lielāka grupa nekā tie, kuriem faktiski būtu jāstrādā ar šo atslēgu. Atsevišķs noslēpumu glabātuvs ar pašiem piekļuves tiesībām neatkarīgi no koda repozitorija ir izplatīts veids, kā to atdalīt. Tas, vai un kā jūs to organizējat, ir tehnisks lēmums; dosijei ir būtiski tikai tas, vai jūs varat izskaidrot, kāpēc izvēlētā pieeja ir piemērota jūsu būvējuma apjomam un riskiem.
Ko jūs dokumentējat, nevis tikai ko jūs iestatāt
Piekļuves tiesību tehniskā iestatīšana ir viens uzdevums; to pierādāma padarīšana ir otrs, un šis otrais uzdevums praksē bieži vien tiek aizmirsts. Saraksts par to, kuram ir piekļuve kādai sistēmai, kad tā tika dota un uz kādiem pamatiem, ir tieši tāds pierādījums, ko meklē jautājumu saraksts vai pārraudzības iestāde. Bez šī saraksta jums ir katru reizi jautājums atsevišķi jāsastāda; ar dzīvu reģistru pie katras pasākuma ir atbilde jau gatava. izskatīt paskaidrojumus katram pasākumam sniedz priekšstatu par to, kā piekļuves kontrole ir saistīta ar pārējiem deviņiem pasākumiem no aprūpes pienākuma.
To, vai jūsu organizācija pati ir pakļauta aprūpes pienākumam vai jūs šo jautājumu saņemat tāpēc, ka to ir izdarījis uzdevuma devējs, var noteikt ar dažiem jautājumiem. Tiem, kas domā, cik strikti īsti ir piekļuves kontroles prasības, kad klients pieprasa pierādīt, kas ir sakārtots, dod paskaidrojums par datu aizsardzību un drošību plašāku priekšstatu par to, no kurienes šādi noteikumi nāk.
Sava uzņēmuma situācijai, piemēram, vai konkrēta jūsu izstrādes plūsmas struktūra atbilst aprūpes pienākumam, kas ir uz jums vai uz jūsu uzdevuma devēju, jurista vai atbildīgā pārraudzības iestāde ir pareizais vieta; secria.eu nodrošina dokumentēšanu, bet neuzsver nolēmumu par individuālu atbilstību.
Vēlaties redzēt, kā piekļuves kontrole ietilpst jūsu pārējā failā, vai jums joprojām ir jautājumi par to, kas precīzi ir paredzēts ar šo pasākumu? izlasīt bieži uzdotos jautājumus sniedz īsu atbildi uz daudziem no šiem punktiem, un bezmaksas ātrā pārbaude parāda dažu minūšu laikā, kur jūsu organizācija šajā jautājumā atrodas.