Compartmented Programs and Classified Levels — enforced at the storage layer
Multiple Special Access Programs and multiple classification levels share physical infrastructure without sharing exposure. BrickStor enforces SAP compartmentation, MLS, and MCS natively — no separate enclave per program, no separate cluster per classification level, no trusting the application layer to do the storage's job.
Three ways programs handle compartmentation today.
All three have a structural ceiling.
Pattern 1
Separate enclave per program
Every SAP, every compartmented program, every classification level gets its own physical infrastructure. Separation is enforced — but the cost, the rack space, the patch burden, and the staffing model scale linearly with the number of programs. A program office running six SAPs and three classification levels stands up eighteen environments instead of one.
Pattern 2
Shared storage with ACL hygiene
One NAS, with directory ACLs and Active Directory groups carrying the burden of program separation. This works until a group membership is changed wrong, an admin escalates by accident, or an auditor asks you to prove that a user cleared for Program A cannot see Program B data. ACLs are not designed for compartmentation; they are designed for convenience.
Pattern 3
A separate storage cluster per classification level
Unclassified, Secret, and Top Secret each get their own NAS, with one-way guards or data diodes moving data between them. Separation is enforced by the cluster boundary — but every cross-level workflow becomes a replication pipeline to maintain, every label change becomes a coordination problem across clusters, and the operational footprint grows linearly with the number of levels.
Compartmentation, MLS, and MCS where they actually belong
The storage layer is the last line of defense and the first place the policy has to be true. BrickStor enforces program isolation, classification levels, and category sets natively — evaluated on every operation, by the platform itself.
The compartment lives where the data lives.
BrickStor evaluates SAP affiliation, clearance, and classification on every file operation — inline, in the data path. The protection does not depend on a separate cluster boundary, an inline guard, or the application above doing its job. The storage itself is the policy enforcement point.
One platform. Many programs. No leakage.
Multiple SAPs, multiple classification levels, and multiple category sets coexist on the same physical BrickStor cluster. Cryptographic isolation, ABAC policy, and immutable audit keep them separated — without standing up an enclave per program.
Levels and categories are first-class.
Classification level, handling caveats, releasability markings, and category memberships are evaluated on every read and write. Bell–LaPadula and category-set logic happen inside the storage — not in a separate gateway or replication pipeline that has to be trusted, certified, and patched alongside it.
The storage system is the policy enforcement point
- Compartmentation is enforced at the storage layer, not at a cluster boundary or by the application — every read and write is evaluated against program affiliation, clearance, and policy by BrickStor itself.
- Multi-Level Security and Multi-Category Security are native — classification labels and category sets are first-class data attributes, not metadata bolted on by an external classifier.
- Multiple SAPs share the same physical hardware while remaining cryptographically and policy-isolated from one another — one hardware footprint, many compartmented programs.
- Hub Central provides administrative visibility across the fleet without granting administrators access to compartmented data — admin separation enforced by the platform.
- Audit is per-program, immutable, and tamper-evident — every decision logged with full context, exportable to the SSP and accreditation evidence package.
- No bolt-on guards, diodes, or filters in the data path — fewer moving parts, fewer accreditation boundaries, and no policy gap when an inline gateway is down or being patched.
Run multiple programs on one platform
Compartmentation enforced by the storage — not by the building, the cluster boundary, or the trust assumed of an admin who happens to be read into multiple programs.
Multiple SAPs on shared infrastructure
Run several Special Access Programs on the same BrickStor cluster with policy-enforced isolation between programs. Reduce hardware footprint, accreditation cost, and operational sprawl without compromising compartmentation.
Read-on-need across compartments
When mission requires it, ABAC policy can grant a specific user controlled visibility into a specific dataset across compartments — with full audit, no permanent membership change, and automatic expiration.
Program startup and sundown
Stand up a new SAP by writing a policy, not by provisioning a new environment. Sundown a program by revoking the policy and producing the audit record — not by decommissioning hardware.
Administrative separation
Storage administrators can manage capacity, replication, and platform health without being read into the programs whose data lives on the platform. Hub Central enforces the boundary.
Levels and categories, native to the storage
Classification level, handling caveats, and category memberships are first-class data attributes — evaluated on every operation, not delegated to a separate enforcement layer.
Multiple classification levels on one cluster
Unclassified, CUI, Secret, and Top Secret datasets coexist on the same BrickStor platform with classification labels enforced by the storage. No separate clusters per level.
Multi-Category Security (MCS)
Classification categories — handling caveats, compartments, and sub-program sets — are enforced alongside the level. Users with the right clearance and the right category memberships see exactly what they are authorized to see.
Read-down and write-up rules
Bell–LaPadula-style read-down and write-up controls are evaluated by BrickStor on every operation — preserving classification integrity without requiring the application to be MLS-aware.
Cross-classification workflows with audit
Where programs require controlled cross-classification movement (downgrade reviews, sanitized exports), every transition is logged with the policy that authorized it, the user who triggered it, and the data's before-and-after state.
Compartmentation and MLS are storage problems.
BrickStor solves them at the storage layer.
Trusting an enclave boundary, an Active Directory group, or a separate-cluster-per-level architecture to enforce program isolation and classification policy is a structural compromise. BrickStor moves the enforcement to where the data lives.
Compartmentation without an enclave per program
Most government storage environments end up with one enclave per SAP because the storage itself cannot enforce program isolation. BrickStor can. Fewer environments to fund, patch, accredit, and operate — without lowering the bar on compartmentation.
MLS where it actually belongs
Trusting a guard, a data diode, or a separate-cluster-per-level architecture to do all the classification work is a structural compromise — the storage is the last line of defense and the first place the labels stop being enforced when something fails. BrickStor moves enforcement to where the data lives.
Admin separation by construction
Storage administrators can manage the platform without being read into the programs hosted on it. Hub Central provides operational telemetry without exposing compartmented data, and every administrative action is captured in the same immutable audit stream.
Continuous accreditation evidence
Every ABAC decision, every classification check, every cross-compartment access is logged immutably and exportable. The evidence accreditors actually ask for is produced as a byproduct of how BrickStor operates — not assembled by hand at audit time.
The same architecture, applied to other federal mission challenges
Mission Partner Environments →
Coalition data sharing on shared infrastructure with dynamic, policy-driven access.
BrickStor CSfC DAR →
NSA CSfC-validated classified data at rest, deployable across borders and platforms.
Federal & Defense Overview →
The full set of mission areas RackTop supports across DoW (formerly DoD) and federal civilian.
Compartmentation, MLS, and MCS — answered
- Yes. ABAC policy and cryptographic isolation enforce program-level separation at the storage layer. Multiple SAPs can run on one BrickStor platform with their data, audit streams, and administrative boundaries kept distinct — without standing up a separate enclave per program.
- Yes. Classification level is a first-class data attribute, evaluated on every file operation. Read-down and write-up rules are enforced by the storage itself, not delegated to a guard between domains or to a separate cluster per level.
- Yes. Category sets — handling caveats, compartments, sub-program memberships, releasability markings — are enforced alongside the classification level on every operation. Users see exactly what their clearance and category memberships authorize.
- The separate-cluster-per-level pattern enforces separation by the cluster boundary and uses one-way guards or data diodes to move data between levels. It works, but every cross-level workflow becomes a replication pipeline, the operational footprint grows linearly with the number of levels, and label management has to be coordinated across clusters by hand. BrickStor enforces classification natively on one platform, so multiple levels coexist with policy-driven access — no replication pipeline, no parallel operational stack per level.
- Yes. Hub Central provides operational telemetry — capacity, replication health, performance — without granting administrators read access to the data on the platform. Every administrative action is captured in the same immutable audit stream as user access decisions.
- MPE focuses on coalition-partner data sharing — different nations, different release authorities, on shared infrastructure. SAP and MLS/MCS focus on program compartmentation and classification-level separation inside U.S. environments. The underlying technology is the same — ABAC and storage-layer enforcement — applied to different policy frameworks.
Run More Programs on Less Hardware — Without Lowering the Bar
Talk to a RackTop federal mission engineer about your specific compartmentation or MLS/MCS architecture, and see the storage-layer enforcement in action.