Lektion 2.7 hat gesagt, dass die Function App func-lieferanten in Azure den Systemschlüssel mcp_extension verlangt, und Lektion 4.1 hat ein Lauf-Token eingeführt, das die Steuerung mit einem Schlüssel aus dem Key Vault signiert. Beides sind Geheimnisse im Betrieb des Teams. Die Lektion fragt: Wo liegen sie, wer liest sie, wie wechseln sie, und was bricht dabei?
Vorwissen. Geheimnisse, Schlüssel und TLS-Objekte, Rollen am Tresor, vorläufiges Löschen und Bereinigungsschutz: „K3, Lektion 3.3.2“. Nie ausgeben: „K3, Lektion 3.3.3“. Signieren im Tresor, Rotationsrichtlinien, Leck-Reihenfolge: „K3, Lektion 3.3.7“. Schlüssellos in Foundry: „AI-103, Lektion 1.4“. Das Lauf-Token und das Tor: Lektion 4.1.
Neu in dieser Lektion. Je Umgebung (M-09) gibt es einen Tresor in rg-ai500-<umgebung>. Er enthält das Geheimnis lieferanten-mcp-key (der Wert des Systemschlüssels mcp_extension) und den Schlüssel lauf-signatur (RSA, 2048 Bit; Annahme). Der Wechsel des Signaturschlüssels ist alle 90 Tage geplant (Annahme).
Die Anforderung
Alle Zahlen sind Annahmen der Aufgabe.
| Nr. | Anforderung | Art | Messgröße | Gewicht | Quelle |
|---|---|---|---|---|---|
| 4.2-01 | Kein Geheimnis in Code, Konfiguration, Prompt oder Spur. | R | 0 Treffer | Muss | R-07 |
| 4.2-02 | Der Schlüssel der Function App liegt nur im Tresor und im Tor. | R | 2 Orte | Muss | 2.7 |
| 4.2-03 | Der private Teil des Signaturschlüssels verlässt den Tresor nie. | R | 0 Exporte | Muss | 4.1-03 |
| 4.2-04 | Ein planmäßiger Wechsel verwirft kein gültiges Lauf-Token. | R | 0 abgewiesene Tokens | Soll | M-02 |
| 4.2-05 | Jeder Verbraucher hat die engste Rolle. | R | 1 Rolle je Verbraucher | Muss | 1.5-01 |