2. rész: A hitelesítési igények ebben a példaforgatókönyvben

Előző rész: Bevezetés és háttér

Ebben a példában a fő alkalmazásnak három különböző hitelesítési követelménye van:

• Azure Key Vault

  Az alkalmazásnak hitelesítenie kell Azure Key Vault egy külső szolgáltatás meghívásához szükséges biztonságosan tárolt API-kulcs lekéréséhez.

• Harmadik féltől származó API

  Miután az alkalmazás lekérte az API-kulcsot, a kulcsot használja a külső külső API-val való hitelesítéshez.

• Azure Queue Storage

  A kérés feldolgozása után az alkalmazásnak hitelesítenie kell magát az Azure Queue Storage-ral, hogy üzenetet küldjön az aszinkron vagy halasztott feldolgozáshoz.

Ezekhez a feladatokhoz az alkalmazásnak három hitelesítőadat-készletet kell kezelnie:

• Két készlet Azure erőforrásokhoz (Key Vault és storage)

• Egy készlet egy külső szolgáltatás (harmadik féltől származó API) számára

A fő hitelesítési kihívások

A biztonságos felhőalkalmazások létrehozásához körültekintően kell kezelni a hitelesítő adatokat, különösen akkor, ha több szolgáltatásról van szó. Ez a példaforgatókönyv számos kritikus kihívást jelent:

• Körkörös függőség a Key Vaultnál

  Az alkalmazás az Azure Key Vault használatával biztonságosan tárol titkos kulcsokat, például külső API-kulcsokat vagy Azure Storage-hitelesítő adatokat. A titkos kulcsok lekéréséhez azonban az alkalmazásnak először hitelesítenie kell magát a Key Vaulttal. Ez a helyzet körkörös problémát okoz: Az alkalmazásnak hitelesítő adatokra van szüksége a Key Vault eléréséhez, de ezeket a hitelesítő adatokat biztonságosan kell tárolnia. Biztonságos megoldás nélkül ez a probléma merevlemezes hitelesítő adatokhoz vagy nem biztonságos konfigurációkhoz vezethet a fejlesztési környezetekben.

• Külső API-kulcsok biztonságos kezelése

  Miután lekérte az API-kulcsot a Key Vaultból, az alkalmazásnak azt kell használnia egy külső szolgáltatás meghívásához. Kezelje ezt a kulcsot rendkívül körültekintően:

  • Soha ne kódolja a forráskódban vagy konfigurációs fájlokban
  • Soha ne jelentkezzen be stdout, stderr vagy alkalmazásnaplókba
  • Csak a memóriában tárolja, és futásidőben, közvetlenül a használat előtt férjen hozzá
  • A kérés befejezése után azonnal törölje.

  Ezen eljárások elmulasztása növeli a hitelesítő adatok szivárgásának vagy jogosulatlan használatának kockázatát.

• Az Azure Queue Storage hitelesítő adatainak védelme

  Ha üzeneteket szeretne írni az Azure Queue Storage-ba, az alkalmazásnak általában kapcsolati sztringre vagy megosztott hozzáférési jogkivonatra van szüksége. Ezek a hitelesítő adatok:

  • Biztonságos helyen kell tárolni, például a Key Vaultban
  • Nem jelenhet meg naplókban, veremnyomokban vagy fejlesztői eszközökben
  • Csak biztonságos futtatókörnyezeti mechanizmusokkal lehet hozzáférni
  • Megfelelő RBAC-konfiguráció megkövetelése felügyelt identitás használata esetén

• Környezet rugalmassága

  Az alkalmazásnak megbízhatóan kell futnia mind a helyi fejlesztési, mind a felhőalapú éles környezetben ugyanazzal a kódbázissal és minimális feltételes logikával.

  Ez a követelmény a következőt jelenti:

  • Ne ágyazza be a környezetspecifikus titkos kulcsokat a kódba
  • Ne kapcsolgassa kézzel a hitelesítő adatokat vagy a logikai ágakat
  • Identitásalapú hitelesítés használata konzisztensen a környezetekben

Elsődlegesen Azure-ra épülő hitelesítés Microsoft Entra ID-val

Ahogy a felhőalkalmazások összetettebbé válnak, és több szolgáltatással integrálhatók, a biztonságos és egyszerűsített hitelesítés elengedhetetlenné válik. Azure egy Azure-első identitásmodellt kínál Microsoft Entra ID keresztül, amely egységes identitáskezelést és zökkenőmentes integrációt tesz lehetővé Azure szolgáltatásokkal a biztonságos, hitelesítő adatok nélküli hitelesítés érdekében.

A titkos kódok manuális kezelése vagy a hitelesítő adatok alkalmazáskódba való beágyazása helyett – ez a biztonsági kockázatokra hajlamos gyakorlat – Microsoft Entra ID lehetővé teszi az alkalmazások számára a biztonságos hitelesítést felügyelt identitások használatával.

A Microsoft Entra által felügyelt identitások fő előnyei a következők:

• Nincsenek titkos kódok a kódban

  Az alkalmazások már nem igényelnek rögzített kapcsolati sztringeket, ügyfélkulcsokat vagy kulcsokat.

• Beépített identitás alkalmazásokhoz

  Azure automatikusan hozzárendelhet egy felügyelt identitást az alkalmazáshoz, így további hitelesítő adatok nélkül is biztonságosan elérheti az olyan szolgáltatásokat, mint a Key Vault, a Storage és az SQL.

• Környezeti konzisztencia

  Ugyanez a kód- és identitásmodell a helyi fejlesztési és Azure üzemeltetett környezetekben is működik a Azure SDK DefaultAzureCredentialhasználatával.

Környezetspecifikus identitásfolyamat

A Microsoft Entra ID-t hitelesítéshez használó alkalmazások egy rugalmas identitásmodell előnyeit élvezhetik, amely zökkenőmentesen működik az Azure-ban üzemeltetett és a helyi fejlesztési környezetekben is. A Azure SDK DefaultAzureCredential ezt a konzisztenciát úgy biztosítják, hogy a környezet alapján automatikusan kiválasztja a megfelelő identitásmetódust.

Azure-környezet

Amikor üzembe helyezi az alkalmazást a Azure:

• Az alkalmazás automatikusan kap egy felügyelt identitást.
• Azure a jogkivonatok kiállítását és a hitelesítő adatok életciklusát belsőleg kezeli, így nem kell titkos kulcsokat kezelnie.
• Az alkalmazás Role-Based Access Control (RBAC) vagy Key Vault hozzáférési szabályzatok használatával fér hozzá a szolgáltatásokhoz.

Helyi fejlesztőkörnyezet

A helyi fejlesztés során:

• A szolgáltatásnév az alkalmazás identitásaként szolgál.
• A fejlesztők a Azure CLI (az login), környezeti változókkal vagy Visual Studio/VS Code-integrációkkal hitelesítik magukat.
• Ugyanaz az alkalmazáskód módosítás nélkül fut – csak az identitásforrás módosul.

Mindkét környezetben az Azure SDK-k a DefaultAzureCredential használják, amely elrejti az identitás forrását, és automatikusan kiválasztja a megfelelő módszert.

Ajánlott eljárások a biztonságos fejlesztéshez

Bár a titkos kulcsokat környezeti változókként állíthatja be (például Azure-alkalmazás Beállításokon keresztül), ennek a megközelítésnek hátrányai vannak:

• A titkos kulcsokat manuálisan kell replikálnia helyi környezetekben.
• Fennáll annak a kockázata, hogy titkos kódok szivárognak be a forráskezelésbe.
• A környezetek megkülönböztetéséhez további logikára lehet szükség.

Ehelyett használja a következő megközelítést:

• A Key Vault használatával külső API-kulcsokat és más titkos kulcsokat tárolhat.
• Felügyelt identitás hozzárendelése az üzembe helyezett alkalmazáshoz.
• Használjon szolgáltatásnév a helyi fejlesztéshez, és adja meg neki ugyanazokat a hozzáférési jogosultságokat.
• A DefaultAzureCredential kódban használva absztrakt hitelesítési logikát használhat.
• Kerülje a hitelesítő adatok tárolását vagy naplózását.

Hitelesítési folyamat a gyakorlatban

A hitelesítés működése a futtatókörnyezetben a következőképpen működik:

• A kód létrehoz egy DefaultAzureCredential példányt.
• Ezzel a hitelesítő adattal példányosíthat egy klienst (például SecretClient, QueueServiceClient).
• Amikor az alkalmazás meghív egy metódust (például get_secret()), az ügyfél a hitelesítő adatok használatával hitelesíti a kérést.
• Az Azure ellenőrzi az identitást, és ellenőrzi, hogy rendelkezik-e a megfelelő szerepkörsel vagy szabályzattal a művelet végrehajtásához.

Ez a folyamat biztosítja, hogy az alkalmazás biztonságosan hozzáférhessen az Azure-szolgáltatásokhoz anélkül, hogy titkos kódokat vagy konfigurációs fájlokat ágyazhat be. Emellett zökkenőmentes váltást tesz lehetővé a helyi fejlesztés és a felhőbeli üzembe helyezés között a hitelesítési logika módosítása nélkül.

3. rész – Külső API-implementáció >>>