Công nhận lẫn nhau nhãn an ninh mạng trong mua sắm IoT nhà máy ASEAN

Cơ chế công nhận lẫn nhau giữa Singapore Cybersecurity Labelling Scheme (CLS) và JC-STAR STAR-1 của Nhật Bản cho phép tái sử dụng kết quả đánh giá những yêu cầu được hai chương trình xem là tương đương khi nộp đơn sang chương trình còn lại. Nhà sản xuất có thể giảm công việc đánh giá sự phù hợp trùng lặp khi tiếp cận nhiều thị trường. Tuy nhiên, với bên mua của nhà máy, nhãn không phải là giấy phép kết nối thiết bị vào mạng sản xuất, không chứng minh hai chương trình giống hệt nhau và không tạo ra nghĩa vụ pháp lý tại Thái Lan. Bài viết chuyển bằng chứng nhãn thành chuỗi cổng mua sắm thực tế: RFP → ánh xạ bằng chứng → phù hợp tài sản/vùng → khắc phục của nhà cung cấp → FAT/SAT → giám sát hết hạn và thay đổi.

Thỏa thuận Nhật Bản–Singapore đã thay đổi điều gì?

Bộ Kinh tế, Thương mại và Công nghiệp Nhật Bản cùng Cơ quan An ninh mạng Singapore ký Memorandum of Cooperation ngày 18 tháng 3 năm 2026. Cơ chế có hiệu lực ngày 1 tháng 6 năm 2026. Phạm vi là các yêu cầu được xem là tương đương giữa JC-STAR STAR-1 và Singapore CLS Level 1, với thủ tục đơn giản hơn khi nộp sang chương trình kia (METI, thông cáo CSA).

IPA giải thích rằng sản phẩm đã có nhãn CLS khi nộp JC-STAR ★1 có thể được miễn các mục checklist tương ứng với yêu cầu đã đáp ứng theo CLS. IPA niêm yết phí STAR-1 cho tuyến sản phẩm có CLS là 140.000 JPY, đã gồm thuế, so với phí tiêu chuẩn 198.000 JPY, đã gồm thuế. Hiệu lực ban đầu của nhãn JC-STAR là 2 năm. Đây là điều kiện/phí nộp đơn của chương trình, không phải tổng chi phí đánh giá nhà máy, kiểm thử, tích hợp, dịch thuật hoặc cải tạo mạng (hướng dẫn IPA).

Giá trị không phải là “không cần đánh giá”, mà là giảm phần đánh giá trùng lặp để dành thời gian cho rủi ro riêng của nhà máy.

Công nhận lẫn nhau không phải tương đương tự động

Từ “công nhận” dễ bị hiểu thành chuyển đổi tự động. Mô tả của IPA hẹp hơn: sản phẩm phù hợp CLS được xem là đáp ứng một phần tiêu chí JC-STAR ★1 và các mục checklist tương ứng có thể được miễn. Bên nộp vẫn phải đi theo quy trình quy định, xác định sản phẩm/nhãn và cung cấp bằng chứng cho những yêu cầu còn lại hoặc mới đáp ứng một phần. Chiều từ JC-STAR sang CLS cũng cần nộp theo tuyến MRA.

Bên mua không nên chấp nhận một dòng “hỗ trợ CLS/JC-STAR” trong báo giá. Với từng sản phẩm, cần thu thập:

• tên chương trình, cấp, số nhãn và URL công khai để xác minh;
• danh tính người nộp/nhà sản xuất và quan hệ với nhà cung cấp theo hợp đồng;
• tên sản phẩm, model, revision phần cứng, firmware và dịch vụ đám mây liên quan;
• ngày cấp, ngày hết hạn, trạng thái gia hạn;
• yêu cầu được tái sử dụng qua MRA và yêu cầu còn cần bằng chứng;
• đầu mối báo cáo lỗ hổng, thời gian hỗ trợ cập nhật, phương thức thông báo;
• điều kiện đánh giá lại khi thay linh kiện, OEM, firmware hoặc đám mây.

Cùng một tên thương mại nhưng phiên bản theo khu vực có thể khác mô-đun radio, firmware, nguồn điện, endpoint đám mây hoặc tùy chọn. Chỉ dùng bằng chứng để nghiệm thu khi cấu hình được gắn nhãn khớp với cấu hình giao thực tế.

Không đánh đồng Singapore CLS Level 1–4

Singapore CLS gồm bốn cấp với các tầng đánh giá tích lũy. CSA mô tả Tier 1 là baseline dựa trên ETSI EN 303 645; Tier 2 là tuân thủ các yêu cầu bắt buộc của tiêu chuẩn; Tier 3 gồm yêu cầu vòng đời và phân tích binary phần mềm; Tier 4 là kiểm thử xâm nhập bởi phòng thử nghiệm (CSA cho nhà sản xuất).

Do đó không được nói sản phẩm CLS Level 1 đã trải qua kiểm thử xâm nhập của bên thứ ba. Hoạt động đó thuộc Level/Tier 4. Ngay cả Level 4 cũng không bảo đảm chống mọi cuộc tấn công hay an toàn trong mọi kiến trúc công nghiệp; đó là bằng chứng cho sản phẩm, phiên bản, phạm vi và điều kiện thử xác định.

Yêu cầu STAR-3 công bố tháng 7/2026 là diễn biến riêng

Ngày 13 tháng 7 năm 2026, IPA thông báo đã phát hành yêu cầu STAR-3 cho thiết bị mạng và camera mạng (IPA JC-STAR). Điều này quan trọng với nhà máy mua router, gateway và camera, nhưng tách biệt với tuyến công nhận STAR-1/CLS Level 1 bắt đầu tháng 6/2026.

RFP cần ghi rõ cấp và loại sản phẩm thay vì chỉ ghi “phù hợp JC-STAR”. Bằng chứng baseline cho cảm biến môi trường và assurance cho gateway nối nhiều vùng là hai quyết định khác nhau. Công bố yêu cầu STAR-3 cũng không có nghĩa mọi sản phẩm ứng viên đã có nhãn STAR-3. Cần kiểm tra riêng yêu cầu, trạng thái nộp và danh mục sản phẩm thật sự có nhãn.

Tham khảo thêm hướng dẫn mua camera mạng theo JC-STAR và hướng dẫn nộp JC-STAR.

Tiêu chí mua sắm an ninh IoT phải là “nhãn + phù hợp nhà máy”

ETSI EN 303 645 V3.1.3 cung cấp baseline an ninh và bảo vệ dữ liệu cho consumer IoT. Chính tiêu chuẩn nêu việc triển khai cần dựa trên đánh giá rủi ro và mô hình hóa mối đe dọa, đồng thời có thể cần điều khoản bổ sung cho ca sử dụng cụ thể. Tài liệu định nghĩa yêu cầu sản phẩm chứ không ấn định một phương pháp thử/chứng nhận chung cho mọi bối cảnh (ETSI EN 303 645).

Ranh giới này rất quan trọng trong nhà máy. Baseline hữu ích để kiểm tra mật khẩu mặc định dùng chung, quản lý báo cáo lỗ hổng và cập nhật an toàn. Nghiệm thu công nghiệp còn phải xét tính sẵn sàng, an toàn, cửa sổ bảo trì, giao thức công nghiệp, tuổi thọ tài sản, truy cập từ xa và tương tác với PLC hiện hữu.

Ngay cả gateway có nhãn cũng cần bị từ chối hoặc khắc phục nếu:

• giao diện quản trị truy cập được từ toàn mạng sản xuất;
• không mô tả endpoint đám mây, hướng lưu lượng, port, DNS hoặc gia hạn certificate;
• tự động cập nhật có thể dừng dây chuyền vào thời điểm bất kỳ;
• không có backup/restore cấu hình;
• chỉ có tài khoản quản trị dùng chung và không truy được người thao tác;
• cảnh báo lỗ hổng đến trụ sở nhưng không đến đội bảo trì địa phương;
• hỗ trợ cập nhật kết thúc sớm hơn nhiều so với tuổi thọ thiết bị.

Nhãn là điểm vào của bằng chứng baseline sản phẩm; chấp nhận rủi ro nhà máy là cổng cuối cho môi trường sử dụng thực tế.

Quy trình mua sắm IoT nhà máy nước ngoài gồm 6 cổng

Đừng tách xác minh nhãn thành công việc hành chính riêng lẻ. Hãy đưa bằng chứng đi xuyên suốt quy trình và xác định ai kiểm tra gì, ai được duyệt ngoại lệ.

Gate 1: quy định cả mẫu trả lời trong RFP

“Hỗ trợ JC-STAR hoặc CLS” là quá mơ hồ. Hãy quy định trường trả lời, tài liệu đính kèm và phân loại bắt buộc/có điều kiện/thông tin.

Không chấp nhận Yes/No thiếu bằng chứng. Ghi phiên bản tài liệu, model áp dụng và ngoại lệ cạnh mỗi câu trả lời. Mục không trả lời là “chưa xác minh”, không phải mặc nhiên đạt.

Gate 2: ánh xạ bằng chứng chương trình với yêu cầu nội bộ

Ánh xạ từng yêu cầu công ty sang bằng chứng chương trình, bằng chứng nhà cung cấp hoặc bài thử nhà máy. Không cần ép mọi thứ 1:1; mục tiêu là cho thấy kết luận dựa trên nguồn nào và phần nào còn mở.

Hồ sơ tối thiểu gồm requirement ID, risk, scheme clause, evidence, covered version, decision, exception, due date và approver. Ghi trang/mục, tổ chức phát hành và ngày, không chỉ tên file.

Gate 3: quyết định phù hợp tài sản và vùng

Cùng một cảm biến có thể ít rủi ro trong phòng họp nhưng tác động lớn nếu gateway của nó truy cập controller sản xuất. Xác định tài sản cần bảo vệ, đường kết nối, dữ liệu, quyền điều khiển, tác động dừng máy, mục tiêu khôi phục và năng lực bảo trì tại chỗ.

Hãy hỏi cụ thể điều gì xảy ra nếu thiết bị bị xâm nhập: mất dữ liệu giám sát, giá trị giả đi vào MES, rò video, đổi cấu hình, di chuyển ngang tới PLC, hoặc mất điều khiển khi cloud ngừng. Sau đó chặn đường không chấp nhận bằng segmentation, allow-list, OT DMZ, jump host, local fallback, backup và monitoring.

Xem thêm hướng dẫn chọn Industrial IoT Gateway. Trạng thái nhãn và vị trí trong vùng OT vẫn là hai quyết định khác nhau.

Gate 4: đóng khắc phục trước khi trao hợp đồng

“Sẽ bàn khi triển khai” trở thành rủi ro chi phí và tiến độ. Mỗi hạng mục cần owner, deliverable, hạn, cách retest và hậu quả nếu không giao. Nếu khó sửa sản phẩm, đánh giá compensating control có thời hạn và ngày xem xét lại.

Ví dụ gồm VLAN riêng, firewall allow-list, kết nối cloud chỉ outbound, jump host, truy cập bảo trì có thời hạn, giám sát ngoài và máy dự phòng. Không dùng mạng để che vĩnh viễn lỗ hổng nền tảng như không hỗ trợ security update, không có đầu mối lỗ hổng hoặc không đổi được mật khẩu dùng chung. Ghi residual-risk owner và ngày review.

Gate 5: nối FAT và SAT trong cùng hồ sơ nghiệm thu

FAT kiểm tra sản phẩm, cấu hình và tài liệu trước khi giao hoặc tại môi trường nhà cung cấp. SAT kiểm tra mạng thật, identity, time, monitoring và failure mode. DNS, NTP, proxy, certificate, VLAN và cloud access có thể làm thiết bị đã đạt FAT cư xử khác tại hiện trường.

Tối thiểu cần kiểm thử:

1. model, HW/FW, bản được gắn nhãn và backup khớp nhau;
2. đổi default credential, dùng named account, least privilege và MFA trong phạm vi yêu cầu;
3. lưu lượng cho phép hoạt động, lưu lượng cấm bị chặn;
4. xác minh tính xác thực/toàn vẹn update và khôi phục khi update lỗi;
5. time sync, event log, forwarding, retention và alert;
6. hành vi local an toàn khi cloud/WAN mất;
7. factory reset, restore và thay máy dự phòng;
8. remote access qua yêu cầu, duyệt, bật, hết hạn và ghi nhận;
9. diễn tập thông báo lỗ hổng và escalation khẩn cấp;
10. ký xác nhận open item, interim control, due date và phê duyệt cuối.

