Identitás- és hozzáférés-kezelésre vonatkozó javaslatok
Az Azure Well-Architected Framework biztonsági ellenőrzőlistára vonatkozó javaslatra vonatkozik:
| SE:05 | Szigorú, feltételes és auditálható identitás- és hozzáférés-kezelést (IAM) valósít meg minden számítási feladat felhasználója, csapattagja és rendszerösszetevője között. Kizárólag szükség esetén korlátozza a hozzáférést. Használjon modern iparági szabványokat minden hitelesítési és engedélyezési implementációhoz. A nem 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. Emellett a számítási feladaton belül található egyes összetevőket is tartalmaz. 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. Olyan entitások, akik nem szolgáltattak bizonyítékot arra vonatkozóan, hogy kik ők.
Meghatározások
| Feltételek | 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ára. |
| Feltételes hozzáférés | Olyan szabálykészlet, amely lehetővé teszi a megadott feltételeken alapuló műveleteket. |
| IdP | Egy identitásszolgáltató, például a Microsoft Entra ID. |
| Persona | Feladatfüggvény vagy beosztás, amely felelősségek és műveletek készletével rendelkezik. |
| Előmegosztott kulcsok | A szolgáltató és a fogyasztó között megosztott, biztonságos és egyeztetett 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, amelyek meghatározzák, hogy mit tehet egy felhasználó vagy csoport. |
| Hatókör | A szervezeti hierarchia különböző szintjei, ahol engedélyezett a szerepkörök működése. A rendszer funkcióinak egy csoportja is. |
| Rendszerbiztonsági tag | Engedélyeket biztosító identitás. Ez lehet felhasználó, csoport vagy szolgáltatásnév. Minden csoporttag ugyanazt a hozzáférési szintet kapja. |
| 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 feladatok identitása | Rendszeridentitás egy olyan alkalmazáshoz, szolgáltatáshoz, szkripthez, tárolóhoz vagy más összetevőhöz, amely más szolgáltatásokban és erőforrásokban való hitelesítésre szolgál. |
Feljegyzé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 biztonsá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 biztosított képességeket az identitás- és hozzáférés-kezeléshez. Ne implementáljon egyéni rendszereket az idP 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őn. A Microsoft Entra ID az Azure-felhőplatform identitásszolgáltatója.
Hitelesítés
A hitelesítés olyan folyamat, amely ellenőrzi az identitásokat. A kérő identitásnak valamilyen ellenőrizhető azonosítási formát kell megadnia. Példa:
Felhasználónév és jelszó.
Egy előre megosztott 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 tagadja 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őbb 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 feladat 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 ki kell terjednie minden olyan használati esetre, 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) irányuló folyamatokat.
Minden használati esetnek valószínűleg saját vezérlőkészlete lesz, amelyet a vélelmezéssel kapcsolatos gondolkodásmóddal kell megterveznie. A használati eset vagy a személyek identitáskövetelményei alapján azonosítsa a feltételes választásokat. Ne használjon egyetlen megoldást minden használati esetben. Ezzel szemben a vezérlőknek nem szabad 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 megfelelőségi auditokhoz.
A hitelesítés összes identitásának 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 a portálon keresztül kell hozzáférnie, 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 példát, 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 kulcsok lekérése a titkos tárból, és 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ítse magát 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ás szükséges.
Ezeket az identitásokat az identitásszolgáltatónak kell hitelesítenie.
Í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 a kívülről vagy kívülről történő adatátvitelt okozzák. Például egy alkalmazás adatokat olvas fel egy adatbázisból, és adatokat ír egy adatbázisba, titkos kulcsokat olvas be, vagy naplókat ír egy figyelési fogadóba. Az összetevő szintjén a rendszer adatsík-műveleteknek tekinti azt a számítást, amely képeket kér le vagy küld 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ő- és adatsíkokhoz is hozzáférnek. Az engedélyezési igények azonosításához jegyezze fel az erőforráson végrehajtható üzemeltetési műveleteket. Az egyes erőforrások engedélyezett műveleteiről további információt az Azure erőforrás-szolgáltatói műveleteiben talál.
Szerepköralapú engedélyezés biztosítása
Az egyes identitások felelőssége alapján engedélyezze azokat a műveleteket, amelyeket engedélyezni kell. Az identitások nem tehetnek többet, mint amennyit meg kell tenni. Mielőtt engedélyezési szabályokat állít be, tisztában kell legyen azzal, hogy ki vagy mi kér kéréseket, milyen szerepkörrel rendelkezhet, és milyen mértékben teheti meg. Ezek a tényezők identitást, szerepkört és hatókört kombináló választási lehetőségekhez vezetnek.
Vegyük példaként a számítási feladatok identitását. 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 tá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 nincs több. 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ő 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 potenciális támadási felületet. Ha csak az adott feladatok elvégzéséhez szükséges minimális engedélyeket adja meg, jelentősen csökken a sikeres támadás vagy a jogosulatlan hozzáférés kockázata. A biztonsági csapatoknak például csak írásvédett 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 felméréséhez, a lehetséges kockázatcsökkentések azonosításához és a kockázatokról való jelentéshez.
Vannak olyan helyzetek, amikor a felhasználóknak több hozzáférésre van szükségük a szervezeti struktúra és a csapatszervezés 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, az üzleti függvényen alapuló szerepkör-hozzárendelést ahelyett, hogy mindegyik felhasználó számára egyéni szerepkört hoz létre. 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ásokra. Ez összetett, örökölt konfigurációt hozhat létre, amely nehezen karbantartható, és negatívan befolyásolja a biztonságot és a megbízhatóságot 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 az engedélyezett felügyeleti csoporton, előfizetésen, erőforráscsoporton vagy erőforrás-hatókörön vagy más egyéni hatókörön működhet. 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. Például az olvasási hozzáférés 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). Az IdP által biztosított RBAC-vel mindig kihasználhatja azokat a funkciókat, amelyek lehetővé teszik a hozzáférés-vezérlés következetes alkalmazását és szigorú visszavonását.
Használjon beépített szerepköröket. Úgy vannak kialakítva, hogy lefedje a legtöbb használati esetet. Az egyéni szerepkörök hatékonyak és néha hasznosak, de olyan forgatókönyvek esetén érdemes lefoglalni őket, amelyekben a beépített szerepkörök nem működnek. A testreszabás összetettséghez vezet, amely növeli a keveredést, és összetettebbé, kihívást jelentőbbé és törékenyebbé teszi az automatizálást. Ezek a tényezők mind negatívan befolyásolják a biztonságot.
Adjon meg a minimális jogosultsággal kezdődő szerepköröket, és adjon hozzá további üzemeltetési vagy adathozzáférési igényeket. A technikai 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 azonos hozzáférési szintet. A döntéseket két fő tényező alapján hozhatja meg:
Az idő. Mennyi ideig férhet 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 a hozzáférés használatával továbbra is módosíthatják a környezetet. Ezeket a hozzáférési tényezőket mind megelőző intézkedésként, mind a robbanási sugár szabályozása érdekében korlátozza.
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ő, más feltételek is é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 adatbesorolás és az 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ő hozzáférési szintre 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 biztosítsa ezt a különbséget, olyan beépített funkciókat biztosítson, amelyek a legkisebb 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 a Microsoft Entra ID. További információkért tekintse meg a cikk Azure-beli facilitálási szakaszát .
Kritikus hatással rendelkező fiókok védelme
A felügyeleti identitások a legnagyobb biztonsági kockázatokat hordozzák magukban, mivel az általuk végzett feladatokhoz kiemelt hozzáférésre van szükség ezen rendszerek és alkalmazások széles köréhez. A kompromisszum vagy a visszaélés káros hatással lehet az üzletére é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 .
Kerülje az állandó vagy állandó hozzáférést az idP JIT-funkcióinak használatával. 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. Ezeket a mechanizmusokat külsőleg kell létrehoznia az identitásszolgáltatójához.
A 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örnyezetekben, é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 konzisztens, mérvadó forrásra van szükségük a biztonsági garanciák teljesítéséhez. A központi identitáscsoporttal együttműködve gondoskodhat arról, hogy a hibrid környezetekben lévő identitások szinkronizálva legyenek.
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 végezhetnek a helyszíni eszközök felett, és ez egy felhőfiók sikeres feltöréséhez vezethet. Értékelje ki a szinkronizálási stratégiát úgy, hogy kiszűri a támadási felülethez hozzáadható fiókokat.
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ó folyamattal, ha a csapatszerkezet vagy a szoftverösszetevők módosulnak.
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 feladatokra vonatkozó engedélyeiket eltávolítsák.
A nonidentitáson alapuló titkos kódok védelme
Az alkalmazás titkos kulcsait, például az előmegosztott kulcsokat a rendszer sebezhető pontjainak kell tekinteni. 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 azért is lehetnek nehézkesek, mert ü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ó 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. Az alkalmazáskódban, az IaC-szkriptekben, az üzembehelyezési folyamatokban vagy bármely más összetevőben nem szabad őket szigorúan kódoltként 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 tekintse meg a titkos kódok rotálásának automatizálását olyan erőforrások esetében, amelyek két hitelesítési hitelesítő adatkészlettel rendelkeznek, és oktatóanyag: A tanúsítvány automatikus rotálási gyakoriságának frissítése a Key Vaultban.
A fejlesztési környezetek biztonságának megőrzése
Minden kód- és szkript-, folyamat-eszköz- és forrásvezérlő rendszert munkaterhelési eszköznek 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 biztonsági kódok társviszony-felülvizsgálatainak a fejlesztési életciklusba 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 erőforrásokhoz az üzembe helyezési környezetekből, például a GitHubról.
Naplózási nyomvonal 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ó fenntartása 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ási 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ás-bejelentkezésekbe és elemzésekbe.
A biztonsági és megfelelőségi követelmények alapján értékelje ki az identitások hozzáférését a számítási feladathoz, é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ókért tekintse meg a biztonsági monitorozásra és fenyegetéselemzésre vonatkozó ajánlásokat.
Az Azure megkönnyítése
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. A Microsoft Entra ID 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. A Microsoft Entra ID az a bérlő, amely a számítási feladatok előfizetéséhez van társítva. 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 szegmensekhez:
Microsoft Entra-azonosító. Alkalmazottak és vállalati erőforrások.
Azure AD B2C. Ügyfelek.
Microsoft Entra összevonási kompatibilitási lista. Külső összevonási megoldások.
A Microsoft Entra ID-t használhatja az egyéni alkalmazások hitelesítéséhez és engedélyezéséhez 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.
A Microsoft Entra ID újdonságainak megtekintésével naprakész maradhat.
Azure-támogatás 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 saját folyamatok tervezése helyett.
Azure RBAC-vel
Az Azure RBAC a Microsoft Entra ID-ban található 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óért lásd: 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 a Microsoft Entra ID-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 a Privileged Identity Management?
Az RBAC-vel kapcsolatos további információkért tekintse meg az Azure RBAC ajánlott eljárásait.
Az attribútumalapú vezérlőkkel kapcsolatos információkért lásd: Mi az Azure ABAC?
Számítási feladatok identitása
A Microsoft Entra ID 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álhatja a szolgáltatásnevek használatát. 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 a Microsoft Entra hitelesítést támogató más szolgáltatásokban. További információ: Azure-szolgáltatások, amelyek felügyelt identitásokkal férhetnek hozzá más szolgáltatásokhoz.
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 írja le. A feltételes hozzáférés használatához ismernie kell a használati esethez szükséges korlátozásokat. A Microsoft Entra feltételes hozzáférés konfigurálásához állítson be egy hozzáférési szabályzatot, amely a működési igényeinek megfelelően van beállítva.
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ése
Ahelyett, hogy engedélyeket ad egy adott felhasználónak, a Microsoft Entra ID-ban rendeljen hozzá hozzáférést a csoportokhoz. Ha egy csoport nem létezik, az identitáscsoporttal 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 aktuálisak. A csoportot más célokra is használhatja, például levelezőlistákra.
További információ: Biztonságos hozzáférés-vezérlés csoportok használatával a 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ás viselkedéselemzése (UEBA) megkönnyíti 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 azokat a Microsoft Entra-azonosítókat, amelyek magas jogosultságokkal rendelkeznek a meglévő Active Directoryban. Ez a szinkronizálás az alapértelmezett Microsoft Entra Connect Sync-konfigurációban le van tiltva, ezért csak azt kell ellenőriznie, hogy nem szabta-e testre ezt a konfigurációt.
A Microsoft Entra ID-ban történő szűrésről további információt a Microsoft Entra Connect Sync: Szűrés konfigurálása című témakörben talál.
Identitásnaplózás
Az Azure-erőforrások diagnosztikai beállításainak engedélyezése az auditútvonalként használható információk kibocsátásához. A diagnosztikai információk azt mutatják, hogy mely identitások próbálják elérni, hogy mely erőforrásokat és a kísérletek eredményét próbálják elérni. Az összegyűjtött naplókat a rendszer elküldi az Azure Monitornak.
Példa
Az alábbi példa egy identitás-implementációt mutat be. A rendszer különböző identitástípusokat használ a szükséges hozzáférési szintek biztosításához.
Identitásösszetevők
Rendszer által felügyelt identitások. A Microsoft Entra ID hozzáférést biztosít olyan szolgáltatásadatsíkokhoz, amelyek nem szembesülnek a felhasználókkal, például az Azure Key Vaulttal és az adattárakkal. Ezek az identitások RBAC-en keresztül is szabályozják az Azure felügyeleti síkhoz való hozzáférést 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. Az Azure Kubernetes Service (AKS) fürt alkalmazásszolgáltatásai számítási feladatidentitásokkal hitelesítik magukat a megoldás más összetevőinek.
Felügyelt identitások. Az ügyfélszerepkör rendszerösszetevői rendszer által felügyelt identitásokat használnak, beleértve a buildügynököket is.
Emberi identitások. A felhasználó- és operátor-hitelesítés a Microsoft Entra-azonosítóra vagy a Microsoft Entra-azonosítóra (natív, B2B vagy B2C) van delegálva.
Az előre felosztott titkos kódok 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 rendszer rotációs mechanizmussal gondoskodik arról, 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.
Az Azure Policy használatával biztosítható, hogy a Key Vaulthoz hasonló identitásösszetevők hozzáférési szabályzatok helyett RBAC-t használjanak. A JIT és a JEA hagyományos állandó engedélyeket biztosít az emberi operátorok számára.
A hozzáférési naplók minden összetevőben engedélyezve vannak az Azure Diagnosticson keresztül, vagy kódösszetevők kódjában.
Kapcsolódó hivatkozások
- Oktatóanyag: A titkos kódok rotálásának automatizálása két hitelesítési hitelesítő adatkészlettel rendelkező erőforrások esetében
- Oktatóanyag: A tanúsítvány automatikus rotálási gyakoriságának frissítése a Key Vaultban
- A Microsoft Entra ID újdonságai
- Microsoft Entra beépített szerepek
- Szerepköralapú hozzáférés-vezérlés áttekintése a Microsoft Entra ID-ben
- Mik azok a számítási feladatok identitásai?
- Melyek 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
- A Microsoft Entra Connect szinkronizálása: a szűrés konfigurálása
Biztonsági ellenőrzőlista
Tekintse meg a javaslatok teljes készletét.