Upravljanje tajnim vrijednostima neljudskih identiteta za revizije u 2026.

Upozorenje u 02:13 kojem nitko nije mogao pripisati vlasništvo

U utorak u 02:13 ujutro aktivira se kanal centra za sigurnosne operacije. Izvoz produkcijske baze podataka pokrenut je s internog računa za automatizaciju. Putanja pristupa je legitimna. Token je valjan. Izvorna IP adresa pripada izvršnom agentu u oblaku koji koristi inženjerski tim. Nema vidljivog zlonamjernog softvera. Nema prijave phishinga.

Glavni službenik za informacijsku sigurnost postavlja prvo očito pitanje: „Tko je vlasnik ovog identiteta?”

Tišina.

Voditelj DevOpsa prisjeća se da je token izrađen tijekom migracije korisnika prije dvije godine. Tim za platformu kaže da ga možda koristi integracija za obračun. Administrator baze podataka kaže da ima pristup za čitanje jer je njegovo uklanjanje jednom prekinulo noćni posao. Pravni poslovi pitaju jesu li bili uključeni osobni podaci. Usklađenost pita je li riječ o incidentu koji se mora prijaviti prema NIS2, DORA ili GDPR. Revizor traži dokaze da su servisni računi, API ključevi, certifikati i CI/CD tajne vrijednosti popisani, pregledavani, rotirani, praćeni i ukinuti.

Do 09:00 nacrt revizijskog nalaza već poprima oblik. Tvrdo kodirani API ključ bez rotacije pronađen je u zaboravljenoj mikrousluzi. Omogućuje širok pristup produkcijskoj bazi podataka s transakcijama korisnika. Razvojni inženjer koji ga je izradio napustio je organizaciju prije dvije godine. Sustav nema imenovanog vlasnika, dokumentiranu svrhu, zapis o rotaciji ni pravilo praćenja.

To je problem neljudskih identiteta u 2026.

Većina organizacija unaprijedila je kontrolu pristupa za ljudske korisnike. Imaju MFA, procese za ulazak novih zaposlenika, promjene radnih mjesta i odlaske, preglede privilegiranog pristupa i zapise pružatelja identiteta. No strojni identiteti umnožili su se brže nego što ih je upravljanje moglo obuhvatiti. Servisni računi, identiteti radnih opterećenja, API ključevi, OAuth tokeni, SSH ključevi, certifikati, Kubernetes tajne vrijednosti, tokeni za SaaS integracije, računi za robotsku automatizaciju procesa i CI/CD vjerodajnice za implementaciju danas izvršavaju kritične poslovne radnje, iako nisu „korisnici” u ljudskom smislu.

Za pružatelje SaaS usluga, fintech društva, pružatelje upravljanih usluga, operatore u oblaku i mala i srednja društva bogata podacima, neupravljani neljudski identiteti više nisu pitanje tehničke higijene. Oni su rizik otpornosti i usklađenosti na razini uprave. NIS2 tretira kontrolu pristupa, upravljanje imovinom, sigurnost opskrbnog lanca, postupanje s incidentima i kibernetičku higijenu kao temeljne mjere upravljanja rizicima kibernetičke sigurnosti. DORA stavlja IKT rizik, operativnu otpornost, prijavljivanje incidenata i rizik trećih strana u području IKT-a pod odgovornost upravljačkog tijela financijskih subjekata. GDPR zahtijeva da voditelji obrade i izvršitelji obrade štite osobne podatke i dokažu odgovornost.

Teži dio nije dokazati da tajne vrijednosti postoje. Teži dio je dokazati da svaki neljudski identitet ima vlasnika, svrhu, životni ciklus, ocjenu rizika, odobreni pristup, sigurnu metodu pohrane, pravilo rotacije, obuhvat praćenja i put ukidanja.

Zašto su neljudski identiteti postali novi problem privilegiranog pristupa

Neljudski identitet, odnosno NHI, svaki je digitalni identitet koji koristi softver, infrastruktura ili automatizirani proces, a ne osoba. U praksi uključuje servisne račune koje koriste aplikacije, API ključeve koje koriste SaaS integracije, OAuth tokene i tokene za osvježavanje koje koriste aplikacije trećih strana, SSH ključeve koje koristi automatizacija, TLS certifikate i privatne ključeve, CI/CD tajne vrijednosti, identitete radnih opterećenja u oblaku, nizove za povezivanje s bazama podataka, ugrađene vjerodajnice, račune RPA botova i integracijske vjerodajnice kojima upravljaju dobavljači.

Ti identiteti često imaju tri obilježja zbog kojih su revizori zabrinuti.

Prvo, dugotrajni su. Ljudski korisnik može rotirati vjerodajnice, promijeniti ulogu i napustiti organizaciju kroz formalni izlazni proces. API token izrađen tijekom termina izdavanja može ostati aktivan godinama jer nitko ne želi riskirati prekid produkcije.

Drugo, snažni su. Token za implementaciju može mijenjati infrastrukturu. Principal usluge u oblaku može izraditi pohranu. Račun baze podataka može izvesti evidencije klijenata. Ključ za potpisivanje može kompromitirati cjelovitost softverskog opskrbnog lanca.

Treće, teško im je pripisati odgovornost. Ljudski identiteti povezani su s HR zapisima. Neljudski identiteti često su povezani sa skriptama, cjevovodima, dobavljačima, zaboravljenim projektima ili nedokumentiranim integracijama.

Clarysecov Zenith Blueprint: revizorova mapa puta u 30 koraka Zenith Blueprint izravno ističe taj problem u fazi Kontrole u praksi, korak 22:

I ne zaboravite neljudske identitete. Revizije upravo tu često otkrivaju tihu izloženost. Prate li se API tokeni? Jesu li integracijski računi povezani s osobama ili plutaju u praznini? Kada je posljednji put rotiran niz za pristup bazi podataka ugrađen u skriptu staru desetljećima?

Upravljanje identitetom nije glamurozno, ali je strukturno. Bez njega je vaš ISMS samo skup zaključanih vrata, bez mogućnosti da sa sigurnošću znate tko drži ključeve.

U tome je poanta posljednje rečenice. Društvo može imati uređenu politiku kontrole pristupa, a ipak pasti na reviziji ako se strojnim identitetima ne upravlja. ISMS koji ne može objasniti tko je vlasnik tajne vrijednosti, zašto ona postoji i kada je posljednji put pregledana još ne djeluje kao kontrolirani sustav.

ISO/IEC 27001:2022 pretvara upravljanje tajnim vrijednostima u dokaze

ISO/IEC 27001:2022 učinkovit je jer upravljanje tajnim vrijednostima ne tretira kao izolirani inženjerski zadatak. Zahtijeva ISMS temeljen na riziku s definiranim opsegom, zahtjevima zainteresiranih strana, odgovornošću vodstva, procjenom rizika, obradom rizika, odabirom kontrola, Izjavom o primjenjivosti i kontinuiranim poboljšavanjem.

Za neljudske identitete organizacija ne bi trebala početi kupnjom alata. Trebala bi početi s opsegom i obvezama.

Prema točkama ISO/IEC 27001:2022 4.1 do 4.4, organizacija utvrđuje interna i vanjska pitanja, zainteresirane strane, pravne, regulatorne i ugovorne zahtjeve, sučelja i ovisnosti. U kontekstu NHI identiteta, opseg ISMS-a treba identificirati okruženja u oblaku, SaaS platforme, CI/CD sustave, produkcijske aplikacije, integracije s korisnicima, izvršitelje obrade podataka, pružatelje upravljanih usluga i kriptografske usluge u kojima postoje strojne vjerodajnice.

Točke 5.1 do 5.3 čine vodstvo odgovornim za politiku, resurse, uloge i izvješćivanje o uspješnosti. To je važno jer otklanjanje nedostataka NHI identiteta često stvara operativnu napetost. Rotacija vjerodajnice produkcijske baze podataka, zamjena naslijeđenog dijeljenog servisnog računa ili provedba injektiranja tajnih vrijednosti iz trezora može prekinuti krhke tijekove rada. Bez izvršnog sponzora, timovi odgađaju čišćenje.

Točke 6.1.1 do 6.1.3 i 6.2 daju upravljački mehanizam. Organizacija definira kriterije rizika, identificira rizike za povjerljivost, cjelovitost i dostupnost, dodjeljuje vlasnike rizika, vrednuje vjerojatnost i utjecaj, odabire opcije obrade, odabire kontrole, izrađuje Izjavu o primjenjivosti i prati mjerljive ciljeve.

U praktičnom smislu, plan obrade rizika za neljudske identitete treba odgovoriti na sljedeće:

• Koji sustavi i poslovne usluge ovise o NHI identitetima?
• Koje tajne vrijednosti mogu pristupiti osobnim podacima, reguliranim financijskim uslugama, produkcijskoj infrastrukturi ili kritičnim korisničkim uslugama?
• Koji su identiteti privilegirani, neaktivni, dijeljeni, pod upravljanjem dobavljača ili neupravljani?
• Koje kontrole smanjuju rizik, kao što su pohrana u trezor, rotacija, načelo najmanjih ovlasti, istek, upravljanje životnim ciklusom certifikata, CI/CD skeniranje, praćenje i hitni opoziv?
• Koji preostali rizici zahtijevaju poslovno odobrenje?

ISO/IEC 27002:2022 zatim daje katalog kontrola iz Priloga A. Najrelevantnije kontrole uključuju 5.9 Popis informacija i druge povezane imovine, 5.15 Kontrola pristupa, 5.16 Upravljanje identitetom, 5.17 Autentifikacijske informacije, 5.18 Prava pristupa, 5.19 Informacijska sigurnost u odnosima s dobavljačima, 5.20 Uređivanje informacijske sigurnosti u ugovorima s dobavljačima, 5.21 Upravljanje informacijskom sigurnošću u IKT opskrbnom lancu, 5.23 Informacijska sigurnost za korištenje usluga u oblaku, 5.24 Planiranje i priprema upravljanja incidentima, 5.28 Prikupljanje dokaza, 8.2 Prava privilegiranog pristupa, 8.3 Ograničenje pristupa informacijama, 8.5 Sigurna autentifikacija, 8.15 Zapisivanje događaja, 8.16 Aktivnosti praćenja, 8.24 Uporaba kriptografije, 8.25 Sigurni životni ciklus razvoja softvera, 8.26 Zahtjevi sigurnosti aplikacija, 8.28 Sigurno kodiranje i 8.31 Odvajanje razvojnih, testnih i produkcijskih okruženja.

Clarysecov Zenith Controls: vodič za višestruku usklađenost Zenith Controls mapira te odnose iz ISO/IEC 27002:2022 na način koji revizori i vlasnici kontrola mogu koristiti. Za kontrolu 5.16, Upravljanje identitetom, Zenith Controls objašnjava vezu između identiteta i vjerodajnica:

Upravljanje identitetom daje odgovor na pitanje tko, dok autentifikacijske informacije osiguravaju odgovor na pitanje kako, potvrđujući da je osoba koja tvrdi da ima određeni identitet legitimna. 5.16 uređuje upravljanje životnim ciklusom identiteta, dok 5.17 osigurava da su lozinke, tokeni, certifikati i druge vjerodajnice sigurno povezani s tim identitetima te pravilno upravljani radi podrške snažnoj autentifikaciji.

Taj je odnos ključan za NHI identitete. Token bez vlasnika identiteta nije prikladan za reviziju. Servisni račun bez pregleda pristupa ne ispunjava načelo najmanjih ovlasti. Certifikat bez statusa životnog ciklusa nije kontrolirana kriptografija. Integracijska vjerodajnica dobavljača bez ugovornih odredbi nije učinkovito upravljanje rizikom trećih strana.

Clarysecov obrazac kontrole: identitet, tajna vrijednost, privilegija, dokaz

Clarysec provodi upravljanje neljudskim identitetima i tajnim vrijednostima kroz ponovljiv obrazac kontrole. „Tajne vrijednosti” ne tretiramo samo kao DevOps pitanje niti „servisne račune” samo kao IAM pitanje. Povezujemo identitet, tajnu vrijednost, privilegiju i dokaz.

Sloj politike mjesto je na kojem to postaje provedivo.

Za mala i srednja društva Clarysecova Politika upravljanja korisničkim računima i privilegijama-sme Politika upravljanja korisničkim računima i privilegijama-sme navodi:

Servisni računi (koje koriste sustavi ili aplikacije) moraju biti dokumentirani, ograničeni na određene sustave i nikada se ne smiju koristiti za interaktivne prijave.

Time se sprječava klasični antiobrazac u kojem servisni račun postaje zajednička administratorska prijava. Revizoru se također daje jasan test: pokažite popis servisnih računa, pokažite ograničenje na sustav i pokažite da je interaktivna prijava onemogućena ili tehnički spriječena.

Clarysecova Politika upravljanja imovinom-sme Politika upravljanja imovinom-sme proširuje definiciju imovine tako da uključuje:

Digitalne vjerodajnice i usluge: nazivi domena, digitalni certifikati, API ključevi, računi e-pošte, prijave u oblak

To je važno jer mnoge organizacije popisuju samo poslužitelje, prijenosna računala i aplikacije. U 2026. API ključ može biti osjetljiviji od prijenosnog računala. Privatni ključ certifikata može biti produkcijska autentifikacijska imovina. Prijava u oblak koju koristi automatizacija može stvoriti izloženost reguliranih podataka. Tretiranje vjerodajnica kao imovine temelj je upravljanja tajnim vrijednostima spremnog za reviziju.

Za korporativna okruženja Clarysecova Politika upravljanja korisničkim računima i privilegijama Politika upravljanja korisničkim računima i privilegijama podiže zahtjeve za dokazima:

Organizacija mora održavati detaljan popis svih aktivnih i neaktivnih vjerodajnica, povlaštenih računa i servisnih računa na razini sustava. Taj se popis mora kontinuirano ažurirati i pregledavati tromjesečno.

Tromjesečni pregled mjesto je na kojem se otkrivaju mnogi nedostaci. Neaktivne vjerodajnice, napušteni principali usluga, stari integracijski korisnici, neupravljani računi dobavljača i hitni tokeni postaju vidljivi tek kada netko usporedi registar sa stvarnim IAM, trezorskim, CI/CD i zapisima iz oblaka.

Tajne vrijednosti su autentifikacijske informacije, a ne praktičnost za razvojne inženjere

Najopasnija fraza u upravljanju tajnim vrijednostima je „privremeni ključ”.

Privremeni ključevi postaju trajni. Testne vjerodajnice dospiju u produkciju. Izvorni kod otkriva tokene. Zapisi izrade izlažu lozinke. Timovi podrške dijele certifikate kroz prijave. Razvojni inženjeri kopiraju datoteke okruženja u chat. Ugovorni izvođač izradi principal usluge u oblaku i ode.

Zenith Blueprint, u fazi Kontrole u praksi, korak 22, široko opisuje autentifikacijske informacije:

Ova kontrola nije samo o lozinkama, iako su lozinke svakako dio slike. Riječ je o svakoj vjerodajnici koja se koristi za potvrđivanje identiteta: lozinkama, PIN-ovima, kriptografskim ključevima, biometrijskim predlošcima, pametnim karticama, tokenima, certifikatima, OAuth tokenima, SSH ključevima, API tajnim vrijednostima. To su ključevi kraljevstva, a Kontrola 5.17 osigurava da se s tim ključevima postupa s ozbiljnošću koju zaslužuju.

Budimo jasni: loše upravljanje autentifikacijom i dalje je jedan od glavnih temeljnih uzroka povreda. Slabe ili dijeljene lozinke. Tvrdo kodirane vjerodajnice u izvornom kodu. Nepromijenjene zadane prijave na administratorskim portalima. Certifikati s isteklim ili nepoznatim vlasništvom. U svakom od tih slučajeva nije zakazao identitet, nego je zakazala zaštita i upravljanje mehanizmom koji se koristi za dokazivanje tog identiteta.

Clarysecove politike to prevode u operativna pravila.

Politika kriptografskih kontrola-sme Politika kriptografskih kontrola-sme navodi:

Ključevi se ne smiju pohranjivati u otvorenom tekstu niti ugrađivati u izvorni kod, dokumente ili e-poštu

Politika sigurnog razvoja-sme Politika sigurnog razvoja-sme navodi:

Bez tvrdo kodiranih vjerodajnica ili tajnih vrijednosti u izvornom kodu

Za korporativne timove Politika sigurnog razvoja Politika sigurnog razvoja navodi:

Tajne vrijednosti ne smiju biti tvrdo kodirane niti pohranjene u otvorenom tekstu u repozitorijima.

A Politika zahtjeva sigurnosti aplikacija Politika zahtjeva sigurnosti aplikacija još je izravnija:

Pohrana lozinki ili kriptografskih ključeva u otvorenom tekstu strogo je zabranjena.

Te odredbe politika stvaraju jasan revizijski trag. Sigurnosni timovi mogu testirati repozitorije, CI/CD varijable, slike spremnika, konfiguracijska spremišta, sustave za praćenje zadataka, dokumentacijske platforme i zapise dnevnika prema izričitim zahtjevima. Također podupiru Article 32 GDPR-a o sigurnosti obrade jer izloženost tajnih vrijednosti može izravno dovesti do neovlaštenog pristupa osobnim podacima.

Korporativno upravljanje kriptografijom također zahtijeva vlasništvo. Clarysecova Politika kriptografskih kontrola Politika kriptografskih kontrola zahtijeva:

Mora se održavati centralizirani Registar upravljanja ključevima za evidentiranje svih kriptografskih ključeva, njihova statusa životnog ciklusa, dodijeljenih skrbnika i konteksta uporabe.

Za neljudske identitete taj registar treba povezati ključeve certifikata, ključeve za potpisivanje, API ključeve i ključeve kojima se upravlja u oblaku sa širim NHI registrom. Revizor bi trebao moći pratiti produkcijski certifikat od poslovne usluge, preko vlasnika, skrbnika, isteka i dokaza rotacije, do postupka odgovora na incidente.

NIS2, DORA i GDPR: jedan model dokaza, više regulatora

Upravljanje neljudskim identitetima problem je višestruke usklađenosti jer isti propust može aktivirati više obveza.

Procurjeli API token kod pružatelja SaaS usluga može uzrokovati prekid usluge prema NIS2, izloženost osobnih podataka prema GDPR-u i ugovorno prijavljivanje incidenata financijskim korisnicima prema očekivanjima DORA u području opskrbnog lanca. Kompromitirana CI/CD tajna vrijednost kod pružatelja IKT usluga može utjecati na otpornost korisnika, cjelovitost softvera i operativnu neprekidnost. Zaboravljeni integracijski račun dobavljača može omogućiti pristup reguliranim sustavima bez odgovarajuće dubinske analize dobavljača ili ugovornih kontrola.

NIS2 Article 21 zahtijeva odgovarajuće i razmjerne tehničke, operativne i organizacijske mjere. Minimalna područja uključuju analizu rizika, politike sigurnosti informacijskih sustava, postupanje s incidentima, neprekidnost poslovanja, sigurnost opskrbnog lanca, sigurnu nabavu, razvoj i održavanje, postupanje s ranjivostima, procjenu učinkovitosti, kibernetičku higijenu, kriptografiju, sigurnost ljudskih resursa, kontrolu pristupa i upravljanje imovinom te, prema potrebi, MFA ili kontinuiranu autentifikaciju. Neljudski identiteti protežu se gotovo kroz sva ta područja. NIS2 Article 23 također uvodi fazno prijavljivanje značajnih incidenata, uključujući rano upozorenje u roku od 24 sata, obavijest o incidentu u roku od 72 sata i završno izvješće najkasnije mjesec dana nakon obavijesti o incidentu.

DORA se primjenjuje od 17. siječnja 2025. i obuhvaća upravljanje IKT rizicima, prijavljivanje većih incidenata povezanih s IKT-om, testiranje operativne otpornosti, razmjenu informacija i rizik trećih strana u području IKT-a. Articles 5 i 6 zahtijevaju upravljanje, odgovornost upravljačkog tijela i dokumentirani okvir za upravljanje IKT rizicima. Article 8 zahtijeva identifikaciju poslovnih funkcija podržanih IKT-om, informacijske imovine i ovisnosti. Articles 17 do 19 zahtijevaju upravljanje incidentima, klasifikaciju i izvješćivanje. Articles 28 do 30 zahtijevaju upravljanje rizikom trećih strana u području IKT-a, ugovorne registre, dubinsku analizu dobavljača, sigurnosne standarde, prava na reviziju, podršku pri incidentima, kontrole podugovaranja i izlazne strategije.

GDPR se primjenjuje gdje god se osobni podaci obrađuju unutar njegova teritorijalnog opsega. Article 5 zahtijeva cjelovitost, povjerljivost i odgovornost. Article 32 zahtijeva odgovarajuće tehničke i organizacijske mjere za sigurnost obrade. Ako servisni račun ili API ključ može pristupiti osobnim podacima, neupravljane tajne vrijednosti postaju neuspjeh kontrole privatnosti, a ne samo IT problem.

Isti dokazi mogu poduprijeti certifikaciju prema ISO/IEC 27001:2022, nadzor prema NIS2, provjere prema DORA i odgovornost prema GDPR-u kada su pravilno strukturirani.

NIST CSF 2.0 može se koristiti kao komunikacijski sloj za iste dokaze. Njegova funkcija GOVERN obuhvaća očekivanja dionika, pravne i ugovorne obveze, apetit za rizik, odgovornost vodstva, politiku i nadzor. Njegovi operativni ishodi obuhvaćaju popise imovine, usluge koje pružaju dobavljači, upravljanje identitetima i vjerodajnicama, načelo najmanjih ovlasti, sigurnost podataka, zapisivanje događaja, praćenje, odgovor na incidente i oporavak.

COBIT 2019 i timovi za pružanje neovisnog uvjerenja u ISACA stilu obično će gledati upravljanje i sposobnost procesa. Pitat će je li odgovornost dodijeljena, jesu li kontrole ugrađene u operativne procese, jesu li iznimke odobrene, izvješćuju li se metrike upravi i pokazuju li dokazi ponovljivost, a ne jednokratno čišćenje.

Praktičan sprint za izradu registra neljudskih identiteta

Praktični Clarysec angažman često počinje usmjerenim sprintom, a ne šestomjesečnim programom uvođenja alata. Cilj je izraditi dokaziv NHI registar, rangiranje rizika i plan otklanjanja nedostataka koji se mogu uključiti u plan obrade rizika prema ISO/IEC 27001:2022 i Izjavu o primjenjivosti.

Počnite s jednom poslovnom uslugom, primjerice platformom za obračun korisnicima, aplikacijom za trgovanje, portalom za pacijente ili sustavom za upravljanje SaaS zakupcima. Uključite produkciju, pripremno okruženje, CI/CD, infrastrukturu u oblaku, alate za praćenje, baze podataka, SaaS integracije i usluge kojima upravljaju dobavljači.

Povežite to sa Zenith Blueprint, fazom Upravljanje rizicima, korak 14, u kojem Clarysec usklađuje politike obrade rizika s regulatornim unakrsnim referencama. U tom koraku kontrole sigurnog razvoja i cjevovoda uključuju zabranu tvrdo kodiranih tajnih vrijednosti, vršnjački pregled, automatiziranu statičku analizu, skeniranje ovisnosti, odvajanje razvoja, testiranja i produkcije, MFA za pristup cjevovodu, cjelovitost artefakata izrade i CI/CD zapisivanje događaja.

Prikupite identitete i tajne vrijednosti od pružatelja identiteta, IAM-a u oblaku, trezora tajnih vrijednosti, Kubernetesa, CI/CD varijabli, postavki repozitorija, korisnika baza podataka, SaaS administratorskih konzola, alata za upravljanje certifikatima i dokumentacije dobavljača.

Ocijenite rizik identiteta koji imaju pristup produkciji, privilegirana prava, pristup osobnim podacima, ovisnost kritične ili važne funkcije, kontrolu dobavljača, dugotrajne tokene, nemaju vlasnika, nemaju rotaciju, nemaju praćenje ili koriste tvrdo kodiranu pohranu. Upotrijebite kriterije rizika prema ISO/IEC 27001:2022 za ocjenu vjerojatnosti i utjecaja. Primijenite analizu kritične ili važne funkcije prema DORA gdje je primjenjivo. Uzmite u obzir učinak prema GDPR-u kada su dostupni osobni podaci. Uzmite u obzir utjecaj na uslugu prema NIS2 kada su mogući prekid ili šteta za korisnika.

Za svaki visokorizični NHI primijenite aktivnosti obrade rizika. Premjestite tajne vrijednosti iz izvornog koda, dokumenata i CI/CD varijabli u otvorenom tekstu u trezor ili upravljanu pohranu tajnih vrijednosti. Zamijenite dijeljene servisne račune jedinstvenim identitetima radnih opterećenja. Onemogućite interaktivnu prijavu za servisne račune. Primijenite načelo najmanjih ovlasti i vjerodajnice specifične za okruženje. Konfigurirajte rotaciju, istek i hitni opoziv. Povežite tajne vrijednosti s vlasnicima i skrbnicima. Dodajte zapisivanje događaja za autentifikaciju, uporabu tokena i osjetljive radnje. Dodajte upozorenja za anomalnu geografiju, neuobičajeno vrijeme, neuobičajen volumen ili pristup novom resursu. Ažurirajte ugovore s dobavljačima za postupanje s vjerodajnicama, podršku pri incidentima i prava na reviziju. Dokumentirajte iznimke s odobrenjem vlasnika rizika i datumom isteka.

Politika testnih podataka i testnih okruženja Politika testnih podataka i testnih okruženja podupire odvajanje okruženja:

Integracija s CI/CD cjevovodima mora provoditi odvajanje okruženja i autentifikacijskih vjerodajnica.

Ta je odredba često presudna. Ako razvoj, testiranje i produkcija dijele tajne vrijednosti, okruženje niskog rizika može postati put do povrede produkcije.

Sprint treba završiti paketom dokaza, a ne samo popisom nalaza. Uključite izvoz NHI registra, unose procjene rizika, plan obrade rizika, mapiranje Izjave o primjenjivosti, reference na politike, snimke zaslona trezora, zapise dnevnika rotacije, odobrenja pregleda pristupa, rezultate CI/CD skeniranja tajnih vrijednosti, definicije pravila praćenja, matricu odgovornosti za vjerodajnice dobavljača, operativne upute za incidente i iznimke s vlasnicima i datumima isteka.

Zapisivanje događaja i otkrivanje: dokaz da je uporaba strojnih identiteta vidljiva

Strojni identitet koji je dobro popisan, ali nevidljiv u zapisima dnevnika i dalje je opasan. Otkrivanje je dio kontrolne priče.

Clarysecova Politika zapisivanja događaja i praćenja-sme Politika zapisivanja događaja i praćenja-sme uključuje dokaze autentifikacije:

Zapisi dnevnika autentikacije: uspješni i neuspješni pokušaji prijave, trajanje sesije, uporaba MFA

Za NHI identitete prilagodite taj zahtjev strojnoj autentifikaciji. Možda nećete imati uporabu MFA za identitet radnog opterećenja, ali trebali biste imati događaje autentifikacije, uporabu tokena, uporabu certifikata, metapodatke API poziva, izvorno radno opterećenje, odredišnu uslugu, trajanje tokena, događaje neuspjeha i privilegirane radnje.

U Zenith Controls, ISO/IEC 27002:2022 kontrola 8.2, Prava privilegiranog pristupa, povezana je sa zapisivanjem događaja i praćenjem jer povlašteni računi zahtijevaju detaljne zapise i nadzor. Zenith Controls također povezuje 8.2 s upravljanjem identitetom, pravima pristupa, ograničenjem pristupa informacijama i sigurnom autentifikacijom. Za revizore to znači da privilegirane neljudske identitete treba pregledavati i pratiti s jednakom ozbiljnošću kao ljudske administratore, ponekad i većom.

Dobra pitanja za praćenje uključuju:

• Je li se servisni račun autentificirao iz neočekivanog radnog opterećenja ili IP raspona?
• Je li API ključ pristupio novoj krajnjoj točki ili skupu podataka?
• Je li certifikat korišten nakon zamjene?
• Je li CI/CD token implementirao izvan odobrenog cjevovoda?
• Je li račun samo za čitanje pokušao izvršiti operacije pisanja?
• Je li neaktivna vjerodajnica postala aktivna?
• Je li integracija dobavljača pristupila podacima izvan dogovorenih sati ili volumena?

Kada se pojavi upozorenje u 02:13, morate odgovoriti koji je identitet korišten, koja ga je tajna vrijednost autentificirala, koja su prava pristupa izvršena, koji su podaci ili sustavi bili zahvaćeni, je li aktivnost bila očekivana, koji je vlasnik može potvrditi i jesu li pragovi za prijavljivanje incidenata dosegnuti.

Revizorska perspektiva: isti proces, različita pitanja

Najjača revizijska pozicija nije „usklađeni smo sa svime”. Ona je „upravljamo jednim kontroliranim procesom koji proizvodi dokaze za više obveza”. Različiti revizori pregledavat će taj proces na različite načine.

U svim tim perspektivama ponavljajući nalazi su predvidljivi: ne postoji jedinstveni NHI popis, nema vlasnika za strojne identitete, tajne vrijednosti pohranjene su u kodu ili dokumentaciji, vjerodajnice se dijele između okruženja, nema rotacije ili isteka, vjerodajnice kojima upravljaju dobavljači izvan su pregleda pristupa, praćenje obuhvaća ljude, ali ne i strojeve, a operativne upute za incidente zanemaruju curenje tajnih vrijednosti.

Svaki nalaz prirodno se mapira na Clarysec kontrole, politike i predloške za otklanjanje nedostataka. Još važnije, svaki se može pretvoriti u mjerljive dokaze unutar ISMS-a.

Kako vam Clarysec pomaže postići spremnost za reviziju

Clarysecov pristup praktičan je jer polazi od dokaza koje će revizori tražiti i vraća se unatrag prema kontrolama, politikama i operativnim rutinama.

U Zenith Blueprint, fazi Kontrole u praksi, korak 19, Clarysec daje izravne smjernice za autentifikaciju između strojeva:

Za autentifikaciju između strojeva, kao što su servisni računi ili API pozivi, ključevi, certifikati i tokeni moraju se štititi jednako strogo. Izbjegavajte ugrađivanje vjerodajnica u kod. Koristite sustave za upravljanje tajnim vrijednostima ili trezore za njihovu sigurnu pohranu i rotaciju.

Tipičan Clarysecov tijek rada za neljudske identitete uključuje otkrivanje NHI identiteta u oblaku, SaaS-u, CI/CD-u, repozitorijima, trezorima i bazama podataka, procjenu nedostataka politika u odnosu na Clarysecove skupove politika za mala i srednja društva ili korporacije, procjenu rizika i mapiranje obrade prema ISO/IEC 27001:2022, ažuriranja Izjave o primjenjivosti, mapiranje dokaza za NIS2, DORA, GDPR i NIST CSF, dizajn NHI registra, usklađivanje Registra upravljanja ključevima, skeniranje tajnih vrijednosti, procese pregleda pristupa, matrice odgovornosti za vjerodajnice dobavljača, operativne upute za incidente i revizijske pakete sa snimkama zaslona, izvozima, zapisima dnevnika, odobrenjima i zapisima o iznimkama.

Za mala i srednja društva pristup je razmjeran. Pružatelj SaaS usluga sa 70 osoba ne treba isti opseg alata kao globalna banka, ali treba vlasništvo, politiku, obradu rizika i dokaze. Za regulirane financijske subjekte i pružatelje IKT usluga isti se model skalira na mapiranje kritičnih funkcija prema DORA, upravljanje rizikom trećih strana i testiranje otpornosti.

Ako je vaša sljedeća revizija u 2026., nemojte čekati da revizor umjesto vas otkrije neljudske identitete. Počnite s jednom kritičnom uslugom i postavite pet pitanja:

1. Znamo li svaki servisni račun, API ključ, token, certifikat i CI/CD tajnu vrijednost koju ta usluga koristi?
2. Ima li svaki NHI imenovanog vlasnika, skrbnika, svrhu i ocjenu rizika?
3. Jesu li tajne vrijednosti pohranjene u trezor, rotirane i zaštićene od izvornog koda, dokumenata, e-pošte i pohrane u otvorenom tekstu?
4. Jesu li privilegirani strojni identiteti pregledavani, praćeni i ograničeni od interaktivne uporabe?
5. Možemo li iz jednog kontroliranog procesa proizvesti dokaze za ISO/IEC 27001:2022, NIS2, DORA i GDPR?

Koristite Zenith Blueprint: revizorova mapa puta u 30 koraka Zenith Blueprint za strukturiranje svojeg puta implementacije ISMS-a. Koristite Zenith Controls: vodič za višestruku usklađenost Zenith Controls za povezivanje kontrola ISO/IEC 27002:2022 za identitet, autentifikaciju, privilegije, zapisivanje događaja, kriptografiju, siguran razvoj i dobavljače s regulatornim dokazima. Koristite Clarysecovu biblioteku politika za mala i srednja društva i korporacije, uključujući Politiku upravljanja korisničkim računima i privilegijama-sme Politika upravljanja korisničkim računima i privilegijama-sme, Politiku kriptografskih kontrola Politika kriptografskih kontrola, Politiku sigurnog razvoja Politika sigurnog razvoja i Politiku zahtjeva sigurnosti aplikacija Politika zahtjeva sigurnosti aplikacija, kako biste dobre namjere pretvorili u provedive zahtjeve.

Upozorenje u 02:13 negdje će se dogoditi. Pitanje je može li vaša organizacija dokazima odgovoriti tko je držao ključ, što je taj ključ otvarao, zašto je postojao i koliko ga brzo možete učiniti sigurnim.