Dynamic, Context-Aware Access Control for Every File Share
Static permissions were designed for a world that no longer exists. BrickStor's native ABAC evaluates every file operation against dynamic policy — user, device, classification, network, time, context — across every product in the line.
Why static permissions fail
ACLs assume the world is static. A user is in a group, the group has rights, the rights apply forever. That model worked when users sat at one desk, on one network, with one role, accessing one kind of data.
It does not work for: coalition operations, multi-program environments, classified data with dissemination caveats, contractors who join and leave, devices whose security posture changes hour to hour, federated identity across partners, time-bounded exercises, or anything where access has to depend on context.
The gap between what static permissions can express and what real environments require is where the workarounds accumulate — manual ACL gymnastics, bolt-on middleware, custom scripts, separate storage silos. Each workaround adds complexity, cost, and risk. ABAC closes the gap by making access decisions dynamic. Every operation is evaluated against a policy that considers attributes of the user, the resource, the environment, and the action — in real time, on every read and write.
How BrickStor's ABAC works
Inline evaluation
Every SMB, NFS, and S3 operation is evaluated against the ABAC policy before the response is served. There is no path to the data that bypasses the engine.
Attributes from your identity infrastructure
BrickStor consumes user attributes from Active Directory, LDAP, and other identity sources. Nationality, clearance, program affiliation, role, and any custom attribute your organization maintains.
Resource attributes on the data
Files and directories carry classification, dissemination markings (NOFORN, REL TO FVEY), program tags, and any other attribute the policy needs to evaluate.
Environmental context
Network enclave, device posture, time of day, operational phase, geolocation when relevant.
Policy expressed by security officers, not just developers
The ABAC policy model is designed to be readable and writable by the people who own the access requirements — not buried in code only the original author understands.
Every decision logged immutably
Allow or deny, every operation, with the user, attributes, resource, action, decision, and the policy rule that applied. Exportable for accreditation and compliance.
What ABAC evaluates
User identity & attributes
Who the user is, what organization they belong to, what roles they hold
Nationality & coalition membership
Which partner nation, which information-sharing agreement applies
Clearance & classification
The user's clearance level versus the data's classification marking
Program affiliation
Which SAP, SCI, or mission program the user is authorized for
Network enclave
Which network segment or enclave the request originates from
Data classification & handling caveats
RELTO, NOFORN, REL TO FVEY, and other dissemination markings on the data itself
What ABAC enables
Multi-program isolation on the same NAS
SAPs and compartmented programs without separate storage infrastructure.
Learn more →MLS/MCS-style separation at the storage layer
Multi-level and multi-category secure storage enforced by the storage system itself.
Learn more →Time-bounded exercise access
Access that opens and closes on schedule without manual ACL intervention.
Need-to-know enforcement
Based on real attributes, not just group membership.
Context-aware data loss prevention
At the storage layer rather than as a separate product.
Continuous compliance evidence
For accreditors and auditors — every decision logged immutably.
ABAC across the BrickStor product line
ABAC ships in every BrickStor product. All managed from Hub Central, so a single ABAC policy framework spans your entire BrickStor estate from enterprise to tactical edge.
BrickStor SP
Cyberstorage NAS with ABAC plus Active Defense, IBR, ImmutaVault, and TDM
BrickStor SP for Lustre
Parallel file system performance with ABAC for AI/HPC
BrickStor HDR
High-speed sensor recording with ABAC for shared collection infrastructure
BrickStor CSfC DAR
Classified storage and recording with ABAC for coalition use
Why ABAC at the storage layer matters
ABAC implemented above the storage — in middleware, a data guard, or an application layer — leaves the storage itself accessible to anyone who can reach it directly or who compromises the layer above. ABAC at the storage layer closes that gap. The system that holds the data also enforces the policy on the data.
For accreditors, this is the difference between a risk acceptance and a clean authorization.
Built by people who lived the problem
RackTop's founders spent two decades in the U.S. Intelligence Community wishing this capability existed. BrickStor's ABAC was designed by people who understand how clearances, caveats, and compartments actually work in practice — not just in theory. The audit trail was designed to produce the evidence that accreditors actually ask for. The policy model was designed to be expressible by a security officer, not just a developer.
About RackTop's founders →FAQ
- RBAC and ACLs are static role/group assignments. ABAC evaluates context dynamically on every operation — who is asking, what they're asking for, from where, on what device, at what time, with what clearance, in what program.
- No. It consumes attributes from Active Directory, LDAP, and other sources to make storage-layer decisions. It does not replace the identity provider.
- SMB, NFS, and S3 — every protocol BrickStor serves. There is no path to the data that bypasses the ABAC engine.
- Yes, immutably, with full context on every operation — user, attributes, resource, action, decision, and the policy rule that applied. Exportable for accreditation and compliance.
- Yes — SP, SP for Lustre, HDR, and CSfC DAR. All managed from Hub Central with a single ABAC policy framework.
- Yes. Data classification and dissemination markings (RELTO, NOFORN, REL TO FVEY, etc.) can be expressed as data attributes in the ABAC policy. Access decisions are made dynamically based on the user's nationality and clearance versus the data's markings.
- Yes. Time-of-day constraints, exercise windows, and operational phases can be expressed as conditions in the ABAC policy. Access opens and closes on schedule without manual intervention.
See ABAC in action
Request a demo and see BrickStor's ABAC evaluate dynamic policy on live file operations — including coalition scenarios, SAP isolation, and NOFORN enforcement.