10 AWS Sicherheitsfehler und wie sie zu vermeiden

10 AWS Sicherheitsfehler und wie sie zu vermeiden

Die Cloud hat es einfach gemacht, schnell einen neuen Server zu spinnen, ohne auf IT warten zu müssen. Die einfache Implementierung neuer Server und der demokratische Charakter des Cloud-Managements kann jedoch ein Sicherheitsalarm sein, da ein einfacher Konfigurationsfehler oder ein administrativer Fehler die Sicherheit der gesamten Cloud-Umgebung Ihres Unternehmens gefährden kann.

Mit sensiblen Daten, die zunehmend in die Cloud wechseln, ist es von größter Bedeutung, wie Ihre Organisation ihre Instanzen und die gesamte Cloud-Infrastruktur sichert. Cloud-Provider, wie Amazon, sichern die Server-Hardware, auf der Ihre Instanzen laufen, aber die Sicherheit der Cloud-Infrastruktur, die Ihre Organisation auf dieser Infrastruktur aufgebaut hat, liegt bei Ihnen. Eine breite Palette von integrierten Sicherheitsdiensten und Tools von Drittanbietern sind verfügbar, um praktisch jede Arbeitsbelastung zu sichern, aber Sie müssen wissen, wie man sie verwendet. Und alles beginnt mit der richtigen Konfiguration.

[Download der öffentlichen Cloud Megaguide PDF: Amazon, Microsoft, Google, IBM und Joyent verglichen. aufrechtzuerhalten Bleiben Sie auf der Cloud mit dem InfoWorld Cloud Computing Newsletter. ]

Analyse der realen Nutzung von Amazon Web Services nicht ein schönes Bild. Cloud Security Unternehmen Saviynt vor kurzem bei seinen Kunden im Durchschnitt 1.150 Fehlkonfigurationen in Elastic Compute Cloud (EC2) Instanzen pro AWS-Konto gefunden. Es ist klar, dass die Leichtigkeit des Spinnens von EC2-Instanzen für Entwicklung und Testing auf Kosten von Sicherheitskontrollen erfolgt, die ansonsten vorhanden wären, um vor Ort Server zu schützen. AWS-Administratoren müssen die verfügbaren Tools richtig verwenden, um die Sicherheit ihrer Umgebung sicherzustellen.

Hier sehen wir einige der häufigsten Konfigurationsfehler, die Administratoren mit AWS machen.

Fehler 1: Ich weiß nicht, wer für die Sicherheit zuständig ist.

Bei der Arbeit mit einem Cloud-Provider ist Sicherheit eine gemeinsame Verantwortung. Leider wissen viele Admins nicht immer, was AWS kümmert und welche Sicherheitskontrollen sie selbst anwenden müssen. Wenn Sie mit AWS arbeiten, können Sie nicht davon ausgehen, dass Standardkonfigurationen für Ihre Workloads geeignet sind. Daher müssen Sie diese Einstellungen aktiv überprüfen und verwalten. Es ist ein einfaches Konzept, aber nuanciert in der Ausführung „, sagt Mark Nunnikhoven, Vice President für Cloud-Research bei Trend Micro. „Der Trick ist herauszufinden, welche Verantwortung welche ist.“

Wichtiger ist, dass AWS eine Vielzahl von Dienstleistungen anbietet, die jeweils unterschiedliche Verantwortungsbereiche erfordern; Kennen die Unterschiede bei der Auswahl Ihrer Dienstleistung. Zum Beispiel, EC2 legt die Sicherheit auf Sie, so dass Sie verantwortlich für die Konfiguration des Betriebssystems, die Verwaltung von Anwendungen und den Schutz von Daten. „Es ist ziemlich viel“, sagt Nunnikhoven. Im Gegensatz dazu, mit AWS Simple Storage Service (S3) Kunden konzentrieren sich nur auf den Schutz von Daten ein und aus, wie Amazon behält die Kontrolle über das Betriebssystem und die Anwendung.

Wenn Sie nicht verstehen, wie dieses Modell funktioniert, gehen Sie selbst offen für unnötige Risiken «, sagt Nunnikhoven.

Zu viele Admins erstellen AWS-Instanzen, ohne AWS CloudTrail, einen Webdienst, der API-Aufrufe von AWS-Verwaltungskonsole, AWS-SDKs, Befehlszeilentools und übergeordnete Dienste aufzeichnet, zu aktivieren Wie zum Beispiel AWS CloudFormation.

