Seite 2: Das Least Privilege Principle

Inhaltsverzeichnis

Cloud-Umgebungen erlauben oft eine feingranulare Einstellung der Zugriffsrechte, die sowohl den Eingang als auch den Ausgang einer Serverless Function steuern. Aufseiten des Eingangs legen die Zugriffsrechte fest, welche anderen Cloud-Komponenten die Funktion mit welcher Art von Payload anstoßen darf. Aufseiten des Ausgangs dagegen bestimmen die Rechte, auf welche anderen Komponenten die Funktion mit welchen Aktionen zugreifen kann.

Dank der feinen Granularität lassen sich Cloud-Komponenten und somit auch Serverless Functions in der Theorie bestmöglich gegen unberechtigte Zugriffe absichern. In der Praxis ist die Vielfalt der Rechte aber häufig äußerst komplex und verwirrend. Daher greifen Teams gerne auf übergreifende Rechte zurück und öffnen damit das Tor für Angriffsszenarien unnötig weit. Der Object Store S3 in AWS – vergleichbar mit einem Dateisystem – unterscheidet etwa 50 Zugriffsberechtigungen für Buckets und Objects. Eine allowAll-Policy in Verbindung mit Wildcards ist daher mehr als verführerisch.

Auch wenn das Auffinden der passenden, minimalen Berechtigung nicht einfach ist und durchaus zu unerwarteten Nebenwirkungen zur Laufzeit führen kann, lohnt sich der Aufwand. Als Best Practice hat sich etabliert, für jede einzelne Funktion eine eigene Rolle mit genau den passenden, minimalen Zugriffsrechten zu definieren. Übergreifende Rollen sollten tabu sein.

Was für die Rollen zutrifft, gilt ebenso für die Rechte innerhalb einer Rolle. Statt beispielsweise in der AWS-Welt einer Rolle ein generelles Lese- und Schreibrecht auf S3 Buckets und Objects zu geben, ist es sinnvoll, diese Rechte explizit getrennt aufzuführen. Ändert sich die Logik der Funktion, lassen sich die Rechte anpassen, ohne das Least Privilege Principle zu brechen.

Für den Zugriff auf Third-Party-Systeme aus der Cloud heraus sollten Teams ebenfalls eigene Rollen mit minimalen Rechten erstellen und den zugreifenden Serverless Functions zuweisen. Bei den meisten Cloud-Providern lassen sich globale und übergreifende Rechte an zentraler Stelle deaktivieren oder durch Tools aufspüren. Davon sollten Teams bei der Cloud-Entwicklung unbedingt Gebrauch machen.

Min-Max Principle

Je breiter die Verantwortung einer Funktion, desto umfangreicher ist das Set der erforderlichen Zugriffsrechte und somit die Gefahr, das Least Privilege Principle zu brechen. Eine einzelne Funktion sollte daher dem Single-Responsibility Pattern folgen und somit die minimal umsetzbare Funktionalität aufweisen. Für das Gesamtsystem ergibt sich dadurch die maximale Granularität.

Dabei gilt es jedoch zu beachten, dass eine äußerst feine Granularität der einzelnen Funktionen zwar die Sicherheit des Systems verbessert, gleichzeitig aber eine erhöhte Komplexität an anderen Stellen mit sich bringen kann. Unter anderem muss gegebenenfalls eine Funktion ihren State an eine andere übergeben. Zudem kann es in einer Kette von Aufrufen zu unnötiger Latenz durch mehrfachen Kaltstart der Serverless Functions kommen. Die Herausforderungen sind jedoch nicht unlösbar.

Best Practice ist, sich zunächst grundsätzlich für die höhere Sicherheit und somit für die feinere Granularität der Funktionen zu entscheiden und erst bei nicht handhabbarer Komplexität Kompromisse einzugehen. Letztere sollten bewusste Entscheidungen sein und vermerkt werden, um zu verhindern, dass der Sicherheitskompromiss erhalten bleibt, wenn er durch Änderung der Funktion obsolet geworden ist.

Isolierter Kontext

Eine Serverless Function kann durch Events von diversen Komponenten aus angestoßen werden. Häufig lässt sich innerhalb der Funktion nicht feststellen, wer das Event beziehungsweise die darin enthaltene Payload ursprünglich mit welchem Zweck erzeugt hat. Insbesondere ist nicht sichergestellt, dass die Payload des Events im Vorfeld validiert und auf schädlichen Inhalt geprüft worden ist.

Eine Serverless Function sollte daher grundsätzlich als isolierter Security Context und eingehende Daten als potenziell schädlich und unsicher gelten. Umgekehrt sollten Funktionen ausgehende Daten niemals ungeprüft an andere Cloud-Komponenten weiterleiten.

Es empfiehlt sich, eingehende Events und deren Payload zunächst mit einer Security-Library zu prüfen und gegebenenfalls zu bereinigen. Serverless Functions sollten ausgehende Events und deren Payloads stets neu erzeugen und nicht weiterleiten. Wichtig ist, die Security-Libraries über alle Funktionen hinweg zu verwenden und sie zentral zu verwalten sowie zu aktualisieren.

Security Gateway

Die bisher genannten Ansatzpunkte bezogen sich direkt auf die Sicherheit der Serverless-Funktionen. Zusätzliche Ansatzpunkte greifen bereits im Vorfeld.

Dabei gilt als Best Practice, niemals Zugriff auf eine Serverless-Funktion von außen beispielsweise durch Nutzerinteraktion zu ermöglichen. Stattdessen sollten Teams eine zusätzliche Sicherheitsebene wie ein API Gateway oder eine Web Application Firewall (WAF) verwenden. Der Layer ermöglicht das Filtern und Prüfen der eingehenden Daten auf Request-/Response-Mapping-Ebene und erfüllt damit das Fail Fast Principle.

Eine Authentifizierung kann ebenfalls innerhalb des Gateways stattfinden. Da sie nur einmalig pro Aufruf erforderlich ist, bringt sie als positiven Nebeneffekt eine Entlastung der im Verlauf der Use-Case-Abarbeitung aufzurufenden Serverless Functions mit sich.

Sicherheitsaspekte wie DDoS, Traffic Throtteling oder Rate Limiting lassen sich ebenfalls an der Grenze zwischen Außenwelt und Cloud mit einem Security-Gateway elegant lösen. Es vermeidet zudem einen durch Angriffe stark steigenden Datenverkehr und die damit verbundene Kostenexplosion.

Secrets sind top secret

Serverless Functions greifen oft lesend oder schreibend auf andere Komponenten zu. Dafür sind die zugehörigen Credentials erforderlich, die sich innerhalb derselben Cloud über das integrierte Identity Access Management abbilden lassen. Gefährlich wird es, wenn Serverless Functions auf die Clouds anderer Provider, auf die Infrastruktur im eigenen Rechenzentrum oder auf Third-Party-Systeme zugreifen. Die dabei übertragenen sensiblen Daten sind für Angreifer Gold wert. Selbst abgelaufene Passwörter können bei der Vorhersage des aktuell gültigen Passworts nützlich sein (Rainbow Table Attacks). Daher ist ein sauber aufgesetztes Secrets Management ein wichtiger Baustein der Serverless-Security-Policy.

Secrets sollten niemals innerhalb des Quellcodes, in Umgebungsvariablen oder im Source-Code-Management-System zu finden sein. Das gilt nicht nur für die Plain-Text-Variante, sondern auch die verschlüsselte Form. Stattdessen sollten Teams eine spezielle Secrets Engine verwenden. Sie ermöglicht sowohl das Verwalten der Secrets inklusive des Abrufs zur Laufzeit als auch das anfängliche Generieren und die automatische Rotation.

Nahezu jeder Cloud-Provider bietet Secrets Engines oder Secrets Stores als integrierten Service an. Wer nach einer plattformunabhängigen Umsetzung sucht, kann auf Tools wie Hashicorp Vault, Akeyless Vault oder Conjur Secrets Manager zurückgreifen.

Sicherer Datenaustausch

Da Serverless-Anwendungen stark verteilt sind und auf eine umfangreiche asynchrone Kommunikation über Events setzen, bieten sie besonders viele Angriffsflächen, den Datenaustausch zwischen den einzelnen internen und externen Komponenten einer Anwendung abzugreifen oder zu verfälschen.

Als Best Practice zum Vermeiden von Attacken wie Men in the Middle sollten Anwendungen überall, wo es möglich ist, HTTPS zur Kommunikation verwenden. Darüber hinaus sollten sie SSL-Zertifikate von Remote Identities stets prüfen und im Falle eines Prüffehlers die zugehörige Kommunikation und weitere Verarbeitung abbrechen. Antworten von Third-Party-Services sollten grundsätzlich als unsicher angesehen und entsprechend vor der Verarbeitung geprüft und gegebenenfalls bereinigt oder abgelehnt werden.

Security Coding Conventions

Nicht zuletzt gilt für jede Software, dass Unternehmen den Aspekt Security bereits während des Designs und der Entwicklung aktiv mitberücksichtigen sollten. Serverless Functions stellen keine Ausnahme dar. Ganz im Gegenteil: Da Angreifern das Ziel der (virtualisierten) Server fehlt, konzentrieren sich deren Bemühungen in der Welt der Serverless Applications auf die Business-Logik.

Als Best Practice sollten Teams Security Coding Conventions aufbauen, etablieren und (automatisch) prüfen, welche sich an den OWASP-Empfehlungen und insbesondere an den Sicherheitsrisiken der OWASP Top 10 orientieren.