Az Azure Key Vaultra vonatkozó szabályozási irányelvek

  • Cikk

A szabályozás egy olyan folyamat, amelyet ön kezdeményez, amely korlátozza az Azure-szolgáltatásba irányuló egyidejű hívások számát az erőforrások túlhasználatának megakadályozása érdekében. Az Azure Key Vault (AKV) nagy mennyiségű kérés kezelésére lett kialakítva. Ha túl sok kérés történik, az ügyfél kéréseinek szabályozása segít fenntartani az AKV-szolgáltatás optimális teljesítményét és megbízhatóságát.

Throttling limits vary based on the scenario. For example, if you are performing a large volume of writes, the possibility for throttling is higher than if you are only performing reads.

Hogyan kezeli a Key Vault a korlátait?

A Key Vault szolgáltatáskorlátjai megakadályozzák az erőforrásokkal való visszaélést, és biztosítják a szolgáltatás minőségét a Key Vault összes ügyfele számára. Ha túllép egy szolgáltatási küszöbértéket, a Key Vault korlátozza az ügyféltől érkező további kéréseket, a HTTP-állapotkódot 429-et (túl sok kérést) ad vissza, és a kérés meghiúsul. A 429-et visszaadó sikertelen kérések nem számítanak bele a Key Vault által nyomon követett szabályozási korlátokba.

A Key Vault eredetileg úgy lett kialakítva, hogy az üzembe helyezéskor tárolja és kérje le a titkos kulcsokat. A világ fejlődött, és a Key Vaultot futtatáskor használják a titkos kódok tárolására és lekérésére, és gyakran az alkalmazások és szolgáltatások adatbázisként szeretnék használni a Key Vaultot. A jelenlegi korlátok nem támogatják a magas átviteli sebességeket.

A Key Vault eredetileg az Azure Key Vault szolgáltatáskorlátjaiban megadott korlátozásokkal lett létrehozva. A Key Vault átviteli sebességének maximalizálása érdekében íme néhány ajánlott irányelv/ajánlott eljárás az átviteli sebesség maximalizálásához:

  1. Győződjön meg arról, hogy a szabályozás a helyén van. Az ügyfélnek tiszteletben kell tartania a 429s exponenciális visszalépési szabályzatait, és gondoskodnia kell arról, hogy az alábbi útmutatásnak megfelelően újrapróbálkozzon.
  2. Ossza el a Key Vault-forgalmat több tároló és különböző régió között. Minden biztonsági/rendelkezésre állási tartományhoz használjon külön tárolót. Ha öt alkalmazással rendelkezik, amelyek mindegyike két régióban található, akkor javasoljuk, hogy 10 tárolót tartalmazzon, amelyek mindegyike az alkalmazásra és régióra jellemző titkos kódokat tartalmazza. Az összes tranzakciótípusra vonatkozó előfizetés-szintű korlát az egyes kulcstartókra vonatkozó korlát ötszöröse. A HSM-egyéb tranzakciók például előfizetésenként 5000 tranzakcióra korlátozódnak előfizetésenként 10 másodperc alatt. Fontolja meg a titkos kód gyorsítótárazását a szolgáltatásban vagy az alkalmazásban, hogy az RPS közvetlenül a Key Vaultra is csökkenjen, és/vagy kezelje a kipukkanási alapú forgalmat. A késés minimalizálása és egy másik előfizetés/tároló használata érdekében a forgalmat különböző régiók között is feloszthatja. Ne küldjön az előfizetési korlátnál nagyobbat egyetlen Azure-régió Key Vault szolgáltatásának.
  3. Gyorsítótárazza a memóriában az Azure Key Vaultból lekért titkos kulcsokat, és amikor csak lehetséges, újra felhasználja a memóriából. Csak akkor olvasson újra az Azure Key Vaultból, ha a gyorsítótárazott másolat nem működik (például mert a forrásnál elforgatták).
  4. A Key Vault saját szolgáltatáskulcsokhoz készült. Ha az ügyfelek titkos kulcsait tárolja (különösen nagy átviteli sebességű kulcstárolók esetén), fontolja meg a kulcsok titkosítással való elhelyezését egy adatbázisban vagy tárfiókban, és csak az elsődleges kulcsot tárolja az Azure Key Vaultban.
  5. A nyilvános kulcsú műveletek titkosítása, körbefuttatása és ellenőrzése a Key Vaulthoz való hozzáférés nélkül is elvégezhető, ami nem csak csökkenti a szabályozás kockázatát, hanem a megbízhatóságot is javítja (mindaddig, amíg megfelelően gyorsítótárazza a nyilvános kulcs anyagát).
  6. Ha a Key Vaultot használja egy szolgáltatás hitelesítő adatainak tárolására, ellenőrizze, hogy a szolgáltatás támogatja-e a Microsoft Entra-hitelesítést a közvetlen hitelesítéshez. Ez csökkenti a Key Vault terhelését, javítja a megbízhatóságot és leegyszerűsíti a kódot, mivel a Key Vault mostantól használhatja a Microsoft Entra-jogkivonatot. Számos szolgáltatás átkerült a Microsoft Entra hitelesítés használatára. Tekintse meg az Azure-erőforrások felügyelt identitását támogató szolgáltatások aktuális listáját.
  7. Fontolja meg a terhelés/üzembe helyezés hosszabb időn keresztül történő megdöbbentését, hogy a jelenlegi RPS-korlátok alatt maradjon.
  8. Ha az alkalmazás több olyan csomópontból áll, amelyeknek ugyanazokat a titkos kódokat kell olvasniuk, akkor érdemes lehet egy rajongói mintát használni, ahol egy entitás beolvassa a titkos kulcsot a Key Vaultból, és a rajongókat az összes csomópontra. A beolvasott titkos kulcsok gyorsítótárazása csak a memóriában.

