Oracle Label Security With Oracle Database

Oracle Label Security can be used in Oracle Database deployments that need database-side row access control for compartmented, regulated, or multi-level data. In a nats-sinks architecture, it is best understood as an Oracle Database enforcement layer that can complement the classification and security label metadata already carried by the sink framework.

This blueprint is conceptual. It is intended for authorized environments only. It does not define an accredited classification scheme, Oracle Label Security policy, user clearance model, cross-domain guard, release authority, or military data-handling approval process.

Context

nats-sinks already normalizes and persists:

core classification values;
semicolon-compatible labels;
optional structured security_labels metadata;
mission metadata and custody evidence where configured.

Oracle Label Security operates inside Oracle Database. It can enforce row-level visibility by comparing a row's policy label with the labels and authorizations assigned to a database user. That makes it relevant for military and mission-support workloads where one Oracle Database contains records with different handling markings, compartments, releasability rules, or communities of interest.

The same pattern can also help non-military deployments. Examples include regulated personal data, tenant-separated SaaS datasets, merger-and-acquisition workspaces, sensitive commercial programmes, export-controlled engineering records, or internal datasets with multiple confidentiality levels.

Boundary

nats-sinks should not become the Oracle Label Security administrator.

Responsibility	Owner
Define official levels, compartments, groups, and releasability rules	Authorized programme team or data governance authority
Create Oracle Label Security policies and authorize database users	Oracle Database security administrator
Validate incoming event envelopes and preserve labels	`nats-sinks` core
Commit events to Oracle Database and ACK only after durable success	`nats-sinks` Oracle sink
Enforce row visibility after data is stored	Oracle Database with Oracle Label Security
Decide whether a record can cross a release boundary	External guard, review, or authorization process

This separation keeps the sink generic. The framework can preserve trusted metadata and fail closed on invalid input, while Oracle Database enforces database access rules for approved schemas and users.

flowchart LR
    Source[Authorized gateway or application] --> JS[NATS JetStream]
    JS --> Core[nats-sinks core]
    Core --> Labels[Classification and security label validation]
    Labels --> Oracle[Oracle sink commit]
    Oracle --> DB[Oracle Database table]
    DB --> OLS[Oracle Label Security policy]
    OLS --> Readers[Authorized database readers]

Processing Model

Oracle Label Security does not change the delivery contract:

nats-sinks receives a JetStream message.
The core validates the envelope, classification, labels, and optional security label profile.
The Oracle sink executes the configured insert, merge, or staging write.
Oracle Database durably commits the row.
Only after commit success does the runner ACK the JetStream message.

If Oracle Database rejects the write because of a policy, privilege, trigger, row-label, schema, or authorization problem, the sink has not succeeded. The message must be retried, redelivered, or routed through DLQ handling according to the configured policy.

Prefer safe duplication over silent loss. Idempotency keys such as JetStream stream sequence, message ID, or a stable event identifier remain required. Oracle Label Security controls row visibility; it is not a duplicate-detection strategy.

Mapping Pattern

The current Oracle sink persists label information in ordinary columns and JSON metadata:

nats-sinks field	Oracle sink storage
`classification`	`CLASSIFICATION`
`labels`	`LABELS`
`security_labels`	`SECURITY_LABELS_JSON` and `METADATA_JSON.security_labels`
`mission_metadata`	`MISSION_METADATA_JSON`

An Oracle Label Security deployment can use that stored metadata as an input to a deployment-owned mapping layer. Typical options are:

a reviewed database migration that adds a policy label column to the target table;
a database-owned trigger or controlled ingestion view that maps validated labels to an Oracle Label Security policy label;
a staging table where nats-sinks writes raw custody records and a separate approved database process promotes rows into an Oracle Label Security protected table;
a future first-party Oracle sink option for row-label mapping, tracked separately from this blueprint.

Do not assume that the current Oracle sink automatically populates an Oracle Label Security row-label column. It stores the generic metadata needed for an approved database-side mapping pattern.

Synthetic Event Example

This example is fake and unclassified. It illustrates metadata shape only.

{
  "event_id": "SYN-OLS-0001",
  "source_system": "synthetic-event-producer",
  "source_gateway": "synthetic-gateway",
  "event_type": "synthetic.custody.event",
  "event_timestamp": "2026-05-31T10:15:00Z",
  "classification": "NATO SECRET",
  "labels": ["synthetic", "ols-example", "mission-support"],
  "security_labels": {
    "profile": "nats-sinks.security-label.v1",
    "classification": "NATO SECRET",
    "releasability": ["NATO"],
    "handling_caveats": ["MISSION"],
    "owner": "synthetic-owner",
    "originator": "synthetic-originator",
    "policy_id": "synthetic-policy",
    "retention_category": "mission-log-1y",
    "extensions": {
      "ols_mapping_hint": "synthetic-secret-mission"
    }
  },
  "mission_metadata": {
    "profile": "generic-mission-event",
    "profile_version": 1,
    "mission_id": "SYNTHETIC-MISSION",
    "correlation_id": "SYN-CORR-0001"
  },
  "payload": {
    "status": "synthetic",
    "detail": "placeholder only"
  }
}

The ols_mapping_hint value is deliberately a placeholder. Real deployments should define their own approved mapping from normalized security label metadata to Oracle Label Security labels.

Non-Normative Oracle Table Pattern

The following table responsibilities are illustrative only:

Table or column responsibility	Purpose
event identity columns	Store stream, sequence, subject, message ID, and idempotency keys.
payload column	Store normalized payload JSON or an encrypted payload envelope.
`CLASSIFICATION` and `LABELS`	Preserve core normalized handling metadata for search and audit.
`SECURITY_LABELS_JSON`	Preserve the full validated data-centric security label profile.
policy label column	Oracle Label Security policy label managed by the database-side design.
audit table	Record mapping failures, retries, deduplication, and administrative review evidence.

An approved schema might apply Oracle Label Security to the target table and derive its policy label from SECURITY_LABELS_JSON. The exact policy name, label values, user authorizations, and database package calls must be supplied by the deployment authority and database security administrator.

-- Illustrative only. Do not copy into production without an approved
-- Oracle Label Security policy, least-privilege role design, and migration
-- review.
alter table NATS_SINK_EVENTS add (
  OLS_ROW_LABEL varchar2(4000)
);

-- A deployment-owned mapping layer may derive OLS_ROW_LABEL from the
-- validated SECURITY_LABELS_JSON document before or during promotion into
-- an Oracle Label Security protected table.

Operational Considerations

Least privilege: the nats-sinks runtime user should normally insert or merge rows, not administer Oracle Label Security policies.
Policy ownership: policy creation, label vocabulary, compartments, groups, and user authorizations belong to database security administrators.
Validation: use the security label profile allow lists to fail closed before sink writes when labels are missing, malformed, or outside the approved vocabulary.
Idempotency: keep deterministic keys independent from classification and label values.
DLQ: mapping failures that occur before durable write should follow DLQ-before-ACK behavior where DLQ is configured.
Observability: avoid exporting raw classification labels, compartments, groups, or policy hints as broad metrics labels.
Audit: preserve the original security label metadata even when a database-side policy label is derived from it.
Deployment: use containerized by default deployments where practical, isolated defence cloud patterns where applicable, and dedicated secret stores for Oracle, NATS, and integration credentials.

Benefits

Oracle Database can enforce row visibility close to the data.
nats-sinks retains at-least-once commit-then-ACK delivery behavior.
Stored security labels remain auditable even when database policy labels are derived later.
Military and non-military deployments can use the same generic event metadata model.
Database security administration remains separate from event persistence.

Explicit Non-Goals

nats-sinks does not create Oracle Label Security policies.
nats-sinks does not authorize database users for labels.
nats-sinks does not define official classification vocabularies.
nats-sinks does not become a cross-domain guard or release authority.
This blueprint does not provide classified policy content, operational label values, mission data, unit identifiers, payloads, or deployment details.