Studie über sichere webbasierte Übertragungswege

Transcription

Energiewirtschaft, Informationsmanagement
Nummer 16/2007
Herausgeber:
Verband der Elektrizitätswirtschaft – VDEW – e.V.
Robert-Koch-Platz 4
10115 Berlin
Ansprechpartner:
Energiewirtschaft,
Informationsmanagement
Beate Becker
Tel. 030 / 72 61 47-209
Fax 030 / 72 61 47-215
[email protected]
Studie über sichere webbasierte
Übertragungswege
Berlin, 15.06.2007
Studie über sichere webbasierte Übertragungsverfahren erstellt
Die VDEW-Projektgruppe „Sicherheit beim elektronischen Datenaustausch“ hat in einer
Studie die Möglichkeiten sicherer webbasierter Übertragungsverfahren untersucht, da dies
im Rahmen der Umsetzung der Datenformate im Rahmen des Festlegungsverfahrens der
Bundesnetzagentur BK6-06-009 eine wichtige Rolle spielt.
Der elektronischer Datenaustausch zwischen Marktteilnehmern gilt als sicher, wenn er über
spezielle Services und nichtöffentliche Netze (Value Added Networks, VAN, z. B. X.400Telebox) abgewickelt wird. Dabei entstehen jedoch volumenabhängige Kosten.
Als Alternativen bieten sich Internet-basierte Dienste an, die meistens in den Unternehmen
schon anderweitig genutzt werden und keine zusätzlichen Kosten verursachen. Mittlerweile
tauschen viele Häuser über E-Mail oder Filetransfer ihre Daten über das Internet aus.
Allerdings muss eine Datenübertragung über das offene Internet seriös abgesichert werden,
so dass die Echtheit der Herkunft (Authentizität) und die Unversehrtheit des Inhaltes
(Integrität) jederzeit gewährleistet ist. Der VDEW hat zu diesen Anforderungen bereits eine
Reihe von Materialien veröffentlicht (VDEW-Projekt VEDIS).
Sobald Datenaustausch über das offene Internet erfolgt, sollte gleichzeitig Verschlüsselung
und Signatur eingesetzt werden. Aber selbst abgesicherte E-Mail-Kommunikation kann
aufgrund des zeitversetzten Übermittlungsprozesses in einigen Fällen Nachteile haben. Dies
gilt besonders bei hohen Anforderungen an die Datenaktualität, an Quittungsmechanismen
und bei stark automatisierter Folgeverarbeitung. Diese Anforderungen bestehen z. B. im
Bereich der zeitnahen Bereitstellung von Verbrauchsdaten für Sondervertragskunden oder
im Fahrplanmanagement.
In diesem Dokument werden zukünftige Alternativen für einen Datenaustausch speziell über
das Internetteilsegment „World Wide Web“ diskutiert. Sie berühren nicht die dringende
Empfehlung, jede Form von geschäftlichem E-Mail-Verkehr abzusichern.
Andere Branchen haben auf ähnliche Anforderungen mit einer vergleichsweise kurzfristigen
Industrienormung reagiert. Vor allem im internationalen und nationalen Groß- und
Zwischenhandel wurde ein Verfahren entwickelt, das zeitnah (synchron) arbeitet. Dabei
werden bestehende Austauschformate genutzt und damit etablierte Prozesse und interne
Anwendungen nicht tangiert. Dies ermöglicht eine bessere Folgeverarbeitung und integriert
Sicherheitsmechanismen. Das Verfahren heißt EDIINT AS2. EDIINT steht dabei für
Electronic Data Interchange über das Internet; AS2 für Applicability Statement 2.
AS2 ist auch für die Stromwirtschaft bei entsprechender Größe des Marktteilnehmers
einsetzbar. AS2 nutzt die Kerntechnologie des World Wide Web (http).
Betriebswirtschaftliche Funktionen und Sicherheitsparameter sind innerhalb einer
Anwendungsumgebung parametrisierbar. Dadurch sind Sicherheitsmechanismen integraler
Bestandteil des Verfahrens bzw. der Anwendung. Es setzt eine ständig offene und durch
Firewall geschützte Internetverbindung voraus, wie sie auch beim Auftritt des Unternehmens
im World Wide Web benötigt wird. Es existiert eine Reihe von
Standardsoftwareimplementierungen.
Studie über sichere webbasierte
Übertragungswege
Sicherheitsempfehlungen bei externen
elektronischen Kommunikationsverbindungen über
das World Wide Web im Electronic Data Interchange
der deutschen Elektrizitätswirtschaft
VDEW-Projektgruppe Sicherheit beim elektronischen Datenaustausch
Version: 1.0
STAND: 15. JUNI 2007
EDI
INHALT
1
Management Summary.....................................................................................................3
2
Zielgruppe / Zielsetzung....................................................................................................4
3
Sicherheit im elektronischen Geschäftsverkehr als Gegenstand der Verbandsarbeit ......5
4
VEDIS – IT-Sicherheit im elektronischen Geschäftsverkehr.............................................6
4.1 Ziele von VEDIS – Sicherheit auf der Informationsebene .............................................6
4.2 Ziele von VEDIS – Sichere Übertragungsverfahren ......................................................8
4.2.1 Synchrone Verfahren schaffen Handlungsbedarf für Verbandsempfehlungen ......8
4.2.2 Fokus auf Transport und Information .....................................................................9
4.2.3 Was wird nicht behandelt? .....................................................................................9
5
Verbindungsvarianten im Internet ...................................................................................10
5.1 Allgemeine Klassifizierung...........................................................................................10
5.2 Verbindungen auf der Basis von http ..........................................................................11
5.2.1 Protokollkonformität von http-Requests ...............................................................11
5.3 Verbindungen auf der Basis von HTTPS.....................................................................12
5.4 Security-Anforderungen in E-Business-Architekturen .................................................13
6
Austauschformate, Kommunikationsverfahren und Sicherheitsmechanismen ...............15
6.1 Standards und Trends im Electronic Data Interchange (EDI) .....................................15
6.2 Das synchrone EDI-Verfahren AS2.............................................................................17
6.3 Web-EDI ......................................................................................................................20
7
Fazit der Betrachtung......................................................................................................21
8
Anhang............................................................................................................................22
8.1 Ausblick auf Webservice .............................................................................................22
8.2 Technische Empfehlungen zum Einsatz des EDIINT AS2-Verfahrens .......................28
8.3 Quellen ........................................................................................................................30
8.4 VDEW-Veröffentlichungen...........................................................................................30
8.5 Glossar ........................................................................................................................31
-2-
EDI
1 Management Summary
Elektronischer Datenaustausch zwischen Marktteilnehmern oder anderen Partnern gilt als
sicher, wenn er über spezielle Services und nichtöffentliche Netze (Value Added Networks,
VAN, z. B. X.400-Telebox) abgewickelt wird. Dabei entstehen jedoch volumenabhängige
Kosten.
Als Alternativen bieten sich Internet-basierte Dienste an, die meistens in den Unternehmen
schon anderweitig genutzt werden und keine zusätzlichen Kosten verursachen. Mittlerweile
tauschen viele Häuser über E-Mail oder Filetransfer ihre Daten über das Internet aus.
Allerdings muss eine Datenübertragung über das offene Internet seriös abgesichert werden,
so dass eine Echtheit der Herkunft (Authentizität) und eine Unversehrtheit des Inhaltes
(Integrität) jederzeit gewährleistet ist. Der VDEW hat zu dieser Anforderung bereits eine
Reihe von Materialien veröffentlicht (VDEW-Projekt VEDIS).
Sobald Datenaustausch über das offene Internet erfolgt, sollte gleichzeitig Verschlüsselung
und Signatur eingesetzt werden.
Aber selbst abgesicherte E-Mail-Kommunikation kann aufgrund des zeitversetzten
Übermittlungsprozesses in einigen Fällen Nachteile haben. Dies gilt besonders bei hohen
Anforderungen an die Datenaktualität, an Quittungsmechanismen und bei stark
automatisierter Folgeverarbeitung. Diese Anforderungen bestehen z. B. im Bereich der
zeitnahen Bereitstellung von Verbrauchsdaten für Sondervertragskunden oder im
Fahrplanmanagement.
In diesem Dokument werden zukünftige Alternativen für einen Datenaustausch speziell über
das Internetteilsegment „World Wide Web“ diskutiert. Sie berühren nicht die dringende
Empfehlung, jede Form von geschäftlichem E-Mail-Verkehr abzusichern.
Andere Branchen haben auf ähnliche Anforderungen mit einer vergleichsweise kurzfristigen
Industrienormung reagiert. Vor allem im internationalen und nationalen Groß- und
Zwischenhandel wurde ein Verfahren entwickelt, das zeitnah (synchron) arbeitet. Dabei
werden bestehende Austauschformate genutzt und damit etablierte Prozesse und interne
Anwendungen nicht tangiert. Dies ermöglicht eine bessere Folgeverarbeitung und integriert
Sicherheitsmechanismen. Das Verfahren heißt EDIINT AS2. EDIINT steht dabei für
Electronic Data Interchange über das Internet; AS2 für Applicability Statement 2.
AS2 ist auch für die Stromwirtschaft bei entsprechender Größe des Marktteilnehmers
einsetzbar. AS2 nutzt die Kerntechnologie des World Wide Web (http).
Betriebswirtschaftliche Funktionen und Sicherheitsparameter sind innerhalb einer
Anwendungsumgebung parametrisierbar. Dadurch sind Sicherheitsmechanismen integraler
Bestandteil des Verfahrens bzw. der Anwendung. Es setzt eine ständig offene und durch
Firewall geschützte Internetverbindung voraus, wie sie auch beim Auftritt des Unternehmens
im World Wide Web benötigt wird. Es existiert eine Reihe von
Standardsoftwareimplementierungen.
-3-
EDI
2 Zielgruppe / Zielsetzung
Diese Ausarbeitung richtet sich an Entscheider und IT- Verantwortliche und enthält im
Anhang konkrete Umsetzungshinweise für technisch interessierte Leser.
Elektronischer Datenaustausch zwischen den Marktteilnehmern wird heute über spezielle
Dienste auf Basis X.400 oder internetbasiert über E-Mail und Filetransfer (ftp) realisiert.
Diese Verfahren arbeiten ausnahmslos zeitversetzt (asynchron). Auf die Sicherheitsaspekte
bei dem internetbasierten Verfahren E-Mail mit Übertragbarkeit der Aussagen auf ftp wurde
bereits in veröffentlichten Dokumenten eingegangen. Es wird dringend empfohlen, diese
Verfahren zum Datenaustausch nur in verschlüsselter und signierter Form zu nutzen.
Zielsetzung dieses Dokumentes ist es, bereits jetzt zukünftig wichtige webbasierte Verfahren
anzusprechen. Dazu soll je nach Anforderung der Kommunikation ein geeignetes
synchrones Verfahren empfohlen werden. Dieses kann asynchrone Verfahren, muss sie
aber nicht ersetzen. Wichtig ist dabei, dass sich lediglich der Transportweg ändert und nicht
die Anwendungen. Die Verfahren können somit nebeneinander koexistieren. Dazu sind
grundsätzlich Lösungen in der Lage, die auf der World Wide Web Technologie und damit
dem http-Protokoll beruhen.
Das vorliegende Dokument diskutiert dabei 2 Varianten.
1) Web-EDI (Client-Server-Lösung):
Von Web-EDI wird dann gesprochen, wenn einer der Partner kein eigenes EDISystem betreibt oder betreiben lässt. Web-EDI ist stets eine Portalanwendung, die
durch den größeren Partner bereitgestellt wird, über die mit einfachen Mitteln
(manuell über Direkteingabe in einer Webseite; halbautomatisch über Datei-Upload)
Daten ausgetauscht werden.
2) http-Kopplung (Server-Server-Lösung):
Synchrone Kopplung zum Datenaustausch über EDI-Verfahren (EDIFACT) unter
Ausnutzung eines bestehenden Standards (AS2). Dies setzt entsprechende analoge
Infrastrukturvoraussetzungen auf beiden Seiten voraus.
Das vorliegende Dokument diskutiert Motivation und Voraussetzungen zur Einführung und
gibt technische Hinweise zur Umsetzung. Besonderer Schwerpunkt wird dabei auf die ITSicherheitsaspekte gelegt. Dazu wird zunächst der Zusammenhang zu den bisherigen
Verbandsempfehlungen in diesem Bereich erläutert.
-4-
EDI
3 Sicherheit im elektronischen Geschäftsverkehr als
Gegenstand der Verbandsarbeit
Die VDEW-Projektgruppe „Sicherheit beim elektronischen Datenaustausch“ hat zur Gewährleistung einer sicheren Kommunikation zwischen den Marktteilnehmern in der deutschen
Elektrizitätswirtschaft eine gemeinsame Erklärung zu "Sicherheitsrahmenbedingungen für
den elektronischen Geschäftsverkehr im deutschen Strommarkt“ zwischen den beteiligten
Verbänden angeregt. Die Erklärung wird von folgenden Verbänden getragen:

Bundesverband der Deutschen Industrie e. V. - BDI, Berlin

VIK Verband der Industriellen Energie- und Kraftwirtschaft e. V., Essen

Verband der Elektrizitätswirtschaft - VDEW - e.V., Berlin

Verband der Netzbetreiber - VDN - e.V. beim VDEW, Berlin

Verband der Verbundunternehmen und Regionalen Energieversorger in Deutschland VRE - e. V., Berlin

Verband kommunaler Unternehmen - VKU - e.V., Köln
Diese Erklärung bildet die gemeinsame Basis, damit die Sicherheitsbelange im Geschäftsverkehr in der Branche angemessen berücksichtigt werden.
Die Erklärung auf der verbandspolitischen Ebene wird durch entsprechende Dokumente im
organisatorischen und technischen Umfeld ergänzt und ausgestaltet. Diese Dokumente werden vom VDEW erarbeitet und veröffentlicht. Das zugehörige Verbandsprojekt heißt VEDIS.
Allgemein definiert, haben die organisatorischen Teile den Anspruch, ein einheitliches organisatorisches Sicherheitsniveau bei der Verschlüsselung und Signatur von unternehmensübergreifenden Transaktionen zwischen den Marktteilnehmern zu gewährleisten.
Ebenso allgemein definiert, sollen die technischen Teile der Dokumente auch beim Einsatz
unterschiedlicher Produkte oder Dienstleistungen die Interoperabilität auf der technischen
Ebene sicherstellen. VEDIS orientiert sich dabei strikt an Standards.
Die politischen, organisatorischen und technischen Aussagen in der gemeinsamen Erklärung
und seinen Folgedokumenten haben Empfehlungscharakter und sollen in der Solidargemeinschaft der Marktteilnehmer eine verlässliche Vertrauensinfrastruktur ermöglichen.
Die Maßnahmen dienen als Leitlinie bei der Umsetzung im eigenen Unternehmen und der
nachfolgenden Anwendung an den Marktschnittstellen. Alternative Vorgehensweisen sollen
begründbar sein und das allgemeine Sicherheitsniveau nicht beeinträchtigen.
Die Marktteilnehmer sind aus wirtschaftlichen Gründen daran interessiert, dass die
Vertrauensinfrastruktur sich weiter entwickeln kann. Nur dadurch ist die sichere elektronische
Abwicklung der Geschäfte gewährleistet und kann so ausgebaut werden, dass auch weitere
Automatisierungsschritte beherrschbar bleiben.
-5-
EDI
4 VEDIS – IT-Sicherheit im elektronischen
Geschäftsverkehr
4.1 Ziele von VEDIS – Sicherheit auf der Informationsebene
VEDIS sieht angesichts des Trends, Stammdaten, Zähldaten, Rechnungen oder Avise über
das Internet zu übertragen, konkreten Handlungsbedarf bei der Informationssicherheit. Dabei
entspricht die Verlagerung von organisationsübergreifender Kommunikation auf das Internet
dem Trend unserer Zeit. Schließlich ist die Dienstgüte des Internets für die Anforderungen
der deutschen Elektrizitätswirtschaft in den letzten Jahren ausreichend gut geworden, so
dass volumenabhängige Kosten für ein Value Added Network (VAN, z. B. X.400) keine
wirtschaftliche, organisatorische oder technische bzw. sicherheitstechnische Begründung
mehr haben. Die Übertragung über das Internet muss nur so sicher gemacht werden, dass
Echtheit der Herkunft (Authentizität des Absenders) und Unversehrtheit des Inhaltes
(Integrität der Daten) in jedem Fall gewährleistet bleiben bzw. Manipulationen automatisch
erkannt werden können. Dies gilt für asynchrone, also zeitversetzte Übertragungsmethoden,
wie E-Mail oder File Transfer oder für zunehmend wichtiger werdende synchrone Methoden.
Die bisherigen VEDIS-Dokumente haben die Voraussetzungen an eine branchenweite
Vertrauensinfrastruktur mit PKI-Mitteln definiert.
Die Dokumente orientieren sich an den Grundzielen

technische Konformität herstellen (bis möglichst zur automatischen Interoperabilität).

Mindestsicherheitsniveau verbandsseitig definieren.

Vergleichbarkeit zwischen den Unternehmen über das Selbsterklärungsprinzip
veröffentlichter Policy-Dokumente (Certificate Policy, CP) herstellen.
Die so definierte Vertrauensinfrastruktur konnte auf asynchrone Methoden, allen voran EMail (SMTP) mit dem dazugehörigen, aber allgemein einsetzbaren Sicherheitsstandard
S/MIME, unmittelbar angewendet werden.
Diese Übertragungsmethode und der damit verbundene Informationsschutz werden nach wie
vor wichtig bleiben.
Für den unformatierten Informationsaustausch von Dokumenten im Rahmen des Geschäftsverkehrs (nicht EDI) wird es sogar zu E-Mail mittelfristig keine wesentliche Alternative geben.
Dabei führt bei einer Übertragung über das Internet per SMTP nichts an einer informationsgebundenen Absicherung, also elektronischer Signatur und Verschlüsselung auf Mail- oder
Dateiebene vorbei, denn für den gesicherten Mailaustausch zum Partner wird kein VPN1
aufgebaut. Hier ist asymmetrische Kryptographie und damit Public Key Infrastruktur entweder auf Mailebene in Form von S/MIME oder auf Dateiebene als Dokumentensignatur zwingend erforderlich. Mittelfristig ist dabei aus wirtschaftlichen Gründen Mail-Verschlüsselung
als „undurchsichtiger Briefumschlag“ und Dateisignatur als „Unterschrift“ sinnvoll, um nicht
auch den „Briefumschlag“ neben der Datei / den Nettodaten zu Beweiszwecken aufbe-
1
Virtual Private Network
-6-
EDI
wahren zu müssen. Kurzfristig wird der Einfachheit halber beides zusammen als kombinierte
Mail-Verschlüsselung und –Signatur angewendet.
Die ungesicherte Internetkommunikation ist für Unternehmen ein ernstzunehmendes Risiko,
weil infolge der zunehmend automatisierten Verarbeitung eine Überprüfung der Kommunikation immer schwieriger wird. Auf jeden Fall nimmt der liberalisierte Strommarkt branchenweit E-Business-Charakter an. Deshalb müssen Sicherheitsmaßnahmen für diese weitere
Digitalisierung und Automatisierung der Geschäftsprozesse allen am Datenaustausch beteiligten Unternehmen „den Rücken frei halten“. Eine manuelle Überprüfung der Übertragungsqualität findet in dieser unaufhaltsamen Entwicklung zukünftig immer weniger statt. Sie muss
durch geeignete Sicherheitsmaßnahmen ersetzt werden. Nur so bleibt weitere
Rationalisierung beherrschbar.
VEDIS setzt keine Unternehmens-PKI voraus, sondern empfiehlt lediglich dort, wo elektronischer Datenaustausch zwischen Marktteilnehmern abgewickelt wird, entsprechende
organisatorische und technische Maßnahmen mit den Mitteln von Public Key Infrastruktur.
Gesetzliche Regelungen bestehen z. B. bei der elektronischen Rechnung oder formgebundenen Verträgen. VEDIS möchte dort, wo keine gesetzlichen Vorgaben existieren, preiswerte technische Lösungen bei angemessener organisatorischer Sicherheit empfehlen. In
bilateralen Vereinbarungen kann auf diese Verbandspapiere referenziert werden. Dadurch
kann mit geringem Aufwand ein EDI-Vertrag zwischen den Partnern geschlossen werden.
Wesentliches Dokument ist dabei die VDEW- Zertifizierungsrichtlinie (englisch Certificate
Policy, CP) und erläuternde Dokumente. Sie definiert die drei wesentlichen Branchenziele
von VEDIS

Interoperabilität

Mindestsicherheitsniveau und

Vergleichbarkeit
Es soll dadurch branchenweit ein vergleichbares Sicherheitsniveau eingeführt und durch
Veröffentlichung der Unternehmens-CP per Selbsterklärung durch den Marktteilnehmer
bestätigt werden. Die Unternehmens-CP soll sich an die vom VDEW veröffentlichte Zertifizierungsrichtlinie (VDEW-CP) anlehnen; Aufbau und zahlreiche Formulierungen können
übernommen werden. Mit dieser Erklärung kann von jedem Marktteilnehmer, der sich zu den
VEDIS-Empfehlungen bekennt, ein angemessener sicherer Umgang mit Geschäftsdaten
vorausgesetzt werden. Weitergehende Maßnahmen sind nicht vorgesehen.
Zur Gewährleistung von Interoperabilität ist der technische Bezug die ISIS-MTT-Norm mit
einigen bewussten Erleichterungen, um eine möglichst breite Anwenderbasis zu erreichen.
Die Erleichterungen (z. B. Verzicht auf deutsche Umlaute in den Zertifikaten, UTF-7Codierung) können dann, wenn normgerechtes Vorgehen und normgerechte Produkte am
Markt die Regel sind, aufgehoben werden. Sie werden im Dokument „Technische PKIInteroperabilität“ beschrieben.
-7-
EDI
4.2 Ziele von VEDIS – Sichere Übertragungsverfahren
4.2.1 Synchrone Verfahren schaffen Handlungsbedarf für
Verbandsempfehlungen
Die VDEW-Projektgruppe Marktschnittstellen hat bei den Nachrichtenformaten wichtige
Branchenanforderungen erkannt und in Form von UN/EDIFACT-Formaten normiert. Solange
die Austauschformate als Dateien (nicht zusätzlich gesichert) per VAN (z. B. X.400-Box)
oder (signiert und verschlüsselt) per E-Mail ausgetauscht werden, besteht auch kein weiterer
Handlungsbedarf durch Verbandsempfehlungen. Erst bei synchronen Verfahren sind
Sicherheitsmechanismen, Übertragungsparameter und Übertragungsprotokolle nicht mehr
selbstverständlich zu trennen. Das vorliegende Dokument trägt dieser neuen Anforderung
Rechnung und macht deutlich, weshalb entsprechende Empfehlungen ausgesprochen
werden.
Formatierte Daten, also der Austausch mittels EDI, werden zunehmend synchron übertragen, weil ein zeitnahes Quittungsmanagement und eine bessere und unverzügliche Folgeverarbeitung benötigt wird oder bei steigender Anzahl von Nachrichten wünschenswert ist.
Es gibt zwar schon käufliche Standardsoftware, die den Postkorb regelmäßig nach neuen EMails durchsucht und diese einer Folgeverarbeitung zuführt. Das SMTP-Protokoll ist jedoch
von seinem Designprinzip „Store-and-Foreward“ so ausgelegt, dass diese Dienstprogramme
nur innerhalb begrenzter Möglichkeiten bei E-Mail Effektivitätsgewinne bringen können. Mit
asynchronen Methoden werden zwar eine Digitalisierung des Übertragungsprozesses
erreicht und somit immerhin Medienbrüche verhindert. Zur besseren Folgeverarbeitung und
damit weiteren Automatisierung des Prozesses sind jedoch synchrone, ereignisgetriebene
Übertragungsmechanismen zumindest in einigen Anwendungsbereichen sinnvoll. Dies gilt
vor allem für zeitkritische Anwendungen, z. B. wo Kunden zeitnah ihre Verbrauchsdaten
benötigen oder auch im Fahrplanmanagement.
Dies ist mit Verfahren denkbar, die auf dem Standardprotokoll des World Wide Web (http)
beruhen (z. B. Web-EDI-Portale oder neuerdings AS2 (Applicability Statement, siehe
Kapitel 4.2).
Grundsätzlich gibt es zu zertifikatsbasierten Authentisierungs-Mechanismen keine sinnvolle
Alternative. Alles andere, wie Value Added Networks (z. B. X.400, POP3) oder eine
Kennung/Passwort pro angeschlossenem Unternehmen wären teurer oder unangemessen
unsicher. Es müssen allerdings nicht immer personengebundene Zertifikate benutzt werden,
wenn durch Kombination von Maßnahmen ein geeignetes Sicherheitsniveau erreicht wird.
-8-
EDI
4.2.2 Fokus auf Transport und Information
Sicherheitsmaßnahmen auf der Informationsebene haben den Vorteil, Sicherheitsmechanismen direkt an die Daten zu binden. Dies wird heute vorwiegend mit Mitteln einer Public Key
Infrastruktur (PKI) gemacht. Allerdings scheuen viele Unternehmen den organisatorischen
Aufwand, der mit dem Aufbau von PKI verbunden ist und suchen nach Möglichkeiten, allein
auf der Leitungsebene zu schützen.
Transportgebundene Sicherheit und informationsgebundene Sicherheit sollten aber nicht als
alternative Methoden oder gar als Gegensätze verstanden werden, sondern haben verschiedene Funktionen: Das VPN dient als gesicherter „Tunnel“ und Signaturen als „Plombe“. Bei
modernen synchronen Verfahren existiert keine unmittelbar einsichtige und klare Grenze
mehr zwischen sicherer Authentisierung, Schutz der Verbindung gegen Manipulation und
vertraulicher Übertragung.
In diesem Dokument wird stärker auf Sicherheitsmaßnahmen in Verbindung mit synchronen
Übertragungsverfahren eingegangen. Das vorliegende Dokument klammert den Bereich der
asynchronen Kommunikation, also vorwiegend E-Mail oder File Transfer, weitgehend aus,
weil er in anderen VEDIS-Dokumenten ausführlich behandelt wurde. Es werden keine tieferen Leitungsprotokolle diskutiert, sondern Mechanismen, die vor allem für sichere Datenübertragung über das Internet geeignet sind bzw. dafür konzipiert wurden.
Ziel dieses Dokumentes ist es (neben dem hier ausgeklammerten E-Mail oder auch dem
Filetransferverfahren ftp)

weitere standardisierte externe Kommunikationsverbindungen über das Internet

in überschaubarer Zahl

mit begründeten Abstufungen und Anwendungsfällen
zu empfehlen.
Im Hauptteil dieses Dokumentes werden die Verfahren sowie ihre Vor- und Nachteile
diskutiert und Empfehlungen ausgesprochen. Der Anhang soll technische Hilfestellung
geben, wie diese Alternativen in der Praxis umzusetzen sind.
4.2.3 Was wird nicht behandelt?
Informationsgebundene Sicherheit kann bis zur End–to–End–Security ausgebaut werden.
Wird dies nicht gemacht, müssen angrenzende Systeme zumindest im Prinzip mit angesprochen werden, um die Sicherheit der ganzen Transaktionsstrecke beurteilen zu können.
Die Kontrolle externer Verbindungen allein durch Firewall-Systeme an der Netzwerkgrenze
bieten in der Mehrzahl der Fälle keine hinreichende Sicherheit für Informationsobjekte bzw.
ihre Verarbeitungssysteme. Vielmehr bedarf es einer angemessenen Kombination aus
verschiedenen, ineinander greifenden Mechanismen, um ein notwendiges Maß an Sicherheit
für interne Systeme zu erzeugen. Zu diesen Mechanismen zählen unter anderem auch
fallweise die Überwachung und Härtung des internen Systems selbst. Auch der Einsatz von
hostbasierten Intrusion Detection Systemen kann notwendig werden, auf die hier aber nicht
-9-
EDI
näher eingegangen wird. Im Allgemeinen wird bei dem gewählten Ansatz von „Verteidigung
in der Tiefe“ gesprochen.
Art und Umfang der als angemessen einzustufenden Schutzmaßnahmen hängen in erheblichem Maße von der Vertrauenswürdigkeit des externen Kommunikationspartners einerseits
und der Schutzbedürftigkeit des internen Systems andererseits ab. „Innere Klammer“ ist
dabei der Schutzbedarf der Informationsobjekte (Daten), die im Innenverhältnis durch die
Verarbeitung und im Außenverhältnis durch die Übertragung betroffen sind. Jedes Unternehmen sollte deshalb Rahmenbedingungen zur Einstufung der Vertrauenswürdigkeit
externer Kommunikationspartner und der Schutzbedürftigkeit interner Systeme definiert
haben. Eine korrekte Einstufung der beiden Kommunikationsendpunkte und der dazwischen
liegenden Verbindung ist eine unabdingbare Voraussetzung für die Auswahl der Zugangstypen. Der Schutzbedarf einer Klasse von Daten/Informationsobjekte (z. B. Adresse,
Bankverbindung) wird durch gesetzliche Regelungen oder durch den Dateneigentümer
festgelegt.
Auf diese Aspekte geht dieses Papier nicht näher ein. Sie werden in den VDEW-Materialien
M-14/2004, Konzept für IT-Sicherheit, behandelt.
5 Verbindungsvarianten im Internet
Der Austausch von Geschäftsdaten über das Internet wird im Allgemeinen „E-Business“
genannt. Ziel dieses Kapitels ist es, die organisatorischen und technischen Aspekte von
synchronen Verbindungen zu diskutieren und daraus Sicherheitsanforderungen für die
Geschäftsabwicklung abzuleiten.
5.1 Allgemeine Klassifizierung
Heute wird umgangssprachlich oft das World Wide Web (WWW) mit dem Begriff „Internet“
gleichgesetzt. Im ursprünglichen Wortsinn ist Internet die Kommunikation in einem offenen
Netz, die mittels des Internet Protocol (IP) vermittelt wird. In diesem Netz haben sich
zahlreiche Dienste mit ihren spezifischen Protokollen etabliert. Dazu gehören das Simple
Mail Transfer Protocol (RFC 2821) und das File Transfer Protocol (RFC 959) oder auch
Telnet (RFC 854 und RFC 855). Telnet bietet eine bidirektionale, 8-bit-pro-Byte-orientierte
Kommunikationsmöglichkeit und wird ebenfalls als Dienst gesehen. In diesem Sinne ist auch
das WWW mit dem http-Protokoll ein Dienst. Eine Fülle weiterer Dienste und Protokolle
verbergen sich hinter den Abkürzungen:
HTTPS, DNS, MBS/IP, NTP, UUCP, NNTP, SSH, IRC, SILC, SNMP, SIP, RTP, IMAP,
ED2K, LDAP, usw. Diese Begriffe repräsentieren Anwendungen oberhalb der
Transportschicht, die immer IP-basiert ist, aber unterschiedlich ausgeprägt sein kann (TCP,
UDP, SSL, SCTP, DCCP, etc.).
Von diesen Anwendungen sollen in diesem Kapitel das Hyper Text Transfer Protocol (http)
auf Basis des Transportprotokolls TCP und seine gesicherte Variante https besonders
- 10 -
EDI
interessieren. Es ist die Kerntechnologie im World Wide Web, dem heute wichtigsten
Anwendungsbereich von Internettechnologie überhaupt.
5.2 Verbindungen auf der Basis von http
http–Verbindungen sind mittlerweile eine eigene technische Welt. An dieser Stelle sollen
lediglich technische Bezüge zu Sicherheitsmechanismen hergestellt werden, die für externe
synchrone Verbindungen zum Zwecke des Datenaustauschs relevant sein können.
Auf den Aspekt „Protokollkonformität“ wird besonders eingegangen. Sicherheitsaspekte in
http-Kommandos sowie Zugriffssteuerung auf URL-Ebene werden ausgeklammert.
5.2.1 Protokollkonformität von http-Requests
Das Hyper Text Transfer Protokoll ist in RFC 1945 und RFC 2068 definiert. Es ist ein
verbindungsloses Protokoll. Dies ist funktional notwendig, erklärt aber im Prinzip die
wesentlichsten Angriffsflächen.
Einer der am häufigsten verwendeten Angriffe auf einen Webserverdienst ist das Versenden
von manipulierten http-Requests, die gezielt Sicherheitslücken des Dienstes ausnutzen. In
vielen Fällen werden vom Firewallsystem keine weiteren Überprüfungen am Datenstrom
durchgeführt. „Screening Firewalls“ und auch „Statefull Inspection Firewallsysteme“ überprüfen die Datenkommunikation auf Sender- und Zieladresse, Sender- und Zielport. Sie sind
also nicht in der Lage, Angriffe über speziell formatierte http-Requests zu erkennen und zu
unterbinden. Oftmals geht mit einer solchen Attacke die Eroberung höchster Rechte auf dem
Webserver einher.
An der Netzgrenze kann jedoch sichergestellt werden, dass die übertragenen Daten konform
zum http-Protokoll den Webserver erreichen. Um den Datenstrom auf manipulierte http-Requests zu überprüfen, finden Reverse Proxies oder Security Server Verwendung. Mittels der
Methoden „Reassembly“, „Scrubbing“ und „Normalization“ kann der Datenstrom verarbeitet
und so ein schadhafter Code erkannt und eliminiert werden. Auch wenn heute weit entwickelte Produkte diese Arbeit erledigen, hilft das Verständnis dieser Sicherheitsmethoden,
Sicherheitslücken zu erkennen und zu schließen.
TCP/IP ist bekanntlich paketorientiert. Die Pakete müssen nicht in der richtigen Reihenfolge
ankommen. Reassembly sorgt zunächst für die richtige Reihenfolge als Voraussetzung für
weitere Untersuchungen. Scrubbing eliminiert Duplikate, Überlappungen und Interpretationsspielräume auf syntaktischer oder auch semantischer Ebene, so dass ein über mehrere
Pakete verteilter Angriff erkannt werden kann. Normalization sorgt für eine einheitliche
Darstellung bei möglichen alternativen Darstellungsmethoden, so dass auf einer
einheitlichen, „sprachlichen“ Ebene ein schädlicher Code erkannt werden kann.
Ordnung, Filterung und Vereinheitlichung sind Voraussetzungen für ein erfolgreiches
Abwehrverhalten gegen einen schädlichen http–Code. Wird dies konsequent eingehalten, so
können ohne Sicherheitsbedenken EDI-Server über das Internet betrieben werden.
- 11 -
EDI
5.3 Verbindungen auf der Basis von HTTPS
Mit https://... beginnen URL (Uniform Resource Locators), bei denen die Datenübertragung
zwischen Browser und Webserver über die Verfahren SSL (Secure Socket Layer) oder über
TLS (Transport Layer Security) verschlüsselt wird. https ist deshalb in jeweils unterschiedlichen Normen (RFC) je nach verwendeter Zwischenschicht definiert. Es sichert das im
Prinzip zustandslose http-Protokoll mit Hilfe von (zunächst) asymmetrischer und (nach
gesichertem Schlüsselaustausch) symmetrischer Kryptographie ab. Der öffentliche Schlüssel
des Servers wird dabei durch ein X.509-Zertifikat bestätigt und muss vorher in den Browser
installiert werden. Nach dem sicheren Kommunikationsaufbau mit Hilfe asymmetrischer
Methoden und dem gegenseitigen Austausch von jeweils unterstützten Algorithmen werden
symmetrische Sitzungsschlüssel vereinbart. Der Sitzungsschlüssel wird dann zur
performanten, symmetrischen Verschlüsselung genutzt. In sensiblen Bereichen und im
Außenverhältnis sollte mit 128 Bit langen Schlüsseln gearbeitet werden.
Die Certification Authority (CA), als vertrauenswürdige dritte Instanz der beiden Kommunikationspartner, bestätigt den öffentlichen Schlüssel per Zertifikat und garantiert so die unverfälschte Übertragung der öffentlichen Schlüssel und die Echtheit des Webservers mit Hilfe
von Fingerprint-Vergleichen. Das Zertifikat der CA wird in allen Browsern installiert und
erscheint dort als "vertrauenswürdige Stammzertifizierungsstelle". Sollte das Zertifikat nicht
installiert sein, erhält der Benutzer beim Öffnen der Webseite eine Fehlermeldung und eine
Abfrage, ob er die Verbindung trotzdem herstellen möchte.
Der Benutzer baut die Verbindung auf, indem er entweder auf einen Link (beginnend mit
https://.....) klickt oder die URL im Browser einträgt. Der Browser baut daraufhin eine
Verbindung nicht mehr über Port 80 sondern über Port 443 (Default-Wert) zum Webserver
auf. Der Webserver überträgt sein Zertifikat, das der Client mit Hilfe des installierten CAZertifikats auf Echtheit überprüft. Danach generiert und überträgt der Browser einen nur für
den Webserver lesbaren Sitzungsschlüssel (mit dem öffentlichen Schlüssel des Webservers
verschlüsselt). Mit dem nun auf beiden Seiten vorhandenen Sitzungsschlüssel kann eine
symmetrische Datenverschlüsselung beginnen. Während das http bzw. https–Protokoll der
Anwendungsschicht zugeordnet werden muss, liegt das eigentliche kryptographische
Verfahren bei SSL (Secure Socket Layer). SSL setzt auf der Socket-Schicht oberhalb
TCP/IP auf und kann auch für andere Anwendungsprotokolle (z. B. ftp) verwendet werden.
Wird das SSL–Verfahren auf Webseiten über das Hypertext Transfer Protocol http
angewendet, so ändern sich die URL von http zu https. SSL kennt die Algorithmen, nutzt
Serverauthentisierung und optional auch Clientauthentisierung und sorgt für Datenintegrität
im Rahmen des paketorientierten Übertragungsverfahrens TCP, d. h. sichert insbesondere
die einzelnen Datenpakete in sich ab.2
Eine bereits hergestellte https-Verbindung kann von einem der Client-Server-Kommunikation
zwischengeschalteten Firewall-System oder Proxy-System nicht überwacht werden. Der
Firewall oder dem Proxy ist es lediglich möglich, den Datenverkehr auf Grund von IP-Adres-
2
Inzwischen ist in RFC 2246 mit Transport Layer Security (TLS) ein Nachfolger von SSL als offener
Standard definiert. Die Unterschiede zu SSL, Version 3, sind minimal.
T. Dierks, C. Allen: RFC 2246: The Transport Layer Security (TLS) Protocol, Version 1.0, Januar 1999
http://www.ietf.org/rfc/rfc2246.txt
- 12 -
EDI
sen und Portnummern zu verbieten. Im Datenstrom selbst können, auf Grund der in den
TCP-Paketen verschlüsselten Daten, keine weiteren Überprüfungen durchgeführt werden.
Um den Datenverkehr dennoch überwachen zu können, muss ein Reverse–Proxy-System
konfiguriert werden. Der Webserver wird nun nicht mehr direkt angesprochen, sondern erhält
seine Anfragen vom Reverse-Proxy. Um die Kommunikation von Client zum Reverse-Proxy
gesichert ablaufen zu lassen, wird auf dem Reverse-Proxy ein Server-Zertifikat benötigt, so
dass eine verschlüsselte Verbindung aufgebaut werden kann. Der Reverse-Proxy seinerseits
baut eine Verbindung zum eigentlichen Zielsystem auf. Hierbei besteht grundsätzlich die
Möglichkeit, die Verbindung zwischen Reverse-Proxy und dem Zielsystem ebenfalls zu
verschlüsseln – aber auch eine unverschlüsselte Weiterführung der Kommunikation ist
möglich.
Sobald dem Reverse–Proxy-System der unverschlüsselte Datenstrom vorliegt, ist es
möglich, diverse Überprüfungen am Datenstrom vorzunehmen und kontrollierend auf ihn
einzuwirken. Beispielsweise können jetzt Normalisierungen oder Viren-Überprüfungen an
übertragenen Objekten durchgeführt, Webserver- und Virenattacken erkannt und
Zugriffsbeschränkungen bezüglich Kommandos und URL implementiert werden.
5.4 Security-Anforderungen in E-Business-Architekturen
Aus dem Anwendungsszenario „E-Business“ und den genannten technischen
Rahmenbedingungen und Protokollebenen im WWW können Security-Anforderungen
abgeleitet werden.
Die verbreiteten Plattformen für E-Business Anwendungen3 werden nach analogen Architekturprinzipien eingesetzt. Sie haben zu einer mehrschichtigen Architektur (Multi-Tier) geführt.
Im Firewall-geschützten Intranet steht der Application Server als Back-End und hat Zugriff
auf etablierte ältere Anwendungen („Legacy“) und auf Datenbanken.
Je nach Größe können Varianten mit und ohne Demilitarisierte Zone (DMZ) gewählt werden.
Mit der DMZ-Variante sind Backup-Konzepte (z. B. über mehrere Provider) realisierbar, falls
die Produktionsverbindung ausfällt.
3
In alphabetischer Reihenfolge BEA, IBM, Microsoft, Oracle, SAP, SUN
- 13 -
EDI
Variante 1: mit DMZ
In einer DMZ stehen empfangender Webserver bzw. Portalserver als Front-End und werden
durch Firewall gegen das Internet geschützt.
Variante 2: ohne DMZ
Der Webserver empfängt und sendet Daten über einen Provider und ist durch eine
entsprechend konfigurierte Firewall geschützt.
E-Business Service
Term inal
Serviceportal
Businesslogik
Nicht Inform ationsgebundener,
persistenter Schutz
Transportgebundene
Sicherheit
Transaktion
Internet,
M obile
Netze,
...
Service Frontend
m it oder ohne DM Z
Intranet
Service Backend
Abb. 1: Status Quo E-Business Security Schlechte Nutzung informationsgebundener Sicherheit
Im Prinzip kann diese Architektur beim synchronen EDI-Datenaustausch über das Internet in
zwei Kommunikationsformen genutzt werden:
1) Server zu Server Kommunikation
2) Client zu Server Kommunikation („Web-EDI“)
Im Folgenden werden Unterschiede zu asynchronen Verfahren diskutiert und wird auf die
beiden synchronen Verfahren näher eingegangen.
- 14 -
EDI
6 Austauschformate, Kommunikationsverfahren und
Sicherheitsmechanismen
6.1 Standards und Trends im Electronic Data Interchange (EDI)
Die folgende Grafik vermittelt einen Trend in den Datenübermittlungsmethoden von
asynchronen Methoden mit eigenem Netz, zur Internetübertragung mit asynchronen
Methoden und synchronen Methoden.
Electronic
Data
Interchange
Übermittlung
Vorgestern
Gestern
Heute
Morgen
Übermorgen
VAN
E-Mail/
Filetransfer
Webportal
AS2
Webservice
Asynchron
Eigenes Netz
Volumenabhängig
Asynchron
Dienstorientiert
Datenunabhängig
Synchron
Browserorientiert
Endgeräteunabhängig
Synchron
HTTP-orientiert
Formatunabhängig
Synchron
Serviceorientiert
Workflowunabhängig
Abb. 2: Migration der Übermittlungsmethoden
Kurzcharakterisierung der Übertragungsmethoden:
1) Value Added Network
Meist X.400-Box der Deutschen Telekom
Volumenabhängige Kosten
gilt als hinreichend sicher
asynchrones Verfahren
Quittungsmechanismen
- 15 -
EDI
2) E-Mail
Internetbasierte Dienste
ohne Mehrkosten vorhanden
Simple Mail Transfer Protocol SMTP
keine Quittungsmechanismen
durch Zusatzfunktionen zu sichern
3) Filetransfer
Internetbasierter Dienst
ohne Mehrkosten vorhanden
File Transfer Protocol FTP
Quittungsmechanismen über 2. Kanal
durch Zusatzfunktionen zu sichern
4) Webportal
WWW-basiert
eigene Infrastruktur und Portalanwendung nötig
technisch synchrones Verfahren, über Handling de facto zeitversetzt
Datenaustausch über ASCII-Schnittstelle (Dialog oder halbautomatisiert)
dient meist zur Anbindung kleiner Partner ohne EDI-Infrastruktur
Sicherheit meist über Username/Passwort
5) AS2
WWW-basiert
integrierte Sicherheitsmaßnahmen
ständig offene Internetverbindung erforderlich
bestehende Austauschformate können verwendet werden (EDIFACT)
synchrones Verfahren
6) Webservice
WWW-basiert
Service orientierte Architektur – neue Philosophie
XML-Austauschformat
zukunftsorientiert, aber sehr großer Migrationschritt
enge Vertrauensbeziehung der Partner
Asynchrone Verfahren
In Form der so genannten Marktschnittstellen wurden EDI-Nachrichtenformate zum
Datenaustausch im Rahmen des liberalisierten Strommarktes in UN/EDIFACT genormt. Sie
wurden anfangs und werden immer noch häufig in Kombination mit Übertragungsdiensten,
wie der Telebox 400 4400 (X.400-Dienst mit Kurzwahl 4400) der Deutschen Telekom oder
anderer Value Added Networks (VAN), genutzt. Durch die externen Postfächer wird eine
ständige Erreichbarkeit der Kommunikationspartner gewährleistet. Mittlerweile haben sich
hier auch Dienstleister etabliert, die z. B. eine Kombination aus Kommunikations- und
- 16 -
EDI
Konvertierungsservices anbieten. Dies kann etwa mit Pop3-E-Mail-Einwahl und
Konvertierung von Inhouse-Format in EDIFACT und umgekehrt erfolgen.
In jedem Fall entstehen bei VAN weitere, insbesondere volumenabhängige Kosten. Dies ist
der Grund, wieso zunehmend eine Übertragung mittels eines VAN durch direkte Nutzung
des Internets ersetzt wird. Dieser Trend ist international zu beobachten, seit das Internet eine
so verlässliche Dienstgüte erreicht hat, die es erlaubt, geschäftskritische Daten in einem ausreichend kleinen Zeitfenster zu versenden. So sollten in Skandinavien deshalb schon X.400Boxen abgeschaltet werden und wurden nur nach Protesten von Anwendern weiterbetrieben.
Doch auch der Wechsel zu E-Mail oder Filetransfer als Kommunikationsmethode für EDI hat
Nachteile aufgezeigt.
In vielen Fällen ist eine Benutzereingabe erforderlich. Bei E-Mail ist zwar eine Digitalisierung
erreicht worden, die immerhin einen Medienbruch verhindert, aber das Automatisierungspotential ist noch nicht ausgeschöpft worden. E-Mail-Transfer kann deshalb nur ein
Zwischenschritt in der Entwicklung von organisationsübergreifenden Geschäftsprozessen
sein. Eine der innovativsten Formen der asynchronen Kommunikation stellt dabei EDIINT
AS1 (Applicability Statement 1) dar. Dabei werden Daten über SMTP weitgehend
automatisiert ausgetauscht; die Restriktionen des Simple Mail Transfer Protocols SMTP als
asynchrones Verfahren bleiben jedoch prinzipiell erhalten. Ein international wichtiger
Anwendungsfall von AS1 findet sich in der Kommunikation zwischen Pharmaindustrie und
Aufsichtsinstanzen beim Austausch von Dokumenten zur Arzneimittelsicherheit.
VerarbeitungsSystem / ERP
Webserver
Intranet
Internet
CLIENT
SERVER
Webbrowser
HTML-Formulare
Manuelle Erfassung oder
ASCII-Schnittstelle
Synchrone Serververbindung
http-Übertragung
Austauschformat z.B. UN/EDIFACT
Offene Internetverbindung
Web-EDI
EDI über http, z.B. AS2
Abb. 3: Synchrone, webbasierte Verfahren über Web-EDI oder AS2
6.2 Das synchrone EDI-Verfahren AS2
Die Unternehmen möchten zunehmend das Internet als Transportplattform nutzen und nicht
mehr über Value Added Services (VAN), wie X.400, Daten austauschen. VAN gelten zwar
- 17 -
EDI
als sicherer Transportweg, es entstehen aber volumenabhängige Kosten. Bei E-Mail entstehen kaum volumenabhängige Kosten, es müssen aber Sicherheitsanforderungen, wie
Vertraulichkeit, Unversehrtheit und Nichtabstreitbarkeit gewährleistet werden.
Aber auch SMTP als E-Mail-Standard im Internet oder das Filetransferprotokoll ftp haben
ebenso wie X.400 den Nachteil der Store-and-Foreward Übertragung. Durch die damit verbundene Asynchronität lässt sich eine automatisierte Weiterverarbeitung nur durch indirekte
Mechanismen erreichen. Bei E-Mail wird dies heute noch vielfach durch umständliche Auswertung der Betreffzeile erreicht. Oft sind trotzdem noch manuelle Eingriffe erforderlich, um
etwa einen Dateianhang einer Folgeverarbeitung zuzuführen. E-Mail-Transfer kann deshalb
nur ein Zwischenschritt in der Entwicklung von organisationsübergreifenden Geschäftsprozessen sein. In einigen Anwendungsfällen, wo es um zeitnahe Datenübermittlung geht,
werden deshalb synchrone Verfahren gefordert.
Auch für diese Verfahren muss die Sicherheit gewährleistet und in Form von Vereinbarungen
definiert werden.
In dem mit April 2004 gestarteten, am 12.07.2005 abgeschlossenen und damit noch relativ
neuen geplanten IETF-Standard EDIINT AS2 (Applicability Statement 2, RFC 4130) wird das
Standardprotokoll des World Wide Web, das Hyper Text Transfer Protocol http, eingesetzt.
Das Projekt EDIINT soll in seiner wichtigsten Intension ein Protokoll bereitstellen, das den
synchronen EDI-Datenaustausch über das Internet mit minimalen Umstellungskosten und
bei weicher Migration ermöglicht. Dies bedeutet, dass der Datenaustausch bei gleichzeitiger
Beibehaltung bestehender EDI-Austauschprozesse und unter Beibehaltung von netzspezifischen Nutzergruppen erfolgen muss. Die Daten werden immer über die gängigen Austauschformate, also Marktschnittstellen, ausgetauscht. Die EDI-Schnittstellen arbeiten heute
vor allem auf dem für die Stromwirtschaft wichtigen UN/EDIFACT-Format. Diese können bei
AS2 beibehalten werden und müssen nicht auf XML umgestellt werden. Bestehende Wege
(z. B. X.400, E-Mail) werden lediglich um einen weiteren Weg (http) ergänzt. Auf dem zusätzlichen, synchronen „Weg“ ist lediglich das Transportprotokoll anders, wie es auch beim
Übergang von X.400-Boxen zu E-Mail sich geändert hat. Somit kann man von InternetTechnologien profitieren, ohne die bestehenden Prozesse und Verarbeitungsschnittstellen
negativ zu beeinflussen.
Dies wird mittels standardisierter Signatur- und Verschlüsselungsmechanismen auf der
Transportebene erreicht. Es wird quasi ein sicherer Briefumschlag um jedes beliebige
Datenaustauschformat gebildet. AS2 verlangt zwingend ein TCP/IP-basiertes Netz und
erfordert eine ständige Erreichbarkeit der Kommunikationspartner über das Internet. Nach
dem Verbindungsaufbau erfolgt eine Authentifizierung und erst dann ein vertraulicher
Datenaustausch.
Die Anforderung nach ständig offener Internetverbindung ist für große und mittlere Häuser
unproblematisch und wird für den Internetauftritt seit langem in Eigenverantwortung im
Rahmen eines Web-Servers in einer so genannten DMZ (mittels Firewall abgesicherte
demilitarisierte Zone) praktiziert. Kleinere Häuser organisieren ihren Internetauftritt jedoch oft
nicht selbst und sind deshalb mit dieser Technologie möglicherweise überfordert.
- 18 -
EDI
Vorteile von AS2
•
Etablierte Nachrichtenformate können beibehalten werden
•
Bestehende Anwendungen und Prozesse bleiben unberührt
•
Nur das Transportnetzwerk wird geändert
•
Internet-basiert (TCP/IP)
•
Kerntechnologie des World Wide Web (http)
•
Vertraulicher Versand von Dokumenten für bestimmte Empfänger
•
Sichere Übertragung ohne Mitlesemöglichkeit
•
Unleugbarkeit
•
Quittungsmechanismen
•
Statusinformationen des Dokumentes / Erkennen von Veränderungen
•
Konsequente Verwendung und Integration bestehender Standards
Vor allem bei Anforderungen an ein konsistentes Quittungsmanagement haben synchrone
Verfahren herausragende Bedeutung, weil nur ein Request-Response-Verfahren zeitnah und
unter Bezug auf die einzelnen Verarbeitungsebenen quittieren kann. Logisch getrennte
Ebenen sind anhand folgender Fragen zu unterscheiden:
1. Physikalische Übertragung korrekt? (Kommunikationsantwort, Communication
Response)
2. Syntaktisch korrekt? (Funktionsantwort, Functional Response)
3. In der Anwendung verarbeitbar? (Geschäftsstufenantwort, Business Level Response)
4. Vertraglich korrekt?
Wenigstens bei den Punkten 1-3 ist eine synchrone Quittungsbehandlung wünschenswert,
Punkt 4 kann in letzter Konsequenz nur durch Menschen entschieden werden.
Bei AS2 kann neben 1-3 ein weiterer synchroner Empfangsbestätigungsmechanismus
eingestellt werden, der als Message Disposition Notification (MDN) bekannt ist und den
Verwendungszweck charakterisiert.
In Deutschland beginnt der Standard AS2 im Marktsegment Handel („Retail“) in rascher
Folge an Bedeutung zu gewinnen. Eine große Baumarktkette hat bereits AS2 eingeführt.
Andere große Handelsketten haben die Einführung angekündigt, begonnen bzw. umgesetzt.
Unter dem Dach der Branchenvertretung Global Standard 1 Germany (GS1) wurden
Empfehlungen erarbeitet. Es spricht vieles dafür, den Standard AS2 auch als synchrones
Verfahren für die deutsche Stromwirtschaft zu empfehlen, wenn entsprechender
Anwendungsbedarf entsteht. AS2 hat allerdings optionale Parameter; für diese Spielräume
innerhalb des Standards sind technische Empfehlungen zu treffen („Profilierung“).
Ein entsprechender weiterer Standard, EDIINT AS3, ist weniger in der Diskussion und nutzt
das File Transfer Protocol (ftp) als Transportmechanismus.
- 19 -
EDI
AS1, AS2 und in kleinem Umfang AS3 beginnen sich in einzelnen Märkten zu etablieren.
Entscheidend ist bei allen drei Verfahren, dass zwei korrespondierende Anwendungen eine
Reihe von technischen Abhängigkeiten haben, die zwischen den Partnern technisch und
auch vertraglich statisch abgestimmt werden müssen. Diese statische Abhängigkeit wird in
Kauf genommen, um eine kostengünstigere Änderung des Transportweges ohne
Änderungen auf der Prozess- und Informationsebene (z. B. EDIFACT) zu erreichen. Der
kostengünstigere Transportweg wird in den meisten Fällen dadurch erreicht, dass X.400Boxen durch eine Internet-Kommunikation abgelöst werden können.
6.3 Web-EDI
Von Web-EDI wird dann gesprochen, wenn einer der Partner kein eigenes EDI-System betreibt oder betreiben lässt. Web-EDI ist stets eine Portalanwendung, die durch den größeren
Partner bereitgestellt wird, über die mit einfachen Mitteln (manuell über Browser, halbautomatisch über ASCII-Schnittstellen) Daten ausgetauscht werden. Es ist ein Service im World
Wide Web (http). Er darf nicht mit Webservices verwechselt werden (siehe Anhang 8.2), die
darüber hinaus neue Architekturen und Sprachmittel verwenden.
AS2 erfordert Infrastruktur und EDI-Kenntnisse bei der Mitarbeiterqualifikation, die oft mit der
Größe des jeweiligen Kommunikationspartners zusammen hängt. Eine Alternative dazu kann
ein Web-EDI-Service sein, der zentral durch den größeren Partner bereitgestellt werden
muss.
Eine Server zu Server Kommunikation (wie AS2) und eine Web-EDI–Verbindung wird oft je
nach Größe der Kommunikationspartner angewendet. Web-EDI wird heute meist dann
benutzt, wenn kleinere Häuser Daten mit großen Unternehmen austauschen müssen und vor
allem die großen Unternehmen an einer elektronischen Kommunikation interessiert sind. Bei
Web-EDI genügt dem kleineren Partner ein Webbrowser, um manuell oder teilautomatisiert
Daten in das Portal des größeren Partners einzustellen. Bei Web-EDI sind praktisch keine
EDI-Vorkenntnisse beim kleineren Partner erforderlich, weil die EDI-Infrastruktur vom großen
Unternehmen bereitgestellt wird und als Austauschformat entweder HTML-Formulare zur
manuellen Erfassung bereit gestellt werden oder zur Teilautomatisierung lediglich eine
ASCII-Schnittstelle definiert werden muss. Diese haben sich in der deutschen
Stromwirtschaft bereits etabliert, wie z. B. die Einzelkundenwechsel oder die Eingabe von
Jahreszählerständen .
Soll der Datenaustausch im Strommarkt Web-EDI-basiert bzw. Portal-basiert erfolgen, so
entspricht das Vorgehensmodell einem Download oder Upload der Daten aus oder in das
Portal bzw. die Web-Anwendung des anderen Marktteilnehmers. Unter ITSicherheitsgesichtspunkten sind hier besonders Autorisierung und Authentifizierung
interessant. Autorisierung mittels Kennung/Passwort ist zwar noch weit verbreitet, wird aber
zunehmend durch zertifikatsbasierte Verfahren ersetzt, weil eine Unternehmenskennung
kaum geheim zu halten ist.
- 20 -
EDI
7 Fazit der Betrachtung
Im ersten Schritt sollten die Marktteilnehmer den Übertragungsweg E-Mail nutzen. Dabei
sind E-Mails mit personenbezogenem Inhalt aus Datenschutzgründen nach dem S/MIMEStandard zu verschlüsseln. Dies gilt auch für vertrauliche Daten insbesondere aus sensiblen
Tätigkeitsbereichen sowie für wirtschaftlich bedeutsame Netzdaten gemäß § 9, Abs. 1
EnWG. Der EDI-Anhang sollte signiert werden. Die weiteren aufgeführten Verfahren werden
sicherlich in den nächsten Jahren an Bedeutung für die Elektrizitätswirtschaft gewinnen.
Asynchrone Verfahren
Bei asynchronen Verfahren sollte, wie heute in der Bürokommunikation üblich, bei kleineren
Datenmengen E-Mail (SMTP) und bei größeren Datenmengen Filetransfer genutzt werden.
Die Grenze liegt heute in der Praxis bei ca. 5 MByte, mit großen Schwankungen, besonders
nach oben.
Sicherheitsmechanismen bei asynchronen Verfahren
Als Sicherungsmechanismus bei E-Mail sollte der S/MIME-Standard genutzt werden.
S/MIME ist jedoch nicht auf das E-Mail-Protokoll SMTP beschränkt. Beim Filetransfer bietet
sich nicht ftp oder secure ftp an, weil nur die Authentisierung des Clients am Server über
Kanal 21 per Secure Shell getunnelt, also verschlüsselt wird. Der Übertragungskanal der anschließenden ftp-Übertragung bleibt unverschlüsselt. Hier sollte das (nicht mit secure ftp zu
verwechselnde) SFTP verwendet werden, das auf SCP (Secure Copy Protocol) beruht, aber
weitere Dateioperationen ermöglicht.
Synchrone Verfahren
a) Web-EDI
Web-EDI als synchrone Austauschvariante kann als Alternative für kleine Partner angeboten
werden. Die Datensicherheit ist dabei durch Anwendung von https gewährleistet. Eine starke
Authentisierung ist wünschenswert. Kleinere Partner können mit Web-EDI angebunden werden. Dabei entspricht die benötigte Empfehlung für die ASCII-Schnittstelle des Portals den
heute praktizierten Austauschformaten.
b) AS2
AS2 als synchrones Standardaustauschverfahren über das Internet verlangt kaum Änderungen am Geschäftsprozess, sondern ist lediglich eine andere Transportvariante auf hoher
Protokollebene. UN/EDIFACT kann als Austauschformat beibehalten werden. Größere Partner, die auf synchrone Verfahren über das Internet unter Beibehaltung des UN/EDIFACTNachrichtenformates migrieren möchten, sollten AS2 verwenden.
Webservices und andere Verfahren
Für die deutsche Elektrizitätswirtschaft sind heute noch Austauschverfahren erforderlich, die
unabhängig von der Art des Übertragungsformates sind. Webservices erfordern das SOAPProtokoll und sind nur mit XML-Nachrichtenformaten sinnvoll einsetzbar. Sie sind deshalb
zum heutigen Zeitpunkt noch nicht für die Branche zu empfehlen, auch wenn den Serviceorientierten Architekturen die Zukunft gehört. Im Anhang wird deshalb auf diese zukünftigen
Technologien eingegangen.
- 21 -
EDI
8 Anhang
8.1 Ausblick auf Webservice
In den in Kapitel 6.1 genannten 6 Standardplattformen werden zügig Anwendungen unter
Nutzung von Webservice-Funktionalität entstehen. Es soll deshalb an dieser Stelle auf diese
neue Technologie und ihre Sicherheitsanforderungen eingegangen werden. Im typischen
Umfeld einer heute gebräuchlichen Website liefert der Webserver hauptsächlich HTMLSeiten, Bilder (JPG, GIF, PNG) und Stylesheets aus. Bis auf den zurück gelieferten MIMETyp (Multipurpose Internet Mail Extensions), also der Formatangabe, z. B. einer Datei, macht
es für den Webserver aber keinen Unterschied, welche Art von Daten er ausliefert.
Zunehmend wird aber neben der Auslieferung statischer Daten vermehrt auf den Einsatz von
Skripten (PHP, JSP, ASP), Server-Containern (Servlets, ASP.NET) und eben auch
Webservices über SOAP (Simple Object Access Protocol) zurückgegriffen. Dies ermöglicht
einerseits z. B. eine interaktive Benutzerführung, kann aber andererseits auch Angriffspunkte
liefern.
Aus diesem Grund sind Sicherheitsanforderungen weiter zu fassen. Sie betreffen nicht nur
die Verknüpfung von Personen oder Rollen mit ihrem Personal Security Environment
(Kennworte, Smartcards etc.) und ihre Integration in Sicherheitsinfrastrukturen (Netzlogin,
PKI, etc.), sondern müssen auf weitere IT-Instanzen (Anwendungen) ausgedehnt werden.
Gerade auch im Hinblick auf organisationsübergreifenden Einsatz in so genannten
föderativen Unternehmensprozessen, mussten deshalb eine Reihe von Web Service
Security Spezifikationen erarbeitet werden. Ebenso wie das Projekt Liberty Alliance4 setzen
sie auf XML–Security-Standards auf, wie SAML, XML–Signature, XML–Encryption, XACML
(AC für Access Control) und XKMS (für Key Management System).
Auf einige technische und organisatorische Aspekte dieser Normen soll eingegangen
werden.
Wichtig ist jedoch, dass die Kernanliegen von VEDIS auch im technischen Umfeld Service–
orientierter Architekturen gleich bleiben:

Vertraulichkeit der Informationsobjekte

Integrität des Inhaltes

Authentizität der Herkunft

Verbindlichkeit der Transaktion
sowie Verfügbarkeit der Technologie sollen stets sichergestellt sein.
In diesem Kontext sind die Anforderungen von VEDIS an Policies und
Vertrauensvoraussetzungen unverändert gültig und werden nur über natürliche Personen
hinaus auf neue Technologien übertragen.
4
Europäische Projektgruppe zu Datensicherheit und –schutz
- 22 -
EDI
Dabei sind jedoch einige wenige prinzipielle Erweiterungen zu berücksichtigen, die erst
sichere organisationsübergreifende Prozesse technisch ermöglichen. Sie beziehen sich im
Wesentlichen auf die Nutznießer von Ressourcen sowie die zugehörigen Rechte und
Regeln.
Internet
Externe
Mobile
Services
Published
Mobile
Mitarbeiter
HTTP
Zulieferer
WS
WS
UDDI
SOAP
Unternehmen
Mobile
Services
Branchen
Appl.
...
Kunden
Componenten
basiert
Mobile
Services
WS
WS
Mobile
Clients
Standardapplikationen
WS
WS
HTTP
SOAP
SCM
Services
SCM
WS
WS
Applikationsplattform
ERP
WS
WS
HTTP
CRM
Portal Server
Application Server
WS
WS
SOAP
Desktop
Clients
Integration Server
END - TO - END SECURITY
Nach G. Wiehler
Abb. 4: Technische Ausprägungen zukünftiger föderativer Strukturen
Webservices (WS)
Webservices sind ebenfalls synchrone Austauschverfahren über das Internet, die eine
Applikation–Applikation-Kommunikation mit Sprachmitteln erreichen, deren Austauschformat
auf XML und deren Protokoll auf SOAP beruht. Webservices haben dort, wo sie sinnvoll einsetzbar sind, einige technische und wirtschaftliche Vorteile. Allerdings ist die Einführung mit
teilweise gravierenden Änderungen verbunden. Diese beginnen bereits beim neuen Paradigma einer Service-orientierten Arbeitsweise, benötigen eine entsprechende technische
Umgebung und führen zu organisatorische Änderungen in den Geschäftsprozessen. Ziel ist
es, flexible, kombinierbare Bausteine zu erhalten, so dass der Geschäftsprozess nicht mehr
unmittelbar in der Anwendungsarchitektur berücksichtigt werden muss. Die Architektur ist
somit Workflow-unabhängig.
Mit den Webservices kann eine Plattform für verteilte Verarbeitungsprozesse aufgebaut
werden, die XML-Dokumente als grundlegende Informationseinheit interpretieren und
verarbeiten kann.
Eine entsprechende Verarbeitungs-Software in Form von Webservices kann im Web
publiziert und aufrufbar gehalten werden. Im Gegensatz zu früheren Verfahren, wie DCOM
und CORBA, wo gemeinsame Daten und Parameter (Sprache, Transportformat,
Messageformat, Firewall, etc.) Abhängigkeiten schufen, sind Webservices frei von solchen
- 23 -
EDI
Abhängigkeiten. Zum ersten Mal kann mit Hilfe von Webservices eine Service-orientierte
Architektur (SOA) realisiert werden.
1990
1980
Geschäftslogik
Geschäftslogik
2000
Geschäftslogik
2010
Service
Service
integriert
DB-Server
DB-Server
DB-Server
abhängig
Datenunabhängig
Endgeräteunabhängig
Nach J. Wagner
K. Schwarzenbacher
DBS
DBS
Workflowunabhängig
Abb. 5: Evolution der Lösungsarchitekturen nach SOA
SOA hat somit Möglichkeiten und Grenzen:
•
Für Prozesse oder Datenübertragungen, deren Laufzeit zu lange oder zu wenig
definiert sind, sind asynchrone Verfahren oder noch „klassisch“ zu nennende
synchrone Verfahren, wie AS2, nach wie vor besser geeignet.
•
Die ereignisgetriebene Kommunikation („Event–Driven“) ist eher keine treibende Kraft
für SOA und WS.
•
Für Anforderungen an bessere Real–Time-Fähigkeit und automatisierte Verarbeitung
haben Webservices in Service-orientierten Architekturen ihre Stärken.
•
Die Unterscheidung synchron/asynchron greift viel zu kurz. Für Webservices
sprechen vor allem eine größere Flexibilität durch die Entkopplung der Funktionalität
(Service) vom Geschäftsprozess (Business-Logik).
Eine wesentliche Forderung an IT-Infrastrukturen ist die Flexibilität geworden. Sie wirkt sich
an unterschiedlichsten Stellen und auf unterschiedlichsten Ebenen im Unternehmen aus. So
müssen Anwendungen einerseits flexibel und andererseits Kosteneffizient sein (keine
monolithischen Anwendungen, Anpassungsfähigkeit bei Standard-Software, etc.). Eine
Mehrherstellerpolitik auf Hardware oder Software-Ebene, aus unterschiedlichen Motivationen
(z. B. Funktionalitätsanforderungen, Preis), sollte keine Integrationsprobleme mit sich
bringen.
Flexibilität im Software-Design, Flexibilität im Geschäftsprozess–Design, Wiederverwendbarkeit von Software–Komponenten, leichte Integration und Interoperabilität zwischen
Schnittstellen sind Pflichtanforderungen an die IT geworden.
- 24 -
EDI
Service-orientierte Architekturen (SOA) als Paradigma und Webservices (WS) als
Technologie sollen hier Abhilfe schaffen. SOA und Webservices sollen die geeignete
Umgebung für eine verteilte Verarbeitung schaffen, wobei sich die modularen und autonom
agierenden Services sozusagen selbst beschreiben.
Webservices gelten als Zukunftstechnologie. Sie können im Rahmen der Anforderungen an
eine XML–basierte Verarbeitung praktisch ohne Zusatzinvestitionen in Hardware und
Software entwickelt werden, denn die Ablaufumgebung ist meist schon in Form eines
modernen Application Servers für den Internet-Auftritt im Hause. Richtig eingesetzt, können
sie in geeigneten Einstiegsprojekten in kurzer Zeit einen positiven Return on Investment
erzeugen. Geeignete Projekte sind besonders die, in denen eine „Request–Response“
Applikation–zu–Applikation Kommunikation Vorteile mit sich bringt, die vorher durch
ungeeignete Mechanismen oder gar unautomatisiert nicht realisiert werden konnten.
Politisch einmalig in der Informationstechnologie ist die Tatsache, dass konkurrierende
Softwaretechnologielieferanten, wie Microsoft, SUN und IBM, sowie Lösungsanbieter, wie
SAP, sich bei SOA und WS besonders eng abstimmen.
Es ist also durchaus sinnvoll, sich mit dieser Technologie auseinander zu setzen. Der VDEW
möchte allerdings Webservices jetzt noch nicht als synchrone EDI-Austauschverfahren
empfehlen, um bestehende Prozesse möglichst wenig zu beeinflussen.
Web-Service-Security
Webservices stellen einen Paradigmenwechsel dar.
Web-Service-Security ist eine große Herausforderung an IT-Sicherheit. Sie ist vergleichbar
mit den neuen Anforderungen an Sicherheit für mobile Anwendungskomponenten.
Die klassische Authentisierung und ihre Weiterentwicklungen bis hin zum Zertifikatsbasierenden Single Sign On reicht dann nicht mehr aus, wenn dynamische Elemente dazu
kommen. Dies ist bei höheren Anforderungen an die Mobilität schon seit einigen Jahren zu
beobachten und unter dem Schlagwort Mobile Security bekannt. Im weitesten Sinne ist damit
der externe Zugriff auf Unternehmensressourcen gemeint und seine Absicherung durch
End–to–End Security Mechanismen. Sowohl die Authentisierung als auch der Remote
Access werden vor allem in Verbindung mit Rollen und Rechten natürlicher Personen, also
Mitarbeiter, betrachtet. Alle daraus resultierenden Anforderungen an IT-Komponenten sind
nachgelagert.
Web-Services stellen Verbindungen über das Intranet oder Internet her, in denen eine
Anwendung–zu–Anwendung Kommunikation stattfindet. Sie sind durch ihre Konzeption nicht
fest verbunden, praktisch sprachneutral und innerhalb der großen Systemplattformen bemerkenswert interoperabel. Allerdings haben bisher unzureichende Sicherheitsvoraussetzungen
den großen Durchbruch dieser Technologie behindert.
Prinzipiell geht es darum, das zentrale Sprachmittel SOAP mittels Security Mechanismen
abzusichern, die nicht bzw. nicht in erster Linie personenbezogen sind. Dabei müssen
Vertrauensinfrastrukturen, wie sie nach und nach organisationsübergreifend entstehen, auf
Service orientierte Architekturen übertragen und automatisiert werden. Die automatisierte
- 25 -
EDI
Interpretation von Policies im Rahmen von Trustmodellen ist wahrscheinlich unumgänglich
und stellt vor allem für föderative Unternehmensprozesse eine große Aufgabe dar.
• Authentisierungstechnologien
• Liberty Alliance
• Passportsysteme
MS .NET Passport
• XML-Security
Sign
on
WS
Security
• Federation
• Secure Messaging
• Trust
• Sigle Sign On
Mobile
Security
Nach G. Wiehler
• Mobile Netze
• End-to-End Security
• SmartCards / SIM-Cards
Abb. 6: Mobile Security und Web Services bringen
qualitativ neue Sicherheitsanforderungen
Wesentlichstes Sprachmittel für WS–Security ist die Security Assertion Markup Language
(SAML). SAML nutzt Remote Procedure Calls (RPC) mittels SOAP, um verteilte Authentifikationsinformationen zusammen zu führen (Vereinigung=Federation). Die beteiligten,
organisationsübergreifenden Domänen können lose gekoppelt sein, können heterogene
Systemplattformen haben und können unterschiedliche Authentisierungsmethoden, wie
RADIUS, SSL/TLS, Secure Shell, Kerberos oder PKI-Mechanismen, benutzen. SAML hat
aufgrund dieser Flexibilität in kürzester Zeit eine beeindruckende Verbreitung gefunden.
- 26 -
EDI
Die folgende Grafik charakterisiert das Zusammenspiel von Web-Services mit den
korrespondierenden Security Modellen.
SOAP-Request
Requester
(WS-Client)
Intermediär
Aufruf eines Web Services
Web
Service
SOAP-Response
Security Context
Security Modell bei Web Services
Policy
Policy
Requester
Claims
Claims
Security
Token
Security
Token
Service
Security
Token
Claims
Claims
Policy
Web
Service
Nach G. Wiehler
Security
Token
Claims
Claims
Abb. 7: Aufruf und Security-Mechanismen bei Web Services
Web-Services bringen damit zwangsläufig Änderungen an den Prozessen. Sie müssen
strategisch gewollt sein und dürfen nicht nur den Electronic Data Interchange betreffen, um
wirtschaftlich sinnvoll zu sein.
Web-Service-Security schafft darüber hinaus Anforderungen an eine „Dynamisierung“ der ITSecurity-Anforderungen, die viele Häuser zurzeit überfordern würde und eher zu
Sicherheitseinbußen in der Kommunikation zwischen Marktteilnehmern führen würde.
In Abwägung dieser Gründe verstehen sich die nachfolgenden Empfehlungen.
- 27 -
EDI
8.2 Technische Empfehlungen zum Einsatz des EDIINT AS2Verfahrens
Die folgende Tabelle fasst die AS2-Parameter und Empfehlungen zur Nutzung zusammen.
Die Tabelle ist analog zur EDIINT AS2 Umsetzungshilfe von GS1 Germany aufgebaut. Die
Empfehlungen orientieren sich an den VEDIS-Empfehlungen.
AS2-Parameter
Bereich
Thema
Empfehlung
Sicherheit
Transportschicht
Die Nutzung eines einzelnen Zertifikats für
Signatur und Verschlüsselung ist nicht
zulässig
Zertifikate
Klasse 2 Typ beglaubigt gemäß der VEDISCP
Minimale Gültigkeitsdauer: 2 Jahre
Maximale Gültigkeitsdauer: 5 Jahre
Digitale Signatur
SHA1
Verschlüsselung
3DES
Länge des Schlüssels
>= 128 Bit
Länge des
öffentlichen/privaten
Schlüssels (X.509)
Gemäß den Empfehlungen der
Bundesnetzagentur
>= 1024 Bit Länge des öffentlichen/
privaten Schlüssels (X.509).
Transport-Protokoll
http
http/s kann benutzt werden, um AS2-To and
AS2-From ab zu sichern.
Verbindung zum
Internet
Permanente Internet Verbindung; Vollständig
qualifizierter Name der Domäne (URL) muss
angegeben werden. Für die Konfiguration der
Firewall muss eine veröffentlichte IP-Adresse
vorhanden sein.
- 28 -
EDI
AS2Kopfinformation
AS2-From
ILN bzw. VDEW-Codenummer5 des AS2Servers des Geschäftspartners muss
verwendet werden. Ausnahme:
Sofern ein Hub benutzt wird, kann die
Nummer des Geschäftspartners verwendet
werden, falls das Feld AS2-To für das Routing
verwendet wird.
AS2Kopfinformation
AS2-To
GLN bzw. VDEW-Codenummer des AS2Servers des Geschäftspartners muss
verwendet werden. Ausnahme:
Sofern ein Hub benutzt wird, kann die
Nummer des Geschäftspartners verwendet
werden, falls das Feld AS2-To für das Routing
verwendet wird.
MDN
muss
MDN signiert
muss
MDN verschlüsselt
Nicht erlaubt
Synchron / Asynchron
Asynchron: Bei Nutzung eines Reverse Proxy
und falls das Risiko eines Time-out besteht.
Synchron: In allen anderen Fällen erforderlich.
Zeitstempel
Formate
optional
MIME
MIME Typ zusammenhängend mit Inhalt
S/MIME
muss
Komprimierung
(Ja/Nein)
Akzeptiert und optional (bilateral zu
vereinbaren)
AS2-Version
Eingangs- und
Ausgangsport
Die Portvorgaben werden grundsätzlich von
jedem Unternehmen selbst festgelegt. Sofern
möglich sollte 4080 für http und 1443 für https
verwendet werden, um AS2-Transaktionen
von anderen zu unterscheiden, die das gleiche
Protokoll nutzen.
5
In der deutschen Energiewirtschaft wird die VDEW-Codenummer als Alternative zur ILN verwendet,
wenn der Vertragspartner keine ILN besitzt.
- 29 -
EDI
8.3 Quellen
Common ISIS-MTT Spezification for PKI Applications from T7 & TeleTrusT, V1.1, März 2004
EDIINT AS2 Umsetzungshilfe, GS1 Germany, Köln 2005
AS2 Beschreibung und Parameter, EDI Anwenderkreis Handel, vom 10.10.2004
8.4 VDEW-Veröffentlichungen

Einsatz von Verschlüsselung und Elektronischer Signatur im elektronischen
Geschäftsverkehr der deutschen Elektrizitätswirtschaft
Studie
VDEW-Materialie M-14/2002

Sicherheitsrahmenbedingungen für den elektronischen Geschäftsverkehr im deutschen
Strommarkt
Gemeinsame Erklärung der Verbände

Sicherheitspolitik (PKI-Policy), Version 1.0

Umgang mit Schlüsselmaterial, Version 1.0

Technische PKI-Interoperabilität, Version 1.0

Umsetzungsempfehlungen, Version 1.0

Zertifizierungsrichtlinie (Certification Practice Statement), Version 1.0

Zehn Schritte zur VEDIS-Sicherheit

Unternehmensübergreifende PKI-Topologien, PKI-Dienste und
Einsatzrahmenbedingungen

Weitere VEDIS-Einsatzpotentiale in papierlosen Geschäftsprozessen
Energie Spezial 2006

PKI-Zertifikatsrichtlinie (Certificate Policy) des VDEW
Energie-Info 01/2007

Studie: Sicherer elektronischer Geschäftverkehr
Energie-Info 02/2007
- 30 -
EDI
8.5 Glossar
Begriff
Beschreibung
Quelle
AS1
EDIINT AS1 (EDI over Internet applicability tools.ietf.org/wg/ediint/draft-ietf-ediintas1/draft-ietf-ediint-as1-17.txt
statement 1)
Internet-basiertes Datenaustauschverfahren auf Basis des SMTP-Protokolls
AS2
EDIINT AS2 (EDI over Internet applicability www.ietf.org/rfc/rfc4130.txt
statement 2
Internet-basiertes Datenaustauschverfahren auf Basis des http-Protokolls,
Standard seit 12.07.2005
DCCP
Datagram Congestion Control Protocol
Kein RFC, IETF-Vorschlag
Protokoll in der TCP/IP-Transportschicht
zur Dateiübertragung
DMZ
Demilitarisierte Zone
Die DMZ wird durch eine Firewall (außen)
und eine Firewall (innen) gegen das Internet abgeschirmt. Durch diese Trennung
besteht die Möglichkeit Zugriff auf öffentliche Dienste (z. B. E-Mail, WWW) anzubieten und gleichzeitig das interne Netz
LAN vor ungerechtfertigten Zugriffen zu
schützen.
DNS
Domain Name System
RFC 1034 und 1035
Verteilte Datenbasis zur Verwaltung des
Internets
ED2K
eDonkey2000
www.edonkey2000.com
Filesharing-Netzwerk im Internet, nutzbar
mit fast jedem Betriebssystem und
entsprechender Software
- 31 -
EDI
FTP
File Transfer Protocol
RFC 959
Netzwerkprotokoll zur Dateiübertragung
über TCP/IP-Netzwerke
ILN
International Location Number
(bei deutschen Vertragspartnern wird
alternativ die VDEW-Codenummer
verwendet)
GS1
http
Hyper Text Transfer Protocol
RFC 2616
Das Protokoll im World Wide Web
HTTPS, https
Hypertext Transfer Protocol Secure
RFC 2818
Mittels SSL/TLS gesichertes http über TCP
IMAP
Internet Message Access Protocol
RFC 3501
Zugriff und Verwaltung von empfangenen
E-Mails
IPsec
IP Security
Ergänzungen zur Behebung von
Sicherheitsschwächen von Æ IP in der
Version 4 und Entwicklungsbasis für IPv6
RFC 2401 (Hauptdokument)
Sicherheitsarchitektur für das
Internetprotokoll
RFC 2402
Authentication Header
RFC 2406
Encapsulating Security Payload
RFC 2407
IPsec Domain of Interpretation (IPsec
DoI)
RFC 2408
Internet Security Association and Key
Management Protocol (ISAKMP)
RFC 2409
Internet Key Exchange (IKE)
IRC
Internet Relay Chat
RFC 1459
Chatten im Internet, aber nicht im WWW
LDAP
Lightweight Directory Access Protocol
Abfrage und die Modifikation von
Informationen eines Verzeichnisdienstes
- 32 -
RFC 2251
EDI
MBS/IP
Multi-purpose Business Security over IP
http://www.mbsip.com
SSL verschlüsselte Übertragung im
Banking, wird meist bei EDIFACTKommunikation im österreichischen
Bankenumfeld verwendet
MIME
Multipurpose Internet Mail Extensions
RFC 2045 erweitert RFC 822
Informationen über den Typ der
übermittelten Daten (Content-Type) und
Festlegung der sicheren Kodierung gemäß
Übertragungsweg (Content-TransferEncoding)
NNTP
Network News Transfer Protocol
RFC977, RFC2980, RFC 1036
Vor allem in Newsgroups verwendetes
Kommando-Protokoll
NTP
Network Time Protocol
www.ietf.org/rfc/rfc958.txt
Zeitsynchronisation über UDP oder auch
TCP
POP3
Post Office Protocol Version 3
RFC 1939
Kommando-orientiertes ASCII
Übertragungsprotokoll, über das ein Client
E-Mails von einem E-Mail-Server abholen
kann.
RTP
Real-Time Transport Protocol
RFC 1889
kontinuierliche Übertragung von
audiovisuellen Daten über IP-basierte
Netze
S/MIME
Secure MIME
RFC 2045
Verschlüsseln und digitales Signieren von
Nachrichten mittels asymmetrischer
Kryptographie
SCTP
Stream Control Transmission Protocol
RFC 2960
neues IETF-Transportprotokoll vor allem
als Antwort auf Denial of Service Attacken
Siehe auch RFC 3286
- 33 -
EDI
Secure FTP
Secure File Transfer Protocol
Netzwerkprotokoll zur Dateiübertragung
über TCP/IP-Netzwerke, das eine FileTransfer-Protocol-Verbindung (FTP)
teilweise über Secure Shell (SSH) tunnelt.
SILC
Secure Internet Live Conferencing
Absicherung von IRC über asymmetrische
Kryptographie
SIP
Session Initiation Protocol
http://silcnet.org/support/documentation/s
pecs/
RFC 3261
zum Aufbau einer Kommunikationssitzung
zwischen zwei und mehr Teilnehmern
SMTP
Simple Mail Transfer Protocol
RFC 821
Protokoll der TCP/IP-Protokollfamilie zum
Versand von E-Mails
SNMP
Simple Network Management Protocol
RFC 1065, 1066, 1067
Überwachung von Netzkomponenten
SSH
Secure Shell
www.openssh.com/
Entferntes, authentisiertes und
verschlüsseltes Einloggen und Programme
über Port 22 ausführen
SSL
Secure Sockets Layer bzw. Transport
Layer Security (TLS)
Ursprünglich RFC 2246
RFC 2712, 2817, 2818, 3268
Verschlüsselungsprotokoll für Datenübertragungen im Internet. TLS ist die standardisierte Weiterentwicklung von SSL 3.0.
TCP
Transmission Control Protocol
RFC 793
zuverlässiges, verbindungsorientiertes
Transportprotokoll; Teil der TCP/IPProtokollfamilie
UDP
User Datagram Protocol
RFC 768
minimales, unzuverlässiges,
verbindungsloses Netzprotokoll
- 34 -
EDI
URL
Uniform Resource Locator
RFC 1738, siehe auch RFC 1808
identifizieren eine Ressource über ihren
primären Zugriffsmechanismus (häufig http
oder ftp) und den Ort (engl. location) der
Ressource
UUCP
Unix to Unix Copy
www.ietf.org/rfc/rfc976.txt
Basis für das erste Internet Mail Usenet
VAN
Value Added Network
VPN
Virtual Private Network
Computernetz zum Transport privater
Daten über ein öffentliches Netz (zum
Beispiel das Internet), Absicherung über Æ
IPsec oder Æ SSL/TLS
X.400
Nicht auf das Internet-bezogene E-MailVerfahren mit aufwändigen Protokoll- und
Quittungsmechanismen, weitgehend
verdrängt durch Æ SMTP
ISO 10021
X.509
striktes hierarchisches System von
vertrauenswürdigen Zertifizierungsstellen
(engl.: certificate authority, CA), die
Zertifikate erteilen können.
RFC 3280
- 35 -