Chia sẻ tài khoản SaaS trong nhóm: bốn rủi ro và phương án tuân thủ

Thêm một chỗ ngồi người dùng cho công cụ SaaS có thể là khoản chi không nhỏ. Khi số lượng thành viên tăng lên, khoản chi này càng trở nên rõ ràng.

Vì vậy, dùng chung một bộ thông tin đăng nhập có thể trông rất tự nhiên, nhất là khi ai đó chỉ thỉnh thoảng cần xem báo cáo hoặc tạm thời kiểm tra dữ liệu cho khách hàng. Tuy nhiên, cái giá của cách làm này thường bị đánh giá thấp và nằm rải rác ở nhiều khía cạnh: điều khoản sử dụng, thông tin đăng nhập, nhật ký hoạt động và thay đổi nhân sự. Mỗi khía cạnh đều có vấn đề riêng.

Điều khoản rất rõ: tài khoản không được dùng chung

Phần lớn sản phẩm SaaS áp dụng mô hình cấp phép theo chỗ ngồi. Ngoài các gói doanh nghiệp hoặc gói nhóm hỗ trợ rõ ràng nhiều người dùng, các gói còn lại thường giới hạn cho một người. Điều khoản dịch vụ thường cấm nhiều người dùng chung một thông tin đăng nhập, và nền tảng có thể tạm ngưng hoặc thu hồi quyền truy cập khi phát hiện. Có một điểm dễ bị bỏ qua: hình thức chấm dứt này thường không hoàn tiền, nên khoản đã thanh toán có thể bị mất.

Ngoài ra còn có một chi phí ít thấy hơn. Mục đích của việc dùng chung là tiết kiệm, nhưng cách nền tảng tính phí theo số người cần truy cập không thay đổi. Phần tiết kiệm thực chất là đổi chi phí cấp phép lấy rủi ro vi phạm, và rủi ro đó chỉ khó nhìn thấy khi chưa xảy ra sự cố.

Khi nhiều người biết mật khẩu, rất khó xác định ai đã thao tác

Dùng chung đồng nghĩa với việc mật khẩu phải được truyền giữa nhiều người, thường qua ứng dụng trò chuyện, ghi chú hoặc những nơi mà một tin nhắn có thể trở thành bản ghi tồn tại lâu dài.

Vấn đề không chỉ nằm ở bản thân mật khẩu mà còn ở hai hệ quả. Thứ nhất, bề mặt lộ lọt tăng lên: càng nhiều người tham gia, khả năng một người tái sử dụng cùng mật khẩu ở nơi khác hoặc một thiết bị bị xâm nhập càng cao, từ đó tạo lối vào tài khoản. Thứ hai, việc quy trách nhiệm trở nên khó khăn. Nếu tài khoản được dùng để xuất dữ liệu, thay đổi cấu hình hoặc gửi nội dung không nên gửi, sau đó chỉ có thể thấy tài khoản đã làm gì chứ không thể biết chắc ai thực hiện. Với các nhóm phải giải thích luồng dữ liệu cho khách hàng, đây thường là một trong những vấn đề phiền phức nhất.

Nhật ký hoạt động ghi tài khoản, không ghi con người

Hệ thống quản trị SaaS thường lưu hoạt động theo tài khoản: ai đã xuất báo cáo, thay đổi cài đặt nào và xóa dữ liệu gì. Trong nhật ký, nhiều khi chỉ còn lại một tên tài khoản.

Khi nhiều người cùng dùng tài khoản đó, khả năng truy vết này bị mất. Nội bộ nhóm không thể xác định ai đã thay đổi, còn cơ chế phát hiện bất thường của nền tảng cũng gặp cùng vấn đề. Hệ thống có thể thấy một tài khoản đăng nhập từ nhiều thành phố, nhiều thiết bị và nhiều điểm ra mạng, với các phiên đồng thời, rồi đánh dấu hoạt động. Cách xử lý thường gặp là buộc đăng xuất, khóa tạm thời hoặc yêu cầu xác minh lại. Nếu công cụ là một phần thiết yếu của công việc hằng ngày, việc bị chặn trong giờ làm có thể gây thiệt hại lớn hơn nhiều so với vài chỗ ngồi bổ sung.

Đổi proxy hoặc đồng nhất dấu vân tay trình duyệt chỉ có thể giảm khả năng bị phát hiện; chúng không biến việc dùng chung thông tin đăng nhập thành hành vi tuân thủ. Hơn nữa, nếu mọi lần đăng nhập đều gắn với cùng một môi trường, khi môi trường đó gặp vấn đề — chẳng hạn IP bị đánh dấu hoặc môi trường bị đánh giá là bất thường — quyền truy cập của tất cả mọi người có thể bị gián đoạn cùng lúc, khiến phạm vi sự cố rộng hơn.

Người đã rời đi nhưng quyền truy cập vẫn còn

Khi nhân viên nghỉ việc hoặc hợp tác thuê ngoài kết thúc, việc thu hồi quyền trên tài khoản dùng chung thường không có người chịu trách nhiệm rõ ràng. Lý do rất đơn giản: tài khoản là của mọi người nên không có một bước bàn giao với chủ sở hữu cụ thể.

Một số rủi ro vẫn còn. Người đã rời nhóm có thể vẫn biết mật khẩu, và không ai biết còn ai khác đã lưu nó. Cookie phiên được cấp trước đó có thể vẫn còn hiệu lực. Nếu người đó từng cấu hình script tự động hóa hoặc lệnh gọi API bằng tài khoản này, các đường truy cập ấy cũng không tự động mất hiệu lực. Đến khi phát hiện vấn đề, dữ liệu có thể đã bị thay đổi.

Ngoài ra, mỗi khi thành viên thay đổi, về lý thuyết cả nhóm đều phải đổi mật khẩu. Trong mô hình dùng chung, việc thay đổi triệt để thường rất khó thực hiện.

Phương án tuân thủ không hề phức tạp

Nếu tách riêng từng lý do khiến nhóm muốn chia sẻ, các phương án phù hợp khá rõ ràng.

• Với thành viên cố định cần sử dụng lâu dài: mua thêm chỗ ngồi. Đây là cách duy nhất được hỗ trợ chính thức cho nhiều người dùng và giúp nhật ký trở lại trạng thái có thể truy vết theo từng cá nhân.
• Với nhóm đông người: kiểm tra xem nền tảng có gói nhóm hoặc gói doanh nghiệp hỗ trợ nhiều người dùng hay không. Những gói này thường có mô hình quyền để giới hạn theo vai trò ai được xem hoặc thay đổi nội dung nào.
• Khi cần quản lý tập trung: sử dụng SSO. Khi một thành viên rời đi, quyền truy cập có thể được vô hiệu hóa tập trung mà không phụ thuộc vào việc ai đó nhớ thu hồi.
• Nếu chỉ cần tạm thời cho khách hàng xem kết quả: xuất báo cáo hoặc tạo liên kết chia sẻ chỉ đọc để khách hàng kiểm tra dữ liệu mà không phải đăng nhập vào tài khoản.

Cần phân biệt dùng chung tài khoản với sử dụng nhiều tài khoản. Dùng chung là nhiều người sử dụng một bộ thông tin đăng nhập. Còn nhiều tài khoản là mỗi người có thông tin đăng nhập riêng nhưng cần dùng trên cùng một thiết bị mà không gây ảnh hưởng lẫn nhau; mô hình thứ hai tự thân có thể hoàn toàn phù hợp. Ví dụ, nếu nhóm mua chỗ ngồi riêng cho từng thành viên và mỗi người có tài khoản của mình, cookie và phiên trong cùng một trình duyệt có thể ghi đè lẫn nhau. Cấp cho mỗi tài khoản một môi trường trình duyệt độc lập sẽ tách phiên, bộ nhớ đệm và dữ liệu. PurpleMark cung cấp chính loại khả năng cô lập môi trường này. Nó giải quyết vấn đề nhiều tài khoản hợp lệ cùng tồn tại ổn định trên một thiết bị; việc nhiều người dùng chung một bộ thông tin đăng nhập vẫn vi phạm điều khoản dịch vụ và điều đó không thay đổi vì có công cụ hỗ trợ.

Hãy tính chi phí trước khi chọn

Về bản chất, chia sẻ tài khoản là đổi rủi ro tuân thủ lấy một khoản tiết kiệm nhỏ về phí chỗ ngồi. Việc sử dụng thỉnh thoảng, tạm thời và chỉ bởi một người có thể trông như không có vấn đề trong một thời gian, nhưng ở quy mô nhóm, nếu quyền truy cập bị thu hồi hoặc xảy ra sự cố dữ liệu, chi phí có thể vượt xa số tiền đã tiết kiệm.

Hãy tính rõ chi phí cấp phép trước, rồi chọn phương án phù hợp. Nếu có thể mua chỗ ngồi, hãy mua; nếu có thể xuất dữ liệu, hãy xuất.

Quy tắc cấp phép cụ thể phải theo điều khoản chính thức của từng sản phẩm.