Biztonságos alkalmazások tervezése az Azure-ban

Ebben a cikkben bemutatjuk a felhőalkalmazások tervezésekor figyelembe veendő biztonsági tevékenységeket és vezérlőket. A microsoftos biztonsági fejlesztési életciklus (SDL) követelményei és tervezési fázisai során figyelembe veendő biztonsági kérdések és fogalmak mellett képzési források is szerepelnek. A cél az, hogy segítsen meghatározni azokat a tevékenységeket és Azure-szolgáltatásokat, amelyekkel biztonságosabb alkalmazásokat tervezhet.

A cikk a következő SDL-fázisokat ismerteti:

• Oktatás
• Követelmények
• Tervezés

Oktatás

Mielőtt elkezdené fejleszteni a felhőalkalmazást, szánjon időt az Azure-beli biztonság és adatvédelem megismerésére. Ezzel a lépéssel csökkentheti az alkalmazás kihasználható biztonsági réseinek számát és súlyosságát. Felkészültebb lesz arra, hogy megfelelően reagáljon a folyamatosan változó veszélyforrásokra.

A betanítási szakaszban a következő erőforrások segítségével ismerkedhet meg a fejlesztők számára elérhető Azure-szolgáltatásokkal és az Azure biztonsági ajánlott eljárásaival:

• Az Azure fejlesztői útmutatója bemutatja, hogyan kezdheti el az Azure-t. Az útmutató bemutatja, hogy mely szolgáltatásokat használhatja az alkalmazások futtatásához, az adatok tárolásához, az intelligencia beépítéséhez, az IoT-alkalmazások létrehozásához és a megoldások hatékonyabb és biztonságosabb üzembe helyezéséhez.

• Az Azure-fejlesztőknek készült első lépések útmutatója alapvető információkat nyújt azoknak a fejlesztőknek, akik fejlesztési igényeiknek megfelelően szeretnék használni az Azure platformot.

• Az SDK-k és -eszközök az Azure-ban elérhető eszközöket ismertetik.

• Az Azure DevOps Services fejlesztési együttműködési eszközöket biztosít. Az eszközök közé tartoznak a nagy teljesítményű folyamatok, az ingyenes Git-adattárak, a konfigurálható Kanban-táblák, valamint a kiterjedt automatizált és felhőalapú terheléstesztelés. A DevOps Resource Center egyesíti az erőforrásainkat a DevOps-gyakorlatok, a Git-verziókövetés, az agilis módszerek, a Microsoft DevOps-ral való együttműködése és a saját DevOps-folyamat értékeléséhez.

• Az éles környezetbe való leküldés előtt megfontolandó öt biztonsági elem bemutatja, hogyan védheti meg webalkalmazásait az Azure-ban, és hogyan védheti meg alkalmazásait a leggyakoribb és legveszélyesebb webalkalmazás-támadásokkal szemben.

• Az Azure-hoz készült Secure DevOps Kit szkriptek, eszközök, bővítmények és automatizálások gyűjteménye, amelyek kielégítik a kiterjedt automatizálást használó DevOps-csapatok átfogó Azure-előfizetési és erőforrás-biztonsági igényeit. Az Azure-hoz készült Secure DevOps Kit bemutatja, hogyan integrálhatja zökkenőmentesen a biztonságot a natív DevOps-munkafolyamatokba. A készlet olyan eszközöket kezel, mint a biztonsági ellenőrző tesztek (SVT-k), amelyek segítségével a fejlesztők biztonságos kódot írhatnak, és tesztelhetik a felhőalkalmazásaik biztonságos konfigurációját a kódolási és korai fejlesztési szakaszokban.

• Az Azure biztonsági ajánlott eljárásai és mintái – A felhőmegoldások Azure-beli tervezése, üzembe helyezése és kezelése során használható ajánlott biztonsági eljárások gyűjteménye. Az útmutató az informatikai szakemberek erőforrása. Ilyenek lehetnek a biztonságos Azure-megoldások készítését és üzembe helyezését végző tervezők, tervezők, fejlesztők és tesztelők.

Követelmények

A követelmények definíciós fázisa kulcsfontosságú lépés annak meghatározásában, hogy mi az alkalmazás, és mit tesz a kiadáskor. A követelmények fázisa egyben az alkalmazásba épített biztonsági vezérlők átgondolása is. Ebben a fázisban az SDL-ben végrehajtott lépéseket is meg kell kezdenie annak biztosítása érdekében, hogy biztonságos alkalmazást engedjen ki és telepítsen.

