Skip to content

Data redaction capability in Federator (i.e. data aware) #166

Description

@Co1Mars

Summary: Data redaction capability in Federator (data-aware routing)

Type: Story
Component: Federator
Labels: federation, data-governance, redaction, m2m


Description

The Federator currently treats payloads as opaque during inter-organisational data exchange. To support data governance requirements across the federation, the Federator must become data-aware — capable of inspecting outbound payloads and applying configurable redaction rules before data leaves an organisational boundary. This ensures sensitive fields are never transmitted to nodes that are not authorised to receive them.


Acceptance Criteria

  • Federator can inspect outbound payload content prior to transmission
  • Redaction rules are configurable per data classification or destination node (e.g. field-level, pattern-based)
  • Redacted fields are replaced with a consistent placeholder (e.g. [REDACTED]) — data is not silently dropped
  • Redaction is applied before the payload leaves the source node; no sensitive data transits the network
  • Redaction events are logged with field name, destination node identity, and rule triggered — payload values are never written to logs
  • If a payload cannot be parsed for inspection, the Federator rejects transmission and logs a structured error — it does not fail open
  • Redaction rule configuration is externally managed and does not require a Federator restart to take effect
  • Unit tests cover: full match, partial match, no match, unparseable payload

Technical Notes

  • Redaction pipeline should be implemented as an interceptor/filter in the outbound request chain, keeping it decoupled from routing logic
  • Rule configuration format should support field path expressions (e.g. JSONPath for JSON payloads) and regex patterns for unstructured content
  • Consider a pluggable RedactionStrategy interface to allow future extension (e.g. tokenisation, pseudonymisation) without modifying core logic
  • Rule hot-reload can reuse the file-watch pattern established in the cert reload story if rules are file-backed
  • Structured redaction audit log must be separate from the general application log to facilitate compliance reporting

Out of Scope

  • Inbound payload redaction (source node responsibility)
  • Payload encryption (handled at transport layer via mTLS)
  • UI-based rule management

Dependencies

  • Agreed data classification taxonomy and field-level sensitivity definitions
  • Outbound request pipeline in Federator is sufficiently modular to support interceptor insertion

Definition of Done

  • Redaction applied and verified on outbound payloads in integration test
  • Fail-closed behaviour on unparseable payload confirmed
  • Redaction audit log entries validated (no value leakage)
  • Hot-reload of rules verified without restart
  • PR reviewed and merged

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions