ทำไมทางออก VPN ที่ใช้ร่วมกันจึงกระตุ้นคำเตือนการเข้าสู่ระบบที่คุณไม่ได้ก่อ
การบล็อกการเข้าสู่ระบบมักเป็นคะแนนความเสี่ยง ไม่ใช่คำตัดสินเกี่ยวกับอุโมงค์ของคุณ ทางออกที่ใช้ร่วมกันเปลี่ยนว่าใครอื่นถูกรวมอยู่ในคะแนนนั้นและต้องเสียอะไร
เปิดเว็บไซต์ที่คุ้นเคยผ่าน VPN แล้วเจอการท้าทายเพิ่มเติม คำอธิบายที่ชวนให้คิดคืออุโมงค์ถูกตรวจพบ มีบางอย่างถูกตรวจพบ แต่ไม่ใช่คุณ เว็บไซต์ให้คะแนนสัญญาณหลายอย่าง หนึ่งในนั้นคือที่อยู่ต้นทาง และที่อยู่ดังกล่าวถูกใช้ร่วมกับคนแปลกหน้าที่อาจสร้างการเข้าสู่ระบบล้มเหลวเมื่อหนึ่งนาทีก่อน การอ่านคำตัดสินว่าเป็นคำตัดสินเกี่ยวกับการเชื่อมต่อของคุณคือการเข้าใจผิดว่าคะแนนนี้มีไว้เพื่ออะไร
ที่อยู่ต้นทางตัดสินอะไรได้และตัดสินอะไรไม่ได้
ที่อยู่ IP อธิบายเส้นทางผ่านเครือข่าย ณ ช่วงเวลาหนึ่ง มันไม่ได้ระบุตัวบุคคล อุปกรณ์ หรือแม้แต่บัญชีเดียว และด้วย NAT ระดับผู้ให้บริการหรือกลุ่ม VPN ที่คับคั่ง มันอาจเป็นตัวแทนของเซสชันที่ไม่เกี่ยวข้องกันหลายพันเซสชันพร้อมกัน เว็บไซต์ที่ถือว่าที่อยู่เป็นตัวตนจริง ๆ แล้วถือว่ามันเป็นชื่อเสียง ซึ่งเป็นข้อความทางสถิติ ไม่ใช่ข้อเท็จจริง
คนสองคนใช้ทางออกร่วมกันและให้หลักฐานตรงข้ามกันได้ คนหนึ่งเข้าสู่ระบบสำเร็จด้วยปัจจัยที่สอง อีกคนลองรหัสผ่านสี่สิบรหัส ที่อยู่เหมือนกัน ดังนั้นกฎใดที่อิงเฉพาะที่อยู่จึงแยกแยะพวกเขาไม่ได้ และการตอบสนองใดที่ถูกกระตุ้นก็ใช้กับทั้งคู่
นี่ไม่ใช่ข้อโต้แย้งให้เพิกเฉยต่อที่อยู่ แต่เป็นข้อโต้แย้งให้จดจำว่าสัญญาณวัดอะไร เพราะพฤติกรรมที่น่าประหลาดใจส่วนใหญ่รอบการเข้าสู่ระบบผ่าน VPN เกิดจากการใช้การควบคุมในระดับที่ไม่เหมาะสม ไม่ใช่จากการสังเกตที่ผิด
ทำไมการบล็อกทางออกจึงลงโทษคนแปลกหน้า
การบล็อกในระดับที่อยู่ถูกนำไปใช้ได้ถูกและเล็งเป้าได้แพง รัศมีผลกระทบคือทุกเซสชันที่อยู่เบื้องหลังที่อยู่นั้น และนี่คือเหตุผลที่ที่อยู่ที่ใช้ร่วมกันและพฤติกรรมของ NAT มีประวัติของตัวเองในเอกสารปฏิบัติการ: เหตุผลเดียวกันปรากฏในงานของ IETF เกี่ยวกับที่อยู่ต้นทางที่ใช้ร่วมกันและผลข้างเคียงของการกรองตามที่อยู่
| Signal | What it provides evidence about | What it cannot settle |
|---|---|---|
| Source address and its reputation | The network path, and how that path behaved recently for others | Which account or person is behind the request |
| Authenticator result | Whether the account claim was proved at the required strength | Whether the account's owner initiated it |
| Request timing and volume | Whether the pattern looks automated or burst-like | Whether the intent was malicious or a shared client |
| Application event history | What this account has done while signed in | Anything about requests that never authenticated |
พิจารณาความล้มเหลวสองอย่างที่การบล็อกสร้างขึ้น ลูกค้าที่ชอบด้วยกฎหมายที่อยู่เบื้องหลังทางออกเดียวกันถูกปฏิเสธบริการและเปิดตั๋วสนับสนุนที่มีค่าใช้จ่ายสูงกว่าการละเมิดเอง ผู้โจมตีจริงย้ายไปยังทางออกถัดไปในกลุ่มที่มีหลายพันแห่งและดำเนินต่อไป โดยไม่ได้ใช้จ่ายใด ๆ นอกจากการเชื่อมต่อใหม่
ความได้สัดส่วนคือขั้นตอนที่ขาดไป การเข้าสู่ระบบล้มเหลวซ้ำ ๆ การเพิ่มขึ้นของคำขออัตโนมัติ และการละเมิดสิทธิ์ที่ผ่านการรับรองแล้วเป็นสามเหตุการณ์ที่แตกต่างกัน และมีเพียงอย่างที่สองเท่านั้นที่ดูเหมือนปัญหาในรูปร่างของที่อยู่ การใช้การแบนเครือข่ายทั่วทั้งไซต์เดียวกันกับทั้งสาม คือวิธีที่การควบคุมความปลอดภัยกลายเป็นคิวสนับสนุน
วางการตัดสินใจไว้ที่หลักฐาน
การควบคุมระดับบัญชีติดตามบัญชีข้ามที่อยู่ ซึ่งตรงกับสิ่งที่คุณใส่ใจจริง ๆ การจำกัดอัตรา ช่วงเวลารอหลังความล้มเหลวซ้ำ ๆ และการยืนยันตัวตนแบบขั้นบันไดสำหรับการกระทำที่ละเอียดอ่อนล้วนทำงานกับบัญชีหรือการกระทำ ไม่ใช่เส้นทางเครือข่าย สิ่งนี้เข้ากับสิ่งที่คุณปกป้องจริง ๆ ได้ดีกว่า และยังขจัดแรงจูงใจของผู้โจมตีในการหาที่อยู่ทางออกใหม่
แนวทางปฏิบัติของ NIST เกี่ยวกับการยืนยันตัวตน ถือว่าสิ่งเหล่านี้เป็นอินพุตของการประเมินความเสี่ยงและระบุที่อยู่ ตำแหน่งทางภูมิศาสตร์ และเวลาของคำขอไว้ในสัญญาณ ซึ่งเป็นกรอบที่ควรยืมมาใช้: สัญญาณให้ข้อมูลแก่การตัดสินใจ แต่ไม่แทนที่ตัวยืนยันตัวตน อ่านรายการนั้นเป็นอินพุต ไม่ใช่เมนูของสิ่งที่ต้องห้าม การพิสูจน์ยังคงเป็นหน้าที่ของตัวยืนยันตัวตน และสัญญาณอื่น ๆ เพียงตัดสินว่าจะวางแรงเสียดทานรอบ ๆ มากน้อยเพียงใด
ข้อจำกัดการออกแบบสองข้อป้องกันไม่ให้แนวทางระดับบัญชีกลายเป็นความขัดข้องของตัวเอง การจำกัดอัตราต้องมีเส้นทางการทบทวนที่ปลอดภัยเพื่อให้ผู้ใช้รายงานการจัดประเภทผิดได้โดยไม่ต้องเผยแพร่ข้อมูลรับรอง และการท้าทายแบบขั้นบันไดต้องไม่สามารถตอบได้ด้วยรหัสผ่านหรือรหัสใช้ครั้งเดียวที่มอบให้กับผู้ติดต่อฝ่ายสนับสนุนที่ยังไม่ได้ยืนยัน
นโยบายที่เป็นธรรมมีหน้าตาอย่างไรเมื่อมองจากภายนอก
เขียนว่าการควบคุมแต่ละอย่างสนับสนุนการตัดสินใจใด แล้วตรวจสอบว่าความละเอียดของการควบคุมตรงกันหรือไม่ การควบคุมที่อยู่ตอบคำถามเกี่ยวกับการรับส่งข้อมูลจากเครือข่าย การควบคุมบัญชีตอบคำถามเกี่ยวกับบัญชี เหตุการณ์ของแอปพลิเคชันตอบคำถามเกี่ยวกับพฤติกรรมหลังการยืนยันตัวตน นโยบายที่ระบุทั้งสามอย่างสามารถตรวจสอบได้ และนโยบายที่ระบุเพียงการรับส่งข้อมูล VPN ไม่สามารถ
จากนั้นวัดผลลัพธ์ไม่ใช่จำนวนกฎ ความพยายามที่ไม่ได้รับอนุญาตควรลดลง ผู้ใช้ที่ชอบด้วยกฎหมายควรมีเส้นทางที่ได้รับการสนับสนุน และจำนวนการติดต่อฝ่ายสนับสนุนต่อการเข้าสู่ระบบหนึ่งพันครั้งไม่ควรเพิ่มขึ้น การบล็อกที่ปรับปรุงตัวเลขแรกแต่ทำลายอีกสองตัวได้ย้ายปัญหา ไม่ได้แก้ไข
การยอมรับการเชื่อมต่อ VPN และการบังคับใช้การควบคุมการละเมิดเป็นเป้าหมายที่เข้ากันได้ เวอร์ชันที่ได้ผลถือว่าที่อยู่ต้นทางเป็นหนึ่งในหลายอินพุต ใช้การควบคุมที่แคบที่สุดที่เหมาะกับหลักฐาน และเหลือเส้นทางที่ซื่อสัตย์ให้กับผู้ที่ถูกจัดประเภทผิด เวอร์ชันที่ล้มเหลวถือว่าที่อยู่เป็นผู้ต้องสงสัยและเรียกสิ่งนั้นว่านโยบาย