Warum werden Cloud-Computing-Services nicht wie ein Service geschützt?

Original Artikel von Justin Foster (Software Architect, Trend Micro)

Angebote zu webbasierter Sicherheit als ein Service werden aufgrund der Vorteile des Verteilungsmodells immer beliebter. Sicherheit als ein Service ermöglicht durch Echtzeit-Updates und Feedback von Benutzern eine sehr schnelle Bereitstellung, Kostensenkungen und verbesserte Sicherheit.

Mit der explosionsartigen Zunahme des öffentlichen Cloud-Computings ist es an der Zeit, die Techniken, die wir für die Sicherheit AUS der Cloud einsetzen, nun auch zum Schutz FÜR die Cloud verwenden.

In Umgebungen der public Clouds, wie z. B. Amazon Web Services (AWS), bieten Instanzen von Elastic Compute Cloud (EC2) nur eine Firewall als Service. Es liegt am Kunden, alle Schwachstellen des Betriebssystems und der auf der virtuellen Maschine ausgeführten Anwendungen zu schließen. Das regelmäßige Patching kann die Angriffsflächen reduzieren, reicht aber nicht als einzige Maßnahme aus, um eine sichere Umgebung zu gewährleisten. Die einzige zurzeit brauchbare Option zur Stärkung des Sicherheitsprofils ist, dass der Kunde Host-basierte Steuerelemente verteilt und verwaltet. Host-basierte Agenten können Anti-Malware, IDS/IPS, WAF, DLP, Integritätsüberwachung und andere Funktionen bereitstellen, doch liegt es am Endbenutzer, diese Gegenmaßnahmen zu erwerben, zu verteilen, zu konfigurieren und zu überwachen.

Dies ist eine Chance für Service Provider: Sie können Sicherheit als einen Service zum Schutz der Instanzen anbieten, die ihre Kunden erzeugen. Mit der Einführung hochwertiger Pay-per-Use-Sicherheitsservices könnten Kunden die Gegenmaßnahmen auswählen, die sie je nach Funktion benötigen. Es bedarf dann einfach nur der Aktivierung in einer Check Box, um ihre virtuellen Maschinen nach Malware durchsuchen zu lassen.

Während dies eine natürliche Weiterentwicklung zu sein scheint, setzt sich Sicherheit als ein Service im Bereich Infrastructure-as-a-Service (IaaS) nur langsam durch. Dies liegt teilweise an der erforderlichen Architektur. Um die Unabhängigkeit der Plattform sowie die Flexibilität der Umgebung zu bewahren und virtualisierungsspezifische Themen wie Rollback zu lösen, sollten die Sicherheitsservices transparent außerhalb der virtuellen Maschine bereitgestellt werden (Platform-as-a-Service- und SaaS-Angebote unterliegen nicht dieser Einschränkung, da der Service Provider das Betriebssystem verwaltet).

Externe Sicherheit hat sich bereits in Sicherheit als ein Service zum Schutz AUS der Cloud bewährt, beispielsweise E-Mail-Gateways zum Filtern von Spam und Malware. Es ist nicht gängige Praxis, externe Sicherheit FÜR virtuelle Maschinen bei Cloud Providern bereitzustellen, aber es ist heute möglich – und zwar mit virtuellen Gateways oder virtuellen Appliances, die Hypervisor-Sicherheits-APIs einsetzen, um den Prozessor, den Arbeitsspeicher, das Netzwerk und den Speicher der virtuellen Maschinen zu überprüfen. Was Virtualisierungsplattformen angeht, so ist VMware hier mit VMsafe führend bei der Bereitstellung von Sicherheits-APIs. Service Providern, die andere Virtualisierungstechnologien einsetzen, stehen mittlerweile jedoch auch andere Optionen zur Verfügung.

Damit Sicherheit als ein Service auch brauchbar ist, muss Benutzerfreundlichkeit oberste Priorität haben. Bei AWS allein werden JEDEN TAG schätzungsweise 50.000 neue Instanzen hinzugefügt. Um den Anforderungen, den Preisvorstellungen, dem Ausmaß an Selbstbedienungsfunktionen und der Fachkenntnis der Benutzerbasis gerecht zu werden, müssen die Sicherheitslösungen einfach zu verwalten sein. Die aktuelle Konfiguration von Firewall-ACLs in heutigen IaaS-Angeboten der public Cloud ist ein perfektes Beispiel für die erforderliche Einfachheit. Während einige Sicherheitsservices nur sehr wenig Konfiguration erfordern (wie z. B. Anti-Malware), ist bei anderen seit jeher mehr Konfigurationsaufwand nötig. Um Erfolg zu haben, müssen die Sicherheitsservices so weit wie möglich rationalisiert und automatisiert werden. Das kann bedeuten, dass Hypervisor-Sicherheits-APIs verwendet werden, um den Inhalt der virtuellen Maschinen zu überprüfen und sie gemäß der auf ihr ausgeführten Arbeitslast zu konfigurieren.

Diese Anforderungen sind eine ganz besondere Herausforderung für Anbieter von Sicherheitssoftware, die schnell bedarfsgerechte, Mehrmandanten-fähige Lösungen bereitstellen müssen. Die Anbieter müssen sich auch mit dem Mangel an Standards für die Integration mit den Service Providern auseinandersetzen, eine Herausforderung, die erst im Lauf der Zeit durch das Erstellen gemeinsamer Sicherheits-APIs bewältigt werden kann. Für Service Provider bedeutet Sicherheit als ein Service eine zusätzliche Einnahmequelle und Wertsteigerung ihrer Services. Höchstwahrscheinlich werden die Lösungen zunächst von kleineren Service Providern angeboten, um sich von der Konkurrenz abzuheben. Es gibt jedoch genug Marktchancen, so dass auch die dominierenden Provider zwangsläufig nachziehen werden.

Unter Verwendung des dynamisch bereitgestellten, externen Pay-per-Use-Sicherheitsmodells, das bei webbasierten Services zum Schutz AUS der Cloud sehr gängig ist, macht Cloud-Computing zum Schutz FÜR die Cloud absolut Sinn. Endbenutzer haben Zugriff auf die von ihnen benötigten Sicherheitsservices, ohne selbst Zeit und Aufwand zu investieren, und erhalten Sicherheit, die genau so dynamisch ist wie die von ihnen verwendeten webbasierten Services.

Schreibe einen Kommentar

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

*