SQL によるセキュリティ監査分析
セキュリティ レポートは、すべての特権操作に制御されたアクション名、リソース クラス、アクター ロール、ポリシーの結果、およびレビュー状態がある場合に役立ちます。自由形式のメッセージでは、これらの次元を比較することが難しく、誤って資格情報やプライベート リソースのコンテンツが含まれる可能性があります。
報告契約の範囲を維持する
特権アクションが最終結果に達したときにイベントを発行します。推奨されるフィールドは次のとおりです action, resource_type, actor_role, outcome, requires_review, policy_version, environment、そして timestamp_utc。一般的なダッシュボードには通常、電子メール アドレスではなく、ロール クラスが必要です。承認されたアクターとリソースの識別子を、アクセス ログを使用して制限された調査パスに配置します。
パスワード、API キーの値、セッション トークン、認証ヘッダー、未加工のエクスポート、無制限のリクエスト本文、または完全なポリシー入力を決して収集しないでください。セキュリティ テレメトリは、自動的に不変のコンプライアンス アーカイブになるわけではありません。セキュリティ所有者とともに証拠の保管、保持、およびアクセス要件を定義します。
失敗の確認とキューの確認
の 特権アクション監査 SQL レシピ 共有の失敗または拒否によってアクション クラスをランク付けし、同じ出力内の絶対レビュー量を維持します。その決定論的フィクスチャは、ローカルで実行できます。 SQL 遊び場.
アラートを発行する前に、結果を分類します。
- 予想されるポリシー拒否により、制御が機能していることが示される可能性があります。
- 同じ承認されたアクタークラスによる繰り返しの拒否には、調査が必要になる場合があります。
- 新しい特権アクションは、インストルメンテーションまたはロールアウトの変更を示す場合があります。
- 成長する
requires_reviewすべてのアクションが成功した場合でも、キューは操作上の所有権の問題です。
を使用します。 認証失敗レシピ 認証試行と管理アクションを混合するのではなく、サインイン結果を確認します。
クエリを運用可能にする
ダッシュボードには、アクションの合計、拒否または失敗したアクション、失敗率、レビューが必要な数、およびポリシーのバージョンが表示される必要があります。アラートには、繰り返し拒否された試行、新しいアクション クラス、期限を過ぎたレビュー キューなどのレビュー済みの条件が必要です。
の セキュリティ監査分析の使用例 インストルメンテーションプロンプトを提供します。また、 機密データ編集ガイド プロデューサ境界にあるため、安全でない値がテーブルに入ることはありません。