Ne žmogaus tapatybių slaptųjų duomenų valdymas 2026 m. auditams

02:13 įspėjimas, kurio niekas negalėjo priskirti

Antradienio rytą 02:13 suaktyvėja saugumo operacijų kanalas. Iš vidinės automatizavimo paskyros pradėtas produkcinės duomenų bazės eksportas. Prieigos kelias teisėtas. Žetonas galioja. Šaltinio IP priklauso debesijos vykdymo aplinkai, kurią naudoja inžinerijos komanda. Kenkėjiškos programinės įrangos požymių nėra. Duomenų viliojimo pranešimo nėra.

CISO užduoda pirmą akivaizdų klausimą: „Kam priklauso ši tapatybė?“

Tyla.

DevOps vadovas prisimena, kad žetonas buvo sukurtas kliento migracijos metu prieš dvejus metus. Platformos komanda teigia, kad jis galbūt naudojamas atsiskaitymų integracijoje. Duomenų bazės administratorius sako, kad jam suteikta skaitymo prieiga, nes jo pašalinimas kadaise sutrikdė naktinę užduotį. Teisės komanda klausia, ar buvo susiję asmens duomenys. Atitikties komanda klausia, ar tai praneštinas incidentas pagal NIS2, DORA arba GDPR. Auditorius prašo įrodymų, kad paslaugų paskyros, API raktai, sertifikatai ir CI/CD slaptieji duomenys yra inventorizuojami, peržiūrimi, reguliariai keičiami, stebimi ir atšaukiami.

Iki 09:00 audito išvados projektas jau formuojasi. Pamirštoje mikropaslaugos dalyje rastas kode įrašytas, reguliariai nekeistas API raktas. Jis suteikia plačią prieigą prie produkcinės klientų operacijų duomenų bazės. Jį sukūręs kūrėjas išėjo prieš dvejus metus. Sistema neturi įvardyto savininko, dokumentuoto tikslo, reguliaraus keitimo įrašo ir stebėsenos taisyklės.

Tai yra ne žmogaus tapatybių problema 2026 m.

Dauguma organizacijų pagerino žmonių prieigos kontrolę. Jos turi MFA, darbuotojų priėmimo, pareigų keitimo ir atleidimo procesus, privilegijuotos prieigos peržiūras ir tapatybės teikėjo žurnalus. Tačiau mašininės tapatybės augo greičiau nei jų valdysena. Paslaugų paskyros, darbo krūvio tapatybės, API raktai, OAuth žetonai, SSH raktai, sertifikatai, Kubernetes slaptieji duomenys, SaaS integracijų žetonai, robotizuoto procesų automatizavimo paskyros ir CI/CD diegimo prisijungimo duomenys dabar vykdo kritinius verslo veiksmus, nors nėra „naudotojai“ žmogiškąja prasme.

SaaS teikėjams, fintech įmonėms, valdomų paslaugų teikėjams, debesijos operatoriams ir daug duomenų tvarkančioms MVĮ nevaldomos ne žmogaus tapatybės nebėra vien techninės higienos klausimas. Tai valdybos lygmens atsparumo ir atitikties rizika. NIS2 prieigos kontrolę, turto valdymą, tiekimo grandinės saugumą, incidentų valdymą ir kibernetinę higieną laiko pagrindinėmis kibernetinio saugumo rizikos valdymo priemonėmis. DORA finansų subjektams IRT riziką, operacinį atsparumą, incidentų pranešimą ir IRT trečiųjų šalių riziką priskiria valdymo organo atskaitomybei. GDPR reikalauja, kad duomenų valdytojai ir tvarkytojai saugotų asmens duomenis ir galėtų įrodyti atskaitomybę.

Sudėtinga ne įrodyti, kad slaptieji duomenys egzistuoja. Sudėtinga įrodyti, kad kiekviena ne žmogaus tapatybė turi savininką, tikslą, gyvavimo ciklą, rizikos įvertinimą, patvirtintą prieigą, saugaus saugojimo būdą, reguliaraus keitimo taisyklę, stebėsenos aprėptį ir atšaukimo kelią.

Kodėl ne žmogaus tapatybės tapo nauja privilegijuotos prieigos problema

Ne žmogaus tapatybė, arba NHI, yra bet kuri skaitmeninė tapatybė, kurią naudoja programinė įranga, infrastruktūra arba automatizuoti procesai, o ne žmogus. Praktikoje tai apima paslaugų paskyras, naudojamas taikomųjų programų, API raktus, naudojamus SaaS integracijų, OAuth ir atnaujinimo žetonus, naudojamus trečiųjų šalių taikomųjų programų, SSH raktus, naudojamus automatizavimui, TLS sertifikatus ir privačiuosius raktus, CI/CD slaptuosius duomenis, debesijos darbo krūvio tapatybes, duomenų bazių prisijungimo eilutes, įterptus prisijungimo duomenis, RPA robotų paskyras ir tiekėjų valdomus integracijų prisijungimo duomenis.

Šios tapatybės dažnai turi tris savybes, kurios kelia auditorių susirūpinimą.

Pirma, jos yra ilgalaikės. Žmogiškasis naudotojas gali reguliariai keisti prisijungimo duomenis, keisti pareigas ir išeiti per formalų darbo santykių nutraukimo procesą. API žetonas, sukurtas diegimo lango metu, gali likti aktyvus metų metus, nes niekas nenori rizikuoti sutrikdyti produkcinės aplinkos.

Antra, jos yra galingos. Diegimo žetonas gali keisti infrastruktūrą. Debesijos paslaugos tapatybė gali kurti saugyklas. Duomenų bazės paskyra gali eksportuoti klientų įrašus. Pasirašymo raktas gali kompromituoti programinės įrangos tiekimo grandinės vientisumą.

Trečia, jų priskiriamumas silpnas. Žmogiškosios tapatybės siejamos su žmogiškųjų išteklių įrašais. Ne žmogaus tapatybės dažnai siejamos su scenarijais, konvejeriais, tiekėjais, pamirštais projektais arba nedokumentuotomis integracijomis.

Clarysec Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planas Zenith Blueprint tai tiesiogiai įvardija etape „Kontrolės priemonės praktikoje“, 22 žingsnyje:

Nepamirškite ir ne žmogaus tapatybių. Būtent čia auditai dažnai atskleidžia tylų pažeidžiamumą. Ar API žetonai sekami? Ar integracijų paskyros susietos su žmonėmis, ar paliktos nežinioje? Kada paskutinį kartą buvo reguliariai pakeista duomenų bazės prieigos eilutė, įrašyta dešimtmečių senumo scenarijuje?

Tapatybės valdymas nėra patrauklus, tačiau jis yra struktūrinis. Be jo jūsų ISVS tėra užrakintų durų rinkinys, neturintis būdo įsitikinti, kas turi raktus.

Paskutinis sakinys ir yra esmė. Organizacija gali turėti išbaigtą Prieigos kontrolės politiką ir vis tiek neišlaikyti audito, jei mašininės tapatybės nevaldomos. ISVS, kuri negali paaiškinti, kam priklauso slaptasis duomuo, kodėl jis egzistuoja ir kada paskutinį kartą buvo peržiūrėtas, dar neveikia kaip kontroliuojama sistema.

ISO/IEC 27001:2022 paverčia slaptųjų duomenų valdymą įrodymais

ISO/IEC 27001:2022 veiksmingas todėl, kad slaptųjų duomenų valdymo nelaiko izoliuota inžinerine užduotimi. Jis reikalauja rizika grindžiamos ISVS su apibrėžta taikymo sritimi, suinteresuotųjų šalių reikalavimais, vadovybės atskaitomybe, rizikos vertinimu, rizikos tvarkymu, kontrolės priemonių parinkimu, Taikomumo pareiškimu ir nuolatiniu tobulinimu.

Ne žmogaus tapatybių atveju organizacija neturėtų pradėti nuo įrankio įsigijimo. Ji turi pradėti nuo taikymo srities ir įpareigojimų.

Pagal ISO/IEC 27001:2022 4.1–4.4 punktus organizacija nustato vidaus ir išorės klausimus, suinteresuotąsias šalis, teisinius, reglamentavimo ir sutartinius reikalavimus, sąsajas ir priklausomybes. NHI kontekste ISVS taikymo sritis turi nustatyti debesijos aplinkas, SaaS platformas, CI/CD sistemas, produkcines taikomąsias programas, klientų integracijas, duomenų tvarkytojus, valdomų paslaugų teikėjus ir kriptografines paslaugas, kuriose egzistuoja mašininiai prisijungimo duomenys.

5.1–5.3 punktai vadovybę padaro atskaitingą už politiką, išteklius, vaidmenis ir veiklos ataskaitų teikimą. Tai svarbu, nes NHI trūkumų šalinimas dažnai sukuria operacinę įtampą. Produkcinės duomenų bazės prisijungimo duomenų reguliarus keitimas, senos bendros paslaugų paskyros pakeitimas arba saugykla pagrįsto slaptųjų duomenų įterpimo taikymas gali sutrikdyti trapią darbo eigą. Be vykdomojo rėmėjo komandos atideda sutvarkymą.

6.1.1–6.1.3 ir 6.2 punktai sudaro kontrolės priemonių variklį. Organizacija apibrėžia rizikos kriterijus, nustato konfidencialumo, vientisumo ir prieinamumo rizikas, priskiria rizikos savininkus, vertina tikimybę ir poveikį, pasirenka tvarkymo galimybes, parenka kontrolės priemones, parengia Taikomumo pareiškimą ir seka išmatuojamus tikslus.

Praktiškai ne žmogaus tapatybių rizikos tvarkymo planas turi atsakyti:

• Kurios sistemos ir verslo paslaugos priklauso nuo NHI?
• Kurie slaptieji duomenys gali pasiekti asmens duomenis, reglamentuojamas finansines paslaugas, produkcinę infrastruktūrą arba kritines klientų paslaugas?
• Kurios tapatybės yra privilegijuotos, neaktyvios, bendros, tiekėjų valdomos arba nevaldomos?
• Kurios kontrolės priemonės mažina riziką, pavyzdžiui, saugojimas saugyklose, reguliarus keitimas, mažiausios teisės, galiojimo pabaiga, sertifikatų gyvavimo ciklo valdymas, CI/CD skenavimas, stebėsena ir neatidėliotinas atšaukimas?
• Kurioms likutinėms rizikoms reikia verslo patvirtinimo?

ISO/IEC 27002:2022 tada pateikia A priedo kontrolės priemonių katalogą. Aktualiausios kontrolės priemonės apima 5.9 Informacijos ir kitų susijusių išteklių apskaita, 5.15 Prieigos kontrolė, 5.16 Tapatybės valdymas, 5.17 Autentifikavimo informacija, 5.18 Prieigos teisės, 5.19 Informacijos saugumas santykiuose su tiekėjais, 5.20 Informacijos saugumo įtraukimas į tiekėjų susitarimus, 5.21 Informacijos saugumo valdymas IRT tiekimo grandinėje, 5.23 Informacijos saugumas naudojant debesijos paslaugas, 5.24 Incidentų valdymo planavimas ir pasirengimas, 5.28 Įrodymų rinkimas, 8.2 Privilegijuotos prieigos teisės, 8.3 Informacijos prieigos ribojimas, 8.5 Saugus autentifikavimas, 8.15 Žurnalų registravimas, 8.16 Stebėsenos veikla, 8.24 Kriptografijos naudojimas, 8.25 Saugaus kūrimo gyvavimo ciklas, 8.26 Taikomųjų programų saugumo reikalavimai, 8.28 Saugus programavimas ir 8.31 Kūrimo, testavimo ir produkcinių aplinkų atskyrimas.

Clarysec Zenith Controls: kryžminės atitikties vadovas Zenith Controls šiuos ISO/IEC 27002:2022 ryšius susieja taip, kad juos galėtų naudoti auditoriai ir kontrolės priemonių savininkai. Kalbant apie kontrolės priemonę 5.16, Tapatybės valdymas, Zenith Controls paaiškina ryšį tarp tapatybės ir prisijungimo duomenų:

Tapatybės valdymas pateikia atsakymą „kas“, o autentifikavimo informacija užtikrina „kaip“ – patikrina, ar asmuo, teigiantis turintis tapatybę, yra teisėtas. 5.16 reglamentuoja tapatybės gyvavimo ciklo valdymą, o 5.17 užtikrina, kad slaptažodžiai, žetonai, sertifikatai ir kiti prisijungimo duomenys būtų saugiai susieti su šiomis tapatybėmis ir tinkamai valdomi, kad palaikytų stiprų autentifikavimą.

Šis ryšys NHI atveju yra esminis. Žetonas be tapatybės savininko nėra audituojamas. Paslaugų paskyra be prieigos peržiūros neatitinka mažiausių teisių principo. Sertifikatas be gyvavimo ciklo būsenos nėra kontroliuojama kriptografija. Tiekėjo integracijos prisijungimo duomenys be sutarties sąlygų nėra veiksmingas trečiųjų šalių rizikos valdymas.

Clarysec kontrolės modelis: tapatybė, slaptasis duomuo, privilegija, įrodymai

Clarysec ne žmogaus tapatybių ir slaptųjų duomenų valdymą įgyvendina taikydama kartotinį kontrolės modelį. „Slaptųjų duomenų“ nelaikome vien DevOps rūpesčiu, o „paslaugų paskyrų“ – vien IAM rūpesčiu. Sujungiame tapatybę, slaptąjį duomenį, privilegiją ir įrodymus.

Politikos sluoksnyje tai tampa įgyvendinama.

MVĮ atveju Clarysec MVĮ skirta naudotojų paskyrų ir privilegijų valdymo politika MVĮ skirta naudotojų paskyrų ir privilegijų valdymo politika nustato:

Paslaugų paskyros (naudojamos sistemų arba taikomųjų programų) turi būti dokumentuotos, apribotos konkrečiomis sistemomis ir niekada nenaudojamos interaktyviems prisijungimams.

Tai apsaugo nuo klasikinio antipavyzdžio, kai paslaugų paskyra tampa bendra administratoriaus prisijungimo paskyra. Auditorius taip pat gauna aiškų testą: parodykite paslaugų paskyrų registrą, parodykite sistemos apribojimą ir parodykite, kad interaktyvus prisijungimas išjungtas arba techniškai užkirstas.

Clarysec MVĮ skirta turto valdymo politika MVĮ skirta turto valdymo politika išplečia turto apibrėžimą įtraukdama:

Skaitmeniniai prisijungimo duomenys ir paslaugos: domenų vardai, skaitmeniniai sertifikatai, API raktai, el. pašto paskyros, debesijos prisijungimai

Tai svarbu, nes daugelis organizacijų inventorizuoja tik serverius, nešiojamuosius kompiuterius ir taikomąsias programas. 2026 m. API raktas gali būti jautresnis nei nešiojamasis kompiuteris. Sertifikato privatusis raktas gali būti produkcinis autentifikavimo turtas. Debesijos prisijungimas, naudojamas automatizavimui, gali sukurti reglamentuojamų duomenų atskleidimo riziką. Prisijungimo duomenų traktavimas kaip turto yra auditui parengto slaptųjų duomenų valdymo pagrindas.

Įmonės aplinkose Clarysec Naudotojų paskyrų ir privilegijų valdymo politika Naudotojų paskyrų ir privilegijų valdymo politika kelia aukštesnius įrodymų reikalavimus:

Organizacija turi palaikyti išsamią visų aktyvių ir neaktyvių prisijungimo duomenų, privilegijuotųjų paskyrų ir sistemos lygmens paslaugų paskyrų apskaitą. Ši apskaita turi būti nuolat atnaujinama ir kas ketvirtį peržiūrima.

Ketvirtinė peržiūra yra vieta, kur išryškėja daug spragų. Neaktyvūs prisijungimo duomenys, našlaitės paslaugų tapatybės, seni integracijų naudotojai, nevaldomos tiekėjų paskyros ir avariniai žetonai tampa matomi tik tada, kai kas nors palygina registrą su faktiniais IAM, saugyklos, CI/CD ir debesijos įrašais.

Slaptieji duomenys yra autentifikavimo informacija, o ne kūrėjų patogumas

Pavojingiausia frazė slaptųjų duomenų valdyme yra „laikinas raktas“.

Laikini raktai tampa nuolatiniai. Testiniai prisijungimo duomenys pasiekia produkcinę aplinką. Pirminis kodas atskleidžia žetonus. Kūrimo žurnalai atskleidžia slaptažodžius. Pagalbos komandos dalijasi sertifikatais per užklausas. Kūrėjai kopijuoja aplinkos failus į pokalbius. Rangovas sukuria debesijos paslaugos tapatybę ir išeina.

Zenith Blueprint, etape „Kontrolės priemonės praktikoje“, 22 žingsnyje, autentifikavimo informaciją apibūdina plačiai:

Ši kontrolės priemonė nėra vien apie slaptažodžius, nors slaptažodžiai tikrai yra dalis vaizdo. Ji apima visus prisijungimo duomenis, naudojamus tapatybei patvirtinti: slaptažodžius, PIN kodus, kriptografinius raktus, biometrinius šablonus, lustines korteles, žetonus, sertifikatus, OAuth žetonus, SSH raktus, API slaptuosius duomenis. Tai yra karalystės raktai, o kontrolė 5.17 užtikrina, kad su tais raktais būtų elgiamasi taip rimtai, kaip jie nusipelno.

Būkime aiškūs: prastas autentifikavimo valdymas išlieka viena pagrindinių pažeidimų priežasčių. Silpni arba bendri slaptažodžiai. Kode įrašyti prisijungimo duomenys pirminiame kode. Nepakeisti numatytieji prisijungimai administravimo portaluose. Sertifikatai, kurių galiojimas pasibaigęs arba savininkystė nežinoma. Kiekvienu iš šių atvejų žlugo ne pati tapatybė, o nesugebėjimas apsaugoti ir valdyti mechanizmo, naudojamo tai tapatybei įrodyti.

Clarysec politikos tai paverčia operacinėmis taisyklėmis.

MVĮ skirta kriptografinių kontrolės priemonių politika MVĮ skirta kriptografinių kontrolės priemonių politika nustato:

Raktai neturi būti saugomi atviruoju tekstu arba įterpti į pirminį kodą, dokumentus ar el. laiškus

MVĮ skirta saugaus kūrimo politika MVĮ skirta saugaus kūrimo politika nustato:

Pirminiame kode draudžiama laikyti kode įrašytus prisijungimo duomenis ar slaptuosius duomenis

Įmonės komandoms Saugaus kūrimo politika Saugaus kūrimo politika nustato:

Slaptieji duomenys neturi būti įrašomi į kodą arba saugomi atviruoju tekstu saugyklose.

O Taikomųjų programų saugumo reikalavimų politika Taikomųjų programų saugumo reikalavimų politika yra dar tiesesnė:

Slaptažodžių arba kriptografinių raktų saugojimas atviruoju tekstu yra griežtai draudžiamas.

