Jay Chaudhry & Zscaler: Zero Trust ถูกออกแบบให้สเกลกับคลาวด์

เรื่องนี้อธิบายอะไร (มากกว่าโปรไฟล์ผู้ก่อตั้ง)

นี่ไม่ใช่ชีวประวัติของ Jay Chaudhry แต่เป็นเรื่องราวเชิงปฏิบัติว่ากลุ่ม Zscaler ช่วยเปลี่ยนโฉมความปลอดภัยองค์กรอย่างไร—และทำไมทางเลือกทั้งเชิงเทคนิคและเชิงพาณิชย์ของพวกเขาถึงมีความหมาย

คุณจะได้เรียนรู้สองเรื่องพร้อมกัน:

• แบบจำลองความปลอดภัย: Zero trust ทำงานอย่างไรเมื่ิอแอปและผู้ใช้กระจายอยู่บนบริการคลาวด์ สำนักงาน และบ้าน
• แบบจำลองธุรกิจ: บริษัทความปลอดภัยถูกนำไปใช้ในองค์กรขนาดใหญ่ที่เปลี่ยนช้า ซื้อผ่านพันธมิตร และหลีกเลี่ยงการโยกย้ายที่มีความเสี่ยง อย่างไร

ความหมายของ "ความปลอดภัยองค์กรยุคใหม่" (ภาษาง่าย)

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

เสาหลักสามข้อที่เราจะกลับมาพูดถึงบ่อยๆ

1. การให้บริการจากคลาวด์: ฟังก์ชันความปลอดภัยย้ายจากกล่องออน-พรอมไปเป็นบริการที่ขยายตัวได้ทั่วโลก
2. Zero trust: การเข้าถึงขึ้นกับตัวตน บริบท และนโยบาย ไม่ใช่ตำแหน่งเครือข่าย
3. การจัดจำหน่าย: ความปลอดภัยองค์กรแพร่ผ่านความเป็นจริงด้านการจัดซื้อ: พันธมิตรช่องทาง ผู้เล่นเก่า และการเปิดตัวที่ทำซ้ำได้

สิ่งที่คุณจะนำไปใช้ได้

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

Jay Chaudhry ในหน้าเดียว: มุมมองผู้ก่อตั้ง

Jay Chaudhry เป็นผู้ประกอบการต่อเนื่องที่รู้จักกันดีในฐานะผู้ก่อตั้งและ CEO ของ Zscaler บริษัทที่ผลักดันความปลอดภัยองค์กรจากการ "ปกป้องเครือข่ายของบริษัท" ไปสู่การ "ปกป้องผู้ใช้และแอปไม่ว่าจะอยู่ที่ไหน" ก่อน Zscaler เขาสร้างและขายสตาร์ทอัพด้านความปลอดภัยหลายแห่ง ทำให้เขาเห็นพัฒนาการของพฤติกรรมผู้โจมตีและการเปลี่ยนแปลงของ IT ในองค์กรได้ชัดเจน

ปัญหาที่เขาเลือกไล่ตาม

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

การเปลี่ยนนี้สร้างทางเลือกที่เจ็บปวดสำหรับทีม IT:

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

สมมติฐานก่อตั้งของ Zscaler คือความปลอดภัยต้องตามผู้ใช้ ไม่ใช่ตามอาคาร

วิสัยทัศน์ที่นำโดยผู้ก่อตั้งซึ่งหล่อหลอมหมวดหมู่

สิ่งที่โดดเด่นคือวิสัยทัศน์ของผู้ก่อตั้งที่มีอิทธิพลต่อกลยุทธ์ของบริษัทตั้งแต่แรก:

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

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

ทำไมโมเดลเพอริมิเตอร์เดิมถึงเริ่มล้มเหลว

มาหลายปี ความปลอดภัยองค์กรถูกสร้างบนแนวคิดง่ายๆ: เก็บ "สิ่งที่ดี" ไว้ภายในเครือข่ายของบริษัท แล้วสร้างกำแพงล้อมรอบ กำแพงนั้นมักเป็นชุดอุปกรณ์ออน-พรอม—ไฟร์วอลล์ เว็บพร็อกซี่ ระบบป้องกันการบุกรุก—ที่ตั้งอยู่ในไม่กี่ดาต้าเซ็นเตอร์ พนักงานระยะไกลเข้าผ่าน VPN ซึ่งขยายเครือข่ายภายในไปยังที่ที่พวกเขาอยู่

โมเดลก่อนคลาวด์ในทางปฏิบัติ

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

แต่โมเดลนี้ตั้งอยู่บนสมมติฐานสองข้อที่เริ่มไม่เป็นจริง:

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

ทำไมมันถึงพัง: ผู้ใช้เคลื่อนที่ SaaS และเว็บเปิด

เมื่อพนักงานเคลื่อนที่มากขึ้นและการนำ SaaS มาใช้เร็วขึ้น รูปแบบทราฟฟิกพลิกกลับ ผู้คนในร้านกาแฟต้องการเข้าถึง Office 365, Salesforce และเครื่องมือบนเบราว์เซอร์หลายตัวอย่างรวดเร็ว—มักจะไม่ผ่านดาต้าเซ็นเตอร์ของบริษัทเลย

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

ปัญหาที่ทีมความปลอดภัยรู้สึกก่อน

ความซับซ้อนพุ่งขึ้น (อุปกรณ์มากขึ้น กฎมากขึ้น ข้อยกเว้นมากขึ้น) VPN เกิดภาระเกินและเสี่ยงเมื่อให้การเข้าถึงเครือข่ายที่กว้าง และทุกสาขาใหม่หรือการควบรวมกิจการหมายถึงการเปิดตัวฮาร์ดแวร์ใหม่ การวางแผนความจุเพิ่ม และสถาปัตยกรรมที่เปราะบาง

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

ความปลอดภัยที่ให้บริการจากคลาวด์: เดิมพันหลัก

เดิมพันที่นิยาม Zscaler พูดง่ายแต่ทำยาก: ให้บริการความปลอดภัยเป็นบริการคลาวด์ วางตำแหน่งให้ใกล้ผู้ใช้ แทนที่จะเป็นกล่องที่ตั้งอยู่ในเครือข่ายของบริษัท

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

"การตรวจสอบแบบอินไลน์" หมายถึงอะไร (ไม่ใช้ศัพท์เทคนิคมาก)

"อินไลน์" เหมือนการนำทราฟฟิกผ่านด่านตรวจความปลอดภัยก่อนเดินทางไปยังจุดหมาย

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

ทำไมสิ่งนี้ถึงน่าสนใจสำหรับองค์กร

การให้บริการความปลอดภัยจากคลาวด์เปลี่ยนความเป็นจริงประจำวันของทีม IT และความปลอดภัย:

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

โมเดลนี้ยังสอดคล้องกับวิธีที่บริษัททำงานตอนนี้: ทราฟฟิกมักจะไปยัง SaaS และอินเทอร์เน็ตโดยตรง ไม่ใช่ "ผ่านสำนักงานใหญ่" เสมอไป

ข้อแลกเปลี่ยน (ไม่อวย)

การนำบุคคลที่สามมาอินไลน์สร้างความกังวลจริงที่ทีมต้องประเมิน:

• ความเชื่อใจและการจัดการข้อมูล: อะไรที่ตรวจสอบ บันทึก ถอดรหัส (ถ้ามี) และเก็บไว้ยังไง
• ความแตกต่างของการมองเห็น: บางทีมคุ้นกับมุมมองระดับกล่องมากกว่า แม้แดชบอร์ดจะดีขึ้นก็ตาม
• การพึ่งพาบริการ: การขัดข้องหรือปัญหาประสิทธิภาพในภูมิภาคอาจกลายเป็นปัญหาทางธุรกิจได้อย่างรวดเร็ว

เดิมพันหลักจึงไม่ใช่แค่เชิงเทคนิค—แต่เป็นความเชื่อมั่นในการปฏิบัติการว่าผู้ให้บริการคลาวด์สามารถบังคับใช้นโยบายได้อย่างน่าเชื่อถือ โปร่งใส และในสเกลระดับโลก

Zero Trust อธิบายสำหรับผู้อ่านทั่วไป

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

การเปลี่ยนจาก "การเข้าถึงเครือข่าย" เป็น "การเข้าถึงแอป"

ความคิดแบบ VPN คล้ายกับการให้บัตรผ่านที่เปิดประตูทั้งอาคาร เมื่อเชื่อมต่อผ่าน VPN หลายระบบจะรับว่าผู้ใช้นั้นเป็น "ภายใน" ซึ่งอาจเปิดเผยมากกว่าที่ตั้งใจ

Zero trust พลิกโมเดลนี้ มันเหมือนการให้คนเข้าห้องเดียวเพื่อทำงานหนึ่งสิ่ง คุณไม่ได้ "เข้าร่วมเครือข่าย" กว้างๆ แต่คุณได้รับสิทธิ์เข้าถึง เฉพาะแอป ที่ได้รับอนุญาต

ตัวอย่างในชีวิตประจำวันง่ายๆ

ผู้รับเหมาต้องเข้าถึงเครื่องมือจัดการโครงการเป็นเวลา 2 เดือน ด้วย Zero trust พวกเขาสามารถได้รับสิทธิ์เข้าแอปเดียวโดยไม่เผลอเข้าถึงระบบเงินเดือนหรือเครื่องมือผู้ดูแลภายใน

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

การทำงานระยะไกลปลอดภัยขึ้นเพราะการตัดสินใจเรื่องความปลอดภัยตามผู้ใช้และแอป ไม่ใช่เครือข่ายออฟฟิศ

Zero trust ไม่ใช่สิ่งใด

Zero trust ไม่ใช่สินค้าชิ้นเดียวที่ซื้อแล้ว "เปิดใช้งาน" มันคือ แนวทางความปลอดภัย ที่นำไปปฏิบัติด้วยเครื่องมือและนโยบาย

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

แผนภาพระดับสูงของแนวทาง Zscaler

Zscaler เข้าใจง่ายที่สุดในฐานะ "จุดควบคุม" บนคลาวด์ที่อยู่ระหว่างคนกับสิ่งที่พวกเขาพยายามเข้าถึง แทนที่จะเชื่อถือพรมแดนเครือข่ายบริษัท มันประเมินการเชื่อมต่อแต่ละครั้งตามว่าใครเป็นผู้ใช้และบริบท จากนั้นใช้กฎที่เหมาะสม

องค์ประกอบหลัก

การติดตั้งส่วนใหญ่สามารถอธิบายด้วยสี่ชิ้นง่ายๆ:

• ผู้ใช้: พนักงาน ผู้รับเหมา พันธมิตร—ตัวตนใดๆ ที่ล็อกอิน
• แอป & ปลายทาง: เว็บไซต์สาธารณะ (SaaS เว็บ) และแอปส่วนตัว (ระบบภายใน)
• นโยบาย: กฎเช่น "การเงินเข้าถึงระบบเงินเดือน" "บล็อกการอัปโหลดไฟล์เสี่ยง" หรือ "ต้องการการตรวจสอบเข้มขึ้นเมื่ออยู่นอกเครือข่าย"
• การบังคับใช้บนคลาวด์: บริการความปลอดภัยบนคลาวด์ใช้กฎเหล่านั้นใกล้จุดที่ผู้ใช้เชื่อมต่อ แทนการส่งทราฟฟิกกลับไปยังดาต้าเซ็นเตอร์เดียว

สองเลน: ความปลอดภัยอินเทอร์เน็ต vs การเข้าถึงแอปส่วนตัว

แนวคิดคือ Zscaler แบ่งทราฟฟิกเป็นสองเลน:

• อินเทอร์เน็ต/SaaS (Secure Web Gateway): ปกป้องการท่องเว็บและการใช้แอปคลาวด์—กรอง ตรวจสอบ และควบคุมสิ่งที่ออกและเข้าช่วงเซสชันของผู้ใช้
• การเข้าถึงแอปส่วนตัว: ให้การเชื่อมต่อเฉพาะแอปภายในโดยไม่ต้องวางผู้ใช้ไว้ "บนเครือข่าย" เช่น VPN แบบเดิม

การแยกนี้สำคัญ: เลนหนึ่งเกี่ยวกับการใช้เว็บอย่างปลอดภัย อีกเลนเกี่ยวกับการเข้าถึงระบบภายในอย่างแม่นยำ

"ตัวตน + บริบท" โดยไม่ต้องใช้ศัพท์ดัง

การตัดสินใจไม่ได้อิงที่ IP ของสำนักงานที่เชื่อถือได้ แต่อิงสัญญาณเช่น ใครเป็นผู้ใช้ สุขภาพอุปกรณ์ (จัดการได้/ไม่จัดการ ได้แพตช์/ล้าสมัย) และ ที่มา/วิธีการเชื่อมต่อ

ผลลัพธ์ที่จับต้องได้

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

Secure Web Gateway: ฝั่งอินเทอร์เน็ตของเรื่อง

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

Secure Web Gateway (SWG) คือหมวดหมู่ที่สร้างมาเพื่อทำให้การเข้าถึงอินเทอร์เน็ตในชีวิตประจำวันปลอดภัยขึ้น—โดยไม่บังคับให้ทราฟฟิกของผู้ใช้ทุกคนต้องวนกลับผ่านออฟฟิศกลาง

ปัญหาที่ SWG แก้

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

การป้องกันทั่วไปได้แก่:

• การกรอง URL: อนุญาต/ปฏิเสธตามหมวดหมู่ ชื่อเสียง หรือนโยบาย
• การบล็อกมัลแวร์: หยุดไฟล์ที่รู้ว่าเป็นอันตราย สคริปต์น่าสงสัย และปลายทางฟิชชิ่ง
• การควบคุมข้อมูล: ตรวจจับและป้องกันข้อมูลสำคัญไม่ให้อัปโหลดไปยังที่ไม่อนุญาต

ทำไม SWG บนคลาวด์เร่งตัวเมื่อ SaaS และผู้ใช้มือถือเติบโต

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

SWG ที่ให้บริการจากคลาวด์สอดคล้องกับความจริงใหม่: นโยบายตามผู้ใช้ ทราฟฟิกตรวจสอบใกล้จุดเชื่อมต่อ และทีมความปลอดภัยได้การควบคุมที่สม่ำเสมอทั่วสำนักงานใหญ่ สาขา และการทำงานระยะไกล—โดยไม่ต้องถือว่าอินเทอร์เน็ตเป็นข้อยกเว้น

แทนความคิดแบบ VPN ด้วยการเข้าถึงแบบมุ่งที่แอป

VPN ถูกสร้างมาสำหรับยุคที่ "อยู่บนเครือข่าย" เท่ากับ "สามารถเข้าถึงแอป" ความคิดแบบนั้นล้มเมื่อแอปกระจายข้ามหลายคลาวด์ SaaS และระบบออน-พรอมที่เหลือน้อยลง

การเข้าถึงแอปส่วนตัวโดยไม่เปิดเครือข่าย

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

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

ทำไมการแบ่งส่วนตามแอปชนะการแบ่งส่วนเครือข่าย (ในหลายกรณี)

การแบ่งส่วนเครือข่ายมีพลัง แต่เปราะบางในองค์กรจริง: การควบรวม VLAN แบน แอปเก่า และข้อยกเว้นมักทับซ้อน การแบ่งส่วนตามแอปเข้าใจง่ายกว่าเพราะแม็ปกับเจตนาธุรกิจ:

• ผู้ใช้การเงินเข้าถึงแอปการเงิน
• ผู้รับเหมาเข้าถึงเครื่องมือโปรเจกต์ตัวเดียว
• ผู้ดูแลเข้าถึงคอนโซลที่มีสิทธิพิเศษด้วยการตรวจสอบเข้มงวดขึ้น

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

เส้นทางการนำไปใช้ที่พบได้บ่อย

ทีมส่วนใหญ่ไม่ทิ้ง VPN ในคืนเดียว มักจะใช้วิธีเป็นขั้นตอน:

1. เริ่มจากแอปภายในหนึ่งตัวที่สร้างปัญหา VPN (เช่น help desk, dev portal, HR tool)
2. ขยายไปยังแผนกแล้วทำซ้ำสำหรับชุดแอปถัดไป
3. เก็บ VPN เป็นทางเลือกในช่วงเปลี่ยนผ่าน แล้วค่อยลดการใช้ลงเมื่อเวลาผ่านไป

ผลลัพธ์ทางธุรกิจที่วัดได้

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

การจัดจำหน่าย: ความจริงที่ทำให้ความปลอดภัยระดับองค์กรแพร่

ผลิตภัณฑ์ความปลอดภัยที่ดีไม่จำเป็นต้องกลายเป็นมาตรฐานองค์กรโดยอัตโนมัติ ในทางปฏิบัติ "การจัดจำหน่าย" ในความปลอดภัยองค์กรหมายถึงเส้นทางที่ผู้ขายใช้เข้าถึง ชนะใจ และติดตั้งในองค์กรใหญ่—มักผ่านบริษัทอื่น

สิ่งที่รวมอยู่ใน "การจัดจำหน่าย"

ในการรักษาความปลอดภัย การจัดจำหน่ายมักครอบคลุม:

• พันธมิตรช่องทางและผู้จำหน่าย ที่แนะนำผลิตภัณฑ์ จัดแพ็กกับเครื่องมืออื่น และช่วยนำทางการจัดซื้อ
• Systems Integrators (SIs) และ Managed Service Providers (MSPs) ที่ออกแบบการเปิดตัว เชื่อมตัวตนและเครือข่าย และดูแลการปฏิบัติการระยะที่สอง
• พันธมิตรทางเทคโนโลยี (ผู้ให้บริการตัวตน ผู้ขายเอ็นด์พอยต์ แพลตฟอร์มคลาวด์) ที่ทำให้การติดตั้งราบรื่นขึ้นและเพิ่มความมั่นใจให้ผู้ซื้อ

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

ทำไมช่องทางสำคัญกว่าที่คนคาด

องค์กรใหญ่ซื้ออย่างรอบคอบ พันธมิตรให้:

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

สำหรับแพลตฟอร์มอย่าง Zscaler การนำไปใช้มักขึ้นกับงานโยกย้ายจริง—ย้ายผู้ใช้ออกจากรูปแบบ VPN เก่า ผสานตัวตน ปรับแต่งนโยบาย พันธมิตรทำให้การเปลี่ยนแปลงนั้นดูจัดการได้

การให้บริการจากคลาวด์เปลี่ยนการขายอย่างไร

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

สิ่งที่ควรสังเกต (สำหรับทีมที่ประเมินผู้ขาย)

ดูใกล้ชิดที่ แรงจูงใจของพันธมิตร คุณภาพของ การเปิดใช้งานพันธมิตร (การฝึกอบรม playbook การขายร่วม) และการส่งมอบงานฝ่ายความสำเร็จลูกค้าหลังเซ็นสัญญาที่ชัดเจน หลายการติดตั้งล้มเหลวไม่ใช่เพราะผลิตภัณฑ์อ่อน แต่เพราะความรับผิดชอบระหว่างผู้ขาย พันธมิตร และลูกค้าไม่ชัดเจน

การจับเวลาในหมวดหมู่: คลาวด์ การทำงานระยะไกล และ SASE/SSE

การซื้อความปลอดภัยไม่ค่อยเริ่มจาก "เราต้องการความปลอดภัยมากขึ้น" มันมักเริ่มจากการเปลี่ยนแปลงเครือข่ายที่ทำลายสมมติฐานเก่า: แอปย้ายไป SaaS มากขึ้น สาขาเปลี่ยนเป็น SD-WAN หรือการทำงานระยะไกลกลายเป็นถาวร เมื่อทราฟฟิกไม่ไหลผ่านออฟฟิศกลาง โมเดล "ปกป้องทุกอย่างที่สำนักงานใหญ่" กลายเป็นการเชื่อมช้า ข้อยกเว้นยุ่ง และจุดบอด

ทำไมการจับเวลาหมวดหมู่สำคัญ

Zscaler มักถูกพูดถึงพร้อมกับ SASE และ SSE เพราะคำเหล่านั้นอธิบายการเปลี่ยนแปลงของวิธีการให้บริการความปลอดภัย:

• SSE (Security Service Edge): ควบคุมความปลอดภัยที่ให้บริการจากคลาวด์เพื่อให้ผู้ใช้ได้รับการป้องกันสม่ำเสมอที่ใดก็ตามที่พวกเขาอยู่
• SASE (Secure Access Service Edge): แนวคิดเดียวกัน พร้อมฝั่งเครือข่าย (มักเป็น SD-WAN) ดังนั้นการเชื่อมต่อและความปลอดภัยถูกวางแผนร่วมกัน

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

เช็คลิสต์ปฏิบัติเมื่อทีมประเมินโซลูชันเหล่านี้

บริษัทมักประเมินวิธีการแบบ SSE/SASE เมื่อ:

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

เมื่อทริกเกอร์เหล่านี้ปรากฏ หมวดหมู่ก็ "มาถึง" โดยธรรมชาติ—เพราะเครือข่ายเปลี่ยนไปแล้ว

ความจริงในการนำไปใช้: สิ่งที่ทำให้การเปิดตัวสำเร็จหรือพัง

การซื้อแพลตฟอร์ม Zero Trust มักเป็นเรื่องง่าย การทำให้มันทำงานข้ามเครือข่ายที่ยุ่ง แอปที่สืบทอดมา และผู้คนจริงๆ คือที่ที่โครงการสำเร็จหรือหยุดชะงัก

อุปสรรคการนำไปใช้ที่พบบ่อยที่สุด

แอปเก่ามักเป็นผู้ร้ายซ้ำ ระบบเก่าอาจคิดว่า "อยู่ภายในเครือข่าย = เชื่อถือได้" พึ่งพารายการอนุญาต IP แบบฝัง หรือติดขัดเมื่อทราฟฟิกถูกตรวจสอบ

แรงเสียดทานอื่นๆ มาจากมนุษย์: การจัดการการเปลี่ยนแปลง การออกแบบนโยบาย และการโต้แย้งว่า "ใครเป็นเจ้าของอะไร" การย้ายจากการเข้าถึงเครือข่ายกว้างสู่กฎระดับแอปบังคับให้ทีมต้องบันทึกการทำงานจริง—และนั่นอาจเปิดช่องว่างที่ถูกละเลยมานาน

ผู้มีส่วนได้ส่วนเสียที่ต้องดึงเข้ามาตั้งแต่ต้น

การเปิดตัวจะราบรื่นขึ้นเมื่อฝ่ายความปลอดภัยไม่พยายามทำงานคนเดียว คาดว่าต้องประสานกับ:

• ทีมความปลอดภัยและเครือข่าย (การชี้ทราฟฟิก การตัดสินใจแบ่งส่วน)
• IT/Helpdesk (สถานะอุปกรณ์ การนำเข้า ผู้ใช้ซัพพอร์ต)
• ฝ่าย Compliance/Risk (การบันทึก การจัดการข้อมูล ความคาดหวังด้านการตรวจสอบ)
• เจ้าของแอปธุรกิจ (อะไรสำคัญ อะไรอาจเสีย อะไรจะเปลี่ยนเร็ว)

กลยุทธ์นำร่องที่ลดความเสี่ยง

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

รันการนำร่องเป็นรอบ: ย้ายหมวดหมู่แอปทีละตัว ปรับนโยบาย แล้วขยาย เป้าหมายคือเรียนรู้เร็วโดยไม่ทำให้ทั้งบริษัทเป็นสนามทดสอบ

เรื่องปฏิบัติการ: งานหลังวัน-2

วางแผนการบันทึกและการแก้ปัญหาตั้งแต่วันแรก: บันทึกอยู่ที่ไหน ใครสามารถค้นหาได้ เก็บนานเท่าไหร่ และการแจ้งเตือนเชื่อมกับการตอบสนองเหตุการณ์อย่างไร หากผู้ใช้ไม่ได้รับความช่วยเหลือเมื่อ "แอปถูกบล็อก" ความเชื่อมั่นจะลดอย่างรวดเร็ว—แม้ว่ารูปแบบความปลอดภัยจะดี

ตัวเร่งปฏิบัติการที่มักถูกมองข้ามคืิอเครื่องมือภายใน: พอร์ทัลขอข้อยกเว้นแบบง่าย การตรวจสอบสิทธิ์ บัญชีรายการแอป การติดตามการเปิดตัว และการรายงาน ทีมมักสร้าง "แอปกาว" น้ำหนักเบาเหล่านี้เองแทนการรอโรงงานของผู้ขาย แพลตฟอร์มอย่าง Koder.ai สามารถช่วยทีมต้นแบบและส่งเครื่องมือเว็บภายในได้เร็วผ่านเวิร์กโฟลว์แบบแชท—มีประโยชน์เมื่อคุณต้องการแดชบอร์ด React พร้อม backend Go/PostgreSQL และการวนรอบเร็วตามการเติบโตของนโยบายและกระบวนการ

ความเสี่ยงและข้อแลกเปลี่ยนที่ต้องพิจารณา (ไม่อวย)

การย้ายการควบคุมความปลอดภัยจากฮาร์ดแวร์ที่คุณเป็นเจ้าของไปยังแพลตฟอร์มที่ให้บริการจากคลาวด์สามารถลดการปฏิบัติการ แต่ก็เปลี่ยนความเสี่ยงที่คุณเดิมพัน การตัดสินใจที่ดีคือไม่ใช่เรื่อง "Zero Trust vs เก่า" แต่เป็นการเข้าใจโหมดล้มเหลวใหม่

ความเสี่ยงการรวมศูนย์ (ผู้ขายเดียว หลายฟังก์ชัน)

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

การพึ่งพาประสิทธิภาพและความพร้อมใช้งาน

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

การกำหนดค่าผิดยังคงเป็นความเสี่ยงอันดับหนึ่ง

Zero Trust ไม่ใช่โล่เวทมนตร์ นโยบายที่กำหนดไม่ดี (ยืดหยุ่นเกินไป เข้มงวดเกินไป หรือไม่สอดคล้องกัน) อาจเพิ่มการเปิดเผยหรือขัดขวางงาน ยิ่งเครื่องยนต์นโยบายยืดหยุ่น ทีมยิ่งต้องมีวินัยมากขึ้น

ผู้ซื้อลดความเสี่ยงอย่างไร

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

การกำกับดูแลที่สำคัญจริงๆ

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

ข้อคิดสำคัญ: ทีมและผู้ก่อตั้งควรลอกแบบอะไรได้บ้าง

1) วิทยานิพนธ์ผลิตภัณฑ์ที่ชัดเจนชนะรายการฟีเจอร์ยาวๆ

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

2) ความชัดเจนของหมวดหมู่คือกลยุทธ์การเติบโต

"Zero trust" ใช้ได้เพราะมันแปลงเป็นคำสัญญาเชิงปฏิบัติ: ลดสมมติฐานความเชื่อใจ ลดงานติดตั้งเครือข่าย และการควบคุมที่ดีขึ้นเมื่อแอปย้ายออกจากออน-พรอม สำหรับทีม หมายถึงการซื้อผลลัพธ์ ไม่ใช่คำพูดฮิต เขียนผลลัพธ์ที่ต้องการ (เช่น "ไม่ให้การเข้าถึงขาเข้า" "สิทธิ์ขั้นต่ำต่อแอป" "นโยบายสม่ำเสมอสำหรับผู้ใช้ระยะไกล") และแม็ปแต่ละข้อกับความสามารถที่ทดสอบได้

3) พันธมิตรขยายความปลอดภัยองค์กรได้เร็วกว่าการขายตรงอย่างเดียว

ความปลอดภัยองค์กรแพร่ผ่านเครือข่ายความเชื่อใจ: ตัวแทนจำหน่าย GSIs MSPs และตลาดคลาวด์ ผู้ก่อตั้งสามารถลอกแบบนี้ได้โดยทำผลิตภัณฑ์ให้พร้อมสำหรับพันธมิตรตั้งแต่ต้น—การแพ็กเกจชัดเจน กำไรที่คาดการณ์ได้ playbook การติดตั้ง และเมตริกที่แชร์ ผู้นำด้านความปลอดภัยก็ใช้พันธมิตรได้เช่นกัน: ให้พวกเขาจัดการการเปลี่ยนแปลง การผสานตัวตน และการโยกย้ายเป็นขั้นตอน แทนที่จะพยายามยกระดับทักษะทุกทีมภายในครั้งเดียว

4) คำแนะนำปฏิบัติสำหรับผู้นำความปลอดภัยที่พิจารณาคลาวด์/Zero Trust

เริ่มจากกรณีใช้งานปริมาณสูงหนึ่งรายการ (มักเป็นการเข้าถึงอินเทอร์เน็ตหรือแอปสำคัญตัวเดียว) วัดก่อน/หลัง แล้วขยาย

คำถามสำคัญในการวางแผนการเปิดตัว:

• แหล่งข้อมูล "ความจริง" สำหรับตัวตน (และสมาชิกกลุ่ม) คืออะไร?
• จะจัดการแอปเก่า ผู้รับเหมา และ BYOD อย่างไร?
• แผนการครอบครองนโยบายเป็นของใคร: ความปลอดภัย เครือข่าย หรือร่วมกัน?

5) คำแนะนำปฏิบัติสำหรับผู้ก่อตั้งเรื่องการจัดจำหน่ายและการสร้างหมวดหมู่

อย่าแค่ "ขายความปลอดภัย"—ขายเส้นทางการย้าย เรื่องราวที่ชนะมักเป็น: ปัญหา → ขั้นตอนง่ายที่สุด → ชัยชนะที่วัดได้ → การขยาย สร้างการนำเข้าและการรายงานที่ทำให้มูลค่าเห็นได้ใน 30–60 วัน

รูปแบบที่เป็นมิตรกับผู้ก่อตั้งคือการเสริมผลิตภัณฑ์หลักด้วยแอปประกอบที่สร้างได้เร็ว (เวิร์กโฟลว์การประเมิน ตัวติดตามการย้าย เครื่องคิดเลข ROI พอร์ทัลพันธมิตร) ถ้าคุณอยากสร้างสิ่งเหล่านี้โดยไม่ต้องรื้อท่อพัฒนาระบบเดิมทั้งหมด Koder.ai ถูกออกแบบมาสำหรับการสร้างแอปสแต็กเต็มจากแชท—มีประโยชน์สำหรับนำเครื่องมือภายในหรือที่ใช้กับลูกค้าเข้าสู่การผลิตอย่างรวดเร็ว แล้ววนปรับตามการพัฒนากลไกการจัดจำหน่าย

หากคุณต้องการลงลึก ดูบทความเพิ่มเติม: ข้อมูลพื้นฐาน Zero Trust และ ภาพรวม SASE vs SSE การออกแบบแพ็กเกจดูได้ที่ pricing.