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

Security vs. Delivery: Win with Dependency Inversion

Security vs. Delivery: Win with Dependency Inversion

Security tools, separate policies everywhere and not one place to audit! How do you solve the multi-platform management problem for security? After all, we’ve solved some multi-cloud management problems with infrastructure as code. In this talk, I’ll outline how you can apply dependency inversion to maintain the security of your system as it quickly evolves.

You’ll learn about patterns, technologies, and approaches to evolve your systems while minimizing the erosion of your security practices. We’ll explore one solution with HashiCorp Terraform, Consul, Vault, and Boundary, but you’ll find the patterns broadly apply to your system architecture. This talk will be useful to platform, infrastructure, or security architects, and anyone designing or engineering infrastructure systems.

Be8b596c46f4c9a1aec6a7586af33134?s=128

Rosemary Wang

March 23, 2022
Tweet

More Decks by Rosemary Wang

Other Decks in Technology

Transcript

  1. Copyright © 2020 HashiCorp March 2022 Security vs. Delivery Win

    with dependency inversion
  2. Security “We must secure!” Delivery “We must innovate!” DATACENTERS ACCESS

    CONTROL VULNERABILITY MANAGEMENT AUDIT LOGGING CLOUDS SECRETS NETWORK POLICY MANAGED SERVICES 😰
  3. Author, Patterns & Practices for IaC Developer Advocate, HashiCorp 


    she/her 
 @joatmon08 Rosemary Wang
  4. Dependency Inversion In software development 01 Round 1 / Security

    vs. Delivery
  5. High-Level Object Low-Level Object Application Depends On Database

  6. APPLICATION CODE Database Type 1 Implement access to 
 MySQL

    Database Type 2 Implement access to PostgreSQL public class CustomerService { private CustomerDao customer ; public Optional<Customer> findById(int id) { return customer.findById(id) ; } public List<Customer> findAll() { return customer.findAll() ; } } Example from https://www.baeldung.com/java-dependency-inversion-principle DATA ACCESS OBJECT public interface CustomerDao { Optional<Customer> findById(int id) ; List<Customer> findAll() ; } High-Level Object Low-Level Object Abstraction
  7. …both high-level and low-level objects must depend on same abstraction.

    This loosely couples software modules.
  8. Loose coupling supports evolution. Change low-level object while minimizing impact

    to high-level object.
  9. 02 Infrastructure as code Round 2 / Security vs. Delivery

  10. …both high-level and low-level objects must depend on same abstraction.

    This loosely couples infrastructure dependencies. infrastructure resources
  11. High-Level Object Low-Level Object Depends On Server Network

  12. SERVER CONFIG resource "aws_instance" “machine" { ## omitted for clarit

    y subnet_id = data.aws_subnet.selected.id tags = { Name = local.nam e } } DATA ACCESS OBJECT data "aws_subnet" "selected" { filter { name = "tag:Team " values = [var.team ] } filter { name = "tag:Environment " values = [var.environment ] } } High-Level Object Low-Level Object Abstraction NETWORK CONFIG resource "aws_subnet" "main" { vpc_id = aws_vpc.main.i d cidr_block = cidrsubnet ( var.cidr_block, 4, 1 ) tags = { Name = local.nam e } } Infrastructure API
  13. DATA ACCESS OBJECT output "ip" { value = aws_instance.machine.private_i p

    } High-Level Object Low-Level Object Abstraction DNS CONFIG resource "cloudflare_record" "machine" { ## omitted for clarit y zone_id = var.cloudflare_zone_i d name = "vm " value = module.vm.ip } SERVER CONFIG resource "aws_instance" "machine" { ## omitted for clarit y subnet_id = data.aws_subnet.selected.i d tags = { Name = local.nam e } } Infrastructure Module Output
  14. DNS CONFIG resource "cloudflare_record" "machine" { ## omitted for clarit

    y zone_id = var.cloudflare_zone_i d name = "vm " value = module.vm.ip } DATA ACCESS OBJECT output "ip" { value = azurerm_linux_virtual_machine.machin e .private_ip_addres s } High-Level Object Low-Level Object Abstraction SERVER CONFIG resource "azurerm_linux_virtual_machine" "machine" { ## omitted for clarit y subnet_id = data.aws_subnet.selected.i d tags = { Name = local.nam e } } Multiple Clouds / Platforms
  15. 03 Security Round 3 / Security vs. Delivery

  16. Infrastructure / applications depend on security. Benefits from dependency inversion

    principle.
  17. Secrets

  18. High-Level Object Low-Level Object Application Depends On Database Secret

  19. 1. Regret 2. Revoke 3. Rotate 4. Reference 5. Replace

    6. Restart Can you imagine contacting multiple teams to fix their passwords? 😞 😞 😞 Invert application’s dependency on secret.
  20. APPLICATION CODE public class CustomerService { private CustomerDao customer ;

    public Optional<Customer> findById(int id) { return customer.findById(id) ; } public List<Customer> findAll() { return customer.findAll() ; } } https://cloud.spring.io/spring-cloud-vault/reference/html/#vault.config.backends.database-backends High-Level Object Low-Level Object Abstraction CODE LIBRARY ## install spring-cloud-vault- config-databases dependenc y ## application.propertie s spring.cloud.vault : database : enabled: tru e role: readonl y backend: database Application does not change! Change these if necessary. Secrets Manager + Code Library Database Secret Database Password /database/creds/customer
  21. APPLICATION CODE public class CustomerService { private CustomerDao customer ;

    public Optional<Customer> findById(int id) { return customer.findById(id) ; } public List<Customer> findAll() { return customer.findAll() ; } } https://cloud.spring.io/spring-cloud-vault/reference/html/#vault.config.backends.database-backends High-Level Object Low-Level Object Abstraction SIDECAR PROCESS ## run Vault agent as a separate proces s vault agent -config /vault-agent/agent.hc l ## Vault agent generates application.propertie s {{ with secret “database/creds/customer“ -} } spring.datasource.username={{ .Data.username }} spring.datasource.password={{ .Data.password } } {{- end }} Application reads configuration from file. 
 No changes to code. Secrets Manager + Sidecar Process Database Secret Database Password /database/creds/customer APPLICATION.PROPERTIES spring.datasource.username=custome r spring.datasource.password=Depend3ncy!nversio n
  22. Network Policy

  23. High-Level Object Low-Level Object Web Depends On App Database SHOULD

    NOT DEPEND ON
  24. 1. API Authorization 2. Certificates 3. Traffic Management 4. Telemetry

    5. Firewalls 6. Network Routing 7. Security Groups Can you imagine contacting multiple teams to manage these configurations? 😞 😞 😞
  25. 1. API Authorization 2. Certificates 3. Traffic Management 4. Telemetry

    5. Firewalls 6. Network Routing 7. Security Groups Inverts application’s dependencies on these.
  26. High-Level Object Low-Level Object Web App Database Service Mesh +

    Sidecar Proxy Abstraction NETWORK POLICY Kind = "service-intentions " Name = "db " Sources = [ { Name = "web " Action = "deny " } , { Name = “app " Action = "allow " } ] Offers abstraction for certificates, traffic management, API authorization, and telemetry.
  27. 1. API Authorization 2. Certificates 3. Traffic Management 4. Telemetry

    5. Firewalls 6. Network Routing 7. Security Groups Service catalog + automation can help invert infrastructure’s dependency on these.
  28. Access Control

  29. High-Level Object Low-Level Object Depends On Identity SSH Access to

    Server
  30. High-Level Object Low-Level Object Depends On Many Identity Providers Across

    platforms, clouds, and services. …and more SSH Access to Server
  31. High-Level Object Low-Level Object Many Identity Providers Many platforms, clouds,

    etc. …and more Secure Access Management Abstraction SSH Access to Server TERRAFORM ## Azure AD operator group should have SSH acces s resource "boundary_role" "core_infra" { ## omitted for clarit y scope_id = boundary_scope.org.i d grant_scope_id = boundary_scope.core_infra.i d grant_strings = [ "id=*;type=*;actions=* " ] principal_ids = [ boundary_managed_group.operators.id ] }
  32. Is it a win? 04 Final Round / Security vs.

    Delivery
  33. Units of Effort over Time Effort Time No Dependency Inversion

    You spend several months changing your security architecture and refactoring high-level applications and infrastructure.
  34. Can I change my security tool or policy tomorrow without

    affecting delivery?
  35. 1. Dependency inversion 2. Choose an abstraction between low-level and

    high-level objects 3. Share security practices and knowledge
  36. Units of Effort over Time Effort Time No Dependency Inversion

    Dependency Inversion Initially, you spend a month or two adding abstraction. Initially, you spend a month or two adding abstraction. Future changes to security architecture minimizes refactor for high-level applications and infrastructure. Benefit of “Shifting Security Left”!
  37. Rosemary Wang joatmon08.github.io 
 she/her 
 @joatmon08 Thank you!