IT-Beratung & IT-Services

Cloud-Umgebungen wachsen oft schneller als Teams sie manuell verwalten können. Zwar sind sie in kleinen Infrastrukturen noch überschaubar, können allerdings schnell zum Problem werden, sobald die Infrastruktur komplexer wird. Änderungen dauern zu lange, Fehler können sich einschleichen und Entwickler warten auf Ressourcen, um weiterarbeiten zu können. Um sowohl Entwicklern als auch dem Platform-Team die Arbeit zu erleichtern, können verschiedene Prozesse automatisiert werden. In diesem Artikel geben wir einen Überblick, wie Automatisierung im Cloud Platform Engineering aussehen kann und welche Vorteile sie Unternehmen bringt.

Warum manuelle Prozesse im Cloud Platform Engineering an ihre Grenzen stoßen

Ohne Automatisierung ist Cloud Platform Engineering komplex: Jede Entwicklungsumgebung muss manuell aufgesetzt werden. Dadurch können sich Releases verzögern, Umgebungen inkonsistent sein und eine aufwendige Koordination ist nötig. Auch das Fehlerpotenzial ist entsprechend höher: Je mehr manuelle Eingriffe ein Prozess erfordert, desto wahrscheinlicher wird ein Versehen und desto schwerer lässt sich das Problem im Nachhinein nachvollziehen.

In der Praxis bedeutet das: Tickets stapeln sich, Teams verschieben Deployments und das Platform-Team wird zum Flaschenhals, weniger zum Enabler. Gerade beim Aufsetzen der Umgebungen gibt es jedoch zahlreiche wiederkehrende und regelbasierte Aufgaben, die sich an Anforderungen und Compliance-Richtlinien des Unternehmens orientieren. Um das Platform-Team zu entlasten und verlässlich und schnell Umgebungen aufsetzen zu können, kann Automatisierung auf verschiedenen Wegen umgesetzt werden.

3 wichtige Säulen der Automatisierung im Cloud Platform Engineering

Im Cloud Platform Engineering gibt es nicht die eine Automatisierung oder das eine Automatisierungs-Tool. Vielmehr können Unternehmen in mehreren Bereichen Tools und Konzepte einsetzen, die sich gegenseitig ergänzen. Dabei kann es beispielsweise um die Bereitstellung der Infrastruktur gehen, die eigenständige Arbeit der Entwickler oder den permanenten Blick auf den Betrieb.

CI/CD-Pipelines für die Cloud-Infrastruktur

Bei CI/CD-Pipelines handelt es sich um einen automatisierten Prozess, der Änderungen am Code kontinuierlich integriert (Continuous Integration), testet und bereitstellt (Continuous Deployment). Das Prinzip dahinter, Infrastructure as Code, sorgt dafür, dass Umgebungen nicht mehr per Hand konfiguriert werden müssen. Stattdessen entstehen sie durch reproduzierbare, beschreibbare Vorlagen.

In einer automatisierten Pipeline durchläuft jede Änderung an der Infrastruktur mehrere Schritte, bevor sie in den Release geht: automatische Validierung, Sicherheitschecks und Testläufe. Fehler werden so früh erkannt und nicht erst dann, wenn sie bereits Auswirkungen haben. So entstehen konsistentere Umgebungen, weniger manuelle Eingriffe und deutlich kürzere Durchlaufzeiten bei Änderungen.

Die wichtigsten Vorteile auf einen Blick:

• Konsistenz:Jede Umgebung entsteht nach denselben Vorlagen, ohne Abweichungen oder manuelle Sonderwege.
• Früherkennung:Fehler und Sicherheitslücken werden automatisch vor dem Deployment erkannt.
• Geschwindigkeit:Änderungen an der Infrastruktur werden in Minuten ausgerollt statt in Stunden oder Tagen.

Self-Service-Portale für Entwickler

Gerade in wachsenden IT-Teams entsteht oft die gleiche Herausforderung: Entwickler müssen auf Ressourcen warten, weil jede Anfrage über das Platform-Team läuft. Mit Self-Service-Portalen können Unternehmen dieses Problem lösen, indem sie standardisierte Bausteine bereitstellen, die Entwickler eigenständig nutzen können. Dafür brauchen sie kein technisches Spezialwissen und sparen sich Wartezeiten.

Die Plattform dabei stellt sicher, dass alles, was über das Portal geschieht, den internen Standards für Sicherheit und Compliance entspricht. Entwickler arbeiten schneller und unabhängiger. Das Platform-Team wiederum gewinnt Zeit im Arbeitsalltag.

Die wichtigsten Vorteile auf einen Blick:

• Autonomie:Entwickler können Ressourcen eigenständig ohne Ticket und Wartezeit einrichten.
• Standardisierung:Alle bereitgestellten Umgebungen entsprechen automatisch den internen Sicherheits- und Compliance-Vorgaben.
• Entlastung:Das Platform-Team spart Zeit und kann sich auf andere Aufgaben konzentrieren.

Monitoring & Observability

Neben dem Rollout gibt es auch im laufenden Betrieb Möglichkeiten zur Automatisierung. Vom Monitoring bis zur automatischen Reaktion auf Probleme können Unternehmen verschiedene Automatisierungen umsetzen.

Wichtig ist vor allem der Unterschied zwischen klassischem Monitoring und moderner Observability: Monitoring zeigt auf, dass etwas nicht stimmt, Observability hingegen gibt Aufschluss darüber, warum etwas nicht stimmt. Durch automatisierte Alarme, strukturierte Protokolle und nachvollziehbare Metriken können Teams proaktiv handeln. Teilweise gibt es bereits Systeme, die bekannte Probleme selbstständig korrigieren können, ohne dass ein Mensch eingreifen muss.

Die wichtigsten Vorteile auf einen Blick:

