BLOG

Verbesserung der Betriebssicherheit in der Cloud

Lori MacVittie Miniaturbild
Lori MacVittie
Veröffentlicht am 03. Juni 2019

Wenn Sie die Kosten für den Betrieb in der Cloud gering halten möchten, sollten Sie Ihre Sicherheitspraktiken auf der Verwaltungsseite des Betriebs überprüfen.

Heutzutage gilt die meiste Aufmerksamkeit in Sachen Sicherheit den Application und Schwachstellen im Application selbst. Das überrascht nicht, denn die Mehrzahl der Sicherheitsverletzungen geschieht, weil Schwachstellen in gängigen Plattformen und Frameworks eine Vielzahl leichter Angriffsziele bieten.

Doch wir dürfen die zunehmend zugängliche Managementseite des Geschäfts nicht außer Acht lassen. Beim Verschieben von Apps in die öffentliche Cloud haben wir häufig aus den Augen verloren, wie wichtig es ist, den Verwaltungsverkehr vom einfachen Zugriff zu isolieren. Vor Ort war dies einfach. Das Verwaltungsnetzwerk war für die Öffentlichkeit nicht zugänglich. Wir haben sie auf ein nicht routbares Netzwerk beschränkt, auf das nur von innen zugegriffen werden konnte. Da wir sowohl Apps als auch deren Application -Infrastruktur in die Cloud migriert haben, benötigen wir ein öffentlich zugängliches Management, weil die Betreiber jetzt remote arbeiten.

Obwohl wir von Telnet (mit Ausnahme aller IoT-Geräte, die noch aufholen müssen) auf SSH umgestiegen sind und uns sogar gute Verhaltensweisen bei der Kennwortgenerierung aneignen, haben wir uns nicht unbedingt damit befasst, wie wir die Cloud-native Sicherheit besser in Kombination mit unseren eigenen Praktiken nutzen können.

Es ist die Nutzung der Sicherheitsdienste von Cloud-Anbietern, die die Betriebskosten von Geschäften in der Cloud dramatisch beeinflussen kann – insbesondere, wenn es um die Verwaltung der Infrastruktur für Application geht.

Die Bedrohung ist real

Wenn Sie noch keine Gelegenheit hatten, den Artikel von F5 Labs zu den am häufigsten angegriffenen Benutzernamen und Passwörtern zu lesen, sollten Sie dies tun. Darin erfahren Sie, dass SSH ein äußerst zielgerichteter Dienst ist. Wie sich herausstellt, mehr als alles andere.

Aus dem Artikel:

Gemessen am Angriffsvolumen konzentrieren Angreifer mehr Zeit und Aufwand auf Angriffe auf SSH als auf jeden anderen Onlinedienst. Brute-Force-Angriffe auf administrative Logins von Applications über SSH kommen 2,7-mal häufiger vor als Angriffe auf die Application selbst über HTTP (Angreifer versuchen, Anwendungsschwachstellen auszunutzen).

Und warum nicht? Durch die administrative Kontrolle über die Infrastruktur der Application haben Sie umfangreiche Möglichkeiten – einschließlich der Möglichkeit, Richtlinien zu ändern, die andernfalls einen einfachen Zugriff auf Applications verhindern könnten. Im Falle von Kubernetes - das häufig im Visier ist, weil keinerlei Anmeldeinformationen erforderlich sind - ist der Zugriff erwünscht, um Ressourcen auf Kosten anderer zu beschaffen.

Aber Sie sind sicherheitsbewusst und verlangen sichere Passwörter für den gesamten Zugriff auf die Infrastruktur. Ihr SSH-Passwort ist so stark, dass Sie innehalten und darüber nachdenken müssen, was es bedeutet, wenn Sie es eingeben. Jedes Mal.

Und nun die offensichtliche Aussage des Jahrhunderts: Starke Passwörter verhindern keine Angriffe. Sie schwächen lediglich erfolgreiche Angriffe ab. Sie können niemanden davon abhalten, einen Angriff zu starten. Das kannst du wirklich nicht. Man kann es nur erkennen und seinen Erfolg verhindern.

Doch in der Zwischenzeit sind mit diesem Angriff echte Betriebskosten verbunden. Weil Sie intelligente Sicherheit praktizieren und alle fehlgeschlagenen Versuche protokolliert werden. Jeder. Einzel. Eins.

Und für jeden fehlgeschlagenen Versuch, den Sie blockieren, verbrauchen Sie Ressourcen. Bandbreite. Lagerung. Berechnen.  

Nutzen Sie Cloud Native Services zur Verbesserung Ihrer Sicherheitspraktiken

Alle großen Cloud-Anbieter (und wahrscheinlich auch die kleineren) stellen grundlegende Netzwerksicherheitskontrollen bereit, mit denen der Verwaltungszugriff auf die Application -Infrastruktur gesperrt werden kann. AWS-Sicherheitsgruppen (SGs) und Azure-Netzwerksicherheitsgruppen (NSG) funktionieren ähnlich wie eine Firewall – sie filtern den ein- und ausgehenden Datenverkehr einer Instanz. Im Falle eines Verwaltungszugriffs kann dies ein wichtiges Werkzeug in Ihrem Sicherheitswerkzeugkasten sein. Indem Sie den Zugriff auf ausschließlich bekannte IP-Adressen (oder bestimmte Bereiche) beschränken, können Sie die Anzahl der Angriffe, die Ihre Infrastruktur erreichen, drastisch reduzieren. Dadurch können die Kosten niedrig gehalten werden, indem ein übermäßiger Verbrauch von Rechenleistung, Bandbreite und Speicher verhindert wird.

Dies ist dasselbe Prinzip, das den Einsatz von Web Application Firewalls in der Cloud fördert, sowohl als Schutz für Apps als auch als optimale Betriebspraxis. Die Absicht besteht darin, den Angriff zu stoppen, bevor er übermäßig viele Ressourcen verbrauchen kann.  Selbst wenn dieser Angriff fehlgeschlagen wäre, besteht eine Tatsache, dass die Versuche wahrscheinlich ausreichen würden, um automatische Skalierungsereignisse zu erzwingen, die das Unternehmen Geld kosten oder die Verfügbarkeit für legitime Benutzer beeinträchtigen. Beides ist kein wünschenswertes Ergebnis.

Als allgemeine Regel gilt: Je näher Sie an der Quelle des Angriffs sind und diesen stoppen können, desto sicherer sind Sie und desto geringer sind die Kosten für das Unternehmen.

Erweitern. Nicht ersetzen.

Der Schlüssel zur Verwendung von Cloud-nativen Diensten in Ihrer Sicherheitspraxis ist die „Erweiterung“. Die Verwendung starker SSH-Passwörter ist sinnvoll. Besser ist die Kombination mit einer starken Zugriffskontrolle. Aber verzichten Sie niemals auf sichere Passwortpraktiken zugunsten ausschließlicher Sicherheitsgruppen. Verwenden Sie beides zusammen, um die Sicherheit zu gewährleisten und die Geschäftskosten in der Cloud zu begrenzen.