CloudTrail liefert unschätzbare Log-Daten und unterhält eine Historie aller AWS-API-Aufrufe, einschließlich der Identität des API-Anrufers, der Uhrzeit des Anrufs, der Quell-IP-Adresse des Anrufers, der Anfrageparameter und der Reaktionselemente Zurückgegeben durch den AWS-Dienst. Als solche kann CloudTrail für Sicherheitsanalyse, Ressourcenverwaltung, Change Tracking und Compliance-Audits verwendet werden.

Die Analyse von Saviynt ergab, dass CloudTrail häufig gelöscht wurde, und die Protokollvalidierung wurde oftmals aus einzelnen Instanzen deaktiviert.

Administratoren können CloudTrail nicht nachträglich einschalten. Wenn Sie es nicht einschalten, sind Sie blind für die Aktivität Ihrer virtuellen Instanzen im Laufe der künftigen Untersuchungen. Einige Entscheidungen müssen getroffen werden, um CloudTrail zu aktivieren, z. B. wo und wie die Protokolle gespeichert werden, aber die Zeit, die für die korrekte Einrichtung von CloudTrail benötigt wird, lohnt sich.

„Tun Sie es zuerst, bevor Sie es brauchen“, sagt John Robel, ein Prinziplösungsarchitekt für Evident.io.

Fehler 3: Zu viele Privilegien weggeben

Zugriffsschlüssel und Benutzerzugriffskontrolle sind ein integraler Bestandteil der AWS-Sicherheit. Es kann verlockend sein, Entwicklern Administratorrechte zu geben, um bestimmte Aufgaben zu behandeln, aber Sie sollten nicht. Nicht jeder muss ein Administrator sein, und es gibt keinen Grund, warum Richtlinien nicht die meisten Situationen behandeln können. Saviynts Forschung stellte fest, dass 35 Prozent der privilegierten Benutzer in AWS vollen Zugriff auf eine Vielzahl von Diensten haben, einschließlich der Fähigkeit, die gesamte Kunden-AWS-Umgebung zu senken. Ein weiterer häufiger Fehler ist das Verlassen High-Privileg AWS Konten gedrehtOn für beendete Benutzer, Saviynt gefunden.

Administratoren schlagen häufig keine gründlichen Richtlinien für eine Vielzahl von Benutzerszenarien ein, anstatt, sie so breit zu bilden, dass sie ihre Wirksamkeit verlieren. Das Anwenden von Richtlinien und Rollen, die den Zugriff beschränken, verringert die Angriffsoberfläche, da es die Möglichkeit vermeidet, dass die gesamte AWS-Umgebung kompromittiert wird, da ein Schlüssel freigelegt, Kontobestimmungen gestohlen wurde oder jemand in Ihrem Team einen Konfigurationsfehler verursacht hat.

Wenn Sie sich selbst einen kompletten Zugang zu einem Service für jemanden finden, halten Sie an «, sagt Nunnikhoven. „

AWS Identity and Access Management (IAM) ist entscheidend für die Sicherung von AWS-Implementierungen, sagt Nunnikhoven. Der Service, der kostenlos ist, macht es recht einfach, neue Identitäten, Benutzer und Rollen einzurichten und Vorrang zu definieren oder granulare Berechtigungen anzupassen. Sie sollten den Dienst verwenden, um einer EC2-Instanz eine Rolle zuzuweisen, dann eine Richtlinie zu dieser Rolle. Dies gewährt der EC2-Instanz alle Berechtigungen in der Richtlinie, ohne dass die Anmeldeinformationen lokal auf der Instanz gespeichert werden müssen. Benutzer mit einer niedrigeren Zugriffsstufe können bestimmte (und genehmigte!) Aufgaben in der EC2-Instanz ausführen, ohne dass höhere Zugriffsrechte gewährt werden müssen.

Eine allgemeine Fehlkonfiguration ist, den Zugriff auf den vollständigen Satz von Berechtigungen für jedes AWS-Element zuzuweisen. Wenn die Anwendung die Fähigkeit, Dateien auf Amazon S3 schreiben und es hat vollen Zugriff auf S3, kann es lesen, schreiben und löschen Sie jede einzelne Datei in S3 für dieses Konto. Wenn der Job des Skrips eine vierteljährliche Bereinigung nicht verwendeter Dateien ausführen soll, müssen beispielsweise keine Leseberechtigungen vorhanden sein. Verwenden Sie stattdessen den IAM-Dienst, um den Anwendungsschreibzugriff auf einen bestimmten Bucket in S3 zu gewähren. Durch das Zuweisen bestimmter Berechtigungen kann die Anwendung keine Dateien lesen oder löschen, in oder aus diesem Bucket.

