Megosztás a következőn keresztül:

Saját üzemeltetésű átjáró áttekintése

  • Cikk

A KÖVETKEZŐKRE VONATKOZIK: Fejlesztő | Prémium

A saját üzemeltetésű átjáró az alapértelmezett felügyelt átjáró opcionális, tárolóalapú verziója, amely minden API Management szolgáltatásban megtalálható. Olyan helyzetekben hasznos, mint az átjárók ugyanabban a környezetben való elhelyezése, ahol az API-kat üzemelteti. A saját üzemeltetésű átjáróval javíthatja az API-forgalom folyamatát, és kezelheti az API biztonsági és megfelelőségi követelményeit.

Ez a cikk bemutatja, hogyan teszi lehetővé az Azure API Management saját üzemeltetésű átjárófunkciója a hibrid és többfelhős API-kezelést, hogyan mutatja be magas szintű architektúráját, és hogyan emeli ki képességeit.

A különböző átjáróajánlatok funkcióinak áttekintéséért tekintse meg az API-átjárót az API Managementben.

Hibrid és többfelhős API-felügyelet

A saját üzemeltetésű átjáró funkció kibővíti a hibrid és többfelhős környezetek API Management-támogatását, és lehetővé teszi, hogy a szervezetek hatékonyan és biztonságosan felügyelhessék a helyszínen és felhőkben üzemeltetett API-kat egyetlen Azure-beli API Management szolgáltatásból.

A saját üzemeltetésű átjáróval az ügyfelek rugalmasan helyezhetik üzembe az API Management-átjáró összetevő egy tárolóalapú verzióját ugyanazon környezetekben, ahol az API-kat üzemeltetik. Az összes saját üzemeltetésű átjárót az API Management szolgáltatásból felügyeljük, amely az összes belső és külső API-ban biztosítja az ügyfelek számára a láthatóságot és az egységes felügyeleti élményt.

Minden API Management-szolgáltatás a következő fő összetevőkből áll:

  • Az API-ként közzétett felügyeleti sík az Azure Portalon, a PowerShellen és más támogatott mechanizmusokon keresztül konfigurálja a szolgáltatást.
  • Átjáró (vagy adatsík), amely az API-kérések proxyzásával, szabályzatok alkalmazásával és telemetriai adatok gyűjtésével foglalkozik
  • Fejlesztői portál, amelyet a fejlesztők használnak az API-k felderítésére, megismerésére és előkészítésére

Alapértelmezés szerint ezek az összetevők az Azure-ban vannak üzembe helyezve, így az API-forgalom (az alábbi képen egyszínű fekete nyilakkal) az Azure-on halad át, függetlenül attól, hogy az API-kat implementáló háttérrendszerek hol találhatók. Ennek a modellnek a működési egyszerűsége a megnövekedett késés, a megfelelőségi problémák és bizonyos esetekben a többlet adatátviteli díjak költségével jár.

API-forgalom saját üzemeltetésű átjárók nélkül

A saját üzemeltetésű átjárók ugyanabban a környezetben való üzembe helyezése, ahol a háttér API-implementációk üzemelnek, lehetővé teszi, hogy az API-forgalom közvetlenül a háttér API-kba áramoljon, ami csökkenti a késést, optimalizálja az adatátviteli költségeket, és lehetővé teszi a megfelelőséget, miközben megtartja a szervezeten belüli összes API felügyeletének, megfigyelhetőségének és felderítésének előnyeit, függetlenül attól, hogy hol üzemeltetik az implementációkat.

API-forgalom saját üzemeltetésű átjárókkal

Csomagolás

A saját üzemeltetésű átjáró Linux-alapú Docker-tárolórendszerképként érhető el a Microsoft Eszközjegyzék. Üzembe helyezhető a Dockerben, a Kubernetesben vagy bármely más tárolóvezénylési megoldásban, amely egy kiszolgálófürtön fut a helyszínen, felhőinfrastruktúra vagy kiértékelési és fejlesztési célokra egy személyes számítógépen. A saját üzemeltetésű átjárót fürtbővítményként is üzembe helyezheti egy Azure Arc-kompatibilis Kubernetes-fürtön.

Tárolólemezképek

A saját üzemeltetésű átjárókhoz különböző tárolórendszerképeket biztosítunk az igényeinek megfelelően:

Címkekonvenció Ajánlás Példa Gördülő címke Éles környezetben ajánlott
{major}.{minor}.{patch} Ezzel a címkével mindig ugyanazt az átjáróverziót futtathatja 2.0.0 ❌ ✔️
v{major} Ezzel a címkével mindig futtathatja az átjáró főverzióját minden új funkcióval és javítással. v2 ✔️ ❌
v{major}-preview Ezt a címkét akkor használja, ha mindig a legújabb előzetes verziójú tárolórendszerképet szeretné futtatni. v2-preview ✔️ ❌
latest Ezt a címkét akkor használja, ha ki szeretné értékelni a saját üzemeltetésű átjárót. latest ✔️ ❌
beta1 Ezt a címkét akkor használja, ha ki szeretné értékelni a saját üzemeltetésű átjáró előzetes verzióit. beta ✔️ ❌

Az elérhető címkék teljes listáját itt találja.

Az 1előzetes verzió hivatalosan nem támogatott, és csak kísérleti célokra használható. Tekintse meg a saját üzemeltetésű átjáró támogatási szabályzatát.

Címkék használata a hivatalos üzembehelyezési lehetőségekben

Az Azure Portal üzembe helyezési beállításai a címkét használják v2 , amely lehetővé teszi az ügyfelek számára, hogy az összes funkciófrissítéssel és javítással a saját üzemeltetésű átjáró v2 tárolólemezképének legújabb verzióját használják.

Feljegyzés

Referenciaként megadjuk a parancsot és a YAML-kódrészleteket, ha szeretné, nyugodtan használjon egy konkrétabb címkét.

A Helm-diagramunkkal történő telepítéskor a rendszerkép-címkézés optimalizálva van. A Helm-diagram alkalmazásverziója rögzíti az átjárót egy adott verzióra, és nem támaszkodik rá latest.

További információ arról, hogyan telepíthet saját üzemeltetésű API Management-átjárót a Kubernetesre a Helmel.

Működés közbeni címkék használatának kockázata

A gördülő címkék olyan címkék, amelyek a tárolólemezkép új verziójának megjelenésekor esetleg frissülnek. Ez lehetővé teszi a tárolófelhasználók számára a tárolólemezkép frissítését anélkül, hogy frissíteniük kellene az üzemelő példányokat.

Ez azt jelenti, hogy lehetséges, hogy a különböző verziókat párhuzamosan futtatja anélkül, hogy észrevenned, például ha a címke frissítése után v2 skálázási műveleteket hajt végre.

Példa – v2 a címkét tárolórendszerképpel 2.0.0 adták ki, de mikor 2.1.0 jelenik meg, a v2 címke a 2.1.0 rendszerképhez lesz csatolva.

Fontos

Érdemes lehet egy adott verziócímkét használni az éles környezetben, hogy elkerülje az újabb verzióra való véletlen frissítést.

Kapcsolódás az Azure-hoz

A saját üzemeltetésű átjárók kimenő TCP/IP-kapcsolatot igényelnek az Azure-hoz a 443-as porton. Minden saját üzemeltetésű átjárót egyetlen API Management szolgáltatáshoz kell társítani, és a felügyeleti síkon keresztül kell konfigurálni. A saját üzemeltetésű átjárók az Azure-hoz való kapcsolódást használják a következő célokra:

  • Állapotjelentés szívverési üzenetek percenkénti küldésével
  • Rendszeresen ellenőrizze (10 másodpercenként) és alkalmazza a konfigurációs frissítéseket, amikor elérhetők
  • Metrikák küldése az Azure Monitorba, ha erre van konfigurálva
  • Események küldése az Application Insightsba, ha erre van beállítva

FQDN-függőségek

A megfelelő működéshez minden saját üzemeltetésű átjárónak kimenő kapcsolatot kell létesítenie a 443-as porton a felhőalapú API Management-példányhoz társított következő végpontokkal:

Leírás Az 1. verzióhoz szükséges A v2-hez szükséges Jegyzetek
A konfigurációs végpont állomásneve <apim-service-name>.management.azure-api.net <apim-service-name>.configuration.azure-api.net1 Az egyéni gazdagépnevek is támogatottak, és az alapértelmezett gazdagépnév helyett használhatók.
Az API Management-példány nyilvános IP-címe ✔️ ✔️ Az elsődleges hely IP-címe elegendő.
Az Azure Storage szolgáltatáscímkéjének nyilvános IP-címei ✔️ Nem kötelező2 Az IP-címeknek meg kell felelnie az API Management-példány elsődleges helyének.
Az Azure Blob Storage-fiók állomásneve ✔️ Nem kötelező2 Példányhoz társított fiók (<blob-storage-account-name>.blob.core.windows.net)
Az Azure Table Storage-fiók gazdagépneve ✔️ Nem kötelező2 Példányhoz társított fiók (<table-storage-account-name>.table.core.windows.net)
Az Azure Resource Manager végpontjai ✔️ Nem kötelező3 A szükséges végpontok a következők management.azure.com: .
Végpontok a Microsoft Entra-integrációhoz ✔️ Nem kötelező4 A szükséges végpontok a következők: <region>.login.microsoft.com és login.microsoftonline.com.
Végpontok Azure-alkalmazás Insights-integrációhoz Nem kötelező5 Nem kötelező5 Minimálisan szükséges végpontok a következők:
  • rt.services.visualstudio.com:443
  • dc.services.visualstudio.com:443
  • {region}.livediagnostics.monitor.azure.com:443
További információ az Azure Monitor-dokumentumokban
Az Event Hubs-integráció végpontjai Nem kötelező5 Nem kötelező5 További információ az Azure Event Hubs dokumentációjában
Külső gyorsítótár-integráció végpontjai Nem kötelező5 Nem kötelező5 Ez a követelmény a használt külső gyorsítótártól függ

1Egy belső virtuális hálózat API Management-példánya esetén lásd a belső virtuális hálózat kapcsolatát.
2Csak akkor szükséges a 2- es verzióban, ha API-ellenőrt vagy kvótákat használnak a szabályzatokban.
3Csak akkor szükséges, ha Az RBAC-engedélyek ellenőrzéséhez Microsoft Entra-hitelesítést használ.
4Csak a Microsoft Entra-hitelesítés vagy a Microsoft Entra-tal kapcsolatos szabályzatok használata esetén szükséges.
5Csak akkor szükséges, ha a szolgáltatás használatban van, és nyilvános IP-címet, portot és gazdagépnév-információkat igényel.

Fontos

  • A DNS-állomásneveknek feloldhatónak kell lenniük az IP-címekre, és a megfelelő IP-címeknek elérhetőnek kell lenniük.
  • A társított tárfiókok nevei az Azure Portalon, a szolgáltatás hálózati kapcsolati állapotlapján jelennek meg.
  • A társított tárfiókok alapjául szolgáló nyilvános IP-címek dinamikusak, és értesítés nélkül változhatnak.

Kapcsolat a belső virtuális hálózaton

  • Privát kapcsolat – Ha a saját üzemeltetésű átjáró virtuális hálózaton van üzembe helyezve, engedélyezze a v2 konfigurációs végponthoz való privát kapcsolatot a saját üzemeltetésű átjáró helyéről, például privát DNS használatával egy társhálózatban.

  • Internetkapcsolat – Ha a saját üzemeltetésű átjárónak az interneten keresztül kell csatlakoznia a v2 konfigurációs végponthoz, konfiguráljon egy egyéni gazdagépnevet a konfigurációs végponthoz, és tegye elérhetővé a végpontot az Application Gateway használatával.

Hitelesítési lehetőségek

A saját üzemeltetésű átjáró és a felhőalapú API Management-példány konfigurációs végpontja közötti kapcsolat hitelesítéséhez az alábbi beállításokat használhatja az átjárótároló konfigurációs beállításai között.

Lehetőség Megfontolások
Microsoft Entra hitelesítés Egy vagy több Microsoft Entra-alkalmazás konfigurálása átjáróhoz való hozzáféréshez

Hozzáférés kezelése alkalmazásonként külön

A titkos kódok hosszabb lejárati idejének konfigurálása a szervezet szabályzatainak megfelelően

Szabványos Microsoft Entra-eljárások használata felhasználói vagy csoportengedélyek alkalmazáshoz való hozzárendeléséhez vagy visszavonásához, valamint titkos kulcsok elforgatásához
Átjáró hozzáférési jogkivonata (más néven hitelesítési kulcs) A jogkivonat legfeljebb 30 naponta lejár, és meg kell újítani a tárolókban

Egy egymástól függetlenül elforgatható átjárókulcs (például a hozzáférés visszavonása) által támogatott

Az átjárókulcs újragenerálása érvényteleníti a vele létrehozott összes hozzáférési jogkivonatot

Csatlakozási hibák

Ha az Azure-hoz való kapcsolat megszakad, a saját üzemeltetésű átjáró nem tud konfigurációs frissítéseket fogadni, állapotjelentést vagy telemetriai adatokat feltölteni.

A saját üzemeltetésű átjáró úgy lett kialakítva, hogy "sikertelen statikus" legyen, és túlélje az Azure-hoz való csatlakozás ideiglenes elvesztését. Helyi konfigurációs biztonsági mentéssel vagy anélkül is üzembe helyezhető. A konfigurációs biztonsági mentéssel a saját üzemeltetésű átjárók rendszeresen mentik a legújabb letöltött konfiguráció biztonsági másolatát a tárolójukhoz vagy podjukhoz csatlakoztatott állandó köteten.

Ha a konfigurációs biztonsági mentés ki van kapcsolva, és megszakad a kapcsolat az Azure-hoz:

  • A saját üzemeltetésű átjárók futtatása továbbra is működni fog a konfiguráció memóriabeli másolatának használatával
  • A leállított saját üzemeltetésű átjárók nem fognak tudni elindulni

Ha a konfigurációs biztonsági mentés be van kapcsolva, és megszakad a kapcsolat az Azure-sal:

  • A saját üzemeltetésű átjárók futtatása továbbra is működni fog a konfiguráció memóriabeli másolatának használatával
  • A leállított saját üzemeltetésű átjárók elkezdhetik használni a konfiguráció biztonsági másolatát

A kapcsolat visszaállításakor a kimaradás által érintett minden egyes saját üzemeltetésű átjáró automatikusan újracsatlakozik a társított API Management szolgáltatással, és letölti az összes konfigurációs frissítést, amely az átjáró offline állapotában történt.

Biztonság

Korlátozások

A felügyelt átjárókban található alábbi funkciók nem érhetők el a saját üzemeltetésű átjárókban:

  • TLS-munkamenet újraindítása.
  • Ügyféltanúsítvány újratárgyalása. Az ügyféltanúsítvány-hitelesítés használatához az API-felhasználóknak a kezdeti TLS-kézfogás részeként kell bemutatniuk a tanúsítványaikat. Ennek a viselkedésnek a biztosításához engedélyezze az Ügyféltanúsítvány egyeztetése beállítást egy saját üzemeltetésű átjáró egyéni gazdagépnevének (tartománynév) konfigurálásakor.

Transport Layer Security (TLS)

Fontos

Ez az áttekintés csak a saját üzemeltetésű átjáró 1. és 2. v2-ére vonatkozik.

Támogatott protokollok

A saját üzemeltetésű átjáró alapértelmezés szerint támogatja a TLS 1.2-s verziót.

Az egyéni tartományokat használó ügyfelek engedélyezhetik a TLS 1.0-s és/vagy 1.1-s verziójának használatát a vezérlősíkon.

Elérhető titkosítási csomagok

Fontos

Ez az áttekintés csak a saját üzemeltetésű átjáró v2-ére vonatkozik.

A saját üzemeltetésű átjáró az alábbi titkosítási csomagokat használja az ügyfél- és kiszolgálókapcsolatokhoz:

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_DHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_RSA_WITH_AES_256_GCM_SHA384
  • TLS_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_RSA_WITH_AES_128_CBC_SHA

Titkosítási csomagok kezelése

A 2.1.1-s és újabb verziókban a konfiguráció során használt titkosításokat kezelheti:

  • net.server.tls.ciphers.allowed-suites Lehetővé teszi az API-ügyfél és a saját üzemeltetésű átjáró közötti TLS-kapcsolathoz használandó titkosítások vesszővel tagolt listájának definiálását.
  • net.client.tls.ciphers.allowed-suites Lehetővé teszi a saját üzemeltetésű átjáró és a háttérrendszer közötti TLS-kapcsolathoz használandó titkosítások vesszővel tagolt listájának definiálását.

Következő lépések