Tutorial 3: Enterprise Data and Service Boundaries
Unit 6 ยท Enterprise security architecture
Objectives
Define ownership and contracts between services.
Control data propagation and privilege across boundaries.
Handle dependency and consistency failures.
A service boundary should clarify data ownership, API contract, identity, authorization, validation, and failure behavior. Copying sensitive data into many services increases exposure and deletion complexity. Prefer purpose-limited views, tokenized references, and explicit retention.
service A -[scoped identity + contract]-> service B
service B owns data and policy; A receives minimum representation
Distributed transactions are difficult; use idempotency, compensating actions, durable events, and clear consistency expectations. Do not let a convenience integration bypass authorization or audit.
Exercises
Draw ownership for customer data across three services.
Design a scoped service-to-service token.
Describe failure when a downstream service is unavailable.
Self-check
Why minimize data propagation?
What is idempotency?
Who owns a resource policy?
Self-Check Quiz
1. What should a service contract specify?
AnswerInputs, outputs, identity, authorization expectations, errors, consistency, and security constraints.
2. What does idempotency help prevent?
AnswerDuplicate effects when a request is retried after an uncertain or timed-out response.
Homework
Design secure boundaries for an HR integration.
Specify data minimization, identity, audit, and failure behavior.
Write a threat for duplicated or stale data.
Sample answerThe HR system remains owner of employee identity; downstream services receive only necessary attributes through a scoped identity and versioned contract. Updates are authenticated, authorized, audited, idempotent, and retried with limits. Stale data has an explicit expiry and reconciliation process.