Upravljanje skrivnosti za nečloveške identitete za presoje v letu 2026

Opozorilo ob 02:13, ki ga nihče ni znal pripisati

Ob 02:13 v torek zjutraj zasveti kanal varnostno-operativnega centra. Iz internega računa za avtomatizacijo se je začel izvoz produkcijske podatkovne baze. Pot dostopa je legitimna. Žeton je veljaven. Izvorni IP pripada ponudniku oblaka, ki ga uporablja inženirska ekipa. Zlonamerne programske opreme ni videti. Prijave lažnega predstavljanja ni.

Vodja informacijske varnosti zastavi prvo očitno vprašanje: »Kdo je lastnik te identitete?«

Tišina.

Vodja DevOps se spomni, da je bil žeton ustvarjen med migracijo stranke pred dvema letoma. Ekipa za platformo pravi, da ga morda uporablja obračunska integracija. Administrator podatkovne baze pravi, da ima dostop za branje, ker je njegova odstranitev nekoč prekinila nočno opravilo. Pravna služba vpraša, ali so bili vključeni osebni podatki. Funkcija skladnosti vpraša, ali gre za incident, ki ga je treba priglasiti po NIS2, DORA ali GDPR. Presojevalec zahteva dokazila, da so storitveni računi, ključi API, digitalna potrdila in skrivnosti CI/CD popisani, pregledani, menjani, spremljani in preklicani.

Do 09:00 se osnutek presojevalske ugotovitve že oblikuje. V pozabljeni mikrostoritvi je bil odkrit trdo kodiran ključ API, ki se ni menjal. Omogoča širok dostop do produkcijske podatkovne baze transakcij strank. Razvijalec, ki ga je ustvaril, je odšel pred dvema letoma. Sistem nima imenovanega lastnika, dokumentiranega namena, zapisa o menjavi in pravila spremljanja.

To je problem nečloveških identitet v letu 2026.

Večina organizacij je izboljšala nadzor dostopa za ljudi. Imajo večfaktorsko avtentikacijo (MFA), delovne tokove za novozaposlene, premeščene in odhajajoče zaposlene, preglede privilegiranega dostopa in dnevnike ponudnikov identitet. Toda strojne identitete so se širile hitreje kot upravljanje. Storitveni računi, identitete delovnih obremenitev, ključi API, žetoni OAuth, ključi SSH, digitalna potrdila, skrivnosti Kubernetes, integracijski žetoni SaaS, računi za robotsko avtomatizacijo procesov in poverilnice za uvajanje CI/CD danes izvajajo kritična poslovna dejanja, ne da bi bili »uporabniki« v človeškem pomenu.

Za ponudnike SaaS, fintech podjetja, ponudnike upravljanih storitev, operaterje v oblaku ter podatkovno intenzivna mala in srednja podjetja neupravljane nečloveške identitete niso več vprašanje tehnične higiene. So tveganje odpornosti in skladnosti na ravni upravnega odbora. NIS2 obravnava nadzor dostopa, upravljanje sredstev, varnost dobavne verige, obvladovanje incidentov in kibernetsko higieno kot ključne ukrepe za obvladovanje tveganj kibernetske varnosti. DORA postavlja upravljanje tveganj IKT, operativno odpornost, poročanje o incidentih in tveganje tretjih oseb na področju IKT pod odgovornost upravljalnega organa finančnih subjektov. GDPR od upravljavcev in obdelovalcev zahteva varstvo osebnih podatkov ter dokazljivo odgovornost.

Težava ni dokazati, da skrivnosti obstajajo. Težava je dokazati, da ima vsaka nečloveška identiteta lastnika, namen, življenjski cikel, oceno tveganja, odobren dostop, varen način hrambe, pravilo menjave, pokritost s spremljanjem in pot preklica.

Zakaj so nečloveške identitete postale novi problem privilegiranega dostopa

Nečloveška identiteta oziroma NHI je vsaka digitalna identiteta, ki jo uporablja programska oprema, infrastruktura ali avtomatizirani procesi, ne pa oseba. V praksi vključuje storitvene račune, ki jih uporabljajo aplikacije, ključe API za integracije SaaS, žetone OAuth in osvežitvene žetone, ki jih uporabljajo aplikacije tretjih oseb, ključe SSH za avtomatizacijo, digitalna potrdila TLS in zasebne ključe, skrivnosti CI/CD, identitete delovnih obremenitev v oblaku, povezovalne nize za podatkovne baze, vdelane poverilnice, račune botov RPA in integracijske poverilnice, ki jih upravljajo dobavitelji.

Te identitete imajo pogosto tri značilnosti, zaradi katerih presojevalci postanejo pozorni.

Prvič, so dolgožive. Človeški uporabnik lahko zamenja poverilnice, spremeni vlogo in odide skozi formalni postopek prenehanja. Žeton API, ustvarjen med oknom izdaje, lahko ostane aktiven več let, ker nihče ne želi tvegati prekinitve produkcije.

Drugič, so zmogljive. Žeton za uvajanje lahko spremeni infrastrukturo. Glavni storitveni račun v oblaku lahko ustvari shrambo. Račun podatkovne baze lahko izvozi evidence o strankah. Podpisni ključ lahko ogrozi celovitost dobavne verige programske opreme.

Tretjič, težko jih je pripisati. Človeške identitete so povezane s kadrovskimi evidencami. Nečloveške identitete so pogosto povezane s skriptami, cevovodi, dobavitelji, pozabljenimi projekti ali nedokumentiranimi integracijami.

Clarysecov Zenith Blueprint: 30-koračni načrt presojevalca Zenith Blueprint to neposredno izpostavi v fazi Controls in Action, korak 22:

Ne pozabite na nečloveške identitete. Tu presoje pogosto odkrijejo tiho izpostavljenost. Ali so žetoni API evidentirani? Ali so integracijski računi vezani na ljudi ali lebdijo v praznini? Kdaj je bil nazadnje zamenjan povezovalni niz za podatkovno bazo, vdelan v desetletja staro skripto?

Upravljanje identitet ni glamurozno, vendar je strukturno. Brez njega je vaš ISMS le zbirka zaklenjenih vrat, brez možnosti zanesljivo ugotoviti, kdo ima ključe.

Zadnji stavek je bistvo. Podjetje ima lahko dovršeno politiko nadzora dostopa, pa vseeno ne uspe pri presoji, če strojne identitete niso upravljane. ISMS, ki ne zna pojasniti, kdo je lastnik skrivnosti, zakaj obstaja in kdaj je bila nazadnje pregledana, še ne deluje kot nadzorovan sistem.

ISO/IEC 27001:2022 upravljanje skrivnosti spremeni v dokazila

ISO/IEC 27001:2022 je učinkovit, ker upravljanja skrivnosti ne obravnava kot izolirano inženirsko nalogo. Zahteva ISMS na podlagi tveganj z opredeljenim obsegom, zahtevami zainteresiranih strani, odgovornostjo vodstva, oceno tveganja, obravnavo tveganja, izbiro kontrol, izjavo o uporabnosti in nenehnim izboljševanjem.

Pri nečloveških identitetah organizacija ne sme začeti z nakupom orodja. Začeti mora z obsegom in obveznostmi.

V skladu s klavzulami ISO/IEC 27001:2022 4.1 do 4.4 organizacija določi notranja in zunanja vprašanja, zainteresirane strani, pravne, regulativne in pogodbene zahteve, vmesnike in odvisnosti. V kontekstu NHI mora obseg ISMS opredeliti okolja v oblaku, platforme SaaS, sisteme CI/CD, produkcijske aplikacije, integracije s strankami, obdelovalce podatkov, ponudnike upravljanih storitev in kriptografske storitve, kjer obstajajo strojne poverilnice.

Klavzule 5.1 do 5.3 vodstvo zavezujejo k odgovornosti za politiko, vire, vloge in poročanje o uspešnosti. To je pomembno, ker odpravljanje tveganj NHI pogosto povzroča operativne napetosti. Menjava produkcijske poverilnice podatkovne baze, zamenjava zastarelega skupnega storitvenega računa ali uveljavitev vbrizgavanja skrivnosti iz trezorja lahko prekine krhke delovne tokove. Brez izvršnega sponzorja ekipe čiščenje odlagajo.

Klavzule 6.1.1 do 6.1.3 in 6.2 zagotavljajo kontrolni mehanizem. Organizacija opredeli merila tveganja, prepozna tveganja za zaupnost, celovitost in razpoložljivost, določi lastnike tveganj, ovrednoti verjetnost in vpliv, izbere možnosti obravnave, izbere kontrole, pripravi izjavo o uporabnosti in spremlja merljive cilje.

V praksi mora načrt obravnave tveganja za nečloveške identitete odgovoriti na vprašanja:

• Kateri sistemi in poslovne storitve so odvisni od NHI?
• Katere skrivnosti omogočajo dostop do osebnih podatkov, reguliranih finančnih storitev, produkcijske infrastrukture ali kritičnih storitev za stranke?
• Katere identitete so privilegirane, mirujoče, deljene, upravljane s strani dobavitelja ali neupravljane?
• Katere kontrole zmanjšujejo tveganje, na primer hramba v trezorju, menjava, načelo najmanjših privilegijev, potek veljavnosti, upravljanje življenjskega cikla digitalnih potrdil, skeniranje CI/CD, spremljanje in nujni preklic?
• Katera preostala tveganja zahtevajo poslovno odobritev?

ISO/IEC 27002:2022 nato zagotovi katalog kontrol iz Annex A. Najpomembnejše kontrole vključujejo 5.9 Popis informacij in drugih povezanih sredstev, 5.15 Nadzor dostopa, 5.16 Upravljanje identitet, 5.17 Avtentikacijske informacije, 5.18 Pravice dostopa, 5.19 Informacijska varnost v odnosih z dobavitelji, 5.20 Obravnava informacijske varnosti v sporazumih z dobavitelji, 5.21 Upravljanje informacijske varnosti v dobavni verigi IKT, 5.23 Informacijska varnost pri uporabi storitev v oblaku, 5.24 Načrtovanje in priprava upravljanja incidentov, 5.28 Zbiranje dokazov, 8.2 Privilegirane pravice dostopa, 8.3 Omejevanje dostopa do informacij, 8.5 Varna avtentikacija, 8.15 Beleženje, 8.16 Dejavnosti spremljanja, 8.24 Uporaba kriptografije, 8.25 Varen življenjski cikel razvoja, 8.26 Zahteve informacijske varnosti aplikacij, 8.28 Varno kodiranje in 8.31 Ločevanje razvojnih, testnih in produkcijskih okolij.

Clarysecov Zenith Controls: vodnik za navzkrižno skladnost Zenith Controls preslika ta razmerja ISO/IEC 27002:2022 na način, ki ga lahko uporabljajo presojevalci in lastniki kontrol. Za kontrolo 5.16, Upravljanje identitet, Zenith Controls pojasni povezavo med identiteto in poverilnicami:

Upravljanje identitet določa »kdo«, avtentikacijske informacije pa zagotavljajo »kako« — preverjanje, da je oseba, ki uveljavlja identiteto, legitimna. 5.16 ureja upravljanje življenjskega cikla identitet, 5.17 pa zagotavlja, da so gesla, žetoni, digitalna potrdila in druge poverilnice varno povezani s temi identitetami ter ustrezno upravljani za podporo močni avtentikaciji.

To razmerje je bistveno za NHI. Žeton brez lastnika identitete ni preverljiv. Storitveni račun brez pregleda pravic dostopa ni skladen z načelom najmanjših privilegijev. Digitalno potrdilo brez statusa življenjskega cikla ni nadzorovana kriptografija. Integracijska poverilnica dobavitelja brez pogodbenih določil ni učinkovito upravljanje tveganj tretjih oseb.

Clarysecov kontrolni vzorec: identiteta, skrivnost, privilegij, dokazila

Clarysec upravljanje nečloveških identitet in skrivnosti izvaja prek ponovljivega kontrolnega vzorca. »Skrivnosti« ne obravnavamo zgolj kot skrb DevOps, »storitvenih računov« pa ne zgolj kot skrb IAM. Povežemo identiteto, skrivnost, privilegij in dokazila.

Na ravni politike to postane izvršljivo.

Za mala in srednja podjetja Clarysecova Politika upravljanja uporabniških računov in privilegijev-sme Politika upravljanja uporabniških računov in privilegijev-sme določa:

Storitveni računi (ki jih uporabljajo sistemi ali aplikacije) morajo biti dokumentirani, omejeni na določene sisteme in se nikoli ne smejo uporabljati za interaktivne prijave.

To preprečuje klasičen neustrezen vzorec, pri katerem storitveni račun postane skupna administratorska prijava. Presojevalcu daje tudi jasen test: pokažite popis storitvenih računov, pokažite sistemsko omejitev in pokažite, da je interaktivna prijava onemogočena ali tehnično preprečena.

Clarysecova Politika upravljanja sredstev-sme Politika upravljanja sredstev-sme razširi definicijo sredstev tako, da vključuje:

Digitalne poverilnice in storitve: domenska imena, digitalna potrdila, ključi API, e-poštni računi, prijave v oblak

To je pomembno, ker številne organizacije popisujejo samo strežnike, prenosnike in aplikacije. V letu 2026 je lahko ključ API občutljivejši od prenosnika. Zasebni ključ digitalnega potrdila je lahko produkcijsko avtentikacijsko sredstvo. Prijava v oblak, ki jo uporablja avtomatizacija, lahko povzroči izpostavljenost reguliranih podatkov. Obravnava poverilnic kot sredstev je temelj upravljanja skrivnosti, pripravljenega na presojo.

Za poslovna okolja Clarysecova Politika upravljanja uporabniških računov in privilegijev Politika upravljanja uporabniških računov in privilegijev dvigne raven dokazil:

Organizacija mora vzdrževati podroben popis vseh aktivnih in mirujočih poverilnic, privilegiranih računov in sistemskih storitvenih računov. Ta popis se mora stalno posodabljati in četrtletno pregledovati.

Pri četrtletnem pregledu se pokaže veliko vrzeli. Mirujoče poverilnice, osiroteli glavni storitveni računi, stari integracijski uporabniki, neupravljani računi dobaviteljev in nujni žetoni postanejo vidni šele, ko nekdo primerja register z dejanskimi zapisi IAM, trezorja, CI/CD in oblaka.

Skrivnosti so avtentikacijske informacije, ne priročnost za razvijalce

Najnevarnejša besedna zveza pri upravljanju skrivnosti je »začasni ključ«.

Začasni ključi postanejo trajni. Testne poverilnice dosežejo produkcijo. Izvorna koda razkrije žetone. Dnevniki gradnje izpostavijo gesla. Podporne ekipe delijo digitalna potrdila prek zahtevkov. Razvijalci kopirajo okoljske datoteke v klepet. Izvajalec ustvari glavni storitveni račun v oblaku in odide.

Zenith Blueprint, faza Controls in Action, korak 22, avtentikacijske informacije opisuje široko:

Ta kontrola ne govori samo o geslih, čeprav so gesla zagotovo del slike. Gre za vsako poverilnico, uporabljeno za uveljavljanje identitete: gesla, kode PIN, kriptografske ključe, biometrične predloge, pametne kartice, žetone, digitalna potrdila, žetone OAuth, ključe SSH, skrivnosti API. To so ključi kraljestva, kontrola 5.17 pa zagotavlja, da se ti ključi obravnavajo z resnostjo, ki si jo zaslužijo.

Bodimo jasni: slabo upravljanje avtentikacije ostaja eden glavnih temeljnih vzrokov kršitev. Šibka ali skupna gesla. Trdo kodirane poverilnice v izvorni kodi. Nespremenjene privzete prijave na administratorskih portalih. Digitalna potrdila s poteklo veljavnostjo ali neznanim lastništvom. V vsakem od teh primerov ni odpovedala identiteta, temveč je odpovedalo varovanje in upravljanje mehanizma, uporabljenega za dokazovanje te identitete.

Clarysecove politike to prevedejo v operativna pravila.

Politika kriptografskih kontrol-sme Politika kriptografskih kontrol-sme določa:

Ključi se ne smejo hraniti kot nešifrirano besedilo ali biti vdelani v izvorno kodo, dokumente ali e-pošto

Politika varnega razvoja-sme Politika varnega razvoja-sme določa:

Brez trdo kodiranih poverilnic ali skrivnosti v izvorni kodi

Za poslovne ekipe Politika varnega razvoja Politika varnega razvoja določa:

Skrivnosti ne smejo biti trdo kodirane ali shranjene kot nešifrirano besedilo v repozitorijih.

Politika zahtev za varnost aplikacij Politika zahtev za varnost aplikacij pa je še neposrednejša:

Shranjevanje gesel ali kriptografskih ključev kot nešifrirano besedilo je strogo prepovedano.

Te klavzule politike ustvarijo jasno presojevalsko sled. Varnostne ekipe lahko repozitorije, spremenljivke CI/CD, slike vsebnikov, konfiguracijske shrambe, sisteme za upravljanje zahtevkov, dokumentacijske platforme in dnevnike testirajo glede na izrecne zahteve. Podpirajo tudi GDPR Article 32 varnost obdelave, ker lahko izpostavljenost skrivnosti neposredno vodi do nepooblaščenega dostopa do osebnih podatkov.

Upravljanje kriptografije v poslovnem okolju potrebuje tudi lastništvo. Clarysecova Politika kriptografskih kontrol Politika kriptografskih kontrol zahteva:

Vzdrževati je treba centraliziran register upravljanja ključev, ki evidentira vse kriptografske ključe, njihov status življenjskega cikla, dodeljene skrbnike in kontekste uporabe.

Pri nečloveških identitetah mora ta register povezovati ključe digitalnih potrdil, podpisne ključe, ključe API in ključe, upravljane v oblaku, s širšim registrom NHI. Presojevalec mora biti sposoben slediti produkcijskemu digitalnemu potrdilu od poslovne storitve do lastnika, skrbnika, poteka veljavnosti, dokazila o menjavi in postopka odzivanja na incidente.

NIS2, DORA in GDPR: en model dokazil, več regulatorjev

Upravljanje nečloveških identitet je vprašanje navzkrižne skladnosti, ker lahko ista odpoved sproži več obveznosti.

Ušel žeton API pri ponudniku SaaS lahko povzroči prekinitev storitve po NIS2, izpostavljenost osebnih podatkov po GDPR in pogodbeno poročanje o incidentih finančnim strankam glede na pričakovanja DORA za dobavno verigo. Kompromitirana skrivnost CI/CD pri ponudniku storitev IKT lahko vpliva na odpornost strank, celovitost programske opreme in neprekinjeno poslovanje. Pozabljen integracijski račun dobavitelja lahko ustvari dostop do reguliranih sistemov brez ustreznega skrbnega pregleda ali pogodbenih kontrol.

NIS2 Article 21 zahteva ustrezne in sorazmerne tehnične, operativne in organizacijske ukrepe. Minimalna področja vključujejo analizo tveganja, politike varnosti informacijskih sistemov, obravnavanje incidentov, neprekinjeno poslovanje, varnost dobavne verige, varno nabavo, razvoj in vzdrževanje, obravnavo ranljivosti, oceno učinkovitosti, kibernetsko higieno, kriptografijo, kadrovsko varnost, nadzor dostopa in upravljanje sredstev ter, kjer je primerno, MFA ali neprekinjeno avtentikacijo. Nečloveške identitete segajo skoraj čez vsa ta področja. NIS2 Article 23 uvaja tudi stopenjsko poročanje o pomembnih incidentih, vključno z zgodnjim opozorilom v 24 urah, obvestilom o incidentu v 72 urah in končnim poročilom najpozneje en mesec po obvestilu o incidentu.

DORA se uporablja od 17. januarja 2025 in pokriva upravljanje tveganj IKT, poročanje o večjih incidentih, povezanih z IKT, testiranje operativne odpornosti, izmenjavo informacij in tveganje tretjih oseb na področju IKT. Articles 5 in 6 zahtevata upravljanje, odgovornost upravljalnega organa in dokumentiran okvir upravljanja tveganj IKT. Article 8 zahteva identifikacijo poslovnih funkcij, ki jih podpira IKT, informacijskih sredstev in odvisnosti. Articles 17 do 19 zahtevajo upravljanje incidentov, razvrščanje in poročanje. Articles 28 do 30 zahtevajo upravljanje tveganj tretjih oseb na področju IKT, pogodbene registre, skrbni pregled, varnostne standarde, pravice do revizije, podporo pri incidentih, kontrole podizvajanja in strategije izstopa.

GDPR se uporablja povsod, kjer se osebni podatki obdelujejo v okviru njegovega teritorialnega področja uporabe. Article 5 zahteva celovitost, zaupnost in odgovornost. Article 32 zahteva ustrezne tehnične in organizacijske ukrepe za varnost obdelave. Če lahko storitveni račun ali ključ API dostopa do osebnih podatkov, neupravljane skrivnosti postanejo odpoved kontrole zasebnosti, ne le IT-vprašanje.

Ista dokazila lahko podpirajo certifikacijo ISO/IEC 27001:2022, nadzor NIS2, preglede DORA in odgovornost po GDPR, kadar so pravilno strukturirana.

NIST CSF 2.0 se lahko uporabi kot komunikacijska plast za ista dokazila. Njegova funkcija GOVERN pokriva pričakovanja zainteresiranih strani, zakonske in pogodbene obveznosti, apetit po tveganju, odgovornost vodstva, politiko in nadzor. Njegovi operativni izidi pokrivajo popise sredstev, storitve, ki jih zagotavljajo dobavitelji, upravljanje identitet in poverilnic, načelo najmanjših privilegijev, varnost podatkov, beleženje, spremljanje, odziv na incidente in obnovitev.

COBIT 2019 in ekipe za zagotavljanje zaupanja po pristopu ISACA običajno gledajo upravljanje in zmogljivost procesov. Vprašale bodo, ali je odgovornost dodeljena, ali so kontrole vgrajene v operativne procese, ali so izjeme odobrene, ali se kazalniki poročajo vodstvu in ali dokazila izkazujejo ponovljivost, ne le enkratnega čiščenja.

Praktičen sprint za vzpostavitev registra nečloveških identitet

Praktičen Clarysecov angažma se pogosto začne z osredotočenim sprintom, ne s šestmesečnim programom uvajanja orodij. Cilj je pripraviti zagovorljiv register NHI, razvrstitev tveganj in načrt odprave pomanjkljivosti, ki se lahko vključijo v načrt obravnave tveganja ISO/IEC 27001:2022 in izjavo o uporabnosti.

Začnite z eno poslovno storitvijo, na primer platformo za obračun strankam, trgovalno aplikacijo, portalom za paciente ali sistemom za upravljanje najemnikov SaaS. Vključite produkcijo, pripravljalno okolje, CI/CD, infrastrukturo v oblaku, orodja za spremljanje, podatkovne baze, integracije SaaS in storitve, ki jih upravljajo dobavitelji.

To povežite z Zenith Blueprint, faza upravljanja tveganj, korak 14, kjer Clarysec uskladi politike obravnave s sklici za navzkrižno regulativno skladnost. V tem koraku kontrole varnega razvoja in cevovodov vključujejo prepoved trdo kodiranih skrivnosti, medsebojni strokovni pregled, avtomatizirano statično analizo, skeniranje odvisnosti, ločevanje razvoja, testiranja in produkcije, MFA za dostop do cevovodov, celovitost gradbenih artefaktov in beleženje CI/CD.

Zberite identitete in skrivnosti iz ponudnika identitet, IAM v oblaku, trezorja skrivnosti, Kubernetes, spremenljivk CI/CD, nastavitev repozitorijev, uporabnikov podatkovnih baz, administratorskih konzol SaaS, orodij za upravljanje digitalnih potrdil in dokumentacije dobaviteljev.

Ocenite tveganje identitet, ki imajo produkcijski dostop, privilegirane pravice, dostop do osebnih podatkov, odvisnost od kritične ali pomembne funkcije, nadzor dobavitelja, dolgožive žetone, nimajo lastnika, nimajo menjave, nimajo spremljanja ali so shranjene trdo kodirano. Za točkovanje verjetnosti in vpliva uporabite merila tveganja ISO/IEC 27001:2022. Kjer je primerno, uporabite analizo kritičnih ali pomembnih funkcij po DORA. Kjer so dostopni osebni podatki, uporabite vidike vpliva GDPR. Kjer sta verjetna motnja storitve ali škoda za stranke, uporabite vpliv storitve po NIS2.

Za vsako visoko tvegano NHI uporabite ukrepe obravnave. Skrivnosti iz izvorne kode, dokumentov in spremenljivk CI/CD v nešifriranem besedilu premaknite v trezor ali upravljano shrambo skrivnosti. Skupne storitvene račune zamenjajte z enoličnimi identitetami delovnih obremenitev. Onemogočite interaktivno prijavo za storitvene račune. Uporabite načelo najmanjših privilegijev in poverilnice, specifične za okolje. Konfigurirajte menjavo, potek veljavnosti in nujni preklic. Povežite skrivnosti z lastniki in skrbniki. Dodajte beleženje avtentikacije, uporabe žetonov in občutljivih dejanj. Dodajte opozarjanje za anomalno geografijo, neobičajen čas, neobičajen obseg ali dostop do novih virov. Posodobite pogodbe z dobavitelji glede ravnanja s poverilnicami, podpore pri incidentih in pravic do revizije. Dokumentirajte izjeme z odobritvijo lastnika tveganja in datumom poteka.

Politika testnih podatkov in testnega okolja Politika testnih podatkov in testnega okolja podpira ločevanje okolij:

Integracija s CI/CD cevovodi mora uveljaviti ločevanje okolij in avtentikacijskih poverilnic.

Ta klavzula je pogosto odločilna. Če razvoj, testiranje in produkcija delijo skrivnosti, lahko okolje z nizkim tveganjem postane pot do produkcijske kršitve.

Sprint se mora končati s paketom dokazil, ne le s seznamom ugotovitev. Vključite izvoz registra NHI, vnose ocene tveganja, načrt obravnave, preslikavo izjave o uporabnosti, sklice na politike, posnetke zaslona trezorja, dnevnike menjave, odobritve pregledov pravic dostopa, rezultate skeniranja skrivnosti CI/CD, opredelitve pravil spremljanja, matriko odgovornosti za poverilnice dobaviteljev, operativni priročnik za odziv na incidente in izjeme z lastniki ter datumi poteka.

Beleženje in zaznavanje: dokazovanje vidnosti uporabe strojnih identitet

Strojna identiteta, ki je dobro popisana, vendar nevidna v dnevnikih, ostaja nevarna. Zaznavanje je del kontrolne zgodbe.

Clarysecova Politika beleženja in spremljanja-sme Politika beleženja in spremljanja-sme vključuje dokazila o avtentikaciji:

Dnevniki avtentikacije: uspešni in neuspešni poskusi prijave, trajanje seje, uporaba MFA

Za NHI to zahtevo prilagodite strojni avtentikaciji. Za identiteto delovne obremenitve morda ne boste imeli uporabe MFA, morali pa bi imeti dogodke avtentikacije, uporabo žetonov, uporabo digitalnih potrdil, metapodatke klicev API, izvorno delovno obremenitev, ciljno storitev, življenjsko dobo žetona, dogodke neuspeha in privilegirana dejanja.

V Zenith Controls je kontrola ISO/IEC 27002:2022 8.2, Privilegirane pravice dostopa, povezana z beleženjem in spremljanjem, ker privilegirani računi zahtevajo podrobne zapise in nadzor. Zenith Controls povezuje 8.2 tudi z upravljanjem identitet, pravicami dostopa, omejevanjem dostopa do informacij in varno avtentikacijo. Za presojevalce to pomeni, da je treba privilegirane nečloveške identitete pregledovati in spremljati z enako resnostjo kot človeške administratorje, včasih še bolj.

Dobra vprašanja za spremljanje vključujejo:

• Ali se je storitveni račun avtenticiral iz nepričakovane delovne obremenitve ali obsega IP?
• Ali je ključ API dostopal do nove končne točke ali podatkovnega niza?
• Ali je bilo digitalno potrdilo uporabljeno po zamenjavi?
• Ali je žeton CI/CD izvedel uvedbo zunaj odobrenega cevovoda?
• Ali je račun samo za branje poskusil izvajati pisalne operacije?
• Ali je mirujoča poverilnica postala aktivna?
• Ali je integracija dobavitelja dostopala do podatkov zunaj dogovorjenih ur ali obsegov?

Ko se pojavi opozorilo ob 02:13, morate odgovoriti, katera identiteta je bila uporabljena, katera skrivnost jo je avtenticirala, katere pravice dostopa so bile uporabljene, kateri podatki ali sistemi so bili prizadeti, ali je bila dejavnost pričakovana, kateri lastnik jo lahko potrdi in ali so doseženi pragi za poročanje o incidentu.

Pogled presojevalca: isti proces, različna vprašanja

Najmočnejše presojevalsko izhodišče ni »skladni smo z vsem«. Je »upravljamo en nadzorovan proces, ki proizvaja dokazila za več obveznosti«. Različni presojevalci bodo ta proces pregledovali različno.

V vseh teh perspektivah so ponavljajoče se ugotovitve predvidljive: ni enotnega popisa NHI, ni lastnika strojnih identitet, skrivnosti so shranjene v kodi ali dokumentaciji, poverilnice so deljene med okolji, ni menjave ali poteka veljavnosti, poverilnice, ki jih upravljajo dobavitelji, so zunaj pregledov pravic dostopa, spremljanje pokriva ljudi, ne pa strojev, operativni priročniki za odziv na incidente pa ne obravnavajo uhajanja skrivnosti.

Vsako ugotovitev je mogoče naravno preslikati na Clarysecove kontrole, politike in predloge za odpravo pomanjkljivosti. Še pomembneje, vsako je mogoče pretvoriti v merljiva dokazila znotraj ISMS.

Kako vam Clarysec pomaga do pripravljenosti na presojo

Clarysecov pristop je praktičen, ker začne z dokazili, ki jih bodo zahtevali presojevalci, in nato od njih nazaj gradi kontrole, politike in operativne rutine.

V Zenith Blueprint, faza Controls in Action, korak 19, Clarysec podaja neposredna navodila za avtentikacijo med stroji:

Za avtentikacijo med stroji, kot so storitveni računi ali klici API, morajo biti ključi, digitalna potrdila in žetoni zaščiteni enako strogo. Izogibajte se vdelavi poverilnic v kodo. Uporabljajte sisteme za upravljanje skrivnosti ali trezorje za njihovo varno hrambo in menjavo.

Tipičen Clarysecov delovni tok za nečloveške identitete vključuje odkrivanje NHI v oblaku, SaaS, CI/CD, repozitorijih, trezorjih in podatkovnih bazah, oceno vrzeli v politikah glede na Clarysecove nabore politik za mala in srednja podjetja ali poslovna okolja, oceno tveganja ISO/IEC 27001:2022 in preslikavo obravnave, posodobitve izjave o uporabnosti, preslikavo dokazil za NIS2, DORA, GDPR in NIST CSF, zasnovo registra NHI, uskladitev registra upravljanja ključev, skeniranje skrivnosti, procese pregledov pravic dostopa, matrike odgovornosti za poverilnice dobaviteljev, operativne priročnike za odziv na incidente in presojevalske pakete s posnetki zaslona, izvozi, dnevniki, odobritvami in zapisi izjem.

Za mala in srednja podjetja je pristop sorazmeren. Ponudnik SaaS s 70 zaposlenimi ne potrebuje enakega nabora orodij kot globalna banka, potrebuje pa lastništvo, politiko, obravnavo tveganja in dokazila. Za regulirane finančne subjekte in ponudnike IKT se isti model razširi na mapiranje kritičnih funkcij po DORA, upravljanje tveganj tretjih oseb in testiranje odpornosti.

Če je vaša naslednja presoja v letu 2026, ne čakajte, da presojevalec odkrije nečloveške identitete namesto vas. Začnite z eno kritično storitvijo in zastavite pet vprašanj:

1. Ali poznamo vsak storitveni račun, ključ API, žeton, digitalno potrdilo in skrivnost CI/CD, ki jih uporablja ta storitev?
2. Ali ima vsaka NHI imenovanega lastnika, skrbnika, namen in oceno tveganja?
3. Ali so skrivnosti v trezorju, se menjajo in so zaščitene pred izvorno kodo, dokumenti, e-pošto in hrambo kot nešifrirano besedilo?
4. Ali so privilegirane strojne identitete pregledane, spremljane in omejene glede interaktivne uporabe?
5. Ali lahko iz enega nadzorovanega procesa pripravimo dokazila za ISO/IEC 27001:2022, NIS2, DORA in GDPR?

Uporabite Zenith Blueprint: 30-koračni načrt presojevalca Zenith Blueprint za strukturiranje poti implementacije ISMS. Uporabite Zenith Controls: vodnik za navzkrižno skladnost Zenith Controls za povezovanje kontrol ISO/IEC 27002:2022 za identiteto, avtentikacijo, privilegije, beleženje, kriptografijo, varen razvoj in dobavitelje z regulativnimi dokazili. Uporabite Clarysecovo knjižnico politik za mala in srednja podjetja ter poslovna okolja, vključno s Politiko upravljanja uporabniških računov in privilegijev-sme Politika upravljanja uporabniških računov in privilegijev-sme, Politiko kriptografskih kontrol Politika kriptografskih kontrol, Politiko varnega razvoja Politika varnega razvoja in Politiko zahtev za varnost aplikacij Politika zahtev za varnost aplikacij, da dobre namene pretvorite v izvršljive zahteve.

Opozorilo ob 02:13 se bo nekje zgodilo. Vprašanje je, ali lahko vaša organizacija z dokazili odgovori, kdo je imel ključ, kaj je odklenil, zakaj je obstajal in kako hitro ga lahko ponovno zavarujete.