Mitteinimidentiteetide saladuste haldus 2026. aasta audititeks

02:13 teavitus, mille omanikku keegi tuvastada ei suutnud

Teisipäeva varahommikul kell 02:13 süttib turbeoperatsioonide kanal. Sisemise automaatikakonto alt on käivitunud tootmiskeskkonna andmebaasi eksport. Juurdepääsutee on õiguspärane. Token on kehtiv. Lähte-IP kuulub pilvekeskkonna täiturile, mida kasutab arendusmeeskond. Pahavara ei ole näha. Andmepüügi teadet ei ole.

CISO esitab esimese ilmselge küsimuse: „Kellele see identiteet kuulub?“

Vaikus.

DevOps juht mäletab, et token loodi kliendi migreerimise ajal kaks aastat tagasi. Platvormimeeskonna sõnul võib seda kasutada arveldusintegratsioon. Andmebaasi administraator ütleb, et kontol on lugemisõigus, sest selle eemaldamine katkestas kunagi öise töö. Õigusosakond küsib, kas tegevus hõlmas isikuandmeid. Vastavuse eest vastutav üksus küsib, kas tegemist on NIS2, DORA või GDPR alusel teatamiskohustusliku intsidendiga. Audiitor küsib tõendusmaterjali selle kohta, et teenusekontod, API-võtmed, sertifikaadid ja CI/CD saladused on inventeeritud, läbi vaadatud, roteeritud, seiratud ja tühistatud.

Kella 09:00-ks on auditi leiu mustand juba kujunemas. Unustatud mikroteenusest leiti kõvakodeeritud ja roteerimata API-võti. See annab laiaulatusliku juurdepääsu tootmiskeskkonna klienditehingute andmebaasile. Arendaja, kes selle lõi, lahkus kaks aastat tagasi. Süsteemil ei ole nimelist omanikku, dokumenteeritud eesmärki, rotatsioonikirjet ega seirereeglit.

See on 2026. aasta mitteinimidentiteetide probleem.

Enamik organisatsioone on inimkasutajate juurdepääsukontrolli parandanud. Neil on MFA, tööleasujate, ametikoha vahetajate ja lahkujate töövood, privilegeeritud juurdepääsuõiguste ülevaatused ning identiteedipakkujate logid. Masinidentiteedid on aga kasvanud kiiremini kui nende juhtimiskorraldus. Teenusekontod, töökoormuse identiteedid, API-võtmed, OAuthi tokenid, SSH-võtmed, sertifikaadid, Kubernetes saladused, SaaS-integratsioonide tokenid, robotprotsesside automatiseerimise kontod ja CI/CD juurutuse autentimisandmed teevad nüüd kriitilisi äritegevusi, olemata inimlikus tähenduses „kasutajad“.

SaaS-i pakkujate, fintech-ettevõtete, hallatud teenusepakkujate, pilveoperaatorite ja andmemahukate VKE-de jaoks ei ole hallamata mitteinimidentiteedid enam tehnilise hügieeni küsimus. Need on juhatuse tasandi küberkerksuse ja vastavuse risk. NIS2 käsitleb juurdepääsukontrolli, varahaldust, tarneahela turvet, intsidentide käsitlemist ja küberhügieeni põhiliste küberturvalisuse riskijuhtimise meetmetena. DORA seab IKT-riski, talitluspidevuse, intsidentidest teatamise ja IKT kolmandate osapoolte riski finantsüksuste juhtorgani vastutuse alla. GDPR nõuab, et vastutavad töötlejad ja volitatud töötlejad kaitseksid isikuandmeid ning suudaksid vastutust tõendada.

Keeruline ei ole tõendada, et saladused on olemas. Keeruline on tõendada, et igal mitteinimidentiteedil on omanik, eesmärk, elutsükkel, riskihinnang, heakskiidetud juurdepääs, turvaline säilitusviis, rotatsioonireegel, seirekatvus ja tühistamistee.

Miks mitteinimidentiteetidest sai uus privilegeeritud juurdepääsu probleem

Mitteinimidentiteet ehk NHI on mis tahes digitaalne identiteet, mida inimese asemel kasutavad tarkvara, taristu või automatiseeritud protsessid. Praktikas hõlmab see rakenduste kasutatavaid teenusekontosid, SaaS-integratsioonide kasutatavaid API-võtmeid, kolmanda osapoole rakenduste kasutatavaid OAuthi ja värskendustokeneid, automatiseerimise kasutatavaid SSH-võtmeid, TLS-sertifikaate ja privaatvõtmeid, CI/CD saladusi, pilve töökoormuse identiteete, andmebaasi ühendusstringe, manustatud autentimisandmeid, RPA-botikontosid ja tarnija hallatavaid integratsiooni autentimisandmeid.

Neil identiteetidel on sageli kolm omadust, mis teevad audiitorid ettevaatlikuks.

Esiteks on need pikaealised. Inimkasutaja võib autentimisandmeid roteerida, rolle vahetada ja läbida ametliku lahkumisprotsessi. Väljalaskeaknas loodud API-token võib jääda aastateks aktiivseks, sest keegi ei soovi riskida tootmiskeskkonna katkestamisega.

Teiseks on need võimsad. Juurutustoken võib muuta taristut. Pilveteenuse teenuseidentiteet võib luua salvestusressursse. Andmebaasikonto võib eksportida kliendiandmeid. Allkirjastamisvõti võib kahjustada tarkvara tarneahela terviklust.

Kolmandaks on nende omistamine keeruline. Inimidentiteedid on seotud HR-kirjetega. Mitteinimidentiteedid on sageli seotud skriptide, konveierite, tarnijate, unustatud projektide või dokumenteerimata integratsioonidega.

Clarysec’i Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint toob selle otseselt välja etapis „Kontrollimeetmed praktikas“, samm 22:

Ärge unustage ka mitteinimidentiteete. Just siin avastavad auditid sageli vaikse kokkupuute. Kas API-tokenid on jälgitavad? Kas integratsioonikontod on seotud inimestega või hõljuvad eikellegimaal? Millal viimati roteeriti seda andmebaasi juurdepääsustringi, mis on manustatud aastakümnete vanusesse skripti?

Identiteedihaldus ei ole glamuurne, kuid see on struktuurne. Ilma selleta on teie ISMS vaid lukustatud uste kogum, ilma võimaluseta olla kindel, kelle käes võtmed on.

Viimane lause on keskne. Ettevõttel võib olla viimistletud juurdepääsukontrolli poliitika, kuid ta võib auditil siiski läbi kukkuda, kui masinidentiteedid on hallamata. ISMS, mis ei suuda selgitada, kellele saladus kuulub, miks see eksisteerib ja millal seda viimati läbi vaadati, ei toimi veel kontrollitud süsteemina.

ISO/IEC 27001:2022 muudab saladuste halduse tõendusmaterjaliks

ISO/IEC 27001:2022 on tõhus, sest see ei käsitle saladuste haldust eraldiseisva inseneritöö ülesandena. See nõuab riskipõhist ISMS-i koos määratletud kohaldamisala, huvitatud osapoolte nõuete, juhtkonna vastutuse, riskihindamise, riskikäsitluse, kontrollimeetmete valiku, kohaldatavusdeklaratsiooni ja pideva täiustamisega.

Mitteinimidentiteetide puhul ei peaks organisatsioon alustama tööriista ostmisest. Alustada tuleb kohaldamisalast ja vastutustest.

ISO/IEC 27001:2022 punktide 4.1 kuni 4.4 kohaselt määrab organisatsioon sisemised ja välised küsimused, huvitatud osapooled, õiguslikud, regulatiivsed ja lepingulised nõuded, liidesed ja sõltuvused. NHI kontekstis peab ISMS-i kohaldamisala tuvastama pilvekeskkonnad, SaaS-platvormid, CI/CD süsteemid, tootmiskeskkonna rakendused, kliendiintegratsioonid, volitatud töötlejad, hallatud teenusepakkujad ja krüptograafilised teenused, kus masinate autentimisandmed eksisteerivad.

Punktid 5.1 kuni 5.3 muudavad juhtkonna vastutavaks poliitika, ressursside, rollide ja tulemusaruandluse eest. See on oluline, sest NHI parandusmeetmed tekitavad sageli operatiivset pinget. Tootmiskeskkonna andmebaasi autentimisandme roteerimine, pärandsüsteemi ühise teenusekonto asendamine või hoidlal põhineva saladuste sisestamise jõustamine võib hapraid töövooge katkestada. Ilma tippjuhtkonna sponsorluseta lükkavad meeskonnad korrastamise edasi.

Punktid 6.1.1 kuni 6.1.3 ja 6.2 annavad kontrollimehhanismi. Organisatsioon määratleb riskikriteeriumid, tuvastab konfidentsiaalsuse, tervikluse ja käideldavuse riskid, määrab riskiomanikud, hindab tõenäosust ja mõju, valib käsitlusvariandid, valib kontrollimeetmed, koostab kohaldatavusdeklaratsiooni ning jälgib mõõdetavaid eesmärke.

Praktikas peab mitteinimidentiteedi riski käsitlemise plaan vastama järgmistele küsimustele:

• Millised süsteemid ja äriteenused sõltuvad NHI-dest?
• Millised saladused pääsevad ligi isikuandmetele, reguleeritud finantsteenustele, tootmiskeskkonna taristule või kriitilistele klienditeenustele?
• Millised identiteedid on privilegeeritud, kasutuseta, jagatud, tarnija hallatavad või hallamata?
• Millised kontrollimeetmed vähendavad riski, näiteks hoidlasse viimine, rotatsioon, vähima privileegi põhimõte, aegumine, sertifikaatide elutsükli haldus, CI/CD skannimine, seire ja erakorraline tühistamine?
• Millised jääkriskid vajavad ärilist heakskiitu?

ISO/IEC 27002:2022 annab seejärel lisa A kontrollikataloogi. Kõige asjakohasemad kontrollimeetmed on 5.9 Teabe ja muude seotud varade inventuur, 5.15 Juurdepääsukontroll, 5.16 Identiteedihaldus, 5.17 Autentimisteave, 5.18 Juurdepääsuõigused, 5.19 Infoturve tarnijasuhetes, 5.20 Infoturbe käsitlemine tarnijalepingutes, 5.21 Infoturbe juhtimine IKT tarneahelas, 5.23 Infoturve pilveteenuste kasutamisel, 5.24 Intsidendihalduse planeerimine ja ettevalmistus, 5.28 Tõendite kogumine, 8.2 Privilegeeritud juurdepääsuõigused, 8.3 Teabele juurdepääsu piiramine, 8.5 Turvaline autentimine, 8.15 Logimine, 8.16 Seiretegevused, 8.24 Krüptograafia kasutamine, 8.25 Turvaline arenduse elutsükkel, 8.26 Rakendusturbe nõuded, 8.28 Turvaline programmeerimine ja 8.31 Arendus-, test- ja tootmiskeskkondade eraldamine.

Clarysec’i Zenith Controls: The Cross-Compliance Guide Zenith Controls kaardistab need ISO/IEC 27002:2022 seosed viisil, mida audiitorid ja kontrollimeetmete omanikud saavad kasutada. Kontrollimeetme 5.16, Identiteedihaldus, puhul selgitab Zenith Controls identiteedi ja autentimisandmete seost:

Identiteedihaldus annab vastuse küsimusele „kes“, samal ajal kui autentimisteave tagab vastuse küsimusele „kuidas“, kinnitades, et identiteeti väitev isik on õiguspärane. 5.16 reguleerib identiteedi elutsükli haldust, 5.17 aga tagab, et paroolid, tokenid, sertifikaadid ja muud autentimisandmed on nende identiteetidega turvaliselt seotud ning neid hallatakse nõuetekohaselt tugeva autentimise toetamiseks.

See seos on NHI-de jaoks keskse tähtsusega. Token ilma identiteedi omanikuta ei ole auditiks sobiv. Teenusekonto ilma juurdepääsuõiguste läbivaatamiseta ei vasta vähima privileegi põhimõttele. Sertifikaat ilma elutsükli staatuseta ei ole kontrollitud krüptograafia. Tarnija integratsiooni autentimisandmed ilma lepingutingimusteta ei ole tõhus kolmanda osapoole riskijuhtimine.

Clarysec’i kontrollimuster: identiteet, saladus, privileeg, tõendusmaterjal

Clarysec rakendab mitteinimidentiteetide ja saladuste haldust korduskasutatava kontrollimustri kaudu. Me ei käsitle „saladusi“ üksnes DevOpsi vastutusena ega „teenusekontosid“ üksnes IAM-i vastutusena. Me seome identiteedi, saladuse, privileegi ja tõendusmaterjali.

Poliitikakiht muudab selle rakendatavaks.

VKE-dele mõeldud Clarysec’i kasutajakontode ja õiguste haldamise poliitika-sme kasutajakontode ja õiguste haldamise poliitika-sme sätestab:

Teenusekontod (mida kasutavad süsteemid või rakendused) peavad olema dokumenteeritud, piiratud konkreetsete süsteemidega ning neid ei tohi kunagi kasutada interaktiivseks sisselogimiseks.

See väldib klassikalist antimustrit, kus teenusekontost saab jagatud administraatori sisselogimine. Samuti annab see audiitorile selge testi: näidake teenusekontode registrit, näidake süsteemipiirangut ja näidake, et interaktiivne sisselogimine on keelatud või tehniliselt takistatud.

Clarysec’i Varahalduse poliitika-sme Varahalduse poliitika-sme laiendab varade määratlust, hõlmates:

Digitaalsed autentimisandmed ja teenused: domeeninimed, digitaalsed sertifikaadid, API-võtmed, e-posti kontod, pilveteenuste sisselogimised

See on oluline, sest paljud organisatsioonid inventeerivad ainult servereid, sülearvuteid ja rakendusi. 2026. aastal võib API-võti olla tundlikum kui sülearvuti. Sertifikaadi privaatvõti võib olla tootmiskeskkonna autentimisvara. Automatiseerimise kasutatav pilveteenuse sisselogimine võib põhjustada reguleeritud andmete kokkupuute. Autentimisandmete käsitlemine varadena on auditivalmis saladuste halduse alus.

Ettevõttekeskkondade jaoks tõstab Clarysec’i kasutajakontode ja õiguste haldamise poliitika kasutajakontode ja õiguste haldamise poliitika tõendusmaterjali lati kõrgemale:

Organisatsioon peab pidama detailset inventuuri kõigist aktiivsetest ja kasutuseta autentimisandmetest, privilegeeritud kontodest ning süsteemitaseme teenusekontodest. Seda inventuuri tuleb pidevalt ajakohastada ja kord kvartalis läbi vaadata.

Kvartaalne läbivaatamine toob esile paljud lüngad. Kasutuseta autentimisandmed, omanikuta teenuseidentiteedid, vanad integratsioonikasutajad, hallamata tarnijakontod ja erakorralised tokenid muutuvad nähtavaks alles siis, kui keegi võrdleb registrit tegelike IAM-i, hoidla, CI/CD ja pilvekirjetega.

Saladused on autentimisteave, mitte arendaja mugavus

Kõige ohtlikum fraas saladuste halduses on „ajutine võti“.

Ajutised võtmed muutuvad püsivateks. Testimise autentimisandmed jõuavad tootmiskeskkonda. Lähtekood paljastab tokenid. Koostamislogid avaldavad paroolid. Tugimeeskonnad jagavad sertifikaate piletite kaudu. Arendajad kopeerivad keskkonnafaile vestlusse. Töövõtja loob pilveteenuse teenuseidentiteedi ja lahkub.

Zenith Blueprint, etapp „Kontrollimeetmed praktikas“, samm 22, kirjeldab autentimisteavet laiemalt:

See kontrollimeede ei puuduta ainult paroole, kuigi paroolid on kindlasti osa pildist. See puudutab iga autentimisandmeid, mida kasutatakse identiteedi kinnitamiseks: paroolid, PIN-koodid, krüptograafilised võtmed, biomeetrilised mallid, kiipkaardid, tokenid, sertifikaadid, OAuthi tokenid, SSH-võtmed, API saladused. Need on kuningriigi võtmed ning kontrollimeede 5.17 tagab, et neid võtmeid käsitletakse vajaliku tõsidusega.

Olgem selged: nõrk autentimishaldus on endiselt üks peamisi algpõhjuseid andmeleketes. Nõrgad või jagatud paroolid. Kõvakodeeritud autentimisandmed lähtekoodis. Muutmata vaikesisselogimised haldusportaalides. Aegunud või teadmata omanikuga sertifikaadid. Kõigil neil juhtudel ei kukkunud läbi identiteet, vaid ebaõnnestus selle mehhanismi kaitsmine ja juhtimine, mida kasutatakse identiteedi tõendamiseks.

Clarysec’i poliitikad teisendavad selle operatiivseteks reegliteks.

Krüptograafiliste kontrollimeetmete poliitika-sme Krüptograafiliste kontrollimeetmete poliitika-sme sätestab:

Võtmeid ei tohi säilitada lihttekstina ega manustada lähtekoodi, dokumentidesse või e-kirjadesse

Turvalise arenduse poliitika-sme Turvalise arenduse poliitika-sme sätestab:

Lähtekoodis ei tohi olla kõvakodeeritud autentimisandmeid ega saladusi

Ettevõtte meeskondadele sätestab Turvalise arenduse poliitika Turvalise arenduse poliitika:

Saladusi ei tohi kõvakodeerida ega säilitada repositooriumides lihttekstina.

Ja Rakendusturbe nõuete poliitika Rakendusturbe nõuete poliitika on veel otsesem:

Paroolide või krüptograafiliste võtmete säilitamine lihttekstina on rangelt keelatud.

Need poliitikasätted loovad selge auditijälje. Turvameeskonnad saavad repositooriume, CI/CD muutujaid, konteinerikujutisi, konfiguratsioonihoidlaid, probleemihaldussüsteeme, dokumentatsiooniplatvorme ja logisid testida selgesõnaliste nõuete alusel. Need toetavad ka GDPR Article 32 töötlemise turvalisuse nõuet, sest saladuste avalikustumine võib otseselt viia volitamata juurdepääsuni isikuandmetele.

Ettevõtte krüptograafia juhtimine vajab samuti omandivastutust. Clarysec’i Krüptograafiliste kontrollimeetmete poliitika Krüptograafiliste kontrollimeetmete poliitika nõuab:

Kõigi krüptograafiliste võtmete, nende elutsükli staatuse, määratud hoidjate ja kasutuskontekstide registreerimiseks tuleb pidada keskset võtmehalduse registrit.

Mitteinimidentiteetide puhul peab see register siduma sertifikaadivõtmed, allkirjastamisvõtmed, API-võtmed ja pilves hallatavad võtmed laiema NHI registriga. Audiitor peab suutma jälgida tootmiskeskkonna sertifikaati äriteenusest omanikuni, hoidjani, aegumistähtajani, rotatsiooni tõendusmaterjalini ja intsidentidele reageerimise protseduurini.

NIS2, DORA ja GDPR: üks tõendusmudel, mitu regulaatorit

Mitteinimidentiteetide juhtimine on mitut nõuete raamistikku hõlmav probleem, sest sama rikkumine võib käivitada mitu kohustust.

Lekinunud API-token SaaS-i pakkuja juures võib põhjustada teenusekatkestuse NIS2 tähenduses, isikuandmete kokkupuute GDPR tähenduses ja lepingulise intsidenditeavituse finantsklientidele DORA tarneahela ootuste alusel. Kompromiteeritud CI/CD saladus IKT-teenusepakkuja juures võib mõjutada klientide talitluspidevust, tarkvara terviklust ja operatsioonilist toimepidevust. Unustatud tarnija integratsioonikonto võib anda juurdepääsu reguleeritud süsteemidele ilma nõuetekohase taustakontrolli või lepinguliste kontrollimeetmeteta.

NIS2 Article 21 nõuab asjakohaseid ja proportsionaalseid tehnilisi, operatiivseid ja korralduslikke meetmeid. Miinimumvaldkonnad hõlmavad riskianalüüsi, infosüsteemide turbepoliitikaid, intsidentide käsitlemist, talitluspidevust, tarneahela turvet, turvalist hankimist, arendust ja hooldust, haavatavuste käsitlemist, tõhususe hindamist, küberhügieeni, krüptograafiat, personaliturvet, juurdepääsukontrolli ja varahaldust ning vajaduse korral MFA-d või pidevat autentimist. Mitteinimidentiteedid paiknevad peaaegu kõigis nendes valdkondades. NIS2 Article 23 loob ka etapiviisilise olulistest intsidentidest teatamise, sealhulgas varajase hoiatuse 24 tunni jooksul, intsidenditeavituse 72 tunni jooksul ja lõpparuande hiljemalt ühe kuu jooksul pärast intsidenditeavitust.

DORA kohaldub alates 17. jaanuarist 2025 ning hõlmab IKT-riski juhtimist, suurematest IKT-ga seotud intsidentidest teatamist, talitluspidevuse testimist, teabe jagamist ja IKT kolmandate osapoolte riski. DORA Articles 5 and 6 nõuavad juhtimist, juhtorgani vastutust ja dokumenteeritud IKT-riski juhtimise raamistikku. Article 8 nõuab IKT-toega ärifunktsioonide, teabevarade ja sõltuvuste tuvastamist. Articles 17 to 19 nõuavad intsidendihaldust, klassifitseerimist ja aruandlust. Articles 28 to 30 nõuavad IKT kolmandate osapoolte riskijuhtimist, lepinguregistreid, taustakontrolli, turbestandardeid, auditeerimisõigusi, intsidendituge, alltöövõtu kontrollimeetmeid ja väljumisstrateegiaid.

GDPR kohaldub kõikjal, kus isikuandmeid töödeldakse selle territoriaalse kohaldamisala alusel. Article 5 nõuab terviklust, konfidentsiaalsust ja vastutust. Article 32 nõuab töötlemise turvalisuse jaoks asjakohaseid tehnilisi ja korralduslikke meetmeid. Kui teenusekonto või API-võti pääseb ligi isikuandmetele, muutuvad hallamata saladused andmekaitse kontrollimeetme rikkeks, mitte ainult IT-probleemiks.

Sama tõendusmaterjal võib toetada ISO/IEC 27001:2022 sertifitseerimist, NIS2 järelevalvet, DORA kontrolle ja GDPR vastutust, kui see on õigesti struktureeritud.

NIST CSF 2.0 saab kasutada sama tõendusmaterjali kommunikatsioonikihina. Selle GOVERN-funktsioon hõlmab sidusrühmade ootusi, õiguslikke ja lepingulisi kohustusi, riskivalmidust, juhtkonna vastutust, poliitikat ja järelevalvet. Selle operatiivsed tulemused hõlmavad varade registreid, tarnijate osutatavaid teenuseid, identiteedi- ja autentimisandmete haldust, vähima privileegi põhimõtet, andmeturvet, logimist, seiret, intsidentidele reageerimist ja taastet.

COBIT 2019 ja ISACA-laadsed kindlust andvad meeskonnad vaatavad tavaliselt juhtimist ja protsessivõimekust. Nad küsivad, kas vastutus on määratud, kas kontrollimeetmed on operatiivsetesse protsessidesse lõimitud, kas erandid on heaks kiidetud, kas mõõdikud esitatakse juhtkonnale ning kas tõendusmaterjal näitab korratavust, mitte ühekordset korrastust.

Praktiline sprint mitteinimidentiteetide registri loomiseks

Praktiline Clarysec’i kaasamine algab sageli fokusseeritud sprindiga, mitte kuuekuulise tööriistaprogrammiga. Eesmärk on koostada kaitstav NHI register, riskijärjestus ja parandusmeetmete plaan, mida saab siduda ISO/IEC 27001:2022 riski käsitlemise plaani ja kohaldatavusdeklaratsiooniga.

Alustage ühest äriteenusest, näiteks kliendi arveldusplatvormist, kauplemisrakendusest, patsiendiportaalist või SaaS-i rentnike haldussüsteemist. Kaasake tootmiskeskkond, vahekeskkond, CI/CD, pilvetaristu, seiretööriistad, andmebaasid, SaaS-integratsioonid ja tarnija hallatavad teenused.

Siduge see Zenith Blueprint riskijuhtimise faasi sammuga 14, kus Clarysec joondab käsitluspoliitikad regulatiivsete ristviidetega. Selles etapis hõlmavad turvalise arenduse ja konveierite kontrollimeetmed kõvakodeeritud saladuste keeldu, kolleegipoolseid koodikontrolle, automatiseeritud staatilist analüüsi, sõltuvuste skannimist, arendus-, testimis- ja tootmiskeskkonna eraldamist, MFA-d konveierile juurdepääsuks, koostamisartefaktide terviklust ja CI/CD logimist.

Koguge identiteedid ja saladused identiteedipakkujast, pilve IAM-ist, saladuste hoidlast, Kubernetesest, CI/CD muutujatest, repositooriumi seadetest, andmebaasikasutajatest, SaaS-i halduskonsoolidest, sertifikaadihalduse tööriistadest ja tarnijadokumentatsioonist.

Hinnake riskitaseme alusel identiteete, millel on tootmiskeskkonna juurdepääs, privilegeeritud õigused, ligipääs isikuandmetele, sõltuvus kriitilisest või olulisest funktsioonist, tarnijapoolne kontroll, pikaealised tokenid, puuduv omanik, puuduv rotatsioon, puuduv seire või kõvakodeeritud säilitamine. Kasutage tõenäosuse ja mõju skoorimiseks ISO/IEC 27001:2022 riskikriteeriume. Vajaduse korral kasutage DORA kriitilise või olulise funktsiooni analüüsi. Kui isikuandmed on ligipääsetavad, kasutage GDPR mõju kaalutlusi. Kui katkestus või kliendikahju on usutav, kasutage NIS2 teenusemõju.

Rakendage iga kõrge riskiga NHI puhul käsitlusmeetmeid. Viige saladused lähtekoodist, dokumentidest ja CI/CD lihtteksti muutujatest hoidlasse või hallatud saladuste talletusse. Asendage jagatud teenusekontod unikaalsete töökoormuse identiteetidega. Keelake teenusekontode interaktiivne sisselogimine. Rakendage vähima privileegi põhimõtet ja keskkonnapõhiseid autentimisandmeid. Seadistage rotatsioon, aegumine ja erakorraline tühistamine. Siduge saladused omanike ja hoidjatega. Lisage logimine autentimise, tokeni kasutamise ja tundlike tegevuste jaoks. Lisage teavitused anomaalse geograafia, ebatavalise aja, ebatavalise mahu või uue ressursi juurdepääsu kohta. Ajakohastage tarnijalepinguid autentimisandmete käitlemise, intsidenditoe ja auditeerimisõiguste osas. Dokumenteerige erandid koos riskiomaniku heakskiidu ja aegumiskuupäevaga.

Testandmete ja testkeskkonna poliitika Testandmete ja testkeskkonna poliitika toetab keskkondade eraldamist:

CI/CD konveieritega integreerimine peab jõustama keskkondade ja autentimisandmete eraldamise.

See säte on sageli otsustava tähtsusega. Kui arendus-, test- ja tootmiskeskkond jagavad saladusi, võib madala riskiga keskkonnast saada tootmiskeskkonna rikkumise tee.

Sprint peab lõppema tõendusmaterjalide paketiga, mitte ainult leidude loeteluga. Kaasake NHI registri eksport, riskihindamise kirjed, käsitlusplaan, kohaldatavusdeklaratsiooni kaardistus, poliitikaviited, hoidla ekraanipildid, rotatsioonilogid, juurdepääsuõiguste läbivaatamise kinnitused, CI/CD saladuste skannimise tulemused, seirereeglite määratlused, tarnija autentimisandmete vastutusmaatriks, intsidendi tööjuhis ning erandid koos omanike ja aegumiskuupäevadega.

Logimine ja tuvastamine: tõendamine, et masinidentiteetide kasutus on nähtav

Masinidentiteet, mis on hästi inventeeritud, kuid logides nähtamatu, jääb ohtlikuks. Tuvastamine on osa kontrolliloost.

Clarysec’i logimis- ja seirepoliitika-sme logimis- ja seirepoliitika-sme hõlmab autentimise tõendusmaterjali:

Autentimislogid: edukad ja ebaõnnestunud sisselogimiskatsed, seansi kestus, MFA kasutamine

NHI-de puhul kohandage see nõue masina autentimisele. Töökoormuse identiteedi puhul ei pruugi MFA kasutust olla, kuid olemas peavad olema autentimissündmused, tokeni kasutus, sertifikaadi kasutus, API-kutse metaandmed, lähtetöökoormus, sihtteenus, tokeni eluiga, tõrkesündmused ja privilegeeritud tegevused.

Zenith Controls seob ISO/IEC 27002:2022 kontrollimeetme 8.2, Privilegeeritud juurdepääsuõigused, logimise ja seirega, sest privilegeeritud kontod vajavad detailseid kirjeid ja järelevalvet. Zenith Controls seob 8.2 ka identiteedihalduse, juurdepääsuõiguste, teabele juurdepääsu piiramise ja turvalise autentimisega. Audiitorite jaoks tähendab see, et privilegeeritud mitteinimidentiteete tuleb läbi vaadata ja seirata sama tõsiselt kui inimadministraatoreid, mõnikord veel tõsisemalt.

Head seireküsimused on järgmised:

• Kas teenusekonto autentis end ootamatust töökoormusest või IP-vahemikust?
• Kas API-võti pääses ligi uuele lõpp-punktile või andmestikule?
• Kas sertifikaati kasutati pärast asendamist?
• Kas CI/CD token juurutas väljaspool heakskiidetud konveierit?
• Kas ainult lugemisõigusega konto üritas kirjutamistoiminguid?
• Kas kasutuseta autentimisandmed muutusid aktiivseks?
• Kas tarnija integratsioon pääses andmetele ligi väljaspool kokkulepitud aegu või mahtusid?

Kui 02:13 teavitus toimub, peate suutma vastata, millist identiteeti kasutati, milline saladus selle autentis, milliseid juurdepääsuõigusi kasutati, milliseid andmeid või süsteeme see mõjutas, kas tegevus oli oodatud, milline omanik saab selle valideerida ja kas intsidendist teatamise lävendid on täidetud.

Audiitori vaade: sama protsess, erinevad küsimused

Tugevaim auditipositsioon ei ole „me vastame kõigele“. See on „me kasutame ühte kontrollitud protsessi, mis toodab tõendusmaterjali mitme kohustuse jaoks“. Erinevad audiitorid kontrollivad seda protsessi erinevalt.

Nende vaadete lõikes korduvad leiud on etteaimatavad: puudub ühtne NHI inventuur, masinidentiteetidel puudub omanik, saladused on salvestatud koodi või dokumentatsiooni, autentimisandmed on keskkondade vahel jagatud, rotatsiooni või aegumist ei ole, tarnija hallatavad autentimisandmed jäävad juurdepääsuõiguste ülevaatustest välja, seire katab inimesi, kuid mitte masinaid, ning intsidendi tööjuhised eiravad saladuste lekkimist.

Iga leid kaardistub loomulikult Clarysec’i kontrollimeetmete, poliitikate ja parandusmeetmete mallidega. Veelgi olulisem on, et iga leiu saab ISMS-is teisendada mõõdetavaks tõendusmaterjaliks.

Kuidas Clarysec aitab auditiks valmis saada

Clarysec’i lähenemine on praktiline, sest see alustab tõendusmaterjalist, mida audiitorid küsivad, ning liigub sealt tagasi kontrollimeetmete, poliitikate ja operatiivsete rutiinideni.

Zenith Blueprint etapis „Kontrollimeetmed praktikas“, samm 19, annab Clarysec otsesed suunised masin-masin autentimiseks:

Masin-masin autentimise puhul, näiteks teenusekontode või API-kutsete korral, tuleb võtmeid, sertifikaate ja tokeneid kaitsta sama rangelt. Vältige autentimisandmete manustamist koodi. Kasutage saladuste haldussüsteeme või hoidlaid, et neid turvaliselt säilitada ja roteerida.

Tüüpiline Clarysec’i mitteinimidentiteetide töövoog hõlmab NHI avastamist pilves, SaaS-is, CI/CD-s, repositooriumides, hoidlates ja andmebaasides, poliitikalünkade hindamist Clarysec’i VKE või ettevõtte poliitikakomplektide suhtes, ISO/IEC 27001:2022 riskihindamise ja käsitluse kaardistamist, kohaldatavusdeklaratsiooni uuendusi, NIS2, DORA, GDPR ja NIST CSF tõendusmaterjali kaardistust, NHI registri kavandamist, võtmehalduse registri joondamist, saladuste skannimist, juurdepääsuõiguste läbivaatamise protsesse, tarnija autentimisandmete vastutusmaatrikseid, intsidendi tööjuhiseid ja auditipakette koos ekraanipiltide, eksportide, logide, kinnituste ja erandikirjetega.

VKE-de puhul on lähenemine proportsionaalne. 70 inimesega SaaS-i pakkuja ei vaja sama tööriistamahtu kui üleilmne pank, kuid ta vajab omandivastutust, poliitikat, riskikäsitlust ja tõendusmaterjali. Reguleeritud finantsüksuste ja IKT-teenusepakkujate puhul skaleerub sama mudel DORA kriitiliste funktsioonide kaardistamiseks, kolmandate osapoolte riskijuhtimiseks ja talitluspidevuse testimiseks.

Kui teie järgmine audit toimub 2026. aastal, ärge oodake, kuni audiitor mitteinimidentiteedid teie eest avastab. Alustage ühest kriitilisest teenusest ja esitage viis küsimust:

1. Kas me teame iga teenusekontot, API-võtit, tokenit, sertifikaati ja CI/CD saladust, mida see teenus kasutab?
2. Kas igal NHI-l on nimeline omanik, hoidja, eesmärk ja riskihinnang?
3. Kas saladused on hoidlates, roteeritud ning kaitstud lähtekoodi, dokumentide, e-kirjade ja lihtteksti salvestuse eest?
4. Kas privilegeeritud masinidentiteedid on läbi vaadatud, seiratud ja interaktiivsest kasutusest piiratud?
5. Kas suudame ühest kontrollitud protsessist toota tõendusmaterjali ISO/IEC 27001:2022, NIS2, DORA ja GDPR jaoks?

Kasutage Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, et struktureerida oma ISMS-i rakendamise teekond. Kasutage Zenith Controls: The Cross-Compliance Guide Zenith Controls, et siduda ISO/IEC 27002:2022 identiteedi, autentimise, privileegide, logimise, krüptograafia, turvalise arenduse ja tarnijate kontrollimeetmed regulatiivse tõendusmaterjaliga. Kasutage Clarysec’i VKE ja ettevõtte poliitikate kogu, sealhulgas kasutajakontode ja õiguste haldamise poliitika-sme kasutajakontode ja õiguste haldamise poliitika-sme, Krüptograafiliste kontrollimeetmete poliitika Krüptograafiliste kontrollimeetmete poliitika, Turvalise arenduse poliitika Turvalise arenduse poliitika ja Rakendusturbe nõuete poliitika Rakendusturbe nõuete poliitika, et muuta head kavatsused rakendatavateks nõueteks.

02:13 teavitus toimub kusagil niikuinii. Küsimus on selles, kas teie organisatsioon suudab tõendusmaterjaliga vastata, kelle käes oli võti, mida see avas, miks see eksisteeris ja kui kiiresti suudate selle ohutuks muuta.