Bereich 7 Infrastruktur-Sicherheit

vPierre Cloud, Cloud Computing, Sicherheit / Security Leave a Comment

Zentrale Cloud-Infrastruktursicherheit, Netzwerk- und Arbeitslast-Sicherheit sowie Betrachtungen für Hybrid-Clouds. Dieser Bereich umfasst auch Sicherheitsgrundlagen für private Clouds.

  • Einleitung
  • Infrastruktur-Sicherheit ist die Grundlage für einen sicheren Betrieb in der Cloud.
  • Sie umfasst die untersten Schichten der Sicherheit von den physischen Einrichtungen über die Konfiguration des Kunden bis zur Implementierung der Infrastruktur-Komponenten.
    • Das umfasst die Sicherheit für Computer (Arbeitslast), Netzwerke und Speichersysteme.
    • Die Sicherheit von Speichersystemen wird in Bereich 11 behandelt, dieser Bereich kümmert sich um die Sicherheit von Netzwerk und Arbeitslast einschließlich Betrachtungen für hybride Clouds.
  • Grundlegende Sicherheit im Rechenzentrum gehört nicht zum Umfang der CSA-Anleitung. Cloud-Provider und Nutzer privater Clouds sollten bei den bestehenden Industriestandards nachsehen.
  • Überblick
  • Definition der Infrastruktur
    • Zwei Ebenen
      • Die grundlegenden Ressourcen sind in einem Pool zusammengefasst, um eine Cloud zu bilden. Z.B. Computer, Netzwerke und Speichersysteme.
      • Die virtuelle/abstrahierte Infrastruktur wird von einem Cloud-Kunden gemanagt. Die verwendeten Dinge für Computer, Netzwerk und Speicherung stammen aus den Ressourcen-Pools,
    • Dieser Bereich beschäftigt sich mit der Infrastruktursicherheit für den Cloud-Kunden. Die Infrastruktursicherheit für Cloud-Provider einschließlich jener, die private Clouds managen, ist stark an bestehenden Sicherheitsstandards für Rechenzentren orientiert.
  • Cloud-Netzwerksicherheit
    • Alle Clouds verwenden virtuelle Netzwerke.
      • Das ist die einzige Möglichkeit zur Abstraktion von einem physischen Netzwerk.
    • Zwei Hauptkategorien
      • VLAN-basiert
        • Ausnutzung vorhandener Netzwerktechnologie, die in der meisten Netzwerk-Hardware implementiert ist.
        • Ist für die Verwendung in Netzwerken einzelner Mandaten konstruiert (Unternehmens-Rechenzentren), um verschiedene Geschäftsbereiche, Funktionen usw. (wie Gast-Netzwerke) zu trennen.
        • Verwendet einen festen Pool sich nicht überschneidender IP-Adressen und anderer Netzwerk-Kennungen.
      • Software Defined Networking (SDN)
        • Eine vollständigere Abstraktionsschicht über der Netzwerk-Hardware.
        • mehrere Implementierungen einschließlich auf Standards basierend und proprietär.
        • Abhängig von der Implementierung kann das viel mehr Flexibilität und Isolierung bieten. Zum Beispiel mehrere abgetrennte sich überlappende IP-Bereiche für ein virtuelles Netzwerk über demselben physischen Netzwerk.
        • Bietet typisch eine Softwaredefinition von frei wählbaren IP-Bereichen und ermöglicht Kunden eine bessere Ausweitung ihrer bestehenden Netzwerke in die Cloud.
        • Kann für einen Cloud-Kunden an der Oberfläche wie ein normales Netzwerk aussehen, funktioniert unter der Oberfläche aber ziemlich anders, weil es eine vollständigere Abstraktion ist.
        • Sehr verbreitet wird eine Paketkapselung verwendet, so dass virtuelle Maschinen anderer „standardmäßiger“ Systeme keinerlei Änderungen an ihrem Netzwerkstack erfordern.
    • Wie sich die Sicherheit ändert
      • Das Fehlen physischer Netzwerke ändert gängige Netzwerkpraktiken.
        • Sniffing ist entweder nicht möglich oder sollte standardmäßig deaktiviert sein.
          • Sicherheits-Tools des Kunden müssen daher auf ein virtuelles Inline-Gerät oder einen auf den Instanzen installierten Software-Agenten vertrauen.
        • Physische Geräte lassen sich nicht einsetzen (außer durch den Cloud-Provider). Sie müssen durch virtuelle Geräte ersetzt werden, wenn das Cloud-Netzwerk das nötige Routing unterstützt.
          • Virtuelle Geräte werden daher zu Flaschenhälsen, weil sie nicht einfach öffnen können. sondern sämtlichen Datenverkehr abhören.
          • Virtuelle Geräte können erhebliche Ressourcen erfordern und die Kosten erhöhen, um die Anforderungen an die Netzwerkleistung zu erfüllen.
          • Virtuelle Geräte sollten eine Auto-Skalierung unterstützen, um der Elastizität der durch sie geschützten Ressourcen zu entsprechen.
        • Komponenten von Cloud-Anwendungen sind tendenziell mehr verteilt, um die Widerstandsfähigkeit zu erhöhen und können wegen automatischer Skalierung virtueller Server kürzere Lebensdauern haben und produktiver sein. Das ändert, wie Sicherheitsrichtlinien gestaltet sein müssen.
          • Das induziert sehr häufige Änderungen, mit denen Sicherheits-Tools umgehen müssen (z.B. Server mit einer Lebensdauer von unter einer Stunde).
          • IP-Adressen ändern sich viel schneller als in einem herkömmlichen Netzwerk, was Sicherheits-Tools berücksichtigen müssen.
          • Anlagen existieren wahrscheinlich nicht an statischen IP-Adressen.
          • Verschiedene Anlagen können sich innerhalb kurzer Zeit die gleiche IP-Adresse teilen.
          • Anlagen mit einer einzelnen Anwendungsschicht befinden sich häufig zwecks Widerstandsfähigkeit auf mehreren Subnetzen, was IP-basierte Sicherheitsrichtlinien noch komplizierter macht.
          • Weniger Dienste pro Server bieten Ihnen bessere Möglichkeiten, restriktive Firewall-Regeln festzulegen.
      • Software-definierte Netzwerke ermöglichen neuartige Sicherheitskontrollen
        • Die Isolierung ist einfacher. Ohne Beschränkungen der physischen Hardware können Sie so viele isolierte Netzwerke aufbauen, wie Sie möchten.
        • SDN-Firewalls (z.B. Sicherheitsgruppen) können für Anlagen basierend auf flexibleren Kriterien angewandt werden als Hardware-Firewalls, weil sie nicht durch die physische Topologie beschränkt sind,
          • SDN-Firewalls sind typisch Richtlinien-Sätze, welche Eingangs- und Ausgangsregeln definieren, die für einzelne Anlagen oder Anlagengruppen unabhängig von ihrem Ort im Netzwerk (innerhalb eines gegebenen virtuellen Netzwerks) gelten können .
          • Kombiniert mit der Orchestrierungs-Schicht der Cloud-Plattform ermöglicht das sehr dynamische und granuläre Kombinationen sowie Richtlinien mit weniger Verwaltungs-Overhead als die äquivalente Nutzung herkömmlicher Hardware oder hostbasierter Ansätze.
          • Die standardmäßige Verweigerung ist häufig der Ausgangspunkt, von wo aus Sie Verbindungen öffnen müssen, was im Gegensatz zu den meisten physischen Netzwerk-Firewalls steht.
          • Betrachten Sie das als die Granularität einer Host-Firewall mit besserer Handlichkeit als ein Netzwerk-Gerät.
          • Können potenziell auch auf anderen Kriterien wie etwa Tags angewandt werden.
          • Beachten Sie, auch wenn das Potenzial besteht, hängen die tatsächlichen Fähigkeiten von der Plattform ab.
        • Viele Netzwerk-Angriffe werden standardmäßig eliminiert (je nach Ihren Plattformen), etwa ARP-Spoofing und andere Taten auf niedriger Ebene über die reine Beseitigung von Schnüffeln hinaus.
        • Es besteht das Potenzial für standardmäßige Verschlüsselung, da Pakte gekapselt sind.
        • Wie bei Sicherheitsgruppen können anderen Routing- und Netzwerk-Designs dynamisch und an die Orchestrierungsschicht des Providers gebunden sein.
        • Zusätzliche Sicherheitsfunktionen lassen sich nativ hinzufügen.
      • Für Cloud-Provider oder private Clouds sind zusätzliche Anstrengungen erforderlich.
        • Sie müssen die Kernsicherheit des herkömmlichen physischen Netzwerkes erhalten, worauf die Plattform aufgebaut ist.
        • Sie müssen das auch mit beliebigen Kommunikationen und mehreren Mandaten machen.
        • Absolut wichtig ist die Erhaltung der Abgrenzung und Isolierung in der mandantenfähigen Umgebung.
        • Zusätzlicher Overhead für die richtige Aktivierung, Konfiguration und Erhaltung der SDN-Sicherheitskontrollen.
        • Sie müssen die Sicherheitskontrollen auch den Cloud-Kunden darlegen.
        • Sie müssen Perimeter-Sicherheit implementieren, welche die Umgebung schützt, aber die Auswirkung auf Arbeitslasten der Kunden minimiert.
    • Betrachtungen für die Hybrid-Cloud
      • Idealerweise unterstützt die Hybrid-Cloud frei wählbare Netzwerkadressierung und hilft, Netzwerke der Cloud-Kunden nahtlos auszudehnen.
      • Die hybride Verbindung  kann die Sicherheit des Cloud-Netzwerkes verringern, falls das private Netzwerk kein äquivalentes Sicherheitsniveau besitzt.
      • Eine hybride Verbindung sollte nicht die Sicherheit beider Netzwerke reduzieren.
        • Das sollte durchgesetzt werden mittels Routing, Zugangskontrollen und sogar Firewalls oder zusätzlichen Tools für Netzwerksicherheit.
      • Normalerweise ist es vorzuziehen, die hybriden Verbindungen zu minimieren. Häufig sind sie dennoch notwendig, aber nehmen Sie nicht, sie sind erforderlich.
        • Sie erhöhen die Komplexität bei Routing.
        • Sie können die Fähigkeit zum Betrieb mehrerer Cloud-Netzwerke mit überlappenden IP-Bereichen vermindern.
        • Sie machen die Sicherheit auf beiden Seiten komplizierter, weil die Sicherheitskontrollen aufeinander abgestimmt werden müssen.
  • Sicherheit von Cloud-Computing und Arbeitslasten
    • Eine Arbeitslast ist eine Verarbeitungseinheit, die in einer virtuellen Maschine, einem Container oder einer anderen Abstraktion sein kann.
    • Arbeitslasten laufen immer irgendwo auf einem Prozessor und verbrauchen Speicherplatz.
    • Wie die Cloud die Sicherheit von Arbeitslasten ändert
      • Mehrere Arbeitslasten werden sich fast immer denselben zugrundeliegenden Prozessor und Speicher teilen.
        • Mehrere Mandanten werden sich wahrscheinlich denselben physischen Rechnerknoten teilen.
          • Dedizierte private Mietverhältnisse sind möglich, aber normalerweise zu höheren Kosten (für die öffentliche Cloud als ein Kunde und bei der privaten Cloud wegen der weniger effizienten Nutzung der Ressourcen).
        • Der Kunde hat kaum die Kontrolle darüber, wo eine Arbeitslast physisch läuft.
        • Es gibt mehrere Abstraktionsarten mit unterschiedlichem Ausmaß der Abgrenzung und Isolierung.
          • Virtuelle Maschinen
            • sind am bekanntesten und können in die Fähigkeiten der zugrundeliegenden Hardware eingebunden werden, um die Isolierung zu verstärken.
            • Potenziell offen für bestimmte Speicherangriffe, aber das ist zunehmend schwierig.
          • Container
            • Mehrere Container können auf derselben virtuellen Maschine laufen oder ohne Einsatz von VMs implementiert werden.
            • neuer und mit unterschiedlichen Fähigkeiten zur Isolierung, die stark von der Plattform abhängig sind.
          • plattformbasierte Arbeitslasten (z.B. Logik/Prozeduren, die auf einer gemeinsamen Datenbank-Plattform laufen)
            • die Sicherheit der Isolierung liegt völlig in der Verantwortung des Plattformanbieters.
      • Unveränderbare Arbeitslasten ermöglichen Sicherheit.
        • Autoskalierung und Container funktionieren von Natur aus am besten, wenn Sie dynamisch basierend auf einem Image gestartete Instanzen nutzen und diese Instanzen abgeschaltet werden können, wenn sie nicht mehr gebraucht werden, ohne einen Anwendungs-Stack zu unterbrechen.
        • So werden Sie eine laufende Arbeitslast nicht mehr reparieren oder anderweitig ändern, weil dies das Image nicht ändern würde und daher neue Instanzen nicht mehr synchron wären.
        • Stattdessen aktualisieren Sie das zugrundeliegende Image und wechseln zu den neuen Instanzen, indem Sie die alten abschalten und die neuen starten.
        • Das bringt erhebliche Sicherheitsvorteile.
          • Sie reparieren nicht mehr laufende Systeme und sorgen sich dabei um Abhängigkeiten, unterbrochene Reparaturprozesse usw. sondern ersetzen diese durch einen neuen Gold-Master.
          • Sie können und sollten eine Fernanmeldung an laufenden Arbeitslasten deaktivieren (falls Anmeldungen überhaupt eine Option sind). Das ist eine operative Anforderung, um inkonsistente Änderungen über den Stack zu verhindern, was zugleich einen großen Sicherheitsvorteil bringt.
          • Die Einführung aktualisierter Versionen geht viel schneller, weil Anwendungen so gestaltet werden müssen, dass sie mit einzelnen herunterfahrenden Knoten umgehen können (erinnern Sie sich, dies ist grundlegend für jede Autoskalierung).
          • Es ist einfacher, Dienste und Whitelist-Anwendungen/Prozesse zu deaktivieren.
          • Die meisten Sicherheitstest können beim Erzeugen des Images erfolgen, was die Notwendigkeit von Schwachstellenanalysen an laufenden Arbeitslasten verringert, weil deren Verhalten vollständig bekannt sein sollte.
        • Das fügt Anforderungen hinzu.
          • Ein konsistenter Prozess zum Erzeugen der Images ist nötig.
          • In den Prozess müssen Sicherheitstests integriert werden einschließlich Test des Quellcodes sowie einer Schwachstellenanalyse, falls virtuelle Maschinen oder Standard-Container verwendet werden.
          • Mechanismen zum Deaktivieren von Anmeldungen und zur Beschränkung von Diensten sind nötig.
            • Für manche Arbeitslasten kann ein Prozess gewünscht sein, um zur Fehlerbehebung Anmeldungen zu Arbeitslasten zu ermöglichen, die nicht aktiv im Anwendungs-Stack sind. Das könnte eine Arbeitslast sein, die von einer Gruppe abgezogen wurde, aber in Isolierung weiterlaufen darf.
            • Alternativ (und häufig bevorzugt) senden Sie ausreichen detaillierte Protokolle an einen externen Datensammler, so dass niemals eine Anmeldung nötig ist.
          • Erhöhte Komplexität zur Verwaltung des Servicekatalogs.
      • Einige Standardkontrollen von Arbeitslasten sind nicht möglich (z.B. das Ausführen von Antivirus innerhalb einiger Container-Arten). Andere sind nicht unbedingt notwendig.
        • Die Möglichkeit zur Ausführung von Software-Agenten für nicht VM-basierte Arbeitslasten kann verlorengehen.
        • Agenten können die Leistungsanforderungen behindern.
          • Schlanke Agenten mit geringeren Leistungsanforderungen ermöglichen eine bessere Arbeitslastverteilung und effiziente Nutzung von Ressourcen.
        • Laufende Agenten müssen dynamische Cloud-Arbeitslasten unterstützen.
          • Sie dürfen nicht von statischer IP-Adressierung abhängen.
          • Sie müssen die Management-/Kontrollebene entdecken können.
          • Die Managementebene muss in der Geschwindigkeit der Autoskalierung arbeiten und Elastizität unterstützen (z.B. fähig sein, mit unglaublich dynamischer IP-Adressierung mitzuhalten, etwa das dieselbe Adresse innerhalb einer Stunde von mehreren Arbeitslasten verwendet wird).
          • Agenten sollten die Angriffsfläche wegen Kommunikation/Vernetzung oder anderer Anforderungen nicht vergrößern,
        • Unveränderliche Arbeitslasten erfordern wegen ihrer gehärteten Natur normalerweise weniger zusätzliche Sicherheits-Tools.
      • Langlaufende VMs benötigen dennoch Standard-Sicherheitskontrollen, haben aber andere Managementanforderungen.
        • Sie können im Netzwerk stärker isoliert sein, wodurch Sie die Art und Weise ihrer Verwaltung ändert.
        • Isoliert laufende Cloud-Arbeitslasten sind wegen ihrer Abstraktion normalerweise weniger widerstandsfähig als auf einer physischen Infrastruktur. Die Notfallwiederherstellung ist noch wichtiger.
      • Die Sicherheits-Protokollierung/Überwachung ist komplexer.
        • IP-Adressen würden einen bestimmten Arbeitsablauf nicht wiedergeben
        • Protokolle müssen ausgeladen und schneller extern gesammelt werden.
        • Protokoll-Architekturen müssen Kosten für Cloud-Speicherung und Netzwerknutzung berücksichtigen. Beispielsweise kann es sich durch die Kosten verbieten, alle Protokolle von Instanzen in einer öffentlichen Cloud zu einem SIEM vor Ort zu senden.
      • Änderungen der Schwachstellenanalyse.
        • Der Cloud-Eigentümer (öffentlich oder privat) wird normalerweise Benachrichtigungen zu Beurteilungen fordern und Grenzen für die Art der Beurteilungen setzen.
        • Das liegt daran, weil sie ohne eine vorherige Warnung nicht zwischen einer Beurteilung und einem echten Angriff unterscheiden können.
        • Standardmäßig verweigernde Netzwerke begrenzen zudem die potenzielle Wirksamkeit einer Beurteilung weiter, ähnlich wie eine Firewall.
        • Beurteilungen können im Prozess des Erzeugens unveränderlicher Arbeitslasten ausgeführt werden.
  • Sicherheit von Cloud-Speichersystemen
    • ist in Bereich 11 ausführlicher behandelt
  • SaaS und PaaS
    • Der Provider von SaaS oder PaaS ist vollständig für die Sicherheit der Infrastruktur verantwortlich.
  • Empfehlungen
  • Kennen Sie die Infrastruktur-Sicherheit Ihres Providers oder der Plattform.
    • Im Modell geteilter Sicherheit hat der Provider (oder wer auch immer die private Cloud-Plattform verwaltet) die Aufgabe sicherzustellen, dass die darunter liegenden physikalischen, Abstraktions- und Orchestrierungs-Schichten der Cloud sicher sind.
  • Netzwerk
    • Bevorzugen Sie SDN, sofern verfügbar.
    • Nutzen Sie SDN-Fähigkeiten für mehrfache virtuelle Netzwerke und mehrfache Cloud-Konten/Segmente, um die Isolierung im Netzwerk zu erhöhen.
      • Abgegrenzte Konten und virtuelle Netzwerke begrenzen den Wirkungsradius im Vergleich zu herkömmlichen Rechenzentren erheblich.
    • Implementieren Sie standardmäßige Abweisung mit Cloud-Firewalls.
    • Wenden Sie Cloud-Firewalls basierend pro Arbeitslast und nicht basierend pro Netzwerk an.
    • Beschränken Sie stets den Datenverkehr zwischen Arbeitslasten im gleichen virtuellen Subnetz mittels einer Cloud-Firewall-Richtlinie (Sicherheitsgruppe), wann immer möglich.
    • Minimieren Sie die Abhängigkeit von virtuellen Geräten, welche die Elastizität beschränken oder Flaschenhälse der Leistung verursachen.
  • Rechensystem/Arbeitslast
    • Nutzen Sie unveränderliche Arbeitslasten, wann immer möglich.
      • Deaktivieren Sie den Fernzugriff.
      • Integrieren Sie Sicherheitstests in die Anlage von Images.
      • Alarmieren Sie mit der Dateiintegritätsüberwachung.
      • Bei unveränderlichen Systemen patchen Sie durch Aktualisierung der Images und nicht durch Installation in laufende Instanzen hinein.
    • Wählen Sie Sicherheitsagenten, die cloudfähig sind und Leistungsauswirkungen bei Bedarf minimieren.
    • Erhalten Sie die Sicherheitskontrollen für langlaufende Anwendungen, aber verwenden cloudfähige Werkzeuge.
    • Speichern Sie Protokoll extern gegenüber den Arbeitslasten.

Verstehen und befolgen Sie die Grenzen des Cloud-Providers bei Schwachstellenanalyse und Penetrations-Tests.

Schreibe einen Kommentar

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