Was ist serverlose Sicherheit?

Was ist serverloses Computing?

Serverloses Computing bezieht sich auf ein Cloud-Computing-Modell, bei dem der Cloud-Anbieter den Server betreibt und die Zuweisung von Maschinenressourcen dynamisch verwaltet. AWS Lambda Functions, Google Cloud Functions und Azure Functions sind beliebte serverlose Frameworks, die Anwendungen erstellen.

Eine serverlose Architektur bietet den Vorteil einer automatisierten, nahezu unbegrenzten Skalierung. Zwischen Entwicklern und bereitgestelltem Code steht nur sehr wenig, was die Markteinführung beschleunigt und die Wartung und das Testen einzelner Funktionen erleichtert. Schließlich wirkt sich die tatsächliche Menge der verbrauchten Anwendungsressourcen auf die Preisgestaltung aus, d. h. Sie zahlen nur für das, was Sie nutzen, was zu niedrigeren Kosten führt.

Serverless bedeutet eine zusätzliche Verlagerung der Verantwortung vom Kunden zum Cloud-Anbieter. Da keine Infrastruktur beteiligt ist, verringert sich der Betriebsaufwand erheblich.

Durch die Verlagerung des Infrastrukturmanagements auf Ihren Cloud-Anbieter können Sie sich auf die Entwicklung von Lösungen konzentrieren, die Ihrem Unternehmen und Ihren Kunden dienen. Es hilft Ihnen, sich auf Ihre einzigartigen Wettbewerbsvorteile zu konzentrieren, und führt häufig zu Kosteneinsparungen nicht nur bei der Rechenleistung, sondern auch durch die Verlagerung von Mitarbeitern in die Entwicklung.

Wie verbessert Serverless die Sicherheit?

Hier sind einige wichtige Punkte:

1. Cloud-Anbieter kümmern sich um Betriebssystem, Laufzeitsicherheit und Patching. Bei der Bereitstellung einer serverlosen Anwendung geben Sie die Kontrolle über den Großteil des Stacks an Ihren Cloud-Anbieter ab, und dieser stellt Dienste wie die Schlüsselverwaltung bereit. Sie verfügen nicht mehr über OS , Administratorrechte, SSH und Segmentierung. AWS, Microsoft und Google sind zuverlässig darin, ihre Teile des Stacks gepatcht und sicher zu halten, sodass die Bereitstellung eines größeren Teils des Stacks in dieser Hinsicht sicherlich eine Verbesserung darstellt.
2. Staatenlos/Vergänglich. Darüber hinaus erschwert die kurzlebige, zustandslose Natur serverloser Datenverarbeitung das Leben von Angreifern. Serverlose Funktionen wie AWS Lambda werden einige Sekunden lang ausgeführt und sterben dann ab. Behälter werden recycelt. Die Tatsache, dass serverlose Funktionen ohne Speicher kommen und gehen, verringert das Risiko langfristiger Angriffe.
3. Einblick in serverlose Anwendungen – der Vorteil. Die Tatsache, dass serverlose Anwendungen als eine große Anzahl kleiner Funktionen in der Cloud strukturiert sind, bietet ein fantastisches Sicherheitspotenzial. Anwendungssicherheitstools unternehmen oft unglaubliche Anstrengungen, um Ihre gepackte Anwendung zu analysieren und zu instrumentieren, nur um den internen Fluss Ihrer Anwendung beobachten oder filtern zu können.
4. Kleinerer Mikroservice = Die Fähigkeit, geeignete, minimale Rollen für jede Funktion zu konstruieren. Der Wechsel zu einem kleineren Mikroservice ermöglicht Ihnen ein feinkörnigeres IAM. Sie haben die Möglichkeit, auf jedes dieser kleinen Dinge Sicherheitsrichtlinien anzuwenden, die Ihre Angriffsfläche erheblich reduzieren können.

Solange eine Funktion innerhalb eines Containers Lesezugriff auf S3 benötigt, verfügen auch alle Funktionen innerhalb dieses Containers über diese Berechtigung. Mit AWS Lambda haben Sie die Möglichkeit, Berechtigungen auf einzelne Funktionen anzuwenden und sicherzustellen, dass diese Berechtigungen nur auf den kleinsten erforderlichen Umfang beschränkt sind. Wenn in einer Ihrer Funktionen eine Schwachstelle vorliegt, erhält ein Angreifer nur Zugriff auf die eingeschränkten Funktionen dieser Funktion, nicht jedoch auf die umfangreichen Berechtigungen, die für die Gewährung eines Containers erforderlich sind.

Was sind serverlose Sicherheitsherausforderungen?

Mit der sich verändernden Struktur der serverlosen Anwendung ergeben sich einige neue Herausforderungen.

1. Die Sichtbarkeit der Sicherheit wird schwieriger. Die Gesamtmenge an Informationen und die Anzahl der Ressourcen erhöht sich bei Serverless. Dies beeinträchtigt Ihre Fähigkeit, alle Daten zu verstehen. Bei einer Milliarde Ereignissen pro Tag in Ihrem Protokoll ist es eine Herausforderung, aus den Datenbergen Informationen zu gewinnen, um eine echte Beobachtbarkeit zu gewährleisten.
2. Protokolle, Vektoren und Angriffspunkte haben sich auf jede Funktion vervielfacht, und Protokoll = ein potenzieller Angriffspunkt. Dies erfordert einzigartige Ansätze für die Sicherheit von Google Functions, Azure Functions und AWS Lambda.
3. Mehr Ressourcen = mehr Verwaltungsberechtigungen. Mehr Ressourcen bedeuten mehr zu verwaltende Berechtigungen, was zu Herausforderungen bei der Festlegung der Berechtigungen für all diese Interaktionen führt. Automatisierte Technologie kann Konfigurationsrisiken erkennen und automatisch Funktionsberechtigungen mit den geringsten Privilegien generieren.
4. Beobachtbarkeit in serverlosen Apps – Die Herausforderung. Serverlose Apps nutzen verschiedene Dienste von verschiedenen Cloud-Anbietern über mehrere Versionen und Regionen hinweg. Um Ihre Angriffsfläche und potenzielle Risiken zu verstehen, benötigen Sie einen umfassenden Überblick über Ihr gesamtes serverloses Ökosystem. Mit der Verbreitung Ihrer App kann es immer schwieriger werden, diese sicherheitsorientierte Ansicht zu erstellen und zu warten.

Wo kann serverlose Sicherheit bereitgestellt werden?

Bei der serverlosen Anwendung gibt es keinen Platz für klassische Sicherheit wie WAF, Firewall und IDS. Der Aufbau von Mauern zwischen Angreifern und Ressourcen ist aus mehreren Gründen nicht einfach.

1. Während eine schnellere und häufigere Bereitstellung sehr positiv sein kann, kann die Geschwindigkeit der Serverlosigkeit neue Herausforderungen bei der Konfiguration der Sicherheit mit sich bringen.
2. Sicherheitstools können die Verarbeitungszeit verlängern, die Sie mit allen Anfragen multiplizieren müssen. Glücklicherweise erfordern die meisten Best Practices für Serverlose Sicherheit keine zusätzliche Verarbeitungszeit.
3. Erosion des Perimeters. Die traditionelle Anwendung hatte eine klare Grenze. Das Äußere und das Innere waren unterschiedlich, und wir konnten die Sicherheit am Rande gewährleisten. Obwohl es nicht ideal ist, die Sicherheit ausschließlich an der Außengrenze zu gewährleisten, war es dennoch möglich, eine Mauer zu errichten.

Serverlose Anwendung sind poröser und feinkörniger. Serverlose Anwendungen bestehen aus Dutzenden oder Hunderten von Funktionen und sind winzige Mikrodienste mit eigenen Richtlinien, Rollen, API, Prüfprotokollen usw. Dadurch ändert sich die Angriffsfläche: Anstelle einer kleinen Anzahl von Einstiegspunkten, hinter denen sich jede Menge Funktionalität verbirgt, gibt es jetzt mehr Einstiegspunkte, hinter denen sich jeweils ein kleiner Teil der App befindet. Um Ihre Anwendung zu verteidigen, müssen Sie nun über jeden Einstiegspunkt nachdenken.

Verschiedene Ereignisse können Funktionen auslösen, wie zum Beispiel:

• Cloud-Speicherereignisse (z. B AWS S3, Azure Blob Storage, Google Cloud Storage)
• Stream-Datenverarbeitung (z AWS Kinesis)
• Datenbankänderungen (z AWS DynamoDB, Azure CosmosDB)
• Codeänderungen (z AWS CodeCommit)
• Benachrichtigungen (z. B. SMS, E-Mails, IoT)

Was sind serverlose Sicherheitsbedrohungen?

Während die Beweggründe der Angreifer gleich bleiben, müssen sich die Taktiken, die sie bei der serverlosen Anwendung anwenden, ändern. Im Folgenden sind einige der serverlosen Sicherheitsbedrohungen aufgeführt, die für diese neue Anwendungsarchitektur einzigartig sind.

1. Die Bedrohung durch überprivilegierte Funktionen

Mit der serverlosen Anwendung haben Sie die Möglichkeit, Berechtigungen auf einzelne Funktionen anzuwenden und sicherzustellen, dass diese Berechtigungen nur auf den kleinsten erforderlichen Umfang beschränkt sind. Dadurch können Sie Ihre Angriffsfläche erheblich minimieren und die Auswirkungen eines Angriffs abschwächen.

Leider haben aktuelle Untersuchungen von Check Point ergeben, dass die überwiegende Mehrheit der Entwickler diese Gelegenheit nicht nutzt. Unsere Untersuchungen haben ergeben, dass 98 Prozent der Funktionen in der serverlosen Anwendung gefährdet sind, wobei 16 Prozent als „schwerwiegend“ eingestuft werden. Darüber hinaus verfügen die meisten dieser Funktionen über mehr Berechtigungen als erforderlich, die entfernt werden könnten, um die Sicherheit der Funktion und der Anwendung zu verbessern.

Bei der Analyse von Funktionen weist Check Point jeder Funktion eine Risikobewertung zu. Dies basiert auf den festgestellten Haltungsschwächen und berücksichtigt nicht nur die Art der Schwäche, sondern auch den Kontext, in dem sie auftritt. Nachdem wir Zehntausende Funktionen in Live-Anwendungen gescannt haben, haben wir festgestellt, dass die meisten serverlosen Anwendungen einfach nicht so sicher bereitgestellt werden, wie sie zur Minimierung von Risiken erforderlich wären. Die größten Sicherheitsprobleme, die Check Point aufgedeckt hat, sind unnötige Berechtigungen, während der Rest auf anfälligen Code und Konfigurationen zurückzuführen ist.

2. Der Murmeltier-Tagesangriff

Die Tatsache, dass serverlose Funktionen kurzlebig und kurzlebig sind, erschwert es Angreifern, langfristig an Ihrer Anwendung festzuhalten. Darüber hinaus ist dies einer der vielen Sicherheitsvorteile von Serverless. Nur weil dies den Angreifern das Leben erschwert, heißt das jedoch nicht, dass sie die Angriffe stoppen werden; Sie werden einfach die Strategie ändern.

Die kurze Dauer serverloser Funktionen bedeutet, dass Bedrohungen durch serverlose Sicherheit ihre Gestalt ändern können. Angreifer könnten einen viel kürzeren Angriff konstruieren, bei dem sie beispielsweise nur ein paar Kreditkartennummern stehlen. Diese einzelne Angriffsrunde wiederholt sich ständig in dem, was wir als „Murmeltier-Tag“-Angriff bezeichnen.

3. Den Brunnen vergiften

Trotz der kurzen Lebensdauer Cloud-nativer Ressourcen können Angreifer immer noch Möglichkeiten finden, eine langfristige Persistenz in Ihrer App zu erreichen. Eine Möglichkeit für Angreifer, die kurzlebige Natur der serverlosen Anwendung zu umgehen, ist ein Upstream-Angriff oder „Poisoning the Well“.

Cloud-native Anwendungen umfassen in der Regel viele Module und Bibliotheken mit Code aus verschiedenen Quellen von Drittanbietern. Angreifer arbeiten daran, Schadcode in gängige Projekte einzuschleusen. Nachdem der Brunnen dann vergiftet wurde, kann der Schadcode in Ihren Cloud-Apps zu Hause sein, Anweisungen erhalten und Chaos anrichten.

4. Erhöhte Zeit für serverlose Sicherheitskonfiguration

Dies stellt zwar nicht gerade eine „Sicherheitsbedrohung“ dar, es ist jedoch eher eine Herausforderung und ein mögliches Hindernis für Ihre Bemühungen, Ihre serverlose Architektur zu sichern.

Serverlos bietet den Vorteil einer schnelleren Anwendungsentwicklungsgeschwindigkeit. Leider funktioniert der traditionelle Sicherheitsansatz, bei dem Entwickler Code schreiben und Workloads paketieren und Sicherheitsvorgänge dann Sicherheitskontrollen für diese Workloads einführen, bei Serverless einfach nicht.

Wenn Entwickler auf die Sicherheit warten müssen, um Ports, IAM-Rollen oder Sicherheitsgruppen für sie zu öffnen, schmälert der Vorteil der höheren Geschwindigkeit schnell. Allzu oft besteht die Lösung darin, SecOps aus der Gleichung zu streichen, was tatsächlich ein Risiko darstellen könnte.

Andererseits ist die Konfiguration von Berechtigungen für die unzähligen serverlosen Ressourcen und Interaktionen zwischen ihnen eine zeitaufwändige Aufgabe. Darüber hinaus kann es schnell teuer werden, die Zeit der Entwickler für diese Sicherheitskonfiguration aufzuwenden, und es ist auch nicht die ideale Zeitnutzung. Durch die Nutzung von Automatisierung wie der CloudGuard-Plattform kann die Serverlose-Sicherheit erhöht werden, ohne übermäßig viel Entwicklerzeit aufzuwenden.

5. Längere Zeit für die Sicherheitsverarbeitung

Ein weiterer Vorteil von Serverless besteht darin, dass Sie nur für das bezahlen, was Sie tatsächlich verbrauchen, was zu geringeren Kosten führen kann. Wenn Sie jedoch genau für das bezahlen, was Sie verbrauchen, bedeutet dies, dass jede Verlängerung der Bearbeitungszeit zu höheren Kosten führt.

Wenn Sie Ihrer App zu viele App-Sec-Konfigurationen hinzufügen, kann dies möglicherweise zu einem Mehraufwand für Ihre Funktionen führen, was zu höheren Kosten führen kann. Auch wenn die Erhöhung der Verarbeitungszeit aus Sicherheitsgründen eine kluge Investition ist, erfordert sie eine ordnungsgemäße Implementierung, um übermäßige, unnötige Kostensteigerungen zu vermeiden.

Ähnlich wie bei der oben genannten erhöhten Zeit für die serverlose Sicherheitskonfiguration handelt es sich hierbei nicht gerade um eine Bedrohung, sondern vielmehr um eine Herausforderung, die Sie bei der Sicherung Ihrer serverlosen Architektur bewältigen müssen.