Az alkalmazás szabályozása a szolgáltatási korlátokra válaszul

A szolgáltatás szabályozása során az alábbi ajánlott eljárásokat kell implementálnia:

  • Csökkentse a műveletek számát kérésenként.
  • Csökkentse a kérések gyakoriságát.
  • Kerülje az azonnali újrapróbálkozást.
    • Minden kérés a használati korlátok alapján keletkezik.

Az alkalmazás hibakezelésének megvalósításakor a 429-ben megadott HTTP-hibakóddal észlelheti az ügyféloldali szabályozás szükségességét. Ha a kérés http 429-hibakóddal ismét meghiúsul, akkor továbbra is Azure-szolgáltatási korlátot tapasztal. Folytassa az ajánlott ügyféloldali szabályozási módszer használatát, és próbálkozzon újra a kéréssel, amíg az sikeres lesz.

Az alábbi kód exponenciális visszalépést implementál:

SecretClientOptions options = new SecretClientOptions()
    {
        Retry =
        {
            Delay= TimeSpan.FromSeconds(2),
            MaxDelay = TimeSpan.FromSeconds(16),
            MaxRetries = 5,
            Mode = RetryMode.Exponential
         }
    };
    var client = new SecretClient(new Uri("https://keyVaultName.vault.azure.net"), new DefaultAzureCredential(),options);
                                 
    //Retrieve Secret
    secret = client.GetSecret(secretName);

A kód használata egy ügyfél C#-alkalmazásban egyszerű.

A 429-es hibakód esetén kezdje meg az ügyfél szabályozását exponenciális visszalépést alkalmazó megközelítéssel:

  1. Várjon 1 másodpercet, majd próbálkozzon újra a kéréssel
  2. Ha a szabályozás továbbra is fennáll, várjon 2 másodpercet, majd próbálkozzon újra a kéréssel
  3. Ha a szabályozás továbbra is fennáll, várjon 4 másodpercet, majd próbálkozzon újra a kéréssel
  4. Ha a szabályozás továbbra is fennáll, várjon 8 másodpercet, majd próbálkozzon újra a kéréssel
  5. Ha a szabályozás továbbra is fennáll, várjon 16 másodpercet, majd próbálkozzon újra a kéréssel

Ekkor már nem szabad 429-es HTTP-válaszkódot kapnia.

Kapcsolódó információk

A Szabályozás a Microsoft Cloudon című témakörben talál részletesebb útmutatást.