Ajánlott eljárások az összes elkülönítési architektúrához
Az alábbiakban az összes elkülönítési konfiguráció tervezési szempontjait vesszük figyelembe. Ebben a tartalomban számos hivatkozás található. Itt nem duplikáljuk, hanem a tartalomra hivatkozunk, így mindig hozzáférhet a legfrissebb információkhoz.
A Microsoft Entra-bérlők (izolált vagy nem elkülönített) konfigurálásáról a Microsoft Entra szolgáltatás üzembe helyezési útmutatójában talál általános útmutatást.
Feljegyzés
Minden izolált bérlő esetében javasoljuk, hogy használjon egyértelmű és megkülönböztetett védjegyzést, hogy elkerülje a rossz bérlőn végzett munka emberi hibáját.
Elkülönítési biztonsági alapelvek
Izolált környezetek tervezésekor fontos figyelembe venni a következő alapelveket:
Csak modern hitelesítés használata – Az izolált környezetekben üzembe helyezett alkalmazásoknak jogcímalapú modern hitelesítést (például SAML, * Auth, OAuth2 és OpenID Connect) kell használniuk olyan képességek használatához, mint az összevonás, a Microsoft Entra B2B együttműködése, a delegálás és a hozzájárulási keretrendszer. Így az örökölt hitelesítési módszerektől függő örökölt alkalmazások, például az NT LAN Manager (NTLM) nem fognak továbbhaladni elszigetelt környezetekben.
Erős hitelesítés kényszerítése – Az elkülönített környezeti szolgáltatások és infrastruktúra elérésekor mindig erős hitelesítést kell használni. Amikor csak lehetséges, jelszó nélküli hitelesítést kell használni, például a Windows for Business Hello-t vagy a FIDO2 biztonsági kulcsokat.
Biztonságos munkaállomások - üzembe helyezése A biztonságos munkaállomások biztosítják a mechanizmust annak biztosítására, hogy a platform és az identitás, amelyet a platform képvisel, megfelelő igazolással és védelemmel rendelkezzen a hasznosítás ellen. Két másik megfontolandó megközelítés:
Használjon Windows 365 felhőalapú PC (felhőalapú PC) a Microsoft Graph API-val.
Feltételes hozzáférés használata és az eszközök szűrése feltételként.
Régi megbízhatósági mechanizmusok megszüntetése – Az izolált címtárak és szolgáltatások nem hozhatnak létre megbízhatósági kapcsolatokat más környezetekkel olyan örökölt mechanizmusokon keresztül, mint például az Active Directory megbízhatósági kapcsolatok. A környezetek közötti összes megbízhatósági kapcsolatot modern szerkezetekkel, például összevonással és jogcímalapú identitással kell létrehozni.
Szolgáltatások elkülönítése – A felszíni támadási terület minimalizálása a mögöttes identitások és a szolgáltatási infrastruktúra kitettség elleni védelmével. Csak modern hitelesítéssel engedélyezze a hozzáférést a szolgáltatásokhoz, és biztonságos (szintén modern hitelesítéssel védett) távelérést az infrastruktúrához.
Címtárszintű szerepkör-hozzárendelések – A címtárszintű szerepkör-hozzárendelések számának elkerülése vagy csökkentése (AU-hatókör helyett a címtár hatókörében lévő felhasználói rendszergazda) vagy a szolgáltatásspecifikus címtárszerepkörök vezérlősík-műveletekkel (a biztonsági csoporttagságok kezeléséhez szükséges engedélyekkel rendelkező tudásadminisztrátor).
A Microsoft Entra általános üzemeltetési útmutatójában található útmutatás mellett az alábbi szempontokat is javasoljuk az izolált környezetek esetében.
Emberi identitás kiépítése
Kiemelt fiókok
Fiókok kiépítése elkülönített környezetben a környezetet üzemeltető rendszergazdai és informatikai csapatok számára. Ez lehetővé teszi, hogy erősebb biztonsági szabályzatokat, például eszközalapú hozzáférés-vezérlést adjon hozzá a biztonságos munkaállomásokhoz. Az előző szakaszokban leírtak szerint a nem termelési környezetek a Microsoft Entra B2B-együttműködést kihasználva emelt szintű fiókokat hozhatnak létre a nem éles bérlők számára ugyanazokkal a testtartási és biztonsági vezérlőkkel, amelyek az éles környezetben való kiemelt hozzáférésre lettek tervezve.
A csak felhőalapú fiókok a legegyszerűbb módja annak, hogy emberi identitásokat építhessenek ki a Microsoft Entra-bérlőkben, és ez jó választás zöldmezős környezetekhez. Ha azonban van egy meglévő helyszíni infrastruktúra, amely megfelel az izolált környezetnek (például az éles üzem előtti vagy a felügyeleti Active Directory-erdőnek), érdemes lehet onnan szinkronizálni az identitásokat. Ez különösen igaz, ha az itt leírt helyszíni infrastruktúrát olyan IaaS-megoldásokhoz használják, amelyek kiszolgálói hozzáférést igényelnek a megoldás adatsíkjának kezeléséhez. Erről a forgatókönyvről további információt a Microsoft 365 helyszíni támadások elleni védelme című témakörben talál. Az elkülönített helyszíni környezetekből való szinkronizálásra akkor is szükség lehet, ha konkrét jogszabályi megfelelőségi követelmények vannak, például csak intelligens kártyás hitelesítés.
Feljegyzés
A Microsoft Entra B2B-fiókok identitásellenőrzéséhez nincsenek technikai vezérlők. A Microsoft Entra B2B-vel kiépített külső identitások egyetlen tényezővel vannak kihasználva. A kockázatcsökkentés az, hogy a szervezetnek rendelkeznie kell egy folyamattal a szükséges identitások ellenőrzésére a B2B-meghívás kiadása előtt, valamint a külső identitások rendszeres hozzáférési felülvizsgálatát az életciklus kezeléséhez. Fontolja meg egy feltételes hozzáférési szabályzat engedélyezését az MFA-regisztráció szabályozásához.
Magas kockázatú szerepkörök kiszervezése
A belső fenyegetések csökkentése érdekében ki lehet szervezni a globális rendszergazdai és emelt szintű szerepkör-rendszergazdai szerepkörökhöz való hozzáférést felügyelt szolgáltatóként az Azure B2B együttműködésével, vagy a hozzáférés csp-partneren vagy világítótoronyon keresztüli delegálásával. Ezt a hozzáférést a házon belüli személyzet szabályozhatja az Azure Privileged Identity Management (PIM) jóváhagyási folyamatán keresztül. Ez a megközelítés jelentősen csökkentheti a belső fenyegetéseket. Ez egy olyan megközelítés, amellyel kielégítheti az aggályokkal rendelkező ügyfelek megfelelőségi igényeit.
Nem emberi identitás kiépítése
Vészhelyzeti hozzáférési fiókok
A Microsoft azt javasolja, hogy a szervezetek két kizárólag felhőalapú segélyhívási fiókkal rendelkezzenek, amelyekhez véglegesen hozzárendelték a globális rendszergazdai szerepkört. Ezek a fiókok kiemelt jogosultságokkal rendelkeznek, és nincsenek meghatározott személyekhez rendelve. A fiókok vészhelyzeti vagy "töréstörési" forgatókönyvekre korlátozódnak, ahol a normál fiókok nem használhatók, vagy az összes többi rendszergazda véletlenül ki van zárva. Ezeket a fiókokat a segélyhívási fiók javaslatait követve kell létrehozni.
Felügyelt Azure-identitások
Azure-beli felügyelt identitások használata szolgáltatásidentitást igénylő Azure-erőforrásokhoz. Tekintse meg a felügyelt identitásokat támogató szolgáltatások listáját az Azure-megoldások tervezésekor.
Ha a felügyelt identitások nem támogatottak vagy nem lehetségesek, fontolja meg a szolgáltatásnév-objektumok kiépítését.
Hibrid szolgáltatásfiókok
Egyes hibrid megoldások helyszíni és felhőbeli erőforrásokhoz is hozzáférést igényelhetnek. Ilyen eset például egy olyan alkalmazás, amely szolgáltatásfiókot használ az AD DS-ben a helyszíni tartományhoz csatlakoztatott kiszolgálókhoz való hozzáféréshez, és rendelkezik egy Fiókkal a Microsoft Entra-azonosítóban, mivel az hozzáférést igényel a Microsoft Online Serviceshez.
A helyszíni szolgáltatásfiókok általában nem tudnak interaktívan bejelentkezni, ami azt jelenti, hogy a felhőbeli forgatókönyvekben nem képesek teljesíteni az erős hitelesítő adatokra vonatkozó követelményeket, például a többtényezős hitelesítést. Ebben a forgatókönyvben ne a helyszínen szinkronizált szolgáltatásfiókot használja, hanem használjon felügyelt identitás \ szolgáltatásnevet. Szolgáltatásnév (SP) esetén használjon tanúsítványt hitelesítő adatként, vagy védje az SP-t feltételes hozzáféréssel.
Ha vannak olyan technikai korlátozások, amelyek ezt nem teszik lehetővé, és ugyanazt a fiókot kell használni a helyszínen és a felhőben is, akkor olyan kompenzáló vezérlőket implementáljon, mint a feltételes hozzáférés, hogy zárolja a hibrid fiókot, hogy egy adott hálózati helyről érkezzen.
Erőforrás-hozzárendelés
A vállalati megoldások több Azure-erőforrásból állhatnak, és hozzáférését logikai hozzárendelési egységként – erőforráscsoportként – kell kezelni és szabályozni. Ebben a forgatókönyvben a Microsoft Entra biztonsági csoportjai létrehozhatók és társíthatók a megfelelő engedélyekkel és szerepkör-hozzárendeléssel az összes megoldáserőforrásban, így a felhasználók felvétele vagy eltávolítása a csoportokból a teljes megoldáshoz való hozzáférés engedélyezését vagy letiltását eredményezi.
Javasoljuk, hogy olyan Microsoft-szolgáltatások csoportalapú licencelési és biztonsági csoportokat használjon, amelyek a hozzáférés (például Dynamics 365, Power BI) biztosítása előtt előfeltételként licenchely-hozzárendeléssel rendelkező felhasználóra támaszkodnak.
A Microsoft Entra felhőbeli natív csoportjai natív módon szabályozhatók a felhőből a Microsoft Entra hozzáférési felülvizsgálataival és a Microsoft Entra jogosultságkezelésével kombinálva.
A Microsoft Entra ID emellett támogatja a közvetlen felhasználói hozzárendelést külső SaaS-szolgáltatásokhoz (például Salesforce, Service Now) és helyszíni alkalmazásokhoz egyszeri bejelentkezéshez és identitáskiépítéshez. Az erőforrásokhoz való közvetlen hozzárendelések natív módon szabályozhatók a felhőből a Microsoft Entra hozzáférési felülvizsgálataival és a Microsoft Entra jogosultságkezelésével kombinálva. A közvetlen hozzárendelés jó választás lehet a végfelhasználók számára.
Egyes esetekben szükség lehet a helyszíni erőforrásokhoz való hozzáférés megadására helyi Active Directory biztonsági csoportokon keresztül. Ezekben az esetekben fontolja meg a Microsoft Entra ID-ra való szinkronizálási ciklust a folyamatok SLA-jának tervezésekor.
Hitelesítés kezelése
Ez a szakasz a szervezet biztonsági helyzetén alapuló hitelesítőadat-kezelési és hozzáférési szabályzatok végrehajtásához szükséges ellenőrzéseket és műveleteket ismerteti.
Hitelesítő adatok kezelése
Erős hitelesítő adatok
Az izolált környezetben az összes emberi identitást (a B2B-együttműködéssel kiépített helyi fiókokat és külső identitásokat) erős hitelesítési hitelesítő adatokkal kell kiépíteni, például többtényezős hitelesítéssel vagy FIDO-kulccsal. Az erős hitelesítéssel, például intelligenskártya-hitelesítéssel rendelkező helyszíni infrastruktúrával rendelkező környezetek továbbra is használhatják az intelligenskártya-hitelesítést a felhőben.
Jelszó nélküli hitelesítő adatok
A jelszó nélküli megoldás a legjobb megoldás a legkényelmesebb és legbiztonságosabb hitelesítési módszer biztosítására. A jelszó nélküli hitelesítő adatok, például a FIDO biztonsági kulcsok és a Vállalati Windows Hello a kiemelt szerepkörökkel rendelkező emberi identitásokhoz ajánlottak.
Jelszavas védelem
Ha a környezet szinkronizálva van egy helyi Active Directory erdőből, a microsoft Entra jelszóvédelem üzembe helyezésével kiküszöbölheti a gyenge jelszavakat a szervezetben. A Microsoft Entra intelligens zárolását hibrid vagy csak felhőalapú környezetekben is érdemes használni, hogy kizárja azokat a rossz szereplőket, akik megpróbálják kitalálni a felhasználói jelszavakat, vagy találgatásos módszerekkel próbálnak bejutni.
Önkiszolgáló jelszókezelés
Az ügyfélszolgálati hívások mennyiségének és költségének egyik legnagyobb forrása, hogy a felhasználóknak módosítaniuk vagy alaphelyzetbe kell állítaniuk a jelszavukat. A költségek mellett a jelszó eszközként való módosítása a felhasználói kockázat csökkentése érdekében alapvető lépés a szervezet biztonsági helyzetének javításában. Legalább helyezzen üzembe önkiszolgáló jelszókezelést emberi és tesztfiókok számára jelszavakkal az ügyfélszolgálati hívások eltérülése érdekében.
Külső identitások jelszavai
A Microsoft Entra B2B együttműködésével a meghívási és visszaváltási folyamat lehetővé teszi, hogy külső felhasználók, például partnerek, fejlesztők és alvállalkozók saját hitelesítő adataikkal férhessenek hozzá a vállalat erőforrásaihoz. Ez csökkenti annak szükségességét, hogy több jelszót vezessen be az elkülönített bérlőkbe.
Feljegyzés
Egyes alkalmazásokhoz, infrastruktúrához vagy munkafolyamatokhoz helyi hitelesítő adatokra lehet szükség. Ezt eseti alapon értékelje ki.
Szolgáltatásnevek hitelesítő adatai
Olyan esetekben, amikor szolgáltatásnevekre van szükség, használja a tanúsítvány hitelesítő adatait a szolgáltatásnevekhez vagy a feltételes hozzáférést a számítási feladatok identitásaihoz. Ha szükséges, használja az ügyfél titkos kulcsát a szervezeti szabályzat kivételeként.
Az Azure Key Vault mindkét esetben használható felügyelt Azure-identitásokkal, így a futtatókörnyezet (például egy Azure-függvény) lekérheti a hitelesítő adatokat a kulcstartóból.
Ebben a példában önaláírt tanúsítvánnyal rendelkező szolgáltatásneveket hozhat létre a szolgáltatásnevek hitelesítéséhez tanúsítványhitelesítéshez.
Hozzáférési szabályzatok
Az alábbi szakaszokban az Azure-megoldásokra vonatkozó javaslatok találhatók. Az egyes környezetek feltételes hozzáférési szabályzataival kapcsolatos általános útmutatásért tekintse meg a feltételes hozzáférés ajánlott eljárásait, a Microsoft Entra üzemeltetési útmutatóját és a feltételes hozzáférést Teljes felügyelet:
Feltételes hozzáférési szabályzatok definiálása a Windows Azure Service Management API felhőalkalmazáshoz az identitásbiztonsági helyzet kikényszerítéséhez az Azure Resource Manager elérésekor. Ennek tartalmaznia kell az MFA vezérlőit és az eszközalapú vezérlőket, amelyek csak biztonságos munkaállomásokon keresztül engedélyezik a hozzáférést (erről bővebben az Identitásszabályozás kiemelt szerepkörök szakaszában olvashat). Emellett a feltételes hozzáféréssel szűrhet az eszközökre.
Az elkülönített környezetekbe előkészített összes alkalmazásnak explicit feltételes hozzáférési szabályzatokkal kell rendelkeznie az előkészítési folyamat részeként.
A helyszíni megbízhatósági folyamat biztonságos gyökerét tükröző biztonsági információregisztrációs feltételes hozzáférési szabályzatok definiálása (például fizikai helyeken lévő munkaállomások esetében, AMELYEK IP-címek alapján azonosíthatók, amelyeket az alkalmazottaknak személyesen kell felkeresniük ellenőrzés céljából).
Fontolja meg a feltételes hozzáférés használatát a számítási feladatok identitásainak korlátozásához. Hozzon létre egy szabályzatot a hozzáférés hely vagy egyéb releváns körülmények alapján történő korlátozásához vagy jobb szabályozásához.
Hitelesítési kihívások
Előfordulhat, hogy a Microsoft Entra B2B-vel kiépített külső identitások esetében újra kell építenie a többtényezős hitelesítési hitelesítő adatokat az erőforrás-bérlőben. Erre akkor lehet szükség, ha a bérlők közötti hozzáférési szabályzat nincs beállítva az erőforrás-bérlővel. Ez azt jelenti, hogy a rendszerbe való bevezetés egyetlen tényezővel van leképezve. Ezzel a megközelítéssel a kockázatcsökkentés célja, hogy a szervezet egy B2B-meghívó kiadása előtt igazolnia kell a felhasználó és a hitelesítő adatok kockázati profilját. Emellett definiálja a regisztrációs folyamat feltételes hozzáférését a korábban ismertetett módon.
Külső identitások bérlők közötti hozzáférési beállításainak használatával kezelheti, hogyan működnek együtt más Microsoft Entra-szervezetekkel és más Microsoft Azure-felhőkkel A B2B együttműködés és a közvetlen B2B-kapcsolat révén.
Adott eszközkonfigurációhoz és -vezérléshez a feltételes hozzáférési szabályzatokban eszközszűrőket használhat adott eszközök megcélzásához vagy kizárásához. Ez lehetővé teszi az Azure felügyeleti eszközökhöz való hozzáférés korlátozását egy kijelölt biztonságos rendszergazdai munkaállomásról (SAW). További megközelítések az Azure Virtual Desktop, az Azure Bastion vagy a Cloud PC használata.
A számlázási felügyeleti alkalmazások, például az Azure EA Portal vagy az MCA számlázási fiókok nem jelennek meg felhőalapú alkalmazásként a feltételes hozzáférés célzásához. Kompenzáló vezérlőként definiáljon külön felügyeleti fiókokat és cél feltételes hozzáférési szabályzatokat ezekhez a fiókokhoz egy "Minden alkalmazás" feltétel használatával.
Identity Governance
Kiemelt szerepkörök
Az alábbiakban néhány identitásszabályozási alapelvet érdemes figyelembe venni az elkülönítés összes bérlői konfigurációja esetében.
Nincs állandó hozzáférés – Egyetlen emberi identitásnak sem kell állandó hozzáféréssel rendelkeznie a kiemelt műveletek izolált környezetekben való végrehajtásához. Az Azure Szerepköralapú hozzáférés-vezérlés (RBAC) integrálható a Microsoft Entra Privileged Identity Management (PIM) szolgáltatással. A PIM olyan biztonsági kapuk által meghatározott igény szerinti aktiválást biztosít, mint a többtényezős hitelesítés, a jóváhagyási munkafolyamat és a korlátozott időtartam.
Rendszergazdák száma – A szervezeteknek meg kell határozniuk a kiemelt szerepkörrel rendelkező emberek minimális és maximális számát az üzletmenet-folytonossági kockázatok csökkentése érdekében. Túl kevés kiemelt szerepkör esetén előfordulhat, hogy nincs elegendő időzóna-lefedettség. A minimális jogosultsági elvnek megfelelően a lehető legkevesebb rendszergazdai jogosultsággal csökkentheti a biztonsági kockázatokat.
Emelt szintű hozzáférés korlátozása – Csak felhőalapú és szerepkörhöz rendelhető csoportok létrehozása magas jogosultsági vagy bizalmas jogosultságokhoz. Ez védelmet nyújt a hozzárendelt felhasználók és a csoportobjektum számára.
Legkevésbé kiemelt hozzáférés – Az identitások csak a szervezeten belüli szerepkörüknek megfelelő kiemelt műveletek végrehajtásához szükséges engedélyeket kaphatják meg.
Az Egyéni Azure RBAC-szerepkörök lehetővé teszik a legkevésbé kiemelt szerepkörök tervezését a szervezeti igények alapján. Javasoljuk, hogy az egyéni szerepkör-definíciókat speciális biztonsági csapatok szerkesszen vagy vizsgálja felül, és mérsékelje a nem szándékos túlzott jogosultságok kockázatát. Az egyéni szerepkörök írása az Azure Policy használatával naplózható.
A szervezeten belüli szélesebb körű használatra szánt szerepkörök véletlen használatának mérséklése érdekében az Azure Policy használatával explicit módon határozhatja meg, hogy mely szerepkör-definíciók használhatók a hozzáférés hozzárendeléséhez. További információ erről a GitHub-mintáról.
Emelt szintű hozzáférés biztonságos munkaállomásokról – Minden emelt szintű hozzáférésnek biztonságos, zárolt eszközökről kell történnie. Ezeknek a bizalmas feladatoknak és fiókoknak a napi használattól való elkülönítése munkaállomásoktól és eszközöktől védi a kiemelt fiókokat az adathalász támadásoktól, az alkalmazások és operációs rendszerek biztonsági réseitől, a különböző megszemélyesítési támadásoktól és a hitelesítő adatok ellopásával kapcsolatos támadásoktól, például a kulcsleütés-naplózástól, a Pass-the-Hash-tól és a Pass-The-Tickettől.
A kiemelt hozzáférési történet részeként a biztonságos eszközök használatára használható egyes megközelítések közé tartozik a feltételes hozzáférési szabályzatok használata bizonyos eszközök megcélzásához vagy kizárásához, az Azure Virtual Desktop, az Azure Bastion vagy a Cloud PC használatával, vagy az Azure által felügyelt munkaállomások vagy emelt szintű hozzáférési munkaállomások létrehozása.
Privileged role process guardrails – A szervezeteknek olyan folyamatokat és technikai védőkorlátokat kell meghatározniuk, amelyek biztosítják, hogy a kiemelt műveletek szükség esetén végrehajthatók legyenek a jogszabályi követelményeknek való megfelelés mellett. A védőkorlátok feltételei közé tartoznak például a következők:
Kiemelt szerepkörrel rendelkező emberek minősítése (például teljes munkaidős alkalmazott/szállító, engedélyszint, állampolgárság)
A szerepkörök explicit inkompatibilitása (más néven a feladatok elkülönítése). Ilyenek például a Microsoft Entra címtárszerepkörrel rendelkező csapatok, nem lehetnek felelősek az Azure Resource Manager kiemelt szerepköreinek kezeléséért stb.
A közvetlen felhasználó- vagy csoporthozzárendelések előnyben részesíthetők-e a szerepkörökhöz.
A Microsoft Entra PIM-en kívüli IAM-hozzárendelések monitorozása nem automatizálható az Azure-szabályzatok segítségével. A kockázatcsökkentés célja, hogy ne adjon előfizetés-tulajdonosi vagy felhasználói hozzáférés-rendszergazdai szerepköröket a mérnöki csapatoknak. Ehelyett hozzon létre csoportokat a legkevésbé kiemelt szerepkörökhöz, például a Közreműködőhöz, és delegálja ezeknek a csoportoknak a felügyeletét a mérnöki csapatoknak.
Erőforrás-hozzáférés
Igazolás – A kiemelt szerepköröket tartalmazó identitásokat rendszeresen felül kell vizsgálni a tagság aktuális és indokolt állapotának megőrzése érdekében. A Microsoft Entra hozzáférési felülvizsgálatok integrálhatók az Azure RBAC-szerepkörökkel, csoporttagságokkal és a Microsoft Entra B2B külső identitásaival.
Életciklus – A kiemelt műveletekhez több erőforráshoz, például üzletági alkalmazásokhoz, SaaS-alkalmazásokhoz, valamint Azure-erőforráscsoportokhoz és -előfizetésekhez is hozzáférésre lehet szükség. A Microsoft Entra Jogosultságkezelés lehetővé teszi olyan hozzáférési csomagok meghatározását, amelyek egy, a felhasználókhoz egységként hozzárendelt erőforrást jelölnek, érvényességi időtartamot, jóváhagyási munkafolyamatokat stb.
Bérlői és előfizetési életciklus-kezelés
Bérlői életciklus
Javasoljuk, hogy implementáljon egy folyamatot egy új vállalati Microsoft Entra-bérlő kéréséhez. A folyamatnak a következőt kell figyelembe vennie:
A létrehozás üzleti indoka. Az új Microsoft Entra-bérlő létrehozása jelentősen növeli az összetettségüket, ezért kulcsfontosságú annak megállapítása, hogy szükség van-e új bérlőre.
Az Azure-felhő, amelyben létre kell hozni (például kereskedelmi, kormányzati stb.).
Éles üzemről van-e szó, vagy sem
Címtáradat-tárolási követelmények
Ki fogja kezelni?
A gyakori biztonsági követelmények betanítása és megértése.
Jóváhagyás után a Microsoft Entra-bérlő létrejön, konfigurálva lesz a szükséges alapkonfiguráció-vezérlőkkel, és a számlázási síkon, a monitorozásban és így tovább.
A Microsoft Entra-bérlők rendszeres felülvizsgálatát a számlázási síkon kell végrehajtani a bérlőlétrehozás észleléséhez és felderítéséhez a szabályozott folyamaton kívül. További részletekért tekintse meg a dokumentum Leltár és láthatóság szakaszát.
Az Azure AD B2C-bérlő létrehozása az Azure Policy használatával szabályozható. A szabályzat akkor lesz végrehajtva, ha egy Azure-előfizetés a B2C-bérlőhöz van társítva (ez a számlázás előfeltétele). Az ügyfelek az Azure AD B2C-bérlők létrehozását meghatározott felügyeleti csoportokra korlátozhatják.
Nincsenek olyan technikai vezérlők, amelyek alárendelik a bérlők létrehozását egy szervezetnek. A tevékenység azonban a naplózási naplóban van rögzítve. A számlázási gépre való előkészítés egy kompenzáló vezérlő a kapunál. Ezt inkább monitorozással és riasztásokkal kell kiegészíteni.
Előfizetés életciklusa
Az alábbiakban néhány szempontot figyelembe kell venni egy szabályozott előfizetési életciklus-folyamat tervezésekor:
Az Azure-erőforrásokat igénylő alkalmazások és megoldások osztályozásának meghatározása. Minden előfizetést kérő csapatnak meg kell adnia a "termékazonosítót" az előfizetések igénylésekor. Ez az információ-osztályozás a következőt határozza meg:
Microsoft Entra-bérlő az előfizetés kiépítéséhez
Előfizetés létrehozásához használandó Azure EA-fiók
Elnevezési konvenció
Felügyeleti csoport hozzárendelése
Egyéb szempontok, például címkézés, kereszttöltés, terméknézet-használat stb.
Ne engedélyezze az alkalmi előfizetések létrehozását a portálokon vagy más módon. Ehelyett fontolja meg az előfizetések programozott kezelését az Azure Resource Manager használatával, valamint a használati és számlázási jelentések programozott lekérését. Ez segíthet korlátozni az előfizetések kiépítését a jogosult felhasználók számára, és kikényszerítheti a szabályzatot és az osztályozási célokat. Az AZOps-tagok követésével kapcsolatos útmutatással gyakorlati megoldást hozhat létre.
Előfizetés kiépítésekor hozzon létre Microsoft Entra felhőcsoportokat az alkalmazáscsapatok, például a Közreműködő, az Olvasó és a jóváhagyott egyéni szerepkörök által igényelt standard Azure Resource Manager-szerepkörök tárolásához. Ez lehetővé teszi az Azure RBAC-szerepkör-hozzárendelések kezelését szabályozott emelt szintű hozzáféréssel.
Konfigurálja a csoportokat úgy, hogy jogosultak legyenek az Azure RBAC-szerepkörökre a Microsoft Entra PIM használatával a megfelelő vezérlőkkel, például az aktiválási szabályzattal, a hozzáférési felülvizsgálatokkal, a jóváhagyókkal stb.
Ezután delegálhatja a csoportok felügyeletét a megoldástulajdonosoknak.
Védőkorlátként ne rendeljen terméktulajdonosokat felhasználói hozzáférés-rendszergazdai vagy tulajdonosi szerepkörökhöz, hogy elkerülje a Microsoft Entra PIM-en kívüli szerepkörök véletlen közvetlen hozzárendelését, vagy az előfizetést teljesen más bérlőre módosíthatja.
Azoknak az ügyfeleknek, akik úgy döntenek, hogy az Azure Lighthouse-on keresztül engedélyezik a bérlők közötti előfizetés-kezelést nem éles bérlőkben, győződjön meg arról, hogy az előfizetések kezelésekor az éles jogosultságú fiók ugyanazon hozzáférési szabályzatai (például a kiemelt hozzáférés csak biztonságos munkaállomásokról) lesznek érvényesítve.
Ha a szervezet előre jóváhagyott referenciaarchitektúrákkal rendelkezik, az előfizetés kiépítése integrálható olyan erőforrás-üzembehelyezési eszközökkel, mint az Azure Blueprints vagy a Terraform.
Tekintettel az Azure-előfizetésekhez való bérlői affinitásra, az előfizetések kiépítésének több identitással kell rendelkeznie ugyanazon emberi szereplőhöz (alkalmazott, partner, szállító stb.) több bérlő között, és ennek megfelelően kell hozzárendelnie a hozzáférést.
EA- és MCA-szerepkörök
Az Azure Enterprise (Azure EA) szerződési portál nem integrálható az Azure RBAC-vel vagy a feltételes hozzáféréssel. Ennek a megoldásnak az a megoldása, hogy dedikált felügyeleti fiókokat használ, amelyek szabályzatokkal és további figyeléssel célozhatók meg.
Az Azure EA Enterprise portál nem biztosít naplózási naplót. Ennek mérséklése érdekében fontolja meg az előfizetések kiépítésének automatizált, a fent ismertetett szempontokat figyelembe véve történő kiépítését, valamint dedikált EA-fiókok használatát és a hitelesítési naplók naplózását.
Microsoft Ügyfélszerződés (MCA) szerepkörök nem integrálhatók natív módon a PIM-sel. Ennek csökkentése érdekében használjon dedikált MCA-fiókokat, és figyelje ezeknek a fiókoknak a használatát.
Azure AD B2C-bérlők
Egy Azure AD B2C-bérlőben a beépített szerepkörök nem támogatják a PIM-et. A biztonság növelése érdekében javasoljuk, hogy a Microsoft Entra B2B-együttműködéssel vegye fel az Azure-bérlőből az Ügyfélidentitás-hozzáférés-kezelést (CIAM) kezelő mérnöki csapatokat, rendelje őket az Azure AD B2C kiemelt szerepköreihez, és alkalmazza a feltételes hozzáférési szabályzatokat ezekre a dedikált felügyeleti fiókokra.
Az Azure AD B2C-bérlő kiemelt szerepkörei nincsenek integrálva a Microsoft Entra hozzáférési felülvizsgálataival. A kockázatcsökkentés az, hogy dedikált fiókokat hoz létre a szervezet Microsoft Entra-bérlőjében, hozzáadja ezeket a fiókokat egy csoporthoz, és rendszeres hozzáférési felülvizsgálatokat végez ezen a csoporton.
A Microsoft Entra-azonosítóra vonatkozó fenti vészhelyzeti hozzáférési irányelveket követve fontolja meg, hogy a fent leírt külső rendszergazdákon kívül egyenértékű segélyhívási hozzáférési fiókokat hozzon létre.
Javasoljuk, hogy a B2C-bérlő mögöttes Microsoft Entra-előfizetésének logikai tulajdonjoga igazodjon a CIAM mérnöki csapatához, ugyanúgy, ahogyan a többi Azure-előfizetést a B2C-megoldásokhoz használják.
Üzemeltetés
Az alábbiakban további üzemeltetési szempontokat is figyelembe kell venni a Microsoft Entra ID-ra vonatkozóan, amelyek több elkülönített környezetre vonatkoznak. Az egyes környezetek üzemeltetéséhez részletes útmutatást az Azure felhőadaptálási keretrendszer, a Microsoft felhőbiztonsági teljesítménytesztje és a Microsoft Entra Operations útmutatója nyújt.
Környezetek közötti szerepkörök és felelősségek
Nagyvállalati szintű SecOps-architektúra – A szervezet összes környezetéből származó üzemeltetési és biztonsági csapatok tagjainak közösen kell meghatározniuk a következőket:
A környezetek létrehozásának, konszolidálásának vagy elavult állapotának meghatározására vonatkozó alapelvek.
Alapelvek a felügyeleti csoportok hierarchiájának meghatározásához az egyes környezeteken.
Számlázási sík (EA Portal / MCA) biztonsági helyzet, működési helyzet és delegálási megközelítés.
Bérlőlétrehozás folyamata.
Nagyvállalati alkalmazás osztályozása.
Az Azure-előfizetések kiépítésének folyamata.
Elkülönítési és adminisztrációs autonómiahatárok és kockázatértékelés csapatok és környezetek között.
Az alapkonfiguráció és a biztonsági vezérlők (műszaki és kompenzáló) és a működési alapkonfigurációk, amelyeket minden környezetben használni kell.
Gyakori szabványos üzemeltetési eljárások és eszközök, amelyek több környezetre (például monitorozásra, kiépítésre) terjednek ki.
A szerepkörök több környezetben történő delegálásáról állapodtunk meg.
A feladatok elkülönítése a környezetek között.
A kiemelt munkaállomások ellátási láncának általános kezelése.
Elnevezési konvenciók.
Környezetek közötti korrelációs mechanizmusok.
Bérlőlétrehozás – Egy adott csapatnak kell létrehoznia a bérlőt a nagyvállalati szintű SecOps-architektúra által meghatározott szabványosított eljárások alapján. Ide tartoznak az alábbiak:
Mögöttes licenckiépítés (például Microsoft 365).
Bevezetés a vállalati számlázási csomagba (például Azure EA vagy MCA).
Az Azure felügyeleti csoport hierarchiájának létrehozása.
Felügyeleti szabályzatok konfigurálása különböző szegélyekhez, például identitáshoz, adatvédelemhez, Azure-hoz stb.
A biztonsági verem üzembe helyezése a kiberbiztonsági architektúrára vonatkozó megállapodás szerint, beleértve a diagnosztikai beállításokat, a SIEM-előkészítést, a CASB-előkészítést, a PIM-előkészítést stb.
A Microsoft Entra-szerepkörök konfigurálása a delegálás alapján.
A kezdeti emelt szintű munkaállomások konfigurálása és elosztása.
Segélyhívási hozzáférési fiókok kiépítése.
Identitáskiépítési verem konfigurálása.
Környezetek közötti eszközkezelési architektúra – Egyes eszközöknek, például az identitáskiépítésnek és a forrásvezérlési folyamatoknak több környezetben is működnie kell. Ezeket az eszközöket az infrastruktúra szempontjából kritikus fontosságúnak kell tekinteni, ezért ezeket az eszközöket úgy kell megtervezni, megtervezni, megvalósítani és felügyelni. Ennek eredményeképpen minden környezet tervezőit be kell vonni, amikor környezetközi eszközöket kell definiálni.
Leltár és láthatóság
Azure-előfizetések felderítése – Minden felderített bérlő esetében a Microsoft Entra globális rendszergazdája emelheti a hozzáférést a környezet összes előfizetésének láthatósága érdekében. Ez a jogosultságszint-emelés a felhasználói hozzáférés-rendszergazda beépített szerepkörét fogja hozzárendelni a gyökérszintű felügyeleti csoporthoz.
Feljegyzés
Ez a művelet kiemelt jogosultságokkal rendelkezik, és hozzáférést adhat a rendszergazda számára olyan előfizetésekhez, amelyek rendkívül bizalmas információkat tárolnak, ha az adatok nem lettek megfelelően elkülönítve.
Olvasási hozzáférés engedélyezése az erőforrások felderítéséhez – A felügyeleti csoportok több előfizetésre kiterjedő, nagy léptékű RBAC-hozzárendelést tesznek lehetővé. Az ügyfelek egy olvasói szerepkört adhatnak egy központosított informatikai csapatnak egy szerepkör-hozzárendelés konfigurálásával a gyökérszintű felügyeleti csoportban, amely a környezet összes előfizetésére propagálja.
Erőforrás-felderítés – Miután erőforrás-olvasási hozzáférést szerzett a környezetben, az Azure Resource Graph használható a környezet erőforrásainak lekérdezésére.
Naplózás és figyelés
Központi biztonsági naplókezelés – Naplók központi betöltése az egyes környezetekből, a környezetek konzisztens ajánlott eljárásait követve (például diagnosztikai beállítások, naplómegőrzés, SIEM-betöltés stb.). Az Azure Monitor különböző forrásokból, például végponteszközökről, hálózatról, operációs rendszerek biztonsági naplóiból stb. származó naplók betöltésére használható.
A naplók biztonsági műveletek részeként történő monitorozására automatizált vagy manuális folyamatok és eszközök használatával kapcsolatos részletes információk a Microsoft Entra biztonsági műveleti útmutatójában érhetők el.
Egyes környezetek olyan szabályozási követelményekkel rendelkezhetnek, amelyek korlátozzák, hogy mely adatok (ha vannak ilyenek) hagyhatnak el egy adott környezetet. Ha a környezetek közötti központosított monitorozás nem lehetséges, a csapatoknak üzemeltetési eljárásokkal kell rendelkezniük az identitások tevékenységeinek különböző környezetekben való összekapcsolására naplózási és kriminalisztikai célokra, például a környezetek közötti oldalirányú mozgási kísérletekhez. Javasoljuk, hogy az objektum egyedi azonosítói, az azonos személyhez tartozó emberi identitások felderíthetők, akár az identitáskiépítési rendszerek részeként is.
A naplóstratégiának tartalmaznia kell a következő Microsoft Entra-naplókat a szervezetben használt összes bérlőhöz:
Bejelentkezési tevékenység
Naplók
Kockázati események
A Microsoft Entra ID azure monitor-integrációt biztosít a bejelentkezési tevékenységnaplókhoz és az auditnaplókhoz. A kockázati események a Microsoft Graph API-n keresztül is betölthetők.
Az alábbi ábra a figyelési stratégia részeként beépítendő különböző adatforrásokat mutatja be:
Az Azure AD B2C-bérlők integrálhatók az Azure Monitorral. Javasoljuk, hogy az Azure AD B2C-t a Microsoft Entra ID-ra vonatkozó fent ismertetett feltételek szerint monitorozza.
Azok az előfizetések, amelyek engedélyezték a bérlők közötti felügyeletet az Azure Lighthouse-ral, engedélyezhetik a bérlők közötti monitorozást, ha a naplókat az Azure Monitor gyűjti. A megfelelő Log Analytics-munkaterületek az erőforrás-bérlőben lehetnek, és központilag elemezhetők a felügyeleti bérlőben az Azure Monitor-munkafüzetek használatával. További információ: Delegált erőforrások monitorozása nagy méretekben – Azure Lighthouse.
Hibrid infrastruktúra operációs rendszer biztonsági naplói
A hibrid identitásinfrastruktúra operációsrendszer-naplóit 0. rétegbeli rendszerként kell archiválni és gondosan monitorozni, figyelembe véve a felületre gyakorolt hatásokat. Ide tartoznak az alábbiak:
AD FS-kiszolgálók és webes alkalmazásproxy
Microsoft Entra Connect
alkalmazásproxy ügynökök
Jelszóvisszaíró ügynökök
Password Protection Gateway-gépek
A Microsoft Entra többtényezős hitelesítési RADIUS-bővítményt tartalmazó NPS
A Microsoft Entra Connect Health-et minden környezet identitásszinkronizálásának és összevonásának figyeléséhez (ha van) telepíteni kell.
Naplótárolás megőrzése – Minden környezetnek egységes naplótárolási stratégiával, kialakítással és megvalósítással kell rendelkeznie, hogy egységes eszközkészletet (például SIEM-rendszereket, például az Azure Sentinelt), gyakori lekérdezéseket, nyomozásokat és kriminalisztikai forgatókönyveket biztosíthasson. Az Azure Policy használatával diagnosztikai beállítások állíthatók be.
Monitorozás és naplóellenőrzés – Az identitásfigyelés működési feladatainak konzisztensnek kell lenniük, és minden környezetben rendelkezniük kell tulajdonosokkal. A fentiekben leírtaknak megfelelően törekedjen arra, hogy ezeket a felelősségeket a jogszabályi megfelelőség és az elkülönítési követelmények által megengedett mértékben konszolidálja a környezetekben.
A következő forgatókönyveket explicit módon monitorozni és kivizsgálni kell:
Gyanús tevékenység – Minden Microsoft Entra-kockázati eseményt figyelni kell a gyanús tevékenységekre. Minden bérlőnek meg kell határoznia a hálózat által elnevezett helyeket , hogy elkerülje a zajos észlelést a helyalapú jeleken. Microsoft Entra ID-védelem natív módon integrálva van az Azure Security Centerrel. Javasoljuk, hogy minden kockázatészlelési vizsgálat tartalmazza az identitás által kiépített összes környezetet (például ha egy emberi identitás aktív kockázatészlelést végez a vállalati bérlőben, az ügyféllel szemben álló bérlőt üzemeltető csapatnak is meg kell vizsgálnia a megfelelő fiók tevékenységét az adott környezetben).
Felhasználói entitás viselkedéselemzési (UEBA) riasztásai – Az UEBA-t az anomáliadetektáláson alapuló megállapításalapú információk lekérésére kell használni. A Microsoft Microsoft 365 Felhőhöz készült Defender Apps UEBA-t biztosít a felhőben. Az ügyfelek integrálhatják a helyszíni UEBA-t a Microsoft Microsoft Microsoft 365 Defender for Identity szolgáltatásból. Az MCAS jeleket olvas Microsoft Entra ID-védelem.
Segélyhívási fiókok tevékenysége – A segélyhívási fiókokat használó összes hozzáférést figyelni kell, és riasztásokat kell létrehozni a vizsgálatokhoz. Ennek a figyelésnek a következőket kell tartalmaznia:
Bejelentkezések
Hitelesítő adatok kezelése
A csoporttagságok frissítései
Alkalmazás-hozzárendelések
Számlázási felügyeleti fiókok – Tekintettel az Azure EA-ban vagy MCA-ban számlázási felügyeleti szerepkörrel rendelkező fiókok bizalmasságára és jelentős jogosultságára, ajánlott figyelni és figyelmeztetni:
Bejelentkezési kísérletek számlázási szerepkörökkel rendelkező fiókok alapján.
Az EA Portaltól eltérő alkalmazások hitelesítésére tett kísérletek.
Az Azure Resource Managementen kívüli alkalmazások hitelesítésére tett kísérletek, ha dedikált fiókokat használnak az MCA számlázási feladataihoz.
Hozzárendelés Azure-erőforrásokhoz dedikált fiókok használatával az MCA számlázási feladataihoz.
Kiemelt szerepkör-tevékenység – A Microsoft Entra PIM által létrehozott biztonsági riasztások konfigurálása és áttekintése. Ha a közvetlen RBAC-hozzárendelések zárolása nem érvényesíthető teljes mértékben műszaki vezérlőkkel (például tulajdonosi szerepkört kell adni a termékcsapatoknak a munkájuk elvégzéséhez), akkor a PIM-en kívüli kiemelt szerepkörök közvetlen hozzárendelését figyelheti úgy, hogy riasztásokat hoz létre, amikor egy felhasználót közvetlenül rendelnek hozzá az előfizetéshez az Azure RBAC-vel való hozzáféréshez.
Klasszikus szerepkör-hozzárendelések – A szervezeteknek a klasszikus szerepkörök helyett a modern Azure RBAC szerepkör-infrastruktúrát kell használniuk. Ennek eredményeképpen a következő eseményeket kell figyelni:
- Hozzárendelés klasszikus szerepkörökhöz az előfizetés szintjén
Bérlőszintű konfigurációk – Minden bérlőszintű konfigurációs szolgáltatásnak riasztásokat kell létrehoznia a rendszerben.
Egyéni tartományok frissítése
Arculat frissítése
Microsoft Entra B2B engedélyezési/blokklista
Microsoft Entra B2B által engedélyezett identitásszolgáltatók (SAML-azonosítók közvetlen összevonással vagy közösségi bejelentkezésekkel)
A feltételes hozzáférési szabályzatok változásai
Alkalmazás- és egyszerű szolgáltatási objektumok
Új alkalmazások/ szolgáltatásnevek, amelyek feltételes hozzáférési szabályzatokat igényelhetnek
Alkalmazás-hozzájárulási tevékenység
Felügyeleti csoport tevékenysége – A felügyeleti csoportok alábbi identitási aspektusait kell figyelni:
RBAC-szerepkör-hozzárendelések az MG-ben
Az MG-ben alkalmazott Azure-szabályzatok
A MG-k között áthelyezett előfizetések
A gyökérszintű MG biztonsági szabályzatainak módosítása
Egyéni szerepkörök
Az egyéni szerepkördefiníciók frissítései
Új egyéni szerepkörök létrehozva
A feladatokra vonatkozó szabályok egyéni elkülönítése – Ha a szervezetei megállapították a vámszabályok elkülönítését, a Microsoft Entra Entitlement Management inkompatibilis hozzáférési csomagokkal kényszerítse ki a feladatok elkülönítését, és hozzon létre riasztásokat, vagy konfiguráljon rendszeres felülvizsgálatokat a rendszergazdák által elkövetett szabálysértések észleléséhez.
Egyéb figyelési szempontok – A Naplókezeléshez használt erőforrásokat tartalmazó Azure-előfizetéseket kritikus infrastruktúrának (0. szint) kell tekinteni, és le kell zárni a megfelelő környezet biztonsági üzemeltetési csapatához. Fontolja meg az olyan eszközök használatát, mint az Azure Policy, hogy további vezérlőket kényszerítsen ki ezekre az előfizetésekre.
Operatív eszközök
A környezetek közötti eszközkezelés tervezési szempontjai:
Amikor csak lehetséges, a több bérlőre kiterjedő üzemeltetési eszközöket úgy kell megtervezni, hogy Több-bérlős Microsoft Entra-alkalmazásként fussanak, hogy elkerüljék az egyes bérlők több példányának újbóli üzembe helyezését, és elkerüljék a működési hatékonyságot. Az implementációnak tartalmaznia kell az engedélyezési logikát annak biztosítása érdekében, hogy a felhasználók és az adatok elkülönítése megmaradjon.
Riasztások és észlelések hozzáadása a környezetek közötti automatizálás (például identitáskiépítés) és a hibabiztosítók küszöbértékeinek monitorozásához. Előfordulhat például, hogy riasztást szeretne kapni, ha a felhasználói fiókok kivonása egy adott szintet ér el, mivel ez egy olyan hibát vagy működési hibát jelezhet, amely széles körű hatással lehet.
A környezetek közötti feladatokat vezénylő automatizálásokat magas jogosultsági szintű rendszerként kell működtetni. Ezt a rendszert a legmagasabb biztonsági környezetnek kell otthont adni, és külső forrásokból kell lekérni, ha más környezetekből származó adatokra van szükség. A rendszer integritásának fenntartása érdekében adatérvényesítést és küszöbértékeket kell alkalmazni. A környezetek közötti gyakori feladat az identitás életciklusának kezelése, amely eltávolítja az identitásokat a leállított alkalmazottak összes környezetéből.
Informatikai szolgáltatásfelügyeleti eszközök – Az informatikai szolgáltatásfelügyeleti (ITSM) rendszereket, például a ServiceNow-t használó szervezeteknek konfigurálnia kell a Microsoft Entra PIM szerepkör-aktiválási beállításait , hogy az aktiválási célok részeként jegyszámot kérjenek.
Hasonlóképpen, az Azure Monitor integrálható az ITSM-rendszerekkel az IT Service Management Connectoron keresztül.
Üzemeltetési eljárások – Minimalizálja azokat az üzemeltetési tevékenységeket, amelyek közvetlen hozzáférést igényelnek a környezethez az emberi identitásokhoz. Ehelyett olyan Azure Pipelines-ként modellezi őket, amelyek közös műveleteket hajtanak végre (például kapacitást adnak hozzá egy PaaS-megoldáshoz, futtatnak diagnosztikát stb.), és közvetlen hozzáférést modelleznek az Azure Resource Manager-felületekhez az "üvegtörés" forgatókönyvekhez.
Üzemeltetési kihívások
A szolgáltatásnév monitorozásának tevékenysége bizonyos esetekben korlátozott
A Microsoft Entra PIM-riasztások nem rendelkeznek API-val. A kockázatcsökkentés az, hogy rendszeresen felülvizsgálják ezeket a PIM-riasztásokat.
Az Azure EA Portal nem biztosít monitorozási képességeket. A kockázatcsökkentéshez dedikált felügyeleti fiókokat kell használni, és figyelni kell a fióktevékenységet.
Az MCA nem biztosít naplózási naplókat a számlázási feladatokhoz. A kockázatcsökkentéshez dedikált felügyeleti fiókokat kell használni, és figyelni kell a fióktevékenységet.
Az Azure-ban a környezet üzemeltetéséhez szükséges egyes szolgáltatásokat újra kell üzembe helyezni és újra kell konfigurálni a környezetek között, mivel nem lehetnek több-bérlősek vagy többfelhősek.
Nincs teljes API-lefedettség a Microsoft Online Servicesben az infrastruktúra kódként való teljes eléréséhez. A kockázatcsökkentés az API-k lehető legnagyobb mértékű használata és a portálok használata a fennmaradó részre. Ez a nyílt forráskódú kezdeményezés segítséget nyújt a környezetében használható megközelítés meghatározásában.
Nem lehet programozott módon felderíteni azokat az erőforrás-bérlőket, amelyek delegált előfizetési hozzáféréssel rendelkeznek a felügyelt bérlő identitásaihoz. Ha például egy e-mail-cím engedélyezte a contoso.com-bérlő biztonsági csoportjának a fabrikam.com-bérlőben lévő előfizetések kezelését, a contoso.com rendszergazdái nem rendelkeznek API-val a delegálás megtörténtének felderítéséhez.
Az adott fióktevékenység-figyelés (például üvegtöréses fiók, számlázási felügyeleti fiók) nem szerepel a mezőben. A kockázatcsökkentés célja, hogy az ügyfelek saját riasztási szabályokat hozzanak létre.
A bérlőszintű konfigurációfigyelés nem szerepel a mezőben. A kockázatcsökkentés célja, hogy az ügyfelek saját riasztási szabályokat hozzanak létre.