Identitás- és hozzáférés-kezelési javaslatok

Az Azure Well-Architected Framework Security ellenőrzőlista-javaslatára vonatkozik:

SE:05	Szigorú, feltételes és naplózható identitás- és hozzáférés-kezelés (IAM) implementálása az összes számítási feladat felhasználója, csapattagja és rendszerösszetevője között. A hozzáférés korlátozása kizárólag a szükségesre. Használjon modern iparági szabványokat minden hitelesítési és engedélyezési implementációhoz. Az identitáson alapuló hozzáférés korlátozása és szigorú naplózása.

Ez az útmutató a számítási feladatok erőforrásaihoz hozzáférni próbáló identitások hitelesítésére és engedélyezésére vonatkozó javaslatokat ismerteti.

Műszaki ellenőrzés szempontjából az identitás mindig az elsődleges szegély. Ez a hatókör nem csak a számítási feladat széleit tartalmazza. Az egyes összetevőket is tartalmazza, amelyek a számítási feladaton belül találhatók. A tipikus identitások a következők:

• Emberek. Alkalmazásfelhasználók, rendszergazdák, operátorok, auditorok és rossz szereplők.

• Rendszerek. Számítási feladatok identitásai, felügyelt identitások, API-kulcsok, szolgáltatásnevek és Azure-erőforrások.

• Névtelen. Azok az entitások, akik nem szolgáltattak bizonyítékot arra vonatkozóan, hogy kik ők.

Definíciók 

Kifejezések	Definíció
Hitelesítés (AuthN)	Egy folyamat, amely ellenőrzi, hogy az identitás ki vagy mit mond.
Engedélyezés (AuthZ)	Egy folyamat, amely ellenőrzi, hogy egy identitás rendelkezik-e engedéllyel a kért művelet végrehajtásához.
Feltételes hozzáférés	Olyan szabálykészlet, amely lehetővé teszi a megadott feltételeken alapuló műveleteket.
IdP	Identitásszolgáltató, például Microsoft Entra azonosító.
Persona	Feladatfüggvény vagy olyan beosztás, amely felelősségek és műveletek készletével rendelkezik.
Előre megosztott kulcsok	A szolgáltató és a fogyasztó között megosztott, biztonságos és elfogadott mechanizmuson keresztül használt titkos kódtípus.
Erőforrás-identitás	A platform által felügyelt felhőerőforrásokhoz definiált identitás.
Szerepkör	Engedélyek készlete, amely meghatározza, hogy mit tehet egy felhasználó vagy csoport.
Hatókör	A szervezeti hierarchia különböző szintjei, ahol egy szerepkör működhet. A rendszer funkcióinak egy csoportja is.
Rendszerbiztonsági tag	Engedélyeket biztosító identitás. Lehet felhasználó, csoport vagy szolgáltatásnév. Minden csoporttag ugyanolyan szintű hozzáféréssel rendelkezik.
Felhasználói azonosító	Egy személy identitása, például egy alkalmazott vagy egy külső felhasználó.
Számítási feladat identitása	Egy olyan alkalmazás, szolgáltatás, szkript, tároló vagy más összetevő rendszeridentitása, amely más szolgáltatásokban és erőforrásokban való hitelesítésre szolgál.

Megjegyzés

Az identitások más, hasonló identitásokkal csoportosíthatók egy biztonsági tagnak nevezett szülő alatt. A biztonsági csoport egy példa egy rendszerbiztonsági tagra. Ez a hierarchikus kapcsolat leegyszerűsíti a karbantartást és javítja a konzisztenciát. Mivel az identitásattribútumok kezelése nem egyéni szinten történik, a hibák esélye is csökken. Ebben a cikkben az identitás kifejezés a biztonsági tagokra is kiterjed.

Identitásszolgáltató szerepe

Az identitásszolgáltató (IdP) egy felhőalapú szolgáltatás, amely digitális identitásként tárolja és kezeli a felhasználókat.

Használja ki a megbízható identitásszolgáltató által az identitás- és hozzáférés-kezeléshez nyújtott képességeket. Ne implementáljon egyéni rendszereket az identitásszolgáltató helyére. Az idP-rendszereket gyakran fejlesztik a legújabb támadási vektorok alapján azáltal, hogy naponta több milliárd jelet rögzítenek több bérlő között. Microsoft Entra azonosító az Azure-felhőplatform identitásszolgáltatója.

Hitelesítés

A hitelesítés egy olyan folyamat, amely ellenőrzi az identitásokat. A kérő identitásnak valamilyen ellenőrizhető azonosítási formát kell megadnia. Például:

• Felhasználónév és jelszó.

• Egy előre felosztott titkos kód, például egy API-kulcs, amely hozzáférést biztosít.

• Közös hozzáférésű jogosultságkód (SAS) jogkivonat.

• A TLS kölcsönös hitelesítésében használt tanúsítvány.

Az ellenőrzési folyamatot a lehető legnagyobb mértékben az identitásszolgáltatónak kell kezelnie.

Engedélyezés

Az engedélyezés olyan folyamat, amely engedélyezi vagy letiltja az ellenőrzött identitás által kért műveleteket. A művelet működési vagy erőforrás-kezeléssel kapcsolatos lehet.

Az engedélyezéshez engedélyeket kell hozzárendelnie az identitásokhoz, amelyeket az identitásszolgáltató által biztosított funkciókkal kell elvégeznie.

Fő tervezési stratégiák

Ha átfogó képet szeretne kapni a számítási feladatok identitásigényéről, katalogizálnia kell a folyamatokat, a számítási feladatok eszközeit és a személyeket, valamint azokat a műveleteket, amelyeket az eszközök és a személyek végrehajtanak. A stratégiának minden olyan használati esetre ki kell terjednie, amely kezeli a számítási feladatot vagy annak összetevőit (külső hozzáférés) elérő folyamatokat, valamint a számítási feladatból más forrásokba (külső hozzáférés) érkező folyamatokat.

Minden használati esetnek valószínűleg saját vezérlőkészlete lesz, amelyet a vélelmezett incidens szemlélettel kell megterveznie. A használati eset vagy a személyek identitáskövetelményei alapján azonosítsa a feltételes választási lehetőségeket. Ne használjon egyetlen megoldást az összes használati esethez. Ezzel szemben a vezérlőknek nem kell olyan részletesnek lenniük, hogy szükségtelen felügyeleti többletterhelést vezessenek be.

Naplóznia kell az identitáselérési útvonalat. Ezzel érvényesítheti a vezérlőket, és a naplókat használhatja a megfelelőségi auditokhoz.

A hitelesítéshez szükséges összes identitás meghatározása

• Külső hozzáférés. Az identitástervnek minden olyan felhasználót hitelesítenie kell, aki különböző célokból fér hozzá a számítási feladathoz. Például egy végfelhasználó, aki API-k meghívásával fér hozzá az alkalmazáshoz.

  Részletes szinten a számítási feladat összetevőinek kívülről is hozzáférésre lehet szükségük. Például egy operátornak, akinek hozzáférésre van szüksége a portálon keresztül, vagy hozzáférésre van szüksége a számításhoz a parancsok futtatásához.

  Mindkettő olyan felhasználói identitásokra mutat be példákat, amelyek eltérő személyiségekkel rendelkeznek.

• Belső hozzáférés. Az alkalmazásnak más erőforrásokhoz kell hozzáférnie. Például olvasás az adatplatformról vagy írás az adatplatformra, titkos kódok lekérése a titkos kódtárból, valamint telemetriai adatok naplózása a figyelési szolgáltatásokba. Előfordulhat, hogy külső szolgáltatásokhoz is hozzá kell férnie. Ezekhez a hozzáféréshez számítási feladat identitására van szükség, amely lehetővé teszi, hogy az alkalmazás hitelesítést végezzen a többi erőforrással.

  A koncepció az összetevő szintjén érvényes. Az alábbi példában előfordulhat, hogy a tárolónak hozzá kell férnie az üzembehelyezési folyamatokhoz a konfiguráció lekéréséhez. Ezekhez a hozzáféréshez erőforrás-identitásra van szükség.

Ezeket az identitásokat az identitásszolgáltatónak hitelesítenie kell.

Íme egy példa az identitások architektúrában való implementálására:

Engedélyezési műveletek meghatározása

Ezután tudnia kell, hogy az egyes hitelesített identitások mit próbálnak megtenni, hogy ezek a műveletek engedélyezhetők legyenek. A műveletek feloszthatók az általuk igényelt hozzáférés típusával:

• Adatsík-hozzáférés. Az adatsíkon végrehajtott műveletek adatátvitelt okoznak a külső vagy külső hozzáféréshez. Például egy alkalmazás adatokat olvas fel egy adatbázisból, és adatokat ír egy adatbázisba, titkos kódokat kér le, vagy naplókat ír egy figyelési fogadóba. Az összetevő szintjén a rendszer adatsík-műveleteknek tekinti azokat a számításokat, amelyek lemezképeket kérnek le vagy küldnek le egy beállításjegyzékbe vagy onnan.

