監査前の「火消し」なしで、セキュリティコントロールを定期検証

Zero が指定したペースでセキュリティ設定をチェックし、各コントロールが正しく設定されていることを検証し、監査週の前にコンプライアンスチームへ差分を報告します。

Zeroの接続先:

すべての監査が2週間の火消しになる理由

監査はかつて四半期ごとの全社火消しでした。すべてのファイアウォールルール、IAMポリシー、アクセスレビューのスクリーンショットを、監査人が来る直前の1週間で手作業で集める。コントロールは誰にも気づかれずにドリフトし、是正は危機モードで行われました。継続的コントロール検証は、安定したペースでチェックを回し、ドリフトは監査の前週ではなく発生した週に捕捉されます。コンプライアンスチームには日付入り・署名入りの検査記録、エンジニアリングにはドリフト時のアラート、監査人にはすでに整理された証拠が届きます。

Zero にコントロール検証を依頼する方法

@Zero 毎週月曜の朝7時に、セキュリティコントロールを検証して。ファイアウォールルールが Notion のベースラインに一致、必要な GitHub branch protection が `main` で有効、どのリポジトリでも2FAが無効になっていないこと。結果をコントロールデータベースにログし、ドリフトがあれば #compliance にアラートして。

試してみる

Zero がセキュリティコントロールを検証する流れ

Zero が現在のセキュリティ設定を取得

Zero は信頼できる情報源となるコントロール（branch protection、IAM、ファイアウォールルール、アクセスレビュー）を、それらが存在するシステムから読み込みます。サンプリングなし。対象範囲のすべてのコントロールが毎回チェックされます。

Zero が定義されたベースラインと比較

期待される設定は Notion データベースに存在します。Zero は現在の状態をベースラインと比較し、ドリフトをフラグ付けし、タイムスタンプと証拠リンクとともにコントロールごとの合否を記録します。

Zero が結果をログし、ドリフトをアラート

各実行はコントロールデータベースに日付入りレコードを書き込みます。ドリフトがあれば、コンプライアンスチャンネルとコントロールを保有するエンジニアをタグ付けした Slack アラートがトリガーされます。監査人には改ざん不能な履歴が残ります。

差分を是正、カバレッジ拡大、またはスケジュール固定

ドリフトを是正

Zero にドリフトを自動修正するチケットやPRを開かせる。

@Zero branch protection のドリフトがあれば、protection ルールを復元するPRを開いてリポジトリオーナーをタグ付けして。

試してみる

コントロールカバレッジを拡大

検証スイープに新しいコントロールファミリーを追加。

@Zero 週次検証に GDPR コントロールを追加して。DPA遵守、削除リクエスト対応時間、クロスボーダー転送ログ。

試してみる

スケジュールを強化

高リスクコントロールを週次から日次に。

@Zero prod DB アクセス検証は週次ではなく日次で実行して。他は週次のままで。

試してみる

必要なインテグレーション：GitHub、Notion、Slack

GitHub

GitHub：Zero は対象のすべてのリポジトリについて branch protection、リポジトリ権限、2FAステータスを読み込みます。組織設定への読み取りアクセスが必要です。

必須

Notion

Notion：Zero はベースライン設定を保存し、検証結果を書き込みます。2つのデータベース（ベースラインと結果）への読み書きアクセスが必要です。

必須

Slack

Slack：Zero はドリフト時にコンプライアンスチャンネルへアラートし、週次サマリーを投稿します。チャンネルへの書き込みアクセスが必要です。

必須

継続的コントロール検証のベストプラクティス

●ベースラインは1箇所にまとめる（Notion、Drata、または自社の CMDB）。分散したベースラインは静かにドリフトし、Zero はドキュメント化されていないものをチェックできません。

●「ドリフト」と「例外」を分けること。ドリフトは承認なしで変わったコントロール、例外はチームが承認した逸脱です。Zero は両者を別々に扱うべきです。

●監査シーズンにサマリーを流し込みましょう。監査人は継続的ログが大好きで、「2年間毎週これをやってきた」は「先週チェックした」よりはるかに強いストーリーです。