Datu drošība mākonī: padariet kopīgo atbildību konkrētu

Mākoņpakalpojumu sniedzējs darbina daļu no drošības vides. Jūsu komandai joprojām jānoskaidro, kurus aizsardzības pasākumus tā konfigurē, vai tie aptver izmantotos datus un pakalpojumus un kā tā zina, ka tie joprojām ir efektīvi.

Datu drošība mākonī aizsargā konfidencialitāti, integritāti un pieejamību glabāšanas, apstrādes, koplietošanas un atjaunošanas laikā. Tā ietver datubāzes un objektu krātuves, bet arī lietotņu atļaujas, SaaS eksportus, pakalpojumu identitātes, rezerves kopijas un klēpjdatorus vai automatizācijas sistēmas, kas var izgūt datus.

No CTO skatpunkta kopīgā atbildība kļūst noderīga tikai tad, ja tā rada konkrētus inženiertehniskus lēmumus: kurš konfigurē kontroli, kurš to uzrauga, kādi pierādījumi apliecina tās darbību un kurš rīkojas, ja tā neizdodas. Pakalpojumu sniedzēja drošības paziņojums nevar atbildēt uz šiem jautājumiem jūsu izvietojumam.

Nosakiet robežu, pirms izvēlaties kontroles

Mākoņvides apvieno attālināti nodrošinātu infrastruktūru, platformas un lietotnes. Publiskais mākonis parasti izmanto pakalpojumu sniedzēja darbinātu infrastruktūru, kas apkalpo vairākus klientus; privātais mākonis ir paredzēts vienai organizācijai. Neviens no šiem apzīmējumiem nenosaka, vai jūsu dati ir pienācīgi aizsargāti. Izolācija, piekļuves ceļi, darbības atbildība un atjaunošanas kārtība ir svarīgāka par apzīmējumu.

Sāciet ar vienu biznesa pakalpojumu un izsekojiet tā atkarības. Identificējiet mākoņkontus vai abonementus, reģionus, pakalpojumus, datu krātuves, administratorus un izvietošanas sistēmas. Iekļaujiet SaaS produktus, ko izmanto atbalsta, finanšu un izstrādes komandas: produkcijas datubāze var būt stingri kontrolēta, kamēr tās klientu eksports atrodas plaši koplietotā darbvietā.

Inventāram jāatbild uz šiem jautājumiem:

• Kāda informācija tiek glabāta vai apstrādāta, un kam pieder biznesa nolūks?
• Kur atrodas primārie ieraksti, replikas, žurnāli, eksporti, kešatmiņas un rezerves kopijas?
• Kuri cilvēki, darba slodzes, piegādātāji un ārējie saņēmēji tiem var piekļūt?
• Kuri konti, reģioni un pakalpojumi ir apstiprināti, un kā tiek atklāti jauni?
• Kādas glabāšanas, dzēšanas, pieejamības un līgumiskās prasības ir piemērojamas?

Mākoņa mērogojamība un attālinātā pieejamība var uzlabot darbību, savukārt pārvaldītie pakalpojumi var samazināt infrastruktūras uzturēšanu. Tie arī ļauj viegli izveidot resursus un kopijas ātrāk, nekā pārskatītāji spēj tās izsekot. Tāpēc drošības izmaksās ietilpst identitāšu administrēšana, uzraudzība, pierādījumu vākšana, atjaunošanas testēšana un piegādātāju uzraudzība, nevis tikai rēķins par krātuvi.

Klasificējiet informāciju tur, kur tā faktiski atrodas

Izmantojiet pārvaldāmu klasifikācijas shēmu, kas saistīta ar darbībām. Piemēram, publiskas, iekšējas, konfidenciālas un ierobežotas pieejamības kategorijas var noteikt koplietošanas noteikumus, piekļuves pārskatus, žurnalēšanu un glabāšanu. Definējiet, kura kategorija aptver klientu identifikatorus, autentifikācijas noslēpumus, finanšu ierakstus, pirmkodu un sensitīvu personas informāciju.

Automatizēta atklāšana var palīdzēt atrast nepamanītas datu kopas, taču validējiet rezultātus kopā ar datu īpašniekiem. Skeneris var palaist garām saspiestus arhīvus vai lietotnei specifiskus laukus, savukārt nekaitīga testa virkne var izraisīt kļūdaini pozitīvu rezultātu. Reģistrējiet neskenētās vietas un izlases ierobežojumus. Pilnīgāku atklāšanas darbplūsmu skatiet rakstā par datu atklāšanu un privātumu.

Kartējiet atbildību katram pakalpojumam atsevišķi

Atbildības robeža mainās atkarībā no pakalpojuma modeļa un pakalpojumu sniedzēja ieviešanas. Uzskatiet turpmāko par sākumpunktu, kas jāapstiprina attiecībā pret pakalpojuma dokumentāciju un līgumiem, nevis par universālu sadalījumu.

Katram svarīgam aizsardzības pasākumam reģistrējiet pakalpojumu sniedzēja ieguldījumu, klienta konfigurāciju, darbības īpašnieku, pārskatītāju un pierādījumu avotu. Izvairieties no ierakstiem, piemēram, „šifrēšana: pakalpojumu sniedzējs”. Tā vietā rakstiet: „Pakalpojumu sniedzējs nodrošina pārvaldītu šifrēšanu; platformas komanda izvēlas atslēgu konfigurāciju; drošības komanda pārskata atšifrēšanas atļaujas; pakalpojuma īpašnieks testē atjaunošanu.”

Līdzās cilvēkiem lietotājiem iekļaujiet pakalpojumu identitātes un izvietošanas automatizāciju. Konveijers, kas izveido resursus, maina piekļuves politikas vai izgūst noslēpumus, ir daļa no drošības robežas. Arī pārvaldīto pakalpojumu operatoriem un ārējiem atbalsta sniedzējiem nepieciešami skaidri pienākumi, pat ja viņi administrē infrastruktūru jūsu vārdā.

Identificējiet nodošanas kļūmes. Ja pakalpojumu sniedzējs ziņo par kompromitētiem akreditācijas datiem, kurš saņem paziņojumu ārpus darba laika? Ja datubāze nav pieejama, kurš izlemj, vai atjaunot, pārslēgties uz rezerves sistēmu vai gaidīt? Katram klienta puses rezultātam piešķiriet vienu atbildīgo iekšējo īpašnieku, pat ja darbu izpilda vairākas komandas.

Izvērtējiet pakalpojumu sniedzēja apliecinājumu, to nepārspīlējot

Pārskatiet pakalpojuma drošības dokumentāciju, saziņu incidentu gadījumā, atbalsta piekļuves kārtību, apakšapstrādātājus, dzēšanas uzvedību, atjaunošanas iespējas un pieejamos audita žurnālus. Pārbaudiet, vai attiecīgais konta līmenis patiešām ietver funkcijas, kas nepieciešamas jūsu risinājumam.

Apliecinājuma dokumentiem nepieciešama tvēruma pārskatīšana. SOC 2 ziņojums ir apliecinājuma ziņojums, nevis sertifikāts. ISO 27001 sertifikācija attiecas uz noteiktā tvērumā darbojošos informācijas drošības pārvaldības sistēmu, nevis pierāda, ka jūsu nomnieks ir droši konfigurēts. Pārbaudiet aptvertos pakalpojumus, pārskata periodu, izņēmumus un ziņojumā identificētās klienta kontroles.

Ja attiecināms, BSI C5 katalogs sniedz mākoņpakalpojumu apliecinājuma kritērijus. Nošķiriet 1. tipa novērtējumu par dizainu un ieviešanu noteiktā brīdī no 2. tipa pārklājuma par darbību noteiktā periodā. Neviens no tiem neaizstāj jūsu pašu piekļuves un datu plūsmu testēšanu.

Pārvērtiet saistības tehniskās prasībās

Pirms reģiona izvēles vai pakalpojumu sniedzēja noteikumu akceptēšanas nosakiet piemērojamos tiesību aktus un saistības pret klientiem. Piemērojamība ir atkarīga no informācijas, apstrādes lomām, nozares, jurisdikcijām un pakalpojumu attiecībām. Pakalpojumu sniedzēja ziņojums vai sertifikāts nepierāda jūsu organizācijas juridisko atbilstību.

Personas datiem, uz kuriem attiecas VDAR, 32. pants prasa riskam atbilstošu drošību; tas nav vispārējs pienākums šifrēt katru datu kopu visos apstākļos. Ja pakalpojumu sniedzējs darbojas kā apstrādātājs, izvērtējiet 28. panta līgumiskās prasības. Starptautiskās nosūtīšanas kārtībai nepieciešams atsevišķs novērtējums. Datu atrašanās vieta vien nepierāda suverenitāti vai atbilstību VDAR, īpaši ja atbalsta piekļuve vai apakšapstrādātāji rada papildu piekļuves ceļus.

