Felhőalapú adatbiztonság: tegye konkréttá a megosztott felelősséget

A felhőszolgáltató a biztonsági környezet egy részét üzemelteti. Csapatának azonban továbbra is meg kell állapítania, mely védelmi intézkedéseket konfigurálja, kiterjednek-e azok a használt adatokra és szolgáltatásokra, és honnan tudja, hogy továbbra is hatékonyak.

A felhőalapú adatbiztonság a bizalmas jelleget, az integritást és a rendelkezésre állást védi a tárolás, a feldolgozás, a megosztás és a helyreállítás során. Ide tartoznak az adatbázisok és az objektumtárak, de az alkalmazásjogosultságok, a SaaS-exportok, a szolgáltatásidentitások, a mentések, valamint azok a laptopok vagy automatizálási rendszerek is, amelyek adatokat tudnak lekérni.

Egy CTO szemszögéből a megosztott felelősség csak akkor válik hasznossá, ha konkrét mérnöki döntéseket eredményez: ki konfigurál egy kontrollt, ki felügyeli, milyen bizonyíték igazolja a működését, és ki lép, ha meghibásodik. Egy szolgáltató biztonsági nyilatkozata ezekre a kérdésekre nem tud választ adni az Ön telepítése esetében.

Határozza meg a határt, mielőtt kontrollokat választ

A felhőkörnyezetek távolról nyújtott infrastruktúrát, platformokat és alkalmazásokat kombinálnak. A nyilvános felhő általában szolgáltató által üzemeltetett, több ügyfelet kiszolgáló infrastruktúrát használ; a privát felhő egyetlen szervezet számára dedikált. Egyik megnevezés sem dönti el, hogy az adatai megfelelő védelemben részesülnek-e. Az elkülönítés, a hozzáférési útvonalak, az operatív felelősség és a helyreállítási megoldások többet számítanak, mint a megnevezés.

Kezdjen egyetlen üzleti szolgáltatással, és kövesse végig a függőségeit. Azonosítsa a felhőfiókokat vagy előfizetéseket, a régiókat, a szolgáltatásokat, az adattárakat, az adminisztrátorokat és a telepítési rendszereket. Vegye fel az ügyfélszolgálat, a pénzügy és a fejlesztés által használt SaaS-termékeket is: egy éles adatbázis lehet szigorúan kontrollált, miközben az ügyféladat-exportja egy széles körben megosztott munkaterületen hever.

A leltárnak a következő kérdésekre kell választ adnia:

• Milyen információkat tárolnak vagy dolgoznak fel, és ki a gazdája az üzleti célnak?
• Hol vannak az elsődleges rekordok, a replikák, a naplók, az exportok, a gyorsítótárak és a mentési másolatok?
• Mely személyek, munkaterhelések, beszállítók és külső címzettek férhetnek hozzájuk?
• Mely fiókok, régiók és szolgáltatások jóváhagyottak, és hogyan derülnek ki az újak?
• Milyen megőrzési, törlési, rendelkezésre állási és szerződéses követelmények vonatkoznak rájuk?

A felhő skálázhatósága és távoli elérhetősége javíthatja a működést, a menedzselt szolgáltatások pedig csökkenthetik az infrastruktúra-karbantartást. Ugyanakkor megkönnyítik azt is, hogy erőforrások és másolatok gyorsabban jöjjenek létre, mint ahogy a felülvizsgálók követni tudják őket. A biztonság költségébe ezért beletartozik az identitásadminisztráció, a felügyelet, a bizonyítékgyűjtés, a helyreállítási tesztelés és a beszállítók felügyelete is, nem csak a tárhelyszámla.

Az információkat ott osztályozza, ahol ténylegesen vannak

Használjon kezelhető, cselekvésekhez kötött osztályozási sémát. Például a nyilvános, belső, bizalmas és korlátozott kategóriák meghatározhatják a megosztási szabályokat, a hozzáférés-felülvizsgálatokat, a naplózást és a megőrzést. Határozza meg, melyik kategória fedi le az ügyfélazonosítókat, a hitelesítési titkokat, a pénzügyi nyilvántartásokat, a forráskódot és az érzékeny személyes információkat.

Az automatizált adatfeltárás segíthet a figyelmen kívül hagyott adatkészletek megtalálásában, de az eredményeket validálja az adatgazdákkal. Egy szkenner kihagyhatja a tömörített archívumokat vagy az alkalmazásspecifikus mezőket, míg egy ártalmatlan tesztkarakterlánc téves riasztást válthat ki. Rögzítse a nem szkennelt helyeket és a mintavételezés korlátait. Teljesebb feltárási munkafolyamatért lásd az adatfeltárásról és adatvédelemről szóló cikket.

Térképezze fel a felelősséget szolgáltatásonként

A felelősségi határ a szolgáltatási modelltől és a szolgáltató megvalósításától függően változik. Az alábbiakat tekintse kiindulópontnak, amelyet a szolgáltatás dokumentációjával és a szerződésekkel kell összevetni, nem általános felosztásnak.

Minden fontos védelmi intézkedésnél rögzítse a szolgáltató hozzájárulását, az ügyféloldali konfigurációt, az üzemeltetési felelőst, a felülvizsgálót és a bizonyíték forrását. Kerülje az olyan bejegyzéseket, mint „titkosítás: szolgáltató”. Írja helyette ezt: „A szolgáltató menedzselt titkosítást biztosít; a platformcsapat választja ki a kulcskonfigurációt; a biztonsági terület felülvizsgálja a visszafejtési jogosultságokat; a szolgáltatásgazda teszteli a helyreállítást.”

Az emberi felhasználók mellett vegye fel a szolgáltatásidentitásokat és a telepítési automatizálást is. Egy pipeline, amely erőforrásokat hoz létre, hozzáférési szabályokat módosít vagy titkokat kér le, a biztonsági határ része. A menedzselt szolgáltatások üzemeltetőinek és a külső támogatási szolgáltatóknak is kifejezett felelősségekre van szükségük, még akkor is, ha az Ön nevében adminisztrálják az infrastruktúrát.

Azonosítsa az átadási hibákat. Ha a szolgáltató kompromittált hitelesítő adatot jelez, ki kapja meg az értesítést munkaidőn kívül? Ha egy adatbázis elérhetetlen, ki dönti el, hogy helyreállítanak, átállnak egy tartalékra vagy várnak? Minden ügyféloldali eredményhez rendeljen egyetlen elszámoltatható belső felelőst, még akkor is, ha a munkát több csapat végzi.

Értékelje a szolgáltatói garanciákat anélkül, hogy túlterjesztené őket

Tekintse át a szolgáltatás biztonsági dokumentációját, az incidenskommunikációt, a támogatási hozzáférésre vonatkozó megoldásokat, a további adatfeldolgozókat, a törlés működését, a helyreállítási lehetőségeket és a rendelkezésre álló auditnaplókat. Ellenőrizze, hogy az adott fiókszint ténylegesen tartalmazza-e a kialakításához szükséges funkciókat.

A garanciális dokumentumok hatókörét felül kell vizsgálni. A SOC 2 jelentés attesztációs jelentés, nem tanúsítvány. Az ISO 27001 tanúsítás egy meghatározott hatókörű információbiztonsági irányítási rendszerre vonatkozik, nem bizonyítja, hogy az Ön bérlője biztonságosan van konfigurálva. Ellenőrizze a lefedett szolgáltatásokat, a jelentési időszakot, a kivételeket és a jelentésben azonosított ügyféloldali kontrollokat.

Adott esetben a BSI C5 katalógusa felhőre vonatkozó garanciális kritériumokat ad. Különböztesse meg a tervezés és a megvalósítás egy adott időpontra vonatkozó, 1. típusú értékelését a működés egy időszakra kiterjedő, 2. típusú lefedésétől. Egyik sem helyettesíti a saját hozzáférési és adatfolyamainak tesztelését.

