.NET-alkalmazások hitelesítése Azure-szolgáltatásokba a .NET Azure SDK használatával

Ha egy alkalmazásnak hozzá kell férnie egy Azure-erőforráshoz, például a tárolóhoz, a kulcstartóhoz vagy a kognitív szolgáltatásokhoz, az alkalmazást hitelesíteni kell az Azure-ban. Ez minden alkalmazásra igaz, legyen szó az Azure-ban üzembe helyezett, a helyszínen üzembe helyezett vagy a helyi fejlesztői munkaállomáson végzett fejlesztés alatt álló alkalmazásokról. Ez a cikk azokat a módszereket ismerteti, hogyan hitelesíthet egy alkalmazást az Azure-ban az Azure SDK for .NET használatakor.

Az Azure-erőforrásokhoz való hitelesítéskor ajánlott, hogy az alkalmazások jogkivonatalapú hitelesítést használjanak ahelyett, hogy kapcsolati sztring. A .NET-hez készült Azure SDK olyan osztályokat biztosít, amelyek támogatják a jogkivonatalapú hitelesítést, és lehetővé teszik az alkalmazások számára, hogy zökkenőmentesen hitelesítsék magukat az Azure-erőforrásokon, függetlenül attól, hogy az alkalmazás helyi fejlesztés alatt áll, üzembe van helyezve az Azure-ban vagy egy helyszíni kiszolgálón.

A jogkivonat-alapú hitelesítés adott típusa, amelyet az alkalmazásnak az Azure-erőforrásokon való hitelesítéshez kell használnia, attól függ, hogy hol fut az alkalmazás, és az alábbi ábrán látható.

Egy alkalmazás ajánlott jogkivonatalapú hitelesítési stratégiáit bemutató diagram attól függően, hogy hol fut.

  • Ha egy fejlesztő helyi fejlesztés során futtat egy alkalmazást – Az alkalmazás hitelesítést végezhet az Azure-ban egy alkalmazásszolgáltatásnév használatával a helyi fejlesztéshez, vagy a fejlesztő Azure-beli hitelesítő adatainak használatával. Ezekről a lehetőségekről részletesebben a helyi fejlesztés során történő hitelesítés szakaszában olvashat.
  • Ha egy alkalmazást az Azure-ban üzemeltetnek – Az alkalmazásnak felügyelt identitással kell hitelesítenie az Azure-erőforrásokat. Ezt a lehetőséget az alábbiakban a kiszolgálói környezetekben történő hitelesítés szakaszában ismertetjük részletesebben.
  • Amikor egy alkalmazást üzemeltetnek és üzembe helyeznek a helyszínen , az alkalmazásnak hitelesítenie kell magát az Azure-erőforrásokban egy alkalmazásszolgáltatás-tag használatával. Ezt a lehetőséget az alábbiakban a kiszolgálói környezetekben történő hitelesítés szakaszában ismertetjük részletesebben.

DefaultAzureCredential

Az DefaultAzureCredential Azure SDK által biztosított osztály lehetővé teszi, hogy az alkalmazások a futtatott környezettől függően különböző hitelesítési módszereket használjanak. Ez lehetővé teszi az alkalmazások előléptetését a helyi fejlesztéstől a környezetek tesztelése az éles környezetekig kódmódosítások nélkül. Konfigurálja a megfelelő hitelesítési módszert az egyes környezetekhez, és DefaultAzureCredential automatikusan észleli és használja ezt a hitelesítési módszert. A feltételes logika vagy a funkciójelzők manuális kódolása DefaultAzureCredential helyett előnyben kell részesíteni a különböző hitelesítési módszerek használatát különböző környezetekben.

Az osztály használatával DefaultAzureCredential kapcsolatos részletekről a cikk későbbi részében, a Használat DefaultAzureCredential egy alkalmazásban című szakaszban olvashat.

A jogkivonatalapú hitelesítés előnyei

Az Azure-hoz készült alkalmazások létrehozásakor erősen ajánlott a jogkivonatalapú hitelesítés kapcsolati sztring használata esetén. A jogkivonatalapú hitelesítés a következő előnyöket nyújtja a kapcsolati sztring hitelesítésével szemben.

  • Az alábbiakban ismertetett jogkivonatalapú hitelesítési módszerek lehetővé teszik az alkalmazás által az Azure-erőforráson szükséges konkrét engedélyek létrehozását. Ez a minimális jogosultság elvét követi. Ezzel szemben egy kapcsolati sztring teljes jogokat biztosít az Azure-erőforrás számára.
  • Míg bárki vagy bármely kapcsolati sztring rendelkező alkalmazás csatlakozhat egy Azure-erőforráshoz, a jogkivonatalapú hitelesítési módszerek csak az erőforrás eléréséhez használni kívánt alkalmazás(ok)hoz férhetnek hozzá az erőforráshoz.
  • Felügyelt identitás esetén nincs tárolandó alkalmazáskulcs. Ez biztonságosabbá teszi az alkalmazást, mert nincs kapcsolati sztring vagy alkalmazás titkos kódja, mint ami feltörhető.
  • Az Azure SDK Azure.Identity csomagja a színfalak mögött kezeli a jogkivonatokat. Ez megkönnyíti a jogkivonatalapú hitelesítés használatát kapcsolati sztring.

A kapcsolati sztring használatát a koncepcióalkalmazások vagy fejlesztési prototípusok kezdeti ellenőrzésére kell korlátozni, amelyek nem férnek hozzá éles vagy bizalmas adatokhoz. Ellenkező esetben az Azure SDK-ban elérhető jogkivonatalapú hitelesítési osztályokat mindig előnyben kell részesíteni az Azure-erőforrásokhoz való hitelesítéskor.

Hitelesítés kiszolgálói környezetekben

Kiszolgálói környezetben való üzemeltetéskor minden alkalmazáshoz egyedi alkalmazásidentitást kell hozzárendelni az alkalmazás által futtatott környezetenként. Az Azure-ban az alkalmazásidentitást egy szolgáltatásnév képviseli, amely egy speciális biztonsági egyszerű típus, amelynek célja az alkalmazások azonosítása és hitelesítése az Azure-ban. Az alkalmazáshoz használandó szolgáltatásnév típusa attól függ, hogy az alkalmazás hol fut.

Hitelesítési módszer Leírás
Az Azure-ban üzemeltetett alkalmazások Az Azure-ban üzemeltetett alkalmazásoknak felügyelt identitásszolgáltatásnevet kell használniuk. A felügyelt identitások az Azure-ban üzemeltetett alkalmazások identitását képviselik, és csak az Azure által üzemeltetett alkalmazásokkal használhatók.

A Azure-alkalmazás Szolgáltatásban üzemeltetett .NET-webalkalmazáshoz például felügyelt identitás lesz hozzárendelve. Az alkalmazáshoz rendelt felügyelt identitás ezután az alkalmazás más Azure-szolgáltatásokban való hitelesítésére szolgál.

Az Azure-on kívül üzemeltetett alkalmazások
(például helyszíni alkalmazások)
Az Azure-on kívül üzemeltetett alkalmazásoknak (például helyszíni alkalmazásoknak), amelyeknek csatlakozniuk kell az Azure-szolgáltatásokhoz, egy alkalmazásszolgáltatásnevet kell használniuk. Az application service principal az alkalmazás identitását jelöli az Azure-ban, és az alkalmazásregisztrációs folyamaton keresztül jön létre.

Vegyük például az Azure Blob Storage-t használó helyszíni .NET-webalkalmazást. Az alkalmazásregisztrációs folyamattal létrehozna egy alkalmazásszolgáltatásnevet az alkalmazáshoz. A AZURE_CLIENT_ID, AZURE_TENANT_IDés AZURE_CLIENT_SECRET mind környezeti változókként lesz tárolva, amelyeket az alkalmazás futásidőben olvas be, és lehetővé teszi az alkalmazás számára az Azure-ban való hitelesítést az Application service principal használatával.

Hitelesítés a helyi fejlesztés során

Ha egy alkalmazás egy fejlesztői munkaállomáson fut a helyi fejlesztés során, akkor is hitelesítenie kell az alkalmazás által használt Azure-szolgáltatásokban. Az alkalmazások Azure-ba történő hitelesítésének két fő stratégiája a helyi fejlesztés során:

Hitelesítési módszer Leírás
A helyi fejlesztés során használandó dedikált alkalmazásszolgáltatás-egyszerű objektumok létrehozása Ebben a módszerben a dedikált alkalmazásszolgáltatás-egyszerű objektumok az alkalmazásregisztrációs folyamat használatával vannak beállítva a helyi fejlesztés során való használatra. A szolgáltatásnév identitása ezután környezeti változókként lesz tárolva, amelyeket az alkalmazás a helyi fejlesztésben való futtatáskor érhet el.

Ez a módszer lehetővé teszi az alkalmazás által igényelt erőforrás-engedélyek hozzárendelését a fejlesztők által a helyi fejlesztés során használt egyszerű szolgáltatásobjektumokhoz. Ez biztosítja, hogy az alkalmazás csak azokhoz az erőforrásokhoz férhessen hozzá, amelyekre szüksége van, és replikálja azokat az engedélyeket, amelyeket az alkalmazás éles környezetben fog biztosítani.

Ennek a megközelítésnek a hátránya, hogy külön szolgáltatásnév-objektumokat kell létrehozni minden olyan fejlesztő számára, aki egy alkalmazáson dolgozik.

Az alkalmazás hitelesítése az Azure-ba a fejlesztő hitelesítő adataival a helyi fejlesztés során Ebben a módszerben a fejlesztőknek be kell jelentkezniük az Azure-ba a Visual Studióból, a VS Code Azure Tools-bővítményéből, az Azure CLI-ből vagy az Azure PowerShellből a helyi munkaállomásukon. Az alkalmazás ezután hozzáférhet a fejlesztői hitelesítő adatokhoz a hitelesítőadat-tárolóból, és ezekkel a hitelesítő adatokkal elérheti az Azure-erőforrásokat az alkalmazásból.

Ez a módszer a könnyebb beállítás előnye, mivel egy fejlesztőnek csak a Visual Studióból, a VS Code-ból vagy az Azure CLI-ből kell bejelentkeznie az Azure-fiókjába. Ennek a módszernek a hátránya, hogy a fejlesztő fiókja valószínűleg több engedéllyel rendelkezik, mint amennyit az alkalmazás igényel. Ezért ez a megközelítés nem replikálja pontosan azokat az engedélyeket, amellyel az alkalmazás éles környezetben fog futni.

DefaultAzureCredential használata egy alkalmazásban

DefaultAzureCredential több hitelesítési módszert támogat, és meghatározza a futtatókörnyezetben használt hitelesítési módszert. Ily módon az alkalmazás különböző hitelesítési módszereket használhat különböző környezetekben, környezetspecifikus kód implementálása nélkül.

A hitelesítő adatokat kereső sorrend és helyek DefaultAzureCredential a DefaultAzureCredential helyen találhatók.

A megvalósításhoz DefaultAzureCredentialelőször adja hozzá a Azure.Identity csomagokat, és igény szerint adja hozzá az Microsoft.Extensions.Azure alkalmazáshoz. Ezt a parancssor vagy a NuGet Csomagkezelő használatával teheti meg.

Nyisson meg egy tetszőleges terminálkörnyezetet az alkalmazásprojekt könyvtárában, és írja be az alábbi parancsot.

dotnet add package Azure.Identity
dotnet add package Microsoft.Extensions.Azure

Az Azure-szolgáltatásokat általában az SDK megfelelő ügyfélosztályai használják. Ezeket az osztályokat és a saját egyéni szolgáltatásokat regisztrálni kell a Program.cs fájlban, hogy az alkalmazás függőséginjektálásával elérhetőek legyenek. Program.csBelül kövesse az alábbi lépéseket a szolgáltatás és a .DefaultAzureCredential

  1. Adja meg a névtereket és Microsoft.Extensions.Azure a Azure.Identity névtereket egy felhasználói utasítással.
  2. Regisztrálja az Azure-szolgáltatást a megfelelő segítő módszerek használatával.
  3. Adja át az objektum egy példányát DefaultAzureCredential a UseCredential metódusnak.

Erre példa a következő kódszakaszban látható.

using Microsoft.Extensions.Azure;
using Azure.Identity;

// Inside of Program.cs
builder.Services.AddAzureClients(x =>
{
    x.AddBlobServiceClient(new Uri("https://<account-name>.blob.core.windows.net"));
    x.UseCredential(new DefaultAzureCredential());
});

Azt is megteheti, hogy a szolgáltatásokban közvetlenül, további Azure-regisztrációs módszerek nélkül is használhatja DefaultAzureCredential az alábbiakban látható módon.

using Azure.Identity;

// Inside of Program.cs
builder.Services.AddSingleton<BlobServiceClient>(x => 
    new BlobServiceClient(
        new Uri("https://<account-name>.blob.core.windows.net"),
        new DefaultAzureCredential()));

Ha a fenti kód a helyi fejlesztés során fut a helyi munkaállomáson, az alkalmazás-szolgáltatásnév környezeti változóiban, illetve a Visual Studióban, a VS Code-ban, az Azure CLI-ben vagy az Azure PowerShellben fog keresni a fejlesztői hitelesítő adatok készletében, amelyek bármelyikével hitelesítheti az alkalmazást az Azure-erőforrásokban a helyi fejlesztés során.

Az Azure-ban való üzembe helyezéskor ugyanez a kód más Azure-erőforrásokon is hitelesítheti az alkalmazást. DefaultAzureCredential lekérheti a környezeti beállításokat és a felügyelt identitáskonfigurációkat a többi szolgáltatás automatikus hitelesítéséhez.

A DefaultAzureCredential hitelesítési módszerek sorozatának feltárása

Belsőleg DefaultAzureCredential hitelesítőadat-szolgáltatók láncát valósítja meg az alkalmazások Azure-erőforrásokhoz való hitelesítéséhez. Minden hitelesítőadat-szolgáltató képes észlelni, hogy az adott típusú hitelesítő adatok konfigurálva vannak-e az alkalmazáshoz. DefaultAzureCredential sorrendben ellenőrzi az egyes szolgáltatókat, és az első, hitelesítő adatokat konfigurált szolgáltatótól származó hitelesítő adatokat használja.

A hitelesítő adatokat kereső sorrend és helyek DefaultAzureCredential a DefaultAzureCredential helyen találhatók.

Hitelesítő adatok típusa Leírás
Alkalmazás-szolgáltatásnév DefaultAzureCredential Beolvassa a környezeti változók egy készletét annak megállapításához, hogy az alkalmazáshoz be van-e állítva egy alkalmazás-szolgáltatásnév (alkalmazásfelhasználó). Ha igen, DefaultAzureCredential ezeket az értékeket használva hitelesítheti az alkalmazást az Azure-ban.

Ezt a módszert leggyakrabban kiszolgálókörnyezetekben használják, de helyi fejlesztéskor is használható.
Felügyelt identitás Ha az alkalmazás olyan Azure-gazdagépen van üzembe helyezve, amelyen engedélyezve van a felügyelt identitás, DefaultAzureCredential az alkalmazás hitelesítése az Azure-ban ezzel a felügyelt identitással történik. A felügyelt identitást használó hitelesítést a dokumentum Kiszolgálói környezetek hitelesítése szakasza ismerteti.

Ez a módszer csak akkor érhető el, ha egy alkalmazást az Azure-ban üzemeltet egy olyan szolgáltatás használatával, mint a Azure-alkalmazás Szolgáltatás, az Azure Functions vagy az Azure Virtual Machines.
Visual Studio Ha a fejlesztő a Visual Studióba való bejelentkezéssel hitelesítette az Azure-t, DefaultAzureCredential azzal a fiókkal hitelesíti az alkalmazást az Azure-ban.
Visual Studio Code Ha a fejlesztő a Visual Studio Code Azure-fiók beépülő modullal hitelesítette az Azure-t, DefaultAzureCredential az alkalmazást ugyanazzal a fiókkal hitelesíti az Azure-ban.
Azure CLI Ha egy fejlesztő az Azure CLI-ben található paranccsal hitelesítette az az login Azure-t, DefaultAzureCredential ugyanazzal a fiókkal hitelesíti az alkalmazást az Azure-ban.
Azure PowerShell Ha egy fejlesztő az Azure PowerShell parancsmagjának használatával hitelesítette az Connect-AzAccount Azure-t, DefaultAzureCredential az alkalmazás hitelesítése az Azure-ban ugyanazzal a fiókkal történik.
Interaktív Ha engedélyezve van, DefaultAzureCredential a rendszer interaktívan hitelesíti a fejlesztőt az aktuális rendszer alapértelmezett böngészőjén keresztül. Alapértelmezés szerint ez a beállítás le van tiltva.