Alkalmazások és szolgáltatások

Az alkalmazások és a hozzájuk kapcsolódó adatok végső soron az üzleti érték elsődleges tárolójaként működnek a felhőplatformon. Bár a platform összetevői, például az identitás és a tárolás kritikus fontosságú elemei a biztonsági környezetnek, az alkalmazások az üzletmenetet fenyegető kockázatokban a következő módon játszanak szerepet:

  • Az üzleti folyamatokat alkalmazások és szolgáltatások foglalják össze és hajtják végre, és magas integritással kell rendelkezniük

  • Az üzleti adatokat az alkalmazás számítási feladatai tárolják és dolgozzák fel, és magas szintű titoktartást, integritást és rendelkezésre állást igényelnek.

Ez a szakasz a szervezet vagy a szervezet nevében mások által írt alkalmazásokra, illetve az IaaS virtuális gépekre telepített SaaS- vagy kereskedelmileg elérhető alkalmazásokra összpontosít.

Diagram of Application Models

Az olyan modern felhőplatformok, mint az Azure, az alkalmazások örökölt és modern generációinak üzemeltetésére is képesek

  • A régi alkalmazásokat szolgáltatott infrastruktúra (IaaS) virtuális gépek üzemeltetik, amelyek általában minden függőséget tartalmaznak, beleértve az operációs rendszert, a köztes szoftvereket és más összetevőket.

  • Modern A paaS-alkalmazások nem igénylik az alkalmazás tulajdonosát a mögöttes kiszolgálói operációs rendszerek (OSes) kezeléséhez és védelméhez, és néha teljesen "kiszolgáló nélküliek", és elsősorban szolgáltatásként működő függvényeket használnak.

    Megjegyzések: A modern alkalmazások népszerű formái az Azure App Servicesben és a tárolóba helyezett alkalmazásokban üzemeltetett alkalmazáskódok (bár a tárolók IaaS virtuális gépeken vagy a helyszínen is üzemeltethetők).

  • Hibrid – Bár a hibrid alkalmazások számos formát ölthetnek, a leggyakoribb az "IaaS plus" állapot, amelyben a régi alkalmazások modern architektúrára váltanak, és a régi összetevőket lecserélő modern szolgáltatásokra váltanak, vagy egy örökölt alkalmazást adnak hozzá.

Az alkalmazások biztonságossá tételéhez három különböző összetevőtípus biztonsági garanciáira van szükség:

  • Alkalmazáskód – Ez az a logika, amely meghatározza a megírt egyéni alkalmazást. A kód biztonsága az alkalmazástulajdonosok felelőssége az alkalmazásarchitektúra minden generációjában, beleértve a kódban szereplő nyílt forráskódú kódrészleteket vagy összetevőket is. A kód biztonságossá tételéhez azonosítani és enyhíteni kell az alkalmazás tervezéséből és megvalósításából eredő kockázatokat, valamint fel kell mérni a belefoglalt összetevők ellátási láncának kockázatát. Vegye figyelembe, hogy az alkalmazások mikroszolgáltatás-architektúrákká történő fejlődése az alkalmazáskód különböző aspektusait kisebb szolgáltatásokra és egyetlen monolitikus kódbázisra bontja.

  • Application Services – Az alkalmazás által használt különböző szabványosított összetevők, például adatbázisok, identitásszolgáltatók, eseményközpontok, IoT-eszközkezelés stb. A felhőszolgáltatások esetében ez egy megosztott felelősség:

    • Felhőszolgáltató – A mögöttes szolgáltatás biztonsága a felhőszolgáltató felelőssége

    • Alkalmazás tulajdonosa – Az alkalmazás tulajdonosa felelős az alkalmazás által használt szolgáltatáspéldány(ok) konfigurálásának és működésének biztonsági következményeiért, beleértve a szolgáltatásban tárolt és feldolgozott adatokat is.

  • Alkalmazásüzemeltetési platform – Ez az a számítási környezet, amelyben az alkalmazás ténylegesen fut és fut. A helyszínen, az Azure-ban és külső felhőkben, például az Amazon Web Servicesben (AWS) üzemeltetett alkalmazásokkal rendelkező nagyvállalatokban ez számos formában történhet, és jelentős eltéréseket okozhat a biztonságért felelős személyek esetében:

    • Az örökölt alkalmazásokhoz általában teljes operációs rendszer (és bármilyen köztes szoftver) szükséges, amely fizikai vagy virtualizált hardveren fut. A virtuális hardver üzemeltethető a helyszínen vagy IaaS virtuális gépeken. Ezt az operációs rendszert és a telepített köztes szoftvert/egyéb összetevőket az alkalmazás tulajdonosa vagy az infrastruktúra-csapat(ok) üzemeltetik és védik.
      A fizikai hardver- és operációsrendszer-virtualizálási összetevők (virtualizálási gazdagépek, operációs rendszerek és felügyeleti szolgáltatások) felelőssége a következő:

      • Helyszíni – Az alkalmazás tulajdonosa vagy szervezete felelős a karbantartásért és a biztonságért.

      • IaaS – A felhőszolgáltató felelős a mögöttes infrastruktúra karbantartásáért és biztonságáért, és az alkalmazás tulajdonosa szervezete felelős a virtuális gép konfigurációja, az operációs rendszer és a rá telepített összetevőkért.

    • A modern alkalmazások szolgáltatásként nyújtott platform (PaaS) környezetekben vannak üzemeltetve, például egy Azure-alkalmazásszolgáltatásban. A legtöbb alkalmazásszolgáltatás-típus esetében a mögöttes operációs rendszer absztrakcióra kerül az alkalmazás tulajdonosától, és a felhőszolgáltató biztosítja. Az alkalmazástulajdonosok felelősek a számukra biztosított alkalmazásszolgáltatás-konfigurációk biztonságáért.

    • A tárolók olyan alkalmazáscsomagolási mechanizmusok, amelyekben az alkalmazások el vannak távolítva a futtatásuk környezetéből. Ezek a tárolóalapú alkalmazások a fenti örökölt vagy modern modellekbe illeszkednek attól függően, hogy a felhőszolgáltató (Modern alkalmazások) vagy a szervezet által felügyelt kiszolgálón futtatják őket (a helyszínen vagy az IaaS-ben). További részletekért tekintse meg az alábbi tárolóbiztonsági szakaszt .

Üzletileg kritikus alkalmazások azonosítása és besorolása

Győződjön meg arról, hogy azonosította és besorolta a portfóliójában az üzleti funkciók szempontjából kritikus fontosságú alkalmazásokat.

A nagyvállalati szervezetek általában nagy alkalmazásportfólióval rendelkeznek, így a biztonsági program hatékonyságának növelése érdekében fontos, hogy hol érdemes időt és energiát fektetni a manuális és erőforrás-igényes feladatokba, például a fenyegetésmodellezésbe.

Azonosítsa azokat az alkalmazásokat, amelyeknek nagy a potenciális hatása, és/vagy magas kockázatnak van kitéve.

  • Magas potenciális hatás – Azonosítsa azokat az alkalmazásokat, amelyek a biztonság sérülése esetén jelentős hatással lennének a vállalkozásra. Ez a következő egy vagy több formáját öltheti:

    • Üzleti szempontból kritikus adatok – Olyan alkalmazások, amelyek adatokat dolgoznak fel vagy tárolnak, amelyek jelentős negatív hatással lennének az üzletmenetre vagy a küldetésre, ha a bizalmasság, az integritás vagy a rendelkezésre állás garantálása elveszne.

    • Szabályozott adatok – A pénzügyi eszközöket és a szabványok által szabályozott bizalmas személyes adatokat kezelő alkalmazások. Például a payment card industry (PCI) és az egészségügyi információk hordozhatóságáról és elszámoltathatóságáról szóló törvény (HIPAA).

    • Üzletileg kritikus rendelkezésre állás – Olyan alkalmazások, amelyek működése kritikus fontosságú a szervezetek üzleti küldetéséhez, például a bevételt generáló gyártósorokhoz, az eszközökhöz vagy az élet- és biztonság szempontjából kritikus szolgáltatásokhoz, valamint egyéb kritikus fontosságú funkciókhoz.

    • Jelentős hozzáférés – Olyan alkalmazások, amelyek magas potenciális hatással rendelkező rendszerekhez férnek hozzá olyan technikai eszközökkel, mint a

      • Tárolt hitelesítő adatok vagy kulcsok/tanúsítványok, amelyek hozzáférést biztosítanak az adatokhoz/szolgáltatásokhoz

      • Hozzáférés-vezérlési listákon vagy más módon megadott engedélyek

  • Magas kitettség a támadásoknak – Olyan alkalmazások, amelyek könnyen elérhetők a támadók, például a nyílt interneten futó webalkalmazások számára. Az örökölt alkalmazások nagyobb kitettséget is jelenthetnek, mivel a támadók és a behatolástesztelők gyakran célba veszik őket, mivel tudják, hogy ezek az örökölt alkalmazások gyakran nehezen javítható biztonsági résekkel rendelkeznek.

A DevOps-megközelítés bevezetése

A szervezeteknek a "Vízesés" fejlesztési ciklusról át kell térnie a folyamatos integráció DevOps-életciklusára, a folyamatos teljesítésre (CI/CD) az alkalmazások esetében a lehető leggyorsabban. A DevOps olyan személyek, folyamatok és eszközök uniója, amelyek lehetővé teszik az érték folyamatos átadását a végfelhasználók számára. A dev and ops összevonása azt jelenti, hogy a fejlesztési és üzemeltetési szemléleteket olyan multidiszciplináris csapatokban egyesítik, amelyek megosztott és hatékony gyakorlatokkal és eszközökkel működnek együtt.

A DevOps-modell növeli a szervezet azon képességét, hogy gyorsan kezelje a biztonsági problémákat anélkül, hogy egy vízesésmodell hosszabb tervezési és tesztelési ciklusára vár.

Kövesse a DevOps biztonsági útmutatóját

A szervezeteknek útmutatást és automatizálást kell használniuk az alkalmazások biztonságossá tételéhez a felhőben, nem pedig nulláról kiindulva.

Az ilyen modellek korai alkalmazóinak számítanak a külső szervezetek által tanult erőforrások és tanulságok felhasználásával a szervezet biztonsági helyzetének javítása kevesebb erőfeszítéssel és erőforrás-kiadással felgyorsítható.

Felhőszolgáltatások használata egyéni implementációk helyett

A fejlesztőknek a felhőszolgáltatótól elérhető szolgáltatásokat kell használniuk az olyan jól bevált funkciókhoz, mint az adatbázisok, a titkosítás, az identitáskönyvtár és a hitelesítés, és nem kell egyéni verziókat írniuk.

Ezek a szolgáltatások nagyobb biztonságot, megbízhatóságot és hatékonyságot biztosítanak, mivel a felhőszolgáltatók olyan dedikált csapatokkal üzemeltetik és védik őket, amelyek ezekben a területeken mélyreható szakértelemmel rendelkeznek. Ezeknek a szolgáltatásoknak a használatával a fejlesztői erőforrásokat is megszabadíthatja a közmondásos kerék újrafelfedezésétől, hogy a fejlesztési időt a vállalkozás egyedi igényeire összpontosíthassák. Ezt a gyakorlatot kell követni az új alkalmazásfejlesztés során felmerülő kockázatok elkerülése, valamint a meglévő alkalmazások kockázatának csökkentése érdekében akár a tervezett frissítési ciklus, akár a biztonságközpontú alkalmazásfrissítés során.

Számos olyan képesség, amelyet a potenciális biztonsági hatás miatt először rangsorolásra kell használni:

  • Identitás – A felhasználói címtárak és más hitelesítési funkciók fejlesztése összetett feladat, és kritikus fontosságú a biztonsági garanciák szempontjából. Kerülje a benőtt hitelesítési megoldások használatát, és előnyben részesítse az olyan fejlett képességeket, mint az Azure Active Directory (Azure AD), az Azure AD B2B, az Azure AD B2C vagy a külső megoldások a felhasználók, partnerek, ügyfelek, alkalmazások, szolgáltatások és egyéb entitások hitelesítéséhez és engedélyezéséhez.

  • Adatvédelem – A fejlesztőknek olyan felhőszolgáltatóktól származó, már meglévő képességeket kell használniuk, mint a natív titkosítás a felhőszolgáltatásokban az adatok titkosításához és védelméhez. A biztonsági világ tele van példákkal az olyan adatok vagy jelszavak védelmére tett sikertelen kísérletekre, amelyek nem állnak készen a valós támadásokra. Ha a kriptográfia közvetlen használatára van szükség, a fejlesztőknek jól bevált titkosítási algoritmusokat kell meghívniuk, és nem kell megpróbálniuk kitalálni a sajátjukat.

  • Kulcskezelés – Ideális esetben identitást használjon hitelesítéshez a kulcsok közvetlen kezelése helyett (lásd : Identitáshitelesítés előnyben részesítése kulcsokkal szemben). Olyan helyzetekben, amikor a kulcsokhoz hozzáférést igénylő szolgáltatásokhoz való hozzáféréshez egy kulcskezelő szolgáltatást, például az Azure Key Vaultot vagy az AWS kulcskezelő szolgáltatást kell használnia a kulcsok kezeléséhez és védelméhez, ahelyett, hogy az alkalmazáskódban lévő kulcsokat megkísérli biztonságosan kezelni. A CredScan használatával felderítheti az alkalmazás kódjában potenciálisan közzétett kulcsokat.

  • Alkalmazáskonfigurációk – Az alkalmazások inkonzisztens konfigurációi biztonsági kockázatokat okozhatnak. Az Azure App Configuration szolgáltatással központilag kezelheti az alkalmazásbeállításokat és a funkciójelölőket, ami segít csökkenteni ezt a kockázatot.

Natív biztonsági képességek használata az alkalmazásszolgáltatásokban

Külső biztonsági összetevők (adattitkosítás, hálózati forgalomszűrés, fenyegetésészlelés és egyéb funkciók) hozzáadása helyett használja a felhőszolgáltatásokba beépített natív biztonsági képességeket.

A natív biztonsági vezérlőket a szolgáltató tartja karban és támogatja, kiküszöbölve vagy csökkentve a külső biztonsági eszközök integrálásához és az integrációk frissítéséhez szükséges időt. A felhőszolgáltatások gyorsan fejlődnek, ami jelentősen növeli a külső eszközök karbantartásának terheit, és növeli a biztonsági láthatóság és az eszközök védelmének elvesztésének kockázatát, ha az eszköz nem tart lépést a felhőszolgáltatással.

Identitáshitelesítés előnyben részesítve a kulcsokat

Ha elérhető, mindig identitásszolgáltatásokkal hitelesítse magát titkosítási kulcsok helyett.

A kulcsok biztonságos kezelése az alkalmazáskóddal nehézkes és rendszeresen olyan hibákhoz vezet, mint például a bizalmas hozzáférési kulcsok véletlen közzététele a kódtárakban, például a GitHubon. Az identitásrendszerek biztonságos és használható hozzáférést biztosítanak a hozzáférés-vezérléshez a kulcsrotálás beépített kifinomult mechanizmusaival, az anomáliák figyelésével és egyebekkel. A legtöbb szervezet rendelkezik olyan képzett csapatokkal is, amelyek az identitásrendszerek kezelésével foglalkoznak, és kevés (ha van) olyan személy, aki aktívan kezeli a kulcsfontosságú biztonsági rendszereket.

Az Azure AD-hitelesítést (például Azure Storage, Azure App Service, Azure Backup) kínáló szolgáltatások esetében használja a hitelesítéshez és engedélyezéshez. Az identitások fejlesztők számára történő használatának további egyszerűsítése érdekében a felügyelt identitások használatával identitásokat rendelhet erőforrásokhoz, például virtuális gépekhez és App Serviceshez, így a fejlesztőknek nem kell az alkalmazáson belül kezelniük az identitásokat.

Alulról felfelé haladó megközelítés a biztonsági hibák mennyiségének és hatásának csökkentéséhez

image showing bottom-up approach to reduce security bug volume and impact

A biztonsági eljárások és eszközök a fejlesztési életciklus során történő implementálásával csökkentheti az alkalmazás biztonsági hibáinak számát és lehetséges súlyosságát.

A biztonsági hibák azt eredményezhetik, hogy az alkalmazások bizalmas adatokat adnak ki, lehetővé téve a bűnözők számára az adatok/rekordok módosítását, vagy az adatok/alkalmazások elérhetetlenné válását az ügyfelek és az alkalmazottak számára. Az alkalmazásoknak mindig lesznek olyan logikai hibái, amelyek biztonsági kockázatot jelenthetnek, ezért fontos felderíteni, kiértékelni és kijavítani őket, hogy elkerülje a szervezet hírnevét, bevételét vagy árrését. Ezeket egyszerűbb és olcsóbb megoldani a fejlesztési életciklus korábbi szakaszában, mint az alkalmazás tesztelésének befejezése, éles használatban lévő vagy gyakran "balra tolódás" vagy "balra leküldés" elvnek nevezett hibák kijavítása.

Az alkalmazáskockázat mérséklése a biztonsági eljárások és eszközök a fejlesztési életciklusba való integrálásával érhető el, amelyet gyakran biztonságos fejlesztési életciklusnak (SDL vagy SDLC) neveznek. A Microsoft számos javaslatot tett közzé az Azure-beli biztonságos alkalmazások fejlesztése című tanulmányban a Microsoft biztonsági fejlesztési életciklusa alapján, hogy a bemeneti és kimeneti ellenőrzéssel, intelligens teszteléssel, támadási felületi felülvizsgálatokkal és egyebekkel mérsékelje a gyakori kockázatokat.

Felülről lefelé történő megközelítés fenyegetésmodellezéssel

image showing top-down approach through threat modeling

Az üzletileg kritikus fontosságú alkalmazások fenyegetésmodellezésével felderítheti és mérsékelheti a szervezetet érintő lehetséges kockázatokat.

A fenyegetésmodellezés azonosítja magát az alkalmazást érintő kockázatokat, valamint azokat a kockázatokat, amelyeket az alkalmazás jelenthet a vállalat számára, különösen egy nagyobb rendszer egyes alkalmazásainak kiértékelésekor.

A fenyegetésmodellezés az alkalmazásfejlesztés vagy az éles környezet bármely szakaszában használható, de egyedülállóan hatékony az új funkciók tervezési fázisaiban, mivel az alkalmazáshoz még nem léteznek valós adatok.

