NEWS | BLOG | THINGS

Sichere Kommunikation zwischen Azure Diensten innerhalb einer SaaS Lösung

Innerhalb einer Software as a Service (SaaS) Lösung interagieren viele Dienste eines Cloud-Anbieters untereinander. Die gegenseitige Kommunikation der Dienste muss vor einem Zugriff von außen und von fremden Diensten geschützt werden. Aus der Erfahrung zeigt comlet am Beispiel von Microsoft Azure welche Methoden eingesetzt werden können und deren Vor- und Nachteile. 

Eine gängige Herausforderung für Software-Entwickler ist die Absicherung einer Anwendung gegen unberechtigte Zugriffe auf Daten und Funktionen. Das trifft auch auf einen Dienst zu, der in einer Cloud betrieben wird. Die Verwaltung von Geheimnissen, Berechtigungsnachweisen, Zertifikaten und Schlüsseln ist in der Cloud eine Herausforderung, da diese Daten zwischen Diensten ausgetauscht werden müssen, die Cloud-Dienste jedoch öffentlich im Internet verfügbar sind. 

Microsoft Azure bietet hauptsächlich drei Möglichkeiten, um Anfragen an Azure Dienste zu authentifizieren:

 

  1. Access Keys 
  2. Shared Access Signatures (SAS) 
  3. Azure Active Directory
 

Diese drei Methoden unterscheiden sich grundsätzlich in ihrer Funktion, Verwaltungsaufwand, Zugriffsbereich und Geltungsdauer.

 

Access Keys

 

Access Keys sind vom System generierte Schlüssel, die vollständigen Zugriff auf die Konfiguration sowie auf die Daten des jeweiligen Azure Dienstes bieten. Daher wird empfohlen die Zugriffsschlüssel sicher aufzubewahren (z.B. in einem Azure Key Vault) und regelmäßig auszutauschen, um unbefugte Zugriffe möglichst zu vermeiden. Mit den Schlüsseln können einfach und schnell Anfragen authentifiziert werden. 

Diese Methode eignet sich daher sehr gut zum Testen während der Entwicklung einer Saas Lösung. Comlet empfiehlt jedoch, Access Keys nicht in einem Produktivsystem zu verwenden und eine Authentifizierung mit Access Keys nicht zuzulassen.

  

Shared Access Signatures (SAS)

 

Andere Authentifizierungsmethoden ermöglichen eingeschränktere Zugriffe und Privilegien auf einzelne Dienste und Funktionen. Eine dieser Möglichkeiten ist die Authentifizierung mit Shared Access Signatures. SAS. Sie basiert auf Tokens, die aus einer oder mehreren Ressourcen des Dienstes, der Geltungsdauer und den Berechtigungen generiert und mit einem Access Key signiert werden. 

Die SAS-Tokens ermöglichen einen delegierten Zugriff auf Ressourcen eines Azure Dienstes. Durch SAS besteht die Möglichkeit zu steuern, auf welche Ressource mit welchen Berechtigungen und für wie lange zugegriffen werden darf.

 

Nachteil Access Keys und Shared Access Signatures

 

Analog zu Access Keys sollten auch Shared Access Signatures regelmäßig ausgetauscht werden, um die Sicherheit zu gewährleisten. Durch die regelmäßige Erneuerung der Anmeldeinformationen dieser zwei Authentifizierungsmöglichkeiten entsteht ein ständiger Verwaltungsaufwand, um eine sichere Kommunikation zwischen Diensten zu gewährleisten.

 

Azure Active Directory mit Managed Identities

 

Mit Managed Identity bietet die Azure Cloud eine automatisch verwaltete Identität in Azure Active Directory. Mit dieser Funktion können sich Azure Dienste an anderen Azure Diensten authentifizieren, ohne dass Anmeldeinformation verwaltet werden müssen. Eine Managed Identity kann einen oder mehreren Diensten zugewiesen werden.

 

Über das Identitäts- und Zugriffsmanagement der Azure Dienste können Managed Identities Zugriff auf Ressourcen anderer Dienste erhalten. Dies geschieht über eine rollenbasierte Zugriffskontrolle, bei der jede Rolle eine Funktion besitzt. Eine Rolle verfügt nur über die Rechte, die erforderlich sind, um ihre Funktion auszuführen. Azure bietet bereits viele vorgefertigte Standardrollen an. Falls diese nicht ausreichend sind, können auch benutzerdefinierte Rollen mit benutzerdefinierten Berechtigungen angelegt werden. Bei der Zuteilung der Rollen sollte beachtet werden, dass die Identität nicht mehr Berechtigungen bekommt als nötig, damit unautorisierte Zugriffe vermieden werden.

 

Wenn ein Azure Dienst mit einer zugewiesenen Identität Anfragen an einen anderen Azure Dienst senden möchte, fordert er zuerst einen Authentifizierungstoken von Azure Active Directory an. Dieser Token wird mit der Anfrage an den Zieldienst gesendet. Wenn die Managed Identity des Quelldienstes die benötigte Rolle mit den ausreichenden Berechtigungen für die angefragte Operation besitzt, wird die Anfrage autorisiert. Somit können Azure Dienste sicher untereinander kommunizieren, ohne dass Anmeldeinformationen verwaltet werden müssen.

 
 

Zusammenfassung

 

 

Grundsätzlich sind Access Keys ein probates Mittel, um während der Entwicklung eine autorisierte Kommunikation mit vollem Zugriff auf einen Dienst einfach und schnell zu realisieren. Shared Access Signatures eignen sich für einen eingeschränkten Zugriff für z.B. Dienste oder Benutzer, die nur einen zeitbegrenzten Zugang benötigen. Um eine sichere und kontinuierliche Kommunikation mit gezielten Berechtigungen sicherzustellen, ist die Authentifizierung mit einer Managed Identity jedoch die beste Möglichkeit. Im Vergleich zu den anderen Authentifizierungsmöglichkeiten entfällt der Verwaltungsaufwand und das Risiko Zugriffsschlüssel Unbefugten zugänglich zu machen.

 

Allerdings ist es nicht in allen Szenarien möglich eine Managed Identity zu benutzen. Denn nicht alle Dienste unterstützen diese Authentifizierungsmethode oder andere Umstände verhindern die Benutzung. Wenn es keine Möglichkeit gibt außer Geheimnisse, Schlüssel oder Kennwörter selbst zu verwalten, müssen geeignete Maßnahmen getroffen werden, um solche sensible Anmeldeinformationen sicher zu speichern.

 

Zum Beispiel können die Daten regelmäßig erneuert werden und in einem Azure Key Vault abgelegt werden. Auf diesen kann wiederum ein Azure Dienst, mit einer berechtigten Managed Identity, zugreifen und sich mit den darin befindenden Anmeldedaten beim Zieldienst authentifizieren.

 

Sie möchten mehr Details erfahren?

Rufen Sie uns an

+49 6332 811 0

Schreiben Sie uns

Es freut uns von Ihnen zu hören! Wir melden uns umgehend bei Ihnen zurück.