• Proaktivität:Probleme werden erkannt und gemeldet, bevor sie den Betrieb beeinflussen.
• Nachvollziehbarkeit: Protokolle und Metriken machen Ursachen schnell sichtbar. Die stundenlange Fehlersuche entfällt.
• Resilienz:Bekannte Störungen können ohne manuellen Eingriff automatisch behoben werden.

Vorteile durch Automatisierung im Cloud Platform Engineering

Die Wirkung von Automatisierung im Cloud Platform Engineering zeigt sich auf verschiedenen Ebenen, von der Geschwindigkeit bis zur Kosteneffizienz.

• Geschwindigkeit:Sie ist der unmittelbarste Effekt. Prozesse, die früher Stunden oder Tage gedauert haben, laufen in Minuten ab. Entwicklungsteams können schneller liefern, weil sie weniger auf externe Freigaben angewiesen sind.
• Zuverlässigkeit:Automatisierte Abläufe führen dieselben Schritte in derselben Reihenfolge aus. Dabei gibt es keine Abweichungen und nichts kann vergessen werden. So sinkt die Fehlerquote deutlich.
• Skalierbarkeit:Eine gut automatisierte Plattform wächst mit den Anforderungen mit, ohne dass der Betriebsaufwand proportional steigt. Mehr Workloads bedeuten nicht automatisch mehr manuellen Aufwand.
• Kosteneffizienz:Einerseits sparen Entwickler und Platform-Teams Zeit und damit Geld, andererseits können Unternehmen durch automatisiertes Ressourcenmanagement ungenutzte Kapazitäten erkennen, Umgebungen bedarfsgerecht anpassen und verhindern, dass Cloud-Ressourcen unnötig laufen. Auch so sinken die laufenden Kosten für den Cloud-Betrieb.

Fazit: Cloud Platform Engineering Hand in Hand mit automatisierten Prozesse

Automatisierung ist ein wichtiger und grundlegender Bestandteil im Cloud Platform Engineering. Durchdachte Automatisierungsstrukturen schaffen die Voraussetzungen für schnellere Entwicklung, höhere Zuverlässigkeit und Cloud Plattformen, die mit den Anforderungen des Unternehmens wachsen können. Zwar lohnt es sich schon von Anfang an, Automatisierung in die Cloud Infrastruktur zu integrieren, aber auch nachträglich können Tools und Konzepte integriert werden. Dabei ist es am sinnvollsten, mit den Bereichen zu beginnen, die den größten Engpass verursachen und von dort aus strukturiert weiterzubauen. So entsteht mit der Zeit eine zuverlässige Automatisierungsstruktur.

Nachdem wir im im ersten Teil unserer Blogreihe das Extensibility-Modell grundlegend betrachtet haben, widmen wir uns nun der praktischen Anwendung bei der Erweiterung von SAP S/4HANA. Die fundamentale Systementscheidung für eine Architektur auf der SAP Business Technology Platform (BTP) gegenüber einem On-Stack-Ansatz definiert maßgeblich die Performance, Wartbarkeit und Skalierbarkeit künftiger Entwicklungen. Eine klare S/4HANA Erweiterungsstrategie hilft dabei, die Vorteile beider Welten effizient zu nutzen. Während direkte Erweiterungen im ERP-Kern einen tiefgreifenden Zugriff auf lokale Geschäftsprozesse bieten, eröffnet die Cloud neue Wege für die Integration von Drittsystemen und externen Nutzergruppen. Dieser Artikel bietet konkrete Entscheidungskriterien für technische Projektleiter, Enterprise-Architekten und leitende SAP-Entwickler.

On-Stack-Erweiterung mit Key User und Developer Extensibility

Die Entwicklung direkt im S/4HANA-System stellt die engste Form der Systemerweiterung dar. Sie unterteilt sich heute in zwei primäre Bereiche, wobei die Key User Extensibility vor allem Anwender mit tiefem Prozessverständnis anspricht. Diese können über integrierte Wizard-Tools benutzerdefinierte Felder, einfache Validierungen oder analytische Ansichten generieren, ohne tiefgehende Programmierkenntnisse zu besitzen. Mit dem Release S/4HANA 2025 FPS01 hat SAP diesen Bereich funktional deutlich aufgewertet. Es ist nun möglich, vollwertige Fiori-Elements-Anwendungen für benutzerdefinierte Geschäftsobjekte mit wenigen Klicks zu erstellen und die Verhaltenssteuerung für SAP-eigene Objekte nahtlos anzupassen.

Sobald die fachlichen Anforderungen komplexer werden, kommt die Developer Extensibility zum Einsatz. Sie stellt professionellen Entwicklern das moderne ABAP Cloud Modell zur Verfügung. Der entscheidende architektonische Vorteil dieses On-Stack-Ansatzes liegt in der physischen und logischen Nähe zu den Geschäftsdaten. Dadurch bleiben die transaktionale Integrität und hohe Ausführungsgeschwindigkeiten gewahrt, da keine externen Schnittstellenaufrufe notwendig sind.

Cloud-Flexibilität durch Side-by-Side Extensibility

Im Gegensatz dazu steht die Side-by-Side Extensibility auf der SAP BTP, bei der Applikationen vollständig außerhalb des ERP-Kerns entwickelt und betrieben werden. Die Kommunikation erfolgt ausschließlich über lose gekoppelte, freigegebene Remote-APIs oder asynchrone Ereignisse über den Event Mesh. Dieses Modell eignet sich besonders für Applikationen, die für externe Endnutzer wie Lieferanten oder Endkunden gedacht sind. Die BTP fungiert hierbei als sichere, isolierte Zone, die den internen ERP-Kern schützt. Zudem ist dieses Muster ideal für Partner, die eigenständige und mandantenfähige Software-as-a-Service Lösungen entwickeln möchten.

Bei der Wahl des Programmiermodells innerhalb der S/4HANA Erweiterungsstrategie stehen das SAP Cloud Application Programming Model (CAP) und das ABAP RESTful Application Programming Model (RAP) im Fokus. Während Entwicklungen über das RAP-Modell On-Stack meist keine zusätzlichen Lizenzkosten verursachen, erfordert die ABAP Environment auf der BTP eine eigene Subskription. Im Vergleich dazu bieten CAP-Anwendungen auf Cloud Foundry ein granulareres Preismodell, was je nach Projektumfang wirtschaftlicher sein kann.

Herausforderungen der S/4HANA Erweiterungsstrategie

Die Entscheidung zwischen On-Stack und Side-by-Side erfordert eine genaue Analyse der Datenströme, da eine Lösung auf der BTP nicht automatisch effizienter ist. Ein kritischer Faktor bleibt die physikalische Bindung von Daten an ihren Ursprungsort. Wenn Millionen von Datensätzen über OData-Schnittstellen übertragen werden, entstehen unweigerlich Performance-Engpässe, sofern der BTP-Subaccount und das S/4HANA-System nicht geografisch und infrastrukturell optimal aufeinander abgestimmt sind.

Neben den Latenzen stellt die sogenannte Principal Propagation eine administrative Hürde dar. Sie erfordert eine komplexe Konfiguration des SAP Cloud Connectors sowie den Import von Zertifikaten und regelbasierte Mappings im System. On-Stack-Erweiterungen punkten hier durch die native Nutzung lokaler Berechtigungskonzepte, was die Stabilität erhöht. Cloud-Szenarien verlangen hingegen eine exakte Synchronisation der Identitätsdaten zwischen dem lokalen System und dem Cloud-Identitätsanbieter.

Um Ihnen die Navigation durch diese komplexen Abwägungen zu erleichtern, bietet die folgende Infografik eine grobe Entscheidungsgrundlage, welche die wichtigsten Kriterien von der Datenlast bis hin zum Nutzerkreis visualisiert.

Hybride Lösungsansätze

Da keine der beiden Varianten isoliert alle modernen Anforderungen abdeckt, liegt die optimale Lösung für komplexe Szenarien häufig in einer hybriden Architektur. Hierbei werden datenintensive Kernprozesse performant On-Stack mittels ABAP Cloud abgewickelt, während kundenorientierte Frontends oder die Integration von Drittsystemen flexibel über die BTP realisiert werden. Die Wahl der Bereitstellungsform beeinflusst langfristig sowohl die Backend-Performance als auch die Flexibilität Ihrer Systemlandschaft. Im dritten Teil dieser Serie analysieren wir, wie sich diese Faktoren künftig auf Benutzeroberflächen und die Integration von künstlicher Intelligenz auswirken.

Gerne unterstützen wir Sie bei diesen komplexen Fragestellungen durch detaillierte Machbarkeitsstudien, um die perfekte Balance zwischen Cloud-Innovation und ERP-Stabilität für Ihr Unternehmen zu finden. Kontaktieren Sie uns für ein unverbindliches Beratungsgespräch oder lesen Sie unsere weiteren Blogartikel zu den Themen Clean Core und SAP BTP Integration.

Die Architektur von Unternehmenssoftware durchläuft einen fundamentalen Wandel. Historisch gewachsene ERP-Landschaften zeichnen sich durch tiefgreifende, monolithische Strukturen aus. Kundenindividueller Code greift häufig in Form von Modifikationen oder User Exits direkt und ungeschützt in den Kern des Systems ein. Diese über Jahrzehnte übliche Praxis führt heute zu erheblicher technischer Schuld, bremst die Agilität von Unternehmen, und macht Systemupgrades komplex und kostenintensiv. Um in einem dynamischen Marktumfeld wettbewerbsfähig zu bleiben, ist die Umsetzung einer Clean Core Strategie unerlässlich. Diese fordert eine strikte technologische Entkopplung von Standardsoftware und individuellen Anpassungen. Unser erster Beitrag dieser dreiteiligen Blogreihe richtet sich gezielt an Enterprise Architekten, leitende SAP-Entwickler und IT-Strategen, die eine performante, wartbare und zukunftssichere Systemlandschaft konzipieren möchten.

Clean Core Strategie im SAP Kontext

Der Begriff des „sauberen Kerns“ wird in der globalen Entwicklergemeinschaft intensiv diskutiert und oft missverstanden. Kundenindividueller Code muss nicht vollständig vermieden werden. „Clean Core“ bedeutet Erweiterung technologisch so zu entkoppeln und zu standardisieren, dass der eigentliche SAP-Standard unangetastet bleibt. Dadurch lassen sich künftige Releases ohne manuellen Anpassungsaufwand einspielen. Das Ziel ist es, Upgrades reibungslos zu gestalten, Altlasten abzubauen und neue Technologien wie Künstliche Intelligenz nahtlos zu integrieren. Für einen dauerhaft effizienten Betrieb stützt sich dieses Architekturkonzept auf fünf Kernprinzipien: durchgängige Prozesse, nahtlose Integration, verlässliche Datenqualität, effiziente Operations und eine standardisierte Erweiterbarkeit.

Im Bereich der Erweiterbarkeit hat die SAP ihre Vorgaben zuletzt stark an die Realität historisch gewachsener Systeme angepasst. Ursprünglich wurde der Entwickler-Community ein striktes Drei-Tier-Modell vorgegeben. Dieses unterschied zwischen Cloud-konformen Erweiterungen (Tier 1), Brückenlösungen (Tier 2) und klassischen, modifizierenden Anpassungen (Tier 3). Dieses binäre System aus „erlaubt“ und „verboten“ erwies sich jedoch in der Migrationspraxis als viel zu restriktiv. Als Lösung führt die SAP ein differenziertes Modell mit vier Leveln ein, das die Kompatibilität von Erweiterungen wesentlich granularer bewertet und einen realistischeren Transformationspfad aufzeigt.

Das Clean Core A-D Extensibility Modell

Das sogenannte A-D Extensibility Modell klassifiziert den individuellen Code anhand seiner technischen Umsetzung und der genutzten Schnittstellen in folgende vier Kategorien beziehungsweise Stufen:

• Level A (ABAP Cloud Readiness): Die sauberste Form der Erweiterung nutzt exklusiv offiziell freigegebene SAP-APIs sowie das ABAP Cloud Entwicklungsmodell. Diese Stufe garantiert höchste Upgrade-Stabilität ohne manuellen Anpassungsaufwand und ist vollständig Cloud-ready.

• Level B (Classic SAP APIs): Auf dieser Ebene nutzt der Code klassische, gut dokumentierte SAP-APIs wie BAPIs oder freigegebene BADIs und folgt den etablierten Best Practices für die klassische ABAP-Entwicklung. Diese Stufe bietet eine sehr hohe Stabilität, erfordert bei Upgrades in der Regel nur marginale funktionale Prüfungen und gilt im Rahmen von Private Cloud Deployments oder On-Premise-Szenarien als valide und zukunftssichere Basis.

• Level C (Unreleased SAP Objects): Diese Stufe umfasst die Nutzung interner SAP-Objekte, die nicht offiziell für Kunden freigegeben wurden. Die Stabilität ist hier nur bedingt gegeben, da vor jedem Upgrade eine zwingende technische Verifizierung der genutzten Objekte über das Changelog erforderlich ist.

• Level D (Modifications & Technical Debt): Diese kritische Stufe umfasst die Nutzung explizit nicht empfohlener Objekte, direkte Kernmodifikationen des SAP-Standards oder veraltete, invasive Techniken wie implizite Enhancements. Code auf diesem Level erzeugt massive technische Schulden, verhindert reibungslose Upgrades und muss im Rahmen der Transformation zwingend in höhere Level refaktoriert werden.

Die rein theoretische Definition dieser vier Level reicht für eine erfolgreiche und nachhaltige Architektur-Transformation jedoch bei Weitem nicht aus. Es bedarf einer strengen Governance, um sicherzustellen, dass Entwicklungsteams diese Leitplanken im Arbeitsalltag konsequent einhalten. Die technische Einhaltung dieser strikten Vorgaben wird durch das ABAP Test Cockpit (ATC) unterstützt, welches den Code automatisiert auf seine ABAP Cloud Readiness prüft und detaillierte Fehler oder Warnungen ausgibt, sobald ein Entwickler den im System definierten Clean Core Standard verlässt. Um Entwicklern den Übergang zu erleichtern, stellt die SAP den SAP Extensibility Explorer sowie das Cloudification Repository zur Verfügung. So können Sie bereits in der Designphase freigegebene Schnittstellen identifizieren und neue Erweiterungen direkt konform zu Level A entwickeln.

Herausforderungen in der Umsetzung

Trotz dieser klaren strategischen Ausrichtung gibt es in der realen Projektpraxis weiterhin erhebliche Herausforderungen. Die Deutschsprachige SAP-Anwendergruppe (DSAG) hat diese kritische Situation bereits auf den Technologietagen 2025 unter dem Motto „Strategy Royale: Call, Raise or Fold?“ intensiv diskutiert. Die mit Abstand größte technische Hürde bei der Umsetzung der Clean Core Paradigmen ist derzeit die mangelnde Verfügbarkeit von Level-A-kompatiblen, freigegebenen Schnittstellen.

Wie sich diese theoretischen Vorgaben in der Praxis umsetzen lassen und welche Kriterien die architektonische Entscheidung zwischen On-Stack-Erweiterungen und Side-by-Side-Bereitstellungen beeinflussen, beleuchten wir im zweiten Teil dieser Blogreihe.

Gehen Sie den nächsten Schritt

Eine fundierte Entscheidung bildet hier das Rückgrat Ihrer digitalen Transformation. Unser Expertenteam begleitet Sie gerne bei der strategischen Neuausrichtung Ihrer Systemlandschaft. Wir führen tiefgreifende Code-Analysen Ihres S/4HANA-Systems mittels ATC durch und erarbeiten einen belastbaren Refactoring-Plan, um Ihre historischen Modifikationen sicher in die Level A und B zu überführen. Nehmen Sie Kontakt mit uns auf, um Ihre individuelle Roadmap für einen Clean Core zu definieren.

Mobile Endgeräte sind fester Bestandteil im Arbeitsalltag zahlreicher Unternehmen geworden. Smartphones, Tablets und Laptops ermöglichen flexibles Arbeiten – ob im Büro, im Homeoffice oder unterwegs. Je mehr Geräte allerdings im Umlauf sind, desto komplexer wird ihre Verwaltung. Mobile Device Management bietet Unternehmen die technische Grundlage, um alle Geräte zentral zu steuern, abzusichern und zu überwachen. Die rein technische Umsetzung reicht jedoch noch nicht aus. Auch alle Mitarbeitenden müssen wissen, wie sie mit ihren Geräten umgehen sollen und welche Richtlinien warum gelten. Deshalb lohnen sich MDM-Schulungen für alle Mitarbeitenden im Zuge der Einführung des Mobile Device Managements. Warum diese Schulungen wichtig sind, welche Inhalte sie vermitteln sollten und welche Formate sich eignen, erklären wir in diesem Artikel.

Warum MDM-Schulungen wichtig für Unternehmen sind

Zahlreiche Sicherheitsvorfälle entstehen durch menschliche Fehler, weniger durch technische Schwachstellen. Mitarbeitende, die nicht wissen, welche Apps sie auf ihrem Dienstgerät installieren dürfen oder wie sie mit Unternehmensdaten auf privaten Geräten umgehen sollen, machen eines der größten Risiken für die IT im Unternehmen aus. Mit MDM-Lösungen können entsprechende Sicherheitsrichtlinien umgesetzt werden, erfordern allerdings Verständnis und Akzeptanz der User, das durch Schulungen entsteht. Andernfalls entstehen verschiedene Risiken:

• Mitarbeitende umgehen bewusst oder unbewusst Sicherheitsrichtlinien, etwa indem sie Gerätesperren deaktivieren.
• Nicht freigegebene Apps werden installiert, die Risiken für Malware bieten.
• Sie wissen nicht, wie sie sich bei Verlust oder Diebstahl eines Geräts verhalten sollten.
• Der Umgang mit BYOD-Geräten und der Trennung privater und beruflicher Daten ist unklar.

An dieser Stelle sind auch Anforderungen der DSGVO und der NIS2-Richtlinie relevant. Beide fordern, dass Unternehmen neben technischen Maßnahmen für die IT-Sicherheit auch organisatorische Maßnahmen etablieren. Dazu zählen auch Mitarbeiterschulungen, die das Team über richtige Verhaltensweisen und Schutzmaßnahmen aufklären.

Diese Inhalte können Teil einer effektiven MDM-Schulung sein

Eine gute MDM-Schulung geht einerseits auf technisches Grundwissen ein und schafft andererseits ein Verständnis für den Sinn hinter verwalteten Geräten und Sicherheitsmaßnahmen. Verstehen alle Teams, warum Regeln gelten, steigt die Akzeptanz und Mitarbeitende halten sich daran. Wichtig ist dabei auch: Passen Sie die Inhalte auf die jeweilige Zielgruppe an. Für IT-Administratoren sind andere Grundlagen und Themen wichtig als für Mitarbeitende im Vertrieb oder Kundenservice.

Für alle Mitarbeitenden eignen sich diese Inhalte:

• Was ist MDM und welche Geräte sind im Unternehmen davon betroffen?
• Welche Unternehmensrichtlinien gelten für mobile Endgeräte?
• Wie funktioniert die Einbindung eines Geräts in das MDM-System?
• Was ist im Fall eines Geräteverlusts zu tun und was bedeutet ein Remote Wipe?
• Wie werden private und berufliche Daten auf BYOD-Geräten sauber getrennt?

Für IT-Verantwortliche und Administratoren kommen weitere Themen hinzu, etwa die Konfiguration von Geräteprofilen, das Management von App-Berechtigungen oder die Auswertung von Compliance-Reports. Durch eine klare Unterscheidung dieser Zielgruppen stellen Sie sicher, dass die Schulungen effizient sind und die Informationen wirklich relevant sind.

Wie können Unternehmen MDM-Schulungen erfolgreich umsetzen?

Natürlich ist es wichtig, was Teams im Zuge der MDM-Schulungen lernen. Zentrale Frage ist aber auch, wie sie die nötigen Infos vermittelt bekommen. Dafür können Unternehmen verschiedene Wege wählen:

• Ein Präsenztraining eignet sich optimal für komplexere Themen und den direkten Austausch, vor allem bei der Implementierung von MDM im Unternehmen.
• E-Learning-Module sind flexibel und lassen sich gut dokumentieren, eignen sich also besonders gut für verteilte Teams, die hauptsächlich remote arbeiten.
• Micro-Learning umfasst kurze Einheiten von wenigen Minuten zu einem konkreten Thema und kann gut für regelmäßige Auffrischungen eingesetzt werden.
• Im Onboarding neuer Mitarbeitender können direkt die nötigen MDM-Grundlagen eingebunden werden, damit sie Geräte von Anfang an richtig nutzen können.

Den Erfolg der MDM-Schulungen können Sie beispielsweise durch kleine Wissenstests nach einzelnen Einheiten überprüfen. Holen Sie sich außerdem Feedback ein, ob an den Schulungen etwas verbessert werden kann, um für zukünftige Einheiten zu lernen.

Wichtig ist auch: MDM-Lösungen entwickeln sich ständig weiter. Deshalb reicht eine einmalige Schulung meist nicht aus. Neue Gerätetypen, aktualisierte Unternehmensrichtlinien oder neue gesetzliche Vorgaben erfordern regelmäßige Updates. Sinnvoll ist es daher, MDM-Schulungsinhalte jährlich aufzufrischen und zusätzliche Schulungen einzuplanen, wenn es größere Änderungen gibt.

Fazit: Schulungen machen MDM zum Erfolg

Oft werden MDM-Schulungen als notwendige Compliance-Maßnahme angesehen. Dabei sorgen sie dafür, dass alle Teams die Regeln und Vorgaben rund um die Geräteverwaltung verstehen und akzeptieren und reduzieren somit die Sicherheitsrisiken für die IT des gesamten Unternehmens. Je besser Mitarbeitende nämlich verstehen, warum Regeln gelten, desto weniger fühlen sie sich kontrolliert und desto eher halten sie sich an sie. Unternehmen schaffen so die Grundlage für sichere Remote-Arbeit.

Ein Termin wird kurzfristig abgesagt.
Familiärer Krankheitsfall.
Keine Vertretung.

Alles hängt an einer Person.

Was im Alltag nachvollziehbar ist, wird in der IT zum Risiko:
– Ein Single Point of Failure

Die entscheidende Frage lautet:

Wie viele solcher Abhängigkeiten gibt es in Ihrem Unternehmen, ohne dass Sie es wissen?

Die Realität in vielen Unternehmen

• Kritisches Wissen liegt bei einzelnen Personen

• Systeme sind nicht einheitlich abgesichert

• Prozesse sind nicht ausreichend dokumentiert

• Vertretungsregelungen existieren nur auf dem Papier

Solange alles läuft, bleibt das unsichtbar.
Doch im Ernstfall führt genau das zu:

• Ausfällen
• Sicherheitsvorfällen
• Compliance-Risiken

Warum jetzt Handlungsdruck besteht

Mit NIS2, ISO 27001 und neuen regulatorischen Anforderungen verändert sich IT-Sicherheit grundlegend:

Weg von Einzelmaßnahmen
Hin zu nachweisbarer Resilienz

Unternehmen müssen heute zeigen können:

• Welche Risiken bestehen

• Welche Maßnahmen umgesetzt wurden

• Wie Systeme abgesichert sind

• Wie Ausfälle abgefangen werden

„Wir haben das im Griff“ reicht nicht mehr.

Die Lösung: Struktur statt Zufall

Moderne IT-Sicherheit basiert auf zwei Säulen:

 Technische Absicherung

• System Hardening (IT-Härtung)

• Sichere Konfigurationen

• Zugriffskontrollen

• Monitoring & Logging

 Organisatorische Sicherheit

• Klare Verantwortlichkeiten

• Dokumentierte Prozesse

• Vertretungsregelungen

• Notfall- und Wiederanlaufpläne

Erst die Kombination macht Ihr Unternehmen wirklich widerstandsfähig.

Vorgehen nach ISO 27001 & NIS2 – einfach erklärt

Wir setzen genau dort an, wo die größten Risiken entstehen:

1. Transparenz schaffen

• Analyse Ihrer Systeme, Prozesse und Abhängigkeiten

• Identifikation von Schwachstellen (z. B. Single Points of Failure)

2. Risiken bewerten

• Welche Ausfälle hätten welche Auswirkungen?

• Wo besteht akuter Handlungsbedarf?

3. Maßnahmen definieren

• Technisch (Hardening, Zugriffskonzepte)

• Organisatorisch (Vertretung, Prozesse, Richtlinien)

4. Umsetzung begleiten

• Einführung sicherer Standards (z. B. CIS Benchmarks)

• Strukturierte Umsetzung statt Insellösungen

5. Nachweis & Weiterentwicklung

• Dokumentation für Audits (ISO 27001, NIS2)

• Kontinuierliche Verbesserung

Ergebnis: Sicherheit, die funktioniert und geprüft standhält

Ihr Vorteil

• Weniger Abhängigkeit von Einzelpersonen
• Reduzierte Angriffsflächen
• Höhere Ausfallsicherheit
• Audit- und Compliance-Fähigkeit
• Klare Strukturen statt Unsicherheit

Die entscheidende Frage

Was passiert bei Ihnen, wenn morgen eine Schlüsselperson ausfällt?

• Läuft alles weiter?

• Oder steht ein Teil Ihres Unternehmens still?

Jetzt Klarheit schaffen

Lassen Sie uns gemeinsam herausfinden, wo Ihre größten Risiken liegen und wie Sie diese strukturiert beseitigen.

Jetzt unverbindlich anfragen:

Kontaktieren Sie uns für eine erste Einschätzung

Rewion – Ihr Partner für IT-Härtung, ISO 27001 & NIS2-Compliance

Lesen sie auch: Warum ISO 27001 und NIS2 keine Bedrohung, sondern eine strategische Chance sind.

Auch interessant alle Themen und Informationen beim: BSI

Der klassische Weg, ein Legacy-Upgrade oder kurzweilige Koexistenz unterschiedlicher Exchange-Versionen, ist für größere Organisationen oder langsame Migrationsphasen oft der sinnvollste Weg. Sie nehmen einen neuen Exchange SE-Server in Ihre Organisation auf und migrieren Postfächer dorthin. Das ist Pflicht, wenn Sie noch auf Exchange 2016 sind, aber optional bei 2019.

Das In-Place-Upgrade ist die spannende Neuheit: Sie installieren Exchange SE einfach über Ihre bestehende 2019-CU15-Installation und machen daraus direkt einen SE-Server. Der Vorgang verhält sich wie eine normale CU-Installation. Weitere Einblicke gibt es hier.

Warum das In-Place Upgrade kaum Risiko birgt

Microsoft betitelt das In-Place Upgrade als „Low-Risk“. Früher waren neue Exchange-Versionen echte Monster-Updates.
Neue Anforderungen, Produktkeys und Features wurden eingearbeitet. Für die IT-Admins unter Ihnen hieß das: Side-by-Side-Migration, endlose Tests, Kompatibilitätschecks, Team-Schulungen, Skripte umbauen (oder Mut zur Lücke). Kein Wunder, dass viele früher lieber auf ein CU1 gewartet haben, bevor es produktiv ging.

Microsoft Exchange Server SE ist unter der Haube ein Exchange 2019. Der Code ist 1:1 der gleiche. Microsoft hat nur den Produktnamen und die EULA geändert. Keine neuen Features, keine geänderten Hardware-Anforderungen, keine neuen Keys oder Code-Überarbeitungen.

Das In-Place Upgrade klingt gut, passt aber nicht pauschal zu jeder Umgebung. Die meisten von Ihnen betreiben Exchange 2019 wahrscheinlich noch auf älteren Windows-Servern. In diesem Zusammenhang wäre ein In-Place Upgrade vermutlich die falsche Lösung. Hier wäre das Legacy-Upgrade am sinnvollsten, um dem neuen Exchange SE ein zukunftssicheres Zuhause zu bieten. Mit einem modernen Windows Server 2025 profitieren Sie von Security-Fixes, längerer Supportlaufzeit und Hotpatching.

Warum sollten Sie trotzdem auf SE migrieren?

Das „Sollen“ muss eher durch „Müssen“ ersetzt werden. Microsoft baut die Lizenzierung für die Zukunft um – und die Exchange-On-Premises-Welt leidet mit. Da der Support für Exchange 2019 im Oktober 2025 geendet ist, müssen Sie auf SE upgraden.

Aber die neue SE Version bietet auch interessante Features, wie bspw. ein fortlaufendes Update-Modell, das stärker an Windows Server und Azure Stack angelehnt ist. Statt großer, seltener CUs wird es künftig kleinere, kontinuierliche Updates geben, die weniger Risiko erzeugen und Ihre Wartungsfenster verkürzen. Ihre Organisation profitiert dadurch von einer stabileren Plattform, planbareren Updatezyklen und schneller verfügbaren Security-Fixes.

Microsoft Exchange Extended Security Updates

Microsoft Exchange SE gibt es nun seit einigen Monaten auf dem Markt, Exchange 2016 und 2019 haben seit dem 14. Oktober 2025 ihr Support-Ende erreicht. Microsofts Goodie, die Extended Security Updates (ESU), wurden ins Leben gerufen, um gegen Einwurf von Münzen weiterhin kritische Sicherheitsupdates (SUs) und generellen Support zu gewährleisten.​

Doch alles hat ein Ende – der Extended Support läuft am 14. April 2026 aus. Dann sind Exchange Server 2016 und 2019 offiziell „tot“ und werden nicht weiter von Microsoft berücksichtigt. Es ist also Zeit zum Handeln, falls Sie noch alte Exchange Server in Ihrer Organisation betreiben.

Migrationspfade

Microsoft passt das Koexistenz-Verhalten der Exchange Server an. Früher konnte man noch ältere, sogar nicht mehr unterstützte Versionen neben neueren Versionen koexistieren lassen. Diese Flexibilität endet nun in zwei Schlüsselpunkten.

Die Installation von Exchange Server 2019 CU15 oder Exchange Server SE RTM verweigert die Koexistenz mit Exchange Server 2013. Ein Zwischenschritt auf 2019 Cu14 im klassischen Legacy Upgrade Pfad ist von Nöten. Anschließend muss nach der Postfachmigration der alte 2013 Server entfernt werden, bevor mittels In-Place Upgrade auf Exchange SE RTM aktualisiert werden darf.

Migrationspfad EX 2013

Möchten Sie von einem Exchange Server 2016 CU23 zum Exchange SE RTM migrieren, ist der Zwischenschritt auf 2019 CU15 relevant. Anschließend ist eine langsame Migrationsphase inklusive Koexistenz mit einem neu hinzugefügten Exchange Server SE RTM möglich. Die Option direkt vom Exchange 2019 CU15 via In-Place Upgrade zum Exchange SE ist ebenfalls möglich.

Sollte später bereits das CU1 für Exchange SE vorhanden sein, ist eine Koexistenz mit Exchange 2019 Cu15 technisch noch machbar, aber offiziell nicht supported. Wenn gegen Ende 2026 Exchange SE CU2 veröffentlich wird, ist erneut keine Koexistenz mit Exchange 2019 CU15 möglich. Hier müssen Sie vor dem CU2 Update den letzten Exchange 2019 CU15 aus der Organisation entfernen.

Migrationspfad EX 2016

Einfacher sieht es für den Schritt vom Exchange Server 2019 CU15 zum Exchange Server SE RTM aus. Die Optionen zum In-Place Upgrade oder Koexistenz mit einem neu hinzugefügten Exchange Server SE RTM sind möglich. Ebenfalls unterstützen die in Zukunft erscheinenden Exchange SE CU1 und CU2 Versionen keine weiteren Koexistenz-Szenarien mit Exchange 2019 Cu15.

Migrationspfad EX 2019

Sicherheit in der Cloud ist keine Zusatzfunktion, die sich nachträglich einbauen lässt. Sie muss von Beginn an Teil der Architektur sein. Diesen Grundsatz verfolgt der Cloud Security by Design Ansatz. Sicherheitsmechanismen werden bereits in der Planungsphase berücksichtigt und in jede Schicht der Infrastruktur integriert. So schützen Unternehmen ihre Cloud-Infrastruktur zuverlässig vor bekannten Bedrohungen und schaffen die Grundlage für künftige Anforderungen. Wir erklären in diesem Artikel die Hintergründe des Security by Design Ansatzes, gehen auf Umsetzungsmöglichkeiten ein und geben Tipps für den sicheren Aufbau der Cloud-Infrastruktur.

Was bedeutet der Cloud Security by Design Ansatz?

Cloud Security by Design steht für den Grundsatz, Sicherheit von Beginn an als zentralen Bestandteil der Cloud-Architektur zu verstehen, statt das Thema wie ein Add-on zu behandeln. Statt Sicherheitsmaßnahmen reaktiv nach Vorfällen einzuführen, werden Schutzmechanismen von Anfang an in Design-Entscheidungen eingebettet. Konkret können das verschiedene Mechanismen sein:

• Auswahl sicherer Services
• Definition von Zugriffsrechten
• Verschlüsselung von Daten
• Kontinuierliche Überwachung der Infrastruktur

Ziel ist es, Schwachstellen zu minimieren, die Reaktionszeiten bei Angriffen zu verkürzen und sicherzustellen, dass Compliance-Anforderungen automatisch erfüllt werden. Wichtig ist auch, dass Entwicklungsteams, Platform Engineers und Sicherheitsexperten eng zusammenarbeiten, um gemeinsam eine sichere und resiliente Cloud-Umgebung zu schaffen.

Wie kann Cloud Security by Design umgesetzt werden?

Für eine erfolgreiche Umsetzung von Cloud Security by Design braucht es eine Kombination aus technischen Maßnahmen, organisatorischen Prozessen und kulturellem Wandel. Unternehmen können in der Entwicklung ihrer Cloud-Infrastruktur verschiedene Maßnahmen implementieren.

Zero-Trust-Ansatz
Das Prinzip „Never trust, always verify“ gilt als Fundament moderner Cloud-Sicherheit. Anders als traditionelle Netzwerkmodelle, die innerhalb des eigenen Netzwerks Vertrauen voraussetzen, behandelt Zero Trust jede Anfrage, unabhängig von ihrer Herkunft, als potenziell gefährlich. Jeder Zugriff wird einzeln validiert, Nutzer und Geräte werden kontinuierlich überprüft und Zugriffsrechte werden auf das absolute Minimum beschränkt. Dieser Ansatz verhindert laterale Bewegungen von Angreifern innerhalb der Infrastruktur und minimiert so den Schaden im Falle einer Kompromittierung.

Identity & Access Management (IAM)
Die richtige Verwaltung von Identitäten und Zugriffsrechten ist unumgänglich für den Aufbau einer sicheren Cloud-Umgebung. IAM-Systeme stellen sicher, dass nur autorisierte Personen und Services auf bestimmte Ressourcen zugreifen können. Durch rollenbasierte Zugriffskontrollen erhalten Nutzer genau die Berechtigungen, die sie für ihre Aufgaben benötigen. Multi-Faktor-Authentifizierung fügt eine zusätzliche Sicherheitsebene hinzu, zudem reduzieren zeitlich begrenzte Zugriffstoken das Risiko kompromittierter Zugänge.

Automatisierte Sicherheitsprüfungen
Manuelle Sicherheitsüberprüfungen sind fehleranfällig und können mit der Geschwindigkeit moderner Cloud-Deployments kaum Schritt halten. Automatisierte Sicherheitstests sollten daher fester Bestandteil jeder CI/CD-Pipeline sein. Tools scannen Code auf Schwachstellen, überprüfen Konfigurationen auf Fehleinstellungen und identifizieren unsichere Abhängigkeiten noch vor dem Deployment. Regelmäßige Penetrationstests und Schwachstellenscans ergänzen diese kontinuierlichen Prüfungen und stellen sicher, dass auch produktive Systeme laufend auf Sicherheitslücken untersucht werden.

Compliance-Anforderungen
Regulatorische Vorgaben wie die DSGVO oder ISO 27001 setzen klare Standards für den Umgang mit Daten und Sicherheitsprozessen. Cloud Security by Design berücksichtigt diese Anforderungen bereits in der Architekturphase, sodass Compliance nicht nachträglich zum Problem wird. Dazu gehören Mechanismen zur Datenverschlüsselung, Protokollierung von Zugriffen, Löschkonzepte und Dokumentation von Sicherheitsmaßnahmen. Durch die Integration dieser Anforderungen von Beginn an vermeiden Unternehmen teure Nachbesserungen und potenzielle Strafen.

CSPM (Cloud Security Posture Management)
CSPM-Tools überwachen die Cloud-Umgebung kontinuierlich auf Fehlkonfigurationen, Compliance-Verstöße und Sicherheitsrisiken. Sie erkennen beispielsweise öffentlich zugängliche Speicher-Buckets, übermäßig permissive Firewalls oder veraltete Verschlüsselungsstandards. Durch automatisierte Warnungen und Empfehlungen helfen CSPM-Lösungen IT-Teams dabei, den Sicherheitsstatus der Cloud-Infrastruktur hoch zu halten und Schwachstellen zu schließen, bevor sie ausgenutzt werden können.

3 Tipps für sicheres Cloud Platform Engineering

Neben den grundlegenden Sicherheitskonzepten gibt es noch einige konkrete Maßnahmen, die IT-Teams im Aufbau ihrer Cloud-Infrastruktur umsetzen können, um ihre Umgebung abzusichern.

• Verschlüsselung überall implementieren: Daten sollten sowohl im Ruhezustand als auch während der Übertragung verschlüsselt sein. Moderne Cloud-Plattformen arbeiten mit nativen Verschlüsselungsmechanismen, die sich mit wenig Aufwand aktivieren lassen. Besonders wichtig ist das Management der Verschlüsselungsschlüssel: Sie sollten getrennt von den Daten gespeichert und regelmäßig rotiert werden. Durch sichere Verschlüsselung schützen Unternehmen sich sowohl vor externen Angreifern als auch vor internen Risiken.
• Least Privilege Prinzip konsequent anwenden: Jeder Nutzer, jede Anwendung und jeder Service sollte soweit möglich nur die minimalen Berechtigungen erhalten, die für die jeweilige Aufgabe notwendig sind. Übermäßige Rechte gelten als eine der häufigsten Ursachen für erfolgreiche Angriffe. Durch regelmäßige Überprüfungen der vergebenen Berechtigungen stellt die IT sicher, dass keine ungenutzten oder veralteten Zugriffsrechte bestehen bleiben. Automatisierte Tools können dabei helfen, diese Reviews effizient durchzuführen.
• Logging und Monitoring als Frühwarnsystem nutzen: Umfassendes Logging aller Aktivitäten in der Cloud-Umgebung schafft Transparenz und ermöglicht die Nachverfolgung von Sicherheitsvorfällen. Kombiniert mit intelligenten Monitoring- und Alerting-Systemen kann die IT verdächtige Aktivitäten in Echtzeit erkennen. Ergänzend können SIEM-Lösungen dabei helfen, aus der großen Anzahl an Logdaten relevante Sicherheitsereignisse herauszufiltern und schnelle Reaktionen zu ermöglichen.

Fazit: Cloud Security by Design als Grundlage für jede Entwicklung

Arbeiten Unternehmen im Aufbau ihrer Cloud-Infrastruktur nach dem Security by Design Ansatz, folgen sie damit einer heute notwendigen Grundhaltung. Indem sie Sicherheit von Anfang an in Planung und Umsetzung integrieren, minimieren sie Risiken, erfüllen Compliance-Anforderungen und sparen langfristig Kosten. Eine Kombination aus automatisierten Sicherheitsprüfungen, IAM und kontinuierlichem Monitoring legt ein sicheres Fundament. Wichtig ist, dass Unternehmen Sicherheit zum zentralen Bestandteil jeder Cloud-Lösung machen, statt sie als nachträglichen Gedanken zu vernachlässigen.