Kuka saa käyttää lähdekoodia, putkea ja tuotantoympäristöä?
Pääsynhallinta ohjelmistokehityksessä käsittelee kysymystä siitä, kuka saa tehdä mitäkin toimia kehitysputkesi millä osuudella: kuka voi lukea koodia, kuka voi muuttaa ja yhdistää koodia, kuka voi käynnistää rakennuksen ja kuka voi julkaista ohjelmiston tuotantoon. Tämä on täsmällisempi kysymys kuin pääsynhallinta organisaatiossa yleensä, koska kehitystiimi työskentelee useiden järjestelmien kanssa samanaikaisesti: lähdekoodin varastossa, rakentamisen ja testaamisen ympäristössä ja yleensä erillisessä tuotantoympäristössä, jossa ohjelmisto todella toimii.
Syy siihen, että tämä aihe ilmestyy turvallisuuskysymyksissä ja NIS2-direktiivin turvaamisvelvoitteista, on se, että virhe kehitysputkesi pääsyissä vaikuttaa suoraan jokaisen, joka käyttää ohjelmistoasi. Kuka voi muuttaa huomaamatta koodia, joka sitten otetaan käyttöön, vaikuttaa paitsi omaan organisaatioon myös asiakkaisiin. Siksi sekä valvonta-auktoriteetti että asiakas, joka itse kuuluu turvaamisvelvoitteen piiriin, kysyy, miten olet järjestänyt tämän.
Miksi tämä koskee juuri lähdekoodia ja putkea
Kehitystiimissä on yleensä enemmän ihmisiä, joilla on laajemmat oikeudet kuin ehdottomasti tarpeen olisi, yksinkertaisesti koska se on käytännöllistä: kaikilla on pääsy kaikkeen, kukaan ei joudu odottamaan. Turvaamisvelvoitteen näkökulmasta juuri tämä on kysyttävä kohta. Ei siksi, että luottamus olisi väärin, vaan koska todennettavuus on jotain muuta kuin luottamus: valvonta-auktoriteetti tai asiakas haluaa tietää, pystytkö näyttämään, kenellä on pääsy, eikä vain sitä, että luotat siihen.
Kysymykset, jotka nousevat esiin, liittyvät yleensä kolmeen tasoon. Ensimmäinen on lähdekoodin varasto itse: kuka voi lukea, kuka voi muuttaa, ja onko pakollinen tarkistus ennen kuin muutos yhdistetään pääversioon. Toinen on rakentamisen ja testaamisen ympäristö: kuka voi käynnistää rakennuksen, ja pääseekö se ympäristö tietoihin tai järjestelmiin, jotka eivät ole tarkoitettu testaukseen. Kolmas on tuotantoympäristö: kuka voi todella ottaa julkaisun käyttöön, ja onko se eri ihmisryhmä kuin ne, jotka kirjoittavat koodia.
Ero kirjoittamisen ja käyttöönottamisen välillä
Kysymyksissä toistuvasti esiin tulevaa eroa on se, onko koodi kirjoittava henkilö sama kuin se, joka ottaa julkaisun tuotantoon käyttöön. Kun se on sama henkilö, ilman toisen henkilön välivaihetta, syntyy tilanne, jossa virhe tai pahantahtoinen muutos päätyy huomaamatta tuotantoon. Monet organisaatiot ratkaisevat tämän velvoittavalla toisella tarkistuksella ennen kuin koodi yhdistetään, ja erillä roolilla tai erillisillä oikeuksilla varsinaiseen käyttöönotolle. Kuinka tämä käytännössä näyttää, vaihtelee suuresti tiimien ja koon mukaan; direktiivi itse ei kirjoita tiettyä työtapaa, mutta valvonta-auktoriteetit ja asiakkaat katsovat taustalla olevaa kysymystä: voiko yksi henkilö hallitsemattomasti tehdä muutoksia, jotka vaikuttavat asiakkaisiin.
Salaisuudet ja avaimet erillään koodista
Toinen kohta, josta kysymykset usein kysyvät, on se, missä salasanat, ohjelmointirajapinnan avaimet ja muut salaisuudet säilytetään. Salaisuudet, jotka ovat itse lähdekoodissa, näkyvät kaikille, joilla on lukulupa kyseiseen koodiin, mikä voi olla paljon suurempi joukko kuin ne, joiden pitäisi todella käyttää kyseistä avainta. Erillinen säilytys salaisuuksille omilla pääsyoikeuksilla koodivarastosta erillään on tavanomainen tapa erottaa ne toisistaan. Se, otat tämän käyttöön ja miten, on tekninen valinta; asiakirjoihin relevantiksi tulee lähinnä se, voitko selittää, miksi valittu lähestymistapa sopii rakentamasi ohjelmiston kokoon ja riskeihin.
Mitä dokumentoit, ei vain mitä asetat
Pääsynhallinnon tekninen toteuttaminen on yksi asia; sen dokumentoitu osoittaminen on toinen, ja jälkimmäinen unohtuu käytännössä usein. Luettelo siitä, kenellä on pääsy mihin järjestelmään, milloin pääsy on myönnetty ja millä perusteella, on juuri se todiste, jota kyselylomake tai valvontaviranomainen pyytää. Ilman tätä luetteloa joudut ratkaisemaan jokaisen kysymyksen uudelleen; elävän rekisterin kanssa jokaisen toimenpiteen rinnalla vastaus on jo valmiina. jokaisen toimenpiteen selityksen läpikäynti antaa kuvan siitä, miten pääsynhallinta suhteutuu muihin yhdeksään zorgplicht-velvoitteen mukaiseen toimenpiteeseen.
Se, kuuluuko organisaatiosi itse zorgplicht-velvoitteen piiriin vai saatko tämän kysymyksen siksi, että tilaajasi kuuluu siihen, voidaan määrittää muutamalla kysymyksellä. Sille, joka pohtii, kuinka tiukkoja pääsynhallinnan vaatimukset tarkalleen ottaen ovat, kun asiakas pyytää osoittamaan, mitä on järjestetty, antaa selitys tietosuojasta ja turvaamisesta laajemman kuvan siitä, mistä tämänkaltaiset vaatimukset juontavat.
Omasta tilanteesta, esimerkiksi siitä, onko kehityslinjaston tietty järjestely riittävä sinulle tai tilaajallesi kuuluvalle zorgplicht-velvoitteelle, oikea paikka on juristin tai toimivaltaisen valvontaviranomaisen puoleen kääntyä; secria.eu valmistaa dokumentointia mutta ei anna lausuntoa yksittäisen noudattamisen oikeellisuudesta.
Haluatko nähdä, miten pääsynhallinta sopii muuhun dossiereihin, vai onko sinulla vielä kysymyksiä siitä, mitä tällä toimenpiteellä tarkalleen tarkoitetaan? usein kysytyt kysymykset läpi antaa monista näistä kohdista jo lyhyen vastauksen, ja ilmainen pika-arvio näyttää muutamassa minuutissa, missä organisaatiosi tämän aiheen osalta on.