20 ต.ค. 2568·3 นาที
Jay Chaudhry & Zscaler: Zero Trust ถูกออกแบบให้สเกลกับคลาวด์
มุมมองเชิงปฏิบัติว่า Jay Chaudhry และ Zscaler ใช้ความปลอดภัยบนคลาวด์ Zero Trust และการจัดจำหน่ายผ่านพันธมิตรอย่างไรเพื่อสร้างบริษัทความปลอดภัยระดับองค์กรชั้นนำ
มุมมองเชิงปฏิบัติว่า Jay Chaudhry และ Zscaler ใช้ความปลอดภัยบนคลาวด์ Zero Trust และการจัดจำหน่ายผ่านพันธมิตรอย่างไรเพื่อสร้างบริษัทความปลอดภัยระดับองค์กรชั้นนำ
นี่ไม่ใช่ชีวประวัติของ Jay Chaudhry แต่เป็นเรื่องราวเชิงปฏิบัติว่ากลุ่ม Zscaler ช่วยเปลี่ยนโฉมความปลอดภัยองค์กรอย่างไร—และทำไมทางเลือกทั้งเชิงเทคนิคและเชิงพาณิชย์ของพวกเขาถึงมีความหมาย
คุณจะได้เรียนรู้สองเรื่องพร้อมกัน:
ความปลอดภัยองค์กรยุคใหม่คือชุดการควบคุมที่ให้พนักงานใช้อินเทอร์เน็ตและแอปภายในได้อย่างปลอดภัย โดยไม่ถือว่าสิ่งใดปลอดภัยเพียงเพราะมันอยู่ "ภายใน" เครือข่ายของบริษัท มันไม่ใช่การสร้างกำแพงที่ใหญ่ขึ้นรอบดาต้าเซ็นเตอร์ แต่เป็นการตรวจสอบ ใคร กำลังเชื่อมต่อ, อะไร ที่พวกเขาเชื่อมต่อไป และ เชื่อมต่อนั้นควรอนุญาตไหม—ทุกครั้งที่มีการเชื่อมต่อ
เมื่อจบแล้ว คุณจะสามารถอธิบายเดิมพันหลักของ Zscaler ในประโยคเดียว ระบุได้ว่าจุดไหน Zero Trust แทนความคิดแบบยุค VPN และเห็นว่ากลยุทธ์การจัดจำหน่ายสามารถสำคัญเท่าการออกแบบผลิตภัณฑ์ได้อย่างไร
Jay Chaudhry เป็นผู้ประกอบการต่อเนื่องที่รู้จักกันดีในฐานะผู้ก่อตั้งและ CEO ของ Zscaler บริษัทที่ผลักดันความปลอดภัยองค์กรจากการ "ปกป้องเครือข่ายของบริษัท" ไปสู่การ "ปกป้องผู้ใช้และแอปไม่ว่าจะอยู่ที่ไหน" ก่อน Zscaler เขาสร้างและขายสตาร์ทอัพด้านความปลอดภัยหลายแห่ง ทำให้เขาเห็นพัฒนาการของพฤติกรรมผู้โจมตีและการเปลี่ยนแปลงของ IT ในองค์กรได้ชัดเจน
เป้าหมายของ Chaudhry กับ Zscaler ชัดเจน: เมื่อการทำงานและแอปย้ายออกจากเครือข่ายของบริษัท (ไปยังอินเทอร์เน็ตสาธารณะและบริการคลาวด์) โมเดลเดิมที่บังคับให้ทุกอย่างต้องวิ่งผ่านดาต้าเซ็นเตอร์กลางเพื่อตรวจสอบเริ่มล้มเหลว
การเปลี่ยนนี้สร้างทางเลือกที่เจ็บปวดสำหรับทีม IT:
สมมติฐานก่อตั้งของ Zscaler คือความปลอดภัยต้องตามผู้ใช้ ไม่ใช่ตามอาคาร
สิ่งที่โดดเด่นคือวิสัยทัศน์ของผู้ก่อตั้งที่มีอิทธิพลต่อกลยุทธ์ของบริษัทตั้งแต่แรก:
นี่ไม่ใช่แค่มุมการตลาด แต่มันขับเคลื่อนการตัดสินใจด้านผลิตภัณฑ์ พันธมิตร และวิธีที่ Zscaler อธิบาย "ทำไม" ให้ผู้ซื้อองค์กรที่ระมัดระวัง ฟังชัดเจนนี้ช่วยเปลี่ยน "ความปลอดภัยที่ให้บริการจากคลาวด์" และ "Zero Trust" จากแนวคิดให้กลายเป็นรายการงบประมาณ—สิ่งที่บริษัทใหญ่สามารถซื้อ ติดตั้ง และมาตรฐานได้
มาหลายปี ความปลอดภัยองค์กรถูกสร้างบนแนวคิดง่ายๆ: เก็บ "สิ่งที่ดี" ไว้ภายในเครือข่ายของบริษัท แล้วสร้างกำแพงล้อมรอบ กำแพงนั้นมักเป็นชุดอุปกรณ์ออน-พรอม—ไฟร์วอลล์ เว็บพร็อกซี่ ระบบป้องกันการบุกรุก—ที่ตั้งอยู่ในไม่กี่ดาต้าเซ็นเตอร์ พนักงานระยะไกลเข้าผ่าน VPN ซึ่งขยายเครือข่ายภายในไปยังที่ที่พวกเขาอยู่
เมื่อแอปส่วนใหญ่ยังอยู่ในดาต้าเซ็นเตอร์ของบริษัท โมเดลนี้ทำงานได้พอสมควร ทราฟฟิกเว็บและแอปไหลผ่านจุดคอขวดเดียวกัน ทีมความปลอดภัยสามารถตรวจสอบ บันทึก และบล็อกได้
แต่โมเดลนี้ตั้งอยู่บนสมมติฐานสองข้อที่เริ่มไม่เป็นจริง:
เมื่อพนักงานเคลื่อนที่มากขึ้นและการนำ SaaS มาใช้เร็วขึ้น รูปแบบทราฟฟิกพลิกกลับ ผู้คนในร้านกาแฟต้องการเข้าถึง Office 365, Salesforce และเครื่องมือบนเบราว์เซอร์หลายตัวอย่างรวดเร็ว—มักจะไม่ผ่านดาต้าเซ็นเตอร์ของบริษัทเลย
เพื่อรักษาการบังคับใช้นโยบาย หลายบริษัทจึง "backhaul" ทราฟฟิก: ส่งคำขออินเทอร์เน็ตและ SaaS ของผู้ใช้ผ่าน HQ ก่อน ตรวจสอบ แล้วส่งออก ผลที่ได้คาดเดาได้: ประสิทธิภาพช้า ผู้ใช้ไม่พอใจ และแรงกดดันให้เจาะช่องว่างการควบคุมเพิ่มขึ้น
ความซับซ้อนพุ่งขึ้น (อุปกรณ์มากขึ้น กฎมากขึ้น ข้อยกเว้นมากขึ้น) VPN เกิดภาระเกินและเสี่ยงเมื่อให้การเข้าถึงเครือข่ายที่กว้าง และทุกสาขาใหม่หรือการควบรวมกิจการหมายถึงการเปิดตัวฮาร์ดแวร์ใหม่ การวางแผนความจุเพิ่ม และสถาปัตยกรรมที่เปราะบาง
ช่องว่างนี้—ต้องการความปลอดภัยที่สม่ำเสมอโดยไม่บังคับให้ทุกอย่างผ่านเพอริมิเตอร์ทางกาย—สร้างโอกาสให้การรักษาความปลอดภัยแบบให้บริการจากคลาวด์ที่ตามผู้ใช้และแอป ไม่ใช่ตามอาคาร
เดิมพันที่นิยาม Zscaler พูดง่ายแต่ทำยาก: ให้บริการความปลอดภัยเป็นบริการคลาวด์ วางตำแหน่งให้ใกล้ผู้ใช้ แทนที่จะเป็นกล่องที่ตั้งอยู่ในเครือข่ายของบริษัท
ในบริบทนี้ "ความปลอดภัยบนคลาวด์" ไม่ได้หมายความเฉพาะการปกป้องเซิร์ฟเวอร์คลาวด์เท่านั้น แต่มันหมายถึงตัวความปลอดภัยเองรันอยู่บนคลาวด์—ดังนั้นผู้ใช้ที่สาขา ที่บ้าน หรือบนมือถือจะเชื่อมต่อกับจุด PoP ที่ใกล้ที่สุด และนโยบายจะถูกบังคับที่นั่น
"อินไลน์" เหมือนการนำทราฟฟิกผ่านด่านตรวจความปลอดภัยก่อนเดินทางไปยังจุดหมาย
เมื่อพนักงานเข้าไปยังเว็บไซต์หรือแอปคลาวด์ การเชื่อมต่อของพวกเขาจะถูกชี้ผ่านบริการก่อน บริการจะตรวจสอบสิ่งที่ทำได้ (ตามนโยบาย) บล็อกปลายทางที่เสี่ยง สแกนหาภัยคุกคาม แล้วส่งต่อทราฟฟิกที่อนุญาตต่อไป เป้าหมายคืิอผู้ใช้ไม่จำเป็นต้อง "อยู่ในเครือข่ายของบริษัท" เพื่อรับการป้องกันระดับองค์กร—ความปลอดภัยตามผู้ใช้ไปด้วย
การให้บริการความปลอดภัยจากคลาวด์เปลี่ยนความเป็นจริงประจำวันของทีม IT และความปลอดภัย:
โมเดลนี้ยังสอดคล้องกับวิธีที่บริษัททำงานตอนนี้: ทราฟฟิกมักจะไปยัง SaaS และอินเทอร์เน็ตโดยตรง ไม่ใช่ "ผ่านสำนักงานใหญ่" เสมอไป
การนำบุคคลที่สามมาอินไลน์สร้างความกังวลจริงที่ทีมต้องประเมิน:
เดิมพันหลักจึงไม่ใช่แค่เชิงเทคนิค—แต่เป็นความเชื่อมั่นในการปฏิบัติการว่าผู้ให้บริการคลาวด์สามารถบังคับใช้นโยบายได้อย่างน่าเชื่อถือ โปร่งใส และในสเกลระดับโลก
Zero trust คือหลักการง่ายๆ: อย่าสันนิษฐานว่าสิ่งใดปลอดภัยเพียงเพราะมันอยู่ "ภายในเครือข่ายบริษัท" แต่ให้ ยืนยันเสมอ ว่าใครเป็นผู้ใช้ อุปกรณ์เป็นอย่างไร และควรเข้าถึงแอปหรือข้อมูลชิ้นใดในสถานการณ์นั้น—เมื่อใดก็ตามที่จำเป็น
ความคิดแบบ VPN คล้ายกับการให้บัตรผ่านที่เปิดประตูทั้งอาคาร เมื่อเชื่อมต่อผ่าน VPN หลายระบบจะรับว่าผู้ใช้นั้นเป็น "ภายใน" ซึ่งอาจเปิดเผยมากกว่าที่ตั้งใจ
Zero trust พลิกโมเดลนี้ มันเหมือนการให้คนเข้าห้องเดียวเพื่อทำงานหนึ่งสิ่ง คุณไม่ได้ "เข้าร่วมเครือข่าย" กว้างๆ แต่คุณได้รับสิทธิ์เข้าถึง เฉพาะแอป ที่ได้รับอนุญาต
ผู้รับเหมาต้องเข้าถึงเครื่องมือจัดการโครงการเป็นเวลา 2 เดือน ด้วย Zero trust พวกเขาสามารถได้รับสิทธิ์เข้าแอปเดียวโดยไม่เผลอเข้าถึงระบบเงินเดือนหรือเครื่องมือผู้ดูแลภายใน
พนักงานใช้เครื่องส่วนตัวขณะเดินทาง นโยบาย Zero trust อาจบังคับให้ตรวจสอบการล็อกอินที่เข้มขึ้น หรือบล็อกการเข้าถึงหากอุปกรณ์ล้าสมัย ไม่เข้ารหัส หรือมีสัญญาณการถูกบุกรุก
การทำงานระยะไกลปลอดภัยขึ้นเพราะการตัดสินใจเรื่องความปลอดภัยตามผู้ใช้และแอป ไม่ใช่เครือข่ายออฟฟิศ
Zero trust ไม่ใช่สินค้าชิ้นเดียวที่ซื้อแล้ว "เปิดใช้งาน" มันคือ แนวทางความปลอดภัย ที่นำไปปฏิบัติด้วยเครื่องมือและนโยบาย
มันก็ไม่ได้หมายความว่า "ไม่เชื่อใคร" แบบรุนแรง ในทางปฏิบัติหมายถึง ความเชื่อถือต้องได้มาอย่างต่อเนื่อง ผ่านการตรวจสอบตัวตน สถานะอุปกรณ์ และสิทธิ์ขั้นต่ำ—เพื่อให้ความผิดพลาดและการถูกโจมตีไม่แพร่กระจายโดยอัตโนมัติ
Zscaler เข้าใจง่ายที่สุดในฐานะ "จุดควบคุม" บนคลาวด์ที่อยู่ระหว่างคนกับสิ่งที่พวกเขาพยายามเข้าถึง แทนที่จะเชื่อถือพรมแดนเครือข่ายบริษัท มันประเมินการเชื่อมต่อแต่ละครั้งตามว่าใครเป็นผู้ใช้และบริบท จากนั้นใช้กฎที่เหมาะสม
การติดตั้งส่วนใหญ่สามารถอธิบายด้วยสี่ชิ้นง่ายๆ:
แนวคิดคือ Zscaler แบ่งทราฟฟิกเป็นสองเลน:
การแยกนี้สำคัญ: เลนหนึ่งเกี่ยวกับการใช้เว็บอย่างปลอดภัย อีกเลนเกี่ยวกับการเข้าถึงระบบภายในอย่างแม่นยำ
การตัดสินใจไม่ได้อิงที่ IP ของสำนักงานที่เชื่อถือได้ แต่อิงสัญญาณเช่น ใครเป็นผู้ใช้ สุขภาพอุปกรณ์ (จัดการได้/ไม่จัดการ ได้แพตช์/ล้าสมัย) และ ที่มา/วิธีการเชื่อมต่อ
ถ้าทำดี แนวทางนี้จะลดพื้นผิวการโจมตีที่เปิดเผย จำกัดการเคลื่อนที่ด้านข้างเมื่อมีปัญหา และเปลี่ยนการควบคุมการเข้าถึงให้เป็นนโยบายที่เรียบง่ายและสม่ำเสมอ—โดยเฉพาะเมื่อการทำงานระยะไกลและสแตกแอปแบบคลาวด์กลายเป็นค่าพื้นฐาน
เมื่อคนพูดถึง "ความปลอดภัยองค์กร" พวกเขามักนึกถึงแอปส่วนตัวและเครือข่ายภายใน แต่ความเสี่ยงจำนวนมากอยู่ฝั่งอินเทอร์เน็ต: พนักงานท่องเว็บ คลิกลิงก์ในอีเมล ใช้เครื่องมือบนเบราว์เซอร์ หรืออัปโหลดไฟล์ไปยังเว็บแอป
Secure Web Gateway (SWG) คือหมวดหมู่ที่สร้างมาเพื่อทำให้การเข้าถึงอินเทอร์เน็ตในชีวิตประจำวันปลอดภัยขึ้น—โดยไม่บังคับให้ทราฟฟิกของผู้ใช้ทุกคนต้องวนกลับผ่านออฟฟิศกลาง
อย่างง่าย SWG ทำหน้าที่เป็นจุดตรวจควบคุมระหว่างผู้ใช้กับเว็บสาธารณะ แทนที่จะเชื่อในสิ่งที่อุปกรณ์เข้าถึง เกตเวย์จะใช้กฎและการตรวจสอบเพื่อลดการเปิดรับต่อเว็บไซต์เป็นอันตราย ไฟล์เสี่ยง และการรั่วไหลของข้อมูลโดยไม่ตั้งใจ
การป้องกันทั่วไปได้แก่:
แรงขับเคลื่อนเกิดจากงานที่ย้ายจากสำนักงานคงที่ไปยัง SaaS เบราว์เซอร์ และอุปกรณ์มือถือ หากผู้ใช้และแอปอยู่ทุกที่ การส่งทราฟฟิกกลับไปที่เพอริมิเตอร์เดียวจะเพิ่มความหน่วงและสร้างจุดบอด
SWG ที่ให้บริการจากคลาวด์สอดคล้องกับความจริงใหม่: นโยบายตามผู้ใช้ ทราฟฟิกตรวจสอบใกล้จุดเชื่อมต่อ และทีมความปลอดภัยได้การควบคุมที่สม่ำเสมอทั่วสำนักงานใหญ่ สาขา และการทำงานระยะไกล—โดยไม่ต้องถือว่าอินเทอร์เน็ตเป็นข้อยกเว้น
VPN ถูกสร้างมาสำหรับยุคที่ "อยู่บนเครือข่าย" เท่ากับ "สามารถเข้าถึงแอป" ความคิดแบบนั้นล้มเมื่อแอปกระจายข้ามหลายคลาวด์ SaaS และระบบออน-พรอมที่เหลือน้อยลง
การเข้าถึงแบบมุ่งที่แอปพลิกค่าเริ่มต้น แทนที่จะโยนผู้ใช้ลงบนเครือข่ายภายใน (แล้วหวังว่านโยบายแบ่งส่วนจะคงอยู่) ผู้ใช้จะเชื่อมต่อเฉพาะกับแอปที่กำหนด
ในเชิงแนวคิด มันทำงานเหมือนการเชื่อมต่อที่ผ่านนายหน้า: ผู้ใช้พิสูจน์ตัวตนและสิทธิ์ จากนั้นเส้นทางสั้น ๆ ที่ควบคุมจะถูกสร้างไปยังแอปนั้น—ไม่ต้องเผยแพร่ช่วง IP ภายในสู่สาธารณะและไม่ให้ผู้ใช้มองเห็นเครือข่ายภายในอย่างกว้าง
การแบ่งส่วนเครือข่ายมีพลัง แต่เปราะบางในองค์กรจริง: การควบรวม VLAN แบน แอปเก่า และข้อยกเว้นมักทับซ้อน การแบ่งส่วนตามแอปเข้าใจง่ายกว่าเพราะแม็ปกับเจตนาธุรกิจ:
ลดความไว้วางใจโดยปริยายและทำให้นโยบายการเข้าถึงอ่านง่าย: คุณตรวจสอบได้ตามแอปและกลุ่มผู้ใช้แทนการติดตามเส้นทางและซับเน็ต
ทีมส่วนใหญ่ไม่ทิ้ง VPN ในคืนเดียว มักจะใช้วิธีเป็นขั้นตอน:
เมื่อการเข้าถึงแบบมุ่งที่แอปทำดี ผลที่เห็นได้เร็ว: ตั๋วซัพพอร์ต VPN ลดลง นโยบายการเข้าถึงชัดเจนที่ทั้งทีมความปลอดภัยและ IT อธิบายได้ และประสบการณ์ผู้ใช้ราบรื่นขึ้น—โดยเฉพาะพนักงานระยะไกลและไฮบริดที่แค่อยากให้แอปใช้งานได้โดยไม่ต้อง "เชื่อมต่อกับเครือข่าย" ก่อน
ผลิตภัณฑ์ความปลอดภัยที่ดีไม่จำเป็นต้องกลายเป็นมาตรฐานองค์กรโดยอัตโนมัติ ในทางปฏิบัติ "การจัดจำหน่าย" ในความปลอดภัยองค์กรหมายถึงเส้นทางที่ผู้ขายใช้เข้าถึง ชนะใจ และติดตั้งในองค์กรใหญ่—มักผ่านบริษัทอื่น
ในการรักษาความปลอดภัย การจัดจำหน่ายมักครอบคลุม:
สิ่งเหล่านี้ไม่ใช่ของเสริม พวกมันคือท่อที่เชื่อมผู้ขายกับงบประมาณ ผู้ตัดสินใจ และความสามารถในการติดตั้ง
องค์กรใหญ่ซื้ออย่างรอบคอบ พันธมิตรให้:
สำหรับแพลตฟอร์มอย่าง Zscaler การนำไปใช้มักขึ้นกับงานโยกย้ายจริง—ย้ายผู้ใช้ออกจากรูปแบบ VPN เก่า ผสานตัวตน ปรับแต่งนโยบาย พันธมิตรทำให้การเปลี่ยนแปลงนั้นดูจัดการได้
การให้บริการจากคลาวด์เปลี่ยนธุรกิจจากการติดตั้งครั้งเดียวเป็น การสมัครสมาชิก การขยาย และการต่ออายุ นั่นเปลี่ยนการจัดจำหน่าย: พันธมิตรไม่ใช่แค่ "ปิดดีล" แต่เป็นพาร์ทเนอร์การเปิดตัวต่อเนื่องที่แรงจูงใจสอดคล้องกับผลลัพธ์ของลูกค้า—ถ้าโปรแกรมถูกออกแบบดี
ดูใกล้ชิดที่ แรงจูงใจของพันธมิตร คุณภาพของ การเปิดใช้งานพันธมิตร (การฝึกอบรม playbook การขายร่วม) และการส่งมอบงานฝ่ายความสำเร็จลูกค้าหลังเซ็นสัญญาที่ชัดเจน หลายการติดตั้งล้มเหลวไม่ใช่เพราะผลิตภัณฑ์อ่อน แต่เพราะความรับผิดชอบระหว่างผู้ขาย พันธมิตร และลูกค้าไม่ชัดเจน
การซื้อความปลอดภัยไม่ค่อยเริ่มจาก "เราต้องการความปลอดภัยมากขึ้น" มันมักเริ่มจากการเปลี่ยนแปลงเครือข่ายที่ทำลายสมมติฐานเก่า: แอปย้ายไป SaaS มากขึ้น สาขาเปลี่ยนเป็น SD-WAN หรือการทำงานระยะไกลกลายเป็นถาวร เมื่อทราฟฟิกไม่ไหลผ่านออฟฟิศกลาง โมเดล "ปกป้องทุกอย่างที่สำนักงานใหญ่" กลายเป็นการเชื่อมช้า ข้อยกเว้นยุ่ง และจุดบอด
Zscaler มักถูกพูดถึงพร้อมกับ SASE และ SSE เพราะคำเหล่านั้นอธิบายการเปลี่ยนแปลงของวิธีการให้บริการความปลอดภัย:
ประโยชน์จริงไม่ได้อยู่ที่ตัวย่อ—แต่คือการดำเนินงานที่ง่ายขึ้น: อุปกรณ์ออน-พรอมลดลง การอัปเดตนโยบายทำได้ง่ายขึ้น และการเข้าถึงแอปตรงขึ้นโดยไม่ต้องส่งทราฟฟิกกลับไปดาต้าเซ็นเตอร์
บริษัทมักประเมินวิธีการแบบ SSE/SASE เมื่อ:
เมื่อทริกเกอร์เหล่านี้ปรากฏ หมวดหมู่ก็ "มาถึง" โดยธรรมชาติ—เพราะเครือข่ายเปลี่ยนไปแล้ว
การซื้อแพลตฟอร์ม Zero Trust มักเป็นเรื่องง่าย การทำให้มันทำงานข้ามเครือข่ายที่ยุ่ง แอปที่สืบทอดมา และผู้คนจริงๆ คือที่ที่โครงการสำเร็จหรือหยุดชะงัก
แอปเก่ามักเป็นผู้ร้ายซ้ำ ระบบเก่าอาจคิดว่า "อยู่ภายในเครือข่าย = เชื่อถือได้" พึ่งพารายการอนุญาต IP แบบฝัง หรือติดขัดเมื่อทราฟฟิกถูกตรวจสอบ
แรงเสียดทานอื่นๆ มาจากมนุษย์: การจัดการการเปลี่ยนแปลง การออกแบบนโยบาย และการโต้แย้งว่า "ใครเป็นเจ้าของอะไร" การย้ายจากการเข้าถึงเครือข่ายกว้างสู่กฎระดับแอปบังคับให้ทีมต้องบันทึกการทำงานจริง—และนั่นอาจเปิดช่องว่างที่ถูกละเลยมานาน
การเปิดตัวจะราบรื่นขึ้นเมื่อฝ่ายความปลอดภัยไม่พยายามทำงานคนเดียว คาดว่าต้องประสานกับ:
เริ่มกับกลุ่มความเสี่ยงต่ำ (เช่น แผนกเดียวหรือกลุ่มผู้รับเหมาตัวอย่าง) และกำหนดเมตริกความสำเร็จก่อน: ตั๋ว VPN ลดลง การเข้าถึงแอปเร็วขึ้น การลดพื้นผิวการโจมตีที่วัดได้ หรือการมองเห็นที่ดีขึ้น
รันการนำร่องเป็นรอบ: ย้ายหมวดหมู่แอปทีละตัว ปรับนโยบาย แล้วขยาย เป้าหมายคือเรียนรู้เร็วโดยไม่ทำให้ทั้งบริษัทเป็นสนามทดสอบ
วางแผนการบันทึกและการแก้ปัญหาตั้งแต่วันแรก: บันทึกอยู่ที่ไหน ใครสามารถค้นหาได้ เก็บนานเท่าไหร่ และการแจ้งเตือนเชื่อมกับการตอบสนองเหตุการณ์อย่างไร หากผู้ใช้ไม่ได้รับความช่วยเหลือเมื่อ "แอปถูกบล็อก" ความเชื่อมั่นจะลดอย่างรวดเร็ว—แม้ว่ารูปแบบความปลอดภัยจะดี
ตัวเร่งปฏิบัติการที่มักถูกมองข้ามคืิอเครื่องมือภายใน: พอร์ทัลขอข้อยกเว้นแบบง่าย การตรวจสอบสิทธิ์ บัญชีรายการแอป การติดตามการเปิดตัว และการรายงาน ทีมมักสร้าง "แอปกาว" น้ำหนักเบาเหล่านี้เองแทนการรอโรงงานของผู้ขาย แพลตฟอร์มอย่าง Koder.ai สามารถช่วยทีมต้นแบบและส่งเครื่องมือเว็บภายในได้เร็วผ่านเวิร์กโฟลว์แบบแชท—มีประโยชน์เมื่อคุณต้องการแดชบอร์ด React พร้อม backend Go/PostgreSQL และการวนรอบเร็วตามการเติบโตของนโยบายและกระบวนการ
การย้ายการควบคุมความปลอดภัยจากฮาร์ดแวร์ที่คุณเป็นเจ้าของไปยังแพลตฟอร์มที่ให้บริการจากคลาวด์สามารถลดการปฏิบัติการ แต่ก็เปลี่ยนความเสี่ยงที่คุณเดิมพัน การตัดสินใจที่ดีคือไม่ใช่เรื่อง "Zero Trust vs เก่า" แต่เป็นการเข้าใจโหมดล้มเหลวใหม่
ถ้าแพลตฟอร์มเดียวให้ความปลอดภัยเว็บ การเข้าถึงแอปส่วนตัว การบังคับใช้นโยบาย และการบันทึก คุณลดการกระจายเครื่องมือ—แต่ก็รวมความเสี่ยงไว้ในที่เดียว ข้อพิพาทสัญญา การเปลี่ยนแปลงราคา หรือช่องว่างของผลิตภัณฑ์สามารถมีผลกระทบกว้างกว่าการกระจายฟังก์ชันไว้ที่หลายเครื่องมือ
ความปลอดภัยบนคลาวด์เพิ่มขั้นตอนการเดินทางของทราฟฟิกระหว่างผู้ใช้กับแอป เมื่อมันทำงานดีก็คือผู้ใช้แทบไม่สังเกต แต่เมื่อภูมิภาคมีการขัดข้อง ปัญหาเส้นทาง หรือความจุไม่พอ "ความปลอดภัย" อาจดูเหมือนว่า "อินเทอร์เน็ตล่ม" นี่เป็นเรื่องของการพึ่งพาการเชื่อมต่อที่พร้อมใช้งานเสมอ
Zero Trust ไม่ใช่โล่เวทมนตร์ นโยบายที่กำหนดไม่ดี (ยืดหยุ่นเกินไป เข้มงวดเกินไป หรือไม่สอดคล้องกัน) อาจเพิ่มการเปิดเผยหรือขัดขวางงาน ยิ่งเครื่องยนต์นโยบายยืดหยุ่น ทีมยิ่งต้องมีวินัยมากขึ้น
การเปิดตัวเป็นขั้นตอนช่วยได้: เริ่มจากกรณีใช้ชัด (เช่น กลุ่มผู้ใช้หรือหมวดแอป) วัดผลความหน่วงและผลลัพธ์การเข้าถึง แล้วขยาย กำหนดนโยบายเป็นภาษาธรรมดา ตั้งการมอนิเตอร์และการแจ้งเตือนตั้งแต่ต้น และวางแผนความพร้อมสำรอง (การกำหนดเส้นทางหลายภูมิภาค ทางเข้าฉุกเฉิน และทางเลือกที่เป็นลายลักษณ์อักษร)
รู้ว่าประเภทข้อมูลที่คุณปกป้องคืออะไร (ข้อมูลที่ถูกควบคุม vs ทั่วไป) จัดให้การควบคุมสอดคล้องกับความต้องการการปฏิบัติตาม แล้วกำหนดการตรวจสอบการเข้าถึงเป็นประจำ เป้าหมายไม่ใช่การซื้อด้วยความกลัว แต่คือให้แน่ใจว่าโมเดลใหม่นี้ล้มอย่างปลอดภัยและคาดเดาได้
บทเรียนซ้ำของ Zscaler คือความชัดเจน: ย้ายการบังคับใช้นโยบายไปยังคลาวด์และทำให้การเข้าถึงขับเคลื่อนด้วยตัวตน เมื่อตรวจสอบผู้ขาย (หรือสร้างหนึ่ง) ถามคำถามง่ายๆ: "เดิมพันสถาปัตยกรรมข้อเดียวที่ทำให้ทุกอย่างง่ายขึ้นคืออะไร?" หากคำตอบคือ "ขึ้นอยู่กับ" เตรียมรับความซับซ้อนที่จะแสดงในต้นทุน เวลาเปิดตัว และข้อยกเว้น
"Zero trust" ใช้ได้เพราะมันแปลงเป็นคำสัญญาเชิงปฏิบัติ: ลดสมมติฐานความเชื่อใจ ลดงานติดตั้งเครือข่าย และการควบคุมที่ดีขึ้นเมื่อแอปย้ายออกจากออน-พรอม สำหรับทีม หมายถึงการซื้อผลลัพธ์ ไม่ใช่คำพูดฮิต เขียนผลลัพธ์ที่ต้องการ (เช่น "ไม่ให้การเข้าถึงขาเข้า" "สิทธิ์ขั้นต่ำต่อแอป" "นโยบายสม่ำเสมอสำหรับผู้ใช้ระยะไกล") และแม็ปแต่ละข้อกับความสามารถที่ทดสอบได้
ความปลอดภัยองค์กรแพร่ผ่านเครือข่ายความเชื่อใจ: ตัวแทนจำหน่าย GSIs MSPs และตลาดคลาวด์ ผู้ก่อตั้งสามารถลอกแบบนี้ได้โดยทำผลิตภัณฑ์ให้พร้อมสำหรับพันธมิตรตั้งแต่ต้น—การแพ็กเกจชัดเจน กำไรที่คาดการณ์ได้ playbook การติดตั้ง และเมตริกที่แชร์ ผู้นำด้านความปลอดภัยก็ใช้พันธมิตรได้เช่นกัน: ให้พวกเขาจัดการการเปลี่ยนแปลง การผสานตัวตน และการโยกย้ายเป็นขั้นตอน แทนที่จะพยายามยกระดับทักษะทุกทีมภายในครั้งเดียว
เริ่มจากกรณีใช้งานปริมาณสูงหนึ่งรายการ (มักเป็นการเข้าถึงอินเทอร์เน็ตหรือแอปสำคัญตัวเดียว) วัดก่อน/หลัง แล้วขยาย
คำถามสำคัญในการวางแผนการเปิดตัว:
อย่าแค่ "ขายความปลอดภัย"—ขายเส้นทางการย้าย เรื่องราวที่ชนะมักเป็น: ปัญหา → ขั้นตอนง่ายที่สุด → ชัยชนะที่วัดได้ → การขยาย สร้างการนำเข้าและการรายงานที่ทำให้มูลค่าเห็นได้ใน 30–60 วัน
รูปแบบที่เป็นมิตรกับผู้ก่อตั้งคือการเสริมผลิตภัณฑ์หลักด้วยแอปประกอบที่สร้างได้เร็ว (เวิร์กโฟลว์การประเมิน ตัวติดตามการย้าย เครื่องคิดเลข ROI พอร์ทัลพันธมิตร) ถ้าคุณอยากสร้างสิ่งเหล่านี้โดยไม่ต้องรื้อท่อพัฒนาระบบเดิมทั้งหมด Koder.ai ถูกออกแบบมาสำหรับการสร้างแอปสแต็กเต็มจากแชท—มีประโยชน์สำหรับนำเครื่องมือภายในหรือที่ใช้กับลูกค้าเข้าสู่การผลิตอย่างรวดเร็ว แล้ววนปรับตามการพัฒนากลไกการจัดจำหน่าย
หากคุณต้องการลงลึก ดูบทความเพิ่มเติม: ข้อมูลพื้นฐาน Zero Trust และ ภาพรวม SASE vs SSE การออกแบบแพ็กเกจดูได้ที่ pricing.
Zero trust คือแนวทางที่การตัดสินใจเรื่องการเข้าถึงทำเป็นรายคำขอโดยอาศัย ตัวตน สถานะอุปกรณ์ และบริบท แทนที่จะถือว่าสิ่งใดปลอดภัยเพราะอยู่ "ภายในเครือข่าย" ในทางปฏิบัติ หมายถึง:
VPN แบบดั้งเดิมมักจะวางผู้ใช้ให้ "อยู่บนเครือข่าย" ซึ่งอาจเปิดการเข้าถึงระบบมากกว่าที่ต้องการ การเข้าถึงแบบมุ่งที่แอป (app-centric) พลิกโมเดลนี้:
"Inline" หมายถึงทราฟฟิกถูกส่งผ่านจุดตรวจความปลอดภัยก่อนจะไปยังอินเทอร์เน็ตหรือแอปคลาวด์ ในโมเดลที่ให้บริการจากคลาวด์ จุดตรวจนี้จะอยู่ใน point of presence (PoP) ใกล้ผู้ใช้ ทำให้ผู้ให้บริการสามารถ:
เป้าหมายคือตัวการรักษาความปลอดภัยที่สม่ำเสมอโดยไม่ต้องส่งทราฟฟิกกลับไปยังสำนักงานใหญ่
การส่งทราฟฟิกกลับ (backhauling) ส่งทราฟฟิกเว็บและ SaaS ของผู้ใช้ระยะไกลไปยังดาต้าเซ็นเตอร์กลางเพื่อตรวจสอบแล้วส่งออกอีกครั้ง ซึ่งมักล้มเหลวเพราะ:
Secure Web Gateway (SWG) ปกป้องการท่องเว็บและการใช้แอป SaaS ของผู้ใช้ ความสามารถทั่วไปของ SWG ได้แก่:
มีประโยชน์โดยเฉพาะเมื่อทราฟฟิกส่วนใหญ่ไปยังอินเทอร์เน็ตและผู้ใช้ไม่ได้อยู่หลังไฟร์วอลล์ของบริษัทเพียงจุดเดียว
การย้ายการควบคุมความปลอดภัยไปยังคลาวด์ช่วยลดภาระการปฏิบัติการ แต่เปลี่ยนสิ่งที่คุณพึ่งพาได้ จุดที่ต้องพิจารณา:
แผนทดสอบ (pilot) ที่เสี่ยงต่ำมักสำเร็จเมื่อมีขอบเขตแคบและวัดผลได้:
เป้าหมายคือเรียนรู้เร็วโดยไม่ทำให้ทั้งองค์กรเป็นสนามทดสอบ
การกำหนดค่าผิดพลาดยังคงเป็นความเสี่ยงอันดับหนึ่งเพราะการเปลี่ยนจาก “การเข้าถึงเครือข่าย” ไปเป็น “การเข้าถึงแอป/นโยบาย” บังคับให้ทีมระบุเจตนารมณ์ชัดเจน เพื่อลดความเสี่ยง:
SSE คือการควบคุมความปลอดภัยที่ให้บริการจากคลาวด์ (เช่น SWG และการเข้าถึงแอปส่วนตัว) ที่อยู่ใกล้ผู้ใช้ ในขณะที่ SASE รวมเอามุมมองเครือข่ายเข้ามาด้วย (มักเป็น SD-WAN) ทำให้การเชื่อมต่อและความปลอดภัยถูกออกแบบร่วมกัน
ในเชิงการซื้อ:
องค์กรขนาดใหญ่มักซื้อผ่านพันธมิตรและต้องการความสามารถด้านการนำไปใช้งาน พันธมิตรช่องทาง SIs และ MSPs ช่วยโดย:
ระบบนิเวศพันธมิตรที่แข็งแรงสามารถกำหนดได้ว่าแพลตฟอร์มจะกลายเป็นมาตรฐานหรือหยุดอยู่แค่การใช้งานเล็กๆ