Autosave

MA-Inhalt.tex

@@ -273,8 +273,23 @@ Zusätzlich besteht ein reduziertes Bedrohungsrisiko bei kompromittierten privat
 Außerdem ist die Angriffsfläche beim Einsatz von Zertifikaten geringer, da kein zusätzlicher Code in das System integriert wird, durch das Zugangsdaten verarbeitet würden.
 Unter Abwägung dieser Vor- und Nachteile werden Zertifikate zur Authentisierung von Benutzern verwendet.
 
+\paragraph{Irgendwas mit Installation:}
+Es soll eine PKI zum Einsatz kommen.
+Die könnte auf dem VPN-Server installiert werden.
+Warum ist das eine blöde Idee und was wäre alternativ möglich?
+Die Installation der PKI auf einem separaten Server.
+Muss dieser im Internet ereichbar sein? Nein? Dann kommt er auch nicht in irgendwelche Netze. Der private Schlüssel der PKI soll geschützt werden.
+
+Wie können öffentliche Daten der PKI öffentlich zugänglich gemacht werden?
+HTTP bietet sich an, kann auch für den Zugang zu Benutzeranleitungen, VPN-Konfiguration, \dots verwendet werden.
+VPN-Benutzer dürfen auf Server im internen Netz zugreifen - Dann ab mit dem Server ins interne Netz.
+
+
+
+\section{Gesamtkonzept des VPN-Dienstes} \label{sct:whole_abstract_concept}
+Die geplante Konfiguration des VPN-Servers und dessen Platzierung im DMZ-Netz der Abteilung Informatik wurde in Kapitel~\ref{sct:vpn_concept} bereits dargelegt.
+
 
-\section{Überblick VPN-Dienst} \label{sct:whole_abstract_concept}
 VPN-Server in DMZ mit VPN-Serverkomponente darauf.
 PKI wird auf separaten Server in internem Netz aufgesetzt.
 (Warum ist das eine gute Idee?)
@@ -282,6 +297,7 @@ Wer aktualisiert die CRL? PKI oder Cronjob? Lösungsabhängig?
 Öffentliche Daten der PKI sind via HTTP abrufbar, VPN-Server ruft die aktuelle CRL via HTTP ab.
 Warum HTTP? Weil öffentliche Daten öffentlich sind, Zertifikate sind signiert.
 
+Abbildung~\ref{fig:vpn_service_concept} zeigt den in diesem Kapitel konzipierten VPN-Dienst im Überblick.
 
 \begin{figure}[ht]
 \centering