Naudotojų teisės IT komandoje: vadovas kūrėjams

Įvadas

IT sektoriuje ir programinės įrangos kūrime naudotojų teisių valdymas komandoje yra daug daugiau nei paprastas vidinis organizavimas. Jis lemia sistemų saugumą, normatyvinį atitikimą ir kolektyvinį produktyvumą. Pasak 2024 m. IBM Security tyrimų, 74 % duomenų nuotėkių apima privilegijuotų prieigos teisių piktnaudžiavimą arba vagystę. Susiduriant su dažniausiai paskirstytomis, daugiarojektėmis ir labai automatizuotomis komandomis, apibrėžti, kas turi prieigą prie ko ir kodėl, tapo pirmosios eilės strateginiu klausimą. Šis straipsnis pavedinys jus žingsnis po žingsnio per naudotojų teisių strukturizavimą: autorizavimo modeliai, praktinės gerosios praktiką, integravimas į programinės įrangos kūrimo srautus ir poveikis techninio pasiūlymo elektroniniam parašui.

---

Suprasti prieigos teisių valdymo modelius

Prieš konfigūruojant ką nors, būtina pasirinkti tinkamą konceptualų teisių valdymo modelį. Kiekviena IT komandos architektūra reikalauja skirtingo paradigmos.

RBAC modelis: pramonės standartas

Role-Based Access Control (RBAC) yra labiausiai paplitęs modelis programinės įrangos kūrimo aplinkose. Jis susideda iš to, kad leidimai nėra suteikiami tiesiogiai asmenims, o iš anksto nustatytiems vaidmenims (jaunas kūrėjas, techninis lyderis, DevOps inžinierius, sistemos administratorius ir kt.), o tada kiekvienas naudotojas siejamas su vienu ar keliais vaidmenimis.

RBAC privalumai:

• Supaprastintas valdymas atleidus/priėmus darbuotojus (offboarding)
• Aiški audito prieiga: tiksliai žinote, ką gali daryti kiekvienas vaidmuo
• Rizikos nuo nenumatyto teisių pakilimo sumažinimas

Praktikoje jaunas kūrėjas turės prieigą tik prie kūrimo ir pasitikrinimo aplinkų, niekada prie gamybos. Techninis lyderis gali tvirtinti pull prašymus ir paleisti CI/CD pipeline'ius, tuo tarpu tik vyresnysis DevOps administratorius turės prieigą prie gamybos paslapčių raktų.

ABAC modelis sudėtingoms aplinkoms

Attribute-Based Access Control (ABAC) eina toliau nei RBAC, sąlyginiu prieigos teises kontekstiniais atributais: naudotojo vieta, prisijungimo laikas, projekto klasifikacija, kodo saugyklos jautrumas. Šis modelis yra ypač tinkamas komandoms, kurios valdo projektus finansų, sveikatos priežiūros arba gynybos sektoriaus klientams, kur segregacijos reikalavimus yra didžiausi.

Konkretiškai, inžinierius gali turėti prieigą prie Git saugyklos ryte iš įmonės biuro, tačiau šiam prašymui gali būti atmestas savaitgalį iš nepatvirtinto gyvenamojo IP adreso – net jei vaidmuo yra identiškas.

Mažiausio privilegio principas kaip vedlys

Nepriklausomai nuo pasirinkto modelio, mažiausio privilegio principas (Least Privilege Principle) turi vadovauti visai teisių politikai. Šis principas, kuris yra ANSSI rekomendacijose ir formalizuotas ISO/IEC 27001 standarte, teigia, kad kiekvienas naudotojas ar procesas turėtų turėti tik būtinai reikalingas teises savo užduočių atlikimui.

DevOps kontekste tai reiškia, kad niekada nereikėtų dalintis bendrais paslaugų paskyrais, reikėtų naudoti riboto laiko trukmės paslaptis (trumpaamžius žetonus) ir niekada nesuteikti administratoriaus teisių pagal numatytuosius nustatymus.

---

Strukturizuoti teises pagal aplinką ir projektą

Programinės įrangos kūrimo komanda retai dirba tik su vienu projektu ar viena aplinka. Teisių segregacija turi atspindėti šią operacinę realybę.

Izoliuoti kūrimo, pasitikrinimo ir gamybos aplinkas

Griežtas aplinkų atskyrimas yra pagrindinė gera praktika. Daugumoje brandžių komandų teisės yra strukturizuotos taip:

• Kūrimo aplinka: prieinama visiems projekto kūrėjams, su plačiais leidimais eksperimentavimui
• Pasitikrinimo/test aplinka: prieiga ribota vyresniesiems kūrėjams ir QA inžinieriams; nėra galimybės rankiniu būdu diegti be patvirtinimo
• Gamybos aplinka: prieiga tik sistemos administratoriams ir automatizuotiems pipeline'iams (CI/CD) su būtinu daugiafaktoriniu autentikavimu

Ši segregacija drastiškai sumažina atakos paviršių ir riboja kompromitavimo pasėkų mastą.

Valdyti teises bendradarbiavimuose kūrimo įrankiuose

Platformos tokios kaip GitHub, GitLab ar Bitbucket siūlo numanias teisių sistemas, kurios nusipelno ypatingo dėmesio. GitHub Enterprise, pavyzdžiui, leidimo lygiai apima: Read, Triage, Write, Maintain ir Admin – kiekvienas su tiksliai apibrėžtomis galimybėmis.

Gera praktika: apibrėžti RACI prieigos matricą kiekvienam kritiniam saugyklai, formalizuotą projekto vidinio dokumentavimo viduje. Ši matrica identificira, kas yra atsakingas, tvirtintis, pasikonsultavo ir informuotas kiekvienai saugyklos veiksmų rūšiai.

Projektų valdymo įrankiams (Jira, Linear, Notion) taip pat galvokite taikyti tą patį griežtumo lygį: išorinis paslaugų teikėjas turėtų prieigą tik prie jam susijusių bilietų, niekada prie visamos strateginės kelio žemėlapio.

Automatizuoti teisių valdymą CI/CD pipeline'iuose

Teisės neliečia tik žmonių. Modernios architektūros metu paslaugų paskyros, API žetonai ir CI/CD agentai yra tokios pat ne-žmogaus esybės, kurios turi leidimus. Jų valdymas dažnai yra pamirštas ir sudaro pagrindinį atakos vektorių.

Praktinės rekomendacijos:

• Naudoti dedikuotą paslapčių valdiklį (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault), o ne aplinkos kintamuosius tiesiogine forma
• Konfigūruoti API žetonus su trumpa trukmės laikotarpiu ir automatine rotacija
• Reguliariai audituoti paslaugų paskyrų teises ir ištrinti nepanaudotas

Šios praktiką yra dalimi dokumentinės atitikties ir sekimo pareigu, kurią Certyneo lydi, ypatingai per saugos politikos elektroninį parašą.

---

Integruoti teisių valdymą į bendradarbio gyvenimo ciklą

Teisių valdymas nėra statinė konfigūracija: jis turi nuolat evoliucionuoti keičiantis komandoje.

Strukturizuotas atgabendavimo procesas

Naujo kūrėjo ar paslaugų teikėjo atvykimas turi suaktyvinti formalizuotą teisių priskyrimo procesą, idealiai automatizuotą per Identity Governance and Administration (IGA) įrankį arba bent per prašymo formos su valdybine patvirtinimu.

Automatinis parūpinimas iš HR sistemos (per SCIM jungtis į Active Directory, Okta ar Google Workspace) garantija, kad teisės priskiriamos pirma dieną ir svarbiausia atšaukiamos paskutinę dieną. Pasak Ponemon Institute (2023) tyrinėjimo, 58 % įmonių pripažįsta, kad buvę darbuotojai gali toliau turėti prieigą prie sistemų po jų atsistatymo.

Šis atgabendavimo procesas dažnai apima IT chartijos, saugos politikos arba konfidencialumo sąlygų pasirašymą – dokumentus, kuriems elektroninis parašas įmonėje suteikia nenuginčijamą teisinį sekimo.

Periodiniai teisių peržiūros (Access Reviews)

DORA (Digital Operational Resilience Act) ir saugos žinialraščiai kaip SOC 2 ar ISO 27001 reikalauja periodinių prieigos teisių peržiūrų – paprastai kas ketvirtį ar kas pusmetį. Šie auditi susideda iš to, kad kiekvienas vadovas patvirtina ar atšaukia kiekvieno savo komandos nario teises.

Šios peržiūros turi būti dokumentuotos ir sekamos. Teisių audito ataskaitų elektroninis parašas sudaro gerą praktiką jų integralumui ir neperleisimui garantuoti – tema, kurią detalizuoja mūsų elektroninio parašo visus vadovas.

Valdyti ypatingus atvejus: paslaugų teikėjai, freelancerai ir studentai

Išoriniai dalyviai teikia specifinį iššūkį. Jie turi turėti pakankami prieigą veiksmingai dirbti, bet turi būti izoliuoti nuo jautrių duomenų ir kritinių sistemų.

Geros praktikou:

• Kurti atskiras paskyras paslaugų teikėjams (niekada bendros vidinės paskyros)
• Pritaikyti automatinę išeigos datą išorėms paskyroms
• Apriboti prieigą prie tinklo per dedikuotą VPN arba Zero Trust architektūrą
• Pasirašyti konfidencialumo sutartį (NDA) prieš bet kokią prieigą – idealiai per elektroninį parašą atitiktyje eIDAS maksimaliai įrodymų vertei

---

Atitiktis, auditas ir IT komandos teisių valdymas

Teisių valdymas ne sumatytas į techninį sukonfigūravimą: jis yra daugiau valdymo ketvirtdalio sistemos dalies.

Palaikyti habilituoto registrą

Visa organizacija, tvarkanti asmens duomenis arba valdanti kritines sistemas, turi palaikyti atnaujintą habilituotų registrą. Šis dokumentas aprašo, kiekvienos sistemos ir kiekvienos programos:

• Suteikiami naudotojai ir jų prieigos lygiai
• Teisių priskyrimo ir peržiūros datos
• Susijusios valdybos patvirtinimai

BDAR (23 straipsnio) kontekste šis registras yra dalimi atitinkamų techninių ir organizacinių priemonių, kurias turi parodyti duomenų tvarkytojus. Jo nebuvimas gali būti nubaustas CNIL.

Prieigos žurnalizavimas ir monitoringas

Paprasti teisių priskyrimas nepakanka: reikia stebėti jų naudojimą. SIEM (Security Information and Event Management) sprendimai tokios kaip Splunk, Elastic SIEM ar Microsoft Sentinel leidžia atlikti nenormalų elgesį: prisijungimą ne darbo metu, masyvus failų atsisiuntimus, prieigą prie netikinų išteklių.

NIS2 direktyva, transponuota į Prancūzijos teisę 2024 pabaigoje, reikalauja esminėms ir svarbos esybėms (iš jų daug ESN ir kritiškai svarbių programinės įrangos redaktorių) diegti tvirtas aptikimo ir žurnalizavimo galias.

Elektroninio parašo vaidmuo teisių valdymo nuomonėje

Teisių prieigos politikų, naudotojų chartijos ir konfidencialumo sutarčių formalizavimas per elektroniniu parašu pasirašytus dokumentus žymiai sustiprina valdymą. Skirtingai nei paprastas el. laiškas sutikimui, elektroniniu parašu pasirašytas dokumentas su eIDAS atitikties sprendimu suteikia integralumo ir tapatybės įrodymą, kuris bus priimtinas jei litigas.

Certyneo leidžia ypatingai konfigūruoti parašų srautus su tiksliais vaidmenimis – pavyzdžiui, reikalauti RSSI parašo prieš viešinant saugos politiką – kurie natūraliai integruojasi į brandžią teisių valdymo politiką. Taip pat galite įvertinti šios priemonės operacinę naudą naudodami elektroninio parašo ROI skaičiuoklę.

Teisiniai rėmai, taikytini IT komandos naudotojų teisių valdymui

IT komandoje naudotojų teisių valdymas nėra tik techninis derinimas: jis yra suvaržytas gana ribojančių normatyvinių aktų rinkiniu, kurių nežinojimas organizacijoms gresia rimtomis sankcijomis.

BDAR – Reglamentas (ES) 2016/679

BDAR 5 straipsnis iškelia duomenų minimizavimo principą, kuris pagal analogiją išplečiasi į prieigos minimizavimo principą: naudotojas turėtų prieigą tik prie duomenų, kurie būtini savo užduočiams. 25 straipsnis (duomenų apsauga nuo pat dizaino) ir 32 straipsnis (tvarkymų saugumas) įpareigoja diegti atitinkamas technines ir organizacines priemones, tarp kurių aiškiai yra prieigos kontrolė.

CNIL nurodė savo doktrines, kad habilituotų taisyklių nesilaikimas sudaro 32 straipsnio pažeidimą. Baudos siekiant iki 4% visuotinio pagrindinio įmonės biudžeto arba 20 milijonų eurų gali būti skiriamos.

NIS2 direktyva – Direktyva (ES) 2022/2555

Transponuota Francūzijos teisėje spalio 17, 2024 dėsnio, NIS2 direktyva gerokai išplečia esybių, turinčių kibernetinio saugumo pareigas, sritį. Dabar apima daug programinės įrangos redaktorių, IT paslaugų tiekėjų ir ESN. NIS2 21 straipsnis ypatingai nustatytina prieigos kontrolės, tapatybės valdymo ir saugos įvykių žurnalizavimo priemoniniu.

Reglamentas eIDAS – Reglamentas (ES) 910/2014 ir eIDAS 2.0

Dėl teisės formalizavimo politikų (chartijos, saugos politikos, tvarkalo sutarčių), eIDAS reglamentas suteikia pilną teisinę vertę elektroniniu parašais. 25 straipsnis nurodytina, kad kvalifikuotas elektroninis parašas turi teisinį poveikį, lygiavertį rašytiniam parašui. 26 straipsnis apibrėžtina išlaidos, taikytinas pažangautiems elektroniniams parašams, ypatingai parašu unikalumą ir jeigu visos keletos pakeitimai būtų atpažinti.

Darbo teisė ir darbdavio pareigos

Francūzijos teisėje darbdavys yra atsakingas darbininkų numatytos IT sistemos saugumui (Darbo kodekso L.4121-1 straipsnis). Kasacijos Teismo jurisprudencija kelis kartus patvirtino, kad prieigos kontrolės trūkumas įpareigoja darbdavį atsakomybę, jei įvyksta duomenų pažeidimas. Vidinis darbdavio reglamentas arba IT chartija, kurios galiojimas yra sureguliytas Darbo kodekso L.1321-1 straipsniu, turi formalizuoti sistemos naudojimo taisykles ir susijusias teises.

Naudojimo scenarijos: teisių valdymas IT komandoje

Scenarijus 1 – ESN, valdanti kelių klientų projektus vienu metu

Apie 80 kūrėjų turinčios skaitmeninės paslaugos įmonė dirba vienu metu dešimt kliento projektų, iš jų kai kurie reglamentuotuose sektoriuose (finansai, sveikatos priežiūra). Prieš diegiant strukturizuotą teisių politiką, prieigai valdimanoms ad hoc: kūrėjai išlaikė prieigą į senus projektus jei naikinami, ir kai kurie API žetonai buvo bendra kelios komandose.

Diegus IGA sprendimą su RBAC rolėmis pagal projektą ir centralizuotą paslapčių valdiklį, įmonė sumažino 65% aptiktas viešas prieigos teises audituose kas ketvirtį. Teisių atšaukimo laikas baigus misiją sumažėjo iš 3 darbo dienų į mažiau nei 2 valandas dėl automatizuoto depprovisioningo. Prieš kiekvieno projekto prieigą elektronininiai pasirašyti konfidencialumo chartija leido sudaryti tiriamą bylą atliekant banko kliento auditą.

Scenarijus 2 – Greitai auganti SaaS startup

SaaS B2B programinės įrangos redagimo startup auglinčiausias iš 12 į 45 kūrėjus per 18 mėnesių. Greitą auglinimą sukelia nemaigų teisių kaupimas: išėję stažai dar gali pasiekti saugyklas, valdybos teisės buvo laikinai suteiktos incidento dėl bet niekada neatšauktos.

Priėmus Zero Trust modelį pasikeitę su pusmečių prieigos peržiūromis formalizuotomis ir elektroniniu parašu pasirašytomis tech lyderių, startup sumažino 40% atakos paviršiu (matuojamas aktyviais prieigos teisę skaičiumi naudotojui). Dokumentuoto atgabendavimo proceso diegimas – įskaitant IT chartijos elektroninį parašą iš pirmos dienos – sustiprino SOC 2 Type II atitikties poziciją, reikalingą jos Šiaurės Amerikos klientams.

Scenarijus 3 – Vidinis IT departamentas vidurio dydžio pramoninės grupės

Vidurio dydžio pramonės grupės (1 200 darbuotojų) IT departamentas valdo 35 asmenų komandą atsakingą programinės įrangos veikimo verslo taikymuose kurimas ir palaikymui. ISO 27001 audite yra nustatyta, kad prieigos teisės gamybos aplinką nėra formaliai dokumentuotos ir nėra vykdoma perodatą peržiūrą.

Diegus habilituotų matricą, peržiūrėtą kas ketvirtį ir kurio kiekviena versija yra elektroniniu parašu pasirašyta RSSI ir DSI, buvo galima pasiekti ISO 27001 sertifikavimą atliekant pakartotinį auditą. Prieigos prašymo tvarkymo laikas sumažėjo iš 5 dienų į mažiau nei 4 valandas dėl integruoto skaitmeninio srauto, sumažinant veiklos blokiavimus ir gerinant verslo komandų pasitenkinimą.

Išvada

Naudotojų teisių valdymas IT komandoje ir programinės įrangos kūrime yra centrinis saugumo, atitikties ir organizacinio produktyvumo pilas. Priėmus strukturizuotą modelį – RBAC arba ABAC priklausomai nuo jūsų aplinkos sudėtingumo – naudodami mažiausio privilegio principą, automatizuodami prieigos priskyrimo ir atšaukimą, ir formalizuodami savo habilituotų politiką, drastiškai sumažinate riskas ir atitinkate BDAR, NIS2 ir tokių žinialraščių kaip ISO 27001 reikalavimus.

Elektroninis parašas turi didėjantį vaidmenį šiame valdyme: IT chartijos, saugos politikos, NDA su paslaugų teikėjais – dokumentai, kuriems Certyneo siūlo eIDAS atitiktį, sekimusbę ir integruojamumą į jūsų esamus srautus.

Pasirengę strukturizuoti jūsų teisių valdymą ir formalizuoti saugos dokumentus? Sužinokite apie Certyneo siūlymus arba susisiekite su mūsų ekspertais personalizuotam lydiui.