Nulles uzticēšanās arhitektūra 2026: auditam gatavi pierādījumi
Pirmdienas rīta nulles uzticēšanās audits, kuru neviens nebija plānojis
Pirmdien plkst. 08:12 Eiropas SaaS finanšu tehnoloģiju uzņēmuma informācijas drošības vadītājs piecu minūšu laikā saņem trīs ziņas.
Pirmā ir no bankas klienta: “Lūdzu, iesniedziet jūsu nulles uzticēšanās arhitektūras pierādījumu pakotni mūsu ikgadējai IKT trešās puses pārbaudei.”
Otrā ir no juridiskās komandas: “Vienā dalībvalstī mūs var klasificēt kā svarīgu subjektu saskaņā ar NIS2, un daži klienti jautā, vai DORA prasības attiecas uz mums kā IKT pakalpojumu sniedzēju.”
Trešā ir no inženierijas vadītāja: “Mums ir MFA, SSO, EDR, Kubernetes tīkla politikas un SIEM brīdinājumi. Vai tā ir nulles uzticēšanās?”
Šajā brīdī daudzas organizācijas apstājas. Tām ir drošības rīki, bet nav nulles uzticēšanās atbilstības darbības modeļa. Tās var parādīt MFA ekrānuzņēmumus, bet nevar izskaidrot, kā savstarpēji saistās identitāte, ierīces drošības stāvoklis, minimāli nepieciešamās tiesības, segmentācija, uzraudzība, incidentu ziņošana, privātuma aizsardzības pasākumi un piegādātāju atkarības. Tās var parādīt kontroles pasākumus, bet ne izsekojamību.
- gadā nulles uzticēšanās arhitektūrai, kas balstīta uz NIST SP 800-207, ir jābūt vairāk nekā “nekad neuzticies, vienmēr pārbaudi”. CISO, atbilstības vadītājiem, auditoriem un uzņēmumu īpašniekiem praktiskais jautājums ir daudz konkrētāks:
Kā nulles uzticēšanos pārvērst pierādījumos, kas apmierina ISO/IEC 27001:2022, NIS2 kiberdrošības higiēnas gaidas, DORA IKT risku pārvaldību, GDPR Article 32 apstrādes drošību, klientu sākotnējo izpēti un valdes pārraudzību?
Atbilde nav vēl viens rīks. Tā ir uz risku balstīta pierādījumu pieeja, kas sasaista politikas, kontroles pasākumus, tehnisko ieviešanu, uzraudzību un vadības pārskatatbildību.
Nulles uzticēšanās 2026. gadā: no drošības stratēģijas līdz atbilstības pierādījumiem
NIST SP 800-207 definē nulles uzticēšanos kā principu kopumu drošu sistēmu projektēšanai un ekspluatācijai vidē, kur uzticēšanās nekad netiek pieņemta pēc noklusējuma. Piekļuve tiek piešķirta, pamatojoties uz identitāti, kontekstu, politiku, aktīva drošības stāvokli un nepārtrauktu izvērtēšanu.
Septiņi NIST nulles uzticēšanās principi ir īpaši noderīgi, jo tie vispārīgu drošības saukli pārvērš par kaut ko tādu, ko var kartēt, testēt un auditēt:
- Visi datu avoti un skaitļošanas pakalpojumi tiek uzskatīti par resursiem.
- Visa saziņa tiek aizsargāta neatkarīgi no tīkla atrašanās vietas.
- Piekļuve atsevišķiem uzņēmuma resursiem tiek piešķirta katrai sesijai atsevišķi.
- Piekļuvi resursiem nosaka dinamiska politika, tostarp identitātes, ierīces, lietojumprogrammas un uzvedības atribūti.
- Uzņēmums uzrauga un mēra visu īpašumā esošo un saistīto aktīvu integritāti un drošības stāvokli.
- Visa resursu autentifikācija un autorizācija ir dinamiska un tiek stingri piemērota pirms piekļuves atļaušanas.
- Uzņēmums apkopo informāciju par aktīviem, infrastruktūru un saziņu un izmanto to drošības stāvokļa uzlabošanai.
Modernam SaaS pakalpojumu sniedzējam, digitālajai bankai, pārvaldīto pakalpojumu sniedzējam vai mākoņrisinājumos balstītai platformai šie principi pārtop praktiskās kontroles jomās:
- Identitāte tiek pārbaudīta un pārvaldīta.
- Ierīces tiek izvērtētas pirms piekļuves piešķiršanas.
- Priviliģētā piekļuve tiek minimizēta un pārskatīta.
- Tīkla ceļi tiek segmentēti un kontrolēti.
- Lietojumprogrammas, API un datu glabātuves piemēro autorizāciju.
- Žurnāli un telemetrijas dati nodrošina nepārtrauktu uzraudzību.
- Incidenti aktivizē ierobežošanu, ziņošanu un atjaunošanu.
- Pierādījumi apliecina, ka kontroles pasākumi darbojas, nevis tikai ir izstrādāti.
Tieši pēdējais punkts ir vieta, kur sākas atbilstība.
ISO/IEC 27001:2022 prasa organizācijām definēt kontekstu, ieinteresētās puses, piemērojamās tiesiskās un līgumiskās prasības, darbības jomu, saskarnes un atkarības. Tas prasa arī risku izvērtēšanu, risku apstrādi, piemērojamības deklarāciju, vadības pārskatatbildību, iekšējo auditu, vadības pārskatīšanu un nepārtrauktu pilnveidi.
Nulles uzticēšanās šajā struktūrā iekļaujas dabiski, ja to uzskata par kontroles sistēmu. Tai nevajadzētu atrasties ārpus informācijas drošības pārvaldības sistēmas (IDPS) kā atsevišķai inženierijas iniciatīvai. Tai jābūt daļai no risku izvērtēšanas, kontroles pasākumu atlases, politiku pārvaldības, piegādātāju pārvaldības, privātuma aizsardzības, reaģēšanas uz incidentiem un ziņošanas valdei.
Regulatīvais spiediens aiz nulles uzticēšanās pierādījumiem
Spiediens nodrošināt nulles uzticēšanās pierādījumus parasti rodas nevis no viena standarta, bet gan no pārklājošiem pienākumiem.
NIS2 var attiekties uz publiskiem vai privātiem subjektiem Annex I vai Annex II nozarēs, ja tie atbilst lieluma un darbības sliekšņiem, un tā var attiekties arī uz noteiktiem mazākiem, bet kritiskiem subjektiem. Annex I ietver mākoņdatošanas pakalpojumu sniedzējus, datu centru pakalpojumu sniedzējus, satura piegādes tīklu pakalpojumu sniedzējus, uzticamības pakalpojumu sniedzējus, pārvaldīto pakalpojumu sniedzējus, pārvaldīto drošības pakalpojumu sniedzējus, banku un finanšu tirgus infrastruktūras subjektus. Annex II ietver digitālos pakalpojumu sniedzējus, piemēram, tiešsaistes tirdzniecības vietas, meklētājprogrammas un sociālo tīklu platformas.
NIS2 Article 20 nosaka, ka kiberdrošība ir pārvaldības struktūras atbildība. Valdei jāapstiprina kiberdrošības risku pārvaldības pasākumi, jāuzrauga ieviešana un jāsaņem kiberdrošības apmācība. Article 21 prasa atbilstošus un samērīgus tehniskos, operacionālos un organizatoriskos pasākumus, kas aptver risku analīzi, incidentu apstrādi, darbības nepārtrauktību, piegādes ķēdes drošību, drošu izstrādi, ievainojamību pārvaldību, efektivitātes izvērtēšanu, kiberdrošības higiēnu, apmācības, kriptogrāfiju, personāla drošību, piekļuves kontroli, aktīvu pārvaldību un, ja piemērojams, MFA vai nepārtrauktu autentifikāciju. Article 23 ievieš pakāpenisku ziņošanu par būtiskiem incidentiem, tostarp 24 stundu agrīno brīdinājumu, 72 stundu paziņojumu un galīgo ziņojumu.
DORA ir piemērojama no 2025. gada 17. janvāra un izveido vienotu digitālās darbības noturības režīmu finanšu subjektiem. Tā aptver IKT risku pārvaldību, ziņošanu par būtiskiem ar IKT saistītiem incidentiem, digitālās darbības noturības testēšanu, apdraudējumu informācijas apmaiņu un IKT trešo pušu risku. DORA Articles 5 un 6 prasa pārvaldību un dokumentētu IKT risku pārvaldības ietvaru. Article 9 attiecas uz aizsardzību un novēršanu, tostarp politikām, procedūrām, protokoliem un rīkiem IKT sistēmu aizsardzībai. Article 17 prasa ar IKT saistītu incidentu pārvaldības procesu.
GDPR attiecas uz apstrādi ES uzņēmuma darbības kontekstā, kā arī uz ārpus ES esošiem pārziņiem vai apstrādātājiem, kas piedāvā preces vai pakalpojumus personām ES vai uzrauga viņu uzvedību. GDPR Article 5 prasa pārskatatbildību. Article 32 prasa atbilstošus tehniskos un organizatoriskos pasākumus, lai nodrošinātu riskam atbilstošu drošības līmeni. Article 33 prasa paziņošanu par personas datu aizsardzības pārkāpumu uzraudzības iestādei bez nepamatotas kavēšanās un, ja iespējams, 72 stundu laikā pēc tam, kad par pārkāpumu kļuvis zināms.
Nulles uzticēšanās pierādījumu modelis palīdz, jo viens un tas pats kontroles pasākums var atbalstīt vairākus ietvarus. MFA var atbalstīt ISO/IEC 27001:2022 piekļuves kontroli, NIS2 autentifikācijas pasākumus, DORA aizsardzības prasības un GDPR apstrādes drošību. Taču tikai tad, ja organizācija var pierādīt darbības jomu, īpašumtiesības, ieviešanu, uzraudzību un pārskatīšanu.
NIST nulles uzticēšanās principu kartēšana uz ISO/IEC 27001:2022 kontroles pasākumiem
ISO/IEC 27001:2022 Annex A kontroles pasākumi, kurus papildina ISO/IEC 27002:2022 ieviešanas vadlīnijas, nodrošina auditoriem saprotamu audita valodu. Zemāk esošā tabula pārvērš NIST nulles uzticēšanās principus ISO kontroles jomās, kuras auditori atpazīst.
| NIST SP 800-207 nulles uzticēšanās princips | Nulles uzticēšanās pamatprincips | Attiecīgie ISO/IEC 27001:2022 Annex A kontroles pasākumi |
|---|---|---|
| Visi datu avoti un skaitļošanas pakalpojumi ir resursi | Aktīvu un datu identificēšana | A.5.9 Informācijas un citu saistīto aktīvu uzskaite, A.5.10 Informācijas un citu saistīto aktīvu pieņemama lietošana, A.5.12 Informācijas klasifikācija |
| Visa saziņa tiek aizsargāta neatkarīgi no tīkla atrašanās vietas | Droša saziņa un šifrēti kanāli | A.8.20 Tīkla drošība, A.8.22 Tīklu nodalīšana, A.8.24 Kriptogrāfijas izmantošana |
| Piekļuve tiek piešķirta katrai sesijai atsevišķi | Uz sesiju balstīta autentifikācija un autorizācija | A.5.17 Autentifikācijas informācija, A.8.5 Droša autentifikācija |
| Piekļuvi nosaka dinamiska politika | Kontekstuāla piekļuve, kas balstīta uz minimāli nepieciešamajām tiesībām | A.5.15 Piekļuves kontrole, A.5.18 Piekļuves tiesības, A.8.3 Informācijas piekļuves ierobežošana |
| Tiek uzraudzīta aktīvu integritāte un drošības stāvoklis | Galiekārtu un darbslodžu drošības stāvokļa pārbaude | A.8.1 Lietotāju galiekārtu ierīces, A.8.8 Tehnisko ievainojamību pārvaldība |
| Autentifikācija un autorizācija ir dinamiska un stingri piemērota | Identitātes dzīves cikls un priviliģētās piekļuves pārvaldība | A.5.16 Identitātes pārvaldība, A.8.2 Priviliģētās piekļuves tiesības, A.8.5 Droša autentifikācija |
| Informācija tiek apkopota drošības stāvokļa uzlabošanai | Nepārtraukta uzraudzība, žurnalēšana un pilnveide | A.8.15 Žurnalēšana, A.8.16 Uzraudzības darbības, A.8.23 Tīmekļa filtrēšana |
Šī kartēšana nav tikai tehniskās arhitektūras uzdevums. Tā kļūst par risku reģistra, piemērojamības deklarācijas, pierādījumu pakotnes un vadības pārskatīšanas darba kārtības struktūru.
Piemēram, riska scenārijs “kompromitēts izstrādātāja konts maina produkcijas kodu un piekļūst klientu datiem” ir jākartē uz identitāšu pārvaldību, MFA, priviliģēto piekļuvi, tīklu nodalīšanu, žurnalēšanu, uzraudzību, drošu izstrādi, izmaiņu pārvaldību un reaģēšanu uz incidentiem. Šis viens scenārijs var atbalstīt ISO/IEC 27001:2022, NIS2 Article 21, DORA IKT risku pārvaldību un GDPR Article 32.
Clarysec nulles uzticēšanās kontroles pasākumu steks
Clarysec veido nulles uzticēšanos ap piecām pierādījumu jomām: identitāte, ierīce, tīkls, lietojumprogramma un dati, ar uzraudzību un pārvaldību visās piecās jomās.
Pamats ir piekļuves kontrole un identitāšu pārvaldība. Zenith Controls: starpietvaru atbilstības ceļvedī ISO/IEC 27002:2022 kontroles pasākums 5.15 “Piekļuves kontrole” ir klasificēts kā preventīvs kontroles pasākums, kas atbalsta konfidencialitāti, integritāti un pieejamību, ir saskaņots ar kiberdrošības funkciju “Aizsargāt” un identitāšu un piekļuves pārvaldības (IAM) spēju. Kontroles pasākums 5.16 “Identitātes pārvaldība” arī ir preventīvs un sasaistīts ar tām pašām KIP īpašībām un IAM spēju. Kontroles pasākums 8.16 “Uzraudzības darbības” ir klasificēts kā atklājošs un koriģējošs, atbalstot atklāšanu un reaģēšanu, izmantojot informācijas drošības notikumu pārvaldību.
Šī kombinācija ir būtiska. Nulles uzticēšanās nav tikai piekļuves kontrole. Tā ir piekļuves kontrole kopā ar identitātes dzīves ciklu, ierīces drošības stāvokli, tīklu nodalīšanu, uzraudzību un reaģēšanu.
Clarysec politikas prasības pārvērš šo modeli piemērojamā pārvaldībā.
No Uzņēmuma piekļuves kontroles politikas, sadaļas “Mērķi”, 3.4. punkts:
Atbalstīt nulles uzticēšanās principus, liedzot piekļuvi pēc noklusējuma, ja vien tā nav skaidri apstiprināta un pamatota.
No Uzņēmuma lietotāju kontu un privilēģiju pārvaldības politikas, sadaļas “Politikas ieviešanas prasības”, 6.2.1. punkts:
Visiem lietotājiem ir jāpiešķir minimālais piekļuves līmenis, kas nepieciešams viņu darba pienākumu veikšanai.
No Uzņēmuma tīkla drošības politikas, sadaļas “Pārvaldības prasības”, 5.2. punkts:
Visa starpzonu datplūsma jākontrolē ar ugunsmūriem vai programmatūras definēta perimetra risinājumiem, izmantojot skaidras noklusējuma lieguma konfigurācijas.
No Uzņēmuma žurnalēšanas un uzraudzības politikas, sadaļas “Mērķi”, 3.4. punkts:
Izveidot centralizētas žurnalēšanas un brīdināšanas sistēmas (piemēram, SIEM), lai apkopotu, korelētu un eskalētu aizdomīgas darbības gandrīz reāllaikā.
No Uzņēmuma informācijas drošības politikas, sadaļas “Politikas ieviešanas prasības”, 6.6.1. punkts:
Visiem ieviestajiem kontroles pasākumiem jābūt auditējamiem, atbalstītiem ar dokumentētām procedūrām un saglabātiem darbības pierādījumiem.
MVU gadījumā to pašu pārvaldības nolūku var īstenot ar vienkāršāku politikas dokumentāciju. Lietotāju kontu un privilēģiju pārvaldības politika — MVU, sadaļas “Mērķi” 3.2. punkts nosaka:
Piemērot minimālo privilēģiju principu, nodrošinot, ka lietotājiem tiek piešķirts tikai minimālais piekļuves līmenis, kas nepieciešams viņu pienākumu veikšanai.
Piekļuves kontroles politika — MVU, sadaļas “Pārvaldības prasības” 5.4.3. punkts papildina:
Priviliģētajiem kontiem jāizmanto daudzfaktoru autentifikācija (MFA), ja tā tiek atbalstīta.
Tīkla drošības politika — MVU, sadaļas “Politikas ieviešanas prasības” 6.2.3. punkts nosaka:
Datplūsma starp segmentiem ir jāfiltrē, un starpsegmentu piekļuvei jāievēro minimālo privilēģiju princips.
Žurnalēšanas un uzraudzības politika — MVU, sadaļas “Mērķis” 1.3. punkts skaidro:
Žurnalēšana un uzraudzība atbalsta draudu atklāšanu, regulatīvo atbilstību, incidentu ziņošanu un pārvaldību, kā arī digitālo forensiku.
Uz privātumu orientētai nulles uzticēšanās pieejai Datu aizsardzības un privātuma politika — MVU, sadaļas “Pārvaldības prasības” 5.3.2. punkts nosaka:
Lietotāju piekļuve personas datiem jāierobežo līdz lomām ar dokumentētu biznesa vajadzību.
Šīs prasības izveido audita atskaites punktus. Auditors var testēt, vai piekļuve tiek liegta pēc noklusējuma, privilēģijas ir minimizētas, starpzonu datplūsma tiek kontrolēta, žurnāli ir centralizēti un pierādījumi tiek saglabāti.
Starpietvaru nulles uzticēšanās pierādījumu karte
Spēcīgam nulles uzticēšanās pierādījumu modelim jāizvairās no sadrumstalotiem ekrānuzņēmumiem. Pierādījumiem jāparāda pārvaldība, arhitektūra, ieviešana, uzraudzība un pārskatīšana.
| Nulles uzticēšanās spēja | ISO/IEC 27001:2022 un ISO/IEC 27002:2022 pierādījumi | NIS2 pierādījumi | DORA pierādījumi | GDPR pierādījumi |
|---|---|---|---|---|
| Identitātes pārbaude un dzīves cikls | IDPS darbības joma, risku reģistrs, SoA ieraksti par A.5.15 un A.5.16, darbinieku pieņemšanas, pārcelšanas un darba attiecību izbeigšanas ieraksti | Article 21 personāla drošības, piekļuves kontroles un aktīvu pārvaldības pasākumi | IKT aktīvu un lietotāju piekļuves pārvaldība IKT risku ietvarā | Piekļuve ierobežota līdz autorizētām lomām, pārziņa pārskatatbildības ieraksti |
| MFA un nepārtraukta autentifikācija | Piekļuves kontroles politika, priviliģētās piekļuves procedūra, MFA piemērošanas pārskati | Article 21 pasākumi MFA vai nepārtrauktai autentifikācijai, ja piemērojams | Kontroles pasākumi, kas atbalsta drošu piekļuvi IKT sistēmām un kritiskām funkcijām | Article 32 apstrādes drošības pierādījumi piekļuvei personas datiem |
| Ierīces drošības stāvoklis un galiekārtu uzticamība | Aktīvu uzskaite, galiekārtu konfigurācijas bāzlīnija, EDR pārklājums, izņēmumu apstiprinājumi | Kiberdrošības higiēna, ievainojamību pārvaldība un drošu sistēmu politikas | IKT aktīvu uzskaite, noturības testēšana, IKT sistēmu uzraudzība | Aizsardzība pret nesankcionētu vai nelikumīgu apstrādi no kompromitētām galiekārtām |
| Tīkla segmentācija un mikrosegmentācija | Tīkla shēmas, ugunsmūra noteikumi, segmentācijas testu rezultāti, izmaiņu ieraksti | Pasākumi incidenta ietekmes novēršanai vai mazināšanai un darbības nepārtrauktības atbalstam | Atsauces arhitektūra, ietekmes tolerance, kritisko sistēmu testēšana | Datu izolācija, pārkāpuma tvēruma minimizēšana |
| Lietojumprogrammu un API minimāli nepieciešamās tiesības | RBAC vai ABAC matricas, mākoņvides IAM politikas, marķieru tvērumi, API piekļuves tiesību pārskatīšana | Droša iegāde, izstrāde un uzturēšana, ievainojamību pārvaldība | Ar IKT atbalstītu funkciju kartēšana un atkarību dokumentācija | Nolūka ierobežošana, piekļuve personas datiem, pamatojoties uz biznesa vajadzību |
| Nepārtraukta uzraudzība un atklāšana | SIEM lietošanas gadījumi, brīdinājumu triāža, uzraudzības procedūra, incidentu ieraksti | Incidentu apstrāde un gatavība ziņot par būtiskiem incidentiem | Incidentu klasifikācija, vadības eskalācija un ziņošanas dzīves cikls | Personas datu aizsardzības pārkāpumu atklāšanas un pārskatatbildības pierādījumi |
| Piegādātāju un mākoņpakalpojumu uzticamība | Piegādātāju līgumi, mākoņpakalpojumu izstāšanās plāns, piegādātāju uzraudzība, kopīgās atbildības kartējums | Piegādes ķēdes drošība tiešajiem piegādātājiem un pakalpojumu sniedzējiem | IKT trešo pušu riska stratēģija, IKT līgumu reģistrs, audita tiesības un izstāšanās plāni | Apstrādātāja sākotnējā izpēte, līgumiskie drošības pasākumi un drošības kontroles pasākumi |
Šī tabula ir valdei piemērotas nulles uzticēšanās programmas kodols. Tā parāda, kā viena kontroles vide var atbalstīt vairākas apliecinājuma vajadzības, neveidojot atsevišķas pierādījumu pakotnes katram ietvaram.
Zenith Blueprint izmantošana izsekojamības izveidei
Clarysec Zenith Blueprint: auditora 30 soļu ceļvedis ir izstrādāts, lai nulles uzticēšanās nekļūtu par nedokumentētu inženierijas filozofiju. Risku pārvaldības posmā, 13. solī “Risku apstrādes plānošana un piemērojamības deklarācija”, tas skaidro:
SoA faktiski ir savienojošais dokuments: tas sasaista jūsu risku izvērtēšanu/apstrādi ar
faktiskajiem kontroles pasākumiem, kas jums ir. To aizpildot, jūs arī atkārtoti pārbaudāt, vai nav palaists garām kāds kontroles pasākums.
Tas pats solis iesaka kartēt kontroles pasākumus uz riskiem, pievienot Annex A kontroles atsauces risku apstrādes ierakstiem un veikt savstarpēju salīdzināšanu ar regulējumu, piemēram, GDPR, NIS2 vai DORA, ja kontroles pasākumi ieviesti šo pienākumu izpildei.
Nulles uzticēšanās gadījumā tas ir trūkstošais savienojums. Ja auditors jautā, kāpēc esat ieviesuši nosacīto piekļuvi, atbildei nevajadzētu būt “tāpēc, ka to prasa nulles uzticēšanās”. Labāka atbilde ir:
- Riska scenārijs ir nesankcionēta piekļuve klientu datiem, izmantojot kompromitētus autentifikācijas datus.
- Riska īpašnieks ir CTO vai inženierijas vadītājs.
- Riska apstrāde ietver SSO, MFA, nosacīto piekļuvi, galiekārtu drošības stāvokļa validāciju, minimāli nepieciešamās tiesības, segmentāciju un uzraudzību.
- SoA kartē apstrādi uz piekļuves kontroli, identitāšu pārvaldību, žurnalēšanu, uzraudzību, kriptogrāfiju, ievainojamību pārvaldību un mākoņpakalpojumu pārvaldību.
- Tā pati apstrāde atbalsta NIS2 Article 21, DORA IKT risku pārvaldību un GDPR Article 32.
- Pierādījumi ietver politikas prasības, piekļuves tiesību pārskatīšanu, SIEM brīdinājumus, EDR drošības stāvokļa pārskatus, ugunsmūra noteikumus, IAM eksportus, incidentu vingrinājumus un vadības pārskatīšanas protokolus.
Tā nulles uzticēšanās arhitektūra kļūst gatava auditam.
Galiekārtu uzticamība, API un tīklu nodalīšana praksē
Nulles uzticēšanās bieži neizdodas, jo organizācijas koncentrējas uz identitāti, ignorējot ierīces, darbslodzes, datu un tīkla kontekstu.
Zenith Blueprint 19. solis “Tehnoloģiskie kontroles pasākumi I” skaidri izskaidro galiekārtu drošības stāvokļa prasību:
Piekļuvei informācijai caur galiekārtām jābūt kontekstuālai. Piemēram, vai ierīce
atbilst minimālajiem drošības standartiem pirms piekļuves uzņēmuma resursiem? Vai tai nesen ir veikta
ļaunatūras skenēšana? Vai tā pieslēdzas no neparastas atrašanās vietas vai tīkla? Integrējot ar nulles
uzticēšanās principiem, galiekārtas drošības stāvokli var izmantot nosacītajā piekļuvē, liedzot piekļuvi līdz brīdim, kad
ierīce pierāda, ka tā ir droša.
Tas padara ierīci par daļu no autorizācijas lēmuma. Derīgu paroli no nepārvaldīta klēpjdatora nedrīkst vērtēt tāpat kā derīgu pieteikšanos no atbilstošas, šifrētas un uzraudzītas uzņēmuma galiekārtas.
Tas pats solis uzsver, ka piekļuves ierobežojumi attiecas uz lietojumprogrammām, pakalpojumiem un API, ne tikai uz lietotājiem:
Piekļuves ierobežojumi jāpiemēro arī lietojumprogrammām, pakalpojumiem un API, ne tikai cilvēkiem.
Piemēram, mikropakalpojumam var būt nepieciešama tikai lasīšanas piekļuve datubāzes tabulai, nevis pilnas CRUD
tiesības. Rezerves kopiju rīkam var būt nepieciešama piekļuve tikai konkrētiem glabāšanas spaiņiem, nevis visiem nomnieka resursiem.
Šīs vadlīnijas ir kritiski svarīgas mākoņrisinājumos balstītām vidēm. API tvērumi, servisa konti, darbslodžu identitātes, Kubernetes lomas un mākoņvides IAM politikas visās situācijās jābalsta uz minimāli nepieciešamajām tiesībām. Cilvēku piekļuve ir tikai viena kontroles virsmas daļa.
Zenith Blueprint 20. solis aplūko tīklu nodalīšanu:
Nodalīšana ir viens no senākajiem un efektīvākajiem kiberdrošības principiem: ierobežot
izplatību, samazināt risku un lokalizēt kaitējumu. Control 8.22 koncentrējas uz tīkla
nodalīšanu — praksi nošķirt sistēmas, pakalpojumus un lietotājus dažādās loģiskās vai
fiziskās zonās, lai nepieļautu nesankcionētu piekļuvi un kompromitēšanas gadījumā ierobežotu laterālo pārvietošanos.
Tas ir kritiski DORA un NIS2 noturības kontekstā. Nulles uzticēšanās tīklam jāpieņem, ka viens konts, darbslodze vai galiekārta var tikt kompromitēta. Segmentācija nepieļauj, ka lokāls notikums pārvēršas par sistēmisku incidentu.
10 dienu nulles uzticēšanās pierādījumu pakotne
Iedomāsimies SaaS finanšu tehnoloģiju uzņēmumu, kas bankām sniedz krāpšanas analītikas pakalpojumus. Tas apstrādā personas datus, izmanto mākoņa infrastruktūru, paļaujas uz pārvaldītu Kubernetes, integrējas ar klientu API un izmanto trešās puses identitātes nodrošinātāju. Klients pieprasa nulles uzticēšanās pierādījumus, un uzņēmumam ir desmit darba dienas.
Praktisks Clarysec pierādījumu sprints izskatītos šādi.
| Laika grafiks | Darbība | Pierādījumu rezultāts |
|---|---|---|
| 1.–2. diena | Definēt nulles uzticēšanās darbības jomu produkcijas mākoņkontiem, identitātes nodrošinātājam, CI/CD, administratoru darbstacijām, klientu API vārtejai, datu noliktavai, SIEM, EDR un kritiskajiem piegādātājiem | Darbības jomas paziņojums, atkarību karte, robežu shēma |
| 3. diena | Izveidot risku un kontroles pasākumu izsekojamību, izmantojot Zenith Blueprint 13. soli | Risku reģistra ieraksti, apstrādes plāns, SoA kartējumi |
| 4.–5. diena | Piemērot uzņēmuma vai MVU politikas prasības un dokumentēt izņēmumus | Apstiprinātas politikas, izņēmumu reģistrs, riska pieņemšanas ieraksti |
| 6.–7. diena | Apkopot tehniskos pierādījumus | MFA pārskati, nosacītās piekļuves politikas, PAM ieraksti, galiekārtu informācijas paneļi, ugunsmūra noteikumi, Kubernetes tīkla politikas, IAM eksporti, SIEM lietošanas gadījumi |
| 8. diena | Pievienot privātuma un datu aizsardzības pierādījumus | Lomu un datu matrica, apstrādes ieraksti, šifrēšanas pierādījumi, glabāšanas noteikumi, pārkāpuma eskalācijas procedūra |
| 9. diena | Pievienot NIS2 un DORA pārklājumus | Article 21 kartējums, gatavība ziņot par incidentiem, IKT funkciju karte, piegādātāju reģistrs, izstāšanās plāna pierādījumi |
| 10. diena | Izveidot vadības kopsavilkumu | Valdei piemērots izklāsts, atlikušā riska kopsavilkums, uzlabošanas ceļkarte |
Mērķis nav izlikties, ka organizācija desmit dienās ir sasniegusi perfektu nulles uzticēšanos. Mērķis ir izveidot pamatotu pierādījumu ķēdi būtiskākajiem riskiem un pierādīt, ka programma tiek pārvaldīta, mērīta un pilnveidota.
Kā dažādi auditori testēs nulles uzticēšanos
Bieža kļūda ir sagatavot vienu tehnisku stāstu un pieņemt, ka katrs auditors uzdos tos pašus jautājumus. Tā nenotiks.
ISO/IEC 27001:2022 auditors meklēs pārvaldības sistēmu. Viņš jautās, vai nulles uzticēšanās riski ir iekļauti risku izvērtēšanā, vai apstrādes pasākumi ir apstiprināti, vai SoA ir pilnīga, vai politikas ir kontrolēti dokumenti, vai tiek veikta piekļuves tiesību pārskatīšana, vai iekšējie auditi testē kontroles pasākumus un vai vadības pārskatīšanā tiek vērtēta veiktspēja.
DORA pārbaudītājs jautās, vai nulles uzticēšanās kontroles pasākumi ir daļa no dokumentētā IKT risku pārvaldības ietvara. Viņš sagaidīs aktīvu un atkarību uzskaiti, kritisku vai svarīgu funkciju kartēšanu, incidentu klasifikāciju, eskalāciju valdei, testēšanu, trešo pušu līgumu prasības, audita tiesības, izstāšanās stratēģijas un trūkumu novēršanas izsekošanu.
NIS2 vērtētājs koncentrēsies uz pārvaldības struktūras pārskatatbildību, Article 21 kiberdrošības risku pārvaldības pasākumiem un Article 23 gatavību ziņot par incidentiem. Viņš sagaidīs arī pierādījumus, ka tiek pārvaldīta piegādes ķēdes drošība, darbības nepārtrauktība, ievainojamību pārvaldība, piekļuves kontrole un kiberdrošības higiēna.
GDPR pārbaudītājs vai privātuma auditors jautās, vai piekļuve personas datiem ir nepieciešama, dokumentēta, ierobežota, uzraudzīta un saskaņota ar apstrādes nolūkiem. Viņš pārbaudīs pārziņa un apstrādātāja lomas, personas datu aizsardzības pārkāpumu atklāšanu, lomās balstītu piekļuvi, šifrēšanu, pseidonimizāciju, ja tā piemērojama, glabāšanu un pārskatatbildību.
| Auditora skatpunkts | Iespējamais jautājums | Pierādījumi, kas uz to atbild |
|---|---|---|
| ISO/IEC 27001:2022 auditors | Vai nulles uzticēšanās ir uz risku balstīta, apstiprināta un atspoguļota SoA? | Risku reģistrs, SoA, risku apstrādes plāns, politiku apstiprinājumi, vadības pārskatīšanas protokoli |
| NIST CSF vērtētājs | Vai pārvaldības, identitātes, aizsardzības, atklāšanas, reaģēšanas un atjaunošanas rezultāti ir integrēti? | CSF profils, trūkumu novēršanas plāns, IAM kontroles pasākumi, žurnalēšanas lietošanas gadījumi, reaģēšanas instrukcijas, atjaunošanas testi |
| DORA pārbaudītājs | Vai nulles uzticēšanās atbalsta IKT risku pārvaldību un kritisko funkciju noturību? | IKT aktīvu uzskaite, atkarību karte, testēšanas programma, incidentu klasifikācija, piegādātāju reģistrs |
| GDPR/privātuma auditors | Vai piekļuve personas datiem ir ierobežota un pierādāmi aizsargāta? | Lomu un datu matrica, piekļuves tiesību pārskatīšana, šifrēšanas pierādījumi, pārkāpumu procedūras, apstrādes ieraksti |
| COBIT 2019/ISACA auditors | Vai pienākumi, metrikas un kontroles veiktspēja tiek pārvaldīti? | RACI, KPI, izņēmumu reģistrs, audita konstatējumi, trūkumu novēršanas izsekotājs |
Tas pats kontroles pasākums var apmierināt vairākus jautājumus, taču tikai tad, ja pierādījumi ir sakārtoti.
Piegādātāju, mākoņpakalpojumu un IKT trešo pušu risks
Nulles uzticēšanās nebeidzas pie ugunsmūra, un mākoņvidēs tradicionālas ugunsmūra robežas var nebūt vispār. Identitātes nodrošinātāji, mākoņplatformas, CI/CD rīki, pārvaldītie atklāšanas pakalpojumu sniedzēji, maksājumu apstrādātāji, API vārtejas un ārpakalpojuma izstrādes komandas kļūst par uzticēšanās auduma daļu.
NIS2 Article 21 skaidri ietver piegādes ķēdes drošību tiešajiem piegādātājiem un pakalpojumu sniedzējiem, tostarp piegādātāju ievainojamības, produktu un pakalpojumu noturību, piegādātāju kiberdrošības praksi un drošas izstrādes procedūras.
DORA prasa IKT trešo pušu risku pārvaldīt kā daļu no IKT risku pārvaldības ietvara, izmantojot IKT pakalpojumu līgumu reģistru, pirmslīguma sākotnējo izpēti, kritiskuma izvērtēšanu, koncentrācijas risku, līgumiskās drošības prasības, incidentu atbalstu, sadarbību ar iestādēm, audita tiesības, izbeigšanas tiesības, izstāšanās stratēģijas un pārejas plānus.
Nulles uzticēšanās praktiskais noteikums ir vienkāršs: neuzticieties piegādātāja savienojumam tikai tāpēc, ka tas ir līgumisks. Pieprasiet tehniskos kontroles pasākumus un pierādījumus.
Klienta API integrācijai jābūt ar ierobežota tvēruma marķieriem, pieprasījumu ātruma ierobežošanu, uzraudzību, rotāciju, īpašumtiesībām un atsaukšanu. Pārvaldīto pakalpojumu sniedzējam jāizmanto MFA, vārdiskie lietotāju konti, minimāli nepieciešamās tiesības, sesiju žurnalēšana un laikierobežota piekļuve. Attiecībās ar mākoņpakalpojumu sniedzēju jābūt kopīgās atbildības kartējumam, šifrēšanas konfigurācijai, žurnālu glabāšanai, rezerves kopiju testēšanai un izstāšanās plānošanai.
Tāpēc piegādātāju un mākoņpakalpojumu pierādījumiem jāatrodas nulles uzticēšanās modelī, nevis atsevišķā iepirkumu mapē.
Metrikas, kas pierāda, ka nulles uzticēšanās darbojas
Valdes un auditori nevēlas tikai arhitektūras shēmas. Viņi vēlas darbības pierādījumus un uzlabošanas tendences.
Noderīgas nulles uzticēšanās metrikas ir:
- Priviliģēto kontu procentuālā daļa, kas aizsargāta ar MFA.
- Lietotāju procentuālā daļa, uz ko attiecas nosacītā piekļuve.
- Pastāvīgo priviliģēto kontu skaits salīdzinājumā ar just-in-time kontiem.
- Kavētu piekļuves tiesību pārskatīšanas gadījumu skaits.
- Galiekārtu procentuālā daļa, kas atbilst drošības stāvokļa prasībām.
- EDR pārklājums kritiskajiem aktīviem.
- Liegtu piekļuves mēģinājumu skaits ierīces vai atrašanās vietas riska dēļ.
- Vidējais laiks līdz aizdomīgas priviliģētas darbības atklāšanai.
- Vidējais laiks līdz piekļuves atsaukšanai pēc darba attiecību izbeigšanas.
- Starpzonu ugunsmūra noteikumu procentuālā daļa, kas pārskatīta pēdējā ceturksnī.
- Kritisko piegādātāju skaits ar aktuāliem drošības pierādījumiem.
- Nulles uzticēšanās izņēmumu skaits pēc trūkumu novēršanas termiņa.
- Kritisko lietojumprogrammu procentuālā daļa, kas sūta žurnālus uz SIEM.
- Incidentu simulāciju rezultāti autentifikācijas datu kompromitēšanas scenārijiem.
Šīs metrikas atbalsta ISO/IEC 27001:2022 nepārtrauktu pilnveidi, NIS2 efektivitātes izvērtēšanu, DORA testēšanas un trūkumu novēršanas gaidas, kā arī GDPR pārskatatbildību.
Biežākās nulles uzticēšanās pierādījumu nepilnības
Biežākās nepilnības nerodas rīku trūkuma dēļ. Tās izraisa vāja izsekojamība.
Pirmkārt, organizācijas ievieš MFA, bet nevar pierādīt, ka visi priviliģētie konti ir pilnībā aptverti. Servisa konti, “break glass” administratora konti un lokālie administratora konti bieži paliek ārpus kontroles pasākuma.
Otrkārt, piekļuves tiesību pārskatīšana tiek veikta manuāli, bet nav sasaistīta ar biznesa lomām, datu sensitivitāti vai riska īpašniekiem. Pierādījumi parāda, ka kāds noklikšķināja “pārskatīts”, nevis to, ka nevajadzīgā piekļuve tika noņemta.
Treškārt, tīkla segmentācija pastāv shēmās, bet ne pārbaudītos noteikumos. Auditori jautās, vai starpsegmentu piekļuve tiek liegta pēc noklusējuma un vai izņēmumi ir apstiprināti.
Ceturtkārt, žurnāli tiek vākti, bet nav izmantojami rīcībai. SIEM bez definētiem lietošanas gadījumiem, brīdinājumu triāžas un reaģēšanas procedūrām nepierāda nepārtrauktu uzraudzību.
Piektkārt, piegādātāju piekļuve netiek pārvaldīta. Piegādātāji var izmantot koplietojamus kontus, pastāvīgu VPN piekļuvi vai plašas mākoņvides lomas bez sesiju uzraudzības.
Sestkārt, privātuma pierādījumi ir nošķirti no drošības pierādījumiem. GDPR prasa pierādāmu personas datu aizsardzību, tāpēc identitātes un piekļuves kontroles pasākumiem jābūt sasaistītiem ar datu kategorijām un apstrādes nolūkiem.
Visbeidzot, izņēmumi netiek dokumentēti. Nulles uzticēšanās var pieļaut izņēmumus, ja tie ir izvērtēti risku kontekstā, apstiprināti, laikierobežoti un uzraudzīti. Tā nevar pieļaut neredzamus izņēmumus.
Izveidojiet savu nulles uzticēšanās pierādījumu pakotni ar Clarysec
Nulles uzticēšanās arhitektūra 2026. gadā nav sauklis. Tā ir atbilstības darbības modelis, kas identitāti, ierīces, lietojumprogrammas, tīkla segmentāciju, minimāli nepieciešamās tiesības, nepārtrauktu uzraudzību, piegādātāju kontroli un privātuma aizsardzības pasākumus sasaista vienā auditējamā sistēmā.
Ja gatavojaties ISO/IEC 27001:2022 sertifikācijai, atbildat uz NIS2 klientu pieprasījumiem, saskaņojaties ar DORA IKT risku pārvaldību vai pierādāt GDPR Article 32 apstrādes drošību, sāciet ar izsekojamību.
Izmantojiet Zenith Blueprint: auditora 30 soļu ceļvedi, lai kartētu nulles uzticēšanās riskus uz jūsu risku reģistru, apstrādes plānu un SoA. Izmantojiet Zenith Controls: starpietvaru atbilstības ceļvedi, lai saskaņotu piekļuves kontroli, identitāšu pārvaldību un uzraudzību ar starpietvaru gaidām. Izmantojiet Clarysec politiku bibliotēku, tostarp Uzņēmuma piekļuves kontroles politiku, Uzņēmuma lietotāju kontu un privilēģiju pārvaldības politiku, Uzņēmuma tīkla drošības politiku, Uzņēmuma žurnalēšanas un uzraudzības politiku, Uzņēmuma informācijas drošības politiku un Datu aizsardzības un privātuma politiku — MVU, lai arhitektūru pārvērstu piemērojamā pārvaldībā.
Nākamais praktiskais solis ir izvēlēties vienu augsta riska scenāriju, piemēram, kompromitētu priviliģētu piekļuvi klientu datiem, un ap to izveidot pilnu nulles uzticēšanās pierādījumu ķēdi. Ja varat pierādīt šo scenāriju no gala līdz galam, jums ir pamats mērogojamai, auditējamai un regulatoram gatavai nulles uzticēšanās programmai.
Lejupielādējiet Clarysec politiku pakotnes vai ieplānojiet stratēģijas sarunu, lai redzētu, kā Zenith Blueprint un Zenith Controls var pārvērst nulles uzticēšanos no audita riska par atbilstības priekšrocību.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
