
Debesijos paslaugų teikėjas valdo dalį saugumo aplinkos. Jūsų komanda vis tiek turi nustatyti, kurias apsaugas ji konfigūruoja, ar jos apima naudojamus duomenis ir paslaugas ir kaip ji žino, kad jos išlieka veiksmingos.
Duomenų saugumas debesijoje apsaugo konfidencialumą, vientisumą ir prieinamumą saugojimo, tvarkymo, dalijimosi ir atkūrimo metu. Jis apima duomenų bazes ir objektų saugyklas, bet taip pat programų leidimus, SaaS eksportus, paslaugų tapatybes, atsargines kopijas ir nešiojamuosius kompiuterius ar automatizavimo sistemas, kurios gali gauti duomenis.
CTO požiūriu bendra atsakomybė tampa naudinga tik tada, kai ji virsta konkrečiais inžineriniais sprendimais: kas konfigūruoja kontrolės priemonę, kas ją stebi, kokie įrodymai patvirtina jos veikimą ir kas veikia, kai ji sugenda. Paslaugų teikėjo saugumo pareiškimas negali atsakyti į šiuos klausimus jūsų diegimui.
Debesijos aplinkos derina nuotoliniu būdu teikiamą infrastruktūrą, platformas ir programas. Viešoji debesija paprastai naudoja paslaugų teikėjo valdomą infrastruktūrą, aptarnaujančią daug klientų; privačioji debesija skirta vienai organizacijai. Nė viena etiketė nenulemia, ar jūsų duomenys tinkamai apsaugoti. Izoliacija, prieigos keliai, veiklos atsakomybė ir atkūrimo tvarka svarbesni už etiketę.
Pradėkite nuo vienos verslo paslaugos ir atsekite jos priklausomybes. Nustatykite debesijos paskyras ar prenumeratas, regionus, paslaugas, duomenų saugyklas, administratorius ir diegimo sistemas. Įtraukite SaaS produktus, kuriuos naudoja pagalbos, finansų ir inžinerijos komandos: gamybinė duomenų bazė gali būti griežtai kontroliuojama, o jos klientų eksportas – gulėti plačiai bendrinamoje darbo erdvėje.
Inventorius turėtų atsakyti į šiuos klausimus:
Debesijos mastelio keitimas ir nuotolinis prieinamumas gali pagerinti veiklą, o valdomos paslaugos gali sumažinti infrastruktūros priežiūrą. Tačiau jos taip pat leidžia lengvai kurti išteklius ir kopijas greičiau, nei vertintojai spėja juos sekti. Todėl saugumo kaina apima tapatybių administravimą, stebėseną, įrodymų rinkimą, atkūrimo testavimą ir tiekėjų priežiūrą, o ne vien saugyklos sąskaitą.
Naudokite valdomą klasifikavimo schemą, susietą su veiksmais. Pavyzdžiui, viešoji, vidinė, konfidenciali ir riboto naudojimo kategorijos gali nulemti dalijimosi taisykles, prieigos peržiūras, žurnalų registravimą ir saugojimą. Apibrėžkite, kuriai kategorijai priklauso klientų identifikatoriai, autentifikavimo paslaptys, finansiniai įrašai, išeitinis kodas ir jautri asmeninė informacija.
Automatinis aptikimas gali padėti rasti nepastebėtus duomenų rinkinius, tačiau rezultatus patvirtinkite su duomenų savininkais. Skeneris gali praleisti suspaustus archyvus ar programai būdingus laukus, o nekenksminga testinė eilutė gali sukelti klaidingai teigiamą rezultatą. Užfiksuokite nenuskenuotas vietas ir imčių apribojimus. Išsamesnė aptikimo darbo eiga aprašyta straipsnyje apie duomenų aptikimą ir privatumą.
Atsakomybės riba keičiasi priklausomai nuo paslaugos modelio ir paslaugų teikėjo įgyvendinimo. Toliau pateiktą lentelę laikykite atspirties tašku, kurį reikia patvirtinti pagal paslaugos dokumentaciją ir sutartis, o ne universaliu paskirstymu.
| Paslaugos modelis | Įprastos paslaugų teikėjo atsakomybės | Kliento sprendimai, kuriuos reikia patikrinti |
|---|---|---|
| Infrastruktūra kaip paslauga | Patalpos, fizinė įranga, pagrindinė virtualizacija | Svečių operacinės sistemos, pataisų diegimas, programos, tapatybės, tinklo taisyklės, duomenų apsauga |
| Valdoma platforma ar duomenų bazė | Infrastruktūra ir nurodytos vykdymo aplinkos ar duomenų bazės operacijos | Prieigos politikos, programos elgsena, pasiekiamumo nustatymai, duomenų naudojimas, žurnalų registravimo parinktys, atsarginių kopijų konfigūracija |
| Programinė įranga kaip paslauga | Talpinamos programos ir pagrindinės platformos veikimas | Nuomininko nustatymai, naudotojų gyvavimo ciklas, dalijimasis, prijungtos programos, saugojimo pasirinkimai, eksportai |
Kiekvienai svarbiai apsaugai užfiksuokite paslaugų teikėjo indėlį, kliento konfigūraciją, veiklos savininką, vertintoją ir įrodymų šaltinį. Venkite įrašų, tokių kaip „šifravimas: paslaugų teikėjas“. Vietoj to rašykite: „Paslaugų teikėjas suteikia valdomą šifravimą; platformos komanda pasirenka raktų konfigūraciją; saugumo komanda peržiūri iššifravimo leidimus; paslaugos savininkas testuoja atkūrimą.“
Greta žmonių naudotojų įtraukite paslaugų tapatybes ir diegimo automatizavimą. Diegimo grandinė, kuri kuria išteklius, keičia prieigos politikas ar gauna paslaptis, yra saugumo ribos dalis. Valdomų paslaugų operatoriams ir išoriniams pagalbos teikėjams taip pat reikia aiškių atsakomybių, net kai jie administruoja infrastruktūrą jūsų vardu.
Nustatykite perdavimo nesėkmes. Jei paslaugų teikėjas praneša apie pažeistus prisijungimo duomenis, kas gauna pranešimą ne darbo valandomis? Jei duomenų bazė nepasiekiama, kas sprendžia, ar atkurti, perjungti į atsarginę sistemą, ar laukti? Kiekvienam kliento pusės rezultatui paskirkite vieną atskaitingą vidinį savininką, net kai darbą atlieka kelios komandos.
Peržiūrėkite paslaugos saugumo dokumentaciją, pranešimus apie incidentus, pagalbos prieigos tvarką, subtvarkytojus, ištrynimo elgseną, atkūrimo galimybes ir prieinamus audito žurnalus. Patikrinkite, ar atitinkamas paskyros lygis iš tikrųjų apima funkcijas, kurių reikia jūsų sprendimui.
Užtikrinimo dokumentų taikymo sritį reikia peržiūrėti. SOC 2 ataskaita yra atestavimo ataskaita, o ne sertifikatas. ISO 27001 sertifikatas susijęs su apibrėžtos taikymo srities informacijos saugumo valdymo sistema, o ne įrodo, kad jūsų nuomininkas sukonfigūruotas saugiai. Patikrinkite aprėptas paslaugas, ataskaitinį laikotarpį, išimtis ir ataskaitoje nurodytas kliento kontrolės priemones.
Kai aktualu, BSI C5 katalogas pateikia debesijos užtikrinimo kriterijus. Atskirkite 1 tipo vertinimą, apimantį projektą ir įgyvendinimą tam tikru momentu, nuo 2 tipo aprėpties, apimančios veikimą per tam tikrą laikotarpį. Nė vienas iš jų nepakeičia jūsų pačių prieigos ir duomenų srautų testavimo.
Prieš pasirinkdami regioną ar priimdami paslaugų teikėjo sąlygas, nustatykite taikomą teisę ir įsipareigojimus klientams. Taikymas priklauso nuo informacijos, duomenų tvarkymo vaidmenų, sektoriaus, jurisdikcijų ir paslaugų santykių. Paslaugų teikėjo ataskaita ar sertifikatas neįrodo jūsų organizacijos teisinės atitikties.
Asmens duomenims, kuriems taikomas BDAR, 32 straipsnis reikalauja rizikai tinkamo saugumo; tai nėra visuotinė prievolė šifruoti kiekvieną duomenų rinkinį bet kokiomis aplinkybėmis. Kai paslaugų teikėjas veikia kaip duomenų tvarkytojas, įvertinkite 28 straipsnio sutartinius reikalavimus. Tarptautinių perdavimų tvarkai reikia atskiro vertinimo. Vien duomenų buvimo vieta neįrodo suverenumo ar BDAR atitikties, ypač kai pagalbos prieiga ar subtvarkytojai sukuria papildomų prieigos kelių.
Kaip praktinė rekomendacija, kiekvieną taikomą reikalavimą paverskite patikrinamu teiginiu: leidžiami duomenų tvarkymo regionai, patvirtinti gavėjai, saugojimo terminai, prieigos apribojimai, atkūrimo tikslai ar pranešimų apie incidentus perdavimo taškai. Teisės ir privatumo specialistai turėtų patvirtinti aiškinimą, o inžinerija – nustatyti, kaip reikalavimas bus įgyvendintas ir įrodytas.
Pavogti prisijungimo duomenys, pertekliniai leidimai, viešas dalijimasis ir vidinių asmenų piktnaudžiavimas yra dažni duomenų atskleidimo debesijoje keliai. Šifruota saugykla vis tiek gali atskleisti įrašus per įgaliotą paskyrą ar programą, kuri grąžina kito kliento duomenis.
Kai įmanoma, federuokite žmonių tapatybes, kad darbuotojų atėjimo, perkėlimo ir išėjimo procesai pasiektų debesijos paslaugas. Privilegijuotai prieigai reikalaukite stiprios autentifikacijos, kai palaikoma, rinkitės sukčiavimui atsparų MFA ir atskirkite kasdienį darbą nuo administravimo. Avarinei prieigai reikia kontroliuojamų prisijungimo duomenų, stebimo naudojimo ir išbandyto atkūrimo proceso; ji neturėtų tapti nuolatiniu apėjimu.
Darbo krūvių tapatybėms, kai palaikoma, rinkitės siauros apimties trumpalaikius prisijungimo duomenis. Peržiūrėkite pasitikėjimo ryšius: kuris darbo krūvis gali prisiimti vaidmenį, kokiomis sąlygomis ir kurioje aplinkoje? Pašalinkite įterptas paslaptis iš repozitorijų ir diegimo artefaktų bei apribokite prieigą prie pačios paslapčių paslaugos.
Vertinkite faktinius leidimus atsižvelgdami į tapatybių politikas, išteklių politikas, vaidmenų prisiėmimą, narystę grupėse, dalijimosi nuorodas ir organizacijos lygio apribojimus. „Tik skaitymas“ vis tiek gali leisti didelio masto jautrios informacijos išgavimą. Vaidmuo, kuris negali skaityti įrašų, bet gali pakeisti programą ar raktų politiką, gali gauti prieigą netiesiogiai.
Prieigos peržiūros įrodymuose turėtų būti nurodytas subjektas, išteklius, leidžiami veiksmai, verslo pagrindimas, tvirtintojas ir, kai taikoma, panaikinimo data. Testuokite išėjimo iš darbo procesą ir pasibaigusią laikiną prieigą, o ne pasikliaukite vien rašytine procedūra.
Netinkama konfigūracija dažnai derina kelis atskirai tikėtinai atrodančius nustatymus. Objektų saugyklos atveju numatytasis šifravimas neatsako į klausimą, kas gali skaityti objektus ar ar dalijimosi politika juos padaro viešais. Tapatybes, išteklių politikas, programos elgseną ir stebėseną nagrinėkite kartu.
Patikrinkite viešosios prieigos apribojimus, įeinantį tinklo srautą, duomenų bazių klausytojus, tarpusavio paskyrų pasitikėjimą, pasirašytų nuorodų elgseną ir išorinį dalijimąsi. Privatieji galiniai taškai gali sumažinti pasiekiamumą, tačiau jie neištaiso perteklinių leidimų ar pažeidžiamos programos. Atskirkite aplinkas ir apribokite prieigą prie gamybinės aplinkos iš kūrimo sistemų.
Debesijos API reikia autentifikavimo ir autorizavimo objekto ir veiksmo lygmeniu. Galiojantis naudotojo prieigos raktas neturi leisti asmeniui gauti kito nuomininko įrašų pakeitus identifikatorių. Testuokite eksporto galinius taškus, administracines operacijas, masines užklausas ir įkėlimo apdorojimo funkcijas. Užklausų dažnio ribojimai gali sumažinti piktnaudžiavimą, tačiau nepakeičia autorizavimo.
Naudokite infrastruktūros kaip kodo peržiūrą ir politikų patikras, kad užkirstumėte kelią žinomiems nesaugiems nustatymams, tada palyginkite patvirtintas taisykles su įdiegta konfigūracija. Pakeitimai konsolėje, migracijos ir skubūs taisymai gali sukelti nuokrypį. Užfiksuokite, kodėl egzistuoja išimtys, kokios jų kompensuojamosios kontrolės priemonės ir kada jos baigia galioti. Grėsmių modeliavimas gali padėti dar prieš įgyvendinimą nustatyti kelius nuo pasiekiamos sąsajos iki jautrių duomenų.
Duomenis perdavimo metu apsaugokite naudodami modernius autentifikuotus protokolus ir tinkamą sertifikatų patvirtinimą. Peržiūrėkite ne tik viešus galinius taškus, bet ir vidinius programų ryšius. Saugomiems duomenims nustatykite, kurios paslaugos, kopijos, eksportai, momentinės kopijos ir atsarginės kopijos yra šifruojamos ir kokia raktų tvarka.
Paslaugų teikėjo valdomi raktai ir kliento valdomi raktai palaiko skirtingus veiklos pasirinkimus. Rinkitės atsižvelgdami į grėsmių modelį, sutartinius reikalavimus, administracinį atskyrimą ir atkūrimo poreikius. Kliento valdomas raktas automatiškai nėra saugesnis, jei tas pats neribotas administratorius kontroliuoja ir prieigą prie duomenų, ir raktų leidimus.
Dokumentuokite, kas gali šifruoti, iššifruoti, administruoti, išjungti ir ištrinti raktus. Peržiūrėkite raktų politikos pakeitimus ir neįprastą iššifravimo veiklą. Nustatykite raktų keitimo, atšaukimo, saugojimo ir atkūrimo procesus; priklausomai nuo paslaugos, rakto pakeitimas nebūtinai iš naujo užšifruoja kiekvieną esamą kopiją.
KMS ir HSM paslaugos gali padėti apsaugoti raktus ir atlikti kriptografines operacijas, tačiau jos nepanaikina gyvavimo ciklo atsakomybių. Prieš įgyvendindami ištrynimo ar atšaukimo procesą, išbandykite rakto nepasiekiamumo pasekmes. Apsaugota atsarginė kopija netinkama naudoti, jei jai reikalingo rakto neįmanoma atkurti. Susiję kriptografiniai sprendimai aprašyti straipsnyje apie šifravimą ir raktų valdymą.
Žurnalų registravimas turi apimti klausimus, į kuriuos turi atsakyti reaguojantys asmenys. Administraciniai audito įvykiai gali parodyti, kas pakeitė politiką, bet neparodyti, kas atsisiuntė duomenų rinkinį. Nustatykite, kur prieinamas duomenų prieigos žurnalų registravimas, ar jis įjungtas ir kurie įvykiai ar paslaugos lieka neaprėpti.
Rinkite atitinkamus tapatybių, valdymo plokštumos, duomenų prieigos, programų, raktų valdymo ir dalijimosi įvykius. Išsaugokite paskyrų ir išteklių identifikatorius, veikėjo tapatybę, laiko žymas, veiksmus ir rezultatus. Apsaugokite žurnalus nuo pakeitimo ir neleistino ištrynimo. Venkite žurnaluose laikyti jautrų turinį ar pakartotinai naudojamus prisijungimo duomenis; diagnostiniai duomenys gali tapti dar vienu atskleidimo šaltiniu.
Pirmenybę teikite tokiems aptikimo scenarijams:
Apibrėžkite reaguojančius asmenis ir išbandykite įspėjimus kontroliuojamomis pratybomis. Taisyklė, siunčianti pranešimus į niekieno neprižiūrimą pašto dėžutę, nėra veiksmingas aptikimo procesas. Užfiksuokite rinkimo nesėkmes, vėluojantį duomenų gavimą, naujai sukurtus išteklius ir paslaugų teikėjo apribojimus, o ne pateikite prietaisų skydelį kaip visišką aprėptį.
Incidento metu išsaugokite atitinkamus įrodymus ir koordinuokite suvaldymą tapatybių, programų ir saugyklų lygmeniu. Vieno prieigos rakto atšaukimas gali nenutraukti kitų seansų ar jau vykstančio eksporto. Asmens duomenų saugumo pažeidimų atveju pagal BDAR duomenų tvarkytojai praneša duomenų valdytojams nepagrįstai nedelsdami. Duomenų valdytojai praneša priežiūros institucijai nepagrįstai nedelsdami ir, jei įmanoma, ne vėliau kaip per 72 valandas nuo sužinojimo, nebent pažeidimas neturėtų kelti pavojaus asmenų teisėms ir laisvėms. Apie didelį pavojų keliančius pažeidimus taip pat reikia nepagrįstai nedelsiant pranešti paveiktiems asmenims, atsižvelgiant į 34 straipsnio išimtis. Išsaugokite pranešimo arba nepranešimo argumentus.
Debesijos saugumo įrankiai naudingiausi tada, kai aiški jų taikymo sritis ir sprendimų tikslas:
| Įrankių kategorija | Naudingas klausimas | Apribojimas, kurį reikia išnagrinėti |
|---|---|---|
| Debesijos saugumo būklės valdymas (CSPM) | Kurios įdiegtos konfigūracijos pažeidžia bazinę liniją? | Nepalaikomos paslaugos, paskyros ir rinkimo leidimai |
| Debesijos programų apsaugos platforma (CNAPP) | Kaip sąveikauja konfigūracijos, tapatybių, pažeidžiamumų ir darbo krūvių radiniai? | Faktiškai įdiegti moduliai ir aprėptis visame programos gyvavimo cikle |
| Duomenų saugumo būklės valdymas (DSPM) | Kur yra jautrūs duomenys ir kokie pasiekiamumo keliai juos veikia? | Klasifikavimo tikslumas ir matomumas šifruotuose ar neįprastuose formatuose |
| Duomenų nutekėjimo prevencija (DLP) | Ar galima aptikti ar apriboti jautrių duomenų perdavimus? | Nestebimi kanalai, klaidingai teigiami rezultatai ir verslo procesų sutrikdymas |
DLP taikymą pradėkite nuo reprezentatyvaus testavimo ir duomenų savininkų peržiūros. Taisyklė, blokuojanti teisėtą pagalbos darbą, gali paskatinti naudotojus ieškoti nekontroliuojamų apėjimo būdų. Skenerių ir stebėsenos agentų prieigą apribokite tik tuo, ko jiems reikia; plačią skaitymo prieigą turintis aptikimo įrankis pats tampa jautriu komponentu.
Automatizavimas gali sumažinti pasikartojančių patikrų ir įrodymų rinkimo darbą. Jis negali įrodyti, kad nepalaikoma paslauga yra saugi ar kad teisinis aiškinimas teisingas. Reikšmingiems radiniams ir išimtims žmogaus peržiūrą palikite aiškią.
Atsarginės kopijos apsaugo nuo praradimo ir sugadinimo tik tada, jei jas galima atkurti per paslaugai reikalingą laiką. Kartu su verslo savininku nustatykite atkūrimo taško tikslus toleruotinam duomenų praradimui ir atkūrimo laiko tikslus toleruotinam veiklos sutrikimui.
Atskirkite replikaciją, versijų valdymą, momentines kopijas ir atsargines kopijas. Replikacija gali nukopijuoti sugadinimą ar ištrynimą. Momentinės kopijos gali likti pažeidžiamos to paties administratoriaus, kuris kontroliuoja gamybinę aplinką. Pasirinkite grėsmių modeliui tinkamas apsaugotas kopijas ir administracinį atskyrimą, įskaitant, kai palaikoma, atsparumą ištrynimui.
Atkurkite reprezentatyvų darbo krūvį izoliuotoje aplinkoje. Patikrinkite duomenų nuoseklumą, programų priklausomybes, tapatybių konfigūraciją, raktų prieinamumą ir atkūrimo trukmę. Vien duomenų bazės atkūrimas neįrodo, kad verslo paslauga veikia. Užfiksuokite nesėkmes ir pakartotinai testuokite po ištaisymo.
SaaS atkūrimą vertinkite atskirai. Paslaugų teikėjo nelaimių atkūrimas gali atkurti platformą, bet neatšaukti atsitiktinio duomenų ištrynimo jūsų nuomininke. Nustatykite prieinamą atkūrimo detalumą, saugojimo laikotarpius, eksporto galimybes ir atsakomybę už atkūrimo inicijavimą. Klasifikavimo ir saugojimo taisykles taikykite ir atsarginėms kopijoms.
Panagrinėkime iliustracinę SaaS komandą, kuri naudoja valdomą duomenų bazę, objektų saugyklą eksportams ir foninį procesą. Tarkime, eksportuose yra konfidenciali klientų kontaktinė informacija, klientai gali pasiekti tik savo eksportus, o sutarti atkūrimo tikslai yra keturios valandos duomenų praradimo ir aštuonios valandos veiklos sutrikimo. Tai pavyzdinės prielaidos, o ne rekomenduojami universalūs tikslai.
Paslaugų teikėjas valdo valdomą infrastruktūrą. Platformos komanda konfigūruoja tinklo apribojimus, tapatybes, šifravimą ir žurnalų registravimą. Programų inžinieriai atsako už nuomininkų autorizavimą ir eksporto nuorodų elgseną. Paslaugos savininkas tvirtina saugojimo ir atkūrimo tikslus; saugumo komanda peržiūri prieigą ir įrodymus.
Foninis procesas gauna leidimą skaityti reikiamus duomenų bazės įrašus ir rašyti eksportus į nurodytą saugyklą. Jam nereikia leidimo keisti saugyklos politikos ar trinti atsarginių kopijų. Atsisiuntimai praeina nuomininko autorizavimą; visos laikinos nuorodos turi ribotą galiojimą ir laikomos pateikėjo prisijungimo duomenimis. Eksporto failai nustoja galioti pagal patvirtintą saugojimo taisyklę.
Testavimas apima neautentifikuotą objekto užklausą, kliento bandymą gauti kito kliento eksportą ir foninio proceso bandymą atlikti draudžiamą administracinį veiksmą. Vertintojai taip pat patikrina, ar vieša prieiga užblokuota ir ar testiniai atsisiuntimai sukuria laukiamus audito įvykius.
Atkūrimo pratybos patikrina duomenų bazę ir programų priklausomybes pagal numatytus atkūrimo tikslus. Įrodymai apima konfigūracijos eksportus, autorizavimo testų rezultatus, atrinktus prieigos įvykius ir atkūrimo įrašą. Jei viename regione trūksta duomenų prieigos žurnalų registravimo, peržiūroje ši spraga užfiksuojama ir priskiriamas ištaisymas; sėkmingas testavimas kitur jos neuždaro.
Įrodymuose turėtų būti nurodyta paskyra, išteklius, laikas, rinkimo metodas ir vertintojas. Vienos paskyros konfigūracijos eksportas negali įrodyti visų paskyrų būklės. Palyginkite surinktus išteklius su inventoriumi ir užfiksuokite nepavykusius rinkimus ar nepasiekiamas vietas.
Kiekvienai paslaugai palaikykite kompaktišką įrodymų rinkinį: jos atsakomybių žemėlapį, patvirtintą bazinę liniją, dabartinės konfigūracijos patikras, faktinės prieigos peržiūrą, žurnalų registravimo aprėptį, atkūrimo rezultatus ir atviras išimtis. Kiekvienai išimčiai reikia savininko, rizikos pagrindimo, kompensuojamųjų kontrolės priemonių, patvirtinimo, galiojimo pabaigos ir pakartotinio testavimo sąlygos.
Greta planinių peržiūrų naudokite įvykiais grindžiamas inicijavimo sąlygas. Reikšmingi diegimo pokyčiai, nauji regionai, tiekėjų pasikeitimai, incidentai, pakeistos duomenų klasifikacijos ir nauji dalijimosi keliai turėtų paskatinti pakartotinį vertinimą. NIST kibernetinio saugumo sistema yra naudinga organizavimo nuoroda pagal funkcijas Govern, Identify, Protect, Detect, Respond ir Recover; tai gairės, o ne įrodymas, kad diegimas atitinka savo pareigas.
Secani gali susieti šį darbą su reikalavimais, tiksliniais objektais, įrodymais, savininkais, užduotimis ir peržiūros sprendimais. Sumodeliuokite debesijos paslaugą ir jos priklausomybes, pridėkite konfigūracijos eksportus ir testų įrašus prie kontrolės priemonių, kurias jie pagrindžia, ir trūkstamą aprėptį paverskite priskirtu darbu. Žmogaus patvirtinimą ir šaltinių atsekamumą palikite aiškius. Debesijos saugumo įrankiai lieka techninės konfigūracijos ir įspėjimų šaltiniu; atitikties darbo erdvė išsaugo jų taikymo sritį ir veiksmus, kuriuos jie pagrindžia.
Kitai inžinerinei peržiūrai pasirinkite vieną jautrių duomenų srautą. Atsekite kiekvieną kopiją ir prieigos kelią, paskirstykite kliento pusės atsakomybes, išbandykite faktinius leidimus ir atkurkite reprezentatyvų darbo krūvį. Plėskite taikymo sritį, kai ši peržiūra duos patikimų įrodymų ir pakartojamą procesą.
Secani sujungia aprėptis, įrodymus, užduotis ir DI agentus vienoje bendroje darbo erdvėje.
Susiekite kritines paslaugas su atkūrimo tikslais, priklausomybėmis, pratybomis ir taisomaisiais veiksmais, kad tęstinumo planai atspindėtų faktinius gebėjimus.
Derinkite pasikartojančias technines patikras ir periodinį vertinimą, aiškiai apibrėždami aprėptį, duomenų rinkimo būklę, ribines vertes ir atsakomybę už tolesnius veiksmus.
Sukurkite naudingą duomenų inventorių atsekdami šaltinius, kopijas, atsakingus asmenis, tiekėjus, saugojimą ir ištrynimą, o ne vien išvardydami taikomąsias programas.