← Về danh sách
Bảo mật & Quyền riêng tư
#CommonCriteria#ISO15408#보안평가인증#보호프로파일#EAL
Cập nhật lần cuối · 2026-09-15

Tiêu chí đánh giá chung (CC, Common Criteria / ISO/IEC 15408)

1. Tổng quan

A. Định nghĩa

Tiêu chí đánh giá chung (CC, Common Criteria for Information Technology Security Evaluation) là tiêu chuẩn quốc tế để một tổ chức độc lập bên thứ ba đánh giá và chứng nhận, theo thủ tục chuẩn hóa, chức năng bảo mật của sản phẩm·hệ thống bảo mật thông tin cùng mức đảm bảo (Assurance) rằng các chức năng đó được hiện thực·vận hành đúng đắn; CC gồm ISO/IEC 15408 (tiêu chí đánh giá) và phương pháp luận đánh giá tương ứng ISO/IEC 18045 (CEM).

Đặc điểm của CC là xử lý tách biệt "sản phẩm này cung cấp chức năng bảo mật gì" (tính năng) và "chức năng đó được xây dựng đáng tin cậy tới mức nào" (đảm bảo). Tức là, việc tường lửa chặn gói tin (chức năng) và việc logic chặn đó đã được chứng minh hoạt động không khiếm khuyết qua thiết kế·hiện thực·kiểm thử·phân tích lỗ hổng (đảm bảo) được đánh giá trên hai trục riêng biệt.

B. Bối cảnh ra đời và sự cần thiết

Trước CC, mỗi quốc gia·khu vực có các tiêu chí đánh giá bảo mật khác nhau tràn lan. TCSEC (Orange Book) của Mỹ, ITSEC của châu Âu và CTCPEC của Canada dùng hệ thống cấp độ và thuật ngữ khác nhau, nên muốn xuất khẩu một sản phẩm đã được chứng nhận ở nước này sang nước khác thì lần nào cũng phải đánh giá lại. Điều này gây chi phí trùng lặp cho nhà phát triển và sự bất khả so sánh cho tổ chức mua sắm. Khi đó chưa có một ngôn ngữ chung để so sánh khách quan độ tin cậy của sản phẩm bảo mật.

CC được xây dựng vào thập niên 1990 bằng cách hài hòa hóa (harmonization) nhiều tiêu chí nhằm giải quyết sự phân mảnh này, và được chuẩn hóa quốc tế thành ISO/IEC 15408 năm 1999. Động lực cốt lõi là công nhận lẫn nhau (Mutual Recognition) — "đánh giá một lần, được công nhận ở nhiều nước (Evaluate once, recognize everywhere)". Hậu thuẫn về mặt thể chế cho điều này là CCRA (CC Recognition Arrangement), theo đó các nước thành viên công nhận chứng chỉ của nhau trong phạm vi quy định.

Sự cần thiết có thể tóm tắt thành ba điểm. Thứ nhất là căn cứ tin cậy khách quan: có thể đánh giá tính bảo mật dựa trên kết quả kiểm chứng chuẩn hóa của tổ chức đánh giá độc lập chứ không phải lời tự khẳng định của nhà cung cấp. Thứ hai là đáp ứng yêu cầu mua sắm: tại Hàn Quốc, các cơ quan công về nguyên tắc yêu cầu chứng nhận CC (hoặc kiểm chứng tương đương) khi mua sản phẩm bảo mật thông tin, nên chứng nhận CC đóng vai trò cửa ngõ gia nhập thị trường. Thứ ba là khả năng so sánh: dù là các sản phẩm khác nhau, nếu được đánh giá theo cùng một PP (hồ sơ bảo vệ) thì có thể so sánh việc đáp ứng yêu cầu bảo mật trên cùng một thước đo.

C. Đặc điểm của CC

Đặc điểm thứ nhất của CC là tách biệt tính năng và đảm bảo. Khác với TCSEC vốn cứng nhắc vì gộp chức năng và đảm bảo theo từng cấp, CC xử lý "làm gì" (SFR) và "tin cậy được bao nhiêu" (SAR) như hai trục độc lập, cho phép cùng một chức năng chọn cường độ đảm bảo khác nhau tùy mức độ đe dọa. Nhờ sự tách biệt này, từ chứng nhận chi phí thấp cho môi trường ít đe dọa tới chứng nhận đảm bảo cao cho môi trường nhiều đe dọa đều được chứa trong một khung duy nhất.

Đặc điểm thứ hai là danh mục yêu cầu có thể tái sử dụng. SFR·SAR được chuẩn hóa theo lớp–họ–thành phần, nên khi soạn PP·ST chỉ cần tổ hợp·tinh chỉnh chúng, bảo đảm đồng thời khả năng biểu đạt và tính nhất quán của việc định nghĩa yêu cầu. Thứ ba là công nhận lẫn nhau quốc tế: thông qua CCRA, chứng nhận của một nước thành viên được nước thành viên khác công nhận trong phạm vi quy định, giảm chi phí đánh giá trùng lặp. Ba đặc điểm này kết hợp lại giúp CC trở thành ngôn ngữ chung về độ tin cậy của sản phẩm bảo mật thông tin.

2. Hệ thống cấu thành và khái niệm cốt lõi của CC

Mối quan hệ giữa hệ thống tài liệu của CC với đối tượng đánh giá·yêu cầu, thể hiện dưới dạng cấu trúc tổng thể, như sau.

flowchart TD
  subgraph STD["Hệ thống tài liệu CC (ISO/IEC 15408)"]
    P1["Part 1<br/>Tổng quan·mô hình chung·thuật ngữ"]
    P2["Part 2<br/>Danh mục yêu cầu chức năng bảo mật (SFR)"]
    P3["Part 3<br/>Yêu cầu đảm bảo (SAR)·thang EAL"]
  end
  P2 --> PP["Hồ sơ bảo vệ (PP)<br/>Yêu cầu bảo mật chung của nhóm sản phẩm"]
  P3 --> PP
  PP --> ST["Mục tiêu bảo mật (ST)<br/>Yêu cầu bảo mật của sản phẩm cụ thể"]
  P2 --> ST
  P3 --> ST
  ST --> TOE["Đối tượng đánh giá (TOE)<br/>Sản phẩm·firmware·tài liệu thực tế"]
  TOE --> EVAL["Đánh giá (CEM)·chứng nhận"]
  EVAL --> CERT["Chứng chỉ CC + báo cáo chứng nhận"]

Chìa khóa để hiểu CC là tài liệu hóa một cách tường minh đối tượng đánh giá và yêu cầu. Các khái niệm cốt lõi dưới đây ăn khớp với nhau để tạo thành một logic đánh giá duy nhất.

A. TOE (Target of Evaluation) là sản phẩm hoặc một phần sản phẩm là đối tượng đánh giá, bao gồm phần mềm·phần cứng·firmware và tài liệu hướng dẫn liên quan. Điều quan trọng là thiết lập ranh giới của TOE. Cùng một sản phẩm nhưng tùy việc đưa phạm vi nào vào đánh giá mà tuyên bố bảo mật và chi phí đánh giá khác nhau, nên định nghĩa TOE gắn trực tiếp với độ tin cậy của đánh giá. Các giả định về môi trường vận hành bên ngoài ranh giới (ví dụ bảo vệ vật lý, quản trị viên đáng tin cậy) được nêu riêng. Chẳng hạn, cùng một DBMS nhưng khi chỉ lấy engine kiểm soát truy cập làm TOE so với khi bao gồm cả console quản trị·log kiểm toán thì tuyên bố bảo mật và công sức đánh giá khác nhau rất nhiều, nên ranh giới TOE là hạng mục thiết kế cốt lõi mà nhà phát triển quyết định một cách chiến lược. Thu hẹp ranh giới thì đánh giá dễ hơn nhưng có rủi ro không bao quát phạm vi bảo mật mà tổ chức sử dụng kỳ vọng; mở rộng thì phạm vi tin cậy lớn hơn nhưng chi phí tăng.

B. SFR (Security Functional Requirements) là các yêu cầu quy định chức năng bảo mật mà TOE phải cung cấp, được lập danh mục trong CC Part 2 dưới dạng lớp·họ. Ví dụ có các lớp như định danh·xác thực (FIA), kiểm soát truy cập·kiểm soát luồng thông tin (FDP), kiểm toán (FAU), hỗ trợ mật mã (FCS), quản lý bảo mật (FMT), và nhà phát triển chọn·cụ thể hóa các mục cần cho sản phẩm của mình từ danh mục này. Vì tái sử dụng danh mục chuẩn nên bảo đảm được tính nhất quán và khả năng so sánh trong định nghĩa yêu cầu.

C. SAR (Security Assurance Requirements) và EAL xử lý câu hỏi "chức năng có được xây dựng đúng không". Các lớp đảm bảo của Part 3 gồm phát triển (ADV), tài liệu hướng dẫn (AGD), hỗ trợ vòng đời (ALC), kiểm thử (ATE), đánh giá lỗ hổng (AVA), v.v., và các gói định nghĩa sẵn gộp chúng theo một cường độ nhất định là EAL (Evaluation Assurance Level) 1~7. EAL càng cao thì tính hình thức của biểu diễn thiết kế, phạm vi kiểm thử và độ sâu phân tích lỗ hổng càng tăng. Cần lưu ý rằng đảm bảo không có nghĩa là "nhiều chức năng" mà là "kiểm chứng nghiêm ngặt".

D. PP và ST là hai vật chứa yêu cầu. PP (Protection Profile) là tập yêu cầu bảo mật độc lập với hiện thực mà một nhóm sản phẩm cụ thể (ví dụ tường lửa, thẻ thông minh, DBMS) phải cùng đáp ứng — là đường cơ sở mà tổ chức sử dụng·chính phủ quy định "sản phẩm loại này ít nhất phải có chừng này". ST (Security Target) là bản đặc tả hướng hiện thực nêu rõ một sản phẩm cụ thể thực sự đáp ứng gì và như thế nào, thường tuyên bố tuân thủ (claim) một hoặc nhiều PP. Nếu PP là 'đặc tả kỹ thuật chuẩn' thì ST tương ứng với 'bản đề xuất của sản phẩm đó'.

Khái niệm Ý nghĩa Tính chất
TOE Sản phẩm·tài liệu là đối tượng đánh giá Định nghĩa phạm vi (ranh giới) đánh giá
SFR Yêu cầu chức năng bảo mật (Part 2) Làm gì (chức năng)
SAR / EAL Yêu cầu đảm bảo (Part 3) Tin cậy được bao nhiêu (đảm bảo)
PP Yêu cầu chung của nhóm sản phẩm Độc lập hiện thực·đường cơ sở
ST Đặc tả bảo mật của sản phẩm cụ thể Hướng hiện thực·tuyên bố tuân thủ PP

Quan hệ giữa các khái niệm này được tóm tắt trong một câu. Khi chính phủ·tổ chức có nhu cầu định nghĩa đường cơ sở bằng PP, nhà phát triển dùng ST để nêu rõ TOE của mình đáp ứng các SFR của PP đó theo cách nào, và tổ chức đánh giá kiểm chứng tuyên bố đó có đúng sự thật không theo SAR/EAL. Tức là cấu trúc tam giác — PP là nguồn gốc yêu cầu, ST là lời hứa của sản phẩm, EAL là cường độ kiểm chứng — là bộ khung của CC. Nhờ cấu trúc này, sản phẩm của các nhà phát triển khác nhau, nếu tuân theo cùng một PP, có thể được so sánh·mua sắm trên cùng thước đo.

3. Quy trình đánh giá·chứng nhận

Chứng nhận CC được tiến hành theo cấu trúc ba bên nhà phát triển (bên nộp đơn)–tổ chức đánh giá–tổ chức chứng nhận. Tại Hàn Quốc, vai trò tổ chức chứng nhận do Văn phòng Chứng nhận Bảo mật CNTT (KECS) trực thuộc Cơ quan Tình báo Quốc gia đảm nhiệm, còn việc đánh giá thực tế do các tổ chức đánh giá được chỉ định thực hiện theo phương pháp luận CEM (ISO/IEC 18045).

sequenceDiagram
  participant D as Nhà phát triển·bên nộp đơn
  participant L as Tổ chức đánh giá
  participant C as Tổ chức chứng nhận KECS
  D->>D: Chọn PP·soạn ST·chuẩn bị tài liệu chứng cứ
  D->>L: Nộp đơn đánh giá và nộp TOE
  L->>L: Đánh giá dựa trên CEM ADV·AGD·ALC·ATE·AVA
  L-->>D: Báo cáo khiếm khuyết·yêu cầu bổ sung
  D->>L: Nộp lại sản phẩm đã bổ sung
  L->>C: Nộp báo cáo kết quả đánh giá ETR
  C->>C: Thẩm định chứng nhận·kiểm chứng chất lượng
  C-->>D: Cấp chứng chỉ CC và báo cáo chứng nhận

Quy trình có thể hiểu theo luồng chuẩn bị–đánh giá–chứng nhận. Ở giai đoạn chuẩn bị, nhà phát triển chọn PP mục tiêu, soạn ST và chuẩn bị tài liệu chứng cứ về thiết kế·kiểm thử·quản lý cấu hình phù hợp với cấp đảm bảo yêu cầu. Khi đó EAL càng cao thì tính hình thức và khối lượng tài liệu yêu cầu tăng vọt, nên phải quyết định thận trọng cấp mục tiêu có tính đến yêu cầu kinh doanh và chi phí.

Ở giai đoạn đánh giá, tổ chức đánh giá kiểm tra sản phẩm bàn giao theo các hoạt động chi tiết (work unit) của CEM. Ví dụ, xác nhận qua ADV biểu diễn thiết kế·hiện thực có tinh chỉnh đầy đủ SFR không, qua ATE kiểm thử chức năng có bao phủ đủ phạm vi không, qua AVA có phân tích các lỗ hổng đã biết·tiềm ẩn từ góc độ kiểm thử xâm nhập không. Khi phát hiện khiếm khuyết, tổ chức đánh giá yêu cầu nhà phát triển bổ sung, và vòng lặp khiếm khuyết–bổ sung này là yếu tố then chốt quyết định thời gian đánh giá.

Ở giai đoạn chứng nhận, tổ chức đánh giá nộp báo cáo kết quả đánh giá (ETR) cho tổ chức chứng nhận, và tổ chức chứng nhận thẩm định độc lập tính thích đáng và nhất quán của việc đánh giá. Khi qua thẩm định, chứng chỉ CC được cấp cùng báo cáo chứng nhận chứa phạm vi·tiền đề·kết quả đánh giá. Tổ chức sử dụng nhất định phải kiểm tra ranh giới TOE và giả định môi trường vận hành trong báo cáo chứng nhận này, vì chứng nhận chỉ có hiệu lực "dưới các giả định môi trường đã nêu".

Giai đoạn Chủ thể Hoạt động chính Sản phẩm đầu ra
Chuẩn bị Nhà phát triển Chọn PP, soạn ST, chuẩn bị chứng cứ ST, chứng cứ thiết kế·kiểm thử
Đánh giá Tổ chức đánh giá Thực hiện hoạt động CEM, chỉ ra khiếm khuyết Báo cáo khiếm khuyết, kết quả kiểm thử
Chứng nhận Tổ chức chứng nhận (KECS) Thẩm định tính thích đáng của đánh giá Chứng chỉ, báo cáo chứng nhận

Mặt khác, bản thân tài liệu yêu cầu cũng là đối tượng đánh giá. PP được kiểm chứng trước về tính đầy đủ·nhất quán·luận cứ (rationale) qua lớp APE (Protection Profile Evaluation), còn ST qua lớp ASE (Security Target Evaluation). Lý do là nếu đánh giá sản phẩm trên các yêu cầu bị định nghĩa sai thì toàn bộ kết quả trở nên vô nghĩa; đây là việc thể chế hóa logic hai bước "kiểm chứng tính hợp lý của yêu cầu → kiểm chứng sản phẩm đáp ứng yêu cầu". Vì vậy ở đầu quá trình đánh giá, một nỗ lực đáng kể được dành cho việc bảo đảm tính nhất quán ST·PP, và sự yếu kém ở đây là nguyên nhân phổ biến gây chậm trễ đánh giá về sau.

4. So sánh các cấp EAL và trường hợp áp dụng

EAL 17 là thang đo tăng dần cường độ đảm bảo. Cấp thấp chủ yếu xem xét tài liệu·kiểm thử chức năng, càng lên cấp cao càng đòi hỏi biểu diễn thiết kế bán hình thức·hình thức (semiformal·formal) và phân tích lỗ hổng sâu. Điều cần lưu ý ở đây là trên thực tế, phạm vi mà công nhận lẫn nhau quốc tế vận hành hiệu quả thường giới hạn ở mức EAL 2 (hoặc dựa trên PP cộng tác). Đánh giá đảm bảo cao EAL 57 có chi phí·thời gian rất lớn và nằm ngoài phạm vi công nhận lẫn nhau, nên chỉ được dùng hạn chế cho các lĩnh vực rủi ro cao đặc thù như thẻ thông minh, quốc phòng.

Cấp Khái niệm đảm bảo Bối cảnh áp dụng tiêu biểu
EAL1 Kiểm thử chức năng Đe dọa thấp, đảm bảo tối thiểu
EAL2 Kiểm thử cấu trúc Sản phẩm thương mại·phạm vi công nhận lẫn nhau hiệu quả
EAL3 Kiểm thử·kiểm tra có phương pháp Thiết bị bảo mật thương mại thông thường
EAL4 Thiết kế·kiểm thử·rà soát có phương pháp Cấp cao nhất cho thương mại (tường lửa·DBMS, v.v.)
EAL5~7 Kiểm chứng bán hình thức·hình thức Rủi ro cao như thẻ thông minh·quốc phòng

Vị thế của CC càng rõ khi so sánh với các tiêu chí đánh giá trước đó. TCSEC (Orange Book) theo góc nhìn quân sự lấy tính bí mật làm trung tâm, gộp chức năng và đảm bảo vào một trục duy nhất D~A1 nên kém linh hoạt và khó chứa đựng các mục tiêu bảo mật đa dạng của sản phẩm thương mại. ITSEC là hệ thống tiến bộ hơn khi tách tính năng (F) và đảm bảo (E), nhưng chỉ dừng ở chuẩn khu vực châu Âu nên tính thông dụng quốc tế hạn chế. CC lấy ưu điểm của cả hai (tách chức năng·đảm bảo) và kết hợp chuẩn hóa quốc tế·công nhận lẫn nhau, mở rộng thành tiêu chí đa dụng bao trùm thương mại·công·quốc phòng. Lý do căn bản của sự khác biệt là đối tượng đánh giá đã chuyển từ các hệ thống chính phủ khép kín sang thị trường sản phẩm thương mại toàn cầu, và sự thay đổi này đã sinh ra nhu cầu về "tiêu chí đa dụng có thể so sánh và được công nhận lẫn nhau".

Tiêu chí Chức năng·đảm bảo Phạm vi thông dụng Hạn chế
TCSEC (Orange Book) Gộp chung (D~A1) Mỹ·quân sự Cứng nhắc, thiên về bí mật
ITSEC Tách biệt (F/E) Châu Âu Thiếu tính thông dụng quốc tế
CC (ISO/IEC 15408) Tách biệt (SFR/SAR) Quốc tế (CCRA) Tin cậy có điều kiện·chi phí

Về trường hợp cụ thể, các sản phẩm tường lửa·hệ thống ngăn chặn xâm nhập (IPS)·kiểm soát truy cập DBMS cung cấp cho khu vực công Hàn Quốc thường đạt chứng nhận CC dùng trong nước ở mức EAL theo PP của nhóm sản phẩm tương ứng để đáp ứng yêu cầu mua sắm. Ngược lại, các sản phẩm như thẻ IC tài chính·chip hộ chiếu điện tử có mối đe dọa vật lý·kênh kề (side-channel) lớn nên thường được yêu cầu đánh giá đảm bảo cao từ EAL 5 trở lên. Như vậy, việc chọn cấp phụ thuộc vào môi trường đe dọa và giá trị tài sản nơi sản phẩm được đặt, và nguyên tắc là chọn mức đảm bảo thích đáng tương xứng với mối đe dọa chứ không phải cấp càng cao càng tốt.

Vì chọn cấp gắn trực tiếp với chi phí·thời gian nên góc độ kinh tế cũng quan trọng. Thông thường mỗi khi EAL tăng một bậc, tính hình thức của sản phẩm bàn giao và phạm vi kiểm thử·phân tích lỗ hổng mở rộng, khiến thời gian và chi phí đánh giá tăng rõ rệt, đặc biệt từ EAL5 trở lên khi yêu cầu biểu diễn thiết kế bán hình thức thì gánh nặng tăng vọt. Do đó thông lệ thực tế là phần lớn sản phẩm thương mại chọn khoảng EAL24 ở điểm cân bằng giữa công nhận lẫn nhau và chi phí, còn EAL57 chỉ giới hạn cho số ít sản phẩm rủi ro cao gắn trực tiếp với tính mạng·an ninh quốc gia. Điều này cho thấy hợp lý là chọn "cấp tối thiểu đủ dùng tương xứng với đe dọa và tài sản" chứ không phải "cấp cao nhất có thể".

Ngoài ra cần hiểu qua trường hợp thực tế rằng CC không bảo đảm an toàn tuyệt đối. Chứng nhận là sự tin cậy có điều kiện: "dưới ranh giới TOE và giả định môi trường vận hành đã định nghĩa, các SFR đã nêu được kiểm chứng ở mức EAL". Do đó các lỗ hổng mới phát hiện sau chứng nhận, cấu hình sai, sự cố do thành phần ngoài ranh giới đều nằm ngoài phạm vi chứng nhận. Chỉ nhìn chứng chỉ mà khẳng định "an toàn" là hiểu lầm phổ biến, nhất định phải xem xét cùng tiền đề·phạm vi của báo cáo chứng nhận.

5. Nâng cao — Xu hướng mới và sửa đổi tiêu chuẩn (CC:2022 / ISO/IEC 15408:2022)

Trong thời gian dài, CC v3.1 được dùng như tiêu chuẩn trên thực tế, nhưng năm 2022 CC:2022 (Release 5) được công bố cùng các bản sửa đổi tương ứng ISO/IEC 15408:2022 và ISO/IEC 18045:2022, qua đó hệ thống được mở rộng. Cốt lõi của lần sửa đổi là vượt qua cấu trúc các phần hiện có để đưa đặc tả phương pháp·hoạt động đánh giá (Part 4) và các gói định nghĩa sẵn (Part 5) vào tiêu chuẩn, nâng cao khả năng tái sử dụng·tính nhất quán của việc định nghĩa yêu cầu và thực hiện đánh giá. Các chương trình chứng nhận mới đang dần chuyển sang dựa trên CC:2022, nên nhà phát triển·tổ chức sử dụng cần xác nhận phiên bản tuân thủ và chuẩn bị chuyển đổi.

Xu hướng lớn về phương pháp luận là cPP (collaborative Protection Profile) và thoát khỏi EAL. Kể từ lần sửa đổi năm 2014, CCRA đã thu hẹp công nhận lẫn nhau toàn diện đối với EAL cao, và chuyển sang lấy việc tuân thủ hồ sơ bảo vệ cộng tác (cPP) — do các cộng đồng kỹ thuật quốc tế (iTC) thống nhất cho từng nhóm sản phẩm cụ thể — làm trục công nhận lẫn nhau. Điều này phản ánh nhận thức rằng "yêu cầu chính xác phù hợp với mối đe dọa thực chất của từng nhóm sản phẩm (cPP)" phù hợp với độ tin cậy thực tế hơn "cấp đảm bảo chung chung (EAL)". Kết quả là các đánh giá gần đây ngày càng hay được biểu thị bằng việc tuân thủ một cPP cụ thể thay vì nhãn EAL.

Xu hướng này có nghĩa là căn cứ của sự tin cậy đang dịch chuyển từ "công nhận lẫn nhau các nhãn cấp chung" sang "cùng định nghĩa quốc tế các yêu cầu chính xác theo nhóm sản phẩm". Tuy nhiên, các nhóm sản phẩm mới nổi chưa có cPP vẫn phụ thuộc vào đánh giá dựa trên PP·ST riêng lẻ, nên EAL và cPP được dự báo sẽ cùng tồn tại trong một thời gian.

Về xu hướng tại Hàn Quốc, chế độ xác nhận nhanh sản phẩm bảo mật thông tin, được đưa vào để bù đắp thực tế không phải nhóm sản phẩm nào cũng có PP, đang bổ trợ cho chứng nhận CC. Mục đích là giảm bớt vấn đề các sản phẩm công nghệ mới·hội tụ chưa có PP để đánh giá bị chậm gia nhập thị trường công vì phải chờ chứng nhận CC. Tuy nhiên xác nhận nhanh không phải là sự thay thế hoàn toàn CC mà là con đường bổ trợ·có thời hạn, nên về lâu dài nên chỉnh đốn PP cho nhóm sản phẩm đó và đưa vào CC. Bên cạnh đó, chuyển đổi sang mật mã kháng lượng tử (PQC), định nghĩa ranh giới TOE cho sản phẩm dạng đám mây·container, xây dựng phương pháp luận đánh giá cho sản phẩm tích hợp AI, v.v. đang nổi lên như những thách thức mà hệ thống CC cần giải quyết trong thời gian tới.

6. Các lưu ý và hàm ý

  • Chọn mức đảm bảo thích đáng (tương xứng với đe dọa): việc chọn EAL·cPP phải tỷ lệ với giá trị tài sản và mức độ đe dọa. Cấp quá cao làm tăng không cần thiết chi phí·thời gian, cấp quá thấp thì thiếu đảm bảo thực chất. Kỹ sư chuyên nghiệp phải có khả năng khuyến nghị cấp/PP tối ưu trên cơ sở xem xét đồng thời yêu cầu mua sắm và mô hình đe dọa.
  • Kiểm chứng ranh giới TOE và giả định môi trường vận hành: chứng nhận là sự tin cậy có điều kiện, nên khi áp dụng phải kiểm tra phạm vi TOE·tiền đề (quản trị viên đáng tin cậy, bảo vệ vật lý, v.v.) trong báo cáo chứng nhận có khớp với môi trường vận hành thực tế không. Thành phần ngoài ranh giới·cấu hình sai không được chứng nhận bảo đảm.
  • Chiến lược phiên bản·công nhận lẫn nhau (CC:2022·CCRA): nếu kinh doanh quốc tế, cần chiến lược chứng nhận có tính đến phạm vi công nhận lẫn nhau (thường là EAL2 hoặc tuân thủ cPP) và phiên bản tuân thủ (chuyển sang CC:2022). Lập kế hoạch phân biệt mục đích và nơi sử dụng của chứng nhận trong nước và chứng nhận quốc tế.
  • Tính liên tục vòng đời (ALC·duy trì đảm bảo): chứng nhận áp dụng cho một thời điểm·cấu hình cụ thể, nên khi vá lỗi·bổ sung chức năng thì đảm bảo có thể bị tổn hại. Cần liên kết quản lý cấu hình (ALC) với thủ tục duy trì chứng nhận·đánh giá lại để bảo đảm đảm bảo bền vững.
  • Tích hợp với công nghệ·chế độ liên quan: CC bổ trợ lẫn nhau với ISMS-P, lập trình an toàn (secure coding), SBOM·bảo mật chuỗi cung ứng, kiểm chứng mô-đun mật mã (KCMVP/FIPS). Khi kết hợp theo tầng chứng nhận sản phẩm (CC)–chứng nhận vận hành (ISMS-P)–kiểm chứng mật mã thì hệ thống đảm bảo thực chất mới hoàn chỉnh.
  • Cân bằng giữa tồn đọng đánh giá và tiếp nhận công nghệ mới: thiếu PP để đánh giá·thời gian đánh giá kéo dài làm chậm việc các sản phẩm công nghệ mới gia nhập khu vực công. Cần tận dụng các con đường bổ trợ như chế độ xác nhận nhanh, đồng thời trung và dài hạn song song chỉnh đốn PP theo nhóm sản phẩm và xây dựng ranh giới TOE·phương pháp luận đánh giá phù hợp với sản phẩm đám mây·AI, để bảo đảm cùng lúc tính nghiêm ngặt của đảm bảo và tính kịp thời với thị trường.

Tài liệu tham khảo


Tóm tắt một câu: Tiêu chí đánh giá chung (CC, ISO/IEC 15408) là tiêu chuẩn quốc tế để bên thứ ba đánh giá·chứng nhận chức năng bảo mật (SFR) và mức đảm bảo (SAR/EAL) của sản phẩm bảo mật thông tin theo thủ tục chuẩn, lấy các khái niệm PP·ST·TOE và quy trình đánh giá·chứng nhận ba bên làm trục, và đang tiến hóa qua công nhận lẫn nhau CCRA·chuyển dịch sang cPP cùng lần sửa đổi CC:2022.