Component Definition を書く

第 3 部に入ります。ここまでの 3 つのモデル（Catalog、Profile、Mapping Collection）は、どれも「何を守るべきか」という管理策を書くものでした。第 3 部の 2 つのモデルは、決めた管理策を「誰が、何で、どう満たしているか」を書きます。管理策の「実装」にあたる層です。

最初のモデルは Component Definition（コンポーネント定義）です。Component、つまり「部品」とは、クラウドサービス、ソフトウェア、設備、社内の手順といった、システムを構成する要素のことです。Component Definition は、部品の提供者が「私たちの部品は、この管理策をこう満たす」と、部品の側から書く文書です。

これまでのモデルとの一番の違いは、書き手です。Catalog も Profile も Mapping Collection も、ミナト精機自身が自社のために書きました。Component Definition の典型的な書き手は、部品の提供者、つまりベンダーです。クラウドサービスを新しく使い始めるとき、提供元にセキュリティ対応状況を確認したことのある方もいるはずです。ベンダーが用意した説明資料を読んだり、自社のチェックシートに回答をもらったりする、あの確認です。Component Definition は、あの説明資料の機械可読版にあたります。

ベンダーの回答を読む：implemented-requirements

ミナト精機は、外部のクラウドサービス「アオバドライブ」（アオバクラウド株式会社が提供）を利用しています。受発注システムのバックアップの保管先としての利用です。社内基準の mk-bk-01 は「業務データを毎日バックアップし、復元の試験を年 1 回行う」と定めていますが、保管した先でファイルがどう守られているかは、アオバクラウド側しかわかりません。

では、その答えがどこに書かれるのか。それは、アオバクラウドが作成し、配布する Component Definition です。以下は、バックアップに関する 1 件の記述です。

          implemented-requirements:
            - uuid: 63492789-e229-450f-995c-28a9deedae6f
              control-id: PR.DS-11
              description: 保存されたファイルは 1 日 1 回、離れた場所にある第 2 のデータセンターに複製される。複製からの復元手順は、アオバクラウドが四半期ごとに試験している。

1 件の implemented-requirements が、1 件の管理策への回答です。

control-id の PR.DS-11 は、Mapping の章で読んだ CSF 2.0 の管理策です。CSF 2.0 の本文は「データのバックアップが作成され、保護され、維持され、試験されている」でした。description と読み比べると、1 日 1 回の複製が「作成と維持」に、離れた場所の第 2 データセンターが「保護」に、四半期ごとの復元手順の確認が「試験」に、それぞれ対応しています。

まるで、Excel で作成するセキュリティチェックシートのようですね。

回答の宛先：source

さきほど、暗黙的に control-id の PR.DS-11 は、CSF 2.0 と決めつけてしまいましたが、厳密にどの Catalog の id かを決めるのが、control-implementations です。

      control-implementations:
        - uuid: d154cee0-cbfa-438b-b4b3-06b81c79d9a0
          source: NIST_CSF_v2.0_catalog.yaml
          description: NIST CSF 2.0 の管理策に対する、アオバドライブの実装内容。
          implemented-requirements:
            - uuid: 205cacce-1978-4719-b222-f368a61ccbb4
              control-id: PR.DS-01
              description: 保存されたファイルはすべて暗号化される。暗号化の鍵はアオバクラウドが利用企業ごとに分けて管理する。
            - uuid: 63492789-e229-450f-995c-28a9deedae6f
              control-id: PR.DS-11
              description: 保存されたファイルは 1 日 1 回、離れた場所にある第 2 のデータセンターに複製される。複製からの復元手順は、アオバクラウドが四半期ごとに試験している。

source は、Profile の imports で覚えた href と同じ発想の参照です。以降に書かれる control-id は、source が指すカタログに載っている管理策の id として解釈されます。もう 1 件の回答にある PR.DS-01（保存中のデータの保護）も、CSF 2.0 の管理策です。

受け取ったミナト精機の側には、第 2 部で作った Mapping Collection の対応表があります。「mk-bk-01 は PR.DS-11 の一部にあたる（subset-of）」という map です。この対応をたどれば、CSF 2.0 宛ての回答の中から、自社の基準に関わる記述を探せます。mk-bk-01 の保管先での扱いを確かめたければ、PR.DS-11 への回答を読めばよい、というたどり方です。

回答している部品：component

主役である「部品」の説明は、components に書かれています。基本の項目は 4 つです。

type には、決まった値の一覧から選ぶ慣例があります。よく使うのは service（外部や社内で提供される仕組み）、software（ソフトウェア）、hardware（機器）、policy（規程や方針）、process-procedure（手順）あたりです。クラウドサービスであるアオバドライブは service です。規程や手順のような「モノでないもの」も部品になれる、という点は覚えておいてください。管理策を満たす手段は、システムだけではないからです。

  components:
    - uuid: 624ae1a4-39f2-4f3b-aedb-a80cc5b4979d
      type: service
      title: アオバドライブ
      description: アオバクラウド株式会社が提供する、ファイル保管のクラウドサービス。保存したファイルは国内のデータセンターに置かれ、伝送中も保存中も暗号化される。
      purpose: 業務ファイルの保管と共有
      control-implementations:
        # …さきほどの回答が続く…

文書の全体

部品と回答に uuid と metadata を加えると、アオバクラウドが配っている文書の全体になります。全体像を確認してみましょう。

いちばん外側がモデル名の component-definition: であり、その下に uuid と metadata。metadata の必須 4 項目が書かれているのも、Catalog や Profile と同じです。

component-definition:
  uuid: 8a4145c1-5948-41a2-9b0f-8c769ac93d42
  metadata:
    title: アオバドライブ コンポーネント定義
    last-modified: "2026-06-10T09:00:00+09:00"
    version: "2.3.0"
    oscal-version: "1.2.2"
  components:
    - uuid: 624ae1a4-39f2-4f3b-aedb-a80cc5b4979d
      type: service
      title: アオバドライブ
      description: アオバクラウド株式会社が提供する、ファイル保管のクラウドサービス。保存したファイルは国内のデータセンターに置かれ、伝送中も保存中も暗号化される。
      purpose: 業務ファイルの保管と共有
      control-implementations:
        - uuid: d154cee0-cbfa-438b-b4b3-06b81c79d9a0
          source: NIST_CSF_v2.0_catalog.yaml
          description: NIST CSF 2.0 の管理策に対する、アオバドライブの実装内容。
          implemented-requirements:
            - uuid: 205cacce-1978-4719-b222-f368a61ccbb4
              control-id: PR.DS-01
              description: 保存されたファイルはすべて暗号化される。暗号化の鍵はアオバクラウドが利用企業ごとに分けて管理する。
            - uuid: 63492789-e229-450f-995c-28a9deedae6f
              control-id: PR.DS-11
              description: 保存されたファイルは 1 日 1 回、離れた場所にある第 2 のデータセンターに複製される。複製からの復元手順は、アオバクラウドが四半期ごとに試験している。

自社の設備を書く：入退室管理システム

Component Definition を書くのはベンダーだけではありません。社内の複数のシステムが共通に利用する設備や手順を、自社で 1 度だけ文書にしておく、という使い方があります。

題材は、ミナト精機の本社サーバー室の入退室管理システムです。扉に IC カードの読み取り機があり、解錠のたびに記録が残る仕組みです。サーバー室に置かれたすべてのサーバーは、物理的なセキュリティの多くをこの仕組みに頼ることになるので、部品として 1 度書いておき、使い回すことを考えます。

文書の名前は「ミナト精機 共通部品定義」、ファイル名は mk-common-components.yaml とします。まず部品からです。

component-definition:
  uuid: 09ce348e-ef9e-4193-ad82-2cd811ea1107
  metadata:
    title: ミナト精機 共通部品定義
    last-modified: "2026-07-22T09:00:00+09:00"
    version: "1.0.0"
    oscal-version: "1.2.2"
  components:
    - uuid: d57ed24c-9ed9-4aab-802f-478f6edc917d

次に、この部品で実装されている管理策を書きます。サーバ室は社内の施設なので、Catalog はミナト精機の社内基準カタログ（mk-standards-catalog.yaml）にある 6 件でよいでしょう。

入退室管理システムが実際にやっていることは、次のとおりです。

IC カードで解錠した日時と利用者を自動で記録し、記録を 1 年間保存する。IC カードは、情報システム部長が承認した者にだけ発行する。

  components:
    - uuid: d57ed24c-9ed9-4aab-802f-478f6edc917d
      type: service
      title: 入退室管理システム
      description: 本社サーバー室の扉に設置した、IC カードで解錠する入退室管理の仕組み。解錠のたびに入退室の記録を自動で残す。
      purpose: サーバー室への入室を、承認された者に限定する
      control-implementations:
        - uuid: 01adde3f-17cd-4051-b0cc-1df7a030ab32

これで「ミナト精機 共通部品定義」の版 1.0.0 ができました。社内の 1 つの設備のセキュリティ対策を、OSCAL のモデルを使って説明できたことになります。

チェックシートの回答との違い

ベンダーへのセキュリティ確認を、自社独自のセキュリティチェックシートで行う場合と、Component Definition を受け取る場合とで、何が変わるかを形式の面から確かめておきます。

チェックシートの回答は、質問した側の様式でしか使えません。質問の番号も文言も会社ごとに違うので、ベンダーは会社の数だけ回答を書き、受け取った側も自社の様式の中でしか照合できません。Component Definition は、管理策の id（PR.DS-01 のような公開された識別子）に実装の記述を紐づけるので、ベンダーは 1 つの文書を書けばよく、受け取った側は自社が使う管理策の id で機械的に照合することができます。

次へ

部品（ベンダー）の側から、管理策の実装を書く手法を覚えました。次のセクションからは、Implementation Layer のもう 1 つのモデル、SSP（System Security Plan、システムセキュリティ計画書）です。1 つのシステムのセキュリティ対策を丸ごと説明する大きな文書で、この章で書いた Component Definition も、アオバクラウドから受け取った Component Definition も、あとで SSP を書く材料になります。まず NIST が公開しているサンプルの実物を読むところから始めましょう。