8 モデルの復習と、この先
書いてきた 8 つのモデルと参照関係を振り返ってみましょう。Profile の解決やファイル検証など、この講座では深く扱わなかった話題にも触れます。
このセクションを終えるとできること
- 8 つのモデルの役割を、自分の言葉で一行ずつ説明できる。
- モデル間の参照関係を、どの項目がどの文書を指すかまで含めてたどれる。
- Profile の解決と OSCAL ファイルの検証が、それぞれ何をする処理か説明できる。
- この講座の先にある学習事項から、自分が次に調べるものを選べる。
第 1 部の最初に、8 つのモデルの一覧を「いまは全部で 8 種類あると分かれば十分です」と紹介しました。いまは違います。8 つすべてを自分の手で書き、参照でつないできました。いままで書いてきたものを、改めて整理してみましょう。
8 モデルの一行説明
各モデルの役割と、この講座でミナト精機の担当者として作った成果物です。各講座の内容を振り返りながら、眺めてみてください。
| モデル | 一行説明 | 講座で作った成果物 |
|---|---|---|
| Catalog | 守るべきこと（管理策）の一覧を定義する | ミナト精機社内基準カタログ、CSF 2.0 抜粋カタログ |
| Profile | Catalog から採用する管理策を選び、調整する | 受発注システム基準プロファイル |
| Mapping Collection | 2 つの文書の管理策同士の対応を記録する | 社内基準 × CSF 2.0 対応表 |
| Component Definition | 部品の提供者が「この部品はこの管理策を支援できる」と書く | ミナト精機 共通部品定義（アオバドライブのものは読んだ） |
| SSP | システム 1 つの実装を「何で、どう満たすか」まで書く | 受発注システム セキュリティ計画書 |
| Assessment Plan | 評価の範囲、対象、作業の段取りを書く | 内部監査計画（2026 年度） |
| Assessment Results | 評価の結果を、事実、判定、リスクの 3 層で書く | 内部監査結果（2026 年度） |
| POA&M | 見つかった問題の是正を、期限と進捗つきで追いかける | 受発注システム 是正計画 |
Profile を解決する
さて、この講座で触れなかった応用的な内容についても、触りだけ紹介します。
第 10 セクションでは、Profile に「6 件から 4 件を選ぶ」「パスワードの最低文字数を 16 にする」「手引きを 1 つ足す」という指定を書きました。その結果を人が読むときは、Profile と選択元の Catalog を行き来する必要があります。
この指定をコンピュータに処理させ、Catalog と Profile をもとに、全く新しい 1 つの Catalog を作ることを、「Profile の解決（Profile Resolution）」と呼びます。
importsを読み、選択元から使う管理策を集めるmergeを読み、集めた管理策の並べ方を決めるmodifyを読み、変数の値や追加の文章を反映する
生成された、全く新しい Catalog のことを、解決済みの Catalog と呼びます。受発注システム基準プロファイルを「解決」すると、選ばれた 4 件、その中のパスワード最低文字数の設定値 16、追加した手引きを含む、きれいな新しい Catalog を得ることができます。Profile が「選び方と直し方の指示書」、解決済み Catalog が「実際に Profile に書かれた指示を適用した結果」です。
講座では 1 つの Catalog だけを選択元にし、merge も as-is だけを使いました。OSCAL の Profile は、複数の Catalog や別の Profile から管理策を集めたり、元の章立てを外して平らに並べたり、新しい章立てを指定したりもできます。規格のベースラインを組織向けに重ねていく場面では、この「解決」の仕組みが使われます。
書いたファイルを検証する
演習では、完成形を「OSCAL の検証を通るファイル」と呼んできました。実務では、保存して終わりにはしません。少なくとも、次の点をコンピュータで確かめます。この操作を「検証」と呼びます。
- YAML として読み取れるか
- 選んだ OSCAL モデルの項目と並び方に合っているか
- Profile の解決など、必要な処理を実行できるか
たとえば、インデントがずれたファイルは YAML として読めません。metadata の必須項目が欠けたファイルは、YAML として読めても OSCAL の決まりには合いません。Profile の href が存在しないファイルを指していれば、Profile 単体の形を確認しただけでは分からず、解決しようとしたところで止まります。
そこで、検証を行い、機械が読める形になっているかを確かめることができます。
この講座で説明を省略した部分
8 モデルのどれにも、講座で使わなかった項目がまだあります。すべてを覚える必要はありません。
たとえば Assessment Plan には、監査の日程だけでなく、確認手順、使用する道具、担当者を詳しく書けます。Assessment Results では、根拠にした証拠を参照したり、年 1 回の内部監査だけでなく定期的な確認結果を同じ形式で積み重ねたりできます。SSP にも、ネットワーク構成、データの流れ、認可の情報などをさらに詳しく置く場所があります。
また、事前に OSCAL に用意された項目だけでは、自社や制度固有の分類を表せないこともあります。そのため props などには、名前空間という「このキーを決めた組織」を示す情報を付けて、独自の値を追加できます。第 6 セクションで使った label や sort-id は OSCAL があらかじめ提供している項目でした。その隣に、自社が意味を決めた項目を、他の組織の項目と混同しない形で置くこともできます。
ファイル形式も YAML だけではありません。同じ内容を XML や JSON に変換して、受け取り側に合う形式で渡せます。また、OSCAL の版が上がれば、新しいスキーマで既存ファイルを検証し、必要な修正を行う必要もあります。書くことに加えて、検証、変換、Profile の解決、版の更新まで含めると、OSCAL を継続して運用するイメージが見えてくるでしょうか。
元も子もないこと
そして、ここまで OSCAL モデルを書いてきましたが、実務上、人間が直接 OSCAL ファイルを修正する機会は、あまり多くないと思われます。すでにアメリカでは実用が始まっている OSCAL ですが、実用の普及に伴い、OSCAL モデルを読み書きする GUI ツールやサービスが多く登場しています。つまり、私たちが直接 OSCAL モデルを触るのではなく、ツールやサービスを使って、間接的に OSCAL モデルを読み書きする仕組みとなっています。
まだ日本国内には、このような OSCAL を取り扱えるツールは十分に普及していません。しかし、今後ツールが普及したとしても、今回学んだ OSCAL のコンセプトや考え方、文法の基礎が無駄になることは決してありません。また、OSCAL を取り扱う事ができるツールを作るのはあなた自身かもしれません。
理解の確認
監査人が Assessment Plan を受け取りました。この計画から、対象システムに適用されるルールの本文（管理策の条文）までたどる経路として正しいものはどれですか。
受発注システム基準プロファイルを解決すると、どのモデルのファイルが出力されますか。
次へ
8 モデルの中心を一周し、その外側にある処理や項目も見渡しました。最後のセクションで、講座全体の完了状況を確かめ、修了証を発行します。Profile の解決や検証を実際に試すときに開く公式資料も、そこにまとめています。
このセクションは OSCAL 1.2.2 系の仕様に基づいて執筆しています。