Lektion 3.3.6 hat die Werkzeuge erklärt, diese Lektion kümmert sich um ihr Leben im Betrieb. Ein Schlüssel wird erzeugt, benutzt, ersetzt und irgendwann ausgemustert, und an jeder dieser Stellen kann etwas schiefgehen: Er liegt an der falschen Stelle, er läuft unbemerkt ab, ein Wechsel macht alle Links ungültig, oder nach einem Leck weiß niemand, was zuerst zu tun ist. Am Ende dieser Lektion signiert die Kladde Daten im Tresor, ohne den privaten Schlüssel je zu sehen, ihr Linkschlüssel lässt sich wechseln, ohne dass ein verschickter Link kaputtgeht, und ein Alarm meldet sich, bevor etwas im Tresor abläuft.
Neu in dieser Lektion:
| Paket | Version | wofür |
|---|---|---|
Azure.Security.KeyVault.Keys |
4.10.2 | Schlüssel im Tresor anlegen, rotieren und mit ihnen signieren (KeyClient, CryptographyClient) |
Drei Arten von Objekten, drei Lebensläufe
Lektion 3.3.2 hat die drei Arten von Objekten im Key Vault genannt. Für den Betrieb unterscheiden sie sich vor allem darin, was die App bekommt und wer den Wechsel erledigt:
| Objekt | Was die App bekommt | Wer wechselt | Bei der Kladde |
|---|---|---|---|
| Geheimnis (secret) | den Wert selbst | Sie: eine neue Version schreiben, die App neu starten | der Linkschlüssel Booking--LinkKey |
| Schlüssel (key) | nie den privaten Teil, nur Ergebnisse (eine Signatur) und den öffentlichen Teil | Key Vault selbst, nach einer Richtlinie | der Signaturschlüssel für Exporte (Übung 1) |
| TLS-Material (certificate) | nichts; Container Apps oder Front Door holen es | Key Vault erneuert es, bei einer angebundenen Stelle oder selbst ausgestellt | nur, wenn kein verwalteter Ausweis passt |
Daraus folgt die erste Regel: Was die App nicht im Klartext braucht, bekommt sie nicht im Klartext. Ein HMAC-Schlüssel muss als Wert in die App, denn HMAC rechnet die App selbst. Ein Signaturschlüssel muss es nicht: Der Tresor kann selbst signieren.