AWS Client VPN: Welche CA sollte Client-Zertifikate ausstellen?
Eine bestehende CA, ein selbst betriebener Aussteller und AWS Private CA verteilen die Arbeit unterschiedlich. Legen Sie fest, wer Client-Zertifikate genehmigt, erneuert und widerruft, bevor Sie starten.
Die Zertifikatsfrage bei AWS Client VPN wird als Produktfrage gestellt, und sie ist wirklich eine Betriebsfrage. Jede der drei üblichen Varianten betreibt einen funktionierenden Tunnel: eine bestehende organisatorische CA, ein dedizierter selbst betriebener Aussteller oder AWS Private CA. Sie unterscheiden sich darin, wer ein Gerät genehmigt, wer den Signaturschlüssel hält und wer antwortet, wenn ein Laptop zu einer ungünstigen Stunde verschwindet. Wählen Sie die Option, deren Verantwortlichen Sie benennen können.
AWS verlangt für die Zertifikatsauthentifizierung keine Private CA. Ein Server-Zertifikat in ACM abzulegen ist ein Bereitstellungsschritt, kein Registrierungsprozess.
Die drei Bedingungen, die es entscheiden
Drei Bedingungen trennen die Optionen sauber: ob bereits ein genehmigter Geräteregistrierungsprozess existiert, ob Sie einen Signaturschlüssel mit Backups und einem benannten Verantwortlichen betreiben können und wie ein Widerruf den Endpunkt erreicht. Jede ist nahe an einem Ja oder Nein, und das erste Nein entscheidet meist die Architektur.
Arbeiten Sie sie der Reihe nach ab. Der direkte Sprung zum Kostenvergleich führt dazu, dass Teams mit einer verwalteten CA dastehen und niemand weiß, wer das nächste Laptop-Zertifikat ausstellt.
| Option | You still own | Fits when |
|---|---|---|
| Existing organizational CA | Enrollment, approvals, revocation list | A device process already exists |
| Self-run issuer | Signing-key custody, backups, revocation list | You can staff key custody |
| AWS Private CA | Policy, permissions, certificate delivery | Your PKI already lives in AWS |
Bedingung eins: Gibt es bereits eine Registrierung?
Wenn Ihre Organisation bereits eine CA mit einem genehmigten Geräteregistrierungspfad betreibt, ist die Ausstellung der Client-Zertifikate für Client VPN daraus der kürzeste Weg. Die Genehmigungen, der Prozess und die Asset-Datensätze sind bereits vorhanden. Ein dedizierter untergeordneter Aussteller unter dieser Hierarchie ist meist besser als die allgemeine ausstellende CA, weil er der VPN eine eigene Vertrauensgrenze und eine eigene Widerrufsliste gibt. Halten Sie diese Liste vom Rest der Hierarchie getrennt, damit ein VPN-Vorfall keine PKI-weite Änderung erzwingt.
Existiert kein solcher Prozess, ist die eigentliche Frage, ob Sie einen aufbauen wollen. Eine CA ist leicht zu starten und teuer, wenn man sie schlecht betreibt.
Bedingung zwei: Können Sie einen Signaturschlüssel betreiben?
Ein selbst betriebener Aussteller funktioniert mit dem dokumentierten Importmodell, und EasyRSA oder ein kleines internes Werkzeug kann das Material erzeugen. Den Befehl auszuführen ist nicht der schwierige Teil. Schwierig sind Offline-Backups des Signaturschlüssels, ein Wiederherstellungspfad, den jemand tatsächlich getestet hat, ein Verantwortlicher, der nicht im Urlaub ist, und eine Regel, dass der Schlüssel nie in einem Client-Bundle oder einem Konfigurationsexport landet. Schreiben Sie das als Verfahren auf, bevor das erste Zertifikat ausgestellt wird, nicht nach dem ersten Vorfall.
AWS Private CA verlagert diese Verwahrung in einen verwalteten Dienst. Es verlagert nicht die Registrierungsrichtlinie, den Genehmigungsschritt oder die Zustellung des Zertifikats an das Gerät.
Bedingung drei: Wie kommt der Widerruf an?
Client VPN nutzt eine Sperrliste für Client-Zertifikate, die Sie in den Endpunkt importieren, wie im Leitfaden zum Zertifikatslebenszyklus beschrieben. Eine CRL anderswo in Ihrer PKI zu veröffentlichen schiebt sie nicht in den Dienst. Der Import ist ein separater, geplanter Vorgang, und eine abgelaufene Liste stoppt Verbindungen, statt still schlechter zu werden. Legen Sie die Erneuerung auf denselben Kalender wie die Zertifikate selbst.
Damit wird die Erneuerung zu einem Überwachungspunkt mit Verantwortlichem, nicht zu einer Aufgabe, die beim Start erledigt ist. Widerrufen Sie ein Testzertifikat von Anfang bis Ende, bevor Sie den Mechanismus wirklich brauchen.
Was keine der Optionen beseitigt
Jede Option braucht weiterhin ein eigenes Client-Zertifikat und einen eigenen Schlüssel pro unabhängig verwaltetem Gerät. Eine Anleitung, die allen eine einzige Identität austeilt, ist eine Abkürzung in der Anleitung und macht einen gezielten Widerruf unmöglich.
Importierte Server-Zertifikate in ACM haben keine verwaltete Erneuerung, also muss der Verantwortliche den Ersatz beschaffen, ihn erneut importieren und dann bestätigen, dass der Endpunkt ihn übernommen hat. Das Server-Zertifikat zu erneuern erneuert nicht die Client-Anmeldedaten, die bereits auf Laptops liegen. Das sind getrennte Lebenszyklen mit getrennten Kalendern.
Prüfen Sie die Schlüsseltypen und Erweiterungen, die der Dienst akzeptiert, bevor Sie etwas ausstellen. Dass eine CA einen Algorithmus unterstützt, heißt nicht, dass der Endpunkt ihn akzeptiert.
Führen Sie vor dem Start eine Erneuerung und eine Client-Entfernung durch den gewählten Ablauf durch und notieren Sie, welche Anmeldedaten sich geändert haben, welche Endpunkt-Einstellung sich geändert hat und was mit der aktiven Sitzung passiert ist. Endet diese Übung ohne klaren Verantwortlichen, ist die Wahl des Ausstellers nicht abgeschlossen.