Refael Angel, ผู้ร่วมก่อตั้งและ CTO ของ Akeyless – สัมภาษณ์ Series

Refael Angel ผู้ร่วมก่อตั้งและ CTO ของ Akeyless เป็นผู้นำด้านความปลอดภัยทางไซเบอร์และวิศวกรรมซอฟต์แวร์ที่มีประสบการณ์อย่างลึกซึ้งในการรักษาความปลอดภัยบนคลาวด์ การเข้ารหัส การยืนยันตัวตนของเครื่อง และโครงสร้างพื้นฐานขององค์กร ตั้งแต่เริ่มก่อตั้ง Akeyless ในปี 2018 เขาได้ช่วยสร้างบริษัทโดยมุ่งเน้นไปที่การบริหารความลับและความปลอดภัยด้านตัวตนสำหรับสภาพแวดล้อมคลาวด์แบบเนทีฟ ก่อนที่จะเข้าร่วม Akeyless เขา曾ทำงานเป็นวิศวกรซอฟต์แวร์ระดับสูงด้านความปลอดภัยที่ Intuit (INTU ) โดยสร้างระบบสำหรับการจัดการคีย์เข้ารหัสบนคลาวด์สาธารณะและการยืนยันตัวตนของเครื่อง โดยได้รับประสบการณ์จริงในการใช้งาน AWS, Go, Python, Java, PHP, Bash, Linux, Git และ Jenkins ในช่วงแรกของอาชีพการงานของเขา Angel曾ทำงานในตำแหน่งวิศวกรซอฟต์แวร์ที่ 3D Systems (DDD ) และ Cimatron โดยพัฒนาซอฟต์แวร์ CAD/CAM และแอปพลิเคชันบน Windows โดยใช้ C/C++, C#, WPF, MFC และรูปแบบการออกแบบเชิงวัตถุ

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

คุณร่วมก่อตั้ง Akeyless ในปี 2018 หลังจากสร้างระบบการจัดการคีย์เข้ารหัสและการยืนยันตัวตนของเครื่องที่ Intuit สิ่งใดที่ทำให้คุณเชื่อว่ามีช่องว่างในการรักษาความปลอดภัยบนคลาวด์และการจัดการตัวตนที่ทำให้คุณตัดสินใจเริ่มต้น Akeyless และวิสัยทัศน์ดั้งเดิมของคุณได้พัฒนาไปอย่างไรเมื่อตัวแทน AI ออกมาเป็นตัวตนใหม่?

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

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

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

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

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

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

ความท้าทายอีกประการหนึ่งซึ่งเป็นหนึ่งในความท้าทายที่สำคัญที่สุดคือการทำให้ส่วนต่างๆ มีการอัปเดตอย่างต่อเนื่อง เราต้องสามารถแทนที่ส่วนต่างๆ ด้วยค่าทางคณิตศาสตร์ใหม่ในทุกตำแหน่ง ในขณะที่คีย์หลักที่ส่วนต่างๆ แทนนั้นยังคงไม่เปลี่ยนแปลง และกระบวนการเข้ารหัสไม่ถูกรบกวน การเพิ่มสิ่งนี้ทำให้เพิ่มความปลอดภัยของโซลูชันอย่างมาก เนื่องจากผู้โจมตีไม่สามารถรวบรวมส่วนต่างๆ ได้อย่างอดทนเมื่อเวลาผ่านไป ส่วนต่างๆ ที่ถูกจับเมื่อสัปดาห์ที่แล้วไม่เกี่ยวข้องกับส่วนต่างๆ ที่มีอยู่ในวันนี้ ดังนั้นจึงเป็นเพียงสัญญาณรบกวน เพื่อที่จะเรียนรู้อะไรเกี่ยวกับคีย์ ผู้โจมตจะต้องสามารถเข้าถึงส่วนต่างๆ ทั้งหมดในตำแหน่ง ทรัสต์โดเมน และช่วงเวลาการอัปเดตที่เพิ่มขึ้นในเวลาเดียวกัน ซึ่งเป็นความต้องการที่ยากขึ้นอย่างมากเมื่อจำนวนตำแหน่ง โดเมนความไว้วางใจ และความถี่ในการอัปเดตเพิ่มขึ้น เมื่อรวมกับเกณฑ์แบบ all-or-nothing ซึ่ง 100% ของส่วนต่างๆ ถูกต้องและไม่มีส่วนใดๆ ที่รั่วไหล การอัปเดตเปลี่ยนโมเดลความปลอดภัยจากการรับประกันแบบคงที่เป็นแบบผูกกับเวลา

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

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

ข้อผิดพลาดทั่วไปอื่นๆ ที่ฉันเห็น ได้แก่ การให้สิทธิ์แบบยืนยันแทนการเข้าถึงแบบ just-in-time การพึ่งพาสิทธิ์แบบ role-based ที่หยาบซึ่งอธิบายว่าตัวแทนสามารถเข้าถึงอะไรได้ แต่ไม่เคยระบุว่าตัวแทนจะทำอะไร การให้ตัวแทนมีเส้นทางเครือข่ายโดยตรงไปยังฐานข้อมูลและ API เพื่อให้การละเมิดกลายเป็นการเคลื่อนไหวแบบขนาน และไม่มีห่วงตรวจสอบที่เชื่อมการกระทำของตัวแทนกลับไปยังผู้คนและคิวรี่ที่กระตุ้นให้เกิดการกระทำนั้นๆ ทั้งหมดนี้เป็นการพยายามนำการควบคุมยุคมนุษย์มาใช้กับสิ่งที่ไม่เหมือนมนุษย์

Akeyless ได้โต้แย้งว่าตัวแทน AI ต้องการโมเดลตัวตนที่แตกต่างจากมนุษย์หรือภาระงานเครื่องแบบดั้งเดิม คุณคิดว่าอะไรทำให้ตัวแทน AI ยากที่จะรักษาความปลอดภัยมากกว่าโครงสร้าง IAM และ PAM ที่มีอยู่?

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

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

และนี่คือจุดที่ IAM และ PAM ที่มีอยู่แตกหักมากที่สุด: RBAC และ ABAC แบบคงที่ไม่สามารถบรรลุผลต่อผู้กระทำที่ไม่แน่นอนได้ ตัวแทน AI ที่มีโทเค็นแบบมีหน้าที่และ TTL ที่ถูกต้องสามารถถูกฉีดคิวรี่ได้ หลงทางในการค้นหาที่ทำลายล้าง หรือเปลี่ยนจากงานอ่านไปยังงานเขียนในเซสชันเดียวกัน โดยไม่มีการละเมิดนโยบายที่เห็นได้ชัดเจนที่ชั้นการอนุญาต

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

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

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

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

เมื่อตัวแทน AI มีความสามารถในการวางแผน ทำงาน และโต้ตอบกับระบบหลายระบบอิสระ อะไรคือเวกเตอร์การโจมตีที่คุณกังวลมากที่สุดในช่วงสามถึงห้าปี?

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

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

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

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

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

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

ก่อนที่ตัวแทน AI ใดๆ จะทำงานอิสระในระบบการผลิต ฉันอยากเห็นหลายสิ่ง ประการแรก คือ ไม่มีค่าเครดิตแบบยืนยันบนเครื่อง โดยให้สิทธิ์แบบ just-in-time สำหรับการเข้าถึงในแต่ละเซสชัน ประการที่สอง คือ ไม่มีการเชื่อมต่อเครือข่ายโดยตรง ดังนั้นทุกการกระทำของตัวแทนจึงถูกจัดให้โดยจุดควบคุมที่จำเป็น ประการที่สาม คือ การบังคับใช้นโยบายที่ตระหนักถึงความตั้งใจ ซึ่งประเมินวัตถุประสงค์ของคำขอเทียบกับคำสั่งเริ่มต้นที่กระตุ้นให้เกิดการกระทำนั้น ก่อนที่จะออกค่าเครดิตใดๆ ประการที่สี่ คือ การตรวจสอบและตอบสนองในเซสชันเพื่อให้ข้อมูลที่ละเอียดอ่อน เช่น PII และ PHI ถูกทำให้ไม่สามารถอ่านได้ก่อนที่จะเข้าสู่หน้าต่างบริบทของตัวแทน และประการที่ห้า คือ บันทึกการตรวจสอบที่ไม่สามารถเปลี่ยนแปลงได้ซึ่งเชื่อมต่อคำสั่งเริ่มต้นของมนุษย์ ความตั้งใจที่จัดประเภท นโยบายที่ตัดสินใจ การกระทำ และผลลัพธ์สุดท้าย

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

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

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

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

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

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

ชั้นการรับรองอัตลักษณ์ของตัวแทน AI ที่ฉันคาดหวังคือการเชื่อมโยงอัตลักษณ์กับตัวตนของงานที่รันไทม์ออกมา เช่น IAM บนคลาวด์ โทเค็นบัญชีบริการของ Kubernetes การสหพันธ์ OIDC และมาตรฐานเช่น SPIFFE/SPIRE ที่ได้รับการพิสูจน์แล้วและใช้ได้กับหลายซับสเตรท การอนุญาตจะถูกแสดงเป็นความสัมพันธ์ระหว่างวิธีการรับรองและการเข้าถึงระบบเป้าหมาย ไม่ใช่ระหว่างอัตลักษณ์ที่ตั้งชื่อและขอบเขต และจุดศูนย์กลางจะเป็นระนาบการบังคับใช้ในขณะทำงาน ประตูที่จัดให้ทุกการกระทำ ระบุความตั้งใจ ใส่ค่าเครดิตแบบ just-in-time ปิดบังการตอบสนองที่ละเอียดอ่อน และผลิตห่วงตรวจสอบที่สมบูรณ์ อัตลักษณ์ยังคงมีความสำคัญ แต่จัดเรียงตัวหลังการบังคับใช้ ไม่ใช่ก่อนหน้า

ขอขอบคุณสำหรับการสัมภาษณ์ที่ยอดเยี่ยม ผู้อ่านสามารถเรียนรู้เพิ่มเติมได้ที่ Akeyless