สถาปัตยกรรมอ้างอิงด้านความปลอดภัยของระบบคลาวด์แบบไฮบริด

สถาปัตยกรรมอ้างอิงด้านความปลอดภัยของระบบคลาวด์แบบไฮบริด คือแผนงานที่ไม่ผูกมัดกับผู้จำหน่าย ซึ่งแสดงให้เห็นว่ากลไกการควบคุมความปลอดภัยเชื่อมต่อกันอย่างไรระหว่างโครงสร้างพื้นฐานภายในองค์กร คลาวด์ส่วนตัว SaaS และคลาวด์สาธารณะ โดยใช้เพื่อวางแผนการติดตั้งระบบ เปรียบเทียบผู้จำหน่าย อธิบายการออกแบบระบบความปลอดภัยให้กับผู้ตรวจสอบ และวัดความก้าวหน้าในการก้าวสู่โมเดล Zero Trust

บทความนี้นำเสนอแบบจำลองอ้างอิงที่ครบถ้วน: หลักการออกแบบที่อยู่เบื้องหลังแบบจำลองนี้, แผนภาพเชิงตรรกะและแผนภาพการปรับใช้, ข้อมูลอ้างอิงเกี่ยวกับส่วนประกอบ, หกกระแสการไหลของข้อมูล, ขอบเขตการควบคุม, ข้อพิจารณาในการออกแบบเกี่ยวกับอัตลักษณ์, การบันทึกข้อมูล, ความจุ และความทนทาน, การเชื่อมโยงกับมาตรการควบคุมของ CISA และ NIST, ตัวอย่างการปรับใช้ห้าแบบ, และเส้นทางการพัฒนาความพร้อมพร้อมการทดสอบการตรวจสอบความถูกต้อง

บทความนี้เป็นส่วนหนึ่งของคู่มือความปลอดภัยของระบบคลาวด์แบบไฮบริดสำหรับภาพรวมโครงสร้างพื้นฐานของสภาพแวดล้อมแบบไฮบริด โปรดดูที่“สถาปัตยกรรมระบบคลาวด์แบบไฮบริด: องค์ประกอบและแบบการปรับใช้”

หลักการออกแบบที่อยู่เบื้องหลังแบบจำลองอ้างอิง

แบบจำลองอ้างอิงนี้ตั้งอยู่บนหลักการสี่ข้อที่นำมาจากแนวทาง Zero Trust ของ NIST และ CISA.

1. แยกการตัดสินใจออกจากกระบวนการบังคับใช้NISTSP 800-207แยกจุดตัดสินใจนโยบาย (PDP) ซึ่งกำหนดว่าจะอนุญาตการเข้าถึงหรือไม่ ออกจากจุดบังคับใช้นโยบาย (PEP) ซึ่งเปิดใช้งาน ตรวจสอบ หรือยุติการเชื่อมต่อ มี PDP หนึ่งจุด แต่มี PEP หลายจุด
2. อย่าให้ความเชื่อถือเพียงเพราะตำแหน่งในเครือข่ายการอยู่ในเครือข่าย LAN ของบริษัทไม่ใช่เหตุผลที่จะข้ามขั้นตอนการตรวจสอบหรือการยืนยันตัวตน NISTSP 800-215อธิบายว่าการสูญเสียขอบเขตเครือข่ายที่มีความหมายเป็นลักษณะสำคัญของเครือข่ายองค์กรในปัจจุบัน
3. ปกป้องข้อมูลตามประเภท ไม่ใช่ตามตำแหน่งการควบคุมจะติดตามประเภทข้อมูลไปทุกที่ที่ข้อมูลนั้นถูกย้ายไป
4. สมมติว่าความพึ่งพาใดก็ตามอาจเกิดข้อผิดพลาดได้ผู้ให้บริการระบุตัวตน บริการคลาวด์ และลิงก์ WAN อาจหยุดทำงานทั้งหมด สถาปัตยกรรมนี้กำหนดว่าสิ่งที่จะเกิดขึ้นเมื่อสิ่งเหล่านั้นหยุดทำงาน

คู่มือปฏิบัติSP 1800-35 ของ NISTเรื่อง “การนำสถาปัตยกรรม Zero Trust มาใช้” ซึ่งเผยแพร่ในเดือนมิถุนายน 2568 ร่วมกับผู้จำหน่าย 24 ราย แสดงตัวอย่างการนำหลักการเหล่านี้ไปใช้ 19 ตัวอย่าง ในทั้งสภาพแวดล้อมภายในองค์กรและสภาพแวดล้อมบนคลาวด์ และถือเป็นคู่มือที่มีประโยชน์สำหรับโมเดลนี้

แผนผังสถาปัตยกรรม

มีสองมุมมองที่อธิบายสถาปัตยกรรมอ้างอิง ได้แก่ มุมมองเชิงตรรกะของชั้นต่าง ๆ และมุมมองการปรับใช้ที่แสดงตำแหน่งที่ส่วนประกอบทำงาน

สถาปัตยกรรมเชิงตรรกะ

สถาปัตยกรรมเชิงตรรกะมีสามชั้น ได้แก่ ชั้นควบคุมแบบรวมศูนย์ ชั้นบังคับใช้แบบกระจาย และชั้นการมองเห็นแบบแบ่งปัน

ชั้นควบคุมกำหนดนโยบายเพียงครั้งเดียว ชั้นบังคับใช้นโยบายจะนำไปใช้ทุกที่ที่การไหลของข้อมูลเกิดขึ้น ส่วนชั้นการมองเห็นจะรวบรวมข้อมูลวัดผลจากทุกจุดบังคับใช้ และส่งสัญญาณความเสี่ยงกลับไปยังนโยบาย

โครงสร้างการปรับใช้

มุมมองการปรับใช้แสดงตำแหน่งที่จุดบังคับใช้แต่ละจุดทำงานอยู่จริงในสำนักงานใหญ่ สาขา พื้นที่คลาวด์ และผู้ใช้ระยะไกล

ข้อมูลอ้างอิงของส่วนประกอบ

แต่ละส่วนประกอบมีบทบาท ตำแหน่ง และชุดข้อกำหนดเฉพาะสำหรับระบบไฮบริดที่กำหนดไว้

การไหลของจราจร

มีหกเส้นทางจราจรที่ครอบคลุมพื้นที่ส่วนใหญ่ของเขตที่อยู่อาศัยแบบไฮบริด และแต่ละเส้นทางควรมีจุดบังคับใช้กฎระเบียบที่บันทึกไว้หนึ่งจุด และจุดถอดรหัสหนึ่งจุด

ขั้นตอน 1: ผู้ใช้ในสำนักงานเชื่อมต่อกับอินเทอร์เน็ตหรือ SaaS

ผู้ใช้จะยืนยันตัวตนผ่านผู้ให้บริการระบุตัวตน (Identity Provider) การส่งข้อมูลจะส่งไปยังเกตเวย์ท้องถิ่น ซึ่งจะทำการถอดรหัส ตรวจสอบภัยคุกคาม และบังคับใช้นโยบายเว็บและนโยบายการเข้าถึง ก่อนที่จะส่งต่อเซสชันที่อยู่ภายใต้การคุ้มครองข้อมูลไปยังคลาวด์ของผู้ให้บริการ เพื่อตรวจสอบตามนโยบายเดียวกัน ให้บันทึกการยุติ TLS และการเข้ารหัสใหม่ตลอดเส้นทางนี้ และหลีกเลี่ยงการตรวจสอบซ้ำซ้อน ตามแนวทางของ NSAเกี่ยวกับการจัดการความเสี่ยงจากการตรวจสอบ TLS

ขั้นตอนที่ 2: ผู้ใช้จากระยะไกลสู่ SaaS

เอเจนต์ที่ปลายทางหรือเบราว์เซอร์จะควบคุมการส่งข้อมูลไปยังจุดให้บริการบนคลาวด์ที่ได้รับการอนุมัติและอยู่ใกล้ที่สุด นโยบายที่ใช้เป็นชุดเดียวกันกับใน Flow 1 CASB เพิ่มการควบคุมเฉพาะสำหรับ SaaS เช่น การจำกัดผู้เช่า (tenant restrictions) และ DLP ระดับกิจกรรม (activity-level DLP)

ขั้นตอนที่ 3: ผู้ใช้ไปยังแอปพลิเคชันส่วนตัว

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

ขั้นตอน 4: จากภาระงานหนึ่งไปยังภาระงานอื่น

การส่งข้อมูลระหว่างบริการกับบริการระหว่างศูนย์ข้อมูลและงาน IaaS ใช้ข้อมูลระบุตัวตนของงาน TLS แบบสองทาง และกฎการแบ่งส่วน แหล่งนโยบายเดียวกันนี้กำหนดว่าบริการใดสามารถสื่อสารกันได้

ขั้นตอนที่ 5: ข้อมูลที่เก็บไว้ในบริการคลาวด์

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

ขั้นตอนที่ 6: ตัวแทน AI และบัญชีบริการ

เอเยนต์ AI และระบบอัตโนมัติมักมีสิทธิ์เข้าถึงระดับผู้ใช้ และเรียกใช้ API ภายในผ่านช่องเชื่อมต่อที่มีอายุการใช้งานยาวนาน เช่น WebSockets ซึ่งเริ่มต้นจากภายในเครือข่าย ให้เอเยนต์แต่ละตัวมีตัวตนและสิทธิ์เฉพาะสำหรับแต่ละแอปพลิเคชัน ส่งข้อมูลผ่านจุดควบคุมภายใน และใช้ระบบ DLP กับข้อมูลที่ส่งไปยังบริการ AI ภายนอก

ขอบเขตการควบคุม

ควรกำหนดขอบเขตการควบคุมรอบสิ่งที่ต้องได้รับการคุ้มครอง ไม่ใช่รอบตำแหน่งที่อุปกรณ์ตั้งอยู่

ขอบเขตเขตอำนาจมักถูกมองข้าม หากข้อมูลที่ถอดรหัสแล้ว บันทึกการตรวจสอบ หรือสำเนาเหตุการณ์ DLP ออกจากเขตอำนาจ ระบบอาจละเมิดข้อผูกพันด้านความเป็นเจ้าของข้อมูล แม้ข้อมูลที่จัดเก็บจะไม่ถูกย้ายไปไหนก็ตาม ดูหัวข้อ“ความเป็นเจ้าของข้อมูล” ในส่วน “ความปลอดภัยของระบบคลาวด์แบบไฮบริด”

ความปลอดภัยเครือข่ายสำหรับระบบคลาวด์แบบไฮบริด

ความปลอดภัยของเครือข่ายในสภาพแวดล้อมแบบไฮบริด ได้เปลี่ยนจากการป้องกันขอบเขตเครือข่ายเป็นการป้องกันการเชื่อมต่อแต่ละจุด

• แทนที่ความเชื่อถือแบบ site-to-site แบบทั่วไปด้วยระบบแบ่งส่วนและการเข้าถึงตามแอปพลิเคชัน
• รักษาช่องทางที่เข้ารหัส (IPsec, GRE หรือการเชื่อมต่อส่วนตัว) ระหว่างไซต์และภูมิภาคคลาวด์ แต่ไม่ควรถือว่าการเป็นสมาชิกของช่องทางดังกล่าวเป็นการอนุญาต
• ควบคุมการไหลของข้อมูลอย่างมีจุดมุ่งหมาย: ใช้ไฟล์พร็อกซีหรือ PAC ที่กำหนดไว้อย่างชัดเจนสำหรับเครือข่ายสำนักงานที่ได้รับการจัดการ, ตัวแทนหรือการควบคุมเบราว์เซอร์สำหรับผู้ใช้ที่เคลื่อนที่, และอุโมงค์เครือข่ายสำหรับสาขา
• กำหนดว่าส่วนประกอบใดจะถอดรหัสแต่ละโฟลว์ เพื่อไม่ให้โฟลว์ใดถูกถอดรหัสสองครั้ง
• บันทึกข้อมูลที่ทุกจุดตรวจสอบและวิเคราะห์ข้อมูลแบบรวมศูนย์

NIST SP 800-215 วิเคราะห์ตัวเลือกเหล่านี้ ซึ่งรวมถึง ZTNA, การแบ่งส่วนเครือข่ายแบบไมโคร (microsegmentation), ขอบเขตที่กำหนดโดยซอฟต์แวร์ (software-defined perimeters) และโมเดล Secure Access Service Edge (SASE) ที่รวมบริการเครือข่ายและบริการความปลอดภัยเข้าด้วยกัน

ข้อพิจารณาในการออกแบบ

มีสี่ด้านของการออกแบบที่กำหนดว่าสถาปัตยกรรมนั้นจะทำงานได้จริงหรือไม่ ได้แก่: ความเป็นเอกลักษณ์, การบันทึกข้อมูล, ความจุ, และพฤติกรรมเมื่อเกิดข้อผิดพลาด

สถาปัตยกรรมอัตลักษณ์

อัตลักษณ์เป็นข้อมูลนำเข้าแรกในทุกการตัดสินใจเกี่ยวกับการเข้าถึง ดังนั้น สถาปัตยกรรมอ้างอิงจึงถือว่าอัตลักษณ์ทั้งสี่ประเภทเป็นปัจจัยสำคัญอันดับแรก

• ผู้ใช้ในองค์กรผู้ให้บริการระบุตัวตนที่เชื่อถือได้เพียงรายเดียว ซึ่งเชื่อมต่อแบบเฟเดอเรชันกับผู้ให้บริการคลาวด์และแอปพลิเคชัน SaaS ทุกแห่ง พร้อมด้วยระบบยืนยันตัวตนหลายขั้นตอน (MFA) ที่ต้านทานการฟิชชิ่ง และระบบการเข้าถึงตามเงื่อนไข ข้อมูลกลุ่มและบทบาทควรมาจากแหล่งเดียว เพื่อป้องกันไม่ให้สิทธิ์การใช้งานแตกต่างกันไปในแต่ละสภาพแวดล้อม
• อุปกรณ์.ควรประเมินข้อมูลประจำตัวและสภาพของอุปกรณ์ (สถานะการจัดการ, ระดับการอัปเดตแพตช์, การเข้ารหัสดิสก์, การป้องกันจุดปลาย) สำหรับผู้ใช้ทั้งในสถานที่และผู้ใช้ระยะไกล
• งานและบริการแอปพลิเคชันและบริการยืนยันตัวตนซึ่งกันและกันโดยใช้ตัวตนของงานและ TLS แบบสองทาง แทนที่จะใช้ข้อมูลลับที่แชร์ร่วมกันหรือตำแหน่งบนเครือข่าย
• เอเยนต์ AI และระบบอัตโนมัติแต่ละเอเยนต์จะได้รับตัวตนเฉพาะ สิทธิ์การใช้งานที่กำหนดขอบเขต และผู้ดูแลที่เป็นมนุษย์ซึ่งต้องรับผิดชอบ ดังนั้นการดำเนินการของเอเยนต์จึงสามารถได้รับการอนุมัติ บันทึก และเพิกถอนได้อย่างอิสระ

มีรายละเอียดการออกแบบสองข้อที่มักถูกมองข้ามได้ง่าย ข้อแรก คือ ควรประเมินเซสชันใหม่เมื่อบริบทเปลี่ยนแปลง เช่น เมื่ออุปกรณ์ไม่เป็นไปตามข้อกำหนดอีกต่อไป แทนที่จะถือว่าเซสชันนั้นน่าเชื่อถือจนกว่าจะหมดอายุ ข้อที่สอง คือ ควรกำหนดสิทธิ์การเข้าถึงฉุกเฉิน (break-glass access) สำหรับผู้ดูแลระบบ ซึ่งสามารถใช้งานได้เมื่อผู้ให้บริการระบุตัวตนไม่สามารถใช้งานได้ พร้อมด้วยมาตรการควบคุมที่เข้มงวดและระบบแจ้งเตือนเมื่อมีการใช้งานสิทธิ์ดังกล่าว

การบันทึกข้อมูลและการวัดระยะไกล

การบันทึกข้อมูลในสถาปัตยกรรมแบบไฮบริดต้องสนับสนุนการตรวจจับ การสืบสวน และการปฏิบัติตามกฎระเบียบ พร้อมทั้งต้องปฏิบัติตามข้อจำกัดเกี่ยวกับสถานที่ที่ข้อมูลสามารถถูกส่งไปได้

• ข้อมูลที่ควรเก็บรวบรวมทุกจุดบังคับใช้ควรบันทึกข้อมูลเกี่ยวกับผู้ใช้ อุปกรณ์ แอปพลิเคชัน หรือปลายทาง การตัดสินใจตามนโยบาย กฎที่ตรงกัน และการจัดประเภทข้อมูลที่เกี่ยวข้อง ให้ใช้คีย์การเชื่อมโยงข้อมูลทั่วไป (ID ผู้ใช้ ID อุปกรณ์ ID เซสชัน) เพื่อให้สามารถรวมเหตุการณ์จากระบบบังคับใช้ในท้องถิ่นและระบบคลาวด์เข้าด้วยกันได้
• สถานที่เก็บข้อมูลผู้เก็บข้อมูลท้องถิ่นที่แต่ละไซต์หลักจะเก็บข้อมูลเหตุการณ์ไว้ก่อน แล้วส่งต่อไปยัง SIEM กลาง สิ่งนี้ช่วยรักษาบันทึกไว้แม้ในช่วงที่เครือข่าย WAN หยุดทำงาน และช่วยให้สามารถส่งข้อมูลต่อไปยังจุดหมายเฉพาะได้
• ข้อมูลที่ควรส่งต่อ:ส่งต่อข้อมูลเมตาดาต้าที่จำเป็นสำหรับการตรวจจับ เก็บรักษาหลักฐาน DLP ทั้งหมดและส่วนเนื้อหาที่ถูกคัดลอกไว้ในเขตอำนาจศาลที่ข้อมูลดังกล่าวถูกบันทึกไว้ โดยจำกัดการเข้าถึงเฉพาะผู้สอบสวนที่ได้รับอนุญาตเท่านั้น
• การเก็บรักษาข้อมูลให้การเก็บรักษาข้อมูลสอดคล้องกับข้อกำหนดทางกฎหมายตามประเภทข้อมูลและเขตอำนาจศาล และบันทึกไว้เป็นเอกสาร
• ความน่าเชื่อถือป้องกันไม่ให้บันทึกถูกแก้ไข และแจ้งเตือนเมื่อมีช่องว่าง ซึ่งอาจเป็นสัญญาณทั้งความล้มเหลวและการโจมตี

ความจุและการกำหนดขนาด

จุดตรวจสอบการบังคับใช้ในท้องถิ่นต้องได้รับการออกแบบให้รองรับปริมาณการรับส่งข้อมูลที่ถอดรหัสแล้วในช่วงเวลาที่มีการใช้งานสูงสุด ซึ่งเป็นสาเหตุหลักของปัญหาด้านประสิทธิภาพในการใช้งานแบบไฮบริด

• วัดปริมาณการส่งข้อมูลสูงสุดและอัตราการเชื่อมต่อต่อแต่ละไซต์ รวมถึงสัดส่วนของปริมาณการส่งข้อมูลที่จะถูกถอดรหัส TLS เป็นกระบวนการที่ใช้ทรัพยากรการประมวลผลสูง
• จัดกลุ่มตามขนาดโดยเผื่อพื้นที่สำรองสำหรับการสลับระบบ (failover) เพื่อป้องกันไม่ให้การสูญเสียโหนดหนึ่งตัวทำให้โหนดที่เหลือต้องรับภาระมากเกินไป
• พิจารณาถึงการเพิ่มขึ้นของปริมาณการส่งข้อมูลที่เข้ารหัส การส่งไฟล์ขนาดใหญ่ และเซสชัน AI และการทำงานร่วมกันที่มีระยะเวลาทำงานยาวนาน
• วางแผนการเพิ่มกำลังประมวลผล อุปกรณ์เสมือนและอุปกรณ์ในคอนเทนเนอร์สามารถขยายขนาดได้เร็วกว่าอุปกรณ์ฮาร์ดแวร์เฉพาะ
• สำหรับจุดให้บริการบนคลาวด์ (PoP) ให้ตรวจสอบความจุของภูมิภาคและตัวเลือกการสลับระบบสำรองกับผู้ให้บริการ โดยเฉพาะอย่างยิ่งในกรณีที่ข้อจำกัดด้านสถานที่ตั้งทำให้คุณไม่สามารถใช้ภูมิภาคบางแห่งได้

ความยืดหยุ่นและพฤติกรรมเมื่อเกิดความล้มเหลว

สถาปัตยกรรมอ้างอิงจะยังไม่สมบูรณ์จนกว่าจะกำหนดไว้ว่าสิ่งที่จะเกิดขึ้นเมื่อแต่ละส่วนที่ขึ้นอยู่กับกันเกิดข้อผิดพลาด

• บริการคลาวด์ของผู้ให้บริการไม่สามารถใช้งานได้:การบังคับใช้นโยบายเว็บและแอปพลิเคชันส่วนตัวในระบบท้องถิ่นจะยังคงดำเนินต่อไปโดยใช้ข้อมูลนโยบายที่เก็บไว้ในแคช ส่วนบริการที่ส่งมาจากคลาวด์ ซึ่งรวมถึงการปกป้องข้อมูลremote browser isolation, การควบคุมความปลอดภัยด้วย AI, CASB และการจัดการสถานะความปลอดภัยของข้อมูล จะยังไม่ถูกนำไปใช้จนกว่าเส้นทางจะกลับมาทำงานปกติ; ผู้ใช้ระยะไกลจะเปลี่ยนไปใช้จุดให้บริการอื่นแทน
• ผู้ให้บริการระบุตัวตนไม่สามารถใช้งานได้:กำหนดว่าเซสชันที่มีอยู่จะดำเนินต่อไปหรือไม่ และว่ามีตัวเลือกสำรองในระบบท้องถิ่นหรือไม่
• เมื่อเครือข่าย WAN หรือการเชื่อมต่ออินเทอร์เน็ตของไซต์เกิดขัดข้อง:ZTNA ในพื้นที่จะยังคงทำให้การเข้าถึงแอปพลิเคชันในพื้นที่จากภายในไซต์ทำงานได้
• ข้อผิดพลาดของเกตเวย์ท้องถิ่น:คอมพิวเตอร์ในคลัสเตอร์หรือจุดเชื่อมต่อบนคลาวด์จะรับหน้าที่แทนตามนโยบายเดียวกัน
• แบบเปิดเมื่อเกิดข้อผิดพลาด หรือแบบปิดเมื่อเกิดข้อผิดพลาด:ตัดสินใจตามประเภทการจราจร และทำให้สถานะดังกล่าวมองเห็นได้โดยทีมปฏิบัติการ

ดูHybrid SSE Resilience: Failover and Recoveryเพื่อทราบแผนการทดสอบ

การกำหนดการแมปปิ้งกับ CISA และ NIST

การจัดให้แต่ละส่วนประกอบสอดคล้องกับกรอบงานที่ได้รับการยอมรับ จะทำให้สถาปัตยกรรมอ้างอิงกลายเป็นหลักฐานสำหรับผู้ตรวจสอบ และเป็นรายการตรวจสอบสำหรับผู้ดำเนินการ

ตารางนี้แสดงการเชื่อมโยงระหว่างองค์ประกอบกับเสาหลักของแบบจำลองระดับความพร้อม Zero Trustของ CISA และกับกลุ่มมาตรการควบคุมที่เป็นตัวแทนในNIST SP 800-53 Rev. 5.

การกำหนดนี้ถือเป็นจุดเริ่มต้น องค์กรแต่ละแห่งควรตรวจสอบความเหมาะสมของการควบคุมตามเกณฑ์พื้นฐานและขอบเขตการกำกับดูแลของตนเอง

ตัวอย่างการนำไปใช้

โมเดลอ้างอิงเดียวกันนี้สามารถปรับให้เหมาะสมกับอุตสาหกรรมต่าง ๆ ได้โดยการปรับเปลี่ยนจุดบังคับใช้ ไม่ใช่ด้วยการออกแบบนโยบายใหม่

ตัวอย่าง 1: ธนาคารระดับภูมิภาค

สำนักงานใหญ่และศูนย์ข้อมูลใช้เกตเวย์ SWG และ ZTNA ในท้องถิ่น เพื่อให้ข้อมูลของลูกค้าถูกถอดรหัสและตรวจสอบเฉพาะบนโครงสร้างพื้นฐานที่ธนาคารควบคุมเท่านั้น การส่งข้อมูลของสาขาใช้อุปกรณ์ในท้องถิ่นหรือช่องทางเชื่อมต่อ (tunnel) ไปยังศูนย์ข้อมูลที่ใกล้ที่สุด พนักงานที่ทำงานจากระยะไกลใช้จุดเชื่อมต่อบนคลาวด์ (cloud points of presence) ที่จำกัดอยู่ในพื้นที่ภายในภูมิภาคเท่านั้น บันทึกการตรวจสอบจะเก็บไว้ภายในประเทศ รูปแบบนี้สนับสนุนข้อกำหนดด้านความเสี่ยง ICT ของ DORA และข้อกำหนดของฝ่ายที่สามสำหรับสถาบันในสหภาพยุโรป (EU) พร้อมทั้งยังคงอนุญาตให้ใช้ CASB บนคลาวด์สำหรับบริการ SaaS

ตัวอย่างที่ 2: ผู้ผลิตที่มีเครือข่าย OT

ไฟร์วอลล์แบบแบ่งส่วน (segmentation firewall) แยกเครือข่าย OT ของโรงงานออกจากเครือข่าย IT ของบริษัท ระบบ OT สามารถเข้าถึงจุดหมายปลายทางสำหรับการอัปเดตและข้อมูลวัดระยะไกลที่ได้รับการอนุมัติเท่านั้น ผ่าน SWG ท้องถิ่น วิศวกรสามารถเข้าถึงระบบโรงงานผ่าน ZTNA ท้องถิ่น พร้อมกับการตรวจสอบสถานะอุปกรณ์ หากเครือข่าย WAN หรือบริการคลาวด์เกิดข้อผิดพลาด การเข้าถึงและตรวจสอบระบบโรงงานจะยังคงดำเนินการต่อไปในระบบท้องถิ่น

ตัวอย่าง 3: หน่วยงานภาครัฐ

เครือข่ายที่ได้รับการจัดประเภทหรือเครือข่ายที่แยกตัวออกจากระบบจำเป็นต้องใช้ส่วนประกอบที่ได้รับการสนับสนุนอย่างชัดเจนเพื่อทำงานได้โดยไม่ต้องพึ่งพาบริการจากภายนอก ส่วนเครือข่ายที่ไม่ได้รับการจัดประเภทอาจใช้บริการคลาวด์ที่ได้รับอนุญาตอย่างเหมาะสมสำหรับพนักงานที่ทำงานจากระยะไกล ให้บันทึกการซิงโครไนซ์นโยบาย ความสัมพันธ์ด้านอัตลักษณ์ การอัปเดต และความสัมพันธ์ด้านใบอนุญาต และควบคุมการเปลี่ยนแปลงของข้อยกเว้นที่เฉพาะเจาะจงกับสภาพแวดล้อม

ตัวอย่างที่ 4: ระบบสุขภาพระดับภูมิภาค

ระบบบันทึกสุขภาพอิเล็กทรอนิกส์และระบบภาพทางการแพทย์ทำงานในศูนย์ข้อมูลของระบบสุขภาพ สถานีงานคลินิกในโรงพยาบาลใช้เกตเวย์ท้องถิ่น ดังนั้นข้อมูลผู้ป่วยในข้อมูลการสื่อสารผ่านเว็บและ SaaS จึงถูกตรวจสอบภายในสถานที่ อุปกรณ์ทางการแพทย์ตั้งอยู่ในโซนที่แบ่งแยกกัน โดยมีการจำกัดการเข้าถึงจากภายนอกอย่างเข้มงวด แพทย์และบุคลากรทางการแพทย์ที่ทำงานจากระยะไกลสามารถเข้าถึงระบบบันทึกสุขภาพอิเล็กทรอนิกส์ (EHR) ผ่านตัวกลาง ZTNA บนคลาวด์ ซึ่งมีการกำหนดข้อกำหนดสำหรับอุปกรณ์ที่ได้รับการจัดการ และกฎ DLP สำหรับข้อมูลสุขภาพที่ได้รับการคุ้มครองถูกนำไปใช้อย่างเท่าเทียมกันในทั้งสองช่องทาง เพื่อสนับสนุนมาตรการป้องกันตามกฎความปลอดภัยของ HIPAA

ตัวอย่างที่ 5: ผู้ค้าปลีกระดับโลก

ร้านค้าใช้เกตเวย์หรืออุโมงค์ขนาดเล็กของสาขาเพื่อเชื่อมต่อกับศูนย์กลางระดับภูมิภาค โดยระบบจุดขาย (POS) อยู่ในสภาพแวดล้อมข้อมูลผู้ถือบัตรที่แบ่งส่วน ซึ่งข้อมูลดังกล่าวจะส่งถึงเพียงผู้ประมวลผลการชำระเงินเท่านั้น การท่องเว็บของพนักงานบริษัทและพนักงานร้านจะถูกตรวจสอบที่ศูนย์กลางระดับภูมิภาคหรือจุดให้บริการบนคลาวด์ โดยข้อมูลการรับส่งข้อมูลจากยุโรปจะถูกจำกัดให้อยู่ภายในภูมิภาคของสหภาพยุโรป (EU) และบันทึกการใช้งานจะถูกเก็บรักษาภายในภูมิภาคดังกล่าว ระบบของร้านยังคงทำงานได้แม้เกิดการหยุดชะงักของเครือข่าย WAN เนื่องจากการแบ่งส่วนและกฎการเข้าถึงในท้องถิ่นไม่ขึ้นอยู่กับคลาวด์ ซึ่งสนับสนุนข้อกำหนดด้านการแบ่งส่วนและบันทึกการใช้งานตามมาตรฐาน PCI DSS

ขั้นตอนการพัฒนาและตรวจสอบความถูกต้อง

ใช้ขั้นตอนความพร้อมของ CISA เพื่อแบ่งการนำระบบมาใช้เป็นระยะ ๆ และใช้การทดสอบที่สามารถทำซ้ำได้เพื่อพิสูจน์ว่าแต่ละขั้นตอนทำงานได้อย่างถูกต้อง

เส้นทางการเติบโต

องค์กรต่าง ๆ มักไม่ค่อยนำสถาปัตยกรรมอ้างอิงมาใช้อย่างครบถ้วนในครั้งเดียว; แบบจำลองของ CISA อธิบายถึงสี่ขั้นตอน (แบบดั้งเดิม, ขั้นต้น, ขั้นสูง และขั้นสูงสุด) ซึ่งถือเป็นแผนงานที่มีประโยชน์

ใช้ช่องว่างระหว่างขั้นตอนปัจจุบันกับขั้นตอนต่อไปเป็นพื้นฐานในการจัดทำแผนแบบเป็นขั้นตอน

การตรวจสอบความถูกต้องของสถาปัตยกรรม

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

• ส่ง URL ที่ทราบว่ามีความอันตราย ไฟล์มัลแวร์สำหรับการทดสอบ และเอกสารทดสอบ DLP ผ่านทุกจุดบังคับใช้ และยืนยันว่าผลลัพธ์ที่ได้เป็นเหมือนกันกับเส้นทางคลาวด์ที่มีอยู่ บันทึกพฤติกรรมที่คาดการณ์ไว้ของมาตรการควบคุมที่ปรับใช้ผ่านคลาวด์ เมื่อเส้นทางดังกล่าวถูกขัดขวาง
• ตรวจสอบให้แน่ใจว่าข้อมูลในแต่ละโฟลว์ถูกถอดรหัสเพียงครั้งเดียวเท่านั้น
• ลองเข้าถึงแอปพลิเคชันส่วนตัวจากภายในสถานที่ จากระยะไกล และจากอุปกรณ์ที่ไม่ได้จัดการ แล้วตรวจสอบผลลัพธ์ที่คาดไว้
• บล็อกการเข้าถึงจากเว็บไซต์ไปยังระบบคลาวด์ของผู้จำหน่าย และตรวจสอบให้แน่ใจว่าการบังคับใช้มาตรการในระบบท้องถิ่นยังคงดำเนินต่อไป
• ตรวจสอบให้แน่ใจว่าบันทึกจากทุกจุดบังคับใช้ถูกส่งไปยัง SIEM และกฎการเก็บรักษาข้อมูลได้รับการปฏิบัติตาม

Skyhigh สอดคล้องกับสถาปัตยกรรมอ้างอิงอย่างไร

Skyhigh Hybrid SSE Meshครอบคลุมส่วนควบคุม (คอนโซลหนึ่งเครื่องและเครื่องยนต์นโยบายที่นโยบายถูกส่งเป็นโค้ด), การบังคับใช้ในท้องถิ่น (อุปกรณ์ SWG ในสถานที่ที่มีฟังก์ชันตรวจสอบ TLS และ ZTNA ในท้องถิ่น), การบังคับใช้บนคลาวด์ (SWG บนคลาวด์, CASB, ZTNA และ RBI), การควบคุมระดับเบราว์เซอร์ และ DSPM (Skyhigh Security).

เพื่อป้องกันรหัสตรวจสอบและใช้ระบบแซนด์บ็อกซ์ภายในองค์กร โปรดตรวจสอบการผสานรวมที่รองรับ เวอร์ชันผลิตภัณฑ์ และข้อกำหนดการติดตั้งกับ Skyhigh อย่าสมมติว่า HSM รองรับเกตเวย์หรือบริการที่เลือกไว้

แหล่งข้อมูล

1. NISTSP 800-207: สถาปัตยกรรม Zero Trust(สิงหาคม 2020).https://csrc.nist.gov/pubs/sp/800/207/final
2. NISTSP 800-215: คู่มือการจัดตั้งโครงสร้างเครือข่ายองค์กรที่ปลอดภัย(พฤศจิกายน 2022).https://csrc.nist.gov/pubs/sp/800/215/final
3. NIST NCCoE.SP 1800-35: การนำสถาปัตยกรรม Zero Trust มาใช้(มิถุนายน 2025).https://csrc.nist.gov/pubs/sp/1800/35/final
4. NISTSP 800-53 Rev. 5: มาตรการควบคุมด้านความปลอดภัยและความเป็นส่วนตัวสำหรับระบบข้อมูลและองค์กร https://csrc.nist.gov/pubs/sp/800/53/r5/upd1/final
5. CISA.แบบจำลองระดับความพร้อมของ Zero Trust, เวอร์ชัน 2.0. https://www.cisa.gov/zero-trust-maturity-model
6. NSA.การจัดการความเสี่ยงจากการตรวจสอบความปลอดภัยชั้นการส่งข้อมูล(พฤศจิกายน 2019).https://media.defense.gov/2019/Nov/18/2002212783/-1/-1/0/MANAGING%20RISK%20FROM%20TLS%20INSPECTION_20191106.PDF
7. สหภาพยุโรป.กฎระเบียบ (EU) 2022/2554 (พระราชบัญญัติความยืดหยุ่นในการดำเนินงานดิจิทัล). https://eur-lex.europa.eu/eli/reg/2022/2554/oj
8. กระทรวงสาธารณสุขและบริการมนุษย์ของสหรัฐอเมริกา (U.S. HHS).กฎความปลอดภัย HIPAA. https://www.hhs.gov/hipaa/for-professionals/security/index.html
9. คณะกรรมการมาตรฐานความปลอดภัย PCI.PCI DSS v4.0.1(คลังเอกสาร).https://www.pcisecuritystandards.org/document_library/
10. Skyhigh Security. “การปรับปรุง Symantec EdgeSecure Web Gateway ให้ทันสมัยด้วย Skyhigh Hybrid SSE Mesh” (15 กรกฎาคม 2026).https://www.skyhighsecurity.com/industry-perspectives/modernizing-your-symantec-edge-secure-web-gateway-with-skyhigh-hybrid-sse-mesh.html
11. Skyhigh Security. “การนำระบบไฮบริดมาใช้กลายเป็นเรื่องที่ง่ายขึ้นด้วยแพลตฟอร์ม Skyhigh SSE” (3 ตุลาคม 2024).https://www.skyhighsecurity.com/cloud-security/adopting-hybrid-just-got-easier-with-skyhigh-sse-platform.html