Redigera

Dela via


Accelerator för Azure API Management-landningszon

Azure API Management
Azure Application Gateway
Azure Functions
.NET

API:er har blivit allt mer framträdande i hur företag och kunder får åtkomst till tjänster, både internt och externt. Internt används API:er för att komma åt verksamhetsspecifika program, hembyggda lösningar och tredjepartsintegreringar. Externt ser fler företag ut att vara produktiva och tjäna pengar på sina API:er. Med den här trenden i åtanke blir API Management en central komponent i en standardmetod för att hantera, styra och publicera API:er till både interna och externa målgrupper.

Med hjälp av Azure Application Gateway är det nu möjligt att skydda och begränsa åtkomsten till API:er som hanteras via Azure API Management. Den här artikeln beskriver en lösning där du kan hantera både interna och externa API:er via en enda API Management-instans. Du kan upprätthålla en säker hållning från att exponeras direkt via Internet, men i stället nås den via en Application Gateway.

Kommentar

Den här arkitekturen används som grund för Azure API Management-acceleratorn för landningszoner i Cloud Adoption Framework.

Arkitektur

Diagram som visar arkitekturen för API Management-acceleratorn för landningszoner.

Det här arkitekturdiagrammet börjar med en heltäckande ruta som representerar omfånget för en prenumeration, en privat DNS-zon där privata domäner kommer att matchas och omfattningen för ett virtuellt nätverksnamn APIM-CS VNet. Ovanpå prenumerationen finns en ruta som anger att det är en lokal arbetsbelastning. Rutan har en serverikon i den. En pipe anger en plats-till-plats-anslutning, eller så ansluter Azure ExpressRoute till API Management-instansen i Azure-prenumerationen. Ytterligare sju mindre rutor finns i den stora rutan som visar Azure-prenumerationen. Fyra av rutorna finns på den översta raden och tre på den nedre raden. Varje enskild ruta representerar ett separat undernät med en ansluten nätverkssäkerhetsgrupp. Till vänster finns det en offentlig IP-adress som är kopplad till Azure Application Gateway längst till vänster på den översta raden. Application Gateway finns också i en av de sju mindre rutorna, med undernätet med namnet App GW-undernät. Till höger finns en annan ruta som innehåller API Management-instansen, med undernätet med namnet APIM-undernät. Bredvid den finns den tredje rutan på den översta raden, som innehåller en privat slutpunkt för Azure Functions-instansen i undernätet med namnet PE-undernät. Den högra rutan på den översta raden är serverdelsundernätet som innehåller Azure Function Apps, Azure App Service-planen för funktionen och lagringskontot som är associerat med funktionsappen. På den nedre raden, från vänster, finns en ruta som innehåller Azure Bastion i Bastion-undernätet. Den andra rutan innehåller den virtuella datorn för hantering av jumbox i Jump Box-undernätet. Den sista rutan på den nedre raden är DevOps Agent som finns i DevOps-undernätet. Längst ned till höger i bilden finns tre delade resurser med respektive ikoner. Från vänster till höger finns följande rutor: nyckelvalv, application insights och log analytics-arbetsytan. Det finns två uppsättningar med arbetsflöden. Det första arbetsflödet anges i svarta cirklar och det andra arbetsflödet anges i blå cirklar, vilket förklaras i senare avsnitt. Det svarta arbetsflödet anger åtkomsten till API:er som är tillgängliga externt. Flödet börjar från användaren som har åtkomst till den offentliga IP-adressen. Pilen pekar sedan mot riktningen för Application Gateway, från Application Gateway till den privata slutpunkten och från den privata slutpunkten till funktionsappen. Det blå arbetsflödet startar från en lokal server, med en pil som pekar på API Management-instansen, via en pipelineikon som anger antingen en plats-till-plats-anslutning eller via ExpressRoute. Resten av flödet är detsamma som beskrivs ovan: från API Management till privat slutpunkt och från privat slutpunkt till Azure Function.

Den här arkitekturen förutsätter att principerna finns på plats från Azure-landningszonens accelerator och att strukturen drivs nedåt från hanteringsgruppen.

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

Hybridscenario (blå cirklar)

Det här scenariot kräver en plats-till-plats eller en Azure ExpressRoute-anslutning till din lokala miljö.

  1. Ett lokalt program kräver åtkomst till ett internt API som hanteras via Azure API Management.
  2. API Management ansluter till serverdels-API:er som finns i Azure Functions. Den här anslutningen sker via en privat slutpunkt som är tillgänglig via Azure Functions Premium-planen och som finns i ett eget undernät.
  3. Den privata slutpunkten har säker åtkomst till det interna API:et som finns i Azure Functions.

Scenario för extern åtkomst (svarta cirklar)

  1. Ett externt program har åtkomst till en offentlig IP-adress eller ett anpassat FQDN som är kopplat till Azure Application Gateway.
  2. Application Gateway fungerar som brandvägg för webbprogram, vilket kräver PFX-certifikat för SSL-avslutning.
  3. API Management ansluter till serverdels-API:erna, som finns i Azure Functions, via en privat slutpunkt. Den här slutpunkten är tillgänglig via Azure Functions Premium-planen och finns i ett eget undernät.
  4. Den privata slutpunkten har säker åtkomst till det externt tillgängliga API:et som finns i Azure Functions.

Komponenter

Arkitekturen använder följande komponenter:

  • Azure API Management är en hanterad tjänst som gör att du kan hantera tjänster i hybridmiljöer och miljöer med flera moln. API-hantering fungerar som en fasad för att abstrahera serverdelsarkitekturen och ger kontroll och säkerhet för API-observerbarhet och förbrukning för både interna och externa användare.

  • Azure Functions är en serverlös lösning som gör att du kan fokusera mer på kodblock som kan köras med minimal infrastrukturhantering. Funktioner kan finnas i olika värdplaner, medan den här referensarkitekturen använder premiumplanen på grund av användningen av privata slutpunkter.

  • Azure Application Gateway är en hanterad tjänst som fungerar som en layer 7-lastbalanserare och brandvägg för webbprogram. I det här scenariot skyddar programgatewayen den interna APIM-instansen, vilket gör att du kan använda det interna och externa läget.

  • Med privata DNS-zoner i Azure DNSkan du hantera och matcha domännamn i ett virtuellt nätverk, utan att behöva implementera en anpassad DNS-lösning. En privat DNS-zon kan justeras till ett eller flera virtuella nätverk via virtuella nätverkslänkar. På grund av att Azure Functions exponeras via en privat slutpunkt som används i den här referensarkitekturen måste du använda en privat DNS-zon.

  • Azure MonitorApplication Insights hjälper utvecklare att identifiera avvikelser, diagnostisera problem och förstå användningsmönster. Application Insights-funktioner utökningsbar programprestandahantering och övervakning för webbappar i realtid. Olika plattformar stöds, inklusive .NET, Node.js, Java och Python. Den stöder appar som finns i Azure, lokalt, i en hybridmiljö eller i andra offentliga moln. Application Insights ingår som en del av den här referensarkitekturen för att övervaka beteendet för det distribuerade programmet.

  • Med Azure MonitorLog Analytics kan du redigera och köra loggfrågor med data i Azure Monitor-loggar, om du vill från Azure-portalen. Utvecklare kan köra enkla frågor för en uppsättning poster eller använda Log Analytics för att utföra avancerad analys. De kan sedan visualisera resultaten. Log Analytics har konfigurerats som en del av den här referensarkitekturen för att aggregera alla övervakningsloggar för mer analys och rapportering.

  • Azure Virtual Machines är en databehandlingsresurs som kan användas som värd för många olika arbetsbelastningar. I den här referensarkitekturen används virtuella datorer för att tillhandahålla en jumpbox-server för hantering samt en värd för DevOps-agenten eller GitHub-löparen.

  • Azure Key Vault är en molntjänst som på ett säkert sätt lagrar och kommer åt hemligheter, som sträcker sig från API-nycklar och lösenord till certifikat och kryptografiska nycklar. Den här referensarkitekturen använder Azure Key Vault för att lagra de SSL-certifikat som används av Application Gateway.

  • Azure Bastion är en plattform som en tjänst som etableras i utvecklarens virtuella nätverk. Det ger säker RDP/SSH-anslutning till utvecklarens virtuella datorer via TLS från Azure-portalen. Med Azure Bastion kräver virtuella datorer inte längre en offentlig IP-adress för att ansluta via RDP/SSH. Den här referensarkitekturen använder Azure Bastion för att komma åt DevOps-agenten eller GitHub-löparservern eller jump box-servern för hantering.

Om du använder ett DevOps-verktyg, till exempel Azure DevOps eller GitHub, fungerar molnbaserade agenter eller löpare via det offentliga Internet. Eftersom API-hanteringen i den här arkitekturen är inställd på ett internt nätverk måste du använda en DevOps-agent som har åtkomst till det virtuella nätverket. DevOps-agenten hjälper dig att distribuera principer och andra ändringar av API:erna i din arkitektur. Dessa CI/CD-mallar kan användas för att dela upp processen och för att dina utvecklingsteam ska kunna distribuera ändringar per API. De körs av DevOps-löparna.

Alternativ

För serverdelstjänster som API Management-instansen ansluter till finns det flera alternativ, utöver Azure Functions, som används i den här referensimplementeringen:

  • Azure App Service är en fullständigt hanterad HTTP-baserad tjänst som skapar, distribuerar och skalar webbappar. .NET, .NET Core, Java, Ruby, Node.js, PHP och Python stöds alla. Program kan köras och skalas i windows- eller Linux-baserade miljöer.
  • Azure Kubernetes Service erbjuder fullständigt hanterade Kubernetes-kluster för en integrerad ci/CD-upplevelse (kontinuerlig integrering och kontinuerlig leverans), styrning och säkerhet.
  • Azure Logic Apps är en molnbaserad plattform som skapar och kör automatiserade arbetsflöden. Ett exempel på en referensarkitektur finns i Grundläggande företagsintegrering i Azure.
  • Med Azure Container Apps kan du köra mikrotjänster och containerbaserade program på en serverlös plattform.

För distributioner i flera regioner bör du överväga att använda Azure Front Door för att ge snabb, tillförlitlig och säker åtkomst mellan dina användare och programmens statiska och dynamiska webbinnehåll.

Mer information om hur Application Gateway kan skydda API:er finns i Skydda API:er med Application Gateway och API Management.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tillförlitlighet

Tillförlitlighet säkerställer att ditt program kan uppfylla de åtaganden du gör gentemot dina kunder. Mer information finns i Översikt över tillförlitlighetspelare.

  • Distribuera minst två skalningsenheter för API Management som är spridda över två tillgänglighetszoner per region. Den här metoden maximerar din tillgänglighet och prestanda.
  • VNet-peering ger bra prestanda i en region, men den har en skalbarhetsgräns på högst 500 nätverk. Om du behöver fler arbetsbelastningar som ska anslutas använder du en hubb ekerdesign eller Azure vWAN.

Säkerhet

Säkerhet ger garantier mot avsiktliga attacker och missbruk av dina värdefulla data och system. Mer information finns i Översikt över säkerhetspelare.

  • Valideringsprinciper för API Management är tillgängliga för att verifiera API-begäranden och svar mot ett OpenAPI-schema. De här funktionerna ersätter inte brandväggen för webbprogram, men de kan ge ytterligare skydd mot vissa hot. Att lägga till valideringsprinciper kan ha prestandakonsekvenser, så vi rekommenderar att du använder prestandabelastningstester för att utvärdera deras inverkan på API-dataflödet.
  • Distribuera Azure Web Application Firewall (WAF) framför API Management för att skydda mot vanliga sårbarheter och sårbarheter i webbprogram.
  • Använd namngivna värden med Key Vault-hemligheter för att skydda känslig information i APIM-principer.
  • Använd Application Gateway för extern åtkomst till en intern APIM-instans för att skydda APIM-instansen och för att aktivera hybridanslutning.
  • Distribuera API Management-gatewayen i ett virtuellt nätverk för att stödja hybridanslutningar och ökad säkerhet.
  • VNet-peering ger bra prestanda i en region, men den har en skalbarhetsgräns på högst 500 nätverk. Om du behöver fler arbetsbelastningar som ska anslutas använder du en hubb ekerdesign eller Azure vWAN.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

  • På grund av behovet av tillgänglighetszon och stöd för virtuella nätverk valde vi Premium-nivån för API Management, enligt prissättningen för varje region. I den här arbetsbelastningen finns dessutom Azure Functions i Premium-planen på grund av behovet av VNet-åtkomst.
  • För konceptbevis eller prototyper rekommenderar vi att du använder andra nivåer av API Management (till exempel Utvecklare eller Standard).

Driftsäkerhet

Driftskvalitet omfattar de driftsprocesser som distribuerar ett program och håller det igång i produktion. Mer information finns i Översikt över grundpelare för driftskvalitet.

  • API Management-konfigurationer bör representeras som ARM-mallar och du bör använda ett infrastruktur-som-kod-tänkesätt.
  • Använd en CI/CD-process för att hantera, version och uppdatera API Management-konfigurationer.
  • Skapa anpassade hälsoavsökningar för att verifiera statusen för din API-hanteringsinstans. Använd URL:en /status-0123456789abcdef för att skapa en gemensam hälsoslutpunkt för APIM-tjänsten i appgatewayen.
  • Certifikat som uppdateras i nyckelvalvet roteras automatiskt i API Management, som uppdateras inom 4 timmar.
  • Distribuera minst två skalningsenheter för API Management som är spridda över två tillgänglighetszoner per region. Den här metoden maximerar tillgänglighet och prestanda.

Distribuera det här scenariot

Den här arkitekturen är tillgänglig på GitHub. Den innehåller alla nödvändiga infrastruktur-som-kod-filer och distributionsinstruktionerna.

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudsakliga författare:

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

Se de här nyckelresurserna:

Läs mer om dessa viktiga tjänster: