Message Queues, Event Streaming and Distributed-System Security — DedSec Project

Event-driven systems move trust through brokers, topics, schemas, consumers, retries, and background workers. Security failures often appear as confused-deputy problems, cross-tenant routing mistakes, replay, or privilege hidden inside automation.

Learning objectives

By the end of this module you should be able to:

• Explain Producer and consumer identity and connect it to a concrete trust boundary or security invariant.
• Explain Topic and routing design and connect it to a concrete trust boundary or security invariant.
• Explain Message authenticity and replay and connect it to a concrete trust boundary or security invariant.
• Explain Schema evolution and connect it to a concrete trust boundary or security invariant.
• Explain Retries and idempotency and connect it to a concrete trust boundary or security invariant.
• Explain Dead-letter queues and connect it to a concrete trust boundary or security invariant.

Deep concepts

1. Producer and consumer identity

Treat every producer and consumer as a principal with explicit topic/queue permissions. Avoid one broad service credential shared by unrelated workloads.

2. Topic and routing design

Names, routing keys, partitions, consumer groups, and dead-letter destinations can carry tenant or sensitivity boundaries. Authorization should not rely solely on a client choosing the “right” topic.

3. Message authenticity and replay

Transport encryption protects links; it does not necessarily prove an old message is fresh or that an authorized producer created it. For high-risk workflows consider identifiers, timestamps, deduplication, signatures/MACs, and idempotency.

4. Schema evolution

Loose schemas can allow security-relevant fields to appear, disappear, or change meaning. Version schemas, validate at trust boundaries, and define safe defaults for unknown fields.

5. Retries and idempotency

At-least-once delivery means a consumer may process the same event more than once. Security-sensitive actions such as payments, account changes, or provisioning need idempotency keys and replay-aware state transitions.

6. Dead-letter queues

Dead-letter storage often contains malformed or sensitive payloads and can become a forgotten data repository. Protect access, define retention, and prevent automated reprocessing from bypassing the original validation path.

7. Background privilege

Workers frequently hold broader permissions than front-end services. Map what each worker can do, what message fields influence that behavior, and whether a less-trusted producer can indirectly invoke privileged operations.

8. Distributed tracing

Correlation IDs, producer identity, consumer identity, schema version, retry count, and outcome make event chains explainable. Observability should support reconstruction without recording unnecessary secrets.

Authorized exercises

Exercise 1 — Model an order-processing pipeline with producer, broker, three consumers, dead-letter queue, and admin replay tool; mark each trust boundary

Model an order-processing pipeline with producer, broker, three consumers, dead-letter queue, and admin replay tool; mark each trust boundary.

Exercise 2 — Write test cases for duplicate delivery, out-of-order delivery, expired messages, malformed schemas, and unauthorized routing using toy data

Write test cases for duplicate delivery, out-of-order delivery, expired messages, malformed schemas, and unauthorized routing using toy data.

Exercise 3 — Design a least-privilege matrix for producers and consumers and identify where one compromised workload would currently have excessive reach

Design a least-privilege matrix for producers and consumers and identify where one compromised workload would currently have excessive reach.

Knowledge checks

1. Explain the most important trust boundary in Message Queues, Event Streaming and Distributed-System Security without naming a security tool.
2. Give one example where cryptographic or authentication success still does not imply authorization success.
3. Describe one stale-state or replay condition relevant to this module.
4. Identify one telemetry source that can support a strong conclusion and one blind spot it still leaves.
5. Explain how you would turn a discovered weakness into a regression test rather than a one-time finding.

Guided study workflow