Restructure MA, improve readability of resulting pdf in the process
This commit is contained in:
parent
c22ea29632
commit
56612e7d45
@ -274,8 +274,8 @@ Weil RSA immer noch funktioniert und in naher Zukunft nicht geknackt werden wird
|
||||
Das BSI hat in seinen technischen Richtlinien keine Bedenken gegen den Einsatz von RSA in Szenarien, die über 2023 hinausgehen\cite[][Kapitel 3.5, Absatz \enquote{Schlüssellänge} (S.38)]{bsi:tr-02102-1}.
|
||||
|
||||
Ressourcen:
|
||||
* Empfehlungen des BSI\cite{bsi:tr-02102-1}
|
||||
* Empfehlungen des BSI bezüglich IPsec\cite{bsi:tr-02102-3}
|
||||
* Empfehlungen des BSI für kryptografische Algorithmen und Schlüssellängen\cite{bsi:tr-02102-1}
|
||||
* Empfehlungen des BSI für kryptografische Algorithmen und Schlüssellängen bezüglich IPsec\cite{bsi:tr-02102-3}
|
||||
|
||||
|
||||
|
||||
@ -290,43 +290,60 @@ Volles Schema => Mehr Informationen darüber, wo der VPN-Dienst angesiedelt ist.
|
||||
|
||||
|
||||
Welche Angaben werden für Benutzerzertifikate übernommen? Namen? Benutzerkennungen?
|
||||
-> Falls es möglich sein soll, Zertifikate bei Missbrauch/Verlust/etc zu sperren, dann braucht man einen eindeutigen Identifier
|
||||
* Voller Name -> Konflikte selten aber möglich, personenbezogene Daten
|
||||
* E-Mail-Adresse: Eindeutig, aber personenbezogene Daten
|
||||
* Benutzername/LUH-ID: Eindeutig, kein Konfliktpotential, personenbeziehbar. (Nur "alte" Studenten haben noch Benutzernamen mit Namen drin)
|
||||
* Matrikelnummer (bei Studenten): Eindeutig, ggf. hat ein Student mehrere, aber das ist kein Thema. personenbeziehbar. Nachteil: Gibt es für Mitarbeiter nicht.
|
||||
\begin{itemize}
|
||||
\item Falls es möglich sein soll, Zertifikate bei Missbrauch/Verlust/etc zu sperren, dann braucht man einen eindeutigen Identifier
|
||||
\item Voller Name: Konflikte selten aber möglich, personenbezogene Daten
|
||||
\item E-Mail-Adresse: Eindeutig, aber personenbezogene Daten
|
||||
\item Benutzername/LUH-ID: Eindeutig, kein Konfliktpotential, personenbeziehbar. (Nur "alte" Studenten haben noch Benutzernamen mit Namen drin)
|
||||
\item Matrikelnummer (bei Studenten): Eindeutig, ggf. hat ein Student mehrere, aber das ist kein Thema. personenbeziehbar. Nachteil: Gibt es für Mitarbeiter nicht.
|
||||
\end{itemize}
|
||||
Benutzername wäre eine eindeutige Angabe, ist garantiert eindeutig.
|
||||
Gleichzeitig kann man argumentieren, dass diese häufig pseudonym sind und die Zuordnung von Benutzername zu Person nicht immer trivial ist.
|
||||
Datenschutzrechtlich sollte das gerade so okay sein.
|
||||
|
||||
Wie begründe ich eine empfohlene maximale Laufzeit für ausgestellte Zertifikate von 2 Jahren?
|
||||
|
||||
Laufzeit für Serverzertifikate?
|
||||
* 10 Jahre ist etwas viel. Vielleicht 1 oder 2 Jahre?
|
||||
Die vollen 10 Jahre sind zu viel.
|
||||
Es ist eine gute Idee, nach maximal 2 Jahren neue Zertifikate auszustellen.
|
||||
Tut auch nicht weh. Neu ausstellen, Dienst neustarten, fertig.
|
||||
|
||||
Laufzeit für Clientzertifikate individuell oder je nach Zielgruppe?
|
||||
* Studenten: 6 Monate (immer bis zum Ende des Semesters).
|
||||
* Mitarbeiter: selbe Laufzeit würde den Prozess vereinfachen. Ansonsten vllt sogar 1-2 Jahre?
|
||||
Studenten bekommen maximal 6 Monate (immer bis zum Ende des Semesters oder 6 Monate? Kann man ggf. noch anpassen.).
|
||||
Mitarbeiter mit der selben Laufzeit zu versorgen würde den Prozess vereinfachen.
|
||||
Begründete Ausnahmefälle mit einer Laufzeit von maximal 2 Jahren sollte okay sein.
|
||||
|
||||
Laufzeit der CA - sinnvolle Werte?
|
||||
10 Jahre ist akzeptabel. Wenn man die Laufzeit bestehender Zertifikate im Auge behält, kann der Wechsel einer CA zu einem Stichtag hin funktionieren.
|
||||
Von der CA ausgestellte Zertifikate können nicht länger gültig sein als das Wurzelzertifikat der CA selbst.
|
||||
|
||||
Gültigkeitsdauer der CRL - falls Zertifikate überhaupt zurückgezogen werden sollen: maximal 180 Tage, kann ja vorher jederzeit aktualisiert werden (->Cronjob oder so)
|
||||
Gültigkeitsdauer der CRL - falls Zertifikate überhaupt zurückgezogen werden sollen: maximal 180 Tage, kann ja vorher jederzeit aktualisiert werden (Cronjob oder so)
|
||||
|
||||
|
||||
\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
|
||||
* 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
|
||||
* Diverse Best-practices/Designpattern übernommen (Konfiguration durch Pakete, SSH-Konfiguration, ...)
|
||||
\begin{itemize}
|
||||
\item IP-Adressen und Routing geklärt
|
||||
\item Konzepte und Konfiguration des IT-Teams in das Konzept integriert
|
||||
\item virtuelle IP als Alias auf Netzwerkkarte, über die der Dienst angestoßen wird
|
||||
\item Voraussichtlich separate Maschine zur Verwaltung der CA
|
||||
\item Koordination Firewallregeln
|
||||
\begin{itemize}
|
||||
\item Dienst bietet nur OpenVPN udp/1194 (Internetoffen) und SSH tcp/22 (mal gucken, wie offen das ist)
|
||||
\item lokale Firewall auf VPN-Server verhindert Zugriffe vom VPN in die DMZ
|
||||
\end{itemize}
|
||||
\item Koordination Routing
|
||||
\begin{itemize}
|
||||
\item IPv6-Bereich für VPN-Clients wird an virtuelle IPv6-Adresse des VPN-Dienstes geroutet: manuelles Failover möglich
|
||||
\item IPv4: VPN-Clients bekommen IP-Adressen aus 10.2.0.0/16 Block, für IPv4 wird auf NAT zurückgegriffen
|
||||
\end{itemize}
|
||||
\item Diverse Best-practices/Designpattern übernommen (Konfiguration durch Pakete, SSH-Konfiguration, ...)
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\section{Erstellung eines Betriebskonzept}
|
||||
Installation/Installationsanleitung
|
||||
\todo{Installation/Installationsanleitung: Separates Dokument}
|
||||
Konfiguration
|
||||
Inbetriebnahme
|
||||
notwendige (regelmäßige) Wartungsarbeiten
|
||||
@ -344,4 +361,4 @@ In großen Umgebungen eines Konzerns kann die Situation schon etwas anders ausse
|
||||
|
||||
\section{Ausblick}
|
||||
Es gibt da noch etwas mit dem schönen Namen Wireguard. Mit gewollt geringer Komplexität und einem aktuellen Umfang von ca. 4000 Zeilen Code ist es eine würdige Alternative zu IPsec.
|
||||
Auch OpenVPN in Version 3 ist schon in der Beta - das könnte man auch im Auge behalten.
|
||||
Auch OpenVPN in Version 3 ist schon in der Beta - das könnte man auch im Auge behalten.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user