Zero Trust Architecture

Chokchai Phatharamalai
odds.team
Published in
2 min readOct 23, 2023
Photo by Patrick Hendry on Unsplash

ผมได้ยินคำนี้มาซักพักแล้ว แต่เข้าใจมันมากขึ้นตอนฟัง session Implementing a Zero Trust Architecture (A deep dive on NIST SP 800–207A) ของ Zack Butcher

Zero Trust Architecture (ZTA) คือ สมมติว่าผู้ร้ายเจาะเข้ามาใน network เราได้แล้ว เราจะลดความเสียหายได้อย่างไร

โดยปรกติแล้ว เราจะใช้ firewall เป็นกำแพงหลักในการป้องกันไม่ให้คนโจมดีเข้ามาใน network เราได้ แต่ถ้าเค้าเจาะเข้ามาได้แล้วหล่ะ เราจะทำอย่างไร?​ ซึ่งหลักการคือเราจะบีบผู้โจมตีด้วย time & space หมายถึง กรอบเวลา และ ขอบเขตที่เค้าเข้าถึงได้ ซึ่งวิธีการคือการกำหนด authorization ​(AuthN) ระดับ อุปกรณ์, ผู้ใช้งาน และ service นั่นเอง

จากที่เราเคยตัดสินใจว่าจะ block request ที่เข้ามาไหม จาก network parameter เช่น IP หรือ subnet เราจะเปลี่ยนเป็น ตัดสินจาก indentity ของ อุปกรณ์, ผู้ใช้งาน หรือ service

การจะทำให้ได้ตามเงื่อนไขของ ZTA ตอน run time จำเป็นต้องมีการตรวจสอบอย่างน้อย 5 อย่างดังนี้

  1. เข้ารหัสตอนส่งข้อมูล
  2. service identity และ authentication (AuthN)
  3. service-to-service AuthZ
  4. End user identity & AuthN
  5. End user-to-resource AuthZ

ปรกติเราทำ End user identity & AuthN อยู่แล้วด้วยการให้ผู้ใช้งาน login เพื่อจะได้รู้ว่าใครเป็นใคร และกำหนดว่าผู้ใช้งานคนนั้นมีสิทธิ์ (AuthZ) เข้าถึงข้อมูล (resource) อะไรได้บ้าง และบ่อยครั้งเราก็จะเห็น request จากผู้ใช้งานถูกเข้ารหัส

สิ่งที่แปลกใหม่สำหรับผมในการทำ ZTA คือเราจะให้ service login เพื่อให้ได้ indentity ว่านี่คือ service อะไร และถ้า indentity นั้นเป็น certificate (SPIFFE) เราสามารถใช้มันในการเข้ารหัส request ที่เราส่งหากันระหว่าง service ได้ด้วย

ถ้าเรากำหนดให้ identity ของเรามีการหมุนเวียนบ่อยหน่อย เช่น ทุกชั่วโมง หรือ 15 นาที ต่อให้ผู้ร้ายอยู่ใน network เราก็จะทำอะไรได้ลำบาก เพราะมีเวลาจำกัดก่อน indentity นั้นจะหมดอายุ แถม service ที่เข้าถึงได้ก็จะจำกัดแค่ service ที่เรากำหนดไว้ จึงลดความเสียหายที่เกิดขึ้นได้

ทั้งหมดนี้ฟังดูปลอดภัยแหละ คำถามที่ผมสงสัยคือจะ implement มันอย่างไร โชคดีที่ Zack เสนอทางหนึ่งคือใช้ service mesh ในการ implement ZTA

Service mesh คืออะไร

มันคือ proxy ที่เราลงเป็น sidecar ไว้ข้าง ๆ service ต่าง ๆ ของเรา เพื่อตรวจจับ ทุก ๆ request ที่วิ่งเข้าออกเพื่อตรวจสอบว่าตรงตามที่เรากำหนดไว้ไหม ถ้าไม่ตรงก็ block

Tools ที่สามารถใช้ได้ก็มี Itsio เพื่อ config policy ตรงกลาง และใช้ envoy เป็น sidecar proxy

นอกจาก service mesh จะช่วยเรา implement ZTA ได้แล้ว ยังมีความสามารถอื่น ๆ ด้วยเช่น retry, timeouts, circuit breaker, tracing, logs, load balance เป็นต้น

ค่อย ๆ ขยับจาก Network based เป็น Identity based อย่างไร

จากเดิมที่เราเคยกำหนด firewall จากเครื่องต่อเครื่อง ถ้าเราจะเอา indentity based เราอาจจะต้องเไปเอา rules ใน firewall ออก แล้วไปกำหนดใน service mesh แทน แต่ถ้าให้ทำทั้งหมดพร้อม ๆ กันก็ทำไม่ไหว แถมความเสี่ยงก็สูงด้วย

Zack แนะนำว่าเราค่อย ๆ ย้าย firewall rules จาก service เครื่องต่อเครื่อง ไปกำหนดที่ gateway ต่อ gateway แทนได้ เพราะใน service mesh จะมี Ingress (gateway ขาเข้า) และ Egress (gateway ขาออก) อยู่แล้ว เค้าเรียกท่านี้ว่า multi-tier policies

อ้างอิง

--

--