FS security and compliance posture

@@ -20,18 +20,18 @@ paired_with: service-fs-security-compliance.es.md

Foundry’s security posture is designed to satisfy multiple international regulatory frameworks:

*   **SEC Rule 17a-4(f):** Foundry targets the strict "WORM path," structurally denying record modification. This exceeds the "Audit-Trail" alternative often used by cloud vendors to mask mutable underlying storage.
*   **eIDAS (EU 2025/1946):** Aligns with Qualified Preservation standards by ensuring long-term integrity, authenticity, and accessibility "irrespective of future technological changes."
*   **SOC 2 Trust Services Criteria:** Directly addresses Processing Integrity (PI1, PI4) through signed ingest and read-audit sub-ledgers, and Logical Access (CC6) via tenant-level isolation.
* **SEC Rule 17a-4(f):** Foundry targets the strict "WORM path," structurally denying record modification. This exceeds the "Audit-Trail" alternative often used by cloud vendors to mask mutable underlying storage.
* **eIDAS (EU 2025/1946):** Aligns with Qualified Preservation standards by ensuring long-term integrity, authenticity, and accessibility "irrespective of future technological changes."
* **SOC 2 Trust Services Criteria:** Directly addresses Processing Integrity (PI1, PI4) through signed ingest and read-audit sub-ledgers, and Logical Access (CC6) via tenant-level isolation.

## 2. Security by Construction

The security of `service-fs` is not a policy layer but a fundamental architectural property:

1.  **Structural Immutability:** The Rust API surface and underlying storage engine physically lack the ability to delete or modify records.
2.  **Merkle-Chain Integrity:** Every entry is cryptographically linked to the next. Any attempt to alter history is instantly detectable via consistency proofs.
3.  **External Witnessing:** Monthly anchoring to the Sigstore Rekor public log (Doctrine Invention #7) provides an irrefutable proof-of-state that is independent of Foundry’s internal systems.
4.  **Tenant Isolation:** In the intended seL4 deployment, isolation is enforced by microkernel-level capabilities, making cross-tenant access mathematically impossible.
1. **Structural Immutability:** The Rust API surface and underlying storage engine physically lack the ability to delete or modify records.
2. **Merkle-Chain Integrity:** Every entry is cryptographically linked to the next. Any attempt to alter history is instantly detectable via consistency proofs.
3. **External Witnessing:** Monthly anchoring to the Sigstore Rekor public log (Doctrine Invention #7) provides an irrefutable proof-of-state that is independent of Foundry’s internal systems.
4. **Tenant Isolation:** In the intended seL4 deployment, isolation is enforced by microkernel-level capabilities, making cross-tenant access mathematically impossible.

## 3. Data Archive Retrieval Protocol (DARP)

@@ -40,9 +40,9 @@ In alignment with Doctrine Pillar 1, `service-fs` utilizes a plain-text tile for
## 4. Threat Model Mitigation

Foundry’s posture is intended to defend against high-level institutional risks:
*   **Operator Tampering:** Even an administrator with root access cannot alter the ledger without breaking the Merkle chain and failing public Rekor consistency checks.
*   **Vendor Obsolescence:** Open-standard formats ensure data survival beyond the lifespan of the software vendor.
*   **Cryptographic Agility:** The system is designed to transition to post-quantum signature schemes (e.g., Dilithium) without requiring a full storage migration.
* **Operator Tampering:** Even an administrator with root access cannot alter the ledger without breaking the Merkle chain and failing public Rekor consistency checks.
* **Vendor Obsolescence:** Open-standard formats ensure data survival beyond the lifespan of the software vendor.
* **Cryptographic Agility:** The system is designed to transition to post-quantum signature schemes (e.g., Dilithium) without requiring a full storage migration.

## See also