Cloud-Sicherheit in AWS: Die häufigsten Probleme

Sicherheit ist wohl das wichtigste Thema, wenn es um die Cloud geht. Sie ist eine der größten Bedenken die Unternehmen vor der Migration haben, und das ist etwas, das selbst Cloud-native Unternehmen regelmäßig überprüfen.

Kurz gesagt, es ist wichtig, immer auf dem neuesten Stand der modernen Sicherheitsstandards zu sein. Eine Möglichkeit, dies zu tun, besteht darin, Ihre Architektur regelmäßig zu überprüfen und sicherzustellen, dass es keine versteckten Schwachstellen oder Probleme gibt. Um Ihnen dabei zu helfen, finden Sie hier einige der häufigsten AWS-Sicherheitsprobleme und Bedrohungen, die wir gefunden haben.

Ist Die Cloud sicher?

Es ist jedoch erwähnenswert, dass die Cloud insgesamt sicher ist. Die großen Plattformführer, namentlich Amazon Web Services (AWS), Google Cloud Platform (GCP) und Microsoft Azure, unternehmen alle große Anstrengungen, um sicher zu bleiben und erfüllen verschiedene Zertifizierungsstufen. Das Problem liegt oft in den Komponenten und Lösungen, die darin enthalten sind.

Einem aktuellen Bericht zufolge waren beispielsweise zwischen Februar 2018 und Juni 2019 90 % aller Cloud-basierten Sicherheitsprobleme auf eine falsche Konfiguration zurückzuführen. In den Nachrichten wird immer wieder von einem großen Unternehmen berichtet, das ein Datenleck hat oder einen Verstoß gegen den Datenschutz bekannt gibt. Auch wenn dies in der Cloud geschieht, ist die Ursache fast immer ein menschliches Versagen bei der Konfiguration des Unternehmens.

Notiz: Bevor wir beginnen, möchte ich erklären, dass wir hier in erster Linie über AWS-Sicherheitsprobleme sprechen, aber viele dieser Punkte gelten für jede Cloud-Plattform, sei es Azure oder Google Cloud Platform. Die Technologien und Einzellösungen mögen sich ändern, aber die allgemeinen Prinzipien nicht!

Klartext-Zugangsdaten in Umgebungsvariablen = Einfacher Zugriff mit Debug

Wenn Ihre Anwendung Debugging aktiviert hat und ein Fehler auftritt, der einen Stack-Trace sowie Umgebungsvariablen auf dem Bildschirm ausgibt, dann ist Ihre Sicherheit gefährdet. Ändern Sie Ihre Passwörter, rotieren Sie Ihre Schlüssel und machen Sie Sitzungen ungültig.

Und warum? Denn bei diesen Fehlern können solche Informationen dank des Debug-Modus angezeigt werden, was Unbefugten die Möglichkeit gibt, auf etwas zuzugreifen, auf das sie nicht zugreifen sollten. Es dauert nur eine Sekunde - das ist alles, was externe Scanner brauchen, um Ihre Informationen zu kopieren und an anderer Stelle zu speichern. Wenn Ihre Geheimnisse auf diese Weise indiziert wurden und Sie keine Änderungen vorgenommen haben, könnten solche Personen monatelang Zugang haben.

Wie wir später noch erläutern werden, sollten Sie außerdem niemals produktive Anmeldeinformationen oder Konten in nicht-produktiven Umgebungen verwenden - insbesondere nicht in Umgebungen mit aktivierter Debug-Funktion.

Beispiele aus der Praxis: Diese Art von Angriff hat einige ziemlich große Unternehmen getroffen, vor allem Gemalto und Tesla. Im letzteren Fall wurden die Zugangsdaten durch eine sehr ähnliche Sicherheitslücke wie die oben beschriebene erlangt, die dann den Zugriff auf einen Speicherbereich mit sensiblen Daten ermöglichte.

Wie können Sie dies vermeiden? Beginnen Sie damit, Ihre nicht produktiven Umgebungen hinter einem VPN zu verstecken, um den Zugriff zu begrenzen. Sie können Ihre Anmeldedaten auch in einem Tresor-Service aufbewahren - wie AWS Parameter Store, AWS Secrets Manager oder HashiCorp Vault - und sie dynamisch extrahieren. Auf diese Weise bleiben sie nicht offen und ungeschützt.

Schließlich ist es immer wichtig, alles regelmäßig zu wechseln - egal ob es sich um Schlüssel, Passwörter oder Geheimnisse handelt. Aber darüber sprechen wir später noch mehr.

Private S3 Buckets privat halten

Da wir bereits S3-Buckets erwähnt haben, ist es immer wichtig, sicherzustellen, dass Ihre verschiedenen Buckets je nach Bedarf privat und öffentlich sind. Dies mag einfach erscheinen, ist aber sehr wichtig. Der öffentliche Zugriff sollte sehr begrenzt sein - alles, was Sie sicher und privat halten möchten, sollte als solches festgelegt werden.

Wie lässt sich dies vermeiden? Ganz einfach: Sie müssen sicherstellen, dass jeder Bucket richtig konfiguriert ist. Dies ist jedoch vor allem ein Problem der Skalierung - je mehr Buckets und größere Services Sie haben, desto mehr Arbeit ist nötig, um zu prüfen und sicherzustellen, dass jeder korrekt zugewiesen ist.

Darüber hinaus kann die Verwendung von Infrastructure as Code (IaC)-Mustern dazu beitragen, das Risiko zu verringern, dass versehentlich ein öffentlicher Bucket erstellt wird, wodurch solche Probleme in Zukunft vermieden werden.

Erteilen Sie nicht mehr Berechtigungen als nötig!

Die Erteilung umfassenderer Berechtigungen ist in vielen Unternehmen üblich - oft, weil es einfacher zu konfigurieren ist und sicherstellt, dass jeder auf das zugreifen kann, was er braucht - aber es birgt eine ganze Reihe von Risiken.

Mit einem unregulierten Zugang in einem Bereich können Benutzer schnell Zugang zu anderen Bereichen erlangen, Änderungen vornehmen, wo sie nicht erwünscht oder sogar willkommen sind, und Zugang zu Informationen und Prozessen in anderen Bereichen des Systems erlangen.

Hier sind ein paar Beispiele:

#Nr. 1 - Ihr QA-Team benötigt die Erlaubnis, bestehende Instanzen zu starten und zu stoppen, aber es erhält vollen Zugriff auf EC2. Das Team hat zwar keinen direkten Zugriff auf IAM, aber es gibt eine bestehende Rolle mit solchen Admin-Rechten.
Das Problem? Ihr QA-Team kann eine neue Instanz starten und ihr die Administratorrolle zuweisen. Auf diese Weise kann Ihr QA-Team nun mit dieser Administratorrolle jede Aktion auf Ihrem Konto durchführen - und nicht nur die, die dem QA-Team ursprünglich zugewiesen wurde.

#Nr. 2 - Ihr Dienst lädt Berichte in einen einzigen S3-Bucket hoch und es gibt eine Richtlinie, die Uploads nur in diesen speziellen Bucket erlaubt. Ihr Team ist sich nicht sicher, welche Berechtigungen hier erforderlich sind, und legt daher vollen Zugriff fest.
Das Problem? Mit Hilfe dieses speziellen Dienstes hat ein potenzieller Angreifer nun Zugriff auf andere Buckets von diesem Ort aus, da seine Berechtigungen nicht gesperrt sind.

#Nr. 3 - Bei der Einrichtung eines neuen Kontos beschließen Sie, allen Mitgliedern Ihres Teams Admin-Zugriff zu gewähren, "für den Fall, dass sie ihn brauchen". Nach einiger Zeit - und ohne Probleme - vergessen Sie bald, dass auch der Rest des Teams über Admin-Zugang verfügt.
Das Problem? Ein böswilliger Insider kann jederzeit sensible Daten extrahieren, Ihre laufenden Ressourcen unterbrechen oder sogar den Zugang für andere Personen sperren.

Wie Sie sehen können, ist es sehr einfach, versehentlich in eine dieser Situationen zu geraten.

Wie lässt sich das vermeiden? Wenn Sie viele Mitarbeiter haben, kann es schwierig sein, so viele Rollen und ihre jeweiligen Berechtigungen zuzuweisen und zu regeln. In der Tat fangen hier viele Probleme an, da Unternehmen ihren Mitarbeitern pauschale Berechtigungen erteilen, um Zeit zu sparen. Ziehen Sie stattdessen die Verwendung von Gruppen und vordefinierten Rollen mit spezifischen Berechtigungen für verschiedene Teams und Benutzer in Betracht.

