Server-lose Architekturen absichern

Verkleinerte Angriffsfläche

24. August 2020, 07:00 Uhr   |  Christine Schönig/wg

Verkleinerte Angriffsfläche
© Check Point

Der Wechsel zu Server-loser Architektur macht die IT-Absicherung sowohl einfacher als auch schwieriger: einfacher, weil sich die Angriffsfläche extrem verkleinern lässt; schwieriger, weil die Fachleute Neuland betreten. Amazon Web Services Lambda eignet sich als anschauliches Beispiel.

In traditionellen IT-Architekturen haben die Administratoren die Hoheit über alle Bereiche des Unternehmensnetzwerks. Wechselt ein Unternehmen jedoch zum Konzept des „Serverless Computings“, gibt es die Kontrolle über viele Bereiche an den gewählten Cloud-Anbieter ab. Dazu gehören die Administratorrechte oder die Segmentierung des Netzwerks. Was jedoch beim Unternehmen verbleibt, ist die Kontrolle über die Anwendungen und deren Konfiguration. Dort müssen daher die Schutzmaßnahmen greifen und dieser Umstand muss in die Planung der IT-Sicherheit einfließen. Besonders das Konzept der geringsten Zugriffsrechte (Least Privilege) kann sich, korrekt angewandt, als großer Vorteil erweisen.

In Server-losen Architekturen zerfallen die großen Container, die umfangreiche Zugriffsrechte besitzen, in tausende kleiner Funktionen, deren Privilegien und Auswirkungen sehr genau definiert sein können. Hier spielt also ein gutes IAM (Identity- und Access-Management) seine Stärken aus. Am Beispiel eines AWS Lambda S3 Buckets lässt sich gut zeigen, wie man deren Konfiguration optimiert.

Grundsätzlich sollte man davon ausgehen, dass jede Funktion, jeder Container oder Bucket so wenig Privilegien erhält wie möglich. Dieses Prinzip kommt nach wie vor zu selten wirklich zur Anwendung, doch lässt es sich mit einer Server-losen Architektur erstmals sehr genau umsetzen.

Bild 1. Einrichtung eines S3-Buckets.
© Check Point

Bild 1. Einrichtung eines S3-Buckets.

Werfen wir einen Blick auf die Einrichtung eines S3-Buckets und gehen von dieser Funktion als Grundlage aus, wie in Bild 1 dargestellt.

Eine schnelle Installation könnte dann aussehen, wie Bild 2 es zeigt.

Bild 2. Schnelle Installation eines S3 Buckets.
© Check Point

Bild 2. Schnelle Installation eines S3 Buckets.

Diese Konfiguration erlaubt allen S3-Buckets alle möglichen Funktionen des S3. Natürlich funktioniert das ohne Fehler, weil es keine Zugriffsbegrenzung gibt. Der Code läuft also reibungslos bei jeder Anfrage. Sicher ist das jedoch nicht: Sollte ein Hacker sich Zugriff verschaffen und den S3-Bucket übernehmen, hat er umfangreiche Handlungsmöglichkeiten, weil dieser Bucket unbegrenzte Zugriffsrechte erhalten hat. Eine optimierte, auf Sicherheit getrimmte Version würde daher so aussehen, wie in Bild 3 dargestellt.

Bild 3. Stärker auf Sicherheit ausgelegte Version der S3-Bucket-Einrichtung.
© Check Point

Bild 3. Stärker auf Sicherheit ausgelegte Version der S3-Bucket-Einrichtung.

Die Funktion ist nun auf den eigenen S3-Bucket beschränkt, was eine Seitwärtsbewegung im Netzwerk hin zu anderen Buckets eindämmt. Jedoch besitzt die Funktion weiterhin volle S3-Berechtigung. Will man nun das Prinzip der geringsten Zugriffsrechte anwenden, so wäre der Funktion nur eine Aktion erlaubt: ‚GetObject‘. Diese Änderung führt dazu, dass die Funktion nur Dateien im eigenen S3-Bucket lesen kann. Sie hat keinen Zugriff auf andere Buckets und kann zudem den eigenen weder löschen noch darin schreiben. Ein Angreifer, der diesen Bucket infiltriert, sitzt buchstäblich in der Klemme.

Hinzu kommt, dass Funktionen und ihre Buckets in einer Server-losen Architektur eine sehr kurze Lebenszeit haben können und haben sollten. Dies lässt sich ebenfalls konfigurieren. Hier sollte die Verweildauer einer Funktion, bevor sie zerfällt und neu aufgesetzt wird, so gering wie möglich eingestellt sein. Denn ein Angreifer müsste dann seine Missetat innerhalb dieser kurzen Zeitspanne begehen, um erfolgreich zu sein. Sobald die Funktion sich wiederherstellt, muss er von vorne beginnen, denn der Container, den er gerade infiltriert hatte, existiert nicht mehr.

Container versus Mikrofunktionen

Der Umstieg auf eine Server-lose Architektur erfordert ein großes Umdenken, genaue Planung und viel Arbeit – besonders um die IT-Sicherheit aufrecht zu erhalten und umzubauen. Jedoch belegt der Blick auf den Unterschied zwischen Containern und Mikrofunktionen (Micro Functions), warum sich die Mühe lohnt. Ein Container, meist sehr groß, enthält sehr viele Funktionen und führt sie aus; daher muss er sehr viele Zugriffsrechte erhalten. Er stellt also ein lukratives Ziel für Kriminelle dar (Bild 4).

Bild 4. Ein Container enthält sehr viele Funktionen und führt sie aus; daher muss er sehr viele Zugriffsrechte erhalten.
© Check Point

Bild 4. Ein Container enthält sehr viele Funktionen und führt sie aus; daher muss er sehr viele Zugriffsrechte erhalten.

Mikrofunktionen dagegen ermöglichen eine detaillierte, fein abgestufte Rollenverteilung über das IAM – für jede einzelne dieser kleinen Funktionen. Die IT-Absicherung ist so auf den jeweiligen Kontext bezogen und abgestimmt. Ein Angreifer, dem es gelingt, eine dieser Funktionen zu kapern, hat sich damit nur deren beschränkten Spielraum verschafft. Die große Sammlung von Privilegien, wie sie Container haben, bleibt ihm verwehrt und seine Handlungsmöglichkeiten, um Schaden in den Systemen anzurichten, sind stark beschnitten.

Bild 5. Mikrofunktionen erschweren Angriffsversuche.
© Check Point

Bild 5. Mikrofunktionen erschweren Angriffsversuche.

Jede der in der Grafik gezeigten Mikrofunktionen lässt sich über Policies kontrollieren. Das ist eine große Chance, aber auch eine Herausforderung, weil sie zu Beginn viel Aufwand erfordert – und Konzentration. Korrekt angewandt allerdings schrumpft die Angriffsfläche enorm, weil jede Mikrofunktion nur das tun darf, was sie tun muss, um ihre Aufgabe zu bewältigen.

Eine Security-Automatisierung kann den Fachleuten bei der Einrichtung und Verwaltung unter die Arme greifen, um das bestmögliche aus Serverless Computing für ein Unternehmen herauszuholen: die Kosten stark zu reduzieren, die Kontrolle über die Zugriffsrechte im Netzwerk enorm zu erhöhen und die IT-Sicherheit auf eine neue Ebene zu heben.

Christine Schönig ist Regional Director Security Engineering CER, Office of the CTO bei Check Point Software Technologies, www.checkpoint.com.

Auf Facebook teilenAuf Twitter teilenAuf Linkedin teilenVia Mail teilen

Verwandte Artikel

Check Point Software Technologies GmbH

Cloud Security