セキュリティチームは、まずルールを作成することから始めることが多い。しかし時間の経過とともに、それらのルールは増殖し、方向性がずれていき、一貫性を失っていきます。たった数件の検出が、すぐにロジックの重複や名前における一貫性の欠如、変更者についての可視性の限定など、運用上の課題をもたらします。
検出エンジニアリングが変化をもたらします。検出結果をコードとして管理することで、企業チームはソフトウェアを出荷するのと同じ方法で、SIEMコンテンツのバージョン管理やレビュー、テスト、そしてデプロイメントを行うことができます。
このガイドでは、次のことを行う方法を説明します。
- Sumo Logic Cloud SIEMのルールをGitHubリポジトリに保存する
- 一貫したデプロイメントのためにTerraformを使用する
- 検証と自動化のためにGitHub Actionsを適用する
- OIDCを使用してTerraformの状態をAWS S3に安全に保存する
目標：SOCにDevOpsの厳密さをもたらす。これにより、すべての検出はバージョン管理され、テスト可能かつ繰り返し可能になります。
コード検出が重要となる理由
| 課題 | コード検出によって可能になること |
| ルールにおける逸脱と矛盾の解決 | バージョンの集中管理による一貫性の強化 |
| 手動デプロイメントとヒューマンエラーの解決 | 自動化されたCI/CDパイプラインによる予測可能なロールアウトの実現 |
| 限定的なコラボレーションの解決 | プルリクエストの適用による全ルールの監査およびレビューの実現 |
| 困難なロールバックやテストの解決 | バージョン履歴による安全なプロモーションおよび即時のロールバックの実現 |
コード検出は、SIEMを静的な構成から、エンジニアリングの規律に基づいて設計、テスト、およびデプロイされた生きたシステムへと変えます。
構築するもの
次のことを可能にするGitHubリポジトリを作成します。
- Cloud SIEMの検出をコード（YAMLまたはJSON形式）として保存する。
- Terraformを使用してSumo Logic環境に変更を適用する。
- GitHub Actionsを通じてデプロイメントを自動化する。
- OIDC（静的認証情報なし）を使用してTerraformの状態をAWS S3バケットに保持する。
このアーキテクチャにより、手作業によるエラーが排除され、反復が加速されるほか、すべての環境にわたる完全な監査可能性がSOCに対し提供されます。
セットアップ手順
ルール管理用のGitHubリポジトリは、組織アカウントの下に設定することを推奨します。ルール管理リポジトリは、他の機能や製品と共有しないことを推奨します。
前提条件
- 状態管理用のS3バケットを備えたAWSアカウント
- Githubアカウントとリポジトリ – 新規リポジトリの作成 – GitHub Docs
- Sumo Logicアカウント
資格情報
AWS認証情報とSumo Logic認証情報はGitHub Secretsに保存されます。Terraformはこれらの認証情報を使用してAWSおよびSumo Logicへの認証を行います。
Sumo APIの資格情報
Sumo Logicの資格情報を取得する手順はこちらをご覧ください
AWSのセットアップ
AWSのバケット作成および資格情報は、以下の手順により取得可能です。
- AWSコンソールで、S3ページに移動し（検索バーで「S3」と検索）、「Create bucket」をクリックします。
- バケットに希望する名前を入力し、残りのオプションはデフォルトのままでバケットを作成します。
- 「IAM」>「Policies」ページに移動し、「Create Policy」をクリックします。
- ポリシーエディターをJSONビューに切り替え、「Statement」フィールドを以下のものに置き換えることで「bucket-name」をステップ2で作成したバケットの名前に置き換えた後、「next」をクリックします。
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "s3:ListBucket",
"Resource": "arn:aws:s3:::bucket-name",
"Condition": {
"StringEquals": {
"s3:prefix": "terraform-state"
}
}
},
{
"Sid": "VisualEditor1",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject"
],
"Resource": "arn:aws:s3:::bucket-name/terraform-state"
},
{
"Sid": "VisualEditor2",
"Effect": "Allow",
"Action": [
"s3:PutObject",
"s3:GetObject",
"s3:DeleteObject"
],
"Resource": "arn:aws:s3:::bucket-name/terraform-state.tflock"
}
]
- 次のページで、ポリシーに任意の名前を入力し、「Create Policy」をクリックします。
- こちらの手順に従って、AWSにIDプロバイダを追加します：https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_create_oidc.html#manage-oidc-provider-console
- プロバイダのURLには次を使用します：https://token.actions.githubusercontent.com
- 「Audience」には次を使用します：sts.amazonaws.com
- 「IAM」>「Roles」ページに移動し、「Create Role」をクリックします。
- 「Trusted entity type」で、「Web Identity」をクリックし、IDプロバイダとして「token.actions.githubusercontent.com」、オーディエンスとして「sts.amazonaws.com」を選択します。このリポジトリがフォークされるGitHub組織の名前を入力し、[次へ]をクリックしてください。
- 「Add Permissions」ページで、ステップ5で作成したポリシーを選択します。
- 適切なロール名を入力し、「Create Role」をクリックします。
- GitHubリポジトリの「Settings」>「Secrets and variables – Actions」>「Variables」で、
「AWS_ROLE_ARN」、「BUCKET_NAME」、「BUCKET_REGION」の変数を、先ほど作成したバケットのロールのARN、バケット名、およびリージョンと置き換える、または追加します。 - GitHub Actionsにおけるシークレット
- Sumo Logic の認証情報（個人アクセスキー）はリポジトリのシークレットに保存され、Terraform GitHub Action によってアクセスされます。同様に、S3 バックエンドへのアクセスに使用される AWS ロール、およびバケット名とバケットリージョンは、リポジトリの変数セクションに保存されます。これらのシークレット/変数は、リポジトリ設定の [シークレットと変数] > [アクション] で更新できます。
SUMOLOGIC_ACCESSID
SUMOLOGIC_ACCESSKEY
AWS_ROLE_ARN
BUCKET_NAME
BUCKET_REGION
ローカルでの実行
ローカルから実行する場合、上記のAWSセットアップは機能しないため、次の手順によりAWSアクセス資格情報を作成し、使用する必要があります（これらの手順では、S3バケットおよびポリシーの作成が前提となるため、未作成の場合はAWSセットアップのステップ1～5に従ってください）。
- 「IAM」>「Users」ページに移動し、「Create User」をクリックします。
- 適切なユーザー名を入力し、「next」をクリックします。
- 「Set Permissions」ページで「Attach Policies Directly」をクリックし、先ほど作成したポリシーを選択します。次のページで「ユーザーを作成」をクリックしてください。
- 「IAM」>「Users」ページに戻り、新しく作成したユーザーをクリックします。
- 「Security Credentials」タブの「Access Keys」セクションで、「Create Access Key」をクリックします
- ユースケースとして「CLI」を選択し、チェックボックスにチェックを入れて「next」をクリックします
- 必要に応じてタグを設定し、次に「次へ」をクリックします。この手順でAWSアクセスキーとシークレットアクセスキーが生成されます。それぞれ
AWS_ACCESS_KEY_IDおよびAWS_SECRET_ACCESS_KEYという環境変数としてエクスポートしてください。
検出の促進とテスト
次のように分岐と環境分離を使用してルールの昇格を管理します。
- 機能ブランチ→開発と検証
- プルリクエスト→ピアレビューと計画承認
- メインブランチ→開発ブランチへの自動デプロイメント
- 手動ワークフロートリガー→テストまたは本番環境に昇格
品質を維持するため、YAMLリンティング、ポリシーテスト、またはメタデータ検証を追加します。
このDevSecOpsスタイルのワークフローでは、誤検知の減少、反復の高速化、および検出に対する組織の信頼構築が実現します。
運用規律
成熟した検出プログラムはすべて、運用の一貫性に依存します。
以下のような慣例を採用してください：
所有者、ユースケース、およびランブックURLなどのメタデータフィールドを含める。- 一時的に無効になっているルールに
enabled: falseを使用する。 - 命名基準とメンテナンスウィンドウを適用する。
Terraformプランを使用して夜間のドリフトチェックを実行する。
強力なプロセス規律により、検出管理は事後対応型のルール調整アプローチから、継続的な検出改善プロセスへと変化します。
トラブルシューティングと回復
一般的な問題：
- 予期せぬ削除：状態のバックエンド設定を確認します。
- 認証エラー：OIDCおよびAPIシークレットを確認してください。
ドリフト警告：Sumo Logic UIで手動編集が行われていないことを確認します。
ロールバック：コミットを元に戻して再適用します。Terraformの状態により完全な回復が保証されます。
価値：これらの安全対策により、検出エンジニアリングの回復力が高まり、操作ミスは危機となるどころか、学習の機会となります。
重要となる注意事項
Sumo Logicは、Cloud SIEMサービス、API、およびCloud SIEMサービス内のルールやその他の設定に関連する公開されたTerraformリソースのサポートと保守のみを担当します。お客様は、ご自身のGitHubリポジトリ、ならびにリポジトリ内で発生するセキュリティとプロセスのサポートおよび保守について責任を負います。本ガイドは保証なしに提供されるものであり、リポジトリの設定とサポートが関連する組織の要件をすべて満たすことを確認する責任はお客様にあります。
プロセスから実践へ
GitHubでのクラウドSIEMルールの管理は、手動調整から測定可能な進歩への移行という重要な転換点となります。バージョン管理、自動化、CI/CDにより、あらゆる検知が学習し、適応し、改善する生きたシステムの一部となります。
Sumo Logic Cloud SIEMを搭載したこのシステムは、検出をコンテキストに、コンテキストをアクションに、そしてアクションを結果に結び付けるインテリジェントセキュリティオペレーションへと進化します。
録画デモにより、SIEMの実際の動作をご覧ください。