Fontolja meg a biztonsági és adatvédelmi problémákat

Ebben a fázisban érdemes megfontolni az alapvető biztonsági és adatvédelmi problémákat. A projekt elején elfogadható biztonsági és adatvédelmi szintek meghatározása segít a csapatnak:

• A biztonsági problémák kockázatainak megismerése.
• Biztonsági hibák azonosítása és javítása a fejlesztés során.
• A teljes projektben alkalmazza a biztonság és az adatvédelem meghatározott szintjeinek alkalmazását.

Amikor megírja az alkalmazásra vonatkozó követelményeket, ügyeljen arra, hogy olyan biztonsági vezérlőket vegye figyelembe, amelyek segíthetnek az alkalmazás és az adatok biztonságának megőrzésében.

Biztonsági kérdések feltevése

Tegye fel a következő biztonsági kérdéseket:

• Az alkalmazás bizalmas adatokat tartalmaz?

• Gyűjt vagy tárol az alkalmazásom olyan adatokat, amelyek megkövetelik, hogy betartsam az iparági szabványokat és megfelelőségi programokat, például a Federal Financial Institution Examination Council (FFIEC) vagy a Payment Card Industry Data Security Standards (PCI DSS)?

• Az alkalmazás olyan bizalmas személyes vagy ügyféladatokat gyűjt vagy tartalmaz, amelyek önállóan vagy más adatokkal is felhasználhatók egyetlen személy azonosítására, kapcsolatfelvételére vagy megkeresésére?

• Az alkalmazás olyan adatokat gyűjt vagy tartalmaz, amelyek felhasználhatók egy adott személy orvosi, oktatási, pénzügyi vagy foglalkoztatási adatainak eléréséhez? Az adatok bizalmassági szintjének azonosítása a követelmények szakaszában segít az adatok besorolásában és az alkalmazáshoz használt adatvédelmi módszer azonosításában.

• Hol és hogyan tárolják az adataimat? Fontolja meg, hogyan monitorozza az alkalmazás által a váratlan változásokhoz (például lassabb válaszidőkhöz) használt tárolási szolgáltatásokat. Képes befolyásolni a naplózást, hogy részletesebb adatokat gyűjtsön, és részletesen elemezzen egy problémát?

• Az alkalmazásom elérhető a nyilvánosság számára (az interneten) vagy belsőleg? Ha az alkalmazás elérhető a nyilvánosság számára, hogyan védheti meg az esetleg összegyűjtött adatokat a helytelen használattól? Ha az alkalmazás csak belsőleg érhető el, vegye figyelembe, hogy a szervezetében kinek és mennyi ideig kell hozzáféréssel rendelkeznie az alkalmazáshoz.

• Tisztában van az identitásmodellel, mielőtt elkezdené megtervezni az alkalmazást? Meg tudja állapítani, hogy a felhasználók kiknek mondják magukat, és hogy milyen jogosultsággal rendelkezik a felhasználó?

• Az alkalmazásom érzékeny vagy fontos feladatokat (például pénzátadást, ajtók kinyitását vagy gyógyszerszállítást) hajt végre? Gondolja át, hogyan ellenőrizheti, hogy a bizalmas feladatot végrehajtó felhasználó jogosult-e a feladat végrehajtására, és hogyan hitelesítheti, hogy az illető az, akinek mondja magát. Az engedélyezés (AuthZ) egy hitelesített biztonsági tag engedélyének megadása a művelethez. A hitelesítés (AuthN) az a cselekmény, amely megkérdőjelezi egy fél jogos hitelesítő adatait.

• Az alkalmazásom végez-e kockázatos szoftvertevékenységeket, például lehetővé teszi a felhasználók számára fájlok vagy egyéb adatok feltöltését vagy letöltését? Ha az alkalmazás kockázatos tevékenységeket végez, gondolja át, hogy az alkalmazás hogyan védi meg a felhasználókat a rosszindulatú fájlok vagy adatok kezelésétől.

Az OWASP áttekintése a 10. helyen

Tekintse át az OWASP 10 alkalmazásbiztonsági kockázatait. Az OWASP Top 10 a webalkalmazások kritikus biztonsági kockázataival foglalkozik. Ezeknek a biztonsági kockázatoknak a megismerése segíthet olyan követelmények és tervezési döntések meghozatalában, amelyek minimalizálják ezeket a kockázatokat az alkalmazásban.

Fontos átgondolni a biztonsági vezérlőket, hogy megelőzzük a behatolásokat. Azt is szeretné azonban feltételezni, hogy a szabálysértés bekövetkezik . Feltételezve, hogy a biztonsági incidens segít előre megválaszolni néhány fontos kérdést a biztonsággal kapcsolatban, így nem kell őket vészhelyzetben megválaszolni:

• Hogyan fogom észlelni a támadást?
• Mit fogok tenni, ha támadás vagy behatolás történik?
• Hogyan fogok helyreállni a támadásból, mint az adatok kiszivárgása vagy illetéktelen módosítása?

Tervezés

A tervezési fázis kritikus fontosságú a tervezési és funkcionális specifikációk ajánlott eljárásainak kialakításához. Emellett kritikus fontosságú a kockázatelemzés elvégzése, amely segít a projekt során felmerülő biztonsági és adatvédelmi problémák megoldásában.

Ha rendelkezik biztonsági követelményekkel, és biztonságos tervezési fogalmakat használ, elkerülheti vagy minimalizálhatja a biztonsági hibák lehetőségét. A biztonsági hiba az alkalmazás kialakításának olyan felügyelete, amely lehetővé teheti, hogy a felhasználó rosszindulatú vagy váratlan műveleteket hajthasson végre az alkalmazás kiadása után.

A tervezési fázisban gondolja át, hogyan alkalmazhatja a biztonságot rétegekben; egy védelmi szint nem feltétlenül elég. Mi történik, ha egy támadó túllép a webalkalmazási tűzfalon (WAF)? Azt szeretné, hogy egy másik biztonsági ellenőrzés legyen érvényben a támadás ellen.

Ennek szem előtt tartásával a következő biztonságos tervezési fogalmakat és a biztonságos alkalmazások tervezésekor kezelni kívánt biztonsági vezérlőket tárgyaljuk:

• Használjon biztonságos kódtárat és egy szoftveres keretrendszert.
• Keresse meg a sebezhető összetevőket.
• Használjon fenyegetésmodellezést az alkalmazás tervezése során.
• Csökkentse a támadási felületet.
• Identitásszabályzat elfogadása elsődleges biztonsági szegélyként.
• A fontos tranzakciókhoz újrahitelesítés szükséges.
• Kulcskezelési megoldással biztonságossá teheti a kulcsokat, a hitelesítő adatokat és az egyéb titkos kulcsokat.
• Bizalmas adatok védelme.
• A feladatbiztos mértékek implementálása.
• Használja ki a hiba- és kivételkezelés előnyeit.
• Használjon naplózást és riasztást.

Biztonságos kódtár és szoftveres keretrendszer használata

A fejlesztéshez használjon biztonságos kódtárat és egy beágyazott biztonságot tartalmazó szoftveres keretrendszert. A fejlesztők használhatják a meglévő, bevált funkciókat (titkosítás, bemeneti higiénia, kimeneti kódolás, kulcsok vagy kapcsolati sztring, és bármi mást, amely biztonsági vezérlőnek minősülne) ahelyett, hogy teljesen új biztonsági vezérlőket fejlesztenének. Ez segít védekezni a biztonsággal kapcsolatos tervezési és megvalósítási hibák ellen.

Győződjön meg arról, hogy a keretrendszer legújabb verzióját és a keretrendszerben elérhető összes biztonsági funkciót használja. A Microsoft minden fejlesztő számára kínál fejlesztési eszközöket , amelyek bármilyen platformon vagy nyelven dolgoznak a felhőalkalmazások biztosításához. A különböző SDK-k közül választva a választott nyelvvel kódokat használhat. Kihasználhatja a teljes körű integrált fejlesztési környezetek (IDE-k) és a speciális hibakeresési képességekkel és beépített Azure-támogatás rendelkező szerkesztők előnyeit.

A Microsoft különböző nyelveket, keretrendszereket és eszközöket kínál, amelyekkel alkalmazásokat fejleszthet az Azure-ban. Ilyen például az Azure a .NET- és a .NET Core-fejlesztők számára. Minden általunk kínált nyelvhez és keretrendszerhez rövid útmutatókat, oktatóanyagokat és API-hivatkozásokat találhat, amelyek segítenek a gyors kezdésben.

