Profile を書く

前のセクションで読んだ管理策の選択の書き方を、今度はミナト精機の文書で使います。

題材は受発注システムです。ミナト精機が内製した Web アプリケーションで、取引先との受発注データを扱います。この講座の後半で、このシステムのセキュリティ文書を OSCAL で書いていくことになるので、その最初の一歩として「受発注システムにはどの社内基準を適用するか」を Profile にします。選択元は、前のセクションまでに作った社内基準カタログ（版 1.1.0、管理策 6 件）です。

最小の Profile：uuid、metadata、imports

Profile の必須項目は、uuid と metadata と imports の 3 つです。外枠 2 つは Catalog と同じなので、新しく書くのは imports だけです。

imports の 1 件には、「どこから」の href に加えて、「どれを使うか」の指定が必ず 1 つ要ります。いちばん単純な指定が include-all、全部使うという意味です。

profile:
  uuid: 5c8e1f3a-7b2d-4d9c-a1e6-3b5d7f9a2c4e
  metadata:
    title: ミナト精機 受発注システム基準プロファイル
    last-modified: "2026-07-10T09:00:00+09:00"
    version: "1.0.0"
    oscal-version: "1.2.2"
  imports:
    - href: mk-standards-catalog.yaml
      include-all: {}
  merge:
    as-is: true

初めて見る書き方が 2 つあります。

1 つ目は href の値です。SP 800-53B の実物は巻末の資料一覧を経由していましたが、ここでは参照先のファイル名を直接書いています。社内基準カタログを mk-standards-catalog.yaml というファイル名で同じ置き場に保存してある、という前提の書き方で、小さな文書のセットならこれで十分です。

2 つ目は include-all: {} の {} です。include-all は「全部使う」という指定そのものが意味のすべてで、値を持ちません。YAML で「項目はあるが、値は空」を表すのがこの {} です。

末尾の merge: as-is: true は、前のセクションで読んだ決まり文句です。選んだ結果を選択元の章立てのまま並べる、という指定で、この講座の Profile には毎回付けておきます。

選んで使う：include-controls と with-ids

全部使うのでなければ、SP 800-53B の実物と同じ include-controls を使います。include-all の行を、使う id の列挙に置き換えます。

  imports:
    - href: mk-standards-catalog.yaml
      include-controls:
        - with-ids:
            - mk-ac-01
            - mk-ac-02

この形なら、社内基準カタログの 6 件からアクセス管理の 2 件だけを選んだ Profile になります。id は選択元である社内基準カタログの表記をそのまま使います。

除外して使う：exclude-controls

逆の書き方もあります。exclude-controls は「これを除く」という指定で、include-all と組み合わせると「全部使う、ただしこれは除く」になります。

  imports:
    - href: mk-standards-catalog.yaml
      include-all: {}
      exclude-controls:
        - with-ids:
            - mk-tr-01

6 件中 4 件を使いたいとき、「使う 4 件を include で列挙する」ことも「除く 2 件を exclude で列挙する」こともできて、結果は同じです。使い分けの目安は列挙の短さです。大半を使って少数を外すなら exclude が短く、少数だけを選ぶなら include が短く書けます。列挙が短いほど、後から読む人が意図を取り違えにくくなります。

判断演習：受発注システムに適用する管理策

それでは、実際の選択を書きます。情報システム部で決めた方針は次のとおりです。

• 情報セキュリティ教育（mk-tr-01）は全社共通で運用する管理策なので、個別システムの基準には含めない。
• 機密書類の施錠保管（mk-ph-02）は紙の書類の管理策で、受発注システムの範囲外なので含めない。
• 残りの 4 件は、すべて受発注システムに適用する。

profile:
  uuid: 5c8e1f3a-7b2d-4d9c-a1e6-3b5d7f9a2c4e
  metadata:
    title: ミナト精機 受発注システム基準プロファイル
    last-modified: "2026-07-10T09:00:00+09:00"
    version: "1.0.0"
    oscal-version: "1.2.2"
  imports:
    - href: mk-standards-catalog.yaml
      include-all: {}
  merge:
    as-is: true

これが「受発注システム基準プロファイル」の版 1.0.0 です。以降のセクションでこの名前で呼ぶときは、4 件を選んだこの Profile を指します。

適用宣言書との対応

ISO/IEC 27001 の適用宣言書を作ったことのある方は、この章の作業に見覚えがあるはずです。管理策の一覧に対して採用・不採用を決めていく、あの表の採否列にあたる情報が、Profile の include と exclude です。

対応しない部分もあります。適用宣言書には不採用の理由や実施状況を書きますが、Profile には管理策ごとの除外理由を書く決まった場所がありません。Profile に書くのは「どれを使うか」の宣言までです。適用宣言書の丸ごとの置き換えではなく、その採否列を機械可読にしたもの、と捉えるのが正確です。

理解の確認

次へ

管理策を選ぶことができるようになりました。ただ、実務の要求はもう一歩先にあります。「パスワードの桁数 12 文字以上」を特定のシステムでは「16 文字以上」にしたい。本文に一言書き足したい。次のセクションでは、選んだ管理策を Profile の側から調整する仕組みを扱います。