• Vezérlősík-hozzáférés. A vezérlősíkon végrehajtott műveletek egy Azure-erőforrás létrehozását, módosítását vagy törlését okozzák. Például az erőforrás tulajdonságainak módosítása.

Az alkalmazások jellemzően adatsík-műveleteket céloznak meg, míg a műveletek gyakran a vezérlőkhöz és az adatsíkokhoz is hozzáférnek. Az engedélyezési igények azonosításához jegyezze fel az erőforráson végrehajtható műveleti műveleteket. Az egyes erőforrások engedélyezett műveleteiről további információt az Azure-erőforrás-szolgáltató műveletei című témakörben talál.

Szerepköralapú engedélyezés biztosítása

Az egyes identitások felelőssége alapján engedélyezze az engedélyezni kívánt műveleteket. Az identitások nem tehetnek többet a szükségesnél. Mielőtt engedélyezési szabályokat állít be, tisztában kell tennie azzal, hogy ki vagy mi kér kéréseket, milyen szerepkört engedélyez, és milyen mértékben teheti meg. Ezek a tényezők identitást, szerepkört és hatókört kombináló döntésekhez vezetnek.

Példaként tekintsünk egy számítási feladat identitására. Az alkalmazásnak adatsík-hozzáféréssel kell rendelkeznie az adatbázishoz, ezért engedélyezni kell az adaterőforrás olvasási és írási műveleteit. Az alkalmazásnak azonban vezérlősík-hozzáférésre van szüksége a titkos kódtárhoz? Ha a számítási feladat identitását egy rossz szereplő veszélyezteti, milyen hatással lenne a rendszerre a bizalmasság, az integritás és a rendelkezésre állás szempontjából?

Szerepkör-hozzárendelés

A szerepkör egy identitáshoz rendelt engedélyek készlete . Olyan szerepkörök hozzárendelése, amelyek csak az identitás számára teszik lehetővé a feladat elvégzését, és többé nem. Ha a felhasználó engedélyei a feladatkövetelményekre korlátozódnak, könnyebb azonosítani a gyanús vagy jogosulatlan viselkedést a rendszerben.

Tegye fel a következőhöz hasonló kérdéseket:

• Elég az írásvédett hozzáférés?
• Az identitásnak engedélyekre van szüksége az erőforrások törléséhez?

A felhasználók, alkalmazások vagy szolgáltatások Azure-erőforrásokhoz való hozzáférésének korlátozása csökkenti a lehetséges támadási felületet. Ha csak az adott feladatok végrehajtásához szükséges minimális engedélyeket adja meg, a sikeres támadás vagy jogosulatlan hozzáférés kockázata jelentősen csökken. A biztonsági csapatoknak például csak olvasási hozzáférésre van szükségük az összes technikai környezet biztonsági attribútumaihoz. Ez a szint elegendő a kockázati tényezők értékeléséhez, a lehetséges kockázatcsökkentések azonosításához és a kockázatokról való jelentéshez.

Vannak olyan forgatókönyvek, amelyekben a felhasználóknak több hozzáférésre van szükségük a szervezeti struktúra és a csoportszervezet miatt. Előfordulhat, hogy átfedés van a különböző szerepkörök között, vagy az egyes felhasználók több szabványos szerepkört is végrehajthatnak. Ebben az esetben használjon több szerepkör-hozzárendelést, amelyek az üzleti függvényen alapulnak, és ne hozzon létre egyéni szerepkört az egyes felhasználók számára. Ez megkönnyíti a szerepkörök kezelését.

Kerülje azokat az engedélyeket, amelyek kifejezetten az egyes erőforrásokra vagy felhasználókra hivatkoznak. A részletes és egyéni engedélyek bonyolultságot és zavart okoznak, mivel nem adják át a szándékot az új, hasonló erőforrásoknak. Ez összetett örökölt konfigurációt hozhat létre, amelyet nehéz karbantartani, és negatív hatással lehet a biztonságra és a megbízhatóságra is.

Kompromisszum: A részletes hozzáférés-vezérlési megközelítés jobb naplózást és a felhasználói tevékenységek monitorozását teszi lehetővé.

A szerepkörökhöz társított hatókör is tartozik. A szerepkör működhet az engedélyezett felügyeleti csoportban, előfizetésben, erőforráscsoportban vagy erőforrás-hatókörben, vagy egy másik egyéni hatókörben. Még ha az identitás korlátozott engedélykészlettel is rendelkezik, a hatókör kibővítése az identitás feladatfüggvényén kívül eső erőforrásokra is kockázatos. Az olvasási hozzáférés például az összes forráskódhoz és adathoz veszélyes lehet, és szabályozni kell.

Szerepköröket rendelhet az identitásokhoz szerepköralapú hozzáférés-vezérléssel (RBAC). Mindig használja az IdP által biztosított RBAC-t az olyan funkciók kihasználásához, amelyek lehetővé teszik a hozzáférés-vezérlés következetes alkalmazását és szigorú visszavonását.

Beépített szerepkörök használata. Úgy tervezték őket, hogy a legtöbb használati esetet lefedje. Az egyéni szerepkörök hatékonyak és néha hasznosak, de olyan forgatókönyvek esetén érdemes őket lefoglalni, amelyekben a beépített szerepkörök nem fognak működni. A testreszabás összetettséghez vezet, amely növeli a zavart, és összetettebbé, kihívást és törékenyebbé teszi az automatizálást. Ezek a tényezők mind negatívan befolyásolják a biztonságot.

Olyan szerepköröket adhat meg, amelyek a legkisebb jogosultsággal kezdődnek, és további üzemeltetési vagy adathozzáférési igényeket adnak hozzá. A műszaki csapatoknak egyértelmű útmutatással kell rendelkezniük az engedélyek implementálásához.

Ha részletes vezérlést szeretne az RBAC-n, adjon hozzá feltételeket a szerepkör-hozzárendeléshez a környezet, például műveletek és attribútumok alapján.

Feltételes hozzáférési lehetőségek kiválasztása

Ne adjon minden identitásnak ugyanolyan szintű hozzáférést. A döntéseket két fő tényező alapján hozhatja meg:

• Az idő. Mennyi ideig fér hozzá az identitás a környezethez.

• Jogosultság. Az engedélyek szintje.

Ezek a tényezők nem zárják ki egymást. A több jogosultsággal és korlátlan hozzáférési időtartammal rendelkező feltört identitások nagyobb ellenőrzést kaphatnak a rendszer és az adatok felett, vagy használhatják ezt a hozzáférést a környezet további módosításához. Korlátozza ezeket a hozzáférési tényezőket mind megelőző intézkedésként, mind pedig a robbanási sugár szabályozása érdekében.

• A Just in Time (JIT) megközelítések csak akkor biztosítják a szükséges jogosultságokat, ha szükség van rájuk.

• A Just Enough Access (JEA) csak a szükséges jogosultságokat biztosítja.

Bár az idő és a jogosultság az elsődleges tényező, vannak más feltételek is, amelyek érvényesek. Használhatja például azt az eszközt, hálózatot és helyet is, ahonnan a hozzáférés származik a szabályzatok beállításához.

Olyan erős vezérlőket használjon, amelyek szűrik, észlelik és letiltják a jogosulatlan hozzáférést, beleértve az olyan paramétereket, mint a felhasználói identitás és a hely, az eszköz állapota, a számítási feladatok környezete, az adatok besorolása és anomáliák.

Előfordulhat például, hogy a számítási feladathoz külső identitásoknak, például szállítóknak, partnereknek és ügyfeleknek kell hozzáférnie. A teljes munkaidős alkalmazottaknak megadott alapértelmezett engedélyek helyett a megfelelő szintű hozzáférésre van szükségük. A külső fiókok egyértelmű megkülönböztetése megkönnyíti az ilyen vektorokból származó támadások megelőzését és észlelését.

Az identitásszolgáltató választásának képesnek kell lennie arra, hogy megadja ezt a különbséget, olyan beépített funkciókat biztosítson, amelyek a legalacsonyabb jogosultság alapján biztosítanak engedélyeket, és beépített fenyegetésfelderítést biztosítanak. Ez magában foglalja a hozzáférési kérelmek és a bejelentkezések monitorozását. Az Azure IdP Microsoft Entra azonosító. További információkért tekintse meg a cikk Azure-beli facilitálási szakaszát .

Kritikus hatással rendelkező fiókok

A felügyeleti identitások a legnagyobb biztonsági kockázatokat is magukban hordozzák, mivel az általuk elvégzett feladatokhoz kiemelt hozzáférés szükséges ezen rendszerek és alkalmazások széles köréhez. A veszélyeztetés vagy a visszaélés káros hatással lehet az ön vállalkozására és információs rendszereire. Az adminisztráció biztonsága az egyik legkritikusabb biztonsági terület.

A kiemelt hozzáférés meghatározott támadókkal szembeni védelméhez teljes és átgondolt megközelítést kell alkalmaznia, hogy elkülönítse ezeket a rendszereket a kockázatoktól. Íme néhány stratégia:

• Minimalizálja a kritikus hatással rendelkező fiókok számát.

• A meglévő identitások jogosultságainak emelése helyett használjon külön szerepköröket.

• Az idP JIT-funkcióival elkerülheti a folyamatos vagy állandó hozzáférést. Törésüveg-helyzetek esetén kövesse a vészhelyzeti hozzáférési folyamatot.

• Használjon modern hozzáférési protokollokat , például jelszó nélküli hitelesítést vagy többtényezős hitelesítést. Külsősítse ezeket a mechanizmusokat az identitásszolgáltatóhoz.

• Kulcsbiztonsági attribútumok kényszerítése feltételes hozzáférési szabályzatok használatával.

• A nem használt felügyeleti fiókok leszerelése.

Használjon egyetlen identitást a környezetek között, és társítson egyetlen identitást a felhasználóhoz vagy az egyszerű felhasználóhoz. Az identitások felhőbeli és helyszíni környezetekben való konzisztenciája csökkenti az emberi hibákat és az ebből eredő biztonsági kockázatokat. Az erőforrásokat kezelő mindkét környezetben lévő csapatoknak egységes, mérvadó forrásra van szükségük a biztonsági garanciák teljesítéséhez. A központi identitásért felelős csapattal együttműködve győződjön meg arról, hogy a hibrid környezetekben lévő identitások szinkronizálva vannak.

Kockázat: Fennáll a magas jogosultsági szintű identitások szinkronizálásának kockázata. A támadók teljes körű ellenőrzést kaphatnak a helyszíni eszközök felett, ami egy felhőfiók sikeres feltöréséhez vezethet. Értékelje ki a szinkronizálási stratégiát a támadási felülethez hozzáadható fiókok szűrésével.

Folyamatok létrehozása az identitás életciklusának kezeléséhez

Az identitásokhoz való hozzáférés nem tarthat tovább, mint az identitások által elérhető erőforrások. Győződjön meg arról, hogy rendelkezik az identitások letiltására vagy törlésére szolgáló eljárással, ha a csapatszerkezet vagy a szoftverösszetevők megváltoznak.

Ez az útmutató a forrásvezérlésre, az adatokra, a vezérlősíkokra, a számítási feladatok felhasználóira, az infrastruktúrára, az eszközökre, az adatok, naplók, metrikák és egyéb entitások monitorozására vonatkozik.

Identitásszabályozási folyamat létrehozása a digitális identitások, a kiemelt jogosultságú felhasználók, a külső/vendégfelhasználók és a számítási feladatok felhasználóinak életciklusának kezeléséhez. Hozzáférési felülvizsgálatok implementálása annak biztosítása érdekében, hogy amikor az identitások kilépnek a szervezetből vagy a csapatból, a számítási feladatok engedélyeit eltávolítsa a rendszer.

A nemidentitáson alapuló titkos kódok védelme

Az alkalmazás titkos kulcsait, például az előmegosztott kulcsokat sebezhető pontoknak kell tekinteni a rendszerben. A kétirányú kommunikáció során, ha a szolgáltató vagy a fogyasztó biztonsága sérül, jelentős biztonsági kockázatokat lehet bevezetni. Ezek a kulcsok is nehézkesek lehetnek, mivel üzemeltetési folyamatokat vezetnek be.

Ha teheti, kerülje a titkos kódok használatát, és fontolja meg az identitásalapú hitelesítés használatát az alkalmazáshoz való felhasználói hozzáféréshez, nem csak az erőforrásaihoz.

Az alábbi lista az útmutatás összegzését tartalmazza. További információ: Javaslatok az alkalmazás titkos kódjaihoz.

• Ezeket a titkos kulcsokat olyan entitásokként kezelje, amelyek dinamikusan leküldhetők egy titkos tárból. Ezeket nem szabad az alkalmazáskódban, az IaC-szkriptekben, az üzembehelyezési folyamatokban vagy bármely más összetevőben szigorúan kódban megadni.

• Győződjön meg arról, hogy képes visszavonni a titkos kulcsokat.

• Olyan üzemeltetési eljárásokat alkalmazhat, amelyek olyan feladatokat kezelnek, mint a kulcsváltás és a lejárat.

A rotációs szabályzatokkal kapcsolatos információkért lásd: Titkos kulcsok rotálásának automatizálása két hitelesítési hitelesítő adatkészlettel rendelkező erőforrások esetében, valamint oktatóanyag: A tanúsítványok automatikus rotálási gyakoriságának frissítése Key Vault.

A fejlesztési környezetek biztonságának megőrzése

Minden kód- és szkriptrendszert, folyamatkezelő eszközt és forrásvezérlő rendszert számítási feladatok eszközeinek kell tekinteni. Az írásokhoz való hozzáférést automatizálással és társértékeléssel kell elérni. A forráskód olvasási hozzáférésének a szerepkörökre kell korlátozódnia, szükség szerint. A kódtáraknak verziószámozással kell rendelkezniük, és a társhálózatok által készített biztonsági kód-felülvizsgálatoknak a fejlesztési életciklussal integrált szokásos gyakorlatnak kell lenniük. Rendelkeznie kell egy olyan folyamattal, amely rendszeresen ellenőrzi az erőforrásokat , és azonosítja a legújabb biztonsági réseket.

Számítási feladatok identitásaival hozzáférést biztosíthat az üzembehelyezési környezetekből származó erőforrásokhoz, például a GitHubhoz.

Auditnapló karbantartása

Az identitáskezelés egyik aspektusa annak biztosítása, hogy a rendszer naplózható legyen. Az auditok ellenőrzik, hogy a szabálysértési stratégiák hatékonyak-e. Az auditnaplók karbantartása a következőkben segít:

• Ellenőrizze, hogy az identitás hitelesítése erős hitelesítéssel történik-e. Minden műveletnek nyomon követhetőnek kell lennie az elutasító támadások megelőzése érdekében.

• Észlelheti a gyenge vagy hiányzó hitelesítési protokollokat , és betekintést nyerhet a felhasználói és alkalmazásbejelentkésekbe, és betekintést nyerhet azokba.

• A biztonsági és megfelelőségi követelmények alapján értékelje ki az identitásokból a számítási feladathoz való hozzáférést, és vegye figyelembe a felhasználói fiókok kockázatát, az eszköz állapotát, valamint a beállított egyéb feltételeket és szabályzatokat.

• Nyomon követheti az előrehaladást vagy a megfelelőségi követelményektől való eltérést .

A legtöbb erőforrás rendelkezik adatsík-hozzáféréssel. Ismernie kell az erőforrásokhoz hozzáférő identitásokat és az általuk végrehajtott műveleteket. Ezeket az információkat biztonsági diagnosztikához használhatja.

További információ: Javaslatok a biztonsági monitorozásra és a fenyegetéselemzésre.

Azure-beli facilitálás

Javasoljuk, hogy mindig olyan modern hitelesítési protokollokat használjon, amelyek figyelembe veszik az összes rendelkezésre álló adatpontot, és feltételes hozzáférést használnak. Microsoft Entra azonosító identitás- és hozzáférés-kezelést biztosít az Azure-ban. Lefedi az Azure felügyeleti síkját, és integrálva van a legtöbb Azure-szolgáltatás adatsíkjaival. Microsoft Entra azonosító a számítási feladat előfizetéséhez társított bérlő. Nyomon követi és kezeli az identitásokat és azok engedélyezett engedélyeit, és leegyszerűsíti az általános felügyeletet a felügyelet vagy az emberi hibák kockázatának minimalizálása érdekében.

Ezek a képességek natív módon integrálhatók ugyanabba a Microsoft Entra identitás- és engedélymodellbe a felhasználói szegmensekben:

• Microsoft Entra azonosító. Alkalmazottak és vállalati erőforrások.

• Microsoft Entra Külső ID. Partnerek.

• Azure AD B2C. Ügyfelek.

• Microsoft Entra összevonási kompatibilitási lista. Külső összevonási megoldások.

Az egyéni alkalmazások hitelesítéséhez és engedélyezéséhez Microsoft Entra azonosítót használhatja a Microsoft Authentication Library (MSAL) vagy platformfunkciók, például a webalkalmazások hitelesítése révén. Lefedi az Azure felügyeleti síkját, az Azure-szolgáltatások többségének adatsíkjait és az alkalmazások integrációs képességeit.

Az Microsoft Entra id újdonságai című témakörben talál naprakész állapotot.

Kompromisszum: A Microsof Microsoft Entra ID egyetlen meghibásodási pont, mint bármely más alapszolgáltatás. Nincs áthidaló megoldás, amíg a Microsoft nem oldja meg a kimaradást. Az Microsoft Entra gazdag funkciókészlete azonban meghaladja az egyéni megoldások használatának kockázatát.

Az Azure támogatja az olyan nyílt protokollokat, mint az OAuth2 és az OpenID Connect. Javasoljuk, hogy ezeket a szabványos hitelesítési és engedélyezési mechanizmusokat használja ahelyett, hogy saját folyamatokat terveznél.

Azure RBAC-vel

Az Azure RBAC az Microsoft Entra azonosítóban lévő biztonsági tagokat jelöli. Minden szerepkör-hozzárendelés az Azure RBAC-en keresztül történik. Használja ki a beépített szerepköröket, amelyek a szükséges engedélyek többségét biztosítják. További információ: Microsoft Entra beépített szerepkörök.

Íme néhány használati eset:

• A felhasználók szerepkörökhöz való hozzárendelésével szabályozhatja az Azure-erőforrásokhoz való hozzáférést. További információ: A szerepköralapú hozzáférés-vezérlés áttekintése Microsoft Entra azonosítóban.

• A Privileged Identity Management használatával időalapú és jóváhagyásalapú szerepkör-aktiválást biztosíthat a nagy hatású identitásokhoz társított szerepkörökhöz. További információ: Mi az a Privileged Identity Management?.

További információ az RBAC-ről: Ajánlott eljárások az Azure RBAC-hez.

Az attribútumalapú vezérlőkkel kapcsolatos információkért lásd : Mi az az Azure ABAC?.

Számítási feladat identitása

Microsoft Entra azonosító képes kezelni az alkalmazás identitását. Az alkalmazáshoz társított szolgáltatásnév diktálhatja a hozzáférési hatókörét.

További információ: Mik azok a számítási feladatok identitásai?.

A szolgáltatásnév a felügyelt identitás használatakor is absztrakcióra kerül. Ennek az az előnye, hogy az Azure kezeli az alkalmazás összes hitelesítő adatait.

Nem minden szolgáltatás támogatja a felügyelt identitásokat. Ha nem tudja használni a felügyelt identitásokat, használhat szolgáltatásneveket. A szolgáltatásnevek használata azonban növeli a felügyeleti többletterhelést. További információ: Mik az Azure-erőforrások felügyelt identitásai?.

Erőforrás-identitás

A felügyelt identitások fogalma kiterjeszthető az Azure-erőforrásokra. Az Azure-erőforrások felügyelt identitásokkal hitelesíthetik magukat más, Microsoft Entra hitelesítést támogató szolgáltatásokban. További információ: Olyan Azure-szolgáltatások, amelyek felügyelt identitásokat használhatnak más szolgáltatások eléréséhez.

Feltételes hozzáférési szabályzatok

A feltételes hozzáférés a hozzáférési döntésre vonatkozó szabályzatot ismerteti . A feltételes hozzáférés használatához ismernie kell a használati esethez szükséges korlátozásokat. Konfigurálja Microsoft Entra feltételes hozzáférést úgy, hogy beállít egy hozzáférési szabályzatot a működési igényeinek megfelelően.

További információ: Feltételes hozzáférés: Felhasználók, csoportok és számítási feladatok identitásai.

Csoporthozzáférés-kezelés

Ahelyett, hogy engedélyeket ad egy adott felhasználónak, rendeljen hozzá hozzáférést Microsoft Entra azonosítójú csoportokhoz. Ha egy csoport nem létezik, az identitásért felelős csapattal együttműködve hozzon létre egyet. Ezután hozzáadhat és eltávolíthat csoporttagokat az Azure-on kívül, és meggyőződhet arról, hogy az engedélyek naprakészek. A csoportot más célokra is használhatja, például levelezőlistákra.

További információ: Hozzáférés-vezérlés biztonságossá tételének biztosítása csoportok használatával Microsoft Entra azonosítóban.

Fenyegetések észlelése

Microsoft Entra ID-védelem segíthet az identitásalapú kockázatok észlelésében, kivizsgálásában és elhárításában. További információ: Mi az Identity Protection?

A fenyegetésészlelés a gyanús tevékenységek riasztására való reagálás vagy a rendellenes események proaktív keresése a tevékenységnaplókban. A Microsoft Sentinel felhasználói és entitásviselkedési elemzései (UEBA) megkönnyítik a gyanús tevékenységek észlelését. További információ: Speciális fenyegetések azonosítása az UEBA használatával.

Hibrid rendszerek

Az Azure-ban ne szinkronizálja a fiókokat Microsoft Entra olyan azonosítóval, amely magas szintű jogosultságokkal rendelkezik a meglévő Active Directoryban. Ez a szinkronizálás le van tiltva az alapértelmezett Microsoft Entra Connect Sync konfigurációban, ezért csak azt kell ellenőriznie, hogy nem szabta-e testre ezt a konfigurációt.

Az Microsoft Entra-azonosítóban történő szűréssel kapcsolatos információkért lásd: Microsoft Entra Connect Sync: Szűrés konfigurálása.

Identitásnaplózás

Engedélyezze az Azure-erőforrások diagnosztikai beállításait az auditnaplóként használható információk kibocsátásához. A diagnosztikai információk azt mutatják, hogy mely identitások kísérelnek meg hozzáférni az erőforrásokhoz és a kísérletek eredményéhez. A rendszer elküldi az összegyűjtött naplókat az Azure Monitornak.

Kompromisszum: A naplózás költségekkel jár a naplók tárolásához használt adattár miatt. A teljesítményre is hatással lehet, különösen a kódra és az alkalmazáshoz hozzáadott naplózási megoldásokra.

Példa

Az alábbi példa egy identitás-implementációt mutat be. A különböző típusú identitások együttes használatával biztosítják a szükséges hozzáférési szinteket.

Identitásösszetevők

• Rendszer által felügyelt identitások. Microsoft Entra-azonosító olyan szolgáltatásadatsíkokhoz biztosít hozzáférést, amelyek nem szembesülnek a felhasználókkal, például az Azure Key Vault és az adattárakkal. Ezek az identitások az RBAC-vel is szabályozzák a hozzáférést az Azure felügyeleti síkjára a számítási feladatok összetevői, az üzembehelyezési ügynökök és a csapattagok számára.

• Számítási feladatok identitásai. A Azure Kubernetes Service (AKS) fürt alkalmazásszolgáltatásai számításifeladat-identitásokkal hitelesítik magukat a megoldás más összetevőivel.

• Felügyelt identitások. Az ügyfélszerepkör rendszerösszetevői rendszer által felügyelt identitásokat használnak, beleértve a fordítóügynököket is.

• Emberi identitások. A felhasználó és az operátor hitelesítése Microsoft Entra azonosítóra vagy Microsoft Entra-azonosítóra (natív, B2B vagy B2C) van delegálva.

Az előre felosztott titkos kulcsok biztonsága minden alkalmazás számára kritikus fontosságú. Az Azure Key Vault biztonságos tárolási mechanizmust biztosít ezekhez a titkos kódokhoz, beleértve a Redist és a külső titkos kulcsokat is.

A rotációs mechanizmussal biztosítható, hogy a titkos kulcsok ne sérüljenek. Az OAuth 2 és az OpenID Connect Microsoft Identitásplatform implementációjának jogkivonatai a felhasználók hitelesítésére szolgálnak.

Azure Policy biztosítják, hogy az identitásösszetevők, például Key Vault RBAC-t használjanak hozzáférési szabályzatok helyett. A JIT és a JEA hagyományos állandó engedélyeket biztosítanak az emberi operátorok számára.

A hozzáférési naplók az összes összetevőre vonatkozóan engedélyezve vannak Azure Diagnostics vagy kódösszetevők kódjában.

Kapcsolódó hivatkozások

• Oktatóanyag: Két hitelesítési hitelesítő adatkészlettel rendelkező erőforrások titkos kulcsainak rotálásának automatizálása
• Oktatóanyag: Tanúsítvány automatikus rotálási gyakoriságának frissítése Key Vault
• Az Microsoft Entra id újdonságai
• beépített szerepkörök Microsoft Entra
• Szerepköralapú hozzáférés-vezérlés áttekintése Microsoft Entra-azonosítóban
• Mik azok a számítási feladatok identitásai?
• Mik az Azure-erőforrások felügyelt identitásai?
• Feltételes hozzáférés: Felhasználók, csoportok és számítási feladatok identitásai
• Microsoft Entra Connect Sync: Szűrés konfigurálása

Biztonsági ellenőrzőlista

Tekintse meg a javaslatok teljes készletét.

Biztonsági ellenőrzőlista