ZDDC
6aae181d19
All checks were successful
Deploy content to live site / deploy (push) Successful in 3s
reference.html § 9: rewrite the canonical-folder tree so each line leads
with what the folder is FOR (drafting space, "about to issue" lane,
permanent record per counterparty, planned deliverables list, review
queue) rather than mechanics. The lifecycle stage of a document is now
visible from its location alone. Mechanics (lazy creation, case-fold
matching, virtual user home, paired delete on issue) demoted to a
single trailing paragraph so a reader can grasp the layout without
needing to track them.
federal.html: surface the access-control features that landed since the
page was written —
- Role-based access control as a first-class shipped feature, with the
AC-2 / AC-3(7) mapping called out.
- Verb-based least privilege (r/w/c/d/a) under AC-6, with the rc
shape used by immutable archives flagged explicitly.
- WORM enforcement on archive/<party>/{received,issued}/ under AU-9
and MP-5, including the at-the-WORM-folder grant pattern that lets
doc controllers drop transmittals without giving them overwrite.
- Cascade tracer (/.profile/effective-policy) under AC-3 reviewability.
- OPA wire-format detail (input shape + cache TTL + fail-open).
Move "Role-based access control" out of the "what you'd add for ATO"
table now that it's shipped; replace with "Identity-provider role
sync" — the integrator's job is wiring AD/Okta/EntraID groups into
the existing role members: list, not building RBAC from scratch.
Update "Policy export" to acknowledge the per-path tracer that already
ships and frames the missing piece as the batch-export companion.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
167 lines
19 KiB
HTML
167 lines
19 KiB
HTML
<!DOCTYPE html>
|
|
<html lang="en">
|
|
<head>
|
|
<meta charset="UTF-8">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1.0">
|
|
<title>Federal Compliance — Zero Day Document Control (ZDDC)</title>
|
|
<meta name="description" content="ZDDC is designed to be deployed in regulated environments — including US federal. Here's what's already in place, what we'd add when a customer engages on ATO, and the supported deployment shape.">
|
|
<meta property="og:type" content="website">
|
|
<meta property="og:url" content="https://zddc.varasys.io/federal.html">
|
|
<meta property="og:title" content="Federal Compliance — ZDDC">
|
|
<meta property="og:description" content="Federally-deployable design with a clear ATO path.">
|
|
<meta name="theme-color" content="#2a5a8a">
|
|
<link rel="preconnect" href="https://fonts.googleapis.com">
|
|
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
|
|
<link href="https://fonts.googleapis.com/css2?family=Inter:wght@400;500;600;700;800&display=swap" rel="stylesheet">
|
|
<link rel="stylesheet" href="css/style.css">
|
|
</head>
|
|
<body>
|
|
<!-- Header -->
|
|
<header class="site-header">
|
|
<div class="container header-content">
|
|
<a href="/" class="brand">
|
|
<svg class="brand-logo" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 64 64" aria-hidden="true">
|
|
<rect width="64" height="64" rx="12" fill="#1e3a5f"/>
|
|
<g fill="#fff">
|
|
<rect x="14" y="18" width="36" height="7"/>
|
|
<polygon points="43,25 50,25 21,43 14,43"/>
|
|
<rect x="14" y="43" width="36" height="7"/>
|
|
</g>
|
|
</svg>
|
|
<span class="brand-name">ZDDC</span>
|
|
</a>
|
|
<nav class="header-nav">
|
|
<a href="/" class="nav-link">Home</a>
|
|
<a href="reference.html" class="nav-link">Docs</a>
|
|
<a href="releases/" class="nav-link">Releases</a>
|
|
</nav>
|
|
</div>
|
|
</header>
|
|
|
|
<!-- Hero -->
|
|
<section class="hero">
|
|
<div class="container">
|
|
<h1>Federal Compliance</h1>
|
|
<p class="hero-subtitle">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.</p>
|
|
</div>
|
|
</section>
|
|
|
|
<main class="container" style="margin-bottom: var(--spacing-2xl);">
|
|
|
|
<!-- ────────────── What's already in place ────────────── -->
|
|
<section class="card" style="background: var(--color-bg-subtle); border: 1px solid var(--color-border); border-radius: var(--radius-md); padding: var(--spacing-lg) var(--spacing-xl); margin-top: var(--spacing-lg);">
|
|
<h2 style="margin-top:0;">What's already in place</h2>
|
|
<p>These controls ship in every release today. No federal-specific build required to use them.</p>
|
|
<ul class="feature-list">
|
|
<li><strong>Hardened TLS posture.</strong> The TLS 1.2 cipher suite list, curve preferences, and HSTS header are pinned to the federal TLS guidance (NIST SP 800-52 Rev. 2). Only AEAD ciphers; only forward-secret key exchanges; only modern curves. Weak suites cannot be negotiated even if a client offers them.</li>
|
|
<li><strong>Role-based access control (NIST AC-2 / AC-3).</strong> A <code class="inline">.zddc</code> file declares named roles whose members are email patterns; permissions reference role names rather than pasting the same wildcards across every directory. Role definitions cascade and child files shadow ancestors for that subtree, so federation between an organisation-wide role definition and a project-specific override is built in. Maps cleanly to AC-3(7) "role-based" enforcement and AC-2 account-management workflows.</li>
|
|
<li><strong>Verb-based least privilege (NIST AC-6).</strong> Every access decision evaluates one of five explicit verbs — <code class="inline">r</code> read, <code class="inline">w</code> overwrite, <code class="inline">c</code> create, <code class="inline">d</code> delete, <code class="inline">a</code> admin / edit ACL. A grant of <code class="inline">rc</code> means "this principal can read existing files and create new ones, but cannot modify or delete what's already there" — exactly the permission shape an immutable archive needs. Empty grants (<code class="inline">""</code>) are explicit denies that beat any other grant at the same level.</li>
|
|
<li><strong>Write-once-read-many archive folders (NIST AU-9, MP-5).</strong> Files placed under <code class="inline">archive/<party>/issued/</code> or <code class="inline">archive/<party>/received/</code> are protected by a server-enforced verb mask: ancestor grants are reduced to read-only when crossing the WORM boundary, regardless of what an upstream <code class="inline">.zddc</code> says. A separate <code class="inline">.zddc</code> placed at the WORM folder itself can grant <code class="inline">rc</code> to specific principals (the doc-controller dropping a fresh transmittal) — that survives the mask. Root admins bypass the mask only as the deliberate escape hatch for mis-filed documents, with bypasses visible in the audit log.</li>
|
|
<li><strong>Pluggable policy engine.</strong> Access decisions can be delegated to an external <a href="https://www.openpolicyagent.org/" rel="noopener">Open Policy Agent</a> server with the customer's own audited Rego rules. The server POSTs request user, path, action, and the full <code class="inline">.zddc</code> cascade chain to <code class="inline">/v1/data/zddc/access/allow</code>; the customer's OPA returns allow/deny. Default in-process engine and OPA-delegated engine speak the same wire format, so customers swap by setting one environment variable. Failures fail closed by default; <code class="inline">ZDDC_OPA_FAIL_OPEN=1</code> flips it for the rare case where availability outranks confidentiality.</li>
|
|
<li><strong>Strict-least-privilege policy variant available out of the box.</strong> A parity-tested federal-mode Rego that enforces NIST AC-6 (parent denies are absolute; no leaf-level override) ships embedded in the binary. <code>zddc-server --print-rego=federal</code> emits it for use with the customer's OPA.</li>
|
|
<li><strong>Cascade tracer for reviewers (NIST AC-3 reviewability).</strong> Admins can hit <code class="inline">/.profile/effective-policy?path=<url></code> on a running server to see the resolved ACL chain at any path — every directory's grants, the role evaluation, and the final verb-set returned for the requesting user. A security reviewer can confirm "yes, this person has exactly these rights at this path" without reading the source. Helpful during accreditation and for incident response.</li>
|
|
<li><strong>Structured audit logging.</strong> Every request is logged with the authenticated email, method, path, status, response size, and duration. Logs are JSON-line, ready for fluentd / Vector / SIEM pipelines.</li>
|
|
<li><strong>Documented vulnerability-disclosure process.</strong> A <a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/SECURITY.md">SECURITY.md</a> covering supported versions, reporting channel, response timeline, embargo workflow, and CVE assignment.</li>
|
|
<li><strong>Cascading access control with explicit trust boundaries.</strong> The <code class="inline">.zddc</code> ACL model has documented invariants — root-only admin escalation gate, subtree-author authority limited to their subtree, default-deny when any <code class="inline">.zddc</code> exists. The <a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/zddc/README.md#access-control-the-zddc-cascade">access-control reference</a> includes a five-minute verify-it recipe a security reviewer can run on their own deployment.</li>
|
|
</ul>
|
|
</section>
|
|
|
|
<!-- ────────────── Supported deployment shape ────────────── -->
|
|
<section class="card" style="border: 1px solid var(--color-border); border-radius: var(--radius-md); padding: var(--spacing-lg) var(--spacing-xl); margin-top: var(--spacing-xl);">
|
|
<h2 style="margin-top:0;">Supported deployment shape</h2>
|
|
<p>Federal-track deployments run zddc-server <strong>on loopback only</strong>, 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.</p>
|
|
<pre style="font-family: ui-monospace, SFMono-Regular, monospace; font-size: 0.85rem; background: var(--color-bg); padding: var(--spacing-md); border-radius: var(--radius-sm); overflow-x: auto;">
|
|
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)</pre>
|
|
<p style="margin-top: var(--spacing-md);">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.</p>
|
|
<p>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.</p>
|
|
</section>
|
|
|
|
<!-- ────────────── What you'd add ────────────── -->
|
|
<section class="card" style="border: 1px solid var(--color-border); border-radius: var(--radius-md); padding: var(--spacing-lg) var(--spacing-xl); margin-top: var(--spacing-xl);">
|
|
<h2 style="margin-top:0;">What you'd add for full ATO</h2>
|
|
<p>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 <a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/zddc/README.md#federal-readiness-gap-analysis">federal-readiness gap analysis</a>.</p>
|
|
<table style="width: 100%; border-collapse: collapse; margin-top: var(--spacing-md);">
|
|
<thead>
|
|
<tr style="border-bottom: 2px solid var(--color-border);">
|
|
<th style="text-align: left; padding: var(--spacing-sm); font-weight: 700;">What</th>
|
|
<th style="text-align: left; padding: var(--spacing-sm); font-weight: 700;">Plain-language summary</th>
|
|
</tr>
|
|
</thead>
|
|
<tbody>
|
|
<tr style="border-bottom: 1px solid var(--color-border);">
|
|
<td style="padding: var(--spacing-sm); vertical-align: top;"><strong>FIPS-validated cryptography</strong></td>
|
|
<td style="padding: var(--spacing-sm); vertical-align: top;">A separate <code class="inline">zddc-server-fips</code> 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.</td>
|
|
</tr>
|
|
<tr style="border-bottom: 1px solid var(--color-border);">
|
|
<td style="padding: var(--spacing-sm); vertical-align: top;"><strong>Authenticated proxy↔server channel</strong></td>
|
|
<td style="padding: var(--spacing-sm); vertical-align: top;">Today 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.</td>
|
|
</tr>
|
|
<tr style="border-bottom: 1px solid var(--color-border);">
|
|
<td style="padding: var(--spacing-sm); vertical-align: top;"><strong>Identity-provider role sync</strong></td>
|
|
<td style="padding: var(--spacing-sm); vertical-align: top;">Role-based grants are already in the <code class="inline">.zddc</code> model — see the "Role-based access control" row above. What an integrator adds for federal is a sync layer that populates a role's <code class="inline">members:</code> list from the customer's identity provider (Active Directory groups, Okta, EntraID) on a schedule, so role membership tracks the IdP rather than being maintained by hand. The cascade format already accepts role members; this is the wiring that keeps them in sync.</td>
|
|
</tr>
|
|
<tr style="border-bottom: 1px solid var(--color-border);">
|
|
<td style="padding: var(--spacing-sm); vertical-align: top;"><strong>Policy export for change control</strong></td>
|
|
<td style="padding: var(--spacing-sm); vertical-align: top;">The cascade tracer (<code class="inline">/.profile/effective-policy</code>) already returns a resolved policy for any single path. What's missing is a batch export — a command that walks the entire 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 <code class="inline">.zddc</code> change produces a diff that reviewers approve before deploy. NIST CM-3.</td>
|
|
</tr>
|
|
<tr>
|
|
<td style="padding: var(--spacing-sm); vertical-align: top;"><strong>Code-signed tool fetches</strong></td>
|
|
<td style="padding: var(--spacing-sm); vertical-align: top;">When a <code class="inline">.zddc</code> 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.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</section>
|
|
|
|
<!-- ────────────── The two-track build plan ────────────── -->
|
|
<section class="card" style="border: 1px solid var(--color-border); border-radius: var(--radius-md); padding: var(--spacing-lg) var(--spacing-xl); margin-top: var(--spacing-xl);">
|
|
<h2 style="margin-top:0;">The two-track build plan</h2>
|
|
<p>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.</p>
|
|
<p>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:</p>
|
|
<ul class="feature-list">
|
|
<li>Eliminates the "single static binary" property of the standard build (validated OpenSSL must be present at runtime)</li>
|
|
<li>Ties the deployment to a RHEL/UBI-class OS (validated OpenSSL packages exist there; not on macOS or Windows)</li>
|
|
<li>Gains nothing for the ~95% of customers who don't need a FIPS certificate to procure the system</li>
|
|
</ul>
|
|
<p>So when a federal customer engages, an integrator builds a parallel <code class="inline">zddc-server-fips</code> 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.</p>
|
|
<p>This way every customer gets the deployment shape that fits their environment without paying for ones that don't.</p>
|
|
</section>
|
|
|
|
<!-- ────────────── Where the engineering detail lives ────────────── -->
|
|
<section class="card" style="border: 1px solid var(--color-border); border-radius: var(--radius-md); padding: var(--spacing-lg) var(--spacing-xl); margin-top: var(--spacing-xl);">
|
|
<h2 style="margin-top:0;">Engineering reference</h2>
|
|
<p>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.</p>
|
|
<ul style="line-height: 1.9;">
|
|
<li><a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/zddc/README.md#federal-readiness-gap-analysis">Federal-readiness gap analysis</a> — every NIST control we know is incomplete, with the planned remediation. Per-item subsections cover FIPS, authenticated proxy↔server, policy export, and code-signed app fetches with implementation depth.</li>
|
|
<li><a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/ARCHITECTURE.md">ARCHITECTURE.md § Server security model</a> — commercial-vs-federal trust models side-by-side. Cooperating layers (auth, policy decider, ACL cascade, tool-rooted view, audit log) and what each one's actual job is.</li>
|
|
<li><a href="https://codeberg.org/VARASYS/ZDDC/src/branch/main/zddc/README.md#access-control-the-zddc-cascade">Access-control reference</a> — cascade rules, anti-patterns, worked deployment layouts (third-party-vendor folders, paired open/closed projects), and a five-minute verify-it-works recipe. Useful for the security-review reading too.</li>
|
|
<li><a href="https://codeberg.org/VARASYS/ZDDC">codeberg.org/VARASYS/ZDDC</a> — source code, issue tracker, contribution docs.</li>
|
|
</ul>
|
|
</section>
|
|
|
|
</main>
|
|
|
|
<footer class="site-footer">
|
|
<div class="container footer-content">
|
|
<span>ZDDC is open source — <a href="https://codeberg.org/VARASYS/ZDDC">codeberg.org/VARASYS/ZDDC</a></span>
|
|
</div>
|
|
</footer>
|
|
|
|
<script src="js/layout.js"></script>
|
|
</body>
|
|
</html>
|