Necilvēku identitāšu noslēpumu pārvaldība 2026. gada auditiem

02:13 brīdinājums, kuru neviens nevarēja piesaistīt atbildīgajam

Otrdienas rītā plkst. 02:13 iedegas drošības operāciju kanāls. No iekšēja automatizācijas konta ir sākta ražošanas datubāzes eksportēšana. Piekļuves ceļš ir leģitīms. Marķieris ir derīgs. Avota IP adrese pieder mākoņvides izpildes videi, ko izmanto inženierijas komanda. Ļaunatūra nav redzama. Ziņojuma par pikšķerēšanu nav.

Galvenais informācijas drošības vadītājs uzdod pirmo acīmredzamo jautājumu: “Kam pieder šī identitāte?”

Klusums.

DevOps vadītājs atceras, ka marķieris tika izveidots klienta migrācijas laikā pirms diviem gadiem. Platformas komanda saka, ka to, iespējams, izmanto norēķinu integrācija. Datubāzes administrators norāda, ka tam ir lasīšanas piekļuve, jo tās noņemšana reiz pārtrauca nakts uzdevumu. Juridiskais dienests jautā, vai bija iesaistīti personas dati. Atbilstības funkcija jautā, vai tas ir ziņojams incidents saskaņā ar NIS2, DORA vai GDPR. Auditors pieprasa pierādījumus, ka servisa konti, API atslēgas, sertifikāti un CI/CD noslēpumi ir iekļauti uzskaitē, pārskatīti, rotēti, uzraudzīti un atsaukti.

Līdz plkst. 09:00 audita konstatējuma projekts jau ir skaidri iezīmējies. Aizmirstā mikropakalpojumā tika atrasta cieti iekodēta, nerotēta API atslēga. Tā piešķir plašu piekļuvi ražošanas klientu darījumu datubāzei. Izstrādātājs, kas to izveidoja, aizgāja pirms diviem gadiem. Sistēmai nav vārdā nosaukta īpašnieka, dokumentēta mērķa, rotācijas ieraksta un uzraudzības noteikuma.

Tā ir necilvēku identitāšu problēma 2026. gadā.

Vairums organizāciju ir uzlabojušas cilvēku piekļuves kontroli. Tām ir MFA, darbinieku pieņemšanas, pārcelšanas un atbrīvošanas darbplūsmas, priviliģētās piekļuves pārskatīšana un identitātes nodrošinātāju žurnāli. Taču mašīnidentitāšu skaits ir pieaudzis straujāk nekā to pārvaldība. Servisa konti, darbslodzes identitātes, API atslēgas, OAuth marķieri, SSH atslēgas, sertifikāti, Kubernetes noslēpumi, SaaS integrāciju marķieri, robotizētas procesu automatizācijas konti un CI/CD izvietošanas akreditācijas dati tagad veic kritiskas biznesa darbības, nebūdami “lietotāji” cilvēku izpratnē.

SaaS sniedzējiem, finanšu tehnoloģiju uzņēmumiem, pārvaldīto pakalpojumu sniedzējiem (MSP), mākoņoperatoriem un datu ietilpīgiem SME nepārvaldītas necilvēku identitātes vairs nav tikai tehniskās higiēnas jautājums. Tas ir valdes līmeņa noturības un atbilstības risks. NIS2 piekļuves kontroli, aktīvu pārvaldību, piegādes ķēdes drošību, incidentu apstrādi un kiberdrošības higiēnu uzskata par kiberdrošības risku pārvaldības pamatpasākumiem. DORA finanšu iestādēs IKT risku, darbības noturību, incidentu ziņošanu un IKT trešo pušu risku pakļauj vadības struktūras pārskatatbildībai. GDPR prasa pārziņiem un apstrādātājiem aizsargāt personas datus un pierādīt pārskatatbildību.

Sarežģītākais nav pierādīt, ka noslēpumi pastāv. Sarežģītākais ir pierādīt, ka katrai necilvēku identitātei ir īpašnieks, mērķis, dzīves cikls, riska vērtējums, apstiprināta piekļuve, droša glabāšanas metode, rotācijas noteikums, uzraudzības pārklājums un atsaukšanas ceļš.

Kāpēc necilvēku identitātes kļuva par jauno priviliģētās piekļuves problēmu

Necilvēku identitāte jeb NHI ir jebkura digitāla identitāte, ko personas vietā izmanto programmatūra, infrastruktūra vai automatizēti procesi. Praktiski tā ietver servisa kontus, ko izmanto lietojumprogrammas, API atslēgas SaaS integrācijām, OAuth un atsvaidzināšanas marķierus trešo pušu lietotnēm, SSH atslēgas automatizācijai, TLS sertifikātus un privātās atslēgas, CI/CD noslēpumus, mākoņdarbslodžu identitātes, datubāzu savienojuma virknes, iegultus akreditācijas datus, RPA robotu kontus un piegādātāju pārvaldītus integrāciju akreditācijas datus.

Šīm identitātēm bieži ir trīs īpašības, kas auditorus dara piesardzīgus.

Pirmkārt, tās ir ilgdzīvojošas. Cilvēks kā lietotājs var rotēt akreditācijas datus, mainīt lomas un aiziet no organizācijas formālā darba attiecību izbeigšanas procesā. API marķieris, kas izveidots laidiena loga laikā, var palikt aktīvs gadiem, jo neviens nevēlas riskēt pārtraukt ražošanu.

Otrkārt, tās ir jaudīgas. Izvietošanas marķieris var mainīt infrastruktūru. Mākoņpakalpojuma princips var izveidot krātuves. Datubāzes konts var eksportēt klientu ierakstus. Parakstīšanas atslēga var kompromitēt programmatūras piegādes ķēdes integritāti.

Treškārt, tās ir vāji piesaistāmas atbildīgajam. Cilvēku identitātes ir sasaistītas ar personālvadības ierakstiem. Necilvēku identitātes bieži ir sasaistītas ar skriptiem, konveijeriem, piegādātājiem, aizmirstiem projektiem vai nedokumentētām integrācijām.

Clarysec Zenith Blueprint: auditora 30 soļu ceļvedis Zenith Blueprint to tieši uzsver posmā “Kontroles pasākumi darbībā”, 22. solī:

Un neaizmirstiet necilvēku identitātes. Tieši šeit auditi bieži atklāj klusu pakļautību riskam. Vai API marķieri tiek izsekoti? Vai integrāciju konti ir piesaistīti cilvēkiem vai peld nekurienē? Kad pēdējo reizi tika rotēta datubāzes piekļuves virkne, kas iegulta vairākus desmitus gadu vecā skriptā?

Identitātes pārvaldība nav spoža tēma, taču tā ir strukturāla. Bez tās jūsu ISMS ir tikai aizslēgtu durvju kopums bez iespējas pārliecināties, kam ir atslēgas.

Pēdējais teikums ir būtība. Uzņēmumam var būt noslīpēta piekļuves kontroles politika, un tas joprojām var neizturēt auditu, ja mašīnidentitātes nav pārvaldītas. ISMS, kas nespēj izskaidrot, kam pieder noslēpums, kāpēc tas pastāv un kad tas pēdējo reizi pārskatīts, vēl nedarbojas kā kontrolēta sistēma.

ISO/IEC 27001:2022 pārvērš noslēpumu pārvaldību pierādījumos

ISO/IEC 27001:2022 ir efektīvs, jo tas neuztver noslēpumu pārvaldību kā izolētu inženierijas uzdevumu. Tas prasa uz risku balstītu ISMS ar definētu piemērošanas jomu, ieinteresēto pušu prasībām, vadības pārskatatbildību, risku izvērtēšanu, riska apstrādi, kontroles pasākumu atlasi, piemērojamības deklarāciju (SoA) un nepārtrauktu uzlabošanu.

Attiecībā uz necilvēku identitātēm organizācijai nevajadzētu sākt ar rīka iegādi. Jāsāk ar piemērošanas jomu un pienākumiem.

Saskaņā ar ISO/IEC 27001:2022 punktiem 4.1 līdz 4.4 organizācija nosaka iekšējos un ārējos jautājumus, ieinteresētās puses, tiesiskās, regulatīvās un līgumiskās prasības, saskarnes un atkarības. NHI kontekstā ISMS darbības jomai jāidentificē mākoņvides, SaaS platformas, CI/CD sistēmas, ražošanas lietojumprogrammas, klientu integrācijas, datu apstrādātāji, pārvaldīto pakalpojumu sniedzēji un kriptogrāfiskie pakalpojumi, kuros pastāv mašīnu akreditācijas dati.

Punkti 5.1 līdz 5.3 nosaka vadības atbildību par politiku, resursiem, lomām un veiktspējas ziņošanu. Tas ir būtiski, jo NHI trūkumu novēršana bieži rada operatīvu spriedzi. Ražošanas datubāzes akreditācijas datu rotēšana, mantota koplietota servisa konta aizstāšana vai uz glabātavām balstītas noslēpumu ievades piemērošana var pārtraukt trauslas darbplūsmas. Bez izpildvadības sponsora komandas atliek sakārtošanu.

Punkti 6.1.1 līdz 6.1.3 un 6.2 nodrošina kontroles mehānismu. Organizācija definē riska kritērijus, identificē konfidencialitātes, integritātes un pieejamības riskus, piešķir riska īpašniekus, izvērtē iespējamību un ietekmi, izvēlas apstrādes iespējas, atlasa kontroles pasākumus, sagatavo piemērojamības deklarāciju (SoA) un uzrauga izmērāmus mērķus.

Praktiski necilvēku identitāšu riska apstrādes plānam jāatbild uz šādiem jautājumiem:

• Kuras sistēmas un biznesa pakalpojumi ir atkarīgi no NHI?
• Kuri noslēpumi var piekļūt personas datiem, reglamentētiem finanšu pakalpojumiem, ražošanas infrastruktūrai vai kritiskiem klientu pakalpojumiem?
• Kuras identitātes ir priviliģētas, neaktīvas, koplietotas, piegādātāju pārvaldītas vai nepārvaldītas?
• Kuri kontroles pasākumi samazina risku, piemēram, glabāšana seifā, rotācija, minimāli nepieciešamās tiesības, derīguma termiņš, sertifikātu dzīves cikla pārvaldība, CI/CD skenēšana, uzraudzība un ārkārtas atsaukšana?
• Kuriem atlikušajiem riskiem nepieciešams biznesa apstiprinājums?

ISO/IEC 27002:2022 tālāk nodrošina Annex A kontroles katalogu. Būtiskākie kontroles pasākumi ietver 5.9 Informācijas un citu saistīto aktīvu uzskaite, 5.15 Piekļuves kontrole, 5.16 Identitātes pārvaldība, 5.17 Autentifikācijas informācija, 5.18 Piekļuves tiesības, 5.19 Informācijas drošība attiecībās ar piegādātājiem, 5.20 Informācijas drošības iekļaušana piegādātāju līgumos, 5.21 Informācijas drošības pārvaldība IKT piegādes ķēdē, 5.23 Informācijas drošība mākoņpakalpojumu izmantošanā, 5.24 Incidentu pārvaldības plānošana un sagatavošanās, 5.28 Pierādījumu vākšana, 8.2 Priviliģētās piekļuves tiesības, 8.3 Informācijas piekļuves ierobežošana, 8.5 Droša autentifikācija, 8.15 Žurnālfiksēšana, 8.16 Uzraudzības darbības, 8.24 Kriptogrāfijas izmantošana, 8.25 Drošs izstrādes dzīves cikls, 8.26 Lietojumprogrammu drošības prasības, 8.28 Droša kodēšana un 8.31 Izstrādes, testēšanas un ražošanas vides nodalīšana.

Clarysec Zenith Controls: starpatbilstības ceļvedis Zenith Controls šīs ISO/IEC 27002:2022 attiecības kartē auditoriem un kontroles pasākumu īpašniekiem praktiski izmantojamā veidā. Par kontroles pasākumu 5.16 Identitātes pārvaldība Zenith Controls skaidro saikni starp identitāti un akreditācijas datiem:

Identitātes pārvaldība nosaka “kas”, savukārt autentifikācijas informācija nodrošina “kā”, pārbaudot, ka persona, kas apgalvo identitāti, ir leģitīma. 5.16 pārvalda identitātes dzīves cikla pārvaldību, savukārt 5.17 nodrošina, ka paroles, marķieri, sertifikāti un citi akreditācijas dati ir droši piesaistīti šīm identitātēm un atbilstoši pārvaldīti, lai atbalstītu spēcīgu autentifikāciju.

Šī saikne NHI ir būtiska. Marķieris bez identitātes īpašnieka nav auditējams. Servisa konts bez piekļuves tiesību pārskatīšanas neatbilst minimāli nepieciešamo tiesību principam. Sertifikāts bez dzīves cikla statusa nav kontrolēta kriptogrāfija. Piegādātāja integrācijas akreditācijas dati bez līguma noteikumiem nav efektīva trešo pušu risku pārvaldība.

Clarysec kontroles modelis: identitāte, noslēpums, privilēģija, pierādījumi

Clarysec necilvēku identitāšu un noslēpumu pārvaldību ievieš ar atkārtojamu kontroles modeli. Mēs neuzskatām “noslēpumus” tikai par DevOps jautājumu vai “servisa kontus” tikai par IAM jautājumu. Mēs sasaistām identitāti, noslēpumu, privilēģiju un pierādījumus.

Politikas slānis ir vieta, kur tas kļūst piemērojams.

SME vajadzībām Clarysec Lietotāju kontu un privilēģiju pārvaldības politika SME Lietotāju kontu un privilēģiju pārvaldības politika SME nosaka:

Servisa kontiem (kurus izmanto sistēmas vai lietojumprogrammas) jābūt dokumentētiem, ierobežotiem konkrētām sistēmām, un tos nekad nedrīkst izmantot interaktīvai pieteikšanās darbībai.

Tas novērš klasisku antipatternu, kur servisa konts kļūst par koplietotu administratora pieteikšanos. Tas auditoram arī dod skaidru pārbaudi: parādīt servisa kontu uzskaiti, parādīt sistēmas ierobežojumu un parādīt, ka interaktīvā pieteikšanās ir atspējota vai tehniski novērsta.

Clarysec Aktīvu pārvaldības politika SME Aktīvu pārvaldības politika SME paplašina aktīvu definīciju, iekļaujot:

Digitālie akreditācijas dati un pakalpojumi: domēna vārdi, digitālie sertifikāti, API atslēgas, e-pasta konti, mākoņvides pieteikšanās dati

Tas ir būtiski, jo daudzas organizācijas uzskaita tikai serverus, klēpjdatorus un lietojumprogrammas. 2026. gadā API atslēga var būt sensitīvāka nekā klēpjdators. Sertifikāta privātā atslēga var būt ražošanas autentifikācijas aktīvs. Automatizācijas izmantota mākoņvides pieteikšanās var radīt reglamentētu datu ekspozīciju. Akreditācijas datu uzskatīšana par aktīviem ir auditam gatavas noslēpumu pārvaldības pamats.

Uzņēmuma vidēm Clarysec Lietotāju kontu un privilēģiju pārvaldības politika Lietotāju kontu un privilēģiju pārvaldības politika paaugstina pierādījumu latiņu:

Organizācijai jāuztur detalizēta visu aktīvo un neaktīvo akreditācijas datu, priviliģēto kontu un sistēmas līmeņa servisa kontu uzskaite. Šī uzskaite ir nepārtraukti jāatjaunina un jāizskata reizi ceturksnī.

Ceturkšņa pārskatīšanā parādās daudzi trūkumi. Neaktīvi akreditācijas dati, bezsaimnieka servisa principi, veci integrāciju lietotāji, nepārvaldīti piegādātāju konti un ārkārtas marķieri kļūst redzami tikai tad, kad kāds salīdzina reģistru ar faktiskajiem IAM, seifu, CI/CD un mākoņvides ierakstiem.

Noslēpumi ir autentifikācijas informācija, nevis izstrādātāju ērtība

Bīstamākā frāze noslēpumu pārvaldībā ir “pagaidu atslēga”.

Pagaidu atslēgas kļūst pastāvīgas. Testa akreditācijas dati nonāk ražošanā. Pirmkods atklāj marķierus. Būvēšanas žurnāli atklāj paroles. Atbalsta komandas koplieto sertifikātus pieteikumos. Izstrādātāji kopē vides datnes tērzētavās. Līgumslēdzējs izveido mākoņpakalpojuma principu un aiziet.

Zenith Blueprint posmā “Kontroles pasākumi darbībā”, 22. solī, autentifikācijas informāciju apraksta plaši:

Šis kontroles pasākums nav tikai par parolēm, lai gan paroles noteikti ir daļa no kopainas. Tas attiecas uz visiem akreditācijas datiem, ko izmanto identitātes apliecināšanai: parolēm, PIN kodiem, kriptogrāfiskajām atslēgām, biometriskajām veidnēm, viedkartēm, marķieriem, sertifikātiem, OAuth marķieriem, SSH atslēgām, API noslēpumiem. Tās ir karaļvalsts atslēgas, un kontroles pasākums 5.17 nodrošina, ka šīs atslēgas tiek uztvertas ar pienācīgu nopietnību.

Būsim skaidri: vāja autentifikācijas pārvaldība joprojām ir viens no biežākajiem pārkāpumu pamatcēloņiem. Vājas vai koplietotas paroles. Cieti iekodēti akreditācijas dati pirmkodā. Nemainītas noklusējuma pieteikšanās administratīvajos portālos. Sertifikāti ar beigušos derīguma termiņu vai nezināmu īpašnieku. Katrā no šiem gadījumiem neizgāzās identitāte; izgāzās spēja aizsargāt un pārvaldīt mehānismu, ko izmanto šīs identitātes pierādīšanai.

Clarysec politikas to pārvērš operatīvos noteikumos.

Kriptogrāfisko kontroles pasākumu politika SME Kriptogrāfisko kontroles pasākumu politika SME nosaka:

Atslēgas nedrīkst glabāt atklātā tekstā vai iegult pirmkodā, dokumentos vai e-pastos

Drošas izstrādes politika SME Drošas izstrādes politika SME nosaka:

Pirmkodā nedrīkst būt cieti iekodētu akreditācijas datu vai noslēpumu

Uzņēmumu komandām Drošas izstrādes politika Drošas izstrādes politika nosaka:

Noslēpumus nedrīkst cieti iekodēt vai glabāt repozitorijos atklātā tekstā.

Un Lietojumprogrammu drošības prasību politika Lietojumprogrammu drošības prasību politika ir vēl tiešāka:

Paroļu vai kriptogrāfisko atslēgu glabāšana atklātā tekstā ir stingri aizliegta.

Šīs politikas klauzulas rada skaidru audita pēdu. Drošības komandas var pārbaudīt repozitorijus, CI/CD mainīgos, konteineru attēlus, konfigurāciju krātuves, problēmu izsekošanas rīkus, dokumentācijas platformas un žurnālus pret skaidri noteiktām prasībām. Tās arī atbalsta GDPR Article 32 apstrādes drošību, jo noslēpumu ekspozīcija var tieši novest pie nesankcionētas piekļuves personas datiem.

Uzņēmuma līmeņa kriptogrāfiskajai pārvaldībai nepieciešama arī īpašumtiesību noteikšana. Clarysec Kriptogrāfisko kontroles pasākumu politika Kriptogrāfisko kontroles pasākumu politika prasa:

Jāuztur centralizēts atslēgu pārvaldības reģistrs, lai reģistrētu visas kriptogrāfiskās atslēgas, to dzīves cikla statusu, piešķirtos glabātājus un lietošanas kontekstus.

Necilvēku identitāšu gadījumā šim reģistram jāsasaista sertifikātu atslēgas, parakstīšanas atslēgas, API atslēgas un mākoņvidē pārvaldītās atslēgas ar plašāku NHI reģistru. Auditoram jāspēj izsekot ražošanas sertifikātu no biznesa pakalpojuma līdz īpašniekam, glabātājam, derīguma termiņam, rotācijas pierādījumiem un incidentu reaģēšanas procedūrai.

NIS2, DORA un GDPR: viens pierādījumu modelis, daudzi regulatori

Necilvēku identitāšu pārvaldība ir starpatbilstības problēma, jo viena un tā pati kļūme var izraisīt vairākus pienākumus.

Nopludināts API marķieris SaaS sniedzējam var izraisīt pakalpojuma darbības traucējumus saskaņā ar NIS2, personas datu ekspozīciju saskaņā ar GDPR un līgumisku incidentu ziņošanu finanšu klientiem DORA piegādes ķēdes prasību kontekstā. Kompromitēts CI/CD noslēpums pie IKT pakalpojumu sniedzēja var ietekmēt klientu noturību, programmatūras integritāti un darbības nepārtrauktību. Aizmirsts piegādātāja integrācijas konts var radīt piekļuvi reglamentētām sistēmām bez pienācīgas sākotnējās izpētes vai līguma kontroles pasākumiem.

NIS2 Article 21 prasa atbilstošus un samērīgus tehniskus, operatīvus un organizatoriskus pasākumus. Minimālās jomas ietver riska analīzi, informācijas sistēmu drošības politikas, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu iegādi, izstrādi un uzturēšanu, ievainojamību apstrādi, efektivitātes novērtēšanu, kiberdrošības higiēnu, kriptogrāfiju, personāla drošību, piekļuves kontroli un aktīvu pārvaldību, kā arī, kur piemērojams, MFA vai nepārtrauktu autentifikāciju. Necilvēku identitātes atrodas gandrīz visās šajās jomās. NIS2 Article 23 arī nosaka pakāpenisku ziņošanu par būtiskiem incidentiem, tostarp agrīnu brīdinājumu 24 stundu laikā, incidenta paziņojumu 72 stundu laikā un gala ziņojumu ne vēlāk kā vienu mēnesi pēc incidenta paziņojuma.

DORA ir piemērojama no 2025. gada 17. janvāra un aptver IKT risku pārvaldību, būtisku ar IKT saistītu incidentu ziņošanu, darbības noturības testēšanu, informācijas apmaiņu un IKT trešo pušu risku. Articles 5 un 6 prasa pārvaldību, vadības struktūras pārskatatbildību un dokumentētu IKT risku pārvaldības ietvaru. Article 8 prasa identificēt ar IKT atbalstītās biznesa funkcijas, informācijas aktīvus un atkarības. Articles 17 līdz 19 prasa incidentu pārvaldību, klasifikāciju un ziņošanu. Articles 28 līdz 30 prasa IKT trešo pušu risku pārvaldību, līgumu reģistrus, sākotnējo izpēti, drošības standartus, audita tiesības, incidentu atbalstu, apakšuzņēmēju kontroles pasākumus un izstāšanās stratēģijas.

GDPR piemērojams visur, kur personas dati tiek apstrādāti tā teritoriālajā darbības jomā. Article 5 prasa integritāti, konfidencialitāti un pārskatatbildību. Article 32 prasa atbilstošus tehniskus un organizatoriskus pasākumus apstrādes drošībai. Ja servisa konts vai API atslēga var piekļūt personas datiem, nepārvaldīti noslēpumi kļūst par privātuma kontroles kļūmi, ne tikai IT jautājumu.

Tie paši pierādījumi var atbalstīt ISO/IEC 27001:2022 sertifikāciju, NIS2 uzraudzību, DORA pārbaudes un GDPR pārskatatbildību, ja tie ir strukturēti pareizi.

NIST CSF 2.0 var izmantot kā komunikācijas slāni tiem pašiem pierādījumiem. Tā GOVERN funkcija aptver iesaistīto pušu gaidas, juridiskos un līgumiskos pienākumus, riska apetīti, vadības pārskatatbildību, politiku un pārraudzību. Operatīvie rezultāti aptver aktīvu uzskaiti, piegādātāju sniegtos pakalpojumus, identitātes un akreditācijas datu pārvaldību, minimāli nepieciešamās tiesības, datu drošību, žurnālfiksēšanu, uzraudzību, incidentu reaģēšanu un atjaunošanu.

COBIT 2019 un ISACA tipa apliecinājuma komandas parasti skatīsies uz pārvaldību un procesu spēju. Tās jautās, vai atbildība ir piešķirta, vai kontroles pasākumi ir iestrādāti operatīvajos procesos, vai izņēmumi ir apstiprināti, vai metrikas tiek ziņotas vadībai un vai pierādījumi demonstrē atkārtojamību, nevis vienreizēju sakārtošanu.

Praktisks sprints necilvēku identitāšu reģistra izveidei

Praktiska Clarysec iesaiste bieži sākas ar fokusētu sprintu, nevis sešu mēnešu rīku programmu. Mērķis ir sagatavot aizstāvamu NHI reģistru, risku ranžējumu un trūkumu novēršanas plānu, ko var iekļaut ISO/IEC 27001:2022 riska apstrādes plānā un piemērojamības deklarācijā (SoA).

Sāciet ar vienu biznesa pakalpojumu, piemēram, klientu norēķinu platformu, tirdzniecības lietojumprogrammu, pacientu portālu vai SaaS nomnieku pārvaldības sistēmu. Iekļaujiet ražošanas vidi, sagatavošanas vidi, CI/CD, mākoņinfrastruktūru, uzraudzības rīkus, datubāzes, SaaS integrācijas un piegādātāju pārvaldītus pakalpojumus.

Sasaistiet to ar Zenith Blueprint riska pārvaldības posma 14. soli, kur Clarysec saskaņo riska apstrādes politikas ar regulatīvajām krusteniskajām atsaucēm. Šajā solī drošas izstrādes un konveijeru kontroles pasākumi ietver cieti iekodētu noslēpumu nepieļaušanu, koda līdzinieku pārskatīšanu, automatizētu statisko analīzi, atkarību skenēšanu, izstrādes, testēšanas un ražošanas nodalīšanu, MFA piekļuvei konveijeriem, būvēšanas artefaktu integritāti un CI/CD žurnālfiksēšanu.

Apkopojiet identitātes un noslēpumus no identitātes nodrošinātāja, mākoņvides IAM, noslēpumu seifa, Kubernetes, CI/CD mainīgajiem, repozitoriju iestatījumiem, datubāzu lietotājiem, SaaS administratīvajām konsolēm, sertifikātu pārvaldības rīkiem un piegādātāju dokumentācijas.

Novērtējiet risku identitātēm, kurām ir pieeja ražošanas videi, priviliģētas tiesības, piekļuve personas datiem, atkarība no kritiskas vai svarīgas funkcijas, piegādātāja kontrole, ilgdzīvojoši marķieri, nav īpašnieka, nav rotācijas, nav uzraudzības vai ir cieti iekodēta glabāšana. Izmantojiet ISO/IEC 27001:2022 riska kritērijus, lai vērtētu iespējamību un ietekmi. Kur piemērojams, izmantojiet DORA kritisko vai svarīgo funkciju analīzi. Kur pieejami personas dati, izmantojiet GDPR ietekmes apsvērumus. Kur iespējami pakalpojuma darbības traucējumi vai kaitējums klientam, izmantojiet NIS2 pakalpojuma ietekmi.

Katrai augsta riska NHI piemērojiet riska apstrādes darbības. Pārvietojiet noslēpumus no pirmkoda, dokumentiem un CI/CD atklāta teksta mainīgajiem uz seifu vai pārvaldītu noslēpumu glabātuvi. Aizstājiet koplietotus servisa kontus ar unikālām darbslodzes identitātēm. Atspējojiet servisa kontiem interaktīvo pieteikšanos. Piemērojiet minimāli nepieciešamās tiesības un videi specifiskus akreditācijas datus. Konfigurējiet rotāciju, derīguma termiņu un ārkārtas atsaukšanu. Piesaistiet noslēpumus īpašniekiem un glabātājiem. Pievienojiet autentifikācijas, marķieru izmantošanas un sensitīvu darbību žurnālfiksēšanu. Pievienojiet brīdināšanu par anomālu ģeogrāfiju, neparastu laiku, neparastu apjomu vai piekļuvi jauniem resursiem. Atjauniniet piegādātāju līgumus attiecībā uz rīcību ar akreditācijas datiem, incidentu atbalstu un audita tiesībām. Dokumentējiet izņēmumus ar riska īpašnieka apstiprinājumu un beigu datumu.

Testa datu un testa vides politika Testa datu un testa vides politika atbalsta vides nodalīšanu:

Integrācijai ar CI/CD konveijeriem jāpiemēro vides un autentifikācijas akreditācijas datu nodalīšana.

Šī klauzula bieži ir izšķiroša. Ja izstrāde, testēšana un ražošana koplieto noslēpumus, zema riska vide var kļūt par ceļu uz ražošanas pārkāpumu.

Sprintam jābeidzas ar pierādījumu paketi, ne tikai konstatējumu sarakstu. Iekļaujiet NHI reģistra eksportu, risku izvērtēšanas ierakstus, riska apstrādes plānu, piemērojamības deklarācijas (SoA) kartējumu, politiku atsauces, seifa ekrānuzņēmumus, rotācijas žurnālus, piekļuves tiesību pārskatīšanas apstiprinājumus, CI/CD noslēpumu skenēšanas rezultātus, uzraudzības noteikumu definīcijas, piegādātāju akreditācijas datu atbildības matricu, incidentu rokasgrāmatu un izņēmumus ar īpašniekiem un beigu datumiem.

Žurnālfiksēšana un atklāšana: pierādīt, ka mašīnidentitāšu izmantošana ir redzama

Mašīnidentitāte, kas ir labi iekļauta uzskaitē, bet nav redzama žurnālos, joprojām ir bīstama. Atklāšana ir daļa no kontroles stāsta.

Clarysec Žurnālfiksēšanas un uzraudzības politika SME Žurnālfiksēšanas un uzraudzības politika SME ietver autentifikācijas pierādījumus:

Autentifikācijas žurnāli: veiksmīgi un neveiksmīgi pieteikšanās mēģinājumi, sesijas ilgums, MFA izmantošana

NHI vajadzībām pielāgojiet šo prasību mašīnu autentifikācijai. Darbslodzes identitātei var nebūt MFA izmantošanas, taču jābūt autentifikācijas notikumiem, marķieru izmantošanai, sertifikātu izmantošanai, API izsaukumu metadatiem, avota darbslodzei, galamērķa pakalpojumam, marķiera dzīves laikam, atteices notikumiem un priviliģētām darbībām.

Zenith Controls ISO/IEC 27002:2022 kontroles pasākums 8.2 Priviliģētās piekļuves tiesības ir sasaistīts ar žurnālfiksēšanu un uzraudzību, jo priviliģētiem kontiem nepieciešami detalizēti ieraksti un pārraudzība. Zenith Controls arī sasaista 8.2 ar identitātes pārvaldību, piekļuves tiesībām, informācijas piekļuves ierobežošanu un drošu autentifikāciju. Auditoriem tas nozīmē, ka priviliģētas necilvēku identitātes jāpārskata un jāuzrauga ar tādu pašu nopietnību kā cilvēku administratoriem, dažkārt pat vēl stingrāk.

Labi uzraudzības jautājumi ietver:

• Vai servisa konts autentificējās no negaidītas darbslodzes vai IP diapazona?
• Vai API atslēga piekļuva jaunam galapunktam vai datu kopai?
• Vai sertifikāts tika izmantots pēc nomaiņas?
• Vai CI/CD marķieris izvietoja ārpus apstiprināta konveijera?
• Vai tikai lasīšanas konts mēģināja veikt rakstīšanas darbības?
• Vai neaktīvi akreditācijas dati kļuva aktīvi?
• Vai piegādātāja integrācija piekļuva datiem ārpus saskaņotā laika vai apjoma?

Kad notiek 02:13 brīdinājums, jums jāspēj atbildēt, kura identitāte tika izmantota, kurš noslēpums to autentificēja, kādas piekļuves tiesības tika izmantotas, kurus datus vai sistēmas tas ietekmēja, vai darbība bija gaidāma, kurš īpašnieks to var validēt un vai ir sasniegti incidentu ziņošanas sliekšņi.

Auditora skatījums: tas pats process, atšķirīgi jautājumi

Spēcīgākā audita pozīcija nav “mēs atbilstam visam”. Tā ir “mēs darbinām vienu kontrolētu procesu, kas rada pierādījumus vairākiem pienākumiem”. Dažādi auditori šo procesu pārbaudīs atšķirīgi.

Šajos skatījumos atkārtojošie konstatējumi ir paredzami: nav vienotas NHI uzskaites, mašīnidentitātēm nav īpašnieka, noslēpumi glabāti kodā vai dokumentācijā, akreditācijas dati koplietoti starp vidēm, nav rotācijas vai derīguma termiņa, piegādātāju pārvaldīti akreditācijas dati ir ārpus piekļuves tiesību pārskatīšanas, uzraudzība aptver cilvēkus, bet ne mašīnas, un incidentu rokasgrāmatas ignorē noslēpumu noplūdi.

Katrs konstatējums dabiski kartējas uz Clarysec kontroles pasākumiem, politikām un trūkumu novēršanas veidnēm. Vēl svarīgāk — katru no tiem var pārvērst izmērāmos pierādījumos ISMS ietvaros.

Kā Clarysec palīdz sagatavoties auditam

Clarysec pieeja ir praktiska, jo tā sākas ar pierādījumiem, kurus auditori pieprasīs, un no tiem atpakaļ veido kontroles pasākumus, politikas un operatīvās rutīnas.

Zenith Blueprint posmā “Kontroles pasākumi darbībā”, 19. solī, Clarysec sniedz tiešus norādījumus mašīna–mašīna autentifikācijai:

Mašīna–mašīna autentifikācijai, piemēram, servisa kontiem vai API izsaukumiem, atslēgas, sertifikāti un marķieri jāaizsargā tikpat stingri. Neieguliet akreditācijas datus kodā. Izmantojiet noslēpumu pārvaldības sistēmas vai seifus, lai tos droši glabātu un rotētu.

Tipiska Clarysec necilvēku identitāšu darba plūsma ietver NHI atklāšanu mākoņvidē, SaaS, CI/CD, repozitorijos, seifos un datubāzēs, politiku trūkumu izvērtēšanu pret Clarysec SME vai uzņēmuma politiku kopām, ISO/IEC 27001:2022 risku izvērtēšanu un riska apstrādes kartēšanu, piemērojamības deklarācijas (SoA) atjauninājumus, NIS2, DORA, GDPR un NIST CSF pierādījumu kartēšanu, NHI reģistra izstrādi, saskaņošanu ar atslēgu pārvaldības reģistru, noslēpumu skenēšanu, piekļuves tiesību pārskatīšanas procesus, piegādātāju akreditācijas datu atbildības matricas, incidentu rokasgrāmatas un audita paketes ar ekrānuzņēmumiem, eksportiem, žurnāliem, apstiprinājumiem un izņēmumu ierakstiem.

SME gadījumā pieeja ir samērīga. 70 cilvēku SaaS sniedzējam nav vajadzīgs tāds pats rīku nospiedums kā globālai bankai, taču tam ir vajadzīgas īpašumtiesības, politika, riska apstrāde un pierādījumi. Reglamentētām finanšu iestādēm un IKT pakalpojumu sniedzējiem tas pats modelis mērogojas līdz DORA kritisko funkciju kartēšanai, trešo pušu risku pārvaldībai un noturības testēšanai.

Ja jūsu nākamais audits ir 2026. gadā, negaidiet, līdz auditors jūsu vietā atklās necilvēku identitātes. Sāciet ar vienu kritisku pakalpojumu un uzdodiet piecus jautājumus:

1. Vai mēs zinām katru servisa kontu, API atslēgu, marķieri, sertifikātu un CI/CD noslēpumu, ko izmanto šis pakalpojums?
2. Vai katrai NHI ir vārdā nosaukts īpašnieks, glabātājs, mērķis un riska vērtējums?
3. Vai noslēpumi ir glabāti seifā, rotēti un aizsargāti pret nonākšanu pirmkodā, dokumentos, e-pastos un atklāta teksta krātuvēs?
4. Vai priviliģētas mašīnidentitātes tiek pārskatītas, uzraudzītas un ierobežotas no interaktīvas lietošanas?
5. Vai mēs no viena kontrolēta procesa varam sagatavot pierādījumus ISO/IEC 27001:2022, NIS2, DORA un GDPR vajadzībām?

Izmantojiet Zenith Blueprint: auditora 30 soļu ceļvedis Zenith Blueprint, lai strukturētu savu ISMS ieviešanas ceļu. Izmantojiet Zenith Controls: starpatbilstības ceļvedis Zenith Controls, lai sasaistītu ISO/IEC 27002:2022 identitātes, autentifikācijas, privilēģiju, žurnālfiksēšanas, kriptogrāfijas, drošas izstrādes un piegādātāju kontroles pasākumus ar regulatīvajiem pierādījumiem. Izmantojiet Clarysec SME un uzņēmuma politiku bibliotēku, tostarp Lietotāju kontu un privilēģiju pārvaldības politika SME Lietotāju kontu un privilēģiju pārvaldības politika SME, Kriptogrāfisko kontroles pasākumu politika Kriptogrāfisko kontroles pasākumu politika, Drošas izstrādes politika Drošas izstrādes politika un Lietojumprogrammu drošības prasību politika Lietojumprogrammu drošības prasību politika, lai labus nodomus pārvērstu piemērojamās prasībās.

02:13 brīdinājums kaut kur notiks. Jautājums ir, vai jūsu organizācija ar pierādījumiem spēj atbildēt, kam bija atslēga, ko tā atvēra, kāpēc tā pastāvēja un cik ātri jūs varat to padarīt drošu.