SSP の骨格を書く

前のセクションで読んだ SSP を、ミナト精機の受発注システムで書き始めます。文書の名前は「ミナト精機 受発注システム セキュリティ計画書」、ファイル名は order-system-ssp.yaml です。この章では、このシステムが従う管理策と、システムの概要までを書いてみます。

このシステムが従う管理策：import-profile

受発注システムが何を守るべきかは、第 2 部ですでに決めてあります。社内基準カタログにある 6 件の管理策から 4 件（mk-ac-01、mk-ac-02、mk-ph-01、mk-bk-01）を選び、パスワードの最低文字数を 16 に調整した、受発注システム基準プロファイル（order-system-profile.yaml、版 1.1.0）です。

SSP では、この管理策を再度列挙する必要はありません。import-profile の href に参照を 1 行書くだけで、「このシステムが従う管理策は、この Profile で選んだものだ」という宣言になります。

書き出しは 8 モデル共通の形です。system-security-plan: で全体を包み、uuid と metadata を置きます。その次に import-profile が来ます。

system-security-plan:
  uuid: 46a1cef8-7cb7-43a5-bee1-55f3e267b931
  metadata:
    # …略…
  import-profile:
    href: order-system-profile.yaml

IFA の実物は巻末の資料一覧を経由する書き方でしたが、Profile の章で覚えたとおり、同じ置き場のファイルなら href にファイル名を直接書けます。

system-security-plan:
  uuid: 46a1cef8-7cb7-43a5-bee1-55f3e267b931
  metadata:
    title: ミナト精機 受発注システム セキュリティ計画書
    last-modified: "2026-07-29T09:00:00+09:00"
    version: "1.0.0"
    oscal-version: "1.2.2"

システムの概要：system-characteristics

審査や監査でシステムの話をするとき、まずはシステムの概要の確認が行われます。何というシステムで、何をするものか。どんな情報を扱うか。いま動いているのか。どこまでが範囲か。system-characteristics は、この 4 つを書くブロックです。

何というシステムか。名前を system-name に、説明を description に書きます。あわせて system-ids に、システムの識別番号を付けます。番号の形式は、組織の中でシステムを指せるものなら自由です。IFA の実物は uuid 形式の番号に「これは uuid 形式です」という補足（identifier-type）を付けていましたが、社内の管理番号をそのまま書く形でも構いません。ミナト精機では mk-sys-001 という番号を付けます。文書の uuid は改定のたびに変わりますが、この番号は同じシステムである限り変わりません。

どんな情報を扱うか。system-information の中の information-types に、扱う情報の種類を並べます。1 件には uuid、title、description を書きます。受発注システムが扱う情報は「受発注データ」、説明は「取引先との注文、出荷、請求に関する情報。」とします。

いま動いているのか。status の state に、決まった一覧から選んだ値を書きます。主な値は、運用中の operational、開発中の under-development、大きな改修中の under-major-modification、廃止済みの disposition です。

どこまでが範囲か。authorization-boundary に、対象範囲の説明（description）を書きます。受発注システムの範囲は、本社サーバー室の Web サーバーに加えて、バックアップの保管先であるアオバドライブまでを含めることにします。外部のサービスでも、このシステムのセキュリティを支える一部なら範囲に入れて説明する、という線引きです。

まとめると、system-characteristics の必須項目は次の 6 つです。

  system-characteristics:
    system-ids:
      - id: mk-sys-001
    system-name: 受発注システム
    description: 取引先との受発注データを扱う、ミナト精機が内製した Web アプリケーション。
    system-information:
      information-types:
        - uuid: bb920766-fcfb-4dbd-97b6-e019f7fbb4ca
          title: 受発注データ
          description: 取引先との注文、出荷、請求に関する情報。
    status:
      state: operational
    authorization-boundary:
      description: 本社サーバー室に設置した Web サーバーと、バックアップの保管先であるアオバドライブまでを、この計画書の対象範囲とする。

  system-characteristics:
    system-ids:
      - id: mk-sys-001
    system-name: 受発注システム

残りの必須ブロック

このシステムが従う管理策と、システムの概要を書き終えました。ただし、この時点のファイルはまだ OSCAL の検証を通りません。SSP には必須のブロックがあと 2 つ残っているからです。システムの実装を書く system-implementation と、管理策の実装を書く control-implementation です。

Catalog や Profile は最小の形でも文書として成立しましたが、SSP はシステムの実装と管理策の実装まで書いて初めて成立する、という設計になっています。セキュリティ計画書と名乗る以上、システムの概要だけ書いて実装に触れない文書は認めない、という思想です。

次へ

受発注システムの SSP に、このシステムが従う管理策とシステムの概要を書き終えました。次のセクションはシステムの実装、system-implementation です。利用者の種類、部品の一覧、機器の台帳を書きます。第 13 セクションで書いた共通部品定義と、アオバクラウドから受け取った Component Definition の記述を、ここで SSP の部品に引き継ぎます。