Sie sollten auch sicherstellen, dass Ihre allgemeine Richtlinie auf "Standardverweigerung" eingestellt ist. Auf diese Weise vergessen Sie nicht, jedem Benutzer die Berechtigungen zu entziehen, sondern fügen einfach die erforderlichen Berechtigungen hinzu.

Veraltete Software & verpasste Sicherheits-Patches

Dieses Problem gab es schon lange vor der Cloud - es gilt für Software vor Ort, Netzwerke und im Grunde für jede digitale Lösung. Es sollte Sie also nicht überraschen, dass dies eine der grundlegendsten Praktiken des Cloud-Sicherheitsrisikomanagements ist - und gleichzeitig eine der am meisten übersehenen.

Natürlich haben wir bereits erwähnt, dass die Cloud selbst sehr sicher ist. Doch während AWS seine eigenen verwalteten Dienste und gehosteten Betriebssysteme mit Patches versieht, liegt es an den einzelnen Kunden, was in den virtuellen Maschinen läuft.

Das Ignorieren von Updates ist ein törichtes Unterfangen: Diese Updates werden erstellt, wenn mögliche Schwachstellen gefunden werden. Diese werden oft öffentlich bekannt, und wenn Sie die Updates nicht einspielen, wird Ihr Dienst zu einem Ziel für bösartige Aktivitäten.

Hier sind zwei Szenarien:

#1 - Sie haben eine EC2 mit Zugriffsrechten auf Ihr(e) S3-Bucket(s). Eine Ihrer Anwendungen, die auf dieser EC2 läuft, ist veraltet und offen für eine Schwachstelle, die es Angreifern ermöglicht, sich in Ihren Rechner zu hacken. Wenn sie erfolgreich sind, haben sie dieselben Berechtigungen wie Ihre Instanz und können problemlos auf Ihre privaten S3-Objekte zugreifen.

#Nr. 2 - Sie haben eine Unternehmenslösung zur Verwaltung von Aufgaben für mehrere Projekte, aber sie ist veraltet. Hacker können einen bekannten Exploit verwenden, um sie als Proxy zu nutzen und jede beliebige URL zu öffnen. Da der Rechner auf AWS läuft, können Angreifer auf seine Metadaten zugreifen und nach einer "magischen" internen Adresse fragen, was, um es kurz zu machen, eine ganze Reihe von Problemen für Sie und Ihr Unternehmen verursacht.

(Nein, ich erzähle Ihnen nicht, was ich tatsächlich gemacht habe!)

Wie lässt sich dies vermeiden? Auch hier gibt es eine einfache Lösung: Aktualisieren Sie alles in der Cloud. Stellen Sie außerdem sicher, dass Ihr IT-Team immer über alle offiziellen Patches und Updates auf dem Laufenden ist. Die neuesten AWS-Sicherheitspatches und -Probleme werden zum Beispiel regelmäßig aktualisiert. Auf der Bulletin-Seite von AWS finden Sie die neuesten CVE-Probleme (Common Vulnerabilities and Exposures) - stellen Sie also sicher, dass Ihr IT-Team dies täglich überprüft!

Wenn Sie verwaltete Dienste in Anspruch nehmen, können diese das Patchen automatisieren, einschließlich eines Service-Fensters, das sicherstellt, dass solche Updates nicht zum falschen Zeitpunkt kommen.

Verwenden Sie niemals gemeinsam genutzte Schlüssel!

Gemeinsame Schlüssel sind ein Alptraum für Ermittlungen. Wenn Sie wissen, dass mehr als eine Person Zugriff auf einen bestimmten Schlüssel hat, ist es nicht einfach, die Verantwortung zu ermitteln. Einzelne Schlüssel für jede Person sind dagegen viel einfacher.

Außerdem ist es auch sicherer. Gemeinsame Schlüssel führen oft dazu, dass ehemalige Teammitglieder weiterhin Zugriff auf Ihren Rechner haben, selbst wenn sie das Unternehmen verlassen haben, was alles andere als sicher ist. Gemeinsam genutzte Schlüssel sind auch viel leichter auszuspionieren, da man sie an neue Teammitglieder weitergeben muss usw. Ein einzelner Schlüssel hat keinen Grund, so oft weitergegeben zu werden. Er wird nicht per E-Mail verschickt oder auf ein Stück Papier geschrieben!

Wie kann man das Problem lösen? Verwenden Sie niemals gemeinsame Schlüssel! Verwenden Sie immer Schlüssel, die einer bestimmten Person zugewiesen sind. Und wenn Sie gemeinsame Schlüssel verwenden, deaktivieren Sie diese und weisen Sie sofort einen individuellen Zugang zu.

Ja, jetzt sofort!

Aber wo wir gerade von Schlüsseln sprechen...

Wechseln Sie Ihre Schlüssel regelmäßig!

Auch wenn Sie einzelne Schlüssel haben, müssen diese regelmäßig gewechselt werden. Ein Schlüssel kann immer noch undicht werden. Je länger Ihre Schlüssel aktiv sind, desto mehr Risiko bauen Sie auf.

Eine Schlüsselrotation trägt jedoch auch dazu bei, Ihre Teams zu einem Umdenken zu bewegen. Anstatt ihre eigenen Zugangsschlüssel in verschiedenen Anwendungen fest zu codieren, werden sie weniger dauerhafte, rotierende Lösungen verwenden, die schwerer zu knacken sind. Hier ist ein Beispiel, das erklärt, warum:

Ein Junior-Entwickler arbeitet an einer Lambda-Funktion und hat seine Änderungen, einschließlich der Zugriffsschlüssel, in das Repository übertragen. Dieses Leck wurde zwar schnell erkannt und entfernt, aber der Änderungsverlauf ist möglicherweise noch in Git verfügbar. Ein potenzieller Angreifer kann den Git-Verlauf extrahieren und diesen Schlüssel finden. Wenn er nicht rotiert wurde und noch aktiv ist, hat er direkten Zugriff auf Ihre Ressourcen.

Beispiele aus der realen Welt: Darauf können selbst große Tech-Giganten hereinfallen. Letztes Jahr gelang es einer Sicherheitsfirma, mithilfe von durchgesickerten Zugangsdaten in die Infrastruktur von Nokia einzudringen. Von hier aus konnten sie Benutzer- und Admin-Passwörter, Verschlüsselungsschlüssel und verschiedene private Schlüssel finden - alles, was ein böswilliger Hacker braucht, um großen Schaden anzurichten. Glücklicherweise testete das betreffende Unternehmen die Sicherheit und informierte Nokia über die Änderungen. Aber nicht jeder hat so viel Glück.

Rollen statt Zugriffsschlüssel verwenden

In den letzten beiden Fällen waren die Schlüssel selbst das Problem. Wenn sie als Klartext-Zugangsschlüssel vorliegen, können sie leicht kopiert und erworben werden. Was wäre also, wenn wir dieses Risiko ganz ausschalten würden?

Definierte Rollen in Verbindung mit temporären und kurzlebigen Anmeldeinformationen von AWS Security Token Service (STS) erfüllen dieselbe Funktion, sind aber wesentlich sicherer. Ähnlich wie bei rotierenden Schlüsseln sorgt die temporäre Natur von STS dafür, dass alte Protokolle oder Datensätze nicht in potenzielle Exploits verwandelt werden können.

Kurz gesagt, indem wir definierte Schlüssel vollständig entfernen, können wir ein weiteres Datenleckszenario aus der Gleichung entfernen.

Rechnungswarnungen verwenden

Hier geht es weniger darum, Bedrohungen zu verhindern, sondern sicherzustellen, dass Sie bei solchen Vorfällen nicht unvorbereitet getroffen werden. Abrechnungswarnungen werden von Cloud-Anbietern wie AWS verwendet, um Sie über wichtige Entwicklungen auf dem Laufenden zu halten. Wenn sich jemand Zugang verschafft und Ihre Ressourcennutzung umverteilt hat, werden Sie auf diese Weise informiert, dass etwas nicht stimmt.

Hier ist ein klares Beispiel:

Ihre derzeitige Infrastruktur - die sehr stabil ist - kostet Sie bis zum 10. eines jeden Monats in der Regel 300 $, bis zum 20. 1.200 $ und die letzte monatliche Rechnung kostet in der Regel etwa 2.000 $. Was passiert nun, wenn Ihre Schlüssel durchsickern und ein Angreifer beschließt, kostspieligere EC2-Instanzen (z.B. für das Bitcoin-Mining) auf Ihre Kosten zu betreiben?

Wenn Sie Rechnungswarnungen mit den oben genannten Zahlen ($300, $1.200 und $2.000) einrichten, werden Sie benachrichtigt, sobald die Kosten $300 erreichen. Sie werden dann feststellen, dass dies viel früher als gewöhnlich der Fall ist, was Sie dazu veranlasst, diese Vorgänge zu untersuchen und zu stoppen.

Wenn Sie keine Rechnungswarnungen haben, bleiben die Instanzen unbemerkt und Sie müssen am Ende die Kosten bezahlen. Sie bemerken es erst am Ende des Monats, wenn die Kosten weit über 2.000 $ liegen.

Verwenden Sie MFA!

Die Multi-Faktor-Authentifizierung (MFA) ist in der heutigen Welt weit verbreitet. Die meisten Anwendungen verwenden sie, darunter auch zahlreiche Banken. Warum sollten Sie sie also nicht auch für Ihre Cloud verwenden.

Die Single-Factor-Authentifizierung ist ein klares Risiko - sie ist einer der Gründe, warum Schlüssel so problematisch sind. Durch die Verwendung von MFA für alle Ihre AWS Identitäts- und Zugriffsverwaltungsrichtlinien (IAM) für jeden API-Aufruf können Sie Ihre Ressourcen schützen, selbst wenn ein Zugriffsschlüssel durchsickert. Ohne jedes Stück kommt niemand ohne genehmigten Zugriff hinein.

Root User Access Keys entfernen

... und lassen Sie uns wieder über Schlüssel sprechen! Diesmal geht es um das Problem der Zugangsschlüssel für Root-Benutzer. Da Root-Benutzer Zugriff auf das gesamte Konto haben, einschließlich der Ressourcen und Daten, sollte dies auf keinen Fall geschehen.

Verwenden Sie stattdessen IAM-Benutzer. Selbst mit Admin-Rechten können diese keine Aktionen zur Kontoverwaltung durchführen. Selbst wenn sich jemand Zugang zu einem solchen Konto verschafft, ist das Ausmaß des möglichen Schadens also viel geringer.

Verwenden Sie getrennte Konten für Produktions- und Entwicklungsumgebungen

Normalerweise werden Entwicklungs- und Produktionsumgebungen klar voneinander getrennt, aber in der Cloud teilen sie sich oft aus Bequemlichkeit die gleichen Konten. Ähnlich wie bei gemeinsamen Schlüsseln und unnötigen Privilegien führt dies zu einer ganzen Reihe von Problemen. Denken Sie nur an eines dieser nicht gerade idealen Szenarien:

• Das Entwicklungsteam beendet versehentlich den Produktionsrechner und löscht damit den Service Ihres Unternehmens.
• Produktionsprotokolle sind für nicht autorisierte Entwickler zugänglich, die nun über Informationen verfügen, auf die sie nicht hätten zugreifen dürfen.
• Da alles über ein einziges Konto läuft, gibt es keine klaren Informationen über die Kosten. Sie können beispielsweise nicht ohne weiteres feststellen, ob eine Kostenspitze aus der Produktion oder aus der Nicht-Produktion stammt.
• Ein einfaches, einmaliges Leck ermöglicht es Angreifern, auf Ihr Konto zuzugreifen, wodurch sie nun Zugang zu beiden Umgebungen erhalten und so viel Schaden wie möglich anrichten können.
• Ein Entwickler erstellt ein Amazon Machine Image (AMI) von der Produktionsmaschine und führt davon eine reine Entwicklungsmaschine aus. Das funktioniert zwar für die Entwickler, aber auf diesem Rechner befinden sich nun alle Daten und Konfigurationen aus der Produktion.
• Ein Entwickler erstellt einen Snapshot der Elastic Block Storage (EBS)-Volumes der Produktionsumgebung und verbindet ihn mit seinem Entwicklungsrechner, um Zugriff auf die Produktionsdaten und -konfigurationen zu erhalten.

Zum Glück gibt es auch für dieses Problem eine einfache Lösung: Trennen Sie Ihre Produktions- und Nicht-Produktionsumgebung! Sie können weiterhin Protokolle von allen Konten in einem einzigen Bucket sammeln, auf das diejenigen, die es benötigen, über ein externes Konto zugreifen können. Auf diese Weise überschneiden sich Produktion und Entwicklung nicht.

Blockieren Sie den öffentlichen Zugang zu Diensten wie Elasticsearch, Jenkins usw...

Verwaltungstools und andere verwaltete Dienste wie Jenkins oder ElasticSearch können die Konfiguration der Cloud noch einfacher machen, aber es ist wichtig, dass der Zugang zu diesen Tools sicher ist - auch weil sie oft auf Standardports angewiesen sind. Deshalb empfehlen wir Ihnen, den Zugriff ausschließlich auf die IP-Adresse Ihres Büros zu beschränken.

Hier sind zwei mögliche Szenarien, die Sie berücksichtigen sollten:

#1 - Nehmen wir an, dass einige Ihrer Teammitglieder von zu Hause aus arbeiten möchten und Ihnen ihre IP-Adresse für den Zugang zur Verfügung stellen. Das mag auf den ersten Blick gut erscheinen, aber eine einzige IP-Adresse könnte von halb London verwendet werden - und alle hätten nun potenziellen Zugang, wenn sie sich dafür entscheiden würden, das zu überprüfen.

#Nr. 2 - Ihre Teammitglieder arbeiten oft von verschiedenen Standorten aus und da Sie nicht in ein virtuelles privates Netzwerk (VPN) investiert haben, halten Sie Jenkins öffentlich zugänglich, so dass Ihr Team immer Zugriff hat. Da Jenkins in der Lage ist, eine administrative Rolle in AWS einzunehmen, haben Sie soeben ein potenzielles Einfallstor für Ihr gesamtes AWS-Konto öffentlich zugänglich gemacht.

Beispiele aus der realen Welt: Dies ist ein weiteres Beispiel, das recht einfach ist, aber dennoch immer wieder auftaucht. In der Vergangenheit waren dies große Namen und Dienste wie Snapchat!

Woher wissen Sie also, ob Sie sicher sind?

Die einfache Wahrheit ist, dass Sie nicht wissen, ob Sie sicher sind, wenn Sie sich nicht die Zeit nehmen, um nachzusehen. Wenn Sie Ihre Lösungen sorgfältig entwickelt haben, die wichtigsten Exploits vermieden und keine Hintertüren offen gelassen haben, dann sind Sie sicher. Die eigentliche Frage ist - haben Sie Ihre Infrastruktur getestet, um dies zu beweisen?

Zusammenfassung

Ich hoffe, dies zeigt, dass einige der größten AWS-Sicherheitsverletzungen auf Fehlkonfigurationen und unsachgemäße Zugriffspraktiken zurückzuführen sind. Was wie eine einfache Änderung aussieht, kann Sie in Wirklichkeit für viel größere Angriffe und Konsequenzen anfällig machen. In der Tat ist dies eines der ersten Dinge, die wir in jedem Cloud-Sicherheitsrisikomanagementprojekt untersuchen - wir prüfen immer auf diese Probleme, bevor wir uns fortgeschritteneren Problemen zuwenden.

Sie ist auch Teil des AWS Well Architected Framework. Die AWS-Sicherheitssäule ist ein Thema für sich, aber natürlich ist sie einer der wichtigsten Aspekte einer jeden Cloud-Infrastruktur. Die Cloud ist in ihrer jetzigen Form nicht gefährlicher als ein Server vor Ort. Tatsächlich ist sie in der Regel sogar sicherer, da Cloud-Anbieter wie AWS Kunden und Anforderungen haben, die oft über Ihre eigenen hinausgehen, und in dieser Hinsicht angemessene Vorsichtsmaßnahmen ergreifen, damit Sie in sicheren Händen sind.

Wie diese allgemeinen Sicherheitsrisiken zeigen, sind es in der Regel schlechte Sicherheitsstandards und veraltete Zugriffspraktiken, die zu den größten Risiken und Sicherheitsbedrohungen führen.

Unser Rat? Überprüfen Sie Ihre aktuelle Einrichtung und berücksichtigen Sie alle Aspekte. Hier ist eine kurze Checkliste, nur zur Erinnerung:

Verwenden Sie Klartext-Anmeldeinformationen in Umgebungsvariablen mit Debug? Richtige Antwort: Nein!

Sind Ihre privaten S3-Buckets wirklich privat? Richtige Antwort: Ja! Unsere öffentlichen und privaten Buckets sind korrekt konfiguriert.

Haben Menschen mehr Berechtigungen, als sie benötigen. Richtige Antwort: Nein, Berechtigungen sind sehr streng und definiert.

Haben Sie einige Software- und Sicherheits-Patches verpasst? Die richtige Antwort: Nein, wir sind immer auf dem neuesten Stand und verpassen keinen Patch!

Verwenden Sie gemeinsame Schlüssel? Richtige Antwort: Nein, jeder hat einen eigenen Schlüssel für seine eigenen Zugriffszwecke.

Was ist mit dem Benutzer root? Richtige Antwort: Nein, wir verwenden nie den Root-Benutzer - wir haben separate Benutzergruppen für alle unsere Bedürfnisse und Anforderungen.

Drehen Sie Ihre Schlüssel? Richtige Antwort: Ja! Wir wechseln die Schlüssel regelmäßig aus, mit individuellen Schlüsseln für jede Person.

Verwenden Sie Rollen?Richtige Antwort: Ja! Wir verwenden nach Möglichkeit Rollen, um nicht auf Klartext-Zugangsschlüssel angewiesen zu sein.

Haben Sie eine Benachrichtigung für die Rechnungsstellung eingerichtet? Richtige Antwort: Ja - Ich möchte wissen, wenn die Kosten unerwartet in die Höhe schießen und steigen.

Verwenden Sie eine Multi-Faktor-Authentifizierung? Die richtige Antwort: Natürlich - wir verwenden sie für alle Zugriffsmethoden, einschließlich AWS IAM.

Halten Sie Produktions- und Entwicklungsumgebungen getrennt? Richtige Antwort: Immer - wir haben getrennten Zugang zu jeder Umgebung. Unsere Entwickler können nicht auf die Produktionsumgebung zugreifen und andersherum.

Schränken Sie den Zugriff auf Ihre Verwaltungstools ein? Richtige Antwort: Ja, wir erlauben nur unseren Büro-IP-Adressen einen solchen Zugriff. (Fernarbeitskräfte können nur über unsere VPN-Lösung Zugang erhalten).

Geschäftsperspektive

Die meisten AWS-Sicherheitsprobleme entstehen auf der Seite des jeweiligen Kunden/Unternehmens und nicht direkt durch den Cloud-Anbieter. Oft liegt es an kleinen Fehlern oder Abweichungen von modernen Cloud-Sicherheitsstandards. Alles, was potenzielle Hacker brauchen, ist, dass Ihr Unternehmen mit seinen Zugriffsrechten nicht sorgfältig umgeht oder seine Online-Konfigurationen nicht sorgfältig genug vornimmt. Die oben genannten Beispiele sind nur einige der häufigsten AWS-Sicherheitsbedrohungen, die wir erlebt haben, aber sie alle können große Folgen haben, wenn sie ausgenutzt werden. Eine allgemeine Überprüfung und Bewertung Ihrer Cloud-Architektur ist immer nützlich, aber eine regelmäßige Überprüfung Ihrer Cloud-Sicherheit ist unerlässlich!

Quellen

• Bericht findet 34 Millionen Sicherheitslücken bei AWS, Google Cloud und Azure
• Ihre AWS-Schlüssel werden entwendet oder gestohlen. Bereiten Sie sich vor
• Lehren aus dem Kryptojacking-Angriff bei Tesla
• Hackerone-Bericht - AWS-Bucket führt zu iOS-Test-Build-Code und Konfiguration Exposition (Slask)
• Der Capital One-Hack hätte für Amazons profitabelstes Geschäft keinen schlechteren Zeitpunkt erwischen können
• Nokia gibt Passwörter und geheime Zugangsschlüssel zu seinen internen Systemen preis
• Hackerone Bericht - Öffnen Sie eine Jenkins-Instanz (Snapchat)