Az Azure különböző szolgáltatásokat kínál webhelyek és webalkalmazások üzemeltetéséhez. Ezek a szolgáltatások lehetővé teszik a fejlesztést a kedvenc nyelven, legyen szó .NET, .NET Core, Java, Ruby, Node.js, PHP vagy Python nyelvről. Azure-alkalmazás Service Web Apps (Web Apps) ezen szolgáltatások egyike.

A Web Apps hozzáadja a Microsoft Azure erejét az alkalmazáshoz. Ez magában foglalja a biztonságot, a terheléselosztást, az automatikus skálázást és az automatizált felügyeletet. A Web Apps devOps-funkcióit is kihasználhatja, például a csomagkezelést, az átmeneti környezeteket, az egyéni tartományokat, az SSL/TLS-tanúsítványokat, valamint az Azure DevOps, a GitHub, a Docker Hub és más források folyamatos üzembe helyezését.

Az Azure más szolgáltatásokat is kínál, amelyekkel webhelyeket és webalkalmazásokat üzemeltethet. A legtöbb forgatókönyvhöz a Webalkalmazások a legjobb választás. Mikroszolgáltatás-architektúra esetén fontolja meg az Azure Service Fabric használatát. Ha a kódot futtató virtuális gépek nagyobb mértékű felügyeletére van szüksége, akkor érdemes megfontolnia az Azure Virtual Machines használatát. További információ az Azure-szolgáltatások közötti választásról: Azure-alkalmazás Service, Virtual Machines, Service Fabric és Cloud Services összehasonlítása.

Frissítések alkalmazása összetevőkre

A biztonsági rések elkerülése érdekében folyamatosan leltárba kell helyeznie mind az ügyféloldali, mind a kiszolgálóoldali összetevőket (például keretrendszereket és kódtárakat), valamint azok frissítési függőségeit. Az új biztonsági rések és a frissített szoftververziók folyamatosan jelennek meg. Győződjön meg arról, hogy van egy folyamatos terve a frissítések és konfigurációs módosítások figyelésére, osztályozására és alkalmazására a használt kódtárakra és összetevőkre.

Az eszközjavaslatokért tekintse meg az Open Web Application Security Project (OWASP) (Open Web Application Security Project, OWASP) oldalt az ismert biztonsági résekkel rendelkező összetevők használatával kapcsolatban. Feliratkozhat e-mailes riasztásokra is a használt összetevőkkel kapcsolatos biztonsági rések esetén.

Fenyegetésmodellezés használata az alkalmazás tervezése során

A fenyegetésmodellezés a vállalkozást és az alkalmazást fenyegető potenciális biztonsági fenyegetések azonosításának, majd a megfelelő kockázatcsökkentések biztosításának folyamata. Az SDL azt határozza meg, hogy a csapatoknak a tervezési fázisban részt kell vennie a fenyegetésmodellezésben, amikor a lehetséges problémák megoldása viszonylag egyszerű és költséghatékony. A fenyegetésmodellezés használata a tervezési fázisban jelentősen csökkentheti a teljes fejlesztési költséget.

A fenyegetésmodellezési folyamat megkönnyítése érdekében az SDL fenyegetésmodellezési eszközt nem biztonsági szakértők szem előtt tartásával terveztük meg. Ez az eszköz megkönnyíti a fenyegetésmodellezést minden fejlesztő számára azáltal, hogy világos útmutatást nyújt a fenyegetésmodellek létrehozásához és elemzéséhez.

Az alkalmazás tervezésének modellezése és a STRIDE-fenyegetések számbavétele– hamisítás, illetéktelen módosítás, elutasítás, információfeltárás, szolgáltatásmegtagadás és jogosultságszint-emelés minden megbízhatósági határon – hatékony módszernek bizonyult a tervezési hibák korai észlelésére. Az alábbi táblázat felsorolja a STRIDE-fenyegetéseket, és példákat ad az Azure által biztosított funkciókat használó kockázatcsökkentésekre. Ezek a kockázatcsökkentések nem minden helyzetben működnek.

A támadási felület csökkentése

A támadási felület a potenciális biztonsági rések előfordulásának teljes összege. Ebben a tanulmányban egy alkalmazás támadási felületére összpontosítunk. A fókusz az alkalmazások támadással szembeni védelmén van. A támadási felület minimalizálásának egyszerű és gyors módja, ha eltávolítja a nem használt erőforrásokat és kódot az alkalmazásból. Minél kisebb az alkalmazás, annál kisebb a támadási felület. Távolítsa el például a következőt:

