IT Security März/April
Die Industrie sicherer machen – Sicherheit in Echtzeit für zeitkritische Produktionsverfahren Gravierende Folgen des neuen SAP-Lizenzmodells – Ungeprüfte Berechtigungen: Gefährlich – und nun auch teuer! KI-basierte Angriffserkennung – Möglichkeiten und Grenzen RBAC ist tot – lang lebe PBAC? Warum RBAC nicht stirbt
Die Industrie sicherer machen – Sicherheit in Echtzeit für zeitkritische Produktionsverfahren
Gravierende Folgen des neuen SAP-Lizenzmodells – Ungeprüfte Berechtigungen: Gefährlich – und nun auch teuer!
KI-basierte Angriffserkennung – Möglichkeiten und Grenzen
RBAC ist tot – lang lebe PBAC? Warum RBAC nicht stirbt
- Keine Tags gefunden...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
<strong>IT</strong> SECUR<strong>IT</strong>Y | 7<br />
SAP<br />
?<br />
Selbst wenn man die eindringlichen<br />
Warnungen der Sicherheitsexperten<br />
weiterhin ignoriert, gilt: Ausufernde Berechtigungen<br />
werden mittelfristig sehr,<br />
sehr teuer. Dabei zeigt die Erfahrung:<br />
Im Schnitt braucht ein User 75 Prozent<br />
der ihm zugewiesenen Berechtigungen<br />
überhaupt nicht. Das ist zumindest finanziell<br />
noch unproblematisch, solange<br />
auf Verbrauch lizenziert werden<br />
kann. Da man aber später auf Berechtigungen<br />
lizenzieren muss, und das wird<br />
passieren, entscheidet ja nicht mehr das<br />
Did-do eines Users, sondern ausschließlich<br />
das Could-do. Und dann werden<br />
diese 75 Prozent, die nie benutzt wurden,<br />
mit eingerechnet. Die Erfahrung<br />
der letzten Jahre im Bereich ECC hat<br />
gezeigt, dass diese Änderungen definitiv<br />
kommen werden, auch wenn der Aufschrei<br />
in der DSAG und anderen Gremien<br />
groß sein wird.<br />
Die Product Conversion<br />
Product Conversion bedeutet, dass alte<br />
Verträge (zunächst) bestehen bleiben.<br />
Im Gegensatz zur Contract Conversion<br />
ist es hier möglich, die bestehenden Verträge<br />
mit der SAP und damit eben auch<br />
deren Bedingungen zur Lizenzierung<br />
beizubehalten. Neue Produkte aus<br />
S/4HANA werden dann hinzugefügt,<br />
das heißt, wer eine neue Engine nutzen<br />
will, die es nur unter S/4HANA gibt,<br />
kauft diese hinzu und lizenziert sie entsprechend.<br />
Aber er verbleibt mit seinen<br />
Nutzungslizenzen mehr oder weniger<br />
im ECC-Bereich und vermisst weiterhin<br />
nach Verbrauch und nicht nach Berechtigung.<br />
Es findet damit natürlich aber<br />
auch keine Wandlung aus bestehenden<br />
Lizenzen wie bei der Contract Conversion<br />
statt. Zunächst wird also an das<br />
Bestehende einfach nur ein Vertrag<br />
über den konkreten Zukauf angefügt<br />
und die Lizenzierung basiert weiterhin<br />
auf tatsächlicher Nutzung.<br />
Die Konsequenzen<br />
Das Bisherige könnte zu dem Schluss<br />
verleiten, wenn man die Product Conversion<br />
wählt, bleibt alles, was das Thema<br />
Berechtigungen angeht, erst mal<br />
beim Alten, nur mit der Contract Conversion<br />
holt man sich die geschilderte<br />
Problematik ins Haus. Das ist aber in<br />
vielerlei Hinsicht zu kurz gedacht. Zum<br />
einen, weil es in den neuen Modellen<br />
neue Anwendungen gibt, während andere<br />
wegfallen, und wenn man dann<br />
Rollen baut, die kleinste Änderung dazu<br />
führen kann, dass diese nicht mehr<br />
lizenzkompatibel sind, was die entsprechenden<br />
Konsequenzen hat.<br />
Zum anderen: Wenn man eine Product<br />
Conversion betreibt, zeigt die Erfahrung,<br />
dass die benötigten Berechtigungen<br />
für die neu hinzugekauften Produkte<br />
meist einfach zu den alten Rollen<br />
hinzugefügt werden. Das heißt, es findet<br />
kaum eine Auseinandersetzung mit<br />
den bestehenden SAP-Rollen statt, mit<br />
der Folge, dass nicht mehr benötigte<br />
Berechtigungen weiterhin nicht entfernt<br />
werden. Was die Rolle angeht, wird<br />
diese erweitert, statt sie auf ein gesundes<br />
Maß zu reduzieren.<br />
Der Best Practice Ansatz<br />
Wie achtet man dann aber zukunftssicher<br />
auf Berechtigungen und Lizenzen<br />
im Projekt Rollenmigration? Die klare<br />
Antwort ist: Alles außer einem Greenfield-Ansatz<br />
macht bei S/4HANA-Berechtigungen<br />
nun keinen Sinn mehr!<br />
Hier bringt es auch nichts zu sagen, wir<br />
räumen auf, weil dies nicht so gründlich<br />
erfolgt wie eine Neuerstellung. Der<br />
richtige Ansatz eines Best Practice ist,<br />
über eine Verbrauchsanalyse aller Nutzer<br />
im aktuellen System festzustellen,<br />
was haben wir wirklich gebraucht, sowie<br />
eine Rollenanalyse im Nachgang<br />
der Verbrauchsanalyse durchzuführen.<br />
Und dann zu klären, wie bilden die aktuellen<br />
Rollen den tatsächlichen Verbrauch<br />
ab? Dann erfolgt die Neuzuordnung<br />
der Lizenzen aufgrund der Verbrauchsanalyse.<br />
Und dafür sind zum<br />
jetzigen Zeitpunkt Tools wie die von<br />
Pathlock unverzichtbar für die kontinuierliche<br />
Kontrolle der Ergebnisse. Das<br />
bezieht sich sowohl auf die Analyse<br />
dessen, was gebraucht wird, als auch<br />
auf die Ergebnisse bei der Neuerstellung<br />
der Rolle und der Berechtigungen.<br />
Eine Empfehlung zum Schluss<br />
Die SAP bietet jetzt ein Tool, mit dem<br />
man auf Knopfdruck ermittelt, ob eine<br />
Rolle teuer wird. Man kann sich dafür<br />
unverbindlich registrieren und die dazugehörige<br />
Excel-Tabelle zeigt, welches<br />
Berechtigungsobjekt in welcher Ausprägung<br />
welchem Lizenztyp zugeordnet ist.<br />
Und man kann einen Testlauf nutzen, der<br />
ausgibt, aktuell wäre eine S/4HANA-Lizenz<br />
exakt so teuer. Gut möglich, dass<br />
dieses Tool für die meisten Unternehmen<br />
einen erheblichen Schreckmoment und<br />
notwendigen Weckruf bereithält.<br />
Ralf Kempf<br />
www.it-daily.net | <strong>März</strong>/<strong>April</strong> 2023