จะปกป้องรหัสผ่านไปทำไม ในเมื่อเลิกใช้มันได้?

ปัญหาที่เราคุ้นชินจนคิดว่าเป็นเรื่องปกติ

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

เราคุ้นเคยกับรูปแบบนี้มากจนแทบไม่เคยถามตัวเองว่า ทุกอย่างจำเป็นต้องทำงานแบบนี้จริงหรือ?

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

แต่จะเกิดอะไรขึ้นเมื่อมีโครงการสิบ ยี่สิบ หรือสามสิบโครงการ?

ในกรณีของผม นี่คือระบบนิเวศ DigiMeld ซึ่งรวมโครงการซอฟต์แวร์อิสระมากกว่าสามสิบโครงการ แต่ละโครงการมีสถาปัตยกรรม ตรรกะฝั่งเซิร์ฟเวอร์ และอินเทอร์เฟซผู้ดูแลระบบเป็นของตัวเอง

ดังนั้น แต่ละโครงการจึงต้องมีกลไกสำหรับการเข้าถึงระดับผู้ดูแลระบบ

เป็นเวลานาน ผมใช้แนวทางที่คุ้นเคยกันดี นั่นคือข้อมูลบัญชีผู้ดูแลระบบแยกกัน รหัสผ่านที่ซับซ้อน และบันทึกรหัสผ่านเหล่านั้นไว้ในเบราว์เซอร์

มันใช้งานได้

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

แล้วเราจะเลิกต้องทำเช่นนั้นได้หรือไม่?

ผมเริ่มคิดว่าแนวคิดนี้อาจเป็นพื้นฐานของวิธีแก้ปัญหาที่ผมพัฒนาขึ้นในภายหลัง:

บางทีเราไม่ควรปกป้องช่องทางเข้าสู่ระบบที่มีอยู่ตลอดเวลา แต่ควรปกป้องสิทธิ์ในการขอเข้าถึงชั่วคราวแทน

รหัสผ่านที่ซับซ้อนไม่ได้ขจัดปัญหาที่แท้จริง

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

แต่ไม่ว่ารหัสผ่านจะซับซ้อนเพียงใด ก็ยังต้องเก็บไว้ที่ไหนสักแห่ง แล้วนำมาใช้ในภายหลัง

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

อย่างไรก็ตาม โครงสร้างพื้นฐานก็ยังคงเดิม กล่าวคือมีอินเทอร์เฟซบางอย่างที่ผู้ใช้ใช้ยืนยันข้อมูลบัญชีของตน

อินเทอร์เฟซนั้นสามารถถูกส่งคำขอเข้าไปได้ ถูกสแกนได้ และอาจตกเป็นเป้าหมายของการโจมตีแบบอัตโนมัติ

เราอาจซ่อนที่อยู่ของแผงควบคุมผู้ดูแลระบบ เปลี่ยนเส้นทางมาตรฐานเป็นชุดอักขระสุ่มที่ยาว หรือจำกัดการเข้าถึงตาม IP

แต่แล้วก็เกิดคำถามใหม่ว่า จะเก็บที่อยู่นี้ไว้ที่ไหน และจะใช้งานอย่างไร?

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

ผมเริ่มคิดได้ว่าแนวคิดนี้อาจเป็นพื้นฐานของวิธีแก้ปัญหาที่พัฒนาขึ้นในภายหลัง:

บางทีเราไม่ควรปกป้องช่องทางเข้าสู่ระบบที่มีอยู่ตลอดเวลา แต่ควรปกป้องสิทธิ์ในการขอเข้าถึงชั่วคราวแทน

ถ้าไม่มีหน้าเข้าสู่ระบบแบบเดิมเลยล่ะ?

ผมตัดสินใจเลิกใช้รูปแบบการยืนยันตัวตนสำหรับผู้ดูแลระบบแบบดั้งเดิมในโครงการของตัวเอง

ไม่ใช่แค่ซ่อนแบบฟอร์มล็อกอิน

ไม่ใช่แค่เปลี่ยนชื่อเส้นทาง

ไม่ใช่เปลี่ยนรหัสผ่านเป็นรหัสผ่านที่ซับซ้อนกว่าเดิม

แต่เป็นการขจัดความจำเป็นที่จะต้องมีช่องทางเข้าสู่ระบบด้วยรหัสผ่านอยู่ตลอดเวลา

แน่นอนว่าอินเทอร์เฟซผู้ดูแลระบบไม่ได้หายไปไหน เพราะยังจำเป็นสำหรับการจัดการแอปพลิเคชัน

สิ่งที่เปลี่ยนไปคือวิธีการขอเข้าถึงอินเทอร์เฟซเหล่านั้น

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

ผมใช้ระบบระบุตัวตนและจัดการการเข้าถึงของตัวเองที่ชื่อ MeldID แทน

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

การมีบัญชีผู้ใช้เพียงอย่างเดียวไม่ได้หมายความว่าผู้ใช้มีสิทธิ์เปิดแผงควบคุมผู้ดูแลระบบ

ต้องให้สิทธิ์ดังกล่าวแยกต่างหาก

สิทธิ์เข้าถึงที่ไม่มีอยู่เมื่อไม่กี่นาทีก่อน

นี่อาจเป็นส่วนที่น่าสนใจที่สุดของแนวคิดทั้งหมด

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

ผมตัดสินใจเปลี่ยนหลักการนี้

แทนที่จะใช้ข้อมูลบัญชีผู้ดูแลระบบแบบถาวร ระบบจะให้ความสามารถในการเริ่มขั้นตอนเข้าสู่ระบบเป็นการชั่วคราว

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

แต่แม้จะครอบครองลิงก์ชั่วคราวนี้ ก็ไม่ได้หมายความว่าจะได้รับสิทธิ์เข้าถึงโดยอัตโนมัติ

นี่คือประเด็นสำคัญ

สมมติว่ามีใครบางคนได้ลิงก์ไปไม่ว่าด้วยวิธีใด ในระบบทั่วไปที่อาศัยเพียงการเก็บที่อยู่ให้เป็นความลับ การรั่วไหลเช่นนี้อาจกลายเป็นปัญหาร้ายแรง

แต่ในรูปแบบของผม ลิงก์ทำได้เพียงเริ่มขั้นตอนการยืนยันเท่านั้น

หากต้องการดำเนินการต่อ ต้องได้รับอนุญาตแยกต่างหากผ่านอุปกรณ์มือถือที่เชื่อถือได้ซึ่งใช้ MeldID

หากไม่มีการยืนยันที่ถูกต้อง ระบบจะไม่สร้างเซสชันผู้ดูแลระบบ

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

การรู้ว่าต้องไปที่ไหน กับการมีสิทธิ์เข้าใช้งาน เป็นคนละเรื่องกันโดยสิ้นเชิง

โทรศัพท์กลายเป็นเครื่องมือจัดการสิทธิ์การเข้าถึง

ในรูปแบบนี้ อุปกรณ์มือถือมีบทบาทสำคัญกว่าการเป็นเพียงเครื่องสร้างรหัสใช้ครั้งเดียวมาก

อุปกรณ์นี้ใช้ยืนยันการดำเนินการที่เกี่ยวข้องกับสิทธิ์ผู้ดูแลระบบ

เมื่อผมต้องการเปิดแผงควบคุมผู้ดูแลระบบ ระบบจะขอให้ยืนยันผ่าน MeldID

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

ระบบจะอนุญาตให้ดำเนินขั้นตอนเข้าสู่ระบบต่อได้ก็ต่อเมื่อการตรวจสอบสำเร็จเท่านั้น

การยืนยันนี้ผูกกับการดำเนินการเฉพาะอย่าง ไม่ใช่แค่การปลดล็อกโทรศัพท์

ไบโอเมตริกบนมือถือใช้ตรวจสอบผู้ใช้ในอุปกรณ์ ส่วนฝั่งเซิร์ฟเวอร์จะตรวจสอบการยืนยันทางวิทยาการเข้ารหัสจากอุปกรณ์ที่ลงทะเบียนไว้

แนวทางนี้ช่วยให้ไม่ต้องพึ่งพาเพียงรหัสผ่านหรือข้อความที่อ้างว่าผู้ใช้ได้ยืนยันการเข้าสู่ระบบแล้ว

และยังมีข้อดีอีกอย่างหนึ่ง นั่นคือเราสามารถจัดการอุปกรณ์ที่เชื่อถือได้

หากไม่ควรใช้อุปกรณ์ใดเพื่อยืนยันสิทธิ์เข้าถึงอีกต่อไป ก็สามารถเพิกถอนสถานะความน่าเชื่อถือของอุปกรณ์นั้นได้

หลังจากนั้น อุปกรณ์ดังกล่าวก็จะไม่สามารถใช้ยืนยันการดำเนินการที่เกี่ยวข้องได้อีก

ระบบเดียว หลายโครงการที่เป็นอิสระต่อกัน

ตอนเริ่มพัฒนากลไกนี้ หนึ่งในโจทย์สำคัญคือการรักษาความเป็นอิสระของแต่ละโครงการ

ผมไม่ต้องการรวมแผงควบคุมผู้ดูแลระบบทั้งหมดเข้าเป็นแอปพลิเคชันขนาดใหญ่เพียงแอปเดียว

บริการแต่ละรายการใน DigiMeld ยังคงต้องจัดการตรรกะ การตั้งค่า ผู้ใช้ และข้อมูลของตัวเองต่อไป

ดังนั้น ผมจึงแยกหน้าที่ออกเป็นสองส่วน

MeldID รับผิดชอบการระบุตัวตนและการให้สิทธิ์เข้าถึงระดับผู้ดูแลระบบ

ส่วนแต่ละโครงการรับผิดชอบฟังก์ชันผู้ดูแลระบบของตัวเองและการตรวจสอบสิทธิ์ที่ยังมีผลอยู่

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

นอกจากนี้ ยังมีการกำหนดสิทธิ์แยกกันด้วย

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

เราสามารถกำหนดกลุ่มผู้ใช้ที่ได้รับอนุญาตสำหรับแต่ละส่วนงานผู้ดูแลระบบได้เอง

ขณะเดียวกัน สิทธิ์ของผู้ใช้ทั่วไปกับสิทธิ์ระดับผู้ดูแลระบบก็แยกจากกัน

แนวทางนี้สะดวกเป็นพิเศษสำหรับระบบนิเวศที่มีบริการหลายสิบรายการ

ทำไมผมจึงชอบสิทธิ์เข้าถึงชั่วคราวมากกว่าสิทธิ์ถาวร

ยังมีหลักการอีกข้อหนึ่งที่ผมตั้งใจออกแบบไว้ในระบบ

สิทธิ์เข้าถึงระดับผู้ดูแลระบบไม่ควรอยู่ตลอดไป

การอนุญาตมีอายุจำกัดและจะสิ้นสุดลง ไม่ว่าผู้ใช้จะยังทำงานอยู่ในเบราว์เซอร์หรือไม่

หากต้องการทำงานต่อหลังจากสิทธิ์หมดอายุ จะต้องยืนยันใหม่อีกครั้ง

วิธีนี้ช่วยป้องกันไม่ให้การยืนยันตัวตนที่ทำไปครั้งหนึ่งกลายเป็นสิทธิ์ที่ใช้ได้ตลอดเวลา

แต่การจำกัดเวลาเพียงอย่างเดียวยังไม่เพียงพอ

สิ่งสำคัญคือความสามารถในการยุติสิทธิ์ที่ให้ไปแล้วก่อนกำหนด

ด้วยเหตุนี้ MeldID จึงมีระบบเพิกถอนสิทธิ์ผู้ดูแลระบบจากส่วนกลาง

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

ดังนั้น การจัดการสิทธิ์เข้าถึงจึงไม่ได้สิ้นสุดลงทันทีที่ผู้ใช้เข้าสู่ระบบสำเร็จ

สำหรับผม ความสามารถในการเพิกถอนสิทธิ์มีความสำคัญไม่น้อยไปกว่าความสามารถในการให้สิทธิ์

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

แล้วการทำงานในแต่ละวันเปลี่ยนไปอย่างไร?

อย่างแรกคือไม่จำเป็นต้องเรียกดูรหัสผ่านผู้ดูแลระบบที่บันทึกไว้อยู่ตลอดเวลาอีกต่อไป

ผมไม่ต้องเก็บชุดข้อมูลบัญชีไว้ในเบราว์เซอร์เพื่อเข้าสู่แผงควบคุมผู้ดูแลระบบของแต่ละโครงการที่เชื่อมต่อ

แทนที่จะทำเช่นนั้น ผมจัดการสิทธิ์ผ่านกลไกเดียว

เลือกโครงการที่ต้องการ ยืนยันสิทธิ์เข้าถึง แล้วเริ่มทำงาน

เมื่อไม่จำเป็นต้องใช้สิทธิ์ผู้ดูแลระบบแล้ว ก็สามารถเพิกถอนสิทธิ์ได้

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

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

แน่นอนว่าไม่ได้หมายความว่าความเสี่ยงด้านความปลอดภัยทั้งหมดจะหายไป

สิทธิ์ชั่วคราว อุปกรณ์ที่เชื่อถือได้ เซสชันฝั่งเซิร์ฟเวอร์ และโครงสร้างพื้นฐานส่วนกลาง ต่างก็ต้องได้รับการปกป้องเช่นกัน

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

และนี่คือหนึ่งในเป้าหมายแรกเริ่มของผม

เทคโนโลยีแบบนี้มีอยู่แล้วไม่ใช่หรือ?

แน่นอนว่ามีอยู่แล้ว

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

แนวทางเหล่านี้พบได้ในระบบ Identity and Access Management, Privileged Access Management และแนวคิด Zero Trust

ผมไม่ได้อ้างว่าตัวเองเป็นผู้คิดค้นหลักการเหล่านี้

โจทย์ของผมแตกต่างออกไป

ผมต้องการสร้างระบบแบบบูรณาการของตัวเอง เพื่อแก้ปัญหาเฉพาะด้านโครงสร้างพื้นฐานของ DigiMeld และช่วยจัดการสิทธิ์ผู้ดูแลระบบให้กับโครงการอิสระหลายโครงการ

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

และผมเชื่อว่าคุณค่าของงานวิศวกรรมไม่ได้อยู่ที่การคิดค้นเทคโนโลยีใหม่ทั้งหมดเสมอไป

บางครั้งคุณค่าของมันอยู่ที่การระบุปัญหาให้ถูกต้องและหาวิธีแก้ที่เหมาะสม

MeldID ไม่ได้มีไว้สำหรับแผงควบคุมผู้ดูแลระบบเท่านั้น

ตรงนี้ควรชี้แจงเพิ่มเติมเป็นการเฉพาะ

MeldID ไม่ได้สร้างขึ้นมาเพื่อเป็นเครื่องมือสำหรับการเข้าถึงระดับผู้ดูแลระบบของผมเองเท่านั้น

นอกจากนี้ยังมี SDK สำหรับนักพัฒนา เพื่อผสานกลไกการระบุตัวตนและการยืนยันการเข้าสู่ระบบเข้ากับแอปพลิเคชันของตนเอง

และ SDK นี้เปิดให้ใช้งานฟรี

ตัวอย่างเช่น นักพัฒนาภายนอกสามารถใช้ MeldID เป็นชั้นการยืนยันเพิ่มเติมสำหรับการเข้าสู่ระบบของผู้ใช้

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

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

วิธีนี้ช่วยลดความเสี่ยงของการเข้าถึงโดยไม่ได้รับอนุญาต หากข้อมูลบัญชีถูกเจาะ

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

ทั้งสองใช้หลักการร่วมกันในเรื่องความน่าเชื่อถือและการยืนยันการดำเนินการ แต่มีเป้าหมายที่แตกต่างกัน

ความปลอดภัยไม่ได้มีแค่การปกป้องสิ่งที่มีอยู่

การพัฒนาระบบนี้ทำให้ผมมองกลไกการยืนยันตัวตนที่คุ้นเคยต่างออกไป

เรามักพยายามปกป้องสิ่งที่ยังคงอยู่เพียงเพราะเหตุผลทางประวัติศาสตร์

เราเพิ่มการตรวจสอบใหม่ ข้อจำกัด รหัสผ่านเพิ่มเติม และชั้นการป้องกัน

บางครั้งสิ่งเหล่านี้ก็จำเป็นจริง ๆ

แต่บางครั้งการถามคำถามอีกแบบอาจเป็นประโยชน์กว่า:

กลไกที่เราพยายามปกป้อง จำเป็นต้องคงอยู่ในรูปแบบเดิมจริงหรือ?

ในกรณีของผม คำตอบคือไม่

ผมไม่จำเป็นต้องมีแบบฟอร์มเข้าสู่ระบบผู้ดูแลระบบที่เปิดให้เข้าถึงได้ตลอดเวลา

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

สองอย่างนี้เป็นคนละโจทย์กัน

และการเปลี่ยนจากโจทย์แรกไปสู่โจทย์ที่สองไม่ได้เปลี่ยนแค่สถาปัตยกรรมทางเทคนิค แต่ยังเปลี่ยนวิธีทำงานกับโครงการในแต่ละวันด้วย

ไม่ใช่จุดสิ้นสุด แต่เป็นทิศทางที่เลือกไว้

ปัจจุบันสถาปัตยกรรมนี้ใช้งานแล้วในระบบนิเวศ DigiMeld ส่วนใหญ่

โครงการที่เหลือกำลังทยอยเปลี่ยนไปใช้รูปแบบการเข้าถึงระดับผู้ดูแลระบบใหม่นี้

ผมดำเนินการย้ายระบบทีละขั้น โดยตรวจสอบการทำงานของแต่ละแอปพลิเคชัน และเมื่อเปลี่ยนผ่านเสร็จแล้วก็วางแผนจะตรวจสอบระบบทั้งหมดเพิ่มเติม

องค์ประกอบบางส่วนของอินเทอร์เฟซและกฎการจัดการเซสชันอาจยังมีการเปลี่ยนแปลงได้

แต่แนวคิดหลักได้กำหนดไว้แล้ว

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

ขณะเดียวกัน ผมก็ไม่ได้มองว่าการนำระบบของตัวเองไปใช้เป็นคำตอบที่ใช้ได้กับทุกคน

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

สิ่งที่สะดวกและเหมาะสมกับระบบนิเวศ DigiMeld อาจไม่ใช่ทางเลือกที่ดีที่สุดสำหรับนักพัฒนารายอื่น

อย่างไรก็ตาม หลักการให้สิทธิ์ชั่วคราวเป็นสิ่งที่ควรพิจารณา

ส่งท้าย

ผมตัดสินใจแบ่งปันประสบการณ์นี้ ไม่ใช่เพราะคิดว่าตัวเองเป็นผู้คิดค้นวิธีการยืนยันตัวตนแบบใหม่

และไม่ใช่เพราะต้องการนำเสนอระบบอีกระบบหนึ่งว่าเป็นระบบที่ปลอดภัยอย่างสมบูรณ์

ไม่มีสิ่งที่เรียกว่าความปลอดภัยอย่างสมบูรณ์

ผมแค่คิดว่าการตั้งคำถามในลักษณะนี้น่าสนใจ

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

แทนที่จะเก็บรหัสผ่านไว้มากมาย ก็ใช้สิทธิ์ชั่วคราว

แทนที่จะเชื่อถือโดยอัตโนมัติหลังจากยืนยันตัวตนครั้งแรก ก็ยืนยันการให้สิทธิ์เฉพาะอย่าง

แทนที่จะรอให้เซสชันหมดอายุ ก็เตรียมความสามารถในการเพิกถอนสิทธิ์เข้าถึงจากส่วนกลาง

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

ผมไม่ได้อ้างว่าแนวทางนี้จะป้องกันการถูกเจาะระบบได้ทั้งหมด

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

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

สำหรับผม เรื่องราวของ MeldID Admin Gateway เริ่มต้นขึ้นจากแนวคิดนี้