องค์กรต่างๆ กำลังย้ายปริมาณงาน AI/ML ไปยังระบบคลาวด์ แต่กำลังประสบปัญหาด้านความปลอดภัยที่สำคัญ ต่อไปนี้คือปัญหาและวิธีแก้ไข

การย้าย AI/ML ไปยังคลาวด์ได้เริ่มต้นแล้ว

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

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

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

ในปัจจุบัน ดูเหมือนว่าการจัดการข้อกังวลด้านความปลอดภัยทางไซเบอร์อาจกลายเป็นข้อกำหนดเบื้องต้นสำหรับการย้ายปริมาณงาน AI/ML บนคลาวด์สำหรับองค์กรหลายแห่ง

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

AI/ML Cloud Migration ได้นำเสนอข้อกังวลด้านความปลอดภัยที่ถูกต้อง

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

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

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

ดังนั้นจึงเป็นที่ชัดเจนว่ารูปแบบการสื่อสารขององค์กรและรูปแบบการใช้ระบบคลาวด์มีการพัฒนาไปค่อนข้างมาก และยังชัดเจนว่าข้อกำหนดด้านการมองเห็นข้อมูลและการเข้าถึงได้พัฒนาไปเนื่องจาก AI/ML

น่าเสียดายที่แนวทางปฏิบัติด้านความปลอดภัยขององค์กรในอดีตไม่ได้มีการพัฒนาให้ก้าวทันเสมอไป อย่างน้อยที่สุด หัวข้อข่าว ล่าสุดเกี่ยวกับการละเมิดข้อมูลของ Capital One แนะนำให้เป็นเช่นนั้น

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

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

ประการที่สาม ด้วยข้อมูลที่ละเอียดอ่อนจำนวนมหาศาลที่ AI/ML ต้องการสำหรับพนักงาน องค์กรต่างๆ จำเป็นต้องแนะนำการควบคุมเพื่อหลีกเลี่ยงการรั่วไหลโดยเจตนา The Globe and Mail รายงาน ว่าการละเมิดข้อมูลที่ Desjardins Group ส่งผลกระทบต่อลูกค้า 2.9 ล้านรายนั้นเกิดจากพนักงานหลงทางซึ่งถูกกล่าวหาว่าขโมยและเปิดเผยข้อมูลที่ละเอียดอ่อน รวมถึงข้อมูลส่วนบุคคล เช่น ชื่อ วันเกิด หมายเลขประกันสังคม (คล้ายกับ US Social หมายเลขรักษาความปลอดภัย) และอีเมล โทรศัพท์ และที่อยู่บ้าน

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

แก้ไขปัญหาความปลอดภัยทางไซเบอร์ที่แนะนำโดย AI/ML

มีเทคนิคสมัยใหม่หลายประการ (ดูรูปที่ 1) ซึ่งจัดการกับภัยคุกคามด้านความปลอดภัยที่กล่าวมาข้างต้น และเป็นรากฐานสำหรับการเช่าระบบคลาวด์ขององค์กรที่ปลอดภัย

ประการแรก วิธีการรักษาความปลอดภัย “ตามข้อมูลประจำตัว»” กำหนดว่าเฉพาะข้อมูลประจำตัวที่ถูกต้องเท่านั้นที่จะให้การรับรองความถูกต้องและการอนุญาตเพื่ออนุญาตการเข้าถึงทรัพยากรภายในการเช่าระบบคลาวด์ขององค์กร

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

การใช้แนวทางการรักษาความปลอดภัยตามข้อมูลประจำตัวควรพิจารณาสิ่งต่อไปนี้น้อยที่สุด:

  • ไดเร็กทอรีภายในองค์กรและคลาวด์ (เช่น Active Directory ของ Microsoft หรือ LDAP) ควรซิงโครไนซ์ (“2” ในรูปที่ 1) ซึ่งช่วยให้สามารถจัดการข้อมูลประจำตัวและข้อมูลประจำตัวที่เกี่ยวข้องได้อย่างสม่ำเสมอ โดยไม่คำนึงว่าข้อมูลประจำตัวจะถูกสร้างขึ้นหรือใช้ที่ใด
  • อินสแตนซ์ภายในองค์กรเป็นอินสแตนซ์หลักที่เสนอแหล่งข้อมูลที่เชื่อถือได้แหล่งเดียวสำหรับข้อมูลประจำตัว ซึ่งจะช่วยลดความเสี่ยงด้านความปลอดภัยเนื่องจากข้อผิดพลาดของมนุษย์และความซับซ้อนในการกำหนดค่า จากมุมมองของผู้ใช้ สิ่งนี้มอบประสบการณ์การลงชื่อเข้าระบบครั้งเดียว (SSO) สำหรับการเข้าถึงทรัพยากรทั้งบนคลาวด์และในองค์กร ซึ่งจัดการกับความยุ่งยากทั่วไปในการจัดการ ID และรหัสผ่านหลายรายการ
  • กลไก Role-Based-Access-Control ("RBAC") ("3" ในรูปที่ 1) ซึ่งเก็บรักษาไว้ในระบบการจัดการข้อมูลประจำตัวขององค์กร เป็นระบบการอนุญาตที่จำกัดการเข้าถึงทรัพยากรสำหรับผู้ใช้ที่ได้รับอนุญาต มันทำงานเช่นนี้ (แม้ว่าจะเป็นการทำให้ง่ายขึ้น): โดยทั่วไปแล้ว บทบาทจะถูกสร้างขึ้นเพื่อแสดงถึงหน้าที่งาน สิทธิ์ถูกกำหนดให้กับบทบาทในการดำเนินการต่างๆ โดยทั่วไปแล้วผู้ใช้/พนักงานจะถูกมอบหมายให้กับกลุ่ม ซึ่งในทางกลับกัน จะถูกมอบหมายให้กับบทบาท สิ่งนี้จะสร้างระดับทางอ้อมที่เป็นประโยชน์: ผู้ใช้ไม่ได้รับการกำหนดสิทธิ์ แต่จะได้รับสิทธิ์จากการเป็นสมาชิกของบทบาทเท่านั้น ขณะนี้ การจัดการสิทธิ์ผู้ใช้ทำได้ง่ายขึ้น เนื่องจากเพียงกำหนดบทบาทที่เหมาะสมให้กับบัญชีผู้ใช้/พนักงานเท่านั้น

ประการที่สอง วิธีการรักษาความปลอดภัย “zero-trust»” (“4” ในรูปที่ 1) กำหนดทรัพยากรที่ถูกสร้างขึ้นโดยไม่มีสิทธิ์ในการเข้าถึง — ไม่มีสิ่งใดที่สามารถเข้าถึงได้ภายในการเช่าระบบคลาวด์ขององค์กร เว้นแต่จะมีการตรวจสอบสิทธิ์และการอนุญาตอย่างชัดเจน ที่ให้ไว้. สถาปัตยกรรม Zero Trust ใช้ข้อมูลประจำตัวและการอ้างสิทธิ์/ข้อมูลอุปกรณ์ (เช่น ที่อยู่ IP) เพื่อรับรองความถูกต้องของผู้ใช้และตรวจสอบการอนุญาตที่จำเป็นในการเข้าถึงข้อมูลและแอปพลิเคชันในการเช่าระบบคลาวด์ขององค์กร ด้วยวิธีนี้ การรักษาความปลอดภัยตามข้อมูลประจำตัวจะมอบความสามารถพื้นฐานที่จำเป็นสำหรับการนำนโยบาย Zero Trust ไปใช้

ประการที่สาม นโยบาย “การรั่วไหลเป็นศูนย์»” กำหนดว่าข้อมูลไม่สามารถขนส่งในรูปแบบใด ๆ ภายนอกการเช่าระบบคลาวด์ขององค์กร นโยบายนี้จะหยุดทั้งพนักงานที่สามารถเข้าถึงข้อมูลที่ละเอียดอ่อน หรือเอเจนต์ที่เป็นอันตรายที่เข้าถึงข้อมูลที่ละเอียดอ่อน ไม่ให้ข้อมูลออกหรือรั่วไหลจากการเช่าระบบคลาวด์ขององค์กร จากประสบการณ์ของฉัน Zero Leakage สามารถนำไปใช้ได้โดยใช้ “พอร์ทัลที่ปลอดภัย” (“5” ในรูปที่ 1) ซึ่งทำหน้าที่เป็นวิวพอร์ตที่นักวิทยาศาสตร์ข้อมูลใช้เพื่อเข้าถึงการเช่าระบบคลาวด์ พอร์ทัลอนุญาตให้เข้าถึงระบบคลาวด์ได้ค่อนข้างเต็มประสิทธิภาพ แต่ความสามารถเฉพาะถูกปิดใช้งาน (โดยทั่วไปคือความสามารถในการ "ตัดวาง" และดาวน์โหลด) ที่จะอนุญาตให้เคลื่อนย้ายข้อมูลได้ Citrix มีผลิตภัณฑ์จำนวนหนึ่งที่รองรับสิ่งนี้ เช่นเดียวกับ Microsoft (Remote Desktop) และ VMWare (Horizon View)

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

สู่ AI/การเรียนรู้ของเครื่องที่ปลอดภัย

กลับมาที่ข้อเสนอเดิมของฉัน: การโยกย้ายปริมาณงาน AI/ML ระดับองค์กรไปยังระบบคลาวด์เป็นสิ่งที่หลีกเลี่ยงไม่ได้ แต่ต้องรับทราบว่าสิ่งนี้ทำให้เกิดข้อกังวลด้านความปลอดภัยใหม่และร้ายแรงซึ่งทำให้องค์กรต่างๆ ดำเนินการย้ายข้อมูลนี้ด้วยความระมัดระวัง

แต่รัฐวิสาหกิจกลับไม่หยุดนิ่ง พวกเขากำลังตอบกลับโดย:

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

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

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