Die dort beschriebenen Angriffe zielen im Kern auf bereits bekannte Angriffe gegen das SAP-Gateway. Zum Schutz vor diesen Angriffen kann eine Zugriffsrichtlinie für das SAP-Gateway definiert werden. Diese erlaubt im Default nur Zugriff von dem Localhost und den zum „Internen“ Verbund zählenden SAP-Systemen.
Außenstehende erhalten damit keinen Zugriff auf das Gateway und können keine Angriffe ausführen. Als Ergebnis der neuen Angriffe gilt dies jedoch nicht mehr uneingeschränkt.
10KBLAZE
Zur Ausführung dieses Angriffes haben Sicherheitsforscher neue Wege identifiziert, um die ACLs auszutricksen.
Dazu nutzen Sie entweder einen vorgeschalteten SAP-Router oder im zweiten Weg den Zugriff auf den MS-Monitor Port.
Im ersten Fall bei einem Angriff über den SAP-Router wird eine Konfigurationslücke genutzt, die es erlaubt den SAP-Router als Proxy für Zugriffe auf das SAP-System zu nutzen. Diese entsteht, wenn der SAP-Router auf dem SAP-System oder einem zum „internen“ Verbund der SAP-Systeme zählenden System betrieben wird. Dann gewährt die Standard-ACL dem SAP-Router Zugriff auf das Gateway. Unter diesen Vorrausetzungen kann ein Angreifer den SAP-Router sodann als Proxy nutzen. Daraufhin erscheinen für das Gateway die Anfragen des Angreifers als kämen diese von dem SAP-Router und werden zugelassen. Damit kann ein Angreifer die ACLs umgehen.
SAP-Router als Proxy setzen
Beim zweiten Weg benötigt ein Angreifer Zugriff auf einen ungeschützten SAP-Monitor Port (39NN). Dann kann er dort -ohne die Notwendigkeit eines Logins- sein eigenes System zur Liste des „Internen“ SAP-Verbundes hinzufügen. Damit ist es ihm im im Anschluss möglich von seinem System aus die Gateway ACL zu passieren und auf das Gateway zuzugreifen.
Registrierung als „Trusted“ Server über MS Monitor
Starten eines Angriffs nach erfolgreicher „Registrierung“ als Trusted Server
Beide Wege erlauben dann die bekannten Angriffe gegen das SAP-Gateway auszuführen.
Risikoeinschätzung
Wie hoch ist jetzt das tatsächliche Risiko?
Grundlegend sollte ein SAP-Gateway mit ACLs abgesichert sein. Weiterhin sollten die SAP-Systeme durch eine Firewall geschützt sein. Bei der Nutzung eines SAP-Router für den Zugriff sollte dieser nicht auf dem SAP-System oder einem System, welches zu dem Verbund der „Internen“ SAP-Systeme gehört, betrieben werden.
Die Sicherheitsforscher konnten in Deutschland 733 „verwundbare“ SAP-Router aufspüren. Wie zuverlässig die Verwundbarkeit geprüft wurde, ist nicht beschrieben. Es ist jedoch zu erwarten, dass hier und dort ein SAP-Router zu finden ist, der als Proxy missbraucht werden kann.
Der SAP Monitor Port (39NN) für interne Kommunikation sollte definitiv nicht von außen erreichbar sein. Zusätzlich empfhielt sich der Schutz mit einer Firewall.
Laut Aussage der Sicherheitsforscher konnten 92 Systeme mit Zugriff auf den Monitoring Port in Deutschland identifiziert werden. Wie exakt die Ermittlung der Anzahl ist, kann nicht validiert werden. Dennoch ist zu erwarten, dass ein exponierter MS Monitor Dienst doch eher ein seltener Fund ist.
Schutzmaßnahmen
Was bleibt jetzt zu tun?
Die SAP-Router Installationen sind zu prüfen. Diese sollten nicht auf den SAP-Systemen oder Systemen des „Internen“ Verbund betrieben werden.
Für den Schutz des Gateways ist die SAP Note 1408081 Basic settings for reg_info and sec_info zu beachten.
SAP Monitor Dienste für die interne Kommunikation (39NN) dürfen nicht von Außen erreichbar sein. Zusätzlich kann eine Firewall schützen. Hier sind zwei Hinweise zu befolgen:
SAP Note 821875 Security settings in the message server
SAP Note 1421005 Secure configuration of the message server
Im Februar 2019 hat das BSI die Aktualisierung seines IT-Grundschutzkompendiums veröffentlicht. Im Rahmen des IT-Grundschutz werden Anforderungen für den sicheren Betrieb von SAP-ERP-Systemen genannt.
Zielstellung des Bausteins
Im Baustein selbst sind die Ziele und Abgrenzungen wie folgt beschrieben:
Der Baustein beschreibt, welche Gefährdungen für SAP-ERP-Systeme zu beachten sind und wie diese Systeme sicher installiert, konfiguriert und betrieben werden können. Er richtet sich an Informationssicherheitsbeauftragte und Administratoren, die dafür verantwortlich sind, SAP-ERP-Systeme zu planen und umzusetzen.
Der Baustein beschränkt sich auf die Kerninstallation eines SAP-ERP-Systems und fokussiert die spezifischen Merkmale des darunterliegenden SAP-NetWeaver-Applikationsservers.
APP.4.2: SAP-ERP-System
Besondere Bedrohungen
Der Baustein nennt vier wesentliche Bedrohungen für die Sicherheit von SAP-ERP-Systemen.
Fehlende Berücksichtigung der Sicherheitsempfehlungen von SAP
Eine nichtbeachtung der von SAP Empfohlenen Sicherheitseinstellungen und -maßnahmen kann zu schweren Sichereheitsproblemen führen. Das gesamte System kann angreifbar werden.
Fehlendes oder nicht zeitnahes Einspielen von Patches und SAP-Sicherheitshinweisen
Patches schließen bekannt gewordene Schwachstellen. Bleibt ein zeitnahes einspielen aus, können offene bekannte Schwachstellen für unautorisierten Systemzugriff oder -ausfall missbraucht werden.
Mangelnde Planung, Umsetzung und Dokumentation eines SAP-Berechtigungskonzeptes
Ohne ein durchdachtes Berechtigungskonzept erhalten Benutzer oftmals mehr Berechtigungen als notwendig. Dies ermöglicht vorsätzliche Manipulation oder Sabotage. Eine fehlende Dokumentation verhindert die Nachvollziehbarkeit und Pfelge. Als Folge könnten ggfs. ausgeschiedene Mitarbeiter weiterhin auf die Systeme zugreifen.
Fehlende SAP-Dokumentation und fehlende Notfallkonzepte
Fehlt die Dokumentation wie und mit welcher Konfiguration das System aufgebaut wurde kann dies zu Verzögerungen bei der Wiederanlaufzeit im Notfall führen. Ebenso besteht die Gefahr, dass im Notfall keine detaillierte Beschreibung existiert, wie die Verantwortlichen vorzugehen haben.
Im dem fünften Teil der Serie „Howto SAP Security“ (Gateway , Netzwerk,Datenbank, RFC ) ist das Thema der Internet Communication Manager (ICM).
Internet Communication Manager (ICM)
Der ICM nimmt Anfragen über das HTTP(s) Protokoll entgegen. Insbesondere Aufrufe aus dem Internet an das SAP-System lassen sich so seit geraumer Zeit realisieren. Diese Aufrufe gibt der ICM je nach Architektur an den JAVA oder ABAP Dispatcher zur Verarbeitung weiter. Dies ist auf dem folgenden Schaubild zu erkennen:
Architektur SAP ABAP / JAVA mit ICM (Quelle SAP: https://help.sap.com/doc/saphelp_scm70/7.0/ru-RU/48/03b72c49f04aa5e10000000a421937/frameset.htm)
Im vierten Teil der Serie „Howto SAP Security“ (Gateway , Netzwerk,Datenbank ) ist das Thema ABAP RFC.
Sicherheitsrisiken bei ABAP RFC
Die Remote Function Calls (RFC) finden breite Anwendung in SAP ABAP Systemen. Ein Benutzer kann ABAP Funktionen, die Remote aufrufbar sind, von anderen Systemen aus aufrufen.
Dazu muss er jedoch die System ID, den Mandanten, sowie die Zugangsdaten des Benutzers kennen.
Im dritten Teil der Serie „Howto SAP Security“ (Teil 1 , Teil 2) steht die Datenbanksicherheit im Fokus.
Datenbanksicherheit bei SAP-Systemen
Obwohl HANA immer stärkere Verbreitung findet, ist weiterhin Oracle die meist genutzte SAP-Datenbank. Entsprechend liegt hier der Fokus auf Oracle Datenbanken . Dem Thema HANA widmen wir uns in einem späteren Post. „Howto: SAP Security #3 – SAP Datenbanksicherheit“ weiterlesen
Im zweiten Teil der Serie „Howto SAP Security“ (Teil 1) wird die Netzwerksicherheit betrachtet. Hierbei sind zwei Punkte von besonderer Bedeutung. Zuerst ist die Zugriffskontrolle zu betrachten. Dann folgt die Verschlüsselung der Kommunikation.
SAP Netzwerksicherheit
SAP beinhaltet diverse Dienste, die größtenteils aus dem Netzwerk heraus erreichbar sind. Es ist wichtig die verfügbaren Dienste zu kennen, daher zeigt der folgende Screenshot einige wichtige Dienste.
SAP Portliste, Quelle: https://help.sap.com/viewer/ports
Um Remote zu erkennen, welche Dienste konkret von einem SAP-System in Netzwerk angeboten werden, ist ein Netzwerkscan des Systems ein gutes Mittel. Ein Beispiel eines Scans kann wie folgt ausfallen:
PORT STATE SERVICE VERSION
21/tcp open ftp?
22/tcp open ssh SSH (SSH-2.0-WeOnlyDo 2.1.3)
445/tcp open microsoft-ds?
3200/tcp open sapdisp SAP ABAP Dispatcher release 7010, patch level 111, database release 701 (DB name T11)
3300/tcp open sapgateway SAP Gateway (Monitoring mode disabled)
3389/tcp open ms-wbt-server Microsoft Terminal Service
3600/tcp open sapms SAP Message Server (SID T11, ID 00)
3900/tcp open sapms SAP Message Server (SID T11, ID 00)
7210/tcp open maxdb SAP MaxDB 7.7.07
8000/tcp open sapicm SAP Internet Communication Manager
8100/tcp open sapmshttp SAP Message Server httpd release 701 (SID T11)
40080/tcp open sapigs SAP Internet Graphics Server
50013/tcp open sapstartservice SAP Management Console (SID T11, NR 00)
Hier sieht man neben typischen SAP Diensten auch noch weitere kritische Dienste wie SSH, MSRDP, SMB und FTP.
Seit dem 25. Mai 2018 sind Verstöße gegen die Datenschutz-Grundverordnung (DSGVO) mit empfindlichen Geldbußen belegt. Entsprechend viel Aufmerksamkeit hat das Thema bereits erhalten. Doch wie sieht eine Compliance Prüfung und ein Nachweis der Rechenschaftspflicht im Kontext von SAP-Systemen aus?
DSGVO Umsetzungsstatus in den Unternehmen
Die Datenschutzbeauftragten in den Unternehmen und Behörden haben sicher auch ohne Berücksichtigung der SAP-Systeme keine Langeweile.
Nachdem die Verfahren dokumentiert und Prozesse festgelegt sind rücken die SAP-Systeme in den Vordergrund. Hier sind beispielsweise die definierten Lösch- und Sperrprozesse technisch einzurichten. Doch aufgepasst, denn es ist sicher mehr zu beachten als nur Daten zu sperren und zu löschen. „DSGVO Compliance bei SAP-Systemen“ weiterlesen
Mit diesem Beitrag startet die Serie „Howto SAP Security“. In der Serie werden typische SAP Angriffsflächen vorgestellt – mitsamt Angriffsvektoren und Gegenmaßnahmen. Zu Beginn der Serie wird daher mit dem SAP Gateway das wahrscheinlich größte Angriffsziel betrachtet.
SAP Gateway
Das SAP Gateway ist eine Schnittstelle des Systems nach außen. Es dient der Kommunikation mit anderen Systemen oder Programmen und regelt jegliche RFC Kommunikation. Das Gateway ist eine Kernkomponente der SAP Netweaver Systeme.
RFC Kommunikation, Quelle: SAP – Securing Remote Function Calls
Für einen Angreifer sind folgende Eigenschaften des Gateways von Bedeutung.
Zuerst ist die Ausführung mit <SID>adm Rechten im System zu nennen. Weiterhin besitzt es Funktionen zur Befehlsausführung auf OS-Ebene. Letztlich ist das Gateway ohne Authentifizierung nutzbar.
Die Vernetzung der Systeme nimmt immer weiter zu. Industrie 4.0 sowie IoT sind hier wesentliche Faktoren. Doch ein Faktor im IT-Betrieb scheint unverändert gültig zu bleiben:
Die Systeme müssen „laufen“. Patch-Management und Security erhalten daher nicht immer die erforderliche Priorität. Dies führt letztlich zur Anbindung von Systemen an das Internet, die veraltete Releases nutzen oder nicht die neuesten Security-Patches erhalten.
Anhand dieser Systeme lässt sich anschaulich skizzieren wie Hacker SAP-Systeme identifizieren und angreifen. Das Verständnis wie ein Hack eines solchen SAP-Systems abläuft, dient hier der Sensibilisierung der Systemverantwortlichen. Dies wiederum sollte sodann zur Härtung der SAP-Systeme führen.
Warum ist die Internet-Anbindung ein Risiko?
Die globale Erreichbarkeit des Systems durch die Anbindung an das Internet sorgt für eine deutliche Steigerung der Gefährdung des Systems. Dies liegt einfach daran, dass ab dem Moment der Internet-Anbindung jeder dieses System aufspüren und angreifen kann.
Jedes System bietet auch im Normalfall eine gewisse Angriffsfläche. Denn ein System wird in der Regel zu einem bestimmten Zweck an das Internet angeschlossen und bietet für diesen Zweck vorgesehene Dienste im Internet an. Beispielweise bieten die im Internet bekannten Web-Server ihre Webseiten über einen Web-Dienst (HTTP/HTTPS) an.
Dienste können bekanntlich Schwachstellen haben. Dies gilt auch für SAP-Systeme. Hier sind 4 bekannte und „gefixte“ Schwachstellen in SAP-Systemen aufgeführt, die für potentielle Angriffe aus dem Internet nutzbar sind:
2234971 – Directory-Traversal in AS Java Monitoring
SAP NetWeaver AS Java 7.10 bis 7.50 verwundbar
1682613 – Fehlende Berechtigungsprüfung im Core-Service
SAP NetWeaver AS Java 6.40 bis 7.31 verwundbar
2101079 – Mögliche Änderung/Offenlegung von persist. Daten in BC-ESI-UDDI
SAP NetWeaver AS Java 7.11 bis 7.50 verwundbar
Wie hoch ist nun die Wahrscheinlichkeit potentiell verwundbare Systeme im Internet zu finden? Beispielsweise in einem technologisch fortschrittlichem Land wie Deutschland…
SAP-Systeme mit Shodan.io finden
SAP-Systeme lassen sich relativ zuverlässig und kostenlos mit Shodan.io aufspüren. Die hier ausgesuchten Schwachstellen beziehen sich auf Systeme des Typs SAP NetWeaver AS Java. Solche Systeme findet diese Suche bei Shodan „sap as Java„. Insgesamt werden 2391 Systeme gefunden.
Shodan Suche
Anhand des Server Tags in der Ergebnisliste lässt sich einfach die Version ablesen:
Server: SAP NetWeaver Application Server 7.21 / AS Java 7.31
Dieses System wäre potentiell für 3 der 4 genannten Schwachstellen anfällig.
Schränkt man die Suche auf Deutschland ein („sap as Java country:DE„), so werden immer noch 183 Systeme gefunden.
Shodan Karte für Deutschland
Darunter sind durchaus neuere Systeme:
server: SAP NetWeaver Application Server 7.45 / AS Java 7.50
Jedoch könnten immer noch 2 der 4 Schwachstellen vorhanden sein.
Es lässt sich jedoch auch gezielt nach älteren Systemen suchen: „SAP J2EE Engine„. Hier werden 1078 Systeme gefunden. Vornehmlich veraltete Systeme.
server: SAPJ2EEEngine/7.00
Auch in Deutschland stehen noch 70 solcher Systeme.
Karte für ältere Systeme in Deutschland
Zwei potentielle Schwachstellen lassen sich diesen älteren Versionen zuordnen.
Shodan zeigt sich wirklich auskunftsfreudig zu diesen Systemen.
Detailansicht in Shodan
An dieser Stelle kann man soweit festhalten, dass mit wenig Aufwand und kostenlos eine immense Liste an potentiell verwundbaren Systemen identifiziert werden kann.
An 4 theoretischen Beispielen lässt sich nun die Gefährdung solcher Systeme nachvollziehen.
Beispiel Hack 1: Anonymer Datei Download (SAP Hinweis 2234971)
Ein Angreifer kann unter Kenntnis der URL der verwundbaren Komponente beliebige Dateien des Servers herunterladen. Dies sogar ohne gültiges Login. Auf diesem Weg kann sich ein Angreifer Zugriff auf den Passworttresor (SecStore) des Systems verschaffen. Diesen kann er im Anschluss knacken (decodieren) und erhält die darin enthaltenen administrativen Zugangsdaten. Mit diesen Logindaten hat er dann Vollzugriff auf das System.
Beispiel Hack 2: Anonymer Dateitransfer (SAP Hinweis 1682613)
In dem Kernservice des P4-Dienstes von SAP Netweaver AS Java Systemen klafft bis zur Version 7.31 eine schwerwiegende Lücke. Diese kann ein Angreifer wie folgt ausnutzen. Zunächst prüft er ob der betroffene Dienst bei dem System aus dem Internet erreichbar ist. Sofern dies der Fall ist kann er eine anonyme Verbindung ohne Logindaten zu diesem Dienst aufbauen. Über diese Verbindung kann er dann jede beliebige Datei aus dem System lesen. Wie zuvor kann ein Angreifer damit Zugriff auf den SecStore erhalten und die administrativen Zugangsdaten auslesen.
Beispiel Hack 3: CTC Servlet (SAP Hinweis 1445998)
Diese Schwachstelle hat viel Aufsehen erhalten, selbst das US-CERT hat eine Warnung zu dieser Schwachstelle veröffentlicht. SAP selbst beschreibt die Schwachstelle mit diesen Worten:
Der Zugriff auf Servlets ist unabhängig von in der Datei web.xml definierten Sicherheitsbeschränkungen anonym über einen anderen Pfad möglich.
Konkret bedeutet dies, dass ein Angreifer lediglich eine bestimmte URL des Servers aufrufen muss. Damit kann er dann beliebige Systembefehle ausführen. Weiterhin kann er Benutzer anlegen und beliebige Berechtigungen zuweisen. Mit diesen Mitteln ist er in der Lage das System vollkommen unter seine Kontrolle zu bringen.
Besonders gefährlich bei dieser Lücke ist, dass ein Patch nicht generell das Problem behebt sondern lediglich eine bestimmte Konfigurationseinstellung deaktiviert. Diese kann jederzeit wieder aktiviert werden und damit das System erneut verwundbar machen.
Beispiel Hack 4: SQL-Injection (SAP Hinweis 2101079)
Es existiert eine SQL-Injection Schwachstelle in der Komponente SAP NetWeaver AS Java UDDI. Diese Schwachstelle kann anonym ohne Zugangsdaten ausgenutzt werden. Doch ganz so einfach ist dieser Weg dann doch nicht. Zunächst benötigt man einen Benutzernamen im System. Dieser ist für den Angriff zwingend nötig. Es gibt jedoch weitere Schwachstellen in den Systemen zu diesen Releases. Diese erlauben das anonyme Anzeigen der Benutzer im System. Hierzu reicht es aus eine von zwei möglichen URLs aufzurufen und sich die Benutzer anzuzeigen. In der Liste der Benutzer sucht man nun nach einem administrativen Account wie J2EE_ADMIN.
Mit Kenntnis des Benutzernamens kann über die SQL-Injection Schwachstelle nun auf dessen im System gespeicherten Passworthash zugegriffen werden. Dieser Hash kann aufgrund eines weiteren Fehlers in diesen Systemen sehr leicht in ein klartext Passwort überführt werden.
Damit kennt ein Angreifer nun die Zugangsdaten und erhält somit administrativen Vollzugriff auf das System.
SAP-Systeme schützen
Die Beispiele zeigen eindrucksvoll, dass es mit dem notwendigen Know-how relativ einfach ist SAP-Systeme erfolgreich aufzuspüren und zu hacken.
Abwehrstrategien scheitern vor allem an zu wenig Ressourcen und mangelndem Verständnis für Sicherheitslücken sowie dem fehlenden Know-how zur Ermittlung des tatsächlichen Sicherheitsstatus eines Systems. Mit dem werthAUDITOR von Werth IT ist es möglich die Systemsicherheit zu prüfen bevor und während die Systeme mit dem Internet verbunden sind. Damit lassen sich nicht nur die hier vorgestellten Risiken mindern, sondern auch Problemstellungen im ABAP-Coding, den Berechtigungen, der Systemkonfiguration und weiteren sicherheitskritischen Systemeigenschaften lösen. Trotz limitierter Ressourcen kann so ein dauerhaft sicherer Betrieb und die Einhaltung der Compliancevorgaben erreicht werden.
Mehr Informationen zu unserem SAP Security Service erhalten Sie hier.
Ohne parlamentarische Anhörung hat der US-Kongress Ende März 2018 mit dem „Cloud Act“ ein Gesetz verabschiedet, dass Dienstleister ungeachtet des physischen Server Standorts die dort gespeicherten Kundendaten herausgeben müssen.
Cloud Act Bill
Damit stellt die US-Regierung US-Recht über das geltende Recht des Landes in dem die Daten physikalisch gespeichert sind.
Auslöser
Einer der Auslöser für diesen Beschluss war der Streit zwischen Microsoft und den US-Behörden. Der US-Supreme Court hat sich bereits mit diesem Fall beschäftigt und für dieses Jahr wurde mit einem Urteil gerechnet.
Im Kern war zu entscheiden ob Microsoft E-Mails von einem in der EU betriebenen Server herausgeben muss. Mit dem in Kraft treten des neuen Gesetzes hat der Supreme Court den Fall nun für erledigt erklärt.
Damit ist bereits die erste Anwendung nach dem Neuen Gesetz auf dem Weg und Microsoft ist verpflichtet die angeforderten Daten herauszugeben.
Der Cloud Act und seine Folgen – Daten(un)sicherheit
Der Justiziar Neema Singh Guliani der US-Bürgerrechtsorganisation American Civil Liberties Union (ACLU) hat wesentliche Datenschutz-Probleme in dem Gesetz erkannt:
For the first time, the bill allows foreign governments to wiretap and intercept communications in real-time, without even requiring governments to adhere to critical privacy protections in the Wiretap Act (such as notice, probable cause, or a set duration); and
The bill permits broad information sharing between governments, allowing countries (including the U.S.) to obtain information from foreign partners under standards that may be lower than their own domestic law.
Auch die Electronic Frontier Foundation (EFF) warnt vor dem Cloud Act:
Grants real-time access and interception to foreign law enforcement without requiring the heightened warrant standards that U.S. police have to adhere to under the Wiretap Act.
Fails to require notice on any level – to the person targeted, to the country where the person resides, and to the country where the data is stored. (Under a separate provision regarding U.S. law enforcement extraterritorial orders, the bill allows companies to give notice to the foreign countries where data is stored, but there is no parallel provision for company-to-country notice when foreign police seek data stored in the United States.)
Ein Abhören von Zielpersonen ist damit deutlich vereinfacht, ebenso gibt es nahezu keine Informationspflichten mehr.
Für Unternehmen, die Dienstleistungen von US-Firmen in Anspruch nehmen, bedeutet dies ein mögliches Scheitern der DSGVO-Compliance. Denn hier können Dritte auf Daten zugreifen. Noch etwas weiter gedacht wird klar, dass US-Behörden nach eigenem Ermessen auf sämtliche Daten eines Unternehmens zugreifen können, die bei dem US-Dienstleister gespeichert sind. Dazu können auch Geschäfts- und Betriebsgeheimnisse sowie Informationen zu den getroffenen IT-Sicherheitsmaßnahmen oder bekannten Cyber-Schwachstellen zählen.
Auswege
Ein möglicher Ausweg könnte der Einsatz eines „Datentreuhändlers“ sein. So betreibt beispielsweise T-Systems als Dienstleister den Cloud-Dienst für Office 365 Deutschland. Doch ob diese Konstellation Zugriffswünsche wirkungsvoll eindämmt ist nur schwer vorherzusagen.
Besonders brisant wird es für Unternehmen die IT-Sicherheitsdienstleistungen wie Schwachstellenmanagement an US-Anbieter vergeben haben. Überspitzt gefragt kann man sagen: Wer möchte schon seine Schwachstellen frei Haus an die NSA liefern?
Zur eigenen Sicherheit muss hier hinterfragt werden ob es nicht einen EU-Anbieter mit Datenspeicherung in der EU als Alternative gibt.
Der Markt bietet hier einige Alternativen – teils sogar Lösungen die ausschließlich innerhalb der Unternehmens-IT arbeiten und keine Daten in die Cloud oder zum Anbieter übertragen.
Der werthAUDITOR ist eine solche Lösung und prüft IT- und SAP-Systeme auf Schwachstellen und die Daten bleiben dabei garantiert in der sicheren Unternehmens-IT.
Der Cloud Act trägt deutlich die Handschrift der „America First“ Initiative und sollte zum Nachdenken anregen welche Daten wie und wo sicher gespeichert und verarbeitet werden. Idealerweise verlassen sensible Daten gar nicht erst das eigene Unternehmen.
