Implicit Trust Versus Zero Trust (Implicit Trust เทียบกับ Zero Trust)

สถาปัตยกรรม microservice ของเราประกอบด้วยการสื่อสารระหว่างสิ่งต่างๆ มากมาย ผู้ใช้ที่เป็นมนุษย์โต้ตอบกับระบบของเราผ่าน user interface ซึ่ง user interface เหล่านี้จะเรียก microservice ต่างๆ ต่อไป และ microservice ก็เรียก microservice อื่นๆ ต่อไปอีก เมื่อพูดถึง application security เราจำเป็นต้องพิจารณาประเด็นเรื่อง trust ในทุกจุดที่มีการติดต่อกันเหล่านั้น เราจะสร้างระดับความไว้วางใจที่ยอมรับได้อย่างไร? เราจะสำรวจหัวข้อนี้ในอีกไม่ช้าในแง่ของ authentication และ authorization ทั้งของมนุษย์และ microservice แต่ก่อนอื่นเราควรพิจารณาโมเดลพื้นฐานบางอย่างเกี่ยวกับ trust ก่อน

เราไว้วางใจทุกอย่างที่รันอยู่ในเครือข่ายของเราหรือไม่? หรือเรามองทุกอย่างด้วยความสงสัย? ตรงนี้ เราสามารถพิจารณา mindset สองแบบ—implicit trust และ zero trust

Implicit Trust (ความไว้วางใจโดยปริยาย)

ทางเลือก แรกของเราอาจเป็นการสมมติว่า call ใดๆ ที่เรียกไปยัง service จากภายในขอบเขต (perimeter) ของเรานั้นได้รับความไว้วางใจโดยปริยาย

ขึ้นอยู่กับความอ่อนไหวของข้อมูล วิธีนี้อาจจะโอเค บางองค์กรพยายามรักษาความปลอดภัยที่ perimeter ของเครือข่ายของตน และด้วยเหตุนี้จึงสมมติว่าไม่จำเป็นต้องทำอะไรเพิ่มเติมเมื่อสอง service กำลังคุยกัน อย่างไรก็ตาม หากผู้โจมตีเจาะเข้ามาในเครือข่ายของคุณได้ เรื่องร้ายๆ ก็อาจเกิดขึ้น หากผู้โจมตีตัดสินใจดักฟังและอ่านข้อมูลที่ถูกส่ง เปลี่ยนแปลงข้อมูลโดยที่คุณไม่รู้ตัว หรือแม้แต่ในบางสถานการณ์ปลอมตัวเป็นสิ่งที่คุณกำลังคุยด้วย คุณอาจไม่รู้อะไรเกี่ยวกับเรื่องนี้เลย

นี่คือรูปแบบของ trust ภายใน perimeter ที่ผมพบเห็นได้บ่อยที่สุดในองค์กรต่างๆ ผมไม่ได้บอกว่านั่นเป็นเรื่องดีนะ! สำหรับองค์กรส่วนใหญ่ที่ผมเห็นใช้โมเดลนี้ ผมกังวลว่าโมเดล implicit trust ไม่ได้เป็นการตัดสินใจอย่างมีสติ แต่เป็นเพราะผู้คนไม่รู้ตัวถึงความเสี่ยงตั้งแต่แรกมากกว่า

Zero Trust (ความไม่ไว้วางใจโดยสิ้นเชิง)

“จิลล์ เราตามรอยสายมาแล้ว—มันมาจากในบ้านนี่เอง!”

When a Stranger Calls

เมื่อ ทำงานในสภาพแวดล้อมแบบ zero trust คุณต้อง สมมติ ว่าคุณกำลังทำงานอยู่ในสภาพแวดล้อมที่ถูกโจมตีไปแล้ว—คอมพิวเตอร์ที่คุณกำลังคุยด้วยอาจถูกโจมตีไปแล้ว การเชื่อมต่อขาเข้าอาจมาจากฝ่ายไม่หวังดี ข้อมูลที่คุณเขียนอาจถูกอ่านโดยคนไม่ดี หวาดระแวงไหม? ใช่! ยินดีต้อนรับสู่ zero trust

Zero trust โดยพื้นฐานแล้วคือ mindset ไม่ใช่สิ่งที่คุณสามารถทำได้ด้วยเวทมนตร์ผ่านผลิตภัณฑ์หรือเครื่องมือใดๆ มันเป็นแนวคิด และแนวคิดนั้นคือ ถ้าคุณทำงานภายใต้สมมติฐานว่าคุณกำลังทำงานอยู่ในสภาพแวดล้อมที่เป็นศัตรู ซึ่งอาจมีผู้ไม่หวังดีแฝงตัวอยู่แล้ว คุณก็ต้องทำมาตรการป้องกันเพื่อให้แน่ใจว่าคุณยังสามารถทำงานได้อย่างปลอดภัย ในทางปฏิบัติ แนวคิดของ “perimeter” ไม่มีความหมายอะไรเลยใน zero trust (ด้วยเหตุนี้ zero trust จึงมักถูกเรียกว่า “perimeterless computing” ด้วย)

เนื่องจากคุณสมมติว่าระบบของคุณถูกโจมตีไปแล้ว call ขาเข้าทั้งหมดจาก microservice อื่นๆ จะต้องได้รับการประเมินอย่างเหมาะสม นี่คือ client ที่ผมควรไว้วางใจจริงๆ หรือไม่? ในทำนองเดียวกัน ข้อมูลทั้งหมดควรถูกเก็บอย่างปลอดภัย และ encryption key ทั้งหมดต้องถูกถือครองอย่างมั่นคง และเนื่องจากเราต้องสมมติว่ามีคนกำลังดักฟังอยู่ ข้อมูลอ่อนไหวทั้งหมดที่กำลังเดินทางในระบบของเราจึงต้องถูกเข้ารหัส

ที่น่าสนใจคือ หากคุณนำ zero-trust mindset มาใช้อย่างถูกต้อง คุณสามารถเริ่มทำสิ่งที่ดูค่อนข้างแปลกได้:

[ด้วย zero trust] คุณสามารถทำการตัดสินใจเรื่องการเข้าถึงที่ดูขัดสามัญสำนึกได้จริงๆ เช่น อนุญาตให้เชื่อมต่อไปยัง internal service จากอินเทอร์เน็ต เพราะคุณปฏิบัติต่อเครือข่าย “internal” ของคุณว่าน่าเชื่อถือพอๆ กับอินเทอร์เน็ต (นั่นคือไม่น่าเชื่อถือเลย)

Jan Schaumann 11

ข้อโต้แย้งของ Jan ที่นี่คือ ถ้าคุณสมมติว่าไม่มีอะไรภายในเครือข่ายของคุณที่ควรไว้วางใจ และ trust ต้องถูกสร้างขึ้นใหม่ทุกครั้ง คุณจะสามารถยืดหยุ่นมากขึ้นเกี่ยวกับสภาพแวดล้อมที่ microservice ของคุณอาศัยอยู่—คุณจะไม่คาดหวังว่าสภาพแวดล้อมรอบตัวจะปลอดภัย แต่โปรดจำไว้ว่า zero trust ไม่ใช่สิ่งที่คุณเปิดใช้งานด้วยการกดสวิตช์ มันเป็นหลักการพื้นฐานที่ขับเคลื่อนวิธีที่คุณตัดสินใจทำสิ่งต่างๆ มันต้องขับเคลื่อนการตัดสินใจของคุณเกี่ยวกับวิธีสร้างและพัฒนาระบบของคุณ—มันจะเป็นสิ่งที่คุณต้องลงทุนอย่างต่อเนื่องเพื่อให้ได้ผลตอบแทนกลับมา

It’s a Spectrum (มันคือสเปกตรัม)

ผมไม่ได้หมายความว่าคุณต้องเลือกอย่างใดอย่างหนึ่งอย่างเด็ดขาดระหว่าง implicit trust กับ zero trust ระดับความไว้วางใจ (หรือไม่ไว้วางใจ) ที่คุณมีต่อฝ่ายอื่นในระบบของคุณ สามารถเปลี่ยนแปลงได้ตามความอ่อนไหวของข้อมูลที่กำลังถูกเข้าถึง คุณอาจตัดสินใจ เช่น ใช้แนวคิด zero trust สำหรับ microservice ใดๆ ที่จัดการกับ PII แต่ผ่อนปรนมากขึ้นในพื้นที่อื่นๆ อีกครั้ง ต้นทุนของการนำ security implementation ใดๆ มาใช้ควรได้รับการพิสูจน์ความคุ้มค่า (และขับเคลื่อน) ด้วย threat model ของคุณ ให้ความเข้าใจของคุณเกี่ยวกับภัยคุกคามและผลกระทบที่เกี่ยวข้องเป็นตัวขับเคลื่อนการตัดสินใจของคุณว่า zero trust คุ้มค่าสำหรับคุณหรือไม่

ยกตัวอย่างเช่น ลองมาดู MedicalCo บริษัทที่ผมเคยร่วมงานด้วยซึ่งจัดการข้อมูล healthcare ที่อ่อนไหวเกี่ยวกับบุคคลต่างๆ ข้อมูลทั้งหมดที่บริษัทถือครองถูกจัดประเภทตามแนวทางที่ค่อนข้างสมเหตุสมผลและตรงไปตรงมา:

Public (สาธารณะ)

ข้อมูลที่สามารถแบ่งปันกับฝ่ายภายนอกใดๆ ได้อย่างอิสระ ข้อมูลนี้อยู่ในโดเมนสาธารณะโดยพื้นฐานอยู่แล้ว

Private (ส่วนตัว)

ข้อมูลที่ควรพร้อมใช้งานเฉพาะกับผู้ใช้ที่ล็อกอินเข้าระบบแล้วเท่านั้น การเข้าถึงข้อมูลนี้อาจถูกจำกัดเพิ่มเติมด้วยข้อจำกัดด้าน authorization ซึ่งอาจรวมถึงสิ่งอย่างแผนประกันที่ลูกค้าใช้อยู่

Secret (ลับ)

ข้อมูลที่อ่อนไหวมากๆ เกี่ยวกับบุคคล ซึ่งสามารถเข้าถึงได้โดยคนอื่นนอกเหนือจากตัวบุคคลนั้นในสถานการณ์ที่เจาะจงมากเท่านั้น ซึ่งรวมถึงข้อมูลสุขภาพของบุคคลนั้น

จากนั้น microservice ต่างๆ จะถูกจัดประเภทตามข้อมูลที่อ่อนไหวที่สุดที่พวกมันใช้ และต้องรันในสภาพแวดล้อม (zone) ที่ตรงกันพร้อม control ที่ตรงกัน ดังที่เราเห็นใน Figure 11-5 microservice หนึ่งๆ จะต้องรันใน zone ที่ตรงกับข้อมูลที่อ่อนไหวที่สุดที่มันใช้ ยกตัวอย่างเช่น microservice ที่รันใน public zone จะสามารถใช้ได้เฉพาะข้อมูล public เท่านั้น ในขณะที่ microservice ที่ใช้ทั้งข้อมูล public และ private จะต้องรันใน private zone และ microservice ที่เข้าถึงข้อมูล secret ก็จะต้องรันใน secret zone เสมอ

Figure 11-5. การ deploy microservice ไปยัง zone ที่แตกต่างกันตามความอ่อนไหวของข้อมูลที่พวกมันจัดการ

Microservice ภายใน zone เดียวกันสามารถสื่อสารกันได้ แต่ไม่สามารถเข้าถึงข้อมูลหรือ functionality ใน zone ที่ปลอดภัยกว่าและอยู่ต่ำกว่าได้โดยตรง Microservice ใน zone ที่ปลอดภัยกว่าสามารถเข้าถึง functionality ที่รันอยู่ใน zone ที่ปลอดภัยน้อยกว่าได้ แต่ในทิศทางกลับกันทำไม่ได้

ตรงนี้ MedicalCo ได้ให้ความยืดหยุ่นแก่ตัวเองในการปรับเปลี่ยนแนวทางในแต่ละ zone public zone ที่ปลอดภัยน้อยกว่าสามารถทำงานในลักษณะที่ใกล้เคียงกับสภาพแวดล้อมแบบ implicit trust มากขึ้น ในขณะที่ secret zone สมมติแบบ zero trust หากพูดกันจริงๆ ถ้า MedicalCo นำแนวทาง zero trust มาใช้ทั่วทั้งระบบ การมี microservice ที่ deploy แยกออกไปเป็นแต่ละ zone ก็อาจไม่จำเป็นอีกต่อไป เพราะทุก inter-microservice call จะต้องมี authentication และ authorization เพิ่มเติมอยู่แล้ว แต่ถึงกระนั้น เมื่อคิดถึงเรื่อง defense in depth อีกครั้ง ผมก็อดไม่ได้ที่จะคิดว่าตัวเองก็ยังคงจะพิจารณาแนวทางแบบแบ่ง zone นี้อยู่ดี เมื่อคำนึงถึงความอ่อนไหวของข้อมูล!