Drafting up stuff
This commit is contained in:
parent
85e6f25a53
commit
1aa0fc9b58
|
@ -348,16 +348,59 @@ Vorzüge von OpenVPN und IPsec im Vergleich.
|
|||
Begründung der Auswahl.
|
||||
|
||||
|
||||
\paragraph{Erstellung eines Betriebskonzept}
|
||||
|
||||
\paragraph{Erstellung eines Konzepts für die Benutzerverwaltung}
|
||||
Anforderungen:
|
||||
* Soll möglichst "einfach" sein
|
||||
* Möglichst wenig personenbezogene Daten verarbeiten oder speichern
|
||||
* Zielgruppe des Dienstes sind Beschäftigte und Studenten der Abteilung Informatik (Größenordnung: 20-200 Personen)
|
||||
* Studenten sollen immer für ein (laufendes?) Semester Zugriff erhalten
|
||||
|
||||
Möglichkeiten: User+Passwort oder SSL-Zertifikate
|
||||
|
||||
Zertifikate:
|
||||
* klare Laufzeit
|
||||
* kann nicht erraten werden
|
||||
* Können schlimmstenfalls via CRL gesperrt werden
|
||||
* Verschlüsselung des privaten Schlüssels verhindert Missbrauch bei gestohlenen Daten (Cert+Key)
|
||||
* Einrichtung von Benutzern geschieht durch Signatur eines Zertifikatsantrags
|
||||
* Erfolgreich gestohlenes Zertifikat kann nur für VPN-Dienst genutzt werden
|
||||
|
||||
Benutzer/Passwort:
|
||||
* Bequemlichkeit: Kann über existierende Infrastruktur abgewickelt werden (Hochschulaccount)
|
||||
* Einrichung von Benutzern kann quasi vollautomatisch oder durch eine Whitelist geschehen
|
||||
* Benutzerkonten werden automatisch deaktiviert
|
||||
* Nur Benutzername+Passwort reichen aus, gestohlene Zugangsdaten bedeuten großes Schadenspotential
|
||||
* Zugangsdaten müssen zur Authentisierung an entsprechende Dienste "durchgereicht" werden, daher größere Angriffsfläche
|
||||
|
||||
Gewinner: Zertifikate
|
||||
|
||||
\paragraph{Einrichtung einer SSL-CA mit EasyRSA}
|
||||
EasyRSA2.2.3 aus Debian vs EasyRSA3.x direkt von Github - Vorteile/Nachteile
|
||||
Kurz: EasyRSA2.2.3 aus Debian vs EasyRSA3.x direkt von Github - Vorteile/Nachteile
|
||||
Danach: Wie funktioniert die CA mit EasyRSA?
|
||||
--> Dokumente: Benutzerdokumentation, CA-Admin-Dokumentation, Serverdokumentation
|
||||
|
||||
|
||||
\paragraph{Planung der Umsetzung mit dem IT-Team der Abteilung Informatik}
|
||||
* IP-Adressen und Routing geklärt
|
||||
* Konzepte und Konfiguration des IT-Teams in das Konzept integriert
|
||||
* virtuelle IP als Alias auf Netzwerkkarte, über die der Dienst angestoßen wird
|
||||
* Voraussichtlich separate Maschine zur Verwaltung der CA
|
||||
* Koordination Firewallregeln
|
||||
** Dienst bietet nur OpenVPN udp/1194 (Internetoffen) und SSH tcp/22 (mal gucken, wie offen das ist)
|
||||
** lokale Firewall auf VPN-Server verhindert Zugriffe vom VPN in die DMZ
|
||||
* Koordination Routing
|
||||
** IPv6-Bereich für VPN-Clients wird an virtuelle IPv6-Adresse des VPN-Dienstes geroutet -> manuelles Failover möglich
|
||||
** IPv4: VPN-Clients bekommen IP-Adressen aus 10.2.0.0/16 Block, für IPv4 wird auf NAT zurückgegriffen
|
||||
|
||||
\paragraph{Erstellung eines Betriebskonzept}
|
||||
|
||||
\paragraph{Fazit}
|
||||
Wie ist es gelaufen, gab es Probleme? Wie macht sich OpenVPN als Lösung?
|
||||
Gibt es vielleicht Szenarien, in denen sich IPsec doch lohnt?
|
||||
|
||||
\paragraph{Ausblick}
|
||||
Es gibt da noch etwas mit dem schönen Namen Wireguard. Das könnte ein richtig nettes Ding werden \dots
|
||||
|
||||
\chapter*{Anhang}
|
||||
\addcontentsline{toc}{chapter}{Anhang}
|
||||
|
||||
|
|
Loading…
Reference in New Issue