CISO Assistant を採用する前に見るべき構成と制約

CISO Assistant が埋めようとしている穴

GRC の実務では、リスク登録簿、統制の証跡、第三者評価、監査対応が別々のツールや表計算に散らばりやすい。同じ統制を ISO 27001 と SOC 2 の両方で書き直す作業が発生し、フレームワークを増やすたびに二重管理が膨らむ。CISO Assistant はこの重複を、オブジェクト間のリンクと自動マッピングで減らすことを狙ったプラットフォームである。README は「compliance from cybersecurity controls」を明示的に分離すると述べており、統制をコンプライアンス要件から独立した再利用可能な単位として扱う設計方針が読み取れる。想定利用者は、複数の規格を同時に維持する必要があるセキュリティ責任者、ISMS の運用担当、監査対応を兼務する少人数チームである。対象は企業の情報システム部門に限らず、MSSP のように複数顧客の準拠状況を扱う立場も想定されている。

API-first と再利用を支えるデータモデル

README が繰り返し述べるのは、compliance と control を分離するという方針である。統制を独立したオブジェクトとして定義し、フレームワーク側の要件から参照させる。同じ統制が ISO 27001 の附属書統制にも NIST CSF のカテゴリにも紐づくため、フレームワークを追加しても統制の記述を書き直さずに済む。自動マッピングと Mapping Explorer はこの関連を可視化する機能で、どの要件がどの統制でカバーされているかを確認する入口になる。設計は API-first と明記されており、UI の操作も外部自動化も同じ API を経由する。README には Kafka を含む入出力チャネルが列挙されているため、既存のチケットシステムや SIEM との連携を API 側で組む前提だと考えてよい。リスク評価、是正追跡、EBIOS RM、事業継続影響分析、サイバーリスクの定量化まで、機能一覧は1つのデータモデル上に載る。モジュールを別製品として足すのではなく、同じオブジェクトグラフを共有する構成だと理解しておくと、導入後の拡張判断がしやすい。

docker-compose.sh で立ち上げるまで

README が示す最短手順は Docker と Docker Compose を前提とする。リポジトリを単一ブランチで取得し、起動スクリプトを実行する。

git clone --single-branch -b main https://github.com/intuitem/ciso-assistant-community.git ./docker-compose.sh # Linux/MacOS ./docker-compose.ps1 # Windows

スクリプトは事前ビルド済みイメージを使うと README に記載されている。Windows では Docker Desktop と WSL2 が必要で、PowerShell 版が Docker Desktop に設定を渡す挙動になると説明されている。ホストのアーキテクチャとイメージのプラットフォームが一致しない警告が出る場合は、docker-compose-build.sh で自環境向けにビルドする選択肢が案内されている。メール送信などの追加パラメータは docker-compose ファイル側で渡す。セルフホストの他の選択肢は config ディレクトリの設定ビルダーと GitBook のドキュメントに誘導されている。クラウドの無償トライアルも用意されているため、構成を確かめるだけならそちらで機能を触り、自組織のデータ管理要件に合うかを先に判断する順序もある。

main ブランチを本番に置かないという警告

README の注意書きは明確である。main ブランチは開発中のマージ先であり、破壊的変更が入り得るため本番利用は避け、タグ付きの安定版か事前ビルドイメージを使うよう求めている。デプロイ手順を自動化する場合、追跡対象を main ではなくリリースタグに固定する必要がある。ここは運用設計に直接影響する制約で、CI で latest を引く構成のままだと、検証していない変更が本番に入る。リリースは v4.0.1、v3.21.4、v3.21.3 のように版が並んでおり、メジャー更新とパッチ更新が同じ系列で流れている。アップグレード時はタグ間の差分を確認し、スキーマ変更の有無をリリースノートで追う作業が前提になる。セルフホストではこの追跡コストがそのまま運用負荷になる点を、導入前に見積もっておきたい。

ライセンス表記が NOASSERTION のままである意味

リポジトリのライセンス識別子は NOASSERTION であり、GitHub が既知のライセンスとして認識していない状態を示す。これは「ライセンスが存在しない」ことと同じではないが、識別子だけから利用条件を判断できないという意味では同じくらい扱いにくい。README にはライセンス条項の説明がなく、ホームページとドキュメントへの導線があるのみである。自組織で本番運用するなら、リポジトリ内のライセンスファイルと配布元の記載を直接確認し、法務の確認を通す必要がある。ここで法的な助言はできないが、識別子が未確定のまま大規模展開する判断は避けるべきである。ソースが公開されていることと、商用利用や再配布が許諾されていることは別の話であり、この区別を曖昧にしたまま導入計画を進めると後工程で詰まる。

SaaS 型 GRC との設計の違い

比較対象として分かりやすいのは、Vanta や Drata のような SaaS 型のコンプライアンス自動化サービスである。これらの多くは、クラウド事業者の API に接続して設定を収集し、証跡の取得を自動化する方向に力を置く。統制の実装状況を技術的に検出し、監査人向けのレポートに落とす流れが中心になる。CISO Assistant は逆の重心を持つ。データを自組織のインスタンスに置き、フレームワークと統制の対応関係を編集可能なオブジェクトとして管理する。自動検出よりも、複数規格のマッピングとリスク評価のワークフローを同じ場所で回すことに主眼がある。したがって、クラウド設定の継続的な監視を主目的にするなら SaaS 型のほうが向く。逆に、規格間の対応表を自組織で保守したい、データを外部に出したくない、EBIOS RM や事業継続影響分析まで同じ基盤で扱いたい場合は、この設計のほうが噛み合う。どちらが優れているかではなく、何を自動化したいかの違いである。

向く組織と向かない組織、最初に確かめること

採用が向くのは、複数のフレームワークを並行して維持し、統制の記述を再利用したい組織である。Docker を扱える担当がいて、アップグレードをタグ単位で追える体制があれば、セルフホストの負荷は現実的な範囲に収まる。向かないのは、専任の運用担当を割けない組織と、ライセンス条件が確定するまで本番展開を保留したい組織である。前者はアップグレードとバックアップの作業が滞留し、後者は識別子が NOASSERTION である以上、判断を先送りする理由が残る。導入前に確かめるべきは3点ある。1つ目はリポジトリ内のライセンスファイルの内容。2つ目は config ディレクトリと GitBook のドキュメントにあるメール送信設定とバックアップ対象のボリューム。3つ目は追跡するリリースタグを決め、main を本番から外すことである。無償トライアルで画面を確認するだけでは、この3点は埋まらない。

更新コストはタグ追跡とスキーマ差分に集約される

維持コストの大半は、リリースタグの追跡とデータベーススキーマの差分確認に集約される。v3.21.3 から v3.21.4 のようなパッチは比較的軽いが、v3 系から v4.0.1 のようなメジャー更新では、オブジェクトの構造や API の挙動が変わり得ると考えるのが自然である。README は破壊的変更が開発中に起こり得ると明記しており、この前提はセルフホスト運用の計画に直接効いてくる。バックアップはアップグレード前の必須手順として組み込み、ロールバック先のイメージタグも同時に固定しておく。API-first の設計は自動化の余地を広げるが、その分だけ外部連携側も API 変更に追随させる必要がある。連携スクリプトを多く抱えるほど、更新時の確認範囲は広がる。導入初期に連携を絞っておくことが、結果として更新コストを抑える。

編集部の結論

採用を検討すべきなのは、ISO 27001 や NIS2 などの複数フレームワークを横断して管理し、コンプライアンスと制御を分離して再利用したい組織である。Docker と Docker Compose を扱える運用担当者がいない場合や、監査証跡を SaaS ベンダーの管理下に置きたい場合は向かない。最初に確認するのは、リポジトリのライセンス表記が NOASSERTION のままであり、法務判断を保留したまま本番導入できるかを自組織で決められるかどうかである。次に config ディレクトリと GitBook のドキュメントで、メール送信設定とバックアップ対象のボリュームを特定しておく。

公式情報源

1. intuitem/ciso-assistant-community on GitHub
2. Issues
3. Project website
4. README
5. Releases