Az Azure-ban kritikus fontosságú számítási feladatok biztonsági szempontjai

A biztonság az egyik alapvető tervezési alapelv, és egyben kulcsfontosságú tervezési terület, amelyet első osztályú problémaként kell kezelni a kritikus fontosságú architektúrafolyamaton belül.

Tekintettel arra, hogy a kritikus fontosságú tervezés elsődleges célja a megbízhatóság maximalizálása, hogy az alkalmazás továbbra is teljesíthető és elérhető maradjon, az ezen a tervezési területen alkalmazott biztonsági szempontok és javaslatok a fenyegetések enyhítésére összpontosítanak a rendelkezésre állást befolyásoló és az általános megbízhatóságot akadályozó kapacitással. A sikeres szolgáltatásmegtagadási (DDoS-) támadások például ismertek, hogy katasztrofális hatással vannak a rendelkezésre állásra és a teljesítményre. Az, hogy egy alkalmazás hogyan csökkenti ezeket a támadási vektorokat, például a SlowLoris hatással lesz a teljes megbízhatóságra. Ezért az alkalmazást teljes mértékben védeni kell azokkal a fenyegetésekkel szemben, amelyek közvetlenül vagy közvetve veszélyeztetik az alkalmazások megbízhatóságát, hogy valóban kritikus fontosságúak legyenek.

Azt is fontos megjegyezni, hogy gyakran jelentős kompromisszumok társulnak a megerősített biztonsági helyzethez, különösen a teljesítmény, a működési rugalmasság és bizonyos esetekben a megbízhatóság tekintetében. Ha például beágyazott hálózati virtuális berendezéseket (NVA) vesz fel a következő generációs tűzfal (NGFW) képességeihez, például a mély csomagvizsgálathoz, jelentős teljesítménybírságot, további üzemeltetési összetettséget és megbízhatósági kockázatot jelent, ha a méretezhetőség és a helyreállítási műveletek nem összhangban vannak az alkalmazáséval. Ezért alapvető fontosságú, hogy a fő fenyegetésvektorok mérséklésére szolgáló további biztonsági összetevők és eljárások is az alkalmazás megbízhatósági célját támogassák, ami az ebben a szakaszban ismertetett javaslatok és szempontok kulcsfontosságú részét képezi majd.

Fontos

Ez a cikk az Azure Well-Architected kritikus fontosságú számítási feladatok sorozatának része. Ha nem ismeri ezt a sorozatot, javasoljuk, hogy kezdje a kritikus fontosságú számítási feladatokkal ?

Kritikus fontosságú nyílt forráskód projekt

A referencia-implementációk a GitHubon elérhető nyílt forráskód projekt részét képezik. A kódegységek egy Teljes felügyelet modellt vezetnek be a biztonsági tervezési és megvalósítási megközelítés strukturálásához és irányításához.

Igazítás a Teljes felügyelet modellel

A Microsoft Teljes felügyelet modell proaktív és integrált megközelítést biztosít a biztonság alkalmazásához az alkalmazás minden rétegében. A Teljes felügyelet vezérelvei arra törekszenek, hogy minden tranzakciót explicit módon és folyamatosan ellenőrizzenek, a legkisebb jogosultságot érvényesítik, intelligenciát és fejlett észlelést használva közel valós időben reagáljanak a fenyegetésekre. Végső soron az alkalmazás peremhálózatán belüli és kívüli bizalom megszüntetésére összpontosít, és ellenőrzi, hogy bármi megpróbál-e csatlakozni a rendszerhez.

Kialakítási szempontok

Az alkalmazás biztonsági helyzetének felmérése során kezdje ezekkel a kérdésekkel az egyes szempontok alapján.

• Folyamatos biztonsági tesztelés a legfontosabb biztonsági rések kockázatcsökkentéseinek ellenőrzéséhez.

  • A biztonsági tesztelés automatizált CI/CD-folyamatok részeként történik?
  • Ha nem, milyen gyakran végeznek konkrét biztonsági tesztelést?
  • A teszteredményeket egy kívánt biztonsági helyzet és fenyegetésmodell alapján mérik?

• Biztonsági szint az összes alacsonyabb környezetben.

  • A fejlesztési életciklus minden környezete ugyanolyan biztonsági helyzettel rendelkezik, mint az éles környezet?

• Hitelesítés és engedélyezés folytonossága hiba esetén.

  • Ha a hitelesítési vagy engedélyezési szolgáltatások átmenetileg nem érhetők el, az alkalmazás továbbra is működni fog?

• Automatizált biztonsági megfelelőség és szervizelés.

  • Észlelhetők a kulcsbiztonsági beállítások módosításai?
  • Automatikusan elhárítják a nem megfelelő módosításokat?

• Titkos kódok vizsgálata a kód véglegesítése előtt a titkos kódok forráskódtárakon keresztüli kiszivárgásának megakadályozása érdekében.

  • Lehetséges-e a szolgáltatások hitelesítése hitelesítő adatok nélkül a kód részeként?

• A szoftverellátási lánc védelme.

  • Nyomon követhetők a gyakori biztonsági rések és kitettségek (CVE-k) a használt csomagfüggőségeken belül?
  • Van automatizált folyamat a csomagfüggőségek frissítésére?

• Az adatvédelmi kulcs életciklusa.

  • Használhatóak szolgáltatás által felügyelt kulcsok az adatintegritási védelemhez?
  • Ha ügyfél által felügyelt kulcsra van szükség, hogyan működik a kulcs biztonságos és megbízható életciklusa?

• A CI/CD-eszközök használatához a Microsoft Entra szolgáltatásneveknek elegendő előfizetési szintű hozzáféréssel kell rendelkezniük ahhoz, hogy megkönnyítsék az Azure-erőforrások üzembe helyezésének vezérlési síkhoz való hozzáférését az összes figyelembe vett környezeti előfizetéshez.

  • Ha az alkalmazáserőforrások privát hálózatokon belül vannak zárolva, van-e privát adatsík kapcsolati útvonala, hogy a CI/CD-eszközök alkalmazásszintű üzembe helyezéseket és karbantartást hajtsanak végre.
    • Ez további összetettséget vezet be, és a szükséges privát buildügynökökön keresztül megköveteli az üzembe helyezési folyamaton belüli sorrendet.

Tervezési javaslatok

• Az Azure Policy használatával kényszerítheti ki a biztonsági és megbízhatósági konfigurációkat az összes szolgáltatásra vonatkozóan, biztosítva, hogy a vezérlősík konfigurációs időben elhárítsa vagy tiltsa az eltéréseket, segítve a "rosszindulatú rendszergazdai" forgatókönyvekkel kapcsolatos fenyegetések enyhítését.

• Az éles előfizetéseken belül a Microsoft Entra Privileged Identity Management (PIM) használatával visszavonhatja az éles környezetekhez való tartós vezérlési síkhoz való hozzáférést. Ez jelentősen csökkenti a "rosszindulatú rendszergazdai" forgatókönyvekből eredő kockázatokat további "ellenőrzések és egyenlegek" révén.

• Az Azure Managed Identityes használata minden olyan szolgáltatáshoz, amely támogatja a képességet, mivel megkönnyíti a hitelesítő adatok eltávolítását az alkalmazáskódból, és megszünteti az identitáskezelés működési terheit a szolgáltatás és a szolgáltatás közötti kommunikáció számára.

• Használja a Microsoft Entra szerepköralapú hozzáférés-vezérlést (RBAC) az adatsíkok engedélyezéséhez a képességet támogató összes szolgáltatással.

• Az alkalmazáskódon belül használjon belső Microsoft Identitásplatform hitelesítési kódtárakat a Microsoft Entra ID-val való integrációhoz.

• Fontolja meg a biztonságos jogkivonat-gyorsítótárazást, hogy csökkentett, de elérhető felhasználói élményt biztosíthasson, ha a választott identitásplatform nem érhető el, vagy csak részben érhető el az alkalmazásengedélyezéshez.

  • Ha a szolgáltató nem tud új hozzáférési jogkivonatokat kiadni, de továbbra is érvényesíti a meglévőket, az alkalmazás és a függő szolgáltatások probléma nélkül működhetnek, amíg a jogkivonatuk le nem jár.
  • A jogkivonatok gyorsítótárazását általában automatikusan kezelik a hitelesítési kódtárak (például az MSAL).

• Az infrastruktúra mint kód (IaC) és az automatizált CI/CD-folyamatok használatával a frissítéseket az összes alkalmazásösszetevőre irányíthatja, beleértve a meghibásodási körülményeket is.

  • Győződjön meg arról, hogy a CI/CD-eszközök szolgáltatáskapcsolatai kritikus fontosságú bizalmas információkként vannak védve, és nem lehetnek közvetlenül elérhetők egyetlen szolgáltatáscsapat számára sem.
  • Alkalmazzon részletes RBAC-t az éles CD-folyamatokra a "rosszindulatú rendszergazdai" kockázatok csökkentése érdekében.
  • Fontolja meg a manuális jóváhagyási kapuk használatát az éles üzembehelyezési folyamatokon belül a "rosszindulatú rendszergazdai" kockázatok további mérséklése és az összes éles változásra vonatkozó további műszaki biztosíték biztosítása érdekében.
    • A további biztonsági kapuk az agilitás szempontjából kompromisszumra kerülhetnek, és gondosan kell értékelni, figyelembe véve, hogy az agilitás hogyan tartható fenn még manuális kapukkal is.

• Adjon meg egy megfelelő biztonsági helyzetet az összes alacsonyabb környezethez a kulcsfontosságú biztonsági rések csökkentése érdekében.

  • Ne alkalmazza ugyanazt a biztonsági helyzetet, mint a gyártás, különösen az adatkiszivárgás tekintetében, kivéve, ha a jogszabályi követelmények előírják ennek szükségességét, mivel ez jelentősen rontja a fejlesztői rugalmasságot.

• Engedélyezze a Felhőhöz készült Microsoft Defender (korábbi nevén Azure Security Center) minden olyan előfizetéshez, amely egy kritikus fontosságú számítási feladat erőforrásait tartalmazza.

  • A megfelelőség kikényszerítéséhez használja az Azure Policyt.
  • Engedélyezze az Azure Defendert minden olyan szolgáltatáshoz, amely támogatja a képességet.

• Használja a DevSecOpsot , és implementálja a biztonsági tesztelést a CI/CD-folyamatokon belül.

  • A teszteredményeket egy megfelelő biztonsági helyzet alapján kell mérni a kiadás jóváhagyásának tájékoztatása érdekében, legyen az automatizált vagy manuális.
  • Alkalmazza a biztonsági tesztelést a CD éles folyamat részeként minden kiadáshoz.
    • Ha minden kiadás biztonsági tesztelése veszélyezteti a működési rugalmasságot, győződjön meg arról, hogy megfelelő biztonsági tesztelési ütemet alkalmaz.

• Titkos kódok és függőségek vizsgálatának engedélyezése a forráskódtárban.

Fenyegetésmodellezés

A veszélyforrások modellezése kockázatalapú megközelítést biztosít a biztonsági tervezéshez, és azonosítja a lehetséges fenyegetéseket a megfelelő biztonsági kockázatcsökkentések kialakításához. Számos lehetséges fenyegetés létezik, amelyek előfordulási valószínűsége eltérő, és a fenyegetések sok esetben váratlan, kiszámíthatatlan, sőt kaotikus módon láncolódhatnak. Ez az összetettség és bizonytalanság miatt a hagyományos technológiai követelményeken alapuló biztonsági megközelítések nagyrészt nem megfelelőek a kritikus fontosságú felhőalkalmazásokhoz. A kritikus fontosságú alkalmazások fenyegetésmodellezésének folyamata várhatóan összetett és nélkülözhetetlen lesz.

A kihívások közötti navigáláshoz rétegzett védelmi megközelítést kell alkalmazni a modellezett fenyegetések kompenzáló kockázatcsökkentéseinek meghatározására és implementálására, figyelembe véve a következő védelmi rétegeket.

1. Az Azure-platform alapvető biztonsági képességekkel és vezérlőkkel.
2. Az alkalmazás architektúrája és biztonsági kialakítása.
3. Az Azure-erőforrások védelmére beépített, engedélyezett és üzembe helyezhető biztonsági funkciók.
4. Alkalmazáskód és biztonsági logika.
5. Üzemeltetési folyamatok és DevSecOps.

Feljegyzés

Az Azure-beli célzónán belüli üzembe helyezéskor vegye figyelembe, hogy a célzóna-implementáció egy további fenyegetéscsökkentési réteget biztosít a központi biztonsági képességek kiépítésén keresztül.

Kialakítási szempontok

A STRIDE egy egyszerű kockázati keretrendszert biztosít a biztonsági fenyegetések kiértékeléséhez a főbb fenyegetésvektorok között.

• Hamis identitás: Személyek megszemélyesítése hatalommal. Például egy támadó megszemélyesít egy másik felhasználót a saját -
  • Identitás
  • Hitelesítés
• Illetéktelen bemenet: Az alkalmazásnak küldött bemenet módosítása, vagy az alkalmazás kódjának módosításához szükséges megbízhatósági határok megsértése. Egy támadó például sql-injektálást használ az adatbázistáblák adatainak törléséhez.
  • Adatintegritás
  • Érvényesítés
  • Tiltólista/engedélyezés
• A művelet elutasítása: A már végrehajtott műveletek cáfolásának képessége, valamint az alkalmazás képessége arra, hogy bizonyítékokat gyűjtsön, és az elszámoltathatóságot ösztönözze. Például a kritikus adatok törlése anélkül, hogy rosszindulatú rendszergazdai nyomkövetésre képes.
  • Naplózás/naplózás
  • Aláírás
• Információfeltárás: Hozzáférés a korlátozott információkhoz. Ilyen például egy korlátozott fájlhoz hozzáférő támadó.
  • Titkosítás
  • Adatkiszivárgás
  • Középen belüli támadások
• Szolgáltatásmegtagadás: Rosszindulatú alkalmazáskimaradás a felhasználói élmény romlása érdekében. Például egy DDoS-botnetes támadás, például Slowloris.
  • DDoS
  • Botnetek
  • CDN- és WAF-képességek
• Jogosultságszint emelése: Jogosultsági szintű alkalmazáshozzáférés elérése az engedélyezési kihasználtságon keresztül. Egy támadó például módosít egy URL-sztringet, hogy hozzáférjen a bizalmas információkhoz.
  • Távoli kódvégrehajtás
  • Engedélyezés
  • Elkülönítés

Tervezési javaslatok

• A lehetséges új fenyegetések kiértékeléséhez és a kockázatcsökkentések implementálásához rendelje hozzá a tervezési költségvetést az egyes futamokon belül.

• Tudatos erőfeszítéseket kell tenni annak érdekében, hogy a biztonsági kockázatcsökkentések rögzítve legyenek egy közös mérnöki kritériumokon belül, hogy az összes alkalmazásszolgáltatás-csapat konzisztenciáját ösztönözze.

• Kezdje egy szolgáltatással a szolgáltatásszintű fenyegetésmodellezéssel, és egyesítse a modellt a szálmodell alkalmazásszintű összesítésével.

Hálózati behatolás elleni védelem

A kritikus fontosságú alkalmazásokhoz és az azokhoz kapcsolódó adatokhoz való jogosulatlan hozzáférés megakadályozása elengedhetetlen a rendelkezésre állás fenntartásához és az adatintegritás védelméhez.

Kialakítási szempontok

• Teljes felügyelet egy sérült állapotot feltételez, és ellenőrzi az egyes kéréseket, mintha egy ellenőrizetlen hálózatból származna.

  • A fejlett nulla megbízhatóságú hálózati implementáció mikroszegmentálást és elosztott bejövő/kimenő mikroszegmenseket alkalmaz.

• Az Azure PaaS-szolgáltatások általában nyilvános végpontokon keresztül érhetők el. Az Azure lehetővé teszi a nyilvános végpontok biztonságossá tételét, vagy akár teljesen privátsá tételét.

  • Az Azure Private Link/Private Endpoints dedikált hozzáférést biztosít egy Azure PaaS-erőforráshoz privát IP-címek és privát hálózati kapcsolat használatával.
  • A virtuális hálózati szolgáltatásvégpontok szolgáltatásszintű hozzáférést biztosítanak a kijelölt alhálózatokról a kiválasztott PaaS-szolgáltatásokhoz.
  • A Virtual Network Injection dedikált privát üzembe helyezéseket biztosít a támogatott szolgáltatásokhoz, például az App Service-hez egy App Service-környezeten keresztül.
    • A felügyeleti sík forgalma továbbra is nyilvános IP-címeken halad át.

• A támogatott szolgáltatások esetében az Azure Private Link az Azure Private Endpoints használatával kezeli a szolgáltatásvégpontokhoz társított adatkiszivárgási kockázatokat, például egy rosszindulatú rendszergazda, aki adatokat ír egy külső erőforrásba.

• Ha privát végpontok vagy szolgáltatásvégpontok használatával korlátozza az Azure PaaS-szolgáltatásokhoz való hálózati hozzáférést, az üzembe helyezési folyamatokhoz biztonságos hálózati csatornára lesz szükség az Azure-erőforrások Azure-vezérlősíkjának és adatsíkjának eléréséhez az alkalmazás üzembe helyezése és kezelése érdekében.

  • Magánhálózatra telepített saját üzemeltetésű buildügynökök , mivel az Azure-erőforrás proxyként használható CI/CD-függvények privát kapcsolaton keresztüli végrehajtásához. A buildügynökökhöz külön virtuális hálózatot kell használni.
    • A privát buildügynökökhöz ci/CD-eszközökről való csatlakozás szükséges.
  • Egy másik módszer az erőforrás tűzfalszabályainak módosítása menet közben a folyamaton belül, hogy engedélyezve legyen a kapcsolat egy Azure DevOps-ügynök nyilvános IP-címéről, és a tűzfal a feladat befejezése után el lett távolítva.
    • Ez a megközelítés azonban csak az Azure-szolgáltatások egy részhalmazára alkalmazható. Ez például privát AKS-fürtök esetében nem kivitelezhető.
  • A fejlesztői és felügyeleti feladatok az alkalmazásszolgáltatás ugrómezőiben való végrehajtásához használhatók.

• Az adminisztrációs és karbantartási feladatok elvégzése egy további forgatókönyv, amely az Azure-erőforrások adatsíkjával való kapcsolatot igényli.

• A megfelelő Microsoft Entra-szolgáltatásnévvel rendelkező szolgáltatáskapcsolatok az Azure DevOpsban használhatók az RBAC Microsoft Entra-azonosítón keresztüli alkalmazásához.

• A szolgáltatáscímkék a hálózati biztonsági csoportokra alkalmazhatók az Azure PaaS-szolgáltatásokkal való kapcsolat megkönnyítése érdekében.

• Az alkalmazásbiztonsági csoportok nem terjednek ki több virtuális hálózatra.

• Az Azure Network Watcher csomagrögzítésének időtartama legfeljebb öt óra lehet.

Tervezési javaslatok

• Korlátozza a nyilvános hálózati hozzáférést a külső támadási felület csökkentése érdekében az alkalmazás üzleti céljának teljesítéséhez szükséges abszolút minimálisra.

  • Az Azure Private Link használatával privát végpontokat hozhat létre olyan Azure-erőforrásokhoz, amelyek biztonságos hálózati integrációt igényelnek.
  • Üzemeltetett privát buildügynökök használata CI/CD-eszközökhöz az Azure Private Link által védett Azure-erőforrások üzembe helyezéséhez és konfigurálásához.
    • A Microsoft által üzemeltetett ügynökök nem tudnak közvetlenül csatlakozni a hálózatba integrált erőforrásokhoz.

• A privát buildügynökök kezelésekor soha ne nyisson rdp- vagy SSH-portot közvetlenül az internetre.

  • Az Azure Bastion használatával biztonságos hozzáférést biztosíthat az Azure-beli virtuális gépekhez, és felügyeleti feladatokat végezhet az Azure PaaS-en az interneten keresztül.

• Az alkalmazáson belüli összes nyilvános IP-cím biztonságossá tételéhez használjon szabványos DDoS-védelmi tervet.

• Az Azure Front Door webalkalmazási tűzfalszabályzatokkal való használatával biztosíthatja és védheti a több Azure-régióra kiterjedő globális HTTP/S-alkalmazásokat.

  • A fejlécazonosító-ellenőrzéssel zárolhatja a nyilvános alkalmazásvégpontokat, így csak az Azure Front Door-példányból származó forgalmat fogadják el.

• Ha további helyszíni hálózati biztonsági követelmények, például mélycsomag-vizsgálat vagy TLS-vizsgálat, az Azure Firewall Premium vagy a Hálózati virtuális berendezés (NVA) használatát írja elő, győződjön meg arról, hogy a maximális magas rendelkezésre állás és redundancia érdekében van konfigurálva.

• Ha a csomagrögzítési követelmények léteznek, használja a Network Watcher-csomagokat a korlátozott rögzítési idő ellenére történő rögzítéshez.

• Használja a hálózati biztonsági csoportokat és az alkalmazásbiztonsági csoportokat az alkalmazásforgalom mikroszegmentálására.

  • Ne használjon biztonsági berendezést az alkalmazáson belüli forgalom szűréséhez.
  • Fontolja meg az Azure Policy használatát adott NSG-szabályok kikényszerítéséhez, amelyek mindig az alkalmazás alhálózataihoz vannak társítva.

• Engedélyezze az NSG-folyamatnaplókat, és adja őket a Traffic Analyticsbe, hogy betekintést nyerjen a belső és külső forgalmi folyamatokba.

• Az Azure PaaS-szolgáltatásokhoz való hozzáférés biztonságossá tételéhez használja az Azure Private Link/Private Endpoints szolgáltatást, ahol elérhető. A Private Linket támogató Azure-szolgáltatásokról további információt az Azure Private Link rendelkezésre állásával kapcsolatban talál.

• Ha a privát végpont nem érhető el, és elfogadhatók az adatkiszivárgási kockázatok, a virtuális hálózati szolgáltatásvégpontok használatával biztonságossá teheti az Azure PaaS-szolgáltatásokhoz való hozzáférést egy virtuális hálózaton belülről.

  • Ne engedélyezze alapértelmezés szerint a virtuális hálózati szolgáltatásvégpontokat az összes alhálózaton, mivel ez jelentős adatkiszivárgási csatornákat fog bevezetni.

• Hibrid alkalmazások esetén a helyszíni Azure PaaS-szolgáltatásokat az ExpressRoute-on keresztül, privát társviszony-létesítéssel érheti el.

Feljegyzés

Az Azure-beli célzónán belüli üzembe helyezéskor vegye figyelembe, hogy a helyszíni adatközpontokhoz való hálózati kapcsolatot a célzóna implementációja biztosítja. Az egyik módszer a privát társviszony-létesítéssel konfigurált ExpressRoute használata.

Adatintegritási védelem

A titkosítás létfontosságú lépés az adatintegritás biztosítása felé, és végső soron az egyik legfontosabb biztonsági képesség, amely a fenyegetések széles skáláját mérsékelheti. Ez a szakasz ezért a titkosítással és a kulcskezeléssel kapcsolatos legfontosabb szempontokat és javaslatokat nyújt az adatok védelme érdekében az alkalmazások megbízhatóságának veszélyeztetése nélkül.

Kialakítási szempontok

• Az Azure Key Vault tranzakciós korlátokkal rendelkezik a kulcsokra és titkos kódokra vonatkozóan, és a szabályozást tárolónként egy adott időszakon belül alkalmazzák.

• Az Azure Key Vault biztonsági határt biztosít, mivel a kulcsok, titkos kódok és tanúsítványok hozzáférési engedélyei tárolószinten vannak alkalmazva.

  • A Key Vault hozzáférési szabályzat-hozzárendelései külön engedélyeket biztosítanak a kulcsokhoz, titkos kulcsokhoz vagy tanúsítványokhoz.
    • Mostantól részletes objektumszintű engedélyek érhetők el egy adott kulcshoz, titkos kódhoz vagy tanúsítványhoz.

• A szerepkör-hozzárendelés módosítása után a szerepkör alkalmazása akár 10 perc (600 másodperc) késést is okozhat.

  • Előfizetésenként legfeljebb 2000 Azure-szerepkör-hozzárendelés engedélyezett.

• Az Azure Key Vault mögöttes hardverbiztonsági moduljai (HSM-ek) FIPS 140-et érvényesítenek.

  • Dedikált Azure Key Vault által felügyelt HSM érhető el a FIPS 140–2 3. szintű megfelelőséget igénylő forgatókönyvekhez.

• Az Azure Key Vault magas rendelkezésre állást és redundanciát biztosít a rendelkezésre állás fenntartásához és az adatvesztés megelőzéséhez.

• A régió feladatátvétele során a Key Vault szolgáltatás feladatátvétele eltarthat néhány percig.

  • A feladatátvétel során a Key Vault írásvédett módban lesz, így nem módosíthatók a kulcstartó tulajdonságai, például a tűzfal konfigurációi és beállításai.

• Ha privát kapcsolattal csatlakozik az Azure Key Vaulthoz, akár 20 percet is igénybe vehet, amíg a kapcsolat újra létrejön egy regionális feladatátvétel során.

• A biztonsági mentés pillanatképet készít egy titkos kulcsról, kulcsról vagy tanúsítványról, titkosított blobként, amelyet nem lehet visszafejteni az Azure-on kívül. A blob használható adatainak lekéréséhez vissza kell állítani egy Key Vaultba ugyanabban az Azure-előfizetésben és azure-földrajzi helyen.

  • A titkos kódok a biztonsági mentés során megújulhatnak, ami nem egyezik.

• A szolgáltatás által felügyelt kulcsokkal az Azure kulcskezelési funkciókat, például rotációt hajt végre, ezáltal csökkentve az alkalmazásműveletek hatókörét.

• A szabályozási vezérlők előírhatják az ügyfél által felügyelt kulcsok használatát a szolgáltatástitkosítási funkciókhoz.

• Amikor a forgalom az Azure-adatközpontok között mozog, a RENDSZER MACsec adatkapcsolati réteg titkosítást használ a mögöttes hálózati hardveren a nem a Microsoft vagy a Microsoft nevében felügyelt fizikai határokon kívül az átvitel közbeni adatok védelméhez.

Tervezési javaslatok

• Lehetőség szerint szolgáltatás által felügyelt kulcsokat használjon az adatvédelemhez, így nem kell kezelnie a titkosítási kulcsokat, és kezelnie kell az olyan üzemeltetési feladatokat, mint a kulcsváltás.

  • Csak akkor használjon ügyfél által felügyelt kulcsokat, ha erre egyértelmű jogszabályi követelmény vonatkozik.

• Ha további titkosítási mechanizmusokat vagy ügyfél által felügyelt kulcsokat szeretne figyelembe venni, az Azure Key Vaultot biztonságos adattárként használhatja az összes titkos kulcs, tanúsítvány és kulcs számára.

  • Az Azure Key Vault kiépítése olyan helyreállítható törlési és törlési szabályzatokkal, amelyek lehetővé teszik a törölt objektumok megőrzési védelmét.
  • HSM-alapú Azure Key Vault termékváltozat használata alkalmazás-éles környezetekhez.

• Helyezzen üzembe egy külön Azure Key Vault-példányt az egyes regionális üzembehelyezési bélyegeken belül, amely a honosítással biztosítja a hibaelkülönítést és a teljesítmény előnyeit, valamint az egyetlen Key Vault-példány által előírt méretezési korlátokat.

  • Használjon dedikált Azure Key Vault-példányt az alkalmazás globális erőforrásaihoz.

• A minimális jogosultsági modellt követve korlátozza a titkos kulcsok, kulcsok és tanúsítványok végleges törlését a speciális egyéni Microsoft Entra-szerepkörökre.

• Győződjön meg arról, hogy a titkosítási kulcsok és a Key Vaultban tárolt tanúsítványok biztonsági másolatai offline példányt biztosítanak abban a valószínűtlen eseményben, amikor a Key Vault elérhetetlenné válik.

• A Key Vault-tanúsítványok használatával kezelheti a tanúsítványok beszerzését és aláírását.

• Automatikus folyamat létrehozása kulcs- és tanúsítványforgatáshoz.

  • Automatizálja a tanúsítványkezelési és -megújítási folyamatot a nyilvános hitelesítésszolgáltatókkal az adminisztráció megkönnyítése érdekében.
    • Riasztások és értesítések beállítása az automatikus tanúsítványmegújítások kiegészítéséhez.

• A kulcs, a tanúsítvány és a titkos kód használatának figyelése.

  • Riasztások definiálása váratlan használathoz az Azure Monitoron belül.

Szabályzatalapú irányítás

A biztonsági konvenciók végső soron csak akkor hatékonyak, ha következetesen és holisztikusan érvényesítik az összes alkalmazásszolgáltatást és csapatot. Az Azure Policy keretrendszert biztosít a biztonsági és megbízhatósági alapkonfigurációk kikényszerítéséhez, biztosítva a kritikus fontosságú alkalmazások általános mérnöki feltételeinek való folyamatos megfelelést. Pontosabban az Azure Policy az Azure Resource Manager (ARM) vezérlősíkjának kulcsfontosságú részét képezi, kiegészítve az RBAC-t azzal, hogy korlátozza az engedélyezett felhasználók által végrehajtható műveleteket, és felhasználható a létfontosságú biztonsági és megbízhatósági konvenciók érvényesítésére a használt platformszolgáltatásokban.

Ez a szakasz ezért az Azure Policy-alapú szabályozás kritikus fontosságú alkalmazásokhoz való használatával kapcsolatos legfontosabb szempontokat és javaslatokat ismerteti, biztosítva a biztonsági és megbízhatósági konvenciók folyamatos betartatását.

Kialakítási szempontok

• Az Azure Policy olyan mechanizmust biztosít, amely a megfelelőséget olyan biztonsági és megbízhatósági konvenciók kikényszerítésével segíti elő, mint a privát végpontok használata vagy a rendelkezésre állási zónák használata.

Feljegyzés

Az Azure-beli célzónán belüli üzembe helyezéskor vegye figyelembe, hogy a központi alapkonfigurációs szabályzat-hozzárendelések érvényesítése valószínűleg a célzóna-felügyeleti csoportok és -előfizetések implementációjában lesz alkalmazva.

• Az Azure Policy az automatizált felügyeleti tevékenységek, például a kiépítés és a konfigurálás irányítására használható.

  • Erőforrás-szolgáltató regisztrációja.
  • Az egyes Azure-erőforráskonfigurációk ellenőrzése és jóváhagyása.

• Az Azure Policy-hozzárendelés hatóköre határozza meg a lefedettséget, és az Azure Policy-definíciók helye tájékoztatja az egyéni szabályzatok újrafelhasználhatóságát.

• Az Azure Policy számos korlátozást tartalmaz, például a definíciók számát bármely adott hatókörben.

• Az üzembe helyezési ha nem létezik (DINE) szabályzatok végrehajtása több percet is igénybe vehet.

• Az Azure Policy kritikus fontosságú bemenetet biztosít a megfelelőségi jelentésekhez és a biztonsági naplózáshoz.

Tervezési javaslatok

• Szabályozási és megfelelőségi követelmények leképezése az Azure Policy-definíciókra.

  • Ha például vannak adattárolási követelmények, akkor a rendelkezésre álló üzembehelyezési régiók korlátozására szabályzatot kell alkalmazni.

• Definiáljon egy általános mérnöki feltételeket, amelyek biztonságos és megbízható konfigurációs definíciókat rögzítenek az összes használt Azure-szolgáltatáshoz, biztosítva, hogy ez a feltétel megfeleltethető legyen az Azure Policy-hozzárendeléseknek a megfelelőség kikényszerítése érdekében.

  • Alkalmazzon például egy Azure-szabályzatot a rendelkezésre állási zónák minden releváns szolgáltatáshoz való használatának kikényszerítéséhez, biztosítva a régión belüli megbízható üzembehelyezési konfigurációkat.

A kritikus fontosságú referencia-implementáció biztonsági és megbízhatóság-központú szabályzatok széles skáláját tartalmazza, amelyek meghatároznak és érvényesítenek egy közös mérnöki kritériumokat.

• A szolgáltatáskonfiguráció eltérésének monitorozása a gyakori mérnöki feltételekhez képest az Azure Policy használatával.

Kritikus fontosságú forgatókönyvek esetén, ha több éles előfizetés van egy dedikált felügyeleti csoportban, rangsorolja a hozzárendeléseket a felügyeleti csoport hatókörében.

• Ha lehetséges, használjon beépített szabályzatokat az egyéni szabályzatdefiníciók fenntartásával kapcsolatos működési többletterhelés minimalizálásához.

• Ha egyéni szabályzatdefiníciókra van szükség, győződjön meg arról, hogy a definíciók a megfelelő felügyeleti csoport hatókörében vannak üzembe helyezve, hogy lehetővé tegyék a szabályzatok újrafelhasználását a teljes körű környezet-előfizetésekben, így a szabályzatok újra felhasználhatók az éles és az alacsonyabb környezetekben.

  • Ha az alkalmazás ütemtervét az Azure-ütemtervekhez igazítja, használja a rendelkezésre álló Microsoft-erőforrásokat annak vizsgálatára, hogy a kritikus egyéni definíciók beépíthetők-e beépített definíciókként.

Feljegyzés

Azure-beli kezdőzónán belüli üzembe helyezéskor érdemes lehet egyéni Azure Policy-definíciókat üzembe helyezni a köztes vállalati gyökérszintű felügyeleti csoport hatókörén belül, hogy a szélesebb Körű Azure-tulajdonban lévő összes alkalmazás újra felhasználható legyen. A kezdőzóna-környezetekben alapértelmezés szerint bizonyos központi biztonsági szabályzatok lesznek alkalmazva a magasabb felügyeleti csoportok hatókörén belül a teljes Azure-tulajdon biztonsági megfelelőségének kikényszerítése érdekében. Azure-szabályzatokat kell alkalmazni például a szoftverkonfigurációk virtuálisgép-bővítményeken keresztüli automatikus üzembe helyezésére, valamint a megfelelő alapszintű virtuálisgép-konfiguráció kikényszerítésére.

• Az Azure Policy használatával konzisztens címkézési sémát kényszeríthet ki az alkalmazáson belül.
  • Azonosítsa a szükséges Azure-címkéket, és használja a hozzáfűzési szabályzat módot a használat kényszerítéséhez.

Ha az alkalmazás előfizetett a Microsoft kritikus fontosságú támogatására, győződjön meg arról, hogy az alkalmazott címkézési séma értelmes környezetet biztosít a támogatási élmény mély alkalmazásértelmezéséhez.

• Exportálja a Microsoft Entra tevékenységnaplóit az alkalmazás által használt globális Log Analytics-munkaterületre.
  • Győződjön meg arról, hogy az Azure-tevékenységnaplók archiválva vannak a globális tárfiókban, valamint a hosszú távú megőrzéshez szükséges operatív adatok.

Egy Azure-beli célzónában a Microsoft Entra tevékenységnaplói is bekerülnek a központi platform Log Analytics-munkaterületére. Ebben az esetben ki kell értékelni, ha a Globális Log Analytics-munkaterületen továbbra is szükség van a Microsoft Entra-azonosítóra.

• A biztonsági információk és az eseménykezelés integrálása a Felhőhöz készült Microsoft Defender (korábbi nevén Azure Security Center) segítségével.

Az IaaS-specifikus szempontok a virtuális gépek használatakor

Azokban az esetekben, amikor az IaaS virtuális gépek használatára van szükség, figyelembe kell venni néhány jellemzőt.

Kialakítási szempontok

• A rendszer nem frissíti automatikusan a rendszerképeket az üzembe helyezés után.
• A frissítések nem települnek automatikusan a futó virtuális gépekre.
• A rendszerképeket és az egyes virtuális gépeket általában nem a dobozon kívül edzették meg.

Tervezési javaslatok

• Ne engedélyezze a nyilvános interneten keresztül a virtuális gépekhez való közvetlen hozzáférést az SSH- és RDP-protokollokhoz való hozzáférés biztosításával. Mindig használja az Azure Bastiont és a jumpboxokat korlátozott hozzáféréssel a felhasználók egy kis csoportjához.
• Korlátozza a közvetlen internetkapcsolatot a hálózati biztonsági csoportok, az (Azure) tűzfal vagy az Application Gateways (7. szint) használatával a kimenő forgalom szűréséhez és korlátozásához.
• Többrétegű alkalmazások esetén fontolja meg a különböző alhálózatok használatát, és a hálózati biztonsági csoportok használatával korlátozza a hozzáférést a kettő között.
• Lehetőség szerint rangsorolja a nyilvános kulcsú hitelesítés használatát. A titkos kulcsokat biztonságos helyen, például az Azure Key Vaultban tárolhatja.
• A virtuális gépek védelme hitelesítéssel és hozzáférés-vezérléssel.
• Alkalmazza ugyanazokat a biztonsági eljárásokat, mint a kritikus fontosságú alkalmazásforgatókönyvekben leírtakat.

Kövesse és alkalmazza a fent leírt, kritikus fontosságú alkalmazásforgatókönyvek biztonsági eljárásait, valamint az Azure-beli IaaS-számítási feladatok biztonsági ajánlott eljárásait.

Következő lépés

Tekintse át a kritikus fontosságú alkalmazási forgatókönyvek üzemeltetési eljárásainak ajánlott eljárásait.

Működési eljárások