SAP in Azure-Architekturentwurf

Azure Active Directory
ExpressRoute
Managed Disks
SAP HANA in Azure (große Instanzen)
Virtual Machines

Im Handbuch zur Architektur von SAP in Azure werden Grundsätze beschrieben, mit denen die Qualität von SAP-Workloads in Azure sichergestellt wird. Dieses Handbuch basiert auf dem Microsoft Azure Well-Architected Framework, jedoch gelten die Empfehlungen speziell für Bereitstellungen von SAP-Lösungen. Eine solide Grundlage einer Architektur beginnt mit fünf Grundpfeilern: Kosten, DevOps, Resilienz, Skalierbarkeit und Sicherheit.

Microsoft und SAP arbeiten in Partnerschaft, um Organisationen eine klare Roadmap zum Entwickeln innovativer Cloudlösungen bereitzustellen. Azure unterstützt SAP-Anwendungen unter Linux und Windows für Entwicklungs-, Test- und Produktionsumgebungen. Unsere Kunden führen SAP-Bereitstellungen aller Größen in Azure aus – einschließlich SAP NetWeaver und allen unterstützten Datenbankverwaltungssystemen (Database Management System, DBMS), SAP S/4HANA, BW/4HANA, BI und HANA für Szenarien zur Hochskalierung und horizontalen Skalierung.

Eine Einstiegsmöglichkeit ist die Bewertung der Azure-Architektur.

Kosten

Wenn Sie Ihre Workloads in die Cloud verlagern, gibt es mehrere Möglichkeiten, die Kosten für die gesamte Lösung zu reduzieren. Viele dieser Möglichkeiten werden im Azure Well-Architected Framework unter Kostenoptimierung behandelt. Wenn Sie SAP-Lösungen zu Azure verschieben, haben Sie die Möglichkeit, weitere Kostenoptimierungen durchzuführen. Sie können mit der Rationalisierung Ihrer Landschaft beginnen oder die Komponenten umstrukturieren oder ersetzen. Letzteres bietet sich insbesondere an, wenn Sie im Rahmen Ihrer Journey in die Cloud von der Business Suite zu S/4HANA migrieren. Diese Aktionen erfolgen zu Beginn der Migration zu Azure und werden kontinuierlich fortgesetzt.

Bei der Systemrationalisierung werden kostenbezogene Fragen beantwortet. Es wird beispielsweise beantwortet, ob Sie alle SAP-Systeme migrieren müssen oder einige außer Betrieb nehmen können, die nicht mehr benötigt werden. Außerdem wird beantwortet, ob es kosteneffizienter ist, bestimmte Workloads umzugestalten, oder ob es schneller ist, die Migration per Lift & Shift durchzuführen. Benötigen Sie wirklich ein System, das so groß ist wie Ihr lokales System?

Informationen dazu, wie das IT-Team von Microsoft diese Fragen beantwortet hat, können Sie lesen, wie das Team etwa 60 VMs im Rahmen ihrer eigenen SAP-Migration zu Azure außer Betrieb genommen hat.

Mithilfe einer effizienten Vorgehensweise können Sie Verschwendung bei Ihrer SAP-Bereitstellung in Azure vermeiden, wodurch Sie Kosten sparen und Vorgänge vereinfachen. Überprüfen Sie beispielsweise die Größe, nachdem Sie Ihre Lösung in Azure in Betrieb genommen haben. Können Sie die Größe der VMs basierend auf der Nutzung für Ihre Landschaften reduzieren? Können Sie Datenträger entfernen, die nicht mehr verwendet werden?

Sie können ebenfalls Kosten reduzieren, indem Sie die Rationalisierung mit einer potenziellen Umstrukturierung der gesamten Unternehmenslösung kombinieren. Es besteht die Möglichkeit, den Unternehmensprozess in SaaS-Dienste zu verlagern.

Kontinuierliches Kostenmanagement

Eine weitere Möglichkeit zum Reduzieren der Kosten besteht darin, VMs freizugeben oder zu pausieren. Wenn Ihre SAP-Sandboxsysteme von Montag bis Freitag täglich 10 Stunden lang anstatt rund um die Uhr ausgeführt werden, können Sie Ihre Kosten mit der nutzungsbasierten Bezahlung um etwa 70 % reduzieren. Wenn Ihre SAP-Anwendungen ständig ausgeführt werden müssen, sollten Sie sich für reservierte Azure-Instanzen entscheiden, um die Kosten zu reduzieren.

Sie können die Kosten auch senken, indem Sie verschiedene Tarife für VMs kombinieren. Damit Sie Ihr Budget vorhersagen können, können Sie eine reservierte Azure-VM-Instanz verwenden. Hierbei handelt es sich um eine Vorauszahlung für ein Jahr oder drei Jahre in einer bestimmten Region. Sie können die nutzungsbasierte Bezahlung für Computekapazitäten verwenden, die keine langfristige Verpflichtung erfordert, um von den niedrigen Kosten und der Flexibilität zu profitieren.

Schließlich empfiehlt es sich, Ihre Azure-Vorgänge regelmäßig zu überprüfen und nach Möglichkeiten zur Kostenoptimierung zu suchen. Überprüfen Sie beispielsweise, ob es eine kosteneffizientere Speicheroption oder eine neue VM-Serie mit einem besseren Preis-Leistungs-Verhältnis gibt. Weitere Informationen finden Sie im Artikel Governancemethodik für die Cloud zum Cloud Adoption Framework im Abschnitt „Kostenverwaltungsdisziplin“.

Leitfaden zu Kosten

DevOps

Der DevOps-Pfeiler des Handbuchs zur Architektur von SAP in Azure behandelt Bedenken bezüglich des Betriebs und der Effizienz für die Bereitstellung von SAP-Landschaften in Azure und die Ausführung von SAP-Lösungen in der Produktionsumgebung.

Automation

SAP-Bereitstellungen in Azure sollten automatisiert werden, um durch Benutzer verursachte Fehler zu vermeiden, die Zuverlässigkeit zu verbessern und die höhere Standards zu erreichen. Es ist nicht nur mühsam, die Infrastruktur für einzelne SAP-Bereitstellungen manuell einzurichten, sondern auch fehleranfällig. Wenn Sie mehrere SAP-Installationen benötigen, kann Sie das mehrere Stunden oder Tage kosten. Daher empfiehlt es sich für einen vorhersagbaren effizienten Bereitstellungsprozess, Ihre Azure-Infrastrukturbereitstellungen und SAP-Softwareinstallationen weitestgehend zu automatisieren.

Die Einführung eines DevOps-Paradigmas bedeutet, dass Sie ein IaC-Verfahren (Infrastructure-as-Code, Infrastruktur als Code) verwenden, um bei Bedarf neue SAP-Umgebungen zu erstellen. IaC ist ein wichtiger Aspekt von SAP-Projektlandschaften.

Nachteile der manuellen Bereitstellung Vorteile der automatisierten Bereitstellung
– Erfordert Fachkenntnisse über viele Domänen außerhalb von SAP – Funktioniert sofort nach einer anfänglichen Vorbereitungszeit und erfordert wenig Domänenwissen
– Kann je nach Größe der SAP-Landschaft viel Zeit in Anspruch nehmen – Dauert zwischen 30 Minuten und 2 Stunden (berechenbar)
– Kann teuer sein – Bietet kostenlose Ressourcen, z. B. diese SAP HANA-Vorlagen auf GitHub
– Einschränkungen für Tests: Es ist schwieriger, Tests in den Prozess einzufügen – Stellt Vorlagen bereit, die Testinstrumentierung während der Bereitstellung und der Migration enthalten
– Mühsames und zeitaufwändiges Skalieren und Anpassen der Umgebung – Vereinfacht die zentrale und horizontale Skalierung und bietet neue Bereitstellungsvorlagen
– Kann zu unerwünschten Abweichungen beim Entwurf führen – Einmal definierte Standards werden auf jede Bereitstellung angewendet

Überwachung

Die Überwachung und die Diagnose sind von entscheidender Bedeutung. SAP-Anwendungen in Azure werden in einem Remoterechenzentrum von Microsoft ausgeführt. Sie geben etwas Kontrolle über die Infrastruktur und in manchen Fällen über das Betriebssystem auf, um im Gegenzug die Vorteile der Clouddienste nutzen zu können.

Bei großen Anwendungen ist es nicht praktikabel, eine Verbindung mit VMs herzustellen, um ein Problem zu behandeln oder Protokolldateien zu durchsuchen. Darüber hinaus steht möglicherweise keine dedizierte VM zur Verfügung, wenn Sie Platform-as-a-Service in Azure verwenden.

Alle Systeme müssen beobachtet werden können. Überwachung und Diagnose bieten Einblick in das System, sodass Sie ermitteln können, wann und wo Fehler auftreten. Eine bewährte Methode besteht darin, ein gängiges und konsistentes Protokollierungsschema zu verwenden, mit dem Sie Ereignisse systemübergreifend korrelieren können.

Der Überwachungs- und Diagnoseprozess besteht aus mehreren unterschiedlichen Phasen:

  • Instrumentierung: Generieren der Rohdaten aus Anwendungsprotokollen, Webserverprotokollen, in die Azure-Plattform integrierten Diagnosefunktionen und anderen Quellen

  • Sammlung und Speicherung: Konsolidieren der Daten an einem zentralen Speicherort

  • Analyse und Diagnose: Beheben von Problemen und Übersicht über die Gesamtintegrität

  • Visualisierung und Warnungen: Verwenden von Telemetriedaten zum Erkennen von Tendenzen oder zum Benachrichtigen des Betriebsteams

Leitfaden zu DevOps

Resilienz

Der Resilienzpfeiler des Handbuchs zur Architektur von SAP in Azure bezieht sich auf die Betriebsstabilität und Geschäftskontinuität, die Sie benötigen, um unternehmenskritische SAP-Anwendungen auf Ebene 1 auszuführen. Durch den Entwurf mit Rücksicht auf die Verfügbarkeit wird die Betriebszeit von SAP-Anwendungen im Falle lokaler Software- oder Hardwarefehler sichergestellt.

In Produktionsumgebungen ist es wichtig, jede Anwendungs- und Infrastrukturkomponente vor einem Single Point of Failure zu schützen. Dies kann durch die Prinzipien Isolation und Redundanz erreicht werden.

  • Isolation: Stellen Sie sicher, dass alle beteiligten Komponenten auf einer Anwendungs- und Infrastrukturebene isoliert sind.

  • Redundanz: Stellen Sie sicher, dass alle beteiligten Komponenten redundant auf einer Anwendungs- und Infrastrukturebene verfügbar sind.

Wenn Sie diese grundlegenden Prinzipien im Hinterkopf behalten, sollten Sie dreistufige Systeme in alle SAP-Landschaften implementieren, um sicherzustellen, dass alle beteiligten Anwendungskomponenten voneinander isoliert sind und durch Redundanz Hochverfügbarkeit erreichen können.

Es wird empfohlen, die VMs, die SAP Central Services und Datenbanken ausführen, in Verfügbarkeitsgruppen oder Verfügbarkeitszonen bereitzustellen. Dadurch können Anwendungen vor geplanten Wartungsereignissen und nicht geplanten Ausfällen geschützt werden.

Beim Anwenden der Resilienz auf die SAP-Anwendungsserver wird empfohlen, einige kleine Server anstelle eines großen Anwendungsservers zu verwenden. Die bewährte Methode besteht darin, die Clustertechnologien des Gastbetriebssystems (z. B. Windows-Failovercluster oder Linux Pacemaker) zu konfigurieren, um kurze Failoverzeiten für SAP Central Services und das Datenbank-Managementsystem (DBMS) zu gewährleisten. Die bewährte Methode dazu, sicherzustellen, dass kein (oder nur minimaler) Datenverlust vorliegt, besteht darin, je nach Szenario die synchrone oder asynchrone Replikation für das DBMS zu konfigurieren.

Resilienz des Anwendungsservers

Resilienz für die SAP-Anwendungsserverebene kann durch Redundanz erzielt werden. Sie können mehrere Dialoginstanzen auf verschiedenen Instanzen von Azure-VMs konfigurieren. Hierfür benötigen Sie mindestens zwei Anwendungsserver.

Es wird empfohlen, die Azure-VMs, in denen die SAP-Anwendungsserver ausgeführt werden, in derselben Azure-Verfügbarkeitsgruppe bereitzustellen. Wenn Sie die SAP-Anwendungsserver in derselben Azure-Verfügbarkeitsgruppe bereitstellen, wird Folgendes sichergestellt:

  • Die Azure-VMs sind nicht Teil derselben Updatedomäne, sodass gleichzeitige Ausfälle vermieden werden

  • Die Azure-VMs sind nicht Teil derselben Standarddomäne, sodass gemeinsame physische Ebenen zwischen den Azure-VMs vermieden werden

Azure-to-Azure Site Recovery kann als Teil einer effizienten und kostenbewussten Notfallwiederherstellungslösung verwendet werden.

Weitere Informationen finden Sie unter Hochverfügbarkeitsarchitektur für SAP-Anwendungsserver.

Resilienz bei zentralen Diensten

Die SAP Central Services-Ebene, die aus (A)SCS/ERS-Instanzen (nur Linux) basiert, wird als ein Single Point of Failure betrachtet, dessen Komponenten mit Hochverfügbarkeit eingerichtet werden müssen, um Resilienz zu erzielen. Die Lösung besteht aus der Erstellung eines Clusters der SAP Central Services-Ebene, der von einer kompatiblen freigegebenen Speichertechnologie unterstützt wird.

Je nach Betriebssystem und verfügbarem gemeinsamen Speicher sind in den Phasen der allgemeinen Verfügbarkeit (General Availability, GA) oder der privaten Vorschau/Public Preview verschiedene Optionen verfügbar.

Weitere Informationen finden Sie unter Hochverfügbarkeitsarchitektur für eine SAP ASCS/SCS-Instanz unter Windows und Hochverfügbarkeitsarchitektur für eine SAP ASCS/SCS-Instanz unter Linux.

Datenbankresilienz

Auf der Datenbankebene können Produktionsdaten innerhalb der Region oder zwischen der primären Region und der Region für die Notfallwiederherstellung (synchron bei Hochverfügbarkeit oder asynchron bei Replikation der Notfallwiederherstellung) repliziert werden. Je nachdem, welches DMBS ausgewählt wird und welche Vereinbarungen zum Servicelevel erforderlich sind, können unterschiedliche Datenbankmethoden verwendet werden.

Beachten Sie beim Entwerfen von resilienten Architekturen für die Datenbankebene die folgenden Aspekte:

  • Resilienz gegen Datenverlust: Das Entwerfen mit Blick auf Resilienz umfasst auch die Wiederherstellung nach Datenverlusten. Dabei kann es sich um die Wiederherstellung nach einem logischen Fehler in der SAP-Datenbank, einem umfangreichen Notfall oder dem Verlust der gesamten Azure-Region handeln. Beim Entwerfen der Wiederherstellbarkeit müssen Sie die RPO (Recovery Point Objective) und die RTO (Recovery Time Objective) Ihrer SAP-Anwendung verstehen. Es ist von entscheidender Bedeutung, dass Sie sowohl die Verfügbarkeit als auch die Wiederherstellbarkeit im Entwurf der SAP-Bereitstellungsarchitektur sorgfältig berücksichtigen. Dadurch können Sie Ihre Organisation vor finanziellen Verlusten bewahren, die zu Ausfallzeiten und Datenverlusten führen.

  • Verwendung der synchronen Replikation: Wenn das Unternehmen verlangt, dass die Recovery Point Objective (RPO) bei 0 (null) liegt, also dass bei einem Ausfall keine Daten verloren können, sollten Sie die synchrone Replikation auf Datenbankebene in Betracht ziehen und beim Entwurf berücksichtigen. Dadurch entsteht ein System, bei dem jede Transaktion mindestens an zwei Stellen der hoch verfügbaren Datenbanken committet werden muss. Die Latenz zwischen den beiden DBMS-Instanzen muss vorsichtig bemessen und berücksichtigt werden. Je höher die Netzwerklatenz, desto höher die Wahrscheinlichkeit einer Auswirkung auf die Skalierbarkeit Ihrer Workload. Dies ist besonders wichtig, wenn Sie sich dazu entscheiden, Verfügbarkeitszonen zu verwenden, in denen Workloads in einer Azure-Region in eindeutige physische Standorte voneinander getrennt werden können. Die Netzwerklatenz entspricht dem physischen Abstand zwischen diesen Standorten.

Weitere Informationen finden Sie unter Azure Virtual Machines – DBMS-Bereitstellung für SAP-Workload. Dieser Artikel enthält Empfehlungen zu den einzelnen DBMS.

Sicherungsresilienz

Neben einer robusten Architektur, einschließlich Funktionen für Hochverfügbarkeit und Notfallwiederherstellung, müssen unternehmenskritische Umgebungen auch eine Sicherungslösung implementieren.

SAP HANA bietet eine Sicherungs-API mit namens „Backint“, mit der Sicherungslösungen direkt auf der Datenbankebene sichern können.

Im Azure Marketplace gibt es mehrere zertifizierte Sicherungslösungen von Drittanbietern, die von den Herstellern und SAP zertifizierte Sicherheitsfunktionen umfassen.

Speicherlösungen wie Azure NetApp Files können wichtige Daten mithilfe von Momentaufnahmen sichern.

Azure Backup ist die native Sicherungslösung von Azure:

  • Native SAP HANA-Sicherungen über den Backint-Connector
  • Möglichkeit zum Erstellen einer mit der Anwendung konsistenten Sicherung unter Verwendung von Datenträgermomentaufnahmen von Azure Storage Premium
  • Sichern und Wiederherstellen von Daten zu Azure-VMs über das Azure-Portal. Die regionsübergreifende Wiederherstellung ermöglicht die Wiederherstellung von Azure-VMs in einer gekoppelten sekundären Region.
  • Langzeitaufbewahrung, durch die Sicherungen Compliance- und Überwachungsanforderungen entsprechend mehrere Jahre aufbewahrt werden können
  • Sicherungsverwaltung über das Azure-Portal

Weitere Informationen zu den Sicherungsfunktionen von SAP HANA finden Sie in der Sicherungsanleitung für SAP HANA in Azure Virtual Machines.

Weitere Informationen zu Azure Backup finden Sie in der Dokumentation zum Azure Backup-Dienst.

Leitfaden zu Resilienz

Hochverfügbarkeit von Azure Virtual Machines für SAP NetWeaver

Hochverfügbarkeit von SAP HANA für virtuelle Azure-Computer

Hochverfügbarkeit und Notfallwiederherstellung für SAP HANA in Azure (große Instanzen)

Einrichten der Notfallwiederherstellung für die Bereitstellung einer SAP NetWeaver-App mit mehreren Ebenen

Sicherungsanleitung für SAP HANA in Azure Virtual Machines

Skalierbarkeit

Der Skalierbarkeitspfeiler des Handbuchs zur Architektur von SAP in Azure beschreibt die Leistungseffizienz und die Erfüllung der Anforderungen an eine Workload. Benutzer benötigen ebenfalls leistungsfähige SAP-Anwendungen, damit sie effizient und problemlos arbeiten können. Es ist wichtig, dass Sie eine Größenanpassung für Ihre SAP-Bereitstellung durchführen und Ihre Azure-Komponenten anpassen. Zu diesen Komponenten gehören Compute-, Speicher- und Netzwerkressourcen.

Im SAP-Hinweis 1928533 wird der SAPS-Wert für die VMs beschrieben, die die Ausführung von SAP-Anwendungen unterstützen. (Für den Zugriff auf diesen SAP-Hinweis ist ein SAP Service Marketplace-Konto erforderlich.) Weitere Informationen über den Netzwerk- und Speicherdurchsatz der einzelnen Arten von Azure-VMs finden Sie in den folgenden Ressourcen:

Die Agilität von Azure ermöglicht Ihnen die einfache Skalierung Ihres SAP-Systems. Sie können beispielsweise die Computekapazität des Datenbankservers erhöhen oder horizontal skalieren, indem Sie Anwendungsserver hinzufügen, wenn der Bedarf steigt. Sie können Ihre Infrastruktur vorübergehend erweitern, um Ihren SAP-Migrationsdurchsatz zu beschleunigen und Ausfallzeiten zu reduzieren.

Sie sollten SAP-Redundanzfeatures wie Anmeldegruppen und Batchservergruppen verwenden, um diesen Anwendungsserver zuzuweisen. Gemäß der Gruppendefinition kann SAP die Workload automatisch an mehrere Anwendungsserverinstanzen versenden, sodass Ihr System automatisch auf- oder abskalieren kann, wenn die Nachfrage steigt bzw. sinkt.

Verwenden Sie für die SAP-Datenbankebene verwaltete Premium Azure Managed Disks, um von E-/A-Vorgängen mit hoher Leistung und geringer Latenz zu profitieren. Möglicherweise müssen Sie einen RAID-0-Stripe zum Aggregieren der IOPS und des Durchsatzes erstellen, um die Anforderungen Ihrer Anwendung zu erfüllen. Ausführliche Informationen zu bewährten Speichermethoden für SAP HANA-Workloads finden Sie unter SAP HANA-Infrastrukturkonfigurationen und -Vorgänge in Azure.

Es wird empfohlen, eine Azure ExpressRoute-Verbindung oder ein VPN (virtuelles privates Netzwerk) zwischen den lokalen Ressourcen und Azure zu verwenden. Diese Verbindungen sind für SAP-Benutzer und die Anwendungsschnittstellen von Vorteil, die eine Verbindung mit Ihren SAP-Anwendungen in Azure herstellen. Für SAP-Produktionsanwendungen in Azure wird ExpressRoute empfohlen, um eine private, dedizierte Verbindung herzustellen, die Zuverlässigkeit, höhere Geschwindigkeit und höhere Sicherheit als Site-to-Site-VPNs bietet.

Beachten Sie Schnittstellen zwischen SAP- und anderen Anwendungen, die anfällig für Wartezeiten sind. Möglicherweise müssen Sie Migrationsgruppen definieren. Dabei handelt es sich um Gruppen von SAP- und anderen Anwendungen, die gemeinsam bei Azure eingehen.

Infographic of SAP deployment on Azure using a hub-spoke network topology.

Eine gängige SAP-Bereitstellung in Azure mithilfe einerHub-Spoke-Netzwerktopologie

Leitfaden für die Skalierbarkeit

Hochskalieren/Aufskalieren:

Ausführen von SAP HANA für virtuelle Linux-Computer in einer zentral hochskalierten Architektur in Azure

Konfigurieren der Azure-Infrastruktur für die horizontale SAP HANA-Skalierung

Bewährten Methoden:

Sicherheit

Ihre SAP-Daten sind vermutlich das wertvollste Bestandteil des technischen Fußabdrucks Ihrer Organisation. Daher müssen Sie sich darauf konzentrieren, den Zugriff auf Ihre SAP-Architektur mithilfe einer sicheren Authentifizierung zu schützen, die Ihre Anwendung und Daten vor Netzwerksicherheitsrisiken schützt, und die Datenintegrität mithilfe von Verschlüsselungsmethoden aufrechterhalten.

SAP in Azure wird im IaaS-Cloudmodell (Infrastructure-as-a-Service) bereitgestellt. Das bedeutet, dass die Sicherheitsmaßnahmen von Microsoft im physischen Rechenzentrum, im physischen Netzwerk, auf physischen Hosts und im Hypervisor implementiert werden. Für die Bereiche über dem Hypervisor, z. B. das Gastbetriebssystem für SAP, müssen Sie die ausgewählten Dienste und Technologien sorgfältig auswerten, um sicherzustellen, dass Sie die geeigneten Sicherheitskontrollen für Ihre Architektur bereitstellen.

Zur Authentifizierung können Sie Azure Active Directory (Azure AD) mit SAML nutzen, um sich bei Ihrer SAP NetWeaver- oder HANA-Instanz anzumelden. Sie können außerdem SSO für andere SAP-Dienste wie Fiori Launchpad, SAP Cloud Platform oder Success Factors konfigurieren.

Mit NSGs (Netzwerksicherheitsgruppen) können Sie Netzwerkdatenverkehr von und zu Ressourcen in Ihrem virtuellen Netzwerk filtern. Sie können NSG-Regeln definieren, um den Zugriff auf Ihre SAP-Dienste zu erlauben oder zu verweigern. So können Sie beispielsweise den Zugriff auf die SAP-Anwendungsports über lokale IP-Adressbereiche zulassen und über das öffentliche Internet verweigern.

Sie sollten Anwendungssicherheitsgruppen (ASG) verwenden, um die Netzwerksicherheitskonfiguration zu vereinfachen. ASG können in Sicherheitsregeln anstelle von expliziten IPs für VMs verwendet werden. Die VMs werden dann ASGs zugewiesen. Durch diese Abstraktionsebene können Sie dieselbe Richtlinie für mehrere Anwendungslandschaften verwenden.

Mit Azure Disk Encryption können Sie die Datenträger Ihrer SAP-VMs im Hinblick auf die Datenintegrität verschlüsseln. Sowohl das Betriebssystem als auch die Datenvolumes können verschlüsselt werden, während sie im Speicher ruhen.

Azure Disk Encryption kann zusammen mit Azure Key Vault verwendet werden. Dies ist ein Dienst, der Ihre Verschlüsselungsschlüssel kontrolliert und verwaltet. Azure Key Vault unterstützt SQL Server aus DBMS-Sicht. Viele SAP-Kunden wählen Azure Disk Encryption für Ihre Betriebssystemdatenträger und die transparente DBMS-Datenverschlüsselung für ihre SAP-Datenbankdateien. Mit diesem Ansatz wird die Integrität des Betriebssystems gefördert und sichergestellt, dass Datenbanksicherungen ebenfalls verschlüsselt werden.

Identitätsverwaltung

Ziehen Sie Azure AD zum Authentifizieren und Autorisieren von Benutzern in Betracht. Azure AD ist ein vollständig verwalteter Identitäts- und Zugriffsverwaltungsdienst. Sie können damit Domänen erstellen, die nur in Azure existieren, oder Azure AD in Ihre eigenen lokalen Active Directory-Identitäten integrieren. Azure AD kann auch mit Microsoft 365, Dynamics CRM Online und vielen SaaS-Anwendungen (Software-as-a-Service) von Partnern integriert werden.

Bei Endverbraucheranwendungen ermöglicht Azure Active Directory B2C es Benutzern, sich mit ihren vorhandenen Konten sozialer Netzwerke (z. B. Facebook, Google oder LinkedIn) zu authentifizieren oder ein neues Benutzerkonto zu erstellen, das von Azure AD verwaltet wird.

Wenn Sie eine lokale Active Directory-Umgebung in ein Azure-Netzwerk integrieren möchten, gibt es je nach Anforderungen verschiedene Herangehensweisen. Weitere Informationen finden Sie in den Referenzarchitekturen zu Identitätsverwaltung.

Schützen Ihrer Infrastruktur

Kontrollieren Sie den Zugriff auf die von Ihnen bereitgestellten Azure-Ressourcen. Jedes Azure-Abonnement weist eine Vertrauensstellung mit einem Azure AD-Mandanten auf. Verwenden Sie die rollenbasierte Zugriffssteuerung von Azure (Azure Role-Based Access Control, Azure RBAC), um Benutzern in Ihrer Organisation die richtigen Berechtigungen für Azure-Ressourcen zu gewähren. Gewähren Sie Zugriff, indem Sie Benutzern oder Gruppen die entsprechenden Azure-Rollen für einen bestimmten Bereich zuweisen. Bei dem Bereich kann es sich um ein Abonnement, eine Ressourcengruppe oder eine einzelne Ressource handeln. Stellen Sie sicher, dass Sie alle Änderungen an der Infrastruktur überwachen.

Anwendungssicherheit

Im Allgemeinen gelten die bewährten Methoden für die Sicherheit in der Anwendungsentwicklung auch in der Cloud. Dazu gehört beispielsweise die Verwendung von SSLs (Secure Sockets Layer) überall, damit Sie vor websiteübergreifenden Anforderungsfälschungen und XSS-Angriffen (Cross-Site-Scripting) geschützt sind. Außerdem werden dadurch Angriffe durch Einschleusung von SQL-Befehlen verhindert.

Cloudanwendungen verwenden häufig verwaltete Dienste, die über Zugriffsschlüssel verfügen. Man kann es nicht oft genug sagen: Implementieren Sie diese niemals in die Quellcodeverwaltung. Speichern Sie Anwendungsgeheimnisse stattdessen in Azure Key Vault.

Datensouveränität und -verschlüsselung

Stellen Sie sicher, dass Ihre Daten in der richtigen geopolitischen Zone bleiben, wenn Sie die Azure-Regionen mit Hochverfügbarkeit verwenden. Azure Storage kann die Georeplikation wie Azure NetApp Files basierend auf dem Konzept eines Regionspaars in derselben geopolitischen Zone bereitstellen.

Ein Feature von cloudbasierten Infrastrukturen wie Azure Storage ist, dass sie eine hochverfügbare und permanente Plattform zum Hosten von Daten und Anwendungen bereitstellen. Entwickler von cloudbasierten Anwendungen müssen genau überlegen, wie sie diese Plattform nutzen, um diese Vorteile für ihre Benutzer zu maximieren.

Berücksichtigen Sie bei der Entscheidung, welche Redundanzoption für Ihr Szenario am besten geeignet ist, die Kompromisse zwischen geringeren Kosten und höherer Verfügbarkeit. Für den Fall, dass Kunden ihre SAP in Azure-Infrastruktur aus BCDR-Gründen (Business Continuity & Disaster Recovery) in andere Azure-Regionen replizieren möchten, erreichen sie dasselbe Ziel durch die Speicherreplikation, z. B. GRS- oder Notfallwiederherstellungsmechanismen wie Azure Site Recovery. Weitere Informationen finden Sie unter https://docs.microsoft.com/azure/storage/common/storage-redundancy.

Die Verwendung von Key Vault wird empfohlen, um Kryptografieschlüssel und Geheimnisse zu sichern. Sie können Key Vault zum Verschlüsseln von Schlüsseln und kleinen Geheimnissen wie Kennwörter verwenden, die Schlüssel verwenden, die wiederum in HSMs (Hardware-Sicherheitsmodule) gespeichert werden. Azure Key Vault unterstützt SQL Server aus DBMS-Sicht. Viele Speicher- und Datenbankdienste unterstützen die Verschlüsselung ruhender Daten, dazu gehören Azure Storage, Azure SQL-Datenbank, Azure Synapse Analytics und Azure Cosmos DB.

Sicherheitsressourcen

Infrastruktur

Eine qualitativ hochwertige SAP-Bereitstellung beginnt mit sorgfältiger Planung. In der Prüfliste für die Planung und Bereitstellung von SAP-Workloads in Azure finden Sie Prüflisten, Meilensteine und bewährte Methoden.

Wenn Sie eine vorhandene SAP-Ressource zu Azure migrieren möchten, finden Sie mögliche Migrationsoptionen im Whitepaper Migration Methodologies for SAP on Azure (Migrationsmethoden für SAP in Azure). Wenn Ihre SAP-Anwendung einen erheblichen Datenbankspeicherbedarf umfasst, finden Sie weitere Informationen im Blogbeitrag Very Large Database Migration to Azure (Migration sehr großer Datenbanken zu Azure).

In den folgenden Szenarios werden einige gängige Methoden zum Erstellen von SAP-Lösungen auf einer Azure-Infrastruktur beschrieben.

GitHub-Ressourcen

Die SAP-Community bietet viele kostenlose Vorlagen an, die Ihnen beim Einstieg helfen. Diese werden zwar nicht offiziell von Microsoft unterstützt, können Ihnen aber als Sprungbrett in Ihren eigenen Automatisierungsprozess dienen. Beispiel:

Nächste Schritte

Die folgenden Ressourcen unterstützen Sie bei Ihren ersten Schritten: