Willkommen zusammen zum Webinar für Access Governance für SAP-Systeme – Direkt aus dem IGA-System heraus. Das heutige Webinar ist unterstützt durch SailPoint und Turnkey. Heute besprechen wir, warum Zugriffskontrollen auch über Systemgrenzen hinweg funktionieren müssen und nicht auf SAP-Systeme ausschließlich beschränkt sein können. Mein Name ist Kai Boschert, ich bin Advisor bei KuppingerCole und werde heute begleitet von Klaus Hild und Sven Pieper, die sich jetzt kurz selbst vorstellen dürfen.
Hallo, mein Name ist Klaus Hild von der Firma SailPoint. Ich arbeite bei SailPoint als Principal Identity Strategist und meine Aufgabe ist es heute, das, was Ihnen der Herr Pieper zeigen wird, mit ein paar Zahlen und technischen Informationen zu untermauern zu unserem Produkt Access Risk Management.
Sven, zu dir. Mein Name ist Sven Pieper, ich bin von der Turnkey Consulting in Deutschland. Ich freue mich dabei sein zu können, einen Aspekt, wie du es gesagt hast, zu beleuchten und Kai bei genau den Dingen zu unterstützen, die er vorbereitet hat. Vielen Dank zusammen. Bevor wir direkt ins Webinar und in die Präsentation starten, möchte ich nochmal kurz auf ein paar Housekeeping-Rules aufweisen. Wir haben einmal Audio, hier werden alle zentral gesteuert, sie müssen sich weder stumm schalten noch entmuten.
Umfragen, wir werden ein paar Polls während des Webinars schalten. Währenddessen haben Sie ca. 30 Sekunden Zeit, auf die Polls zu antworten. Am Ende wird es eine kleine Fragerunde geben, wo Sie während des Webinars jederzeit Fragen in den Chat eintragen können. Diese werden dann in dieser Runde aufgegriffen und beantwortet. Die Vortrage werden natürlich aufgenommen und die Aufnahmen und Folien werden anschließend an das Webinar online auf der Website zur Verfügung gestellt. Bevor ich in meine Präsentation direkt starte, würde ich gerne mit einer Umfrage beginnen.
Und zwar geht es einmal um, welche Line-of-Business-Applications oder Business-Anwendungen sind in Ihrem Unternehmen im Einsatz. Dafür gibt es vier verschiedene Antwortmöglichkeiten, hauptsächlich traditionelle SAP-Lösungen, sowohl traditionelle als auch moderne SAP-Lösungen. Eine Mischung aus modernen Software-as-a-Service, Line-of-Business-Anwendungen von verschiedenen Anbietern oder ein sehr durchmischtes Software-as-a-Service, Line-of-Business-Application-Landscape mit sehr vielen verschiedenen Anbietern. Ich habe jetzt 30 Sekunden Zeit, die Umfrage zu beantworten. So.
Kurz zu meiner Präsentation bzw. was ich kurz abhandeln möchte. Ich möchte Ihnen heute ein bisschen näher bringen, wie sich die Systemlandschaft in der Vergangenheit verändert hat und warum es dadurch dringend notwendig ist, seine Herangehensweise zu IGA oder auch zu Applikationen, zum Zugriffsmodell oder auch zu SOD in dieser neuen Architekturlandschaft anzupassen und wie man das Ganze dann am besten auch machen muss oder könnte. Wird dann auch der Kollege wahrscheinlich ein bisschen mehr drauf eingehen. Landschaft von den Line-of-Business-Applikationen ist im Wandel.
Ursprünglich sind wir von ausschließlich On-Prem-Lösungen zu immer mehr Cloud-Lösungen gekommen und wir sehen und verzeichnen auch, dass immer mehr Cloud-Lösungen in die Architekturlandschaft mit Einzug halten und dadurch auch das Angebot von Applikationen und Anbietern einfach viel variabler wird und dadurch auch neue Lösungen dieser zu orchestrieren und managen einfach auf den Markt kommen müssen und auch vorhanden sein müssen, um eben das Risiko innerhalb des Unternehmens immer noch manageable zu gestalten und auch transparent machen zu können.
Getrennt dazu ist ganz klar Access-Control und Sicherheit, einmal für SAP, aber auch für mehr. Das heißt Line-of-Business-Applikationen, klassisch wie SAP, die immer weiterhin ausweiten, wie zum Beispiel in einem Workforce oder, oder, oder, die dann einfach unterschiedlich gemanagt werden müssen und das Ganze dann einheitlich auch gemanagt werden muss. Dafür muss man aber auch weggehen von dem klassischen Modell, dass einfach die Applikation einen klassischen Use-Case bedienen muss, sondern immer viel mehr liefern muss, also auch ein Business-Value dahinter stehen muss.
Also nicht mehr wie zum Beispiel bei GRC, dass es eine normale Checkbot-Compliance ist, die einfach nur für Auditoren gedacht ist, dass man sagt, man hat folgende Regulatorien und Policies, die durchgesetzt werden, sondern viel mehr, dass man Einsicht in Prozesse gewinnen kann und daraus dann nützliche Controls etablieren kann, die dann eben einen Schlüssel zum Erfolg bieten. Wie schon erwähnt, erweitert sich die Landschaft immer weiter und weiter. Sie wird immer breiter und dadurch brauchen natürlich auch Business-Systeme Veränderungen. Diese verändern sich.
Es gibt Software-as-a-Service-Applikationen und immer mehr Hersteller, die in die Systemlandschaft eindringen und auch verwendet werden und diese müssen auch betrachtet und gemanagt werden. Benutzer müssen auch identifiziert und mitgenommen werden. Die meisten Business-User sind für diese ganzen technischen Eager und Compliance-Regulatorien nur in Hinsicht von Business-Prozessen, also Geschäftsprozessen integriert und verstehen hauptsächlich die Geschäftsprozesse, mögen jedoch nicht diese sogenannten T-Codes um einfach tief in die technische Seite eindringen zu können.
Und daher muss man auch das Ganze in einer managebaren Übersicht auf eine Art und Weise gestalten, dass es eben auch die Business-Anwender verstehen können. Gleichzeitig müssen Applikationen dabei effizient und flexibel gestaltet werden.
Zum einen, es gibt Änderungen in der SAP-Welt, aber es gibt auch Änderungen in den anderen Lösungen, die mittlerweile verwendet werden und daran müssen die Nutzer angepasst werden und diese müssen natürlich dann auch die Funktionalitäten von einem einheitlichen Compliance-Modell mitnehmen können und dieses Modell muss auf jede Applikation mit integriert werden können, egal wie schnell diese sich entwickelt und ob sie sich schnell oder weniger schnell verändert.
Hier sieht man auch nochmal ganz klar, links unten in der Grafik, von dem traditionellen Modell eines einzelnen Vendors On-Prem, wie sich die Systemlandschaft dahin entwickelt, dass es wenige Vendoren in dem hybriden Modell und der Trend ganz klar zu vielen Vendoren in einem hauptsächlich Software-as-a-Service getriebenen Modell entwickelt.
Dabei modernisieren sich natürlich die Architekturen innerhalb der Lösungen und Software-as-a-Service als Trend, gibt natürlich auch jede Menge Möglichkeiten über APIs moderne Orchestrierungslösungen für Line-of-Business-Applikationen zu nutzen und somit verschiedene Anwender oder Vendoren und verschiedene Applikationen als Punktlösung einsetzen zu können.
Viele Unternehmen haben jedoch immer noch einen bevorzugten Anbieter oder sind gar in einer hybriden Lösung mit wenigen Vendoren oder Applikationen auf eine Art gefangen, weil sie eben nicht so einfach diesen Shift hin zu einer SaaS-Applikationslandschaft hinkriegen, weil eben die ganze Orchestrierung und das Management nicht so einfach ist und dadurch eben auch Hindernisse entstehen. Wie können wir das Ganze jetzt jedoch machen?
Es reicht nicht nur, die einzelnen Applikationen getrennt zu betrachten, wie ich es bereits gesagt habe, dahingehend auch, wie die einzelnen Vendoren sich etabliert haben in den Unternehmen und die Unternehmen in einem Art hybriden Netz gefangen sind, weil sie eben nicht den Sprung schaffen auf diese einzelnen Line-of-Business-Punktlösungs-Applikationen mit einem einheitlichen Compliance- und Governance-Modell. Dahingehend benötigt man eben eine einheitliche Lösung über alle Line-of-Business-Applications.
Dafür benötigt man natürlich auch ein solides und ausgefuchstes IT-Asset-Management mit allen Applikationen, damit eben auch keine Applikationen herunterfallen oder alle Applikationen über das Unternehmen hin betrachtet werden und braucht somit eine ganz umfassende Darstellung aller End-Assets, um somit ein kumuliertes Risiko über alle Applikationen hinweg darstellen zu können. Wie schafft man nun eine solche Breite zu erstellen über oder innerhalb des Unternehmens?
Wie schafft man es, diese Breite an Applikationen abzudecken und Identity Governance über alle Applikationen hinweg aufzubauen? Hier muss man ganz klar zwischen zwei verschiedenen Themen unterscheiden. Einmal EGAR als Identity Governance and Administration und ARM, Application Risk Management. Es gibt Überschneidungen bei den beiden Sachen, aber ich fange erstmal bei EGAR an. EGAR konzentriert sich hauptsächlich auf den Benutzerlebenszyklus und dessen Management um die Identitätsbereitstellung und die Zugriffsverwaltung.
Es hat somit ein sehr breites Spektrum von Anwendungen von der Infrastruktur bis zu Line-of-Business-Applications. EGAR befestigt sich nicht nur mit Line-of-Business-Applications, sondern über alle Applikationen im Unternehmen hinweg. ARM hingegen schaut sich eine Applikation in der Tiefe an. Das ist somit ein Unterschied zum einmal EGAR in der Breite zu nehmen und ARM in die Tiefe zu gehen.
ARM in Hinsicht auf Line-of-Business-Applikationen, wie diese eben in ein gewisses Risk-Portfolio eingeordnet werden kann, wie und welche Regelbücher und Rollenoptimierung für jene Applikation etabliert werden kann und eben auch SAP-spezifische Funktionen auf diese Applikationen in Betracht gezogen werden, während EGAR eine Unterstützung für eine breite Palette von Anwendungen her ist. Wie man in der Grafik sieht, ist hier auch ein Schnittpunkt zwischen den beiden Modellen abgebildet, also einmal EGAR links, ARM rechts.
Das ist zum einen die Bereitstellung der Benutzerlebenszyklus und dessen Verwaltung, Zugriffsüberprüfung und zum Beispiel SOD-Kontrollen, um ein paar Beispiele hier zu nennen, die eben als Schnittpunkt zwischen den beiden Feldern genannt werden können. Somit kann man hier auch nicht sagen, muss ich mich zum einen auf EGAR fokussieren oder auf ARM, sondern es ist vielmehr ein Zusammenspiel zwischen den beiden und es ist schwierig zu verstehen, was man davon braucht. Es ist immer ein sehr individuelles Feld und ein individuelles Szenario für jedes Unternehmen.
Wenn man dann von der Breite aus dem EGAR in die Tiefe reingehen möchte, stehen natürlich die LOB-Anwendungen im Zentrum des Fokus, weil diese natürlich businesskritisch sind. Hier gibt es unter anderem drei Hauptkategorien, die spezifische Anwendungen an LOB-Anwendungen von dem ARM erfüllen müssen. Betrachtet man zum einen erstmal die Users, hier auf der linken Seite der Folie, ist hier ganz klar die Verwaltung von Nutzern, vor allem innerhalb der LOB-Anwendungen gemeint.
Gleichzeitig muss man auch mit dem Shift in eine immer modernere Architekturlandschaft gleichzeitig Legacy-Spezifika mit betrachten und darf diese natürlich auch nicht vergessen. Diese dürfen nicht hinten anstellen, da diese weiter in Betrieb sind. Gleichzeitig braucht man hier eine enge Integration mit HR oder HCM-System, um eben auch User Lifecycle-Modelle entsprechend abbilden zu können und zu sehen, wo gibt es gegebenenfalls Shifts von Usern, Wechselziele, Abteilungen oder anderes.
Betrachtet man Entitlements, betrachtet man am besten die Unterstützung spezifischer Mehrstuferberechtigungsmodelle bis in die tiefste Ebene, also bis zum T-Code hinein, betrachtet auf SAP.
Zum anderen muss man natürlich auch Rollenoptimierung, also Best Practices aus der Wirtschaft, aus dem Markt heraus mitnehmen und diese dann auch mit etablieren, damit eben auch nicht nur die Line-of-Business-Applikationen sich verändern oder auch nicht nur die Management-Systeme sich verändern, sondern auch die ganzen Prozesse dahin und Rollen dahinter, die sie sich optimieren und dadurch effizient bleiben.
Des Weiteren eine automatisierte Generierung von Berechtigungen während der Markteinführung, um eben auch diese effiziente Etablierung von Programmen oder von Applikationen mit in das Unternehmen mitnehmen zu können. Betrachtet man Governance, muss man natürlich in erster Linie ein tiefgreifendes Management von SOD-Kontrollen mit betrachten. Hier einmal gibt es natürlich SOD-Kontrollen innerhalb von Applikationen, jedoch auch SOD-Kontrollen innerhalb von Vendoren, was natürlich relativ gut funktioniert, da die Vendoren an sich schon anbieten.
Interessant wird es dann hier, um dann wieder von der Tiefe in die Breite zu gehen, was passiert, wenn man von der Applikation auf weitere Applikationen sprengt. Darauf kommen wir aber später nochmal. Und eine Unterstützung von Standard-SOD-Kontrollen und kritischen Berechtigungen über Regelbücher hinweg.
Dadurch kann man natürlich das ganze Application Risk Management utilisieren, um eben das Risiko in das Unternehmensrisikomanagement mit zu integrieren, da man sieht, welches Risiko tragt die jeweilige Applikation und was muss sie tun, damit diese sich verändert oder mitigiert werden kann. Wie können wir Sicherheiten zum Beispiel gewährleisten für solche Applikationen? Es ist einmal der administrative Effizienz und Workflows von Automatisierung und Self-Service, die eben einen gewissen Grad an Sicherheit für solche Prozesse gibt.
Wir brauchen Management und Kontrolle, eine einheitliche Administration aller Identitäten auf allen Systemen Einheitliche Administration aller Identitäten auf allen Systemen in einer hybriden Realität der digitalen Transformation bedeutet nicht nur einzelne Applikationen betrachtet, sondern über alle Applikationen, über die gesamte MSS hinweg. Sicherheit und Vertrauen, wir müssen Identitäten absichern, Zugänge und Berechtigungen mit starker Authentifizierung versehen, damit diese auch so genutzt werden, wie sie vorgesehen sind und Compliance und Governance.
Wir müssen wissen, wer hat auf was Zugriff, wer sollte Zugriff haben und wie dieser Zugriff genutzt ist. Also das Regelwerk, das dahinter steht. Das ganze Umsetzen. In modernen Lösungen heute müssen wir natürlich diese Breite und Integration über alle Anwendungen hinweg bereitstellen. Es müssen alle Betriebsmodelle abgebildet werden können und es muss in eine breite Integration, in ein breites IT-Ökosystem vorhanden sein. Das heißt, man muss alles miteinander verbinden, um damit alles miteinander betrachten zu können.
Man muss gleichzeitig in die Tiefe gehen, also detaillierte Informationen in der erforderlichen Tiefe bereitstellen und anwendungsspezifische Funktionalitäten aufzeigen, um daraus eine fundamentale Analyse kreieren zu können und damit die wichtigen Informationen auch bereitgestellt zu erlangen. Gleichzeitig Effektivität und Effizienz. Effektivität hier das Richtige machen, Effizienz es richtig machen.
Das heißt, was muss ich tun, damit mein Problem gelöst wird und gleichzeitig muss ich das natürlich auch richtig machen, damit eben auch der Fokus auf dem liegt, was wirklich benötigt wird. Also eine konkrete Delivery für das Problem. Dadurch kann man jetzt sagen, IGA und ARM muss miteinander integriert sein. Das ist eine Kombination zwischen den beiden Dingen.
Einmal zwischen Identity Governance und Administration, um Benutzerlebenszyklen, Bereitstellung und Existence Governance für alle Systeme bereitstellen zu können und eben auch ein Cross Systems SOD zu etablieren, um das gesamte Risiko der Applikationslandschaft im Unternehmensrisiko mit aufzufassen und nicht nur ein Application Risk Management und CIG auf die jeweiligen einzelnen Applikationen, sondern wie eben gesagt über alle Applikationen hinweg aufgespannt zu kreieren. Vielen Dank für Ihre Aufmerksamkeit.
Bevor ich jetzt an meine Kollegen von SailPoint und Turnkey weitergebe, würde ich gerne noch zwei weitere Polls schalten. Einmal, wie schätzen Sie den Reifengrad der implementierten Existence Governance über Ihre Line of Business Applikation hinweg ein? Hier gibt es auch wieder vier Antwortmöglichkeiten.
Sehr gut, gut, ausbaufähig und rudimentär. Sie haben auch hier wieder 30 Sekunden. Vielen Dank für die Antworten und in Anschluss auf diese Frage habe ich natürlich direkt auch noch, planen Sie denn in diesem Jahr an Investitionen um Existence Governance Funktionalität für Ihre Line of Business Applikation weiter auszubauen oder zu modernisieren? Unter 100.000, zwischen 100.000 und 500.000, 500.000 und einer Million oder über einer Million Euro? Vielen Dank für die Antworten auch hier wieder. Und dann möchte ich an Klaus weitergeben für seine Präsentation. Viel Spaß dabei.
Vielen Dank. Wir haben uns jetzt hier einfach auf das Access Risk Management, also auf den Armteil, fokussiert, von dem, was Sven eben erzählt hat.
Einfach, was Kai eben erzählt hat, einfach um jetzt wirklich den Fokus in dieser kurzen Zeit darauf zu richten. Für uns natürlich selbstverständlich, dass alles, was mit dem Access Risk Management passiert, sich wiederfindet einem IGA-System, das wir natürlich auch mit anbieten.
Sven, geh einfach mal auf den ersten Slide. Da Sven einfach sehr viel über die Fähigkeiten von Arm zeigen wird und was man mit Arm machen kann, wie das in die Tiefe geht, habe ich mich jetzt einfach darauf beschränkt, einfach mal ein paar Zahlen zu liefern, damit Sie damit einfach ein bisschen was anfangen können. Warum machen wir das überhaupt? Was war die Idee, dass wir überhaupt mit sowas um die Ecke kommen? Das war mir einfach wichtig, da mal so ein bisschen Licht drauf zu werfen, dass man da ein bisschen mehr sieht dazu. Ich finde solche Zahlen immer ganz wichtig.
Wir machen das mit internationalen Firmen, wir fragen Auditoren, wir fragen auch große Unternehmen, die solche Umfragen regelmäßig machen, wie eine IBM beispielsweise. Wo sehen Sie denn, wo die Unternehmen momentan heute hinlaufen? Also diese Zahlen sind nicht von uns gewürfelt, wie sie uns gerade passen, sondern da stehen in aller Regel Umfragen dahinter oder wir dienen uns irgendwelcher Umfragen, die bereits getan worden sind.
Und die GSC, also Risk Governance Compliance Strategie und die Investitionsfaktoren dazu, das ist schon so, dass die Unternehmen heute realisieren, dass tatsächlich ein Paradigmenwechsel stattfindet im Moment. Der eine oder andere von Ihnen aus dem Call kann sich vielleicht noch an den Shift vor vielen Jahren erinnern, wie wir vom Mainframe auf die dedizierten Serverlandschaften gegangen sind. Es kann sich heute kaum noch jemand vorstellen, IT ausschließlich mit Mainframes zu betreiben.
Wir haben im Moment einen ähnlichen Shift von den On-Prem-Anwendungen auf die richtigen Cloud-Anwendungen, also Multitenant, Microservice-basierend, weil einfach dort die Entwicklung schneller und angenehmer läuft. Ich muss mich um keine Hochverfügbarkeit mehr kümmern, um keine Skalierbarkeit mehr kümmern. Also es gibt einige Vorteile davon. Sicherlich ist nicht alles, was neu ist, sofort perfekt. Man muss also alles mit Vorsicht zugenießen. Aber wir sehen in dieser digitalen Transformation, sehen wir einfach auch das Durchnehmen, laufen momentan. Es wird Technologie einfach erneuert.
Das sind mehr als die Hälfte, die davon betroffen sind. Wir finden aber auch aus diesen Unternehmen, die diese technische Migration durchlaufen, sind 71 Prozent, also gut zwei Drittel, die davon ausgehen, dass es eine Integration zwischen diesen Governance and Risk Compliance Anforderungen und den betrieblichen Anwendungen gibt. Also jetzt ist SAP sicherlich ein ganz prominentes Beispiel, gerade hier für uns im deutschsprachigen Raum. Das gilt aber auch natürlich für alle möglichen anderen Anforderungen. Auch eine AD oder ein Azure ist davon nicht losgelöst.
Auch dort müssen in irgendeiner Form GSE Anforderungen berücksichtigt werden. Und natürlich, das ist klar, da geht der Weg von SAP hin. 95 Prozent der Unternehmen planen eine Migration in Richtung SAP H4, S4 HANA. Und da ist natürlich eine gewaltige Forderung, also auch über zwei Drittel, die sagen, hier müssen mehr Dinge verwalten, automatisiert werden. Also ein ganz wichtiger Punkt, das ist ein ganz praktisches Thema. Nächsten Slide bitte. Warum ist das jetzt eigentlich so?
Also der eine oder andere, dem mag das vielleicht gar nicht bewusst werden, was das jetzt eigentlich bedeutet, aber das klassische ECC von SAP, wo eben in einem System im Prinzip diese Anwendungen laufen und aufgehoben sind, ändert sich mit S4 HANA auf eine andere Ebene. Die Systeme, also wie in Hypress, Ariba, Conco, also Sie kennen die Sachen wahrscheinlich besser als ich, die sind auf einmal außerhalb von der Kernapplikation. Das heißt, ich habe einen ganz anderen Anspruch.
Während ich noch auf der alten Schule konnte ich halt eben noch aus einem einzigen System heraus berichterstattende Dinge tun. So bin ich jetzt im Prinzip gefordert, das für viele Dinge zu tun. Und wenn man das jetzt für jedes System einzeln machen würde, auch wenn die Systeme vielleicht Überwachung zulassen oder unterschiedlich Überwachung zulassen, hätte ich dann trotzdem einen Flickenteppich von den verschiedenen Überwachungsoptionen, die mir bleiben. Ich brauche also eine Klammer, die da drum herum geht. Nächster Slide bitte.
Dazu würde ich einfach noch mal ein paar, kannst ruhig mal dreimal klicken, dass wir das ganze Slide sehen. Ich wollte jetzt kein betreutes Lesen machen, sodass Sie einfach schon mal schauen können. Wir sehen also diese, das ist immer so das übliche Marketinggeklappe, aber mir sind diese Zahlen wirklich wichtig, weil ich kann es gar nicht oft genug sagen, wir haben heute immer noch, und ich, überlegen Sie, Identity Management ist seit mehr als 20 Jahren am Markt.
Wir haben heute immer noch das bis zu drei Viertel aller Angriffe, die im Unternehmen stattfinden, und jedes Unternehmen wird angegriffen. Es ist keine Frage, ob, es ist nur eine Frage, wann und wie oft. Also wirklich jedes Unternehmen ist betroffen, und es sind Insider-Bedrohungen. Wir reden gar nicht von, dass von außen irgendwas gehackt werden, und Insider-Bedrohungen, das sieht immer so aus wie, meine Jungs machen sowas nicht, ich kann mich auf meine Jungs verlassen.
Ja, das mag sein, aber dieses berühmte Social Hacking, dass also von jemandem die Identität geknackt wird, oder eine verwaiste Identität für Dinge benutzt wird, die ihm überhaupt nicht gefallen, das sind diese Insider-Bedrohungen mit inkludiert. Das heißt also, diese bis zu drei Viertel der Angriffe, die einfach von existierenden Accounts nicht sorgfältig überwacht worden sind, das ist ein Fakt.
Das ist also nicht, was wir uns ausdenken, um irgendeinem Sackdeckel zu klappern, sondern es ist tatsächlich so, dass da einfach viel zu wenig getan wird, und natürlich, die Zahlen ändern sich natürlich auch nicht, weil die Firmen immer offener werden, transparent darüber zu reden, was tatsächlich passiert. Sie brauchen sich nur diesen IBM-Report mal anzugucken, den Cost of a Threat. Da sind Zahlen drin für die deutschen Unternehmen, da werden sie vielleicht eher erschrocken sein.
Und daraus geht auch unter anderem hervor, dass Unternehmen bis zu 5% ihrer Einnahmen, also nicht gewinnen, sondern ihre Einnahmen, einfach verloren gehen. Die sind einfach weg. Jetzt denkt man ja, 5%, ein bisschen schwund ist immer, was soll's. Das war das Gesetz der Thermodynamik. Aber auf der anderen Seite, wenn sie 50 Millionen machen im Jahr, reden wir von zweieinhalb Millionen. Das ist kein Kleingeld mehr. Da muss man schon mal drüber nachdenken. Das ist bis zu 5%. Natürlich gibt es auch Leute, die verlieren vielleicht weniger.
Vielleicht gibt es auch Leute, die verlieren mehr, je nachdem, ob es da wirklich einen Grund gab. Aber es ist auf jeden Fall eine Zahl, die man durchaus ernst nehmen kann, weil hier liegt wirklich Tisch auf dem Geld, was leicht verdient ist, wenn man ein bisschen mehr sich um Security kümmert. Am erschreckendsten finde ich die Zahl, die Vervielfachung dieser Threats. Ob da jetzt eine 3 steht oder eine 2,5 steht oder eine 4 steht, das sei mal dahingestellt, das ist jetzt seit 2016. Wir schreiben 20, 23, 22 ist abgelaufen.
Überlegen Sie doch mal, ob sich Ihr IT-Budget, also Ihr IT-Team auch ums Dreifache erhöht hat. Einfache Frage, einfache Antwort. Ich tippe mal auf möglicherweise nicht. Das heißt also, wenn hier die Häufigkeit zunimmt, mit der Sie sich eigentlich wehren müssten, dann müssten auch Ihre Möglichkeiten steigen. Wenn Sie das nicht vom Geld her realisiert bekommen, beziehungsweise vom Manpower realisiert bekommen, dann müssten Sie es halt mit Technik machen. Die Technik wäre da. Man muss sie halt nur einsetzen. Das ist eigentlich alles.
Schon wie Kai gesagt hat, das muss natürlich clever passieren. Man muss nicht nur das Richtige tun, sondern muss es auch richtig machen. Das ist vollkommen richtig. Aber wir sind da schon dabei. Ich glaube, wir haben hier einiges im Portfolio, wo wir den Kunden, die sowas interessiert, oder Leuten, die sagen, würde ich mir gerne mal näher angucken, schon viel Content liefern können und viel Input liefern können, die Dinge tatsächlich auch richtig zu bewerten.
Und das ist eine Zahl, die mich wirklich erstaunt hat, muss ich sagen, als ich das erste Mal gehört habe, dass 77 Prozent der weltweiten Transaktionen SAP betreffend, und das war mit einer der Gründe, warum wir uns entschlossen haben, sowas wie ARM zu bauen. Wir haben das nicht alles selbst erfunden. Wir haben uns eine Firma gekauft, die dieses Knowledge-Bite hat. ARM wird bei uns jetzt ausgebaut in andere ERP-Systeme auch, aber der Fokus liegt im Moment ganz klar auf SAP-Systemen. Der nächste Slide, bitte. Und was ist jetzt dieses ARM überhaupt?
Aktuell ist es eine Access-Kontrolllösung für SAP. Also wir können SODs auch zeigen dabei. Wir machen viele Dinge, also das lesen können Sie selbst, von der Senkung der Migrationskosten bis hin zu einfach ausreichenden Kontrollen. Für Audit ist eigentlich alles drin, was man braucht. Das Wichtigste für mich ist einfach das Verhindern von betrügerischen Aktivitäten. Nicht jedes SOD, das gefunden wird, ist wirklich schädlich oder sofort destruktiv zu bewerten. Da kann Sven dann sicherlich mehr zu erzählen, als ich das jetzt kann, aber wir zeigen zumindest auf, was eben gefunden wird.
Nächster Slide, bitte. Und wir machen das mit einem Dashboard, starten wir, das wirklich intuitiv und einfach zu lesen ist. Also das ist natürlich nicht lesbar. Man könnte es zwar lesen, aber es ist nicht lesbar. Wie gesagt, die Slides werden hochgeladen. Vielleicht kann man da mehr sehen, aber wir freuen uns natürlich auch, wenn eine Demoanfrage kommt dazu. Aber was Sie hier beispielsweise sehen, ist das Aufzeigen von der SOD, die wir gefunden haben, und wir zeigen einfach, welche Seite, also eine SOD hat ja immer zwei Seiten.
Ich möchte, dass die eine Seite gegen die andere Seite nicht gleichzeitig von jemandem ausgeführt wird. Und wir zeigen auf, welche dieser Seiten wie häufig benutzt wird und von wem natürlich. Also das hier ist ein Dashboard, in dem man drill down kann, man kann also reinklicken und kann dann eben sich durchwühlen. Man kommt bis auf die Transaktionsdaten hinunter und nicht mehr auf die T-Codes. Wir lösen auch bis zu der Autorisierungsebene. Also Sie kriegen schon jede Menge Informationen und auch Vorschläge, wie Sie es verändern können.
Also wir zeigen Ihnen, ob SODs zwar vorhanden sind, aber beispielsweise eine Seite von diesen SODs überhaupt nicht benutzt worden sind. Dann sagen wir, das kannst du beispielsweise auch auflösen, ohne Sorge, das ist nicht benutzt worden. Und damit ist man zumindest mal wieder eine Sorge los, sage ich mal ganz salopp. Aber das geht natürlich viel weiter, ist natürlich viel mehr. Diese Playbooks, da wird, denke ich, Sven noch mehr drüber erzählen. Das ist eine Sache, die wir zu 100% bedienen können dabei.
Wir liefern einen Grundplaybook mit, aber Sie können natürlich auch Playbooks benutzen von allen möglichen Firmen und ich weiß, dass die Turnkey da auf 15 oder mehr Jahre Erfahrung zurückblicken kann. Also Sie können da wirklich sehr viel Gutes für Sie tun. Den nächsten Slide bitte. Das Wildeste für mich war, wie wir ARM das erste Mal gesehen haben und das erste Mal damit gearbeitet haben, dass dann die Kollegen gesagt haben, in 60 Minuten sind sie installiert. Das war ein netter Versuch, 60 Minuten Installation, ich bin lange drin in der IT, muss mir nichts erzählen, das geht nicht.
Und dann habe ich mich eines Besseren belehren lassen, das geht sehr wohl. Natürlich sehen viele Leute aus der IT-Installation von dem Moment, wo jemand die Tür betritt und dann sagt, ich bin fertig. Und das ist natürlich länger als 60 Minuten. Das dauert also mindestens mal 65 Minuten. Das war ein Scherz. Also das dauert natürlich länger.
Aber die Tatsache, dass ich halt tatsächlich nur einen Service installieren muss auf einer Virtual-Maschine, wie immer auch auf einem Windows-Server, der muss nicht mal ein Domain-Controller sein, also auf irgendeinem Windows-Server, muss ich einen Service installieren. Der muss natürlich mit einem vorher bekannten Proxy-User sich gegen das SAP-System connecten, wir lesen das SAP-System aus. Und dann wird dann die Instanz gesagt, also diese ARM-Instanz läuft auf Azure in Irland, wird eben dorthin geschickt und in dem Moment, wo diese Information dort liegt, kann sie auch analysiert werden.
Also das System zeigt sofort anhand des existierenden Playbooks, was hat es gefunden, was gibt es für Probleme und was das für Probleme sein könnten. Da wird Ihnen Sven jetzt einfach mehr dazu erzählen. Gehen wir auf den nächsten Slide. One more thing, kennt jeder von uns. Wenn Sie dazu mehr wissen wollen, wir sind auf diesen DSA-Technologietagen, also der SAP User Group. Sie finden uns dort. Das ist im Mai, glaube ich. Ich hätte das Datum hinschreiben müssen, mein Fehler, aber Sie sehen die URL, da können Sie eben dorthin gehen.
Wir sind mit der Turnkey dort und können dort Reden und Antworten stehen. Wir haben da sicherlich auch eine Demo dabei, dass Sie sich das Tool einfach mal live und in Farbe anschauen können. Und was da eben genau damit geht, das wird Ihnen jetzt Sven näher bringen. Besten Dank. Vielen Dank, Klaus. Der Termin ist tatsächlich im März, nicht erst im Mai, das heißt also noch gar nicht so lange hin.
Ja, wir freuen uns drauf. Ich glaube, das ist letztendlich auch eine gute Gelegenheit, wirklich mal ins Detail zu gehen, sich mal kundenspezifische Sachen oder Herausforderungen anzugucken und anzuhören und entsprechend ja, dann auch Antworten zu finden. Letztendlich ja, das dann wirklich auch zu ja, individuell zu besprechen. Gut.
Ich denke, was bisher klar geworden ist, ist schlicht und ergreifend die Komplexität soll nicht sagen, dass die Komplexität bisher nicht gegeben war. Ich glaube, jeder, der SAP-Systeme im Hinblick auf Benutzer und Berechtigungen betreut, da Aufgaben übernommen hat, sei es in der Berechtigungsentwicklung, in der Berechtigungsbereitstellung, aber auch in der Zuordnung dann letztendlich in Richtung Benutzer, der kennt diese Komplexität.
Sie wird jetzt, und ich denke, das ist, wie gesagt, ausführlich schon dargestellt von Kai hier, Klaus, die wächst natürlich noch, Stichwort hybride Welten, Stichwort Cloud-Anwendungen. Es wird insgesamt komplexer, aber es wird natürlich auch und nochmal aufgegriffen, was Kai vorhin sagte, in die Tiefe gehen, ja, es wird natürlich auch noch fachlich eine ganze Schippe draufgelegt, an Wissen, was ich brauche, um hier letztendlich dann ja, zu diesem Management der Benutzer respektive der Zugänge, der Berechtigungen zu kommen.
Jetzt ist diese Komplexität für mich, für diesen Vortrag natürlich eine Herausforderung gewesen. Ich glaube, auch eine Lessons learned, eine Erfahrung ist die, man muss sich auf etwas konzentrieren. Worauf ich raus will, ist, ich habe Ihnen ein Beispiel mitgebracht, ein konkretes, nicht sagen, dass es da nicht gefühlte, eben genau Komplexität, dass es nicht gefühlte tausend andere gibt, aber für mich ist wichtig, nicht vor dem riesen Berg zu scheitern, sondern wirklich Schritt für Schritt sich Aufgaben, Herausforderungen zu widmen und genau das habe ich gemacht.
Wir haben in den Vorträgen bereits gehört, SOD, sprich Funktionstrennungen, Segregation of Duties ist eine große Herausforderung, die wir haben im Zusammenspiel mit den Anwendungen beziehungsweise mit den Funktionalitäten in der Anwendung von SailPoint Access Risk Management, was Klaus eben vorgestellt hat, habe ich einfach, wie gesagt, mitgebracht, ein konkretes Beispiel, wie es sozusagen angegangen werden kann. Also das heißt, was bedeutet so eine Access Governance für SAP-Umgebungen konkret? Beziehungsweise, ich habe schon angesprochen, was ist die Herausforderung?
Die Herausforderung denke ich ist ein Monitoring von sensitiven, kritischen Berechtigungen bis hin zu Funktionstrennungskonflikten.
Also die Lösung dabei, und ich denke, das ist wichtig, weil es für so viele Herausforderungen aktuell die Antwort ist, ist Transparenz zu erhalten, Informationen zu haben, mit denen ich Bewertungen vornehmen kann, mit denen ich Aktivitäten starten kann, Maßnahmenkataloge, letztendlich Transparenz durch einen SOD Health Check nachzuschauen auf meinen Systemen, für meine Systeme, welche Benutzer, beziehungsweise auch welche Rechte, wenn ich das so als Bausteinprinzip nehme, welche Rechte haben denn Funktionstrennungskonflikte, und das beginnt natürlich bei der Einschätzung, welche meiner Berechtigungen sind sensitiv, respektive was würde ich als kritische Berechtigungen einstufen wollen.
Die Idee, und es ist eben schon angeklungen, mal Beispiele, was brauche ich dafür oder beziehungsweise, wo bewege ich mich mit diesem Monitoring hin, ist letztlich die Information Benutzer haben Risiko, also die Zuordnung idealerweise nach Geschäftsbereichen. Warum? Weil ich natürlich in der Folge dann, ich habe es schon angesprochen, Maßnahmenkataloge, ich will ja diese Information nutzen, um besser zu werden, um meine, möglicherweise Berechtigungskonzepte oder das Berechtigungskonzept entsprechend zu optimieren.
Was mir auch hilft ist, auch das ist schon angeklungen, ich glaube, das ist ein ganz wichtiger Punkt, Benutzer mit tatsächlich ausgeführten Risiken. Es ist natürlich wichtig zu wissen, wo sind meine Risiken generell? Ich glaube aber entscheidend, wieder im Hinblick auf Optimierungen, wieder im Hinblick auf Maßnahmenkataloge ist, werden sie denn wirklich ausgeführt? Ich weiß aus eigener Erfahrung, dass das immer ein großer Unterschied ist. Natürlich will ich möglichst risikofrei Dinge zuordnen beziehungsweise implementieren, zur Verfügung haben.
Am Ende des Tages ist es aber entscheidend, werden denn diese Dinge wirklich genutzt? Werden sie wirklich ausgeführt? Warum ist das auch entscheidend? Weil ich denke, man hat nicht das gesamte Budget, beziehungsweise die gesamte, was man eigentlich bräuchte, um alles abzudecken, um alles zu optimieren. Lange Rede, kurzer Sinn. Wir reden über Priorisierungen und zur Priorisierung natürlich trägt auch dazu bei, was ist ausgeführt worden, aber, und Sie sehen es rechts unten, tatsächlich die Priorisierung nach High- oder Medium-Risks.
In der Regel, so erlebe ich das bei den Kunden, werden natürlich High-Risks, macht ja auch Sinn, zuerst angegangen und das zumindest mal so gesteuert, dass ich diese High-Risks nicht weiterhin habe. Um Ihnen zu helfen, beziehungsweise mal klar zu sein, was wird denn verstanden unter kritischen respektive sensitiven Berechtigungen versus von Funktionstrennungskonflikte oder Funktionstrennungsrisiken. Ich habe Ihnen zwei Beispiele mitgebracht, damit man das mal greifen kann.
Eine kritische Berechtigung wäre beispielsweise die Pflege von Benutzer, Stammsätzen von Benutzern im System, also darunter natürlich auch so Dinge zu sehen, ich kann mir Benutzer anlegen, auch möglicherweise im produktiven Umfeld, um dort entsprechend auch einen Zugang zu haben. Natürlich ist das alleine als Berechtigung eine sehr sensitive, mit dem kritisch habe ich immer so ein Problem, im Sinne von, es braucht ja Leute, das ist das, was ich sagen will, es braucht ja Leute, die das ausführen.
Letztendlich ist das natürlich eine Berechtigung, wo ich genauer hingucken muss, im Sinne von, ich muss mir klar sein, wer diese Berechtigung hat. Gerne auch kann man das ersetzen mit Kundenstammdaten, Pflegen, das ist vergleichbar, eben genau diese sensitiven Zugriffe, da sind wir wieder bei dem Punkt Transparenz.
Das würden wir als Funktion bezeichnen und Sie merken schon in dem unteren Teil, wenn jetzt zwei Funktionen zusammenkommen, eben genau diese Funktionstrennung, die idealerweise gegeben ist, damit ich mich schützen kann vor Aktivitäten, vor Dingen, die ich so nicht in meinem System zulassen will.
Das heißt, wenn jetzt zwei Funktionen zusammenkommen, ich habe ein anderes Beispiel mitgenommen, nämlich das Ändern von Bankdaten, von Bankverbindungsdaten und dann einen Zahllauf zu starten, also im Grund genommen Überweisungen auf den Weg zu bringen, Geldflüsse aktiv steuern zu können, das beides in einer Hand, ich denke, das ist nachvollziehbar, ist dann natürlich kritisch, mehr als kritisch und das wäre dann das, was wir als Funktionstrennungskonflikt oder zumindest mal als Funktionstrennungsrisiko bezeichnen würden, das heißt also die Kombination von Funktionen.
All das, aber es ist schon angeklungen, können wir in der Anwendung ARM vom SailPoint unterstützt analysieren, können das letztendlich in dieser Komplexität, auch mit Drilldown, wir können also sehr genau diesen Root Cause identifizieren, wieder wichtig, um entsprechende Maßnahmen, Optimierungen entsprechend anzusteuern. Das heißt, warum sind Funktionstrennungskonflikte so gefährlich? Letztendlich immer da, wo Geldflüsse, Abflüsse oder in irgendeiner Form beeinflusst werden können von Mitarbeitern, ist es natürlich klar, dass da eine Bedrohung gegeben ist bzw.
da von der Firma ausgeht, an dem Beispiel anlehnend zu dem Funktionstrennungskonflikt, den ich eben gezeigt habe, wäre es am Ende so, über den gestarteten Zahllauf, ich habe schon gesagt, dann Gutschriften bzw. Geldflüsse dann auf eigene Konten steuern zu können.
Das heißt, die möglichen Folgen dieser Funktionstrennungskonflikte sind klar, wenn man mal bei dem Geld bleibt, finanzielle Schäden, schlicht und ergreifend durch Betrug, natürlich auch die Möglichkeit durch Nichtverbuchen von Waren in diesen Bereichen natürlich auch einen Diebstahl zu ermöglichen, weil ich einfach nicht mehr beispielsweise mich darauf verlassen kann, dass Materialstämme, andere Dinge entsprechend korrekt aktualisiert werden.
Ich habe da natürlich ein Problem im Sinne von Compliance-Verstößen im Rahmen von Wirtschaftsprüfungen, im Rahmen auch möglicherweise von internen Audits. Ich habe aber auch darüber hinaus natürlich Schwierigkeiten beispielsweise in einem Notfall Super-User-Management- Prozess, der ja genau das ermöglichen soll, eben genau diese Funktionstrennungen aufheben soll, aber eben im Rahmen und nur im Rahmen von Notfall oder von Emergency.
Dann greifen natürlich wieder andere Dinge, wie eine Protokollierung, über die ich dann sozusagen wieder die Compliance herstellen kann, aber wenn ich von Haus aus Funktionstrennungskonflikte habe, habe ich natürlich eine Bedrohung meiner unternehmensweiten IT-Sicherheit und letztendlich, um mal auf die SAP-Systeme, auf die SAP-Landschaft zurückzukommen, deren Schutz ist nicht mehr gewährleistet. Und letztendlich, ja, geht es natürlich über die Unternehmensgrenzen hinaus, wir reden über Reputation, wir reden am Ende über das so wichtige Vertrauen meiner Kunden in mein Unternehmen.
Wie gesagt, man kann es wieder umgekehrt beleuchten in Richtung Zahlungen, in Richtung Wareneingänge, all das, was in ihren Geschäftsprozessen entsprechend verfolgt. Welcher Nutzen hat jetzt so ein Health-Check, ein SOD-Check, ein Nachgucken in Bezug auf diese Funktionstrennungen? Letztendlich haben Sie in Ihren SAP-Systemen hochsensible Daten bis hin zu Geschäftsgeheimnissen. Wenn ich an Pharma-Industrien denke, dort werden Rezepturen abgelegt, aber auch andere wie in der Luftfahrtbranche, wo ich einfach hochsensible Kundendaten auch verarbeite.
Letztendlich zusammenfassend kann man sagen, kritische Geschäftsprozesse laufen bei den meisten Kunden in SAP-Systemen ab. Das heißt, sie sind gezwungen, diese Funktionstrennungen, diese kritischen und sensitiven Berechtigungen zu identifizieren, unbewusst und vorhin ist es schon angeklungen, effektiv damit umzugehen, soll sagen, sie auszuschalten, beziehungsweise da, wo es nicht geht, und wir wissen, es geht nicht 100 Prozent, da zumindest so zu optimieren, respektive berühmte Mitigation einzuführen, um wieder diese Compliance zu erlangen.
Das heißt also, für Sie ist wichtig, wie ich schon gesagt habe, zu identifizieren, wo sind sensitive, kritische Berechtigungen? Ziel ist dabei, wieder die Transparenz zu bekommen, auch hier die Transparenz zu bekommen, um dann, ich habe es mehrfach erwähnt, Korrekturen, Optimierungen im Berechtigungskonzept erreichen zu können. In aller Regel sind das dann risikofrei definierte Berechtigungen, sprich Rollen, die man auf dieser Grundlage entsprechend erstellen kann.
Anpassungen und Zuordnungen von Systemrechten, dafür brauchen Sie diesen elementaren initialen Baustein der konfliktfreien Rollen, können Sie natürlich dann in der Benutzeradministration auch verwenden, ohne per se in ein Funktionstrennungskonflikt bei der Zuordnung von Rechten im Benutzerstamm zu laufen. Und dann nicht zuletzt, das ist das, was es oft schwierig macht. Wir brauchen Budget, wir brauchen die Zustimmung.
Ich bin auf dem Wege hin, auch für diese Ansicht, für diese Perspektive kann man ein Business Case erstellen, sprich ein Return on Invest, nämlich ich kann auf dieser Basis bewerten, werde ich denn besser oder bleibt alles so, wie es bisher war. Kurzum noch eine kurze Darstellung, wie läuft so etwas ab? Letztendlich, es ist schon erwähnt worden, wir setzen unser sogenanntes Golden Rulebook ein, das heißt, Sie brauchen ein Regelwerk, wo Sie spezifisch abgestimmt haben, wo Sie Ihre Risiken sehen. Natürlich können Sie starten auf dem Standard, der mitgeliefert wird.
Das ist mehr als nur ein Start. Am Ende des Tages brauchen Sie aber eine individuelle Bewertung. Wir haben einen, wie es hier auch steht, einen Erfahrungsschatz, wo wir aus vielen Unternehmen, aus vielen Projekten unterschiedlicher Größe und Branche zusammengetragen haben. Was wichtig ist, letztendlich das Golden Rulebook gemacht. Wir bewerten daraus dann entsprechend Benutzer und Rollen und können Ihnen mit dieser Prüfung zur Seite stehen.
Das heißt, was haben Sie als Ergebnisse und ich denke, das ist auch nochmal wichtig zu wissen, es hilft mir tatsächlich Benutzer, wir haben verschiedene Screenshots schon gesehen, mit den meisten Risiken respektive in welche Berechtigungsrollen, die dazu geordnet sind, führen dazu. Sogenannte Benutzer-Konflikt-Matrix. Die Darstellung nach Geschäftsbereichen habe ich schon angesprochen. Wichtig auch, wir haben das Dashboard gesehen, eine grafische Darstellung. Warum ist das wichtig? Weil ich schon auch glaube, dass man eine Management-Sensibilisierung braucht.
Da sind wir wieder bei der Teamstärke, bei Budget, im Grunde genommen bei der Ressourcen-Bereitstellung. Und dann der zweite Aspekt, der natürlich immer eine Rolle spielt, ist der Blick aus der Berechtigung an sich, von den Rollen selbst. Es ist ja nicht nur der Benutzer.
Ja, da kommt es am Ende zusammen. Was Sie aber brauchen, ist letztendlich ja auch einen klaren Blick zum Thema risikofrei Berechtigungen und Rollen, sonst sind Sie gar nicht enabled. Und letztendlich haben Sie dann auch zur Verfügung, was auch sehr wichtig ist, was eben genau Ihre Unternehmensspezifika widerspiegelt, eine SOD-Risikomatrix, auf der Sie dann alles aufbauen können. Sie sehen es unten.
Letztendlich die notwendige Transparenz, um dann detaillierte, konkrete Maßnahmen einzuleiten, zur Minimierung, ich habe schon gesagt, wo es gar nicht möglich ist, Minimierung, aber idealerweise natürlich eine Beseitigung von SOD-Konflikten. Wie kann so etwas stattfinden, wie lange dauert das?
Wir, wenn wir das für Unternehmen machen, was wir sehr gerne tun, dann brauchen wir oder setzen wir dafür zehn Tage an. Letztendlich davon benutzen wir in der ersten Woche letztendlich die Daten zu analysieren, überhaupt mal die Grundgesamtheit zu bekommen. Wir machen dann in der Mitte einen Surefix, um einfach auch erste Fragen zu klären.
Wir bereiten das dann auf, wir analysieren das, wir geben Hinweise, also genau das in Richtung Maßnahmenkatalog und kommen dann zu einer, wenn man so will, Abschlusspräsentation, wo wir entsprechende Ergebnisse mit Ihnen als Kunde zusammen besprechen, aber selbstverständlich auch ein entsprechender, was macht Sinn, was macht man zuerst? Also eine Roadmap, so nennen wir das, erstellen, die dann der Optimierung nutzt. Wie gesagt, wir freuen uns auf eine Rückmeldung von Ihnen, wenn Sie Unterstützung brauchen. Wir greifen auf viele Projekte zurück, kommen Sie auf uns zu.
Wir sind sehr gerne und machen das tatsächlich mit viel Erfahrung sehr gerne bereit, dann für Sie individuell zu klären, was ist möglich, was macht Sinn, was ist eine entsprechende Arbeitsinordnung. Dankeschön. Vielen Dank, Sven. Vielen Dank, Klaus, für die super und sehr informative Einführung in die ganze Thematik. Bevor wir jetzt zum Ende kommen, würde ich noch gerne ein paar Fragen aus dem Publikum abklären. Wir haben sehr lange und intensiv über das Thema jetzt gesprochen, daher ist die Zeit für die Fragen etwas knapp.
Ich möchte jedoch alle Teilnehmer dazu anhalten, egal, ob jetzt die Fragen, die gestellt wurden und beantwortet wurden, oder die gestellt wurden und beantwortet wurden, oder eben auch nicht. Sie sind herzlich dazu eingeladen, auch im Nachgang jeden von uns nochmal persönlich per E-Mail oder von uns per E-Mail zu kontaktieren und die Fragen werden dann im Nachgang auch nochmal gerne beantwortet. Als erste Frage würde ich aufgreifen, kann ARM, SAP, GSE ersetzen? Ich glaube, das geht an Klaus im ersten Fall erstmal die Frage zu beantworten.
Also ganz klar, die Aufgabe von ARM ist es nicht, GSE zu ersetzen. Wir ersetzen einen Teil davon, nämlich die Access Control, wenn sie genutzt wird. Das ist halt oft das eine Modul, was eben genutzt wird von GSE. GSE selbst kann aber sehr viel mehr als einfach nur SOD-Kontrolle.
Also das ist nicht unsere Tension damit, sondern die Tension ist eigentlich währende Kunden, Prospekts oder grundsätzlich Firmen, die vielleicht erwägen, SAP, GSE einzusetzen, aber im Grunde genommen nur die SOD-Abfrage im Hinterkopf kann denen eine absolut preiswertere und vor allen Dingen eine weiterblickende, also größerblickende Option zu bieten, eben nicht nur SODs zu sehen, sondern die eben in ein System, in ein IGA-System zusammenzufassen.
Ich denke an die beiden Kreise, die du gehabt hast, Kai, um eben zu sagen, okay, was ich aus dem SAP-System auslesen kann, kann ich eben in einem IGA-System mitbetreuen, kann dann übergreifend auch SOD-Violations feststellen oder dafür sorgen, dass sie eben nicht stattfinden und kann entsprechende Zertifizierungen abfragen dazu oder loslassen dazu. Also das ist die Tension dabei, also es ist kein Ersatz für GSE, aber es ersetzt ziemlich komplett den Access-Control-Teil davon. Vielen Dank, da passt natürlich jetzt auch die nachfolgende Frage direkt dazu. Kann ARM mit IIQ kombiniert werden?
Ja, selbstverständlich. Es ist zwar eine Cloud-Software und von daher ist die Frage völlig berechtigt. Ich habe hier eine On-Prem-Software, viele unserer Kunden sitzen noch auf der On-Prem-Seite und arbeiten natürlich mit IIQ und gerne mit IIQ, das ist völlig in Ordnung.
Und ja, es gibt natürlich eine Integration, es gibt einen Connector rein. Es ist zwar dann vielleicht eine Kröte, die zu schlucken ist, weil ARM ist tatsächlich nur als Cloud-Software verfügbar. Also wir übernehmen das komplette Hosting, den gesamten Service dafür. Wir sorgen dafür, dass das immer auf dem Stand ist. Sie müssen sich um nichts kümmern, außer Licht und Netzwerk anlassen. Den Rest machen wir.
Aber ja, Sie haben die Integration davon, auch innerhalb von IIQ. Das heißt, wenn Sie eine SOD-Violation bekommen, und das hat was mit SAP zu tun, also Sie machen ein Access-Request und da wird ein Teil von SAP mitgefragt. Wir fragen das ARM-System, gibt es hier ein Einwand dagegen? Es kommt ein Ja zurück. Dann können Sie darauf klicken und können dann genau sehen, wo sind denn die T-Codes oder die Autorisierungsobjekte, die diesen Verstoß auslösen. Können das gegebenenfalls korrigieren oder wissen zumindest, woran es ist.
Oder können vielleicht sogar sagen, okay, trotzdem weitermachen, passt für mich, das ist in Ordnung. Wir haben gerade im Rahmen von Corona gelernt, dass wir mit der einen oder anderen Violation einfach leben müssen für eine gewisse Zeit. Das ist also nicht grundsätzlich schlecht. Wichtig ist nur, dass man weiß, was passiert. Jetzt sind wir wieder bei dem Stichwort Transparenz. Absolut. Kann ich nur unterstützen.
Zu wissen, um diese, das reine Wissen ist schon ein Wert an sich. Absolut. Super. Dann hier direkt auch von Jochen Schneider. Ist das auf SailPoint begrenzt? Ich bin mir nicht sicher, ob ich die Frage richtig verstehe. Des Weiteren ist aber auch die Frage, ist ARM auch schließlich für SAP-Systeme? Bitte gern nochmal korrigieren und die Frage nochmal ein bisschen detaillierter füllen, ob das diese Thematik trifft, aber ist ARM ausschließlich für SAP-Systeme? Im Moment ja.
Also ARM ist tatsächlich momentan auf SAP-Systeme fokussiert, aber wir werden es dieses Jahr noch auf andere ERP-Systeme ausweiten, wie zum Beispiel Oracle. Das wird auf jeden Fall kommen. Super. Und eine weitere Frage, was mich auch persönlich so ein bisschen verwundert hat, bevor wir jetzt fast schon der Zeit entlaufen sind. Innerhalb von 60 Minuten das Ganze zu installieren, klingt natürlich wie ein Traum für jeden, der so ein Unternehmen hat, bei vielen Applikationen. Wie genau ist das möglich?
Also, da ist sicherlich, sag ich mal, vielleicht ein Drittel Marketing dabei. Es braucht natürlich ein bisschen Vorarbeit. Sie brauchen halt den Proxy-User, mit dem Sie sich als SAP anconnecten können. Der braucht natürlich die Berechtigung, damit wir auslesen können, was dort passiert. Wir brauchen natürlich eine VMware oder einen Windows-Server, auf dem wir den Dienst installieren können. Und es muss natürlich, also wir machen das über Proxy 4.3, der muss natürlich auch dann erlaubt sein, dass wir dort was rausschicken können.
Wenn diese Sachen aber alle da sind, diese Pre-Requests, wie es so schön heißt, wenn die alle getroffen sind, die Installation von dem Service dauert tatsächlich nur ein paar Minuten. Der Connect wird sofort bestellt. Das ist kein Hexenwerk. In dem Moment, wo der Connect da ist, liest das System aus, was wir in der SAP-Historie auch mitfinden, verschlüsselt es und schickt es auf den Tenant. Der Tenant ist da. Das kann sofort analysiert werden.
Dieser Vorgang, Installation des Service, Auslesen, Vergriften, Hochlesen, Hochschicken auf das System und dann anschließend die erste Analyse starten zu können, dauert tatsächlich längstens eine Stunde. Das ist tatsächlich so.
Also, ich bin gern bereit, die Wette einzugehen. Ich habe meine Wette verloren dabei. Sehr interessant und sehr eindrucksvoll, das Ganze. Leider sind wir für heute auch schon außerhalb der Zeit, beziehungsweise die Zeit ist leider um. Nochmals im Anschluss würde ich gerne allen Teilnehmern anbieten, dass sie uns drei jeweils per E-Mail jederzeit gerne kontaktieren können, falls Fragen sich auftun, die beantwortet werden dürfen oder auch gerne auf der EEC, falls sie denn daran teilnehmen, nochmal auf uns in Person zukommen und das Ganze nochmal persönlich klären dürfen.
Ich würde gerne für die sehr schöne und informative Präsentation, für die informativen Präsentation und hoffe, dass wir uns auf der EEC sehen werden und bis dahin wünsche ich noch einen schönen Abend und bedanke mich fürs Zuhören und Präsentieren. Dankeschön, bis dahin. Vielen Dank, bleiben Sie gesund.
Danke, gleichfalls. Ciao.
