From 410b54524011401d4ba6aad556156ff838fd81fd Mon Sep 17 00:00:00 2001 From: Jan Philipp Timme Date: Wed, 12 Sep 2018 11:52:41 +0200 Subject: [PATCH] Autosave --- Dokumentation-CA.tex | 3 --- MA-Inhalt.tex | 19 +++++++++++-------- 2 files changed, 11 insertions(+), 11 deletions(-) diff --git a/Dokumentation-CA.tex b/Dokumentation-CA.tex index 57dba27..58c1939 100644 --- a/Dokumentation-CA.tex +++ b/Dokumentation-CA.tex @@ -83,11 +83,8 @@ From man:openvpn: --tls-cert-profile profile OpenVPN will migrate to 'preferred' as default in the future. Please ensure that your keys already comply. - - Wie groß soll der Schlüssel sein? [Welche Kurve?] - Zertifikate nur mit CN oder volles Schema? * Eigentlich egal, keine Vorteile oder Nachteile. Volles Schema => Mehr Informationen darüber, wo der VPN-Dienst angesiedelt ist. Ändert nicht viel. Es spricht nichts gegen den Einsatz des vollen Schemas. diff --git a/MA-Inhalt.tex b/MA-Inhalt.tex index 8714794..675ef89 100644 --- a/MA-Inhalt.tex +++ b/MA-Inhalt.tex @@ -211,6 +211,7 @@ Anforderungen: * 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 +* Für Beschäftigte wurde kein Kriterium genannt, allerdings könnten andere Gültigkeitsdauern erwünscht sein. Möglichkeiten: User+Passwort oder SSL-Zertifikate @@ -226,36 +227,38 @@ 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 +* Nur Benutzername+Passwort reichen aus, gestohlene Zugangsdaten bedeuten großes Schadenspotential für betroffene Benutzer * Zugangsdaten müssen zur Authentisierung an entsprechende Dienste "durchgereicht" werden, daher größere Angriffsfläche Gewinner: Zertifikate +Für Zertifikate wird eine Zertifizierungsstelle benötigt. - -\section{Umsetzung einer Zertifizierungsstelle} +\section{Konzeption und Umsetzung einer Zertifizierungsstelle} OpenSSL ist aufgrund der Abhängigkeit von OpenVPN bereits gegeben. Mit OpenSSL kann man Schlüsselpaare erzeugen, Zertifikatsanträge erzeugen und Zertifikate ausstellen. -Allerdings erfordert das viel Detailwissen und die Verwaltung der ausgestellten Zertifikate ist nicht einfach. -Da wir Zertifikate auch unbrauchbar machen wollen, müssen Revocations ebenfalls möglich sein. +Allerdings erfordert das viel Detailwissen und die Verwaltung der ausgestellten Zertifikate mit puren openssl-Befehlen ist nicht einfach. +Da wir Zertifikate auch unbrauchbar machen wollen, muss es möglich sein Zertifikate zu widerrufen. Eine CRL muss erzeugt werden können, damit diese im OpenVPN-Dienst für die Prüfung der Gültigkeit der Zertifikate verwendet werden kann. Jetzt kann man viel Zeit investieren, die notwendigen Skripte selbst zu schreiben. Allerdings hat OpenVPN bereits eine Abhängigkeit auf die Skriptesammlung EasyRSA, welche exakt für diesen Zweck gebaut wurde. Die von Debian 9 mitgelieferte Version 2.3.x ist schon etwas älter, könnte aber verwendet werden. -Allerdings gibt es auch eine modernere Neuentwicklung in Version 3.0.5, die langfristig vom OpenVPN-Team weiterentwickelt wird und einige Verbesserungen im Vergleich zur alten v2 mitbringt. +Allerdings gibt es auch eine modernere Neuentwicklung in Version 3.0.4(Stand 12.09.2018, siehe github.com/openvpn/easyrsa), die langfristig vom OpenVPN-Team weiterentwickelt wird und einige Verbesserungen im Vergleich zur alten v2 mitbringt. Kurz: EasyRSA2.2.3 aus Debian vs EasyRSA3.x direkt von Github vs irgendwie selbst Skripte schreiben (Wieso das Rad neu erfinden?) - Vorteile/Nachteile Ggf. kurz ein Blick darauf, was alles für Features benötigt werden. -EasyRSAv3 ist eine Neuentwicklung von EasyRSAv2. +EasyRSAv3 ist eine Neuentwicklung von EasyRSA2. Die neue Version wird vom OpenVPN-Team weiter entwickelt werden. Vereinfachte Benutzung der zur Verfügung gestellten Shellskripte Viele Verbesserungen, wie z.B. Unterstützung für ECDSA (Siehe Changelog) oder UTF-8 ist jetzt standard, AES256 wird für die Verschlüsselung des CA-Keys verwendet, \dots -Da für die Anfertigung von Zertifikatsanträgen eine korrekte Konfiguration von OpenSSL benötigt wird und diverse Einstellungen vorgegeben werden sollen, ist es sinnvoll, dass die CA durch das IT-Team auf Basis von EasyRSA v3.0.5 kurz vorbereitet wird und dann als Paket für Benutzer bereitgestellt wird. +Da für die Anfertigung von Zertifikatsanträgen einige Details beachtet werden sollen und diverse Einstellungen durch die Zertifizierungsstelle vorgegeben bzw. vorausgesetzt werden, ist es sinnvoll, dass die CA durch das IT-Team auf Basis von EasyRSA3 kurz vorbereitet wird und dann als Paket für Benutzer bereitgestellt wird. Danach: Wie funktioniert die CA mit EasyRSA? --> Dokumente: Benutzerdokumentation, CA-Admin-Dokumentation, Serverdokumentation +\section{Einrichtung des VPN-Servers} + \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