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}.
|
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:
|
Ressourcen:
|
||||||
* Empfehlungen des BSI\cite{bsi:tr-02102-1}
|
* Empfehlungen des BSI für kryptografische Algorithmen und Schlüssellängen\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 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?
|
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
|
\begin{itemize}
|
||||||
* Voller Name -> Konflikte selten aber möglich, personenbezogene Daten
|
\item Falls es möglich sein soll, Zertifikate bei Missbrauch/Verlust/etc zu sperren, dann braucht man einen eindeutigen Identifier
|
||||||
* E-Mail-Adresse: Eindeutig, aber personenbezogene Daten
|
\item Voller Name: Konflikte selten aber möglich, personenbezogene Daten
|
||||||
* Benutzername/LUH-ID: Eindeutig, kein Konfliktpotential, personenbeziehbar. (Nur "alte" Studenten haben noch Benutzernamen mit Namen drin)
|
\item E-Mail-Adresse: Eindeutig, aber personenbezogene Daten
|
||||||
* Matrikelnummer (bei Studenten): Eindeutig, ggf. hat ein Student mehrere, aber das ist kein Thema. personenbeziehbar. Nachteil: Gibt es für Mitarbeiter nicht.
|
\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?
|
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?
|
Laufzeit für Clientzertifikate individuell oder je nach Zielgruppe?
|
||||||
* Studenten: 6 Monate (immer bis zum Ende des Semesters).
|
Studenten bekommen maximal 6 Monate (immer bis zum Ende des Semesters oder 6 Monate? Kann man ggf. noch anpassen.).
|
||||||
* Mitarbeiter: selbe Laufzeit würde den Prozess vereinfachen. Ansonsten vllt sogar 1-2 Jahre?
|
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?
|
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.
|
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}
|
\section{Einrichtung des VPN-Servers}
|
||||||
|
|
||||||
\paragraph{Planung der Umsetzung mit dem IT-Team der Abteilung Informatik}
|
\paragraph{Planung der Umsetzung mit dem IT-Team der Abteilung Informatik}
|
||||||
* IP-Adressen und Routing geklärt
|
\begin{itemize}
|
||||||
* Konzepte und Konfiguration des IT-Teams in das Konzept integriert
|
\item IP-Adressen und Routing geklärt
|
||||||
* virtuelle IP als Alias auf Netzwerkkarte, über die der Dienst angestoßen wird
|
\item Konzepte und Konfiguration des IT-Teams in das Konzept integriert
|
||||||
* Voraussichtlich separate Maschine zur Verwaltung der CA
|
\item virtuelle IP als Alias auf Netzwerkkarte, über die der Dienst angestoßen wird
|
||||||
* Koordination Firewallregeln
|
\item Voraussichtlich separate Maschine zur Verwaltung der CA
|
||||||
** Dienst bietet nur OpenVPN udp/1194 (Internetoffen) und SSH tcp/22 (mal gucken, wie offen das ist)
|
\item Koordination Firewallregeln
|
||||||
** lokale Firewall auf VPN-Server verhindert Zugriffe vom VPN in die DMZ
|
\begin{itemize}
|
||||||
* Koordination Routing
|
\item Dienst bietet nur OpenVPN udp/1194 (Internetoffen) und SSH tcp/22 (mal gucken, wie offen das ist)
|
||||||
** IPv6-Bereich für VPN-Clients wird an virtuelle IPv6-Adresse des VPN-Dienstes geroutet -> manuelles Failover möglich
|
\item lokale Firewall auf VPN-Server verhindert Zugriffe vom VPN in die DMZ
|
||||||
** IPv4: VPN-Clients bekommen IP-Adressen aus 10.2.0.0/16 Block, für IPv4 wird auf NAT zurückgegriffen
|
\end{itemize}
|
||||||
* Diverse Best-practices/Designpattern übernommen (Konfiguration durch Pakete, SSH-Konfiguration, ...)
|
\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}
|
\section{Erstellung eines Betriebskonzept}
|
||||||
Installation/Installationsanleitung
|
\todo{Installation/Installationsanleitung: Separates Dokument}
|
||||||
Konfiguration
|
Konfiguration
|
||||||
Inbetriebnahme
|
Inbetriebnahme
|
||||||
notwendige (regelmäßige) Wartungsarbeiten
|
notwendige (regelmäßige) Wartungsarbeiten
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue