Multi-Tenant Elastic Security Architecture

Security architect and engineer · 2026

I designed the ingestion and access model using Kafka, Logstash, Elastic and more than one tenant identifier.

Context

Each client needed access only to its own data while the service provider required authorized visibility across the managed environment.

Problem

Many client environments shared the same private subnets, so source IP alone could not reliably identify ownership or enforce correct data routing.

Approach

Assign each client a dedicated Kafka listener, enrich events through asset-based identity, route through Logstash to the correct tenant index, and quarantine events that cannot be classified safely.

Ingestion model

Client telemetryDedicated Kafka listenerLogstash: tenant + asset identityValidated client index

Unresolved ownership → quarantine → SOC administrator review.

Implementation

Clients forward events to provider-managed Kafka listeners.
Logstash applies listener and asset identity to determine tenancy.
Validated events route to client-specific Elastic indices.
Unresolved events route to a quarantine index for service-provider review.
Fleet and MISP integrate endpoint management and threat context into the wider architecture.

Decisions

Use the ingestion path as the first tenant signal

Dedicated listeners provide identity before parsing event content.

Listener governance becomes part of onboarding.

Add asset identity as a second control

Layered identification reduces dependence on any single field.

Asset data must be maintained.

Fail to quarantine

Unknown ownership must never result in accidental client exposure.

Ambiguous events require review before becoming searchable.

Outcome

Each client could see only its own data, the SOC provider could work across the service, and events with uncertain ownership went to quarantine for review.

Platforms & methods

Elastic Security · Kafka · Logstash · Fleet · MISP · Private Cloud · RBAC