Šios politikos nuostatos sukuria aiškų audito pėdsaką. Saugumo komandos gali tikrinti saugyklas, CI/CD kintamuosius, konteinerių atvaizdus, konfigūracijų saugyklas, užduočių sekimo sistemas, dokumentacijos platformas ir žurnalus pagal aiškius reikalavimus. Jos taip pat palaiko GDPR Article 32 tvarkymo saugumą, nes slaptųjų duomenų atskleidimas gali tiesiogiai lemti neteisėtą prieigą prie asmens duomenų.

Įmonės kriptografinė valdysena taip pat reikalauja savininkystės. Clarysec Kriptografinių kontrolės priemonių politika Kriptografinių kontrolės priemonių politika reikalauja:

Turi būti palaikomas centralizuotas Raktų valdymo registras, kuriame registruojami visi kriptografiniai raktai, jų gyvavimo ciklo būsena, priskirti atsakingi saugotojai ir naudojimo kontekstai.

Ne žmogaus tapatybių atveju tas registras turi susieti sertifikatų raktus, pasirašymo raktus, API raktus ir debesijos valdomus raktus su platesniu NHI registru. Auditorius turi galėti atsekti produkcinį sertifikatą nuo verslo paslaugos iki savininko, atsakingo saugotojo, galiojimo pabaigos, reguliaraus keitimo įrodymų ir reagavimo į incidentus procedūros.

NIS2, DORA ir GDPR: vienas įrodymų modelis, daug reguliuotojų

Ne žmogaus tapatybių valdysena yra kryžminės atitikties problema, nes tas pats kontrolės nesuveikimas gali sukelti kelis įpareigojimus.

Nutekėjęs API žetonas SaaS teikėjo aplinkoje gali sukelti paslaugos sutrikimą pagal NIS2, asmens duomenų atskleidimą pagal GDPR ir sutartinį incidentų pranešimą finansų klientams pagal DORA tiekimo grandinės lūkesčius. Kompromituotas CI/CD slaptasis duomuo IRT paslaugų teikėjo aplinkoje gali paveikti klientų atsparumą, programinės įrangos vientisumą ir veiklos tęstinumą. Pamiršta tiekėjo integracijos paskyra gali sukurti prieigą prie reglamentuojamų sistemų be tinkamo deramo patikrinimo ar sutartinių kontrolės priemonių.

NIS2 Article 21 reikalauja tinkamų ir proporcingų techninių, operacinių ir organizacinių priemonių. Minimalios sritys apima rizikos analizę, informacinių sistemų saugumo politikas, incidentų valdymą, veiklos tęstinumą, tiekimo grandinės saugumą, saugų įsigijimą, kūrimą ir priežiūrą, pažeidžiamumų tvarkymą, veiksmingumo vertinimą, kibernetinę higieną, kriptografiją, HR saugumą, prieigos kontrolę ir turto valdymą, o prireikus – MFA arba tęstinį autentifikavimą. Ne žmogaus tapatybės patenka beveik į visas šias sritis. NIS2 Article 23 taip pat nustato etapais vykdomą pranešimą apie reikšmingus incidentus, įskaitant ankstyvąjį įspėjimą per 24 valandas, pranešimą apie incidentą per 72 valandas ir galutinę ataskaitą ne vėliau kaip per vieną mėnesį po pranešimo apie incidentą.

DORA taikomas nuo 2025 m. sausio 17 d. ir apima IRT rizikos valdymą, pranešimą apie reikšmingus su IRT susijusius incidentus, operacinio atsparumo testavimą, dalijimąsi informacija ir IRT trečiųjų šalių riziką. Articles 5 ir 6 reikalauja valdysenos, valdymo organo atskaitomybės ir dokumentuotos IRT rizikos valdymo sistemos. Article 8 reikalauja identifikuoti IRT palaikomas verslo funkcijas, informacijos išteklius ir priklausomybes. Articles 17–19 reikalauja incidentų valdymo, klasifikavimo ir pranešimo. Articles 28–30 reikalauja IRT trečiųjų šalių rizikos valdymo, sutarčių registrų, deramo patikrinimo, saugumo standartų, audito teisių, pagalbos incidentų metu, subtiekimo kontrolės ir pasitraukimo strategijų.

GDPR taikomas visur, kur asmens duomenys tvarkomi pagal jo teritorinę taikymo sritį. Article 5 reikalauja vientisumo, konfidencialumo ir atskaitomybės. Article 32 reikalauja tinkamų techninių ir organizacinių priemonių tvarkymo saugumui. Jei paslaugų paskyra arba API raktas gali pasiekti asmens duomenis, nevaldomi slaptieji duomenys tampa privatumo kontrolės nesuveikimu, o ne vien IT klausimu.

Tie patys įrodymai gali palaikyti ISO/IEC 27001:2022 sertifikavimą, NIS2 priežiūrą, DORA patikrinimus ir GDPR atskaitomybę, jei jie tinkamai struktūruoti.

NIST CSF 2.0 gali būti naudojamas kaip komunikacijos sluoksnis tiems patiems įrodymams. Jo GOVERN funkcija apima suinteresuotųjų šalių lūkesčius, teisinius ir sutartinius įpareigojimus, rizikos apetitą, vadovybės atskaitomybę, politiką ir priežiūrą. Jo operaciniai rezultatai apima turto apskaitą, tiekėjų teikiamas paslaugas, tapatybės ir prisijungimo duomenų valdymą, mažiausių privilegijų principą, duomenų saugumą, žurnalų registravimą, stebėseną, reagavimą į incidentus ir atkūrimą.

COBIT 2019 ir ISACA tipo užtikrinimo komandos paprastai vertins valdyseną ir proceso pajėgumą. Jos klaus, ar atsakomybė priskirta, ar kontrolės priemonės įdiegtos operaciniuose procesuose, ar išimtys patvirtintos, ar rodikliai teikiami vadovybei ir ar įrodymai rodo pakartojamumą, o ne vienkartinį sutvarkymą.

Praktinis sprintas ne žmogaus tapatybių registrui sukurti

Praktinis Clarysec pasitelkimas dažnai prasideda nuo sutelkto sprinto, o ne šešių mėnesių įrankių programos. Tikslas – parengti pagrįstą NHI registrą, rizikos reitingavimą ir taisomųjų veiksmų planą, kuris gali būti įtrauktas į ISO/IEC 27001:2022 Rizikos tvarkymo planą ir Taikomumo pareiškimą.

Pradėkite nuo vienos verslo paslaugos, pavyzdžiui, klientų atsiskaitymų platformos, prekybos taikomosios programos, pacientų portalo arba SaaS nuomininkų valdymo sistemos. Įtraukite produkcinę aplinką, parengiamąją aplinką, CI/CD, debesijos infrastruktūrą, stebėsenos priemones, duomenų bazes, SaaS integracijas ir tiekėjų valdomas paslaugas.

Susiekite tai su Zenith Blueprint, Rizikos valdymo faze, 14 žingsniu, kuriame Clarysec suderina rizikos tvarkymo politikas su reglamentavimo kryžminėmis nuorodomis. Šiame žingsnyje saugaus kūrimo ir konvejerių kontrolės priemonės apima draudimą naudoti kode įrašytus slaptuosius duomenis, tarpusavio peržiūrą, automatizuotą statinę analizę, priklausomybių skenavimą, kūrimo, testavimo ir produkcinių aplinkų atskyrimą, MFA konvejerio prieigai, kūrimo artefaktų vientisumą ir CI/CD žurnalų registravimą.

Surinkite tapatybes ir slaptuosius duomenis iš tapatybės teikėjo, debesijos IAM, slaptųjų duomenų saugyklos, Kubernetes, CI/CD kintamųjų, saugyklų nustatymų, duomenų bazių naudotojų, SaaS administravimo konsolių, sertifikatų valdymo priemonių ir tiekėjų dokumentacijos.

Pagal riziką įvertinkite tapatybes, kurios turi produkcinės aplinkos prieigą, privilegijuotas teises, prieigą prie asmens duomenų, priklausomybę nuo kritinės ar svarbios funkcijos, tiekėjo kontrolę, ilgalaikius žetonus, neturi savininko, neturi reguliaraus keitimo, neturi stebėsenos arba saugomos kaip kode įrašyti duomenys. Naudokite ISO/IEC 27001:2022 rizikos kriterijus tikimybei ir poveikiui įvertinti balais. Kur taikoma, naudokite DORA kritinių ar svarbių funkcijų analizę. Kai asmens duomenys pasiekiami, naudokite GDPR poveikio aspektus. Kai tikėtinas sutrikimas arba žala klientui, naudokite NIS2 paslaugos poveikį.

Kiekvienai didelės rizikos NHI taikykite tvarkymo veiksmus. Perkelkite slaptuosius duomenis iš pirminio kodo, dokumentų ir CI/CD atvirojo teksto kintamųjų į saugyklą arba valdomą slaptųjų duomenų saugyklą. Bendras paslaugų paskyras pakeiskite unikaliomis darbo krūvio tapatybėmis. Išjunkite interaktyvų prisijungimą paslaugų paskyroms. Taikykite mažiausių privilegijų principą ir konkrečioms aplinkoms skirtus prisijungimo duomenis. Sukonfigūruokite reguliarų keitimą, galiojimo pabaigą ir neatidėliotiną atšaukimą. Susiekite slaptuosius duomenis su savininkais ir atsakingais saugotojais. Įtraukite autentifikavimo, žetonų naudojimo ir jautrių veiksmų žurnalų registravimą. Pridėkite įspėjimus dėl neįprastos geografinės vietos, neįprasto laiko, neįprastos apimties arba naujos išteklių prieigos. Atnaujinkite tiekėjų sutartis dėl prisijungimo duomenų tvarkymo, pagalbos incidentų metu ir audito teisių. Dokumentuokite išimtis su rizikos savininko patvirtinimu ir galiojimo pabaigos data.

