Differences

This shows you the differences between two versions of the page.

--- user:jan001:ba:reverseproxy [2021/02/09 13:11] – jan001
+++ user:jan001:ba:reverseproxy [2021/08/24 17:35] (current) – external edit 127.0.0.1
@@ Line 1: / Line 1: @@
 ====== Reverse Proxy (NGINX) ======
-Ein Reverse Proxy dient dazu einkommende Anfragen zu verwalten und diese an weitere Applikationen weiter zu leiten (Aivaliotis, 2013). Diese Anfragen folgen meist dem HTTP- bzw. HTTPS-Protokoll, aber sind nicht auf diese beschränkt. Im Allgemeinen wird zwischen 2 verschiedenen Reverse Proxy Arten unterschieden. Zum einen dem Protection Reverse Proxy und zum anderen dem Integration Reverse Proxy. Ein Protection Reverse Proxy ermöglicht es Anfragen gezielt zu filtern und nur gewünschte Anfragen durchzulassen. Ein Integration Reverse Proxy ermöglicht es Anfragen auf viele unterschiedliche Systeme zu verteilen. Im Folgenden wird nur der Intergration Reverse Proxy weiter beachtet, da ein Protection Reverse Proxy nicht zu Einsatz kam. (Sommerlad, 2003)
+Ein Reverse Proxy dient dazu einkommende Anfragen zu verwalten und diese an weitere Applikationen weiter zu leiten (Aivaliotis, 2013). Diese Anfragen folgen meist dem HTTP- bzw. HTTPS-Protokoll, aber sind nicht auf diese beschränkt. Im Allgemeinen wird zwischen 2 verschiedenen Reverse Proxy Arten unterschieden. Zum einen dem Protection Reverse Proxy und zum anderen dem Integration Reverse Proxy. Ein Protection Reverse Proxy ermöglicht es Anfragen gezielt zu filtern und nur gewünschte Anfragen durchzulassen. Ein Integration Reverse Proxy ermöglicht es Anfragen auf viele unterschiedliche Systeme zu verteilen. (Sommerlad, 2003) Im Folgenden wird nur der Intergration Reverse Proxy weiter beachtet, da ein Protection Reverse Proxy nicht zu Einsatz kam.
 ==== Probleme bei der Bereitstellung von Webapplikationen ====
-Eine Webapplikation besteht meistens nicht nur aus einem Webserver beziehungsweise Webdienst, welcher alle Aufgaben übernimmt, sondern mehreren. Als Entwickler entstehen schwerwiegende Probleme, wenn versucht wird eine Applikation auf lediglich einem Server zu betreiben. Nach Sommerlad gibt es sieben Punkte die es zu beachten gilt:
+Eine Webapplikation besteht meistens nicht nur aus einem Webserver beziehungsweise Webdienst, welcher alle Aufgaben übernimmt, sondern aus mehreren. Als Entwickler entstehen schwerwiegende Probleme, wenn versucht wird eine Applikation auf lediglich einem Server zu betreiben. Nach Sommerlad gibt es sieben Punkte die es zu beachten gilt:
   * Man kann eine Webapplikation nicht auf einem Server implementieren, da dies die Komplexität erhöht, die Performance oder Wiederverwendbarkeit verschlechtert.
   * Man möchte die allgemeine Netzwerkstruktur der Webapplikation verstecken, um bei Änderung jener beispielsweise Lesezeichen der Nutzer nicht zu zerstören.
@@ Line 25: / Line 25: @@
 === Nur ein Hostname ===
-Einer der wichtigsten Vorteile laut Sommerlad ist es, dass es lediglich einen bekannten Host gibt, und zwar den Reverse Proxy. Für den Nutzer muss lediglich die Adresse von diesem bekannt sein, um eine Webapplikation zu erreichen, welche auf mehreren Servern betrieben wird. Dass lediglich ein Hostname benötigt wird bringt noch weitere Vorteile mit sich. Auch ist die allgemeine Netzwerkstruktur der Webapplikation versteckt. Dies macht es für potenzielle Angreifer schwerer Sicherheitslücken zu finden. Weiterhin ist es so möglich einen Teil der Applikation auf einen anderen Server zu verschieben, ohne dass dies für einen Nutzer auffallen würde.
+Einer der wichtigsten Vorteile laut Sommerlad ist es, dass es lediglich einen bekannten Host gibt, und zwar den Reverse Proxy. Für den Nutzer muss lediglich die Adresse von diesem bekannt sein, um eine Webapplikation zu erreichen, welche auf mehreren Servern betrieben wird. Dass lediglich ein Hostname benötigt wird bringt noch weitere Vorteile mit sich. Auch ist die allgemeine Netzwerkstruktur der Webapplikation versteckt. Dies macht es für potenzielle Angreifer schwerer Sicherheitslücken zu finden. Weiterhin ist es so möglich einen Teil der Applikation auf einen anderen Server zu verschieben, ohne dass dies für einen Nutzer auffallen würde. (Sommerlad, 2003)
 === Verschlüsselung mit TLS ===
-TLS (kurz für Transport Layer Security) ist der Nachfolger des SSL-Protokolls. Die aktuelleste Version ist Version 1.3. Sowohl SSL als auch TLS sind Teil des HTTPS-Protokolls (Hypertext Transfer Protocol Secure). SSL kommt dabei heutzutage nicht mehr zum Einsatz, da es auf Grund von schweren Sicherheitslücken (POODLE Attacke) seit 2015 von der "Internet Engineering Task Force" als veraltet eingestuft wird (Oppliger, 2016, S.15). TLS ist ein essentieller Bestandteil der verschlüsselten Verbindung zwischen Nutzer und Webserver. Im normalen Fall läuft ein verschlüsselter Verbindungsaufbau mit gerade einmal drei Anfragen ab. {{:user:jan001:ba:oppinger-tls.png?200|}} Der Client (Nutzer) stellt zunächst eine Anfrage an den Server, sich zu authentifizieren. Der Server antwortet darauf hin mit den Verbindungsinformationen, einer Chiffre zur Verschlüsselung und einem Zertifikat. Der Client überprüft dann das Zertifikat. Ist das Zertifikat rechtens schickt er eine weitere Bestätigung an den Server zurück. Daraufhin können Daten verschlüsselt zwischen dem Server und dem Client ausgetauscht werden. Dieser Ablauf wird als TLS-Handshake bezeichnet. (Oppliger, 2016, S.139ff)
+TLS (kurz für Transport Layer Security) ist der Nachfolger des SSL-Protokolls. Die aktuelleste Version ist Version 1.3. Sowohl SSL als auch TLS sind Teil des HTTPS-Protokolls (Hypertext Transfer Protocol Secure). SSL kommt dabei heutzutage nicht mehr zum Einsatz, da es auf Grund von schweren Sicherheitslücken (beispielsweise POODLE Attacke) seit 2015 von der "Internet Engineering Task Force" als veraltet eingestuft wird (Oppliger, 2016, S.15). TLS ist ein essentieller Bestandteil der verschlüsselten Verbindung zwischen Nutzer und Webserver. Im normalen Fall läuft ein verschlüsselter Verbindungsaufbau mit gerade einmal drei Anfragen ab. {{:user:jan001:ba:oppinger-tls.png?200|}} Der Client (Nutzer) stellt zunächst eine Anfrage an den Server, sich zu authentifizieren. Der Server antwortet darauf hin mit den Verbindungsinformationen, einer Chiffre zur Verschlüsselung und einem Zertifikat. Der Client überprüft dann das Zertifikat. Ist das Zertifikat rechtens schickt er eine weitere Bestätigung an den Server zurück. Daraufhin können Daten mit der Chiffre verschlüsselt zwischen dem Server und dem Client ausgetauscht werden. Dieser Ablauf wird als TLS-Handshake bezeichnet. (Oppliger, 2016, S.139ff)
 Die Zertifikate, welche benötigt werden für TLS und somit https, können bei einer Zertifizierungsstelle wie "Let´s Encrypt" beantragt werden. Dies funktioniert nach Einrichtung auf einem Server voll automatisch, transparent und kostenlos. (Let´s Encrypt, o.J.)
 Besteht eine verschlüsselte Verbindung ist dies für den Nutzer anhand der URL erkennbar. Diese beginnt dann mit "https://" statt mit "http://". Würden nun alle Backend-Server einzeln an das Internet angebunden werden, so müsste auch jeder sein eigenes Zertifikat besitzen. Dann müsste der Client auch mit jedem der Server einen TLS-Handshake durchführen, was zusätzlich Zeit benötigen würde. Ein Integration Reverse Proxy ermöglicht es nun alle Verbindungen mit dahinterliegenden Backend-Server mit leiglich einem Zertifikat zu verschlüsseln. Ein weiterer Vorteil ist, dass, sofern sowohl Reverse Proxy, als auch Backend-Server in einem Netzwerk liegen und nicht über das Internet verbunden sind, die Verbindungen zwischen Reverse Proxy und den Backend-Servern nicht verschlüsselt sein müssen. Dies ist eine weitere Zeitersparnis.
 === Load Balancing ===
-Auch ermöglicht ein Reverse Proxy die Einrichtung mit sogenannten Load Balancing. Dabei werden Anfragen auf unterschiedliche Backend-Sever verteilt, welche aber die selbe Applikation betreiben. Dies ermöglicht besonders bei System mit vielen Nutzern, die Last zu verteilen und dem Nutzer so eine bessere Nutzung zu ermöglichen.
+Auch ermöglicht ein Reverse Proxy die Einrichtung mit sogenanntem Load Balancing. Dabei werden Anfragen auf unterschiedliche Backend-Sever verteilt, welche aber die selbe Applikation betreiben. Dies ermöglicht besonders bei System mit vielen Nutzern, die Last zu verteilen und dem Nutzer so eine bessere Nutzung zu ermöglichen.
-Es gibt mehrere Verfahren zur Verteilung von Anfragen. Eine einfache Lösung ist beispielsweise die "Round Robin"-Methode. Dabei wird lediglich eine Warteschlange an freien Backend-Servern abgearbeitet. Effezientere Methoden beinhaltet auch das Einbeziehen von Statistiken wie Antwortzeit und momentane Last von Backend-Servern, zur Verteilung von Anfragen auf die jeweiligen Backend-Server. Probleme entstehen lediglich, wenn die Webapplikation mit Nutzer-Sessions arbeitet. Diese müssen dann auf jedem Backend-Server mit der selben Applikation verfügbar sein. Dies fällt dann aber nicht mehr in den Zuständigkeitsbereich von Reverse Proxys.
+Es gibt mehrere Verfahren zur Verteilung von Anfragen. Eine einfache Lösung ist beispielsweise die "Round Robin"-Methode. Dabei wird lediglich eine Warteschlange an freien Backend-Servern abgearbeitet. Effezientere Methoden beinhaltet auch das Einbeziehen von Statistiken wie Antwortzeit und momentane Last von Backend-Servern, zur Verteilung von Anfragen auf die jeweiligen Backend-Server. Probleme entstehen lediglich, wenn die Webapplikation mit Nutzer-Sessions arbeitet. Diese müssen dann auf jedem Backend-Server mit der selben Applikation verfügbar sein. Dies fällt dann aber nicht mehr in den Zuständigkeitsbereich von Reverse Proxys. (Aivaliotis, 2013)