This commit is contained in:
Jan Philipp Timme 2018-11-01 15:07:08 +01:00
parent 6f25ed6443
commit 1798377d05
1 changed files with 21 additions and 7 deletions

View File

@ -273,14 +273,28 @@ 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.
\paragraph{Betriebskonzept für die PKI:}
Die PKI, die zur Ausstellung von Zertifikaten für die VPN-Benutzer und den VPN-Server benutzt werden soll, muss auf einem Computer installiert werden.
Damit die PKI später von den zuständigen Administratoren aus dem IT-Team der Abteilung Informatik bedient werden kann, empfiehlt sich die Einrichtung der PKI auf einem Server, zu dem die Administratoren SSH-Zugang haben.
Da bereits ein Server für den Betrieb der VPN-Serverkomponente verwendet werden soll, liegt der Gedanke nahe, die PKI ebenfalls auf diesem Server zu installieren.
Davon sollte jedoch abgesehen werden, weil die VPN-Serverkomponente über das Internet erreichbar ist, und somit das Risiko besteht, dass ein entfernter, nicht authentisierter Angreifer unter Ausnutzung von Sicherheitslücken in der VPN-Serverkomponente die Kontrolle über den VPN-Server erlangen kann.
In diesem Fall ist die Vertraulichkeit des privaten Schlüssels vom Wurzelzertifikat der PKI gefährdet.
Wird dieser private Schlüssel einem Angreifer bekannt, kann sich der Angreifer beliebige gültige Client- und Serverzertifikate ausstellen, und diese beispielsweise für Man-in-the-Middle-Angriffe verwenden.
Die Vertraulichkeit, die Authentizität und die Integrität des VPN-Dienstes sind ab diesem Zeitpunkt verletzt.
VPN-Clients können nicht mehr darauf vertrauen, dass sie eine Sitzung mit dem VPN-Server der Abteilung Informatik aufgebaut haben.
Ebenso kann der VPN-Server nicht mehr darauf vertrauen, dass VPN-Clients mit gültigem Benutzerzertifikat wirklich im Auftrag legitimer VPN-Benutzer agieren.
Alles in allem stellt dieses Szenario einen Totalschaden dar.
Die einzige Abhilfe ist der vollständige Neuaufbau der PKI.
Um dieses Risiko im Vorfeld zu reduzieren, soll die PKI auf einem Server eingerichtet werden, der nur für diesen Zweck installiert wird.
Dieser Server muss nur von den Administratoren aus dem IT-Team bedient werden können, und bietet keine Dienste an, die über das Internet erreichbar sein müssen.
Eine Platzierung des Servers im Mitarbeiter-Netz der Abteilung Informatik ist deshalb sinnvoll.
Damit die öffentlichen Daten der PKI, wie zum Beispiel ihr Wurzelzertifikat oder ihre \textit{Certificate Revocation List} (CRL), soll ein Webserver auf dem PKI-Server installiert werden, der nur die öffentlichen Daten im Mitarbeiter-Netz der Abteilung Informatik via HTTP zur Verfügung stellt.
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.