Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK :34

Transkript

1 Sichere Datenübertragung mit IDL.KONSIS.FORECAST und IDL.XLSLINK :34

2 Inhaltsverzeichnis 1 Einführung Sicherheit mit HTTPS Client und Server im Computer-Netzwerk IDL.KOSISFORECAST und Proxy-Server Authentifizierungsmöglichkeiten Anhang allgemein Anhang zum RSA-Algorithmus Literaturhinweise Kontakt IDL GmbH Mitte

3 1 Einführung Motivation Sichere Datenübertragungen nutzen wir bereits im Alltag, ob nun bewusst oder unbewusst, so zum Beispiel beim elektronischen Zahlungsverkehr mit der Kredit- oder der girocard (ehemals electronic cash), beim Online-Banking, in den sozialen Netzwerken und zunehmend bei Internet-Einkäufen. Insgesamt nimmt die Anzahl der Websites mit einer sicheren https-internetverbindungen zu. So nutzen Regierungsstellen, Kommunen, Krankenkassen, Stiftungen, Verbände, Organisationen und zunehmend auch Wirtschafsunternehmen ssl-zertifikatsbasierende https-verbindungen. Ein wesentlicher Grund dafür ist, dass Website-Betreiber Vertrauen zu ihren Kunden und zu ihren Website-Besuchern schaffen möchten, in dem sie vertrauenswürdige SSL-Zertifikate anbieten und damit sichere https-verbindungen. Auch in den sozialen Netzwerken wie bei Google+, Facebook, Instagram, Twitter, Linkedin und Xing werden die Daten zwischen Internet-Browser und Webservern in einer https-verbindung über das Internet übertragen, denn deren Website-Besucher nutzen diese Online-Plattformen zunehmend für den Austausch sensibler Nachrichten und Inhalte. Websites mit einem Kunden-Login benutzen sehr oft https-verbindungen. Auch die IDL-Unternehmensgruppe ist Betreiber einer Website mit Kunden-Login. Sie finden diese Website mit Lösungen für Finanzwesen und Controlling unter der Adresse: Website-Besucher erwarten ein gültiges Sicherheitsschloss im Internetbrowser, wenn vertrauliche und sensible Informationen über das Internet übermittelt werden sollen. SSL-Zertifikate aktivieren dieses Sicherheitsschloss sowie das Übertragungsprotokoll https. SSL-Zertifikate garantieren den Website-Besuchern, dass die über das Internet gesendete Daten verschlüsselt sind. Im Internet-Explorer lassen sich sichere https-verbindungen an einem Schloss-Symbol in der Adressleiste erkennen. Die Internet-Adresse beginnt mit " Bei Einkäufen in Online-Shops sollten Website-Besucher unbedingt darauf achten, sensible Daten wie Zahlungsinformationen nur bei einer https-verbindung einzugeben. Wenn Sie im Handel, im Dienstleistungsgewerbe oder in der Gastronomie gefragt werden, ob Sie mit Karte" bezahlen möchten, ist in den meisten Fällen die girocard in Verbindung mit der PIN- Eingabe gemeint. Hierfür stecken Sie die girocard ins POS-Terminal 1, geben nach Aufforderung ihre vierstellige PIN ins PIN-Pad des Terminals ein und das Geld wird nach Online-Überprüfung und Korrektheit der gesendeten Daten direkt von ihrem Konto abgebucht. Um eine girocard-zahlung dem richtigen Bankkonto zuordnen zu können, ist es nötig, einige Daten an die Bank zu übermitteln. Deshalb ist auf dem Chip der girocard die Primary Account Number (PAN) hinterlegt. Die PAN Nummer identifiziert eindeutig ihre girocard und ist bis zu 19 Stellen lang. Sie umfasst Land, Kreditinstitut, Bankleitzahl, Kontonummer und außerdem noch eine Prüfzahl. POS-Terminals lesen diese PAN aus. Der zu zahlende Betrag und die PAN werden vom Kommunikationsmodul des POS-Terminals über das Netz eines Netzbetreibers 2 an den Server der Bank sicher übertragen. Dort werden die Daten verifiziert. Nach erfolgreicher Verifizierung wird der Bezahlvorgang durchgeführt und der Händler bekommt eine Rückmeldung Zahlung erfolgt. Der Kunde bekommt auf Wunsch einen Beleg mit den Angaben zum Zahlungsvorgang. 1 POS Terminal (Point of Sale Terminal); siehe auch allgemeiner Anhang - Girocard-Verfahren 2 Netzbetreiber im Zahlungssystem der girocard IDL GmbH Mitte 3

4 Sichere Datenübertragung bei Anwendungen / Applikationen im betrieblichen Umfeld Werden betriebliche Daten innerhalb des Firmen-Netzwerkes übertragen, sollten diese ebenfalls vor unbefugten Einsehen oder Manipulation durch eine nicht berechtigte Person angemessen geschützt werden, denn digitale Daten sind ein wesentlicher Wert im Unternehmen bzw. in der Kommune. Unzureichend geschützte betriebliche Daten stellen oft ein unterschätztes Sicherheitsrisiko dar, dass im schlimmsten Fall sogar existenzbedrohend sein kann. Um Daten ausreichend schützen zu können, müssen Unternehmen und Kommunen wissen, wer auf diese Daten zugreifen darf und wie sich diese Daten durch das Unternehmensnetzwerk bewegen. Bevor vertrauliche und sensible Firmendaten im Netz übertragen werden, sollte zu einer gesicherten, verschlüsselten Verbindung gewechselt werden. Wie funktioniert das im Detail? Dieses Handbuch beschreibt, wie diese gesicherte Verbindung im IDLKONSISFORECAST und im IDL.XLSLINK aufgebaut wird. Es erläutert die dabei verwendeten sicherheitsrelevanten Protokolle. Weiterhin wird die für die sichere Datenübertragung notwendige, moderne Client-Server-Architektur beschrieben. Für wen ist das Handbuch geschrieben? Das vorliegende Handbuch spricht Leser an, die sich über die Themen sichere Datenübertragung und Datensicherheit informieren möchten. Welche Inhalte bietet das Handbuch? HTTPS als sicheres Transportprotokoll Mit dem Release IDL.KONSIS.FORECAST 2014 wurde erstmals der neue IDL Applikationsserver ausgeliefert. Dieser kommuniziert mit den beiden Client-Anwendungen IDL.KONSIS.FORECAST und IDL.XLSLINK über das sichere Transportprotokoll HTTPS. HTTPS ist ein weltweit verbreiteter Standard zur sicheren Datenübertragung in Netzwerken und im Internet. Bei HTTPS-Verbindungen wird die Verschlüsselung durch die Verschlüsselungsprotokolle SSL / TLS realisiert, um transportierte Daten unlesbar zu machen. SSL (Secure Socket Layer) wurde bereits 1994 vom Browserhersteller Netscape eingeführt. SSL wird immer noch verwendet, doch ist heute das Nachfolgeprotokoll TLS stärker verbreitet, wobei die Abkürzung TLS für Transport Layer Security steht. Alle gängigen Internet-Browser und viele Dienste-Anbieter nutzen dieses Protokoll. Dieses Handbuch liefert Hintergrundinformationen zu HTTPS. Es geht dabei auf die Unterschiede zwischen symmetrischer und asymmetrischer Verschlüsselung ein und beschreibt die Vorteile einer hybriden Verschlüsselung, so wie sie bei den beiden Protokollen SSL und TLS Verwendung finden. Das vorliegende Handbuch erläutert die Funktion und die Vertrauensprüfung von SSL-Zertifikaten in einer Public Key Infrastruktur. Die Client-Server-Architektur mit dem IDL Applikationsserver im lokalem Netzwerk (LAN) und in regional verteilten Netzwerken (WAN) Voraussetzung für https ist eine Architektur, in der Client und Server dieses Protokoll unterstützen. Das vorliegende Handbuch erklärt die moderne, dreischichtige Client-Server-Architektur in einem lokalen Netzwerk (LAN) und in regional verteilten Netzwerken (WAN). Es beschreibt dabei, wie man den Datenbankserver durch Kapselung vor unberechtigten SQL-Abfragen schützen kann. 4 IDL GmbH Mitte

5 Liegen die Client-Anwendungen und der IDL Applikationsserver in unterschiedlichen Netzwerken, kann es erforderlich sein, dass am Client eine Proxy-Konfigurationseinstellungen durchgeführt werden muss, damit Client und IDL Applikationsserver kommunizieren können. Dies wird in einem eigenen Kapitel erläutert. Authentifizierungsmethoden bei IDL.KONSIS.FORECAST und IDL.XLSLINK Es gibt alternative Authentifizierungsmethoden. Im Handbuch werden verschiedene Möglichkeiten der Authentifizierung bei der Anmeldung an IDL.KONSIS.FORECAST und IDL.XLSLINK genannt und die Vor- und Nachteile gegenübergestellt. Hinweise für Anwender von IDL.KONSIS.FORECAST und IDL.XLSLINK Der Inhalt des vorliegenden Handbuches ist technischer Natur. Kenntnisse aus dem Computer- und Netzwerkbereich sind 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. Ihr technischer Support IDL GmbH Mitte IDL GmbH Mitte 5

6 2 Sicherheit mit HTTPS Um Daten im Netzwerk sicher zu übertragen, wird das Transportprotokoll HTTPS benutzt. HTTPS (Hypertext Transfer Protocol Secure) wird hauptsächlich verwendet, um Webseiten und dynamische Inhalte einer Webseite 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. Integrität liegt immer nur dann vor, wenn die Nachrichten unverändert zugestellt werden. Die Sicherheit der Datenübertragung mit HTTPS wird durch eine Authentifizierung des Servers mit einem SSL-Zertifikat und außerdem durch eine abhörsichere Transportverschlüsselung 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). TLS dient der Verschlüsselung und damit der sicheren Datenübertragung zwischen Client und Server in Netzwerken bzw. im Internet. Verschlüsselung bezeichnet die Umwandlung von Daten in eine andere Form, die man als Chiffretext bezeichnet und die von nicht autorisierten Personen nicht zu verstehen ist. Bei der Entschlüsselung (Dechiffrieren) wiederum werden verschlüsselte Daten wieder in ihre ursprüngliche Form konvertiert, um sie lesbar zu machen. In den letzten Jahren kam es zu einer kontroversen Diskussion hinsichtlich der sogenannten starken Verschlüsselung. Damit sind Chiffren gemeint, deren Entschlüsselung ohne den passenden Schlüssel als unmöglich gilt. Diese Schlüssel ist digital und entsprechend groß, um die Sicherheit des Verfahrens zu gewährleisten. Was geschieht bei einer HTTPS-Verbindung im Einzelnen? Der Client (zum Beispiel ein Internet-Browser) baut eine Verbindung zum Server auf. Der Server authentisiert sich gegenüber dem Client mit einem Zertifikat. Dieses Zertifikat enthält Angaben zum Inhaber, zum Aussteller sowie über die Gültigkeitsdauer. Weiterhin enthält das Zertifikat einen öffentlichen Schlüssel und auch eine digitale Signatur. Diese Signatur erfolgt oft durch eine Zertifizierungsstelle. Der Client (zum Beispiel der Internet-Browser) überprüft mit den im Zertifikat gemachten Angaben nun die Vertrauenswürdigkeit der HTTPS-Verbindung. Ist die Überprüfung der Vertrauenswürdigkeit negativ, zeigt der Client eine Warnung an, dass die Verbindung nicht vertrauenswürdig ist. Der Anwender kann nun entscheiden, wie weiter verfahren werden soll, also ob die HTTPS-Verbindung zum Server abgebrochen oder aber weiter bestehen soll, um dann Daten zu übertragen. Bevor nun 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 HTTPS-Verbindung verwendet werden soll. Der Client und der 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 wieder zusammensetzt. Wird die Sitzung unterbrochen und neu aufgebaut, wiederholt sich der gesamte Prozess, der Server authentifiziert sich gegenüber dem Client mit dem Zertifikat erneut. Es wird eine neue Sitzung aufgebaut und ein neuer Sitzungsschlüssel wird erzeugt, um dann die Nutzdaten zu verschlüsseln. 6 IDL GmbH Mitte

7 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 verwendet werden. Der Advanced Encryption Standard (AES) verschlüsselt Datenblöcke. Nach seinen Entwicklern Joan Daemen und Vincent Rijmen wird AES auch Rijndael-Algorithmus genannt. Bei AES handelt sich um ein symmetrisches Verschlüsselungsverfahren, d. h. der Schlüssel zum Ver- und Entschlüsseln ist identisch. AES schränkt die Blocklänge auf 128 Bit und die Wahl der Schlüssellänge auf 128, 192 oder 256 Bit ein. Die Bezeichnungen der drei AES-Varianten AES-128, AES-192 und AES-256 beziehen sich jeweils auf die gewählte Schlüssellänge. Die Funktionsweise des Rijndael-Algorithmus beruht auf einer Reihe von Byteersetzungen (Substitutionen), Verwürfelungen (bzw. Permutationen) und linearen Transformationen, die auf Datenblöcken von 16 Byte ausgeführt werden daher auch die Bezeichnung Blockverschlüsselung. Diese Operationen werden mehrmals wiederholt, wobei in jeder dieser Runden ein individueller, aus dem Schlüssel berechneter Rundenschlüssel in die Berechnungen einfließt. Wird nur ein einziges Bit im Schlüssel oder im Datenblock verändert, entsteht ein komplett anderer Chiffreblock. Der Rijndael-Algorithmus bietet ein sehr hohes Maß an Sicherheit und daher ist AES der bevorzugte Verschlüsselungsstandard für Regierungen, Banken und High-Security Systeme weltweit. Asymmetrische Kryptosysteme (Public Key Kryptosystem) 1976 erfanden die Mathematiker Whitfield Diffie und Martin Hellman die Grundzüge des Public-Key- Verfahrens, mit dem das Problem der Geheimhaltung des Schlüssels gelöst werden konnte. 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, wird unter keinen Umständen weitergegeben. Dieser wird vom Besitzer geheim gehalten. Der öffentliche Schlüssel hingegen ist in das SSL-Zertifikat integriert und wird an die Clients weitergegeben. Der öffentliche Schlüssel ermöglicht es jedem Benutzer, Nutzdaten zu verschlüsseln, die nur der Besitzer des privaten Schlüssels entschlüsseln kann. Mit dem öffentlichem Schlüssel kann auch die Signatur eines Zertifikates und damit deren Verauenswürdigkeit überprüft werden Der private Schlüssel ermöglicht es seinem Besitzer, mit dem öffentlichen Schlüssel verschlüsselte Daten wieder zu entschlüsseln und digitale Signaturen zu erzeugen. Privater und öffentlicher Schlüssel bilden das gemeinsame Schlüsselpaar für die asymmetrische Verschlüsselung. 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 erfanden die Mathematiker Whitfield Diffie und Martin Hellman die Grundzüge des Public-Key- Verfahrens, mit dem das Problem der Geheimhaltung des Schlüssels gelöst werden konnte. IDL GmbH Mitte 7

8 Der RSA-Verschlüsselungsstandard als Beispiel für eine asymmetrische Verschlüsselung RSA ist ein asymmetrisches kryptographisches Verfahren, das sowohl zum Verschlüsseln als auch zum digitalen Signieren verwendet werden kann. Das RSA-Verfahren benutzt zum Verschlüsseln und zum Überprüfen der Signatur einen öffentlichen Schlüssel. Zum Entschlüsseln sowie zum digitalen Signieren benutzt RSA einen privaten Schlüssel. RSA-Einführung Die drei Mathematik-, Kryptologie- und Informatik-Professoren Ronald Linn Rivest, Adi Shamir und Leonard Adleman entwickelten am Massachusetts Institute of Technology - MIT Laboratory for Computer Science and Mathematics, Cambridge, USA, ein Verfahren zum digitalen Signieren und zum Verschlüsseln mit einem öffentlichen Schlüssel (Public Key) und veröffentlichten ihre Ideen im April 1977 unter dem Titel: A method for obtaining Digital Signatures and Public Key Cryptosystems. Das RSA-Verfahren wurde im Jahr 1983 unter dem US-Patent eingetragen. Das Patent lief im Jahre 2000 aus. Die amerikanische Regierung jedoch konnte RSA auch vor dem Jahr 2000 ohne Lizensierung verwenden, da der RSA-Algorithmus am MIT entwickelt wurde, das von der US Regierung mitfinanziert wird. RSA-Algorithmus zum Erstellung der Schlüssel Vorweg ein Hinweis: Die Mathematik (Zahlentheorie) hinter dem RSA-Algorithmus, die Herleitung der Formeln zum Ver- und zum Entschlüsseln sowie die Konstruktion der Schlüssel sind im RSA-Anhang ausführlich beschrieben. Der öffentliche Schlüssel besteht aus einem Zahlenpaar ( e, N ). Der private Schlüssel besteht ebenfalls aus einem Zahlenpaar ( d, N ). Die Zahl e ist der sogenannte Verschlüsselungsexponent. Die Zahl d ist der Entschlüsselungsexponent und N ist der RSA-Modul. Der Modul N soll das Produkt zweier sehr großer, zufällig gewählter Primzahlen p und q sein. Um die Sicherheit bei RSA zu gewährleisten, sollten Primzahlen mit einer Größe von mindestens Bit verwendet werden. Die Komponenten N, e und d sind durch eine mathematische Formel miteinander verbunden. Folgende Bedingung soll gelten: Die Zahl e soll größer als 1 und kleiner als φ ( N ) sein. Zudem sollen e und φ ( N ) teilerfremd sein: ggt (e, φ ( N ) ) = 1 Mit der Eigenschaft, dass e und φ ( N ) teilerfremd sind, gibt es im Modul φ ( N ) ein multiplikatives Inverses zu e. Das Inverse (e -1 ) multipliziert mit e ergibt als Produkt eine ganze Zahl, die bei der Division mit φ ( N ) den Rest 1 lässt. Das Produkt aus e und e -1 ist kongruent zu 1 im Modul φ ( N ). Das Inverse zu e im Modul φ ( N ) ist der Entschlüsselungsexponent d. e d 1 (mod φ ( N )) Im Modul φ ( N ) ist das Produkt aus e und d kongruent zu 1 => φ ( N ) teilt e d - 1 Für zwei Primzahlen p und q gilt: => φ ( N ) = φ ( p q ) = φ ( p ) φ ( q ) = ( p - 1 ) ( q - 1 ) φ ( N ) kann nur derjenige berechnen, der auch die beiden Primzahlen p und q kennt. Die Primzahlen p und q sowie φ ( N ) werden nach der Schlüsselerstellung nicht mehr benötigt. 8 IDL GmbH Mitte

9 RSA-Algorithmus zum Verschlüsseln und zum Entschlüsseln Haben Sie eine Nachricht als Text und wollen diese verschlüsseln, müssen Sie den Text zuerst in Zahlen umwandeln. Den umgewandelten Text bezeichnen wir nachfolgend als M. Wollen Sie aus M eine verschlüsselte Nachricht C erzeugen, dann berechnen Sie C nach folgender Formel: C = M (e) (mod N) Die verschlüsselte Nachricht C lässt sich mit dem privaten Schlüssel wieder entschlüsseln: M = C (d) (mod N) Anmerkung zu mod in einer Gleichung (=): hier ist die Rechenoperation mod (modula) gemeint. M = C (d) (mod N) bedeutet, dass M das Ergebnis der Rechenoperation C (d) (mod N) ist. Der Ausdruck mod kann auch als Kongruenzrelation benutzt werden, bekommt dann aber eine andere Bedeutung. Als Kongruenz dient das Symbol.. Kongruent sind zwei Zahlen bezüglich eines Moduls, wenn sie in derselben Restklasse sind, wenn sie sich also um ein Vielfaches des Moduls unterscheiden. RSA - Beispiel mit sehr kleinen Primzahlen Nun folgt ein Beispiel mit sehr kleinen Primzahlen, zum besseren Verständnis. p = 2 und q = 5. Daraus folgt N = 2 5 = 10 und φ ( N ) = ( 2-1 ) ( 5-1 ) = 4 Der Verschlüsselungsexponent e soll größer als 1, kleiner als 4 und außerdem teilerfremd zu 4 sein. Für e = 3 treffen diese Bedingung zu. Das Inverse zu e ergibt sich aus dem ggt (3, 4 ) = 1 Aus dem ggt (3, 4 ) = 1 folgt die diophantische Gleichung: 1 = 3 x + y 4 Diese Gleichung ist für ganzen Zahlen x und y lösbar mit der Linearkombination aus [3, -2]. Der Entschlüsselungsexponent d ist damit 3. Die Zahl 4 teilt (mod 4) Wenn wir eine Nachricht ABCD verschlüsseln wollen, um diesen dann über einen unsicheren Kanal zu versenden, müssen wir die Nachricht zuerst in Zahlen umwandeln, zum Beispiel in 1234; M=1234. M M Modulo C=1874 Die verschlüsselte Nachricht C (Chiffre) lautet C C Modulo M=1234 Die entschlüsselte Nachricht M, umgewandelt in Text ist wieder unser Ausgangstext ABCD. Die Primzahlen 2 und 5 lassen sich sehr leicht aus der Primfaktorzerlegung (PFZ) von 10 ermitteln. Damit kann man den Entschlüsselungsexponenten d=3 berechnen und die verschlüsselte Nachricht 1874 sehr leicht entschlüsseln. Dieses Beispiel und andere Beispiele mit kleinen Primzahlen sollten in der Praxis natürlich nicht gewählt werden, da sich die PFZ und damit φ ( N ) aus kleinen N leicht berechnen lässt und das RSA Verfahren nicht sicher wäre. Anmerkung zur Sicherheit von RSA Die Sicherheit des RSA-Algorithmus basiert auf einem scheinbar, unlösbarem mathematischem Problem. Es wird angenommen, dass es auch in Zukunft kein intelligentes Verfahren geben wird, welches jede, noch so große, natürliche Zahl in ihre Primfaktoren zerlegen kann. IDL GmbH Mitte 9

10 Einwegfunktionen und Falltürfunktionen Die Multiplikation zweier Zahlen wird auch als Einwegfunktion bezeichnet, weil es sehr leicht ist, aus zwei natürlichen Zahlen durch eine einfache Multiplikation das Produkt zu bilden. Aber es ist sehr viel schwieriger, aus einer sehr großen, natürlichen Zahl deren mögliche Faktoren zu bestimmen. Wenn N das Produkt genau zweier, großer Primzahlen ist, dann müsste man durch zeitaufwendiges Ausprobieren den Modul N in seine Primfaktoren zerlegen. Eine spezielle Variante der Einwegfunktionen sind die Falltürfunktionen. Diese lassen sich nur dann effizient umkehren, wenn man gewisse Zusatzinformationen besitzt. Der RSA-Algorithmus benutzt eine Falltürfunktion mit e, d und N. Nur wenn e und φ ( N ) bekannt sind, lässt sich d berechnen. Um φ ( N ) berechnen zu können, müsste man die Primfaktorzerlegung (PFZ) von N bestimmen. Wenn allerdings Modul N mehrere Hundert Dezimalstellen hat, dann ist es in annehmbarer Zeit nicht möglich, die PFZ von N zu bestimmen. Nach dem derzeitigem Stand der Technik würden auch die schnellsten, verfügbaren Computer versagen, in annehmbarer Zeit ein RSA Modul mit N > 300 Dezimalstellen zu faktorisieren. Quantencomputer wären theoretisch in der Lage, sehr großer Zahlen mit 300 bis 600 Dezimalstellen zu faktorisieren, nur gibt es diese Art der Quantencomputer nicht, die genau dies in der Praxis könnten. Derzeit verfügbare Quantencomputer können nur sehr kleine Zahlen faktorisieren. Schlüsselraum bei RSA Da der RSA-Modul ein Produkt genau zweier, sehr großer Primzahlen ist und die Primzahlendichte bei sehr großen Zahlen kleiner wird, entfallen viele Zahlen als mögliche Faktoren für das RSA-Modul, sodaß der effektive RSA-Schlüsselraum deutlich geringer ist als die RSA-Schlüssellänge (in bit). Momentan benutzt man sogenannte brute force Methoden (Ausprobieren aller Möglichkeiten), um sehr große Zahlen in deren Primfaktoren zu zerlegen. Es wird damit versucht, den RSA-Algorithmus zu knacken. Die Vermutung, dass es auch in Zukunft keinen mathematischen Algorithmus geben wird, womit man jede, noch so große Zahl in ihre Primfaktoren zerlegen kann, wurde allerdings noch nicht bewiesen. Wenn jemand einen intelligenten Algorithmus finden sollte, der jede Zahl in ihre Primfaktoren zerlegen kann, dann wäre der RSA Algorithmus nicht mehr sicher. Jeder Angreifer, der den RSA Modul N faktorisieren kann, kann auch die Nachrichten entschlüsseln. Deshalb werden im praktischen Einsatz zwei sehr große, zufällig gewählte Primzahlen mit mehreren Hundert Dezimalstellen gewählt, deren Produkt man in annehmbarer Zeit nicht faktorisieren kann. RSA-1024 erzeugt ein Modul N mit einer Zahl in der Größenordnung von 309 Dezimalstellen, RSA 2048 erzeugt ein Modul N mit einer Zahl in der Größenordnung von 617 Dezimalstellen. Ausblick: Es wird vermutet, dass noch vor dem Jahr 2020 RSA-1024 geknackt wird. Gestützt wird diese Vermutung durch die bisherigen Rekorde: 1999 fiel RSA-512 und 2010 fiel RSA-768. Gängige Standards empfehlen deshalb, keine 1024-Bit-Schlüssel mehr zu verwenden, sondern auf 2048-Bit- Schlüssel oder sogar auf 4096-Bit-Schlüssel überzugehen. RSA-Verbreitung Rivest, Shamir und Adleman gründeten im Jahr 1982 die Firma RSA Security Data Inc. Diese erhielt eine Exklusivlizenz zur Nutzung der RSA-Technologie. Dabei musste die US-Firma für die Nutzung der RSA-Technologie an das MIT Lizenzgebühren abführen. Im Jahr 2000 lief diese Lizenz jedoch aus. Seitdem darf RSA auch in den USA lizenzfrei eingesetzt werden. In Europa brauchten Nutzer nie Lizenzgebühren bezahlen. Die Firma RSA Security Data Inc. wurde in den neunziger Jahren von deren Gründern an die Firma Security Dynamics Technologies Inc. verkauft und außerdem in RSA 10 IDL GmbH Mitte

11 Security Inc. umbenannt. Diese stellte ihren Kunden kryptografische Bibliotheken zur Verfügung und so wurde die RSA-Technology millionenfach in kryptografische Anwendungen (von Netscape, PGP, Microsoft, Apple, Intel, Nokia, IBM Notes ) integriert. Im Jahr 2000, in dem auch das US-Patent auslief, hat die RSA Security Inc. den RSA-Verschlüsselungsalgorithmus offen gelegt und so konnten auch andere Unternehmen Lösungen auf Basis dieses RSA-Algorithmus erstellen. Ab dem Jahr 2000 setzen vor allem die beiden Internet-Browser-Produzenten Microsoft und Netscape auf die RSA-Technology zur verschlüsselten Übertragung von Daten. RSA bildet unter anderem die Basis für das Protokoll SSL und das Nachfolgerprotokoll TLS, dass auch heute bei vielen Internet- Browsern zum Einsatz kommt. RSA hat mit zunehmender Verbreitung enorm viel Aufmerksamkeit gefunden und ist deshalb vielfach auf Sicherheitslücken untersucht und getestet worden. Auch in IDL.KONSISFORECAST und IDL.XLSLINK wird RSA verwendet. IDL.KONSISFORECAST und IDL.XLSLINK überprüfen mit dem öffentlichen RSA-Schlüssel die digitale Signatur und damit die Vertrauenswürdigkeit eines SSL-Zertifikates. Beim Erzeugen eines SSL-Zertifikates unterstützt der IDL Applikationsserver momentan RSA-2048 und RSA 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üsselungs- Verfahren ausgehandelt. Danach wird der sogenannte Sitzungsschlüssel (englisch: Session Key) erstellt und dieser wird dann asymetrisch verschlüsselt (zum Beispiel mit der RSA Verschlüsselung) 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 beiden Sicherheitsprotokollen ist es üblich, den Sitzungsschlüssel nach verhältnismäßig kurzer Zeit wieder neu auszuhandeln. Das dient der Sicherheit, denn 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 11

12 Hashfunktion, digitaler Fingerabdruck und 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 (certificate authority, kurz 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 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) Mit Public-Key-Infrastruktur bezeichnet man in der Kryptologie ein System, das digitale Zertifikate ausstellen, verteilen und prüfen kann. Die innerhalb einer PKI ausgestellten Zertifikate werden zur Herstellung von Vertraulichkeit verwendet. Bei 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. Weitere Zertifikate in dieser PKI werden mit dem zum Wurzelzertifikat zugehörigen privaten Schlüssel signiert. Eine solche Signatur für ein 12 IDL GmbH Mitte

13 Zertifikat wird nur dann ausgegeben, wenn alle von der CA festgelegten Anforderungen erfüllt wurden. Diese Anforderungen 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. Zum Signieren eines Zertifikates können auch private Schlüssel verwendet werden, deren zugehörige Zertifikate wiederum mit einem privatem Schlüssel eines Zertifikates innerhalb der PKI signiert wurden sind. Diese Zertifikate mit den zugehörigen privaten Schlüsseln bilden innerhalb einer PKI eine sogenannte Zertifikatskette. Theoretisch kann eine solche, hierarchisch aufgebaute Zertifikatskette beliebig lang werden, sie muss nur immer beim Wurzelzertifikat beginnen und darf nicht unterbrochen sein. 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 dem 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 Sicherheits- Warnmeldung, da diese über keine Signatur einer bekannten CA verfügen. Dem Zertifikat wird nicht vertraut, weil es vom Aussteller selbst signiert wurde. Browser-Warnmeldungen bei SSL-Zertifikaten Die Liste der bekannten SSL-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 diese 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. IDL GmbH Mitte 13

14 Abbildung 1: Internet Explorer -> Das Zertifikat wurde nicht von einer vertrauenswürden Zertifizierungsstelle ausgestellt Abbildung 2: Firefox -> Dem Zertifikat wird nicht vertraut, weil es selbst signiert wurde Dem Zertifikat in obiger Abbildung wurde nicht vertraut. 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. 14 IDL GmbH Mitte

15 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 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 15

16 3 Client und Server im Computer-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 Anwendungen IDL.KONSIS.FORECAST und IDL.XLSLINK sind die Client-Programme (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 Azure 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. Es 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. In der dritten Schicht, der Datenhaltungsschicht, befindet sich die Datenbank. Jede dieser drei Schichten kann nur mit der benachbarten Schicht kommunizieren. Was bedeutet das für IDL.KONSIS.FORECAST? Die beiden Client-Anwendungen IDL.KONSIS.FORECAST und IDL.XLSLINK können in dieser dreischichtigen Client-Server-Architektur mit dem Applikationsserver, aber nicht direkt mit der IDL- Datenbank kommunizieren. 16 IDL GmbH Mitte

17 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 (Netzwerk-Latenzzeit 3 kleiner als eine Millisekunde) zwischen dem Applikationsserver und dem Datenbankserver voraus. Applikationsserver und Datenbankserver sind in der Regel im selben Netzwerk. IDL Applikationsserver Der IDL 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 IDL Applikationsservers zur IDL-Datenbank wird über JDBC 4 - und über Ole DB 5 - Zugriffe 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 IDL-Datenbank zu reduzieren. 3 Die Netzwerk-Latenzzeit bezeichnet Verzögerungen in einem Netzwerk. Ein Netzwerk-Latenzzeit-Test misst die Zeit die ein Packet von einem Punkt zu einem anderen und wieder zurück braucht, die sog. Umlaufzeit. 4 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. 5 OLE DB ist eine von Microsoft entwickelte Programmierschnittstelle für einen standardisierten Zugriff auf unterschiedliche Datenquellen. IDL GmbH Mitte 17

18 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. 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 Desktop- Anwendungen 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. 18 IDL GmbH Mitte

19 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. 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 Server 6 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. 6 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 19

20 4 IDL.KOSISFORECAST und Proxy-Server Ein Proxy-Server ist eine Kommunikationsschnittstelle in Computer-Netzwerken. Wird ein Proxy-Server als Netzwerkkomponente eingesetzt, bleibt einerseits die tatsächliche Adresse eines Kommunikationspartners dem jeweils anderen Kommunikationspartner verborgen, was eine gewisse Anonymität schafft. Der Proxy-Server dient als sicheres Gateway zwischen einem privaten Netz und einem öffentlichen, ungesicherten Netzwerk. Er erlaubt einem Administrator die Installation von strengen Sicherheitsregeln in einem privaten Netz (LAN). Die beiden Clients IDL.KONSISFORECAST und IDL.XLSLINK können über einen Proxy-Server mit dem IDL Applikationsserver kommunizieren. Dazu müssen am Client vor der Anmeldung am IDL Applikationsserver (über die Schaltfläche Optionen) Proxy-Einstellungen durchgeführt werden. Dies ist aber immer nur dann erforderlich, wenn der IDL Applikationsserver in einem anderen Netzwerk (WAN), im Internet oder in der Cloud (zum Beispiel in der Microsoft Azure Cloud) steht und IDL.KONSISFORECAST den Proxy-Server benötigt, um den IDL Applikationsserver über HTTPS zu erreichen. Abbildung 6: Proxy-Server im Firmennetz 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 Proxy- Servers ggf. mit einem Benutzernamen und Kennwort authentifizieren. 20 IDL GmbH Mitte

21 5 Authentifizierungsmöglichkeiten Windows-Authentifizierung Anmeldung mit Single Sign On (SSO) Anmeldung mit Single Sign On 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-Prinzipal 7 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. 7 Windows-Principals stellen Windows-Benutzer und ihre Rollen bzw. ihre Windows-Gruppen dar. IDL GmbH Mitte 21

22 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 spezifischen Kennwort-Richtlinien, so zum Beispiel zur Überprüfung der Komplexität sicherer Kennwörter oder auch zur Gültigkeitsdauer von Kennwörtern (Ablauf des Kennworts erzwingen). 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 IDL 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 bzw. am Oracle Datenbankserver 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 IDL Applikationsserver authentifizieren möchte und Single Sign On (SSO) nicht möglich ist. 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-Server- Authentifizierung 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 IDL Applikationsserver auf die IDL-Datenbank(en) zugreift. 22 IDL GmbH Mitte