Cloud- und SaaS-Sicherheit
25 Fragen zu Cloud- und SaaS-Sicherheit, verständlich beantwortet: was zu prüfen ist, was NetSenX zeigt und was ein Sensor nicht sieht.
Sie beschreiben, wie viel des Stacks der Anbieter für Sie betreibt und damit, wie viel Sicherheitsarbeit bei Ihnen bleibt. Bei Infrastructure as a Service (IaaS) mieten Sie virtuelle Server, Speicher und Netze; Sie installieren und patchen das Betriebssystem, konfigurieren Firewalls und betreiben Ihre Anwendungen, die Sicherheitsarbeit ähnelt also dem Betrieb eigener Server. Bei Platform as a Service (PaaS) betreibt der Anbieter Betriebssystem und Laufzeitumgebung, etwa eine verwaltete Datenbank oder eine Anwendungsplattform; Sie bleiben verantwortlich für Code, Konfiguration, Identitäten und Daten. Bei Software as a Service (SaaS) nutzen Sie eine fertige Anwendung wie E-Mail, CRM oder Buchhaltung; Ihr Teil ist vor allem, wer Zugang hat, mit welchen Rechten und Mehr-Faktor-Authentisierung, wie Daten geteilt werden, und eine eigene Kopie wichtiger Daten. Viele Unternehmen nutzen alle drei gleichzeitig. Ordnen Sie jeden Dienst seinem Typ zu, denn die Fragen von Prüfern oder Versicherern unterscheiden sich je Typ, ebenso die Logs, die Sie bekommen.
Er kann es, für die Teile, die der Anbieter übernimmt, aber er verlagert Risiko mehr, als er es beseitigt. Ein großer Anbieter patcht seine Infrastruktur, betreibt redundante Rechenzentren und beschäftigt Sicherheitsteams, die sich kaum ein Mittelständler leisten könnte; physische Sicherheit, Hardwareausfälle und Grundverfügbarkeit verbessern sich also meist. Was nicht umzieht, ist die Verantwortung für Identitäten, Konfiguration und Daten, und die liegen danach offener: Ein Cloud-Admin-Konto ist von überall im Internet erreichbar, eine Speichereinstellung kann Dateien mit einem Klick weltweit veröffentlichen, und ein gestohlenes Passwort ohne Mehr-Faktor-Authentisierung öffnet alles auf einmal. Angreifer sind den Unternehmen in die Cloud gefolgt, und viele der Vorfälle, die sie dort auslösen, beginnen mit einem gephishten Konto oder einem geleakten Zugriffsschlüssel. Sicher umziehen heißt: MFA für jedes Konto, minimale Rechte für Admins, eingeschaltete und geprüfte Protokollierung, Backups unter Ihrer Kontrolle und jemand, der für die Cloud-Konfiguration verantwortlich ist. Auch Ihr Büronetz zählt weiter: Laptops, Drucker und verbliebene Server sind oft der Ort, an dem ein Angreifer zuerst landet.
Die Verbindungen zwischen Ihren Geräten und der Cloud, nicht das, was in der Cloud geschieht. Ein Sensor im Büronetz oder ein Agent auf einem Server sieht, welche Geräte sich mit welchen Cloud- und SaaS-Diensten verbinden, wann, wie oft und wie viele Daten in jede Richtung fließen, dazu den Servernamen im TLS-Handshake, wo Pakete mitgeschnitten werden. Das reicht, um einen Laptop zu bemerken, der Gigabytes zu einem Speicherdienst hochlädt, den er nie genutzt hat, einen Server, der sich alle paar Minuten bei einer gemieteten Cloud-Maschine meldet, oder ein Gerät, das mit einer unerwarteten Region spricht. Er sieht nicht, was Nutzer in einer SaaS-Anwendung tun, etwa einen Ordner öffentlich freigeben, eine Weiterleitungsregel anlegen oder einer App Zugriff auf ein Postfach geben; er sieht keinen Verkehr zwischen Cloud-Diensten; und er sieht keine Mitarbeitenden im Homeoffice auf nicht verwalteten Geräten. Das liefern die Audit-Logs und Admin-Konsolen des Anbieters. NetSenX deckt die Netzseite ab: Beaconing, Scans, laterale Bewegung und ungewöhnliches ausgehendes Volumen in jedem Plan. Die Logs Ihres Cloud-Anbieters ersetzt es nicht.
Teilweise: Es sieht das Netzverhalten von Linux-Servern, auf denen sein Agent läuft, wo auch immer sie stehen, liest aber nicht die Verwaltungsebene Ihres Cloud-Anbieters. Der NetSenX-Agent läuft unter Linux und macOS, ein virtueller Linux-Server, den Sie bei einem Cloud-Anbieter betreiben, kann ihn also wie jeder andere Linux-Rechner tragen; der Agent sieht dann die Verbindungen dieses Servers, und die Kernerkennungen greifen in jedem Plan: Beaconing zu einem Command-and-Control-Server, Scans, laterale Bewegung zu anderen Servern und ungewöhnliches ausgehendes Datenvolumen. Jeder solche Server zählt als Gerät in Ihrem Plan. Außen vor bleiben: verwaltete Dienste, die Sie nicht selbst betreiben, etwa Datenbanken, serverlose Funktionen und Speicher; Verkehr zwischen Cloud-Diensten, der nie einen Server mit Agent berührt; und alles in der Verwaltungsebene des Anbieters wie Kontoanmeldungen, Rechteänderungen und Konfiguration. Dafür schalten Sie die Audit- und Flow-Logs des Anbieters ein und leiten sie dorthin, wo jemand sie prüft. Beide Sichten zusammen zeigen Ihnen das Netzverhalten Ihrer Server und die Kontoaktivität drumherum.
Indem Sie prüfen, wer das Ziel ist, wie sich die Verbindung verhält und ob etwas in Ihrem Geschäft sie erklärt. Angreifer mögen gemietete Cloud-Server, weil jeder in Minuten einen anlegen kann und die Adresse einem seriösen Anbieter gehört; der Anbietername allein beweist also nichts. Bessere Fragen: Passt das Ziel zu einem Dienst, den Sie nutzen, anhand seines Namens im TLS-Handshake oder im DNS, und steht dieser Dienst auf Ihrer Lieferantenliste? Ist die Verbindung regelmäßig, klein und rund um die Uhr, wie ein Programm, das sich meldet, statt von Menschen in der Arbeitszeit getrieben? Begann sie direkt nach etwas Ungewöhnlichem auf diesem Gerät, etwa einem neuen Programm oder einer Anmeldung aus dem Ausland? Öffnet ein Server, der sonst nur Verbindungen annimmt, plötzlich selbst welche nach außen? Ein legitimer Backup- oder Monitoringdienst hat meist ein dokumentiertes Ziel und einen Vertrag; eine unbekannte virtuelle Maschine, die ein Arbeitsplatz alle fünf Minuten kontaktiert, nicht. NetSenX meldet in jedem Plan das regelmäßige Melde-Muster, Beaconing genannt, und ungewöhnliches ausgehendes Volumen mit dem Ziel, damit Sie den richtigen Verantwortlichen fragen können.
Ermitteln Sie es zuerst aus den Verbindungen und fragen Sie dann den Verantwortlichen jedes Servers, denn die meisten solcher Verbindungen haben eine langweilige Erklärung und einige nicht. Legitime Gründe sind Monitoring- und Backup-Dienste, Spiegelserver für Updates, die API eines Lieferanten, eine Testmaschine eines Entwicklers oder ein SaaS-Anbieter, der bei einem günstigen Hoster betreibt. Bedenkliche Zeichen sind das Gegenteil: ein Server, der geschäftlich gar keinen Grund hat, mit dem Internet zu sprechen, Verbindungen, die sich Tag und Nacht in festen Abständen wiederholen, Verkehr, der nach einem Vorfall oder einer neuen Installation begann, und Ziele, die niemand im Unternehmen kennt. Gemietete virtuelle Server bei günstigen Hostern sind ein häufiger Ort für Steuerserver von Angreifern und zum Sammeln gestohlener Daten, gerade weil sie billig, schnell und anonym zu mieten sind. Führen Sie je Server die Liste erwarteter Ziele, prüfen Sie sie mit den Verantwortlichen und sperren Sie ausgehenden Verkehr von Servern, die ihn nicht brauchen. In jedem Plan zeigt NetSenX Verbindungen Ihrer Hosts mit ihren Zielen und alarmiert bei Beaconing und ungewöhnlichem ausgehendem Volumen, den Mustern, die hier am meisten zählen.
Ja, und sie tun es, weil Verkehr zu einem bekannten Cloud-Dienst selten gesperrt oder hinterfragt wird. Schadsoftware kann Anweisungen aus einer Datei in einem öffentlichen Cloud-Speicherkonto, einem geteilten Dokument, einer Code-Plattform, der Bot-Schnittstelle eines Messengers oder einem Content-Delivery-Netz holen und gestohlene Daten auf demselben Weg zurückschicken. Für eine Firewall, die Ziele nach Reputation beurteilt, sieht das aus wie ein gewöhnlicher Mitarbeiter, der einen beliebten Dienst nutzt. Was es dennoch verrät, ist das Verhalten. Ein Programm, das eine Cloud-Datei in regelmäßigen Abständen, Tag und Nacht, von einem Gerät abfragt, dessen Nutzer gerade nicht arbeitet, hat einen Rhythmus, den Menschen nicht haben; Uploads können für dieses Gerät ungewöhnlich groß sein; und der Client-Fingerprint im TLS-Handshake passt womöglich weder zu einem Browser noch zur offiziellen App des Dienstes. Praktische Schritte: Lassen Sie nur die Cloud-Dienste zu, die das Geschäft nutzt, wo Ihre Werkzeuge es erlauben je Mandant, und untersuchen Sie Geräte, die mit privaten Konten beliebter Dienste sprechen. NetSenX erkennt Beaconing und ungewöhnliches ausgehendes Volumen in jedem Plan, egal welches Ziel, und TLS-Fingerprints ab dem Starter-Plan, wo der Agent Pakete mitschneidet.
Vergleichen Sie die Übertragung mit dem, was das Gerät sonst tut, und mit den Werkzeugen, die Ihr Unternehmen tatsächlich nutzt. Ein Sync-Client, der Dateien an den freigegebenen Speicherdienst des Unternehmens schickt, folgt einem Muster: Er läuft auf Arbeitsplätzen von Menschen, die ihn nutzen, sein Volumen steigt und fällt mit der Arbeitszeit, und das Ziel ist der Dienst, für den Sie zahlen. Datendiebstahl unterscheidet sich meist in mindestens einem Punkt: Ein Server statt eines Arbeitsplatzes lädt viel hoch; das Ziel ist ein privates oder unbekanntes Speicherkonto, ein Filesharing-Dienst oder ein gemieteter Server; das Volumen liegt weit über dem üblichen Niveau des Hosts; es geschieht nachts oder am Wochenende; oder es folgt auf andere Warnzeichen wie Scans oder neue Admin-Anmeldungen. Werkzeuge, die Angreifer dafür nutzen, etwa Kommandozeilen-Sync-Programme, sehen oft genauso aus wie ein legitimes Backup. Fragen Sie zuerst den Verantwortlichen des Hosts und prüfen Sie dann die Logs des Speicheranbieters zum verwendeten Konto. In jedem Plan alarmiert NetSenX bei ungewöhnlichem ausgehendem Datenvolumen je Host und zeigt das Ziel; welche Dateien gesendet wurden, sieht es nicht.
Sie können sehen, ob ein Firmengerät ungewöhnliche Datenmengen an Cloud-Dienste sendet, oft das nützlichste frühe Signal, aber nicht, wer es war oder welche Dateien es waren. In den Wochen vor einem Ausscheiden ist ein deutlicher Anstieg der Uploads vom Laptop zu einem privaten Speicherdienst, einer Dateitransferseite oder einem KI-Werkzeug ein Gespräch wert, besonders zu ungewöhnlichen Zeiten. Ein solider Austrittsprozess zählt mehr als Erkennung: schriftlich festhalten, was im Unternehmen bleibt, am letzten Tag den Zugang zu SaaS- und Cloud-Konten entziehen, Tokens und App-Passwörter widerrufen, Freigabelinks und Weiterleitungsregeln in Mail und Speicher prüfen und Geräte einsammeln. Data Loss Prevention und die Audit-Logs Ihrer Speicher- und Maildienste können Dateinamen zeigen, ein Netzwerksensor nicht. Halten Sie jede Prüfung verhältnismäßig, auf Geräte und Firmendaten ausgerichtet und mit Personalabteilung und, wo nötig, Betriebsrat abgestimmt, denn die Überwachung von Beschäftigten ist in jedem EU-Land geregelt. In jedem Plan alarmiert NetSenX bei ungewöhnlichem ausgehendem Datenvolumen eines Geräts und zeigt das Ziel.
Ja, vor allem über die Geräte und Konten, die sie synchronisieren oder verwalten. Verschlüsselt Ransomware Dateien auf einem Laptop, dessen Ordner mit Cloud-Speicher synchronisiert sind, lädt der Sync-Client die verschlüsselten Versionen getreu hoch, und die Cloud-Kopien ändern sich mit. Ein Angreifer mit einem gestohlenen Admin-Konto kann Daten direkt im Dienst löschen oder verschlüsseln, Backups und Versionen entfernen oder zuerst alles abziehen und mit Veröffentlichung drohen. Was hilft: Lassen Sie die Dateiversionierung mit ausreichender Historie eingeschaltet und wissen Sie, wie man einen ganzen Ordner auf einmal zurücksetzt; schützen Sie Admin-Konten mit phishing-resistenter Mehr-Faktor-Authentisierung und trennen Sie sie von Alltagskonten; aktivieren Sie Löschschutz oder Aufbewahrungssperren, wo der Dienst sie bietet; halten Sie ein unabhängiges Backup, das dieselben Admins nicht entfernen können; und beschränken Sie die Synchronisierung auf die Ordner, die Menschen brauchen. Achten Sie auf die Schritte vor der Verschlüsselung, denn dort können Sie noch eingreifen: In jedem Plan erkennt NetSenX Beaconing, Scans, laterale Bewegung und ungewöhnliches ausgehendes Volumen, auch große Uploads zu Cloud-Speicher. Aktionen in der Admin-Konsole des Cloud-Dienstes sieht es nicht.
Meist nicht so, wie Sie es brauchen. SaaS-Anbieter schützen ihren Dienst vor eigenen Ausfällen, mit redundantem Speicher und Notfallwiederherstellung, versprechen aber in der Regel nicht, Ihre Daten nach etwas wiederherzustellen, das Sie oder ein Angreifer in Ihrem Konto getan haben. Gelöschte Elemente liegen eine begrenzte Zeit in Papierkörben und Versionsverläufen und verschwinden dann; ein Ransomware-Angriff, der synchronisierte Dateien verschlüsselt, ein böswilliger Admin, der Postfächer löscht, oder ein Sync-Fehler, der einen Ordner überschreibt, können diese Fristen überdauern; und wenn ein Abonnement oder eine Nutzerlizenz endet, können die Daten entfernt werden. Lesen Sie die Bedingungen Ihres Anbieters: Die meisten beschreiben diese Aufteilung als Teil der geteilten Verantwortung. Wenn die Daten wichtig sind, halten Sie eine eigene Kopie: einen Backup-Dienst oder Export, der Mails, Dateien und wichtige Anwendungsdaten in Speicher kopiert, den die SaaS-Admins nicht löschen können, so lange aufbewahrt, wie es geschäftliche und rechtliche Anforderungen verlangen. Testen Sie mindestens einmal die Wiederherstellung eines Postfachs und eines Ordners, denn dann zeigen sich die Lücken. Ein Netzwerksensor hilft hier nicht; das ist Backup- und Aufbewahrungsplanung.
Beginnen Sie bei den Identitäten, denn die meisten Kontoübernahmen starten mit einem gephishten oder wiederverwendeten Passwort. Das Wesentliche, der Reihe nach: Mehr-Faktor-Authentisierung für jeden Nutzer, für Admins mit phishing-resistenten Verfahren wie Sicherheitsschlüsseln oder Passkeys; getrennte Admin-Konten nur für die Verwaltung und so wenige globale Admins wie möglich; abgeschaltete Legacy-Authentifizierungsprotokolle, die MFA umgehen; Anmelderichtlinien, die riskante Orte oder nicht verwaltete Geräte sperren, wo Ihre Lizenz es erlaubt; eingeschaltete und ausreichend lange aufbewahrte Audit-Logs; Warnungen bei neuen Weiterleitungsregeln, neuen Admin-Rollen und neuen OAuth-App-Zustimmungen; Grenzen für externes Teilen und für Drittanbieter-Apps, die Nutzer verbinden dürfen; und ein Backup von Mail und Dateien außerhalb des Anbieters, denn dessen Papierkörbe sind kein Backup. Prüfen Sie Admin-Rollen und Gastkonten jedes Quartal. Das meiste davon ist Konfiguration, die Sie bereits bezahlen. Ein Netzwerksensor sieht nicht, was in diesen Diensten passiert; er ergänzt die Sicht auf die Geräte, die sich mit ihnen verbinden, etwa einen Laptop, der nach dem Öffnen eines Phishing-Anhangs mit Beaconing beginnt.
Ein Angriff, bei dem das Opfer dazu gebracht wird, einer bösartigen App Zugriff auf sein Konto zu gewähren, statt ein Passwort preiszugeben. Der Nutzer erhält einen Link zu etwas, das wie eine nützliche App oder eine Dokumentanfrage aussieht, meldet sich auf der echten Microsoft- oder Google-Seite an und klickt, um Berechtigungen wie das Lesen von Mails, Dateien oder Kontakten zu genehmigen. Ab dann hält die App des Angreifers ein Token, das ohne Passwort funktioniert und oft einen Passwortwechsel und die Mehr-Faktor-Authentisierung übersteht, weil der Nutzer zugestimmt hat. Der Angriff wirkt gerade deshalb, weil jede Seite, die das Opfer sieht, echt ist. Abwehr: Schränken Sie Nutzerzustimmungen ein, sodass nur verifizierte Herausgeber oder vom Admin genehmigte Apps Zugriff erhalten können, verlangen Sie eine Admin-Prüfung für riskante Berechtigungen, lassen Sie sich bei neuen App-Zustimmungen warnen und prüfen Sie regelmäßig die Liste verbundener Apps, wobei Sie entfernen, was niemand kennt. Finden Sie eine bösartige Freigabe, widerrufen Sie App und Tokens und prüfen Sie in den Audit-Logs, worauf sie zugegriffen hat. Ein Netzwerksensor sieht Zustimmungen nicht, sie geschehen beim Identitätsanbieter; dort gehören die Kontrollen hin.
Die, die Sie brauchen, um nach einem Vorfall zu beantworten, was passiert ist: wer sich angemeldet hat, was sich geändert hat und auf welche Daten zugegriffen wurde. Prüfen Sie für jeden Cloud- oder SaaS-Dienst, dass Folgendes eingeschaltet ist: Anmeldeprotokolle mit Ort und Gerät; Admin- und Konfigurationsänderungen wie neue Rollen, Richtlinien, Weiterleitungsregeln und App-Zustimmungen; Zugriffe auf Dateien und Postfächer, wo der Dienst es anbietet; API-Aktivität für Cloud-Konten; und Netz-Flow-Logs Ihrer Cloud-Netze, wenn Sie dort Server betreiben. Prüfen Sie dann, wie lange jedes Log standardmäßig aufbewahrt wird, denn manche Dienste halten nur ein kurzes Fenster, sofern Sie nicht mehr bezahlen oder exportieren. Legen Sie Kopien dort ab, wo die Admins des Dienstes sie nicht löschen können, damit ein Angreifer mit Admin-Rechten die Spur nicht verwischt. Legen Sie fest, wer sie prüft und welche Ereignisse einen Alarm auslösen. Die Meldung von Vorfällen nach NIS2 und DSGVO und Ihr Versicherer werden erwarten, dass Sie eine Zeitachse rekonstruieren. Ein Netzwerksensor liefert die Geräteseite dieser Zeitachse: NetSenX bewahrt Alarme für den Zeitraum Ihres Plans auf, mit Hosts, Zielen und Zeitpunkten.
Meist nichts Gutes, und zwar schnell, denn Angreifer durchsuchen öffentliche Code-Repositories ständig nach Schlüsseln. Ein Cloud-Zugriffsschlüssel oder API-Token wirkt wie ein Passwort, das nie nach Mehr-Faktor-Authentisierung fragt; wer es hat, kann das Konto mit den Rechten des Schlüssels von überall nutzen. Typischer Missbrauch reicht vom Starten teurer Rechenleistung für Kryptomining über das Kopieren von Speicher-Buckets und Datenbanken bis zum Anlegen neuer Nutzer, damit der Angreifer nach dem Widerruf Zugang behält. Lecks entstehen durch Code in öffentlichen oder geteilten Repositories, Konfigurationsdateien in Backups, Screenshots, CI-Logs und Chatnachrichten. Wenn es passiert: Widerrufen oder rotieren Sie den Schlüssel sofort, nicht erst nach der Untersuchung; prüfen Sie die Aktivitätslogs des Kontos auf alles, was seit dem Leck damit getan wurde, einschließlich neuer Nutzer, Schlüssel und Ressourcen in ungewöhnlichen Regionen; entfernen Sie, was der Angreifer angelegt hat; und prüfen Sie die Abrechnung. Vorbeugend helfen Secret-Scanning in den Repositories, kurzlebige Zugangsdaten statt langlebiger Schlüssel, enge Rechte je Schlüssel und Budgetwarnungen. Ein Netzwerksensor kann einen im Internet veröffentlichten Schlüssel nicht sehen; die Folgen auf Servern, die er beobachtet, womöglich schon.
Es ist Cloud-Speicher, den mehr Menschen lesen oder sogar beschreiben können als beabsichtigt, oft jeder im Internet. Objektspeicherdienste erlauben es, einen Bucket oder Container mit einer einzigen Einstellung oder einem Link öffentlich zu teilen, nützlich für die Bilder einer Website, gefährlich für Backups, Exporte, Rechnungen oder Kundendateien. Viele bekannt gewordene Datenpannen waren gar keine Hacks, sondern Dateien, die jemand beim Suchen nach offenen Buckets gefunden hat. Vermeiden lässt es sich mit einigen Gewohnheiten: Schalten Sie beim Anbieter die kontoweite Sperre für öffentlichen Zugriff ein, sofern ein Bucket nicht wirklich öffentlich sein muss, und halten Sie öffentliche Inhalte in eigenen, klar benannten Buckets; bevorzugen Sie zeitlich begrenzte signierte Links statt öffentlicher Freigabe; verschlüsseln Sie Daten und beschränken Sie, wer Freigabeeinstellungen ändern darf; nutzen Sie die Konfigurationsprüfungen des Anbieters oder ein Posture-Werkzeug, das öffentlichen Speicher meldet; und prüfen Sie Freigabelinks in SaaS-Speicher, etwa Links, die für jeden mit dem Link funktionieren. Prüfen Sie nach jedem neuen Projekt, denn Test-Buckets sind häufig die Ursache. Ein Netzwerksensor sieht keine Bucket-Einstellungen; das gehört ins Konfigurationsmanagement der Cloud.
Es ist eine spezielle interne Adresse auf jeder virtuellen Maschine in der Cloud, über die die Maschine Informationen über sich selbst abrufen kann, einschließlich temporärer Zugangsdaten für die ihr zugewiesenen Rechte. Software auf dem Server nutzt diese Zugangsdaten, um ohne Passwort in der Konfiguration auf Speicher, Datenbanken und andere Cloud-Dienste zuzugreifen, was gute Praxis ist. Das Risiko: Alles, was den Server dazu bringen kann, eine Webanfrage an diese Adresse zu senden, kann die Zugangsdaten ebenfalls lesen. Ein häufiger Weg ist Server-Side Request Forgery (SSRF): eine Lücke in einer Webanwendung, mit der ein Angreifer den Server eine URL seiner Wahl abrufen lässt. Mit den Zugangsdaten handelt der Angreifer in Ihrem Cloud-Konto mit den Rechten des Servers. Abwehr: Verlangen Sie die neuere, sitzungsbasierte Version des Metadatendienstes, wo Ihr Anbieter eine bietet, denn sie blockiert einfache gefälschte Anfragen; geben Sie jeder Serverrolle nur die nötigen Rechte; beheben Sie SSRF-Lücken und prüfen Sie URLs, die Anwendungen abrufen; und lassen Sie sich warnen, wenn Zugangsdaten aus der Rolle eines Servers von außerhalb Ihrer Umgebung genutzt werden, was die Aktivitätslogs des Anbieters zeigen können.
Meist zuerst an der Rechnung, weshalb Budgetwarnungen die billigste Erkennung sind, die Sie einrichten können. Angreifer, die an Cloud-Zugangsdaten kommen, starten oft viele leistungsstarke virtuelle Maschinen oder Container, häufig in Regionen, die Sie nie nutzen, um auf Ihre Kosten Kryptowährung zu schürfen. Zeichen: ein plötzlicher Anstieg der Rechenkosten oder der Zahl der Instanzen, Maschinen mit GPU-Typen, die niemand bestellt hat, neue Ressourcen in unbekannten Regionen, neue Zugriffsschlüssel oder Nutzer, die etwa zur gleichen Zeit angelegt wurden, und Server, die rund um die Uhr mit voller CPU-Last laufen. Auf einem Server, den Sie selbst betreiben, zeigt sich ein Mining-Prozess auch im Netz: gleichmäßige, langlebige Verbindungen zu Mining-Pools, oft auf ungewöhnlichen Ports, von einem Rechner, der sonst nur Webanfragen beantwortet. Reagieren Sie, indem Sie die verwendeten Zugangsdaten widerrufen, alles entfernen, was der Angreifer in allen Regionen angelegt hat, nach Persistenz wie neuen Nutzern, Rollen und geplanten Funktionen suchen und den Anbieter zu den Kosten ansprechen. NetSenX sieht das Netzverhalten von Servern mit seinem Agenten, etwa regelmäßige Verbindungen zu einem unbekannten Ziel; Ihre Cloud-Rechnung oder Ressourcen ohne Agenten beobachtet es nicht.
Kombinieren Sie einige günstige Quellen, denn keine sieht alles. Der Identitätsanbieter zeigt, bei welchen Apps sich Menschen mit ihrem Firmenkonto anmelden, einschließlich OAuth-Apps, die sie mit Mail oder Dateien verbunden haben. Spesenabrechnungen und Kartenabrechnungen zeigen Abos, die Teams gekauft haben. Browser- und Endgeräteverwaltung kann installierte Erweiterungen und Desktop-Apps auflisten. DNS-Logs sowie Firewall- oder Proxy-Logs zeigen, welche Dienste Firmengeräte erreichen. Sortieren Sie die Liste dann: Werkzeuge, die ein freigegebenes doppeln, Werkzeuge, die Firmen- oder Kundendaten halten, und harmlose. Entscheiden Sie für jedes Werkzeug, das Daten verarbeitet, ob es ordentlich freigegeben wird, mit Vertrag und Admin-Kontrolle, ersetzt oder abgeschaltet, und sagen Sie den Nutzern warum. Einmal im Quartal gemacht, bleibt die Liste kurz. Eine Netzsicht hilft beim Teil der Erreichbarkeit: NetSenX zeigt, welche Hosts sich mit welchen Zielen verbinden, mit einer eigenen Sicht auf KI-Dienste ab dem Pro-Plan; es erkennt nicht jede SaaS-Anwendung beim Namen und sieht weder Anmeldungen noch App-Zustimmungen, die beim Identitätsanbieter liegen.
Es sind drei Arten von Cloud-Sicherheitswerkzeugen, die auf Verschiedenes schauen. Cloud Security Posture Management (CSPM) prüft die Konfiguration Ihrer Cloud-Konten, etwa öffentlichen Speicher, offene Firewallregeln, fehlende Verschlüsselung oder zu weite Rechte, gegen bewährte Praxis und meldet Abweichungen. SaaS Security Posture Management (SSPM) tut dasselbe für SaaS-Anwendungen und prüft Einstellungen wie erzwungene MFA, externes Teilen und Admin-Rollen. Ein Cloud Access Security Broker (CASB) sitzt zwischen Nutzern und Cloud-Diensten, über einen Proxy oder die APIs der Anbieter, um genutzte Dienste zu entdecken und Richtlinien durchzusetzen, etwa das Hochladen sensibler Daten zu sperren. Ob Sie sie brauchen, hängt von der Größe ab. Ein Unternehmen mit einem Cloud-Konto und einer Office-Suite kommt mit den eingebauten Empfehlungen und Sicherheitsbewertungen der Anbieter oft weit, ohne Zusatzkosten. Mehrere Cloud-Konten, viele SaaS-Werkzeuge oder regulierte Daten machen eigene Werkzeuge lohnender. Keines davon beobachtet das Verhalten von Geräten in Ihrem Netz; das ist eine andere Ebene, die Netzwerkerkennung abdeckt.
Stellen Sie Fragen, deren Antworten Sie prüfen können und die zählen, wenn etwas schiefgeht. Nachweise: Welche unabhängigen Berichte oder Zertifikate decken den Dienst ab, den Sie kaufen, etwa ein SOC-2-Type-II-Bericht oder ein Zertifikat nach ISO/IEC 27001, mit Geltungsbereich und Datum, und dürfen Sie sie lesen? Daten: Wo werden sie gespeichert und verarbeitet, welche Unterauftragsverarbeiter sind beteiligt, werden sie zum Training von Modellen genutzt, wie lange werden sie aufbewahrt und wie bekommen Sie sie beim Ausstieg in brauchbarem Format zurück? Zugriff: Single Sign-on, erzwungene MFA, rollenbasierte Rechte und exportierbare Audit-Logs. Vorfälle: Wie schnell werden Sie benachrichtigt, über welchen Kanal, und welche Unterstützung gibt es für Ihre eigenen Meldepflichten nach DSGVO oder NIS2? Resilienz: Backups, Wiederherstellungsziele und Schutz vor dem Missbrauch eines Admin-Kontos. Schwachstellen: Wie werden Meldungen behandelt, und wie schnell wird gepatcht? Schreiben Sie die wichtigsten Antworten in den Vertrag oder den Auftragsverarbeitungsvertrag, nicht nur in einen Fragebogen. Ein kleinerer Anbieter mit klaren, ehrlichen Antworten kann sicherer sein als ein großer mit vagen.
Meist beide, für Unterschiedliches. Der Anbieter ist für die Sicherheit seines Dienstes verantwortlich, und nach der DSGVO muss ein Anbieter, der als Ihr Auftragsverarbeiter handelt, Sie unverzüglich benachrichtigen, nachdem ihm eine Verletzung des Schutzes personenbezogener Daten bekannt wurde. Sie bleiben als Verantwortlicher für die Daten Ihrer Kunden oder Beschäftigten zuständig, das Risiko für die Betroffenen zu bewerten und, wo nötig, die Aufsichtsbehörde binnen 72 Stunden nach Bekanntwerden zu benachrichtigen sowie die Betroffenen bei hohem Risiko zu informieren. Fällt Ihr Unternehmen unter NIS2, kann ein erheblicher Sicherheitsvorfall bei einem Lieferanten eigene Meldepflichten auslösen, und NIS2 erwartet, dass Sie die Sicherheit der Lieferkette als Teil Ihrer Risikomanagementmaßnahmen steuern. Vieles Praktische regeln Verträge: Meldefristen, Mitwirkung, Informationen, die Sie erhalten, und Haftung. Bereiten Sie sich vorher vor: Wissen Sie, welche Lieferanten welche Daten halten, halten Sie deren Sicherheitskontakte bereit und nehmen Sie einen Vorfall bei einem Lieferanten in Ihren Notfallplan auf. Ihr nationales NIS2-Gesetz kann Einzelheiten ergänzen; prüfen Sie es.
Nicht für deren Betrieb, aber für das Management des Risikos, das daraus für Sie entsteht, wenn Ihr Unternehmen unter NIS2 fällt. Die Richtlinie (EU) 2022/2555 nennt die Sicherheit der Lieferkette, einschließlich sicherheitsbezogener Aspekte der Beziehungen zu unmittelbaren Anbietern und Diensteanbietern, unter den Risikomanagementmaßnahmen im Bereich der Cybersicherheit nach Artikel 21. Praktisch heißt das: wissen, von welchen Cloud- und SaaS-Anbietern Ihre wichtigen Dienste abhängen, deren Sicherheit bewerten, Anforderungen in Verträge schreiben und deren Ausfall oder Kompromittierung einplanen. Anbieter von Cloud-Computing-Diensten sind in NIS2 selbst als Einrichtungen im Sektor digitale Infrastruktur aufgeführt, viele haben also eigene Pflichten; das hilft, ersetzt aber Ihre Bewertung nicht. Nützliche Nachweise von Anbietern sind unabhängige Prüfberichte, Zertifikate mit klarem Geltungsbereich, Zusagen zur Meldung von Vorfällen und Ausstiegsbedingungen. Führen Sie ein Lieferantenverzeichnis mit den Daten und Diensten, die jeder unterstützt, und prüfen Sie es jährlich und nach Vorfällen. Nationale Umsetzungen können Anforderungen oder Leitlinien ergänzen; prüfen Sie das Gesetz Ihres Landes und die Veröffentlichungen Ihrer Behörde.
Zuerst eindämmen, dann aufklären, und dabei alles dokumentieren. Eindämmung: Setzen Sie das Passwort zurück und widerrufen Sie alle aktiven Sitzungen und Tokens des Kontos; entfernen Sie MFA-Methoden, die Sie nicht registriert haben, und registrieren Sie neu; suchen und löschen Sie neue Weiterleitungsregeln, App-Zustimmungen, API-Schlüssel, Nutzer oder Admin-Rollen, die der Angreifer angelegt hat; und war es ein Admin-Konto, prüfen Sie den ganzen Mandanten oder das ganze Cloud-Konto, denn Angreifer legen Hintertüren an. Aufklärung: Ermitteln Sie mit den Anmelde- und Audit-Logs des Anbieters, wann der Zugriff begann, von wo, und was gelesen, geändert, geteilt oder heruntergeladen wurde; prüfen Sie, ob dasselbe Passwort anderswo genutzt wurde. Klären Sie dann die Pflichten: Zugriff auf personenbezogene Daten kann eine Meldung nach DSGVO binnen 72 Stunden nach Bekanntwerden bedeuten, und ein erheblicher Vorfall kann in Ihrem Land nach NIS2 meldepflichtig sein. Schauen Sie auch auf die Geräte: Das gestohlene Passwort stammte oft von einem infizierten Laptop oder einer Phishing-Seite. In jedem Plan kann NetSenX zeigen, ob ein Gerät in Ihrem Netz um diese Zeit mit Beaconing, Scans oder ungewöhnlichen Datenmengen begann. Die Anmeldungen am Cloud-Konto sieht es nicht.