Sichere Datenübertragung mit IDL.KONSIS.FORECAST und
Werbung
Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK 06.12.2016 16:49 Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK Inhaltsverzeichnis 1 2 3 4 5 6 7 Einführung ............................................................................................................................... 3 HTTPS .................................................................................................................................... 4 Client und Server im Netzwerk ...............................................................................................10 Authentifizierung.....................................................................................................................14 Proxy-Server ..........................................................................................................................16 Literaturhinweise ....................................................................................................................17 Kontakt ...................................................................................................................................18 2 © IDL GmbH Mitte Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK 1 Einführung Dieses Handbuch richtet sich sowohl an die Anwender als auch an die IT-Administratoren von IDL.KONSIS.FORECAST und IDL.XLSLINK. Es liefert wichtige Hintergrundinformationen zur sicheren Datenübertragung mit HTTPS, zur ClientServer-Architektur und zur Authentifizierung von IDL.KONSIS.FORECAST und IDL.XLSLINK. Das Handbuch ist somit als Ergänzung zu den beiden Handbüchern „IDL.KONSIS.FORECAST – Start der Anwendung“ und „IDL.XLSLINK – Schnelleinstieg“ zu empfehlen. Hinweise für Anwender Der Inhalt des vorliegenden Handbuches ist technischer Natur. Fachbegriffe und Zusammenhänge werden auf eine anschauliche Weise erklärt und durch Abbildungen ergänzt. Spezialwissen aus dem IT-Bereich ist nicht erforderlich. Grundkenntnisse aus dem Computer-Bereich sind aber vorteilhaft. Bitte fragen Sie bei aufkommenden Verständnisschwierigkeiten und auftretenden Problemen nach Unterstützung. Hilfestellung bekommen Sie durch den Technischen Support der IDL GmbH Mitte. Möglichkeiten zur Kontaktaufnahme finden Sie im abschließenden Kapitel. © IDL GmbH Mitte 3 Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK 2 HTTPS Mit dem Release IDL.KONSIS.FORECAST 2014.0 wurde erstmalig der neue Applikationsserver ausgeliefert, der mit den Anwendungen über HTTPS kommuniziert. Um Daten im Netzwerk sicher und verschlüsselt zu übertragen, benutzt man HTTPS. HTTPS (Hypertext Transfer Protocol Secure) wird hauptsächlich verwendet, um Webseiten in einem Internet-Browser zu laden. Es ist jedoch nicht darauf beschränkt und ist auch als allgemeines Datenübertragungsprotokoll verbreitet. HTTPS wird zur Herstellung von Vertraulichkeit und Integrität in der Kommunikation zwischen Server und Client verwendet. Datenintegrität liegt immer nur dann vor, wenn die Nachrichten unverändert zugestellt werden. Dabei ist es nicht sinnvoll, die Integrität der Daten und die Authentizität des Datenursprungs unabhängig voneinander zu betrachten, da eine empfangene Nachricht mit einem modifiziertem Inhalt, aber bekanntem Absender ebenso wertlos sein dürfte wie eine empfangene Nachricht mit einem nicht modifiziertem Inhalt, dafür aber mit einem vorgetäuschten Absender. Die Sicherheit wird bei HTTPS durch eine Authentifizierung des Servers mit einem SSL-Zertifikat und außerdem durch eine Transportverschlüsselung bei der Datenübertragung erreicht. Syntaktisch ist HTTPS identisch mit dem Schema für HTTP, die zusätzliche Verschlüsselung der Daten geschieht mittels des Verschlüsselungsprotokolls Transport Layer Security (TLS). Das Protokoll TLS, auch bekannt unter der Vorgängerbezeichnung Secure Sockets Layer (SSL), dient der Verschlüsselung und damit der sicheren Datenübertragung zwischen Client und Server in Netzwerken bzw. im Internet. Der Client baut eine Verbindung zum Server auf. Der Server authentisiert sich gegenüber dem Client mit einem Zertifikat. Dieses enthält einen öffentlichen Schlüssel und eine digitale Signatur, weiterhin Angaben zum Inhaber, zum Aussteller sowie Angaben über die Gültigkeitsdauer des Zertifikates. Der Client überprüft mit diesen gemachten Angaben die Vertrauenswürdigkeit. Ist die Überprüfung der Vertrauenswürdigkeit negativ, zeigt der Client eine Warnung an, dass die Verbindung nicht vertrauenswürdig ist. Bevor die ersten Nutzdaten ausgetauscht werden, übermittelt das SSL-Handshake-Protokoll die persönlichen Identifikationsdaten beider Teilnehmer und handelt das Verschlüsselungsverfahren aus, das während der Verbindung verwendet werden soll. Client und Server einigen sich auf einen Verschlüsselungscode, den sogenannten Sitzungsschlüssel. Danach fließen die verschlüsselten Informationspakete, die der Empfänger jeweils entschlüsselt und zusammensetzt. Symmetrische Kryptosysteme Die symmetrischen Verfahren zeichnen sich dadurch aus, dass sowohl für die Verschlüsselung in Geheimtext als auch für die Entschlüsselung in Klartext der exakt selbe Schlüssel verwendet wird. Die größte Problematik der symmetrischen Verfahren besteht beim unsicheren Schlüsselaustausch. Eine verschlüsselte Nachricht kann zwar gefahrlos verschickt werden, nicht aber der Schlüssel selbst. Um vor Angriffen geschützt zu sein, muss für den Transport des Schlüssels also unbedingt ein sicherer Kanal gewährleistet sein. Asymmetrische Kryptosysteme Das asymmetrisches Kryptosystem oder Public-Key-Kryptosystem ist ein Verfahren, bei dem die kommunizierenden Parteien zwei unterschiedliche Schlüssel benutzen. Der private Schlüssel, auch geheimer Schlüssel genannt, ist im Keystore-Container auf dem Server installiert und wird unter 4 © IDL GmbH Mitte Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK keinen Umständen an die Clients weitergegeben. Der öffentliche Schlüssel hingegen ist in das SSLZertifikat integriert und wird auch an die Clients weitergegeben. Der öffentliche Schlüssel ermöglicht es jedem Benutzer, Nutzdaten für den Besitzer des privaten Schlüssels zu verschlüsseln, aber auch dessen digitale Signaturen zu überprüfen oder ihn zu authentifizieren. Der private Schlüssel ermöglicht es seinem Besitzer, mit dem öffentlichen Schlüssel verschlüsselte Daten wieder zu entschlüsseln, digitale Signaturen zu erzeugen oder sich zu authentisieren. Der private Schlüssel wird vom Besitzer geheim gehalten. Privater und öffentlicher Schlüssel bilden das gemeinsame Schlüsselpaar für die asymmetrische Verschlüsselung. Beide Schlüssel sind durch eine komplexe mathematische Formel untrennbar miteinander verbunden. Kennt ein Angreifer den öffentlichen Schlüssel, so kann er daraus weder auf die verschlüsselte Nachricht noch auf den privaten Schlüssel schließen. Der öffentliche Schlüssel kann ohne Bedenken über unsichere Kanäle verschickt werden. Hybride Kryptosysteme (Kombination aus symmetrischer und asymmetrischer Kryptographie) Da asymmetrische Verfahren extrem rechenaufwändig sind, benutzt man fast immer eine Kombination aus symmetrischer und asymmetrischer Kryptographie. Diese Kombination nennt man Hybrid-Kryptographie bzw. hybride Verschlüsselung. Dabei wird zu Beginn einer jeden Sitzung zwischen den beiden Partnern das VerschlüsselungsVerfahren ausgehandelt. Danach wird der sogenannte Sitzungsschlüssel (englisch: Session Key) erstellt und asymetrisch verschlüsselt zum Emfpänger übertragen. Der Sitzungsschlüssel ist ein zufällig generierter Schlüssel, der nur ein einziges Mal für eine einzelne Sitzung (Session) zwischen Client und Server verwendet wird. Dieser Sitzungsschlüssel kann von beiden Seiten für eine ressourcenschonende symmetrische Verschlüsselung und Entschlüsselung genutzt wird. Mit dem Sitzungsschlüssel ist es durchaus möglich, größere Mengen an Nutzdaten performant zu verschlüsseln und zu entschlüsseln. Als häufig genutztes Beispiel für hybride Kryptographie wäre das Verschlüsselungsprotokoll TLS bzw. SSL zu nennen. Bei TLS und SSL ist es üblich, den Sitzungsschlüssel nach verhältnismäßig kurzer Zeit wieder neu auszuhandeln. Dadurch würde ein einmalig aufgedeckter Session Key nicht zur Entschlüsselung jeglichen Datenverkehrs führen. Zum besseren Schutz der Integrität und Authentizität wird die verschlüsselte Nachricht außerdem durch einen Message Authentication Code (MAC) abgesichert. Der MAC dient dazu, Gewissheit über den Ursprung von Daten oder Nachrichten zu erhalten und ihre Integrität zu überprüfen. MAC-Algorithmen erfordern genau zwei Eingabeparameter, erstens die zu schützenden Daten und zweitens einen geheimen Sitzungsschlüssel, und berechnen aus beidem eine Prüfsumme, den Message Authentication Code. Der Sender berechnet aus dem Sitzungsschlüssel und der Nachricht einen MAC und sendet dann die Nachricht sowie den MAC an den Empfänger. Der Empfänger berechnet ebenfalls den MAC zu der empfangenen Nachricht mit dem Sitzungsschlüssel und vergleicht den berechneten MAC mit dem empfangenen MAC. Die Übereinstimmung beider Werte interpretiert der Empfänger als erfolgreichen Integritätstest. Die Nachricht wurde von einer Partei abgeschickt, die den geheimen Sitzungsschlüssel kennt, und die Nachricht wurde während der Übertragung nicht verändert. © IDL GmbH Mitte 5 Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK Digitale Signaturen Zum besseren Verständnis von digitalen Signaturen ist es hilfreich, den Begriff der Hashfunktion zu erwähnen. Eine Hashfunktion erzeugt aus einer beliebig großen Datenmenge, zum Beispiel aus einem Textdokument, einen sogenannten Hash-Code definierter Länge. Dieser Hash-Code ist der digitale Fingerabdruck der Nachricht. Um nun eine Nachricht zu signieren, erzeugt der Server über eine Hashfunktion einen digitalen Fingerabdruck der Nachricht und verschlüsselt dann diesen Fingerabdruck mit seinem privaten Schlüssel. Dieser verschlüsselte Fingerabdruck wird als digitale Signatur bezeichnet. Der Server sendet die digitale Signatur zusammen mit der Nachricht an den Client. Dieser berechnet seinerseits den Fingerabdruck der gesendeten Nachricht mit dem gleichen Algorithmus und entschlüsselt die mitgeschickte digitale Signatur mit dem öffentlichen Schlüssel des Servers. Stimmt der selbst berechnete Fingerabdruck mit dem entschlüsselten Wert überein, kann der Client sicher sein, dass die Nachricht auf dem Versandweg nicht verändert worden ist. Durch Einsatz digitaler Signaturen zusammen mit dem asymmetrischen Verschlüsselungsverfahren kann sichergestellt werden, dass Nachrichten auf dem Übertragungsweg nicht verfälscht werden können. SSL-Zertifikate Das Zertifikat ist mit einem elektronischen Ausweis des Zertifikatsinhabers vergleichbar. Durch die Verwendung digitaler Zertifikate soll Vertrauen zwischen dem Prüfer und dem Aussteller eines Zertifikates geschaffen werden. Ein Zertifikat besteht im einfachsten Fall aus den Komponenten: dem Namen des Inhabers, dem Namen des Ausstellers, der Signatur, dem öffentlichen Schlüssel, sowie der Angabe, wie lange das Zertifikat gültig ist (gültig ab, gültig bis). Zertifikate bestätigen also die Authentizität (d.h. die Zugehörigkeit eines Schlüssels zu einer Person) und die Integrität (d.h. die Unverfälschtheit) dieses öffentlichen Schlüssels. Das Zertifikat beinhalten den öffentlichen Schlüssel. Privater und öffentlicher Schlüssel bilden das gemeinsame Schlüsselpaar für die asymmetrische Verschlüsselung. Technisch gesehen sind SSL-Zertifikate in einer Keystore-Datei auf einem Server (Webserver, Applikationsserver) gespeichert. Diese Datei ist ein passwortgeschützter Container, bestehend aus einem oder mehreren Zertifikaten und den zugehörigen privaten Schlüsseln. Die privaten Schlüssel innerhalb des Containers sind ebenfalls passwortgeschützt. Zertifizierungsstellen (CA) Wenn Sie ein SSL-Zertifikat von einer Zertifizierungsstelle (CA) anfordern, verifiziert diese Ihre Unternehmensdaten und gibt auf der Basis dieser Daten ein nur für Sie bestimmtes Zertifikat aus. Die Aufgabe einer Zertifizierungsstelle ist es, Zertifikate herauszugeben bzw. erstellte Zertifikate zu überprüfen. Jede Zertifizierungsstelle (certificate authority, CA) trägt dabei die Verantwortung für die Bereitstellung, Zuweisung und Integritätssicherung der von ihr ausgegebenen Zertifikate. Eine Zertifizierungsstelle kann ein Unternehmen, eine Institution innerhalb eines Unternehmens, eine öffentliche Organisationen oder eine Regierungsstelle sein. Public Key Infrastructure (PKI) und Wurzelzertifikate (Root-Zertifikate) Bei einer Public Key Infrastructure (PKI), also einer Hierarchie von mehreren Zertifikaten, wird ein Wurzelzertifikat (Root-Zertifikat) mit dem zugehörigen Schlüsselpaar bei einer für alle Teilnehmer vertrauenswürdigen CA erstellt. Dieses Wurzelzertifikat kann als Vertrauensanker benutzt werden. 6 © IDL GmbH Mitte Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK Weitere Zertifikate in dieser PKI werden mit dem zum Wurzelzertifikat zugehörigen privaten Schlüssel signiert. Eine solche Signatur für ein Zertifikat wird nur dann ausgegeben, wenn alle von der CA festgelegten Anforderungen erfüllt wurden. Diese beinhalten unter anderem einen Nachweis über die Identität desjenigen, der das Zertifikat nutzen möchte. Nicht jedes Zertifikat einer PKI muss mit dem privaten Schlüssel des Wurzelzertifikats signiert werden. Es können auch private Schlüssel verwendet werden, deren zugehörige Zertifikate mit dem privaten Schlüssel des Wurzelzertifikats signiert wurden. Theoretisch kann eine solche Kette beliebig lang werden, sie muss nur immer beim Wurzelzertifikat beginnen. Für die Prüfung der Echtheit und Vertrauenswürdigkeit eines Zertifikats aus einer PKI müssen alle Zertifikate, die zwischen dem zu prüfenden Zertifikat und der Wurzelzertifikat liegen, verifiziert werden. Wurde ein Zertifikat von einer vertrauenswürdigen CA erfolgreich überprüft, enthält dieses einen Verweis auf das Zertifikat der CA, die das Zertifikat überprüft hat. Selbst erstellte SSL-Zertifikate Eine Alternative zu den Zertifikaten einer CA sind selbst erstellte SSL-Zertifikate, die allerdings nicht von einer Zertifizierungsstelle unterschrieben werden, sondern vom Ersteller des Zertifikates selbst. Browser und auch Java reagieren auf selbst ausgestellte SSL-Zertifikate mit einer SicherheitsWarnmeldung, da diese über keine Signatur einer bekannten CA verfügen. Dem Zertifikat wird nicht vertraut, weil es vom Aussteller selbst signiert wurde. © IDL GmbH Mitte 7 Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK Browser-Warnmeldungen bei SSL-Zertifikaten Jeder Internet-Browser wird mit einer Liste von Root-Zertifikaten ausgeliefert und über Updates aktualisiert. Die Liste der Zertifikate ist in den Browser Einstellungen einsehbar und editierbar. Ist das Root-Zertifikat der PKI nicht dabei, kommt beim Öffnen der Internet-Seite eine Warnung. Ganz ignorieren sollten Sie diese Warnmeldungen nicht, denn sie sollen darauf hinweisen, dass das Zertifikat nicht bekannt ist, also die Authentizität (die Echtheit) des Zertifikates und damit die Angaben über den Inhaber des privaten Schlüssels womöglich nicht stimmen und im schlimmsten Fall jemand unbefugtes die verschlüsselte Verbindung abhören, umleiten bzw. manipulieren kann. Abbildung 1: Internet Explorer -> Das Zertifikat wurde nicht von einer vertrauenswürden Zertifizierungsstelle ausgestellt. 8 © IDL GmbH Mitte Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK Abbildung 2: Firefox -> Dem Zertifikat wird nicht vertraut, weil es selbst signiert wurde Ein Zertifikat kann aus den folgenden Gründen ungültig und somit nicht vertrauenswürdig sein: Das Zertifikat oder seine Signatur wurde widerrufen. Das Zertifikat wurde illegal ausgestellt. Die Richtlinien der Nutzung des Zertifikats wurden verletzt. Das Zertifikat ist abgelaufen. Das Zertifikat ist noch nicht gültig. Die Struktur des Zertifikates ist beschädigt. Bei der Überprüfung der Signatur ist ein Fehler aufgetreten. Die Richtlinien der Nutzung des Zertifikats wurden verletzt. Die im Zertifikat angegebene Domain entspricht nicht der Website bzw. dem Server (Host), zu der die Verbindung hergestellt wird. Die Zertifikatskette ist unterbrochen: Die Zertifikatskette besteht aus einem einzigen selbstsignierten Zertifikat. Die Zertifikatskette endet nicht mit einem vertrauenswürdigen Stammzertifikat. Die Kette enthält Zertifikate, die nicht zum Signieren anderer Zertifikate bestimmt sind. Das Stamm- oder Zwischenzertifikat ist abgelaufen oder noch nicht gültig. Die Zertifikatskette kann nicht gebildet werden. © IDL GmbH Mitte 9 Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK 3 Client und Server im Netzwerk Client-Server-Architektur Die Client-Server-Architektur beschreibt die Verteilung von Aufgaben innerhalb eines Netzwerkes. Die verschiedenen Aufgaben werden von Clients und von Servern erledigt. Der Client kann Dienste von einem Server anfordern. Der Server stellt Dienste zur Verfügung. Die beiden Desktop-Anwendungen IDL.KONSIS.FORECAST und IDL.XLSLINK sind die ClientProgramme (Front-Ends) im Netzwerk. Diese kommunizieren mit dem Applikationsserver. Die Client-Programme und der Applikationsserver benutzen für die Kommunikation im Netzwerk das sichere Hypertext-Übertragungsprotokoll (HTTPS). Abbildung 3: Client-Server-Architektur - oben: Applikationsserver im LAN; unten: Applikationsserver in der Cloud In der obigen Abbildung ist eine dreischichtige Client-Server-Architektur dargestellt. Die drei Schichten haben folgende Aufgaben: In der ersten Schicht, der sogenannten Präsentationsschicht, werden die Client-Programme ausgeführt. Dort werden alle Benutzereingaben vorgenommen. Aber auch die Anzeige der zurückgesendeten Daten erfolgt in dieser Schicht. In der zweiten Schicht, der Anwendungsschicht, findet die Verarbeitung der Anfragen statt. Diese Aufgabe übernimmt der Applikationsserver. Als dritte Schicht gibt es die sogenannte Datenhaltungsschicht. Dort befindet sich die Datenbank und der Datenbankserver. Jede dieser drei Schichten kann nur mit der benachbarten Schicht kommunizieren. Das bedeutet, dass die beiden Client-Anwendungen IDL.KONSIS.FORECAST und IDL.XLSLINK in dieser dreischichtigen Client-Server-Architektur mit dem Applikationsserver, aber nicht direkt mit der IDL-Datenbank kommunizieren können. 10 © IDL GmbH Mitte Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK Abbildung 4: Client-Server-Architektur mit regional verteilten Netzwerken Lokale und entfernte Netzwerke Der Applikationsserver kann im lokalen Netzwerk (LAN), in einem entfernten Netzwerk, im Internet oder auch in der Cloud stehen. Clients und Applikationsserver können in verschiedenen Netzwerken sein. Gibt es regional verteilte Netzwerke, spricht man von einem „Wide Area Network (WAN)“. Eine optimale Performance der Anwendungen setzt eine schnelle und stabile Netzwerkverbindung mit sehr kleinen Ping–Antwortzeiten kleiner als eine Millisekunde zwischen dem Applikationsserver und dem Datenbankserver voraus. Applikationsserver und Datenbankserver sind in der Regel im selben Netzwerk. Applikationsserver Der Applikationsserver stellt Dienste für die Clients zur Verfügung und übernimmt komplett die Kommunikation mit der Datenbank, sodass die beiden Anwendungen IDL.KONSIS.FORECAST und IDL.XLSLINK ihre Anfragen an den Applikationsserver stellen, der die gewünschten Daten von der IDL-Datenbank holt und diese gebündelt an die Anwendungen zurückliefert. Die Anbindung des Applikationsservers zur IDL-Datenbank wird über JDBC1- und über Ole DB2Zugriffe realisiert. Der Applikationsserver übermittelt die Ergebnisse an IDL.KONSIS.FORECAST und IDL.XLSLINK. Ein Applikationsserver kann komplexe, rechenintensive Operationen durchführen und entlastet somit die Clients. Auch dient der Applikationsserver der Zwischenspeicherung von Daten, um die Anzahl der Zugriffe auf die Datenbank (DB) zu reduzieren. Anmerkung: Da die Clients mit dem Applikationsserver kommunizieren und der Applikationsserver wiederum mit der IDL-Datenbank, braucht in der dreischichtigen Architektur mit Applikationsserver der Datenbanktreiber nur auf dem Applikationsserver installiert zu werden. Zu den Aufgaben von JDBC (Java Database Connectivity) gehört es, Datenbankverbindungen aufzubauen, SQL-Anfragen an die Datenbank weiterzuleiten und die Ergebnisse dieser SQL-Abfragen in eine für Java nutzbare Form umzuwandeln. 2 OLE DB (Object Linking and Embedding, Database, auch OLEDB oder OLE-DB genannt) ist eine von Microsoft entwickelte Programmierschnittstelle basierend auf dem Component Object Model (COM) für einen standardisierten Zugriff auf unterschiedliche Datenquellen. 1 © IDL GmbH Mitte 11 Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK Der Applikationsserver kann gleichzeitig mehrere Datenbankverbindungen zu unterschiedlichen IDL-Datenbanken bereitstellen. Der Release-Stand der IDL-Datenbanken muss allerdings mit dem Release des Applikationsservers übereinstimmen. Jede Datenbankverbindung besitzt einen eindeutigen Namen, den sogenannten „Datenbank-Alias“. Dieser und alle zugehörigen DB-Verbindungsparameter sind im Applikationsserver konfiguriert. Für die Anwender ist die Konfiguration der Datenbankverbindungen allerdings gekapselt und damit nicht sichtbar. Applikationsserver bilden eine Sicherheitsgrenze zwischen Client und Datenbank. Ein direkter Zugriff der Desktop-Anwendungen auf die Datenbank ist nicht möglich. Webservices: Der Applikationsserver stellt verschiedene Webservices (Dienste) zur Verfügung. Zum Beispiel liefert ein Webservice die „Datenbank-Aliase“ an die Clients, ein anderer Webservice zeigt alle offenen Sitzungen (Sessions) von Benutzern. Der Applikationsserver beinhaltet außerdem eine Webserver-Funktionalität, sodass es möglich ist, über einen Internet-Browser (Internet Explorer, Mozilla Firefox, Google Chrome …) die Startseite des Applikationsservers aufzurufen und von dieser Seite mit Hilfe von Java Web Start die DesktopAnwendungen IDL.KONSIS.FORECAST und IDL.XLSLINK herunterzuladen und auszuführen. Vorteile der Drei-Schicht-Architektur mit Applikationsserver Nachfolgend werden einige Vorteile der Drei-Schicht-Architektur mit einem Applikationsserver gegenüber einer Zwei-Schicht-Architektur ohne Applikationsserver genannt: höhere Performance durch bessere Aufgabenverteilung (Client und Applikationsserver) Skalierbarkeit (Speicher des Applikationsservers ist nahezu unbegrenzt erweiterbar) höhere Netzwerk-Sicherheit (Netzwerkkommunikation über HTTPS) höhere Datenbank-Sicherheit (Datenbank ist gekapselt und für Außenwelt nicht erreichbar) einfache Client-Installation (Clients benötigen keine Datenbanktreiber) Voraussetzungen der Drei-Schicht-Architektur mit Applikationsserver Voraussetzung für eine Drei-Schicht-Architektur ist die Bereitstellung eines weiteren dedizierten Windows-Servers. Auf diesem wird der Applikationsserver installiert und konfiguriert. Weitere Informationen zur Client-Server-Architektur finden Sie im Handbuch „Neue Architektur von IDL.KONSIS.FORECAST“. Zwei-Schicht-Client-Server-Architektur mit Fat-Client Die zweischichtige Client-Server-Architektur besteht aus dem zentralen Datenbankserver als Server-Komponente und einem oder mehreren Benutzer-Clients als Client-Komponente. Die Desktop-Anwendung ist die Client-Komponente. Sie beinhaltet eine Datenbankschnittstelle, mit der der Benutzer auf die Ressourcen des Datenbankservers zugreift. Der Client liest und pflegt die Daten in der Datenbank durch „Abschicken“ von SQL-Befehlen. Jeden SQL-Befehl sendet der Client als Anforderung an den Datenbankserver, um diesen dort ausführen zu lassen. Das Ergebnis liefert der Datenbankserver als Antwort an den Client zurück. Da in dieser Zwei-Schicht-Architektur der Fat-Client direkt mit der Datenbank kommuniziert, muss der Datenbanktreiber auf jedem Client-Rechner installiert und für die Anwendung konfiguriert sein. 12 © IDL GmbH Mitte Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK Der Name Fat-Client deutet schon darauf hin, dass ein Großteil der gesamten Anwendung auf dem Client liegt. Ein Fat-Client enthält die gesamte Fachlogik. Nicht nur die Dateneingabe und die Datenausgabe, sondern auch die Datenverarbeitung erfolgt dort, wo der Fat-Client ausgeführt wird. Abbildung 5: 2-Schicht-Client-Server-Architektur mit Fat-Client Diese Zwei-Schicht-Architektur mit dem sogenannten Fat-Client wurde in der Vergangenheit bis IDL.KONSIS-Version 2013 fast ausschließlich angewandt. Der Client wurde auf einem PC oder auch auf einem Terminal-Server ausgeführt, oft über eine Netzwerkfreigabe aus dem Programmverzeichnis. Dieses wurde auf einem File Server3 installiert. Dadurch waren Updates sehr einfach umsetzbar. Ein zeitaufwendiges Update der Client-Rechner entfiel durch die zentrale Speicherung der Client-Komponenten auf dem File Server. Allerdings war die Performance von IDL.KONSIS eingeschränkt, da alle Client-Komponenten über das Netzwerk geladen, entpackt und ausgeführt wurden. Zusätzlich verschlechtert sich die Performance erheblich durch eine hohe Netzwerk-Latenz. Die Netzwerklatenz ist die Zeit, welche eine Anfrage benötigt, um vom Client über das Netzwerk zu einem Server und zurück benötigt. Ab IDL.KONSIS.FORECAST-Version 2014 wurde die Zwei-Schicht-Architektur mit Fat-Client nach und nach durch eine moderne Drei-Schicht-Architektur mit Applikationsserver ersetzt. Die zweischichtige Client-Server-Architektur mit dem Fat-Client wird bei IDL.KONSIS.FORECAST und IDL.XLSLINK ab der Version 2016 nicht mehr unterstützt. 3 Der „File Server“ ist ein Rechner oder auch ein Netzwerk-Speicher (NAS: Network Attached Storage), der Dateien und Dateisysteme im Netzwerk für Clients und für andere Server zur Verfügung stellt. © IDL GmbH Mitte 13 Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK 4 Authentifizierung Windows-Authentifizierung – Single Sign On (SSO) Single Sign On (SSO) heißt übersetzt „einmalige Anmeldung“ und bedeutet, dass ein Benutzer nach einmaliger Authentifizierung an einem Arbeitsplatz alle Anwendungen benutzen kann, für die er autorisiert ist, ohne sich jedes Mal neu mit Benutzername und Passwort anmelden zu müssen. Windows-Authentifizierung (SSO) - Anmeldung an Microsoft SQL Server Wenn ein Benutzer eine Verbindung zum Microsoft SQL Server über ein Windows-Benutzerkonto herstellt, überprüft der Microsoft SQL Server den Benutzernamen und das zugehörige Kennwort mithilfe des Tokens für den Windows-Prinzipal4 im Betriebssystem. Bei einer erfolgreichen Überprüfung wird damit die Benutzer-Identität von Windows bestätigt. Die Windows-Authentifizierung ist bei Microsoft SQL-Server der Standardauthentifizierungsmodus. Die Windows-Authentifizierung verwendet das Kerberos-Sicherheitsprotokoll und stellt Maßnahmen zur Durchsetzung von Kennwortrichtlinien bereit, wie die Komplexität sicherer Kennwörter. Darüber hinaus bietet die Windows-Authentifizierung eine Unterstützung für Kontosperrungen und Ablauf von Kennwörtern. Mit der Windows-Authentifizierung können Windows-Gruppen auf Domänen als Anmeldungen im Microsoft SQL Server erstellt werden. So muss nicht jeder einzelne Benutzer als Anmeldung eingerichtet werden. Das spart einen erheblichen Aufwand beim Administrieren. Claims-Based-Identity (CBI) - Authentifizierung Claims-basierte Identität (CBI) kann den Authentifizierungsprozess erheblich vereinfachen, da sich der Benutzer nicht mehrfach an mehreren Anwendungen anmelden muss. Eine einzige Anmeldung erzeugt das Token, das dann zur Authentifizierung gegen mehrere Anwendungen oder Websites verwendet wird. Ein Token ist ein Satz von Bytes, das Informationen über eine Identität enthält. Da bestimmte Informationen (Claims) im Token verpackt sind, muss der Benutzer nicht jeder einzelnen Anwendung diese Informationen wiederholt mitteilen. Optional in Verbindung mit CBI können die Microsoft ADFS (Active Directory Federation Services) genutzt werden. Microsoft ADFS ermöglicht zum Beispiel den Zugriff auf fremde Anwendungen innerhalb und außerhalb des hauseigenen AD (Active Directory). Als Vermittler zwischen dem hauseigenen AD und der Claimsbasierenden Anwendung wird Microsoft ADFS eingesetzt. Claims-Based-Identity (CBI) sorgt für eine integrierte Authentifizierung innerhalb der IDL CPM Suite. Voraussetzung für die Authentifizierung via CBI ist ein CBI-Server. Dieser CBI-Server wird durch den IDL.WORKPLACESERVER (WPS) bereitgestellt. Für die Anbindung von IDL.KONSIS.FORECAST an den Identity Provider des WPS stellt der WPS ein XML-Paket mit einem SSL-Zertifikat zur Verfügung. 4 Windows-Principals stellen Windows-Benutzer und ihre Rollen bzw. ihre Windows-Gruppen dar. 14 © IDL GmbH Mitte Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK Authentifizierung mit IDL-User-Modus Innerhalb der Anwendung IDL.KONSIS.FORECAST können nicht nur Benutzer, sondern auch deren Passwörter verwaltet werden. Es gibt zudem die Möglichkeit zur Durchsetzung von KennwortRichtlinien, so zum Beispiel zur Überprüfung der Komplexität sicherer Kennwörter. Die Kennwörter werden verschlüsselt in der Datenbanktabelle als Hashwert gespeichert und sind für Anwender von IDL.KONSIS.FORECAST nicht lesbar. Ein Hashwert ist ein String definierter Länge. Der Hashwert wird aus dem Passwort und einem Zufallsstring (Salt) gebildet. Diese Authentifizierungsmethode wird aktiv, wenn am Applikationsserver der Aliasname der Datenbankverbindung auf den Authentifizierungsmodus IDL-User gesetzt wird. Berechtigungen zum Ändern der Kennwortrichtlinien und die Berechtigung zum Zurücksetzen der Passwörter erfolgt innerhalb der Anwendung IDL.KONSIS.FORECAST und ist in der Regel die Aufgabe eines Anwendungsadministrators innerhalb der Fachabteilung. Mit dieser Authentifizierungsmethode müssen für die Benutzer keine weiteren Anmeldungen im Microsoft SQL Server gesetzt werden. Dies spart serverseitig erheblichen Verwaltungsaufwand. Der IDL-USER bietet sich an, wenn sich ein Benutzer außerhalb der Domäne (externer Zugriff) am Applikationsserver authentifizieren möchte und Single Sign On (SSO) oder CBI nicht möglich sind. SQL-Server-Authentifizierung Bei Verwendung der SQL-Server-Authentifizierung werden Anmeldungen in Microsoft SQL Server erstellt, die nicht auf Windows-Benutzerkonten basieren. Sowohl der Benutzername als auch das Kennwort werden auf dem Microsoft SQL Server gespeichert. Benutzer, die mit SQL-ServerAuthentifizierung eine Verbindung herstellen, müssen jedes Mal ihre Anmeldeinformationen (Anmeldename und Kennwort) eingeben, wenn sie eine Verbindung herstellen. Es sind drei optionale Kennwortrichtlinien für SQL-Server-Authentifizierung verfügbar: Der Benutzer muss das Kennwort bei der nächsten Anmeldung ändern. Dies erfordert das Ändern des Kennworts durch den Benutzer beim nächsten Herstellen einer Verbindung. Ablauf des Kennworts erzwingen: Die Richtlinie für das maximale Kennwortalter wird für SQL-Server-Anmeldungen erzwungen. Kennwortrichtlinie erzwingen: Die Windows-Kennwortrichtlinien des Computers werden für SQL-Server-Anmeldungen erzwungen. Dies schließt Kennwortkomplexität ein. Es gibt bei IDL.KONSIS.FORECAST einen SQL-authentifizierten Benutzer für Wartungszwecke, mit dem die Updates durchgeführt werden. Weiterhin gibt es einen SQL-authentifizierten Benutzer für die Administration innerhalb der Anwendung und außerdem einen sogenannten internen Benutzer, mit dem der Applikationsserver auf die IDL-Datenbank(en) zugreift. © IDL GmbH Mitte 15 Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK 5 Proxy-Server Ein sogenannter Proxy-Server erlaubt einem Netzwerk-Administrator die Installation von strengen Sicherheitsregeln in einem privaten Netz. Der Proxy-Server dient als sicheres Gateway zwischen einem privaten und einem öffentlichen (ungesicherten) Netz. Ein Proxy-Server leitet über seine eigene Adresse die Anfragen des Clients, etwa die Anfrage zum Aufruf einer Website, an den entsprechenden Server weiter, ohne dass Client und Server direkt mit einander verbunden sein müssen. Ein Proxy-Server dient weiterhin zur Zwischenspeicherung von Web-Inhalten. Damit ermöglicht der Proxy-Server einen schnelleren Zugriff auf Internetinhalte und sorgt für eine Entlastung der Internet-Anbindung. Ein Proxy-Server kann zudem auch als erweiterte Firewall benutzt werden. Je nach Proxy-Server-Konfiguration muss sich ein Benutzer eines ProxyServers ggf. mit einem Benutzernamen und Kennwort authentifizieren. Abbildung 6: Proxy-Server im Firmennetz Die beiden Clients IDL.KONSIS.FORECAST und IDL.XLSLINK können über einen Proxy-Server mit dem Applikationsserver kommunizieren. Dies ist nur dann erforderlich, wenn der Applikationsserver in einem anderen Netzwerk (WAN) oder aber im Internet steht und Sie in Ihrem lokalen Netzwerk (LAN) den Proxy-Server benötigen, um den Applikationsserver im entfernten Netz bzw. im Internet zu erreichen. 16 © IDL GmbH Mitte Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK 6 Literaturhinweise Literaturhinweise für Anwender Das Handbuch „IDL.KONSIS.FORECAST-Start der Anwendung“ beschreibt den ersten Start der Anwendung IDL.KONSIS.FORECAST. Analog dazu beschreibt das Handbuch „IDL.XLSLINK-Schnelleinstieg“ den ersten Start von IDL.XLSLINK, die Konfiguration und die Installation des Excel-Add-Ins. Informationen zum „Einlesen“ und zum „Auslesen“ von Daten und Hinweise zur Benutzung des Excel-Add-Ins finden Sie im Handbuch „Daten lesen und exportieren mit IDL.XLSLINK“. Literaturhinweise für die IT-Administration IDL.KONSIS.FORECAST und IDL.XLSLINK haben bereits mit dem Release 2014.0 eine moderne Client-Server-Architektur bekommen. Wichtige Informationen zur Client-Server-Architektur finden Sie im Handbuch „Neue Architektur von IDL.KONSIS.FORECAST“. Wichtige Informationen zur Serverinstallation, zur Clientinstallation und auch zur Konfiguration des Applikationsservers finden Sie im Handbuch „Installation IDL.KONSIS.FORECAST“. © IDL GmbH Mitte 17 Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK 7 Kontakt Sie können den technischen Support wie folgt erreichen: Per Online-Supportanfrage: https://www.idl.eu/service-center/support/weberfassung-supportanfrage/ Dies setzt voraus, dass ein Account vorhanden ist. Sollte keiner vorhanden sein, so legen Sie bitte einen an. Wichtig hierbei ist, dass Sie Ihre Kundennummer vorliegen haben, um diese im Nachhinein in Ihrem Profil eintragen zu können. Per Mail: [email protected] oder per Telefon: +49 (0)4102-4785-11 Tipp: Um die bestmögliche Reaktionszeit auf Ihre Anfrage zu erhalten, senden Sie Ihre Anfrage einfach per „Online-Supportanfrage“. Ihr technischer Support IDL GmbH Mitte 18 © IDL GmbH Mitte
