LinkedIn Google+

Warum müssen Sie Ihre Verbindungen schützen?

Sie haben sicher schon oft gehört, wie wichtig es heutzutage ist, IT-Systeme zu schützen. IT-Sicherheitstechniken sind uns im Alltag inzwischen vertraut. Bestimmt haben Sie schon eine Smart Card verwendet bzw. beim Interneteinkauf eine URL-Adresse benutzt, die mit https beginnt, oder – noch einfacher – sich bei Hotmail authentisiert.

Für SAP-Systeme gilt das gleiche und natürlich unterliegen sie Sicherheitsvorgaben. Sie sind sogar ganz entscheidend, um ein vernünftiges Sicherheitsniveau zu erreichen, und darauf müssen Unternehmen sorgfältig achten, wenn sie Investitionen unterschiedlicher Art (in Humankapital, Software usw.) tätigen. Ich würde sogar so weit gehen und behaupten, dass die Sicherung von SAP-Systemen zu den wichtigsten zählt, da dort normalerweise sehr kritische Daten für die Geschäfte vieler Firmen gehandhabt werden.

Betrachtet man SAP-Systeme als isolierte Einheiten, sollten Unternehmen ihre Systeme im Allgemeinen folgendermaßen schützen:

  • Authentifizierung: Benutzer müssen irgendwie in SAP-Systemen registriert sein (z. B. durch die Erstellung eines Benutzer-Stammsatzes in ABAP-Stacks) und sich bei der Anmeldung identifizieren.
  • Berechtigung: Abgesehen von der Voraussetzung, dass Systeme Benutzer identifizieren und deren Anmeldung zulassen müssen, muss irgendwie geregelt sein, wer was tun darf.  SAP verwendet für ABAP Berechtigungsmechanismen wie Rollen und Profile, und für Java J2EE-Sicherheitsrollen und UME-Aktionen.
  • Passwortrichtlinien: Die NetWeaver-Plattform gibt Ihnen die Möglichkeit, verschiedene Systemparameter zu setzen, mit denen Sie Ihre Benutzergemeinschaft zwingen können, kompliziertere Passwörter einzugeben, um Hackern das Leben zu erschweren.
  • Risikomanagement: Leider sind Risiken unvermeidlich und müssen bewältigt bzw. gemindert werden. Hier können Techniken wie die Sicherstellung, dass kritische Berechtigungen unter Kontrolle sind, Backup- und Recovery-Strategien, hohe Verfügbarkeit und Disaster-Recovery-Pläne hilfreich sein, um Risiken zu senken.
  • Prozesssteuerung: Die Steuerung Ihrer Geschäftsprozesse birgt ebenfalls Möglichkeiten, Risiken auf Geschäftsebene zu senken. Werden Konzepte wie Funktionstrennung genau im Auge behalten, können sich Unternehmen ebenfalls vor Betrug schützen und stehen aus gesetzlicher Sicht auf der sicheren Seite.
  • Rechtsvorschriften: Unsere Welt wird von Gesetzen bestimmt, und das ist nicht zu ändern (zu unserem Glück!). Für die IT-Welt gelten täglich mehr Vorschriften. Diese zwingen Unternehmen, Richtlinien einzuführen, um aktuelle Bestimmungen durchzusetzen. Eindeutige Beispiele sind Richtlinien zur Vorratsdatenspeicherung, Datenschutzgesetze, das Sarbanes-Oxley Act sowie Basel I, II und III für die Bankwirtschaft.

Ein kleiner Hinweis: Die SAP-Software Governance, Risk und Compliance (GRC) Suite unterstützt Sie dabei diese Punkte unter Kontrolle zu behalten.

Aber kennen Sie ein SAP-System, das alleine arbeitet, ohne Informationen mit anderen Systemen auszutauschen? SAP-Installationen folgen einer typischen Client-Server-Architektur, bei der sich ein Client-Programm, das auf dem PC eines Benutzers läuft, mit dem Back-End-System, z. B. dem SAP-System selbst, verbindet. Es findet ein Informationsaustausch zwischen dem Benutzer-PC und dem SAP-System statt. Tatsächlich erstrecken sich die meisten Geschäftsprozesse heute über vielfältige Systeme und auch über Unternehmensgrenzen hinaus (z. B. B2B, Mobility Applications), so dass Daten kilometerlange Leitungen passieren, auch öffentliche und unsichere Netzwerke, ohne dass Endbenutzer überhaupt zur Kenntnis nehmen, was im Hintergrund geschieht.

Insofern können wir feststellen, dass SAP-Systeme nicht isoliert laufen. Bei Audits über das Zusammenwirken von Systemen werden gewöhnlich viele Sicherheitsmängel erkannt. Nehmen wir ein einfaches und gängiges Beispiel: Firmenangestellte, die sich über die SAP GUI ungesichert mit SAP-Systemen verbinden. Das kann Angreifern ermöglichen, die Identitäten von Angestellten zu stehlen, und anschließend schadenbringend zu nutzen.

Deshalb sind zusätzliche Anstrengungen in Bezug auf die Sicherung der Datenwege nötig, um während des Datentransfers die Datenvertraulichkeit und -integrität (die beiden wesentlichen Elemente, wenn von gesichertem Datentransfer die Rede ist) zu wahren.

Ich werde Ihnen in diesem Artikel einige Techniken vorstellen, die Sie bei der Sicherung des Datenaustauschs bei Ihren SAP-Landschaften in Betracht ziehen können.

Ihre Netzwerksicherheit

Netzwerkzonen

Sehr vereinfacht ausgedrückt steht der Begriff Netzwerktopologie dafür, wie Ihr Netzwerk aussieht, wenn Sie es zu Papier bringen. Sie ist eine Karte, auf der die verschiedenen Netzwerkgeräte eingezeichnet sind, und wie sie zueinander in Beziehung stehen, damit ein auf der einen Seite mit dem Netzwerk verbundener Computer mit einem anderen, auf der anderen Seite, verbunden werden kann.

Unternehmen setzen als private Netzwerke (Intranets) TCP/IP-Netzwerke ein (in den meisten Fällen). Das ist technisch gesehen genau die gleiche Technologie, die öffentlich vom Internet verwendet wird. TCP/IP gestattet Ihnen, Netzwerke basierend auf IP-Adressen, Netzwerkmasken und Routing-Daten in Datenblöcke zu untergliedern. Diese Segmente, die miteinander verbunden werden und letztlich das gesamte private Netzwerk bilden, bezeichnen wir als Netzwerkzonen. Folglich zeigt eine TCP/IP-Netzwerktopologie in sehr vereinfachter Form, wie diese Zonen miteinander zusammenhängen.

Der Sicherheit halber sollten Sie Ihre SAP-unterlegten Systeme in eine separate Netzwerkzone legen. Das bringt Ihnen folgende Vorteile:

  • Sie können eindeutig zwischen der Benutzergemeinschaft und den Back-End-Systemnetzwerken unterscheiden.
  • Sie können für Ihr Back-End-Systemnetzwerk ein strengeres Sicherheitsniveau anwenden.
  • Sie können eine bessere Zugriffskontrolle für Ihr Back-End-Systemnetzwerk erreichen, indem Sie nach ein- und abgehendem Netzwerkverkehr filtern.
  • Der Netzwerkverkehr kann besser optimiert werden.

Firewalls

Das wichtigste Element bei der Herstellung einer guten Zugriffskontrolle sind Firewalls. Eine Firewall ist entweder eine Hardware- oder eine Software-Komponente, die festlegt, welche Verbindungen zwischen Kommunikationspartnern hergestellt werden können. Es gibt abhängig von der Information, die sie benutzen, um den Netzwerkverkehr zu filtern, im Wesentlichen zwei Typen von Firewalls:

  • Paketfilter: Sie können Verkehr basierend auf der Information filtern, die in den TCP- und/oder IP-Vorsätzen (z. B. IP-Adresse, TCP-Ports usw.) enthalten ist.
  • Application-Gateways: Sie können Verkehr basierend auf Informationen auf Anwendungsebene filtern. Das heißt, sie können Informationen herausziehen, die sich tiefer in der Anwendung befinden, innerhalb des gesamten TCP/IP-Netzwerkpakets.

SAP bietet keine Paketfilter-Firewall. Bei Application-Gateways stehen Ihnen dagegen mehrere Möglichkeiten zur Verfügung:

  • Der SAProuter kann Verkehr in der SAP-Netzwerkschnittstelle, einer privaten SAP-Netzwerk-Zwischenschicht die von SAP Protokollen wie RFC und DIAG genutzt wird, weiterleiten und filtern.
  • Der SAP Web Dispatcher kann an SAP NetWeaver Anwendungsserver gerichtete HTTP(S)-Anfragen filtern und ausgleichen.

Firewall-Typen schließen sich übrigens gegenseitig nicht aus. Wie Sie in der nachfolgenden typischen Netzwerktopologie sehen können, koexistieren sie in der realen Welt – der Sicherheit Ihres Systems insgesamt zuliebe – sogar normalerweise:

network

Entnehmen Sie der Abbildung oben, wie die Zugriffskontrolle zu Ihren Back-End-Systemen erreicht wird:

  • Externe Geschäftspartner verbinden sich nicht direkt mit Ihrem Back-End-System. Stattdessen werden deren Anfragen vom SAProuter oder dem SAP Web Dispatcher, der in der DMZ Ihrer Firma läuft (abhängig vom verwendeten Applikationsprotokoll), gefiltert und weitergeleitet.
  • Die Firewall, die Ihre Back-End-Netzwerkzone schützt, lässt nur Verkehr zu, der von Ihren Application-Gateways in der DMZ stammt.
  • Die Back-End-Netzwerkzone wird ferner durch eine zweite interne Firewall Ihres internen Benutzernetzwerks geschützt.

Innere und äußere DMZ

Sie können die Sicherheit noch erhöhen, indem Sie die DMZ in zwei DMZ unterteilen:

  • Die äußere DMZ
  • Die innere DMZ

Die äußere DMZ wird der Einstiegspunkt vom Internet (restliche Welt) zu Ihrer Firma. Die innere DMZ wird der Einstiegspunkt zu Ihrem Back-End-Netzwerk, entweder von der äußeren DMZ oder vom internen Benutzernetzwerk, wobei hier innere SAProuter, innere SAP Web Dispatcher, Portalsysteme (z. B. SAP Enterprise Portal) oder andere Systeme eingesetzt werden, die Ihnen gestatten, auf Inhalte von Back-End-Systemen zuzugreifen.

Reverse Invoke

SAP unterstützt noch eine weitere Sicherheitstechnik, die unter dem Begriff Reverse Invoke bekannt ist. Sie ermöglicht den Aufbau von Netzwerkverbindungen vom Back-End-Netzwerk aus. Das erhöht die Netzwerksicherheit, da die Firewalls keinerlei Verbindungsaufbau mit dem Back-End-Netzwerk von außerhalb zulassen. Sowohl SAProuter als auch SAP Web Dispatcher können für eine Nutzung mit Reverse Invoke eingerichtet werden.

Nehmen wir ein Beispiel. Stellen Sie sich vor, eine Web-Anwendung wird durch ein SAP-System im Back-End-Netzwerk bedient. Wenn ein Benutzer die Web-Anwendung nutzen möchte, startet er einen Web-Browser und verbindet sich mit einem SAP Web Dispatcher in der DMZ. Der SAP Web Dispatcher dient als Einstiegspunkt in die Web-Anwendung. Ist jedoch eine Reverse Invoke-Verbindung eingerichtet, wird die Verbindung im SAP-System vom Internet Communication Manager (ICM) initiiert, und nicht vom SAP Web Dispatcher. Daher kann die innere Firewall (die das Back-End-Netzwerk schützt) so eingestellt werden, dass keine eingehenden Verbindungen gestattet sind.

Reverse Invoke

Transport Layer Security

Sie können Ihr Netzwerk so lange sichern, solange Sie volle Kontrolle über die Netzwerk-Ressourcen haben. Sobald Ihnen diese Kontrolle abhandenkommt, müssen Sie sich auf die Sicherheitspolitik Dritter verlassen oder – schlimmer noch – können die Sicherheit Ihrer Daten überhaupt nicht gewährleisten. In diesem Fall müssen Sie auf nachfolgend erläuterte Verschlüsselungstechniken zurückgreifen, um die Vertraulichkeit und Integrität Ihrer Daten aufrechtzuerhalten.

Bitte bedenken Sie auch, dass die Sicherung Ihres Netzwerks nicht bedeutet, dass Sie auf Datenverschlüsselung verzichten sollten. Nichts liegt der Wahrheit ferner. Sehr kritische Daten (z. B. Personaldaten, medizinische Tests usw.) müssen normalerweise über verschlüsselte Datenwege übertragen werden, selbst dann, wenn Sie keine Unternehmensgrenzen überschreiten und das Netzwerk überall von Firewalls umgeben ist. Daher können folgende Techniken bei spezifischen Szenarien auch  in privaten Firmennetzwerken eingesetzt werden.

Secure Network Communications

Secure Network Communications (SNC) ist eine von SAP entwickelte Softwareschicht, die Datenkommunikationswege zwischen Komponenten eines SAP-Systems, das SAP-Protokolle wie RFC oder DIAG verwendet, durchgängig schützt. Sie stellt eine zusätzliche Sicherheitsschicht dar für die Kommunikation zwischen:

  • SAPGUI und SAP-Systemen
  • Zwei SAP-System-Servern (APAP und Java)
  • Externen RFC-Servern und SAP-System-Servern
  • SAProutern
  • SAP-Systemen und SAP-Druckerservern

Die SNC selbst enthält keinen Sicherheitsmechanismus, sondern stellt mit der GSS-API V2 (Generic Security Services Application Programming Interface Version 2) eine Schnittstelle für ein externes Sicherheitsprodukt bereit. So können Sie externe Sicherheitsprodukte einsetzen, die nicht direkt von SAP stammen (z. B. Smart Cards, Kerberos usw.).

Mit der SNC stehen Ihnen drei Sicherheitsschutzstufen zur Verfügung:

  • Authentifizierung: Das ist der geringste Schutz, bei dem nur die Identitäten der Kommunikationspartner überprüft werden. Die Daten werden unverschlüsselt gesendet.
  • Integrität: Bei diesem mittleren Schutzniveau können sämtliche unerwünschte Datenänderungen während der Übermittlung erkannt werden. Die Daten werden nach wie vor unverschlüsselt gesendet.
  • Privatsphäre: Sie bietet den höchsten Schutz. Die Daten werden zwischen den zwei Partnern über Kabel verschlüsselt übermittelt.

SAP stellt als standardmäßiges SNC-Sicherheitsprodukt kostenfrei die SAP Cryptographic Library bereit. Wenn Sie ein autorisierter SAP-Kunde sind, können Sie das Produkt auf dem SAP Service Marketplace (https://service.sap.com/swdc) herunterladen. Allerdings kann die SAP Cryptographic Library nur zur Implementierung von SNC zwischen Serverkomponenten verwendet werden, d. h. um Kommunikationen auf RFC-Basis zu schützen. Wenn Sie gleichzeitig die Kundenkommunikation schützen müssen (z. B. Verbindungen zwischen SAP GUI und Ihrem SAP-System), müssen Sie ein zusätzliches Produkt anschaffen, entweder von SAP (SAP NetWeaver Single Sign-On) oder einem zertifizierten Partner von SAP.

Denken Sie auch daran, dass pro Anwendungsserver nur ein SNC-Produkt verwendet werden kann. Es ist nicht möglich, abhängig von Ihrem Bedarf innerhalb einer SAP-Instanz zwischen verschiedenen SNC-Produkten hin- und herzuwechseln.

Secure Sockets Layer

Das Secure Sockets Layer (SSL) ist ein weitverbreitetes, von Netscape in den Neunzigern entwickeltes Verschlüsselungsprotokoll zur sicheren Datenübertragung auf ungesicherten Medien im Internet und darüber hinaus ein Mittel, um Abhörversuche und unbefugte Eingriffe zu verhindern. Der Begriff SSL wird heute allgemein auch für seinen Nachfolger, das Transport Layer Security (TLS), verwendet. SSL findet sich inzwischen fast überall im Internet. Falls Sie es noch nicht wussten: Jedes Mal wenn Sie in die Adresszeile Ihres Browser “https://…” eingeben, werden die Daten über eine SSL-Verbindung hin- und hergesendet. Für e-Commerce, darunter Online-Banking, Ebay, Paypal usw., ist SSL unerlässlich, also sind Sie ihm sicher schon begegnet.

Das SSL liegt zwischen der TCP-Schicht und der Anwendungsschicht (z. B. HTTP), auf dem TCP/IP-Stapel. Es verwendet eine Reihe von Verschlüsselungstechniken und bietet damit die gleichen Sicherheitsniveaus wie SNC:

  • Es authentifiziert den Client, den Server oder beide über ein asymmetrisches Verschlüsselungssystem. Beim SSL-Authentifizierungsmechanismus spielen digitale Zertifikate eine wichtige Rolle.
  • Es sorgt mithilfe eines symmetrischen Verschlüsselungssystems dafür, dass Daten vertraulich bleiben.
  • Durch Nachrichtenauthentifizierungscodes (MAC) wird zudem die Datenintegrität gewährleistet.

TLS und SSL sind heutzutage fester Bestandteil der meist genutzten Browser (Internet Explorer, Firefox, Chrome, Opera, usw.) und werden von fast allen Webservern, einschließlich SAP-Systemen, unterstützt.

Bei neuen Systemen mit SAP NetWeaver 7.3x kann SSL durch die richtige Konfiguration des ICM, für ABAP- und Java-Stacks, in SAP implementiert werden. Bei Java-Systemen, die mit früheren Versionen von SAP NetWeaver arbeiten, unterscheidet sich die Vorgehensweise etwas. Hier müssen Sie stattdessen den SSL Service Provider einrichten.

Damit Ihr SAP-System für SSL-Übertragungen gerüstet ist, müssen unabhängig von der Version folgende Anforderungen erfüllt sein:

  • Auf dem SAP-Server muss die SAP Cryptographic Library installiert sein.
  • Sie benötigen Zugriff auf ein PKI-Untersystem, damit das digitale Zertifikat des SSL-Servers von Zertifizierungsstellen erzeugt und registriert werden kann.
  • Sie benötigen einen Container für alle Zertifikate von SSL-Verbindungen. Dieser Container wird wie bei SAP NetWeaver 7.3x in Form einer Datei implementiert, die den Namen SSL Server Personal Security Environment (SSL Server PSE) trägt, und zwar egal ob Sie mit ABAP-, Java-Stacks oder beiden arbeiten. In der ABAP-Umgebung hat sich in Bezug auf ältere Versionen nichts geändert. Bei Java allerdings nutzen Vorgängerversionen von NW 7.3x einen speziellen Service, den so genannten Key Storage, um die Sicherheit der SSL-Zertifikate zu gewährleisten.

Es gibt in der SAP-Welt viele Szenarien, in denen Datenübertragungen durch SSL-Tunnel geschützt werden. Dazu fallen mir folgende Beispiele ein:

  • SAP Mobility-Produkte wie Afaria und Sybase Unwired Platform
  • Web Dynpros
  • ICF-Services
  • SAP GUI für HTML
  • Webservices
  • SAP Message Server
  • SAP NetWeaver Portal
  • SAP NetWeaver PI
  • SAP NetWeaver Gateway

Virtual Private Networks

Virtuelles privates Netzwerk (VPN) ist der allgemeine Begriff für verschiedene Techniken, um private Netzwerke über öffentliche Netzwerke wie das Internet so zu verbinden, dass ein Host-Computer, der sich an einem dieser privaten Netzwerke befindet, Daten an andere so weiterleiten kann, als gäbe es nur ein logisches privates Netzwerk.

Sie können sich ein VPN als einen langen Kanal zwischen zwei Punkten vorstellen, bei dem Sie nicht sehen was sich darin befindet. In der realen Welt wird der Kanaleffekt durch Tunnelprotokolle erreicht und die Undurchsichtigkeit durch Verschlüsselungstechniken.

Das VPN-Sicherheitsmodell bietet ebenso wie SNC und SSL:

  • Vertraulichkeit, da Daten verschlüsselt versandt werden;
  • Absender-Authentifizierung, um den Zugriff nicht berechtigter Benutzer auf das VPN zu verhindern;
  • Nachrichtenintegrität, um zu erkennen, ob übermittelte Nachrichten manipuliert wurden.

Eine kontroverse Eigenschaft der VPN-Techniken ist die Anzahl verschiedener Tunnelprotokolle (z. B. IPSec, TLS/SSL, PPTP), die von Verkäufern von VPN-Lösungen verwendet werden. Normalerweise erfordert jedes dieser Protokolle eine spezielle VPN-Client-Software, was Kompatibilitätsprobleme zwischen diesen VPN zur Folge hat. Trotzdem ist der Einsatz von VPN zur Verbindung entfernter Standorte heute weit verbreitet, und ermöglicht beispielsweise Mitarbeitern, von zuhause zu arbeiten.

Das eindeutigste Beispiel für die Verwendung von VPN-Techniken in der SAP-Welt ist die Verbindung von SAP-Systemen von Kunden mit SAP-Komponenten, über die SAP seine verfügbaren Remote Services bereitstellt (z. B. Remote Support, OS/DB Migration Verifikationssitzung usw.). Die Technik kann aber auch für die Verbindung privater SAP-Systeme mit anderen privaten Remote-Systemen verwendet werden, was bei B2B-Szenarien für gewöhnlich erforderlich ist.

Weitere Sicherheitstechniken

Lassen Sie mich nun noch kurz auf Trusted RFCs und die Mechanismen des Secure Store & Forward  (SSF) eingehen.

Wenn Sie mit der SAP-Terminologie vertraut sind, wissen Sie vielleicht bereits, dass SAP-Systeme auf Anwendungsebene durch Remote Function Calls (RFC) miteinander verbunden werden können. Ist ein aufrufendes SAP-System auf dem aufgerufenen System als trusted System registriert, ist kein Passwort notwendig. Und das ist aus sicherheitstechnischer Sicht letztlich der Hauptvorteil von trusted RFCs. Sie sollten allerdings folgendes berücksichtigen:

  • Daten, die über RFC selbst übermittelt werden, sind nicht verschlüsselt, außer Sie setzen auch SNC ein.
  • Eine Trusted-Beziehung funktioniert nur in eine Richtung.
  • Das Berechtigungsobjekt S_RFCACL muss im Trusting-System (dem aufgerufenem System) bleiben, damit trusted RFC voll funktionsfähig werden.
  • Die Methode ist nur zwischen ABAP-Systemen möglich.

Andererseits haben Sie in der ABAP-Welt Mechanismen des Secure Store & Forward (SSF), die Ihre Daten durch digitale Unterschriften und digitale Umschläge schützen. SSF ist so aufgebaut, dass es Daten auf Anwendungsebene mehr schützt als Kommunikationswege. Oder anders ausgedrückt, anstatt einen geschützten Kommunikationstunnel herzustellen, durch den Sie Daten senden, können Sie mit SSF Daten verschlüsseln, signieren und anschließend unter Wahrung der Vertraulichkeit (digitaler Umschlag) und der Integrität (digitale Unterschrift) bis an den richtigen Empfänger versenden, der wiederum in der Lage sein wird, diese zu entschlüsseln und zu verifizieren (und umgekehrt). Für die effektive Nutzung von SSF muss eine PKI eingesetzt werden. Das wird auch daran deutlich, dass standardmäßig für dieses sichere Datenformat PKCS#7 verwendet wird.

Sie können SSF zum Beispiel in folgenden Szenarien einsetzen:

  • Zur Speicherung vertraulicher Dokumente in der SAP-Datenbank, in verschlüsselter Form
  • Zur Speicherung vertraulicher Dokumente in einem externen Dateisystem oder auf einem Speichermedium (z. B. zur Bearbeitung durch eine fremde Schnittstellensoftware), in verschlüsselter Form
  • Zum Senden um Empfangen von signierten Daten an und von Geschäftspartnern und zur direkten Bearbeitung in SAP (solange diese mit PKCS#7 kompatibel sind)
  • SAP ArchiveLink

Die Verwendung von SSF in der Anwendungsschicht kann (abhängig vom Szenario) eine kundenspezifische ABAP-Entwicklung erfordern. SAP stellt die SSF-Funktion über eine Reihe von ABAP-Funktionsmodulen bereit. Auf niedriger Ebene benötigt SSF zusätzlich einen Sicherheitsanbieter. SAP liefert Ihnen entweder nur die Security Library (SAPSECULIB), die auf digitale Unterschriften beschränkt ist, oder die SAP Cryptographic Library – mit digitalen Unterschriften und Umschlägen. Sie können sich aber auch für externe Sicherheitsprodukte von SAP-zertifizierten Partnern entscheiden.

Fazit

Niemand kann heute die Notwendigkeit in Frage stellen, dass Systeme von Unternehmen sicher zusammenarbeiten. Diese Interoperabilität findet inzwischen global Anwendung und erstreckt sich über Unternehmensgrenzen hinaus. Das bedeutet beispielsweise, dass ein System der Firma ACME, die ihren Sitz in Spanien hat, sich mit einem anderen System der Firma EMCA verbinden muss, die in der USA liegt. Daher hat sich das Internet als Transportmedium durchgesetzt. Wir alle wissen aber, dass das Internet ein gewaltiger Dschungel ist, der von niemandem geregelt wird, und folglich ist die Sicherheit bezüglich Authentifizierung, Vertraulichkeit und Integrität ganz entscheidend, um über dieses Medium Geschäfte zu machen.

Ich habe hier einige Techniken aus der SAP-Welt vorgestellt, die sich an Unternehmen richten und von ihnen implementiert werden können, um gemäß aktuellen Sicherheitsstandards einen vernünftigen Schutz zu gewährleisten, während sie über ungesicherte Datenwege Geschäfte machen. Sicherheitskenntnisse entwickeln sich jedoch relativ schnell weiter und so wird es  bald neue Standards, Anforderungen und Schwächen geben.

Insofern lautet mein Rat: Widmen Sie Sicherheitsthemen so viel Zeit wie möglich und bleiben Sie bezüglich neuer Probleme mit SAP-Produkten und deren Abhilfemaßnahmen auf dem Laufenden. SAP bietet übrigens verschiedene Tools eigens zu diesem Zweck:

  • Sicherheitshinweise finden Sie auf https://service.sap.com/securitynotes.
  • Auf Anregung von Kunden hin führte SAP den so genannten SAP Security Patch Day ein (jeder zweite Dienstag im Monat), um sicherzustellen, dass alle Sicherheitsreparaturen für alle unterstützten SAP-Produkte auf dem SAP Marketplace zum Download bereitstehen.
  • Im SCN-Sicherheitszentrum – http://scn.sap.com/community/security – können Sie Blogs durchstöbern und lesen.

Bitte nehmen Sie diesen Rat ernst! 😉

Referenzen

  1. SAP NetWeaver Security Guide
  2. Hinweis 66687: Einsatz von Netzwerksicherheitsprodukten
  3. Secure Network Communications
  4. Einsatz der SAP Cryptographic Library für SNC
  5. RFC 5246: „Das Protokoll Transport Layer Security (TLS) Version 1.2“
  6. RFC 6101: “Das Protokoll Secure Sockets Layer (SSL) Version 3.0”
  7. SAP Softwarepartner-Programm
  8. Hinweis 486688: VPN-Verbindungen mit dem SAP-Netzwerk planen
  9. http://en.wikipedia.org/wiki/Virtual_private_network
  10. https://service.sap.com/securitynotes
  11. Digitale Unterschriften und Verschlüsselung
 
Artículo anterior

CERTIFICACIONES MICROSOFT: MCSA WINDOWS SERVER 2012

Artículo siguiente

GENERATE SSL CERTIFICATES WITH OPENSSL FOR SAP SYSTEMS

Sin Comentarios

Responder

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *