AI จะปรับปรุงความปลอดภัยของ API ได้อย่างไร

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

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

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

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

มาตรการรักษาความปลอดภัยตามกฎและตามนโยบาย

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

การตรวจสอบความปลอดภัยแบบคงที่

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

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

การตรวจสอบความปลอดภัยแบบไดนามิก

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

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

การรับรองความถูกต้อง

การพิสูจน์ตัวตนช่วยให้เกตเวย์ API ระบุผู้ใช้แต่ละคนที่เรียกใช้ API โดยไม่ซ้ำกัน โซลูชันเกตเวย์ API ที่พร้อมใช้งานโดยทั่วไปรองรับการพิสูจน์ตัวตนพื้นฐานความปลอดภัย OAuth 2.0 JWT (JSON Web Token) และการรักษาความปลอดภัยตามใบรับรอง เกตเวย์บางตัวยังมีเลเยอร์การพิสูจน์ตัวตนที่ด้านบนสำหรับการตรวจสอบสิทธิ์แบบละเอียดเพิ่มเติมซึ่งโดยปกติจะใช้ภาษากำหนดนโยบายสไตล์ XACML (eXtensible Access Control Markup Language) สิ่งนี้มีความสำคัญเมื่อ API มีทรัพยากรหลายรายการที่ต้องการระดับการควบคุมการเข้าถึงที่แตกต่างกันสำหรับแต่ละทรัพยากร

ข้อ จำกัด ของการรักษาความปลอดภัย API แบบเดิม

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

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

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

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

กรณีสำหรับการเพิ่มเลเยอร์ความปลอดภัย AI

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

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

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

การผสานรวมการรักษาความปลอดภัย API ตามนโยบายและ AI

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

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

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

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

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

ความท้าทายของเลเยอร์ความปลอดภัยที่ขับเคลื่อนด้วย AI

แน่นอนว่าผลประโยชน์ไม่ได้มาโดยไม่มีค่าใช้จ่าย แม้ว่าเลเยอร์ความปลอดภัยที่ขับเคลื่อนด้วย AI จะมีการป้องกัน API อีกระดับ แต่ก็มีความท้าทายบางอย่างที่ทีมรักษาความปลอดภัยจะต้องจัดการ

  • ค่าใช้จ่ายเพิ่มเติม ชั้นความปลอดภัย AI เพิ่มเติมจะเพิ่มค่าใช้จ่ายบางส่วนให้กับโฟลว์ข้อความ ดังนั้นโซลูชันการไกล่เกลี่ยควรฉลาดพอที่จะจัดการกับการรวบรวมและเผยแพร่ข้อมูลนอกขั้นตอนการไกล่เกลี่ยหลัก
  • บวกเท็จ ผลบวกที่ผิดพลาดจำนวนมากจะต้องได้รับการตรวจสอบเพิ่มเติมโดยผู้เชี่ยวชาญด้านความปลอดภัย อย่างไรก็ตามด้วยอัลกอริธึม AI ขั้นสูงบางอย่างเราสามารถลดจำนวนผลบวกลวงที่ทริกเกอร์ได้
  • ขาดความไว้วางใจ ผู้คนรู้สึกอึดอัดเมื่อไม่เข้าใจว่าการตัดสินใจเกิดขึ้นได้อย่างไร แดชบอร์ดและการแจ้งเตือนสามารถช่วยให้ผู้ใช้เห็นภาพของปัจจัยเบื้องหลังการตัดสินใจ ตัวอย่างเช่นหากการแจ้งเตือนระบุอย่างชัดเจนว่าผู้ใช้ถูกบล็อกไม่ให้เข้าถึงระบบในอัตราที่ผิดปกติ 1,000 ครั้งภายในหนึ่งนาทีผู้คนจะเข้าใจและเชื่อถือการตัดสินใจของระบบได้
  • ช่องโหว่ข้อมูล โซลูชัน AI และแมชชีนเลิร์นนิงส่วนใหญ่อาศัยข้อมูลจำนวนมากซึ่งมักมีความละเอียดอ่อนและเป็นส่วนตัว เป็นผลให้โซลูชันเหล่านี้มีแนวโน้มที่จะเกิดการละเมิดข้อมูลและการโจรกรรมข้อมูลส่วนบุคคล การปฏิบัติตาม GDPR ของสหภาพยุโรป (General Data Protection Regulation) ช่วยลดความเสี่ยงนี้ แต่ไม่ได้กำจัดทั้งหมด
  • ข้อ จำกัด ของข้อมูลที่มีป้ายกำกับ ระบบ AI ที่ทรงพลังที่สุดได้รับการฝึกฝนผ่านการเรียนรู้ภายใต้การดูแลซึ่งต้องใช้ข้อมูลที่มีป้ายกำกับซึ่งจัดระเบียบเพื่อให้เครื่องจักรเข้าใจได้ แต่ข้อมูลที่มีป้ายกำกับมีข้อ จำกัด และการสร้างอัลกอริทึมที่ยากขึ้นโดยอัตโนมัติในอนาคตจะทำให้ปัญหารุนแรงขึ้นเท่านั้น
  • ข้อมูลที่ผิดพลาด ประสิทธิภาพของระบบ AI ขึ้นอยู่กับข้อมูลที่ได้รับการฝึกฝน บ่อยครั้งที่ข้อมูลที่ไม่ดีเกี่ยวข้องกับอคติทางชาติพันธุ์ชุมชนเพศหรือเชื้อชาติซึ่งอาจส่งผลต่อการตัดสินใจที่สำคัญเกี่ยวกับผู้ใช้แต่ละราย

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

Sanjeewa Malalgoda เป็นสถาปนิกซอฟต์แวร์และผู้อำนวยการฝ่ายวิศวกรรมที่ WSO2 ซึ่งเขาเป็นผู้นำในการพัฒนา WSO2 API Manager Lakshitha Gunasekara เป็นวิศวกรซอฟต์แวร์ในทีม WSO2 API Manager 

-

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