統制 (Controls)
プロジェクトのControls画面は、スキャン結果をフレームワーク(ISMS-P、DORA、NIS2、CISなど)の要求事項の軸で読み直します。「何%準拠しているか」という単一の数値にまとめる代わりに、自動検証で確認できた部分と、人が証跡を添付しなければならない部分を分けて示します — この2つは性質の異なる事実であり、1つの数値に合成すると、その数値が何を意味するのか誰にも答えられなくなるためです。
1. フレームワークの選択
画面上部でフレームワークを選びます。一覧には、フレームワークごとの要求事項の総数とともに、そのうち**スキャンの点検項目が少なくとも1つ紐づいている数(自動)**と、**点検項目がなく人の証跡でしか判断できない数(手動)**が併記されます。
ISMS-Pの要求事項101件のうち、スキャナーの点検項目が1つでも紐づいているのは26件だけで、残りの75件には点検項目が一切なく、人が提出する証跡でしか判断できません。この比率はフレームワークごとに異なります(DORA・NIS2・CISもそれぞれ独自の数値を持ちます)。「ISMS-Pが自動化されている」という表現は正しくありません — スキャンが答えられるのは101件中26件だけであり、その26件も画面上の自動検証という1つの指標にすぎません。
2. 3つの指標
フレームワークを選ぶと、要求事項は自動検証・手動証跡・未評価の3つに分かれて表示されます。この3つを足し合わせたり平均したりして、1つの準拠率にまとめることはしません。
- 自動検証の通過率 — 点検項目が紐づいた要求事項のうち、今回の評価で実際に実行されたものを対象にした通過率です。分母は「紐づいた点検が今回の評価で実行された要求事項の数」で、紐づいた点検のうち1つでも失敗があれば(受容・抑制された例外を除き)その要求事項は失敗として数えられます。
- 手動証跡の完了率 — 点検項目がなく人の証跡が必要な要求事項のうち、承認済みでまだ期限切れになっていない証跡がある割合です。
- 未評価 — まだ何も言えない要求事項です。点検は紐づいているが今回の評価で一度も実行されなかった場合、または手動の要求事項で証跡がまだ1件もない場合です。
各カードには分母の説明が必ず添えられます — 何件の接続を対象に計算したか、そのうち古い評価(参考としてのみ扱う評価)が何件あるか、未レビュー・除外されたマッピングが何件あるか、どの時点の基準かが、数値と文章の両方で示されます。分母のわからない割合は検証できないため、この画面は割合だけを単独で見せることはありません。
計算対象自体が存在しない場合、「0%」ではなくその事実(と理由)をそのまま表示します。0%は「すべて失敗した」と読まれがちですが、実際には「まだ何も評価していない」だけの場合があるためです。
例外(受容・抑制された問題)は失敗の計算から除外され、同じ画面の例外カードに別途一覧表示されます — 黙って消すのではなく、何が・なぜ例外扱いになったかを残すためです。
3. マッピングの信頼度と「未レビュー」
要求事項表の各行には、その要求事項に紐づく点検項目と信頼度が表示されます。
| 等級 | 意味 |
|---|---|
direct | この点検が要求事項を直接検証すると確認済み |
partial | 要求事項の一部だけを検証すると確認済み |
reference | 参考としてのみ残す(自動指標の計算からは除外) |
excluded | この要求事項の判定から除外すると決定済み(自動指標の計算からは除外) |
unreviewed | 誰も確認していない、スキャナー提供元が定義したマッピング |
unreviewedは人が付ける等級ではなく、「まだレビューされていない」ことの表示です。この値を手動で設定することはできません — もっともらしい等級を勝手に付けると、実際には誰も確認していないマッピングがレビュー済みであるかのようにレポートに残ってしまうためです。
各要求事項の行でマッピングをレビューを開くと、等級とメモを記録でき、その判断が保存されて以降の指標・レポートの計算に反映されます。保存済みの判断(ベンダー定義のマッピングの場合)を削除すると、そのマッピングは再びunreviewedに戻ります — マッピング自体が消えるのではなく、「確認済み」の印だけが消えます。スキャナーの定義にない(要求事項、点検)の組み合わせを自分で追加することもできます。
フレームワーク詳細画面には、レビュー状況のサマリー(ベンダー定義の数・自分で追加した数・除外した数・参考扱いの数・未レビューの数・レビュー済みの数)も表示されます。
4. 手動証跡
点検項目のない要求事項は、人がファイルで証跡を残します。
- 要求事項の行で証跡をアップロードを開きます。担当者と証跡の有効期間(デフォルト365日)を指定し、ファイルを選びます。
- ファイルはこの製品のサーバーを経由せず、お客様所有のストレージ(接続されたAWSアカウントのS3バケット)に直接アップロードされます。アップロードが終わると画面が自動でアップロード確認を要求し、サーバーがそのファイルを改めて読み直して、サイズとハッシュがアップロード前に申告した値と一致するかを確認します。値が異なれば提出として認められません。
- 確認が済むと状態は提出済みになり、承認権限を持つ人が承認または却下します。却下には理由が必須です。
- 承認時に有効期限を指定しなければ、提出時刻+有効期間で自動計算されます。有効期限を過ぎると、保存された値はそのままに、画面には期限切れと表示されます — これは参照した瞬間の判定なので、期限を過ぎた直後の参照から反映されます。
- ファイルを添付する必要がない要求事項(製品・環境上、該当しない場合)は該当なしとして閉じられます。この場合も理由は必須です — 「該当しない」という判断自体がレビュー対象だからです。
証跡の状態はnot_started(未着手)・submitted(提出済み)・approved(承認済み)・rejected(却下)・expired(期限切れ)・not_applicable(該当なし)のいずれかで表示されます。
証跡ファイルの実体は常にお客様所有のバケットにのみ存在します。この製品のデータベースにはファイル名・サイズ・ハッシュ・状態・担当者・承認履歴だけが残り、ファイル本体は保存しません。ダウンロードもそのバケットを指す期限付きリンクとしてのみ行われます。
接続グループ(複数アカウントをまとめた組織プロジェクト)単位でアップロードした証跡は、グループに属するすべての接続に適用されます。
5. ドキュメントプロファイル
統制レポートを生成を押すと、選んだフレームワークに合った文書の型でPDFが作成されます。プロファイルはフレームワークに応じて自動選択され、必要なら別の型で作り直すこともできます。
- ISMS-P点検項目体系 — 要求事項ごとに点検項目・証跡一覧・不適合事例の節を持つ文書を作成し、冒頭で「101件中26件が自動検証可能」のように自動/手動の比率を明示します。
- DORAテストレポート — 範囲・頻度・使用ツールとバージョン・実行履歴を冒頭に記載し、柱(Pillar)・条項(Article)でまとめて要求事項を列挙します。
- NIS2附属書 — 節・小節でまとめ、3分割指標・例外・推奨事項を附属書形式で整理します。
- 汎用 — 上記3つに当てはまらないフレームワーク向けの要求事項表です。
どのプロファイルでも、3分割指標とその分母、例外一覧、マッピングのレビュー状況、点数の算式・基準バージョン、文書自体のハッシュが共通して含まれます。レポート本文(要求事項・点検・証跡・相互参照の全量)もお客様所有のストレージに書き込まれ、この製品のデータベースにはサマリーとハッシュ・バージョン情報だけが残ります。本文を読み込めない場合(ストレージへのアクセス障害など)はレポート自体を作成しません — 内容が欠けた文書を出力しないためです。
6. フレームワーク横断マトリクス
同じ点検項目が複数のフレームワークの要求事項に紐づくことがよくあります。要求事項の詳細で相互参照を開くと、この要求事項が他のフレームワークでは何と呼ばれているか(同じ点検を共有する要求事項の一覧)を確認できます。1つの統制を複数の規制対応に再利用できるかを確認する場所です。
7. 接続グループ範囲
複数のAWSアカウントをまとめた組織プロジェクトでは、グループページのControlsタブでグループ全体の3分割指標・例外・レポートを確認します。ただし、グループ内のアカウントごとに実行結果が異なる場合があるため、要求事項ごとの詳細表はグループ画面には表示されません — アカウントごとに異なる答えを1つにまとめると、誤った判定になってしまうためです。要求事項単位の詳細を見るには、グループに属する個別の接続のControls画面を確認してください。
8. 点数と関連ドキュメント
自動検証の通過率は、プロジェクトのリスク評価(スキャン)結果をそのまま読み取ります。各finding(検出項目)がどのような根拠で点数と深刻度を得たかは、リスクスコアの説明を参照してください。アクセス権限レビューについてはアクセスレビュー、この画面の成果物をデータの保管場所・監査履歴とともに署名済みの束として受け取るには証跡パッケージを参照してください。