Az Azure-környezet védelme
Most, hogy megismerte a környezetek szabályozásának és az üzembehelyezési folyamatok biztonságossá tételének módját, érdemes lehet letiltani az emberi hozzáférést az ellenőrzött környezetekhez. Ebben a leckében megtudhatja, hogyan strukturálhatja a felhasználók Azure-környezetekhez való engedélyeit. Beleértve azt is, hogyan engedélyezheti a hozzáférést vészhelyzetekben, és hogyan naplózhatja az Azure-tulajdonban bekövetkező változásokat.
Emberi hozzáférés letiltása
Az ellenőrzött környezetekhez való emberi hozzáférés letiltásával gondoskodhat arról, hogy a véletlen vagy rosszindulatú módosítások ne kerüljék meg a csapat felülvizsgálati és automatizált üzembehelyezési folyamatait. Ha nem tiltja le az emberi hozzáférést, valaki véletlenül megkerülheti azokat a vezérlőket, amelyeket oly sok időt töltött az adattár és a folyamatok tervezésével és implementálásával.
A vezérlők blokkolása nélkül az is egyszerű, hogy valaki véletlenül eltörjön valamit. Tegyük fel például, hogy egy felhasználó két példányban nyitotta meg az Azure Portalt. Az egyik egy tesztkörnyezethez, a másik az éles környezethez tartozik. Amikor a felhasználó oda-vissza vált a böngészőlapok között, egyszerűen módosíthatja véletlenül egy tesztkörnyezethez szánt éles környezetet.
Az emberi hozzáférés letiltásához használhatja az Azure szerepköralapú hozzáférés-vezérlését (RBAC). Az RBAC-ben szerepkör-hozzárendeléseket hoz létre a következő definiálásához:
- Mely felhasználók, csoportok vagy szolgáltatásnevek férhetnek hozzá az Azure-erőforrások meghatározott készletéhez (a hatókörhöz).
- Mit tehetnek ezek a felhasználók, csoportok vagy szolgáltatásnevek az erőforrások (a szerepkör) elérésekor.
Az Azure RBAC számos beépített szerepkörtípust biztosít, többek között a következőket:
- Olvasó, amely írásvédett hozzáféréssel rendelkezik a környezethez.
- Közreműködő, amely módosíthatja az erőforrásokat.
- Tulajdonos, amely módosíthatja az erőforrásokat, és hozzáférést biztosíthat másoknak.
Fontos, hogy a hozzáférést megfelelő hatókörben biztosítsuk. Ha szervezete követi a dedikált Azure-előfizetések minden környezethez való használatát, fontolja meg az Azure felügyeleti csoportok használatát a szerepkör-hozzárendelések hatókörének egyszerűsítése érdekében. Ha a szervezet egyetlen Azure-előfizetést használ az összes környezethez, ne adjon hozzáférést az embereknek a teljes előfizetéshez, mert az összes erőforrás, beleértve az ön által felügyelt környezeteket is, örökölné ezt az engedélyt.
Tipp.
A szerepkör-hozzárendelések Az Azure Resource Manager (ARM) erőforrásai. Ez azt jelenti, hogy az Azure RBAC-szerepkör-hozzárendeléseket kódban, például a Bicep használatával konfigurálhatja.
Amikor megtervezi a szerepkör-hozzárendeléseket, el kell döntenie, hogy mi értelme van a szervezetnek. Tegyük fel például, hogy a szervezet külön előfizetéseket hoz létre az egyes környezetekhez. Dönthet úgy, hogy hozzáférést ad a rendszergazdáknak és a fejlesztőknek olvasói hozzáféréssel az ellenőrzött környezetekhez. Ezzel a szerepkörrel hozzáférhetnek az éles környezethez az Azure Portalon, hogy áttekinthessék az erőforrások konfigurációját, megtekinthessék a metrikákat és naplókat, és anélkül vizsgálhatják meg a problémákat vagy hibákat, hogy módosítanák a környezetet.
Az alábbiakban bemutatjuk, hogyan konfigurálhatja a szerepkör-hozzárendeléseket a játékvállalat környezeteihez az Azure-rendszergazdák és a kódokat és szkripteket író fejlesztők számára:
| Környezet neve | Vezérlési szint | Rendszergazda istrator engedély | Fejlesztői engedély |
|---|---|---|---|
| Development | Ellenőrzött | Reader | Reader |
| Test | Ellenőrzött | Reader | Reader |
| Staging | Ellenőrzött | Reader | Reader |
| Termelés | Ellenőrzött | Reader | Reader |
| Bemutató | Ellenőrizetlen | Owner | Contributor |
| Teljesítménytesztelés | Ellenőrizetlen | Tulajdonos | None |
| Behatolás tesztelése | Ellenőrizetlen | Tulajdonos | None |
| PR-vélemények | Ellenőrizetlen | Tulajdonos | Tulajdonos |
| Fejlesztői tesztkörnyezetek | Ellenőrizetlen | Tulajdonos | Tulajdonos |
A szerepkör-hozzárendelések tervezésekor győződjön meg arról, hogy alaposan teszteli őket. Előfordulhat, hogy a felügyeleti műveletekhez nem egyértelmű engedélyekre van szükség. Adjon lehetőséget a csapattagok számára, hogy mindennapos munkájukat teszteljék a használni kívánt engedélyekkel. Tekintse át a tapasztalt problémákat.
Rendszeresen naplózhatja a szerepkör-hozzárendeléseket. Győződjön meg arról, hogy nem adott véletlenül hozzáférést a rossz személyekhez, vagy nem adott túl széles hozzáférést.
Adatsík-hozzáférés
Az Azure-ban kétféle művelet létezik:
- A síkműveletek vezérlése az előfizetés erőforrásainak kezeléséhez.
- Adatsík-műveletek az erőforrás által elérhető funkciók eléréséhez.
Például egy vezérlősík-művelettel hozhat létre tárfiókot. Egy adatsík-művelettel csatlakozhat a tárfiókhoz, és hozzáférhet a benne lévő adatokhoz.
Ha letiltja az Azure-erőforrásokhoz való közvetlen felhasználói hozzáférést, vegye figyelembe, hogy ez a korlátozás hogyan vonatkozik az adatsík-műveletekre. Az üzembe helyezési folyamat például egy tárfiók kulcsát egy olyan helyen tárolhatja, amelyhez a rendszergazda hozzáférhet. Ez a rendszergazda a kulcs használatával megkerülheti a vezérlőket, és közvetlenül hozzáférhet a tárfiók adatsíkjához.
Egyre több Azure-erőforrás támogatja az adatsík hozzáférés-vezérlésének konfigurálását a Microsoft Entra ID használatával. Ez a támogatás csökkenti a kulcsok kiszivárgásának vagy az adatsík véletlen hozzáférésének valószínűségét. Ajánlott a Microsoft Entra ID-t használni az adatsík-hozzáféréshez, ahol csak lehet.
Vészhozzáférés
Előfordul, hogy vészhelyzetek lépnek fel, és valakinek gyorsan hozzá kell férnie egy éles környezethez a probléma kivizsgálásához vagy megoldásához. Fontos, hogy megtervezze és kipróbálja, hogyan szeretne reagálni ezekre a vészhelyzetekre jóval azelőtt, hogy azok bekövetkeznének. Nem kell firkálnia, hogy reagáljon a kimaradás kellős közepén.
Ennek egyik megközelítése egy üvegtöréses fiók, amely egy speciális felhasználói fiók, amely magasabb szintű engedélyekkel rendelkezik, mint a felhasználók általában. Azért nevezik üvegtörési fióknak, mert valami szokatlant igényel a hitelesítő adataihoz való hozzáféréshez, hasonlóan a tűzjelző panel üvegének feltöréséhez. Biztonságos módot biztosíthat az operátoroknak, hogy hozzáférjenek a break-glass fiók hitelesítő adataihoz. Ezek az operátorok ezután bejelentkezhetnek fiókként a vészhelyzeti módosítások végrehajtásához.
A break-glass fiók használatának lépései a következőek:
- A felhasználó a normál fiókjával próbál vészhelyzeti módosítást végrehajtani, de a művelet le van tiltva, mert a normál felhasználói fiók nem rendelkezik elegendő engedéllyel.
- A felhasználó hozzáfér a break-glass fiók hitelesítő adataihoz, és bejelentkezik a felhasználóként.
- A felhasználó (üvegtörési fiókként) végrehajthatja a műveletet.
Az üvegtöréses fiókok használata magas szintű fegyelmet igényel. Használatukat valós vészhelyzetekre kell fenntartani. Gondosan kezelje és védje hitelesítő adatait, mert a fiók kiemelt jogosultságokkal rendelkezik. Célszerű gyakran módosítani az üvegtöréses fiókok hitelesítő adatait, hogy a lehető legkisebb legyen az esélye annak, hogy illetéktelenek legyenek.
A break-glass fiókokat gyakran osztják meg egy csapaton belül, így nehéz nyomon követni, hogy ki és mit tettek ezek a felhasználók. Az üvegtöréses fiókok alternatív módszere a Microsoft Entra Privileged Identity Management (PIM) funkció bevezetése. Lehetővé teszi, hogy a felhasználó saját fiókja átmenetileg magasabb szintű engedélyt kapjon.
A PIM használatához szükséges lépések sorrendje a következő:
A felhasználó a normál fiókjával próbál vészhelyzeti módosítást végrehajtani, de a művelet le van tiltva, mert a normál felhasználói fiók nem rendelkezik megfelelő engedélyekkel.
A felhasználó kapcsolatba lép a PIM-sel, és ideiglenes jogosultságszint-emelést kér.
A PIM elvégezheti a felhasználó személyazonosságának további ellenőrzését, vagy jóváhagyást kérhet valakitől attól függően, hogy hogyan van konfigurálva a szervezet számára.
Ha a kérés engedélyezve van, a PIM ideiglenesen frissíti a felhasználó engedélyeit.
A felhasználó végrehajthatja a műveletet.
A megadott időszak leteltét követően a PIM visszavonja a felhasználónak adott emelt szintű engedélyeket.
A PIM és az Azure is átfogó naplózási naplókat ír, amelyek segítenek megérteni, hogy ki és miért kért emelt szintű engedélyeket. A naplók azt is nyomon követik, hogy mit tettek a környezetében az engedélyek megadásakor.
Megjegyzés:
A PIM prémium szintű licencet igényel a Microsoft Entra ID-hoz.
A vészhelyzet vége után
A vészhelyzet befejeződése után fontos, hogy a folyamat visszatérjen a normál műveletekhez. Ezt a folyamatot a túl sok idő eltelte előtt kell követnie, vagy megkockáztathatja, hogy elfelejti a fontos információkat, vagy nem biztonságos állapotban hagyja a konfigurációkat.
Gondosan tekintse át az Azure és a PIM naplózási naplóit, hogy megértse az ellenőrzött környezetekben, különösen az éles környezetben végrehajtott módosításokat.
Fontos
Ha valaki PIM-et vagy üvegtörési fiókot használ, lehetősége lehet arra, hogy a szokásos felhasználói fiókjához szélesebb körű hozzáférést biztosítson, mint amennyi kellett volna. Az ideiglenes engedélyeket arra is használhatják, hogy hozzáférjenek azokhoz az adatsíkkulcsokhoz, amelyeket az engedélyek visszavonása után is használhatnak.
Gondosan ellenőrizze az üvegtörési fiókok vagy a PIM összes használatát. Vonja vissza vagy forgassa el a vészhelyzet során esetleg közzétett kulcsokat.
A vészhelyzet után röviddel újraszinkronizálja az infrastruktúra kódként használt eszközeit a vészhelyzet során végrehajtott módosításokkal. Tegyük fel például, hogy egy sürgős probléma megoldásának részeként a rendszergazda manuálisan növelte egy Azure-alkalmazás szolgáltatáscsomag termékváltozatát. Frissítse az üzembehelyezési sablonokat, hogy az új termékváltozatot is belefoglalja az erőforrás-konfigurációba. Ellenkező esetben előfordulhat, hogy a folyamat következő rendszeres üzembe helyezése során az SKU alaphelyzetbe áll az előző értékre, és újabb kimaradást okoz.
Az Azure-környezet változásainak naplózása
Emellett érdemes konfigurálni a naplózást és a naplózást a teljes Azure-környezetben, és figyelni bizonyos eseményeket vagy fenyegetéseket.
Érdemes lehet biztonsági információkat és eseménykezelési (SIEM) eszközöket használni, például a Microsoft Sentinelt. Ezzel az eszközzel naplókat gyűjthet és elemezhet az Azure-tulajdonából, sőt még az Azure DevOpsból, a GitHubról és más rendszerekből is. A Sentinel használatával figyelheti az Azure-erőforrások váratlan vagy jogosulatlan módosításait. Importálhatja a folyamat naplóit és riasztásokat is aktiválhat események bekövetkezésekor, például amikor egy rendszergazda módosít egy fiókvédelmi szabályzatot az adattárban.