Wie sich REST API-Endpunkte für Cloud-Anwendungen absichern lassen
Wenn Entwickler APIs gestalten, müssen sie sich über deren Sicherheit Gedanken machen. Dieser Tipp bietet einen Einblick in kritische API-Komponenten.
Da Security eine Voraussetzung für jede Anwendungsbereitsstellung in der Public Cloud ist, müssen API-Architekten die Sicherheit an oberste Stelle rücken, wenn sie öffentlich APIs für Client-Anwendungen gestalten. Derzeit basieren die meisten öffentlichen APIs auf Representational State Transfer (REST) mit JavaScript Object Notation (JSON) oder Extensible Markup Language (XML). Die Flexibität und Offenheit von REST, JSON und XML machen eine sicheres Design möglich, um Service-Endpunkte und Daten vor Bedrohungen zu schützen.
Wenn Entwickler APIs gestalten, müssen sie Entscheidungen über das Security-Design der Komponenten treffen. Dazu gehören in erster Linie Authentifizierung, Autorisierung, Überwachung und Tracking, – also alle Funktionen, die zeigen, welcher Nutzer welche API, zu welchem Zeitpunkt und für welchen Zweck nutzt.
REST APIs, die über HTTP- oder HTTPS-Protokolle verfügbar sind, nutzen JSON oder XML für die Datenformatierung. REST führt diese grundlegenden Aktionen aus: GET (lesen), POST (erstellen), PUT (Update) und DELETE (löschen).
Wenn ein Entwickler eine REST API entwirft, ist es unerlässlich, dass nur authentifizierte und autorisierte Anwender damit arbeiten können. Der erste Schritt zur Absicherung des API-Endpunkts ist festzulegen, welche Aktionen gesichert werden müssen. Ein sicheres Design erfordert es, dass die API-Architekten die Authetifizierung, Autorisierung und den Schutz des Session-Status betrachten.
Die Absicherung des API-Designs ermöglicht es den Entwicklungsressourcen, die API zusammen mit DevOps-Ressourcen zu unterstützen und zu kontrollieren. Es erlaubt der IT- und den DevOps-Ressourcen zudem, sich auf übergeordnete Sicherheitsprobleme zu konzentrieren, statt jede öffentliche API zu kontrollieren, die ein Unternehmen freigibt.
Authentifizierung und API-Schlüssel
Keyed-Hash Message Authentication Code (HMAC) ist eine Option, die für Server und Client einen öffentlichen oder privaten Schlüssel bietet.
Wenn ein Entwickler eine REST API entwirft, ist es unerlässlich, dass nur authentifizierte und autorisierte Anwender damit arbeiten können.
Der öffentliche Schlüssel ist bekannt, den privaten Schlüssel kennt dagegen nur der jeweilige Server und Client. Der Client erzeugt einen einzigartigen HMAC oder Hash pro Anfrage an den Server, indem er die Anfragedaten mit dem Hash kombiniert und zusammen mit einem privaten Schlüssel als Teil der Anfrage sendet.
Der Server empfängt die Anfrage, regeneriert einen eigenen einzigartigen HMAC und vergleicht beide HMACs. Sollte sie identisch sein, wird der Client als vertrauenswürdig eingestuft und die Anfrage wird ausgeführt. Dieser Prozess wird häufig auch als „Secret Handshake“ bezeichnet.
Eine weitere Option ist die Verwendung des Protokolls Open Authorization (OAuth) innerhalb einer API zusammen mit einem JSON Web Token (JWT). Typischerweise spezifiziert OAuth vier Rollen: Ressourceneigentümer, Client, Ressourcen- sowie Autorisierungs-Server. Jeder Client, der eine API nutzt, erhält für die Authentifizierung einen einzigartigen API-Schlüssel, eingebettet in JWT.
Beide Optionen bieten Sicherheit in der API für die Authentifizierung, sind aber auch komplex einzurichten. Die Präferenzen eines Entwicklers, Architekten oder DevOps entscheiden darüber, welche Option ein Unternehmen wählt.
Autorisierung öffentliches APIs
Die Autorisierung öffentlicher APIs ist mit mehreren Methoden erreichbar. Allerdings sind der HTTP-Schutz sowie Whitelisting die bevorzugten Ansätze und für die Überwachung mit Security Intelligence Systemen verfügbar.
Der Schutz von HTTP mit einer REST API bedeutet, dass man Benutzerberechtigungen von REST für GET-, POST-, PUT- und DELETE-Aktionen festlegen muss. Nicht jeder API-Benutzer benötigt Zugang zu jeder Aktion. Das Einrichten einer Autorisierung basierend auf Berechtigungsstufen bedeutet, dass nur dieser Benutzer für zum Beispiel die Verwendung von DELETE autorisiert ist und tatsächlich Datensätze löschen kann.
Anwender sollten aber zumindest auf einem Minimallevel Zugriff auf gespeicherte Daten oder eine Liste von Informationen haben. Basierend auf den API-Nutzungsbedingungen eines Unternehmens, sollten zudem einige Nutzer berechtigt sein, die Datensätze zu aktualisieren.
Die Autorisierung über priviligierten HTTP-Zugriff ist nicht nur für Benutzer anwendbar, es lässt sich auch für Ressourcensammlungen verwenden. Das Festlegen von Autorisierungen auf Basis von Vorrechten oder der Rolle eines Nutzers ist relativ verbreitet und eine wirksame Schutzschicht für die API-Endpunkt-Sicherheit.
Anwender sollten aber zumindest auf einem Minimallevel Zugriff auf gespeicherte Daten oder eine Liste von Informationen haben.
Whitelisting ist eine weitere Option. Whitelisting ermöglicht Autorisierung basierend auf der URL. Die Aktionen GET, POST, PUT und DELETE bleiben zwar erhalten, allerdings ist die Verwendung dieser Methoden und vordefinierten Aktionen auf URLs beschränkt, die in einer Whitelist verzeichnet sind.
Wenn eine URL nicht in der Liste ist, wird etwa der HTTP-Fehlercode 403 (Verboten) zurückgegeben. Wenn diese Methode eingesetzt wird, ist es sinnvoll, dass die Server- und Systeminformationen von der Standardfehlermeldung entfernt wurden, so dass keine systeminternen Informationen preisgegeben werden.
Ein Vorteil von Whitelisting ist, dass es sich per Zugriffsprotokoll überwachen lässt und die Daten in Protokollen oder Security Intelligence Systemen überwacht werden.
Schutz des Sitzungsstatus
Die meisten Web-Services und APIs wurden ohne Status erstellt, wobei ein sogenannter Status-Blob innerhalb einer Transaktion gesendet wird. Für ein sichereres Design sollte man einen API-Schlüssel nutzen, um den Client-Status aufrechtzuerhalten, wenn die API serverseitigen Cache verwendet.
Das ist eine häufig verwendete Methode bei Web-Anwendungen und bietet zusätzliche Sicherheit, indem es Anti-Replay verhindert. Anti-Replay ist der Punkt, an dem Angreifer einen Blob ausschneiden und wieder einfügen, um autorisierte Benutzer zu werden. Um wirklich sicher zu sein, sollte man einen zeitlich begrenzten Verschlüsselungscode verwenden, der an API-Schlüssel, Datum und Zeit sowie eingehenden IP-Adressen kontrolliert wird.
Der Schlüssel für effektive Sicherheit ist schließlich die Schichtung der Überwachung. Das beinhaltet mehrere Backup-Systeme, falls eines kompromitiert wird. Die Daten und der Zugriff werden wiederum von der nächsten Schicht geschützt. Die Überwachung mit einer API erlaubt es einem Unternehmen, die Kontrolle über die API zu behalten und sicherzustellen, dass sie im Einklang mit den Verträgen und Nutzungsbedingungen verwendet wird und nicht als Zugangspunkt in die Firma oder deren Systeme dient.
Ein API-Architekt muss die API-Endpunkt-Sicherheit von Anfang an für die öffentliche API entwerfen, um den größten Nutzen für ein Unternehmen und deren Anwender zu bieten sowie die Sicherheit beim Entwicklungsteam zu belassen. Auch wenn eine API nicht verwendet wird, um eine Verbindung herzustellen oder vertrauliche sowie allgemein geschützte Daten zu übertragen, sind API-Endpunkte Zugangspunkte für Hacker, um sich unautorisierten Zugang zu verschaffen. Die Sicherheit dieser Endpunkte bietet Schutz für ein Unternehmen und ihre Kunden.
Folgen Sie SearchEnterpriseSoftware.de auch auf Facebook, Twitter und Google+!
