การรักษาความปลอดภัยของแอปพลิเคชันในสภาพแวดล้อมแบบ Cloud-native

แนวทางปฏิบัติที่ดีที่สุดสำหรับการรักษาความปลอดภัยของแอปพลิเคชันในสภาพแวดล้อมแบบ Cloud-native

หมายเหตุบรรณาธิการ: นี่คือส่วนที่ 3 ของชุดรักษาความปลอดภัยระบบ Cloud ซึ่งประกอบด้วย 5 ส่วนซึ่งครอบคลุมการปกป้อง perimeter,  endpoints, application code, sensitive data และบริการและบัญชีผู้ใช้ขององค์กรจากภัยคุกคาม

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

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

แต่ก่อนอื่นเราจะอธิบายสั้น ๆ เกี่ยวกับความซับซ้อนของ Application architectures ที่ทันสมัยและวิธีที่พวกเขาเสี่ยงต่อการถูกโจมตี

เริ่มต้นกับ Application architectures ที่ทันสมัย

แอปพลิเคชันแบบดั้งเดิมถูกสร้างขึ้นบน Monolithic architectures ในประวัติศาสตร์ โมเดลเหล่านี้จะปรับใช้ส่วนประกอบทั้งหมดที่ประกอบขึ้นเป็นแอปพลิเคชัน เช่น user interface, application services และ backend resources, as a single, contained unit ตัวอย่างเช่น ฟังก์ชันหลักของแอปพลิเคชันอีคอมเมิร์ซ เช่น การประมวลผลการชำระเงิน การปฏิบัติตามคําสั่งซื้อ และการจัดการผลิตภัณฑ์ มีความสัมพันธ์กันอย่างแน่นแฟ้นและมักขึ้นอยู่กับฐานข้อมูลที่ใช้ร่วมกัน สำหรับแอพพลิเคชันขนาดเล็ก Architecture นี้จะช่วยลดความซับซ้อนในกระบวนการพัฒนาและเผยแพร่ฟังก์ชันการทำงานใหม่ เนื่องจากวิศวกรเพียงแค่ปรับเปลี่ยนที่เก็บ Code เพียงรายการเดียว และปรับใช้การเปลี่ยนแปลงที่บรรจุเป็นไฟล์เดียวหรือ Directory อย่างไรก็ตาม Monolithic applications มีข้อจํากัดโดยธรรมชาติและจะนํามาซึ่งความซับซ้อนเมื่อขนาดขององค์กรปรับขนาด

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

ด้วยเหตุผลเหล่านี้และอื่น ๆ อีกมากมาย องค์กรต่างๆ กำลังย้าย Monolithic application ของพวกเขาไปยัง Microservice ในระบบ Cloud อย่างต่อเนื่อง Microservice-based architecture จะแบ่งการใช้งานออกเป็นชุดบริการที่มีขนาดเล็กลงและเป็นอิสระตามฟังก์ชันการทำงาน แผนภาพต่อไปนี้แสดงถึงวิธีการแยกฟังก์ชันหลักของ Monolithic e-commerce application แบ่งออกเป็นบริการที่แยกส่วนหลายรายการ โดยมีฐานข้อมูลเฉพาะ

Microservice-based architectures มีข้อดีหลายประการ พวกเขาช่วยให้องค์กรสามารถสร้างแอปพลิเคชันด้วยการแยกข้อผิดพลาดที่ดีขึ้น ซึ่งหมายความว่าปัญหาในบริการหนึ่งมีโอการน้อยที่จะส่งผลเสียต่อบริการอื่น ๆ Microservices ยังเป็นสิ่งที่ไม่รู้ทางเทคนิค ดังนั้นแต่ละบริการจึงสามารถใช้ภาษาการเขียนโปรแกรม กรอบการพัฒนา หรือโครงสร้างพื้นฐานที่แตกต่างกันไปตามเป้าหมายของตนและองค์กร ตัวอย่างเช่น โครงสร้างพื้นฐาน Microservice สามารถใช้ประโยชน์จากกรอบคอนเทนเนอร์ เช่น Docker และ Kubernetes เทคโนโลยีที่ไม่มีเซิร์ฟเวอร์หรือการรวมกันของทั้งสอง เครื่องมือเหล่านี้ได้รับการออกแบบมาเป็นพิเศษเพื่อรองรับบริการ Modular application และกำลังได้รับความนิยมเพิ่มขึ้นในระบบ Cloud สาธารณะที่สำคัญทั้งหมด ในทางกลับกันฟังก์ชันแบบไร้เซิร์ฟเวอร์จะแยกฟังก์ชันการทำงานของแอปพลิเคชันออกเป็นโมดูลเดียวที่ดำเนินการภายใต้เงื่อนไขพิเศษเท่านั้น วิธีนี้จะแยกบริการผ่าน API ซึ่งจะช่วยเพิ่มความเร็วในการปรับใช้ และลดต้นทุน รวมทั้งยังมีข้อดีอื่น ๆ อีกมากมาย

ดังนั้น Microservice-based architectures เทคโนโลยีและทรัพยากรที่รองรับ จึงกลายเป็นมาตรฐานในการสร้างแอปพลิเคชัน Cloud ที่ทันสมัย แต่การออกแบบที่แยกออกจากกันอาจมีความเสี่ยงต่อภัยคุกคามด้านความปลอดภัยต่าง ๆ เป็นพิเศษ เพื่อให้มั่นใจว่าบริการโฮสติ้งของตนได้รับการปกป้อง ผู้ให้บริการ Cloud ใช้รูปแบบความรับผิดชอบร่วมกันเพื่อปกป้องระบบทั้งหมดของบริการที่ไม่มีเซิร์ฟเวอร์ และคอนเทนเนอร์ที่รองรับแอปพลิเคชัน ในขณะที่องค์กรปกป้องรหัสและข้อมูลของแอปพลิเคชันของตน

การใช้เครื่องมือและการควบคุมความปลอดภัยในทุกขั้นตอนเพื่อปกป้องส่วนประกอบของแอปพลิเคชันบนระบบ Cloud เช่น Code และโครงสร้างพื้นฐานซึ่งเรียกว่าความปลอดภัยของแอปพลิเคชัน ในบทความนี้ เราจะเน้นแนวทางปฏิบัติที่ดีที่สุดต่อไปนี้เพื่อรักษาความปลอดภัยแอปพลิเคชันเหล่านี้:

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

ด้วยแนวทางปฏิบัติเหล่านี้ องค์กรสามารถเสริมมาตรการรักษาความปลอดภัยที่มีอยู่ของ endpoint และ network perimeter เพื่อให้พวกเขาสามารถสร้างกลยุทธ์การป้องกันในเชิงลึกที่มีประสิทธิภาพ

ติดตามข่าวสารเกี่ยวกับภัยคุกคามล่าสุดและความสำคัญ

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

ผู้กระทำการคุกคามกำหนดเป้าหมายแอปพลิเคชันและฟังก์ชันการทำงานด้วยเหตุผลหลายประการ กิจกรรมประเภทนี้เรียกว่าการใช้ฟังก์ชันการทํางานในทางที่ผิด (abuse of functionality) และอาจรวมถึงเป้าหมาย เช่น การเก็บข้อมูลขององค์กรเพื่อเรียกค่าไถ่ การใช้ประโยชน์จากระบบคูปองหรือส่วนลดของแอปพลิเคชัน หรือการนําระบบ business-critical ออฟไลน์ เพื่อให้บรรลุเป้าหมายเหล่านี้ ผู้เข้าร่วมภัยคุกคามพยายามที่จะค้นหาและใช้ประโยชน์จากจุดอ่อนของแอปพลิเคชัน ดังนั้น จึงเป็นสิ่งสำคัญที่จะต้องตระหนักถึงความเสี่ยงด้านความปลอดภัยที่พบบ่อยที่สุด Open Web Application Security Project (OWASP) ได้ระบุช่องโหว่ 10 จุดที่ผู้กระทำการคุกคามอาจนำไปใช้ในทางที่ผิด ซึ่งรวมถึงการควบคุมการเข้าถึงที่ผิดพลาด การพึ่งพาที่ล้าสมัย การออกแบบแอปพลิเคชันที่ไม่ปลอดภัย และช่องว่างในการบันทึกและตรวจสอบความปลอดภัย

จุดอ่อนเหล่านี้ สามารถสะท้อนให้เห็นใน Code และโครงสร้างพื้นฐานของแอปพลิเคชัน เช่น Kubernetes clusters และเทคโนโลยีไร้เซิร์ฟเวอร์ สำหรับ Kubernetes บางพื้นที่ที่มีความเสี่ยงมากที่สุด รวมถึงภาระงานและการกำหนดค่าการควบคุมการเข้าถึงตามบทบาท (role-based access control: RBAC) ตัวอย่างเช่น การข่มขู่ผู้เข้าร่วมงานสามารถใช้ประโยชน์จากภาระงานที่ไม่ได้รับการป้องกันหรือไม่ได้รับการตรวจสอบ โดยการหมุนคอนเทนเนอร์ที่มีภาพอันตราย นอกจากนี้ นโยบาย RBAC ที่ผ่อนคลายมากเกินไป อาจให้สิทธิ์แก่ผู้เข้าร่วมที่คุกคามการเข้าถึงกลุ่มคลัสเตอร์และทรัพยากรของพวกเขาได้ไม่จำกัด

Architecture แบบไร้เซิร์ฟเวอร์อาจถูกโจมตีในระดับแอปพลิเคชัน แม้ว่าบริการประเภทนี้จะใช้ Code เมื่อจำเป็นเท่านั้นและผู้ให้บริการ Cloud จะจัดการทรัพยากรพื้นฐานใด ๆ อย่างไรก็ตาม ผู้เข้าร่วมภัยคุกคามสามารถใช้ประโยชน์จาก Code แบบไร้เซิร์ฟเวอร์ คล้ายกับ Code ที่ทำงานบนคอนเทนเนอร์หรือโฮสต์เฉพาะ ตัวอย่างเช่น ฟังก์ชันแบบไร้เซิร์ฟเวอร์จะเป็นแบบ event-based ซึ่งหมายความว่าพวกเขาอาศัยกิจกรรมภายนอก (เช่น เหตุการณ์) เพื่อเรียกใช้ Code ฟังก์ชัน เช่น การอัปโหลดไปยังถังจัดเก็บข้อมูลหรือคำขอ HTTP ดังนั้นบริการแบบไร้เซิร์ฟเวอร์จึงมีความเสี่ยงต่อการโจมตี event-data injection ซึ่งรวมถึงการส่ง Code ที่เป็นอันตรายหรือคำสั่ง SQL ไปยัง payload ของเหตุการณ์ที่จัดการโดยฟังก์ชัน

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

การใช้แบบจำลองภัยคุกคามเพื่อเปิดเผยช่องโหว่ในการออกแบบแอปพลิเคชัน

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

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

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

STRIDE ช่วยให้องค์กรสามารถจัดลำดับความสำคัญของการใช้มาตรการรักษาความปลอดภัยในฟังก์ชันใหม่ บรรลุเป้าหมายได้โดยช่วยให้องค์กรจัดทำรายการบริการแอปพลิเคชันและข้อมูลที่เกี่ยวข้องในการพัฒนาฟีเจอร์ใหม่ ๆ แผนภาพต่อไปนี้แสดงตัวอย่างโมเดลภัยคุกคาม STRIDE สำหรับบริการแอปพลิเคชันโฮสติ้งบน Cloud ใหม่:

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

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

ใช้การตรวจสอบความถูกต้องและการควบคุมการเข้าถึงในระดับแอปพลิเคชัน

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

Input validation aims มีวัตถุประสงค์เพื่อ anitize untrusted input เช่น ฟิลด์แบบฟอร์ม การอัปโหลดไฟล์ และ query parameters Input ที่ไม่ผ่านการ sanitize หรือการตรวจสอบอาจ ช่วยให้ผู้คุกคามสามารถแทรก Code ที่เป็นอันตรายลงใน Input เพื่อกระตุ้นปัญหาใน Downstream service หรือส่งผลกระทบต่อ End-users ที่มีปฏิสัมพันธ์กับแอปพลิเคชัน ตัวอย่างเช่นผู้เข้าร่วมภัยคุกคามสามารถลองแทรกสคริปต์ที่เป็นอันตรายลงในฟิลด์ที่ unsanitize เช่น กล่องความคิดเห็นซึ่งเซิร์ฟเวอร์จะดำเนินการทุกครั้งที่ผู้ใช้ดูหน้าเว็บ การโจมตีแบบนี้เรียกว่า Cross Site Script (XSS) เป็นวิธีที่โดดเด่นในการขโมยข้อมูลผู้ใช้ Input validation ช่วยให้องค์กรสามารถลดการโจมตีเหล่านี้และประเภทอื่น ๆ ของการ injection ซึ่ง OWASP เชื่อว่าเป็นหนึ่งในความเสี่ยงที่ใหญ่ที่สุดของแอปพลิเคชัน

องค์กรสามารถเริ่มลดช่องโหว่ประเภทนี้ได้โดยมุ่งเน้นไปที่กลยุทธ์การตรวจสอบ syntactic and semantic ของ Input ทั้งหมด รวมถึง Serverless event input วิธีการ Syntactic บังคับใช้ Syntax ข้อมูลของสกุลเงิน วันที่ และข้อมูลระบุตัวบุคคล เช่น หมายเลขบัตรเครดิต และหมายเลขประกันสังคม วิธีการ Semantic validation บังคับ Input ค่าของข้อมูลตามกฎทางธุรกิจ เช่น ที่อยู่อีเมลที่ถูกต้องในรูปแบบ

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

OWASP เสนอแนวทางปฏิบัติที่ดีที่สุดที่องค์กรสามารถพิจารณาได้ เมื่อพัฒนาระบบการอนุญาตและการควบคุมการตรวจสอบสิทธิ์ผ่าน Application code, serverless functions และ Kubernetes architecture รวมถึง:

• บังคับใช้รหัสผ่านที่รัดกุมและการตรวจสอบหลายสิทธิ์ปัจจัยสำหรับทุกบัญชี
• การจัดเก็บรหัสผ่านด้วยการเทคโนโลยีการเข้ารหัสที่แข็งแกร่ง
• การบังคับใช้หลักการอนุญาตขั้นต่ำและปฏิเสธคำขอทั้งหมดโดยค่าเริ่มต้น
• ใช้ Role Based Access Control (RBAC) หรือ Property Based Access Control (ABAC) Process
• ใช้การเข้าสู่ระบบของเหตุการณ์การอนุญาตและการตรวจสอบสิทธิ์ทั้งหมด

องค์กรสามารถดําเนินการตามข้อเสนอเหล่านี้ต่อไป โดยจัดลำดับความสําคัญกับการแยกทรัพยากร ตัวอย่างเช่น Serverless functions ควรมีบทบาทในการจัดการตัวตนและการเข้าถึง (IAM) ของตนเอง การแยกบทบาทตามหน้าที่ช่วยให้องค์กรสามารถกำหนดระดับสิทธิ์ที่จำเป็นได้เท่านั้น ซึ่งบังคับหลักการอำนาจขั้นต่ำ สำหรับ Kubernetes clusters องค์กรสามารถแยกปริมาณงานคอนเทนเนอร์ออกจากโฮสต์ เพื่อให้แน่ใจว่าผู้คุกคามสามารถเข้าถึงทรัพยากรระบบได้ จำกัด

สร้างกลยุทธ์การตรวจสอบที่มีประสิทธิภาพสำหรับ code, endpoints และ networks

ความเข้าใจอย่างถ่องแท้เกี่ยวกับกิจกรรมของแอปพลิเคชันใน network, service และ code level มีความสำคัญต่อการระบุและลดภัยคุกคาม แต่ในขณะที่องค์กรต่างๆ ยังคงขยายโครงสร้างพื้นฐานระบบ Cloud เพื่อรวมบริการแอพพลิเคชั่นต่างๆ มากขึ้น อาจเป็นเรื่องยากมากขึ้นที่จะรู้ว่าเครื่องมือตรวจสอบความปลอดภัยใดที่คุ้มค่ากับการลงทุน เพื่อสร้างกลยุทธ์การตรวจสอบที่มีประสิทธิภาพ ซึ่งรองรับโครงสร้างพื้นฐานที่ซับซ้อน องค์กรต่างๆ จึงต้องมุ่งเน้นการลงทุนระบบตรวจจับที่เหมาะสมในแต่ละระดับ

แผนภาพต่อไปนี้เน้นขอบเขตที่องค์กรสามารถตรวจสอบกิจกรรมของ network, endpoint และ application (หรือโค้ด) เลเยอร์:

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

ในส่วน 1 และ 2 ของซีรีส์นี้ เราพูดถึงเครือข่าย Cloud ที่รองรับแอปพลิเคชันเครื่องมือตรวจสอบความปลอดภัยที่หลากหลายสำหรับเครือข่ายย่อย endpoints และวิธีที่ Datadog ให้มุมมองที่ครอบคลุมของเลเยอร์เหล่านี้ การใช้กลยุทธ์การตรวจสอบที่มีประสิทธิภาพในเลเยอร์แอปพลิเคชันจำเป็นต้องมีความเข้าใจอย่างลึกซึ้งเกี่ยวกับ Code บริการและการพึ่งพาบุคคลที่สาม App Log เป็นแหล่งหลักในการติดตามกิจกรรม code-level และเครื่องมือเช่น Cloud SIEM สามารถช่วยจัดระเบียบบันทึกการคัดกรองอย่างรวดเร็วเพื่อค้นหาพฤติกรรมที่ผิดปกติ แต่ก่อนที่ภัยคุกคามของแอปพลิเคชันจะได้รับการอัปเกรดบันทึกอาจไม่ได้ให้บริบทเพียงพอที่จะลดภัยคุกคาม ซึ่งหมายความว่าองค์กรยังต้องสามารถติดตามว่าคำขอโต้ตอบกับ Code แอปพลิเคชันอย่างไรเช่นการเรียกใช้ API หรือคำสั่ง SQL

แพลตฟอร์มการจัดการความปลอดภัยของแอปพลิเคชันช่วยให้องค์กรสามารถมองเห็นการโจมตีเป้าหมายหรือช่องโหว่ที่ส่งผลกระทบต่อบริการและ API ของแอพพลิเคชันได้แบบเรียลไทม์ เช่น OWASP หรือ Common Vulnerabilities and Exposures (CVE) program ตัวอย่างเช่น Datadog ASM สามารถระบุรูปแบบการแทรก SQL และช่วยให้องค์กรมองเห็นเส้นทางการโจมตีได้ดังต่อไปนี้:

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

ดังที่ได้กล่าวไว้ก่อนหน้านี้ แอปพลิเคชันระบบ Cloud ที่ทันสมัยเป็นแบบโมดูลาร์ในการออกแบบ ซึ่งหมายความว่าฟังก์ชันหลักมักจะให้บริการโดย Open-source libraries ที่องค์กรไม่สามารถจัดการได้ เครื่องมือ Software Composition Analysis (SCA) สามารถช่วยองค์กรในการจัดการการพึ่งพาบุคคลที่สามเหล่านี้และตรวจสอบปัญหาต่างๆ เช่นแพ็คเกจที่ล้าสมัย ภาพตัวอย่างต่อไปนี้ แสดง Apache logging library ที่ล้าสมัยสำหรับการจัดการช่องโหว่ Datadog:

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

ปกป้องแอปของคุณด้วยวิธีปฏิบัติที่ดีที่สุดเหล่านี้

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

อ้างอิง Datadog

สอบถามเพิ่มเติม
💬Line: @monsterconnect https://lin.ee/cCTeKBE
☎️Tel: 02-026-6664
📩Email: [email protected]
📝 Price List สินค้า https://bit.ly/3mSpuQY

🛍 Lazada Shop https://www.lazada.co.th/shop/monsteronline/
🛒 Shopee Online https://shopee.co.th/shop/849304465/
🏷 LINE SHOPPING https://shop.line.me/@monsterconnect

🏢 Linkedin : https://www.linkedin.com/company/monster-connect-co-ltd/
📺 YouTube : https://www.youtube.com/c/MonsterConnectOfficial
📲 TikTok : https://www.tiktok.com/@monsteronlines
🌍 Website : www.monsterconnect.co.th