Explain why certificates are better than pure credentials
This commit is contained in:
parent
0a2e4b55ae
commit
ff3d601fb5
@ -307,19 +307,23 @@ Die involvierten Programme erhöhen die Menge des Quellcodes, der aufgrund seine
|
||||
Da die Abwesenheit von Schwachstellen in Quellcode nicht garantiert werden kann, ergibt sich der Verwendung von Zugangsdaten zur Benutzerauthentisierung ein erhöhtes Bedrohungsrisiko.
|
||||
|
||||
\paragraph{Authentisierung mit Zertifikaten}
|
||||
Die Authentisierung von Benutzern anhand von Zertifikaten erfordert den Aufbau und die Verwaltung einer \textit{Public-Key-Infrastructure} (PKI) und bringt somit erst einmal eine Reihe Nachteile mit sich:
|
||||
Für die Benutzer ergibt sich ein zusätzlicher Aufwand durch das regelmäßige Beantragen von neuen Zertifikaten, sowie die Notwendigkeit der Anpassung der OpenVPN-Clientkonfiguration.
|
||||
Auch für den Systemadministrator ergibt sich dieser zusätzliche Aufwand in Bezug auf die regelmäßige Erneuerung des Serverzertifikats und der \textit{Certificate Revocation List} (CRL).
|
||||
Zusätzlich ist der Systemadministrator mit der Betreuung der Zertifizierungsstelle (CA) beschäftigt, nimmt die Zertifikatsanträge der Benutzer entgegen, prüft diese und stellt Benutzerzertifikate aus.
|
||||
Der daraus resultierende Aufwand erhöhts sich proportional zu der Anzahl der VPN-Benutzer.
|
||||
|
||||
\begin{itemize}
|
||||
\item klare Laufzeit
|
||||
\item kann nicht erraten werden
|
||||
\item Können schlimmstenfalls via CRL gesperrt werden
|
||||
\item Verschlüsselung des privaten Schlüssels verhindert Missbrauch bei gestohlenen Daten (Cert+Key)
|
||||
\item Einrichtung von Benutzern geschieht durch Signatur eines Zertifikatsantrags
|
||||
\item Erfolgreich gestohlenes Zertifikat kann nur für VPN-Dienst genutzt werden
|
||||
\end{itemize}
|
||||
Dennoch gibt es eine Reihe von Vorteilen, die diesen zusätzlichen Aufwand rechtfertigen:
|
||||
Zertifikate haben eine klar definierte Laufzeit, die bei Ausstellung des Zertifikates festgelegt wird.
|
||||
Aufgrund der Länge der verwendeten Schlüssel ist es mit herkömmlichen Brute-Force-Angriffen nicht in für Angreifer akzeptabler Zeit möglich, diese zu erraten.
|
||||
Auch das Stehlen von privaten Schlüsseln kann einem Angreifer weniger attraktiv gemacht werden, wenn man den privaten Schlüssel nur in verschlüsselter Form ablegt.
|
||||
Sollte ein privater Schlüssel dennoch kompromittiert werden, besteht jederzeit die Möglichkeit, diesen durch eine Ergänzung der CRL von der CA unbrauchbar zu machen.
|
||||
Zusätzlich gilt, dass ein kompromittierter Schlüssel lediglich zur Benutzung des VPN-Dienst berechtigt.
|
||||
Dadurch reduziert sich der potentielle Schaden, den ein Angreifer mit einem kompromittierten Schlüssel anrichten könnte.
|
||||
|
||||
|
||||
Gewinner: Zertifikate
|
||||
Für Zertifikate wird eine Zertifizierungsstelle benötigt.
|
||||
Insgesamt bringt die Authentisierung von Benutzern mit Zertifikaten im Vergleich zur Authentisierung auf Basis von Zugangsdaten einen höheren Arbeitsaufwand mit sich.
|
||||
Dafür besteht ein reduziertes Bedrohungsrisiko bei kompromittierten privaten Schlüsseln als im Vergleich zu kompromittierten Zugangsdaten, welche gegebenenfalls für weitere Dienste gültig sein können.
|
||||
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.
|
||||
|
||||
|
||||
\section{Konzeption und Umsetzung einer Zertifizierungsstelle}
|
||||
|
Loading…
Reference in New Issue
Block a user