LinkedIn Professional Network  ·  View 27 of 30  ·  7 · Assurance

Security Zones

Where the trust boundaries are, what crosses each one, and where an attacker arrives.

Editable source SVG draw.io All views
Internet · untrusted Member Scraper / bot credential stuffing Edge Front Door + WAF DDoS · bot rules Traffic tier ATS · colo pinning API perimeter API layer session to principal Identity MFA · ATO scoring Rate limiter per member + IP Service zone · mTLS Rest.li services mTLS · D2 ACL service managed in Nuage Privacy policy every read path Data · restricted Espresso · MySQL encrypted at rest KMS + secrets envelope keys Audit log Kafka to immutable HTTPS 443 challenged TLS HTTPS mTLS + principal TLS access log Security Architecture — Trust Zones Person or role Risk / gap Security / platform Interface / broker Application we own Data store synchronous failure / alternate event / async No path reaches a service without a principal, or a store without an ACL decision. v 1.0 · owner Security Architecture · date 2026-09

Decisions

  • The edge authenticates nothing. The API layer turns a session into a principal, and only principals reach services
  • Service-to-service traffic is mTLS. Authorization is a central ACL service enforced inside each service, with access logs sent through Kafka (LinkedIn, 2019)
  • Member privacy policy is checked on every read path, not only at the gateway

Controls

  • Encryption in transit everywhere, and at rest with envelope keys from KMS
  • Secrets are fetched at start-up on short leases; no secret lives in config
  • Scraping defence: per-member and per-IP rate limits, plus bot scoring at the edge

Risks

  • Scraping public profiles is the persistent threat. Rate limits and bot detection raise its cost; they do not end it
  • A compromised internal service is contained by ACLs, not by network zones alone