Sicherheitsgrenzen und Bedrohungen

Eine Cloud kann als eine Sammlung von logischen Komponenten durch ihre Funktion, Benutzer und gemeinsame Sicherheitsbedenken, die wir Sicherheitsdomänen nennen, abstrahiert werden. Bedrohungsakteure und Vektoren werden aufgrund ihrer Motivation und des Zugangs zu Ressourcen klassifiziert. Unser Ziel ist es, Ihnen ein Gefühl der Sicherheitsbedenken zu geben in Bezug auf jede Domain in Abhängigkeit von Ihrem Risiko/Verwundbarkeit, Schutz und Ziele.

Sicherheitsdomänen

Eine Sicherheitsdomäne umfasst Benutzer, Anwendungen, Server oder Netzwerke, die gemeinsame Vertrauensanforderungen und Erwartungen innerhalb eines Systems teilen. In der Regel haben sie das gleiche authentication und authorization (AuthN/Z) Anforderungen und Benutzer.

Obwohl Sie es wünschen, diese Domains weiter zu unterteilen (wir diskutieren weiter, wo dies angebracht sein kann), beziehen wir uns in der Regel auf vier verschiedene Sicherheitsdomänen, die das bloße Minimum bilden, das erforderlich ist, um eine beliebige OpenStack-Cloud sicher zu implementieren. Diese Sicherheitsdomänen sind:

1. Public

2. Gast

3. Management

4. Daten

Wir haben diese Sicherheitsdomänen ausgewählt, weil sie unabhängig voneinander zugeordnet oder kombiniert werden können, um die Mehrheit der möglichen Vertrauensbereiche innerhalb einer gegebenen OpenStack-Bereitstellung darzustellen. Zum Beispiel können einige Bereitstellungstopologien aus einer Kombination von Gast- und Datendomänen auf einem physischen Netzwerk bestehen, während andere Topologien diese Domänen getrennt haben. In jedem Fall sollte der Cloud-Betreiber sich der entsprechenden Sicherheitsbedenken bewusst sein. Sicherheitsdomänen sollten auf Ihre spezifische OpenStack-Bereitstellungstopologie abgebildet werden. Die Domänen und ihre Vertrauensanforderungen hängen davon ab, ob die Cloud-Instanz öffentlich, privat oder hybride ist.

Public

Die öffentliche Sicherheitsdomäne ist ein vollständig nicht vertrauenswürdiger Bereich der Cloud-Infrastruktur. Es kann sich auf das Internet als Ganzes beziehen oder einfach auf Netzwerke, über die Sie keine Autorität haben. Alle Daten, die diese Domain mit Vertraulichkeit oder Integritätsanforderungen überträgt, sollten mit Kompensationskontrollen geschützt werden.

Diese Domain sollte immer als nicht vertrauenswürdig betrachtet werden.

Gast

Typisch für die Compute von Instanz-zu-Instanz-Verkehr verwendet, die Gast-Security-Domäne verarbeitet Compute-Daten, die von Instanzen auf der Cloud erzeugt werden, aber nicht Dienste, die den Betrieb der Cloud unterstützen, wie z. B. API-Aufrufe.

Öffentliche und private Cloud-Anbieter, die keine strengen Kontrollen auf Instanz verwenden oder einen uneingeschränkten Internetzugriff auf VMs zulassen, sollten diese Domain als nicht vertrauenswürdig ansehen. Private Cloud-Provider können dieses Netzwerk als interne und vertrauenswürdige nur dann betrachten, wenn die richtigen Kontrollen implementiert sind, um zu behaupten, dass die Instanzen und alle damit verbundenen Tenants vertraut werden sollen.

Management

Die Verwaltungssicherheitsdomäne ist, wo Dienste interagieren. Manchmal auch als „control plane“ bezeichnet, transportieren die Netzwerke in diesem Bereich vertrauliche Daten wie Konfigurationsparameter, Benutzernamen und Passwörter. Command- und Control-Traffic befindet sich in dieser Domain, was eine starke Integritätsanforderung erfordert. Der Zugriff auf diese Domain sollte stark eingeschränkt und überwacht werden. Gleichzeitig sollte diese Domain immer noch alle in dieser Anleitung beschriebenen Sicherheitsbestimmungen verwenden.

In den meisten Bereitstellungen gilt diese Domain als * vertrauenswürdig *. Allerdings, wenn man eine OpenStack-Bereitstellung betrachtet, gibt es viele Systeme, die diese Domain mit anderen überbrücken und möglicherweise das Vertrauensniveau reduzieren, das Sie auf dieser Domain platzieren können. Siehe Überbrückung von Sicherheitsdomänen für weitere Informationen.

Daten

Die Datensicherheitsdomäne beschäftigt sich primär mit Informationen über die Speicherdienste im Rahmen von OpenStack. Die meisten Daten, die über dieses Netzwerk übertragen werden, benötigen ein hohes Maß an Integrität und Vertraulichkeit. In einigen Fällen kann es je nach Art der Bereitstellung auch starke Verfügbarkeitsanforderungen geben.

Die Vertrauensstufe dieses Netzwerks hängt stark von den Entscheidungsentscheidungen ab, und als solche vergeben wir diese Standardvertragsstufe nicht.

Überbrückung von Sicherheitsdomänen

Eine Brücke ist eine Komponente, die in mehr als einer Sicherheitsdomäne existiert. Jede Komponente, die Sicherheitsdomänen mit unterschiedlichen Vertrauensstufen oder Authentifizierungsanforderungen überbrückt, muss sorgfältig konfiguriert werden. Diese Brücken sind oft die Schwachstellen in der Netzwerkarchitektur. Eine Brücke sollte immer so konfiguriert sein, dass sie die Sicherheitsanforderungen der höchsten Vertrauensstufe eines der Domänen erfüllt, die sie überbrückt. In vielen Fällen sollten die Sicherheitskontrollen für Brücken aufgrund der Wahrscheinlichkeit des Angriffs ein Hauptanliegen sein.

Das obige Diagramm zeigt einen Compute-Knoten, der die Daten- und Verwaltungsdomänen überbrückt; Als solches sollte der Compute-Knoten so konfiguriert sein, dass er die Sicherheitsanforderungen der Verwaltungsdomäne erfüllt. Ähnlich überbrückt der API-Endpunkt in diesem Diagramm die nicht vertrauenswürdige Öffentlichkeit und die Verwaltungsdomäne, die so konfiguriert sein sollte, dass sie vor Angriffen von der Öffentlichkeit, die sich in die Verwaltungsdomäne ausbreiten, schützen soll.

In manchen Fällen können sich die Deployer in Erwägung ziehen, eine Brücke zu einem höheren Standard zu sichern als irgendeine der Domänen, in denen sie sich befindet. Angesichts des obigen Beispiels eines API-Endpunkts könnte ein Gegner potenziell auf den API-Endpunkt aus der Public Domain zielen und ihn in die Hoffnung auf Kompromittierung oder Zugang zu der Management-Domain nutzen.

Das Design von OpenStack ist so, dass die Trennung von Sicherheitsdomänen schwierig ist. Da Kerndienste in der Regel mindestens zwei Domänen überbrücken, muss bei der Anwendung von Sicherheitskontrollen besondere Rücksicht genommen werden.

Bedrohungsklassifikation, Akteure und Angriffsvektoren

Die meisten Arten von Cloud-Bereitstellung, öffentlich oder privat, sind einer Form von Angriff ausgesetzt. In diesem Kapitel kategorisieren wir Angreifer und fassen mögliche Angriffsarten in jeder Sicherheitsdomäne zusammen.

Bedrohungsakteure

Ein Bedrohungsakteuer ist ein abstrakter Weg, um auf eine Klasse von Gegnern zu verweisen, gegen die Sie versuchen können, sich zu verteidigen. Je leistungsfähiger der Akteur, desto teurer sind die Sicherheitskontrollen, die für eine erfolgreiche Angriffsminderung und Prävention erforderlich sind. Sicherheit ist ein Kompromiss zwischen Kosten, Usability und Verteidigung. In manchen Fällen wird es nicht möglich sein, eine Cloud-Implementierung gegen alle von uns hier beschriebenen Bedrohungsakteure zu sichern. Diejenigen, die eine OpenStack-Cloud einsetzen, müssen entscheiden, wo die Balance für ihre Bereitstellung/Nutzung liegt.

Geheimdienste

Von diesem Guide als der fähigste Gegner betrachtet. Intelligenzdienste und andere staatliche Akteure können enorme Ressourcen auf ein Ziel bringen. Sie haben Fähigkeiten jenseits eines anderen Akteurs. Es ist sehr schwierig, sich gegen diese Akteure ohne unglaublich strenge Kontrollen zu verteidigen, sowohl menschliche als auch technische.

Ernstes organisiertes Verbrechen

Hochfähige und finanziell getriebene Gruppen von Angreifern. In der Lage, eigene Entwicklung und Zielforschung zu finanzieren. In den letzten Jahren hat der Aufstieg von Organisationen wie dem russischen Business Network, einem massiven Cyber-Criminal-Unternehmen, gezeigt, wie Cyber-Attacken zu einer Ware geworden sind. Industriespionage fällt in die schwere organisierte Kriminalität.

Hochfähige Gruppen

Dies bezieht sich auf ‚Hacktivist‘-Typen, die typischerweise nicht kommerziell finanziert werden, aber eine ernsthafte Bedrohung für Dienstleister und Cloud-Betreiber darstellen können.

Motivierte Personen

Alleine handelnd, kommen diese Angreifer in viele Gestalten, wie Schurken oder böswillige Angestellte, unzufriedene Kunden oder kleine Industriespionage.

Skript Kiddies

Automatisierte Verwundbarkeit Scannen/Ausbeutung. Nicht gezielte Angriffe. Oft nur ein Ärgernis, Kompromiss eines dieser Akteure stellt ein großes Risiko für den Ruf einer Organisation dar.

Öffentliche und private Cloud-Überlegungen

Private Clouds werden typischerweise von Unternehmen oder Institutionen in ihren Netzwerken und hinter ihren Firewalls eingesetzt. Unternehmen haben strenge Richtlinien, welche Daten erlaubt werden, ihr Netzwerk zu verlassen und können sogar unterschiedliche Clouds für bestimmte Zwecke haben. Benutzer einer privaten Cloud sind typischerweise Angestellte der Organisation, die die Cloud besitzt und für ihre Handlungen verantwortlich gemacht werden können. Die Mitarbeiter besuchen oft Schulungen, bevor sie auf die Cloud zugreifen und werden wahrscheinlich an regelmäßig geplanten Sicherheitsbewusstseinstraining teilnehmen. Öffentliche Clouds dagegen können keine Behauptungen über ihre Benutzer, Cloud-Use-Cases oder User-Motivationen machen. Dies drückt sofort die Gast-Sicherheits-Domain in einen völlig nicht vertrauenswürdigen Status für öffentliche Cloud-Anbieter.

Ein bemerkenswerter Unterschied in der Angriffsfläche der öffentlichen Clouds ist, dass sie Internet-Zugang zu ihren Dienstleistungen bieten müssen. Instanz-Konnektivität, Zugriff auf Dateien über das Internet und die Fähigkeit, mit dem Cloud-Controlling-Gewebe wie die API-Endpunkte und Dashboard zu interagieren, sind Must-Haves für die öffentliche Cloud.

Datenschutzbedenken für öffentliche und private Cloud-Benutzer sind typischerweise diametral entgegengesetzt. Die Daten, die in privaten Clouds erzeugt und gespeichert werden, befinden sich normalerweise im Besitz des Betreibers der Cloud, der in der Lage ist, Technologien wie z.B. :term: Datenverlustprävention (DLP) <Data loss prevention (DLP) software>`Schutz, Datei Inspektion, Deep Packet Inspection und prescriptive Firewalling. Im Gegensatz dazu ist die Privatsphäre eine der primären Barrieren für die Annahme von öffentlichen Cloud-Infrastrukturen, da viele der zuvor erwähnten Steuerelemente nicht vorhanden sind.

Outbound-Angriffe und Reputationsrisiken

Sorgfältige Berücksichtigung von potenziellen Outbound-Missbrauch aus einer Cloud-Bereitstellung. Ob öffentlich oder privat, Clouds neigen dazu, viel Ressourcen zur Verfügung zu haben. Ein Angreifer, der in der Cloud einen Punkt der Präsenz in der Cloud etabliert hat, kann entweder durch Hacken oder berechtigten Zugang, wie z. B. Schurkenarbeiter, diese Ressourcen gegen das Internet einsetzen. Clouds mit Compute Services sorgen für ideale DDoS- und Brute-Power-Motoren. Das Problem ist dringender für öffentliche Clouds, da ihre Benutzer weitgehend unerklärlich sind und schnell eine hohe Anzahl von Einweg-Instanzen für ausgehende Angriffe starten können. Größere Schäden können dem Ruf eines Unternehmens zugerechnet werden, wenn es bekannt ist, schädliche Software zu hosten oder Angriffe auf andere Netzwerke zu starten. Methoden der Prävention gehören ausgehende Sicherheits-Gruppen, ausgehende Verkehrskontrolle, Kundenerziehung und Bewusstsein, und Betrug und Strategie zur Abschwächung von Missbrauch.

Angriffstypen

Das Diagramm zeigt die typischen Angriffsarten, die von den im vorigen Abschnitt beschriebenen Akteuren erwartet werden können. Beachten Sie, dass es immer Ausnahmen von diesem Diagramm gibt.

Angriffstypen

Die präskriptive Verteidigung für jede Form des Angriffs geht über den Rahmen dieses Dokuments hinaus. Das obige Diagramm kann Ihnen helfen, eine fundierte Entscheidung darüber zu treffen, vor welche Arten von Bedrohungen und Bedrohungsakteure geschützt werden sollen. Für kommerzielle öffentliche Cloud-Implementierungen könnte dies die Prävention gegen schweres Verbrechen beinhalten. Für diejenigen, die private Clouds für die staatliche Nutzung einsetzen, sollten strengere Schutzmechanismen vorhanden sein, einschließlich sorgfältig geschützter Einrichtungen und Lieferketten. Im Gegensatz dazu werden diejenigen, die Grundentwicklungs- oder Testumgebungen aufbauen, wahrscheinlich weniger restriktive Kontrollen (Mitte des Spektrums) erfordern.