Biztonsági stratégia meghatározása

A biztonsági szervezetek végső célkitűzései nem változnak a felhőszolgáltatások elfogadásával, de a célok elérése megváltozik. A biztonsági csapatoknak továbbra is az üzleti kockázatok csökkentésére kell összpontosítaniuk a támadások miatt, és azon kell dolgozniuk, hogy az összes információs rendszerbe és adatba beépített bizalmassági, integritási és rendelkezésre állási garanciákat kapják.

Biztonsági stratégia modernizálása

A biztonsági csapatoknak modernizálni kell a stratégiákat, az architektúrákat és a technológiát, mivel a szervezet bevezeti a felhőt, és idővel működteti azt. Bár a változások mérete és száma kezdetben ijesztőnek tűnhet, a biztonsági program modernizálása lehetővé teszi a biztonság számára, hogy az örökölt megközelítésekhez kapcsolódó fájdalmas terheket hárítsa el. A szervezetek ideiglenesen működhetnek örökölt stratégiával és eszközökkel, de ezt a megközelítést nehéz fenntartani a felhőben és a fenyegetési környezetben bekövetkező változás ütemével:

• A biztonsági csapatok valószínűleg kimaradnak a felhőbevezetési döntéshozatalból, ha a "fegyverhosszúságú" biztonság régi szemléletét veszik figyelembe, ahol a válasz mindig a "nem" betűvel kezdődik (ahelyett, hogy együttműködnének az informatikai és üzleti csapatokkal a kockázat csökkentése érdekében, miközben engedélyezik a vállalkozást).
• A biztonsági csapatok nehezen észlelhetik és védhetik a felhőbeli támadásokat, ha csak örökölt helyszíni eszközöket használnak, és kizárólag a csak hálózati peremhálózati doktrínát használják minden védelem és monitorozás céljából.

Monitorozás és védelem felhőalapú méretekben

A felhőalapú védelem jelentős átalakítási munka, amely a natív felhőbeli észlelési és automatizálási képességek használatát, valamint egy identitáshatár bevezetését jelenti a felhőbeli és mobileszközök monitorozásához és védelméhez.

• A Microsoft Identitásplatform segítségével modern hitelesítési és engedélyezési mechanizmusokat építhet be az alkalmazásokba.
• A Microsoft Sentinel natív felhőbeli biztonsági elemzéseket és fenyegetésfelderítést biztosít a szervezeten belül, így továbbfejlesztett fenyegetésészlelést tesz lehetővé, amely a fenyegetésfelderítés nagy tárházait, valamint a felhő szinte korlátlan feldolgozási és tárolási képességeit használja.

Azt javasoljuk, hogy a biztonsági csapatok agilis megközelítést alkalmazzanak a biztonság modernizálására– a stratégia legkritikusabb szempontjainak gyors modernizálására, a lépések folyamatos fejlesztésére és a továbblépésre.

A felhő és a felhő biztonsága

Mivel a szervezet felhőszolgáltatásokat vezet be, a biztonsági csapatok két fő célkitűzésen fognak dolgozni:

• A felhő biztonsága (a felhőerőforrások védelme): A biztonságot integrálni kell a felhőszolgáltatások tervezésébe és működtetésébe, hogy az alapvető biztonsági biztosítékok következetesen érvényesüljenek az összes erőforrásra vonatkozóan.
• Biztonság a felhőből (a felhő használatával a biztonság átalakítására): A biztonságnak azonnal el kell kezdenie a tervezést és a tervezést, és el kell gondolkodnia arról, hogyan lehet a felhőtechnológiák használatával modernizálni a biztonsági eszközöket és folyamatokat, különösen a natívan integrált biztonsági eszközöket. A biztonsági eszközöket egyre inkább a felhőben üzemeltetik– olyan képességeket biztosítva, amelyeket nehéz vagy lehetetlen elvégezni egy helyszíni környezetben.

Szoftveralapú adatközpontok védelme

Számos szervezet azzal kezdi, hogy a felhőerőforrásokat egy másik virtuális adatközpontként kezeli, amely hatékony kiindulópont a felhő biztonságához. Ahogy a szervezetek modernizálják a felhőből származó biztonságot, a legtöbben gyorsan ki fogják használni ezt a gondolkodási modellt. A szoftveralapú adatközpontok biztonságossá tétele lehetővé teszi a helyszíni modellek által kínált lehetőségeken túlmutató képességeket. A felhőben üzemeltetett biztonsági eszközök az alábbiakat kínálják:

• A biztonsági képességek gyors engedélyezése és skálázása.
• Rendkívül hatékony eszközleltár és biztonsági konfiguráció higiénia felderítése.

A Microsoft Defender felhőhöz való üzembe helyezése lehetővé teszi a szervezet biztonsági állapotának és vezérlőinek folyamatos értékelését. Erősíti a felhőerőforrások biztonsági helyzetét, és integrált Microsoft Defender csomagjaival a Defender for Cloud védelmet nyújt az Azure-ban, hibrid és más felhőplatformokon futó számítási feladatok számára. További információ a felhőhöz készült Microsoft Defender.

Megjegyzés

Azure Security Center és az Azure Defender neve mostantól Microsoft Defender a felhőhöz. Az Azure Defender-csomagokat is átneveztük Microsoft Defender csomagokra. Az Azure Defender for Storage például most már Microsoft Defender a Storage-hoz.

További információ a Microsoft biztonsági szolgáltatásainak legutóbbi átnevezéséről.