Fordítsa le a kötelezettségeket műszaki követelményekre

Mielőtt régiót választ vagy elfogadja a szolgáltatói feltételeket, határozza meg az alkalmazandó jogot és az ügyfeleknek tett vállalásokat. Az alkalmazhatóság az információktól, az adatkezelési szerepektől, az ágazattól, a joghatóságoktól és a szolgáltatási kapcsolatoktól függ. Egy szolgáltatói jelentés vagy tanúsítvány nem bizonyítja a szervezete jogszabályi megfelelését.

A GDPR hatálya alá tartozó személyes adatok esetében a 32. cikk a kockázattal arányos biztonságot ír elő; nem általános kötelezettség arra, hogy minden körülmények között minden adatkészletet titkosítsanak. Ha a szolgáltató adatfeldolgozóként jár el, értékelje a 28. cikk szerinti szerződéses követelményeket. A nemzetközi adattovábbítási megoldások külön értékelést igényelnek. Az adatok helye önmagában nem bizonyítja a szuverenitást vagy a GDPR-nak való megfelelést, különösen ha a támogatási hozzáférés vagy a további adatfeldolgozók további hozzáférési útvonalakat teremtenek.

Gyakorlati ajánlásként fordítson le minden alkalmazandó követelményt egy tesztelhető állításra: engedélyezett adatkezelési régiók, jóváhagyott címzettek, megőrzési idők, hozzáférési korlátozások, helyreállítási célok vagy az incidensbejelentési átadások. A jogi és adatvédelmi szakemberek erősítsék meg az értelmezést, miközben a fejlesztés meghatározza, hogyan valósítják meg és bizonyítják a követelményt.

A tényleges hozzáférést ellenőrizze, ne csak a szándékolt jogosultságokat

Az ellopott hitelesítő adatok, a túlzott jogosultságok, a nyilvános megosztás és a belső visszaélés a felhőbeli adatkitettség gyakori útvonalai. Egy titkosított tár is kiszolgáltathat rekordokat egy jogosult fiókon vagy egy olyan alkalmazáson keresztül, amely rossz ügyfél adatait adja vissza.

Ahol lehetséges, federálja az emberi identitásokat, hogy a belépési, áthelyezési és kilépési folyamatok elérjék a felhőszolgáltatásokat is. Írjon elő erős hitelesítést a kiemelt hozzáféréshez, ahol támogatott, részesítse előnyben az adathalászatnak ellenálló MFA-t, és válassza külön a rutinmunkát az adminisztrációtól. A vészhelyzeti hozzáféréshez kontrollált hitelesítő adatok, felügyelt használat és tesztelt helyreállítási folyamat kell; nem válhat állandó kerülőúttá.

A munkaterhelés-identitásoknál, ahol támogatott, részesítse előnyben a szűk hatókörű, rövid élettartamú hitelesítő adatokat. Vizsgálja felül a bizalmi kapcsolatokat: melyik munkaterhelés veheti fel az adott szerepet, milyen feltételek mellett és melyik környezetben? Távolítsa el a beágyazott titkokat a repositorykból és a telepítési artefaktumokból, és korlátozza a hozzáférést magához a titokkezelő szolgáltatáshoz is.

Értékelje a tényleges jogosultságokat az identitásszabályok, az erőforrásszabályok, a szerepfelvételek, a csoporttagságok, a megosztási linkek és a szervezeti szintű korlátozások összességében. A „csak olvasás” is lehetővé teheti érzékeny információk nagymértékű kinyerését. Egy szerep, amely nem olvashat rekordokat, de módosíthatja az alkalmazást vagy a kulcsszabályt, közvetetten hozzáférést szerezhet.