„Im Falle eines Verstoßes ist das Schlimmste, was passieren kann, dass mehr Dateien auf Ihr Konto geschrieben werden. Keine Daten gehen verloren „, sagt Nunnkhoven.








Mistake


Fehler 5: genug. Erzwingen Sie starke Kennwörter und aktivieren Sie die Zwei-Faktor-Authentifizierung, um AWS-Instanzen zu verwalten. Aktivieren Sie für Anwendungen die Multifaktor-Authentifizierung. AWS bietet Tools zum Hinzufügen von Token wie einer physischen Karte oder einer Smartphone-App zum Einschalten der Multifaktor-Authentifizierung.

„Ihre Daten und Anwendungen sind das Herzstück Ihres Geschäfts“, warnt Robin von Evident.io.

Mistake 6: Exposed secrets and keys

Es sollte nicht so oft passieren, wie es funktioniert, aber Anmeldeinformationen werden oft hartcodiert in den Anwendungsquellcode gefunden oder Konfigurationsdateien, die Schlüssel und Passwörter enthalten, sind öffentlich zugänglich Standorten. AWS-Schlüssel wurden in öffentlichen Repositories im Laufe der Jahre ausgesetzt. GitHub durchsucht nun regelmäßig öffentliche Repositories, um Entwickler über exponierte AWS-Anmeldeinformationen zu informieren.

Die Schlüssel sollten regelmäßig gedreht werden. Seien Sie nicht der Administrator, der zu viel Zeit zwischen den Rotationen verbringen lässt. IAM ist leistungsfähig, aber viele seiner Eigenschaften werden häufig ignoriert. Alle Anmeldeinformationen, Passwörter und API-Zugriffstasten sollten häufig gedreht werden, so dass im Falle eines Kompromisses die gestohlenen Schlüssel nur für einen kurzen, festen Zeitrahmen gültig sind, wodurch der Angreiferzugriff auf Ihre Instanzen verringert wird. Administratoren sollten Richtlinien festlegen, um Kennwörter regelmäßig ablaufen zu lassen und die Wiederverwendung von Kennwörtern über Instanzen zu verhindern.

Wenn ein Angreifer in der Lage ist, Ihre Schlüssel zu stehlen, können sie dann auf die Ressourcen in Ihrem Konto zugreifen, als wären Sie es. Verwenden Sie Rollen, wann immer möglich „, sagt Nunnikhoven.

Fehler 7: Nicht die Wurzel ernst

Es taucht immer wieder auf. Admin vergessen zu deaktivieren Root-API-Zugang – eine sehr riskante Praxis. Niemand sollte das AWS-Root-Konto und die zugehörigen Schlüssel verwenden, geschweige denn über Benutzer und Anwendungen teilen. Schlüssel zum direkten Zugriff auf AWS-Ressourcen sollten sparsam verwendet werden, da die Schlüssel verfolgt, verwaltet und geschützt werden müssen. In Fällen, in denen root unbedingt erforderlich ist, hat Saviynt festgestellt, dass diese Konten oft die Multifaktor-Authentifizierung deaktiviert haben. Das Root-Konto verdient einen besseren Schutz als das.

Fehler 8: Putting alles in einem VPC oder Konto

Je mehr Teams und Workloads zu einem Konto oder Virtual Private Cloud (VPC) hinzugefügt werden, desto wahrscheinlicher werden Sie den kleinsten gemeinsamen Nenner treffen. AWS hat sehr großzügige Grenzen für VPCs und Konten. Es gibt keinen Grund, Workloads und Teams nicht in verschiedene Regionen, VPCs oder sogar Konten zu isolieren. Der einfachste Weg zu starten ist, um sicherzustellen, dass Entwicklung, Prüfung und Produktion in verschiedenen Konten sind.

Fehler 9: Verlassen Weit öffnen connEctions

Zu viele Admins ermöglichen globale Berechtigungen für Instanzen. Wenn Sie 0.0.0.0/0 verwenden, geben Sie jeder Maschine überall die Möglichkeit, eine Verbindung zu Ihren AWS-Ressourcen herzustellen. „Sie würden die Haustür nicht offen lassen, warum verwenden Sie 0.0.0.0/0?“, Fragt Robel.

AWS-Sicherheitsgruppen packen EC2-Instanzen ein, um den eingehenden und ausgehenden Datenverkehr zuzulassen oder zu verweigern. Es ist verlockend – und zweckmäßig! – Hinzufügen umfassender Zugriffsregeln auf Sicherheitsregeln. Kämpfe gegen den Drang. Geben Sie Ihren Sicherheitsgruppen den engsten Fokus möglich. Verwenden Sie verschiedene AWS-Sicherheitsgruppen als Quelle oder Ziel, um sicherzustellen, dass nur Instanzen und Lastausgleicher in einer bestimmten Gruppe mit einer anderen Gruppe kommunizieren können.

Ein Drittel der 30 häufigsten AWS-Konfigurationsfehler, die von Saviynt identifiziert wurden, sind offene Ports. Workloads zeigten offene RDP-, MySQL-, FTP- oder telnet-Ports über Sicherheitsgruppen, und Sicherheitsgruppen zeigten offene RDP- und SSH-Ports. Andere waren weit offen für das Internet.

Dank der hochwertigen Automatisierungswerkzeuge wie OpsWorks, Chef, Ansible und Puppet besteht kein Grund für den Remotezugriff – wie zB SSH oder RDP – auf EC2-Instanzen. Wenn eine Anwendung oder ein Betriebssystem gepatcht werden muss, ist es besser, ein neues Image zu erstellen und eine brandneue Instanz mit dem gepatchten anzuwenden, anstatt zu versuchen, eine Verbindung zur Instanz herzustellen und ein Patch zu installieren.

Wenn Remote-Zugriff erforderlich ist, ist ein „Bastion-Host“, bei dem die Benutzer eine Verbindung zu einer EC2-Instanz herstellen, sicherer. Es ist einfacher, alle Remotezugriffsverbindungen zu verwalten, die zu einem einzelnen Host gehen und dann einschränken, welche Verbindungen zwischen jeder Instanz möglich sind. Es ist auch möglich, den Bastion-Host zu sperren, so dass nur zugelassene Systeme erlaubt sind. Kontrollieren Sie alle Fernzugriffe, um Ihr Gesamtrisiko zu reduzieren.





Fehler 10: Skimping auf Verschlüsselung

Viele Organisationen ermöglichen keine Verschlüsselung in ihren AWS-Infrastrukturen, und die Gründe variieren von es ist zu schwer zu nicht erkennen, Saviynt festgestellt, dass relationale Datenbank-Service (RDS) -Instanzen mit der Verschlüsselung deaktiviert erstellt wurden – eine potenzielle Datenverletzung zu erwarten. In EC2 gab es Workloads mit unverschlüsseltem Elastic Block Storage (EBS).

Daten in S3 sollten geschützt werden und der Verkehr zwischen EC2-Instanzen sollte gesichert werden. Eine falsche Implementierung der Verschlüsselung ist genauso schlimm – wenn nicht sogar schlechter – als gar keine Verschlüsselung, doch bietet Amazon tatsächlich Tools an, um die Herausforderungen zu lindern. Administratoren, die die Verschlüsselung vor Bedenken bezüglich der Verwaltung von Schlüsseln ablehnen, sollten AWS diese Schlüssel verwalten lassen. Es ist immer möglich, nachher in die öffentliche Infrastruktur des Unternehmens zu migrieren.

Fehler, nicht Schwachstellen

Die Tatsache, dass privilegierte Benutzer eine ganze AWS-Umgebung mit kritischen Anwendungen und sensiblen Informationen reduzieren können, ist nicht die Schuld der Cloud. Es hebt hervor, dass für viele Organisationen die Sicherheitsimplementierung schwach ist. Administratoren müssen die gleichen strengen Kontrollen in ihren Rechenzentren auf ihre Cloud-Infrastrukturen anwenden. Viele dieser Konfigurationsfehler sind nicht schwer zu beheben, und sie verringern eine große Bandbreite von potenziellen Problemen und befreien Administratoren, um vertiefende Aufgaben zu behandeln, wie zum Beispiel das Ausführen eines Schwachstellen-Scanners wie Amazon Inspector oder Tenable Netzwerksicherheit Nessus. Aber zuerst das erste, und das bedeutet, dass die Sicherheit Hygiene in die Wolke.

  • Öffentliches Cloud-Megaguide: Amazon, Microsoft, Google, IBM und Joyent verglichen
  • Das dirty Dutzend: 12 Cloud Security Bedrohungen
  • Bossie
  • Maschinelles Lernen von Megaguide: Amazon, Microsoft, Databricks, Google, HPE, IBM
  • Verschieben von Legacy-Anwendungen in die Cloud
  • Cloud-Sicherheit Deep Dive
  • Rezension: Amazon Web Services ist die Welt essen
  • Diese Geschichte, „10 AWS Sicherheitsfehler und wie sie zu vermeiden“ war ursprünglich Veröffentlicht von InfoWorld.

    q , q

    Zusammenhängende Posts:

    Schreibe einen Kommentar

    Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.