Testavimo duomenų ir testavimo aplinkos politika Testavimo duomenų ir testavimo aplinkos politika palaiko aplinkų atskyrimą:

Integracija su CI/CD konvejeriais turi užtikrinti aplinkų ir autentifikavimo prisijungimo duomenų atskyrimą.

Ši nuostata dažnai būna lemiama. Jei kūrimo, testavimo ir produkcinė aplinkos dalijasi slaptaisiais duomenimis, mažos rizikos aplinka gali tapti keliu į produkcinį pažeidimą.

Sprintas turi baigtis įrodymų paketu, o ne vien išvadų sąrašu. Įtraukite NHI registro eksportą, rizikos vertinimo įrašus, Rizikos tvarkymo planą, Taikomumo pareiškimo susiejimą, politikų nuorodas, saugyklų ekrano kopijas, reguliaraus keitimo žurnalus, prieigos peržiūrų patvirtinimus, CI/CD slaptųjų duomenų skenavimo rezultatus, stebėsenos taisyklių apibrėžimus, tiekėjų prisijungimo duomenų atsakomybių matricą, incidento reagavimo instrukciją ir išimtis su savininkais bei galiojimo pabaigos datomis.

Žurnalų registravimas ir aptikimas: įrodyti, kad mašininių tapatybių naudojimas matomas

Mašininė tapatybė, kuri gerai inventorizuota, bet nematoma žurnaluose, išlieka pavojinga. Aptikimas yra kontrolės istorijos dalis.

Clarysec MVĮ skirta žurnalų registravimo ir stebėsenos politika MVĮ skirta žurnalų registravimo ir stebėsenos politika apima autentifikavimo įrodymus:

Autentifikavimo žurnalai: sėkmingi ir nesėkmingi prisijungimo bandymai, sesijos trukmė, MFA naudojimas

NHI atveju pritaikykite šį reikalavimą mašininiam autentifikavimui. Darbo krūvio tapatybei gali nebūti MFA naudojimo, tačiau turite turėti autentifikavimo įvykius, žetonų naudojimą, sertifikatų naudojimą, API iškvietimų metaduomenis, šaltinio darbo krūvį, paskirties paslaugą, žetono gyvavimo trukmę, nesėkmės įvykius ir privilegijuotus veiksmus.

Zenith Controls ISO/IEC 27002:2022 kontrolės priemonė 8.2, Privilegijuotos prieigos teisės, susieta su žurnalų registravimu ir stebėsena, nes privilegijuotoms paskyroms reikia išsamių įrašų ir priežiūros. Zenith Controls taip pat susieja 8.2 su tapatybės valdymu, prieigos teisėmis, informacijos prieigos ribojimu ir saugiu autentifikavimu. Auditoriams tai reiškia, kad privilegijuotos ne žmogaus tapatybės turi būti peržiūrimos ir stebimos taip pat rimtai kaip žmogiškieji administratoriai, o kartais ir griežčiau.

Geri stebėsenos klausimai:

• Ar paslaugų paskyra autentifikavosi iš netikėto darbo krūvio arba IP intervalo?
• Ar API raktas pasiekė naują galinį tašką arba duomenų rinkinį?
• Ar sertifikatas buvo panaudotas po pakeitimo?
• Ar CI/CD žetonas diegė už patvirtinto konvejerio ribų?
• Ar tik skaitymui skirta paskyra bandė atlikti rašymo operacijas?
• Ar neaktyvūs prisijungimo duomenys tapo aktyvūs?
• Ar tiekėjo integracija pasiekė duomenis ne sutartomis valandomis arba ne sutartomis apimtimis?

Kai įvyksta 02:13 įspėjimas, turite atsakyti, kokia tapatybė buvo naudota, koks slaptasis duomuo ją autentifikavo, kokios prieigos teisės buvo panaudotos, kokie duomenys ar sistemos buvo paveikti, ar veikla buvo tikėtina, kuris savininkas gali ją patvirtinti ir ar pasiekti incidento pranešimo slenksčiai.

Auditoriaus perspektyva: tas pats procesas, skirtingi klausimai

Stipriausia audito pozicija nėra „mes atitinkame viską“. Ji yra „mes vykdome vieną kontroliuojamą procesą, kuris sukuria įrodymus keliems įpareigojimams“. Skirtingi auditoriai tą procesą tikrins skirtingai.

Šiose perspektyvose pasikartojančios išvados nuspėjamos: nėra vieno NHI registro, mašininės tapatybės neturi savininko, slaptieji duomenys saugomi kode arba dokumentacijoje, bendri prisijungimo duomenys naudojami keliose aplinkose, nėra reguliaraus keitimo arba galiojimo pabaigos, tiekėjų valdomi prisijungimo duomenys nepatenka į prieigos peržiūras, stebėsena apima žmones, bet ne mašinas, o incidentų reagavimo instrukcijos nepaiso slaptųjų duomenų nutekėjimo.

Kiekviena išvada natūraliai susiejama su Clarysec kontrolės priemonėmis, politikomis ir trūkumų šalinimo šablonais. Dar svarbiau, kiekvieną galima paversti išmatuojamais įrodymais ISVS viduje.

Kaip Clarysec padeda pasirengti auditui

Clarysec metodas praktiškas, nes jis prasideda nuo įrodymų, kurių prašys auditoriai, ir grįžta atgal į kontrolės priemones, politikas ir operacines rutinas.

Zenith Blueprint, etape „Kontrolės priemonės praktikoje“, 19 žingsnyje, Clarysec pateikia tiesiogines gaires mašina–mašina autentifikavimui:

Mašina–mašina autentifikavimui, pavyzdžiui, paslaugų paskyroms arba API iškvietimams, raktai, sertifikatai ir žetonai turi būti saugomi taip pat griežtai. Venkite įterpti prisijungimo duomenis į kodą. Naudokite slaptųjų duomenų valdymo sistemas arba saugyklas, kad juos saugiai saugotumėte ir reguliariai keistumėte.

Tipinė Clarysec ne žmogaus tapatybių darbo kryptis apima NHI aptikimą debesijoje, SaaS, CI/CD, saugyklose, slaptųjų duomenų saugyklose ir duomenų bazėse, politikos spragų vertinimą pagal Clarysec MVĮ arba įmonės politikų rinkinius, ISO/IEC 27001:2022 rizikos vertinimo ir tvarkymo susiejimą, Taikomumo pareiškimo atnaujinimus, NIS2, DORA, GDPR ir NIST CSF įrodymų susiejimą, NHI registro projektavimą, suderinimą su raktų valdymo registru, slaptųjų duomenų skenavimą, prieigos peržiūros procesus, tiekėjų prisijungimo duomenų atsakomybių matricas, incidentų reagavimo instrukcijas ir audito paketus su ekrano kopijomis, eksportais, žurnalais, patvirtinimais ir išimčių įrašais.

MVĮ atveju metodas proporcingas. 70 žmonių SaaS teikėjui nereikia tokio pat įrankių masto kaip pasauliniam bankui, tačiau jam reikia savininkystės, politikos, rizikos tvarkymo ir įrodymų. Reglamentuojamiems finansų subjektams ir IRT teikėjams tas pats modelis išplečiamas į DORA kritinių funkcijų susiejimą, trečiųjų šalių rizikos valdyseną ir atsparumo testavimą.

Jei kitas jūsų auditas vyks 2026 m., nelaukite, kol auditorius už jus atras ne žmogaus tapatybes. Pradėkite nuo vienos kritinės paslaugos ir užduokite penkis klausimus:

1. Ar žinome kiekvieną paslaugų paskyrą, API raktą, žetoną, sertifikatą ir CI/CD slaptąjį duomenį, kurį naudoja ši paslauga?
2. Ar kiekviena NHI turi įvardytą savininką, atsakingą saugotoją, tikslą ir rizikos įvertinimą?
3. Ar slaptieji duomenys saugomi saugyklose, reguliariai keičiami ir apsaugoti nuo pirminio kodo, dokumentų, el. laiškų ir atvirojo teksto saugojimo?
4. Ar privilegijuotos mašininės tapatybės peržiūrimos, stebimos ir ribojamos nuo interaktyvaus naudojimo?
5. Ar galime parengti ISO/IEC 27001:2022, NIS2, DORA ir GDPR įrodymus iš vieno kontroliuojamo proceso?

Naudokite Zenith Blueprint: auditoriaus 30 žingsnių veiksmų planas Zenith Blueprint, kad struktūruotumėte savo ISVS įgyvendinimo kelią. Naudokite Zenith Controls: kryžminės atitikties vadovas Zenith Controls, kad susietumėte ISO/IEC 27002:2022 tapatybės, autentifikavimo, privilegijų, žurnalų registravimo, kriptografijos, saugaus kūrimo ir tiekėjų kontrolės priemones su reglamentavimo įrodymais. Naudokite Clarysec MVĮ ir įmonės politikų biblioteką, įskaitant MVĮ skirtą naudotojų paskyrų ir privilegijų valdymo politiką MVĮ skirta naudotojų paskyrų ir privilegijų valdymo politika, Kriptografinių kontrolės priemonių politiką Kriptografinių kontrolės priemonių politika, Saugaus kūrimo politiką Saugaus kūrimo politika ir Taikomųjų programų saugumo reikalavimų politiką Taikomųjų programų saugumo reikalavimų politika, kad gerus ketinimus paverstumėte įgyvendinamais reikalavimais.

02:13 įspėjimas kažkur įvyks. Klausimas, ar jūsų organizacija galės įrodymais pagrįstai atsakyti, kas turėjo raktą, ką jis atrakino, kodėl jis egzistavo ir kaip greitai galite jį apsaugoti.