Upgrade to Pro — share decks privately, control downloads, hide ads and more …

An Introduction to Zero Trust Security

An Introduction to Zero Trust Security

In this session, we’ll take a guided tour of how service mesh, identity-based access management, and secrets management can help implement Zero Trust without increasing development friction. By combining HashiCorp Boundary, Consul, and Vault, we’ll evaluate how these new workflows affect the development process and how we’ve secured the architecture. At the conclusion, you’ll have a better understanding of where you can start implementing a Zero Trust model across users, services, and machines.

Be8b596c46f4c9a1aec6a7586af33134?s=128

Rosemary Wang

April 29, 2021
Tweet

More Decks by Rosemary Wang

Other Decks in Technology

Transcript

  1. An Introduction to Zero Trust Security Rosemary Wang GIDS Live

    | April 29, 2021 1
  2. @JOATMON08 2 ALLOW ALL INBOUND TCP ALLOW OUTBOUND TCP TO

    10.0.0.0/16
  3. “…no person, device, or network enjoys inherent trust. ” cloud.google.com/blog/topics/developers-practitioners/what-zero-trust-

    identity-security @JOATMON08 3
  4. “Never trust, always verify.” @JOATMON08 4

  5. Rosemary Wang (She/Her) Developer Advocate at HashiCorp @joatmon08 joatmon08.github.io 5

  6. “A system needs to know who you are…before it can

    determine what you should have access to. ” cloud.google.com/blog/topics/developers-practitioners/what-zero-trust- identity-security @JOATMON08 6
  7. Zero Trust Security Three goals Authorization Can you access this?

    Authentication Are you who say you are? Audit Who did what? @JOATMON08 7
  8. Zero Trust Security Three challenges Ephemerality No consistent way to

    account for system changes. Identity No unified model across software, platform, and tools. Productivity No easy implementation to support or innovate. @JOATMON08 8
  9. @JOATMON08 9 Zero trust is asymptotic. It can approach zero

    but never reach it.
  10. Address these challenges across… Person Human to machine access Device

    Machine authentication & authorization Network Service to service access @JOATMON08 10
  11. Possible Solutions ▪ Identity & Access Management (IAM) Tools –

    Tool-specific – Cloud-specific ▪ Add abstraction (with tools or build your own) ▪ Manage it “as code” @JOATMON08 11
  12. EKS (KUBERNETES) MY VPC 10.0.0.0/16 HASHICORP VIRTUAL NETWORK 172.25.16.0/20 PEERING

    CONNECTION VAULT SERVER CONSUL SERVER PUBLIC SUBNETS BOUNDARY CONTROLLER PRIVATE SUBNETS EKS (KUBERNETES) BOUNDARY WORKER VAULT AGENT PRODUCTS DATABASE (POSTGRESQL) CONSUL AGENT CONSUL AGENT CONSUL AGENT BOUNDARY DATABASE (POSTGRESQL) PRODUCT API PUBLIC API FRONTEND API CONSUL TERMINATING GATEWAY ENGINEER PSQL SSH AUTHENTICATE TO BOUNDARY TCP :80 12 Devices Person Network CONFIGURATION AS CODE
  13. PRODUCTS DATABASE (POSTGRESQL) PRODUCT API PUBLIC API FRONTEND API Our

    Application DEVICE: ONLY PRODUCT API CAN ACCESS THE DATABASE PERSON: ONLY PRODUCT DEVELOPER CAN ACCESS FRONTEND. 13 NETWORK: ONLY FRONTEND CAN ACCESS PUBLIC API.
  14. Person 14

  15. Should this person be able to access that? Relevant for

    remote work @JOATMON08 15
  16. Development Access includes: ▪ Applications ▪ Business data ▪ Development

    environments ▪ Monitoring systems Business Access includes: ▪ Applications ▪ Business data ▪ Software as a service Operations Access includes: ▪ All environments ▪ Most systems and infrastructure Person(as) 16
  17. 17 Identity Access Management ORGANIZATION CORE_INFRA PROJECT PRODUCTS_INFRA PROJECT OPERATIONS

    TEAM GROUP PRODUCTS TEAM GROUP ROSEMARY ROB EKS NODES (EC2 INSTANCES) PRODUCTS DATABASE (POSTGRESQL) FRONTEND TARGET TCP :80 TARGET TCP:5432 BUSINESS TEAM GROUP MELISSA READ-ONLY FOR ORGANIZATION boundaryproject.io/docs/concepts/domain-model TARGET TCP:22 SAAS ENDPOINTS TARGET TCP:8200 TCP:8500
  18. In this system… Never trust. ▪ Configure IAM as code

    – Uses Terraform to configure AWS & Boundary ▪ One ingress point to access endpoints – Uses AWS IAM to restrict roles – Uses Boundary to restrict access to infrastructure endpoints @JOATMON08 18
  19. To improve… Always verify. ▪ Least-privilege? – Policy as code

    – Remediate and identify unused endpoints ▪ Auditing? – Identify who logged in and did what @JOATMON08 19
  20. Device 20

  21. Should this device be able to access that? Relevant for

    systems @JOATMON08 21
  22. Containers Access includes: ▪ Applications ▪ Business data ▪ Development

    environments ▪ Monitoring systems Machines Access includes: ▪ Other machines ▪ Software Other Access includes: ▪ Personal computing ▪ Edge devices Devices 22
  23. EKS (KUBERNETES) MY VPC 10.0.0.0/16 HASHICORP VIRTUAL NETWORK 172.25.16.0/20 PEERING

    CONNECTION VAULT SERVER PRIVATE SUBNETS EKS (KUBERNETES) VAULT AGENT PRODUCT API PUBLIC API FRONTEND API 4. CREATE FILE WITH DATABASE USERNAME AND PASSWORD 1. AUTHENTICATE TO VAULT 3. RETURN DATABASE USERNAME AND PASSWORD 5. REVOKE DATABASE USERNAME AND PASSWORD WHEN TTL EXPIRES. 2. CREATE DATABASE USERNAME AND PASSWORD 23 PRODUCTS DATABASE (POSTGRESQL)
  24. In this system… Never trust. ▪ Authenticate everything – Uses

    Vault to get access to other machines (like databases) ▪ Ephemeral access – Uses Vault to revoke tokens and access to other machines regularly @JOATMON08 24
  25. To improve… Always verify. ▪ Productivity? – Ephemerality may break

    applications ▪ Least-privilege? – The right time to live for device access – Lock down CI framework ▪ Vulnerabilities? – Scanning code for 3rd party libraries ▪ Auditing? – Identify devices and what they accessed @JOATMON08 25
  26. Network 26

  27. Should the network allow traffic between services? Relevant for network

    policies @JOATMON08 27
  28. API Authorization Access includes: ▪ API Gateways ▪ Authorization servers

    Firewalls / Policy Groups Access includes: ▪ IP Addresses ▪ Virtual machines Service Mesh Access includes: ▪ API Authorization ▪ Services Network 28
  29. Service Mesh mTLS BETWEEN PROXIES NETWORK POLICY THROUGH L4 &

    L7 (INTENTIONS) consul.io/docs/connect 29
  30. In this system… Never trust. ▪ Network policy across layers

    – Uses Terraform to configure firewalls and policy groups – Uses Consul to control service-to-service communication. ▪ Secure communication – Encryption without adding to application code – Telemetry @JOATMON08 30
  31. To improve… Always verify. ▪ Productivity? – Debug with proxy

    – Yet another agent (performance?) ▪ Least-privilege? – Remediate and identify unused network policy ▪ Auditing? – Track service-to-service communication @JOATMON08 31
  32. Almost Zero Trust Security 32

  33. Never trust. Easier to implement in newer systems. ▪ Manage

    it “as code” ▪ Add abstractions for identity of person, device, or network – Identity & access management tool – Secrets management – Service mesh @JOATMON08 33
  34. Always verify. Mostly implemented in older systems. ▪ Dynamic analysis

    – Remediation – Vulnerability management – Security information and events management ▪ Static analysis – Application code – *Infrastructure configuration @JOATMON08 34
  35. @JOATMON08 35 Always Verify Never Trust Always Trust Never Verify

    “Brownfield” Datacenter Environments “Greenfield” Multi-* Environments It works on my local machine. ???
  36. @JOATMON08 36 Always Verify Never Trust Always Trust Never Verify

    All Environments “Brownfield” Datacenter Environments It works on my local machine.
  37. References ▪ https://github.com/joatmon08/hashicorp-stack- demoapp ▪ https://techfieldday.com/appearance/hashicorp- presents-at-security-field-day-5/ ▪ https://www.hashicorp.com/solutions/zero-trust- security

    ▪ https://cloud.google.com/blog/topics/ developers-practitioners/what-zero-trust- identity-security @JOATMON08 37
  38. Thank you! Rosemary Wang @joatmon08 joatmon08.github.io 38