4.4 第四級：結構化保護級

1.4　第四級：結構化保護級

1.4.1　安全功能

1.4.1.1　身份鑒別

身份鑒別包括對用戶的身份進行標識和鑒別。應從以下方面設計和實現SSOOS的身份鑒別功能：

a) 按以下要求設計和實現用戶標識功能：

1) 用戶進入操作系統前，先進行標識（建立賬號）；

2) 操作系統用戶標識使用用戶名和用戶標識（UID），并在操作系統的整個生存周期實現用戶的唯一性標識，以及用戶名或別名、UID等之間的一致性。

b) 按以下要求設計和實現用戶鑒別功能：

1) 采用強化口令管理和/**或生物特征鑒別和/**或數字證書等相結合的方式，采用多鑒別機制，實現對用戶身份的真實性鑒別，并在每次用戶登錄系統時和系統重新連接時進行鑒別；

2) 鑒別信息是不可見的，在存儲和傳輸時使用加密方法進行安全保護，確保其不被非授權的訪問、修改和刪除。

c) 通過對不成功的鑒別嘗試的值（包括嘗試次數和時間的閾值）進行預先定義，并明確規定達到該值時采取的措施來實現鑒別失敗的處理；

d) 對注冊到操作系統的用戶，將用戶進程與所有者用戶相關聯，使用戶進程的行為可以追溯到進程的所有者用戶。

1.4.1.2　自主訪問控制

應從以下方面設計和實現SSOOS的自主訪問控制功能：

a) 客體的擁有者能對其擁有的客體定義其他用戶的訪問控制屬性，訪問控制屬性至少包括：讀、寫、執行等；

b) 主體對客體的訪問遵循該客體的自主訪問控制權限屬性；

c) 客體的擁有者能對其擁有的客體設置為：擁有者是唯一有權修改其訪問權限的主體；

d) 不允許客體擁有者把客體的控制權分配給其他主體；

e) 當主體生成一個客體時，該客體具有該主體設置的自主訪問控制權限屬性的默認值；

f) 有更細粒度的自主訪問控制，將訪問控制主體的粒度控制在單個用戶，將訪問控制客體的粒度控制在文件和目錄；

g) 自主訪問控制能與身份鑒別和審計相結合，通過確認用戶身份的真實性和記錄用戶的各種成功的或不成功的訪問，使用戶對自己的行為承擔明確的責任。

1.4.1.3　標記和強制訪問控制

應從以下方面設計和實現SSOOS的標記和強制訪問控制功能：

a) 采用標記的方法為操作系統所有主體和客體（至少包括系統所有進程、文件、目錄等）標明其安全屬性；

b) 客體的標記隨客體數據一起流動，當信息從操作系統控制范圍之內向控制范圍之外輸出時，帶有安全標記，當信息從操作系統控制范圍之外向控制范圍之內輸入時，通過標記標明其安全屬性。**如打印輸出的數據，需明顯標示出該數據的安全標記**；

c) 主體和客體的安全屬性標記構成了機密性和完整性安全策略模型，這些安全策略模型具有相應的半形式化證明。強制訪問控制基于這些標記和安全策略模型，實現主體對客體讀、寫和執行等操作的訪問控制；

d) 強制訪問控制與用戶身份鑒別、標記等安全功能密切配合，使系統對用戶的安全控制包含從系統啟動到退出系統的全過程，強制訪問控制對客體的控制范圍涉及操作系統內部的存儲、處理和傳輸過程，及信息進行輸入、輸出操作的過程；

e) 由專門設置的系統安全員統一管理操作系統中與強制訪問控制等安全機制有關的事件和信息，并將系統的常規管理、與安全有關的管理以及審計管理，分別由系統管理員、系統安全員和系統審計員來承擔，按職能分割和最小授權原則分別授予它們各自為完成自己所承擔任務所需的最小權限，并形成相互制約關系；

f) 運行于網絡環境的多臺計算機系統上的網絡操作系統，在需要進行統一管理時，考慮各臺計算機操作系統的主、客體安全屬性設置的一致性，并實現跨網絡的SSOOS間用戶數據保密性和完整性保護。

1.4.1.4　安全審計

應從以下方面設計和實現SSOOS的安全審計功能：

a) 能對以下事件生成審計日志：

1) 身份鑒別、自主訪問控制、標記和強制訪問控制等安全功能的使用；

2) 創建、刪除客體的操作；

3) 網絡會話；

4) 所有管理員的操作。

b) 在每個審計記錄中至少記錄下列信息：

1) 事件類型、事件發生的日期和時間、觸發事件的用戶、事件成功或失敗等字段；

2) 身份標識和鑒別事件類審計日志還包括請求的源（如末端號或網絡地址）；

3) 創建和刪除客體的事件審計日志還包括客體的名字、客體的安全屬性；

4) 網絡會話事件還包括：網絡程序名稱、協議類型、源IP地址、目的IP地址、源端口、目的端口、會話總字節數等字段。

c) 提供以下審計日志分析功能：

1) 潛在侵害分析：設置審計日志累積或組合的規則，使用這些規則去監測已經生成的審計事件，并根據這些規則指示出對實施安全功能要求的潛在侵害；

2) 基于模板的異常檢測：根據用戶的歷史使用模式建立模板，用置疑等級表示用戶當前活動與模板中已建立的使用模式不一致的程度，當用戶的置疑等級超過門限條件時，能指出對安全功能要求實施的可能侵害即將發生；

3) **簡單攻擊探測：當發現一個系統事件與一個預示可能潛在違反安全功能要求實施的特征事件匹配時，能指出潛在違反安全功能要求實施的事件即將發生。**

d) 當檢測到潛在的安全侵害時，生成實時報警，并終止違例進程；

e) 提供審計日志的可選擇查詢功能，支持按以下條件之一或邏輯組合進行選擇和排序查閱，并能導出查詢結果：

1) 事件類型；

2) 日期和/或時間；

3) 用戶身份；

4) 客體名稱；

5) 成功或失敗。

f) 提供審計日志的保護功能，主要包括：

1) 保證審計機制默認處于開啟狀態，且對審計日志的開啟和關閉進行保護；

2) 保護審計日志不被未授權的訪問；

3) 保證審計日志不被篡改和刪除，并記錄嘗試篡改和刪除審計日志的行為。

g) 以便于用戶理解的方式提供審計日志查閱；

h) 審計日志存儲在掉電非遺失性存儲介質中。系統管理員能夠定義超過審計跟蹤存儲極限的閾值，當超過閾值時將向管理員報警。當審計存儲空間被耗盡時，覆蓋所存儲的最早的審計記錄。

1.4.1.5　數據完整性

應從以下方面設計和實現SSOOS的數據完整性保護功能：

a) 提供一個實用程序來校驗文件系統和磁盤的完整性。此實用程序由操作系統自動執行；

b) 在對數據進行訪問操作時進行完整性檢測和恢復，檢查存儲在存儲介質上的用戶數據是否出現完整性錯誤，并在檢測到完整性錯誤時進行恢復；

c) 在操作系統內部進行的數據傳輸，如進程間的通信，提供保證數據完整性的功能。

1.4.1.6　數據保密性

1.4.1.6.1　客體重用

應對存儲介質（至少包括：磁盤和內存等）從以下方面設計和實現SSOOS的客體重用功能：

a) 確保非授權用戶不能查找使用后返還系統的記錄介質中的信息內容；

b) 確保非授權用戶不能查找系統現已分配給他的記錄介質中以前的信息內容。

1.4.1.6.2　數據加密

應從以下方面設計和實現SSOOS的數據加密功能：

a) 提供文件加密功能，用戶可對指定的文件和目錄進行加密保護；

b) 提供文件系統加密功能，對存儲在文件系統加密中的文件和目錄，進行透明加解密；

c) **對密鑰提供基于硬件信任根的可信存儲支持。**

1.4.1.7　可信路徑

在本地用戶和遠程用戶進行初始登錄和/或鑒別時，SSOOS應在它與用戶之間建立一條安全的通信路徑。此路徑對其端點進行了可信標識，并能保護通信數據免遭修改、泄露。

1.4.1.8　可信信道

應在SSOOS和另一個可信IT產品之間提供一條通信信道，此信道在邏輯上與其他通信信道截然不同，并對其端點進行了可信標識，并能保護信道中數據免遭修改或泄露。

1.4.1.9　網絡安全保護

應從以下方面設計和實現SSOOS的網絡安全保護：

a) 支持基于IP地址、端口、物理接口和應用程序的雙向網絡訪問控制，將不符合預先設定策略的數據包丟棄；

b) 支持基于系統身份、系統運行狀態雙向網絡可信接入認證；

c) 對網絡訪問進行控制，只有被授權的且通過可信度量的進程才能訪問網絡；

d) 對網絡傳輸數據進行加密與完整性保護。

1.4.2　操作系統安全子系統自身安全保護

1.4.2.1　運行安全保護

應從以下方面實現SSF運行安全保護：

a) 提供設置和升級配置參數的安裝機制。在初始化和對與安全有關的數據結構進行保護之前，對用戶和管理員的安全策略屬性進行定義；

b) 區分普通操作模式和系統維護模式；

c) 只允許系統管理員進入維護模式。在普通用戶訪問系統之前，系統以一個安全的方式進行安裝和配置；

d) 對備份或不影響SSOOS的常規的系統維護，不要求所有的系統維護都在維護模式中執行；

e) 當操作系統安裝完成后，在普通用戶訪問之前，系統配置好初始用戶和管理員職責、根目錄、審計參數、系統審計跟蹤設置以及對文件和目錄的合適的訪問控制；

f) 只允許系統管理員修改或替換系統提供的實用程序；

g) 為操作系統安全管理人員提供一種機制，來產生安全參數值的詳細報告；

h) 在SSOOS失敗或中斷后，確保其以最小的損害得到恢復。并按失敗保護中所描述的內容，實現對SSF出現失敗時的處理。系統因故障或其它原因中斷后，有一種機制去恢復系統。系統提供在管理維護狀態中運行的能力，管理維護狀態只能被系統管理員使用，各種安全功能全部失效；

i) 控制和審計系統控制臺的使用情況；

j) 補丁的發布、管理和使用：操作系統的開發者針對發現的漏洞及時發布補丁。操作系統的管理者及時獲取、統一管理并及時運用補丁對操作系統的漏洞進行修補。

1.4.2.2　資源利用

1.4.2.2.1　容錯

應從以下方面實現SSOOS的容錯功能：

a) 通過一定措施確保當系統出現某些確定的故障情況時，SSF也能維持正常運行，如系統檢測和報告系統的服務水平已降低到預先規定的最小值；

b) 當系統資源的服務水平降低到預先規定的最小值時，能檢測和發出報告；

c) 提供維護狀態中運行的能力，在維護狀態下各種安全功能全部失效，系統只允許由系統管理員使用；

d) 系統提供軟件及數據備份和復原的過程，在系統中加入再啟動的同步點，以便于系統的復原；

e) 系統提供能用于定期確認系統正確操作的機制和過程，這些機制或過程涉及系統資源的監視、硬件和固件單元的正確操作、對可能在全系統內傳播的錯誤狀態的檢測以及超過用戶規定的門限的通訊差錯的檢測等內容。

1.4.2.2.2　服務優先級

應從以下方面實現SSOOS的服務優先級功能：

a) 采取適當的策略，設置主體使用SSF控制范圍內某個資源子集的優先級，進行SSOOS資源的管理和分配；

b) 確保對所有SSOOS資源的每次訪問都基于主體所配得的優先級進行協調。

1.4.2.2.3　資源分配

應從以下方面實現SSOOS的資源分配功能：

a) 按GB/T 20271—2006資源分配中最大限額的要求，進行SSOOS資源的管理和分配。配額機制確保用戶和主體將不會獨占某種受控的資源；

b) 確保在被授權的主體發出請求時，資源能被訪問和利用；

c) 以每個用戶或每個用戶組為基礎，提供一種機制，控制他們對磁盤的消耗和對CPU等資源的使用；

d) 提供用戶查看其可訪問的系統資源的修改歷史記錄的權限。

1.4.2.3　用戶登錄訪問控制

應從以下方面實現SSOOS的用戶登錄訪問控制：

a) 按GB/T 20271—2006中會話建立機制的要求，對會話建立的管理進行設計。登錄機制不允許鑒別機制本身被旁路；

b) 按GB/T 20271—2006中多重并發會話限定中基本限定的要求，進行會話管理的設計。在基于基本標識的基礎上，SSF限制系統的并發會話的最大數量，并利用默認值作為會話次數的限定數；

c) 按GB/T 20271—2006中可選屬性范圍限定的要求，選擇某種會話安全屬性的所有失敗的嘗試 ，對用來建立會話的安全屬性的范圍進行限制；

d) 成功登錄系統后，SSOOS記錄并向用戶顯示以下數據：

1) 日期、時間、來源和上次成功登錄系統的情況；

2) 上次成功訪問系統以來身份鑒別失敗的情況；

3) 顯示口令到期的天數；

4) 成功或不成功的事件次數的顯示可以用整數計數、時間戳列表等表述方法。

e) 在規定的未使用時限后，系統斷開會話或重新鑒別用戶。系統提供時限的默認值；

f) 系統提供鎖定用戶鍵盤的機制，鍵盤開鎖過程要求驗證用戶；

g) 當用戶鑒別過程不正確的次數達到系統規定的次數時，系統退出登錄過程并終止與用戶的交互；

h) 系統提供一種機制，能按時間、進入方式、地點、網絡地址或端口等條件規定哪些用戶能進入系統。

1.4.2.4　可信度量

應從以下方面實現SSOOS的可信度量：

a) 支持硬件可信芯片作為信任根；

b) 在操作系統啟動時進行完整性度量，確保操作系統內核的真實性和完整性；

c) 對可執行程序在啟動時進行完整性度量，確保可執行程序的真實性和完整性；

d) 對完整性度量基準值進行可信存儲，防止其被篡改，確保完整性度量基準值的自身完整性。

1.4.2.5　可信恢復

當系統失效或服務中斷時，應確保SSOOS能夠自動恢復到安全運行狀態。

1.4.2.6　安全策略配置

應對身份鑒別、標記和強制訪問控制、安全審計、網絡安全保護、資源利用、用戶登錄訪問控制提供安全策略配置功能。

1.4.3　安全保障要求

1.4.3.1　開發

1.4.3.1.1　安全架構

開發者應提供產品安全功能的安全架構描述，安全架構描述應滿足以下要求：

a) 與產品設計文檔中對安全功能要求執行的抽象描述的級別一致；

b) 描述與安全功能要求一致的產品安全功能的安全域；

c) 描述產品安全功能初始化過程為何是安全的；

d) 證實產品安全功能能夠防止被破壞；

e) 證實產品安全功能能夠防止安全功能要求執行的功能被旁路。

1.4.3.1.2　功能規范

開發者應提供完備的功能規范說明，功能規范說明應滿足以下要求：

a) 完全描述產品的安全功能；

b) 使用半形式化方式描述安全功能接口；

c) 描述所有安全功能接口的目的與使用方法；

d) 標識和描述每個安全功能接口相關的所有參數；

e) 描述每個安全功能接口相關的所有行為；

f) 描述可能由每個安全功能接口的調用而引起的所有直接錯誤消息；

g) 描述不是由安全功能接口調用而引起的所有錯誤消息；

h) 為每個包含在安全功能實現中但不是由安全功能接口調用而引起的錯誤消息提供基本原理；

i) 證實安全功能要求到安全功能接口的追溯。

1.4.3.1.3　實現表示

開發者應提供全部安全功能的實現表示，實現表示應滿足以下要求：

a) 按詳細級別定義產品安全功能，詳細程度達到無須進一步設計就能生成安全功能的程度；

b) 以開發人員使用的形式提供；

c) 提供產品設計描述與實現表示實例之間的映射，并證明其一致性。

1.4.3.1.4　TSF內部

開發者應提供TSF內部結構的描述和論證過程文檔，TSF內部**應滿足以下要求：**

a) 論證過程描述用于判定“結構合理”的含義的特性；

b) TSF內部結構描述證實指定的整個TSF結構合理。

1.4.3.1.5　產品設計

開發者應提供產品設計文檔，產品設計文檔應滿足以下要求：

a) 根據子系統描述產品結構；

b) 根據模塊描述安全功能，以安全功能要求執行、支撐或無關標出每一個模塊；

c) 標識產品安全功能的所有子系統；

d) 提供每一個安全功能子系統的半形式化描述，適當時配以非形式化的、解釋性的描述；

e) 描述安全功能所有子系統間的相互作用；

f) 提供安全功能子系統到模塊間的映射關系；

g) 描述所有安全功能要求執行、支撐和無關模塊，包括其目的及與其它模塊間的相互作用；

h) 提供的映射關系能夠證實設計中描述的所有行為能夠映射到調用它的安全功能接口；

i) 描述所有安全功能要求執行和支撐模塊模塊的安全功能要求相關接口、其它接口的返回值、與其它模塊間的相互作用及調用的接口；

j) 描述所有安全功能的支撐或相關模塊，包括其目的及與其它模塊間的相互作用。

1.4.3.2　指導性文檔

1.4.3.2.1　操作用戶指南

開發者應提供明確和合理的操作用戶指南，操作用戶指南與為評估而提供的其他所有文檔保持一致，對每一種用戶角色的描述應滿足以下要求：

a) 描述在安全處理環境中被控制的用戶可訪問的功能和特權，包含適當的警示信息；

b) 描述如何以安全的方式使用產品提供的可用接口；

c) 描述可用功能和接口，尤其是受用戶控制的所有安全參數，適當時指明安全值；

d) 明確說明與需要執行的用戶可訪問功能有關的每一種安全相關事件，包括改變安全功能所控制實體的安全特性；

e) 標識產品運行的所有可能狀態（包括操作導致的失敗或者操作性錯誤），以及它們與維持安全運行之間的因果關系和聯系；

f) 充分實現安全目的所必須執行的安全策略。

1.4.3.2.2　準備程序

開發者應提供產品及其準備程序，準備程序描述應滿足以下要求：

a) 描述與開發者交付程序相一致的安全接收所交付產品必需的所有步驟；

b) 描述安全安裝產品及其運行環境必需的所有步驟。

1.4.3.3　生命周期支持

1.4.3.3.1　配置管理能力

開發者的配置管理能力應滿足以下要求：

a) 為產品的不同版本提供唯一的標識；

b) 使用配置管理系統對組成產品的所有配置項進行維護，并唯一標識配置項；

c) 提供配置管理文檔，配置管理文檔描述用于唯一標識配置項的方法；

d) 提供自動化的措施使得只能對配置項進行授權變更；

e) 配置管理系統提供一種自動方式來支持產品的生產；

f) 配置管理文檔包括一個配置管理計劃，配置管理計劃描述如何使用配置管理系統開發產品；

g) 實施的配置管理與配置管理計劃相一致；

h) 配置管理計劃描述用來接受修改過的或新建的作為產品組成部分的配置項的程序。

1.4.3.3.2　配置管理范圍

開發者應提供產品配置項列表，并說明配置項的開發者。配置項列表應包含以下內容：

a) 產品、安全保障要求的評估證據和產品的組成部分和實現表示、安全缺陷報告及其解決狀態、開發工具及其相關信息；

b) 唯一標識配置項；

c) 對于每一個安全功能相關的配置項，配置項列表簡要說明該配置項的開發者。

1.4.3.3.3　交付程序

開發者應使用一定的交付程序交付產品，并將交付過程文檔化。在給用戶方交付產品的各版本時，交付文檔應描述為維護安全所必需的所有程序。

1.4.3.3.4　開發安全

開發者應提供開發安全文檔。開發安全文檔應描述在產品的開發環境中，為保護產品設計和實現的保密性和完整性所必需的所有物理的、程序的、人員的和其他方面的安全措施。

1.4.3.3.5　生命周期定義

開發者應建立一個生命周期模型對產品的開發和維護進行的必要控制，并提供生命周期定義文檔描述用于開發和維護產品的模型。

1.4.3.3.6　工具和技術

開發者應描述所使用的實現標準。開發者應明確定義用于開發產品的工具，并提供開發工具文檔無歧義地定義所有語句和實現用到的所有協定與命令的含義，無歧義地定義所有實現依賴選項的含義。

1.4.3.4　測試

1.4.3.4.1　覆蓋

開發者應提供測試覆蓋文檔，測試覆蓋描述應滿足以下要求：

a) 證實測試文檔中的測試與功能規范中安全功能接口之間的對應性；

b) 證實已經對功能規范中的所有安全功能接口都進行了測試。

1.4.3.4.2　深度

開發者應提供測試深度的分析。測試深度分析描述應滿足以下要求：

a) 證實測試文檔中的測試與產品設計中的安全功能子系統和安全功能要求執行模塊之間的對應性；

b) 證實產品設計中的所有安全功能子系統和所有模塊都已經進行過測試。

1.4.3.4.3　功能測試

開發者應測試產品安全功能，將結果文檔化并提供測試文檔。測試文檔應包括以下內容：

a) 測試計劃：標識要執行的測試，并描述執行每個測試的方案，這些方案包括對于其它測試結果的任何順序依賴性；

b) 預期的測試結果：表明測試成功后的預期輸出；

c) 實際測試結果：和預期的測試結果一致。

d) 證實所有已知的漏洞被改正、消除或使其無效，并在消除漏洞后重新測試，以證實它們已被消除，且沒有引出新的漏洞。

1.4.3.4.4　獨立測試

開發者應提供一組與其自測安全功能時使用的同等資源，以用于安全功能的抽樣測試。

1.4.3.4.5　密碼測試

開發者應對所使用的對稱、非對稱和雜湊密碼算法進行正確性和一致性測試，確保實際運算結果與預期的正確結果相符。

開發者應確保使用符合國家密碼相關規定的對稱、非對稱和雜湊密碼算法。

1.4.3.4.6　代碼安全性測試

開發者應對安全功能實現表示和產品內核代碼進行安全性測試，證實代碼中不包含潛在的安全缺陷或后門。

1.4.3.5　脆弱性評定

開發者應從以下方面對SSOOS進行脆弱性評定：

a) 基于已標識的潛在脆弱性，產品應抵抗具有中等攻擊潛力的攻擊者的攻擊；

b) 通過一般性的隱蔽信道分析，對隱蔽信道進行非形式化搜索，標識出可識別的隱蔽存儲信道，并以文檔形式描述：

1) **標識隱蔽信道，并估算它們的帶寬；**

2) **用于確定隱蔽信道存在的過程，以及進行隱蔽信道分析所需要的信息；**

3) **隱蔽信道分析期間所作的全部假設；**

4) **最壞情況下對隱蔽信道帶寬進行估算的方式；**

5) **每個可標識隱蔽信道的最大可利用情形；**

6) **用封鎖、限制帶寬或審計等措施，對所標識的隱蔽信道進行處理，并證明處理措施的有效性。**

注： 抵抗中等攻擊潛力的攻擊者的攻擊，需要綜合考慮根據以下5個具體因素：攻擊時間、攻擊者能力、對產品的了解程度、訪問產品時間或攻擊樣品數量、使用的攻擊設備，詳見GB/T 30270—2013中的附錄A.8。