[ English | Indonesia | Deutsch | 日本語 ]

Faktoren, die die OpenStack-Bereitstellung beeinflussen

Sicherheitsanforderungen

Wenn OpenStack in einem Unternehmen als private Cloud bereitgestellt wird, befindet es sich in der Regel hinter der Firewall und im vertrauenswürdigen Netzwerk neben bestehenden Systemen. Benutzer sind Mitarbeiter, die an die Sicherheitsanforderungen des Unternehmens gebunden sind. Dies führt dazu, dass die meisten Sicherheitsbereiche zu einem vertrauenswürdigeren Modell tendieren. Wenn OpenStack jedoch in einer öffentlich zugänglichen Rolle eingesetzt wird, können keine Annahmen getroffen werden und die Angriffsvektoren steigen deutlich an.

Berücksichtigen Sie die folgenden Sicherheitsimplikationen und -anforderungen:

• Verwaltung der Benutzer für öffentliche und private Clouds. Der Identitätsdienst ermöglicht es, dass LDAP Teil des Authentifizierungsprozesses ist. Dies kann die Benutzerverwaltung bei der Integration in bestehende Systeme erleichtern.

• Benutzerauthentifizierungsanfragen enthalten sensible Informationen wie Benutzernamen, Passwörter und Authentifizierungstoken. Es wird dringend empfohlen, API-Dienste hinter Hardware zu platzieren, die eine SSL-Terminierung durchführt.

• Negative oder feindliche Benutzer, die die Sicherheit Ihrer Bereitstellung angreifen oder gefährden würden, unabhängig von Firewalls oder Sicherheitsvereinbarungen.

• Die Angriffsvektoren nehmen in einer öffentlich zugänglichen OpenStack-Bereitstellung weiter zu. So werden beispielsweise die API-Endpunkte und die dahinter stehende Software anfällig für feindliche Unternehmen, die versuchen, sich unbefugten Zugriff zu verschaffen oder den Zugriff auf Dienste zu verhindern. Sie sollten für eine angemessene Filterung und eine regelmäßige Sicherheitsüberprüfung sorgen.

Warnung

Achten Sie auf Konsistenz, wenn Sie Clouds von Drittanbietern zur Untersuchung von Authentifizierungsoptionen verwenden.

Weitere Informationen zu OpenStack Security finden Sie im OpenStack Security Guide.

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 die gleichen Authentifizierungs- und Autorisierungsanforderungen und Benutzer.

Zu den Sicherheitsdomänen gehören:

Öffentliche Sicherheitsbereiche

Der Bereich der öffentlichen Sicherheit kann sich auf das Internet als Ganzes oder auf Netzwerke beziehen, über die Sie keine Autorität haben. Diese Domain gilt als nicht vertrauenswürdig. Beispielsweise sind bei einer hybriden Cloud-Bereitstellung alle Informationen, die zwischen und über die Clouds hinausgehen, öffentlich zugänglich und nicht vertrauenswürdig.

Gastsicherheitsdomänen

Die Gastsicherheitsdomäne verarbeitet Compute-Daten, die von Instanzen in der Cloud erzeugt werden, nicht aber Dienste, die den Betrieb der Cloud unterstützen, wie beispielsweise API-Aufrufe. Public Cloud-Provider und private Cloud-Provider, die keine strengen Kontrollen der Instanznutzung haben oder einen uneingeschränkten Internetzugang zu Instanzen erlauben, sollten diese Domain als nicht vertrauenswürdig betrachten. Private Cloud-Anbieter können dieses Netzwerk als intern betrachten und daher nur dann vertrauenswürdig sein, wenn sie über Kontrollen verfügen, um zu behaupten, dass sie Instanzen und allen ihren Mandanten vertrauen.

Verwaltung von Sicherheitsdomänen

In der Verwaltungssicherheitsdomäne interagieren die Dienste. Die Netzwerke in dieser Domäne, die manchmal auch als Steuerungsebene bezeichnet werden, transportieren vertrauliche Daten wie Konfigurationsparameter, Benutzernamen und Passwörter. In den meisten Implementierungen gilt diese Domäne als vertrauenswürdig, wenn sie sich hinter der Firewall eines Unternehmens befindet.

Datensicherheitsdomänen

Die Datensicherheitsdomäne befasst sich in erster Linie mit Informationen über die Speicherdienste innerhalb von OpenStack. Die Daten, die dieses Netzwerk durchqueren, haben hohe Integritäts- und Vertraulichkeitsanforderungen und können je nach Art der Bereitstellung auch hohe Verfügbarkeitsanforderungen haben. Das Vertrauensniveau dieses Netzwerks ist stark von anderen Bereitstellungsentscheidungen abhängig.

Diese Sicherheitsdomänen können einzeln oder gemeinsam einer OpenStack-Bereitstellung zugeordnet werden. Der Cloud-Betreiber sollte sich der entsprechenden Sicherheitsbedenken bewusst sein. Sicherheitsdomänen sollten auf Ihre spezifische OpenStack-Bereitstellungstopologie abgestimmt sein. Die Domänen und ihre Vertrauensanforderungen hängen davon ab, ob die Cloud-Instanz öffentlich, privat oder hybrid ist.

Hypervisor-Sicherheit

Der Hypervisor verlangt auch eine Sicherheitsbewertung. In einer Public Cloud haben Unternehmen in der Regel keine Kontrolle über die Wahl des Hypervisors. Die richtige Sicherung Ihres Hypervisors ist wichtig. Angriffe auf den ungesicherten Hypervisor werden als Hypervisor Breakout bezeichnet. Hypervisor Breakout beschreibt das Ereignis, bei dem eine kompromittierte oder bösartige Instanz aus den Ressourcenkontrollen des Hypervisors ausbricht und Zugang zu den Bare-Metal-Betriebssystem- und Hardware-Ressourcen erhält.

Hypervisor-Sicherheit ist kein Thema, wenn die Sicherheit von Instanzen nicht wichtig ist. Unternehmen können jedoch die Schwachstelle minimieren, indem sie die gemeinsame Nutzung von Hardware mit anderen in einer Public Cloud vermeiden.

Baremetal-Sicherheit

Es gibt andere Dienste, die es wert sind, in Betracht gezogen zu werden, die eine Bare-Metal-Instanz anstelle einer Cloud bereitstellen. In anderen Fällen ist es möglich, eine zweite private Cloud zu replizieren, indem man sie in eine private Cloud-as-a-Service Bereitstellung integriert. Das Unternehmen kauft die Hardware nicht, teilt sich aber auch nicht mit anderen Mietern. Es ist auch möglich, einen Provider zu verwenden, der eine Bare-Metal-Public-Cloud-Instanz hostet, deren Hardware nur für einen Kunden bestimmt ist, oder einen Provider, der private Cloud-as-a-Service anbietet.

Wichtig

Jede Cloud implementiert Services unterschiedlich. Verstehen Sie die Sicherheitsanforderungen jeder Cloud, die mit den Daten oder Workloads des Unternehmens umgeht.

Netzwerksicherheit

Berücksichtigen Sie Sicherheitsimplikationen und -anforderungen, bevor Sie die physischen und logischen Netzwerktopologien entwerfen. Stellen Sie sicher, dass die Netzwerke ordnungsgemäß getrennt sind und die Verkehrsströme zu den richtigen Zielen gelangen, ohne unerwünschte Orte zu passieren. Berücksichtigen Sie die folgenden Faktoren:

• Firewalls

• Overlay-Verbindungen zum Verbinden getrennter Mandantennetze

• Routing durch oder Vermeidung bestimmter Netzwerke

Wie Netzwerke an Hypervisoren anbinden, kann Sicherheitsschwachstellen aufdecken. Um Hypervisor-Ausbrüche zu minimieren, trennen Sie Netzwerke von anderen Systemen und planen Sie Instanzen für das Netzwerk auf dedizierten Compute-Knoten. Dadurch wird verhindert, dass Angreifer von einer kompromittierten Instanz aus Zugriff auf die Netzwerke haben.

Sicherheit an mehreren Standorten

Die Sicherung einer OpenStack-Installation mit mehreren Standorten bringt mehrere Herausforderungen mit sich. Mandanten können erwarten, dass ein vom Mandanten geschaffenes Netzwerk sicher ist. Bei einer Installation mit mehreren Standorten kann die Verwendung einer nicht privaten Verbindung zwischen Standorten erforderlich sein. Dies kann bedeuten, dass der Datenverkehr für Dritte sichtbar wäre, und in Fällen, in denen eine Anwendung Sicherheit erfordert, erfordert dieses Problem eine Verringerung. Installieren Sie in diesen Fällen ein VPN oder eine verschlüsselte Verbindung zwischen Standorten, um vertraulichen Datenverkehr zu verbergen.

Identität ist ein weiterer Sicherheitsaspekt. Die Zentralisierung der Authentifizierung bietet einen einzigen Authentifizierungspunkt für Benutzer in der gesamten Bereitstellung und einen einzigen Verwaltungspunkt für traditionelle Erstellungs-, Lese-, Aktualisierungs- und Löschvorgänge. Die zentralisierte Authentifizierung ist auch für Auditierungszwecke nützlich, da alle Authentifizierungstoken aus derselben Quelle stammen.

Mandanten in standortübergreifenden Installationen müssen voneinander isoliert werden. Die größte Herausforderung besteht darin, sicherzustellen, dass Mandantennetzwerke in allen Regionen funktionieren, die derzeit nicht von OpenStack Networking (Neutron) unterstützt werden. Daher kann ein externes System erforderlich sein, um das Mapping zu verwalten. Mandantennetzwerke können sensible Informationen enthalten, die eine genaue und konsistente Zuordnung erfordern, um sicherzustellen, dass ein Mandante an einem Standort nicht mit einem anderen Mandanten an einem anderen Standort verbunden ist.

Gesetzliche Anforderungen

Die Nutzung von Remote-Ressourcen für die Erfassung, Verarbeitung, Speicherung und Abfrage bietet Unternehmen potenzielle Vorteile. Mit dem rasanten Wachstum von Daten in Unternehmen müssen Unternehmen ihre Datenspeicherstrategien aus Compliance-Sicht proaktiv angehen.

Die meisten Länder haben gesetzliche und regulatorische Anforderungen an die Speicherung und Verwaltung von Daten in Cloud-Umgebungen. Dies ist insbesondere für öffentliche, gemeinschaftliche und hybride Cloud-Modelle relevant, um den Datenschutz und den Schutz von Unternehmen zu gewährleisten, die einen Drittanbieter nutzen.

Zu den gemeinsamen Regelungsbereichen gehören:

• Datenhaltungsrichtlinien, die die Speicherung persistenter Daten und das Records Management sicherstellen, um den Anforderungen der Datenarchivierung gerecht zu werden.

• Richtlinien zum Datenbesitz, die den Besitz und die Verantwortung für Daten regeln.

• Richtlinien zur Datenhoheit, die die Speicherung von Daten im Ausland oder in anderen getrennten Jurisdiktionen regeln.

• Daten-Compliance-Richtlinien für bestimmte Arten von Informationen, die aufgrund von regulatorischen Problemen an bestimmten Orten aufbewahrt werden müssen - und vor allem, aus dem gleichen Grund nicht an anderen Orten aufbewahrt werden dürfen.

• Richtlinien zur Datenlokalisierung, die sicherstellen, dass die in der Cloud bereitgestellten Dienste gemäß den für die Mitarbeiter, ausländische Tochtergesellschaften oder Dritte geltenden Gesetzen und Vorschriften genutzt werden.

• Disaster-Recovery-Richtlinien, die regelmäßige Datensicherungen und die Verlagerung von Cloud-Anwendungen zu einem anderen Anbieter in Szenarien gewährleisten, in denen ein Provider aus dem Geschäft ausscheiden könnte oder sein Rechenzentrum inoperabel werden könnte.

• Sicherheitsverletzungsrichtlinien, die regeln, wie Personen über die Systeme des Cloud-Anbieters oder auf andere Weise benachrichtigt werden können, wenn ihre personenbezogenen Daten in irgendeiner Weise gefährdet werden.

• Richtlinie über Industrienormen, die zusätzliche Anforderungen festlegt, welche Art von Karteninhaberdaten gespeichert werden dürfen oder nicht und wie sie zu schützen sind.

Dies ist ein Beispiel für solche rechtlichen Rahmenbedingungen:

Die Datenschutzbestimmungen in Europa richten sich derzeit nach den Bestimmungen der Datenschutzbehörde. Die Financial Industry Regulatory Authority arbeitet in den Vereinigten Staaten daran.

Datenschutz und Sicherheit sind über verschiedene branchenspezifische Gesetze und Vorschriften verteilt:

• Krankenversicherungsgesetz (Health Insurance Portability and Accountability Act, HIPAA)

• Gramm-Leach-Bliley Act (GLBA)

• Zahlungskartenindustrie Datensicherheitsstandard (PCI DSS)

• Gesetz über die Rechte der Familienbildung und den Datenschutz (FERPA)

Cloud-Sicherheitsarchitektur

Die Cloud-Sicherheitsarchitektur sollte die Probleme erkennen, die beim Sicherheitsmanagement auftreten, das diese Probleme mit Sicherheitskontrollen angeht. Cloud-Sicherheitskontrollen werden eingerichtet, um Schwachstellen im System zu schützen und die Auswirkungen eines Angriffs zu reduzieren.

Die folgenden Sicherheitskontrollen werden im Folgenden beschrieben.

Abschreckende Kontrollen:

Reduzieren Sie in der Regel das Bedrohungsniveau, indem Sie potenzielle Angreifer darüber informieren, dass es für sie nachteilige Folgen haben wird, wenn sie fortfahren.

Vorbeugende Kontrollen:

Stärkung des Systems gegen Vorfälle, im Allgemeinen durch Reduzierung oder gar Beseitigung von Schwachstellen.

Detektivkontrollen:

Sie ist dazu bestimmt, auftretende Vorfälle zu erkennen und angemessen darauf zu reagieren. Die Überwachung der System- und Netzwerksicherheit, einschließlich Intrusion Detection und Prevention, wird typischerweise eingesetzt, um Angriffe auf Cloud-Systeme und die unterstützende Kommunikationsinfrastruktur zu erkennen.

Korrekturmaßnahmen:

Reduzieren Sie die Folgen eines Vorfalls, in der Regel durch Begrenzung des Schadens. Sie treten während oder nach einem Vorfall in Kraft. Die Wiederherstellung von System-Backups, um ein kompromittiertes System wiederherzustellen, ist ein Beispiel für eine Korrekturkontrolle.

Weitere Informationen finden Sie unter NIST-Sonderveröffentlichung 800-53.

Software-Lizenzierung

Die vielen verschiedenen Formen von Lizenzverträgen für Software werden oft mit Blick auf den Einsatz von dedizierter Hardware geschrieben. Dieses Modell ist für die Cloud-Plattform selbst relevant, einschließlich des Hypervisor-Betriebssystems, der unterstützenden Software für Elemente wie Datenbank, RPC, Backup und so weiter. Bei der Bereitstellung von Compute-Service-Instanzen und -Anwendungen für Endnutzer der Cloud ist zu berücksichtigen, da die Lizenzbedingungen für diese Software möglicherweise angepasst werden müssen, um in der Cloud wirtschaftlich arbeiten zu können.

Multi-Site-OpenStack-Implementierungen bieten zusätzliche Lizenzüberlegungen über die regulären OpenStack-Clouds hinaus, insbesondere wenn Standortlizenzen verwendet werden, um einen kosteneffizienten Zugriff auf Softwarelizenzen zu ermöglichen. Die Lizenzierung für Host-Betriebssysteme, Gastbetriebssysteme, OpenStack-Distributionen (falls zutreffend), softwaredefinierte Infrastrukturen einschließlich Netzwerkkontroller und Speichersysteme und sogar einzelne Anwendungen müssen bewertet werden.

Zu den zu berücksichtigenden Themen gehören:

• Die Definition dessen, was einen Standort in den entsprechenden Lizenzen ausmacht, da der Begriff nicht unbedingt einen geografischen oder anderweitig physisch isolierten Standort bezeichnet.

• Unterscheidung zwischen „heißen“ (aktiven) und „kalten“ (inaktiven) Standorten, bei denen erhebliche Einsparungen erzielt werden können, wenn ein Standort nur für Notfallzwecke als Cold Standby zur Verfügung steht.

• Bestimmte Standorte können von lokalen Anbietern verlangen, dass sie für jeden Standort Support und Dienstleistungen anbieten, die von der bestehenden Lizenzvereinbarung abweichen können.