SSP 資料盤點結果 — OSCAL SSP 結構 vs 系統現況

盤點範圍

jedi-oscal 套件：oscal schema 下的 SSP 相關 table
主專案：compliance schema 下的 InformationSystem、ProjectInformationSystem、ProjectSystemCharacteristicMapping
對照標準：OSCAL SSP 規範完整結構

涉及的現有 Table 總覽

#	Table	Schema	說明
1	`system_security_plans`	`oscal`	SSP 文件主檔
2	`system_security_plans_system_characteristics`	`oscal`	系統特徵（1:1 對 SSP）
3	`system_security_plan_system_implementations`	`oscal`	系統實施（元件/子系統）
4	`system_security_plan_control_implementations`	`oscal`	控制項實施狀態
5	`oscal_metadatas`	`oscal`	OSCAL 共用元資料
6	`oscal_documents`	`oscal`	OSCAL 文件 YAML/JSON 內容
7	`oscal_roles`	`oscal`	角色定義
8	`oscal_parties`	`oscal`	參與方（人員/組織）
9	`oscal_locations`	`oscal`	地點
10	`oscal_links`	`oscal`	連結
11	`oscal_props`	`oscal`	擴展屬性
12	`oscal_remarks`	`oscal`	備註
13	`oscal_responsible_parties`	`oscal`	負責方（多態關聯）
14	`oscal_metadata_*` (6 張)	`oscal`	Metadata 關聯表
15	`profiles`	`oscal`	SSP 引用的 Profile
16	`information_systems`	`compliance`	資訊系統主檔（系統管理用）
17	`project_information_systems`	`compliance`	Project ↔︎ InformationSystem 多對多
18	`project_system_characteristic_mapping`	`compliance`	Project ↔︎ SSP SystemCharacteristic

1. metadata（元資料）

OSCAL 欄位	對應 Table	對應欄位	狀態
`title`	`oscal_metadatas`	`title`	✅ 已有
`last-modified`	`oscal_metadatas`	`last_modified`	✅ 已有
`version`	`oscal_metadatas`	`version`	✅ 已有
`oscal-version`	`oscal_metadatas`	`oscal_version`（預設 1.2.0）	✅ 已有
`published`	`oscal_metadatas`	`published`	✅ 已有
`revision`	`oscal_metadatas`	`revision`	✅ 已有
`roles[]`	`oscal_roles` + `oscal_metadata_roles`	`role_id`, `title`, `description`	✅ 已有
`parties[]`	`oscal_parties` + `oscal_metadata_parties`	`uid`, `party_type`, `name`, `short_name`	✅ 已有
`locations[]`	`oscal_locations` + `oscal_metadata_locations`	`uid`, `title`, `address`	✅ 已有
`responsible-parties[]`	`oscal_responsible_parties`	`role_id`, `party_uuid`, `context_type`	✅ 已有
`props[]`	`oscal_props` + `oscal_metadata_props`	`name`, `value`, `ns`	✅ 已有
`links[]`	`oscal_links` + `oscal_metadata_links`	`href`, `rel`, `media_type`	✅ 已有
`remarks`	`oscal_remarks` + `oscal_metadata_remarks`	`content`	✅ 已有

小結：Metadata 完整度 10/10，所有 OSCAL metadata 子元素都有對應。

2. import-profile（引用的 Profile）

OSCAL 欄位	對應 Table	對應欄位	狀態
`import-profile.href`	`system_security_plans`	`profile_id` FK → `profiles.id`	✅ 已有
Profile 內容（控制項選取）	`profiles` + `profile_controls`	完整 Profile 結構	✅ 已有
與 Module Frame 的關聯	`module_frames`	`oscal_profile_uid`（soft ref）	✅ 已有

小結：3/3 完整。SSP 透過 profile_id FK 關聯到 Profile，Profile 再關聯到 Module Frame。

3. system-characteristics（系統特徵）

OSCAL 欄位	對應 Table	對應欄位	狀態
`system-name`	`ssp_system_characteristics`	`name`	✅ 已有
`description`	`ssp_system_characteristics`	`description`	✅ 已有
`system-id`	`ssp_system_characteristics`	`system_identifier`	✅ 已有
`security-sensitivity-level`	`ssp_system_characteristics`	`security_sensitivity_level`（low/moderate/high）	✅ 已有
`status`	`ssp_system_characteristics`	`status`（active/archived）	⚠️ 部分
`system-name-short`	`information_systems`	`abbreviation`（非 SSP 表，在主檔）	⚠️ 部分
`system-information`	—	—	❌ 缺少
→ `information-type[]`	—	—	❌ 缺少
→ → `confidentiality-impact`	—	—	❌ 缺少
→ → `integrity-impact`	—	—	❌ 缺少
→ → `availability-impact`	—	—	❌ 缺少
`security-impact-level`	—	—	❌ 缺少
→ `security-objective-confidentiality`	—	—	❌ 缺少
→ `security-objective-integrity`	—	—	❌ 缺少
→ `security-objective-availability`	—	—	❌ 缺少
`authorization-boundary`	—	—	❌ 缺少
→ `description`	`ssp_system_characteristics`	`scope_description`（可部分對應）	⚠️ 部分
→ `diagrams[]`	—	—	❌ 缺少
`network-architecture`	—	—	❌ 缺少
→ `description`	—	—	❌ 缺少
→ `diagrams[]`	—	—	❌ 缺少
`data-flow`	—	—	❌ 缺少
→ `description`	—	—	❌ 缺少
→ `diagrams[]`	—	—	❌ 缺少

缺少項目評估

缺少項目	優先級	建議
`system-information` + `information-type`	高	需新增 table：`ssp_information_types`（含 C/I/A impact）
`security-impact-level`（C/I/A 三軸）	高	`ssp_system_characteristics` 加 3 欄位（`confidentiality_level`, `integrity_level`, `availability_level`），或從 information-types 聚合推導
`status` 值域不完整	中	現有只有 `active/archived`，OSCAL 要求 `operational/under-development/under-major-modification/disposition/other`。`information_systems` 已有 `system_status`（operational/under-development/disposition），但 SSP system_characteristic 沒有同步
`authorization-boundary`	中	`scope_description` 可部分對應 description，但缺 `diagrams[]` 支援。建議加 JSONB 欄位或關聯 `oscal_links`
`network-architecture`	低	新增欄位或 JSONB（`network_architecture_description`, `network_architecture_diagrams`）
`data-flow`	低	新增欄位或 JSONB（`data_flow_description`, `data_flow_diagrams`）
`system-name-short`	低	`information_systems.abbreviation` 已有，SSP 快照時可帶入

小結：完成度約 4/15（核心欄位有，但 FIPS 199 三軸分類和 information-type 完全缺失）

4. system-implementation（系統實作）

OSCAL 欄位	對應 Table	對應欄位	狀態
`users[]`	—	—	❌ 缺少
→ `role-id`	—	—	❌ 缺少
→ `authorized-privileges`	—	—	❌ 缺少
`components[]`	`ssp_system_implementations`	部分對應	⚠️ 部分
→ `title` / `name`	`ssp_system_implementations`	`name`	✅ 已有
→ `description`	`ssp_system_implementations`	`description`	✅ 已有
→ `type`	`ssp_system_implementations`	`implementation_type`（system/subsystem/service/component/hardware）	⚠️ 部分
→ `status`	—	—	❌ 缺少
→ `responsible-roles[]`	`ssp_system_implementations`	`responsible_party`（單一 String）	⚠️ 部分
→ `props[]`	—	—	❌ 缺少
`inventory-items[]`	—	—	❌ 缺少
→ `description`	—	—	❌ 缺少
→ `implemented-components[]`	—	—	❌ 缺少
`leveraged-authorizations[]`	—	—	❌ 缺少
→ `title`	—	—	❌ 缺少
→ `party-uuid`	—	—	❌ 缺少
→ `date-authorized`	—	—	❌ 缺少

缺少項目評估

缺少項目	優先級	建議
`users[]`（系統使用者角色）	中	新增 table `ssp_system_users`（ssp_id, role_id, authorized_privileges JSONB）；或透過 `oscal_responsible_parties`（context_type='system'）推導
`components[].type` 值域不完整	中	現有 `implementation_type` 缺少 `software/policy/process/plan/guidance/standard`。建議擴充 Enum
`components[].status`	中	新增 `status` 欄位到 `ssp_system_implementations`（operational/under-development/disposition/other）
`components[].responsible-roles[]`	低	現有是單一 String，OSCAL 允許多個 role。可改為 JSONB 或建關聯表
`components[].props[]`	低	可透過 `oscal_props` + association table 支援
`inventory-items[]`	低	需新增 table `ssp_inventory_items`。系統目前用 `devices` 表替代部分功能
`leveraged-authorizations[]`	低	需新增 table `ssp_leveraged_authorizations`。僅聯邦/國防場景需要

小結：完成度約 3/12（有 components 基礎結構，但 users、inventory-items、leveraged-authorizations 完全缺失）

5. control-implementation（控制項實作）

OSCAL 欄位	對應 Table	對應欄位	狀態
`implemented-requirements[]`	`ssp_control_implementations`	每個控制項一筆	✅ 已有
→ `control-id`	`ssp_control_implementations`	`catalog_control_id` FK	✅ 已有
→ `implementation-status`	`ssp_control_implementations`	`implementation_status`	⚠️ 部分
→ `implementation-description`	`ssp_control_implementations`	`implementation_description`	✅ 已有
→ `responsible-roles[]`	`ssp_control_implementations`	`responsible_role`（單一 String）	⚠️ 部分
→ `statements[]`	—	—	❌ 缺少
→ → `statement-id`	—	—	❌ 缺少
→ → `description`	—	—	❌ 缺少
→ → `by-components[]`	—	—	❌ 缺少
→ → → component-uuid	—	—	❌ 缺少
→ → → description	—	—	❌ 缺少
→ → `responsible-roles[]`	—	—	❌ 缺少
→ `remarks`	—	—	❌ 缺少
→ `props[]`	—	—	❌ 缺少
→ `set-parameters[]`	—	—	❌ 缺少

缺少項目評估

缺少項目	優先級	建議
`implementation-status` 值域差異	高	現有：`unknown/implemented/partial/inherited/not_applicable/not_implemented`。OSCAL 要求：`implemented/partial/planned/alternative/not-applicable`。需對齊
`statements[]` + `by-components[]`	高	這是 OSCAL SSP 的核心結構。需新增 table `ssp_control_implementation_statements`（statement_id, description）和 `ssp_statement_by_components`（statement_id, component_id, description）。沒有 by-components 就無法表達「哪個元件負責實作哪個控制項的哪個聲明」
`remarks`	低	在 `ssp_control_implementations` 加 `remarks` Text 欄位
`props[]`	低	可透過 `oscal_props` + association table 支援
`set-parameters[]`	中	需新增 table `ssp_control_parameter_settings`，記錄 SSP 層級覆寫的參數值
`responsible-roles[]` 多值	低	現有單一 String，OSCAL 允許多個 role

小結：完成度約 3/10（有控制項實施的基礎結構，但缺少 statements/by-components 這個 OSCAL SSP 最核心的細粒度描述機制）

6. back-matter（附件與參考資料）

OSCAL 欄位	對應 Table	對應欄位	狀態
`resources[]`	`oscal_documents`	主文件有 YAML/JSON	⚠️ 部分
→ `title`	—	—	❌ 缺少
→ `description`	—	—	❌ 缺少
→ `rlinks[]`	`oscal_links`	`href`, `rel`, `media_type`	⚠️ 部分
→ `base64 content`	—	—	❌ 缺少
→ `citation`	—	—	❌ 缺少

缺少項目評估

缺少項目	優先級	建議
`back-matter.resources[]`	低	需新增 table `oscal_back_matter_resources`（uid, title, description, document_id）+ 關聯到 `oscal_links`。或可在匯出時從 `oscal_documents` + `oscal_links` 組合產生
`base64 content`	低	嵌入式附件，可在匯出時從檔案系統讀取轉換

小結：完成度約 1/5（有 links 和 document 基礎，但缺少獨立的 back-matter resource 管理）

系統特有的額外結構（非 OSCAL 標準但系統需要）

功能	Table	說明	與 OSCAL 的關係
資訊系統主檔管理	`compliance.information_systems`	CRUD 管理，含 OSCAL 匯出方法	啟動專案時快照到 `ssp_system_characteristics`
專案 ↔︎ 資訊系統	`compliance.project_information_systems`	多對多關聯	記錄專案納入哪些系統
專案 ↔︎ 系統特徵快照	`compliance.project_system_characteristic_mapping`	多對多關聯	連結專案到 SSP 的 system_characteristic 快照
設備管理	`devices` + `project_device_mapping`	設備清冊	可部分對應 `inventory-items`

總結

完成度評估

OSCAL SSP 區塊	完成度	評分
1. metadata	10/10	✅ 100%
2. import-profile	3/3	✅ 100%
3. system-characteristics	4/15	⚠️ 27%
4. system-implementation	3/12	⚠️ 25%
5. control-implementation	3/10	⚠️ 30%
6. back-matter	1/5	❌ 20%
整體	24/55	≈ 44%

最需要優先補的 3 塊

1. 🔴 `system-information` + FIPS 199 三軸分類（system-characteristics）

原因：CMMC / FedRAMP 稽核必填，沒有三軸分類（C/I/A）無法正確判定系統安全等級
工作量：新增 1 張 table（ssp_information_types）+ ssp_system_characteristics 加 3 個欄位

建議方案：

新增 ssp_information_types:
  - id, uid, system_characteristic_id FK
  - title, description, categorization
  - confidentiality_impact (low/moderate/high/fips-199-{low,moderate,high})
  - integrity_impact
  - availability_impact

ssp_system_characteristics 加欄位：
  - security_objective_confidentiality (low/moderate/high)
  - security_objective_integrity
  - security_objective_availability

2. 🔴 `statements[]` + `by-components[]`（control-implementation）

原因：這是 OSCAL SSP 最核心的結構，用來表達「哪個元件負責實作哪個控制項的哪個聲明」。沒有這層結構，SSP 匯出會缺少最重要的實作細節
工作量：新增 2 張 table

建議方案：

新增 ssp_control_implementation_statements:
  - id, uid, control_implementation_id FK
  - statement_id (對應 catalog_control_parts.part_name = 'statement')
  - description
  - remarks

新增 ssp_statement_by_components:
  - id, uid, statement_id FK
  - component_id FK → ssp_system_implementations.id
  - description
  - responsible_role

3. 🟡 `components[].type` 值域擴充 + `status` 欄位（system-implementation）

原因：現有 implementation_type 缺少 software、policy、process 等重要類型；元件缺少 status 欄位
工作量：修改 Enum + 加 1 個欄位

建議方案：

擴充 SystemImplementationType enum：
  + SOFTWARE, POLICY, PROCESS, PLAN, GUIDANCE, STANDARD

ssp_system_implementations 加欄位：
  - status (operational/under-development/disposition/other)

可後續擴充（低優先）

項目	說明
`system-implementation.users[]`	系統使用者角色，可透過 `oscal_responsible_parties` 間接表達
`inventory-items[]`	資產清冊，系統已有 `devices` 表可部分替代
`leveraged-authorizations[]`	繼承授權，僅聯邦場景需要
`authorization-boundary.diagrams[]`	邊界圖，可用 `oscal_links` 關聯圖檔
`network-architecture` / `data-flow`	可用 JSONB 欄位或 `oscal_links` 關聯
`back-matter.resources[]`	匯出時可從現有資料組合產生
`implementation-status` 值域對齊	`unknown` → 移除；加入 `planned`、`alternative`

盤點範圍

涉及的現有 Table 總覽

1. metadata（元資料）

2. import-profile（引用的 Profile）

3. system-characteristics（系統特徵）

缺少項目評估

4. system-implementation（系統實作）

缺少項目評估

5. control-implementation（控制項實作）

缺少項目評估

6. back-matter（附件與參考資料）

缺少項目評估

系統特有的額外結構（非 OSCAL 標準但系統需要）

總結

完成度評估

最需要優先補的 3 塊

1. 🔴 system-information + FIPS 199 三軸分類（system-characteristics）

2. 🔴 statements[] + by-components[]（control-implementation）

3. 🟡 components[].type 值域擴充 + status 欄位（system-implementation）

可後續擴充（低優先）

1. 🔴 `system-information` + FIPS 199 三軸分類（system-characteristics）

2. 🔴 `statements[]` + `by-components[]`（control-implementation）

3. 🟡 `components[].type` 值域擴充 + `status` 欄位（system-implementation）