Alkalmazásdentitás és hozzáférés-kezelés

  • Cikk

Ez a cikk azokat a szempontokat és javaslatokat ismerteti, amelyekkel az alkalmazástulajdonosok és a fejlesztők megtervezhetik a natív felhőbeli alkalmazások identitás- és hozzáférés-kezelését.

Ha a csapat natív felhőbeli alkalmazásokat migrál vagy hoz létre, figyelembe kell vennie az alkalmazások hitelesítési és hozzáférési követelményeit. Ezek a követelmények határozzák meg, hogyan hitelesítik a felhasználók az alkalmazásokat, és hogyan hitelesítik egymást az alkalmazáserőforrások, például amikor egy webalkalmazás hozzáfér egy SQL-adatbázishoz.

A platformautomatizálás és a DevOps tervezési területén azt javasoljuk, hogy az alkalmazáscsapat áttérjen a számítási feladatokra előfizetéses értékesítés. Az előfizetés-feldolgozási folyamat részeként az alkalmazáscsapatnak identitás- és hozzáférési követelményeket kell biztosítania a platformcsapat számára, hogy létrehozhassák a megfelelő előfizetéseket. Az egyes alkalmazások identitás- és hozzáférés-kezeléséért az alkalmazástulajdonosok felelősek. Az alkalmazásukat a platformcsapat által biztosított központosított szolgáltatásokkal kell kezelniük.

Kialakítási szempontok

Az alkalmazásokhoz való jogosulatlan hozzáférés kockázatának csökkentése érdekében foglalja bele a következő szempontokat a tervezésbe.

  • Számos hitelesítési és engedélyezési szabvány létezik, például az OAuth 2.0, az OpenID Csatlakozás, a JSON webes jogkivonatok (JWT-k) és az SAML (Security Assertion Markup Language). Határozza meg az alkalmazáshoz használandó hitelesítési és engedélyezési szabványokat .

  • Amikor alkalmazás-kezdőzónát kér a platformcsapattól, a következő kérdések feltevésével biztosíthatja, hogy a megfelelő előfizetéseket hozzák létre:

    • Hogyan hitelesítik és érik el a végfelhasználók az alkalmazást?

    • Kinek van szüksége szerepköralapú hozzáférés-vezérlési (RBAC) engedélyekre az alkalmazás által használt erőforrásokhoz és szolgáltatásokhoz?

    • A meglévő beépített szerepkörök lefedik a vezérlősík és az adatsík-hozzáférés RBAC-hozzáférési követelményeit, vagy új egyéni szerepköröket kell létrehoznia?

    • Implementálták a platformcsapat olyan megfelelőségi szabályzatokat, amelyek problémákat okozhatnak az alkalmazással kapcsolatban?

    • Mely alkalmazásösszetevőknek kell kommunikálniuk egymással?

    • Vannak olyan követelmények a platform kezdőzónájában üzembe helyezett megosztott erőforrásokhoz, például a Microsoft Entra Domain Serviceshez való hozzáféréshez?

Azure Key Vault és felügyelt identitások

  • A nyilvános felhőbeli erőforrások biztonsági megsértései gyakran kódba vagy más szövegbe ágyazott kiszivárgott hitelesítő adatokból erednek. A felügyelt identitások és a Key Vault használatával programozott hozzáférést valósíthat meg, és csökkentheti a hitelesítő adatok ellopásának kockázatát.

  • Ha az alkalmazáshoz vagy számítási feladathoz szolgáltatásra van szükség a hitelesítő adatok biztonságos tárolásához, a Key Vault használatával kezelheti a titkos kulcsokat, kulcsokat és tanúsítványokat.

  • Annak érdekében, hogy ne legyenek hitelesítő adatok a kódban, felügyelt identitásokat használhat azure-beli virtuális gépekkel a Microsoft Entra ID-hitelesítést támogató bármely szolgáltatásban való hitelesítéshez. További információ: Felügyelt identitások használata Azure-erőforrásokhoz virtuális gépen hozzáférési jogkivonat beszerzéséhez.

  • A felügyelt identitások automatikusan felügyelt identitásnevet biztosítanak, amelyet az alkalmazások és az erőforrások a Microsoft Entra ID-hitelesítést támogató erőforrásokhoz való csatlakozáskor használnak. Az alkalmazások felügyelt identitásokkal szerezhetik be a Microsoft Entra-azonosító jogkivonatokat anélkül, hogy hitelesítő adatokat kellene kezelni.

    • Használhat rendszer által hozzárendelt vagy felhasználó által hozzárendelt felügyelt identitásokat.

    • Könnyen összetéveszthető, hogy a szolgáltatásnevek és a felügyelt identitások hogyan férnek hozzá az Azure-erőforrásokhoz. A kettő közötti különbség megértéséhez lásd : Szolgáltatásnevek – Felügyelt identitások demystifying service principals.

    • Ahol lehetséges, a szolgáltatásnevek és a Microsoft Entra ID-alkalmazásregisztrációk használata helyett használjon felügyelt identitásokat a hitelesítés támogatására. Szolgáltatásnevek és alkalmazásregisztrációk létrehozásához rendelkeznie kell az Alkalmazás Rendszergazda istrator vagy az Alkalmazásfejlesztő RBAC szerepkörével. Ezek a kiemelt szerepkörök általában a platformcsapathoz vagy identitáscsoporthoz vannak rendelve. Felügyelt identitások használatával kiküszöbölheti, hogy a platformcsapat szolgáltatásnevek és alkalmazásregisztrációk létrehozására legyen szükség az alkalmazáscsapat számára.

    • Felügyelt identitásokkal hitelesíthet bármely olyan szolgáltatásban, amely támogatja a Microsoft Entra-hitelesítést. Azonban nem minden szolgáltatás támogatja a felügyelt identitásokat más szolgáltatások eléréséhez. Egyes szolgáltatások esetében szükség lehet a hitelesítő adatok tárolására. Biztonságosan kell tárolnia a hitelesítő adatokat, el kell kerülnie a hitelesítő adatok más szolgáltatásokkal való megosztását, és követnie kell a minimális jogosultság elvét. További információ: Azure-szolgáltatások, amelyek felügyelt identitásokkal férhetnek hozzá más szolgáltatásokhoz.

    • Felügyelt identitásokat használhat Azure-beli virtuális gépekkel (VM-ekkel) a Microsoft Entra ID-hitelesítést támogató bármely szolgáltatásban való hitelesítéshez. További információ: Felügyelt identitások használata Azure-erőforrásokhoz virtuális gépen hozzáférési jogkivonat beszerzéséhez.

    • Az előfizetések és régiók közötti felügyelt identitásokkal rendelkező erőforrások áthelyezésére korlátozások vonatkoznak. Előfordulhat például, hogy adatelkülönítési okokból áthelyezi az erőforrásokat az előfizetések vagy régiók között az erőforrások összevonása, beszerzése vagy újratelepítése céljából.

      Ha egy Azure-erőforrás felhasználó által hozzárendelt vagy rendszer által hozzárendelt identitásokkal rendelkezik, nem adhatja át az erőforrást egy másik Azure-előfizetésbe vagy régióba. Az erőforrás áthelyezése előtt törölnie kell a felügyelt identitásokat. Az áthelyezés után újra létre kell hoznia a felügyelt identitásokat, és hozzá kell rendelnie őket az erőforráshoz. További információ: Erőforrások áthelyezése új erőforráscsoportba vagy előfizetésbe.

    • Ha egy előfizetést egyik könyvtárból a másikba helyez át, a felügyelt identitások nem maradnak meg. Át kell helyeznie az erőforrást, majd manuálisan újra létre kell hoznia a felügyelt identitásokat.

    • A felhasználói RBAC-szerepkör-hozzárendelésekhez hasonlóan kövesse a minimális jogosultság elvét, amikor felügyelt identitáshoz biztosít hozzáférést egy erőforráshoz.

Külső felhasználók

Kiértékelheti a külső felhasználók, ügyfelek vagy partnerek beállításával járó forgatókönyveket, hogy hozzáférhessenek az erőforrásokhoz. Annak meghatározása, hogy ezek a forgatókönyvek a Microsoft Entra B2B vagy az Azure Active Directory B2C (Azure AD B2C) konfigurációit foglalják-e magukban. További információ: Microsoft Entra Külső ID áttekintése.

Tervezési javaslatok

Az alkalmazások identitás- és hozzáférés-kezelésének tervezésekor vegye figyelembe az alábbi javaslatokat.

OpenID Connect

Ha az alkalmazáscsapat folyamatos integrációs és folyamatos kézbesítési (CI/CD) folyamatokat használ az alkalmazások programozott üzembe helyezéséhez, konfigurálja az OpenID Csatlakozás hitelesítést az Azure-szolgáltatásokban. Az OpenID Csatlakozás egy ideiglenes, hitelesítő adatok nélküli jogkivonatot használ az Azure-szolgáltatásokban való hitelesítéshez. További információ: Számítási feladatok identitásának összevonása.

Ha az OpenID Csatlakozás nem támogatott, hozzon létre egy szolgáltatásnevet, és rendelje hozzá a szükséges engedélyeket az infrastruktúra vagy az alkalmazáskód üzembe helyezéséhez. További információkért tekintse meg az Azure üzembehelyezési folyamat hitelesítése szolgáltatásnevek használatával című képzési modult.

Attribútumalapú hozzáférés-vezérlés

A hozzáférés további korlátozásához és az adatokhoz való jogosulatlan hozzáférés megakadályozásához használjon attribútumalapú hozzáférés-vezérlést (ABAC), ahol támogatott például az Azure Blob Storage.

Virtuális gépekhez való hozzáférés

Ahol lehetséges, a Microsoft Entra ID-identitásokkal szabályozhatja az Azure-beli virtuális gépekhez való hozzáférést. Használja a Microsoft Entra-azonosítót a helyi hitelesítés helyett a virtuális gépekhez való hozzáférés biztosításához, kihasználva a Microsoft Entra feltételes hozzáférését, a naplózást és a Microsoft Entra többtényezős hitelesítést (MFA). Ez a konfiguráció csökkenti annak a kockázatát, hogy a támadók kihasználják a nem biztonságos helyi hitelesítési szolgáltatásokat. További információ: Bejelentkezés Linux rendszerű virtuális gépre az Azure-ban a Microsoft Entra ID és az OpenSSH használatával, valamint bejelentkezés windowsos virtuális gépre az Azure-ban a Microsoft Entra-azonosítóval, beleértve a jelszó nélkülit is.

Microsoft-identitásplatform

  • Ha a fejlesztők natív felhőbeli alkalmazást építenek, a Microsoft Identitásplatform fejlesztőknek kell használniuk az alkalmazások identitásszolgáltatójaként. A Microsoft Identitásplatform egy OpenID Csatlakozás szabványnak megfelelő hitelesítési szolgáltatást biztosít, amellyel a fejlesztők számos identitástípust hitelesíthetnek, például:

    • Munkahelyi vagy iskolai fiókok a Microsoft Entra-azonosítón keresztül kiépítve

    • Személyes Microsoft-fiókok (Skype, Xbox, Outlook.com)

    • Közösségi vagy helyi fiókok a Microsoft Entra ID használatával

  • Az Microsoft Identitásplatform ajánlott eljárások és javaslatok ellenőrzőlistája útmutatást nyújt az alkalmazás és a Microsoft Identitásplatform hatékony integrálásához.

