Một công ty mới nên lập bảng tài khoản theo hệ thống, người chịu trách nhiệm và quyền được cấp ngay khi bắt đầu dùng email, website hay phần mềm làm việc. Bảng này không chứa mật khẩu. Mục tiêu là biết ai có thể làm gì, ai xử lý khi mất truy cập và cần thu hồi những quyền nào khi công việc thay đổi.
Bài viết dành cho nhóm nhỏ đang chuẩn bị hoặc vừa vận hành doanh nghiệp, gồm các nhóm tại TP.HCM. Đây là mẫu quản trị nội bộ đề xuất, không phải biểu mẫu pháp lý bắt buộc. Khác với việc đặt tên và lưu tệp trong hướng dẫn sắp xếp hồ sơ số, bài này tập trung vào vòng đời tài khoản đăng nhập: tạo, cấp quyền, khôi phục và thu hồi.
1. Kiểm kê hệ thống trước khi thêm người dùng
Đừng bắt đầu bằng danh sách nhân viên rồi cấp cho mỗi người tất cả ứng dụng. Hãy liệt kê từng hệ thống thực sự đang dùng: email theo tên miền, kho tài liệu, công cụ quản lý việc, website, nhà cung cấp tên miền và dịch vụ lưu trữ. Với mỗi hệ thống, ghi người quyết định cấp quyền và công việc cần thực hiện.
Tách ba khái niệm thường bị gộp thành “người giữ tài khoản”:
- Người phụ trách hệ thống: biết dịch vụ dùng để làm gì, ai phê duyệt thay đổi và cách liên hệ nhà cung cấp.
- Người có quyền quản trị: có thể tạo người dùng hoặc đổi cấu hình theo quyền nền tảng cho phép.
- Người sử dụng: chỉ cần chức năng phục vụ phần việc được giao.
Một người có thể kiêm nhiều vai trò trong nhóm nhỏ, nhưng nên ghi rõ từng vai trò. “Bạn thiết kế đang giữ” không đủ để biết công ty có tự quản lý tên miền hay khôi phục được tài khoản hay không.
2. Mẫu bảng phân quyền có thể bắt đầu ngay
Có thể tạo bảng với các cột sau. Chỉ người được giao quản lý mới nên xem toàn bộ vì danh sách hệ thống và người quản trị cũng là thông tin nội bộ.
| Cột | Ghi gì? |
|---|---|
| Hệ thống | Tên dịch vụ và địa chỉ đăng nhập chính thức |
| Người phụ trách | Người chịu trách nhiệm vận hành, không chỉ người tạo lúc đầu |
| Tài khoản được cấp | Định danh người dùng hoặc nhóm được phép truy cập |
| Công việc | Việc cụ thể cần làm, chẳng hạn đăng bài hoặc trả lời thư |
| Vai trò thực tế | Tên quyền đúng như nền tảng hiển thị |
| Phê duyệt và ngày cấp | Ai đồng ý, thời điểm nào |
| Khôi phục | Người phụ trách và nơi giữ hướng dẫn; không ghi mã bí mật |
| Rà soát hoặc kết thúc | Ngày xem lại quyền, hoặc mốc kết thúc hợp tác |
| Kiểm chứng | Người kiểm tra, ngày kiểm tra, kết quả thao tác thử |
Ví dụ minh họa cho nhóm ba người
Một người phụ trách vận hành quản lý danh sách hệ thống; một người làm nội dung chỉ cần quyền soạn và đăng bài trên website; một cộng tác viên chỉ cần làm trong dự án đã giao. Không vì cả ba cùng làm công ty mà cấp cho cả ba quyền thay đổi người quản trị email hoặc cấu hình tên miền.
Đây là tình huống giả định để minh họa cách điền bảng, không phải cơ cấu bắt buộc. Tên vai trò khác nhau giữa các dịch vụ; hãy đối chiếu khả năng thực tế thay vì suy ra quyền chỉ từ nhãn “thành viên” hay “biên tập viên”.
3. Cấp quyền theo việc, rồi kiểm tra bằng tài khoản nhận quyền
Trước mỗi lần cấp mới, ghi một câu ngắn: “Người này cần thực hiện việc gì?”. Chọn phạm vi vừa đủ cho việc đó. Nếu nền tảng có tài khoản riêng cho từng người, nên dùng để việc rà soát và thu hồi không phụ thuộc một mật khẩu chung.
Sau khi cấp, nhờ người nhận kiểm tra trên tài khoản của chính họ: đăng nhập được không, mở đúng khu vực không, thực hiện được thao tác đã giao không? Đồng thời kiểm tra họ có thấy chức năng quản trị ngoài dự kiến hay không. Dùng nội dung mẫu không nhạy cảm; không thử xóa dữ liệu thật để kiểm tra quyền.
Với cộng tác viên, ghi mốc kết thúc ngay khi bắt đầu. Nếu dịch vụ không tự hết hạn quyền, đưa việc thu hồi vào danh sách công việc của người phụ trách. Ngày trong bảng là lịch nội bộ do nhóm chọn, không phải một thời hạn pháp luật chung.
4. Chuẩn bị khôi phục trước khi có sự cố
Email có thể là đầu mối nhận thông báo và đặt lại mật khẩu của nhiều dịch vụ. Vì vậy, cần biết email khôi phục thuộc phạm vi quản lý nào và ai được phép sử dụng; tránh phụ thuộc hoàn toàn vào hộp thư cá nhân của một người ngoài nhóm.
CISA khuyến nghị bật xác thực đa yếu tố (MFA) và minh họa rủi ro khi email bị chiếm rồi kéo theo các tài khoản khác. MFA bổ sung lớp bảo vệ, không có nghĩa tài khoản được bảo đảm an toàn tuyệt đối.
Bảng theo dõi không phải nơi giữ bí mật
Không đưa mật khẩu, mã khôi phục MFA, mã xác thực dùng một lần hoặc ảnh chụp mã QR thiết lập vào bảng. Có thể ghi “hướng dẫn khôi phục do người phụ trách quản lý” và đường dẫn tới tài liệu được hạn chế quyền phù hợp. Bí mật cần được giữ trong công cụ hoặc nơi lưu bảo mật mà tổ chức đã chọn, với người được phép truy cập rõ ràng.
Nếu nền tảng cho phép thêm quản trị viên dự phòng, cân nhắc bố trí người có trách nhiệm và phạm vi phù hợp. Không giải quyết nguy cơ một người vắng mặt bằng cách chia sẻ tài khoản quản trị cho cả nhóm. Kiểm tra hướng dẫn khôi phục của đúng dịch vụ trước khi thay đổi phương thức đăng nhập đang dùng.
5. Khi đổi người phụ trách: thu hồi quyền, không xóa vội
Trước ngày bàn giao, xác định tài sản công việc do tài khoản đó quản lý và người tiếp nhận. Sau đó thực hiện các bước theo khả năng của từng nền tảng:
- Xác nhận người tiếp nhận đã có quyền cần thiết và kiểm tra được công việc.
- Rà lại tài khoản cá nhân, quyền thành viên nhóm, phiên đăng nhập và kết nối ứng dụng liên quan.
- Thu hồi hoặc đình chỉ truy cập theo quyết định của người có thẩm quyền.
- Kiểm tra lại tài nguyên chia sẻ và quyền của các cộng tác viên còn lại.
- Ghi kết quả và người kiểm tra vào bảng; xử lý việc giữ hay xóa dữ liệu thành quyết định riêng.
Ví dụ cụ thể, Google Workspace mô tả việc tạm đình chỉ người dùng là chặn quyền sử dụng dịch vụ của người đó nhưng không xóa email, tài liệu và dữ liệu. Những cộng tác viên đã được cấp quyền với tài liệu chia sẻ vẫn có thể giữ quyền của họ. Vì thế, đình chỉ một tài khoản không đồng nghĩa đã thu hồi mọi đường truy cập vào tài liệu của nhóm.
Ví dụ trên chỉ áp dụng theo tài liệu Google Workspace, không phải quy tắc chung cho mọi phần mềm. Đừng mặc định nút “xóa người dùng” sẽ tự chuyển hết tài sản cho công ty. Nếu chưa rõ dữ liệu sẽ đi đâu, đọc hướng dẫn và hỏi nhà cung cấp trước thao tác không thể đảo ngược.
6. Tiêu chí hoàn tất một lượt rà soát
Một dòng chỉ nên được đánh dấu đã kiểm tra khi xác định được người phụ trách, vai trò hiện tại và kết quả thử phù hợp. Những mục “không biết ai giữ” hoặc “chưa kiểm tra được” cần giữ nguyên trạng thái đó và giao người xử lý, không điền “đã xong” để đủ bảng.
Có thể rà soát khi thêm người, đổi nhiệm vụ, kết thúc hợp tác hoặc thay nhà cung cấp. Chọn thêm lịch định kỳ phù hợp với quy mô nhóm. Không cần mua công cụ phức tạp chỉ để lập bảng, nhưng bảng phải phản ánh cấu hình thực tế chứ không chỉ ý định ban đầu.
Câu hỏi thường gặp
Công ty chỉ có hai người có cần bảng này không?
Có thể dùng bản rút gọn: hệ thống, người phụ trách, người được cấp quyền, cách khôi phục và ngày kiểm tra. Giá trị nằm ở khả năng tiếp tục công việc khi một người vắng mặt, không ở số lượng cột.
Thu hồi tài khoản email đã đủ chưa?
Chưa thể kết luận. Cần kiểm tra từng dịch vụ có tài khoản riêng, phiên đăng nhập, kết nối ứng dụng và quyền tài nguyên liên quan. Phạm vi tác động của việc khóa email tùy cơ chế đăng nhập của hệ thống.
Đây có phải danh mục việc bắt buộc sau thành lập không?
Không. Đây là gợi ý quản trị tài khoản. Những việc về đăng ký, thuế hoặc nghĩa vụ khác cần tìm hiểu riêng theo nguồn chính thức và hoàn cảnh cụ thể. Nếu còn ở bước chuẩn bị, tham khảo checklist thông tin trước khi thành lập doanh nghiệp để tách phần thủ tục khỏi tổ chức công việc nội bộ.
Trao đổi về tên miền cho dự án thông tin doanh nghiệp
thanhlapdoanhnghiepsaigon.com đang được rao bán. Tên gọi có thể phù hợp với dự án nội dung về chuẩn bị và vận hành doanh nghiệp tại Sài Gòn, nếu người mua phát triển thông tin và dịch vụ đúng năng lực thực tế. Website này không tự nhận đang tiếp nhận hồ sơ hay cung cấp dịch vụ thành lập công ty.
Anh/chị quan tâm tên miền có thể liên hệ 0945 279 268 và xem checklist bàn giao tên miền dịch vụ doanh nghiệp. Đây là liên hệ mua bán tên miền, không phải nơi gửi mật khẩu, giấy tờ cá nhân hoặc yêu cầu xử lý thủ tục.
