Einrichtung SNC für SAP auf Windows 

Teil 1 Voraussetzungen und Hinweise

Kerberos Single Sign-On (SSO) bietet eine einfache und sichere Anmeldemethodik für ein SAP System. Sie eignet sich, wenn Windows 2000 oder höher verwendet wird.

Sofern das System für SSO konfiguriert ist, kann ein berechtigter Benutzer, der an Windows angemeldet ist, auf das SAP-System zugreifen, indem er es einfach im SAP-Logon-Fenster auswählt oder eine Verknüpfung verwendet. Der Benutzer braucht nicht bei jeder Anmeldung am SAP-System über SAP GUI für Windows eine Benutzerkennung und ein Kennwort einzugeben. Daher erleichtert SSO die Verwaltung der SAP-Systembenutzer.

Der Microsoft Kerberos Security Service Provider (SSP) bietet sichere Authentifizierung plus Verschlüsselung der Netzwerkkommunikation.

Folgende Hinweise und Dokumentationen sind zu beachten. Wie das ganze eingerichtet und konfiguriert wird, werde ich in meinem nächsten Beitrag zusammenstellen.

SAP Hinweise

352295 – Microsoft Windows Single-Sign-On-Optionen

1257108 - Sammelhinweis: Analyse von Single Sign On (SSO)-Problemen

595341 – Installation issues with Single Sign-On and SNC

1043694 – Schl. Performance bei Verwendung von SNC für SSO

184277 – Längenbeschränkungen von SNC-Namen

150699 – Neueste Patches für SNC-Probleme

1153116 – Work Center: SAP SSO überschreiben

SAP Installationsguides

SAPNW700 InstallGuide mit SNC SSO Kapitel

SAP Online Help

http://help.sap.com/saphelp_nw73/helpdata/DE/44/0ebf6c9b2b0d1ae10000000a114a6b/frameset.htm

Weitere Infos, Whitepaper von Microsoft

http://www.microsoft.com/isv/sap/technology/interop/ad.aspx

Verfahren / Tool zum Rücksetzen von SAP Benutzer Passwörtern

http://download.microsoft.com/download/5/7/f/57f1490e-8a8d-497b-bbae-ec2a44b3799f/Password_Reset.pdf

The post Single Sign On für SAP GUI appeared first on rz10.de - das SAP Basis- und Security Blog.

Über das Berechtigungsobjekt S_DEVELOP kann man Debugging-Berechtigung im SAP erteilen. Diese Berechtigung erlaubt es über die Eingabe von “/h” im OK-Feld der Gui den Debug-Modus zu aktivieren.

Während diese Funktion auf dem Entwicklungssystem ohne Frage zu den notwendigen Entwicklungsfunktionalitäten dazugehört ist es auf einem Produktions- oder Konsolidierungssystem höchst kritisch. Denn es erlaubt dem Anwender den normalen Programmablauf zu beeinflussen und Werte während des Programmlaufs zu ändern.

So kann ein Anwender ein Programm starten und z.B. einen AUTHORITY-CHECK überspringen. Damit erlangt er Zugang zu Daten oder kann Änderungen vornehmen, die im normalen Programmfluss nicht vorgesehen sind.

Ein prominentes Beispiel ist auch über den Debug-Modus das sapedit in der SE16 bzw. SE16N wieder zu aktivieren – dann kann man direkt in der Tabellenansicht Änderungen in der Datenbank durchgeführen. Diese Möglichkeit Felder zu ändern gefährdet den Grundsatz “Keine Änderung ohne Beleg”.

Wie kann man nun S_DEVELOP einschränken?

Zuerst muss man die Rollen identifizieren, die S_DEVELOP mit DEBUG Aktivität 02 enthalten. Dies kann man über die SUIM -> Rollen nach komplexen Selektionskriterien durchgeführt werden. Wenn man den Debug-Modus komplett deaktiveren will, muss man auch nach Aktivität 03 suchen.

Im Rolleneditor in der PFCG kann man nun die entsprechende Rolle einschränken.

Im Hinweis 65968 – ABAP-Debugging-Berechtigungen werden die möglichen Werten für S_DEVELOP dokumentiert:

The post SAP Debug Berechtigung einschränken appeared first on rz10.de - das SAP Basis- und Security Blog.

Wer als Berechtigungsadministrator mehr oder weniger täglich mit wenig aussagekräftige Screenshots der SAP SU53 (Transaktion Berechtigungsdaten von Benutzer xy anzeigen) arbeiten muss, kann sich auf eine deutliche Verbesserung freuen.

Die SAP beschreibt im Hinweis 1671117 – SU53: erweiterte Funktionalität und WebDynpro-Eignung die neuen Funktionen der SU53. Ab einem im Hinweis genannten Support Package Stand der SAP_BASIS Komponente inklusive einem aktuellen Kernel kann die SU53 nicht mehr nur die letzte Berechtigungsprüfung, sondern sogar bis zu 100 Berechtigungsprüfungen pro Benutzer in chronologischer Reihenfolge aufführen. Das dürfte den Berechtigungs-Trace zur genauen Ursachenanalyse in Zukunft deutlich seltener erforderlich machen.

In diesem Zusammenhang lohnt sich auch noch mal ein genauer Blick auf den Hinweis 1718059 – Neue Funktionen in der Traceauswertung – denn das von mir gern genutzte Programm ZSHOWAUTHTRACE von Frank Buchholz hat mit SAP_BASIS 7.03 als Standardtransaktion STAUTHTRACE Einzug gehalten. Und dieses Programm ist ein deutlich besser zu bedienener und verwendbarer Trace als die Auswertung über die Standardtransaktion ST01 (Systemtrace). Ganz zu schweigen von Schmankerln wie “Pflege der SU24 auf Grundlage eines Traces”.

Ein Tipp noch am Schluss: wer den Umgang mit der SU53 vereinfachen will, der sollte seine Benutzer auffordern, die SU53 grundsätzlich in einen Spoolauftrag zu drucken und die Spool-Nummer zu melden. Der Spoolauftrag kann von dem Administrator eingesehen werden und enthält alle, auch die im Screenshot nur als zugeklappte Komponenten zu sehenden Elemente. Und das in einer Variante die Copy&Paste zulässt.

Was halten Sie von den Neuerungen der SU53? Haben Sie noch Tipps im Umgang mit der Analyse von fehlgeschlagenen Berechtigungsprüfungen? Ich freue mich auf Ihr Feedback.

The post Neue Funktionen in der SAP SU53 und im SAP Berechtigungs-Trace appeared first on rz10.de - das SAP Basis- und Security Blog.

Die Konfiguration und Aktivierung des SAP Security Audit Log ist immer dann sinnvoll, wenn Benutzer mit weitreichenden Berechtigungen überwacht werden müssen. Nationale und internationale rechtliche Vorgaben sowie interne Sicherheitsrichtlinien machen eine solche Überwachung häufig erforderlich. In dem folgenden Blog-Beitrag werde ich Ihnen Schritt für Schritt erläutern, wie sich das SAP Standardwerkzeug, das Security Audit Log konfigurieren und aktivieren lässt.

Einrichtung der erforderlichen Profilparameter

Transaktion: RZ10

Schritt 1: Zunächst müssen verschiedene Profilparameter (siehe Tabelle 1) über die Transaktion RZ10 gepflegt werden. Wählen Sie dazu das Profil aus, in welchem Sie die Parameter für das Security Audit Log pflegen möchten. Selektieren Sie anschließend die Option “Erweiterte Pflege” und klicken Sie dann auf die Schaltfläche “Ändern”.

Abbildung 1: Bearbeitung der Profilparameter in der Transaktion RZ10

In der nachfolgenden Tabelle werden die für den Einsatz des SAP Security Audit Log empfohlenen Profilparameter vorgestellt. Selbstverständlich ist es zwingend erforderlich, dass der Parameter “rsau/enable” auf den Wert 1 eingestellt ist. Nur damit wird das SAP Security Audit Log nach einem Neustart der SAP-Instanz aktiviert.

Sollten sich die in der Tabelle genannten Parameter noch nicht in der Profilparameterliste befinden, dann fügen Sie diese über die “Parameter”-Schaltfläche (anlegen) in die Liste ein. Je nach Anforderung und Anzahl der zu überwachenden Benutzer ist möglicherweise eine Anpassung der genannten Empfehlungswerte erforderlich.

Abbildung 2: Anzeige der geänderten Profilparameter

Einrichtung der Filterkriterien

Transaktion: SM19

Schritt 2: Bevor das SAP Security Audit Log nun einsatzbereit ist, müssen Sie noch die gewünschten Filterkriterien einrichten und die entsprechenden Filter aktivieren. Sowohl bei den Audit-Klassen als auch bei den zu überwachenden Ereignissen haben Sie die freie Wahl, wie weit die Aktivitäten des Benutzers im SAP System überwacht werden sollen.

Abbildung 3: Einrichtung der Filterkriterien

Sollten Sie den Profilparameter “rsau/user_selection” auf den Wert “1″ gesetzt haben, dann haben Sie die Möglichkeit Wildcards (“*”) in dem Benutzername-Textfeld zu verwenden. Wie in dem unten dargestellten Screenshot ist so möglich, über einen Filter mit dem Benutzernamen “BENUTZER_*” sowohl den BENUTZER_A als auch den BENUTZER_B zu überwachen.

Abbildung 4: Einrichtung der Filterkriterien mit Wildcards

Nachdem Sie auf die Schaltfläche “Speichern” geklickt haben, fragt das System Sie, ob die eingerichteten Filter-Konfigurationen auf alle Server verteilt werden sollen. Bestätigen Sie diese Meldung mit “Ja”, wenn auf allen Servern die gleiche Konfiguration verwendet werden soll.

Abbildung 5: Sicherheitsabfrage zur Verteilung der Filterkonfiguration

Zuletzt ist es ggf. noch erforderlich, über die im unten dargestellten Screenshot markierte Schaltfläche das SAP Security Audit Log zu aktivieren.

Abbildung 6: Aktivierung des SAP Security Audit Log

Auswertung der Log-Dateien

Transaktion: SM20

Schritt 3: Nachdem Sie nun die oben beschriebenen Schritte durchgeführt haben ist das SAP Security Audit Log einsatzbereit. Entsprechend den von Ihnen konfigurierten Filterkriterien werden die Benutzer wie gewünscht überwacht. Möchten Sie nun die Log-Daten auswerten, rufen Sie die Transaktion SM20 aus. Dort haben Sie die Möglichkeit eine zeitliche Eingrenzung der Auswertung vorzunehmen. Des Weiteren können die Ergebnisse nach verschiedenen weiteren Kriterien gefiltert werden. Wenn Sie die gewünschten Einstellungen für die Auswertung vorgenommen haben, können Sie das AuditLog über die Schaltfläche “AuditLog neu lesen” auslesen.

Abbildung 7: Eingrenzung der Log-Daten in der SM20

Anschließend werden Ihnen die Log-Daten detailliert dargestellt.

Abbildung 8: Ergebnis der Log-Auswertung

Bitte zögern Sie nicht Fragen und Feedback in den Kommentarbereich zu schreiben.

The post Aktivierung und Konfiguration des SAP Security Audit Log appeared first on rz10.de - das SAP Basis- und Security Blog.

Benutzer werden in SAP-Systemen über den Benutzernamen sowie das zugehörige Kennwort authentisiert. Dabei gibt es zahlreiche Parameter, mit denen Sie die Sicherheit Ihrer SAP-Systeme maßgeblich beeinflussen können.

Als verantwortlicher Mitarbeiter der SAP-Basis kennen Sie bestimmt folgende Situationen:

• Eine interne Revisionsabteilung teilt Ihnen mit, dass auf Grund eines Sicherheitsvorfalls die Kennwortrichtlinien für SAP-Systeme in Ihrem Unternehmen geändert werden sollen.
• Ein externer Wirtschaftsprüfer hat Ihre SAP-Systeme überprüft und dabei auch Abweichungen zu gesetzlichen Anforderungen festgestellt. Sie haben nun einen Katalog mit den Prüfergebnissen übergeben bekommen und sollen nun die Anforderungen umsetzen.
• Der Gesetzgeber bzw. die Unternehmensleitung beschließen strengere Anforderungen an die Datensicherheit und den Datenschutz und beauftragen Sie mit der Umsetzung eben dieser.

Trifft eine der oben genannten Situationen auf Sie zu? Oder beschäftigen Sie sich aus einem anderen Grund gerade mit der Kennwortrichtlinie in Ihrem Unternehmen? In jedem Fall finden Sie unten eine Auswahl der wichtigsten Parameter, welche im Zusammenhang mit der Umsetzung von Kennwortrichtlinien eine Rolle spielen. Zu jedem Parameter finden Sie einen Beschreibungstext sowie eine von mir empfohlene Einstellung. Selbstverständlich ist diese Empfehlung nur als Vorschlag zu werten. Auch, wenn die genannten Parameter aus technischer Sicht nicht zwingend angepasst werden müssen, kann es unter Umständen gefährlich sein, die Standardeinstellungen nicht zu ändern.

Einrichtung der erforderlichen Profilparameter

Transaktion: RZ10

Diese unten dargestellten Profilparameter pflegen Sie über die Transaktion RZ10. Wählen Sie dazu das Profil aus, in welchem Sie die Parameter pflegen möchten. Selektieren Sie anschließend die Option “Erweiterte Pflege” und klicken Sie dann auf die Schaltfläche “Ändern”.

Abbildung 1: Bearbeitung der Profilparameter in der Transaktion RZ10

Profilparameter zur Umsetzung von Kennwortrichtlinien

Die nachfolgend dargestellten Profilparameter sind in drei Kategorien aufgeteilt:

Kennwörter. In diesem Bereich finden Sie Profilparameter, welche den Aufbau und die Gültigkeit von Kennwörtern steuern.

Sperren. In dem Bereich “Sperren” legen Sie fest, wie das SAP-System mit fehlerhaften Anmeldeversuchen umgehen soll.

Anmeldungen. Hier können Sie steuern, ob das System eine Anmeldung mit dem SAP*-Benutzer auch ohne bestehenden SAP*-Benutzerstammsatz möglich ist. Des Weiteren finden Sie hier die Parameter, welche zur Steuerung von Sitzungen verwendet werden können.

Bitte beachten Sie, dass jegliche Änderungen der Profilparameter stets einen Neustart der Instanz erfordern, bevor die geänderten Einstellungen aktiv sind.

Kennwörter

Update vom 24.05.2013: Um die Gültigkeit von Initialkennwörtern zu beschränken, ist im SAP-System der Parameter login/password_max_new_valid vorgesehen. An dieser Stelle danke ich dem Kommentator Bernd für den Hinweis, dass dieser Parameter dazu führen kann, dass auch Anmeldeversuche von RFC-Benutzern verhindert werden. Die Ursache dafür ist, dass in den Releases 4.6B, 4.6C, 4.6D, 6.10 und 6.20 kein Datumsstempel für eine Kennwörtänderung gesetzt wird (siehe auch Hinweis 450452). Ein Lösungsweg wäre dann lediglich das Löschen und die Neuanlage des Benutzers. Seit dem Release 6.40 ist dieser Fehler jedoch behoben.

Sperren

Anmeldungen

Ich freue mich, wenn Sie diesen Beitrag in den Kommentaren diskutieren, ergänzen oder korrigieren.

The post Profilparameter zur Umsetzung von Kennwortrichtlinien in SAP-Systemen appeared first on rz10.de - das SAP Basis- und Security Blog.

Auch wenn es keine eine Patentlösung für jede Art von Security Mangel gibt, so gibt es doch eine in der täglichen SAP Berechtigungspraxis bewährte Vorgehensweise um Revisionsfeststellungen und Compliance Mängel zu beheben. Es gilt die Antwort auf die Frage “Wie esse ich einen Elefanten?”. Sie lautet: “Stück für Stück.”

Executive Summary

• Revisionsfeststellungen und Compliance Mängel im SAP sind aufgrund der Komplexität nicht einfach lösbar.
• Die richtige Vorgehensweise ermöglicht das zielgerichtete Abarbeiten von Mängeln.
• Enge Absprachen zwischen den beteiligten Parteien an den richtigen Zeitpunkten helfen Mammut-Projekte zu vermeiden.

Lesen Sie in meinem Whitepaper wie Sie effektiv mit Revisionsfeststellungen und Compliance Mängeln in SAP umgehen können und nachweisbar die Compliance in Ihrem SAP System verbessern können.

The post Whitepaper Umgang mit Revisionsfeststellungen und Compliance Mängeln appeared first on rz10.de - das SAP Basis- und Security Blog.

Mit diesem HowTo möchte ich Ihnen aufzeigen, wie kritisch die Vergabe der Berechtigungen zum Aufruf der Transaktionen SA38 und SE38 in einem produktiven SAP-System unter Umständen sein kann. Anwender sollten in produktiven SAP-Systemen nicht die Berechtigung haben Programme über die SA38 bzw. die SE38 auszuführen, da hier nur schwer einzuschränken ist, welche unter Umständen auch sicherheitskritischen Programme aufgerufen werden können. In der Praxis kommt es jedoch häufig vor, dass für bestimmte Anwendungsfälle die Berechtigung zum Start der SA38 bzw. der SE38 an Benutzer vergeben wird.

Die erforderlichen Berechtigungsobjekte zum Aufruf der Transaktion SA38 sind in der unten dargestellten Grafik abgebildet. Die beiden Berechtigungsobjekte S_TCODE und S_PROGRAM werden bei Aufruf der Transaktion geprüft. Bei dem Berechtigungsobjekt S_PROGRAM wird allerdings nur das Feld P_ACTION auf den Feldwert SUBMIT (Ausführen ABAP Programm) geprüft. Das Feld P_GROUP wird an dieser Stelle noch nicht geprüft. Dieses Feld dient zur Einschränkung der Programmausführungsberechtigung auf die in der Tabelle TPGP angelegten Berechtigungsgruppen.

Abbildung 1: Erforderliche Berechtigungen zum Aufruf der Transaktion SA38

Risiko 1: Fehlende Berechtigungsgruppen bei Programmen

Ruft der Benutzer nun die Transaktion SA38 auf, kann er grundsätzlich, wie in Abbildung 2 dargestellt, den Namen jedes beliebigen Programms in das Feld “Programm” eintragen. Ruft der Benutzer nun ein Programm auf, prüft das SAP-System, ob eine Berechtigungsgruppe in den Eigenschaften des Programms festgelegt wurde. Ist dies der Fall, dann wird über das Feld P_GROUP des Berechtigungsobjekts S_PROGRAM geprüft, ob der Benutzer die entsprechende Berechtigungsgruppe aufrufen darf. Sicherheitskritisch ist jedoch die Tatsache, dass der Benutzer unabhängig von den in seinen Berechtigungen definierten erlaubten Berechtigungsgruppen sämtliche Programme ausführen kann, die keine definierte Berechtigungsgruppe haben. Wenn wir die in Abbildung 1 dargestellte Beispielrolle an einen Benutzer vergeben, dann könnte dieser den Report RK_SE16N aufrufen, welcher sich hinter der Transaktion SE16N verbirgt.

Abbildung 2: SA38 Programmausführung von RK_SE16N

In der Regel sind Benutzer in produktiven SAP-Systemen nicht über das Berechtigungsobjekt S_TCODE berechtigt, die Transaktion SE16N auszuführen. Benutzer, welche unter anderem über die Ausführungsberechtigung der SA38 verfügen, können aber das Programm RK_SE16N jedoch wie in den Abbildungen 2 und 3 dargestellt trotzdem aufrufen, da üblicherweise keine Berechtigungsgruppe vergeben ist.

Abbildung 3: Report RK_SE16N bzw. Transaktion SE16N

Risiko 2: Fehlende Berechtigungsgruppen bei Tabellen

Bei Aufruf einer Tabelle wird zusätzlich das Berechtigungsobjekt S_TABU_DIS und dessen Feld ACTVT (Aktivität) geprüft. Auch bei diesem Berechtigungsobjekt verhält es sich analog zur S_PROGRAM-Berechtigung so, dass nur bei Tabellen mit gepflegter Berechtigungsgruppe auch das Feld DICBERCLS (Berechtigungsgruppe) geprüft wird. Alle Tabellen ohne Tabellenberechtigungsgruppe können entsprechend der erlaubten Aktivität angezeigt (03) oder geändert (02) werden.

Abbildung 4: Berechtigungsobjekt S_TABU_DIS (Tabellenpflege)

Empfehlung

Option 1. Wenn Sie die Vergabe der Transaktion SA38 bzw. SE38 weitestgehend vermeiden möchten, dann können Sie über die Transaktion SE93 für erforderliche Programme eine Transaktion anlegen. Diese Transaktion können Sie dann in den Berechtigungsrollen der Benutzer über das Berechtigungsobjekt S_TCODE berechtigen.

Option 2. Da ein Bedarf, Benutzer für den Aufruf der Transaktion SA38 bzw. SE38 zu berechtigen unter Umständen gegeben sein kann, bleibt noch die Option, für Programme und Tabellen ohne Berechtigungsgruppe eine Berechtigungsgruppe zu definieren. Das mag auf den ersten Blick, in Anbetracht der Menge von Programmen und Tabellen ohne eine entsprechende Einstellung sehr aufwendig wirken, kann jedoch die Wirksamkeit der Berechtigungen und damit die Sicherheit der Systeme enorm steigern. Für Programme und Tabellen ohne Berechtigungsgruppe kann beispielsweise eine beliebige Berechtigungsgruppe angelegt und vergeben werden. Die relevanten Tabellen, in denen Sie die Zuordnungen der Berechtigungsgruppen finden können, finden Sie nachfolgend aufgelistet.

Tabellenübersicht

Programme. Hier finden Sie die Tabellen, welche im Zusammenhang mit Berechtigungsgruppen für Programme relevant sind.

TPGP: Hier können Sie vorhandene Berechtigungsgruppen einsehen und einfügen. Alternativ lassen sich Berechtigungsgruppen auch über das Programm RSCSAUTH pflegen.

TRDIR: In dieser Tabelle sind alle Programme (Feld: NAME) mit den entsprechenden Berechtigungsgruppen (Feld: SECU) verzeichnet.

Tabellen. Hier finden Sie die Tabellen, welche im Zusammenhang mit Berechtigungsgruppen für Tabellen relevant sind.

TBRG: In der Tabelle TBRG können Berechtigungsgruppen für Tabellen (Objekt: S_TABU_DIS) angelegt werden.

TDDAT: Eine Zuordnung von Tabellen zu Berechtigungsgruppen können Sie in dieser Tabelle einsehen und ändern.

Download des Artikels mit zusätzlichem Inhalt

Laden Sie diesen kompletten Beitrag “HowTo Risiko durch fehlende Berechtigungsgruppen von Programmen und Tabellen im SAP minimieren” als PDF herunter inklusive zusätzlichen Beispielen und Tipps zur Analyse.

Ich freue mich auf Ihre Kommentare und Anregungen.

The post Risiko durch fehlende Berechtigungsgruppen von Programmen und Tabellen im SAP minimieren appeared first on rz10.de - das SAP Basis- und Security Blog.

Zahlreiche Fälle aus der Vergangenheit zeigen auf, wie wichtig der Schutz der Daten eines Unternehmens vor Missbrauch und Diebstahl ist. In verschiedenen Bereichen eines Unternehmens kann es des Weiteren aus datenschutzrechtlichen Gründen erforderlich sein, Zugriffe auf bestimmte Daten zu überwachen. So müssen z.B. Banken sicherstellen, dass Zugriffe auf sensible Daten nur durch berechtigte Mitarbeiter durchgeführt werden. Auch in Krankenhäusern muss gewährleistet sein, dass auf Patientenakten nur ein bestimmter Personenkreis Zugriff erhält. Zahlreiche weitere Szenarien sind denkbar, die eine Überwachung definierter Daten erforderlich machen. Grundsätzlich dreht es sich in vielen Fällen um das Recht auf informationelle Selbstbestimmung oder den Schutz der Privatsphäre von Kunden und Patienten. Gesetzlich ist unter Umständen außerdem vorgeschrieben, dass auch Lesezugriffe auf sensible Daten nachweisbar protokolliert werden.

SAP Read Access Logging

Die SAP bietet Kunden mit dem Read Access Logging eine technische Möglichkeit die lesenden Zugriffe auf definierte Daten zu protokollieren. Während Änderungen immer schon in den Änderungsbelegen protokolliert wurden, war dies bisher ohne zusätzliche Anwendungen oder kundenindividuelle Entwicklungen für Lesezugriffe nicht der Fall. Read Access Logging ermöglicht eine flexible Konfiguration der Protokollierungsregeln sowie der Aufbewahrungsrichtlinien. Neben einer grundlegenden Auswertungsanwendung besteht außerdem die Möglichkeit über eine Schnittstelle (API) die Protokolle automatisiert auswerten zu lassen. Dabei steht es dem Unternehmen frei die Regeln so zu definieren, dass lediglich der Lesezugriff auf die Daten durch einen Benutzer protokolliert wird oder zusätzlich auch die angezeigten Daten.

Hervorzuheben ist bei dem Read Access Logging Framework, dass die Protokollierungsregeln nicht nur auf Datenbank- oder Feld-Ebene definiert werden können. So ist beispielsweise sogar eine Einschränkung auf Basis des Feldinhalts möglich, um nur Lesezugriffe auf einige definierte Datensätze einer Tabelle zu protokollieren.

Voraussetzungen und Einschränkungen für RAL

Eingeführt wurde das Read Access Logging mit dem SAP NetWeaver Application Server (ABAP) 7.40 SP02. SAP gibt in der Liste der bisher für die Lesezugriffsprotokollierung unterstützten Kanäle (Zugriffstechnologien) Remote Function Calls (RFC), Web-Dynpro-Applicationen und Web-Service-Aufrufe an. Dabei können bei RFC-Verbindungen sowohl server- als auch clientseitige Zugriffe protokolliert werden. Bei Web-Service-Aufrufen können außerdem sowohl die Daten der Anfrage als auch die zurückgelieferten Daten überwacht werden. Im Web-Dynpro-Bereich können alle kontextgebundenen Datenelemente überwacht werden. Eine Einschränkung gibt es hier lediglich bei den Elementen der F4-Hilfe, welche nicht mitprotokolliert werden können.

Was in der Zukunft geplant ist

Möglicherweise fragen Sie sich nun, wann die Liste der unterstützten Kanäle erweitert wird. Die SAP gibt an, dass für das SAP NetWeaver AS ABAP 7.40 SP04 bereits fest die Unterstützung eines ABAP-Dynpro-Kanals geplant ist. Weitere Kanäle werden dann ab SP05 folgen.

Planen Sie den Einsatz von Read Access Logging oder setzen Sie das Werkzeug bereits ein? Welche Erfahrungen haben Sie mit Anwendungen zur Lesezugriffsprotokollierung gemacht? Ich freue mich auf Ihre Kommentare und Anregungen.

The post Lesezugriffe in SAP Systemen mit Read Access Logging (RAL) protokollieren appeared first on rz10.de - das SAP Basis- und Security Blog.

Die Transaktion SUIM ist als Werkzeug im Berechtigungsumfeld kaum wegzudenken. Interne, sowie externe Auditoren nutzen diese Transaktion um zum Beispiel Benutzer mit kritischen Berechtigungen zu identifizieren, die sie solche nicht haben sollten. Stellen Sie sich jetzt vor, dass es einen Dialog-Benutzer in Ihrem System gibt, der das Profil SAP_ALL besitzt und über die Transaktion SUIM nicht gefunden werden kann. In diesem Beitrag möchte ich Ihnen deshalb zeigen, wie Sie diese Sicherheitslücke auf Ihrem System erkennen und wie Sie diese beheben können.

Die Sicherheitslücke:

Dreh und Angelpunkt ist der unscheinbare Dialog-Benutzer ‘…………’, den ich über die Transaktion SU01 mit den Profilen SAP_ALL und SAP_NEW anlege. Falls jemand die Lücke ausnutzen möchte, wird er sehr wahrscheinlich nicht diesen offensichtlichen Weg gehen, sondern den Benutzer unter zu Hilfenahme verschiedener Funktionsbausteine etc. erstellen.

Der Benutzer sieht wie folgt aus.

Wenn Sie nun über die Transaktion SUIM (Report RSUSR002) nach Benutzern mit dem Profil SAP_ALL suchen, werden Sie merken, dass die Ergebnisliste diesen Dialog-Benutzer nicht enthält. In den nächsten beiden Abbildungen wird dieses Phänomen noch einmal dargelegt.

Die Ursache:

Grund für die Misere sind zwei Zeilen ABAP Code im Report RSUSR002, der hinter der Transaktion SUIM steckt. Über die Transaktion SE38 können Sie sich den Quellcode zu dem Report anschauen und dort über die Suche die betreffenden Stellen ausfindig machen.

Wie Sie der Abbildung entnehmen können wird durch die Anweisung DELETE userlist WHERE bname = ‘…………’. aktiv der Benutzer aus der Liste entfernt und ist somit für Sie unsichtbar. 

Die Lösung:

Durch Einspielen des SAP Hinweises 1844202 lässt sich die Sicherheitslücke schließen. Zusätzlich empfehle ich in diesem Zusammenhang die Implementierung des SAP Hinweises 1731549, über den der Zeichenvorrat für den Benutzerstamm eingeschränkt wird.

Sollten Sie für den Übergang eine schnelle Lösung suchen, so können Sie den Benutzer ‘…………’ auch im SAP Security Audit Log eintragen, da das SAP Security Audit Log als einziges die Aktivitäten dieses Benutzers protokolliert.

Wie sind Ihre Erfahrungen mit Sicherheitslücken in SAP? Ich freue mich auf Ihren Kommentar.

The post SAP Sicherheitslücke in der Transaktion SUIM appeared first on rz10.de - das SAP Basis- und Security Blog.

Personalprozesse, und damit verbunden die technische Unterstützung Ihres SAP-Systems, gehören mittlerweile zu den wichtigsten Erfolgsfaktoren in Unternehmen. Zu diesem Thema veranstaltet die mindsquare GmbH am 10. Oktober 2013 ihre 8. SAP-Infoveranstaltung. Der Fachbereich SAP Basis und Security ist als Teil der Mindsquare mit dabei.

In meinem Vortrag wird es um Maßnahmen zur Absicherung von HR Applikationen in Verbindung mit SAP gehen. Gerade im HR Umfeld gibt es nicht nur gesetzliche Auflagen, sondern auch konkrete innerbetriebliche Anforderungen Datenschutz und Vertraulichkeit von Personaldaten sicherzustellen. Der Vortrag beleuchtet technische und organisatorische Maßnahmen, die sich bewährt haben.

Die Vortragsagenda

(B.Sc.) Alexander Graf (Fachbereichsleiter HR): 
Administratives Tagesgeschäft war gestern – gewinnen Sie Zeit für strategisches Personalmanagement.

(Dipl.-Wirt.-Inf.) Johannes Behrndt (Fachbereichsleiter Mobility):
Begeistern Sie Ihre Mitarbeiter mit mobilen Apps im HR. & Special Guest, André Pradel, Projektleiter bei Audi AG

(B.Sc.) Tobias Harmes (Fachbereichsleiter Basis und Security): 
So sichern Sie Ihre HR Applikationen.

(Dipl.-Wirt.-Inf.) Ingo Biermann (Fachbereichsleiter Custom Solutions): 
SAP User Experience Strategie: Die Zukunft mit Web Dynpro und SAP UI5

(B.Sc.) Jeremia Girke (Fachbereichsleiter Formulare): 
Adobe Formulare im HR

Wo kann man sich anmelden?

Die Einladung zur Veranstaltung und alle Details finden Sie hier: 8. SAP-Infoveranstaltung: Innovation für Ihr SAP-HR und mehr!

The post 8. SAP-Infoveranstaltung: Innovation für Ihr SAP-HR und mehr! appeared first on rz10.de - das SAP Basis- und Security Blog.

Segregation of Duties, oder kurz SoD, bedeutet, dass bestimmte Aufgaben eines Geschäftsprozesses nicht durch ein und dieselbe Person durchgeführt werden sollen. Ähnlich dem Vier-Augen-Prinzip dient die Funktionstrennung Fehler und Manipulationen zu verhindern, sowie Funktionen und Verantwortungsbereiche sauber voneinander zu trennen.

Gerade im Rahmen einer Wirtschaftsprüfung wird immer ein SoD-Check durchgeführt, um zu verhindern, dass zum Beispiel Zahlungswege manipuliert werden und so ein großer finanzieller Schaden sowohl für den Kunden, als auch den Lieferanten entsteht. Werden bei einer Prüfung dann auch noch Lücken in der Umsetzung der Funktionstrennung aufgedeckt, sind dies Punkte die zu einer erneuten Wirtschaftsprüfung führen und gegebenenfalls auch weitere Konsequenzen für das Unternehmen nach sich ziehen können. Neben den zahlreichen Drittanbietern, die Lizenz-Software für SoD Prüfungen im SAP Umfeld anbieten, bietet die SAP selbst eine Möglichkeit SoD Prüfungen im System durchzuführen.

Im folgenden Kapitel wird beschreiben, wie über die SAP Transaktion SUIM eine automatisierte SoD Prüfung durchgeführt werden kann, um im Vorfeld einer Wirtschaftsprüfung Mängel feststellen zu können.

The post Segregation of Duties mit der SAP Transaktion SUIM appeared first on rz10.de - das SAP Basis- und Security Blog.

Nach der Trennung eines SAP Dual-Stack-Systems auf ein separates Java- und ABAP-System kann das SAP NetWeaver Portal Java keine ABAP-Inhalte mehr anzeigen und Single-Sign-On (SSO) funktioniert nicht mehr. Beim Anmelden erscheinen die Fehlermeldungen Issuer of SSO ticket is not authorized bzw. SSO logon not possible.

Die SSO-Fehlermeldung:

Beim Anmelden via System Administration erscheint der Hinweis „SSO logon not possible; browser logon ticket cannot be accepted“.

Beim Anmelden über die SAP Gui erscheint der Hinweis „Issuer of SSO ticket is not authorized“.

Dem SSO-Fehler auf der Spur:

Um auf die Ursache solcher Fehler zu stoßen, bietet sich ein Security Trace mit der SM50 an. Hierfür kann der Trace Level zunächst wie folgt auf Level 2 erhöht werden:

Ein erneutes Nachstellen des Fehlerfalls führte zu folgendem Log:

Im Log heißt es: “ERROR => System ID and client from ticket are not the same than mine […]“, sodass der Fehler in diesem Fall auf die nicht übereinstimmenden Clients zurückzuführen war.

Die Lösung des SSO-Fehlers:

Um das Problem zu lösen gilt es den entsprechenden Parameter login.ticket_client über die UME-Konfiguration des SAP NetWeaver Portals vorzunehmen. Je nach Version des Portal ändern Sie diesen Parameter entweder über SAP NetWeaver Administrator (Portal > 7.2) oder über Visual Admin (Portal 7.0). Den Parameter login.ticket_client finden Sie via Systemadminitration -> UME-Konfiguration -> Expertenmodus öffnen.

Im oben aufgeführten Fehlerfall hatte der Parameter login.ticket_client den Wert 777. Korrekterweise müssen Sie hier den Client des Logon-Tickets (client 000) eintragen.

Sobald Sie den entsprechenden Wert für login.ticket_client eingetragen haben, sollte die Anmeldung wieder funktionieren.

Ich freue mich auf Ihre Kommentare und Ihr Feedback und hoffe, dass ich Ihnen bei der Lösung des Problems behilflich sein konnte.

The post Fehler: Issuer of SSO ticket is not authorized bzw. SSO logon not possible appeared first on rz10.de - das SAP Basis- und Security Blog.

Über das Berechtigungsobjekt S_DEVELOP kann man Debugging-Berechtigung im SAP erteilen. Diese Berechtigung erlaubt es über die Eingabe von “/h” im OK-Feld der Gui den Debug-Modus zu aktivieren.

Während diese Funktion auf dem Entwicklungssystem ohne Frage zu den notwendigen Entwicklungsfunktionalitäten dazugehört ist es auf einem Produktions- oder Konsolidierungssystem höchst kritisch. Denn es erlaubt dem Anwender den normalen Programmablauf zu beeinflussen und Werte während des Programmlaufs zu ändern.

So kann ein Anwender ein Programm starten und z.B. einen AUTHORITY-CHECK überspringen. Damit erlangt er Zugang zu Daten oder kann Änderungen vornehmen, die im normalen Programmfluss nicht vorgesehen sind.

Ein prominentes Beispiel ist auch über den Debug-Modus das sapedit in der SE16 bzw. SE16N wieder zu aktivieren – dann kann man direkt in der Tabellenansicht Änderungen in der Datenbank durchgeführen. Diese Möglichkeit Felder zu ändern gefährdet den Grundsatz “Keine Änderung ohne Beleg”.

Wie kann man nun S_DEVELOP einschränken?

Zuerst muss man die Rollen identifizieren, die S_DEVELOP mit DEBUG Aktivität 02 enthalten. Dies kann man über die SUIM -> Rollen nach komplexen Selektionskriterien durchgeführt werden. Wenn man den Debug-Modus komplett deaktiveren will, muss man auch nach Aktivität 03 suchen.

Im Rolleneditor in der PFCG kann man nun die entsprechende Rolle einschränken.

Im Hinweis 65968 – ABAP-Debugging-Berechtigungen werden die möglichen Werten für S_DEVELOP dokumentiert:

The post SAP Debug Berechtigung einschränken appeared first on rz10.de - die SAP Basis und Security Experten.

Auch die SAP bleibt nicht von Sicherheitslücken verschont, wie der jüngst erschienene Blogbeitrag “SAP Heartbleed: Kein OpenSSL – kein Problem?” meines Kollegen Tobias Harmes zeigt. Glücklicher Weise reagiert die SAP sehr schnell auf diese Risiken und veröffentlich zeitnah SAP Hinweise, um die Sicherheitslücken zu schließen. Zusätzlich findet monatlich ein sogenannter Patch Day der SAP statt, zu dem auch sicherheitsrelevante SAP Hinweise veröffentlicht werden.

Doch die schnelle Reaktionszeit der SAP bleibt völlig wirkungslos, wenn die SAP Hinweise nicht zeitnah implementiert werden. Oft ist aber auch gar nicht bekannt, welche SAP Sicherheitshinweise im eigenen System bereits vorhanden oder notwendig sind. Wie Sie sich an dieser Stelle das Leben leichter machen können, werde ich Ihnen im Folgenden darlegen.

Nur ein Sicherheitsscan bringt keine Sicherheit.

Wir erstellen individuelle SAP Security-Konzepte für Ihr Unternehmen und helfen bei der Behebung von Schwachstellen. Deshalb haben wir dafür auch ein passendes Angebot: Security-Berater von RZ10
Unsere Referenzen finden Sie hier.

Kontaktieren Sie mich: Telefon 0211.175403-22 oder per E-Mail info@rz10.de In einem unverbindlichen Gespräch kann ich mit Ihnen über Ihre Ausgangslage sprechen und Ihnen Möglichkeiten aufzeigen. Selbstverständlich können wir danach auch ein unverbindliches Angebot unterbreiten.Fachbereichsleiter Tobias Harmes

Die SAP hat für diesen speziellen Fall ein eigenes Tool entwickelt, das Bestandteil der Software Komponente ST-A/PI ab Release 01M_* ist. Das Tool heißt RSECNOTE und wird über den SAP Hinweis 888889 im System implementiert. RSECNOTE untersucht ihr System nach bereits implementierten Sicherheitshinweisen und listet diese bzw. die noch zu implementierenden Sicherheitshinweise auf.

Wichtig ist, dass Sie die Implementierungs-/Konfigurationsschritte gemäß dem Hinweis durchführen und sich die Berechtigungen wie im Hinweis beschrieben vergeben, damit Sie das Tool fehlerfrei verwenden können.

Nachdem Sie die Implementierung abgeschlossen haben, können Sie über die Transaktion ST13, in neueren Releases auch die Transaktion SA38, verwenden. Geben Sie dort, wie in der Abbildung dargestellt, jeweils im Eingabefeld das Programm RSECNOTE ein und führen Sie es aus.

Sie erhalten anschließend die schon angesprochene Liste mit implementierten bzw. noch zu implementierenden SAP Hinweisen.

Wie halten Sie Ihre Systeme sicherheitstechnisch auf dem neusten Stand? Ich freue mich auf Ihre Kommentare.

The post Automatische Prüfung für SAP Sicherheitshinweise appeared first on rz10.de - die SAP Basis und Security Experten.

Die SAP Infoveranstaltung der mindsquare GmbH feiert am 03. Juli 2014 in Düsseldorf Jubiläum und wartet mit hochkarätigen Vorträgen zum Thema “Sicherheit im SAP” auf.

Die jüngsten Ereignisse haben gezeigt, dass das Thema Sicherheit immer noch brandaktuell ist und mehr denn je in den Fokus der Öffentlichkeit rückt. So ist erst vor kurzem der SSL Super-GAU, der sogenannte Heartbleed, publik geworden, der auch im SAP Umfeld Wellen geschlagen hat. Dies haben wir zum Anlass genommen, Ihnen das Thema Sicherheit im SAP noch einmal etwas näher zu bringen.

Nur ein Sicherheitsscan bringt keine Sicherheit.

Wir erstellen individuelle SAP Security-Konzepte für Ihr Unternehmen und helfen bei der Behebung von Schwachstellen. Deshalb haben wir dafür auch ein passendes Angebot: Security-Berater von RZ10
Unsere Referenzen finden Sie hier.

Kontaktieren Sie mich: Telefon 0211.175403-22 oder per E-Mail info@rz10.de In einem unverbindlichen Gespräch kann ich mit Ihnen über Ihre Ausgangslage sprechen und Ihnen Möglichkeiten aufzeigen. Selbstverständlich können wir danach auch ein unverbindliches Angebot unterbreiten. Fachbereichsleiter Tobias Harmes

Ich selbst werde für RZ10.de und den Fachbereich Basis & Security Antworten liefern auf die Frage: “Ist die PFCG etwas für Romantiker? Neue Wege für die Wartung Ihrer SAP Berechtigungen in Zeiten von Funktionstrennung und Compliance-Anforderungen.”

Lernen Sie Best Practices kennen, die sich in vielen Kundenprojekten bereits bewährt haben. Ich werde Ihnen zeigen, wie Sie die komplexen Anforderungen von heute meistern können und damit die Limitation der alten SAP Werkzeuge kompensieren.

Unter anderem geht es um:

• Aktuelle Hilfsmittel im Berechtigungsumfeld im SAP Standard
  
• Tipps für die Erstellung von Prozessberechtigungen
  
• Möglichkeiten von externen Berechtigungslösungen
  

Meine Kollegen haben ebenfalls aktuelle sicherheitsrelevante Themen aus ihren Fachbereichen mitgebracht:

(B.Sc.) Jeremia Girke (Fachbereichsleiter Formulare)
“Auch Formulare wollen sicher sein.”

(B.Sc.) Alexander Graf (Fachbereichsleiter HR)
“Berechtigungen auf Personaldaten einfach verwalten.”

(Dipl.-Wirt.-Inf.) Ingo Biermann (Fachbereichsleiter Custom Solutions)
“Sicherheit im eigenen Haus.”

(Dipl.-Wirt.-Inf.) Johannes Behrndt (Fachbereichsleiter Mobility)
“Sicher in die mobile Zukunft.”

Hier sind alle Informationen zusammengefasst und die vollständige Agenda sowie Anmeldeinformationen:

Informationen und Anmeldung – 10. Jubiläums-SAP Infoveranstaltung “Sicherheit im SAP”

Neben dem Rahmenprogramm bleibt Ihnen natürlich genügend Zeit, um mit uns zu Fachsimpeln und Fragen zu stellen. Ich freue mich darauf Sie persönlich kennen zu lernen.

The post 10. Jubiläums-SAP Infoveranstaltung „Sicherheit im SAP“ appeared first on rz10.de - die SAP Basis und Security Experten.

Nach der Trennung eines SAP Dual-Stack-Systems auf ein separates Java- und ABAP-System kann das SAP NetWeaver Portal Java keine ABAP-Inhalte mehr anzeigen und Single-Sign-On (SSO) funktioniert nicht mehr. Beim Anmelden erscheinen die Fehlermeldungen Issuer of SSO ticket is not authorized bzw. SSO logon not possible.

Die SSO-Fehlermeldung:

Beim Anmelden via System Administration erscheint der Hinweis „SSO logon not possible; browser logon ticket cannot be accepted“.

Beim Anmelden über die SAP Gui erscheint der Hinweis „Issuer of SSO ticket is not authorized“.

Dem SSO-Fehler auf der Spur:

Um auf die Ursache solcher Fehler zu stoßen, bietet sich ein Security Trace mit der SM50 an. Hierfür kann der Trace Level zunächst wie folgt auf Level 2 erhöht werden:

Ein erneutes Nachstellen des Fehlerfalls führte zu folgendem Log:

Im Log heißt es: „ERROR => System ID and client from ticket are not the same than mine […]“, sodass der Fehler in diesem Fall auf die nicht übereinstimmenden Clients zurückzuführen war.

Die Lösung des SSO-Fehlers:

Um das Problem zu lösen gilt es den entsprechenden Parameter login.ticket_client über die UME-Konfiguration des SAP NetWeaver Portals vorzunehmen. Je nach Version des Portal ändern Sie diesen Parameter entweder über SAP NetWeaver Administrator (Portal > 7.2) oder über Visual Admin (Portal 7.0). Den Parameter login.ticket_client finden Sie via Systemadminitration -> UME-Konfiguration -> Expertenmodus öffnen.

Im oben aufgeführten Fehlerfall hatte der Parameter login.ticket_client den Wert 777. Korrekterweise müssen Sie hier den Client des Logon-Tickets (client 000) eintragen.

Sobald Sie den entsprechenden Wert für login.ticket_client eingetragen haben, sollte die Anmeldung wieder funktionieren.

Ich freue mich auf Ihre Kommentare und Ihr Feedback zu SSO-Fehlermeldung und hoffe, dass ich Ihnen bei der Lösung des Problems behilflich sein konnte.

The post Fehler: Issuer of SSO ticket is not authorized bzw. SSO logon not possible appeared first on rz10.de - die SAP Basis und Security Experten.

Auch die SAP bleibt nicht von Sicherheitslücken verschont, wie der jüngst erschienene Blogbeitrag „SAP Heartbleed: Kein OpenSSL – kein Problem?“ meines Kollegen Tobias Harmes zeigt. Glücklicher Weise reagiert die SAP sehr schnell auf diese Risiken und veröffentlich zeitnah SAP Hinweise, um die SAP Sicherheitslücken zu schließen. Zusätzlich findet monatlich ein sogenannter Patch Day der SAP statt, zu dem auch sicherheitsrelevante SAP Hinweise veröffentlicht werden.

Doch die schnelle Reaktionszeit der SAP bleibt völlig wirkungslos, wenn die SAP Hinweise nicht zeitnah implementiert werden. Oft ist aber auch gar nicht bekannt, welche SAP Sicherheitshinweise im eigenen System bereits vorhanden oder notwendig sind. Wie Sie sich an dieser Stelle das Leben leichter machen können, werde ich Ihnen im Folgenden darlegen.

RSECNOTE

Die SAP hat für diesen speziellen Fall ein eigenes Tool entwickelt, das Bestandteil der Software Komponente ST-A/PI ab Release 01M_* ist. Das Tool heißt RSECNOTE und wird über den SAP Hinweis 888889 im System implementiert. RSECNOTE untersucht ihr System nach bereits implementierten Sicherheitshinweisen und listet diese bzw. die noch zu implementierenden SAP Sicherheitshinweise auf.

Wichtig ist, dass Sie die Implementierungs-/Konfigurationsschritte gemäß dem Hinweis durchführen und sich die Berechtigungen wie im Hinweis beschrieben vergeben, damit Sie das Tool fehlerfrei verwenden können.

Nachdem Sie die Implementierung abgeschlossen haben, können Sie über die Transaktion ST13, in neueren Releases auch die Transaktion SA38, verwenden. Geben Sie dort, wie in der Abbildung dargestellt, jeweils im Eingabefeld das Programm RSECNOTE ein und führen Sie es aus.

Sie erhalten anschließend die schon angesprochene Liste mit implementierten bzw. noch zu implementierenden SAP Hinweisen.

Was sind Ihre Erfahrungen der SAP Sicherheitshinweise?

Wie halten Sie Ihre Systeme sicherheitstechnisch auf dem neusten Stand? Ich freue mich auf Ihre Kommentare.

The post Sicherheitslücken durch SAP Sicherheitshinweise schließen appeared first on rz10.de - die SAP Basis und Security Experten.

Die SAP Infoveranstaltung der mindsquare GmbH feiert am 03. Juli 2014 in Düsseldorf Jubiläum und wartet mit hochkarätigen Vorträgen zum Thema „Sicherheit im SAP“ auf.

Die jüngsten Ereignisse haben gezeigt, dass das Thema Sicherheit immer noch brandaktuell ist und mehr denn je in den Fokus der Öffentlichkeit rückt. So ist erst vor kurzem der SSL Super-GAU, der sogenannte Heartbleed, publik geworden, der auch im SAP Umfeld Wellen geschlagen hat. Dies haben wir zum Anlass genommen, Ihnen das Thema Sicherheit im SAP noch einmal etwas näher zu bringen.

Nur ein Sicherheitsscan bringt keine Sicherheit.

Wir erstellen individuelle SAP Security-Konzepte für Ihr Unternehmen und helfen bei der Behebung von Schwachstellen. Deshalb haben wir dafür auch ein passendes Angebot: Security-Berater von RZ10
Unsere Referenzen finden Sie hier.

Kontaktieren Sie mich: Telefon 0211.9462 8572-25 oder per E-Mail harmes@rz10.de In einem unverbindlichen Gespräch kann ich mit Ihnen über Ihre Ausgangslage sprechen und Ihnen Möglichkeiten aufzeigen. Selbstverständlich können wir danach auch ein unverbindliches Angebot unterbreiten. Fachbereichsleiter Tobias Harmes

Ich selbst werde für RZ10.de und den Fachbereich Basis & Security Antworten liefern auf die Frage: „Ist die PFCG etwas für Romantiker? Neue Wege für die Wartung Ihrer SAP Berechtigungen in Zeiten von Funktionstrennung und Compliance-Anforderungen.“

Lernen Sie Best Practices kennen, die sich in vielen Kundenprojekten bereits bewährt haben. Ich werde Ihnen zeigen, wie Sie die komplexen Anforderungen von heute meistern können und damit die Limitation der alten SAP Werkzeuge kompensieren.

Unter anderem geht es um:

• Aktuelle Hilfsmittel im Berechtigungsumfeld im SAP Standard
  
• Tipps für die Erstellung von Prozessberechtigungen
  
• Möglichkeiten von externen Berechtigungslösungen
  

Meine Kollegen haben ebenfalls aktuelle sicherheitsrelevante Themen aus ihren Fachbereichen mitgebracht:

(B.Sc.) Jeremia Girke (Fachbereichsleiter Formulare)
„Auch Formulare wollen sicher sein.“

(B.Sc.) Alexander Graf (Fachbereichsleiter HR)
„Berechtigungen auf Personaldaten einfach verwalten.“

(Dipl.-Wirt.-Inf.) Ingo Biermann (Fachbereichsleiter Custom Solutions)
„Sicherheit im eigenen Haus.“

(Dipl.-Wirt.-Inf.) Johannes Behrndt (Fachbereichsleiter Mobility)
„Sicher in die mobile Zukunft.“

Hier sind alle Informationen zusammengefasst und die vollständige Agenda sowie Anmeldeinformationen:

Informationen und Anmeldung – 10. Jubiläums-SAP Infoveranstaltung „Sicherheit im SAP“

Neben dem Rahmenprogramm bleibt Ihnen natürlich genügend Zeit, um mit uns zu Fachsimpeln und Fragen zu stellen. Ich freue mich darauf Sie persönlich kennen zu lernen.

The post 10. Jubiläums-SAP Infoveranstaltung „Sicherheit im SAP“ appeared first on rz10.de - die SAP Basis und Security Experten.

SAP Versionsinformationen der SAP GUI

Warum ist ein Update der SAP GUI Version notwendig?

Wie bei anderer Software auch werden über die Zeit Sicherheitslücken bekannt, die in Updates behoben werden.
So war es in der Vergangenheit in einer älteren SAP GUI Version z.B. möglich, die Session eines Kollegen „zu klauen“ und damit im System weiter zu agieren.

Problem

Der SAP Standard sieht keine Möglichkeit zur Auswertung der SAP GUI Version inkl. Patchlevel vor.

Lösung

In meinen Recherchen bin ich auf den SAP Hinweis 748424 gestoßen. Dieser enthält entsprechende Beispielimplementierungen zweier Reports, die die SAP GUI Version auslesen und die entsprechenden Ergebnisse anzeigen.

Bei den Reports handelt es sich lediglich um Beispielimplementierungen, die eigentlich nicht für den produktiven Einsatz gedacht sind, da diese eine unzureichende Datenbankimplementierung aufweisen. Die Speicherung der Daten ist leider nicht sonderlich performant, lässt sich aber vertreten unter der Prämisse, dass die Daten regelmäßig gelöscht werden.

Der Hinweis kann einfach über die SNOTE eingespielt werden. Anschließend stehen die beiden Reports SAPGUI_VERSION und SAPGUI_VERSION_REPORT zur Verfügung.
Die Reports sind der Note auch angehängt, und könnten so direkt in ein Z-Programm kopiert werden.

Der Report SAPGUI_VERSION kann dann im Exit EXIT_SAPLSUSF_001 aufgerufen werden. Dieses Exit wird immer dann ausgeführt, wenn sich ein Nutzer am System anmeldet. Somit wird bei jedem Login die entsprechende Version protokolliert.

Um den Report aufzurufen, öffnen Sie den Funktionsbaustein EXIT_SAPLSUSF_001 über die Transaktion SE37. In dem Funktionsbaustein befindet sich ein Z-Include, das Sie ohne Modifikationsschlüssel bearbeiten können. Mit dem ABAP Code ‚SUBMIT <<<REPORTNAME>>>.‘ können Sie den Report aufrufen.
Die Datensätze, die durch den Report erstellt werden, werden allerdings nicht überschrieben, wenn der Nutzer sich am nächsten Tag wieder anmeldet, sodass relativ viele Daten zusammen kommen.

Welche Daten werden gesammelt?

Terminal-ID, User-ID, SAP GUI-Version und Patchlevel.

Die Daten können einfach über den Report SAPGUI_VERSION_REPORT angezeigt werden.
In einem Testszenario mit ca. 2500 aktiven Dialogbenutzern pro Tag wurden etwa 40KB erzeugt.

Verfolgen Sie einen anderen Lösungsansatz, um die Kontrolle über die Softwareversionen zu halten? Nutzen Sie vielleicht diesen Report bereits und haben schon Rückmeldungen zur Datenmenge? Ich freue mich über Ihre Kommentare!

The post Ihre SAP GUI Versionen ermitteln appeared first on rz10.de - die SAP Basis und Security Experten.

In einem SAP-System gibt es verschiedene Arten von SAP Benutzersperren. Wichtig ist, dass nicht alle Benutzersperren auch tatsächlich die Anmeldung verhindern.

Benutzersperren verhindern Anmeldung?

Es gibt verschiedene Sperrgründe für Benutzer und für gewöhnlich gehen Administratoren wie User davon aus, dass sie sich mit einem gesperrten Benutzer nicht mehr anmelden können. Doch erst neulich hatte ich einen Fall, wo ein Benutzer trotz Sperre Zugang zu einem System hatte. Wie kann das sein?

Gründe für Benutzersperren in SAP Systemen

a) Kennwortanmeldung nicht möglich (zu viele Falschmeldungen) Der Maximalwert für Fehlerversuche bei der Passwortanmeldung wurde erreicht. Dieser Maximalwert wird mithilfe des Profilparameters login/fails_to_user_lock gesteuert. Bei jedem fehlerhaften Anmeldeversuch eines Users wird ein individueller Falschanmeldezähler im jeweiligen Benutzerstamm erhöht. Wird der Maximalwert dieses Fehlers erreicht, wird der User für weitere Anmeldungen im System gesperrt.

ÜBRIGENS: Mithilfe des Parameters login/failed_user_auto_unlock können Sie festlegen, ob durch Fehlanmeldungen gesperrte User automatisch wieder entsperrt werden. Das heißt, wenn Sie den Wert des Parameters auf 1 festlegen, werden wegen Falschanmeldungen gesperrte User automatisch am nächsten Tag entsperrt!   

b) Kennwortanmeldung nicht möglich (Initialkennwort ist abgelaufen) Einem User (vom Benutzertyp Dialog oder Kommunikation) wurde ein neues Initialkennwort gesetzt. Dieses Initialkennwort wird gesperrt, sofern sich der User nicht innerhalb eines konfigurierten Zeitspanne anmeldet und das Initialkennwort somit seine Gültigkeit verliert. Die Zeitspanne der Gültigkeit von Initialkennwörtern wird mithilfe des Profilparameters login/password_max_idle_initial festgelegt.

c) Benutzer ist gesperrt („Gültig bis“-Datum überschritten) Jeder Benutzer sollte ein „Gültig von“- und „Gültig bis“-Datum hinterlegt werden. Wenn das „Gültig bis“-Datum überschritten wird, wird der Benutzer automatisch vom System gesperrt und eine Anmeldung ist dann nicht mehr möglich.

d) Benutzer manuell gesperrt (Administratorsperre) Zudem ist es jederzeit möglich, dass ein Benutzer vom Benutzeradministrator manuell gesperrt wird. In diesem Fall wird von der Administratorsperre gesprochen. Eine Anmeldung des Users ist dann nicht mehr möglich.

 Anmeldung am System trotz SAP Benutzersperren?

In welchem Fall ist es nun möglich, dass sich ein User – wie eingangs erwähnt – trotz SAP Benutzersperre in einem System anmelden kann? Die Antwort ist einfach: Nur dann, wenn nicht der Benutzer an sich (Fall c & d), sondern nur das Kennwort des Benutzer gesperrt ist (Fall a & b) und keine Anmeldung mittels Passwort erfolgt. Eine reguläre Anmeldung am System ist also nicht möglich. Allerdings gibt es noch andere Authentifizierungsverfahren, wie bspw. Single Sign-On oder auch interne Abläufe (wie zum Beispiel Hintergrundjobs). Diese Authentifizierungsverfahren sind nicht von der Passwortsperre betroffen, da keine Passwortanmeldung notwendig ist. Eine Ausnahme gibt es jedoch: Bei allen Anmeldeverfahren wird geprüft, ob das Passwort eines Benutzers geändert werden muss. Ist dies aktuell der Fall, wird der Benutzer auch bei anderen Authentifizierungsverfahren aufgefordert, dass aktuelle Passwort zu ändern.

ÜBRIGENS: Diese Aufforderung zum Ändern des Passwortes bei anderen Authentifizierungsverfahren können Sie mithilfe des Profilparameters login/password_change_for_SSO ein- und ausschalten.

 Und was ist nun Best Practice in Bezug auf SAP Benutzersperren?

Ich empfehle Ihnen ausdrücklich, den Zugang von Benutzer zum System via Gültigkeiten oder manueller Administratorsperre zu steuern. In diesem Fall ist der Benutzer wirklich gesperrt und kann sich über kein Authentifizierungsverfahren am SAP System anmelden. Denn nur Sperren und Gültigkeiten des Benutzerkontos betreffen auch andere Anmeldeverfahren, wie bspw. SSO. Um einen User also endgültig vom System ‚auszusperren‘ entfernen Sie bestenfalls alle zugeordneten Rollen, deaktivieren das Passwort und – am wichtigsten – setzen das „Gültig bis“-Datum auf einen Zeitpunkt in der Vergangenheit.

Ich hoffe, dass ich Ihnen mit meinem Blogbeitrag die SAP Benutzersperren in SAP Systemen verständlich machen konnte. Welche Erfahrungen haben Sie mit den verschiedenen Benutzersperren auf Ihren SAP Systemen gemacht? Ich freue mich schon auf Ihre Kommentare, Anregungen und Fragen direkt unterhalb dieses Blogbeitrags.

The post SAP Benutzersperren verstehen und Best Practice appeared first on rz10.de - die SAP Basis und Security Experten.