APIs spielen eine immer wichtigere Rolle dabei, wie Unternehmen und Kunden sowohl intern als auch extern auf Dienste zugreifen. Intern werden APIs für den Zugriff auf branchenspezifische Anwendungen, selbstentwickelte Lösungen und Drittanbieterintegrationen verwendet. Extern möchten immer mehr Unternehmen produktiver sein und ihre APIs monetarisieren. Angesichts dieses Trends wird API Management zu einer zentralen Komponente in einem Standardansatz zur Verwaltung, Steuerung und Veröffentlichung von APIs für interne und externe Zielgruppen.
Mithilfe von Azure Application Gateway ist es jetzt möglich, den Zugriff auf APIs, die über Azure API Management bereitgestellt werden, zu schützen und zu beschränken. In diesem Artikel wird eine Lösung beschrieben, mit der Sie sowohl interne als auch externe APIs über eine einzige API Management-Instanz verwalten können. Sie können die Sicherheit gewährleisten, indem kein direkter Zugang über das Internet möglich ist, sondern der Zugriff stattdessen über ein Anwendungsgateway erfolgt.
Hinweis
Diese Architektur wird als Grundlage für die Anleitung für Azure API Management in Azure-Zielzonen im Cloud Adoption Framework verwendet.
Dieses Architekturdiagramm zeigt im unteren Abschnitt einen großen umrandeten Bereich, der den Geltungsbereich eines Abonnements, eine private DNS-Zone zum Auflösen privater Domänen und den Geltungsbereich eines virtuellen Netzwerks namens „APIM-CS VNet“ enthält. Das Rechteck oberhalb des Abonnements repräsentiert eine lokale Workload. Im Rechteck ist ein Serversymbol zu sehen. Eine Linie kennzeichnet eine Site-zu-Site- oder Azure ExpressRoute-Verbindung mit der API Management-Instanz im Azure-Abonnement. Der große Bereich mit dem Azure-Abonnement enthält sieben kleinere Rechtecke. Vier der Rechtecke befinden sich in der oberen Reihe, drei befinden sich in der unteren Reihe. Jedes einzelne Rechteck stellt ein separates Subnetz mit einer verknüpften Netzwerksicherheitsgruppe dar. Ganz links außen ist eine öffentliche IP-Adresse dargestellt, die mit Azure Application Gateway im Rechteck ganz links in der oberen Reihe verknüpft ist. Application Gateway ist auch in einem der sieben kleineren Rechtecke enthalten, wobei das Subnetz den Namen „App GW“ trägt. Rechts daneben befindet sich ein weiteres Rechteck, das die API Management-Instanz mit dem Subnetz „APIM“ enthält. Daneben befindet sich das dritte Rechteck in der oberen Reihe, das einen privaten Endpunkt für die Azure Functions-Instanz im Subnetz namens „PE“ enthält. Das Rechteck ganz außen rechts in der oberen Reihe ist das Back-End-Subnetz, das Azure Function Apps, den Azure App Service-Plan für die Funktion und das Speicherkonto enthält, das der Funktions-App zugeordnet ist. In der unteren Reihe, beginnend von links, befindet sich ein Rechteck, das Azure Bastion im Subnetz „Bastion“ enthält. Das zweite Rechteck enthält die Jumpbox-VM für die Verwaltung im Subnetz „Jump Box“. Das letzte Rechteck in der unteren Reihe ist der im Subnetz „DevOps“ enthaltene DevOps-Agent. Unten rechts im Bild werden drei gemeinsam genutzte Ressourcen mit ihren jeweiligen Symbolen angezeigt. Von links nach rechts sind dies Key Vault, Application Insights und der Log Analytics-Arbeitsbereich. Es gibt zwei Arten von Workflows. Der erste Workflow wird mit schwarzen Kreisen dargestellt, der zweite Workflow wird durch blaue Kreise gekennzeichnet, die in späteren Abschnitten erläutert werden. Der schwarze Workflow zeigt den Zugriff von APIs an, die extern verfügbar sind. Der Workflow beginnt mit dem Zugriff des Benutzers auf die öffentliche IP-Adresse. Der Pfeil zeigt dann in Richtung des Anwendungsgateways, vom Anwendungsgateway zum privaten Endpunkt und vom privaten Endpunkt zur Funktions-App. Der blaue Workflow beginnt bei einem lokalen Server. Von dort aus zeigt ein Pfeil auf die API Management-Instanz, und zwar über ein Leitungssymbol, das entweder auf eine Site-to-Site-Verbindung oder eine Verbindung über ExpressRoute verweist. Der übrige Ablauf ist derselbe wie oben beschrieben: von der API Management-Instanz zum privaten Endpunkt und vom privaten Endpunkt zu Azure Functions.
Bei dieser Architektur wird davon ausgegangen, dass die Richtlinien vom Azure-Zielzonenbeschleuniger umgesetzt werden und dass die Struktur von der Verwaltungsgruppe abwärts verläuft.
Laden Sie eine Visio-Datei dieser Architektur herunter.
Dieses Szenario erfordert eine Site-to-Site- oder eine Azure ExpressRoute-Verbindung mit Ihrer lokalen Umgebung.
- Eine lokale Anwendung benötigt Zugriff auf eine interne API, die über Azure API Management betrieben wird.
- API Management stellt eine Verbindung mit den Back-End-APIs her, die in Azure Functions gehostet werden. Diese Verbindung erfolgt über einen privaten Endpunkt, der im Rahmen des Azure Functions Premium-Plans zur Verfügung steht und in einem eigenen Subnetz gehostet wird.
- Der private Endpunkt greift sicher auf die interne API zu, die in Azure Functions gehostet wird.
- Eine externe Anwendung greift auf eine öffentliche IP-Adresse oder einen benutzerdefinierten FQDN zu, der mit Azure Application Gateway verknüpft ist.
- Application Gateway fungiert als Webanwendungsfirewall, die PFX-Zertifikate für die SSL-Terminierung erfordert.
- API Management stellt über einen privaten Endpunkt eine Verbindung mit den Back-End-APIs her, die in Azure Functions gehostet werden. Dieser Endpunkt steht im Rahmen des Azure Functions Premium-Plans zur Verfügung und wird in einem eigenen Subnetz gehostet.
- Der private Endpunkt greift sicher auf die extern verfügbare API zu, die in Azure Functions gehostet wird.
Diese Architektur nutzt die folgenden Komponenten:
Azure API Management ist ein verwalteter Dienst, mit dem Sie Dienste in Hybrid- und Multi-Cloud-Umgebungen verwalten können. API Management dient als „Fassade“ zur Abstraktion der Back-End-Architektur und bietet Kontrolle und Sicherheit für die Beobachtbarkeit und Nutzung von APIs sowohl für interne als auch externe Benutzer.
Azure Functions ist eine serverlose Lösung, durch die Sie sich stärker auf Codeblöcke konzentrieren können, die mit minimaler Infrastrukturverwaltung ausgeführt werden können. Functions kann in verschiedenen Hostingplänen betrieben werden, wobei diese Referenzarchitektur aufgrund der Verwendung privater Endpunkte den Premium-Plan verwendet.
Azure Application Gateway ist ein verwalteter Dienst, der als Layer 7-Lastenausgleich und Webanwendungsfirewall fungiert. In diesem Szenario schützt das Anwendungsgateway die interne APIM-Instanz, sodass Sie den internen und externen Modus nutzen können.
Private DNS-Zonen von Azure DNS ermöglichen es Ihnen, Domänennamen innerhalb eines virtuellen Netzwerks zu verwalten und aufzulösen, ohne eine eigene DNS-Lösung implementieren zu müssen. Eine private DNS-Zone kann durch virtuelle Netzwerkverbindungen mit einem oder mehreren virtuellen Netzwerken verknüpft werden. Da Azure Functions in dieser Referenzarchitektur über einen privaten Endpunkt verfügbar gemacht wird, müssen Sie eine private DNS-Zone verwenden.
Azure MonitorApplication Insights unterstützt Entwickler dabei, Anomalien zu erkennen, Probleme zu diagnostizieren und Nutzungsmuster zu verstehen. Application Insights bietet eine erweiterbare Verwaltung und Überwachung der Anwendungsleistung für Live-Web-Apps. Es werden verschiedene Plattformen unterstützt, darunter .NET, Node.js, Java und Python. Die Lösung unterstützt Apps, die in Azure, lokal, in einer Hybridumgebung oder in anderen öffentlichen Clouds gehostet werden. Application Insights ist Teil dieser Referenzarchitektur, um das Verhalten der bereitgestellten Anwendung zu überwachen.
Azure Monitor Log Analytics ermöglicht Ihnen die Bearbeitung und Ausführung von Protokollabfragen mit Daten in Azure Monitor-Protokollen, optional über das Azure-Portal. Entwickler können einfache Abfragen für eine Reihe von Datensätzen ausführen oder Log Analytics verwenden, um erweiterte Analysen durchzuführen. Anschließend können sie die Ergebnisse visualisieren. Log Analytics wird als Teil dieser Referenzarchitektur konfiguriert, um alle Überwachungsprotokolle für eine weitere Analyse und für die Berichterstellung zu aggregieren.
Azure Virtual Machines ist eine Computingressource, die zum Hosten einer Vielzahl unterschiedlicher Workloads verwendet werden kann. In dieser Referenzarchitektur werden virtuelle Computer (VMs) verwendet, um einen Jumpbox-Verwaltungsserver sowie einen Host für den DevOps-Agent oder GitHub-Runner bereitzustellen.
Azure Key Vault ist ein Clouddienst für die sichere Speicherung und den Zugriff auf Geheimnisse, die von API-Schlüsseln und Kennwörtern bis hin zu Zertifikaten und Kryptografieschlüsseln reichen. Diese Referenzarchitektur verwendet Azure Key Vault zum Speichern der SSL-Zertifikate, die vom Application Gateway genutzt werden.
Azure Bastion ist ein PaaS-Dienst (Platform-as-a-Service), der innerhalb des virtuellen Netzwerks des Entwicklers bereitgestellt wird. Die Lösung bietet eine sichere RDP/SSH-Verbindung mit den VMs des Entwicklers über TLS aus dem Azure-Portal. Mit Azure Bastion benötigen VMs keine öffentliche IP-Adresse mehr, um sich über RDP/SSH zu verbinden. Diese Referenzarchitektur verwendet Azure Bastion für den Zugriff auf den DevOps-Agent- oder GitHub-Runner-Server oder den Jumpbox-Verwaltungsserver.
Wenn Sie ein DevOps-Tool wie Azure DevOps oder GitHub verwenden, werden die in der Cloud gehosteten Agents oder Runner über das öffentliche Internet betrieben. Da die API-Verwaltung in dieser Architektur über ein internes Netzwerk erfolgt, müssen Sie einen DevOps-Agent verwenden, der Zugriff auf das VNet hat. Der DevOps-Agent unterstützt Sie bei der Bereitstellung von Richtlinien und anderen Änderungen an den APIs in Ihrer Architektur. Mithilfe dieser können Sie den Prozess aufteilen und Ihren Entwicklungsteams ermöglichen, Änderungen pro API zu implementieren. Die Ausführung erfolgt über die DevOps-Runner.
Für die Back-End-Dienste, mit denen sich die API-Verwaltungsinstanz verbindet, stehen neben Azure Functions (das in dieser Referenzimplementierung verwendet wird) mehrere Alternativen zur Verfügung:
- Azure App Service ist ein vollständig verwalteter HTTP-basierter Dienst, der Webanwendungen erstellt, bereitstellt und skaliert. App Service unterstützt .NET, .NET Core, Java, Ruby, Node.js, PHP und Python. Anwendungen können sowohl in Windows- als auch in Linux-basierten Umgebungen ausgeführt und skaliert werden.
- Azure Kubernetes Service bietet vollständig verwaltete Kubernetes-Cluster für integrierte CI/CD-Funktionalität (Continuous Integration and Continuous Delivery), Governance und Sicherheit.
- Azure Logic Apps ist eine cloudbasierte Plattform, die automatisierte Workflows erstellt und ausführt. Ein Beispiel für eine Referenzarchitektur finden Sie unter Einfache Unternehmensintegration in Azure.
- Azure Container Apps ermöglicht Ihnen die Ausführung von Microservices und containerisierten Anwendungen auf einer serverlosen Plattform.
Für eine Bereitstellung in mehreren Regionen sollten Sie Azure Front Door verwenden, um einen schnellen, zuverlässigen und sicheren Zugriff zwischen Benutzern und den statischen und dynamischen Webinhalten Ihrer Anwendungen zu gewährleisten.
Weitere Beispiele für den Schutz von APIs über Application Gateway finden Sie unter Schützen von APIs mit Application Gateway und API Management.
Diese Überlegungen beruhen auf den Säulen des Azure Well-Architected Frameworks, d. h. einer Reihe von Grundsätzen, mit denen die Qualität von Workloads verbessert werden kann. Weitere Informationen finden Sie unter Microsoft Azure Well-Architected Framework.
Zuverlässigkeit stellt sicher, dass Ihre Anwendung Ihre Verpflichtungen gegenüber den Kunden erfüllen kann. Weitere Informationen finden Sie in der Überblick über die Säule „Zuverlässigkeit“.
- Stellen Sie pro Region mindestens zwei API Management-Skalierungseinheiten bereit, die auf zwei Verfügbarkeitszonen verteilt sind. Diese Vorgehensweise maximiert die Verfügbarkeit und Leistung.
- Das VNet-Peering bietet hervorragende Leistung in einer Region, ist aber auf maximal 500 Netzwerke begrenzt. Wenn mehr Workloads verbunden werden müssen, verwenden Sie ein Hub-Spoke-Design oder Azure Virtual WAN.
Sicherheit bietet Schutz vor vorsätzlichen Angriffen und dem Missbrauch Ihrer wertvollen Daten und Systeme. Weitere Informationen finden Sie unter Übersicht über die Säule „Sicherheit“.
- In API Management stehen Überprüfungsrichtlinien zur Verfügung, um API-Anforderungen und -Antworten anhand eines OpenAPI-Schemas zu validieren. Diese Features sind kein Ersatz für eine Webanwendungsfirewall, aber sie können zusätzlichen Schutz vor bestimmten Bedrohungen bieten. Das Hinzufügen von Überprüfungsrichtlinien kann die Leistung beeinträchtigen. Daher empfiehlt es sich, Leistungstests durchzuführen, um die Auswirkungen auf den API-Durchsatz zu beurteilen.
- Implementieren Sie Azure Web Application Firewall (WAF) vor der API Management-Instanz, um sich vor gängigen Exploits und Sicherheitslücken von Webanwendungen zu schützen.
- Wenden Sie benannte Werte mit Key Vault-Geheimnissen an, um vertrauliche Informationen in APIM-Richtlinien zu schützen.
- Verwenden Sie Application Gateway für den externen Zugriff auf eine interne APIM-Instanz, um die APIM-Instanz zu schützen und Hybridkonnektivität zu ermöglichen.
- Stellen Sie das API Management-Gateway in einem VNet bereit, um Hybridkonnektivität und erhöhte Sicherheit zu unterstützen.
- Das VNet-Peering bietet hervorragende Leistung in einer Region, ist aber auf maximal 500 Netzwerke begrenzt. Wenn mehr Workloads verbunden werden müssen, verwenden Sie ein Hub-Spoke-Design oder Azure Virtual WAN.
Bei der Kostenoptimierung geht es um die Suche nach Möglichkeiten, unnötige Ausgaben zu reduzieren und die Betriebseffizienz zu verbessern. Weitere Informationen finden Sie unter Übersicht über die Säule „Kostenoptimierung“.
- Da Verfügbarkeitszonen und virtuelle Netzwerke unterstützt werden müssen, haben wir uns für den Premium-Tarif von API Management entschieden, mit den Preisen für jede Region. Darüber hinaus wird Azure Functions in dieser Workload im Premium-Plan gehostet, da VNet-Zugriff benötigt wird.
- Für einen Proof of Concept oder Prototypen empfehlen wir die Verwendung anderer API Management-Tarife (z. B. Developer oder Standard).
Die Säule „Optimaler Betrieb“ deckt die Betriebsprozesse ab, die für die Bereitstellung einer Anwendung und deren Ausführung in der Produktion sorgen. Weitere Informationen finden Sie unter Übersicht über die Säule „Optimaler Betrieb“.
- API Management-Konfigurationen sollten als ARM-Vorlagen dargestellt werden, und Sie sollten einen Infrastructure-as-Code-Ansatz verfolgen.
- Verwenden Sie einen CI/CD-Prozess zum Verwalten, Versionieren und Aktualisieren von API Management-Konfigurationen.
- Erstellen Sie benutzerdefinierte Integritätstests, um den Status Ihrer API-Verwaltungsinstanz zu überprüfen. Verwenden Sie die URL
/status-0123456789abcdef
, um einen gemeinsamen Integritätsendpunkt für den APIM-Dienst im App-Gateway zu erstellen. - Die im Schlüsseltresor aktualisierten Zertifikate werden automatisch in API Management rotiert, wobei die Aktualisierung innerhalb von 4 Stunden erfolgt.
- Stellen Sie pro Region mindestens zwei API Management-Skalierungseinheiten bereit, die auf zwei Verfügbarkeitszonen verteilt sind. Diese Vorgehensweise maximiert die Verfügbarkeit und Leistung.
Diese Architektur ist auf GitHub verfügbar. Sie enthält alle erforderlichen Infrastructure-as-Code-Dateien und die Bereitstellungsanweisungen.
Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:
Hauptautoren:
- Pete Messina | Senior Cloud Solution Architect
- Anthony Nevico | Senior Cloud Solution Architect
Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.
- Leitfaden für das Cloud Adoption Framework für Azure API Management in Azure-Landzonen
- CI/CD für API Management mit Azure Resource Manager-Vorlagen
- Einführung in API Management
- Verwalten von APIs mit APIM
- API Management-Ressourcen für die ersten Schritte
Sehen Sie sich diese wichtigen Ressourcen an:
- APIOps
- Dokumentation zu Azure API Management
- API Management-Schlüsselkonzepte
- Dokumentation zu Application Gateway
Erfahren Sie mehr über diese wichtigen Dienste: