"Zero trust", เทรนสุด hot 🔥 ของยุค multi-cloud

Key หลักของ zero trust คือ ให้ปิดการเชื่อมต่อ (deny) สิ่งต่างๆ (users, applications, services) ใน networks/clouds โดย default,  แล้วทั้งคนและ machines ก็จะต้องถูก "ยืนยันตัวตน" และ "ตรวจสอบสิทธิ์การเข้าถึง" เสมอ

เนื่องจากว่า applications/services บน cloud ในบัจจุบันมีความซับซ้อนมากขึ้น, นอกจากนั้นก็ยังมีหลายๆ systems ที่ต้อง manage, หลายๆ endpoints ที่ต้อง monitor,  มีการเชื่อมต่อด้าน network มากขึ้นตามมา  และมีผู้คนที่ต้อง access อีกมากมาย (ไม่ว่าจะเป็นฝั่ง end users หรือฝั่งผู้ดูแลระบบ)   ผลกระทบก็คือ อาจจะมีคนเข้าถึง applications/services/endpoints ต่างๆโดยพลกาล ซึ่งเป็นไปได้มากยิ่งขึ้น

เดิมทีแล้วการป้องกันความปลอดภัยของ network ก็จะปกป้องแค่ระดับ IP address หรือ ports โดย Firewall, SIEM หรืออื่นๆ   แต่เครื่องมือเหล่านี้มีประสิทธิภาพ "ไม่เพียงพอ" ในด้าน securiy ให้แก่ applications/services บน cloud ในปัจจุบัน 

ความท้าทายที่เกิดขึ้นบน cloud

-  Applications/services ต่างๆสามารถมี IP addresses/ports เปลี่ยนแปลงแบบ dynamic  จึงทำให้การ allow/deny ที่ระดับ IP เป็นเรื่องยากในงาน operation

- วิธีการที่อยู่บนพื้นฐานของ ITIL แบบที่เราต้องเปิด ticket "มีความช้า", "เป็นภาระ" และ "ไม่ยืดหยุ่น" เพียงพอที่จะตอบสนองต่อความต้องการความปลอดภัยของ "dynamic cloud environment" ในปัจจุบัน

- การที่ให้เจ้าหน้าที IT เป็นผู้ generate ตัว credentials (tokens, key cards และ passwords) ให้แก่ users หรือ machines (VMs, apps, ฯลฯ) โดย manual จะมีความช้า, ไม่มีประสิทธิภาพ, มีประเด็นด้านความปลอดภัย และมีประเด็นเรื่องการ scale

การทำให้ security ระหว่าง clouds มีความสามารถในการ scale แบบ dynamic

ทาง HashiCorp ได้เสนอ security model ซึ่งอยู่บนแนวคิด "identity-based access and security" ที่ว่า

- ไม่ว่าจะเป็น users (คน) หรือว่า machines (applications, services, VMs, Databases, ฯลฯ) จะต้องมีการ "ยืนยันตัวตน"

- users และ machines จะต้องถูกตรงสอบ "สิทธิ์การเข้าถึง" 

จากแนวคิดดังกล่าว  แล้วถ้าจะนำมาสร้างเป็น zero trust ของจริง จะต้องปฏิบัติตาม 4 ข้อ ดังนี้ 

(1) มีการยืนยันตัวตน (authentication) และการตรวจสอบสิทธิ์การเข้าถึง (authorization) แก่ machines

(2) มีการกำหนดการเข้าถึงระหว่าง machine กับ machine

(3) มีการยืนยันตัวตน (authentication) แก่ users

(4) มีการกำหนดการเข้าถึงจาก users (คน) ไปหา machines

1. มีการยืนยันตัวตน (authentication) และการตรวจสอบสิทธิ์การเข้าถึง (authorization) แก่ machines

"HashiCorp Vault" เป็นเครื่องมือช่วยในเรื่อง "การยืนยันตัวตน" และ "การตรวจสอบสิทธิ์" ให้แก่ machines (VMs, applications, ฯลฯ) ได้ โดยจะช่วยเป็นศูนย์กลางใน "การจัดเก็บ" และ "การสร้าง" พวก credentials (token, passwords, certificates และ encryption keys) แบบ dynamic ให้แก่ระหว่าง machines เช่น ระหว่าง VM กับ VM, ระหว่าง applications กับ databases (ซึ่งลักษณะนี้จะแตกต่างจากการทำงานในรูปแบบ ITIL) 

2. มีการกำหนดการเข้าถึงระหว่าง machine กับ machine

"HashiCorp Consul" สามารถช่วยจัดการในเรื่อง "การเข้าถึง", "การเชื่อมต่อ" และ "การยืนยันตัวตน" กันระหว่าง machines (applications หรือ services) 

ตัวอย่างเช่น  เดิมทีนั้นเราอาจจะมี applications/services ต่างๆอยู่ในหลายๆ containers/VMs ซึ่งวิธีแบบ traditional แล้ว ทางผู้ดูแลระบบจำเป็นที่จะต้องไปกำหนด rules ต่างๆ (เช่นกำหนดใน Firewalls) ว่าต้องการให้ IPs/ports ของ app/services ไหนคุยกันได้บ้าง ไม่ได้บ้าง

แต่ด้วย Consul, ผู้ดูแลระบบสามารถกำหนดเพียงว่า ต้องการให้ application/service "A" คุยกับ "B" ("A" คุยกับ "C" ไม่ได้)

จากนั้นไม่ว่า application/service "A" และ "B" จะอยู่ที่ VMs ไหน, containers ไหน หรืออยู่ที่ IP ไหน, port ไหน (แต่ละ application/service อาจจะมีมากกว่า 1 ตัวได้) ทาง HashiCorp Consul ก็จะ automate การ configure ทุกอย่างให้โดยอัตโนมัติ ได้แก่ การค้นหา application/service, การกำหนดสิทธิ์การเข้าถึงระดับ ACL, traffic rules และ encrypted traffic  ซึ่งสิ่งต่างๆเหล่านี้ Consul สามารถทำได้ถึงระดับ multi-clouds 

3. มีการยืนยันตัวตนแก่ users

เครื่องมือในการยืนยันตัวตน ว่าใช่คนๆนั้นหรือเปล่า ซึ่งแต่ละองค์กรณ์อาจจะมีวิธีการของตัวเองอยู่แล้ว เช่น

- วิธีแบบดั้งเดิม อาจจะใช้แค่ username และ password
- ที่ on-premises อาจจะใช้ single sign-on เช่น Active Directory, LDAP
- ที่ clouds อาจจะใช้ single sign-on เช่น Okta , Microsoft AD 

4. มีการกำหนดการเข้าถึงจาก users ไปยัง machines

เดิมทีแล้วการให้ users (พนักงาน) เข้าถึง endpoints ขององค์กร อาจจะใช้ SSH keys, VPN credentials, โดยมี jump host หรือ host ใน DMZ zone (untrusted networks) เป็นทางผ่านก่อนที่จะไปถึง endpoints ปลายทางได้  ซึ่งวิธีการเหล่านี้สามารถเกิดความเสี่ยงสำหรับองค์กรได้ เนื่องจาก users สามารถเข้าถึง private network ขององค์กรได้โดยตรง

"HashiCorp Boundary" เป็นเครื่องมือที่สามารถเพิ่มความปลอดภัยให้แก่ application และ system ได้   เพราะว่า users จะ "ไม่สามารถ" ใช้ credential ของ app/services ของจริงได้โดยตรง , และ user จะ "ไม่สามารถ" เข้าถึง private network ได้โดยตรง

ซึ่ง solution ของ HashiCorp Boundary มีวิธีการดังนี้

- ขั้นตอน 1: ผู้ใช้ต้อง "ยืนยันตัวตน" ด้วย IdP (ซึ่งอาจจะเป็น Active Directory , Okta หรืออื่นๆ)

- ขั้นตอน 2: แต่ละ user ก็จะถูกตรวจสอบสิทธิ์ด้วย policies (ลักษณะ high-level logical policies) ว่า user สามารถเข้าถึงอะไรได้บ้าง, ซึ่งใน policies นี้จะไม่ได้ถูก hard code ด้วย IP, แต่จะเป็น logical service ก็ได้ (ในกรณีที่ว่า node นั้นๆ fails, จากนั้น IP address/port ก็จะถูกเปลี่ยนแบบ dynamic ได้)

- ขั้นตอน 3: ตัว HashiCorp Boundary ก็จะสร้าง session ให้กับ user (คล้าย SSH tunnel)

ขั้นตอน 4: เมื่อ solution นี้ใช้ร่วมกับ Vault ทาง users จะไม่ได้รับ credential จริงของ applications/services/endpoints เนื่องจากว่า Vault จะ generate ตัว credential (หรือ secret) ชั่วคราว ให้แก่ users แบบ dynamic (ผู้ดูแลระบบอาจจะกำหนดได้ว่า credential ที่จะกำหนดให้แก่ users นั้นสามารถใช้ได้นานเท่าไหร่, เมื่อถึงเวลา Vault ก็จะทำลาย credentials ดังกล่าว)

 

(อ้างอิง : https://www.hashicorp.com/solutions/zero-trust-security

https://www.youtube.com/watch?v=tUMe7EsXYBQ ) 

 

CloudHashicorpSecurityZerotrust

Leave a comment

All comments are moderated before being published