Felügyelt identitások

  • A hitelesítő adatok használatához nem szükséges Azure-erőforrások közötti hozzáférés engedélyezéséhez használjon felügyelt identitásokat.

  • Nem szabad megosztania a hitelesítő adatokat vagy a felügyelt identitásokat a különböző környezetek vagy alkalmazások között. Például ne használjon identitásokat éles erőforrásokhoz és fejlesztői/tesztelési erőforrásokhoz, még ugyanahhoz az alkalmazáshoz sem. Hozzon létre külön hitelesítő adatokat egy alkalmazás minden példányához, hogy csökkentse az éles adatokat érintő sérült tesztpéldányok valószínűségét. A különálló hitelesítő adatok megkönnyítik a hitelesítő adatok visszavonását is, ha már nincs rájuk szükség.

  • Ha követelmény a felügyelt identitások nagy léptékű használata, minden régióban használjon felhasználó által hozzárendelt felügyelt identitást minden erőforrástípushoz. Ez a módszer megakadályozza az identitások változását. Az Azure Monitor Agent például felügyelt identitást igényel a figyelt Azure-beli virtuális gépeken, ami miatt a Microsoft Entra-azonosító jelentős számú identitást hozhat létre (és törölhet). Létrehozhat egy felhasználó által hozzárendelt felügyelt identitást, és megoszthatja őket több virtuális gépen. Az Azure Policy használatával implementálhatja ezt a javaslatot.

Key Vault

  • A Key Vault használatával kezelheti az alkalmazások által használt titkos kulcsokat, kulcsokat és tanúsítványokat.

  • Minden régióban külön kulcstartókat kell használnia az egyes alkalmazáskörnyezetekhez (fejlesztés, előkészítés, éles környezet). Az RBAC használatával kezelheti a titkos kulcsokhoz, kulcsokhoz és tanúsítványokhoz (adatsík-műveletekhez) való hozzáférést, valamint a Key Vaulthoz (vezérlősíkhoz) való hozzáférést. Helyezzen üzembe olyan kulcstartókat, amelyek alkalmazáskulcsokkal rendelkeznek az alkalmazás kezdőzónáiban.

Microsoft Entra alkalmazásproxy

  • A helyszíni hitelesítést távolról, Microsoft Entra-azonosítón keresztül használó alkalmazások eléréséhez használja a Microsoft Entra alkalmazásproxyt. A Microsoft Entra alkalmazásproxy biztonságos távoli hozzáférést biztosít a helyszíni webalkalmazásokhoz, beleértve a régebbi hitelesítési protokollokat használó alkalmazásokat is. A Microsoft Entra-azonosítóra való egyszeri bejelentkezés után a felhasználók külső URL-címen vagy belső alkalmazásportálon keresztül is hozzáférhetnek a felhőbeli és a helyszíni alkalmazásokhoz.

    • A Microsoft Entra alkalmazásproxyt egyetlen példányként helyezheti üzembe a Microsoft Entra ID-bérlőben. A konfigurációhoz az application Rendszergazda istrator vagy a Global Rendszergazda istrator privileged Microsoft Entra ID szerepkör szükséges. Ha a szervezet az előfizetés demokratizálását használja szerepkör-hozzárendelési modellként, előfordulhat, hogy az alkalmazástulajdonosok nem rendelkeznek a Microsoft Entra alkalmazásproxy konfigurálásához szükséges engedélyekkel. Ebben az esetben a platformcsapatnak konfigurálnia kell a Microsoft Entra alkalmazásproxyt az alkalmazás tulajdonosához.

    • Ha megfelelő engedélyekkel rendelkező CI/CD üzembehelyezési folyamatokat használ, az alkalmazástulajdonosok a Microsoft Graph API használatával konfigurálhatják a Microsoft Entra alkalmazásproxyt.

  • Ha az alkalmazás örökölt protokollokat , például Kerberost használ, győződjön meg arról, hogy az alkalmazás kezdőzónája hálózati kapcsolatot létesít a Microsoft Identitásplatform-előfizetés tartományvezérlőivel.

Következő lépések

Erőforrás-szervezet