Phân quyền hệ thống quản lý sản xuất – Vai trò, phê duyệt, nhật ký

Phân quyền trong hệ thống quản lý sản xuất là mảng thường được thiết lập theo kiểu “cứ cho tất cả mọi người toàn quyền đã” lúc go-live, rồi để nguyên như vậy suốt nhiều năm. Đến một ngày nó nổi lên cùng lúc dưới dạng phát hiện của kiểm toán, tài khoản của người đã nghỉ việc vẫn đăng nhập được, hoặc một người vừa nhập đơn hàng vừa tự phê duyệt. Bài viết này đi lần lượt qua thiết kế vai trò, thiết kế luồng phê duyệt và kiểm tra nhật ký thao tác, đặt trong bối cảnh nhà máy Nhật Bản đang vận hành tại Thái Lan.

Vì sao phân quyền hệ thống quản lý sản xuất đang được đặt lên bàn

Lối tắt lúc go-live không bao giờ được gỡ bỏ

Khi một hệ thống quản lý sản xuất hay MES bắt đầu chạy thật, ưu tiên cao nhất luôn là “sản xuất không được dừng”. Trong vài tuần cuối trước ngày cắt chuyển, ngày nào cũng có chuyện màn hình của ai đó không hiển thị dữ liệu cần thiết. Cách xử lý hàng đợi nhanh nhất là cấp quyền tương đương quản trị viên cho tất cả những người liên quan.

Xét như một quyết định của giai đoạn go-live thì điều đó không hẳn sai. Vấn đề là trạng thái “tạm thời” ấy trở thành vĩnh viễn. Khi vận hành đã ổn định, không còn ai nhắc đến chuyện phân quyền nữa, các vai trò mặc định do nhà cung cấp cài sẵn cứ để nguyên, và mỗi người mới vào đều được thiết lập “giống hệt người tiền nhiệm”. Ba năm sau, không còn ai trong công ty giải thích được vì sao từng người lại đang giữ những quyền mà họ giữ.

Tại các nhà máy Nhật Bản ở Thái Lan, cấu trúc này còn rõ nét hơn. Bộ phận công nghệ thông tin thường chỉ có một người, hoặc là người kiêm nhiệm cả hành chính hay kế toán, và thiết kế phân quyền đúng là loại công việc mà nếu dừng lại thì cũng chẳng ai thấy phiền. Thêm vào đó, nhân sự địa phương luân chuyển và đổi việc thường xuyên hơn ở Nhật, nên tài khoản thay đổi liên tục trong khi quy trình xử lý vẫn phụ thuộc vào từng cá nhân.

Mùa kiểm toán làm mọi thứ nổi lên cùng lúc

Thời điểm vấn đề lộ ra hầu như luôn là một cuộc kiểm toán. Kiểm toán nội bộ từ trụ sở Nhật Bản, đánh giá kiểm soát của công ty mẹ, đánh giá ISO, hay kiểm tra từ phía khách hàng. Dù là trường hợp nào, các câu hỏi về hệ thống cũng gần giống nhau.

• Có xuất được danh sách cho thấy hiện ai đang giữ quyền gì không
• Có trình bày được căn cứ cấp quyền đó không, tức là phiếu đề nghị và bản ghi phê duyệt
• Có chỉ ra được quyền của người nghỉ việc và người chuyển bộ phận đã bị thu hồi khi nào không
• Có nói được đang tồn tại bao nhiêu tài khoản đặc quyền và ai đang dùng không
• Có truy vết được ai đã thực hiện một thao tác quan trọng và vào lúc nào không

Không trả lời được câu nào trong số này thực ra không hiếm gặp. Điều phiền toái là khắc phục sau khi bị nêu phát hiện tốn kém hơn nhiều so với làm lúc bình thường. Phát hiện luôn đi kèm thời hạn, và bạn sẽ phải chạy song song việc rà soát quyền, thiết kế lại vai trò và dựng cơ chế thu thập nhật ký trong vòng ba tháng, mà vẫn không được dừng sản xuất, trong khi làm thong thả nửa năm lúc bình thường là đủ.

Rủi ro lớn nhất là lạm dụng chính quyền đã được cấp hợp lệ

Trước khi bàn đến kẻ tấn công từ bên ngoài, trường hợp cần hiểu trước là quyền được cấp hợp lệ bị sử dụng qua một lần đăng nhập hợp lệ. Ví dụ công bố công khai sát nhất với đúng kiểu thất bại mà bài viết này bàn tới là vụ việc Recruit công bố ngày 30 tháng 3 năm 2026.

Theo công bố của công ty, một cựu nhân viên đã dùng quyền truy cập được cấp cho công việc của mình để đưa dữ liệu nội bộ ra cho một bên thứ ba bên ngoài công ty. Công ty nhận được thông tin từ bên ngoài vào tháng 12 năm 2025 và xác nhận sự việc qua điều tra nội bộ vào tháng 2 năm 2026. Số người chịu ảnh hưởng được công bố là khoảng 20,699 người, trong đó có 32 thành viên ban điều hành, 24 thư ký ban điều hành, 449 nhân viên kinh doanh thuộc mảng làm đẹp, hồ sơ bao trùm khoảng 19,000 nhân viên nói chung, và 1,194 người phụ trách các câu lạc bộ.

Điều vụ việc này cho thấy là tường lửa, giải pháp phát hiện tại điểm cuối hay xác thực đa yếu tố đều vô hiệu trước kiểu hành vi này. Tài khoản được dùng là tài khoản thật và quyền được dùng là quyền thật, nên nhìn từ phía hệ thống thì không phân biệt được với công việc thường ngày. Chỉ có hai thứ tạo ra được sự phân biệt đó. Thứ nhất là chính thiết kế phân quyền, thứ quyết định người này có bao giờ cần với tới tập dữ liệu đó hay không. Thứ hai là nhật ký thao tác, ghi lại ai đã xem hoặc kết xuất cái gì, vào lúc nào và với khối lượng bao nhiêu.

Tấn công từ bên ngoài rốt cuộc cũng là câu chuyện đi được tới đâu

Dĩ nhiên tấn công từ bên ngoài vẫn quan trọng. Ngày 14 tháng 8 năm 2026, Nichirei công bố rằng một cuộc tấn công mã độc tống tiền xảy ra ngày 13 tháng 7 năm 2026, được quy cho nhóm RansomHouse, có khả năng đã làm rò rỉ tên nhân viên, ngày tháng năm sinh, địa chỉ thư điện tử công ty và thông tin nhân sự. Cũng trong tháng 8 năm 2026 đó, nhiều doanh nghiệp khác, trong đó có Chubu Electric Power, được ghi nhận có sự cố truy cập trái phép vào hệ thống nội bộ.

Chỗ mà phân quyền phát huy tác dụng trong bối cảnh tấn công từ bên ngoài là sau khi hàng rào đã bị chọc thủng. Thông tin đăng nhập mà kẻ tấn công chiếm được đầu tiên thường thuộc về một người dùng thông thường ở đầu cuối. Thứ quyết định thông tin đăng nhập đó với được tới đâu chính là thiết kế phân quyền. Nếu ai cũng chạm được vào mọi phân hệ thì chiếm một tài khoản đầu cuối cũng đồng nghĩa với chiếm toàn bộ dữ liệu công ty. Ngược lại, nếu phạm vi dữ liệu đã được giới hạn theo vai trò, thiệt hại sẽ dừng ở đúng phần việc của tài khoản đó.

Nhà máy vận hành tại Thái Lan còn chịu thêm sức nặng của PDPA

Doanh nghiệp đặt cơ sở tại Thái Lan còn một điều kiện nữa, đó là việc thực thi Luật bảo vệ dữ liệu cá nhân đang diễn ra thật sự. Theo bài phân tích do Tilleke and Gibbins công bố ngày 1 tháng 8 năm 2025, Ủy ban bảo vệ dữ liệu cá nhân của Thái Lan đã công bố 5 vụ việc với 8 khoản phạt, tổng cộng khoảng 21.5 triệu baht. Các nguyên nhân chính được nêu là biện pháp bảo đảm an toàn không đầy đủ hoặc chưa từng được rà soát lại, không thực hiện nghĩa vụ thông báo khi có sự cố, và không bổ nhiệm cán bộ bảo vệ dữ liệu cá nhân.

Cụm “biện pháp chưa từng được rà soát lại” chính là chuyện phân quyền. Một mô hình vai trò thiết kế một lần rồi để yên nhiều năm, hay tài khoản của người đã nghỉ việc vẫn dùng được, đều rơi thẳng vào phát hiện đó. Hệ thống quản lý sản xuất của nhà máy chứa dữ liệu chấm công, kết quả tác nghiệp và thông tin kỹ năng của nhân viên, cùng thông tin người liên hệ phía khách hàng và nhà cung cấp. Tất cả đều là dữ liệu cá nhân. Bức tranh tổng thể về nghĩa vụ PDPA nhìn từ hiện trường nhà máy được sắp xếp trong bài bảo vệ dữ liệu cá nhân cho IoT nhà máy, nên đọc kèm với bài này.

Thiết kế quyền truy cập hệ thống nghiệp vụ theo ba lớp

Gắn quyền vào chức danh thì lần nào cũng vỡ

Điểm xuất phát quen thuộc của thiết kế phân quyền là bám theo sơ đồ tổ chức. Trưởng phòng được bộ này, tổ trưởng được bộ kia, nhân viên được phần còn lại. Nhìn thì gọn gàng nhưng vỡ rất sớm, vì trưởng phòng quản lý sản xuất và trưởng phòng đảm bảo chất lượng cần những bộ quyền hoàn toàn khác nhau dù cùng cấp bậc. Các ngoại lệ cứ chồng lên từng cái một, và trong vài năm thì quan hệ giữa chức danh với quyền tan biến.

Một thiết kế sống sót được sẽ không cố diễn đạt quyền trên một trục duy nhất. Nó tách quyền thành ba lớp độc lập là vai trò, tức người đó làm việc gì, phạm vi, tức với tới được bao nhiêu dữ liệu, và hành động, tức làm được gì với dữ liệu ấy.

Lớp 1 – vai trò, xác định theo hình dạng của công việc

Vai trò được định nghĩa theo nội dung công việc, không theo cấp bậc hay phòng ban. Với hệ thống quản lý sản xuất, các đơn vị dùng được thường có dạng như sau.

• Tiếp nhận đơn hàng và tính toán nhu cầu vật tư
• Lập kế hoạch sản xuất
• Nhập kết quả tác nghiệp tại hiện trường
• Quản lý tồn kho và xuất nhập hàng
• Mua hàng và phát hành đơn đặt hàng
• Nhập hồ sơ chất lượng
• Phân tích giá thành và kết quả thực hiện
• Bảo trì dữ liệu chủ
• Quản trị hệ thống

Tính chất quan trọng là danh sách này bắt nguồn từ công việc phải diễn ra, chứ không từ những con người hiện có trong nhà máy. Một người giữ ba vai trò là điều không tránh khỏi ở nhà máy quy mô vừa và nhỏ. Điều quan trọng là tình trạng ấy phải nhìn thấy được dưới dạng “người này được gán ba vai trò”, chứ không giấu bên trong một vai trò lai ghép làm riêng. Tạo ra vai trò lai ghép riêng thì đến ngày người đó chuyển bộ phận sẽ không ai biết chuyện gì sẽ xảy ra.

Lớp 2 – phạm vi, giới hạn tầm với của dữ liệu

Hai người có thể cùng một vai trò nhưng cần những tập dữ liệu khác nhau. Ở công ty có nhiều nhà máy và nhiều chuyền, lớp này mới là nơi việc kiểm soát thông tin thực sự diễn ra.

• Theo địa điểm hoặc nhà máy, ví dụ người dùng ở nhà máy Rayong không nhìn thấy kết quả sản xuất của Chonburi
• Theo chuyền hoặc công đoạn
• Theo nhóm sản phẩm hoặc khách hàng, ví dụ người phụ trách một khách hàng không xem được bản vẽ hay giá thành của khách hàng khác
• Theo khoảng thời gian, tức tra cứu ngược được dữ liệu cũ tới đâu

Kiểm soát phạm vi là chỗ các sản phẩm khác nhau nhiều nhất về năng lực thực tế. Hệ thống nào cũng định nghĩa được vai trò. Câu hỏi khó hơn là cùng một màn hình nhập đơn hàng có hiển thị được duy nhất những đơn thuộc các khách hàng mà người đó phụ trách hay không. Đây là điểm phải hỏi rõ ở giai đoạn lựa chọn.

Lớp 3 – hành động, tách theo loại thao tác

Lớp thứ ba là loại thao tác. Nếu một hệ thống chỉ diễn đạt được “đọc” và “ghi” thì hãy coi khả năng kiểm soát quyền của nó là yếu. Trên thực tế cần tách được ít nhất năm loại sau.

Loại hay bị bỏ sót nhất là loại cuối. Vì người có quyền xem thì đã nhìn thấy dữ liệu trên màn hình rồi, nên kết xuất bị coi là tương đương. Về mặt kiểm soát thì hai việc này chẳng giống nhau chút nào. Đọc từng bản ghi trên màn hình và tải cả bảng xuống dạng CSV chênh nhau nhiều bậc về mức độ rủi ro. Nếu kiểu thất bại mà bạn đang phòng ngừa giống với vụ mang dữ liệu ra ngoài nêu trên, thì kết xuất khối lượng lớn phải được tách thành một quyền riêng và phải nằm trong phạm vi nhật ký thao tác bàn ở phần sau.

Phân tách nhiệm vụ – những cặp quyền không được nằm trong tay một người

Sau khi phác xong ba lớp, thứ phải đem ra đối chiếu là phân tách nhiệm vụ. Trong thực hành kiểm soát chung về công nghệ thông tin, ví dụ chuẩn mực luôn được nhắc tới là không bao giờ để một người vừa có quyền tạo đơn đặt hàng vừa có quyền phê duyệt thanh toán. Nếu người tạo tự phê duyệt được thì bước phê duyệt trở nên vô nghĩa.

Chuyển sang hệ thống quản lý sản xuất, tối thiểu những cặp sau đáng được xem xét tách ra.

• Tạo đơn đặt hàng mua và phê duyệt chính đơn đặt hàng đó
• Ghi nhận xuất nhập kho và điều chỉnh chênh lệch kiểm kê
• Nhập lệnh giao hàng và xác nhận kết quả giao hàng
• Sửa đơn giá trong dữ liệu chủ vật tư và phê duyệt kết quả tính giá thành
• Thực hiện thao tác nghiệp vụ thông thường và xóa hoặc cấu hình lại nhật ký thao tác

Cặp cuối cùng đặc biệt quan trọng. Nếu người xóa được nhật ký cũng thao tác nghiệp vụ được thì bản thân dấu vết kiểm toán không còn đáng tin. Ngay cả quản trị viên hệ thống cũng nên nằm trong cấu hình không sửa được bản ghi nhật ký.

Ở nhà máy ít người, tách hoàn toàn đôi khi là bất khả thi về mặt vật lý. Cách xử lý đúng không phải là buông xuôi mà là ghi thành văn bản rằng không tách được, rồi đặt một biện pháp kiểm soát bù trừ vào chỗ đó. Biện pháp bù trừ có thể là ghi nhật ký toàn bộ mọi lần thực hiện thao tác ấy và để cấp trên rà soát danh sách hằng tháng. Điều kiểm toán hỏi không phải là có tách hay không, mà là rủi ro đã được nhận diện và xử lý hay chưa.

Các mẫu thiết kế khi đưa luồng phê duyệt lên hệ thống

Đừng sao chép nguyên tuyến duyệt trên giấy

Thất bại phổ biến nhất khi đưa luồng phê duyệt lên hệ thống là bê nguyên tuyến luân chuyển giấy tờ hiện hành lên màn hình. Tuyến duyệt trên giấy thường phình ra vì các ô đóng dấu đảm nhiệm lẫn lộn cả việc thông báo lẫn việc quy trách nhiệm, nên bê nguyên sang sẽ sinh ra ùn tắc chờ duyệt. Hễ có ùn tắc là hiện trường sẽ tạo ra đường vòng. Họ giao hàng trước rồi chỉnh hệ thống cho khớp sau. Đến lúc đó, bản ghi phê duyệt trong hệ thống không còn phản ánh thực tế nữa và biện pháp kiểm soát chỉ còn hình thức.

Trước khi đưa lên hệ thống, hãy bóc tách xem mỗi con dấu đang bảo đảm điều gì. Phần lớn trường hợp nó là một trong ba thứ sau.

• Kiểm tra, tức đã có người xác nhận nội dung là đúng
• Phê duyệt, tức quyết định rằng được phép tiến hành
• Thông báo, tức người cần biết đã được cho biết

Chỉ có thứ ở giữa mới nên trở thành một bước phê duyệt trong hệ thống. Thông báo thì dùng chức năng thông báo là đủ, còn kiểm tra thì nhiều khi thay thế được bằng ràng buộc dữ liệu lúc nhập hoặc bằng một danh mục tự kiểm. Chuyện một quyết định từng có 5 ô đóng dấu rút gọn còn 1 bước phê duyệt cộng 3 thông báo không phải là hiếm.

Thu hẹp lại xem thao tác nào cần phê duyệt

Đặt phê duyệt lên mọi thao tác thì công việc tắc nghẽn, không đặt lên gì cả thì không có kiểm soát. Ba trục sau giúp quyết định một cách khả thi.

Những thao tác hằng ngày không rơi vào cả ba trục, chẳng hạn nhập kết quả tác nghiệp thông thường, không cần phê duyệt. Đặt phê duyệt ở đó thì người duyệt sẽ bắt đầu duyệt hàng loạt mà không xem nội dung, làm giảm độ tin cậy của toàn bộ bản ghi phê duyệt trong hệ thống.

Thiết kế người duyệt thay và cơ chế chuyển lên cấp trên ngay từ đầu

Nguyên nhân lớn nhất khiến luồng phê duyệt sụp đổ là người duyệt vắng mặt. Đi công tác, nghỉ phép, nghỉ việc và chuyển bộ phận. Để chuyện này lại tính sau thì hiện trường rốt cuộc sẽ đi tới đường vòng tệ nhất, đó là mượn tài khoản và mật khẩu của người duyệt. Từ giây phút ấy, cả bản ghi phê duyệt lẫn nhật ký thao tác đều mất ý nghĩa.

Hãy đưa ba điểm sau vào yêu cầu ngay từ đầu.

• Đăng ký trước được người duyệt thay, và việc phê duyệt với tư cách người thay được ghi lại trong nhật ký
• Hạng mục không được duyệt quá một khoảng thời gian định trước sẽ tự động chuyển lên người duyệt cấp cao hơn
• Khi người duyệt nghỉ việc hoặc chuyển bộ phận, các hạng mục còn tồn của họ bàn giao được sang người kế nhiệm theo lô

Điểm thứ ba thường bị xem nhẹ, và thiếu nó thì mỗi lần người duyệt chuyển bộ phận lại có một mớ hạng mục treo lơ lửng không chủ.

Đưa chính việc cấp tài khoản vào luồng phê duyệt

Thứ hay bị bỏ qua là luồng phê duyệt không chỉ cần cho dữ liệu nghiệp vụ mà còn cần cho chính việc cấp quyền. Thực hành kiểm soát chung về công nghệ thông tin mô tả việc cấp tài khoản như một trình tự chuẩn gồm nộp phiếu đề nghị, phê duyệt của người quản lý trực tiếp, rồi phê duyệt của bộ phận công nghệ thông tin. Điểm mấu chốt là phê duyệt được đặt thành hai cấp một cách có chủ ý. Người quản lý phán đoán xem công việc đó có cần quyền đó không. Bộ phận công nghệ thông tin phán đoán xem quyền đó có phù hợp về kỹ thuật và về kiểm soát không. Hai cấp này phán đoán hai chuyện khác nhau nên chỉ một cấp là không đủ.

Rất nhiều công ty xử lý việc này bằng lời nói hoặc qua tin nhắn, nhưng thứ kiểm toán cần là bản ghi. Bạn không cần mua một sản phẩm quản lý luồng công việc chuyên dụng. Một biểu mẫu đề nghị cộng với lịch sử phê duyệt được lưu lại là đủ để bắt đầu, kể cả trên nền tảng cộng tác sẵn có. Điều quan trọng là trình bày được từng quyền một, rằng nó được cấp khi nào và trên phê duyệt của ai.

Chu trình vận hành của kiểm soát nội bộ đối với hệ thống quản lý sản xuất

Rà soát quyền truy cập theo quý

Phân quyền không phải là một bài toán thiết kế xong là hết. Nó chỉ trở thành biện pháp kiểm soát khi được ghép với việc rà soát định kỳ. Thực hành kiểm soát chung về công nghệ thông tin đặt việc rà soát quyền truy cập và xác nhận tính phù hợp theo nhịp hằng quý.

Trên thực tế các bước như sau.

1. Kết xuất danh sách quyền hiện tại từ hệ thống
2. Gửi cho từng trưởng bộ phận danh sách của bộ phận mình và yêu cầu đánh dấu những quyền không còn cần
3. Đối chiếu với dữ liệu nhân sự để bắt những người đã nghỉ việc hoặc chuyển bộ phận vẫn còn sót
4. Kiểm tra riêng từng tài khoản đặc quyền và quyền quản trị hệ thống
5. Ghi lại kết quả xóa và thay đổi, lưu giữ cho tới kỳ rà soát tiếp theo

Việc này có duy trì được thật hay không gần như phụ thuộc hoàn toàn vào bước 1, tức là có kết xuất được danh sách quyền chỉ bằng một nút bấm hay không. Ở những hệ thống phải nhờ nhà cung cấp lấy hộ danh sách, việc rà soát hằng quý sẽ không bao giờ thành thói quen. Hãy xác nhận khả năng tự kết xuất danh sách quyền ngay từ khâu lựa chọn sản phẩm.

Lấy tuyển dụng, nghỉ việc và điều chuyển làm điểm kích hoạt

Rà soát hằng quý là tấm lưới hứng, không phải tuyến phòng thủ đầu tiên. Tài khoản của người nghỉ việc sống sót được tới ba tháng không phải là kết quả chấp nhận được. Tuyến đầu là việc xử lý được kích hoạt bởi các sự kiện nhân sự.

• Nghỉ việc, đình chỉ toàn bộ tài khoản ngay trong ngày làm việc cuối cùng. Đình chỉ chứ không xóa, để giữ khả năng truy vết của nhật ký
• Điều chuyển, gỡ quyền cũ trước rồi mới cấp quyền mới, không cộng dồn lên nhau
• Nghỉ dài ngày, đình chỉ tạm thời rồi xác nhận lại khi quay lại làm việc
• Thay người của nhà thầu, quản lý theo từng cá nhân chứ không theo hợp đồng

Toàn bộ những việc này không chạy được nếu thiếu một sổ đăng ký ai đang giữ tài khoản nào và thiết bị nào. Cách hệ thống hóa việc kiểm kê tài khoản và thiết bị được trình bày trong bài quản lý tài sản công nghệ thông tin trong nhà máy, và nên xây dựng song song với phân quyền.

Xoay xở thế nào khi gần như không có bộ phận công nghệ thông tin

Mọi thứ ở trên có thể đọc như thể giả định rằng có một bộ phận công nghệ thông tin đầy đủ. Phần lớn nhà máy Nhật Bản tại Thái Lan vận hành chức năng này với một người, hoặc dưới dạng kiêm nhiệm. Thực hiện rà soát hằng quý trong hoàn cảnh đó, nói thật, không dễ.

Có ba lựa chọn khả thi. Thứ nhất là thuê ngoài riêng phần kiểm kê nhưng giữ phần phán đoán ở trong. Những phần tốn sức như kết xuất, đối chiếu và lập báo cáo thì đưa ra ngoài, còn trưởng bộ phận chỉ quyết định gỡ cái gì. Thứ hai là đưa việc rà soát quyền hằng năm hoặc nửa năm vào hợp đồng bảo trì của nhà cung cấp hệ thống. Thứ ba là đưa cả chức năng công nghệ thông tin ra bên ngoài, và các tiêu chí quyết định cho hướng này được sắp xếp trong bài thuê ngoài bộ phận công nghệ thông tin. Dù chọn hướng nào, hãy giữ quyết định phê duyệt cuối cùng ở trong công ty. Đưa cả phần đó ra ngoài thì quyền sở hữu biện pháp kiểm soát sẽ không còn rõ ràng.

Danh mục kiểm tra nhật ký thao tác và dấu vết kiểm toán cho nhà máy

Cần ghi lại những gì

Nhật ký thao tác không được đánh giá ở chỗ có hay không có, mà ở chỗ có dùng được trong kiểm toán hay không. Một bản ghi nhật ký cần tối thiểu năm thuộc tính sau.

Giá trị trước và sau là thuộc tính hay thiếu nhất ở cấu hình mặc định. Rất phổ biến tình trạng hệ thống lưu lịch sử đăng nhập và lịch sử truy cập màn hình nhưng lại không giữ nội dung thay đổi dữ liệu thực tế. Riêng với việc sửa dữ liệu chủ và sửa kết quả hồi tố, hãy xác nhận theo từng trường hợp rằng cấu hình có giữ giá trị cũ và giá trị mới.

Thu hẹp phạm vi những gì được ghi

Ghi lại mọi thao tác sẽ tạo ra khối lượng mà không ai đọc. Với hệ thống quản lý sản xuất của nhà máy, phạm vi ưu tiên là như sau.

• Đăng nhập, đăng xuất và các lần xác thực thất bại
• Cấp, thay đổi và thu hồi quyền cùng vai trò
• Thay đổi dữ liệu chủ gồm mã hàng, đơn giá, đối tác, định mức vật tư và giá thành tiêu chuẩn
• Phê duyệt và từ chối
• Khóa sổ kỳ, sửa kết quả hồi tố và điều chỉnh chênh lệch kiểm kê
• Kết xuất và trích xuất dữ liệu khối lượng lớn, bao gồm truy cập qua API

Mục cuối là biện pháp đối phó trực tiếp với rủi ro mang dữ liệu ra ngoài đã nêu. Nếu giữ lại được ai đã kết xuất phạm vi dữ liệu nào, vào lúc nào và bao nhiêu bản ghi, thì một lần trích xuất bất thường vẫn có thể phát hiện được về sau. Không có nó thì việc mang dữ liệu ra ngoài thậm chí không thể biết là đã từng xảy ra.

Thời hạn lưu trữ và chống sửa đổi

Không có một đáp án duy nhất cho thời hạn lưu trữ, nhưng có phương pháp để quyết định. Hãy bắt đầu bằng cách tính ngược từ chu kỳ kiểm toán của chính công ty và đặt mức sàn ở độ dài chắc chắn bao trùm kỳ kiểm toán gần nhất. Sau đó điều chỉnh theo cái dài nhất trong số quy định lưu trữ hồ sơ của công ty mẹ, thông lệ lưu trữ chứng từ thuế và kế toán, và thời hạn mà hợp đồng yêu cầu. Tối thiểu, hãy tránh tình trạng nhật ký tự động xóa sau một năm khiến kỳ kiểm toán trước đó không còn tồn tại.

Về chống sửa đổi, hãy phủ ba điểm. Thứ nhất, cấu hình sao cho quản trị viên hệ thống nghiệp vụ không sửa hay xóa được nhật ký. Thứ hai, sao chép nhật ký sang một nơi lưu trữ tách biệt hằng ngày, nơi phía nghiệp vụ không có quyền ghi. Thứ ba, ghi nhật ký cho chính các thao tác xóa và thay đổi cấu hình. Chỉ khi có đủ cả ba, nhật ký mới hoạt động được như một dấu vết kiểm toán.

Nhật ký không ai đọc thì không phải là tài sản

Vấn đề lặp lại của nhật ký là thu thập rồi không ai đọc. Trong các vụ thực thi của Ủy ban bảo vệ dữ liệu cá nhân đã nêu, việc không thực hiện nghĩa vụ thông báo sự cố cũng nằm trong số nguyên nhân được chỉ ra. Muốn thông báo thì trước hết phải nhận ra, mà muốn nhận ra thì phải có người thật sự xem nhật ký.

Một cách vận hành khả thi là trộn các tần suất lại. Rà soát danh sách thay đổi quyền hằng tháng. Kiểm tra số lần kết xuất khối lượng lớn và truy cập qua API hằng tuần, chỉ truy theo những con số lệch xa khỏi dải bình thường. Với các lần xác thực thất bại liên tiếp và khóa tài khoản thì cảnh báo tức thời. Không phải mọi thứ đều cần xem hằng ngày, và việc tách tần suất theo từng đối tượng đưa khối lượng công việc xuống mức duy trì được.

Nhìn vào đâu khi lựa chọn hoặc cấu hình hệ thống

Những câu hỏi nên đưa vào hồ sơ mời thầu

Phân quyền là mảng mà việc bổ sung sau khi go-live thường bất khả thi vì vướng thiết kế của sản phẩm. Chính vì vậy nó là câu hỏi của giai đoạn lựa chọn. Đưa các mục sau vào hồ sơ mời thầu sẽ làm lộ rõ khoảng cách năng lực thực tế giữa các nhà cung cấp.

• Định nghĩa vai trò có tạo và sửa được trong nội bộ không, hay phải nhờ nhà cung cấp làm
• Một người dùng có gán được nhiều vai trò không
• Có giới hạn được truy cập theo phạm vi dữ liệu như địa điểm, chuyền hay khách hàng không
• Có tách được quyền xem và quyền kết xuất, tức CSV, báo cáo và API, thành các quyền khác nhau không
• Nhân sự của chúng tôi có tự kết xuất được danh sách quyền không, và ở định dạng nào
• Tuyến và điều kiện phê duyệt có tự cấu hình được không, có người duyệt thay và chuyển cấp tự động không
• Nhật ký thao tác có giữ giá trị trước và sau không, và có chọn được ghi những thao tác nào không
• Thời hạn lưu trữ nhật ký là bao lâu, và có cơ chế chuyển sang nơi lưu trữ bên ngoài như thế nào
• Có cấu hình được để quản trị viên không sửa hay xóa được nhật ký không

Cách đưa những yêu cầu kiểu này vào hồ sơ mời thầu mà không bỏ sót được trình bày đầy đủ trong hướng dẫn lập RFP cho hệ thống quản lý sản xuất, nên đọc trước nếu sắp bước vào giai đoạn lựa chọn.

Những nước đi thực tế khi hệ thống hiện tại yếu về phân quyền

Nếu hệ thống đang chạy có năng lực phân quyền không đủ, thay thế không phải là câu trả lời duy nhất. Vẫn có thể khắc phục theo từng giai đoạn dựa trên thứ tự ưu tiên.

Hãy bắt đầu bằng ba việc không tốn chi phí nhưng hiệu quả nhất là bỏ tài khoản dùng chung để chuyển sang tài khoản cá nhân, viết thành văn bản quy tắc đình chỉ tài khoản của người nghỉ việc ngay lập tức, và giảm số người đang giữ quyền quản trị hệ thống. Tiếp theo, bắt đầu kết xuất danh sách quyền theo định kỳ, kể cả khi phải làm thủ công. Sau đó, với những khoảng trống mà sản phẩm không lấp được, chẳng hạn giới hạn phạm vi dữ liệu hay ghi giá trị trước và sau, hãy đánh giá xem có thể phủ tới đâu bằng trigger phía cơ sở dữ liệu hoặc công cụ ngoại vi. Phần thật sự không phủ được sẽ trở thành yêu cầu cho lần thay thế kế tiếp.

Điều cốt yếu là đừng dừng lại ở “hệ thống hiện tại không làm được”, mà hãy xác định chính xác nó không làm được cái gì rồi ghi lại thành văn bản. Kiểm toán không chấm điểm sự hoàn hảo. Kiểm toán chấm điểm việc hiểu rủi ro và sắp xếp được thứ tự ưu tiên.

Câu hỏi thường gặp

Ai nên là người quyết định thiết kế phân quyền của hệ thống quản lý sản xuất

Không phải bộ phận công nghệ thông tin đơn độc. Định nghĩa vai trò và phạm vi nên do phía nghiệp vụ quyết định, tức là quản lý sản xuất, mua hàng, chất lượng và kế toán, còn bộ phận công nghệ thông tin đảm nhiệm việc dịch các định nghĩa đó thành thứ dựng được về mặt kỹ thuật. Tính phù hợp của phân tách nhiệm vụ nên có xác nhận của kiểm toán nội bộ hoặc bộ phận quản trị. Trên thực tế, khởi đầu khả thi nhất là lập một nhóm làm việc nhỏ gồm những người chủ chốt phía nghiệp vụ và hoàn thành bản nháp danh sách vai trò trong khoảng hai tuần.

Nên lưu nhật ký thao tác trong bao lâu

Vì không có thời hạn cố định nào được quy định, hãy tính ngược. Mức sàn là độ dài bao trùm chu kỳ kiểm toán của chính công ty. Nếu mỗi năm chịu một cuộc kiểm toán nội bộ thì toàn bộ kỳ kiểm toán gần nhất phải còn nguyên. Sau đó kiểm tra quy định lưu trữ hồ sơ của công ty mẹ, thông lệ lưu trữ chứng từ thuế và kế toán, cùng thời hạn mà hợp đồng với khách hàng yêu cầu, rồi điều chỉnh theo cái dài nhất. Khi dung lượng là ràng buộc, thay vì giữ mọi thứ thật lâu, hãy giữ lâu hơn các bản ghi quan trọng cao như thay đổi quyền, thay đổi dữ liệu chủ và kết xuất khối lượng lớn, còn lịch sử truy cập màn hình thông thường thì giữ ngắn lại.

Nên bắt đầu đưa luồng phê duyệt lên hệ thống từ đâu

Hãy bắt đầu từ các thao tác không thể đảo ngược. Xác nhận giao hàng, thanh lý tồn kho, khóa sổ kỳ, sửa đơn giá dữ liệu chủ, tức mọi thứ đã làm là không hoàn tác được. Chỉ cần đặt phê duyệt ở đó là đã thu được phần lớn lợi ích về kiểm soát. Ngược lại, nếu bắt đầu từ những thao tác đảo ngược được và có khối lượng lớn như nhập kết quả tác nghiệp hằng ngày thì sẽ sinh ùn tắc và cách vận hành không bám rễ được. Hãy giới hạn phạm vi đầu tiên trong khoảng 3 đến 5 thao tác, chạy nửa năm, xác nhận đã ổn định rồi mới mở rộng.

Nhà máy nhỏ nơi một người kiêm nhiều việc có cần phân tách nhiệm vụ không

Có, nhưng không cần theo đúng hình dạng của doanh nghiệp lớn. Ràng buộc về số người tất yếu để lại những cặp quyền không tách được, và điều kiểm toán hỏi không phải là có tách hay không mà là rủi ro đã được nhận diện và xử lý hay chưa. Hãy liệt kê những cặp không tách được và gắn cho mỗi cặp một biện pháp kiểm soát bù trừ. Biện pháp bù trừ điển hình là ghi nhật ký toàn bộ mọi lần thực hiện thao tác đó rồi để cấp trên hoặc quản lý người Nhật rà soát hằng tháng, hoặc đặt ngưỡng giá trị và số lượng để phần vượt ngưỡng chuyển sang một người duyệt khác. Có danh sách đó cùng bằng chứng rằng nó đang được thực hiện thì việc kiêm nhiệm hầu như tự nó sẽ không trở thành một phát hiện.

Kết luận

Phân quyền trong hệ thống quản lý sản xuất cứ bị hoãn lại vì nó không bao giờ chặn sản xuất, rồi nổi lên cùng lúc dưới dạng một phát hiện kiểm toán hoặc một sự cố. Những điểm đáng mang về là như sau.

• Lõi của rủi ro không phải là kẻ tấn công bên ngoài mà là việc lạm dụng quyền đã được cấp hợp lệ. Trong vụ việc Recruit công bố ngày 30 tháng 3 năm 2026, một cựu nhân viên đã dùng quyền truy cập phục vụ công việc để đưa dữ liệu nội bộ bao trùm khoảng 20,699 người ra ngoài công ty. Hành vi thực hiện bằng tài khoản thật chỉ có thể phân biệt được bằng thiết kế phân quyền và nhật ký thao tác
• Thiết kế quyền theo ba lớp là vai trò, phạm vi và hành động. Gắn vào chức danh thì lần nào cũng vỡ. Riêng ở lớp hành động, việc tách quyền xem khỏi quyền kết xuất là thứ trực tiếp giải quyết bài toán mang dữ liệu ra ngoài
• Lập văn bản cho phân tách nhiệm vụ, bao gồm cả biện pháp bù trừ ở những chỗ không tách được. Tạo và phê duyệt không được nằm trong tay một người, và nơi số nhân sự không cho phép thì hãy ghi lại ngoại lệ kèm biện pháp bù trừ của nó
• Đừng sao chép tuyến duyệt trên giấy. Hãy thu hẹp phê duyệt về các thao tác không thể đảo ngược. Không đưa người duyệt thay và cơ chế chuyển cấp vào yêu cầu ngay từ ngày đầu thì hiện trường sẽ đi tới việc dùng chung mật khẩu, đường vòng tệ nhất
• Nhật ký thao tác cần đủ 5 thuộc tính, trong một cấu hình mà quản trị viên không xóa được. Ai, khi nào, cái gì, làm gì và từ đâu. Việc có giữ giá trị trước và sau hay không phải kiểm tra theo từng trường hợp
• Ghép việc kiểm kê quyền hằng quý với việc đình chỉ tức thời được kích hoạt bởi sự kiện nhân sự. Tại Thái Lan, Ủy ban bảo vệ dữ liệu cá nhân đã công bố 5 vụ việc với 8 khoản phạt, tổng cộng khoảng 21.5 triệu baht, nên biện pháp bảo đảm an toàn chưa từng được rà soát đã là một phát hiện có thật chứ không phải chuyện lý thuyết

Không việc nào trong số này đòi hỏi đầu tư lớn để bắt đầu. Hãy khởi động bằng cách kết xuất danh sách quyền hiện tại. Nếu không kết xuất được thì đó chính là phát hiện đầu tiên của bạn.

Nếu bạn đang làm lại thiết kế phân quyền, hoặc đang sắp xếp các điểm cần kiểm tra cho việc lựa chọn hệ thống quản lý sản xuất, xin mời trao đổi với TOMAS TECH. Chúng tôi đặt trụ sở tại Bangkok, cung cấp hệ thống quản lý sản xuất PEGASUS cùng các giải pháp DX hiện trường khác cho doanh nghiệp sản xuất Nhật Bản tại Thái Lan, và có thể hỗ trợ những phần việc thực tế như soạn danh sách vai trò, thiết kế tuyến phê duyệt, xác định phạm vi ghi nhật ký thao tác. Ngay cả khi bạn còn đang ở giai đoạn định hình vấn đề, xin cứ thoải mái liên hệ.

Tài liệu tham khảo

• Bài viết của Nikkei về công bố sự cố mã độc tống tiền của Nichirei, ngày 14 tháng 8 năm 2026
• Tổng hợp sự cố an ninh thông tin tháng 8 năm 2026 của TMI Consulting
• Thông cáo báo chí của Recruit về việc cựu nhân viên đưa thông tin ra ngoài trái phép, ngày 30 tháng 3 năm 2026
• Thực hành quản lý truy cập theo kiểm soát chung về công nghệ thông tin, IT Audit Compass, ngày 24 tháng 4 năm 2026
• More Than a Warning – Eight Serious Fines Imposed in Thai Data Protection Cases, Tilleke and Gibbins, ngày 1 tháng 8 năm 2025