Mivel a fenyegetésmodellezés egy képességigényes gyakorlat, javasoljuk, hogy az időbefektetés minimalizálása és a biztonsági érték maximalizálása érdekében intézkedésekkel járjon el:

  1. Kockázat szerinti rangsorolás – A fenyegetésmodellezés alkalmazása az üzleti szempontból kritikus fontosságú alkalmazásokra, amelyek nagyobb hatással lennének az üzletmenetre, ha illetéktelen kezekbe kerülnének

  2. Hatókör korlátozása – A fenyegetésmodellezés fokozatos részletekbe ásásával gyorsan azonosíthatja a gyors győzelmeket és a végrehajtható kockázatcsökkentéseket, mielőtt sok manuális munkát végezne:

    1. Kezdje az alábbi egyszerű kérdések módszerével (lásd az Egyszerű kérdések metódust), hogy gyorsan betekintést nyerjen a kockázatokba, és hogy létezik-e alapszintű védelem.

    2. Fokozatosan értékelje ki az alkalmazástervezést – mivel rendelkezésre áll erőforrás és szakértelem, lépjen egy fejlettebb elemzésre a STRIDE módszer használatával, vagy egy másik, a csapat által már használt hasonló fenyegetésmodellezési technikákkal . Kezdje az architektúraszintű tervezéssel, és fokozatosan növelje a részleteket, ahogy az idő és az erőforrások lehetővé teszik:

      1. Rendszerszintű tervezés – alkalmazásokat és azok interakcióinak módját tartalmazza

      2. Alkalmazásszint – az alkalmazás összetevőit és az egymással való interakciót foglalja magában

      3. Összetevő szintje – tartalmazza az egyes összetevők összeállításának módját, valamint azt, hogy az egyes összetevők hogyan kommunikálnak egymással

  3. Igazodás a fejlesztési életciklushoz – Optimalizálhatja erőfeszítéseit a fenyegetésmodellezési tevékenységek alkalmazásfejlesztési életciklusokhoz való igazításával.

    1. Vízesés – győződjön meg arról, hogy a nagyobb projekteknek tartalmazniuk kell a fenyegetésmodellezést a tervezési folyamat során és az alkalmazás jelentős frissítései során.

    2. DevOps – Veszélyforrás-modellezési tevékenységek aktiválása olyan gyakorisággal, amely biztonsági értéket ad hozzá a fejlesztői csapatok túlterhelése nélkül. A jó integrációs pontok az alkalmazás jelentős funkcióinak vagy változásainak bevezetésekor, valamint rendszeres, ismétlődő naptárütemezések, például üzleti szempontból kritikus fontosságú alkalmazások esetében negyedévente.

    3. Örökölt alkalmazások – Ezek az alkalmazások általában nem rendelkeznek támogatással, forráskód-hozzáféréssel és/vagy szakértelemmel a szervezetben, ezért a fenyegetésmodellezést a lehető legjobban elvégezheti az elérhető alkalmazástudással/szakértelemmel.

Egyszerű kérdések módszere

Ez az egyszerű kérdőjelezési módszer arra szolgál, hogy a biztonsági szakemberek és a fejlesztők elkezdjenek fenyegetésmodellezést, mielőtt továbblépnek egy fejlettebb módszerre, például a STRIDE vagy az OWASP módszerére (lásd: Felülről lefelé haladó megközelítés fenyegetésmodellezéssel).

Minden alkalmazáshoz vagy összetevőhöz tegye fel és válaszolja meg ezeket a kérdéseket

  • Az Azure AD, a TLS (kölcsönös hitelesítéssel) vagy egy másik, a biztonsági csapat által jóváhagyott modern biztonsági protokoll használatával hitelesíti a kapcsolatokat? Ez védelmet nyújt az alkalmazáshoz és az adatokhoz való jogosulatlan hozzáféréssel szemben

    • Felhasználók és az alkalmazás között (ha van)

    • Különböző alkalmazásösszetevők és szolgáltatások között (ha van)

  • Korlátozza, hogy mely fiókok rendelkezzenek hozzáféréssel az alkalmazásban lévő adatok írásához vagy módosításához, csak a szükséges fiókokra? Ez csökkenti a jogosulatlan adatok illetéktelen módosításának/módosításának kockázatát

  • Az alkalmazástevékenységet egy Biztonsági információ- és eseménykezelésbe (SIEM) naplózza és eteti az Azure Monitoron keresztül, vagy egy hasonló megoldással? Ez segít a biztonsági csapatnak a támadások észlelésében és gyors kivizsgálásában.

  • Az üzletileg kritikus fontosságú adatokat a biztonsági csapat által jóváhagyott titkosítás védi? Ez segít megvédeni az inaktív adatok jogosulatlan másolása ellen.

  • TLS használatával titkosítja a bejövő és kimenő hálózati forgalmat? Ez segít védelmet nyújtani az adatok jogosulatlan másolása ellen átvitel közben.

  • Az alkalmazás védett az elosztott szolgáltatásmegtagadási (DDoS) támadások ellen olyan szolgáltatások használatával, mint az Azure DDoS Protection, az Akamai vagy hasonló? Ez védelmet nyújt az alkalmazás túlterhelésére tervezett támadások ellen, így nem használható

  • Az alkalmazás tárol-e bejelentkezési hitelesítő adatokat vagy kulcsokat más alkalmazások, adatbázisok vagy szolgáltatások eléréséhez? Ez segít megállapítani, hogy egy támadás az alkalmazással támadhat-e más rendszereket.

  • Az alkalmazásvezérlők lehetővé teszik az Ön által üzemeltetett települések biztonsági és adatvédelmi követelményeinek teljesítését? (Ez segít megvédeni a felhasználó személyes adatait, és elkerülni a megfelelőségi bírságokat)

Fontos: A biztonság egy összetett téma, és a lehetséges kockázatokat csak az intelligens motivált támadók képzelőereje korlátozza. Ezek a kérdések a támadók által könnyen kihasználható hiányosságok azonosítására szolgálnak. Miközben ezzel a módszerrel fejleszti a kényelmet és a kompetenciákat, a fejlett fenyegetésmodellezési technikákkal növelheti a fenyegetésmodellezési képességet.

Fejlett fenyegetésmodellezési technikák

Egy átfogóbb fenyegetésmodell több potenciális kockázatot képes azonosítani, két népszerű technika a STRIDE és az OWASP

  • Microsoft A security development lifecycle dokumentált egy fenyegetésmodellezési folyamatot, és kiadott egy ingyenes eszközt, amely segítséget nyújt ehhez a folyamathoz

    • Ez a metódus kiértékeli az alkalmazás összetevőit és kapcsolatait/kapcsolatait a lehetséges kockázatokkal szemben, amelyek a STRIDE mnemonikusra vannak leképezve:

      • Identitáshamisítás

      • Illetéktelen adatmódosítás

      • Letagadhatóság

      • Információfelfedés

      • Szolgáltatásmegtagadás

      • Jogosultságszint-emelés

    • Ez a módszer a tervezés bármely szintjére alkalmazható a magas szintű architektúraspecifikus alkalmazásösszetevőkből.

  • OWASP – Az Open Web Application Security Project (OWASP) dokumentálta az alkalmazások fenyegetésmodellezési megközelítését, amely a STRIDE-ra és más módszerekre hivatkozik https://www.owasp.org/index.php/Application_Threat_Modeling

Webalkalmazási tűzfalak használata

A webalkalmazási tűzfalak (WAF-ek) csökkentik annak kockázatát, hogy a támadók kihasználhatják az alkalmazások gyakran tapasztalt biztonsági réseit. Bár nem tökéletes, a WAF-k minimális biztonsági szintet biztosítanak a webalkalmazások számára.

A WAF-k fontos kockázatcsökkentést jelentenek, mivel a támadók webalkalmazásokat céloznak meg egy, az ügyfélvégponthoz hasonló szervezetbe irányuló bemeneti ponthoz. A WAF-k mindkét

  • Erős alkalmazásbiztonsági program nélkül rendelkező szervezetek, mivel ez egy kritikus biztonsági intézkedés (hasonlóan a repülőben lévő ejtőernyőkhez). Vegye figyelembe, hogy nem ez az egyetlen tervezett biztonsági mechanizmus az alkalmazások biztonsági hibáinak mennyiségének és súlyosságának csökkentéséhez. Részletekért lásd: A biztonsági hibák mennyiségének és hatásának csökkentése.

  • Azok a szervezetek, amelyek WAF-ként fektettek be az alkalmazásbiztonságba, értékes további mélységi védelmet nyújtanak. Ebben az esetben a WAF-k végső biztonsági mechanizmusként működnek abban az esetben, ha a fejlesztési életciklus biztonsági gyakorlatai kihagytak egy biztonsági hibát.

A Microsoft WAF-képességeket tartalmaz az Azure Application Gatewayben , és számos gyártó kínál ilyen képességeket önálló biztonsági berendezésekként vagy a következő generációs tűzfalak részeként.

Kövesse a tárolóbiztonságra vonatkozó ajánlott eljárásokat

A tárolókban üzemeltetett alkalmazásoknak követniük kell az általános alkalmazás-ajánlott eljárásokat, valamint az új alkalmazásarchitektúra-típus kezelésére vonatkozó konkrét irányelveket

A tárolóalapú alkalmazások ugyanolyan kockázatokkal néznek szembe, mint bármely alkalmazás, és új követelményeket is hozzáad a tárolóalapú alkalmazások biztonságos üzemeltetéséhez és felügyeletéhez.

Az alkalmazástárolók architektúrái egy új absztrakciós és felügyeleti eszközréteget (általában a Kubernetes-t) vezetnek be, amely növeli a fejlesztői hatékonyságot és a DevOps-alapelvek alkalmazását.

Bár ez egy gyorsan változó terület, számos fontos tanulság és ajánlott eljárás vált egyértelművé:

  • Kubernetes által felügyelt szolgáltatás használata a Kubernetes telepítése és kezelése helyett
    A Kubernetes egy nagyon összetett rendszer, és még mindig számos olyan alapértelmezett beállítással rendelkezik, amelyek nem biztonságosak, és kevés Kubernetes biztonsági szakértő van a piacon. Bár ez az elmúlt években minden kiadással javult, még mindig sok kockázatot kell enyhíteni.

  • Tároló és tároló ellátási láncának ellenőrzése
    Ahogyan az alkalmazásokhoz hozzáadott nyílt forráskódú kódok biztonságát is ellenőriznie kell, az alkalmazásokhoz hozzáadott tárolókat is ellenőriznie kell.

    • Győződjön meg arról, hogy a tároló felépítésére alkalmazott eljárások érvényesítve vannak az Ön biztonsági szabványaihoz, például a biztonsági frissítések alkalmazásához, a nemkívánatos kódok , például a backdoorok és a tiltott kriptopénz bányászok kereséséhez, a biztonsági rések kereséséhez és a biztonságos fejlesztési eljárások alkalmazásához.

    • Rendszeresen ellenőrizze a tárolókban az ismert kockázatokat a tárolóregisztrációs adatbázisban használat előtt vagy használat közben.

  • Az ismert jó tárolók beállításjegyzékének beállítása
    Ez lehetővé teszi, hogy a szervezet fejlesztői gyorsan, kis súrlódás mellett használják a biztonsági ellenőrzéssel ellenőrzött tárolókat. Emellett létrehozhat egy folyamatot a fejlesztők számára az új tárolók biztonsági ellenőrzésének kéréséhez és gyors lekéréséhez, hogy a fejlesztőket arra ösztönözzék, hogy ezt a folyamatot használják, és ne megkerüljenek.

  • Ne futtasson tárolókat gyökérként vagy rendszergazdaként, kivéve, ha kifejezetten szükséges
    A tárolók korai verziói gyökérszintű jogosultságokat igényelnek (ami megkönnyíti a támadásokat), de ez a jelenlegi verziók esetében már nem szükséges.

  • Tárolók figyelése
    Győződjön meg arról, hogy olyan biztonsági figyelési eszközöket telepít, amelyek tudatában vannak a rendellenes viselkedés figyelésének és az incidensek kivizsgálásának.

Következő lépések

A Microsoft további biztonsági útmutatóiért tekintse meg a Microsoft biztonsági dokumentációját.