Lưu input, expected result, actual result, log, version, người thử và ngày. Kết quả đạt nhưng không tái hiện được sẽ không giúp audit hay xử lý sự cố.

Gate 6: theo dõi hết hạn và thay đổi sản phẩm

Hiệu lực ban đầu 2 năm của JC-STAR phải liên kết asset register, không nằm im trong hồ sơ mua hàng. Theo dõi gia hạn, firmware, EOL, vulnerability và cloud change. Bắt đầu review trước hạn theo lead time quy định để lấy bằng chứng mới, đánh giá phương án thay thế, tăng control hoặc lập kế hoạch tháo bỏ.

Theo dõi nhiều hơn nhãn:

• firmware đang cài và phiên bản được duyệt;
• vendor advisory, CVE và thông báo khẩn;
• trạng thái nhãn, model được bao phủ và điều kiện MRA;
• product/component change và end of support;
• cloud endpoint, certificate, API và điều kiện vị trí dữ liệu;
• thay đổi vùng, vị trí, ca sử dụng hoặc kết nối ngoài;
• thay đổi supplier, distributor hoặc OEM.

Định nghĩa trước thay đổi nào cần desk review, partial SAT, full reassessment hoặc ngắt kết nối ngay.

Ví dụ: đưa IoT gateway có nhãn vào nhà máy Thái Lan

Giả sử một dự án dùng gateway Singapore CLS Level 1 để giám sát thiết bị tại Thái Lan. Đây là ví dụ quy trình, không phải kết quả đánh giá sản phẩm thật. Gate 1 yêu cầu registry công khai, model/firmware/cloud được bao phủ và thời gian update. Hồ sơ không nêu mô-đun LTE tùy chọn, nên nhóm ghi cấu hình đó là “chưa xác minh”—không loại cả sản phẩm, cũng không cho qua chỉ vì thiết bị cơ sở có nhãn.

Gate 2 tách bằng chứng baseline của chương trình, traffic specification và yêu cầu remote access của nhà máy. Bằng chứng authentication/update không trả lời SIM management, mạng di động, cloud endpoint hoặc local escalation. Wildcard trong traffic sheet phải được tách thành FQDN, port, hướng và certificate check cần thiết. Gate 3 xác nhận gateway chỉ đọc trạng thái PLC, không gửi lệnh điều khiển. Tuy nhiên do thiết kế đầu dùng cùng switch, nghiệm thu có điều kiện gồm monitoring VLAN, firewall, OT-DMZ relay và jump host. PLC phải tiếp tục điều khiển khi cloud mất, và buffer gateway đầy không được ảnh hưởng control traffic.

Gate 4 đóng cấu hình gồm LTE, đầu mối update, phản hồi đầu tiên tại Thái và quy trình gia hạn certificate trước hợp đồng. FAT kiểm firmware, traffic, account, signed update và restore. SAT lặp lại trên DNS, NTP, VLAN, firewall, proxy và monitoring thực, gồm WAN loss, cloud outage, certificate error, restart và buffer limit. Gate 6 nối hiệu lực nhãn 2 năm, firmware, LTE, cloud API, certificate, SIM và hợp đồng nhà phân phối vào một asset ID. Gia hạn nhãn không tự động bao phủ build đã đổi, và nhãn còn hiệu lực không loại bỏ review khi cloud API thay đổi.

Thiết kế sổ bằng chứng theo sản phẩm, phiên bản, vị trí và quyết định

Thư mục PDF/email không mở rộng tốt khi có nhiều nhà máy. Sổ bằng chứng cần nối manufacturer/model/HW/FW, scheme/level/number/URL/expiry, factory/line/zone/use, traffic/identity, decision/exception/residual-risk owner, lifecycle notice và FAT/SAT. Dùng khóa product-build duy nhất và liên kết asset ID để truy từ bằng chứng nhãn đến thiết bị lắp thật, bài thử, ngoại lệ và cập nhật.

Mọi quyết định đều có thời điểm: lưu decision date, assessed version, next review và change trigger cùng nhau. Mua sắm quản lý phạm vi thương mại và điều khoản change/EOL; kỹ thuật quản lý chức năng/FAT; IT/OT security quản lý evidence, traffic và zone fit; bảo trì quản lý update/recovery/SAT; pháp chế/chất lượng quản lý warranty/record; asset owner chấp nhận residual risk. Một sổ chung tránh mỗi bộ phận tái tạo cùng bộ bằng chứng.

Lưu ý khi áp dụng tại nhà máy Thái Lan

Thỏa thuận Nhật Bản–Singapore trong bài không được trình bày như nghĩa vụ pháp lý của Thái Lan. Doanh nghiệp có thể bắt buộc nhãn theo chính sách mua sắm, hợp đồng khách hàng hoặc thị trường xuất khẩu, nhưng điều đó khác với nghĩa vụ theo luật Thái. Hãy kiểm tra riêng loại sản phẩm và quy định áp dụng, đồng thời dùng CLS/JC-STAR như một nguồn bằng chứng an ninh sản phẩm.

Ngôn ngữ vận hành cũng là một kiểm soát. Nếu bằng chứng bằng tiếng Anh/Nhật nhưng kỹ thuật viên địa phương không dùng được quy trình cô lập, cập nhật hoặc khôi phục, kiểm soát sẽ thất bại khi có sự cố. Cần bản địa hóa runbook, danh bạ khẩn cấp và diễn tập với người thực hiện. Khi dịch, giữ label, certification, conformity và factory acceptance là các khái niệm riêng.

Chuỗi thương mại cũng cần rõ: nhà sản xuất, chủ thương hiệu, người nộp nhãn, nhà nhập khẩu Nhật, nhà phân phối Thái, SIer địa phương và đơn vị cloud có thể là các pháp nhân khác nhau. Hợp đồng phải chỉ ra ai gửi advisory, ai phản hồi đầu tiên, ai giữ hàng thay thế và ai hỗ trợ khôi phục khi đổi nhà phân phối.

10 câu hỏi trong cuộc họp phê duyệt mua sắm

1. Nhãn thuộc chương trình/cấp nào và có xác minh công khai được không?
2. Model, HW/FW và cloud giao thực tế có khớp phạm vi nhãn không?
3. Yêu cầu nào tái sử dụng qua MRA và bằng chứng nào vẫn còn?
4. Khi nào hết hạn và ai sở hữu việc gia hạn?
5. Đầu mối lỗ hổng và thời gian update có bao phủ tuổi thọ thiết bị không?
6. Endpoint, port, identity, crypto, certificate và remote access có tài liệu không?
7. Có chấp nhận được tác động khi bị xâm nhập hoặc ngừng trong vùng OT đề xuất không?
8. Chi phí và công vận hành compensating control đã tính trong so sánh chưa?
9. Hợp đồng có định nghĩa FAT/SAT fail, khắc phục, retest và trách nhiệm tiến độ không?
10. Asset register có theo dõi expiry, vulnerability và change sau go-live không?

Mọi câu “sẽ kiểm tra sau lắp đặt” là bất định chi phí/tiến độ. Hãy đóng trước khi đặt hàng hoặc ghi conditional approval cùng ngân sách, hạn và risk owner.

Lỗi thường gặp và cách sửa

Chấp nhận ảnh nhãn nhưng không đối chiếu model/version

So sánh registry công khai, phạm vi nhãn, BOM giao và release note. Ghi model/version vật lý khi nhận hàng và vào asset register.

Mô tả MRA như chuyển đổi nhãn tự động

Dùng câu chính xác: thủ tục đơn giản hơn nhờ tái sử dụng kết quả cho yêu cầu tương đương. Giữ lại các bước nộp, bằng chứng, phí, review và cấp nhãn.

Cho rằng CLS Level 1 đã penetration test

Quay lại mô tả Level/Tier của CSA. Kiểm thử bởi phòng thử nghiệm thuộc Level/Tier 4. Nếu ca sử dụng cần thì đặt bài thử bổ sung với scope/version rõ.

Dùng nhãn thay phê duyệt kết nối nhà máy

Kiểm thử asset/zone fit, traffic, account, update, failure behavior và monitoring. Chủ nhà máy phải chấp nhận residual risk.

Để expiry và EOL trong thư mục mua hàng

Liên kết asset, contract, vulnerability và maintenance bằng product ID chung. Gửi alert tới role mailbox hoặc ticket, không phụ thuộc một cá nhân.

Dùng tài liệu trụ sở thay vận hành địa phương

Chuẩn bị quy trình bản địa, escalation, restore drill, spare và permission. Trụ sở quản lý scheme evidence, nhà máy quản lý operating evidence với điểm bàn giao rõ.

FAQ về công nhận lẫn nhau nhãn an ninh mạng

Có JC-STAR thì tự động nhận Singapore CLS không?

Không. MRA tái sử dụng kết quả cho yêu cầu tương đương và đơn giản hóa thủ tục; bên nộp vẫn phải dùng tuyến của chương trình kia và đáp ứng phần tài liệu/yêu cầu còn lại.

Phí JC-STAR STAR-1 cho sản phẩm có CLS là bao nhiêu?

IPA niêm yết 140.000 JPY gồm thuế, so với tiêu chuẩn 198.000 JPY gồm thuế. Đây là phí nộp đơn, không gồm chuẩn bị bằng chứng, kiểm thử nhà máy, mạng hoặc bản địa hóa.

Hiệu lực ban đầu của nhãn JC-STAR là bao lâu?

IPA nêu 2 năm. Ghi nhãn, bản được bao phủ và ngày hết hạn trong asset register; đánh giá lại khi có thay đổi quan trọng dù chưa hết hạn.

Singapore CLS Level 1 đã được penetration test chưa?

Không được mặc định như vậy. CSA đặt penetration testing bởi phòng thử nghiệm tại Level/Tier 4. Cần xác minh cấp và phạm vi thực tế.

JC-STAR hoặc CLS có bắt buộc theo luật cho nhà máy ở Thái Lan không?

Bài viết không khẳng định nghĩa vụ đó. Hãy kiểm tra riêng chính sách công ty, hợp đồng khách hàng, thị trường xuất khẩu, loại sản phẩm và luật áp dụng.

Gateway có nhãn có thể nối thẳng mạng sản xuất không?

Không. Phải đánh giá tài sản, traffic, quyền, update, tác động ngừng, monitoring và recovery; dùng OT DMZ hoặc control khác khi cần.

Kết luận: chuyển phần công sức tiết kiệm được sang rủi ro riêng của nhà máy

Công nhận lẫn nhau Cybersecurity Labelling Scheme giúp tái sử dụng công việc đánh giá giữa JC-STAR STAR-1 và Singapore CLS Level 1. Nó không phải tương đương toàn phần tự động, không phải quyền kết nối nhà máy và không phải nghĩa vụ pháp lý tại Thái Lan. Kết quả thực tế đến từ chuỗi bằng chứng: RFP, ánh xạ theo phiên bản, phù hợp asset/zone, khắc phục, FAT/SAT, rồi giám sát hết hạn/thay đổi. Hãy dùng thời gian tiết kiệm từ phần kiểm tra trùng lặp để xem xét uptime, safety, remote support và vận hành địa phương—những rủi ro mà nhãn không thể chấp nhận thay doanh nghiệp.

TOMAS TECH hỗ trợ mua sắm IoT cho nhà máy nước ngoài từ giai đoạn đầu: cấu trúc RFP, ánh xạ nhãn–bằng chứng, đánh giá phù hợp mạng OT và thiết kế hạng mục FAT/SAT. Khi doanh nghiệp vẫn đang tách yêu cầu nộp nhãn khỏi điều kiện nghiệm thu nhà máy, có thể trao đổi với chúng tôi qua trang liên hệ.

Nguồn sơ cấp

• IPA: thủ tục công nhận lẫn nhau
• METI: thỏa thuận Nhật Bản–Singapore
• CSA: thông cáo ngày 18/3/2026
• IPA: thông tin JC-STAR
• CSA: tổng quan CLS
• CSA: CLS cho nhà sản xuất
• ETSI EN 303 645 V3.1.3