จุดบอดของแอปพลิเคชันเดิมของ MFA

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

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

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

แอปพลิเคชั่นดั้งเดิมคืออะไร?

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

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

เหตุใดจึงไม่สามารถปกป้องแอปพลิเคชันรุ่นเก่าด้วย MFA

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

นอกจากนี้ แอปพลิเคชันรุ่นเก่ามักจะตรวจสอบความถูกต้องกับ Active Directory มากกว่า NTLM และ Kerberos โปรโตคอล ซึ่งแตกต่างจากโปรโตคอลการตรวจสอบความถูกต้องสมัยใหม่ที่ SaaS และเว็บแอปพลิเคชันใช้ ยังไม่รองรับ MFA ทำให้แอปพลิเคชันรุ่นเก่าไม่มีตัวเลือกการป้องกัน MFA ที่ใช้งานได้จริง

การขาด MFA ในแอปรุ่นเก่าทำให้องค์กรต้องสูญเสียข้อมูลและการดำเนินงานหยุดชะงัก

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

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

นอกจากนี้ การไม่วางการป้องกัน MFA สำหรับแอปพลิเคชันเดิมสามารถสร้างปัญหาการปฏิบัติตามข้อกำหนดสำหรับองค์กรที่ต้องการปฏิบัติตามกรอบการกำกับดูแลของอุตสาหกรรมและ ข้อกำหนดการประกันภัยทางไซเบอร์. 

ทางเลือกในการป้องกันตัวตนในปัจจุบันยังไม่เพียงพอ

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

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

Solution: SilverfortMFA ของ Unified Identity Protection

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

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

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

ทางนี้, Silverfort เอาชนะความท้าทายทั้งหมดที่เราอธิบายไว้ในส่วนก่อนหน้า:

• ไม่ต้องการการเปลี่ยนแปลงรหัสใด ๆ กับตัวแอปเอง
• ไม่จำเป็นต้องติดตั้งตัวแทนใด ๆ บนเซิร์ฟเวอร์ของแอป
• ครอบคลุมความพยายามในการเข้าถึงทั้งหมดที่ใช้ Active Directory.
• ให้การป้องกันเชิงรุกแบบเรียลไทม์สำหรับความพยายามใด ๆ ในการใช้ข้อมูลรับรองที่ถูกบุกรุกเพื่อเข้าถึงแอพรุ่นเก่า

เรียนรู้เพิ่มเติมเกี่ยวกับจุดบอดของ MFA และวิธีป้องกันใน Silverfortอีบุ๊คของ: ประเมินการคุ้มครอง MFA ของคุณอีกครั้ง.