เข้าใจ Zero Trust Security: ปกป้องข้อมูลยุคดิจิทัล

Zero Trust เป็นหนึ่งใน Security Practice ที่จะมองทุกๆ อย่างไม่ว่าจะเป็น Users หรือ Services ต่างๆ ไม่น่าเชื่อถือเพราะ users/services เหล่านั้น อาจจะถูกโจมตีหรือสวมสิทธิ์ไปเรียบร้อยแล้ว เช่นการถูก Phishing, Shared Credentials, No Authentication หรืออื่น ๆ 

ถ้าย้อนกลับไปในสมัยก่อนคือ อะไรก็ตามที่อยู่ด้านหลัง Firewall จะถือว่าเป็น Secured Perimeter จะถือว่า น่าเชื่อถือทั้งหมดสามารถที่จะ Access Services ที่อยู่หลัง Firewall ระหว่างกัน ได้อย่างอิสระ ซึ่งในความเป็นจริงแล้ว มีโอกาสที่จะถูกโจมตีจากภายในได้อยู่ดี ยกตัวอย่าง เช่น

เมื่อมีพนักงานภายในถูกโจมตีด้วย การ Phishing แล้วโดนขโมย Identity ของบุคคลนั้นได้สำเร็จ Hacker ก็จะสามารถ Access ไปยัง Services หรือ ข้อมูลต่างๆ ที่อยู่หลัง Firewall ได้อย่างง่ายดาย ยิ่งถ้าบุคคลนั้นเป็น บุคคลกรระดับสูงๆ ด้วยแล้วล่ะก็ สิทธิการเข้าถึงข้อมูล หรือ Services ต่างๆ ก็จะกว้างขวางตามไปด้วย

computers under a traditional single perimeter defense with an implicit trust zone behind the firewall and the zero trust approach where there is no implicit trust

Image from nist.gov

คำนิยามง่ายๆ สำหรับ Zero Trust 

นั้นก็คือ Trust No One, Verify Everything ประกอบไปด้วย 3 Principles หลักๆ

  1. Verify Explicitly

คือการ Verify Identity ของ User/Service ว่าไม่ได้ถูกใช้งานโดยผู้อื่น ที่ไม่ใช่เจ้าของ Identity นั้นๆ 

  1. Least-privilege

คือการให้สิทธิที่เพียงพอต่อความต้องการใช้งานนั้น ๆ โดยจะแบ่ง ได้ดังนี้

  • Just Enough Access (JEA) คือให้ Permission ที่พอกับความต้องการ
  • Just In Time (JIT) คือการให้สิทธิ์ในเวลาที่เหมาะสม
  1. Assume Breach

คือการที่มองว่าระบบ Infrastructure ของเราถูกโจมตีอยู่ตลอดเวลา ดังนั้นจึงต้องแบ่ง Segment Access เพื่อลด ขอบเขตความเสียหาย (Blast Radius) ให้เหมาะสม การเข้ารหัส (Encryption) รวมไปถึงจะต้องเห็นความเคลื่อนไหวภายในตลอดเวลา (Visibility) ว่าเกิดพฤติกรรมแปลกๆของบุคลากรภายในหรือไม่ เพื่อที่จะตอบสนองการโจมตีได้อย่างรวดเร็ว

บทบาทของ HashiCorp Vault ในการทำ Zero trust ในองค์กร

เมื่อในองค์กรเริ่มที่จะนำระบบ IT มาใช้ในองค์กร แน่นอนว่าสิ่งที่ตามมาคือ Credential Resources เช่น Encryption Key, DB Password, Network Device Password, etc จึงจำเป็นที่จะต้องจัดเก็บ Credential Resources เหล่านั้นไว้ในที่ปลอดภัย ไม่ควร copy แล้วส่งต่อ ๆ กันเพราะมีโอกาสที่จะหลุดไปอยู่ในมือของผู้ที่ไม่หวังดีได้ ซึ่งข้อนี้จะจัดอยู่ใน Principles ข้อที่ 3

การ Verify Identity, HashiCorp Vault รองรับ Authentication Method ในการยืนยัน Identity ที่หลายหลายที่เป็นมาตราฐานสากล เช่น SAML, OIDC, LDAP, OAuth 2.0 ซึ่งสามารถนำไปใช้งานรวมกับ Identity Providers ต่าง ๆ ได้ เช่น Google Identity-platform, Azure Entra ID, Keycloak, AWS IAM

รวมไปถึง Official และ Third-party Tools ต่าง ๆ ที่ช่วยให้การ Implement กับ Infrastructure ในองค์กรได้สะดวกขึ้นและปลอดภัย ด้านล่างจะเป็นตัวอย่างที่เราจะใช้งานกับ Kubernetes ที่ Kube-api จะเป็น Identity-provider และผู้ใช้งานจะเป็นผู้เอา Public CA ของ Cluster นั้นใส่เข้าไปที่ Vault เพื่อเป็น Trust Relationship กับ Kube-api

เมื่อ Pod ถูกสร้าง ตัว Kube-api จะสร้าง Jwt token ที่จะมี Claim Subject ตาม Service Account ที่ Mount เข้าไปที่ Pod แล้ว Sign ด้วย Private Key ที่เป็นคู่เดียวกันกับ Public CA. เมื่อ App ภายใน Pod นั้นต้องการใช้งาน Secret, App จะนำ Token ที่ได้รับมาไปใช้ในการ Gather Secret จาก Vault มาใช้งานได้ แต่ก็จะอยู่ภายใต้ Policy ที่กำหนดว่า Claim Subject ที่ได้รับมามีสิทธิเข้าถึงได้หรือไม่

การกำหนด Policies การเข้าถึง Credential Resources, HashiCorp Vault สามารถกำหนด Policies ในการเข้าถึงได้ในรูปแบบของ Key-value Path ซึ่งมีความคล้ายคลึงกับ Directory ซึ่งเข้าใจได้ง่าย ด้านล่างจะเป็นตัวอย่างการสร้าง Policy

path “secret/data/{{identity.entity.id}}/*” {

 capabilities = [“create”, “update”, “patch”, “read”, “delete”]

}

จากตัวอย่างคือ สามารถสร้าง Policy ที่มี Path ของ Secret เป็น secret/data/{{identity.entity.id}}/* ซึ่งจะเป็น Secret ที่สร้างขึ้นมาตามชื่อเจ้าของ Secret นั้น ซึ่งมีสิทธิ์ครบเฉพาะของตัวเองเท่านั้น ทำให้การใช้งาน Secret มีความ Least Privilege ตามหลัก Zero Trust Principle

นอกจากนั้น HashiCorp Vault ยังคำนึงถึง Availability ซึ่งสามารถ Scale ให้เพียงพอเมื่อ ขนาดขององค์กรเริ่ม Scale ขึ้นเรื่อย ๆ 

Image from developer.hashicorp.com/vault

มากไปกว่านั้น คุณสามารถ ทำ multi-zone/multi-region deployment เพื่อให้ เกิด High Availability ในการทำงานเบื้องหลังจะใช้ Raft Algorithm ในการ Consent Secret Data ให้มีความถูกต้องและเป็นปัจจุบัน ในขณะที่ยังคงความสามารถในการเป็น Distributed Database ได้เพื่อที่จะรองรับจำนวนผู้ใช้งานได้จำนวนมาก

Image from developer.hashicorp.com/vault

HashiCorp Vault จะมี features ที่น่าสนใจ

  1. Securely Store Secrets

HashiCorp Vault จะช่วยจัดการในการจัดเก็บให้ปลอดภัยด้วยการ Encryption at rest และ On transit โดยจะ Secure ตั้งแต่ครั้งแรกที่สร้าง Vault ขึ้นมาด้วย Shamir’s Secret Sharing algorithm

  1. Access management
Vault Workflow

Image from developer.hashicorp.com/vault

HashiCorp Vault สามารถ กำหนดสิทธิ์การเข้าถึง Credential Resources เหล่านั้น โดยจะมีการควบคุม Permission ว่า user/service ไหนสามารถ Access ได้ โดยสามารถ ที่จะใช้งานรวมกับ Identity Provider ที่หลากหลาย

  1. High Availability

HashiCorp Vault สามารถที่จะทำเป็น Cluster สามารถที่จะเพิ่ม Replica ได้อย่างรวดเร็ว เพื่อที่จะรองรับ Workload ที่จะเข้ามาใช้งานได้จำนวนมาก

  1. Dynamic Secrets

สามารถให้ Vault Generate Secret และเก็บไว้ได้เลย โดยที่ไม่ต้อง Generate จากด้านนอก เพื่อป้องกันไม่ให้คนที่สร้างสามารถเห็น Secret ได้ในครั้งแรกที่สร้างขึ้นมา

  1. Leasing and Renewal

เป็นการใช้งาน Secret แบบชั่วคราว คล้าย ๆ การยืมใช้ เมื่อ Lease สิ้นสุดลง Secret จะ Revoke และสร้างใหม่ เหมาะกับการให้ Dev Access Database พอหมดเวลา Password จะถูก Renew ใหม่ทุกครั้ง เพื่อไม่ให้ Dev Copy Secret เก็บไว้ใช้งานภายหลัง

  1. Revocation

การ Revoke Secret ของ Vault สามารถทำการ Revoke Secret ที่เกี่ยวข้องกันทั้งหมดพร้อม ๆ กัน หลังจากที่ถูกใช้งานโดย User

  1. Plugins and Integration

HashiCorp Vault สามารถที่ใช้งานรวมกับ Third-party tools ได้หลากหลาย รวมไปถึง Library ต่าง ๆ ที่สามารถทำให้การใช้งานมีความง่ายและปลอดภัย

  1. Public key infrastructure

Generate และ Store Private Key ไว้สำหรับ auto generate x.509 certificate ต่าง ๆ โดยที่ไม่มีใครสามารถเห็น Private Key ชุดนั้น

Use Case การใช้งาน HashiCorp Vault

หนึ่งในปัญหาที่เกิดขึ้นบ่อยในปัญจุบันคือการ เก็บ Database password โดยส่วนใหญ่คือ เราจะสร้าง user/password ขึ้นมาโดย Remote เข้าไปที่ Database และสร้างแบบ Manual จากนั้นก็นำ User/password ไปเก็บไว้ใน Vault หรือ Secret Manager โดยปกติ แต่ลองคิดดูว่า ถ้าเป็น Production ก็จะมีผู้ดูแลอยู่ 1-2 คนมีสิทธิเข้าถึงได้ตลอดหรือเป็นคนสร้าง Secret เองด้วย ก็มีโอกาสที่จะเก็บ Secret นั้นเอาไว้ที่ใดซักทึ่นึงก่อนนำไปใส่ใน Vault นั้นก็แสดงว่า Secret นั้นก็ไม่ได้ Secret อีกต่อไป. หรือ อาจจะมี Dev บางคนต้องการ Access Database เพื่อ ต้องการ Troubleshooting ปัญหาของ Application แต่ในขณะนั้น อาจจะมีการ Debugging ทำให้สามารถนำ Secret นั้นออกมาได้ก็ทำให้ Secret นั้นไม่ Secret อีกต่อไปเช่นกัน

ดังนั้น Dynamic Secret จะมาแก้ปัญหานี้ก็คือ Vault จะเป็นผู้ Create user/password  ณ ตอนที่ Application หรือ User Login ผ่าน Identity Provider เข้ามาใช้งาน Secret และนำไปสร้าง Account ที่ Database เพื่อที่ Application หรือ User สามารถเข้าถึง Database นั้นได้ และเมื่อ User หรือ Application ไม่ได้ใช้งานแล้ว user/password นั้นก็จะถูกลบไป ทำให้การ Access Database จะไม่มีทางที่จะ Access ได้อีกหลังจากที่ ถูกใช้งานไปแล้ว

สรุปเนื้อหา

จาก Use Case ที่ กล่าวมาจะเห็นว่า HashiCorp Vault ได้สร้าง Mechanism ในการจัดการ Secret ตามหลักการ Zero Trust Principles คือ 

  1. Verify explicitly ผ่าน identity provider ต่าง ๆ ตามที่องร์กรนั้นใช้งานอยู่
  2. Just enough/Just in time access คือผู้ใช้งานจะใช้งานได้เฉพาะ Database ที่เกี่ยวข้องกับงานนั้นเท่านั้น และจะไม่สามารถนำ Password นั้นกลับไปใช้ซ้ำในครั้งต่อไปได้อีก
  3. Assume Breach เมื่อ Secret ที่ถูกผู้ใช้งาน สร้างขึ้นมานั้นถือว่า Secret นั้น ได้ Leak ออกไปแล้วแต่แรก ถึงเราจะไว้ใจผู้ที่ถือ Secret นั้นก็ตาม เพราะถ้า PC ของ User ที่สร้าง Secret นั้นขึ้นมาถูกโจมตีก่อนที่จะสร้าง Secret นั้น ก็มีโอกาสที่จะ Leak ตั้งแต่สร้าง Secret นั้นขึ้นมา ดังนั้นเราจะไม่ไว้ใจแม้กระทั่งคนในองค์กรเราเอง ตามคำนิยาม Zero Trust ที่ได้นำเสนอมาในช่วงแรก

สำหรับองค์กรใดที่ต้องการสร้าง Zero Trust Security ในองค์กร HashiCorp Vault เป็นอีก Security Tool นึงที่จำเป็นในการจัดการ Credentials ต่าง ๆ เพื่อเพิ่ม Security Posture ในองค์กร ลดความเสี่ยงที่จะเกิดความเสียหายต่อธุรกิจเป็นวงกว้าง และสร้างความเชื่อมั่นระหว่าง Partner ทางธุรกิจได้อย่างมีนัยสำคัญ

Reference: 

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf

https://query.prod.cms.rt.microsoft.com/cms/api/am/binary/RWJJdT

https://developer.hashicorp.com/vault/docs/concepts/policies

— Cloud HM