Kā praktisku ieteikumu pārvērtiet katru piemērojamo prasību testējamā apgalvojumā: atļautie apstrādes reģioni, apstiprinātie saņēmēji, glabāšanas termiņi, piekļuves ierobežojumi, atjaunošanas mērķi vai paziņošanas par incidentiem nodošana. Lūdziet juridiskajiem un privātuma speciālistiem apstiprināt interpretāciju, kamēr izstrādes komanda nosaka, kā prasība tiks ieviesta un pierādīta.

Pārbaudiet faktisko piekļuvi, nevis tikai iecerētās atļaujas

Nozagti akreditācijas dati, pārmērīgas privilēģijas, publiska koplietošana un iekšēju personu ļaunprātīga izmantošana ir bieži datu atklāšanas ceļi mākonī. Šifrēta krātuve joprojām var izpaust ierakstus caur autorizētu kontu vai lietotni, kas atgriež cita klienta datus.

Ja iespējams, federējiet cilvēku identitātes, lai pieņemšanas darbā, pārcelšanas un aiziešanas procesi sasniegtu mākoņpakalpojumus. Pieprasiet stipru autentifikāciju priviliģētai piekļuvei, ja tiek atbalstīta, dodiet priekšroku pikšķerēšanas noturīgai MFA un nošķiriet ikdienas darbu no administrēšanas. Ārkārtas piekļuvei nepieciešami kontrolēti akreditācijas dati, uzraudzīta izmantošana un testēts atjaunošanas process; tai nevajadzētu kļūt par pastāvīgu apiešanas ceļu.

Darba slodžu identitātēm, ja tiek atbalstīts, dodiet priekšroku šauri ierobežotiem, īslaicīgiem akreditācijas datiem. Pārskatiet uzticamības attiecības: kura darba slodze var uzņemties lomu, ar kādiem nosacījumiem un kurā vidē? Noņemiet iegultos noslēpumus no repozitorijiem un izvietošanas artefaktiem un ierobežojiet piekļuvi pašam noslēpumu pakalpojumam.

Izvērtējiet faktiskās atļaujas, ņemot vērā identitāšu politikas, resursu politikas, lomu uzņemšanos, dalību grupās, koplietošanas saites un organizācijas līmeņa ierobežojumus. „Tikai lasīšana” joprojām var ļaut liela mēroga sensitīvas informācijas izgūšanu. Loma, kas nevar lasīt ierakstus, bet var mainīt lietotni vai atslēgu politiku, var iegūt piekļuvi netieši.

Piekļuves pārskata pierādījumos jānorāda subjekts, resurss, atļautās darbības, biznesa pamatojums, apstiprinātājs un, ja piemērojams, noņemšanas datums. Testējiet aiziešanas procesu un beigušos pagaidu piekļuvi, nevis paļaujieties tikai uz rakstisku procedūru.

Pārbaudiet atklātību un lietotnes uzvedību kopā

Nepareiza konfigurācija bieži apvieno vairākus atsevišķi šķietami saprātīgus iestatījumus. Objektu krātuvei noklusējuma šifrēšana neatbild uz jautājumu, kas var lasīt objektus vai vai koplietošanas politika tos padara publiskus. Izvērtējiet identitāti, resursu politikas, lietotnes uzvedību un uzraudzību kopā.

Pārbaudiet publiskās piekļuves ierobežojumus, ienākošo tīkla trafiku, datubāzu klausītājus, starpkontu uzticamību, parakstīto saišu uzvedību un ārējo koplietošanu. Privātie galapunkti var samazināt atklātību, taču tie neizlabo pārmērīgas privilēģijas vai ievainojamu lietotni. Nošķiriet vides un ierobežojiet piekļuvi produkcijai no izstrādes sistēmām.

Mākoņa API nepieciešama autentifikācija un autorizācija objektu un darbību līmenī. Derīgs lietotāja marķieris nedrīkst ļaut kādam izgūt cita nomnieka ierakstus, mainot identifikatoru. Testējiet eksporta galapunktus, administratīvās darbības, masveida vaicājumus un augšupielādes apstrādātājus. Pieprasījumu biežuma ierobežojumi var samazināt ļaunprātīgu izmantošanu, taču neaizstāj autorizāciju.

Izmantojiet infrastruktūras kā koda pārskatīšanu un politiku pārbaudes, lai novērstu zināmus nedrošus iestatījumus, pēc tam salīdziniet apstiprinātos noteikumus ar izvietoto konfigurāciju. Izmaiņas konsolē, migrācijas un ārkārtas labojumi var radīt novirzi. Reģistrējiet, kāpēc pastāv izņēmumi, to kompensējošās kontroles un to derīguma termiņu. Draudu modelēšana var palīdzēt identificēt ceļus no atklātas saskarnes līdz sensitīviem datiem pirms ieviešanas.

Padariet šifrēšanu un piekļuvi atslēgām par atsevišķām kontrolēm

Aizsargājiet datus pārsūtīšanas laikā, izmantojot modernus autentificētus protokolus un atbilstošu sertifikātu validāciju. Pārskatiet ne tikai publiskos galapunktus, bet arī iekšējos lietotņu savienojumus. Glabātajiem datiem noskaidrojiet, kuri pakalpojumi, replikas, eksporti, momentuzņēmumi un rezerves kopijas ir šifrēti un ar kādu atslēgu kārtību.

Pakalpojumu sniedzēja pārvaldītas atslēgas un klienta pārvaldītas atslēgas atbalsta atšķirīgas darbības izvēles. Izvēlieties, balstoties uz draudu modeli, līgumiskajām prasībām, administratīvo nošķiršanu un atjaunošanas vajadzībām. Klienta pārvaldīta atslēga automātiski nav drošāka, ja viens un tas pats neierobežotais administrators kontrolē gan piekļuvi datiem, gan atslēgu atļaujas.

Dokumentējiet, kurš drīkst šifrēt, atšifrēt, administrēt, atspējot un dzēst atslēgas. Pārskatiet atslēgu politiku izmaiņas un neparastu atšifrēšanas aktivitāti. Izveidojiet rotācijas, atsaukšanas, glabāšanas un atjaunošanas procesus; atkarībā no pakalpojuma atslēgas rotācija ne vienmēr atkārtoti šifrē katru esošo kopiju.

KMS un HSM pakalpojumi var atbalstīt atslēgu aizsardzību un kriptogrāfiskās darbības, taču tie nenoņem dzīves cikla pienākumus. Pirms dzēšanas vai atsaukšanas procesa ieviešanas testējiet atslēgas nepieejamības sekas. Aizsargāta rezerves kopija nav izmantojama, ja tai nepieciešamo atslēgu nevar atjaunot. Atbalstošos kriptogrāfijas lēmumus skatiet rakstā par šifrēšanu un atslēgu pārvaldību.

Uzraugiet datu aktivitāti un saglabājiet reaģēšanas spēju

Žurnalēšanai jāaptver jautājumi, uz kuriem reaģētājiem jāatbild. Administratīvie audita notikumi var parādīt, kurš mainīja politiku, neparādot, kurš lejupielādēja datu kopu. Noskaidrojiet, kur ir pieejama datu piekļuves žurnalēšana, vai tā ir iespējota un kuri notikumi vai pakalpojumi paliek ārpus pārklājuma.

Vāciet attiecīgos identitātes, vadības plaknes, datu piekļuves, lietotņu, atslēgu pārvaldības un koplietošanas notikumus. Saglabājiet kontu un resursu identifikatorus, darbības veicēja identitāti, laikspiedolus, darbības un rezultātus. Aizsargājiet žurnālus pret izmainīšanu un nesankcionētu dzēšanu. Neievietojiet žurnālos sensitīvu saturu vai atkārtoti izmantojamus akreditācijas datus; diagnostikas dati var kļūt par vēl vienu atklātības avotu.

Par prioritāti nosakiet tādus atklāšanas scenārijus kā:

• Ierobežotas piekļuves krātuve kļūst publiski pieejama.
• Jauna ārēja uzticamība vai priviliģētas lomas piešķiršana.
• Neparasti masveida eksporti vai neaktīvas identitātes piekļuve.
• Žurnalēšana tiek atspējota vai mainīts tās galamērķis.
• Rezerves kopiju dzēšana vai atslēgu administrēšanas izmaiņas.

Definējiet reaģētājus un testējiet brīdinājumus kontrolētā vingrinājumā. Noteikums, kas nosūta brīdinājumu uz neuzraudzītu pastkasti, nav efektīvs atklāšanas process. Reģistrējiet vākšanas kļūmes, aizkavētu datu uzņemšanu, jaunizveidotus resursus un pakalpojumu sniedzēja ierobežojumus, nevis pasniedziet informācijas paneli kā pilnīgu pārklājumu.

Incidenta laikā saglabājiet attiecīgos pierādījumus un koordinējiet ierobežošanu starp identitātēm, lietotnēm un krātuvi. Viena marķiera atsaukšana var nepārtraukt citas sesijas vai neapturēt jau notiekošu eksportu. Personas datu aizsardzības pārkāpumu gadījumā saskaņā ar VDAR apstrādātāji bez nepamatotas kavēšanās paziņo pārziņiem. Pārziņi bez nepamatotas kavēšanās un, ja iespējams, 72 stundu laikā pēc tam, kad tiem kļuvis zināms, paziņo uzraudzības iestādei, ja vien nav ticams, ka pārkāpums radīs risku personu tiesībām un brīvībām. Augsta riska pārkāpumu gadījumā bez nepamatotas kavēšanās jāinformē arī skartās personas, ievērojot 34. panta izņēmumus. Saglabājiet paziņošanas vai nepaziņošanas pamatojumu.

Izmantojiet drošības rīkus definētiem jautājumiem

Mākoņdrošības rīki ir visnoderīgākie, ja to tvērums un lēmumu nolūks ir skaidrs:

Sāciet DLP īstenošanu ar reprezentatīvu testēšanu un datu īpašnieku pārskatīšanu. Noteikums, kas bloķē leģitīmu atbalsta darbu, var mudināt lietotājus meklēt nekontrolētus apiešanas ceļus. Ierobežojiet skenerus un uzraudzības aģentus līdz tiem nepieciešamajai piekļuvei; atklāšanas rīks ar plašu lasīšanas piekļuvi pats kļūst par sensitīvu komponentu.

Automatizācija var samazināt atkārtotas pārbaudes un pierādījumu vākšanu. Tā nevar pierādīt, ka neatbalstīts pakalpojums ir drošs vai ka juridiskā interpretācija ir pareiza. Saglabājiet skaidru cilvēka pārskatīšanu būtiskiem konstatējumiem un izņēmumiem.

Pierādiet atjaunošanu neatkarīgi no rezerves kopēšanas statusa

Rezerves kopijas novērš zudumu un bojājumus tikai tad, ja tās var atjaunot atbilstoši pakalpojuma vajadzībām. Kopā ar biznesa īpašnieku nosakiet atjaunošanas punkta mērķus pieļaujamam datu zudumam un atjaunošanas laika mērķus pieļaujamam pārtraukumam.

Nošķiriet replicēšanu, versiju veidošanu, momentuzņēmumus un rezerves kopijas. Replicēšana var kopēt bojājumus vai dzēšanu. Momentuzņēmumi var palikt neaizsargāti pret to pašu administratoru, kurš kontrolē produkciju. Izvēlieties aizsargātas kopijas un administratīvo nošķiršanu atbilstoši draudu modelim, tostarp, ja tiek atbalstīta, noturību pret dzēšanu.

Atjaunojiet reprezentatīvu darba slodzi izolētā vidē. Pārbaudiet datu konsekvenci, lietotnes atkarības, identitātes konfigurāciju, atslēgu pieejamību un patērēto atjaunošanas laiku. Datubāzes atjaunošana vien nepierāda, ka biznesa pakalpojums darbojas. Reģistrējiet kļūmes un pēc novēršanas testējiet atkārtoti.

SaaS atjaunošanu izvērtējiet atsevišķi. Pakalpojumu sniedzēja avārijas atjaunošana var atjaunot platformu, neatceļot jūsu nomnieka nejaušu dzēšanu. Nosakiet pieejamo atjaunošanas detalizācijas līmeni, glabāšanas logus, eksporta iespējas un atbildību par atjaunošanas uzsākšanu. Piemērojiet klasifikācijas un glabāšanas noteikumus arī rezerves kopijām.

Praktisks piemērs: klientu eksporta pakalpojums

Aplūkosim ilustratīvu SaaS komandu, kas izmanto pārvaldītu datubāzi, objektu krātuvi eksportiem un fona procesu. Pieņemsim, ka eksportos ir konfidenciāla klientu kontaktinformācija, klienti piekļūst tikai saviem eksportiem un saskaņotie atjaunošanas mērķi ir četras stundas datu zuduma un astoņas stundas pārtraukuma. Tie ir piemēra pieņēmumi, nevis ieteicami universāli mērķi.

Pakalpojumu sniedzējs darbina pārvaldīto infrastruktūru. Platformas komanda konfigurē tīkla ierobežojumus, identitātes, šifrēšanu un žurnalēšanu. Lietotņu izstrādātāji atbild par nomnieku autorizāciju un eksporta saišu uzvedību. Pakalpojuma īpašnieks apstiprina glabāšanas un atjaunošanas mērķus; drošības komanda pārskata piekļuvi un pierādījumus.

Fona process saņem atļauju lasīt nepieciešamos datubāzes ierakstus un rakstīt eksportus norādītajā krātuvē. Tam nav nepieciešama atļauja mainīt krātuves politiku vai dzēst rezerves kopijas. Lejupielādes iziet caur nomnieka autorizāciju; jebkurām pagaidu saitēm ir ierobežots derīgums, un tās tiek uzskatītas par uzrādītāja akreditācijas datiem. Eksporta faili beidzas atbilstoši apstiprinātajam glabāšanas noteikumam.

Testēšana ietver neautentificētu objekta pieprasījumu, klienta mēģinājumu izgūt cita klienta eksportu un fona procesa mēģinājumu veikt aizliegtu administratīvu darbību. Pārskatītāji arī pārbauda, vai publiskā piekļuve ir bloķēta un vai testa lejupielādes rada sagaidāmos audita notikumus.

Atjaunošanas vingrinājumā tiek pārbaudīta datubāze un lietotnes atkarības attiecībā pret pieņemtajiem atjaunošanas mērķiem. Pierādījumi ietver konfigurācijas eksportus, autorizācijas testu rezultātus, izlases veidā pārbaudītus piekļuves notikumus un atjaunošanas ierakstu. Ja vienā reģionā trūkst datu piekļuves žurnalēšanas, pārskatā tiek reģistrēta šī nepilnība un piešķirta novēršana; veiksmīga testēšana citur to neslēdz.

Saglabājiet tvērumu, izņēmumus un pārskatīšanas lēmumus

Pierādījumos jānorāda konts, resurss, laiks, vākšanas metode un pārskatītājs. Viena konta konfigurācijas eksports nevar apliecināt visu kontu stāvokli. Salīdziniet savāktos resursus ar inventāru un reģistrējiet neizdevušās vākšanas vai nepieejamās vietas.

Katram pakalpojumam uzturiet kompaktu pierādījumu kopumu: tā atbildības karti, apstiprināto bāzes konfigurāciju, pašreizējās konfigurācijas pārbaudes, faktiskās piekļuves pārskatu, žurnalēšanas pārklājumu, atjaunošanas rezultātus un atklātos izņēmumus. Katram izņēmumam nepieciešams īpašnieks, riska pamatojums, kompensējošās kontroles, apstiprinājums, derīguma termiņš un atkārtotas testēšanas nosacījums.

Izmantojiet plānotus pārskatus līdztekus notikumu ierosinātiem pārskatiem. Būtiskām izvietošanas izmaiņām, jauniem reģioniem, piegādātāju maiņai, incidentiem, mainītām datu klasifikācijām un jauniem koplietošanas ceļiem jāierosina atkārtots novērtējums. NIST Cybersecurity Framework sniedz noderīgu organizējošu atsauci, aptverot funkcijas Govern, Identify, Protect, Detect, Respond un Recover; tā ir vadlīnija, nevis pierādījums, ka izvietojums atbilst saviem pienākumiem.

Secani var sasaistīt šo darbu ar prasībām, mērķa objektiem, pierādījumiem, īpašniekiem, uzdevumiem un pārskatīšanas lēmumiem. Modelējiet mākoņpakalpojumu un tā atkarības, pievienojiet konfigurācijas eksportus un testu ierakstus kontrolēm, ko tie pamato, un pārvērtiet trūkstošo pārklājumu piešķirtā darbā. Saglabājiet skaidru cilvēka apstiprinājumu un izsekojamību līdz avotam. Mākoņdrošības rīki joprojām ir tehniskās konfigurācijas un brīdinājumu avots; atbilstības darbvieta saglabā to tvērumu un darbības, ko tie pamato.

Nākamajam inženiertehniskajam pārskatam izvēlieties vienu sensitīvu datu plūsmu. Izsekojiet katru kopiju un piekļuves ceļu, piešķiriet klienta puses pienākumus, testējiet faktiskās atļaujas un atjaunojiet reprezentatīvu darba slodzi. Paplašiniet tvērumu, kad šis pārskats sniedz uzticamus pierādījumus un atkārtojamu procesu.