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

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

ส่วนที่ 1: การกำหนด password policy

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

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

มีหลายวิธีที่สามารถใช้ในการขโมย password ได้ ตัวอย่างเช่น

เดา password จากคำที่ตั้งง่ายๆ เช่น ชื่อเล่น เบอร์โทรศัพท์ หรือใช้คำทั่วๆ ไป
เดา password โดยใช้วิธี brute force (สุ่มเดาไปเรื่อยๆ จนกว่าจะถูก)
แอบมองจากด้านหลังตอนที่มีการกรอก password
สำรวจบริเวณโต๊ะว่ามีการจด password ลงในกระดาษหรือไม่
ใช้วิธี social engineering ในการหลอกถาม password (เช่น หลอกเข้าเว็บ phishing เพื่อให้กรอก password จริงในเว็บไซต์ปลอม)
ใช้ password ที่หลุดจากบริการหนึ่ง ล็อกอินเข้าใช้งานในอีกบริการหนึ่ง (ในกรณีที่ผู้ใช้ตั้ง password เหมือนกันในทุกบริการ)
ดัก password (หรือ password hash) ที่มีการรับส่งข้อมูลผ่านเครือข่าย
ติดตั้งมัลแวร์ลงในเครื่อง เพื่อดักการพิมพ์คีย์บอร์ด หรือขโมยรายการ password ที่ถูกบันทึกไว้ในเครื่อง

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

Tip 1: Reduce your organisation’s reliance on passwords

ลดความจำเป็นในการใช้งาน password โดยอาจใช้ระบบ single sign-on (SSO) เข้ามาช่วย เพื่อให้ผู้ใช้สามารถล็อกอินได้แบบอัตโนมัติไม่ต้องกรอก password ใหม่ทุกครั้งที่ใช้บริการ รวมถึงอาจพิจารณาช่องทางอื่นเพิ่มเติม อย่างเช่น hardware token หรือ biometric

ทั้งนี้ การใช้งาน SSO มีความเสี่ยงคือหากผู้โจมตีได้ password ที่ถูกต้องไป ก็สามารถเข้าใช้งานบริการอื่นๆ ที่ผูกกับบัญชีดังกล่าวได้ เพราะฉะนั้นหากมีการใช้งาน SSO ก็ควรเปิดใช้งาน multi-factor authentication (MFA) ควบคู่ไปด้วย เพื่อลดความเสี่ยงจากกรณี password รั่วไหล

Tip 2: Implement technical solutions

อาศัย technical defense เพื่อลดความเสี่ยง ดีกว่าพยายามบังคับหรือคาดหวังให้ผู้ใช้ปรับเปลี่ยนพฤติกรรม ซึ่งโดยธรรมชาติของมนุษย์อาจจะลืม ทำผิดขั้นตอน หรืออาจจะต่อต้านข้อกำหนดที่ไม่ practical ตัวอย่างเทคนิคที่สามารถพิจารณาใช้งานได้ เช่น การตั้งค่า throttling ที่หากใส่ password ผิดพลาดจะมีการหน่วงเวลาไว้ระยะหนึ่งก่อนจะสามารถใช้ password ได้อีกครั้ง หรือการตั้งค่า account lockout ที่จะล็อคบัญชีไว้หากใส่ password ผิดจนครบจำนวนครั้งที่กำหนด ซึ่งทั้ง 2 เทคนิคนี้เป็นการลดโอกาสที่บัญชีจะถูก brute force สำเร็จ อย่างไรก็ตาม ผู้โจมตีสามารถใช้เทคนิค account lockout ในการโจมตีแบบ denial of service ด้วยการพยายามล็อกอินด้วย password ผิดๆ ให้กับบัญชีจำนวนมาก เพื่อให้บัญชีเหล่านั้นไม่สามารถเข้าใช้งานได้

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

เทคนิคสุดท้ายคือการทำ password deny list ซึ่งเป็นการกำหนดไม่ให้ตั้ง password ตามเงื่อนไขที่กำหนด เช่น เป็น password ที่คาดเดาง่าย ใช้คำที่อยู่ใน common wordlist หรือตรงกับฐานข้อมูล password ที่เคยหลุดรั่วออกมาแล้ว

Tip 3: Protect all passwords

ข้อนี้ทีม developer, infrastructure, และ security ต้องทำงานร่วมกัน เพราะจำเป็นต้องมีการออกแบบระบบหรือคอนฟิกเพิ่มเติมหากมีบางระบบที่ยังไม่ได้เป็นไปตามมาตรฐาน โดยหลักๆ จะเน้นไปที่การป้องกัน password ทั้งที่อยู่ในรูปแบบ in transit, at rest, และ access control

Password in transit คือ password ที่มีการรับส่งผ่านเครือข่าย ซึ่งหากเป็นการรับส่งผ่านโพรโทคอลที่ไม่มีความมั่นคงปลอดภัยเพียงพอ หรือไม่ได้มีการเข้ารหัสลับข้อมูล ก็อาจถูก intercept ได้ ทุกบริการขององค์กรควรอนุญาตให้ใช้งานได้เฉพาะโพรโทคอลที่มีการเข้ารหัสลับข้อมูล รวมถึงควรมีการป้องกันและเฝ้าระวังการโจมตีในลักษณะ pass-the-hash เพิ่มเติมด้วย

Password at rest คือ password ที่ถูกเก็บอยู่ในระบบ ซึ่งขั้นต่ำควรเก็บในลักษณะ hash + salt โดยใช้ฟังก์ชัน hash ที่มีความมั่นคงปลอดภัยเพียงพอ เช่น SHA-256 ทั้งนี้ การเก็บ password ในลักษณะนี้เป็นเพียงการซื้อเวลาเพื่อให้ผู้ที่ได้ database ไป ยังต้องใช้เวลาในการคำนวณเพื่อหา password จริง แต่ก็ยังจำเป็นต้องมีการทำ hardening และ monitor การโจมตี database server รวมถึงมีมาตรการในการแจ้งเตือนผู้ใช้เพื่อให้เปลี่ยน password ทันทีที่พบว่า database ถูกเข้าถึงโดยไม่ได้รับอนุญาต

ในส่วนข้อแนะนำอื่นๆ เช่น ห้ามใช้ default password แยกกลุ่ม privilege account สำหรับงาน system, service, และ data ไม่ควรใช้ privilege account ในการทำงานอย่างอื่นนอกเหนือจากกิจกรรมของผู้ดูแลระบบ ทำ hardening และ monitor การโจมตีระบบ access management ก็น่าจะเป็นแนวทางพื้นฐานตามข้อกำหนดและมาตรฐานทั่วไป

Tip 4: Help users cope with password overload

แนวปฏิบัติในการบริหารจัดการ password แบบที่เคยยึดถือกันมาในยุคก่อนๆ นั้นหลายอย่างไม่ practical เมื่อมีปริมาณ password จำนวนมากที่ต้องจัดการหรือดูแลรักษา (เหตุการณ์นี้เรียกว่า password overload) ซึ่งปัญหานี้สามารถเกิดขึ้นได้ทั้งกับผู้ใช้งานทั่วไปและผู้ดูแลระบบ การมี policy ที่ไม่สามารถทำตามได้จริง ส่งผลให้มีการพยายามหาช่องทาง wordaround เพื่อให้สามารถปฏิบัติตาม policy ได้ แต่แลกกับความมั่นคงปลอดภัยที่ลดลง (เช่น การจด password แล้วแปะไว้ใกล้ๆ หน้าจอ, การตั้ง password ใหม่ให้คล้ายกับของเดิมแต่เปลี่ยนแค่บางตัวอักษร หรือการพยายามใช้ keyboard combination เช่น ตั้ง password เป็นภาษาไทยแต่พิมพ์ด้วยแป้นภาษาอังกฤษ) แนวทางการกำหนด policy ที่ดีควรมีความเหมาะสมในเรื่องสัดส่วนระหว่างความมั่นคงปลอดภัยและความสะดวกในการใช้งานจริง

ตัวอย่างแนวทางที่ควรจะเป็น คือการอนุญาตให้ผู้ใช้สามารถใช้งาน password manager ได้ เนื่องจากเป็นเครื่องมือที่ช่วยสร้าง password ที่มีความแข็งแรงเพียงพอ และมีระบบ auto fill เพื่อช่วยกรอก password ให้โดยผู้ใช้ไม่ต้องทำเอง รวมถึงควรออกแบบเว็บไซต์และแอปพลิเคชันให้รองรับการกรอกข้อมูลโดยใช้ password manager ด้วย (แนวทางการพิจารณาเลือกใช้งาน password manager จะกล่าวถึงในส่วนที่ 2 ของบทความนี้) แต่หากมีข้อจำกัดที่ทำให้ไม่สามารถใช้งาน password manager ได้ การใช้ physical storage เช่น ลิ้นชักที่มีระบบการป้องกันอย่างแน่นหนา ก็เป็นแนวทางที่สามารถยอมรับได้

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

ในกรณีบัญชีที่จำเป็นต้องใช้งานร่วมกันหลายคน นอกจากจะเพิ่มความเสี่ยงเรื่อง password รั่วไหล ยังทำให้การ monitor หรือการ audit นั้นทำได้ยากขึ้นด้วย เพราะแทบไม่สามารถยืนยันได้ว่าเป็นการใช้งานจริงหรือไม่ โดยใคร แนวทางการลดความเสี่ยงที่เหมาะสม ควรเป็นการใช้ระบบ delegate สิทธิ์ เช่น privileged access management (PAM) หรือจำกัดจำนวนคนที่รู้ password และเปลี่ยน password ทุกครั้งเมื่อมีคนออกหรือไม่มีสิทธิ์เข้าใช้งานบัญชีนั้นแล้ว

Tip 5: Help users to generate better passwords

เมื่อมีการสร้างบัญชีใหม่ ควรให้ระบบช่วยสร้าง random + unique password และให้ผู้ใช้เข้ามาเปลี่ยน password ในครั้งแรกที่ล็อกอินสำเร็จ โดยควรมีระบบที่ช่วยอำนวยความสะดวกเพื่อให้ผู้ใช้สามารถตั้ง password ได้อย่างมั่นคงปลอดภัยเพียงพอ เช่น ใช้ password deny list เพื่อป้องกันไม่ให้มีการตั้ง password ในลักษณะที่คาดเดาได้ง่าย หรือตรงกับฐานข้อมูล password ที่เคยหลุดออกมาแล้ว

ควรเน้นให้ผู้ใช้ตั้ง password ที่มีความยาว มากกว่าบังคับให้ตั้ง password ที่ซับซ้อน (ตัวพิมพ์เล็ก-ใหญ่ ตัวเลข อักขระพิเศษ) เพราะโดยธรรมชาติแล้วผู้ใช้มักจะใช้แนวทางการเปลี่ยนตัวอักษร (เช่น จาก o เป็น 0) หรือใช้ keyboard combination เพื่อให้ผ่าน policy แต่ไม่ได้ช่วยให้ password นั้นมีความแข็งแรงอย่างที่ควรจะเป็น นอกจากนี้ ควรทำความเข้าใจหลักการทำงานและข้อจำกัดของการใช้ password strength meter เป็นตัวชี้วัดความแข็งแรงของ password เนื่องจากอาจเป็นการสร้างความเข้าใจที่ผิดให้กับผู้ใช้ เพราะในบางกรณีอาจเป็นการชี้นำให้ใช้ password ที่ไม่ได้มีความแข็งแรงมากพอ แต่ระบบตีความว่าเป็นไปตามเงื่อนไข

Tip 6: Use training to support key messages

มี password guidance จำนวนมากที่ล้าสมัย หรือไม่สามารถอธิบายเหตุและผลของข้อแนะนำแหล่านั้นได้ หลักการสร้าง security awareness ที่ดีควรเน้นไปที่การสร้างความเข้าใจ ไม่ใช่แค่ถามตอบ yes/no หรือสอนให้ท่องจำโดยที่ไม่รู้ว่าเป็นการทำอะไรเพื่อลดความเสี่ยงในเรื่องอะไร หรืออ้างอิงข้อกำหนดจากมาตรฐานไหน เพราะอาจกลายเป็นการสอนให้ทำตามความเชื่อที่ไม่สามารถพิสูจน์ข้อเท็จจริงได้ หรือใช้แรงใช้เวลาไปกับการป้องกันปัญหาโดยใช้วิธีที่ไม่ได้ก่อให้เกิดผลลัพธ์อย่างที่ควรจะเป็น

แนวทางการสร้าง security awareness เรื่อง password โดยหลักๆ ควรเน้นเรื่องการไม่ตั้ง password ซ้ำกัน ไม่ตั้ง password ที่คาดเดาได้ง่าย รวมถึงแนะนำให้ใช้งาน password manager และการเปิด MFA

ส่วนที่ 2: การเลือกใช้งาน password manager ในองค์กร

Password manager มีหลายรูปแบบ มีทั้งข้อดีและข้อควรระวัง โดยข้อดีของ password manager นั้นหลักๆ จะเป็นการช่วยให้ผู้ใช้สามารถตั้ง password ในแต่ละบริการให้ไม่ซ้ำกัน มีความแข็งแรงเพียงพอ รวมถึงช่วยอำนวยความสะดวกให้ไม่ต้องกรอก password เวลาล็อกอิน อย่างไรก็ตาม การใช้งาน password manager ในองค์กรก็มีหลายประเด็นที่ควรพิจารณา เช่น ตัวโปรแกรมอาจมีช่องโหว่ เป็นเป้าหมายหลักในการโจมตีหากสามารถยึดบัญชีหรือเข้าถึงเครื่องของผู้ใช้ได้ (ถ้าผู้โจมตีได้ master password และ password vault ก็เท่ากับได้ password ของทุกบัญชี) รวมถึงยังมี learning curve ที่ค่อนข้างสูง อาจต้องใช้เวลาในการเรียนรู้และปรับตัว

หนึ่งในข้อแนะนำที่น่าจะเคยได้ยินกันมาอย่างยาวนาน คือการบอกว่าไม่ควรบันทึก password ไว้ใน browser ในขณะที่ผู้พัฒนา browser แทบทุกรายในปัจจุบัน ไม่ว่าจะเป็น Google, Apple, Microsoft, หรือ Mozilla ต่างก็พยายามพัฒนาฟีเจอร์ password manager ให้สามารถใช้งานได้จากตัว browser โดยตรง รวมถึงผลักดันให้มีการทำ cloud sync เพื่อให้สามารถใช้งานข้ามอุปกรณ์ได้ คำถามถัดมาคือข้อแนะนำว่าไม่ควรบันทึก password ไว้ใน browser นั้นยังสมเหตุสมผลมากน้อยแค่ไหน ควรใช้ password manager ของผู้พัฒนา browser หรือเปล่า

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

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

ทั้งนี้ ประเด็นสำคัญที่ควรพิจารณาคือ การที่ browser สามารถเป็น password manager ได้ ก็อาจไม่ได้ดีเพียงพอเมื่อเทียบกับการใช้งานโปรแกรม password manager โดยตรง และที่สำคัญคือทั้ง browser และ password manager นั้นล้วนเป็นเป้าหมายของมัลแวร์ประเภท info-stealer หรือ keylogger หากเครื่องติดมัลแวร์ ก็มีความเสี่ยงที่จะถูกขโมย password ทั้งหมดออกไปได้ เพราะฉะนั้นหากมีการบันทึก password ไว้ในเครื่อง (ไม่ว่าจะเป็นการใช้ browser หรือ password manager ก็ตาม) จำเป็นต้องมีมาตรการป้องกันมัลแวร์อย่างเคร่งครัด

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

Consideration 1: Credentials at rest

ข้อมูล credential ทั้งแบบที่เก็บในเครื่องและเก็บบน cloud ต้องถูก encrypt ด้วยวิธีการที่เหมาะสมและมีความมั่นคงปลอดภัยเพียงพอ ซึ่งผู้พัฒนาโปรแกรม password manager ควรมีรายละเอียดทางเทคนิคให้สามารถใช้ประเมินได้

Consideration 2: Access to credentials and account recovery

โดยหลักการแล้ว credential และข้อมูลอื่นๆ ที่ถูกเก็บอยู่ใน password manager ควรจะถูกป้องกันด้วย master password ซึ่งหากผู้ใช้ลืม master password ก็จะไม่สามารถเข้าถึงข้อมูลอะไรใน vault ได้เลย ผู้ให้บริการ password manager บางรายมีช่องทางในการช่วยให้ผู้ที่ลืม master password ยังสามารถเข้าถึงข้อมูลใน vault ได้ เช่น อาจจะใช้ recovery method บางอย่างเข้ามาช่วย อย่างไรก็ตาม การจะเปิดใช้งานฟีเจอร์นี้ จำเป็นต้องพิจารณาความเสี่ยงระหว่างการที่สามารถกู้คืนข้อมูลได้ กับการยอมให้สูญเสีย credential ทั้งหมด และหากอนุญาตให้ใช้งานฟีเจอร์นี้ได้ ใครจะเป็นผู้ที่มีสิทธิ์และรับผิดชอบในการ recover

Consideration 3: Multi-factor authentication

หากเป็นการใช้งาน password manager แบบที่สามารถเข้าถึงได้ผ่านระบบ cloud ต้องรองรับการเปิดใช้ MFA

Consideration 4: Data export

โปรแกรม password manager อาจมีฟีเจอร์ที่สามารถ export ข้อมูลทั้งหมดออกมาเป็น plain text ได้ เผื่อในกรณีที่ผู้ใช้ต้องการย้ายไปใช้โปรแกรมอื่น ทั้งนี้ ผู้ดูแลระบบควรพิจารณาว่าจะอนุญาตให้มีการ export ข้อมูลจาก password manager หรือไม่ หากอนุญาต จะมี policy หรือมาตรการใดในการป้องกันไม่ให้ผู้ใช้เผลอกด export ข้อมูลออกมาโดยไม่ตั้งใจ หรือไม่ให้ข้อมูลเหล่านั้นถูก export โดยผู้ไม่หวังดี

Consideration 5: Vulnerability disclosure and patching

โปรแกรม password manager ก็สามารถมีช่องโหว่ได้เหมือนกับโปรแกรมอื่นๆ ประเด็นสำคัญที่ควรพิจารณาคือหากมีการรายงานช่องโหว่ ทางผู้พัฒนามีการตอบสนองและแก้ไขปัญหาได้ภายในระยะเวลาที่เหมาะสมหรือไม่ หากระบบถูกโจมตี มีการแจ้งเตือนผู้ใช้หรืออัปเดตสถานการณ์ได้มากน้อยเพียงใด ทั้งนี้ ทางองค์กรจำเป็นต้องกำหนด policy ในการอัปเดตซอฟต์แวร์ที่มีความสำคัญ เช่น password manager, browser, หรือ operating system ให้สามารถทำได้เร็วที่สุดเมื่อมีการออกแพตช์ที่กระทบกับความมั่นคงปลอดภัย

Consideration 6: ‘Auto-fill’ browser extensions

ส่วนใหญ่โปรแกรม password manager ที่มีฟีเจอร์ auto-fill จะใช้วิธีติดตั้ง browser extension เพื่อช่วยในการกรอก password ให้แบบอัตโนมัติ (บางโปรแกรมอาจขอให้ผู้ใช้ปิดฟีเจอร์บันทึก password ของ browser เพื่อไม่ให้กระทบเวลามีการทำ auto-fill) ที่ผ่านมามีการพยายามโจมตีด้วยการหลอกให้ password manager กรอก password ในเว็บไซต์อื่นที่ไม่ใช่เว็บไซต์ที่ถูกบันทึก password ไว้ ซึ่งอาจจะต้องพิจารณาประเด็นในส่วนนี้ด้วย (ส่วนใหญ่แก้ปัญหานี้กันไปหมดแล้ว)

Consideration 7: Password generation

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

Consideration 8: Security auditing

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

Consideration 9: Platform support

พิจารณาว่าอนุญาตให้ผู้ใช้สามารถใช้งาน password manager ได้จากอุปกรณ์ใด ผ่านช่องทางใดได้บ้าง โดยปัจจุบันโปรแกรม password manager ส่วนใหญ่น่าจะรองรับ browser และ operating system ทั้งบน PC และ mobile อยู่แล้ว หากผู้ใช้มีความจำเป็นต้องล็อกอินบนอุปกรณ์อื่นที่โปรแกรม password manager ยังไม่รองรับ อาจมีการพยายามหา workaround ด้วยช่องทางอื่นที่ทำให้ความมั่นคงปลอดภัยลดลง

Consideration 10: Credentials in transit

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

Consideration 11: Password sharing between individuals

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

Consideration 12: Access for administrators

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

Consideration 13: Policies and auditing

ผู้ดูแลระบบสามารถดูภาพรวม และกำหนด policy ของการใช้งาน password manager ในองค์กรได้ เช่น การดูว่ามี password ของบัญชีใดบ้าง รูปแบบการใช้งาน MFA เพื่อเข้าถึง password manager รวมถึงข้อกำหนดและแนวทางการตั้ง master password

Consideration 14: Personal vaults

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

Consideration 15: Logs

โปรแกรม password manager สำหรับใช้งานในองค์กร ควรมี audit log เพื่อให้สามารถตรวจสอบการใช้งานได้ โดยอย่างน้อยควรครอบคลุมเรื่องการล็อกอินเข้าใช้งาน vault, รายการ password ที่ถูกเปิดดูหรือถูกใช้งาน, อุปกรณ์ที่ถูกใช้ในการเข้าถึง password vault, การขอ reset master password, และการใส่ master password ผิดพลาด ซึ่งอาจเป็นการพยายาม brute force

Consideration 16: Directory integration

หากมีการใช้งาน password manager ร่วมกับ Active Directory ควรตรวจสอบให้แน่ใจว่าผู้ใช้สามารถเข้าถึงได้เฉพาะ pasword vault ของตนเอง และการทำงานของโปรแกรม password manager ไม่กระทบกับฟังก์ชันอื่นๆ ของ Active Directory

สรุป

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

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