Add LDAP Distinguished Name Helper and Credential Audit Context

- Implemented LdapDistinguishedNameHelper for escaping RDN and filter values. - Created AuthorityCredentialAuditContext and IAuthorityCredentialAuditContextAccessor for managing credential audit context. - Developed StandardCredentialAuditLogger with tests for success, failure, and lockout events. - Introduced AuthorityAuditSink for persisting audit records with structured logging. - Added CryptoPro related classes for certificate resolution and signing operations.
2025-11-09 12:21:38 +02:00
parent ba4c935182
commit 75c2bcafce
385 changed files with 7354 additions and 7344 deletions
--- a/docs/security/authority-threat-model.md
+++ b/docs/security/authority-threat-model.md
@@ -87,7 +87,7 @@ flowchart LR
 | Token replay by stolen agent | Information Disclosure | TB5 | Med×High | Signed revocation bundles, device fingerprint heuristics, optional mTLS | Monitor revocation acknowledgement latency via Zastava and tune replay alerting thresholds | Security Guild + Zastava (follow-up: **SEC5.E**) |
 | Privilege escalation via plug-in override | Elevation of Privilege | TB3 — Plug-in sandbox | Med×High | Signed plug-ins, restart-only loading, configuration validation | Add static analysis on manifest overrides + runtime warning when policy weaker than host | Security Guild + DevOps (follow-up: **SEC5.F**) |
 | Offline bundle tampering | Tampering | Distribution | Low×High | SHA256 manifest, signed bundles (planned) | Add supply-chain attestation for Offline Kit, publish verification CLI in docs | Security Guild + Ops (follow-up: **SEC5.G**) |
-| Failure to log denied tokens | Repudiation | TB2 — Authority ↔️ Mongo | Med×Med | Serilog structured events (partial), Mongo persistence path (planned) | Finalise audit schema (SEC2.A) and ensure `/token` denies include subject/client/IP fields | Security Guild + Authority Core (follow-up: **SEC5.H**) |
+| Failure to log denied tokens | Repudiation | TB2 — Authority ↔️ Mongo | Med×Med | Serilog structured events (partial), Mongo persistence path (planned), Standard plug-in credential telemetry (`authority.plugin.standard.password_verification`) | Finalise audit schema (SEC2.A), require the same audit contract for third-party plug-ins, and ensure `/token` denies include subject/client/IP fields | Security Guild + Authority Core (follow-up: **SEC5.H**) |

 Risk scoring uses qualitative scale (Low/Med/High) for likelihood × impact; mitigation priority follows High > Med > Low.

@@ -95,6 +95,7 @@ Risk scoring uses qualitative scale (Low/Med/High) for likelihood × impact; mit

 | Backlog ID | Linked Threat | Summary | Target Owners |
 |------------|---------------|---------|---------------|
+| SEC5.PLG | TB3 — Plug-in sandbox | Standard plug-in mitigations documented: Argon2 bootstrap enforcement, password-policy warnings, and credential audit telemetry (`plugin.retry_after_seconds`, `plugin.lockout_until`) wired into SOC pipelines. | Security Guild + BE-Auth Plugin |
 | SEC5.B | Spoofed revocation bundle | Complete libsodium/Core signing integration and ship revocation verification script. | Security Guild + Authority Core |
 | SEC5.C | Parameter tampering on `/token` | Finalise audit contract (`SEC2.A`) and add request tamper logging. | Security Guild + Authority Core |
 | SEC5.D | Bootstrap invite replay | Implement expiry enforcement + audit coverage for unused bootstrap invites. | Security Guild |
@@ -104,3 +105,9 @@ Risk scoring uses qualitative scale (Low/Med/High) for likelihood × impact; mit
 | SEC5.H | Failure to log denied tokens | Ensure audit persistence for all `/token` denials with correlation IDs. | Security Guild + Authority Core |

 Update `src/__Libraries/StellaOps.Cryptography/TASKS.md` (Security Guild board) with the above backlog entries to satisfy SEC5.A exit criteria.
+
+### 5.1 Plugin telemetry status (SEC5.PLG — 2025-11-09)
+
+- Standard plug-in password verification now emits `authority.plugin.standard.password_verification` with caller correlation IDs, client metadata, tenant IDs, and full network context sourced from `AuthorityCredentialAuditContext`. Events classify outcomes via the extended `AuthEventOutcome` set (`LockedOut`, `RequiresFreshAuth`, `RequiresMfa`) so SOC tooling can distinguish lockouts from MFA prompts.
+- Audit properties were standardised: `plugin.failed_attempts`, `plugin.lockout_until`, `plugin.retry_after_seconds`, `plugin.rehashed`, and `plugin.failure_code` are present on both the plug-in event and the host-level `/token` record. `plugin.retry_after_seconds` is derived deterministically from the retry window, ensuring consistent rate-limit responses for air-gapped tenants.
+- Bootstrap mitigations were documented in `docs/dev/31_AUTHORITY_PLUGIN_DEVELOPER_GUIDE.md`: Argon2id hashing, enforced password policies, default `RequirePasswordReset`, and registrar warnings when an operator weakens the baseline policy. These measures close the SEC5.PLG action item and provide auditors with evidence hooks for Offline Kit reviews.
--- a/docs/security/crypto-routing-audit-2025-11-07.md
+++ b/docs/security/crypto-routing-audit-2025-11-07.md
@@ -29,34 +29,49 @@
 All hosts can now express provider ordering and profile overrides via configuration:

 ```yaml
-Crypto:
-  registry:
-    preferredProviders:
-      - default
-      - ru.pkcs11
-    activeProfile: ru-offline
-    profiles:
-      ru-offline:
-        preferredProviders:
-          - ru.cryptopro.csp
-          - ru.pkcs11
-  pkcs11:
-    keys:
-      - keyId: ru-slot-token
-        libraryPath: /usr/local/lib/librutokenecp.so
-        slotId: "0x1"
-        privateKeyLabel: signing-key
-        certificateThumbprint: "<thumbprint>"
-  cryptopro:
-    keys:
-      - keyId: ru-csp-token
-        libraryPath: /opt/cprocsp/lib/libcapi20.so
-        containerLabel: KRYPTO_PRO_KEY
-        certificateThumbprint: "<thumbprint>"
+StellaOps:
+  Crypto:
+    Registry:
+      PreferredProviders:
+        - default
+        - ru.pkcs11
+      ActiveProfile: ru-offline
+      Profiles:
+        ru-offline:
+          PreferredProviders:
+            - ru.cryptopro.csp
+            - ru.pkcs11
+    Pkcs11:
+      Keys:
+        - KeyId: ru-slot-token
+          LibraryPath: /usr/local/lib/librutokenecp.so
+          SlotId: "0x1"
+          PrivateKeyLabel: signing-key
+          CertificateThumbprint: "<thumbprint>"
+    CryptoPro:
+      Keys:
+        - KeyId: ru-csp-token
+          ProviderName: "Crypto-Pro GOST R 34.10-2012 Cryptographic Service Provider"
+          CertificateThumbprint: "<thumbprint>"
+          CertificateStoreLocation: LocalMachine
+          CertificateStoreName: My
 ```

+Call `builder.Services.AddStellaOpsCryptoRu(builder.Configuration)` to bind this configuration and register the RU providers with the correct preferred order.
+
 Each deployment picks a profile (`activeProfile`) that resolves to a deterministic provider order, and individual services call into `ICryptoProviderRegistry` rather than new-ing crypto stacks directly.

+### Known gaps (2025-11-09)
+
+Even after the initial plug-ins landed, several sovereign-crypto deliverables remain outstanding. These items must be addressed before RootPack_RU can be treated as GA:
+
+1. **CryptoPro CSP integration** – `StellaOps.Cryptography.Plugin.CryptoPro` currently reuses the PKCS#11 core and never talks to CryptoPro CSP / GostCryptography. Replace it with a real CSP-backed signer, including certificate-store lookup and DER/raw normalization.
+2. **Ops CLI** – The promised `StellaOps.CryptoRu.Cli` (list keys, try-sign, emit determinism records) has not been implemented; operators are blind when staging PKCS#11/CryptoPro keys.
+3. **Integration tests** – There are zero CryptoPro/PKCS#11 tests in `src/__Libraries/__Tests/StellaOps.Cryptography.Tests/`. The RootPack validation script cannot validate hardware paths today.
+4. **Symmetric GOST** – Magma/Kuznyechik (RFC 5830 / RFC 7801) support is missing, so RU deployments cannot request sovereign symmetric encryption for exports/data-at-rest.
+5. **Host adoption** – Authority, Scanner, Concelier, etc. register only the default providers; none call the RU DI helpers or set `ActiveProfile = ru-offline`, leaving sovereign bundles inert.
+6. **Docs/runbooks** – RootPack docs reference the CLI/config/test harnesses, but they do not yet exist; we need explicit TODOs (see rootpack docs) and follow-up edits once tooling ships.
+
 ## Inspecting providers from the CLI

 `stellaops crypto providers` now lists the registered providers, signing algorithms, certificate metadata, and the current preferred order. Use `--json` for machine-readable output or `--profile <name>` to preview another profile (e.g., `ru-offline`) before flipping configuration.
--- a/docs/security/rootpack_ru_package.md
+++ b/docs/security/rootpack_ru_package.md
@@ -66,3 +66,13 @@ Store these artifacts under `logs/rootpack_ru_<timestamp>/` (same directory as t
 2. Apply `config/rootpack_ru.crypto.yaml`, update certificate thumbprints, slots, and container labels to match the operator tokens.
 3. Restart the services so `ICryptoProviderRegistry` reloads the `ru-offline` profile.
 4. Re-run the validation runbook to confirm JWKS, telemetry, and RootPack evidence are aligned with the shipping bundle.
+
+## Known gaps (2025-11-09)
+
+The bundle and scripts above assume several pieces of functionality that have not landed yet:
+
+- **Ops CLI:** The CLI referenced in the validation runbook (list/verify keys, emit determinism records) has not been implemented. Operators currently rely on manual pkcs11-tool / certmgr commands.
+- **Integration tests:** `scripts/crypto/run-rootpack-ru-tests.sh` exercises only SHA/Ed25519 paths because CryptoPro/PKCS#11 integration tests are still TODO.
+- **Symmetric GOST:** RootPack artifacts ship only signing plug-ins; Magma/Kuznyechik support for exports/data-at-rest is pending.
+
+These gaps are being tracked in Sprint 514 (SEC-CRYPTO backlog). This guide will be updated once the missing work is delivered.
--- a/docs/security/rootpack_ru_validation.md
+++ b/docs/security/rootpack_ru_validation.md
@@ -11,6 +11,7 @@ This runbook documents the repeatable steps for validating the Russian sovereign
   - `src/Scanner/__Tests/StellaOps.Scanner.Worker.Tests/StellaOps.Scanner.Worker.Tests.csproj`
   - `src/Scanner/__Tests/StellaOps.Scanner.Sbomer.BuildXPlugin.Tests/StellaOps.Scanner.Sbomer.BuildXPlugin.Tests.csproj`
   and emits `.log` + `.trx` pairs plus `README.tests` under `logs/rootpack_ru_<timestamp>/`.
+   > **Note:** CryptoPro/PKCS#11 integration suites have not landed yet; the harness currently covers only default SHA/Ed25519 paths. Hardware validation (sections 2–3) is still manual until those tests exist.
 2. For ad-hoc runs (CI or IDE) ensure the same three projects succeed; the cryptography tests validate SHA-256/SHA-512 against BCL implementations and both Streebog variants against BouncyCastle digests.
 3. Archive the generated log directory (`logs/rootpack_ru_<timestamp>/`) along with any additional test outputs inside the RootPack evidence bundle.

@@ -43,3 +44,11 @@ Create a metadata bundle per validation run and store it under `logs/rootpack_ru
 Attach this directory to the RootPack artifact and reference it from the release checklist.

 Refer back to `docs/security/crypto-routing-audit-2025-11-07.md` for the full inventory of components that must consume the shared cryptography stack, and `docs/security/rootpack_ru_package.md` for packaging/attachment steps.
+
+## Known gaps (2025-11-09)
+
+- The `stellaops crypto providers ...` CLI referenced above is still pending implementation—operators must capture PKCS#11 slot info manually.
+- No automated CryptoPro/PKCS#11 integration tests exist; sovereign hardware validation relies on manual signing runs.
+- Symmetric GOST (Magma/Kuznyechik) validation is not covered yet.
+
+These items are tracked in Sprint 514 and will be reflected in this runbook once the corresponding tooling lands.