© Stmool/Shutterstock.com
APIs durch Azure-Dienste absichern - Teil 3

Managed Identity für Web-APIs


Wer nicht als Kernaufgabe die Entwicklung von Sicherheitsprotokollen oder darauf bezogenen Code hat, sollte solchen Code nicht schreiben, sondern auf fertige Bibliotheken und Dienste zurückgreifen. Auch kleine Bugs können sonst in diesem Bereich katastrophale Auswirkungen haben.

Wer mich kennt oder meine Artikel und Vorträge verfolgt, weiß, dass ich ein Verfechter von Platform as a Service (PaaS) und Serverless bin. Ich habe zwar als begeisterter Entwickler Spaß am Lösen kniffliger Softwareprobleme, versuche aber meinen Spieltrieb in Zaum zu halten, wenn es um die professionelle Arbeit geht. Diese Einstellung finde ich essenziell wichtig in Bezug auf sicherheitsbezogenen Code.

In der Cloud bezieht sich meine Aussage auf mehr als nur den C#-Code der Web-APIs und Webapplikationen. Er bezieht sich auch auf die sicherheitsbezogenen Konfigurationen der API-Cloud-Umgebung, die heutzutage bei produktiv eingesetzten SaaS-Lösungen in Form von Infrastructure as Code (IaC) vorliegen sollte, also bei Azure als ARM Templates, PowerShell- oder Bash-Skripts.

Azure bietet eine Vielzahl von Diensten, die Entwicklungsteams viele Kopfschmerzen in Sachen Security abnehmen. Beispiele dafür sind Azure Active Directory (AAD), Azure Role-based Access Control (RBAC), Azure Key Vault, Azure Managed Identities oder Azure Private Endpoints. Wer Azure in der Praxis einsetzt und mit diesen Diensten noch nicht vertraut ist, sollte sich Zeit nehmen, diese Wissenslücke zu schließen. Der dafür notwendige Aufwand zahlt sich in kurzer Zeit aus. Erstens spart man sich die Entwicklung von unnötigem eigenem Code und zweitens sinkt das Risiko eines erfolgreichen Angriffs auf die eigenen Anwendungen in der Cloud. Die Dokumentation von Azure ist eine gute Quelle für Informationen. Darüber hinaus bietet Microsoft unzählige Videos und Onlinetutorials an, mit denen man in die Materie einsteigen kann.

Basiswissen

Dieser Artikel ist der dritte Teil einer Serie über die Absicherung von Web-APIs in der Microsoft-Azure-Plattform. Er setzt daher Basiswissen insbesondere über die Konzepte und das Management von Web-API- und Web-App-Security in Azure Active Directory (AAD) voraus. Darüber hinaus können die hier besprochenen Sicherheitsmaßnahmen gut mit dem Konzept der Private Endpoints verbunden werden, über die sich der Zugriff auf Backend APIs noch weiter einschränken und sich deshalb die Angriffsfläche einer Cloud-Anwendung verkleinern lässt. Private Endpoints wurden im ersten Teil der Artikelserie erklärt.

Leserinnen und Lesern, die mit AAD oder Private Endpoints nicht oder nur wenig vertraut sind, empfehle ich, bei Unklarheiten einen Blick auf die beiden vorherigen Artikel dieser Serie zu werfen.

In diesem Artikel möchte ich zwei der zuvor genannten Dienste, nämlich AAD und Managed Identities, herausgreifen und sie im Rahmen eines nicht so einfachen, aber aus meiner Sicht sehr praxisrelevanten Szenarios zeigen. Wir nutzen Managed Identity in diesem Artikel nämlich nicht nur im Rahmen des Zugriffs auf von Microsoft erstellte PaaS- und Serverless-Dienste, sondern für Machine-to-Machine-(M2M)-Authentifizierung zwischen eigenen Web-APIs. Diese Pro-blemstellung findet man angesichts des anhaltenden Trends hin zu verteilten Cloud-Anwendungen in vielen SaaS-Lösungen. Architekturmuster, die in diesem Zusammenhang oft genannt werden, sind zum Beispiel Microservices oder Backend-for-Frontend (BfF). Abbildung 1 stellt das Szenario, auf das dieser Artikel eingeht, grafisch dar. Im Fokus steht die in der Abbildung blau hinterlegte Kommunikation zwischen Frontend API und Backend APIs. Eins der Backend APIs kommt von Microsoft – hier beispielhaft Azure Blob Storage – und eins ist selbst entwickelt.

stropek_webapi_teil3_1.tif_fmt1.jpgAbb. 1: Machine-to-Machine Authentication

Azure Managed Identities

Starten wir mit einer kurzen Einführung in Azure Managed Identities. Es ist nicht das Ziel dieses Artikels, Managed Identities umfassend zu erklären. Microsoft bietet dafür in der Azure-Dokumentation eine umfangreiche Sammlung an konzeptionellen Beschreibungen und Codebeispielen an. Diese Einführung soll Leserinnen und Lesern, die bisher nicht mit Managed Identities in Berührung gekommen sind, genug Wissen vermitteln, um dem restlichen Text gut folgen zu können.

Die Grundidee von Managed Identities ist einfach: weg mit Secrets. Keine Passwörter oder Keys mehr, wenn man von einem Azure-Dienst wie Azure App Service auf Azure-Services wie Azure SQL Database, Cosmos DB, Storage oder Key Vault zugreifen will. Wenn es keine Secrets mehr gibt, dann können diese auch nicht in falsche Hände geraten. Natürlich ist es technisch nicht möglich, dass sich Secrets einfach in Luft auflösen. Tatsächlich gibt es sie weiterhin, sie werden nur von Azure anstatt vom eigenen Code verwaltet. Wenn beispielsweise ein C#-Web-API lokal im Debugger läuft, holen sich die Managed-Identity-bezogenen NuGet-Pakete (Azure.Identity) die Identität der Entwicklerin von Visual Studio oder vom Azure CLI und nutzen sie zum Zugriff auf Azure-Dienste der jeweiligen Entwicklungsumgebung. Sobald die Anwendung in Azure läuft, stellt Azure unter einer speziellen IP-Adresse (169.254.169.254) ein Web-API namens Azure Instance Metadata Service (IMDS) bereit, von dem sich die App zur Laufzeit Access Tokens holen kann [1]. Wir betrachten Managed Identity in diesem Artikel in Verbindung mit Azure App Service. Managed Identity gibt es jedoch genauso für virtuelle Maschinen und – mit gewissen Einschränkungen – auch in Verbindung mit Azure Kubernetes Service (AKS).

IMDS ist ...

Neugierig geworden? Wir haben diese Angebote für dich:

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang