Ein Passwort genügt

Sonderdruck aus Heft 7-8/2015 vom 09.07.2015 · www.sap-port.de
„SAP Data Services“ bietet Sicherheit für wenig Aufwand
Ein Passwort genügt
Bei der Implementierung neuer Produkte in bestehende Systemlandschaften spielt das Thema Sicherheit eine zentrale Rolle. Dies gilt auch für ETL-Tools (ETL=Extraktion, Transformation, Laden) zur Optimierung der Qualität
von Daten aus den unterschiedlichsten Quellen. Mit „SAP Data Services“ (DS) steht eine Plattform zur Verfügung,
die die gängigsten Authentifizierungsmöglichkeiten unterstützt und damit für wenig Aufwand eine hohe Sicherheit
Quelle: Camelot ITLab
bietet. Folgende Projekterfahrungen sollen Unternehmen die DS-Einführung erleichtern.
Architektur SAP Data Services
Von Marcel Stefanski*
1. Achtung bei der Nutzung der
BI-Plattform zur Authentifizierung
Wer SAP DS installieren will, benötigt neben einem Server für die Anwendungen
einen separaten Server für die Anmeldung
und Authentifikation der Nutzer. Es ist
jedoch nicht ratsam, dafür eine bestehende „SAP Business Intelligence“-(BI-)Plattform zu verwenden. Wie ein Kundenprojekt in der Pflegeproduktbranche gezeigt
hat, kann es zu massiven technischen Problemen kommen, wenn die BI-Plattform
sowohl für die „BusinessObjects“-Lösungen (BO) als auch für SAP DS eingesetzt
*Marcel Stefanski
ist Senior Consultant
BI bei der Camelot
ITLab GmbH.
wird. So stellte sich glücklicherweise noch
vor Produktivsetzung der Data Services
heraus, dass die gleichzeitige Nutzung
von SAP DS und den BO-Web-Intelligence-Services technisch unmöglich ist.
Statt zeitraubende Systemausfälle und
Neustarts zu riskieren, sollten Unternehmen daher lieber gleich auf „SAP BO Information Platform Services“ (IPS), eine
abgespeckte Version der BI-Plattform, als
eigenständigen Server für die Authentifizierung der DS-Anwender setzen.
2. Einsatz von SAP Single Sign-on
Unternehmen, die ein SAP-System im
Einsatz haben, wollen in der Regel die
dort erstellte Security – soweit möglich –
auch für andere Systeme nutzen. Dies ist
bei SAP Data Services ohne Probleme
über die BI-Plattform möglich. Dazu ist es
zunächst erforderlich, BW in die BI-Plattform einzubinden und dann die Secure
Network Communications (SNC) einzu-
richten. Bei SNC handelt es sich um eine
Softwareschicht, die das SAP Single Signon in die DS integriert und die Anwender
damit in die Lage versetzt, sich auch ohne
Passwort am SAP-System anzumelden.
Falls vom Unternehmen gewünscht, kann
sich der Anwender nun über SAP-Benutzernamen und -Kennwort an der BI-Plattform und dann auch an SAP Data Services anmelden, ohne dass das Kennwort
auf der BI-Plattform gespeichert wird.
Des Weiteren bietet die SAP-Authentifizierung die Möglichkeit, SAP-Rollen zu
nutzen, um Rechte für Administrationsaufgaben oder den Zugriff auf Data
Services Repositories zuzuweisen. Dabei
handelt es sich um einen Satz von Tabellen, in denen alle Metadaten abgelegt
werden. Alle Anwender, denen diese Rollen im SAP-System zugeordnet sind, sind
damit automatisch auf der BI-Plattform
verfügbar. SAP Single Sign-on spart beträchtlichen Zeitaufwand und erhöht die
Sicherheit in SAP-Umgebungen.
Darüber hinaus können sich DS-Nutzer
mit der LDAP-Authentifizierung (LDAP=
Lightweight Directory Access Protocol)
über die BI-Plattform anmelden. Hierfür
muss auf der BI-Plattform auch eine Verbindung zum LDAP-Server und die Art
der Zuordnung von Aliasen eingerichtet
werden. Am sinnvollsten ist es, wenn ein
Anwender in jedem System dieselbe UserID hat. Wenn ein Nutzer beispielsweise
über seine BW-Rolle bereits im System
vorhanden ist, genügt eine einmalige Anmeldung mit dem Windows-Kennwort,
um den Alias des LDAP-Users automatisch mit dem Alias des BW-Users zu mappen. Dieses Prinzip gilt auch für jedes
andere SAP-System, das angebunden
wurde. Es reduziert den administrativen
Aufwand, da das Mapping nur einmal innerhalb des Systems vorgenommen werden muss, und zwar lediglich gruppenund rollenbezogen. Die Nutzerzuordnung
Quelle: Camelot ITLab
Beispiel einer Data-Services-Landschaft mit mehreren lokalen Repositories
wird innerhalb des führenden SecuritySystems durchgeführt – in diesem Fall
wäre dies das SAP BW.
3. Vergabe der SAP-Data-ServicesBerechtigungen
Bei der Vergabe der Berechtigungen für
die SAP Data Services auf der BI-Plattform sollten Unternehmen gleich auf mehrere Punkte achten. Der erste Punkt ist bei
der Anwendung „Data Services“ im Bereich Anwendungen. Hier werden die Berechtigungen für die „SAP Data Services
Management Console“ (MC) und für den
„Data Services Designer“ vergeben.
Die SAP DS MC wird für administrative
Aufgaben genutzt. Hier werden auch die
SAP-Systeme angelegt, die später im Designer als Quell- oder Zielsysteme genutzt
werden sollen. Damit lässt sich verhindern, dass zum Beispiel aus Versehen an
ein DS-Entwicklungs- ein SAP-Produktivsystem angebunden wird. Stattdessen
sorgt man dadurch für eine konsistente
Systemlandschaft.
Daneben müssen die Berechtigungen für
die Entwickler vergeben werden, die über
den Data Services Designer auf die lokalen
Repositories zugreifen. Generell werden
dazu BusinessObjects-Enterprise-Gruppen eingerichtet, an die die gewünschten
Berechtigungen vergeben werden. Anschließend werden diese Gruppen zu den
entsprechenden SAP-Rollen gemappt.
Dieses Mapping erfolgt einmalig und erspart somit weitere administrative Tätigkeiten in diesem Bereich. Daher sollten
Unternehmen der Einfachheit halber darauf achten, dass diese Zuordnung immer
pro Rolle und nicht pro Anwender erfolgt.
Somit wird weiterhin die Security des
SAP-Systems genutzt und muss nicht parallel nochmals aufgebaut werden.
4. Unterteilung der Data Services
Repositories
Meldet sich ein Entwickler am Data Services Designer an, öffnet er immer ein
lokales Repository, für das er berechtigt
ist. In diesem lokalen Satz von Tabellen arbeitet er. Hier werden zum Beispiel die
Quell- und Zielsysteme angelegt sowie
die Jobs mit allen vorgenommenen Transformationen. Unternehmen müssen also
darauf achten, auf der BI-Plattform jedes
Repository anzulegen und dafür die Berechtigungen zu vergeben.
In der Regel empfiehlt es sich, mehrere lokale Repositories anzulegen. In der Praxis
hat es sich bewährt, für Gruppen von Entwicklern, die am gleichen Projekt oder in
einem Team arbeiten, jeweils ein Repository aufzubauen. Dies bietet auch den
Vorteil, dass sich die Teams bei ihrer Arbeit
an den Repositories nicht in die Quere
kommen.
5. Mastercopy mit Hindernissen
Neben diesen lokalen gibt es auch zentrale
Repositories. SAP stellt damit eine gemeinsame Objektbibliothek zur Verfügung, in der die Entwickler die Objekte
von den lokalen Repositories ein- und
wieder auschecken können. Dahinter
steckt die Idee: Während jeder Entwickler
an seinen Anwendungen im lokalen Repository arbeitet, verwenden die Teams
ein zentrales Repository, um eine Mastercopy des gesamten Projekts zu haben. Das
hört sich theoretisch gut an – hat in der
Praxis aber leider einen Haken, und der
liegt im Bereich der Sicherheit.
Zwar werden auch die zentralen Repositories auf der BI-Plattform angelegt und
dafür Berechtigungen vergeben, doch sind
in diesem Fall zusätzliche Berechtigungen auf dem Data-Services-Server erforderlich. Der damit verbundene Aufwand
wäre noch akzeptabel, wenn er einmalig
für Gruppen betrieben werden müsste.
Dies ist jedoch nicht gegeben. Da die DS
Management Console nicht auf Gruppen,
sondern nur auf einzelne User zugreifen
kann, müssen hier nochmals Gruppen angelegt und die einzelnen User hinzugefügt
werden. Da dies einen unverhältnismäßig hohen Aufwand erfordern würde, wurde in den vorausgegangenen Kundenprojekten auf die Einrichtung zentraler Repositories gänzlich verzichtet.
Um den Entwicklern dennoch einen gegenseitigen Austausch zu ermöglichen,
empfiehlt sich die Möglichkeit, alle Jobs in
ein lokales Repository in der Sandbox zu
transportieren. Auf dieser Art „Spielwiese“
kann dann jeder Entwickler arbeiten, alles
wird kontinuierlich überschrieben, bis
eine neue Version entstanden ist. Für alle
anderen Fälle, wenn also eine Arbeit im
Entwicklungssystem gesichert werden
soll, gibt es die Möglichkeit, diese separat
zu transportieren.
6. Nachtrag zum BW:
7.x Datenfluss erst ab BW 7.3
Ab „SAP NetWeaver 7.0“ wurden Konzepte und Technologien für einige Elemente im Datenfluss geändert. Dadurch
hat sich die Performance der Datenflüsse
deutlich verbessert. Um diesen neuen Datenfluss auch zum Laden von Daten aus
SAP Data Services nutzen zu können, benötigt man mindestens ein „SAP Business Warehouse“ (BW) 7.3. Unternehmen,
die eine ältere Version des BW im Einsatz
haben, können leider nur mit dem 3.x Datenfluss arbeiten.
Ein weiterer Vorteil ab BW 7.3 ist die Nutzung eines neuen Typs von Quellsystem:
„BO DataServices“ statt der älteren Version „Externes System“. Auch dies steigert
die Performance beim Laden der Daten.
Fazit
Zahlreiche Kundenprojekte haben gezeigt, dass sich SAP Data Services unter
Berücksichtigung der genannten Faktoren schnell und einfach in die vorhandenen Sicherheitsrichtlinien integrieren lassen. Nutzer und Entwickler brauchen nur
ihr Windows-Passwort einzugeben, um an
der Data Services Management Console
oder am Data Services Designer mit allen
angebundenen SAP-Systemen arbeiten
zu können. (ap) @

Download Report