継続的コンプライアンスをVantaによる「途切れない証明」の実現

設計思想を「常時適合」へ ～ 継続的な証明の技術的ボトルネック解消

前回の記事である「設計から安全」を組み込む ～ Vantaで証明する継続的なセキュリティで解説したセキュリティ・バイ・デザイン（SbD）は、いわば「安全な設計図」です。しかし、どれほど完璧な設計図があっても、実際の運用でそのルールが守られ続けていることを証明できなければ、パートナー企業や顧客から真の「信頼」を勝ち取ることはできません。

セキュリティ・バイ・デザイン（SbD）の本質は、開発や運用のプロセスが固まった後に不備を補う「場当たり的な対応」を最小化することにあります。設計段階での考慮が不足していると、対策を後付けするたびにシステムの複雑性が増し、結果として管理しきれない脆弱性を生む要因となります。

複雑化したシステムでは、「運用段階で設計時の安全思想が継続していること」を証明しようとすると、今度は「作業の手間と時間」が最大のボトルネックとして立ちはだかります。システムを横断した手動での証拠収集や、取引先への報告は信頼構築に欠かせない重要な活動ですが、そのための手動による証跡収集や膨大な準備作業が、結果として技術者が本来注力すべき「本質的なセキュリティ対策」を圧迫する要因となってしまうためです。

これこそが、継続的なセキュリティ維持における構造的な課題です。Vantaが実現する「途切れない証明（Continuous Compliance）」は、API連携によってシステムの現状をリアルタイムで監視し、設計思想からの乖離を即座に検知・通知する基盤を提供します。報告のための特別な準備という「事後対応」から、異常を即座に是正する「常時適合」の運用へとシフトさせることで、結果として技術者の負担を本質的に軽減します。

SbDと「途切れない証明」のマッピング

セキュリティ・バイ・デザイン（SbD）に基づく主要な管理領域に対し、Vantaは「技術的な自動テスト」と「管理的な証拠収集」の両面からアプローチします。これにより、各領域における継続的な適合証明を、高い精度で実現することが可能になります。

該当するSbD原則	Vantaの自動証明の役割	Vantaの具体的な証明機能の例
組織的なセキュリティ	情報セキュリティ規程の承認と組織的な浸透状況の証明	ポリシーの承認と正当性の担保 責任者によるポリシーの確認・承認履歴を記録し、「組織として定義されたルール」の存在を証明する
		従業員への周知と同意状況の継続的なトラッキング(捕捉) 従業員へのタスク割り当てと、最新の同意ステータスの定期的なトラッキングにより、運用の実態を証明する
資産管理 / リスク評価	資産・アカウント状況の可視化と設定リスクの自動判定	外部連携によるIT資産情報の同期と集約 MDMやクラウド基盤とAPI連携し、定期的な自動取得によって外部ツールの情報を同期することで、資産リストの鮮度を維持する
		非アクティブなアカウント等の自動判定 アカウントや認証キーの最終利用日データを参照し、設定した基準（例：90日以上未使用）を満たさない対象を、リスト上で「不適合（Fail）」として自動的にフラグを立てる
		アクセス権レビューの実施ログの管理 定期レビューの期日に合わせて担当者にタスクを割り当て、各権限への判断結果を「監査レポート」として出力可能な状態で保持する
セキュア・バイ・デフォルト	技術統制の定期的な自動確認	セキュリティ設定不備の検知とアラート IdPやクラウドの設定を定期的に参照し、基準を満たさない項目を「不合格（Fail）」として記録。修正が完了するまで未解決の課題（Remediation task）として記録する
		エンドポイントの構成チェック MDM（Jamf/Intune等）と連携し、全端末にディスク暗号化やスクリーンロック、アンチウイルスソフトの導入といった「保護設定の配布と強制」が実施されているかを可視化。さらに、Vantaデバイスモニタが各端末の実態を継続的にスキャンし、MDMの設定が意図通りに維持されているか、定義ファイルが最新かといった「不備（NG）の自動検出」を行う
予防的対策	脆弱性対応状況とリスク設定の継続的なモニタリング	脆弱性状況と設定不備の特定 連携ツール（AWS Inspector/GitHub等）の情報を参照し、検知された脆弱性がSLA（規定期間）内に修正されたかを記録
		セキュアな開発環境の維持確認 GitHub等の設定をスキャンし、ブランチ保護が有効でないリポジトリを不備（Fail）として特定
最小権限 / アクセス管理	ID紐付けに基づくアカウント情報の整合性確認	アカウント管理の健全性チェック SSO連携や手動設定（直接入力）で紐付けた個人のステータスに基づき、連携先システムにおけるアカウントのアクティブ・非アクティブ状態を照合する
		アカウント管理の状況照合とリスク特定 退職者の削除漏れアカウントや長期間未使用のIDを特定し、非アクティブ化などの必要な是正アクションを提示する
組織的手順の確立	不備・教育状況の客観的な証跡管理	教育履行状況の記録参 従業員へのセキュリティ研修の受講状況をトラッキング
		外部管理ツールとの連携による自動起票 検出された不備を手動または条件設定により自動でJira等のチケットとして発行
		再テストによる是正結果の判定 不備検知時にJiraチケットを自動発行（自動発行可能なものとそうでないものがある）。テストは設定されたSLAに基づき実行される。自動テストのタイミングで担当者により設定変更がなされ、設定が正しくなっていれば、不備（Fail）の表示が消え、合格（Pass）に切り替わる。

自動証明がもたらす実務プロセスの変革

この章では、第1章で確認した具体的な自動テストが、従来のプロセスをどう変革するかを解説します。

従来のセキュリティ評価プロセスは、時間的に非連続で手動でした。Vantaが実現する「途切れない証明」（Continuous Compliance）の仕組みは、その従来のサイクルを、「証拠の収集」、「不適合の修正」、「継続的な検証」という3つの論理的なステップで根本的に変革します。

従来のプロセス（Before）とVanta導入後の変革（After）

監査プロセスのステップ	従来のプロセス（Before）とその課題	Vanta導入後のプロセス（After）とそれによる変革
1. 証拠の収集	監査直前の「証跡かき集め」作業 担当者がシステムを横断し、ログや設定のスクリーンショットを手動で収集・保管。	証跡管理の一元化とプロセス化 API連携により、統制ルールに基づいた証跡を自動収集。「いつ、どういう状態だったか」を改ざん不可能な形で記録・蓄積。
2. 不適合の修正	属人的で非効率な連絡プロセス 評価時に不備が発覚するたび、担当者が内容を確認し、修正指示をメールやチャットで個別に作成。修正完了の報告を受けた後も、再び担当者が証拠を手動で取得・確認しにいくという、人手を介した非効率なやり取りが多発	是正アクションの可視化と迅速化　 Vantaが自動で不適合を検知。自動連携が可能なテストに関しては、Jiraへのチケット送出と担当者への情報伝達までを自動化し、是正の初動を迅速化する。また、設定されたSLA（期限）に基づく自動再テストにより、修正完了を即座に判定・記録する。
3. 継続的な検証	評価イベントごとの「手動監査対応」 監査のタイミングだけ整合性を合わせる「点」の運用。評価期間外の状況がブラックボックス化し、次の評価時に不備が蓄積された状態で発覚するなど、対策が一時的な「取り繕い」に終始し、実態が伴わない形骸化の懸念が発生。	継続的な準拠確認（Continuous Compliance）の実現 SLAに基づいた自動検証を繰り返し実行し、統制状況を定常的にモニタリング。評価と実運用を同期させることで、監査直前の負荷を大幅に軽減し、持続可能なガバナンス体制を構築します。

1. 証明作業のワークフロー化 (証拠の収集を自動化)

ここでは、ガバナンスの維持やリスク特定に不可欠な「組織的・人的な証跡管理」を、Vantaによってどのように日常の運用プロセスへ統合できるかを、具体的な設定イメージとともに解説します。
従来、人手による回収や管理が中心だったポリシーの周知徹底（例：ISO27001:2022 管理策番号A.5.1）や資産目録の整備（例：ISO27001:2022 管理策番号A.5.9）といった管理項目を、システム連携を通じて自動化・標準化する手法を示します。

設定の例と実現されるSbD

資産インベントリの自動化（Intune連携の具体例）

Vantaでのアクション
VantaのIntegrations (連携) 画面 で、Microsoft Intuneの連携ボタンを押し、必要なアクセス権限を付与します。

実現されるSbD
複雑な手作業なしに、「リスクの特定」に必要な資産管理台帳（従業員のPCなど）がIntune経由でリアルタイムにVantaへ取り込まれ、自動更新されます。これにより、監査のための証拠収集作業がゼロになります。
インテグレーションされるとAssets>Inventry>Computers (MDM) に次のような資産台帳として表示されます。

ポリシー承認の自動化

ポリシー文書の格納と同期
Microsoft SharePoint または Google Drive または Confulence にポリシー文書を格納し、VantaのPoliciesページからSync a file（ファイルを同期）を選択し、連携済みのストレージからポリシーファイルをVantaへ同期します。

従業員グループへのポリシー同意設定（Onboarding/Offboarding）
VantaのPeopleメニュー内で、同期された従業員リストを基にグループを定義・作成します。このグループのTasksタブで、Onboarding and recurringセクション内のPolicies（ポリシー）に同意タスクを設定できます。ここで設定を行うと、従業員が登録された際や、退職する際に、ポリシーに同意するためのリマインダーを自動で送ることができます。

送信されるリマインダーメール

実現されるSbD
「ガバナンスの整備」に必要な「従業員がポリシーを読み、同意した」という監査可能な証拠（誰が、いつ、どのバージョンのポリシーを承認したか）が自動で記録されます。また、同意状況は常に可視化され、未完了者への通知（リマインド）などを通じて実態を継続的に把握できます。

2. 検出から修正まで (不適合の修正を自動化)

ここでは、セキュリティ上の不適合の発生から修正完了までを、Vantaがどうワークフロー化するかを解説します。

設定の例と実現されるSbD

チケット連携の設定と自動起票

Vantaでのアクション
VantaのIntegrations(連携) 画面で Jira などのタスク管理システムとの連携を設定した後、設定画面でAutomatic task creation（自動タスク作成）機能を有効化します。

実現されるSbD
Vanta が、ISO 27001: 2022 - A.5.36（情報システムのテスト）のテストを例に挙げると、「パッケージ内で特定された中程度の脆弱性が（GitHubリポジトリで）対処されている」というテストの結果、不適合（Fail）を検知した瞬間、Jira へタスクを自動で起票し、担当者へ割り当てます。このテストは、Vanta がGitHub の Dependabot などのセキュリティ機能に対し、依存関係の中に中程度の脆弱性が特定されているかどうか、また、その脆弱性が未解決なのか解決済みなのかをAPIを経由して取得することで実行されます。「不適合の発見と修正指示」という事後対応が、技術者の手動操作なしに組織のタスク管理システムに組み込まれます。

SLA（修正期限）に基づく是正状況の可視化

• Vantaでのアクション
  VantaのSettings (設定)メニュー内のSLAsセクションで、セキュリティアラートの重大度や脆弱性のカテゴリ（例：Vulnerabilities: Medium）ごとに、組織のポリシーに合わせてSLA（例：7日以内）を変更・適用します。

実現されるSbD
Vantaは設定されたSLAに基づき、不備の解消状況を自動でモニタリングし、期限を過ぎた項目についてはアラートを通知します。これにより、リスクの放置を未然に防ぐ仕組みが構築され、「インシデントへの対応」に必要な是正プロセスの透明性と客観性が担保されます。

3. 継続的な検証 (信頼性を保証する継続的監視)

ここで)は、Vantaの継続的な監視を通じて実現された「常時適合（Always-on Compliance）」の体制下で、技術者が日常的に確認すべきポイントと、その最新の適合状況を取引先などの検証者へどのように提示し、信頼性を維持するかを解説します。

設定の例と実現されるSbD

日常的な技術統制の確認

Vantaでのアクション
技術者は、まずComplianceメニュー内のFrameworks（フレームワーク）画面でISO27001:2022のフレームワークの進捗を確認します。次に、Controls（統制）タブまたはTests（テスト）メニューへ移動し、以下の手順でリスクのある項目を抽出します。

• フレームワークフィルター
  ISO27001:2022のフレームワークを選択し、関連する統制のみを表示します。
• 不適合項目の抽出
  リスト内で、Status（ステータス）がNeeds evidence（証拠が必要）となっている項目だけをフィルタします。
• テスト結果の確認
  さらにTestsタブをクリックし、Overdue（期限超過）やNeeds remediation（修正が必要）のカテゴリでフィルタされたリストから、Jira への自動起票が漏れていないかを最終的に確認します。Jira のタスクを自動起票しないタイプのテストに関しては Jiraの タスクを Vanta のタスク画面から作成できます。

実現されるSbD
技術者は、リスクのある項目だけに焦点を当てて日常的な確認を行うことで、SbDが目指す「セキュア・バイ・デフォルト」の状態が効率的に維持されているかを確認できます。

人事ライフサイクル（オフボーディング）の監視

Vantaでのアクション
Peopleメニューのグループ設定で、OffboardingセクションのAccess removal（アクセス削除）タスクを有効にします。

実現されるSbD
「攻撃などの検知」においては、特に「退職者のアクセス権残存」によるリスクを自動で監視します。SSO/IdPでユーザーが無効化された後、各システムからアクセス権が確実に削除されたかを自動チェックし、削除漏れがあれば即座に通知します。

監査人（取引先）への情報開示（Auditor Viewの活用）

Vantaでのアクション
Vantaの「Auditor (監査人) View」機能を活用し、取引先や評価担当者に対して、「どの認証規格や管理策（コントロール）の準拠状況を開示するか」を柔軟に選択し、限定的な閲覧権限を付与します。

実現されるSbD
情報開示プロセスにおいて、「相手が必要な情報（規格・管理策）のみにアクセス範囲を限定する」という設計をシステム的に実行します。これにより、不要な情報の誤開示を構造的に排除し、安全かつ透明性の高い情報開示を実現します。

技術者が求める「本質的なセキュリティ」への集中と信頼の自動構築

本記事では、Vantaが「途切れない証明」（Continuous Compliance）を実現する具体的な実践方法を見てきました。Vantaが実現するプロセスは、単に手間を減らすだけでなく、セキュリティ担当者の仕事の質そのものを変革します。

従来のプロセスでは、技術者はその時間の多くを、「監査のための証拠収集」や「事後的な是正措置の追跡」といった、煩雑で手動の証明作業に費やさざるを得ませんでした。これは、システムや設計の本質的な改善に集中すべき時間を奪う、大きな技術的ボトルネックでした。

Vantaを導入し、証明作業を日常のワークフローに組み込むことで、技術者はこの「証明の手間」から解放されます。

• 煩雑な手作業の排除 → セキュリティの「設計と最適化」へリソースをシフト
• 後付けのパッチ当てを排除 → 構造的な弱点をなくし、戦略的なリスク低減に集中
• 「点」ではなく「線」での適合証明 → 監査のための「一時的な整合」を脱却し、常に最適化された状態を維持する「戦略的なセキュリティ向上」へと転換

Vantaの自動証明は、セキュリティ・バイ・デザイン（SbD）という強固な設計思想が、日々の運用において確実に実践されていることを証明し続ける基盤を提供します。技術者が本来の使命である「システムを守る」という活動に注力できる環境こそが、パートナーや顧客からの揺るぎない信頼へとつながるのです。