SSP docx 內容 × 現有資料表對應度分析

來源 docx:ASIA-CMMC-SSP-DRAFT-202604.docx DB schema 來源:guidant_ai_stg(2026-05-02) 目的:把上一份 analysis-ssp-docx-to-oscal-mapping.md 的 OSCAL 欄位 對到現有 table,逐欄看夠不夠用、缺什麼欄位、要加什麼欄位/表


§1

A. 文件層級(OSCAL metadata

docx 內容 目標 table 現有欄位是否夠
Ser. NO(文件編號) oscal.oscal_metadatas.title ⚠️ title 是 SSP 標題,不是文件 NO;建議塞 oscal_metadata_props (name='document_serial_no')
Version oscal_metadatas.version ✅ 夠
Issue Date oscal_metadatas.published ✅ 夠(有欄位但目前 nullable)
組織名 oscal_parties (party_type='organization') ✅ 夠(uid/name/short_name/remarks)
修訂紀錄 T24(多列) ❌ 無對應 缺表:建議新增 oscal.metadata_revisions(metadata_id, version, date, amendment, description)
Appendix 1 核決紀錄 T23 oscal.oscal_metadata_remarksback_matter_resources ⚠️ 只能塞純文字,無簽核流程 / 簽名檔 hash

結論:metadata 表本體夠;缺 metadata_revisions 一張表 + 修訂紀錄資料模型。


§2

B. 系統識別(OSCAL system-characteristics

docx 內容 目標 table & 欄位 是否夠
System Name/Title oscal.system_security_plans_system_characteristics.name
System Categorization (Moderate / Low / High) system_characteristics.security_sensitivity_level ✅(同步存 compliance.information_systems
C / I / A 分項 impact compliance.information_systems.security_objective_{confidentiality,integrity,availability} ✅ enum 已有 (security_objective_level_enum)
System Unique Identifier system_characteristics.system_identifier ✅ varchar(100)
General Description / Purpose system_characteristics.description (text)
系統授權邊界 compliance.information_systems.authorization_boundary (text)
部署模式 compliance.information_systems.deployment_model (enum)
FCI 類型清單(多項) ❌ 無對應 缺表:建議新增 oscal.system_information_types(system_characteristic_id, title, description, c_impact, i_impact, a_impact)

結論:system-characteristics 主欄位很完整(兩張表分工 oscal + compliance); 缺 system_information_types 一張 1:N 表存 FCI 等資料類型。


§3

C. 角色與當事人(OSCAL parties / responsible-parties

docx 5 個角色:Responsible Org / Info Provider / Info Receiver / System Owner / System Security Officer + Approver。

對應實體 目標 table 是否夠
個人/組織基本資料 oscal.oscal_parties ✅(party_type / name / short_name / remarks)
Email / Phone / Office Address ❌ 無對應 缺欄位:建議在 oscal_partiesemail_address(text)、telephone_number(varchar) 或新增 party_contacts
個人 Title(職稱) ❌ 無對應 缺欄位:建議 oscal_parties.title(varchar)
角色定義(system-owner、info-supplier 等) oscal.oscal_roles (role_id, title, description)
角色 → 當事人對應 oscal.oscal_responsible_parties (role_id, party_uuid, context_type, context_id) ✅(context 已支援多種 SSP/AP/profile)
當事人地址(office address) oscal.oscal_locations (title, address, remarks) ⚠️ 有表但目前僅 metadata 級別關聯(oscal_metadata_locations),party 無直連

結論:role / responsible-parties 模型完整;oscal_parties 缺 email / phone / title 欄位,docx 內 5 張 Name/Title/Email 表硬要塞會丟資料。最簡單做法是在 oscal_parties 加 3 欄。


§4

D. 系統環境(OSCAL system-characteristics 子節 / system-implementation

docx 內容 目標 table 是否夠
網路架構圖(圖檔) oscal.system_security_plan_system_implementations (implementation_type='network-architecture', description) + oscal_links 帶圖檔 URL ✅ 模型可組,但要約定 implementation_type 列舉值
資料流敘述(文字) 同上 type='data-flow' ✅ 同上
System Components(HW/SW 清單引用文) 同上 type='component-inventory' ⚠️ 可勉強塞 description 文字;若要結構化清單則缺
結構化的硬體 / 軟體清冊 ❌ 無對應 缺表:建議新增 oscal.system_implementation_components(uid, implementation_id, type, title, version, vendor, status, ...)
軟硬體維護所有權 (Yes/No 描述) system_implementations.descriptionoscal_props ⚠️ 可塞純文字

結論system_security_plan_system_implementations 本身很彈性 (implementation_type 自由字串 + description text),可承載敘述型內容; 但結構化的 component inventory 沒有專屬表,要建。


§5

E. 外部系統與服務(OSCAL leveraged-authorizations / components

T6(Leveraged FedRAMP)+ T7(External Systems with protocol/port)

內容 目標 table 是否夠
1 條 leveraged auth ❌ 無專屬 leveraged_authorizations 表 缺表:建議新增 oscal.leveraged_authorizations(ssp_id, title, party_uuid, package_id, agreement_type, date_authorized)
External system component(協定 / port) 可塞 system_implementations.description 自由文字 ⚠️ 沒結構化欄位;協定 / port 散在 text 內,未來查詢困難
protocol / port_ranges ❌ 無對應 缺欄位:搭配 D 點的 components 新表加 protocols JSONB 或 port_ranges JSONB

結論:leveraged-authorizations 是 OSCAL 標準節點,目前完全無對應表, 推薦補一張獨立表(FedRAMP 場景使用率高)。


§6

F. 控制項實作 + AO(已支援)

內容 對應 table 狀態
控制項實作 oscal.system_security_plan_control_implementations ✅ docx 匯入已寫入
AO 描述 oscal.ssp_control_implementation_objectives ✅ docx 匯入已寫入
Module Frame 範本 compliance.module_frame_control_defaults + module_frame_control_objective_defaults

§7

G. Appendix(OSCAL back-matter

內容 目標 table 是否夠
修訂紀錄 T24 同 A ❌ 缺表
核決紀錄 T23 + 簽名檔 compliance.module_frame_reference_documents + module_frame_reference_document_mappings ⚠️ 有相似機制但綁 module_frame;SSP 也有 oscal.ssp_reference_documents + ssp_reference_document_mappings,可承接
圖示資源(網路架構 / 資料流圖) 同上 reference_documents ✅ 可掛附件;搭配 D 點實作描述使用

結論:reference_documents 兩條(mf 和 ssp)已能承接附件型資源。 仍缺修訂紀錄專表。


§8

H. 缺失盤點(建議新增的 table / 欄位)

必要(影響 OSCAL 完整度)

缺項 類型 用途 優先
oscal_parties.email_address 加欄位 個人聯絡 email
oscal_parties.telephone_number 加欄位 電話
oscal_parties.title 加欄位 職稱
oscal.metadata_revisions 新表 修訂紀錄(version/date/amendment/description)
oscal.system_information_types 新表 FCI / PII 等資料類型清單
oscal.leveraged_authorizations 新表 FedRAMP 等外部授權服務
oscal.system_implementation_components 新表 HW/SW 結構化清單

加值(強化現有 table)

加值項 類型 說明
system_implementations.implementation_type 列舉 enum 約束 'network-architecture' / 'data-flow' / 'component-inventory' 等標準值
oscal_locationsoscal_parties 關聯 M2M 讓 party 可掛地址
back_matter 統一 resources 表 新表 統合 ref docs + 圖示 + 法規引用

§9

I. 現有 table 涵蓋率快表(手機檢視)

區塊 涵蓋度 說明
metadata 主欄位 80% 缺修訂紀錄表
system-characteristics 主欄位 95% 缺 information_types 1:N
parties / roles / responsible-parties 70% 缺 email/phone/title 欄位
system implementation 敘述 100% 用 description 即可
component inventory 結構化 0% 完全沒表
leveraged authorizations 0% 完全沒表
reference docs / 附件 100% ssp_reference_documents 已能承接
控制項 + AO 100% 既有功能

§10

J. 上線優先建議(最小改動 → 最完整)

第 1 階段(最小,立即補資訊保留率)

  • oscal_partiestitle / email_address / telephone_number 三欄
  • 完成後 docx 內 5 張 Name/Title/Email 表才不會漏資料

第 2 階段(中等,OSCAL 完整度提升)

  • 新增 oscal.metadata_revisions(修訂紀錄清單)
  • 新增 oscal.system_information_types(FCI 等資料類型分類)

第 3 階段(完整 OSCAL 對齊)

  • 新增 oscal.leveraged_authorizations
  • 新增 oscal.system_implementation_components + 標準化 implementation_type enum