Partner-HSM-Zugriff über ein VPN: die Schlüsseloperationen definieren

Irgendjemand beim Partner muss ein Dokument mit einem bestimmten Schlüssel signieren, und die Anfrage kommt als Netzwerkfrage formuliert: Sie müssen das HSM erreichen. Behandeln Sie diesen Satz als Symptom eines undefinierten Dienstleistungsvertrags und nicht als Routingproblem, denn ein Tunnel, der das Gerät erreicht, gewährt für sich genommen nichts. Hinter der Anfrage stehen drei Tore: Erreichbarkeit, HSM-Identität und Schlüsselrichtlinie, und jedes wird an einer anderen Stelle von einem anderen Team verwaltet. Schreiben Sie sie eines nach dem anderen auf, sonst vergeben Sie am Ende eine Route, weil das Zertifikatsgespräch schwieriger war.

Halten Sie den konkreten Fall im Blick: Der Partner reicht ein genehmigtes Dokument zur Signatur mit einem benannten Schlüssel ein, und sonst nichts. Alles Folgende ergibt sich aus diesem einen Satz.

Erreichbarkeit, Identität und Schlüsselrichtlinie sind drei Tore

Der VPN-Konzentrator entscheidet, wer einen Tunnel öffnen darf und welche Adressen er berühren darf. Das HSM entscheidet selbst, welcher ihm vorgelegte Benutzerdatensatz sich anmelden darf. Die Schlüsselrichtlinie entscheidet dann, was dieser Datensatz mit einem bestimmten Schlüssel tun darf. Das Passieren des ersten Tors lässt die anderen beiden genau so, wie sie waren, weshalb ein erfolgreicher Handshake so wenig beweist und weshalb ein Partner das Gerät erreichen und trotzdem an jeder Operation scheitern kann.

Ordnen Sie jedes Tor einem Verantwortlichen zu, bevor Sie Anforderungen schreiben. Wenn niemand das zweite besitzt, besteht das übliche Ergebnis darin, eine breite HSM-Administratoridentität auszugeben, weil sie die einzige funktionierende Zugangsberechtigung ist.

Tor eins: der Netzwerkpfad, den der Partner erhält

Benennen Sie den genehmigten Client oder Dienst, das Ziel, das er braucht, und das Protokoll und den Port, auf denen dieser Dienst lauscht. Beschränken Sie dann den Zugriff auf der VPN-Seite auf dieses Paar in beiden Richtungen, einschließlich des Rückwegs, damit die Richtlinie ein Satz ist, den Sie dem Partner vorlesen können. Gateway-Verwaltung, HSM-Managementschnittstellen und nicht zugehörige interne Systeme sollten außerhalb des gewöhnlichen Partnerzugriffs liegen, nicht nur außerhalb der Standardroute.

Ein eigenes Segment macht diese Übergänge sichtbar, aber der Name eines Segments erzwingt nichts. Der Verkehr muss durch die Kontrolle laufen, von der Sie glauben, dass er sie durchläuft. Eine Verbindung vom Partner zuzulassen ist auch keine Aussage, dass jeder Rechner beim Partner vertrauenswürdig ist.

Tor zwei: was sich tatsächlich beim HSM authentifiziert

Eine VPN-Identität und eine HSM-Identität sind getrennte Objekte, sofern eine unterstützte Integration sie nicht bewusst verbindet. Bei einem PKCS#11-Client führt die Anwendung eine Anmeldung an einem Slot mit einer irgendwo auf dem Host des Partners gespeicherten Zugangsberechtigung durch, und genau diese Anmeldung bewertet das HSM.

AWS CloudHSM ist eine nützliche Referenz, weil seine Dokumentation beides auseinanderhält: HSM-Benutzer sind von IAM-Benutzern zu unterscheiden, und der Benutzertyp bestimmt, was das Konto tun darf. Ein Crypto Officer verwaltet Benutzer und Schlüssel, ist aber nicht die Identität, die kryptografische Operationen ausführt, während ein Crypto User Schlüssel nutzen kann, ohne sie verwalten zu können. Diese Trennung ist die Form, die Sie auch auf dem Gerät eines anderen Herstellers wollen, wo die Rollennamen anders lauten.

Welche Identität Sie auch ausgeben, sie muss mit der Granularität entfernbar und zuordenbar sein, die Sie später brauchen. Eine gemeinsame Betriebsberechtigung über mehrere Partner hinweg macht Eindämmung und Rechenschaft gerade in dem Vorfall schwerer, in dem beides am wichtigsten ist.

Tor drei: welcher Schlüssel und welche Operation

Signieren, Entschlüsseln, Schlüsselerzeugung, Schlüsselverpackung und Benutzerverwaltung sind getrennte Berechtigungen und müssen getrennt aufgeführt werden. In PKCS#11-Begriffen beschreiben Attribute wie CKA_SENSITIVE und CKA_EXTRACTABLE, ob Schlüsselmaterial das Modul in nutzbarer Form verlassen kann, und sie werden pro Schlüssel statt pro Gerät gesetzt. Lesen Sie die tatsächliche Richtlinie am Schlüssel, statt die Nicht-Exportierbarkeit aus dem Wort Hardware oder aus dem Vorhandensein eines Tunnels abzuleiten.

Finden Sie dann die Geschäftsgenehmigung. Wenn nur genehmigte Dokumente signiert werden dürfen, welche Komponente stellt diese Genehmigung fest, bevor die Anfrage das HSM erreicht? Eine kryptografische Schnittstelle, die eine autorisierte Anfrage annimmt, weiß nicht, ob das Dokument geprüft wurde, also gehört diese Prüfung zum Dienst davor.

Ein zulässiger Client, der kompromittiert ist, kann die Operationen, die seine Zugangsberechtigung rechtmäßig autorisiert, auch missbrauchen, ohne je einen privaten Schlüssel zu extrahieren. Gespeichertes Schlüsselmaterial zu schützen und die Schlüsselnutzung zu kontrollieren, sind daher zwei Abnahmebedingungen, nicht eine.

Ablehnungen gehören zum Abnahmetest

Akzeptieren Sie die zulässige Signaturanfrage und akzeptieren Sie auch die Ablehnungen: eine nicht autorisierte Identität, einen nicht zugehörigen Schlüssel und eine Verwaltungsoperation aus dem Pfad des Partners. Zeichnen Sie Aufrufer, Operation, Schlüsselkennung, Zeitpunkt und Ergebnis auf und halten Sie privates Schlüsselmaterial, Zugangsberechtigungen und Dokumentinhalte aus allgemeinen Diagnoseprotokollen heraus.

Bestimmen Sie einen Verantwortlichen für das Offboarding des Partners, für einen vermuteten Kompromiss auf Partnerseite sowie für Richtlinienänderungen und Wiederherstellung. Eine Route zu ändern stellt das Vertrauen in einen Host nicht wieder her, der möglicherweise bereits kompromittiert ist, daher muss der Widerruf auch die HSM-Identität erreichen.

Ein abgeschlossener VPN-Handshake gehört in diesen Nachweis. Er kann ein einzelnes HSM-spezifisches Ergebnis nicht ersetzen.