Xiting https://www.xiting.de Ihre SAP-Partner Wed, 27 Nov 2019 14:54:37 +0100 de-DE hourly 1 https://www.xiting.de/wp-content/uploads/2019/10/cropped-xiting-favicon-32x32.png Xiting https://www.xiting.de 32 32 Treffen der SAP Security Group 2020 https://www.xiting.de/treffen-der-sap-security-group-2020/ Tue, 26 Nov 2019 14:12:28 +0000 https://xiting.mewigo.com/?p=6989 Vom 27-28. Mai 2020 findet das 6. Treffen der SAP Security Group in der Print Media Academy in Heidelberg statt. Jetzt anmelden!

Der Beitrag Treffen der SAP Security Group 2020 erschien zuerst auf Xiting.

]]>
Am 27.-28. Mai 2020 findet das 6. Treffen der SAP Security Group in der Print Media Academy in Heidelberg statt.

Hier haben Sie die Möglichkeit exklusive Fachvorträge und Workshops erfahrener Sicherheits-Experten zu erleben. Erfahren Sie mehr zu den Themen SAP S/4 HANA Migration, XAMS, FIORI Security, SAP Identity Management und weitere Neuigkeiten rund um das Thema SAP Security.

Weitere Informationen sowie die Agenda lassen wir Ihnen mit der offiziellen Einladung zukommen. Sollten Sie noch nicht in unserem Newsletter-Verteiler sein, haben Sie am Ende der Seite die Möglichkeit sich dafür einzutragen, um zeitnah alle Informationen zur Veranstaltung zu erhalten.

Wir freuen uns, wenn Sie sich den Termin für Ihren Besuch in Heidelberg schon jetzt vormerken.

Der Beitrag Treffen der SAP Security Group 2020 erschien zuerst auf Xiting.

]]>
Xiting goes green – Engagement im Klimaschutz https://www.xiting.de/xiting-goes-green-engagement-im-klimaschutz-%f0%9f%8c%b3/ Tue, 01 Oct 2019 13:26:48 +0000 https://xiting.mewigo.com/?p=6243 Es ist nun offiziell! Seit Oktober 2019 verfolgen wir erfolgreich das Ziel, als Unternehmen zu 100% CO2-neutral zu agieren. Dies geschieht primär in der Unterstützung der Stiftung Plant-for-the-Planet – ein Aufforstungsprojekt, in dem Bäume gepflanzt und dadurch Treibhausgase gesenkt werden sowie auch die Ausbildung von Klimabotschaftern gefördert wird. Wir übermitteln jährlich neu berechnet unsere CO2-Emissionen […]

Der Beitrag Xiting goes green – Engagement im Klimaschutz erschien zuerst auf Xiting.

]]>
Es ist nun offiziell! Seit Oktober 2019 verfolgen wir erfolgreich das Ziel, als Unternehmen zu 100% CO2-neutral zu agieren. Dies geschieht primär in der Unterstützung der Stiftung Plant-for-the-Planet – ein Aufforstungsprojekt, in dem Bäume gepflanzt und dadurch Treibhausgase gesenkt werden sowie auch die Ausbildung von Klimabotschaftern gefördert wird. Wir übermitteln jährlich neu berechnet unsere CO2-Emissionen von Xiting und kompensieren diese nachhaltig.

Ziel der Kinder- und Jugendinitiative, die 2007 gegründet wurde, ist mittlerweile, weltweit 1.000 Milliarden Bäume zu pflanzen. Bäume sind das günstigste und effektivste Mittel, CO2 zu binden und so der Menschheit einen Zeitjoker zu verschaffen, um die Treibhausgas-Emissionen auf null zu senken und die Klimakrise abzuschwächen.
2011 übergab das Umweltprogramm der Vereinten Nationen, kurz UN Environment, die traditionsreiche Billion Tree Campaign an Plant-for-the-Planet – und damit den offiziellen Weltbaumzähler. Passend zum ambitionierten Ziel der Kinder hat Plant-for-the-Planet inzwischen die Trillion Tree Campaign ausgerufen.

Bisher wurden bereits über 13,6 Milliarden Bäume in 193 Ländern gepflanzt. Auf der Halbinsel Yucatán in Mexiko pflanzt Plant-for-the-Planet alle 15 Sekunden einen neuen Baum. Das Pflanzprojekt zeigt, wie einfach es ist im großen Stil effizient Bäume zu pflanzen. Mit eigenen Produkten (z.B. Die Gute Schokolade) und Kampagnen (z.B. „Stop talking. Start planting.“) pflanzt die Initiative selbst Bäume und motiviert zum Mitpflanzen. Auf Akademien bilden sich die Kinder gegenseitig zu Botschaftern für Klimagerechtigkeit aus – über 81.000 Kinder und Jugendliche aus 73 Ländern sind schon dabei! Xiting erachtet neben direkten Maßnahmen wie dem Bäume Pflanzen es auch als besonders wichtig, bei den nachfolgenden Generationen ein außerordentliches Bewusstsein im Umgang mit unserem Planeten zu schaffen.

Mehr erfahren über Plant-for-the-Planet!

Wir sind davon überzeugt, dass es als Unternehmen besonders wichtig ist, eine gesellschaftliche Verantwortung zu übernehmen und arbeiten aus diesem Grund beständig an der Weiterentwicklung und Unterstützung rund um das Thema Nachhaltigkeit

Das Nachhaltigkeitsteam von Xiting freut sich über Anregungen zu neuen Ideen & Technologien im Bereich des Klimaschutzes, um sich in Sachen Nachhaltigkeit fortlaufend weiterzuentwickeln. Wenden Sie sich gerne an climate@xiting.ch!

Der Beitrag Xiting goes green – Engagement im Klimaschutz erschien zuerst auf Xiting.

]]>
Single Sign-On vs. Multi-Factor-Authentication https://www.xiting.de/single-sign-on-vs-multi-factor-authentication/ Thu, 05 Sep 2019 09:38:15 +0000 https://www.xiting.ch/?p=3668 In diesem Blog spreche ich von Möglichkeiten, Risiken, technischen oder menschlichen Faktoren, die sich beim Einsatz von SAP Single Sign-On ergeben können und davon, wie eine sichere Authentifizierung bzw. MFA ein SSO-System sinnvoll ergänzen kann. Ein technisch korrekt etabliertes Single Sign-On (SSO) bietet viele Vorteile für SAP-Unternehmen wie z. B. den Einsatz von Tokens zur […]

Der Beitrag Single Sign-On vs. Multi-Factor-Authentication erschien zuerst auf Xiting.

]]>
In diesem Blog spreche ich von Möglichkeiten, Risiken, technischen oder menschlichen Faktoren, die sich beim Einsatz von SAP Single Sign-On ergeben können und davon, wie eine sichere Authentifizierung bzw. MFA ein SSO-System sinnvoll ergänzen kann.

Ein technisch korrekt etabliertes Single Sign-On (SSO) bietet viele Vorteile für SAP-Unternehmen wie z. B. den Einsatz von Tokens zur Authentifizierung; den Entfall von Passworten sowie der Passwortverwaltung; die Identifizierung der Kommunikationspartner; Verschlüsselung- und Integritätsschutz von Netzwerkverbindungen usw. Ein schlecht implementiertes SAP SSO kann die allgemeine Sicherheit im schlimmsten Fall auch schwächen und einem unberechtigten Anwender (oder Angreifer) den Zugriff auf jedes angebundene System gewähren. Auch die auf der #OPCDE2019 vorgestellten SAP-Gateway-to-Heaven-Exploits, die man auch besser unter der Onapsis-Bezeichnung „10KBLAZE“ kennt, profitieren von SAP-Unternehmen in denen DIAG- und RFC-Verbindungen noch im Klartext, ohne Integritätsschutz oder PKI-Authentication stattfinden. Im Worst-Case-Szenario gelangt eine andere Person unter verschiedensten Umständen an das Anmeldetoken wie z. B. das Anmeldepasswort, das SAP Logon Ticket, oder das Kerberos Service Ticket bzw. den privaten Schlüssel des Anmelde-Zertifikats.

SSO bietet Zugriff auf viele Ressourcen, sobald der Benutzer erstmalig authentifiziert wurde. Dies erhöht die negativen Auswirkungen, falls die Anmeldeinformationen anderen Personen zur Verfügung stehen und missbraucht werden können. Da reicht schon ein Arbeitsplatz aus, der nicht gesperrt wurde, wenn der Mitarbeiter nicht am Platz ist. Das kommt häufiger vor als man denkt und kann natürlich auch dann passieren, wenn das Unternehmen gar keine SSO-Lösung einsetzt.

Wichtig ist es daher eine „Clean-Desk“-Policy umzusetzen und entsprechende Awareness bei den Mitarbeitern aufzubauen. Aber auch technische Maßnahmen können eingeführt werden, wenn ein Unternehmen für sich entscheidet, dass das Risiko eines potentiellen Missbrauchs zu hoch ist.

Es gelten zwei Grundsätze. Das Single Sign-On Verfahren muss auf aktuellen und sicheren Verschlüsselungsalgorithmen- und Authentifizierungsmethoden basieren und der SSO-Mechanismus darf nicht schwächer sein als die Authentifizierungsmethode selbst. Darüber hinaus bieten gute SSO-Lösungen jederzeit Unterstützung für verschiedene MFA-Verfahren.

Passwörter werden als Schlüssel zu unseren Informationen angesehen und sollten daher sicher ausgewählt und mit Sorgfalt behandelt werden. Passwörter begleiten uns im Alltag und werden häufig beim Zugriff auf das Betriebssystem oder beim Anmelden an Unternehmensanwendungen eingesetzt; SAP ist eine von vielen. Aufgrund ihrer Multi-System-Landschaft und der schrecklichen dezentralen Passwortverwaltung ist eine SAP-Landschaft ein optimaler Kandidat für die Verwendung von Single Sign-On (SSO), um die Gesamtzahl der für mehrere Systemlandschaften erforderlichen Passwörter deutlich zu reduzieren bzw. die Passwortanmeldung komplett abzuschaffen.

Die einfache Kombination aus Benutzer-ID und Passwort ist heute längst nicht mehr gut genug, um unsere wichtigsten  Informationen ausreichend zu schützen. Beispiele sind Ihr Bankkonto, Ihre Bitcoin-Wallet, Ihr iCloud-Konto oder andere sensible Systeme bzw. Cloud-Dienste. In vielen Fällen müssen Sie hier eine zweite Art der Authentifizierung einsetzen, um Ihre Konten vor ungewolltem Einsatz bzw. Phishing zu schützen. Dann spricht man meist von Multi-Factor-Authentication (MFA) oder auch Zwei-Faktor-Authentifizierung (2FA).

SSO und MFA befassen sich beide mit der Authentifizierung. Während SSO meist einfach zu bedienen und vollautomatisch für den Benutzer abläuft, gestaltet sich der Einsatz von MFA oft unbequem, ist aber deutlich sicherer und somit für kritischste Anwendungen bzw. Transaktionen verpflichtend. Wie kann man beides so vereinen, dass die erforderliche Sicherheit und gleichzeitig Anwenderfreundlichkeit erreicht werden?

Multi-Factor-Authentication (MFA)

MFA verwendet mehrere (mindestens aber zwei) verschiedene Faktoren, um Ihre Identität zu überprüfen.

  • Etwas, das du weißt
    • Passwort, persönliche Identifikationsnummer oder Login-Name
  • Etwas, das Du hast
    • Sicherheitstoken; Smartphone-App; Passcode-Generator; SMS; E-Mail oder andere Faktoren
  • Etwas, das Du bist
    • Biometrische Sicherheitsfaktoren wie etwa Fingerabdruck oder Gesichtserkennung

Basierend auf IP-Geolokalisierung oder sonstigen Anti-Fraud-Algorithmen senden einige Dienste auch E-Mails, die Ihre zusätzliche Bestätigung zur Anmeldung benötigen. Der Vorteil ist, dass MFA sehr sicher ist. Die Kombination von etwas, das Sie wissen, mit etwas, das Sie haben oder sind, reduziert das Risiko von kompromittierten Konten erheblich. Der wichtigste Nachteil von MFA sind seine Unannehmlichkeiten: Sie müssen etwas tun, das Zeit braucht, was oft zu einer negativen Benutzererfahrung führt.

Was ist Single Sign-On (SSO)?

Zu aller erst müssen Sie wissen: SSO ist nicht gleich SSO. Es gibt verschiedene Geschmacksrichtungen und die Terminologie ist nicht klar geregelt. Und natürlich sollte Ihr SSO auf standardisierten SSO-Technologien wie Kerberos, SAML 2.0 oder CBA basieren.

Enterprise Single Sign-On (E-SSO): Zu verstehen als Client-Software, die Anmeldebildschirme automatisch (Skriptbasiert) mit dem richtigen Benutzernamen und Kennwort auffüllt. Der Benutzer muss nach einer „Anlernphase“ das Kennwort in verschiedenen Anwendungen nicht mehr manuell eingeben. Geschützt werden alle Credentials über ein Master-Passwort. Ein Beispiel dafür ist der Password-Manager, der in viele Browser integriert ist, sowie viele kommerzielle Produkte bis hin zu Enterprise-Lösungen. Anmeldeinformationen werden entweder auf dem PC oder einer Smartcard sowie auf Servern, Verzeichnisdiensten oder Datenbanken im LAN oder der Cloud gespeichert. E-SSO-Lösungen werden häufig in Fällen verwendet, in denen die Anwendungen keine echten SSO-Mechanismen unterstützen. Sie sind technisch gesehen keine wirkliche SSO-Lösung bzw. lösen nicht die technischen Probleme hinter der Komponente Endanwender.

?? Schwache Sicherheit und häufig mit Usability-Problemen verbunden

Single Password/Single Credential: Es wird immer das gleiche Passwort verwendet, um sich an vielen Diensten zu authentifizieren. In der Regel wird ein zentrales Kennwort aus dem Active Directory über die Synchronisation an alle angebundenen Dienste verteilt, während die Anmeldemethode unverändert bleibt.

?? Nicht sehr sicher und hat viele Nachteile (Security & Usability)

Single Sign-On: Das Konzept des echten SSO basiert auf der Idee, dem Benutzer Zugriff auf alle Anwendungen über eine einmalige Anmeldung zu ermöglichen. Diese sollte hochsicher sein. Meist wird dazu jedoch die Windows-Anmeldung am Active Directory verwendet. Dies wird als primäre Authentifizierung betrachtet. Darauf aufbauend werden Industriestandards wie Kerberos, X.509 oder SAML 2.0 eingesetzt und somit letztlich Kennwörter durch Security-Token ersetzt. SSO reduziert somit die Anzahl der vom Benutzer benötigten Kennwörter auf das absolute Minimum. Der Identity Provider hat dafür Sorge getragen, dass sich der Benutzer als gültiger Anwender identifiziert hat und anschließend einen Vertrauensnachweis ausgestellt.  Im Prinzip überprüft der Anwendungsserver nur diesen Nachweis bzw. das vertrauenswürdige Security-Token, anstatt den Benutzer selbst zu authentifizieren.

SSO bedeutet nicht, dass man auf allen Systemen das gleiche, sondern im besten Fall überhaupt kein Passwort mehr hat. Es handelt sich um eine Vereinfachung, aber es sollten je nach Einsatzumgebung hohe Sicherheitsanforderungen in Betracht gezogen werden.

?? Ein Benutzer muss sich immer nur ein Kennwort merken, und in Kombination mit starker Authentifizierung oder MFA kann gezielt zusätzliche Sicherheit erreicht werden.

?? SSO ist schnell und bequem für den Endbenutzer und infolgedessen gibt es weniger Anrufe an den Service Desk für Passwort-Resets, wodurch die IT-Supportkosten reduziert werden. Technisch werden keine Passwörter mehrmals erneut übertragen, wie es bei den ersten beiden Ansätzen der Fall ist.

?? SSO setzt IMMER auf verschlüsselte Netzwerkverbindungen und auf moderne Algorithmen- und Standards, um eine höchstmögliche Security zu gewährleisten.

Verwenden von SSO in Hochsicherheits-Umgebungen und Einsatz von starker Authentifizierung

Hochsicherheits-Umgebungen wie die US-Regierung erfordern z. B. die Einhaltung der FIPS 140-2-Standards und die Verwendung der Smartcard-Authentifizierung als primäre Methode für den Zugriff auf ihre IT-Systeme. Die Smartcard enthält einen privaten Schlüssel, welcher mit einer PIN geschützt ist. Somit wird eine Zwei-Faktor-Sicherheit erreicht. Wenn Sie die Smartcard aus dem Lesegerät entfernen, wird der Computer sofort gesperrt. Diese Art der primären Authentifizierung (starke Authentifizierung) gilt als hochsicher und wird von einigen Unternehmen verwendet, die solche Anforderungen haben.

Insbesondere haben wir die Erfahrung gemacht, dass in der Regel die Kombination mit Gebäudezugang, Zeiterfassung oder Zahlungssystemen am sinnvollsten ist. In diesem Fall verbleibt die (Firmen-)Karte nicht im Kartenleser, wenn der Mitarbeiter das Mittagessen genießt. Selbstverständlich ist es möglich, dies mit Ihren SAP-Zugriffssteuerungen zu kombinieren und sogar diese Methode der starken Authentifizierung für alle (oder einige) SAP-Benutzer/-Systeme in Ihrer Organisation durchzusetzen.

Wenn Sie jedoch keine Smartcards, Lesegeräte oder gar PKI mit einem angeschlossenen Kartenverwaltungssystem besitzen, macht es wenig Sinn, über diese Methode nachzudenken.

Verwenden von MFA für die sichere Authentifizierung an Ihren wichtigsten Systemen

Nach unserer Erfahrung verfügen die meisten Unternehmen nur über wenige SAP-Systeme bzw. Anwendungen mit höheren Sicherheitsanforderungen. Wir empfehlen, die SAP-Systeme in Sicherheitszonen zu kategorisieren und auf dieser Basis das gewünschte Authentifizierungsverfahren zu definieren.

Wenn Sie SAP-Systeme haben, auf denen Sie Single Sign-On nicht verwenden bzw. zulassen möchten ist es möglich, eine zusätzliche Authentifizierung an einem zentralen Authentifizierungsserver (z. B. einem LDAP/AD) zu erzwingen. Wenn Sie beispielsweise auf Ihr SAP Employee Self-Services (ESS)-Portal zugreifen, müssen Sie sich mit Ihren Active Directory-Anmeldeinformationen anmelden oder sogar einen Einmal-Passcode (OTP) eingeben. Beim Zugriff auf alle anderen SAP-Anwendungen dagegen ist ein SSO konfiguriert.

Eine Methode, die ich auch oft umgesetzt habe, ist folgende: MFA beim Zugriff auf die erste SAP-Anwendung des Tages. Der daraufhin authentifizierte Benutzer kommt nun während des gesamten Arbeitstages in den Genuss von SSO. Unabhängig davon, welchen Ansatz Sie wählen, stellen Sie immer sicher, dass die Übertragung von Authentifizierungsdaten über verschlüsselte Kommunikationskanäle erfolgt. Und letztlich ist der Benutzer die letzte Bastion. Steigern Sie ständig das Security-Bewusstsein der Benutzer, schulen Sie sie im Hinblick auf den sicheren Umgang mit IT-Systemen. Führen Sie Richtlinien für den sauberen Schreibtisch und den Sperrbildschirm ein. Diese nichttechnischen Ansätze werden auch dazu beitragen, die Sicherheit zu erhöhen, mal ganz abgesehen von SAP oder SSO. ?

Wenn Sie erfahren möchten, wie SSO und MFA in Ihrer SAP-Umgebung eingesetzt werden können, sprechen Sie uns an!

Der Beitrag Single Sign-On vs. Multi-Factor-Authentication erschien zuerst auf Xiting.

]]>
SAP Single Sign-On Insider-Tipp: SSO in Multidomains https://www.xiting.de/sap-single-sign-on-insider-tipp-sso-in-multidomains/ Thu, 29 Aug 2019 08:00:09 +0000 https://www.xiting.ch/?p=3663 Anmerkung: Dieser Blog wurde aus dem Englischen übersetzt, hier geht’s zum Original. In unserer Blog-Reihe „SAP Single Sign-On Insider Tips“ teilen wir gerne Best Practices mit Ihnen, um Sie bei Ihren SSO-Projekten besser zu unterstützen und Ihnen unnötiges Kopfzerbrechen zu ersparen. In diesem Blog geht es um die Implementierung von SAP Single Sign-On 3.0 mit […]

Der Beitrag SAP Single Sign-On Insider-Tipp: SSO in Multidomains erschien zuerst auf Xiting.

]]>
Anmerkung: Dieser Blog wurde aus dem Englischen übersetzt, hier geht’s zum Original.

In unserer Blog-Reihe „SAP Single Sign-On Insider Tips“ teilen wir gerne Best Practices mit Ihnen, um Sie bei Ihren SSO-Projekten besser zu unterstützen und Ihnen unnötiges Kopfzerbrechen zu ersparen. In diesem Blog geht es um die Implementierung von SAP Single Sign-On 3.0 mit Kerberos/SPNEGO-Authentifizierung in Active Directory Umgebungen, die aus mehreren Domänen oder Gesamtstrukturen bestehen.

Wir haben bereits viele Projekte in diesem Umfeld durchgeführt, von kleinen bis hin zu mittleren und sehr großen AD-Strukturen, die aus mehreren autonomen Gesamtstrukturen mit Dutzenden von Domänen bestehen. Manchmal ist alleine die Informationsbeschaffung in größeren Landschaften, in denen viele  AD-Domänen oder Forests beteiligt sind, umständlich. Auch gibt es so manche Missverständnisse was korrekte Ansätze und die Vorgehensweise betrifft, um eine Kerberos-Authentifizierung in solchen Umgebungen zu implementieren. Dieser Blog soll Sie dabei unterstützen, die richtigen Entscheidungen für die Architektur der Lösung zu treffen.

Diese Blog-Reihe ist nicht für Neueinsteiger in das Thema gedacht, stellen Sie bitte sicher, dass Sie die Grundprinzipien der Kerberos-Authentifizierung (TGS, KDC, TGT, ST) verstehen und bereits wissen, was Keytabs, Service Accounts und Service Principals sind.

Active Directory Gesamtstrukturen- und Domänen

Ein Active Directory Forest (im Deutschen die Gesamtstruktur) ist der oberste logische Container in einer Active Directory-Konfiguration, der Domänen, Benutzer, Computer und Gruppenrichtlinien enthält. Eine einzelne Domäne bildet auch einen Forest, der später durch zusätzliche Domänen ergänzt werden kann. Unterhalb der so genannten Forest-Root-Domäne (der ersten Domäne in einem neuen AD-Forest) können Sie mehrere untergeordnete Domänen haben, die wiederum ihre eigenen untergeordneten Domänen haben können. Das kann im gleichen durchgängigen Namensraum sein, z. B. COMPANY.INTRA und UK.COMPANY.INTRA, oder in einem eigenen bzw. nicht durchgängigen Namensraum. Somit kann eine größere Struktur aus mehreren Forests etabliert werden, jeder mit seinen Domänen, die mehrere Bäume und Zweige haben, daher wird es auch Forest genannt.

Heute wird in den meisten Fällen eine einzelne AD-Gesamtstruktur bzw. Domänenumgebung als Best Practice betrachtet, also ein Forest, eine Domain, alles Flach. Objekte können mittels OUs (Organisationseinheiten) strukturiert und somit nach dem „Least Privilege-Prinzip“ verschiedenen Verwaltungseinheiten- und Admins zugeordnet werden. In den letzten Jahren wurden viele komplexe AD-Strukturen nach diesem Ansatz vereinfacht und oft erleben wir bei Durchführung von SSO-Projekten, dass gerade ein paralleles Projekt zur Neustrukturierung der Active Directory stattfindet, welches ebenfalls Berücksichtigung finden muss.

Solange alle Domänen zur gleichen Gesamtstruktur gehören, ist gegenseitiges Vertrauen zwischen den Domänen inhärent. Benutzer können daher Ressourcen aus allen Domänen in der Gesamtstruktur verwenden, sofern sie dazu berechtigt sind. Dies wird auch als transitive Vertrauensstellung bezeichnet.

Manchmal kommt es vor, dass eine Organisation entweder aus historischen Gründen, zum Beispiel aufgrund von Firmenübernahmen oder Fusionen, mehrere AD-Forests betreibt. Standardmäßig besteht keine Vertrauensstellung zwischen zwei Gesamtstrukturen. Vertrauensstellungen zwischen Gesamtstrukturen sind dann erforderlich, um Zugriff auf einige Ressourcen der anderen Gesamtstruktur zu erhalten. Es gibt bidirektionale oder unidirektionale Gesamtstruktur- bzw. Domänenvertrauensstellungen. Somit kann man unter Umständen in Projekten, die das Thema Kerberos Authentifizierung adressieren, auch eine Multi-Forest-Umgebung vorfinden und muss nun wissen, wie hier in Bezug auf die Integration von SAP SSO vorzugehen ist. Der technisch beste und einfachste Weg sollte gewählt und dabei auch wichtige Sicherheitsstandards – wie zum Beispiel erzwungene AES256-Verschlüsselung vom KDC – eingehalten werden.

Erster Schritt – Informationsbeschaffung

Wenn Sie im Umfeld IAM und SAP tätig sind, müssen Sie sich normalerweise nicht mit allen Details des Active Directory auskennen. Eines der wichtigsten Dinge ist es, zuerst die Active Directory-Landschaft, dessen Domänen und Gesamtstrukturen sowie deren Vertrauensbeziehungen untereinander zu verstehen.

Anmerkung: Die Domänen- oder Gesamtstrukturfunktionsebene spielt in diesen Projekten meist keine Rolle

Tipp: Beziehen Sie die Experten aus dem Active Directory-Team in Ihr Projekt ein und gewinnen Sie ein genaues Verständnis, bevor Sie mit dem Projekt beginnen. Starten Sie mit einem Workshop, um die erforderlichen Details zu sammeln und architektonische Fehler (z. B. wie die Anlage von Service Accounts in jeder Domäne) zu vermeiden.

Hintergrundinformationen – Beispiel SAP Logon

Jeder Active Directory Domain Controller betreibt den KDC-Dienst (Key Distribution Center) und dient damit als Kerberos-Server. Nach erfolgreicher Anmeldung eines Benutzers an seinem PC erhält dieser vom DC seiner Domäne ein TGT (Ticket Granting Ticket) ausgestellt. Für das SAP-System (z. B. AS ABAP) wird ein Service Konto angelegt. Für dieses Service Konto werden im Active Directory zudem SPNs (Service Principal Names) registriert, auf dessen Basis Kerberos fähige Systeme bzw. Anwendungen ein entsprechendes Service Tickets (ST) anfordern können.

Dieses Service Konto wird auf dem SAP-Backend hinterlegt, das Resultat ist eine Keytab-Datei, die das System zur „Entschlüsselung“ von Service Tickets benötigt. Diese Keytab wird je nach eingesetzter CommonCryptoLib-Version und NetWeaver Release entweder global in der Datenbank oder auf Dateiebene in einer PSE gespeichert. Ein Kerberos Ticket enthält den iUPN (Impliziter UserPrincipalName) der in der Windows-Welt einen Benutzer eindeutig in einem AD-Forest identifiziert und sich aus sAMAccountName@<FQ-Domain-Name> zusammensetzt.

Wenn der Anwender nach erfolgreicher Anmeldung am Windows System nun vom KDC ein TGT erhalten hat, dann versucht der Secure Login Client automatisch – beim Start einer SNC gesicherten SAP Logon Verbindung – mit diesem TGT ein ST für den SPN anzufordern. Darüber weiß der TGS, mit welchem Service Konto er das Ticket verschlüsseln muss und sendet das ST verschlüsselt an den Windows Ticket Cache zurück.

Der Secure Login Client verfügt nun über das Ticket welches er als Credential-Provider der SNC-Bibliothek am Client (CommonCryptoLib) zur Verfügung stellt. Über das DIAG-Protokoll sendet das SAP Logon das ST nun an das SAP-Serversystem. Dieses kann das ST durch die SNC-Konfiguration sowie das vorhandene Keytab entschlüsseln, vertraut somit dem REALM (der Domäne) und kann den Anwender damit eindeutig identifizieren.

SPNEGO-Authentifizierungsablauf in mehreren Domänen einer Gesamtstruktur

Um den Kerberos-Authentifizierungsablauf besser zu veranschaulichen, hier nun ein Beispiel, welches den Vorgang der SPNEGO-Authentifizierung über den Browser verdeutlichen soll. Der Benutzer Max Mustermann in der Domäne SALES.INTRA (eine Child Domäne im Forest COMPANY.INTRA) greift auf das SAP Fiori Launchpad eines Unternehmens zu.

Künftig sollen auch noch Anwender aus verschiedenen anderen Domänen in der gleichen Gesamtstruktur mit SAP Fiori arbeiten. Das Fiori Launchpad wird auf einem SAP NetWeaver AS ABAP betrieben, der für die SPNEGO-Authentifizierung konfiguriert wurde. Für den AS ABAP wurde nur ein Service Account und eine Keytab erstellt, in diesem Fall wurde der Service Account und SPN in der Forest Root-Domäne COMPANY.INTRA erstellt. Das SAP-System vertraut somit durch die Keytab automatisch allen weiteren Domänen in der Gesamtstruktur.

  1. Max meldet sich in der Domäne INTRA an seinem Computer an. SALES.INTRA ist eine Child Domäne im Forest COMPANY.INTRA. Ergebnis dieser Authentifizierungsdienst-Anforderung (AS) ist ein TGT: krbtgt/SALES.INTRA@SALES.INTRA
  2. Anschließend versucht Max, auf die SSO-fähige SAP-Webanwendung zuzugreifen. Durch die SPNEGO Konfiguration liefert der SAP ICM dem Client Browser ein 401 Unauthorized zurück inkl. dem Header WWW-Authenticate: Negotiate.
  3. Max‘ Browser weiß nun, dass der Webserver die Kerberos Authentifizierung unterstützt (SPNEGO) und erstellt einen Ticket Granting Server (TGS)-Request für die aufgerufene URL (SPN) an den KDC in der Domäne INTRA. Da dieser SPN für keine Principals in der Domäne SALES.INTRA registriert ist, sendet der Domänencontroller eine Verweisung an einen globalen Katalog (GC) in der Gesamtstruktur COMPANY.INTRA. Der GC weiß, dass diese TGS-Anforderung für einen Principal in einer anderen vertrauenswürdigen Domäne bestimmt ist, und sendet dem Client eine Verweisung an die übergeordnete Domäne COMPANY.INTRA.
  4. Der Client erhält ein TGT für die Parent-Child-Vertrauensstellung zwischen INTRA und SALES.INTRA: krbtgt/COMPANY.INTRA@SALES.INTRA
  5. Sobald Max nun ein TGT für die Domain INTRA hat, sendet er eine TGS-Anfrage an einen KDC in dieser Domain. Der KDC liefert ein ST für den SPN zurück, z. B. HTTP/<URL>
  6. Das ST wird vom Browser codiert und über den Authorization-Header an den Webserver übergeben. Durch die SPNEGO-Konfiguration und das Keytab, kann das SAP-System das Service Ticket entschlüsseln und den Anwender automatisch authentifizieren.

Tipp: Befindet sich der Benutzer, der auf die SSO-fähige Ressource zugreift, in einer anderen AD-Gesamtstruktur, wird von der so genannten „Cross-Realm-Authentication“ gesprochen. Damit Clients in einer Gesamtstruktur bei einem Dienst in einer anderen vertrauenswürdigen Gesamtstruktur authentifiziert werden können, müssen sie diese Authentifizierung durchlaufen, bevor sie ein Kerberos Service Ticket in der Remotedomäne anfordern können. Hier würde Schritt 4 anders aussehen, da der Client zuerst ein Ticket Granting Ticket (TGT) in seiner eigenen Domäne erhält (falls nicht bereits vorhanden) und dann bereichsübergreifende TGTs für jede Ziel-Domäne in der Gesamtstruktur. Dies gilt natürlich nur für vertrauenswürdige Gesamtstrukturen. Wenn es keinen Trust zwischen den Forests gibt, müssten Sie einen Service  Account pro Gesamtstruktur erstellen.

Empfehlungen für die Verwendung von SNC in Umgebungen mit mehreren Domänen oder Gesamtstrukturen

  • Wenn es mehrere Gesamtstrukturen ohne Vertrauensstellungen gibt, müssen Sie einen Service Account (der Ihren SAP-Anwendungsserver darstellt) und einen oder mehrere SPNs in jeder Gesamtstruktur-Stammdomäne erstellen. Auf diese Weise verfügen Ihre SAP-Systeme möglicherweise über mehrere Keytabs für die verschiedenen Gesamtstrukturen, aber das ist in Ordnung.
  • In Szenarien, in denen Sie über eine Gesamtstrukturvertrauensstellung oder eine Gesamtstruktur mit mehreren Domänen (transitive Vertrauensstellungen) verfügen, müssen Sie die Service Accounts und SPNs nur in der Gesamtstruktur-Stammdomäne (oder in einer der Domänen) erzeugen.
  • Es empfiehlt sich, den SNC-Namen des SAP Server snc/identity/as wie ein X.509 DN zu definieren, z.B. p:CN=<SID>, O=Firma, C=DE. Die SAP CommonCryptoLib kann die zertifikatbasierte Authentifizierung (z. B. für Server-zu-Server-Kommunikation) und Kerberos parallel verwenden. Je nach Authentifizierungsmethode verwendet der Secure Login Client entweder den vorhandenen X.509 (DN) für die zertifikatbasierte Authentifizierung oder versucht, den CN-Teil einem Service Principal Name zuzuordnen z. B. SAP/<SID> wobei SID dem CN entspricht. Mit anderen Worten, der SAP Secure Login Client 3.0 erstellt den richtigen SPN, fügt die jeweilige Domäne des Benutzers hinzu und fordert beim lokalen KDC ein Ticket für SAP/<SID>@<USERDNSDOMAIN> an. Die Elemente O,  OU, C, usw. werden in diesem Fall vom Secure Login Client nicht weiter berücksichtigt. Weitere Informationen finden Sie im SAP-Hinweis 1696905.
  • Wenn mehrere vertrauenswürdige Gesamtstrukturen vorhanden sind, können Sie den Service Account für Ihr SAP-System in der Gesamtstruktur-Stammdomäne Damit Benutzer aus verschiedenen vertrauenswürdigen Gesamtstrukturen ein Service Ticket für Ihr SAP-System in der vertrauenswürdigen Stammdomäne der Gesamtstruktur anfordern können, müssen Sie sicherstellen, dass Sie den Domänennamen dem SNC-Namen im SAP Logon hinzufügen. Beispiel: p:CN=<SID>@<FORESTROOTDOMAIN>
  • Wenn Sie Anmeldegruppen verwenden, wird der SNC-Name dynamisch vom Profilparameter snc/identity/as des jeweiligen Anwendungsservers ausgelesen und vom Message Server an das SAP Logon übertragen. Dies kann Auswirkungen auf Ihr Lösungsdesign haben, und Sie sollten sorgfältig prüfen, ob Sie den Domänenteil in diesem Profilparameter benötigen oder nicht.

Wie Sie sehen, ist die Implementierung von SAP Single Sign-On 3.0 basierend auf Kerberos auch in Umgebungen mit mehreren Gesamtstrukturen nicht so schwierig. Natürlich gibt es noch viele andere wichtige Punkte, die bei solchen Projekten berücksichtigt werden müssen. Sie benötigen ein sauberes Namenskonzept für Ihre Active Directory Service Accounts, sichere Kennwörter und Verschlüsselungsalgorithmen sowie die richtigen SPNs. Sie müssen DNS-Auflösung, Reverse-Proxys bzw. NLB sowie die korrekte Systemzeit berücksichtigen. Sie benötigen ein Konzept zur Erstellung und zum Passwortmanagement Ihrer Service Accounts- und Keytabs etc.

Gerne sind wir Ihnen bei Ihrem nächsten Kerberos-basierten SAP Single Sign-On-Projekt behilflich.

Die anderen Artikel dieser Blog-Reihe finden Sie in unserem englischsprachigen Blog:

Der Beitrag SAP Single Sign-On Insider-Tipp: SSO in Multidomains erschien zuerst auf Xiting.

]]>
UI Masking in SAP GUI für Windows (Teil 3/3) https://www.xiting.de/ui-masking-in-sap-gui-fuer-windows-teil-3-3/ Thu, 22 Aug 2019 09:06:06 +0000 https://www.xiting.ch/?p=3637 Dies ist der dritte und letzte Teil unserer Blog-Serie, der über die Datensicherheitslösung „UI Masking und UI Logging“ von SAP spricht. In diesem Blog möchte ich über die Details der UI-Masking sprechen, die bestimmte Daten wie Steuer-IDs oder Sozialversicherungsnummern in SAP GUI (auch in anderen UI-Technologien) verschleiert. Diese Lösung maskiert Werte in gewünschten Feldern und […]

Der Beitrag UI Masking in SAP GUI für Windows (Teil 3/3) erschien zuerst auf Xiting.

]]>
Dies ist der dritte und letzte Teil unserer Blog-Serie, der über die Datensicherheitslösung „UI Masking und UI Logging“ von SAP spricht.

In diesem Blog möchte ich über die Details der UI-Masking sprechen, die bestimmte Daten wie Steuer-IDs oder Sozialversicherungsnummern in SAP GUI (auch in anderen UI-Technologien) verschleiert.

Diese Lösung maskiert Werte in gewünschten Feldern und Spalten, außer es sei denn, dass diese Informationen für eine spezifische Aufgabe benötigt werden.

Hier finden Sie Teil 1 + 2 dieser Blog-Serie:

Eine Einführung in die SAP UI Datensicherheitslösungen (Teil 1/3)

UI Logging im SAP GUI für Windows (Teil 2/3)

Einleitung

Möchten Sie Ihr Unternehmen vor unbefugter Offenlegung von internen, geheimen oder anderweitig sensiblen Daten schützen? Haben Sie schon einmal darüber nachgedacht, die Transparenz des Zugriffs auf vertrauliche Daten in Ihrem Unternehmen zu erhöhen? Und was ist mit Ihrem neuen Mitarbeiter? Haben Sie jemals darüber nachgedacht, dass er oder sie das schwarze Schaf sein könnte, das sich mit wichtigen Daten davonschleicht? Oder vielleicht ist es auch eine harmlose Aktion, die mehr preisgibt, als Sie eigentlich möchten.

Untersuchungen haben ergeben, dass 60% der Angriffe von Insidern (Personen, denen Sie vertrauen!) begangen werden und die meisten von ihnen dabei böswillige Absichten hatten.

Wenn Sie also darüber nachdenken, wie Sie das Insider-Risiko in Ihrer SAP-Landschaft angehen können, dann sind Sie hier herzlich willkommen und ab nun an der richtigen Hand.

Übersicht über UI Masking

Die UI-Maskierung ist eine Lösung, um die Bildschirmausgabe von eingeschränkten und vertraulichen Datenwerten auf Feldebene zu maskieren. Technisch gesehen bedeutet dies, dass man diese Daten von einem bestimmten User beschränkt, indem man diese Daten teilweise oder vollständig maskiert. Dies betrifft auch Systembenutzer auf hoher Ebene (in dynamischen Transaktionen, z. B. SE11, SE12, SE16, SE16n), sofern sie nicht ausdrücklich für ein Feld berechtigt sind.

Es wird dadurch eine Anonymisierung („Entpersönlichung“) bei Business-Transaktionen sowie technischen Transaktionen vorgenommen und gilt auch bei Aktionen wie Anzeigen, Herunterladen, Exportieren oder Drucken usw. Diese Lösung funktioniert mit vielen UI-Technologien wie SAP GUI für Windows / HTML / Java, UI5 / Fiori, Web Dynpro ABAP und anderen.  

Natürlich bietet die UI-Maskierung über das Business Add-In (BAdI) einen Erweiterungspunkt. Dies bedeutet, dass Ihre gewünschte benutzerdefinierte Logik darüber, was, wann und wie maskiert werden soll, mithilfe von BAdIs bis auf Feldebene implementiert werden kann. Sie haben auch die Möglichkeit zu steuern, wie die Trace-Einträge angereichert werden sollen.

Die UI Masking-Lösung von SAP auf hohem Niveau besteht aus den beiden Funktionen:

  1. Feldmaskierung: Die konfigurierbaren Optionen bieten die Erhöhung der Datensicherheit in SAP-Benutzeroberflächen, indem sensible Werte in Bildschirmfeldern maskiert werden, um den Datenzugriff über das bestehende Rollen-/Berechtigungskonzept hinaus zu verfeinern.
  2. Feld Access Trace: Es wird ein Zugriffsablaufeintrag erstellt, sobald der Benutzer auf die Felder zugreift, die für die Maskierung konfiguriert sind.
Unmaskierte Feldwerte
Maskierte Feldwerte

Funktionsweise der UI-Maskierung für SAP GUI

Die Feldmaskierung ermöglicht nur Benutzern mit einer Berechtigung auf Feldebene das Anzeigen des Feldwerts und der Periode. Wenn ein Benutzer nicht berechtigt ist, werden die Daten mit Maskierungszeichen maskiert. Nur Benutzer, die berechtigt sind, den Feldwert anzuzeigen, können den ursprünglichen Wert sehen.

Kurz bevor die Benutzeroberfläche angezeigt wird, erfolgt eine Maskierung und die Feldzugriffsablaufverfolgung wird aktiviert, je nach Konfiguration des Felds in der UI-Maskierung und der Berechtigung des Benutzers auf Feldebene. Die Maskierung des Datenwerts hängt vom Feldtyp und Zeichenmuster ab, wie es beim Anpassen konfiguriert wurde.

Mit anderen Worten, UI Masking ist an dem Punkt aktiv, kurz bevor die Daten zurück an den Benutzer verarbeitet werden. Die Originaldaten, die dem Benutzer angezeigt werden sollen, werden mit den Datenelementen verglichen, die für den Schutz konfiguriert sind (Maskierung).

Die Lösung überprüft, ob der Benutzer berechtigt ist, diese Informationen anzuzeigen oder nicht. Wenn Sie möchten, ist UI Masking auch in der Lage, eine kurze Ablaufverfolgung zu schreiben, dass der Benutzer die maskierten Daten angefordert hat.

Die folgende Abbildung bietet einen Überblick über den Prozess, in welcher Sie sehen, dass UI Masking weder die Datenbankebene noch die Geschäftslogik Ihres SAP-Systems beeinflusst.

Benutzerinteraktion mit maskierter Oberfläche (Quelle SAP SE)

Highlights der SAP UI Masking

Die globale Maskierung pflegen: In dieser Phase können Sie entscheiden, ob Sie die Maskierung für einen bestimmten Client aktivieren oder deaktivieren möchten. Diese Systemebeneneinstellung legt die Maskierung auf höchster Ebene fest. Wenn die Maskierung auf dieser Ebene nicht aktiv ist, wird keiner der konfigurierten Einträge maskiert und der Wert des ursprünglichen Felds (unmaskiert) wird für den Benutzer angezeigt.

Feldzugriffsablaufverfolgung: Hier wird eine Zugriffsdateneingabe geschrieben, wenn der Benutzer auf die für die Maskierung konfigurierten Felder zugreift. Die Ablaufverfolgung enthält verschiedene Informationen, z. B. den Benutzer, der auf maskierte Werte zugreift, Datum und Uhrzeit des Zugriffs und die Transaktion, die der Benutzer zum Anzeigen der konfigurierten Felder verwendet hat. Darüber hinaus verfügen Sie über umfangreiche Filteroptionen zum Einschränken und Minimieren der Informationen im Protokolldatensatz.

Transaktion (UIM_VIEW_FAT)

In der Feldzugriffsablaufverfolgung haben Sie die drei Möglichkeiten, um zu entscheiden, wie Sie Ihre maskierten Felder verfolgen möchten und können diese nacheinander überprüfen:

  • (L) Trace, wenn der ursprüngliche Feldwert ohne Maskierung angezeigt wird: Die Werte werden protokolliert, wenn das Feld von einem Benutzer abgerufen wird, der den unmaskierten Wert des Felds anzeigen darf.
  • (A) Always Trace (unabhängig von der Maskierung): Die Werte werden protokolliert, wenn ein autorisierter oder nicht autorisierter Benutzer auf das Feld zugreift.
  • (N) Never Trace (unabhängig von der Maskierung): Feldzugriffsablauf ist für dieses Feld oder diese Rolle deaktiviert.
Dies ist eine optionale Funktion auf Feldebene

Konfigurieren von E-Mail-Benachrichtigungen für PFCG-Rollenänderungen: Bei dieser Anpassung haben Sie die Möglichkeit, eine E-Mail-Benachrichtigung (Warnung) auszulösen, wenn jemand mit PFCG-Rollen verwechselt wird.

BAdI – UI-Maskierung und Feldzugriffsverfolgung: Mit Hilfe von BAdIs können Sie Ihre eigenen Regeln erstellen und Ihre eigene Geschäftslogik implementieren, um die maskierten Werte neu zu gestalten, kurz bevor sie an den Endbenutzer übertragen werden.

Für jeden Feldnamen, der in der Maskierungskonfiguration verwaltet wird, können Sie auf die Originaldaten sowie maskierten Daten zugreifen.

Fazit

SAP UI Masking ist eine starke Lösung für Ihre Datensicherheit. Das bedeutet, dass dieser Ansatz verhindert, dass unbefugte Mitarbeiter auf sensible Daten zugreifen können. Die Lösung reduziert das Risiko des Lecks sensibler Daten, indem Informationen einfach ausgeblendet werden, die nicht für den Job benötigt werden und sie damit dem Prinzip der Datenminimierung folgt.

Es gilt als kostengünstige Alternative zu Datenlösungen, wie zum Beispiel SAP ILM und ermöglicht Ihnen, die Datenschutzbestimmungen wie GDPR, HIPAA oder Sarbanes–Oxley einzuhalten.

Hier einige Vorteile, die Ihnen die SAP UI Maskierung bietet:

  • Schädliche und kostspielige Fälle von Datenverlust können vermieden werden
  • Die Transparenz des Zugriffs auf sensible Daten mit Audit-Trail auf Feldebene wird erhöht
  • Ein opportunistisches Datenleck wird verhindert
  • Eine menschliche Firewall wird erstellt und stärkt Mitarbeiter, indem das Bewusstsein für Datensicherheit erhöht wird
  • Ihre Mitarbeiter werden vor unbeabsichtigten Sicherheitsbrüchen geschützt
  • Die Sicherheit Ihrer Mitarbeiter ihre Arbeit selbstbewusst zu erledigen wird gesteigert

Ich wünsche Ihnen ein sicheres und geschütztes System und hoffe, dass Ihnen unsere kleine Reise in die Welt der SAP UI Masking und Logging gefallen hat.

Der Beitrag UI Masking in SAP GUI für Windows (Teil 3/3) erschien zuerst auf Xiting.

]]>
UI Logging im SAP GUI für Windows (Teil 2/3) https://www.xiting.de/ui-logging-im-sap-gui-fuer-windows-teil-2-3/ Thu, 15 Aug 2019 07:42:40 +0000 https://www.xiting.ch/?p=3609 Wie ich bereits im vorherigen Blog beschrieben habe, ereignen sich Verletzungen des Datenschutzes sowie Insider-Bedrohungen heutzutage sehr häufig. Sicherheitsprobleme werden schnell öffentlich. Dies ist offensichtlich eine sehr reale und äußerst große Herausforderung für Unternehmen, die den Schutz ihrer hochsensiblen Informationen gewährleisten müssen. Lesen Sie hier Teil 1 – Eine Einführung in die SAP UI Datensicherheitslösungen! […]

Der Beitrag UI Logging im SAP GUI für Windows (Teil 2/3) erschien zuerst auf Xiting.

]]>
Wie ich bereits im vorherigen Blog beschrieben habe, ereignen sich Verletzungen des Datenschutzes sowie Insider-Bedrohungen heutzutage sehr häufig. Sicherheitsprobleme werden schnell öffentlich. Dies ist offensichtlich eine sehr reale und äußerst große Herausforderung für Unternehmen, die den Schutz ihrer hochsensiblen Informationen gewährleisten müssen.

Lesen Sie hier Teil 1 – Eine Einführung in die SAP UI Datensicherheitslösungen!

In diesem Blog werde ich SAP UI Logging eingehender beleuchten. Diese Lösung umfasst verschiedene UI-Technologien, wie zum Beispiel S/4HANA, SAP GUI für Windows / HTML / Java, UI5 / Fiori, CRM Web Client, RFC / BAPI und Web Services. Von daher ist es schwierig, alle Technologien in einem Blog zu erkunden. Deswegen werde ich mich auf einen speziellen Anwendungsfall (Use Case) – den UI Logging im SAP GUI für Windows – konzentrieren.

UI Logging im SAP GUI für Windows – Ein erster Überblick

Mit SAP UI Logging können Sie herausfinden, welche Benutzer zu welchem Zeitpunkt Zugriff auf welche Daten erhielten. Das heißt, Sie können alle Daten von Transaktionen verfolgen, die in SAP GUI for Windows ausgeführt werden; Logging basiert auf Roundtrips (Frontend – Server – Frontend). Alle Eingabe- und Ausgabefelder auf der Benutzeroberfläche und die entsprechenden Werte wie Feldbezeichnungen, Titel und Überschriften, Tabellen, Bäume und Listen usw. werden in einem Datensatz protokolliert.

Mit anderen Worten: Alle Einträge, die von Nutzern gemacht werden, werden erfasst. Nachdem das System die Benutzereingabe verarbeitet hat, werden die dem Nutzer angezeigten Daten aufgezeichnet und in einem temporären Protokoll gespeichert.

SAP UI Logging kann sehr schnell und einfach implementiert werden, ohne dass Änderungen an der Systemfunktionalität erforderlich sind. Obwohl die Protokollierung im Hintergrund läuft, ist die Leistung optimal abgestimmt, so dass nur geringe Auswirkungen auf Leistung und Systemressourcen erwartet werden müssen.

UI Logging im SAP GUI für Windows – Highlights

Das primäre Ziel dieser Lösung ist es, Ihre Systeme zu schützen, indem Sie die Insider-Bedrohungen sofort identifizieren und die Bedrohung schnell genug analysieren können, bevor ernsthafte Schäden in Ihrem Unternehmen angerichtet werden.

Alarmszenario:

Nachdem Sie die Benachrichtigung im Customizing aktiviert haben, erhalten Sie E-Mail-Benachrichtigungen bei jedem illegalen Zugriff auf sensible Daten, abhängig von der Konfiguration, die Sie im Alerting Condition Editor gemacht haben.

In der Alert-Editor-Transaktion /logwin /alert_edit haben Sie eine Vielzahl von Optionen, um Ihre Alert-Bedingungen abhängig von Ihren Anforderungen zu definieren. Zum Beispiel können Sie entscheiden, dass die Alarmierung nur für bestimmte Benutzer oder Gruppen auf bestimmten Plattformen und Clients innerhalb eines bestimmten Zeitrahmens aktiv wird. Zudem haben Sie die Möglichkeit zu wählen, welche Transaktionen, Programme oder Web-Dynpros entscheidend sind und in Ihrer Benachrichtigung berücksichtigt werden sollen.

Die Benachrichtigungen können in verschiedenen Formen verschickt werden, z.B. in Form von  E-Mails, Kurznachrichtendienst (SMS Gateway erforderlich), SAP-Arbeitsraum-Mails etc.

Bei der Erstellung des temporären Protokollsatzes verarbeitet das System die Informationen nach Alarmbedingungen und löst den Alarm aus. Wenn das temporäre Protokoll für bestimmte Einträge wie Transaktionscodes oder Programme etc. nicht aktiviert ist, werden keine Warnungen für diese Einheiten ausgelöst.

UI-Logging User Manager

Mit dieser Funktion können Sie anhand von Benutzername, Benutzerrolle, Profilen und Gruppenzugehörigkeiten schnell pflegen, welche Benutzer in das UI-Logging aufgenommen oder ausgeschlossen werden sollen.

Der Log Analyzer und der UI Logging Zauberstab

Nehmen wir an, Sie haben das SAP UI Logging für etwa 50 Transaktionen und 200 User in Ihrem System konfiguriert. Am Ende des Tages haben Sie eine riesige Anzahl von Protokollaufzeichnungen mit einer sehr großen Anzahl von Einträgen, wie z.B. alle Eingabe- und Ausgabefelder auf der Benutzeroberfläche sowie die entsprechenden Werte, die Ihre Aufgabe erschweren könnten, die Aktivitäten aller Nutzer zu überwachen.

Der Log Analyzer ist dabei Ihr Zauberstab, um Filter zu setzen, die die wichtigen Log-Einträge abrufen können, während Sie diese Log-Einträge im System überwachen.

Wie Sie Ihre Protokolle auf Abruf effizient analysieren:

In diesem Beispiel habe ich die Transaktion SU01 für die Protokollierung gepflegt. Ich möchte sehen, wer SU01 ausgeführt hat und welche Log-Datensätze ich vorliegen habe.

Transaktion: /LOGWIN/LOGANALYZER

Wie Sie in den Screenshots des Log Analyzers sehen können, sind die protokollierten Daten in einem einzigartigen Namenswertpaar organisiert, so dass Sie bei Bedarf einen klaren Überblick über Ihre Analysedaten haben und umfangreiche Filtermöglichkeiten zur Verwaltung Ihrer Protokolldaten.

Fazit

SAP UI Logging ist als eine leichte, unkomplizierte und sichere Lösung zu verstehen, die Ihre Rolle als Audit massiv unterstützt. Es hilft Ihnen, potenzielle Datenlecks zu identifizieren und gleichzeitig DSGVO-konform zu sein, wobei Transparenz und Reduzierung des Datenzugriffs berücksichtigt werden.

Automatisierte Kontrollen alarmieren bei zweifelhaftem Datenzugriff und manuelle Kontrollen ermöglichen es Ihnen, die Protokolle regelmäßig und gründlich zu überprüfen. Neben der On-Demand-Protokollanalyse und den Echtzeit-Alarmierungsfunktionen können Sie auch die Analyse durch Integration in SAP Enterprise Threat Detection (ETD) automatisieren und Ihr UI Logging als leistungsstarke Datenquelle nutzen. SAP liefert UIL-spezifische Muster seit ETD SP7 aus.

Seien Sie gespannt auf den nächsten Blog, wenn wir den Use Case für SAP UI Masking erkunden werden!

Hier geht es direkt zu Teil 3: UI Masking in SAP GUI für Windows

Der Beitrag UI Logging im SAP GUI für Windows (Teil 2/3) erschien zuerst auf Xiting.

]]>
Eine Einführung in die SAP UI Datensicherheitslösungen (Teil 1/3) https://www.xiting.de/eine-einfuehrung-in-die-sap-ui-datensicherheitsloesungen-teil-1-3/ Thu, 08 Aug 2019 08:57:16 +0000 https://www.xiting.ch/?p=3597 Dies ist die erste einer mehrteiligen Blog-Serie, die sich mit dem Thema SAP UI Datensicherheit beschäftigt. In diesem ersten Blog möchte ich dabei über die allgemeinen Probleme und Risiken sprechen, denen SAP-Unternehmen heutzutage ausgesetzt sind. Lesen Sie hier direkt Teil 2 zu UI Logging im SAP GUI für Windows! Hier geht es direkt zu Teil […]

Der Beitrag Eine Einführung in die SAP UI Datensicherheitslösungen (Teil 1/3) erschien zuerst auf Xiting.

]]>
Dies ist die erste einer mehrteiligen Blog-Serie, die sich mit dem Thema SAP UI Datensicherheit beschäftigt. In diesem ersten Blog möchte ich dabei über die allgemeinen Probleme und Risiken sprechen, denen SAP-Unternehmen heutzutage ausgesetzt sind.

Lesen Sie hier direkt Teil 2 zu UI Logging im SAP GUI für Windows!

Hier geht es direkt zu Teil 3: UI Masking in SAP GUI für Windows!

Bevor wir gleich gemeinsam näher in das Thema einsteigen werden, möchte ich vorab eine kleine Definition von SAP UI Datensicherheitslösungen geben:

Mit diesen SAP-High-Level-Lösungen können Sie kontrollieren und erkennen, welche Daten sich ein Anwender vom Backend holen kann. Sie können auch Ihre eigenen Sicherheitsregeln auf der Feldebene definieren, indem Sie festlegen, welche sensiblen Feldwerte für jeden Nutzer gemäß den Anforderungen Ihres Unternehmens sichtbar oder unsichtbar sind.

Dieser Blog verfolgt das Ziel, eine Einführung von Sicherheitspraktiken in der Benutzeroberfläche zu bewerten. Es geht dabei sowohl um die Benutzeroberfläche selbst, als auch um generelle Sicherheitsprobleme, indem wir über Sicherheitsmechanismen in Ihren SAP-Systemen sprechen.

Risiken

Die meisten Menschen wollen nicht über die Sicherheitsverstöße, Datenlecks oder den Schaden nachdenken, den die Datenlecks verursachen könnten. Um den Wissenschaftler AJIT VARKI in seinem Buch Denial wörtlich zu zitieren: „avoiding the negative is a natural human tendency”.

In den letzten Jahren sind die Ereignisse von Datenlecks rasant gewachsen. Eine unbekannte Anzahl von Nutzern haben dabei wertvolle Informationen aus sensiblen Systemen durchsickern lassen, an denen sie beteiligt waren. Bezeichnen wir diese Aktion als eine Bedrohung, die von innen heraus entsteht.

“Data security issues are (not very surprisingly) quite often perpetrated by insiders, not just hackers. This is a problem in itself, as “an insider threat” is a thousand times worse than a hacker threat because it is so hard to defend against.”

Quelle The Economist: Christopher Hadnagy, Security-Experte

Eine kleine Internetrecherche zeigt, dass rund 35 Prozent aller Organisationen in den vergangenen vier Jahren von Datenlecks durch „insider threats“ betroffen waren.

Die SAP-Systeme in Ihrem Unternehmen enthalten eine riesige Menge an sensiblen Daten und kritischen Geschäftsinformationen, auf die Benutzer Zugriff haben. Einige davon sind notwendig, andere weniger. Wir können sie als „nicht vertrauenswürdige Kunden“ betiteln. Stellen Sie sich vor, ein Benutzer mit einer unehrlichen Absicht in einer sehr guten Position befindet sich in Ihrem System, verfügt über wichtige Berechtigungen und Grundkenntnisse, die erforderlich sind, um Zugang zu kritischen und sensiblen Informationen zu erhalten. Dies könnte dazu führen, dass am Ende des Tages vielleicht diese Daten in Ihrem Unternehmen verloren gegangen sind.

Aufgrund des immer mehr dezentralen Lebensstils, in dem Unternehmen es ihren Mitarbeitern ermöglichen, über viele verschiedene Geräte von überall auf der Welt auf Informationssysteme zuzugreifen, bewegen diese Nutzer daher einen Teil des Informationssystems aus der er erst sicheren Infrastruktur heraus hin zu einer unsicheren. Diese Sicherheitslücken in der SAP UI werden somit durch den Nutzer selbst verursacht.

Sicherheitsverstöße werden heute schnell öffentlich bekannt und die Risiken, die wir jedes Mal in Kauf nehmen, wenn wir einem Nutzer mit den notwendigen Berechtigungen Zugang zu unseren Systemen verschaffen, sind sehr real.

Um diese Risiken zu vermeiden, empfehlen wir jeder SAP-Organisation, ihre Datensicherheit durch die Einführung von UI-Feldmaskierung und UI-Logging von SAP (UILM) zu erhöhen.

UILM High-Level-Lösungsarchitektur (Beispiel: SAP GUI)

Quelle: SAP SE

Dieser Tabelle können Sie entnehmen, dass UI Masking und UI Logging in der SAP UI Layer arbeiten. Technisch gesehen hat jede UI-Technologie Besonderheiten, die wir bei dieser Lösung umsetzen müssen:

Anmerkung: Jede Lösung kann individuell oder gemeinsam installiert werden, je nach den Anforderungen in Ihrem Unternehmen.

SAP UI Maskierung: Es handelt sich um einen „starken“ Ansatz in der Datensicherheit. D.h. es wird eine technische Beschränkung bestimmter Daten auf bestimmte Nutzer eingerichtet, indem bestimmte Datenwerte teilweise oder vollständig maskiert werden.

SAP UI Logging: Es handelt sich um einen „weichen“ Ansatz zur Datensicherheit, der auf der Benutzeroberflächenebene bestimmt und dokumentiert, welche Daten ein Benutzer angefordert hat und auf welche er schließlich zugegriffen hat, und bietet Funktionen zur Analyse des Protokolls in der Tiefe oder durch Berichte.

Durch den Einsatz von SAP UI Datensicherheit können Sie den Zugriff auf eine ganze Ressource in Ihrem Unternehmen einschränken, wie z.B. auf alle Gehaltsabrechnungen, oder komplexere Regeln für eine bestimmte Ressource definieren. Die Datensicherheitslösung SAP UI wird am Service-Endpunkt durchgesetzt. Die sensiblen Informationen in Ihrem Unternehmen sind somit immer sicher und können nicht missbraucht werden.

Seien Sie gespannt auf den nächsten Teil dieser Blog-Serie, wenn wir den Use Case für jede dieser beiden Lösungen erkunden werden!

Lesen Sie hier Teil 2 zu UI Logging im SAP GUI für Windows!

Der Beitrag Eine Einführung in die SAP UI Datensicherheitslösungen (Teil 1/3) erschien zuerst auf Xiting.

]]>
EU-DSGVO: Auswirkung auf SAP-Systeme und eine Lösung durch die XAMS (Teil II) https://www.xiting.de/eu-dsgvo-auswirkung-auf-sap-systeme-und-eine-loesung-durch-die-xams/ Thu, 01 Aug 2019 09:55:24 +0000 https://www.xiting.ch/?p=3582 Die EU-DSGVO (engl. GDPR) ist die „Vorschrift zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien Verkehr solcher Daten“[1]. Diese Kernaussage sowie die Inhalte und Auswirkungen der Datenschutzgrundverordnung auf die Unternehmen habe ich Ihnen in meinem ersten Blog der Blogreihe „EU – DSGVO: Die wichtigsten Fakten im Überblick“ nähergebracht. Nun werde ich […]

Der Beitrag EU-DSGVO: Auswirkung auf SAP-Systeme und eine Lösung durch die XAMS (Teil II) erschien zuerst auf Xiting.

]]>
Die EU-DSGVO (engl. GDPR) ist die „Vorschrift zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien Verkehr solcher Daten“[1]. Diese Kernaussage sowie die Inhalte und Auswirkungen der Datenschutzgrundverordnung auf die Unternehmen habe ich Ihnen in meinem ersten Blog der Blogreihe „EU – DSGVO: Die wichtigsten Fakten im Überblick“ nähergebracht. Nun werde ich Ihnen die Herausforderungen im Kontext der SAP-Systeme und entsprechende Lösungsansätze aufzeigen. Dadurch bekommen Sie einen Einblick, wie Sie Ihre Berechtigungsstruktur in Zukunft GDPR-konform aufbereiten und die Compliance-Vorgaben mit unserer unternehmenseigenen Sicherheitssuite – der Xiting Authorizations Management Suite (kurz XAMS) – einarbeiten können.

Auswirkungen auf die SAP-Systeme

Besonders ERP-Systeme sind von diesen Neuerungen betroffen, da sie vornehmlich personenbezogene Daten halten. Auf welchen Systemen diese Daten gehalten bzw. auf welchen Kanälen sie verteilt werden, stellt die Unternehmen aufgrund ihrer komplexen IT-Strukturen vor eine Herausforderung. Bei regulierten und explizit berechtigten SAP-Systemen kann die Datenschutzgrundverordnung durch Audit-Logs und Berechtigungsprüfungen konsistent umgesetzt werden. Im Zuge des Alltagsgeschäfts werden diese Datensätze jedoch oft exportiert und über mehrere Systeme kommuniziert. Daher greifen dann nicht mehr die vorhandenen Berechtigungsstrukturen. Eine Nachweisbarkeit des Umganges mit den Daten kann somit nicht gewährleistet werden. Aus diesem Grund sind zum einem eine umfängliche Auditierung und zum anderen eine Protokollierung der personenbezogenen Datenverarbeitungen notwendig. Dadurch kann die Sammlung, Verarbeitung und Speicherung der Daten revisionskonform nachvollzogen werden. Gemäß diesem Anspruch ist es besonders wichtig, dass in solchen Systemen nicht nur statische Änderungen hinterlegt werden. Vielmehr müssen variable und aktuelle Anpassungen protokolliert werden. Zudem müssen Sie aufzeichnen, wer auf die Daten potenziell Zugriff hat und welche Anpassungen durch welche Person durchgeführt wurden.

Der Schutz von personenbezogenen sowie unternehmerischen Daten ist schon lange ein wichtiger Faktor bei der Entwicklung unserer Sicherheitssuite. Im Zuge einer Vielzahl von erfolgreichen Projekten bei namenhaften Kunden und Erfahrungen mit staatlichen Regularien konnten wir unser Sicherheitstool optimal auf das Thema Datenschutz abstimmen. Deshalb bietet die XAMS umfassende Lösungsansätze für Ihre Herausforderung bei der Bewältigung von SOD-Konflikten und der Einbindung der DSGVO.

XAMS – die Lösung

Vornehmlich spielen zwei Faktoren bei der Umsetzung der neuen Grundverordnung eine wesentliche Rolle. Das sind die Zugriffs- und Weitergabekontrolle. Demzufolge müssen Sie das vorherrschende Berechtigungskonzept so strukturieren, dass der Zugriff auf personenbezogene Daten möglichst minimal und mit einer zweckgebundenen Berechtigungsvergabe gestaltet wird. Außerdem müssen auch RFC-Schnittstellen entsprechend gesichert und protokolliert werden. Dadurch kann nachgewiesen werden, welche Verbindungsstelle eine Übermittlung von Personendaten vollzieht.

Einen nahtlosen Übergang Ihres alten Berechtigungskonzeptes in ein revisions- und DSGVO-konformes ermöglicht, schon vor der physischen Erstellung von Rollen auf Ihren Systemlandschaften, der Xiting Role Designer. Mit diesem Modul können Sie auf Basis von Nutzungsstatistiken einen virtuellen Rollenbau durchführen. Damit ist es möglich, DSGVO-konform zweckgebundene Berechtigungsrollen zu bauen. Zudem können Sie mit Hilfe dieses universellen Moduls auch die Deckungsgrade zur Vermeidung von bspw. Überberechtigungen berechnen lassen und zudem Ihr virtuelles Rollenkonstrukt schon vorab auf GDPR relevante und kritische Berechtigungen bzw. SODs prüfen. Zusätzlich kann auch ein vorhandenes GRC-Regelwerk an den Xiting Role Designer gekoppelt werden. Dadurch können Sie u.a. schon vorab stringent festlegen, welche Personen, in welchem Ausmaß Zugang zu bestimmten Daten haben.

Für eine vereinfachte Dokumentation Ihres vorhandenen Rollenkonzeptes bei etwaigen Prüfungen hilft Ihnen das Rollenkatalog-Tool. Dieses listet Ihnen eine detaillierte Übersicht Ihrer gesamten Rollen auf. Damit können Sie bei einer Revision per Excel-Download eine klare Struktur Ihrer Zugriffkontrollen vorweisen.

Falls Sie Ihr vorhandenes Berechtigungskonzept auf die Konformität hinsichtlich der DSGVO prüfen und bspw. auch sehen wollen, an welchen Stellen Handlungsbedarf besteht, können Sie auch den Xiting Role Profiler nutzen. Dieses umfassende Analysemodul beinhaltet neben Reports zur Analyse von kritischen Berechtigungen und SOD-Konflikten, auch Analyse- bzw. Lösungsansätze für den Bereich Datenschutz.

Mit diesem Modul können Sie Ihr vorhandenes Rollen- und Berechtigungsdesign mit Ihren und den Vorgaben der EU abstimmen. Dies ermöglicht Ihnen eine schnelle und umfassende Analyse, um konsequent die gesetzlichen Vorgaben mit Ihren vorhandenen Systemen zu verknüpfen. Unser Xiting Role Profiler hat jedoch noch einiges mehr zu bieten. Sie können mit ihm auch Ihre RFC-Sicherheit für eine Weitergabe- und Verarbeitungskontrolle prüfen. Dadurch kann das Gefahrenpotential gesenkt, die RFC-Schnittstellen vor nicht autorisierten Zugriffen geschützt und eine zweckgebundene Verarbeitung von personenbezogenen Daten dokumentiert werden. Durch eine Vielzahl an RFC-Service-Berichten können Sie Ihre RFC-Landschaften analysieren und produktive RFC-Schnittstellen bereinigen. Zudem können auf Basis der verschiedenen Reports technische Benutzer auditkonform berechtigt werden.

Dies rundet die Xiting-eigene produktive Testsimulation der XAMS-Module Xiting Times und Xiting Role Builder ab. Mit dieser Technologie können Sie eine zweckgebundene Berechtigungsvergabe analysieren und umsetzen.

Da besonders Eigenentwicklungen oft große Sicherheitslücken aufweisen, hat Xiting für Sie den ABAP Alchemist entwickelt. Mit diesem Codescanner bereinigen Sie u.a. fehlerhafte Berechtigungsprüfungen und können zugleich eine SU24-Optimierung durchführen.

Die auditkonforme Berechtigungsbereinigung bzw. -umsetzung rundet unser Security Architect ab. Mit diesem IKS-Modul können Sie nicht nur verschiedenste vorgefertigte Konzeptarten per Knopfdruck mit Inhalt und den Echtzeitdaten aus Ihrem System erstellen lassen. Des Weiteren gestattet er Ihnen bspw. die globalen Systemeinstellungen und Systemsicherheit ganzheitlich zu prüfen und Ihre gesamte Systemlandschaft dauerhaft zu analysieren.

Fazit

Durch die XAMS ergeben sich somit eine Vielzahl an Analyse- und Implementierungsmöglichkeiten sowie Lösungsansätze für Ihr Berechtigungskonzept gemäß den Anforderungen der EU-DSGVO. Mit Hilfe unserer Sicherheitssuite sind Sie bei der Überführung Ihrer IT-Struktur in eine datenschutzkonforme Systemlandschaft auf der sicheren Seite.

Wenn Sie eine praxisnahe Vorführung sehen wollen, können Sie sich auch für ein kostenloses Webinar auf unserer Homepage anmelden und sich selbst von den Vorzügen der XAMS überzeugen. Die Xiting AG bietet Ihnen zudem verschiedenste Services rund um das Thema SAP Security und GDPR an.

_________________________

[1] Vgl. Art. 1, EU-DSVGO.

Der Beitrag EU-DSGVO: Auswirkung auf SAP-Systeme und eine Lösung durch die XAMS (Teil II) erschien zuerst auf Xiting.

]]>
EU-DSGVO: Die wichtigsten Fakten im Überblick (Teil I) https://www.xiting.de/eu-dsgvo-die-wichtigsten-fakten-im-ueberblick/ Wed, 24 Jul 2019 14:30:49 +0000 https://www.xiting.ch/?p=3570 „Daten sind das neue Öl“ ist ein Zitat der EU-Politikerin Meglena Kuneva aus dem Jahr 2009, welches kurz und prägnant die Wichtigkeit der privaten und geschäftsbezogenen Daten in der heutigen multimedialen Zeit beschreibt. Dabei geht es den Unternehmen in erster Linie darum, personenbezogene Daten für die unternehmerischen Ziele und Strategien zu sammeln, zu speichern und […]

Der Beitrag EU-DSGVO: Die wichtigsten Fakten im Überblick (Teil I) erschien zuerst auf Xiting.

]]>
„Daten sind das neue Öl“ ist ein Zitat der EU-Politikerin Meglena Kuneva aus dem Jahr 2009, welches kurz und prägnant die Wichtigkeit der privaten und geschäftsbezogenen Daten in der heutigen multimedialen Zeit beschreibt. Dabei geht es den Unternehmen in erster Linie darum, personenbezogene Daten für die unternehmerischen Ziele und Strategien zu sammeln, zu speichern und zu verarbeiten. Dies ist auch der Grund, weshalb die EU am 25. Mai 2016 die DSGVO – Datenschutzgrundverordnung (engl. GDPR) – eingesetzt hat. Diese EU-weit geltende Richtlinie trat schließlich am 25. Mai 2018 in Kraft. Nur wen betrifft das tatsächlich und was sind die Kerninhalte dieser neuen gesetzlichen Regelung? In meiner zweiteiligen Blogreihe werde ich Ihnen dieses Thema näher bringen und zudem auf die Herausforderungen für SAP-Systeme und die damit einhergehenden Lösungen mithilfe unserer unternehmenseigenen Sicherheitssuite – der Xiting Authorizations Management Suite (kurz XAMS) – aufzeigen.

Im nachfolgenden Beitrag werde ich Ihnen zunächst einen Überblick über das Thema EU-DSGVO bzw. GDPR geben.

Inhalte der EU-DSGVO

Die Ziele der EU-DSGVO sind nicht nur der Schutz personenbezogener Daten[1], sondern auch der allgemeine Schutz der Grundrechte und Grundfreiheiten einer jeden natürlichen Person[2]. Dabei wird zukünftig besonders auch der Verkehr von personenbezogenen Daten reguliert[3]. Innerhalb Deutschlands gilt seit 1990 das BDSG[4]. Dieses Gesetz wurde zum Schutz der Verbraucher erlassen und regelt u.a. den Umgang von Daten mit Personenbezug in Deutschland. Die Inhalte des BDSG werden mit der DSGVO erweitert. Da es sich bei DSGVO um eine Verordnung handelt, bedarf sie keiner Umsetzung in die nationalen Gesetze, sondern gilt gleichermaßen für den gesamten europäischen Raum. Diese Tatsache hat auch Einfluss auf den Anwendungsbereich. Demzufolge sind nicht nur die EU-Länder betroffen, sondern auch Unternehmen, die in der EU tätig sind bzw. Daten von EU-Bürgern in irgendeiner Weise für ihr Geschäftsgebaren nutzen. Die Verordnung betrifft somit vor allem auch Länder, die bisher nur minimale Datenschutzanforderungen auferlegt bekamen. Hierbei kommt das Marktortprinzip zum Tragen. Alle Unternehmen, die Waren oder Dienstleistungen in der europäischen Union verarbeiten, sind davon betroffen. Es wird somit nicht der Sitz des Unternehmens beachtet, sondern aus welchem geografischen Raum die Daten bezogen werden. Für den Kreis der Betroffenen heißt das explizit:

  • Datensicherheit – Es muss ein angemessener Schutz der personenbezogenen Daten mit dem aktuellen Stand der Technik und Art und Weise garantiert werden. (Art. 2 DSGVO)
  • Pflicht der Einholung von Einwilligungen – Bevor personenbezogene Daten erhoben werden dürfen, muss vorher die jeweilige Person ihr Einverständnis dafür geben. (Art. 4 DSGVO)
  • Datenminimierung – Es dürfen nur die tatsächlich benötigten Daten gesammelt werden. (Art. 5 DSGVO)
  • Zweckbindung – Die Verarbeitung von Daten ist nur für den Zweck legitim, für den sie auch erhoben wurden. (Art. 5 DSGVO)
  • Datenrichtigkeit – Die erhobenen Daten müssen aktuell und sachlich richtig im Unternehmen gehalten werden. (Art. 5 DSGVO)
  • Rechenschaftspflicht – Datenverantwortliche der Unternehmen müssen bei Aufforderung der zuständigen Stelle die Einhaltung aller Datenschutzprinzipien laut DSGVO nachweisen können. (Art. 5 DSGVO)
  • Verbot mit Erlaubnisvorbehalt – Die Sammlung, Verarbeitung und Nutzung von Daten mit Personenbezug sind grundsätzlich ohne Einwilligung der betroffenen Person bzw. durch Gesetze verboten. (Art. 6 DSGVO)
  • Recht auf Löschung – Jede Person kann ihr Recht geltend machen, die Löschung ihrer eigenen persönlichen Daten bei dem jeweiligen Unternehmen zu verlangen. (Art. 17 DSGVO)
  • Recht auf Datenübertragbarkeit – Die Nutzer, deren Daten erhoben wurden, können einen Datentransfer ihrer Daten zu einer anderen Institution verlangen. (Art. 20 DSGVO)
  • Einsetzung eines Datenschutzbeauftragten – Ein Unternehmen muss nach Sichtung der Auflagen laut DSGVO gegebenenfalls einen unternehmensinternen Datenschutzbeauftragten einsetzen. (Art. 35 DSGVO)

Auswirkung auf die Unternehmen

Aus der Zusammenführung aller Regularien ist ersichtlich, dass die Unternehmen genau prüfen müssen, welche Daten, auf welchen ihrer Systeme betroffen sind. Es muss dementsprechend eine granulare Nachvollziehbarkeit und Nachweisbarkeit für die Prüfer gewährleistet werden. Werden die Vorgaben der DSGVO nicht eingehalten, können erhebliche Sanktionen drohen. So wurden in der Vergangenheit bei Verstößen gegen das BDSG Bußgelder in Höhe von 50.000 bis 300.000€[5] veranschlagt. Diese nahmen eine Vielzahl von Unternehmen billigend in Kauf. Nun sieht die Sachlage anders aus:

  • Ein Verstoß gegen die EU-DSGVO kann mit einem Bußgeld von bis zu 20 Mio. € bzw. 2% bis 4% des weltweiten Vorjahresumsatzes geahndet werden.
  • Gravierende Verstöße können sogar zu Freiheitsstrafen von bis zu 2 Jahren führen.

Fazit

Auf Basis dieses ersten Blogs zur Blogreihe „EU-DSGVO“ haben Sie nun einen gesamtheitlichen Überblick zu den Fakten und Auswirkungen, die mit dieser neuen Verordnung nun für jedes Unternehmen bindend sind. Es ist nicht nur ersichtlich, dass das Thema „Datensammlung, -speicherung und -verarbeitung“ einen ganz neuen Stellenwert in der Wirtschaft und Gesellschaft einnimmt, sondern bei unsachgemäßer Behandlung die Auswirkungen auf die Unternehmen tiefgreifend sein können. Nach der Akkumulation der wichtigsten Kerninhalte bleiben jedoch noch zwei wesentliche Fragen offen: „Welchen Einfluss hat diese Entwicklung auf die bestehenden SAP-Systeme und wie kann man sie lösen?“. Diese technische Transferleistung werde ich mit meinem zweiten Blog „EU-DSGVO: Auswirkung auf SAP-Systeme und eine Lösung durch die XAMS“ für Sie übernehmen, der in der kommenden Woche hier erscheinen wird.

Die Xiting AG bietet Ihnen verschiedenste Services rund um das Thema SAP Security und GDPR an. Vor allem unser unternehmenseigenes Sicherheitstool, die Xiting Authorizations Management Suite, kurz XAMS, ermöglicht Ihnen den Bau eines neuen Rollenkonzepts auf Basis Ihrer Nutzungsdaten bis hin zur Generierung eines revisionskonformen Sicherheitskonzeptes per Knopfdruck. Überzeugen Sie sich einfach selbst und schauen Sie bei einem unserer vielen verschiedenen Webinare vorbei.

_____________

Fußnoten:
[1] Def.: Es entsteht ein Personenbezug, wenn Information oder Daten einer Person in irgendeiner Weise zugeordnet werden können.
[2] Vgl. Art. 1 Abs. 2 DSGVO.
[3] Vgl. Art. 1 Abs. 3 DSGVO.
[4] Def.: Das Bundesdatenschutzgesetzt reguliert seit 1990 jeglichen Umgang mit Personen- und Geschäftsdaten durch Vorgaben für die Unternehmen zum Schutz der Grundrechte eines deutschen Staatsbürgers innerhalb Deutschlands.
[5] Vgl. §43 BDSG.

Der Beitrag EU-DSGVO: Die wichtigsten Fakten im Überblick (Teil I) erschien zuerst auf Xiting.

]]>
Möglichkeiten für ein SSO am SAP Fiori Client auf mobilen Geräten https://www.xiting.de/moeglichkeiten-fuer-ein-sso-am-sap-fiori-client-auf-mobilen-geraeten/ Thu, 18 Jul 2019 12:52:00 +0000 https://www.xiting.ch/?p=3555 Einleitung Mit der mobilen App SAP Fiori Client bietet SAP eine erweiterte mobile Laufzeitumgebung, für die heute über 1.000 SAP-Fiori-Anwendungen zur Verfügung stehen. Sehr oft findet beim Einsatz des SAP Fiori Client die Authentifizierung manuell mit Eingabe von SAP Benutzer und Kennwort statt, da hier eine vollautomatische Authentifizierung (Single Sign-On) nicht so einfach umsetzbar ist, […]

Der Beitrag Möglichkeiten für ein SSO am SAP Fiori Client auf mobilen Geräten erschien zuerst auf Xiting.

]]>
Einleitung

Mit der mobilen App SAP Fiori Client bietet SAP eine erweiterte mobile Laufzeitumgebung, für die heute über 1.000 SAP-Fiori-Anwendungen zur Verfügung stehen. Sehr oft findet beim Einsatz des SAP Fiori Client die Authentifizierung manuell mit Eingabe von SAP Benutzer und Kennwort statt, da hier eine vollautomatische Authentifizierung (Single Sign-On) nicht so einfach umsetzbar ist, wie beispielsweise beim Zugriff über den mobilen Browser. Mehr dazu aber später.

Im Gegensatz zu Cloud-Apps basieren Unternehmensanwendungen wie SAP Fiori auf Benutzern, die das Unternehmen meist selbst verwaltet. Hier zum Beispiel die SAP-Konten der Anwender auf den SAP Fiori Front-End- sowie Backend-Servern. Natürlich können die Zugangsdaten statisch durch den Benutzer in der App hinterlegt und sogar mit Biometrie geschützt werden. Fallen hier jedoch Passwortwechsel an, so kann das Arbeiten auf dem mobilen Gerät recht schnell mühselig werden. Oft wird auf dem Desktop bereits Single Sign-On genutzt (SAP Logon & Browser). Somit kennen Anwender häufig Ihr Kennwort gar nicht mehr.
 

Sicherer Betrieb der mobilen Infrastruktur

In den meisten Unternehmen gehört der Einsatz verschiedenster mobiler Geräte wie Smartphones und Tablets zum normalen Arbeitsalltag. Genauso normal sollte dabei der sichere Betrieb, die zentrale Verwaltung der Geräte- und Sicherheitsrichtlinien sowie App-Deployments und der damit verbundene Einsatz zusätzlicher Infrastrukturkomponenten sein. Spätestens ab einer bestimmten Unternehmensgröße bzw. einem entsprechend hohen Nutzungsgrad mobiler Anwendungen wird dies unverzichtbar.

Mobile Device Management (MDM)-Infrastrukturen stellen oft auch Möglichkeiten für ein Single Sign-On bereit, sei es direkt vom Gerät oder delegiert über ein zentrales SSO-Gateway. Darüber kann zum Beispiel eine gesicherte Sandbox-Umgebung auf die mobilen Geräte gebracht werden. Diese ermöglicht den Zugriffsschutz mittels einer durch den Benutzer vergebenen PIN und gleichzeitig eine Anmeldung an einem SAML Identity Provider. Ein Unternehmen kann damit seine geschäftlichen Anwendungen innerhalb dieser Sandbox isoliert vom restlichen Gerät betreiben und Anwendungszugriffe mittels Micro-VPNs gezielt steuern. Schnittstellen an eine Corporate-PKI ermöglichen die Bereitstellung von personalisierten Client-Authentication-Zertifikaten auf den Geräten.

iOS gilt dabei als das sicherste mobile Betriebssystem der Welt. Im Umfeld SAP-Security habe ich die Erfahrung gemacht, dass iOS den besten Support genießt. Das iOS-Gerät ist als Einzelbenutzergerät konzipiert. Bei anderen mobilen Betriebssystemen – wie Android – wird Multi-User-Support und Benutzerwechsel schon lange unterstützt. Generell werden mobile Geräte meist nah am Anwender getragen bzw. verwendet und sperren sich bei korrekter Sicherheitskonfiguration zügig. Aufgrund der unterschiedlichen Architekturen und auf Basis eventuell bereits vorhandener Lösungen sowie eingesetzter Apps, sollte sehr differenziert unterschieden werden, welches Verfahren für SSO im Unternehmen bestenfalls zum Einsatz kommen kann.

Möglichst sicher, jedoch auch komfortabel sollte es sein. Denn nichts ist schlimmer, als andauernd wieder seine Zugangsdaten manuell eintippen zu müssen. In dieser Hinsicht unterscheidet sich das mobile Gerät deutlich vom klassischen Desktop. Es findet hier ja keine Anmeldung am Active Directory statt. Man startet bzw. entsperrt mobile Geräte meist mit biometrischen Verfahren sowie einer Kombination aus verschiedenen Codes bzw. Wischgesten.

Dank der Biometrie kann – im Vergleich zur PIN – der tatsächliche Anwender am Gerät erkannt werden; die Geräte wurden personalisierbar und intelligenter. Es macht also Sinn, die biometrischen Verfahren als einen Faktor im Authentifizierungsprozess zu berücksichtigen.  

MDM, Sandboxing, Micro-VPNs, SSO-Gateway, SDKs, Entwickler. Das alles ist in kleineren Unternehmen nicht unbedingt immer vorhanden. Dennoch können auch hier mit überschaubarem technischem und organisatorischem Aufwand unterschiedliche SSO-Szenarien auf den vorhandenen mobilen Geräten eingesetzt werden. Einige davon möchte ich in diesem Blog vorstellen; dies mit Fokus auf den SAP Fiori Client.

Sie werden erfahren, wie man mit SAP Single Sign-On 3.0 die SAML-Integration des SAP Fiori Client realisiert und darüber die OTP-basierte Authentifizierung mithilfe des SAP IdP und der SAP Authenticator-App ermöglicht. Zudem möchte ich auch über eine recht neue Möglichkeit der zertifikatsbasierten Anmeldung – direkt aus der Fiori-App heraus – informieren.
 

SSO-Verfahren im mobilen Umfeld

Authentifizierung an einer nativen Mobilanwendung ist eine große Herausforderung, da es keinen definierten Standard gibt, an den sich Entwickler halten müssen. Da stellt sich zunächst die Frage, welche SSO-Verfahren werden im mobilen Umfeld verwendet. Die kurze Antwort lautet: eine ganze Menge!

Cloud-Apps wie Instagram, Deezer, YouTube, Facebook und Konsorten nutzen meist das OAuth-Verfahren. Dabei verwaltet der Anbieter den Account (nicht das eigene Unternehmen) und daher greifen auch andere Passwortrichtlinien bzw. Wechselanforderungen. Zudem wird hier der Anmeldeprozess, meist gegen einen Authorization-Server/IdP in der Cloud, in der Regel einmalig beim Start der App durchgeführt. Anschließend sorgen OAuth Access- und Refresh Tokens transparent und automatisiert für alles weitere. OAuth 2.0 hat sich als standardisiertes Protokoll herauskristallisiert, um genau diese stark vereinfachte Authentifizierung (und Autorisierung) von nativen mobilen Anwendungen (Apps) zu ermöglichen. Die Idee besteht darin, jede Anwendung einzeln zu behandeln. Sie wird einzeln autorisiert und empfängt Ihre OAuth-Tokens, welche für nachfolgende API-Aufrufe notwendig sind.

Wird die Anwendung innerhalb der Lebensdauer des Refresh Token regelmäßig genutzt und steht somit in Kontakt mit dem Server, erhalten die Anwender laufend aktuelle Zugangstoken. Der Anbieter kann mit OAuth (ähnlich wie mit SAML) zudem ein Single Log-out unterstützen, z. B. wenn das mobile Gerät gestohlen wurde und der Account bewusst deaktiviert wurde.

Unter anderem auch die SAP Cloud Platform unterstützt das OAuth 2.0-Protokoll als Methode zum Schutz von Anwendungsressourcen.

Auch der Einsatz von Kerberos auf mobilen Geräten ist technisch machbar und wird zum Beispiel auf iOS-Geräten direkt unterstützt. Der Anwenderkomfort ist ohne weitere Komponenten aber eher gering. Das liegt daran, dass am Gerät ja mangels einer AD-Anmeldung keine Credentials vorliegen und somit die erste Authentifizierung mit AD Benutzername und Kennwort manuell am Gerät erfolgen müsste. Dabei werden dann TGT und STs bezogen. Das ist manchmal schon zu viel des Guten für den normalen Anwender. Angenehmer wird es erst mit Lösungen wie von MobileIron oder Citrix XenMobile, nur um einmal zwei Beispiele zu nennen. Solche Anbieter bringen spezielle sicherere Browser oder E-Mail Clients mit sich. Mit diesen können Unternehmensressourcen sicher angebunden und der Datenverkehr kann über VPNs getunnelt werden. Zudem muss sich der Anwender nur einmal beim Start der App anmelden und hat anschließend transparenten Zugriff auf interne Webanwendungen.

Android Enterprise kann mit Lösungen wie Hypergate um diesen Support erweitert werden. Somit könnte SSO für alle bestehenden Webanwendungen eines Unternehmens, wie vom Desktop gewohnt, über den mobilen Browser eingesetzt werden. Selbst native Apps können mit bestimmten Libraries und SDKs integriert werden. Auch der mobile Browser Microsoft Edge für iOS und Android unterstützt ein SSO für SaaS oder on-premise Anwendungen, sofern das Gerät in Azure AD registriert wurde.

OAuth / OpenID, Kerberos, SAML, X.509 Zertifikate sowie SSO-Gateways, MFA, PINs, Biometrie und Kennwörter… die Möglichkeiten sich mit mobilen Geräten an Unternehmens- bzw. Cloudanwendungen zu authentifizieren sind vielfältig und die Technologie dahinter ist oft komplex.
 

SAP Authenticator | SSO Authentication Library | SAP Identity Provider

Die SAP Authenticator-App ist für die Plattformen iOS, Android und Windows verfügbar. Er generiert nach Registrierung mit der SAP zugehörigen Backend-Komponente zeitbasierte Einmalpasswörter. Diese können, wie zum Beispiel vom Google Authenticator bekannt, als Passwortersatz oder zweiter Faktor genutzt werden. Basierend auf einem gemeinsamen Geheimnis und aktueller Systemzeit, wird alle 30 Sekunden ein 8-stelliger nummerischer Code generiert. Somit müssen Anwender Ihre regulären (statischen) Anmeldeinformationen nicht preisgeben. Folglich ist darüber die sichere Authentifizierung an kritischen on-premise Anwendungen bzw. der Zugriff auf exponierte Anwendungen möglich.

Neben diesem Einsatzszenario bietet der SAP Authenticator auch die Möglichkeit eines zentralen Einstiegspunktes für den mobilen Zugriff auf weitere SAP-Unternehmensanwendungen wie u. a. SAP Fiori Client. Mittels der zentralen OTP-Administrationskonsole können entsprechende Anwendungsprofile erstellt und automatisiert an alle mobilen Anwender bereitgestellt werden. Diese Profile enthalten angepasste Anwendungs-URLs und starten entweder native Apps, wie z. B. den SAP Fiori Client, oder öffnen eine festgelegte URL im Browser auf dem mobilen Gerät. Gleichzeitig wird das Einmalpasswort als Parameter zur Authentifizierung mitgegeben. Es ist zudem möglich, das Einmalpasswort als einzigen Faktor zur Anmeldung zu verwenden, worüber letztlich dann ein komfortables Single Sign-On ermöglicht wird. Der Start der SAP Authenticator-App selbst kann dabei mit einem PIN bzw. Kennwort geschützt werden.

Da dieses Szenario auf Einmalpassworten und SAML 2.0 sowie ausschließlich SAP-Komponenten basiert, benötigt man dafür auch zwingend den SAP Identity Provider. Technisch gesehen erfolgt die Authentifizierung am Identity Provider mit Einmalpassworten und die darauffolgende Authentifizierung am SAP Fiori Front-End Server mittels SAML 2.0. Für den SAML-Flow sorgen die in den Tools integrierten Browser-Engines.

Security Assertion Markup Language (SAML) ist ein dynamisches Token Modell und arbeitet auf der Grundlage von Behauptungen (sog. Assertions). Die zentrale Instanz, ein Identity Provider (IdP) belegt, dass sich ein Subjekt (User) erfolgreich ausgewiesen hat und eine Assertion bietet Platz für viele weitere Attribute, die von vertrauenden Systemen (sog. Service Provider) ausgewertet und zur Authentifizierung aber auch zum Zwecke der Federation genutzt werden können.
 

Funktionsweise

Mit dem Einsatz der zuvor genannten Komponenten aus der Lösungssuite SAP Single Sign-On 3.0 können die vom SAP Authenticator generierten Einmalpassworte zur Anmeldung am SAP IdP verwendet werden. Nur mit Deployment der SSO Authentication Library wird der SAP IdP um das TOTPLoginModule erweitert. Dabei basiert die eingesetzte OTP-Technik auf dem von der IETF im RFC6238 spezifizierten TOTP-Algorithmus.

Der SAP-Authenticator generiert ein neues Einmalpasswort und sendet es zusammen mit dem Benutzernamen an die im Profil hinterlegte Anwendung, welche die Parameter in der vorkonfigurierten SAP Fiori Client-URL verwendet. Der SAP Fiori Client generiert daraufhin eine Authentifizierungsanforderung an den SAP Identity Provider, was ein sogenanntes „Identity Provider initiated SSO“ auslöst. Der Identity Provider überprüft die Anmeldeinformationen und wenn die Prüfung erfolgreich ist, erstellt er in der SAML AuthnResponse eine Assertion für diesen Benutzer. Der SAP Fiori Client (oder Browser) wird geöffnet und der Benutzer ist automatisch und sicher angemeldet; ein entsprechend für SAML 2.0 konfigurierter SAP Fiori Front-End Server vorausgesetzt. Dieses Szenario eignet sich auch hervorragend für den externen Zugriff auf SAP Webanwendungen, die zum Beispiel durch einen SAP Web Dispatcher veröffentlicht wurden.


An dieser Stelle sei nochmals angemerkt, dass für dieses Szenario keine vorhandenen Identity Provider wie Microsoft ADFS/Azure, BIG-IP, Open AM, Shibboleth und andere eingesetzt werden können.

 

Anwender-Zertifikate auf mobilen Geräten

Für Zugriffe auf SAP-Webanwendungen von mobilen Geräten aus, empfiehlt sich in der Regel der Einsatz von X.509 Zertifikaten. Durch Integration der MDM-Lösung in eine vorhandene PKI, lassen sich mittels SCEP automatisiert Anwender-Zertifikate auf die Geräte verteilen. Abgesehen von speziellen Sandboxing Umgebungen, speziellen Browsern oder herstellerspezifischer Eigenentwicklungen, steht dieses Zertifikat (inkl. des zugrundeliegenden privaten Schüssels) zum Beispiel in der iOS System key-chain zur Verfügung. Damit können die Apple eigenen bzw. systemnahen Anwendungen wie Mail oder Safari auf dieses Zertifikat zugreifen. Das Zertifikat könnte somit bei einem direkten Zugriff auf entsprechend konfigurierte Web Dispatcher / SAP Backends wie gewohnt zur Authentifizierung eingesetzt werden. Einem Single Sign-On am Portal oder dem zentralen SAP Fiori Launchpad über den Safari Browser steht somit nichts im Wege.

Apps wie der SAP Fiori Client und andere, können aufgrund des im iOS verwendeten Sandboxing-Prinzips nicht auf die Zertifikate und Schlüssel des Systemschlüsselbundes zugreifen. Hier braucht es dann wieder SDKs bzw. Custom-App-Deployments, die in Verbindung mit dem SAP Mobile Platform Server bzw. der SAP Cloud Lösung zusätzliche Optionen für eine automatische Authentifizierung bereitstellen.

Ab Version 1.12.2 des SAP Fiori Client kann nun aber auch die System-Keychain eines iOS Geräts verwendet werden. Technisch wird der Zugriff auf vorhandene Anwender-Zertifikate und Schlüssel über den SFSafariWebView Controller realisiert. Ergebnis ist die Nutzung der auf dem Gerät befindlichen Zertifikate analog zur Möglichkeit wie dies bisher im Safari machbar war. Sofern sich bereits Zertifikate auf dem iOS Gerät befinden, stellt dieses Feature eine einfache Möglichkeit für eine automatische Authentifizierung am SAP Fiori Client zur Verfügung.


In diesem Szenario wird weder die SAP Mobile Platform Lösung noch der SAP Identity Provider oder SAP Authenticator benötigt.

Eine Auflistung unterstützter mobiler Geräte- und Betriebssysteme ist dem SAP Hinweis 2253818 zu entnehmen. Hilfreiche Informationen rund um den SAP Fiori Client sowie weitere unterstütze Single Sign-On Szenarien, zum Beispiel in Verbindung mit der SAP Mobile Platform, finden Sie hier und hier.

Xiting hat bereits mehrere Unternehmen bei der erfolgreichen Umsetzung einer SSO-Lösung für den SAP Fiori Client unterstützt.

Gerne unterstützen wir Sie in Ihrem Projekt!

Der Beitrag Möglichkeiten für ein SSO am SAP Fiori Client auf mobilen Geräten erschien zuerst auf Xiting.

]]>