diff --git a/federal.html b/federal.html new file mode 100644 index 0000000..e078620 --- /dev/null +++ b/federal.html @@ -0,0 +1,163 @@ + + + + + + Federal Compliance — Zero Day Document Control (ZDDC) + + + + + + + + + + + + + +
+
+ + + ZDDC + + +
+
+ + +
+
+

Federal Compliance

+

ZDDC is designed to be deployed in regulated environments — including US federal. The system's trust boundaries, configuration model, and audit surface were chosen with ATO in mind. This page walks through what's already in place, what an integrator would add when a customer engages on accreditation, and the supported deployment shape.

+
+
+ +
+ + +
+

What's already in place

+

These controls ship in every release today. No federal-specific build required to use them.

+ +
+ + +
+

Supported deployment shape

+

Federal-track deployments run zddc-server on loopback only, fronted by a TLS-terminating proxy. The proxy handles authentication (PIV/CAC via the customer's IdP), terminates TLS using a FIPS-validated module, and forwards plaintext to zddc-server over the local interface. zddc-server stays small, lean, and focused on file-tree access decisions; the proxy is where federal-mandated cryptographic boundaries live.

+
+   PIV/CAC user
+        │
+        ▼
+   ┌──────────────────────┐         (FIPS-validated TLS termination,
+   │  oauth2-proxy /      │          OCSP stapling, MFA, session mgmt)
+   │  nginx-FIPS /        │
+   │  stunnel-FIPS        │
+   └──────────────────────┘
+        │  loopback (HTTP, mTLS or signed JWT)
+        ▼
+   ┌──────────────────────┐         (Per-directory ACL via .zddc;
+   │     zddc-server      │          OPA-delegated for AC-6 strict;
+   │  on 127.0.0.1:8080   │          structured access log to stdout)
+   └──────────────────────┘
+        │
+        ▼
+   /srv/zddc  (RHEL/UBI volume, encrypted at rest by the platform)
+

The base image for the federal track is RHEL UBI 9 or equivalent (Rocky 9, Ubuntu Pro 22.04+) with the OS-level FIPS mode enforced kernel-side. Encryption at rest is delegated to the deployment platform (cloud KMS, LUKS, dm-crypt). Audit logs ship from the proxy and zddc-server's stdout to the customer's SIEM via the orchestrator's normal log pipeline.

+

This isn't a new architecture — it's the standard "small focused service behind a hardened proxy" shape that DoD reference designs already prefer. zddc-server's job is to be the small focused service.

+
+ + +
+

What you'd add for full ATO

+

None of these are forever-open questions; each is a roadmap-able piece of work that an integrator builds when a customer engages on accreditation. Engineering detail for each item lives in the federal-readiness gap analysis.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
WhatPlain-language summary
FIPS-validated cryptographyA separate zddc-server-fips binary built with Microsoft's FIPS-aware Go toolchain on a RHEL/UBI base. The validated cryptography belongs to the OS-level OpenSSL FIPS module; this binary uses it. See the two-track build plan below.
Authenticated proxy↔server channelToday the proxy and zddc-server trust each other via network isolation. For federal, the recommended path is a signed forwarding token (JWT) — proxy signs each request with its private key, zddc-server verifies with the published public key. mTLS available as an alternative when the customer already operates a private CA.
Role-based access controlThe current .zddc model grants access by email pattern. Federal AC-3(7) wants role-based grants populated from the customer's identity provider. The cascade syntax extends to express role allow/deny alongside email allow/deny; roles flow through the same OPA hook so customers running their own Rego pick them up automatically.
Policy export for change controlA command that walks the served tree and emits every directory's resolved access policy in JSON / Markdown / CSV. The change-control workflow checks the export into a Git repo; every .zddc change produces a diff that reviewers approve before deploy. NIST CM-3.
Code-signed tool fetchesWhen a .zddc file pins a tool to a URL, zddc-server today fetches and caches it with no integrity check. The federal answer is code signing: the release pipeline signs every published artifact once with a long-lived key; zddc-server verifies signatures before caching. The operator trusts a published public key once and never deals with hashes — no per-artifact tracking burden.
+
+ + +
+

The two-track build plan

+

Federal evaluators sometimes ask a perfectly reasonable question: "Does the standard zddc-server binary use FIPS-validated cryptography?" The answer is no, and that's by design.

+

FIPS validation is a property of the cryptographic module — typically the OS-level OpenSSL FIPS package shipped by Red Hat or Canonical, certified by NIST and tracked by certificate number. Building with the Microsoft FIPS-aware Go toolchain is what lets a Go program use that validated module instead of Go's stdlib crypto. But it requires linking against the host's OpenSSL, which:

+ +

So when a federal customer engages, an integrator builds a parallel zddc-server-fips binary using the FIPS toolchain and ships it alongside the standard one. linux-amd64 only, RHEL/UBI base, validated OpenSSL on the host. Federal customers download the FIPS variant; everyone else downloads the lean pure-Go binary. The application code is identical between tracks — only the toolchain and the host OS configuration differ.

+

This way every customer gets the deployment shape that fits their environment without paying for ones that don't.

+
+ + +
+

Engineering reference

+

For implementors picking up federal-track work, the in-repo references include effort estimates, design trade-offs, library choices, and pointers to the existing code that each piece would build on.

+ +
+ +
+ + + + + + diff --git a/index.html b/index.html index d9637ce..52d4a14 100644 --- a/index.html +++ b/index.html @@ -177,6 +177,7 @@