SSP を読む

SSP（System Security Plan、システムセキュリティ計画書）は、1 つのシステムを対象に、「このシステムが従う管理策」「システムの概要」「システムの実装」「管理策の実装」を 1 冊にまとめるモデルです。OSCAL の 8 モデルの中で、いちばん大きな文書です。

ISO/IEC 27001 の運用でこれに近い文書はありません。システムごとの管理策の実施状況をまとめた文書を作る機会は多くないからです。システムで守るべきルールは、社内規程に落とし込まれてしまい、終わりとしてしまうケースが多いでしょう。しかし、OSCAL の考え方では、各システムにルールがどう実装されているかこそが重要であるという立場です。無理に例えるのであれば、各システムごとのセキュリティ仕様書や、各システムごとの適用宣言書といったイメージでしょうか。

いきなり書くには大きすぎるモデルなので、Catalog や Profile と同じく、まず実物を読んでみましょう。

NIST の学習用サンプル：IFA SYSTEM1234

題材は、NIST が公式ファイル置き場（usnistgov/oscal-content）で公開している学習用のサンプル SSP、ifa_ssp.yaml です。IFA（Important Federal Agency）という架空の米国連邦機関が運用する「SYSTEM1234」というシステムの SSP、という設定で書かれています。SYSTEM1234 は、職員が長い Web アドレスを短い形に変換して配るための、リンク短縮の Web アプリケーションです。全体は 320 行あります。

米国の機関を想定したサンプルなので、米国の制度に由来する項目がところどころに現れます。そうした項目は深追いしません。

このサンプル SSP の題材は、ac-6.1 という 1 件の管理策だけです。SP 800-53 の管理策で、「操作の権限を必要最小限に絞ること（最小権限）」に関するものです。SYSTEM1234 において ac-6.1 の管理策がどう実装されているかを、この文書を読むことで理解していきましょう。

管理策の実装：control-implementation

答えは、ファイルの後半にある control-implementation というブロックに書かれています。

  control-implementation:
    description: This is the control implementation for the application and infrastructure that compose to the IFA SYSTEM1234 Project's system.
    # …略…
    implemented-requirements:
      - uuid: d5f9b263-965d-440b-99e7-77f5df670a11
        control-id: ac-6.1
        by-components:
          - component-uuid: 551b9706-d6a4-4d25-8207-f2ccec548b89
            uuid: a4c2d318-26a9-49df-9818-ee0acaf066f2
            description: |-
              The IFA SYSTEM1234 application and infrastructure are composed as designed and implemented with lease privilege for the elements of this system.
              # …略…
            implementation-status:
              state: implemented

1 件の implemented-requirements が、1 件分の管理策の実装です。前のセクションで読んだ Component Definition にも同じ名前のリストがありましたが、SSP には 1 つ大きな違いがあります。by-components、「どの部品がこの管理策を実装するか」の指定です。

1 件の by-components は、部品への参照（component-uuid）と、その部品による実装の説明（description）と、実装の状態（implementation-status）を持ちます。description には、アプリケーションの権限の分け方、データベースへの接続の制限、サーバーの管理操作の絞り方といった内容が、長い文章で書かれています（技術的な詳細はここでは読み飛ばして構いません）。implementation-status の state: implemented は「実装済み」の宣言です。

つまり ac-6.1 の管理策の実装状況の答えは、「component-uuid: 551b9706… の部品が、この説明のとおりに実装している」ということです。ただし 551b9706… は数字の列で、これが何なのかはこのブロックだけでは分かりません。

システムの実装：system-implementation

component-uuid が指す部品は、system-implementation というブロックの中の components に定義されています。

  system-implementation:
    users:
      - uuid: 61405ba7-edb4-4243-8461-79aac5805e5c
        title: Public Affairs Officers
        # …略…
    components:
      - uuid: 551b9706-d6a4-4d25-8207-f2ccec548b89
        type: this-system
        title: IFA SYSTEM1234 System
        # …略…
    inventory-items:
      - uuid: 3e3a8d9a-e3d6-4c7d-b59b-a8d6514fa4a2
        description: This is the database for the custom SYSTEM1234 application within the system.
        # …略…

uuid が 551b9706… で一致する部品が見つかりました。type や title の書き方は Component Definition と同じですが、1 つだけ新しい値があります。type: this-system は「このシステム自身」を表す SSP 専用の type で、部品一覧の中に必ず 1 件置く慣例です。ac-6.1 を実装しているのは外部のサービスや設備ではなく、SYSTEM1234 自身だった、というのがこの参照の答えです。

system-implementation は「システムの実装」のブロックで、components のほかに 2 つのリストを持ちます。

users は利用者の種類です。SYSTEM1234 には、リンクを審査して公開する広報担当者（Public Affairs Officers）、システムを管理する開発者、リンクを踏むだけの一般公衆、という 3 種類の利用者が定義されています。個人名の一覧ではなく、「どんな立場の人が、何をできるか」の種類分けです。

inventory-items は機器や構成物の台帳です。実物では、アプリケーション本体、その土台のソフトウェア、データベース、サーバーなどが 1 件ずつ並び、それぞれがどの部品（component）の一部かを指しています。

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

もう 1 つの参照が残っています。control-id の ac-6.1 は、どの文書に載っている管理策なのか。その宣言が import-profile です。実物では 1 行だけです。

  import-profile:
    href: '#84cbf061-eb87-4ec1-8112-1f529232e907'

href の # で始まる値は、Profile の章で読んだのと同じ「このファイル自身の巻末（back-matter）を見よ」という参照です。たどると、SP 800-53 の Profile につながっています。つまりこの SSP は「SP 800-53 から選ばれたベースラインに従います」と宣言していて、ac-6.1 はその選択結果に含まれる管理策です。

Catalog から Profile へ、Profile から SSP へ。Control Layer で作った文書の連なりが、ここで Implementation Layer につながります。SSP 自身は「何を守るべきか」を並べ直す必要はなく、1 行の href で Profile を指すだけです。

システムの概要：system-characteristics

管理策の実装と、システムの実装と、従う管理策がたどれたので、残るはシステムの概要です。system-characteristics に書かれています。

  system-characteristics:
    system-ids:
      - identifier-type: http://ietf.org/rfc/rfc4122
        id: 8101e04d-8305-4e73-bb95-6b59f645b143
    system-name: IFA SYSTEM1234
    description: This system acts as a link shortener for IFA employees
    date-authorized: "2025-05-19"
    security-sensitivity-level: moderate
    system-information:
      # …略…
    security-impact-level:
      # …略…
    status:
      state: operational
    authorization-boundary:
      description: This section describes an attached diagram of the authorization boundary for IFA SYSTEM1234 Project's information system.
    # …略…

system-ids はシステムに付けた識別番号、system-name と description は名前と説明です。文書の uuid とは別に、システムそのものに番号を付けるのは、SSP を書き直してもシステムは同じものだと示すためです。

status は稼働状態です。state: operational は「本番で動いている」を表し、他に開発中（under-development）や廃止済み（disposition）などの値があります。評価する側から見ると、これから作るシステムの計画なのか、動いているシステムの現状なのかで文書の読み方が変わるので、状態の宣言が必須になっています。

authorization-boundary は、この計画書が守る範囲の説明です。どこまでがこのシステムで、どこから外かの線引きで、実物では「別紙の図を参照」という形の説明文が入っています。

途中の date-authorized や security-sensitivity-level、security-impact-level は、米国の制度（システムの重要度を段階分けして扱う運用）に由来する項目です。ここでは説明を省略します。

system-information だけ、より詳細を説明します。このシステムが扱う情報の種類を並べる場所です。

    system-information:
      information-types:
        - uuid: bccfbb65-a7f3-41ac-989f-01d96eddfdc7
          title: User-provided Links
          description: This system maintains a set of user-provided links and their associated shortlinks
          # …略…

SYSTEM1234 が扱う情報は「利用者が登録したリンク」だ、と書かれています。守る対象の情報に先に名前を付けておくことで、情報資産の管理も行いやすくなるでしょう。

全体の並び

今まで説明した順は「管理策の実装 → システムの実装 → このシステムが従う管理策 → システムの概要」でしたが、ファイルの上では次の順に並んでいます。

system-security-plan:
  uuid: cef90dc9-2745-4c59-90b6-f82f6a96dad7
  metadata:
    # …略…
  import-profile:
    # …略…
  system-characteristics:
    # …略…
  system-implementation:
    # …略…
  control-implementation:
    # …略…
  back-matter:
    # …略…

上から順に、「このシステムが従う管理策」「システムの概要」「システムの実装」「管理策の実装」と並ぶ構成です。320 行の実物も、この骨組みに肉が付いたものです。

読み取り演習

次へ

次のセクションから 3 章かけて、ミナト精機の受発注システムの SSP を書きます。書く順序はファイルの並びと同じで、まずこのシステムが従う管理策とシステムの概要、次にシステムの実装、最後に管理策の実装です。材料は揃っています。従う管理策は第 2 部で書いた受発注システム基準プロファイル、部品の説明は前のセクションで書いた共通部品定義とアオバクラウドの文書です。