A hozzáférés-felülvizsgálati bizonyítéknak azonosítania kell a résztvevőt, az erőforrást, az engedélyezett műveleteket, az üzleti indoklást, a jóváhagyót és adott esetben az eltávolítás dátumát. Tesztelje a kiléptetést és a lejárt ideiglenes hozzáférést, ahelyett hogy kizárólag egy írott eljárásra hagyatkozna.

Vizsgálja együtt a kitettséget és az alkalmazás viselkedését

A hibás konfiguráció gyakran több, egyenként hihetőnek tűnő beállítás kombinációja. Egy objektumtárnál az alapértelmezett titkosítás nem válaszolja meg, ki olvashatja az objektumokat, vagy hogy egy megosztási szabály nyilvánossá teszi-e őket. Vizsgálja együtt az identitást, az erőforrásszabályokat, az alkalmazás viselkedését és a felügyeletet.

Ellenőrizze a nyilvános hozzáférés korlátozásait, a bejövő hálózati forgalmat, az adatbázis-figyelőket, a fiókok közötti bizalmat, az aláírt linkek működését és a külső megosztást. A privát végpontok csökkenthetik a kitettséget, de nem javítják ki a túlzott jogosultságokat vagy egy sérülékeny alkalmazást. Válassza szét a környezeteket, és korlátozza az éles hozzáférést a fejlesztési rendszerekből.

A felhőbeli API-knak objektum- és műveletszintű hitelesítésre és jogosultságkezelésre van szükségük. Egy érvényes felhasználói token nem teheti lehetővé, hogy valaki egy azonosító megváltoztatásával egy másik bérlő rekordjait kérje le. Tesztelje az exportvégpontokat, az adminisztratív műveleteket, a tömeges lekérdezéseket és a feltöltéskezelőket. A sebességkorlátok csökkenthetik a visszaéléseket, de nem helyettesítik a jogosultságkezelést.

Használjon infrastruktúra-mint-kód felülvizsgálatot és szabályellenőrzéseket az ismert nem biztonságos beállítások megelőzésére, majd vesse össze a jóváhagyott szabályokat a telepített konfigurációval. A konzolon végzett módosítások, a migrációk és a sürgősségi javítások eltérést okozhatnak. Rögzítse, miért léteznek kivételek, milyen kompenzáló kontrollok tartoznak hozzájuk, és mikor járnak le. A fenyegetésmodellezés még a megvalósítás előtt segíthet azonosítani a kitett interfésztől az érzékeny adatokig vezető útvonalakat.

Kezelje külön kontrollként a titkosítást és a kulcshozzáférést

Az átvitel közbeni adatokat korszerű, hitelesített protokollokkal és megfelelő tanúsítványvalidálással védje. Ne csak a nyilvános végpontokat, hanem a belső alkalmazáskapcsolatokat is vizsgálja felül. A tárolt adatoknál állapítsa meg, mely szolgáltatások, replikák, exportok, pillanatképek és mentések titkosítottak, és milyen kulcskonstrukcióval.

A szolgáltató által kezelt kulcsok és az ügyfél által kezelt kulcsok eltérő operatív döntéseket támogatnak. A választás alapja a fenyegetésmodell, a szerződéses követelmények, az adminisztratív elkülönítés és a helyreállítási igények legyenek. Egy ügyfél által kezelt kulcs nem automatikusan biztonságosabb, ha ugyanaz a korlátlan jogosultságú adminisztrátor rendelkezik az adathozzáférés és a kulcsjogosultságok felett is.

Dokumentálja, ki titkosíthat, ki fejthet vissza, ki adminisztrálhat, ki tilthat le és ki törölhet kulcsokat. Vizsgálja felül a kulcsszabályok módosításait és a szokatlan visszafejtési tevékenységet. Alakítson ki kulcscsere-, visszavonási, megőrzési és helyreállítási folyamatokat; a szolgáltatástól függően egy kulcs cseréje nem feltétlenül titkosítja újra az összes meglévő másolatot.

A KMS- és HSM-szolgáltatások támogathatják a kulcsvédelmet és a kriptográfiai műveleteket, de nem szüntetik meg az életciklussal kapcsolatos felelősségeket. Mielőtt törlési vagy visszavonási folyamatot vezetne be, tesztelje a kulcs elérhetetlenségének következményeit. Egy védett mentés használhatatlan, ha a hozzá szükséges kulcs nem állítható helyre. A kapcsolódó kriptográfiai döntésekért lásd a titkosításról és kulcskezelésről szóló cikket.

Felügyelje az adattevékenységet, és őrizze meg a reagálási képességet

A naplózásnak ki kell terjednie azokra a kérdésekre, amelyekre az incidenskezelőknek választ kell adniuk. Az adminisztratív auditesemények megmutathatják, ki módosított egy szabályt, anélkül hogy megmutatnák, ki töltött le egy adatkészletet. Állapítsa meg, hol érhető el adathozzáférési naplózás, be van-e kapcsolva, és mely események vagy szolgáltatások maradnak a lefedettségen kívül.

Gyűjtse a releváns identitás-, vezérlősík-, adathozzáférési, alkalmazás-, kulcskezelési és megosztási eseményeket. Őrizze meg a fiók- és erőforrás-azonosítókat, a végrehajtó identitását, az időbélyegeket, a műveleteket és az eredményeket. Védje a naplókat a módosítás és a jogosulatlan törlés ellen. Ne helyezzen érzékeny tartalmat vagy újrafelhasználható hitelesítő adatokat a naplókba; a diagnosztikai adatok újabb kitettségi forrássá válhatnak.

Helyezze előtérbe az olyan észlelési forgatókönyveket, mint:

• Egy korlátozott tár nyilvánosan elérhetővé válik.
• Új külső bizalmi kapcsolat vagy kiemelt szerepkör-hozzárendelés.
• Szokatlan tömeges exportok vagy egy inaktív identitás általi hozzáférés.
• A naplózás kikapcsolása vagy a célhelyének megváltoztatása.
• Mentések törlése vagy a kulcsadminisztráció módosítása.

Határozza meg a reagálókat, és ellenőrzött gyakorlattal tesztelje a riasztásokat. Egy szabály, amely egy felügyelet nélküli postafiókba riaszt, nem hatékony észlelési folyamat. Rögzítse a gyűjtési hibákat, a késleltetett betöltést, az újonnan létrehozott erőforrásokat és a szolgáltatói korlátokat, ahelyett hogy egy irányítópultot teljes lefedettségként mutatna be.

Incidens során őrizze meg a releváns bizonyítékokat, és koordinálja a megfékezést az identitások, az alkalmazások és a tárolás között. Egy token visszavonása nem feltétlenül szünteti meg a többi munkamenetet, és nem állít le egy már folyamatban lévő exportot. A GDPR szerinti adatvédelmi incidensek esetén az adatfeldolgozók indokolatlan késedelem nélkül értesítik az adatkezelőket. Az adatkezelők indokolatlan késedelem nélkül és, ha lehetséges, a tudomásszerzéstől számított 72 órán belül bejelentik az incidenst a felügyeleti hatóságnak, kivéve, ha az valószínűsíthetően nem jár kockázattal az érintettek jogaira és szabadságaira nézve. A magas kockázatú incidensek esetén az érintetteket is indokolatlan késedelem nélkül tájékoztatni kell, a 34. cikk szerinti kivételek figyelembevételével. Őrizze meg a bejelentés vagy annak mellőzése indoklását.

A biztonsági eszközöket meghatározott kérdésekre használja

A felhőbiztonsági eszközök akkor a leghasznosabbak, ha a hatókörük és a döntési céljuk egyértelmű:

A DLP-szabályok érvényesítését reprezentatív teszteléssel és az adatgazdák felülvizsgálatával kezdje. Egy szabály, amely blokkolja a jogos ügyfélszolgálati munkát, nem kontrollált kerülőutak felé terelheti a felhasználókat. Korlátozza a szkennereket és a felügyeleti ügynököket a számukra szükséges hozzáférésre; egy széles olvasási jogosultsággal rendelkező feltáró eszköz maga is érzékeny komponenssé válik.

Az automatizálás csökkentheti az ismétlődő ellenőrzéseket és a bizonyítékgyűjtést. Azt azonban nem tudja megállapítani, hogy egy nem támogatott szolgáltatás biztonságos-e, vagy hogy egy jogi értelmezés helyes-e. A lényeges megállapításoknál és kivételeknél tartsa kifejezetten láthatóvá az emberi felülvizsgálatot.

A helyreállítást a mentési állapottól függetlenül bizonyítsa

A mentések csak akkor kezelik az adatvesztést és -sérülést, ha a szolgáltatás igényeinek megfelelő időn belül visszaállíthatók. Az üzleti gazdával együtt határozza meg a tolerálható adatvesztésre vonatkozó helyreállítási pont célkitűzést és a tolerálható kiesésre vonatkozó helyreállítási idő célkitűzést.

Különböztesse meg a replikációt, a verziókezelést, a pillanatképeket és a mentéseket. A replikáció a sérülést vagy a törlést is átmásolhatja. A pillanatképek ugyanazzal az adminisztrátorral szemben is sebezhetők maradhatnak, aki az éles környezetet irányítja. Válasszon a fenyegetésmodellnek megfelelő védett másolatokat és adminisztratív elkülönítést, ahol támogatott, törlésállósággal együtt.

Állítson vissza egy reprezentatív munkaterhelést egy elkülönített környezetbe. Ellenőrizze az adatok konzisztenciáját, az alkalmazásfüggőségeket, az identitáskonfigurációt, a kulcsok elérhetőségét és a helyreállításhoz szükséges időt. Önmagában az adatbázis visszaállítása nem bizonyítja, hogy az üzleti szolgáltatás működik. Rögzítse a hibákat, és a javítás után teszteljen újra.

A SaaS-helyreállítást külön értékelje. A szolgáltató katasztrófa-helyreállítása visszaállíthatja a platformot anélkül, hogy visszafordítaná a bérlőjében történt véletlen törlést. Állapítsa meg a rendelkezésre álló visszaállítási részletességet, a megőrzési időablakokat, az exportálási lehetőségeket és azt, hogy ki felel a helyreállítás elindításáért. Az osztályozási és megőrzési szabályokat a mentésekre is alkalmazza.

Kidolgozott példa: ügyféladat-export szolgáltatás

Vegyünk egy szemléltető SaaS-csapatot, amely menedzselt adatbázist, az exportokhoz objektumtárat és egy háttérfolyamatot használ. Tegyük fel, hogy az exportok bizalmas ügyfél-kapcsolattartási adatokat tartalmaznak, az ügyfelek csak a saját exportjaikhoz férnek hozzá, a megállapodott helyreállítási célok pedig négy óra adatvesztés és nyolc óra kiesés. Ezek példaként szolgáló feltételezések, nem ajánlott általános célértékek.

A szolgáltató üzemelteti a menedzselt infrastruktúrát. A platformcsapat konfigurálja a hálózati korlátozásokat, az identitásokat, a titkosítást és a naplózást. Az alkalmazásfejlesztők felelnek a bérlői jogosultságkezelésért és az exportlinkek működéséért. A szolgáltatásgazda hagyja jóvá a megőrzési és helyreállítási célokat; a biztonsági terület felülvizsgálja a hozzáférést és a bizonyítékokat.

A háttérfolyamat jogosultságot kap a szükséges adatbázisrekordok olvasására és az exportok kijelölt tárba írására. Nincs szüksége a tárolási szabályok módosítására vagy a mentések törlésére vonatkozó jogosultságra. A letöltések a bérlői jogosultságkezelésen haladnak át; az ideiglenes linkek érvényessége korlátozott, és bemutatóra szóló hitelesítő adatként kezelik őket. Az exportfájlok a jóváhagyott megőrzési szabály szerint járnak le.

A tesztelés magában foglal egy hitelesítés nélküli objektumkérést, egy ügyfél kísérletét egy másik ügyfél exportjának lekérésére, valamint a háttérfolyamat kísérletét egy tiltott adminisztratív műveletre. A felülvizsgálók azt is ellenőrzik, hogy a nyilvános hozzáférés blokkolva van-e, és hogy a tesztletöltések a várt auditeseményeket generálják-e.

Egy visszaállítási gyakorlat ellenőrzi az adatbázist és az alkalmazásfüggőségeket a feltételezett helyreállítási célokhoz mérten. A bizonyítékok közé tartoznak a konfigurációs exportok, a jogosultságkezelési teszteredmények, a mintavételezett hozzáférési események és a visszaállítási jegyzőkönyv. Ha egy régióban hiányzik az adathozzáférési naplózás, a felülvizsgálat rögzíti a hiányosságot, és kijelöli a javítást; a máshol sikeres tesztelés nem zárja le.

Őrizze meg a hatókört, a kivételeket és a felülvizsgálati döntéseket

A bizonyítéknak azonosítania kell a fiókot, az erőforrást, az időpontot, a gyűjtési módszert és a felülvizsgálót. Egy fiók konfigurációs exportja nem bizonyítja minden fiók állapotát. Vesse össze az összegyűjtött erőforrásokat a leltárral, és rögzítse a sikertelen gyűjtéseket vagy az elérhetetlen helyeket.

Minden szolgáltatáshoz tartson fenn egy tömör bizonyítékkészletet: a felelősségi térképet, a jóváhagyott alapkonfigurációt, az aktuális konfigurációellenőrzéseket, a tényleges hozzáférés felülvizsgálatát, a naplózási lefedettséget, a helyreállítási eredményeket és a nyitott kivételeket. Minden kivételhez felelős, kockázati indoklás, kompenzáló kontrollok, jóváhagyás, lejárati idő és újratesztelési feltétel kell.

Az ütemezett felülvizsgálatok mellett alkalmazzon eseményalapú kiváltó okokat is. A lényeges telepítési változások, az új régiók, a beszállítóváltások, az incidensek, a megváltozott adatosztályozás és az új megosztási útvonalak újraértékelést kell, hogy kiváltsanak. A NIST Cybersecurity Framework hasznos rendezőelvet ad a Govern, Identify, Protect, Detect, Respond és Recover funkciók mentén; ez útmutatás, nem annak bizonyítéka, hogy egy telepítés teljesíti a kötelezettségeit.

A Secani ezt a munkát követelményekhez, célobjektumokhoz, bizonyítékokhoz, felelősökhöz, feladatokhoz és felülvizsgálati döntésekhez tudja kapcsolni. Modellezze a felhőszolgáltatást és függőségeit, csatolja a konfigurációs exportokat és a tesztjegyzőkönyveket az általuk alátámasztott kontrollokhoz, és alakítsa a hiányzó lefedettséget kiosztott feladatokká. Tartsa kifejezetten láthatóvá az emberi jóváhagyást és a forráskövethetőséget. A műszaki konfiguráció és a riasztások forrásai továbbra is a felhőbiztonsági eszközök maradnak; a megfelelési munkaterület megőrzi a hatókörüket és az általuk alátámasztott intézkedéseket.

A következő mérnöki felülvizsgálathoz válasszon ki egy érzékeny adatfolyamot. Kövessen végig minden másolatot és hozzáférési útvonalat, ossza ki az ügyféloldali felelősségeket, tesztelje a tényleges jogosultságokat, és állítson vissza egy reprezentatív munkaterhelést. A hatókört akkor bővítse, ha ez a felülvizsgálat megbízható bizonyítékokat és megismételhető folyamatot eredményez.