A biztonsági súrlódás megfelelő szintje

A biztonság természetesen olyan súrlódást okoz, amely lelassítja a folyamatokat, ezért fontos meghatározni, hogy mely elemek kifogástalan állapotban vannak a DevOpsban és az informatikai folyamatokban, és melyek nem:

• Egészséges súrlódás: Hasonlóan a gyakorlat ellenállása erősebbé teszi az izmokat, a biztonsági súrlódás megfelelő szintjének integrálása erősíti a rendszert vagy az alkalmazást azáltal, hogy a kritikus gondolkodást a megfelelő időben kényszeríti. Ez általában annak mérlegelése, hogy a támadók hogyan és miért próbálnak meg veszélyeztetni egy alkalmazást vagy rendszert a tervezés során (más néven fenyegetésmodellezés), valamint a szoftverkódokban, konfigurációkban vagy üzemeltetési eljárásokban kihasználható potenciális biztonsági rések áttekintését, azonosítását és ideális megoldását.
• Nem kifogástalan súrlódás: Több értéket akadályoz, mint amennyit véd. Ez gyakran akkor fordul elő, ha az eszközök által létrehozott biztonsági hibák magas hamis pozitív arányúak (például hamis riasztások), vagy ha a biztonsági problémák felderítése vagy megoldása messze meghaladja a támadás lehetséges hatását.

Önálló és integrált felelősségek

A bizalmassági, integritási és rendelkezésre állási garanciák biztosításához a biztonsági szakértőknek dedikált biztonsági funkciókat kell működtetnie, és szorosan együtt kell működnie a szervezet többi csapatával:

• Egyedi biztonsági függvények: A biztonsági csapatok olyan független függvényeket hajtanak végre, amelyek nem találhatók a szervezet más részén, például biztonsági műveletek, biztonsági rések kezelése (például virtuális gépek, tárolók) és egyéb függvények.
• Biztonság integrálása más függvényekbe: A biztonsági csapatok a szervezet más csapatainak és funkcióinak is témaszakértői, akik üzleti kezdeményezéseket vezetnek, felmérik a kockázatokat, alkalmazásokat terveznek vagy fejlesztenek, valamint operációs informatikai rendszereket fejlesztenek. A biztonsági csapatok a támadókkal, a támadási módszerekkel és trendekkel, a jogosulatlan hozzáférést lehetővé tevő biztonsági résekkel, valamint a kockázatcsökkentési lépések vagy kerülő megoldások, valamint azok lehetséges előnyeivel vagy buktatóival kapcsolatos szakértelemmel és kontextussal tanácsokat adnak ezeknek a csapatoknak. Ez a biztonsági funkció hasonlít a minőségi függvényre, mivel sok helyen nagy és kicsi lesz, egyetlen eredmény támogatása érdekében.

Ezeknek a feladatoknak a végrehajtásához, miközben lépést tart a felhőbeli változások gyors ütemével és az üzleti átalakulással, a biztonsági csapatoknak modernizálniuk kell eszközeiket, technológiáikat és folyamataikat.

Átalakítások, gondolkodásmódok és elvárások

Számos szervezet több egyidejű átalakításból álló láncot kezel a szervezetben. Ezek a belső átalakítások általában azért kezdődnek, mert szinte minden külső piac úgy alakul át, hogy megfeleljen a mobil- és felhőtechnológiák új ügyfélbeállításainak. A szervezetek gyakran szembesülnek az új startupok versenyfenyegetettségével és a hagyományos versenytársak digitális átalakulásával, akik megzavarhatják a piacot.

A belső átalakítási folyamat általában a következőket foglalja magában:

• A vállalkozás digitális átalakulása új lehetőségek megragadása és a digitális natív startupokkal szembeni versenyképesség megőrzése érdekében.
• Az informatikai szervezet technológiai átalakítása a kezdeményezés felhőszolgáltatásokkal, modernizált fejlesztési gyakorlatokkal és a kapcsolódó módosításokkal való támogatásához.
• Biztonsági átalakítás a felhőhöz való alkalmazkodáshoz, és egyidejűleg egy egyre kifinomultabb veszélyforrás-környezet kezelése.

A belső ütközés költséges lehet

A változás stresszt és konfliktust okoz, ami megállíthatja a döntéshozatalt. Ez különösen igaz a biztonságra, ha a biztonsági kockázatok elszámoltathatóságát gyakran a tárgy szakértői (biztonsági csoportok) veszik el, nem pedig az üzleti eredményekért és minden más kockázati típusért felelős eszközök tulajdonosaira (üzleti tulajdonosaira). Ez az elhibázott elszámoltathatóság gyakran azért fordul elő, mert minden érdekelt helytelenül műszaki vagy abszolút megoldandó problémának tekinti a biztonságot, nem pedig dinamikus folyamatos kockázatot, például a vállalati kémkedést és más hagyományos bűncselekményeket.

Az átalakítás ezen időszakában az összes csapat vezetőségének aktívan kell dolgoznia a kritikus projektek kisiklását lehetővé tevő ütközések csökkentése érdekében, és ösztönöznie kell a csapatokat a biztonsági kockázatcsökkentés megkerülésére. A csapatok közötti internecine ütközés a következőt eredményezheti:

• Nagyobb biztonsági kockázat , például elkerülhető biztonsági incidensek vagy a támadások által okozott nagyobb üzleti károk (különösen akkor, ha a csapatokat frusztrálja a biztonság és a normál folyamatok megkerülése, vagy ha a támadók könnyen megkerülik az elavult biztonsági megközelítéseket).
• Negatív hatás az üzletre vagy a küldetésre , például ha az üzleti folyamatok nem engedélyezettek vagy nem frissülnek elég gyorsan a piaci igények kielégítéséhez (gyakran akkor, ha a biztonsági folyamatok kulcsfontosságú üzleti kezdeményezéseket tartanak maguknál).

Fontos, hogy tartsa szem előtt a kapcsolatok állapotát a csapatokon belül és között, hogy segítsen nekik abban, hogy navigáljanak a változó tájon, amely az értékes csapattagokat bizonytalanná és rendezetlenné teheti. A türelem, az empátia és az oktatás ezen gondolkodásmódok és a jövő pozitív potenciálja segít a csapatoknak abban, hogy jobban navigáljon ebben az időszakban, ami jó biztonsági eredményeket biztosít a szervezet számára.

A vezetők a következő konkrét proaktív lépésekkel segíthetnek a kulturális változások ösztönzésében:

• Nyilvánosan modellezheti a csapatuktól elvárt viselkedést.
• Átláthatónak lenni a változások kihívásaival kapcsolatban, beleértve a saját alkalmazkodási küzdelmeik kiemelését is.
• Rendszeresen emlékezteti a csapatokat a biztonság modernizálásának és integrálásának sürgősségére és fontosságára.

Kiberbiztonsági rugalmasság

Számos klasszikus biztonsági stratégia kizárólag a támadások megelőzésére összpontosított, ami nem elegendő a modern fenyegetésekhez. A biztonsági csapatoknak biztosítaniuk kell, hogy stratégiájuk túllépjen ezen, és lehetővé teszi a gyors támadásészlelést, reagálást és helyreállítást a rugalmasság növelése érdekében. A szervezeteknek azt kell feltételezniük, hogy a támadók veszélyeztetnek bizonyos erőforrásokat (más néven támadást), és azon dolgoznak, hogy az erőforrások és a technikai kialakítások egyensúlyban legyenek a támadásmegelőzés és a támadáskezelés között (a támadások megelőzésére tett kísérletek tipikus alapértelmezett megközelítése helyett).

Sok szervezet már dolgozik ezen az úton, mert az elmúlt években folyamatosan növekvő mennyiségű és kifinomult támadást hajtottak végre. Ez az utazás gyakran az első jelentős incidenssel kezdődik, amely érzelmi esemény lehet, amikor az emberek elveszítik a sérthetetlenség és a biztonság korábbi érzését. Bár nem olyan súlyos, mint az életvesztés, ez az esemény hasonló érzelmeket válthat ki, kezdve a tagadással, és végső soron elfogadással végződik. A "hiba" feltételezését először nehéz lehet elfogadni, de erős párhuzamokkal rendelkezik a jól bevált "fail-safe" mérnöki elvvel, és a feltételezés lehetővé teszi, hogy a csapatok a siker jobb definíciójára összpontosítsanak: a rugalmasságra.

A NIST kiberbiztonsági keretrendszer funkciói hasznos útmutatóként szolgálnak ahhoz, hogyan lehet egyensúlyt teremteni a befektetések között a rugalmas stratégiában történő azonosítás, védelem, észlelés, reagálás és helyreállítás kiegészítő tevékenységei között.

A kiberbiztonsági rugalmasságról és a kiberbiztonsági ellenőrzések végső céljairól a Hogyan tarthatja vissza a szervezet kockázatait? című témakörben olvashat bővebben.

Hogyan változik a felhő a biztonságban?

A felhőbe való áttérés a biztonság érdekében több, mint egyszerű technológiai változás. Ez a technológia generációváltása, amely a nagyszámítógépekről az asztali gépekre és a vállalati kiszolgálókra való áttéréshez hasonlít. A változás sikeres végrehajtásához alapvető változásokra van szükség a biztonsági csapatok elvárásaiban és gondolkodásmódjában. A megfelelő gondolkodásmódok és elvárások elfogadása csökkenti a szervezeten belüli konfliktusokat, és növeli a biztonsági csapatok hatékonyságát.

Bár ezek bármelyik biztonsági korszerűsítési terv részét képezhetik, a felhőben a gyors változási ütem sürgős prioritást élvez.

• Partnerség a közös célokkal. A gyors ütemű döntések és a folyamatos folyamatfejlődés korában a biztonság már nem alkalmazhat "fegyverhosszúságú" megközelítést a környezet változásainak jóváhagyására vagy elutasítására. A biztonsági csapatoknak szorosan együtt kell működniük az üzleti és informatikai csapatokkal, hogy közös célokat hozzanak létre a hatékonyság, a megbízhatóság és a biztonság területén, és közösen működjenek együtt ezekkel a partnerekkel.

  Ez a partnerség a "balra tolódás" végső formája – a biztonság korábbi folyamatokba való integrálásának elve, amely megkönnyíti és hatékonyabbá teszi a biztonsági problémák megoldását. Ehhez minden érintett (biztonság, üzleti és informatikai) kultúraváltásra van szükség, amely megköveteli, hogy mindenki megismerje a többi csoport kultúráját és normáit, miközben egyidejűleg másoknak is sajátról kell tanítania őket.

  A biztonsági csapatoknak:

  • Megismerheti az üzleti és informatikai célkitűzéseket, és hogy miért fontos ezek mindegyike, és hogyan gondolkodnak a megvalósításukon az átalakításuk során.
  • Ossza meg , hogy miért fontos a biztonság az üzleti célok és kockázatok összefüggésében, mit tehetnek más csapatok a biztonsági célok elérése érdekében, és hogyan kell megtenniük.

  Bár nem könnyű feladat, elengedhetetlen a szervezet és eszközei fenntartható védelméhez. Ez a partnerség valószínűleg egészséges kompromisszumokat eredményez, ahol kezdetben csak a minimális biztonsági, üzleti és megbízhatósági célok teljesülhetnek, de idővel fokozatosan javulnak.

• A biztonság folyamatos kockázat, nem probléma. Nem oldhatja meg a bűnözést. A biztonság lényege, hogy a biztonság csak egy kockázatkezelési szemlélet, amely a természetes események helyett az emberek rosszindulatú cselekedeteire összpontosít. Mint minden kockázat, a biztonság sem olyan probléma, amelyet egy megoldással meg lehet oldani, hanem a negatív eseményből, támadásból eredő károk valószínűségének és hatásának kombinációja. Ez a leginkább hasonlít a hagyományos vállalati kémkedéshez és bűncselekményekhez, ahol a szervezetek motivált emberi támadókkal szembesülnek, akik pénzügyi ösztönzést kapnak a szervezet sikeres megtámadására.

• A hatékonyság és a biztonság sikeréhez mindkettő szükséges. A szervezetnek a biztonságra és a hatékonyságra is összpontosítania kell a mai "innováció vagy irreleváns" környezetben. Ha a szervezet nem produktív, és új innovációt vezet, elveszítheti versenyképességét a piactéren, ami pénzügyileg gyengíti vagy végül meghiúsul. Ha a szervezet nem biztonságos, és elveszíti az eszközök feletti irányítást a támadók számára, elveszítheti a versenyképességet a piactéren, ami pénzügyileg gyengíti, és végül meghiúsul.

• Senki sem tökéletes. Egyetlen szervezet sem tökéletes a felhő bevezetésében, még a Microsoft sem. A Microsoft informatikai és biztonsági csapatai számos olyan kihívással szembesülnek, mint például a programok jól strukturálásának, a régi szoftverek támogatásának és a legkorszerűbb innováció támogatásának kiegyensúlyozása, vagy akár a felhőszolgáltatások technológiai hiányosságainak a kiegyensúlyozása. Mivel ezek a csapatok megtanulják, hogyan lehet hatékonyabban üzemeltetni és biztonságossá tenni a felhőt, aktívan megosztják tapasztalataikat az ehhez hasonló dokumentumokon keresztül másokkal együtt az informatikai bemutató webhelyen, miközben folyamatosan visszajelzést küldenek a mérnöki csapatainknak és a külső gyártóknak az ajánlataik továbbfejlesztése érdekében.

  Tapasztalataink alapján azt javasoljuk, hogy a csapatokat a tökéletesség színvonala helyett a folyamatos tanulás és fejlesztés színvonala szerint tartsuk.

• Lehetőség az átalakításban. Fontos, hogy a digitális átalakítást pozitív biztonsági lehetőségként tekintsünk. Bár könnyű látni a változás lehetséges hátrányait és kockázatát, könnyű kihagyni a nagy lehetőséget, hogy újra feltalálja a biztonsági szerepkört, és helyet szerezzen abban az asztalnál, ahol döntéseket hoznak. A vállalattal való partneri kapcsolat megnövelheti a biztonsági finanszírozást, csökkentheti a pazarló ismétlődő biztonsági erőfeszítéseket, és élvezetesebbé teheti a biztonság terén végzett munkát, mivel azok jobban kapcsolódnak a szervezet küldetéséhez.

A megosztott felelősségi modell bevezetése

A felhőben üzemeltetett informatikai szolgáltatások felosztják a számítási feladatok üzemeltetési és biztonsági feladatait a felhőszolgáltató és az ügyfélbérlő között, és de facto partnerséget hoznak létre a megosztott felelősségekkel. Minden biztonsági csapatnak tanulmányoznia és megértenie kell ezt a megosztott felelősségi modellt, hogy a folyamataikat, eszközeiket és képességcsoportjaikat az új világhoz igazítsák. Ez segít elkerülni, hogy véletlenül hiányosságokat vagy átfedéseket hozzon létre a biztonsági helyzetében, ami biztonsági kockázatokat vagy felesleges erőforrásokat eredményez.

Ez az ábra azt szemlélteti, hogyan oszlanak meg a biztonsági felelősségek a felhőszolgáltatók és a felhőbeli ügyfélszervezetek között de facto partnerségben:

Mivel a felhőszolgáltatások különböző modelleket használnak, az egyes számítási feladatok feladatai attól függően változnak, hogy szolgáltatott szoftveren (SaaS), szolgáltatásként nyújtott platformon (PaaS), szolgáltatásként nyújtott infrastruktúrán (IaaS) vagy helyszíni adatközpontban vannak-e üzemeltetve.

Biztonsági kezdeményezések létrehozása

Ez az ábra azt a három elsődleges biztonsági kezdeményezést szemlélteti, amelyeket a legtöbb biztonsági programnak követnie kell a felhő biztonsági stratégiájának és biztonsági programjának céljainak módosításához:

A rugalmas biztonsági helyzet felhőbeli kialakításához több párhuzamos kiegészítő megközelítésre van szükség:

• Megbízható, de ellenőrizze a következőket: A felhőszolgáltató által végzett feladatok esetében a szervezeteknek "megbízhatósági, de ellenőrzési" megközelítést kell alkalmazniuk. A szervezeteknek értékelniük kell a felhőszolgáltatók biztonsági eljárásait és az általuk kínált biztonsági vezérlőket, hogy a felhőszolgáltató megfeleljen a szervezet biztonsági igényeinek.

• Infrastruktúra- és alkalmazásbiztonság modernizálása: A szervezet irányítása alá tartozó technikai elemek esetében rangsorolja a biztonsági eszközök és a hozzá tartozó képességcsoportok modernizálását, hogy minimalizálja a felhőbeli erőforrások védelmének lefedettségi hiányosságait. Ez két különböző kiegészítő erőfeszítésből áll:

  • Infrastruktúra biztonsága: A szervezeteknek a felhő használatával modernizálniuk kell megközelítésüket a számos alkalmazás, például az operációs rendszerek, a hálózatok és a tárolóinfrastruktúra által használt közös összetevők védelmére és figyelésére. Ezek a felhőbeli képességek gyakran tartalmazhatják az infrastruktúra-összetevők kezelését az IaaS-ben és a helyszíni környezetekben is. A stratégia optimalizálása azért fontos, mert ez az infrastruktúra az azon futó alkalmazások és adatok függősége, amely gyakran lehetővé teszi a kritikus üzleti folyamatokat és a kritikus üzleti adatok tárolását.

  • Alkalmazásbiztonság: A szervezeteknek emellett modernizálniuk kell a szervezet által vagy számára fejlesztett egyedi alkalmazásokat és technológiákat. Ez a szemlélet gyorsan változik az agilis DevOps-folyamatok elfogadásával, a nyílt forráskódú összetevők egyre növekvő használatával, valamint a felhőalapú API-k és felhőszolgáltatások alkalmazásösszetevők vagy alkalmazások összekapcsolása helyére történő bevezetésével.

    A helyesség megszerzése kritikus fontosságú, mert ezek az alkalmazások gyakran engedélyezik a kritikus üzleti folyamatokat, és kritikus üzleti adatokat tárolnak.

  • Modern szegély: A szervezeteknek átfogó megközelítéssel kell rendelkezniük az adatok minden számítási feladatra kiterjedő védelmére, a szervezeteknek egységes, központilag felügyelt identitásvezérlőket kell létrehozniuk az adataik, eszközeik és fiókjaik védelme érdekében. Ezt nagymértékben befolyásolja a CISO-workshop 3. moduljában részletesen tárgyalt megbízhatósági stratégia.

Biztonság és megbízhatóság

A biztonságba vetett bizalom szó használata zavaró lehet. Ez a dokumentáció két módon hivatkozik rá, amelyek a fogalom hasznos alkalmazásait szemléltetik:

• A nulla megbízhatóság a biztonság stratégiai megközelítésének általános iparági kifejezése, amely feltételezi, hogy egy vállalati vagy intranetes hálózat ellenséges (a nulla megbízhatósághoz méltó), és ennek megfelelően tervezi meg a biztonságot.
• A bizalom, de az ellenőrzés egy kifejezés, amely két különböző szervezet lényegét rögzíti egy közös cél érdekében annak ellenére, hogy vannak más, potenciálisan eltérő érdekek. Ez tömören rögzíti a vállalati kereskedelmi felhőszolgáltatóval való partneri kapcsolat korai szakaszainak számos árnyalatát.

A felhőszolgáltató és annak gyakorlata és folyamatai elszámoltathatók lehetnek a szerződéses és szabályozási követelmények teljesítése érdekében, és elnyerhetik vagy elveszíthetik a bizalmukat. A hálózat olyan nem működő kapcsolat, amely nem tud következményekkel szembesülni, ha a támadók használják (hasonlóan ahhoz, hogy nem lehet úttal vagy autóval elszámolni az őket használó bűnözők számára).

Hogyan változtatja meg a felhő a biztonsági kapcsolatokat és a felelősségeket?

Az olyan technológiák új generációjára való korábbi áttérésekhez hasonlóan, mint az asztali számítástechnika és a nagyvállalati kiszolgáló-számítástechnika, a felhőalapú számítástechnikára való áttérés megszakítja a régóta fennálló kapcsolatokat, szerepköröket, felelősségeket és képességcsoportokat. Az elmúlt néhány évtizedben megszokott munkaköri leírások nem képeznek le tiszta térképet egy olyan vállalatra, amely most már felhőalapú képességeket is tartalmaz. Mivel az iparág közösen dolgozik egy új modell normalizálásán, a szervezeteknek a lehető legnagyobb átláthatóságra kell összpontosítaniuk, hogy segítsenek kezelni a kétértelműség bizonytalanságát ebben a változási időszakban.

A biztonsági csapatokra hatással vannak az általuk támogatott üzleti és technológiai változások, valamint saját belső korszerűsítési erőfeszítéseik, amelyek célja a fenyegetést jelentő szereplők jobb tájékozódása. A támadók folyamatosan fejlődnek, és folyamatosan keresik a legegyszerűbben kihasználható gyenge pontokat a szervezet és a biztonság embereiben, folyamataiban és technológiájában, és képességeket és képességeket kell fejleszteniük az ilyen szögek kezeléséhez.

Ez a szakasz a felhőbe vezető út során gyakran változó legfontosabb kapcsolatokat ismerteti, beleértve a kockázat minimalizálásával és a fejlesztési lehetőségek kihasználásával kapcsolatos tanulságokat:

• A biztonság és az üzleti érdekelt felek között: A biztonsági vezetésnek egyre több partnerre lesz szüksége az üzleti vezetőkkel, hogy a szervezetek csökkenthetik a kockázatokat. A biztonsági vezetőknek támogatniuk kell az üzleti döntéshozatalt biztonsági szakértőként (KKV-k), és törekedniük kell arra, hogy megbízható tanácsadókká váljon ezeknek az üzleti vezetőknek. Ez a kapcsolat segít biztosítani, hogy az üzleti vezetők figyelembe vegyék a biztonsági kockázatokat, miközben üzleti döntéseket hoznak, tájékoztatják az üzleti prioritásokat, és gondoskodnak arról, hogy a biztonsági befektetéseket a többi befektetés mellett megfelelően rangsorolják.

• A biztonsági vezetők és a csapattagok között: A biztonsági vezetőknek ezeket az üzleti vezetőktől származó megállapításokat vissza kell vinniük a csapatukba, hogy irányt adjanak a befektetési prioritásaiknak.

  Azáltal, hogy az üzleti vezetőkkel és a csapatokkal való együttműködés hangnemét állítja be a klasszikus "fegyverhosszúságú" kapcsolat helyett, a biztonsági vezetők elkerülhetik a biztonsági és hatékonysági célokat egyaránt akadályozó támadó dinamikát.

  A biztonsági vezetőknek arra kell törekedniük, hogy egyértelművé tegyenek a csapatuk számára a hatékonyságra és a biztonsági kompromisszumokra vonatkozó napi döntések kezelésével kapcsolatban, mivel ez sok csapat számára új lehet.

• Alkalmazás- és infrastruktúra-csapatok (és felhőszolgáltatók) között: Ez a kapcsolat jelentős változásokon megy keresztül az informatikai és biztonsági ágazat számos trendje miatt, amelyek célja az innovációs sebesség és a fejlesztői hatékonyság növelése.

  A régi normák és a szervezeti funkciók megszakadtak, de az új normák és funkciók még mindig megjelennek, ezért javasoljuk, hogy fogadja el a kétértelműséget, lépést tartson a jelenlegi gondolkodással, és kísérletezzen azzal, hogy mi működik a szervezetei számára, amíg meg nem teszi. Ebben a térben nem javasoljuk a várakozási és várakozási megközelítés bevezetését, mert ez komoly versenyhátrányba kerülhet a szervezet számára.

  Ezek a trendek kihívást jelentenek az alkalmazások és az infrastruktúra szerepköreinek és kapcsolatainak hagyományos normáival kapcsolatban:

  • DevOps-fusing szemléletek: Ideális állapotában ez hatékonyan létrehoz egy magas funkcionalitású csapatot, amely egyesíti a szakterületi szakértelem két készletét a gyors innovációhoz, a frissítések kiadásához és a problémák megoldásához (biztonság és egyéb). Bár ez az ideális állapot némi időt vesz igénybe, és a felelősségek középen még mindig kétértelműek, a szervezetek már kihasználják a gyors kiadások néhány előnyét ennek az együttműködési megközelítésnek köszönhetően. A Microsoft azt javasolja, hogy integrálja a biztonságot ebbe a ciklusba, hogy segítsen ezeknek a kultúráknak a megismerésében, a biztonsági tanulás megosztásában, valamint a biztonságos és megbízható alkalmazások gyors kiadásának közös célja érdekében.

  

  • A tárolóba helyezés általános infrastruktúra-összetevővé válik: Az alkalmazásokat egyre inkább olyan technológiák üzemeltetik és vezénylik, mint a Docker, a Kubernetes és hasonló technológiák. Ezek a technológiák leegyszerűsítik a fejlesztést és a kiadást a mögöttes operációs rendszer beállításának és konfigurációjának számos elemének absztrakcióval.

  

  Bár a tárolók a fejlesztői csapatok által felügyelt alkalmazásfejlesztési technológiaként kezdődtek, egyre elterjedtebb infrastruktúra-összetevővé válik, amely egyre inkább az infrastruktúra-csapatokra kerül át. Ez az áttűnés sok szervezetnél még folyamatban van, de ez egy természetes és pozitív irány, amelyet a jelenlegi kihívások közül a legjobban a hagyományos infrastruktúra-képességkészletekkel, például a hálózatkezeléssel, a tárolással és a kapacitáskezeléssel lehet megoldani.

  A technológiát kezelő, monitorozási és biztonsági csapattagokat betanítással, folyamatokkal és eszközökkel kell ellátni.

  • Kiszolgáló nélküli és felhőalkalmazási szolgáltatások: Az iparág egyik meghatározó trendje jelenleg az alkalmazások létrehozásához vagy frissítéséhez szükséges idő és fejlesztési munka csökkentése.

    

    A fejlesztők egyre gyakrabban használják a felhőszolgáltatásokat a következőkre:

    • Futtassa a kódot az alkalmazások virtuális gépeken (virtuális gépeken) és kiszolgálókon való üzemeltetése helyett.
    • Alkalmazásfüggvények biztosítása ahelyett, hogy saját összetevőket fejlesztenek. Ez egy kiszolgáló nélküli modellt eredményezett, amely meglévő felhőszolgáltatásokat használ a gyakori funkciókhoz. A felhőszolgáltatások száma és változatossága (és az innováció üteme) is túllépte a biztonsági csapatok azon képességét, hogy kiértékeljék és jóváhagyják a szolgáltatások használatát, így választhatnak a fejlesztők számára bármely szolgáltatás használatát, megpróbálták megakadályozni, hogy a fejlesztői csapatok nem jóváhagyott szolgáltatásokat használjanak, vagy megpróbálják megtalálni a jobb megoldást.
    • Kód nélküli alkalmazások és Power Apps: Egy másik feltörekvő trend a kód nélküli technológiák használata, például a Microsoft Power Apps. Ez a technológia lehetővé teszi, hogy a kódolási készségekkel nem rendelkező személyek üzleti eredményeket elérő alkalmazásokat hozzanak létre. Ennek az alacsony súrlódásnak és magas értékpotenciónak köszönhetően ez a tendencia gyorsan növelheti a népszerűségét, és a biztonsági szakemberek bölcsek lennének annak következményeinek gyors megértéséhez. A biztonsági erőfeszítéseket azokra a területekre kell összpontosítani, ahol egy ember hibát követhet el az alkalmazásban, nevezetesen az alkalmazás- és eszközengedélyek tervezését az alkalmazás összetevőinek, interakcióinak/kapcsolatainak és szerepkör-engedélyeinek fenyegetésmodellezésével.

• Fejlesztők és nyílt forráskódú összetevők szerzői között: A fejlesztők a saját összetevők fejlesztése helyett nyílt forráskódú összetevők és kódtárak használatával is növelik a hatékonyságot. Ez a hatékonyság révén értéket teremt, de biztonsági kockázatokat is jelent egy külső függőség létrehozásával, valamint az összetevők megfelelő karbantartására és javítására vonatkozó követelményekkel. A fejlesztők hatékonyan vállalják a biztonsági és egyéb hibák kockázatát, amikor ezeket az összetevőket használják, és gondoskodniuk kell arról, hogy azokat ugyanolyan szabványok szerint mérsékeljék, mint az általuk fejlesztett kód.

• Alkalmazások és adatok között: Az adatok és alkalmazások biztonsága közötti határ egyre homályosabbá válik a helyeken, és az új szabályozások szorosabb együttműködést igényelnek az adat-/adatvédelmi csapatok és a biztonsági csapatok között:

  • Gépi tanulási algoritmusok: A gépi tanulási algoritmusok hasonlóak azokhoz az alkalmazásokhoz, amelyek az adatok feldolgozására szolgálnak az eredmények létrehozásához. A legfontosabb különbségek a következők:

    • Nagy értékű gépi tanulás: A gépi tanulás gyakran jelentős versenyelőnyt biztosít, és gyakran bizalmas szellemi tulajdonnak és üzleti titoknak számít.

    • Bizalmassági lenyomat: A felügyelt gépi tanulás adatkészletekkel van hangolva, amelyek az adathalmaz jellemzőit lenyomják az algoritmuson. Emiatt a hangolt algoritmus érzékenynek tekinthető a betanítandó adathalmaz miatt. Ha például betanít egy gépi tanulási algoritmust, amely titkos katonai bázisokat keres egy térképen titkos katonai bázisok adathalmazával, az bizalmas adategységet képezne.

    Megjegyzés

    Nem minden példa egyértelmű, ezért kritikus fontosságú, hogy egy csapatot összehozza az adatelemzési csapatok, az üzleti érdekelt felek, a biztonsági csapatok, az adatvédelmi csapatok és mások megfelelő érdekelt feleivel. Ezeknek a csapatoknak felelősséget kell vállalniuk az innováció és a felelősség közös céljainak teljesítéséért. Meg kell oldaniuk az olyan gyakori problémákat, mint az adatok másolatainak tárolása nem biztonságos konfigurációkban, algoritmusok besorolása, valamint a szervezetek aggályai.

    A Microsoft közzétette a felelős AI-alapelveit , hogy útmutatást nyújtsunk saját csapatainknak és ügyfeleinknek.

    • Adatok tulajdonjoga és adatainak védelme: Az olyan szabályozások, mint a GDPR, megnövelték az adatproblémák és az alkalmazások láthatóságát. Az alkalmazáscsapatok mostantól képesek a bizalmas adatok felügyeletére, védelmére és nyomon követésére a pénzügyi adatok bankok és pénzügyi intézmények általi nyomon követéséhez hasonló szinten. Az adattulajdonosoknak és az alkalmazásoknak a csapatoknak részletes ismereteket kell kialakítaniuk arról, hogy milyen adatalkalmazásokat tárolnak, és milyen vezérlőkre van szükség.

