การใช้บัญชีสมัครสมาชิกเดียวร่วมกันอาจดูเหมือนช่วยประหยัดค่าที่นั่ง แต่ต้นทุนจริงมักสูงกว่า บทความนี้อธิบายปัญหา 4 ด้าน ได้แก่ การผิดเงื่อนไข การกระจายข้อมูลรับรอง ล็อกที่ระบุผู้กระทำไม่ได้ และสิทธิ์ที่ยังคงอยู่หลังสมาชิกออกจากทีม พร้อมทางเลือกที่เหมาะสมกว่า
การเพิ่มที่นั่งผู้ใช้อีกหนึ่งที่ให้กับเครื่องมือ SaaS อาจเป็นค่าใช้จ่ายที่ไม่น้อย เมื่อจำนวนคนในทีมเพิ่มขึ้น ค่าใช้จ่ายส่วนนี้ก็ยิ่งเห็นได้ชัด
ดังนั้น การใช้ข้อมูลเข้าสู่ระบบชุดเดียวร่วมกันจึงอาจดูเป็นเรื่องธรรมดา โดยเฉพาะเมื่อมีเพียงความต้องการดูรายงานเป็นครั้งคราวหรือช่วยตรวจข้อมูลให้ลูกค้าชั่วคราว แต่ต้นทุนที่แท้จริงของวิธีนี้มักถูกประเมินต่ำไป และกระจายอยู่ในหลายด้าน ได้แก่ เงื่อนไขการใช้บริการ ข้อมูลรับรอง ล็อกกิจกรรม และการเปลี่ยนแปลงสมาชิกในทีม ซึ่งแต่ละด้านมีปัญหาของตัวเอง
เงื่อนไขระบุชัด: ไม่ควรแชร์บัญชี
ผลิตภัณฑ์ SaaS ส่วนใหญ่คิดค่าบริการตามจำนวนที่นั่งผู้ใช้ นอกจากแผนสำหรับองค์กรหรือแผนทีมที่ระบุชัดว่ารองรับผู้ใช้หลายคนแล้ว แผนอื่นมักจำกัดไว้สำหรับผู้ใช้คนเดียว เงื่อนไขการใช้บริการโดยทั่วไปห้ามหลายคนใช้ข้อมูลเข้าสู่ระบบเดียวกันอย่างชัดเจน และแพลตฟอร์มอาจระงับหรือเพิกถอนการเข้าถึงเมื่อพบพฤติกรรมดังกล่าว จุดหนึ่งที่มักถูกมองข้ามคือ การยุติสิทธิ์ลักษณะนี้โดยปกติจะไม่คืนเงิน ทำให้เงินที่จ่ายไปแล้วอาจสูญไปทั้งหมด
ยังมีต้นทุนอีกแบบที่มองเห็นได้ยากกว่า เหตุผลของการแชร์คือการประหยัดเงิน แต่รูปแบบการคิดค่าบริการตามจำนวนผู้ที่ต้องการเข้าถึงของแพลตฟอร์มไม่ได้เปลี่ยนไป เงินที่ประหยัดได้จึงแทบเท่ากับการเปลี่ยนต้นทุนค่าลิขสิทธิ์ให้กลายเป็นความเสี่ยงด้านการปฏิบัติตามข้อกำหนด เพียงแต่ความเสี่ยงนี้ยังไม่เห็นชัดตราบใดที่บัญชียังไม่เกิดปัญหา
เมื่อหลายคนรู้รหัสผ่าน ก็ยากจะบอกว่าใครเป็นผู้ลงมือ
การแชร์หมายความว่ารหัสผ่านต้องถูกส่งต่อระหว่างหลายคน และมักผ่านแอปแชต โน้ต หรือพื้นที่อื่นที่ข้อความหนึ่งอาจกลายเป็นบันทึกถาวร
ปัญหาไม่ได้อยู่ที่รหัสผ่านเพียงอย่างเดียว แต่มีผลตามมาอีกสองเรื่อง เรื่องแรกคือพื้นที่เสี่ยงต่อการรั่วไหลกว้างขึ้น ยิ่งมีคนร่วมแชร์มากเท่าไร ก็ยิ่งมีโอกาสที่ใครสักคนจะนำรหัสผ่านเดียวกันไปใช้ซ้ำที่อื่น หรืออุปกรณ์ของใครบางคนถูกเจาะจนกลายเป็นช่องทางเข้าสู่บัญชี เรื่องที่สองคือการระบุความรับผิดชอบทำได้ยาก หากบัญชีถูกใช้เพื่อส่งออกข้อมูล เปลี่ยนการตั้งค่า หรือส่งเนื้อหาที่ไม่ควรส่ง ภายหลังจะเห็นได้เพียงว่าบัญชีนี้ทำอะไร แต่ไม่สามารถระบุได้ว่าใครเป็นผู้ดำเนินการจริง สำหรับทีมที่ต้องอธิบายเส้นทางของข้อมูลให้ลูกค้าทราบ เรื่องนี้มักเป็นหนึ่งในปัญหาที่ยุ่งยากที่สุด
ล็อกกิจกรรมบันทึกบัญชี ไม่ได้บันทึกตัวบุคคล
ระบบผู้ดูแลของ SaaS โดยทั่วไปจะเก็บกิจกรรมตามบัญชี เช่น ใครส่งออกรายงาน เปลี่ยนการตั้งค่าใด หรือลบข้อมูลอะไร โดยในล็อกมักเหลือเพียงชื่อบัญชีเดียว
เมื่อหลายคนใช้บัญชีเดียวกัน ความสามารถในการตรวจสอบย้อนหลังระดับบุคคลก็หายไป ทีมไม่สามารถรู้ได้ว่าใครเป็นผู้เปลี่ยนแปลง และระบบตรวจจับความผิดปกติของแพลตฟอร์มก็เจอปัญหาเดียวกัน ระบบอาจเห็นบัญชีเดียวเข้าสู่ระบบจากหลายเมือง หลายอุปกรณ์ และหลายทางออกของเครือข่าย พร้อมมีหลายเซสชันทำงานพร้อมกัน แล้วจึงทำเครื่องหมายว่าผิดปกติ การตอบสนองที่พบได้บ่อยคือบังคับออกจากระบบ ระงับชั่วคราว หรือขอให้ยืนยันตัวตนใหม่ หากเครื่องมือนี้จำเป็นต่อการทำงานประจำวัน การถูกปิดกั้นในเวลางานอาจสร้างความเสียหายมากกว่าค่าที่นั่งเพิ่มอีกไม่กี่ที่อย่างมาก
การเปลี่ยนพร็อกซีหรือทำให้ลายนิ้วมือเบราว์เซอร์เหมือนกันทำได้เพียงลดโอกาสถูกตรวจพบ ไม่ได้ทำให้การแชร์ข้อมูลรับรองโดยหลายคนกลายเป็นสิ่งที่สอดคล้องกับข้อกำหนด นอกจากนี้ หากการเข้าสู่ระบบทั้งหมดผูกกับสภาพแวดล้อมเดียว เมื่อสภาพแวดล้อมนั้นมีปัญหา เช่น IP ถูกทำเครื่องหมายหรือสภาพแวดล้อมถูกตัดสินว่าผิดปกติ การเข้าถึงของทุกคนอาจหยุดพร้อมกัน และทำให้ขอบเขตของความเสียหายกว้างขึ้น
คนออกจากทีมแล้ว แต่สิทธิ์ยังอยู่
เมื่อพนักงานลาออกหรือการทำงานกับผู้รับเหมาสิ้นสุดลง มักไม่มีผู้รับผิดชอบที่ชัดเจนในการเพิกถอนสิทธิ์ของบัญชีที่ใช้ร่วมกัน เหตุผลง่าย ๆ คือบัญชีนั้นเป็นของทุกคน จึงไม่มีขั้นตอนส่งมอบที่มีเจ้าของชัดเจน
มีความเสี่ยงหลายอย่างที่ยังหลงเหลืออยู่ สมาชิกที่ออกไปอาจยังรู้รหัสผ่าน และไม่มีใครทราบว่ามีใครบันทึกรหัสผ่านไว้อีก คุกกี้เซสชันที่ออกไว้ก่อนหน้านี้อาจยังไม่หมดอายุ หากบุคคลนั้นเคยตั้งค่าสคริปต์อัตโนมัติหรือการเรียก API ด้วยบัญชีนี้ ช่องทางการเข้าถึงเหล่านั้นก็จะไม่หายไปโดยอัตโนมัติ เมื่อสังเกตเห็นปัญหา ข้อมูลอาจถูกแก้ไขไปแล้ว
นอกจากนี้ ทุกครั้งที่มีการเปลี่ยนสมาชิกในทีม ตามหลักแล้วต้องเปลี่ยนรหัสผ่านให้ทุกคน แต่ในรูปแบบบัญชีร่วม การดำเนินการให้ครบถ้วนมักทำได้ยาก
ทางเลือกที่สอดคล้องกับข้อกำหนดไม่ได้ซับซ้อน
เมื่อแยกเหตุผลที่ต้องการแชร์บัญชีออกเป็นกรณี ๆ ทางเลือกที่เหมาะสมก็จะค่อนข้างชัดเจน
- สำหรับสมาชิกประจำที่ต้องใช้งานระยะยาว: ซื้อที่นั่งผู้ใช้เพิ่ม นี่คือวิธีใช้งานหลายคนที่ได้รับการรองรับอย่างเป็นทางการ และทำให้ล็อกกลับมาตรวจสอบย้อนหลังตามบุคคลได้
- สำหรับทีมที่มีคนจำนวนมาก: ตรวจสอบว่าแพลตฟอร์มมีแผนทีมแบบหลายผู้ใช้หรือแผนองค์กรหรือไม่ แผนประเภทนี้มักมีโมเดลสิทธิ์ที่จำกัดตามบทบาทว่าใครดูหรือแก้ไขอะไรได้บ้าง
- หากต้องการควบคุมจากศูนย์กลาง: ใช้ SSO เมื่อสมาชิกออกจากทีม สามารถปิดการเข้าถึงจากส่วนกลางได้โดยไม่ต้องพึ่งให้ใครจำว่าต้องถอนสิทธิ์
- หากต้องการให้ลูกค้าดูผลลัพธ์ชั่วคราว: ส่งออกรายงานหรือสร้างลิงก์แชร์แบบอ่านอย่างเดียว เพื่อให้ลูกค้าตรวจข้อมูลได้โดยไม่ต้องเข้าสู่ระบบบัญชี
สิ่งสำคัญคือต้องแยก “การแชร์บัญชี” ออกจาก “การใช้หลายบัญชี” กรณีแรกคือหลายคนใช้ข้อมูลรับรองชุดเดียวกัน ส่วนกรณีหลังคือแต่ละคนมีข้อมูลรับรองของตนเอง แต่ต้องใช้งานบนอุปกรณ์เดียวกันโดยไม่รบกวนกัน ซึ่งรูปแบบหลังสามารถสอดคล้องกับข้อกำหนดได้ในตัวเอง ตัวอย่างเช่น หากทีมซื้อที่นั่งให้สมาชิกทุกคนและแต่ละคนมีบัญชีของตนเอง คุกกี้และเซสชันในเบราว์เซอร์เดียวกันอาจเขียนทับกันได้ การแยกสภาพแวดล้อมเบราว์เซอร์สำหรับแต่ละบัญชีจะช่วยแยกเซสชัน แคช และข้อมูลออกจากกัน PurpleMark ให้ความสามารถด้านการแยกสภาพแวดล้อมลักษณะนี้ ช่วยให้บัญชีที่ถูกต้องหลายบัญชีใช้งานร่วมกันบนอุปกรณ์เดียวได้อย่างเสถียร แต่ไม่ได้เปลี่ยนข้อเท็จจริงที่ว่าการให้หลายคนใช้ข้อมูลเข้าสู่ระบบชุดเดียวกันยังคงขัดกับเงื่อนไขการใช้บริการ
คำนวณก่อนแล้วค่อยเลือก
โดยพื้นฐานแล้ว การแชร์บัญชีคือการแลกความเสี่ยงด้านการปฏิบัติตามข้อกำหนดกับการประหยัดค่าที่นั่งเพียงเล็กน้อย การใช้งานเป็นครั้งคราว ชั่วคราว และโดยคนคนเดียวอาจดูเหมือนไม่มีปัญหาอยู่ระยะหนึ่ง แต่เมื่อใช้ในระดับทีม หากถูกเพิกถอนการเข้าถึงหรือเกิดเหตุการณ์ด้านข้อมูล ความเสียหายอาจสูงกว่าส่วนที่ประหยัดได้มาก
คำนวณต้นทุนลิขสิทธิ์ให้ชัดเจนก่อน แล้วจึงเลือกวิธีที่เหมาะสม หากซื้อที่นั่งได้ก็ควรซื้อ หากส่งออกข้อมูลได้ก็ควรส่งออก
กฎการอนุญาตใช้งานที่แน่นอนให้ยึดตามเงื่อนไขอย่างเป็นทางการของแต่ละผลิตภัณฑ์