• Kód a még nem kiadott funkciókhoz.
• Hibakeresési támogatási kód.
• A nem használt vagy elavult hálózati adapterek és protokollok.
• A nem használt virtuális gépek és egyéb erőforrások.

Az erőforrások rendszeres tisztítása és a nem használt kód eltávolítása nagyszerű módszer annak biztosítására, hogy kevesebb lehetőség legyen a rosszindulatú szereplők támadására.

A támadási felület csökkentésének részletesebb és részletesebb módja a támadási felület elemzése. A támadási felület elemzése segít feltérképezni a rendszer azon részeit, amelyeket felül kell vizsgálni, és tesztelni kell a biztonsági réseket.

A támadási felület elemzése az alkalmazás kockázati területeinek megértése, hogy a fejlesztők és a biztonsági szakemberek tisztában legyenek azzal, hogy az alkalmazás mely részei nyitottak a támadásra. Ezután megtalálhatja a lehetőségek minimalizálásának módjait, nyomon követheti, hogy mikor és hogyan változik a támadási felület, és hogy ez mit jelent kockázat szempontjából.

A támadási felület elemzése segít a következők azonosításában:

• A biztonsági rések ellenőrzéséhez és teszteléséhez szükséges funkciók és a rendszer részei.
• A kód nagy kockázatú területei, amelyek mélységi védelmet igényelnek (a rendszer azon részei, amelyeket védenie kell).
• Ha módosítja a támadási felületet, és frissítenie kell egy fenyegetésértékelést.

A támadók számára a potenciális gyenge pont vagy sebezhetőség kihasználásának lehetőségének csökkentése megköveteli az alkalmazás általános támadási felületének alapos elemzését. Ebbe beletartozik a rendszerszolgáltatásokhoz való hozzáférés letiltása vagy korlátozása, a minimális jogosultság elve alkalmazása, valamint a rétegzett védelem alkalmazása, ahol csak lehetséges.

Az SDL ellenőrzési szakaszában megvitatjuk a támadási felület felülvizsgálatát .

Identitáskezelési szabályzat elfogadása elsődleges biztonsági szegélyként

Felhőalkalmazások tervezésekor fontos, hogy a biztonsági peremhálózati fókuszt a hálózatközpontú megközelítéstől az identitásközpontú megközelítésig bővítse. Korábban az elsődleges helyszíni biztonsági szegély egy szervezet hálózata volt. A legtöbb helyszíni biztonsági terv elsődleges biztonsági kimutatásként a hálózatot használja. A felhőalkalmazások esetében jobb, ha az identitást tekinti elsődleges biztonsági szegélynek.

A webalkalmazások fejlesztéséhez használható, identitásközpontú megközelítés kialakítása:

• Többtényezős hitelesítés kényszerítése a felhasználók számára.
• Használjon erős hitelesítési és engedélyezési platformokat.
• Alkalmazza a minimális jogosultság elvét.
• Igény szerint történő hozzáférés megvalósítása.

Többtényezős hitelesítés kényszerítése a felhasználók számára

Használjon kéttényezős hitelesítést. A kéttényezős hitelesítés a hitelesítés és az engedélyezés jelenlegi szabványa, mivel elkerüli a felhasználónév és a jelszó típusú hitelesítéssel járó biztonsági hiányosságokat. Az Azure felügyeleti felületeihez (Azure Portal/távoli PowerShell) és az ügyféloldali szolgáltatásokhoz való hozzáférést úgy kell megtervezni és konfigurálni, hogy a Microsoft Entra többtényezős hitelesítést használjon.

Erős hitelesítési és engedélyezési platformok használata

Egyéni kód helyett használjon platformalapú hitelesítési és engedélyezési mechanizmusokat. Ennek az az oka, hogy az egyéni hitelesítési kód fejlesztése hajlamos lehet a hibára. A kereskedelmi kódot (például a Microsofttól) gyakran széles körben áttekintik a biztonság szempontjából. A Microsoft Entra ID (Microsoft Entra ID) az identitás- és hozzáférés-kezelés Azure-megoldása. Ezek a Microsoft Entra-eszközök és -szolgáltatások segítenek a biztonságos fejlesztésben:

• Microsoft Identitásplatform olyan összetevők készlete, amelyekkel a fejlesztők biztonságosan bejelentkező alkalmazásokat hozhatnak létre. A platform olyan fejlesztőknek nyújt segítséget, akik egybérlős, üzletági (LOB) alkalmazásokat és több-bérlős alkalmazásokat fejlesztenek. Az alapszintű bejelentkezés mellett a Microsoft Identitásplatform használatával létrehozott alkalmazások meghívhatják a Microsoft API-kat és az egyéni API-kat. A Microsoft Identitásplatform olyan iparági szabványoknak megfelelő protokollokat támogat, mint az OAuth 2.0 és az OpenID Connect.

• Az Azure Active Directory B2C (Azure AD B2C) egy identitáskezelési szolgáltatás, a segítségével testre szabhatja és szabályozhatja az ügyfelek regisztrációját, bejelentkezését és a profiljaik kezelését az alkalmazások használatakor. Ide tartoznak többek között az iOS, Android és .NET rendszerhez fejlesztett alkalmazások is. Az Azure AD B2C lehetővé teszi ezeket a műveleteket az ügyfélidentitások védelme mellett.

A minimális jogosultság elvének alkalmazása

A minimális jogosultság fogalma azt jelenti, hogy a felhasználóknak pontosan meg kell adniuk a hozzáférést és a vezérlést a munkájuk elvégzéséhez, és semmi mást.

A szoftverfejlesztőnek tartományi rendszergazdai jogosultságra van szüksége? A rendszergazdai asszisztensnek hozzá kell férnie a személyes számítógépe felügyeleti vezérlőihez? A szoftverhez való hozzáférés kiértékelése nem különbözik. Ha az Azure szerepköralapú hozzáférés-vezérlést (Azure RBAC) használva különböző képességeket és jogosultságokat biztosít a felhasználóknak az alkalmazásban, akkor nem adna mindenkinek hozzáférést mindenhez. Az egyes szerepkörökhöz szükséges hozzáférés korlátozásával korlátozhatja a biztonsági problémák előfordulásának kockázatát.

Győződjön meg arról, hogy az alkalmazás a hozzáférési minták során a legkisebb jogosultságot érvényesíti.

Igény szerint történő hozzáférés megvalósítása

Valós idejű (JIT) hozzáférés implementálása a jogosultságok expozíciós idejének további csökkentése érdekében. A Microsoft Entra Privileged Identity Management használatával:

• Adja meg a felhasználóknak azokat az engedélyeket, amelyekre csak JIT-re van szükségük.
• Rövidített időtartamú szerepköröket rendelhet hozzá úgy, hogy a jogosultságok automatikusan vissza lesznek vonva.

Fontos tranzakciók újbóli hitelesítésének megkövetelése

A helyek közötti hamisítás (más néven XSRF vagy CSRF) egy olyan támadás a webalkalmazások ellen, amelyekben egy rosszindulatú webalkalmazás befolyásolja az ügyfélböngésző és a böngészőben megbízható webalkalmazások közötti interakciót. A helyek közötti hamisítási támadások azért lehetségesek, mert a webböngészők minden kéréssel automatikusan küldenek bizonyos hitelesítési jogkivonatokat egy webhelyre. Ezt a hasznosítási formát egykattintásos támadásnak vagy munkamenet-lovaglásnak is nevezik, mivel a támadás kihasználja a felhasználó korábban hitelesített munkamenetét.

Az ilyen típusú támadások elleni védelem legjobb módja, ha olyasmit kér a felhasználótól, amit csak a felhasználó tud megadni minden fontos tranzakció előtt, például vásárlás, fiók inaktiválása vagy jelszómódosítás előtt. Megkérheti a felhasználót, hogy adja meg újra a jelszavát, töltse ki a captcha-t, vagy küldjön be egy titkos jogkivonatot, amely csak a felhasználóé. A leggyakoribb megközelítés a titkos jogkivonat.

Kulcskezelési megoldás használata kulcsok, hitelesítő adatok és egyéb titkos kódok védelméhez

A kulcsok és a hitelesítő adatok elvesztése gyakori probléma. Az egyetlen rosszabb dolog, mint a kulcsok és hitelesítő adatok elvesztése, ha jogosulatlan fél hozzáférést szerez hozzájuk. A támadók kihasználhatják az automatizált és manuális technikákat a kódtárakban, például a GitHubon tárolt kulcsok és titkos kulcsok megtalálásához. Ne helyezzen kulcsokat és titkos kulcsokat ezekben a nyilvános kódtárakban vagy más kiszolgálókon.

Kulcsokat, tanúsítványokat, titkos kulcsokat és kapcsolati sztring mindig egy kulcskezelési megoldásban helyezze el. Olyan központosított megoldást használhat, amelyben a kulcsok és titkos kulcsok hardveres biztonsági modulokban (HSM-ek) vannak tárolva. Az Azure egy HSM-et biztosít a felhőben az Azure Key Vaulttal.

A Key Vault egy titkos tár: egy központosított felhőszolgáltatás az alkalmazás titkos kulcsainak tárolására. A Key Vault úgy tartja biztonságossá a bizalmas adatokat, hogy az alkalmazás titkos kulcsait egyetlen központi helyen tartja, és biztonságos hozzáférést, engedély-vezérlést és hozzáférés-naplózást biztosít.

A titkos kulcsok tárolása egyedi tárolókban történik. Minden tároló saját konfigurációs és biztonsági szabályzatokkal rendelkezik a hozzáférés szabályozásához. Az adatok egy REST API-val vagy egy ügyféloldali SDK-val érhetők el, amely a legtöbb programozási nyelvhez elérhető.

A bizalmas adatok védelme

Az adatok védelme alapvető része a biztonsági stratégiának. Az adatok besorolása és az adatvédelmi igények azonosítása segít az alkalmazás tervezésében az adatbiztonság szem előtt tartásával. A tárolt adatok bizalmassági és üzleti hatás szerinti besorolása (kategorizálása) segít a fejlesztőknek az adatokhoz kapcsolódó kockázatok meghatározásában.

Az adatformátumok tervezésekor az összes alkalmazható adatot bizalmasként kell megjelölni. Győződjön meg arról, hogy az alkalmazás bizalmasként kezeli a vonatkozó adatokat. Az alábbi eljárások segíthetnek a bizalmas adatok védelmében:

• Használjon titkosítást.
• Kerülje a kódolt titkos kulcsokat, például a kulcsokat és jelszavakat.
• Győződjön meg arról, hogy a hozzáférés-vezérlés és a naplózás érvényben van.

Titkosítás használata

Az adatok védelmének alapvető részét kell képeznie a biztonsági stratégiának. Ha az adatok egy adatbázisban vannak tárolva, vagy ha a helyek között oda-vissza mozognak, használja a inaktív adatok titkosítását (az adatbázisban) és az átvitt adatok titkosítását (a felhasználó, az adatbázis, az API vagy a szolgáltatásvégpont felé vezető úton). Javasoljuk, hogy mindig SSL/TLS protokollokat használjon az adatok cseréjéhez. Győződjön meg arról, hogy a TLS legújabb verzióját használja a titkosításhoz (jelenleg ez az 1.2-es verzió).

Kerülje a kemény kódolást

Bizonyos dolgokat soha nem szabad keményen kódolva a szoftverben. Ilyenek például a gazdagépnevek vagy IP-címek, URL-címek, e-mail-címek, felhasználónevek, jelszavak, tárfiókkulcsok és egyéb titkosítási kulcsok. Érdemes lehet olyan követelményeket megvalósítani, amelyeket a kódban nem lehet vagy nem lehet szigorúan kódolni, beleértve a kód megjegyzés szakaszait is.

Amikor megjegyzéseket fűz a kódhoz, győződjön meg arról, hogy nem ment bizalmas információkat. Ide tartoznak az e-mail-címei, jelszavai, kapcsolati sztring, az alkalmazással kapcsolatos olyan információk, amelyeket csak a szervezet egyik tagja ismerne, és minden más, amely előnyt jelenthet a támadó számára az alkalmazás vagy a szervezet megtámadása során.

Tegyük fel, hogy a fejlesztési projekt minden része nyilvános tudás, amikor üzembe helyezték. Kerülje a bizalmas adatok belevésését a projektbe.

Korábban az Azure Key Vaultról volt szó. A Key Vault használatával titkos kulcsokat, például kulcsokat és jelszavakat tárolhat ahelyett, hogy keményen kódolja őket. Ha a Key Vaultot az Azure-erőforrások felügyelt identitásaival kombinálva használja, az Azure-webalkalmazás egyszerűen és biztonságosan férhet hozzá a titkos konfigurációs értékekhez anélkül, hogy titkos kulcsokat tárol a forrásvezérlőben vagy a konfigurációban. További információ: Titkos kódok kezelése a kiszolgálóalkalmazásokban az Azure Key Vaulttal.

Feladatbiztos mértékek implementálása

Az alkalmazásnak képesnek kell lennie a végrehajtás során felmerülő hibák konzisztens kezelésére. Az alkalmazásnak minden hibát el kell kapnia, és biztonságosan vagy bezárva kell lennie.

Gondoskodnia kell arról is, hogy a hibák naplózása megfelelő felhasználói környezettel történjen a gyanús vagy rosszindulatú tevékenységek azonosításához. A naplókat elegendő ideig meg kell őrizni, hogy lehetővé tegye a késleltetett törvényszéki elemzést. A naplóknak olyan formátumban kell lenniük, amelyet egy naplókezelési megoldás könnyen felhasználhat. Győződjön meg arról, hogy a biztonsági hibákra vonatkozó riasztások aktiválódnak. Az elégtelen naplózás és monitorozás lehetővé teszi a támadók számára, hogy tovább támadják a rendszereket, és fenntartsák a megőrzést.

A hiba- és kivételkezelés előnyeinek kihasználása

A helyes hiba- és kivételkezelés megvalósítása a védelmi kódolás fontos része. A hiba- és kivételkezelés kritikus fontosságú a rendszer megbízhatóvá és biztonságossá tételéhez. A hibakezelési hibák különböző biztonsági résekhez vezethetnek, például információk kiszivárogtatásához a támadók számára, és segítenek a támadóknak jobban megismerni a platformot és a kialakítást.

Győződjön meg a következőkről:

• A kivételeket központosított módon kezeli, hogy elkerülje a kód ismétlődő próbálkozási/fogási blokkját .

• Minden váratlan viselkedést az alkalmazáson belül kezelünk.

• A felhasználók számára megjelenített üzenetek nem szivárognak ki kritikus fontosságú adatokból, de elegendő információt nyújtanak a probléma magyarázatához.

• A kivételek naplózva vannak, és elegendő információt biztosítanak a kriminalisztikai vagy incidenskezelési csapatok számára a kivizsgáláshoz.

Az Azure Logic Apps első osztályú felületet biztosít a függő rendszerek által okozott hibák és kivételek kezeléséhez. A Logic Apps használatával munkafolyamatokat hozhat létre olyan feladatok és folyamatok automatizálására, amelyek alkalmazásokat, adatokat, rendszereket és szolgáltatásokat integrálnak a vállalatok és szervezetek között.

Naplózás és riasztás használata

Biztonsági problémák naplózása biztonsági vizsgálatokhoz és riasztások aktiválása a problémákról, hogy a felhasználók időben értesülhessenek a problémákról. Az összes összetevő naplózásának és naplózásának engedélyezése. A naplóknak rögzítenie kell a felhasználói környezetet, és azonosítaniuk kell az összes fontos eseményt.

Ellenőrizze, hogy nem naplózza-e a felhasználó által a webhelyre beküldött bizalmas adatokat. A bizalmas adatok például a következők:

• Felhasználói hitelesítő adatok
• Társadalombiztosítási számok vagy egyéb azonosító adatok
• Hitelkártyaszámok vagy egyéb pénzügyi információk
• Állapotinformációk
• Titkos kulcsok vagy más adatok, amelyek titkosított információk visszafejtésére használhatók
• Az alkalmazás hatékonyabb támadásához használható rendszer- vagy alkalmazásinformációk

Győződjön meg arról, hogy az alkalmazás figyeli a felhasználókezelési eseményeket, például a sikeres és sikertelen felhasználói bejelentkezéseket, a jelszó-visszaállításokat, a jelszómódosításokat, a fiókzárolást és a felhasználói regisztrációt. Az események naplózása segít észlelni és reagálni a gyanús viselkedésre. Emellett operatív adatok gyűjtését is lehetővé teszi, például azt, hogy ki fér hozzá az alkalmazáshoz.

Következő lépések

Az alábbi cikkekben olyan biztonsági vezérlőket és tevékenységeket ajánlunk, amelyek segíthetnek a biztonságos alkalmazások fejlesztésében és üzembe helyezésében.

• Biztonságos alkalmazások fejlesztése
• Biztonságos alkalmazások üzembe helyezése