• Szervezetek és felhőszolgáltatók között: Mivel a szervezetek számítási feladatokat üzemeltetnek a felhőben, üzleti kapcsolatot létesítenek az egyes felhőszolgáltatókkal. A felhőszolgáltatások használata gyakran hoz üzleti értéket, például:

  • A digitális átalakítási kezdeményezések felgyorsítása azáltal, hogy csökkenti az új képességek piacra jutásának idejét.

  • Az informatikai és biztonsági tevékenységek értékének növelése azáltal, hogy lehetővé teszi a csapatok számára, hogy magasabb értékű (üzleti szempontból igazított) tevékenységekre összpontosítsanak ahelyett, hogy alacsonyabb szintű árutőzsdei feladatokra összpontosítanának, amelyeket a felhőszolgáltatások hatékonyabban nyújtanak a nevükben.

  • Nagyobb megbízhatóság és válaszképesség: A legtöbb modern felhő magas üzemidővel rendelkezik a hagyományos helyszíni adatközpontokhoz képest is, és azt mutatta, hogy gyorsan skálázhatók (például a COVID-19-világjárvány idején), és rugalmasságot biztosítanak a természetes események, például villámcsapások után (amelyek sok helyszíni megfelelőt sokkal tovább tartottak volna le).

    Bár előnyös, ez a felhőre való áttérés nem kockázat nélkül történik. Ahogy a szervezetek felhőszolgáltatásokat vezetnek be, figyelembe kell venniük a lehetséges kockázati területeket, többek között a következőket:

  • Üzletmenet-folytonosság és vészhelyreállítás: A felhőszolgáltató pénzügyileg kifogástalan állapotban van egy olyan üzleti modellel, amely valószínűleg túléli és virágzik a szolgáltatás használata során? Rendelkezik-e a felhőszolgáltató olyan rendelkezésekkel, amelyek lehetővé teszik az ügyfél-folytonosságot, ha a szolgáltató pénzügyi vagy egyéb hibát tapasztal, például a forráskódját adja meg az ügyfeleknek, vagy nyílt forráskóddal nyitja meg?

    A Microsoft pénzügyi állapotával kapcsolatos további információkért és dokumentumokért tekintse meg a Microsoft befektetői kapcsolatait ismertető cikket.

  • Biztonsági: Követi a felhőszolgáltató az iparág biztonsági ajánlott eljárásait? Ezt független szabályozó testületek ellenőrizték?

    • Microsoft Defender for Cloud Apps lehetővé teszi több mint 16 000 felhőalkalmazás használatának felderítését, amelyek több mint 70 kockázati tényező alapján vannak rangsorolva és értékelve, hogy folyamatos betekintést nyújtson a felhőhasználatba, az árnyék informatikába és az árnyék informatikai részleg által a szervezet számára jelentett kockázatba.
    • A Microsoft Szolgáltatásmegbízhatósági portál elérhetővé teszi a jogszabályi megfelelőségi tanúsítványokat, auditjelentéseket, tollteszteket és egyebeket az ügyfelek számára. Ezek a dokumentumok számos részletet tartalmaznak a belső biztonsági gyakorlatokról (nevezetesen a SOC 2 Type 2 jelentésről és a FedRAMP Moderate rendszerbiztonsági tervről). Microsoft Defender a felhőhöz lehetővé teszi a biztonsági szabályzatok kezelését, és jelezheti az előre meghatározott iparági és szabályozási szabványoknak való megfelelés szintjét.

  • Üzleti versenytárs: A felhőszolgáltató jelentős üzleti versenytárs az ön iparágában? Rendelkezik megfelelő védelemmel a felhőszolgáltatási szerződésben vagy más eszközökkel, amelyekkel megvédheti vállalkozását a potenciálisan ellenséges műveletek ellen?

    Ebből a cikkből megtudhatja, hogyan kerüli el a Microsoft a felhőbeli ügyfelekkel való versengést.

  • Többfelhős: Számos szervezet de facto vagy szándékos többfelhős stratégiával rendelkezik. Ez szándékos cél lehet az egyetlen szállítótól való függés csökkentése vagy az egyedi legjobb fajtaképességek elérése érdekében, de azért is előfordulhat, mert a fejlesztők előnyben részesített vagy ismerős felhőszolgáltatásokat választottak, vagy a szervezet egy másik vállalkozást szerzett. Az októl függetlenül ez a stratégia potenciális kockázatokat és költségeket vezethet be, amelyeket kezelni kell, beleértve a következőket:

    • Állásidő több függőségből: A több felhőre épülő rendszerek több állásidő-kockázat forrásának is ki vannak téve, mivel a felhőszolgáltatókban (vagy a csapat használatában) bekövetkező fennakadások a vállalat leállását/megszakadását okozhatják. Ez a megnövekedett rendszerösszetettség a fennakadási események valószínűségét is növeli, mivel a csapattagok kevésbé valószínű, hogy teljes mértékben megértik az összetettebb rendszert.
    • Tárgyalási erő: A nagyobb szervezeteknek azt is figyelembe kell venniük, hogy az egyfelhős (kölcsönös elkötelezettség/partnerség) vagy a többfelhős stratégia (az üzletváltás képessége) nagyobb befolyást fog-e elérni a felhőszolgáltatókra, hogy a szervezet funkciókéréseit rangsorolják.
    • Megnövekedett karbantartási többletterhelés: Az informatikai és biztonsági erőforrások már túlterheltek a meglévő számítási feladatokból, és lépést tartanak egyetlen felhőplatform változásaival. Minden további platform tovább növeli ezt a többletterhelést, és eltávolítja a csapattagokat a nagyobb értékű tevékenységektől, például a technikai folyamat felgyorsítása az üzleti innováció felgyorsítása érdekében, tanácsadás üzleti csoportokkal a technológiák hatékonyabb használatáról stb.
    • Személyzet és képzés: A szervezetek gyakran nem veszik figyelembe a több platform támogatásához szükséges személyzeti követelményeket és a gyors ütemben kiadott új funkciók ismeretének és pénznemének fenntartásához szükséges képzést.