はじめに

こんにちは、大林です。2025年3月1日に開催されたJAWS DAYS 2025 に「AWSアカウントのセキュリティ自動化、どこまで進める？　最適な設計と実践ポイント」というタイトルで登壇してきました。聴講してくださった方々、本当にありがとうございました。
また、NRIネットコムのJapan AWS Ambassadorsに選出されている佐々木さん、志水さんにXでのツイートで盛り上げていただきました。佐々木さん、志水さん、ありがとうございました。

NRIネットコムのスポンサーセッション
大林さんが話していますが、大盛況。素晴らしい！！#jawsug　#jawsdays #jawsdays2025 pic.twitter.com/Z0vJqBDPtS
— Takuro SASAKI (@dkfj) 2025年3月1日

へーしゃジュニチャンの発表、大盛況！！かっちょいーーー#jawsdays2025 #jawsdays2025_c pic.twitter.com/7bl4SQcfn4
— しみ (@shimi023) 2025年3月1日

登壇内容

speakerdeck.com

セキュリティ・ガバナンス運用の課題

セキュリティ・ガバナンス運用のあるべき姿を説明していきます。 AWSではAmazon GuardDuty（以下 GuardDuty）やAmazon Inspector（以下 Inspector）などのサービスを活用して脅威や脆弱性を検出できます。脅威や脆弱性を検出したら、検知内容を確認して検知内容をもとにAWSリソースを修正していきます。ここで終わりではなく、組織全体やOU単位でのセキュリティ検知に傾向を分析して、同じような検知が出ないような予防的改善アクションを実施していく必要があります。例えば、ガイドラインの改定、開発者への継続的なアナウンスなどです。ガイドラインでAWSでのアンチパターンやベストプラクティスを定義して、それを周知していくことで継続的な改善につながります。
ただ、人の手のみでセキュリティ・ガバナンス運用を完璧に実施すると人手不足に陥りやすいです。なので、自動化を進めてセキュリティ・ガバナンス運用を効率的に実施していく必要があります。

セキュリティ運用の自動化例

FW系リソースの自動更新

AWSサービスのみで作成する完全自動化パターン

AWSのサービスだけを使って、FWを完全に自動で更新するパターンについて説明します。今回はAWS WAF（以下 WAF）のIPセットを例に自動化の仕組みを説明します。この仕組みでは、まずWAFがブロックしたリクエストのログをAmazon S3（以下 S3）に保存します。S3に新しいログファイルが出力されると、それをAmazon EventBridge（以下 EventBridge）が検知し、自動的にAWS Step Functions（以下 Step Functions）が起動するようになっています。Step Functionsは、S3に保存されたログを解析し、新たにブロックが必要なIPアドレスを特定した後、そのIPアドレスをWAFのIPセットに追加します。これによって、攻撃を試みたIPアドレスが自動的にブロックされ、管理者が手動でIPセットを更新する手間がなくなります。

この仕組みのメリットは、IPセットの更新作業を人が手動で行う必要がなくなるので、人的リソースをより重要なセキュリティ対策や分析に集中できるようになることです。限られたリソースを効率よく使いながら、より戦略的な業務に時間を割くことができるようになります。
一方で、注意すべきポイントとして、自動でIPセットを更新することで、誤ってブロックすべきでないIPアドレスが追加されるリスクがあります。誤検知が発生すると、正当なユーザーのアクセスがブロックされてしまう可能性があります。その結果、ブロックされたIPアドレスの調査・解除といった作業が発生したり、ブロックされたユーザーが機能を使うことができないというビジネス的なリスクが生じます。

チャットツール起点とした自動化パターン

チャットツールを活用したFWを自動更新する仕組みについて説明します。従来、WAFのIPセットを更新するには管理者がAWSのコンソールにログインし手動で設定を変更する必要がありましたが、Slackを起点としたワークフローを活用することでこのプロセスを自動化し、作業の効率を大幅に向上させることができます。まず、運用担当者がSlack上でIPアドレスのブロックをリクエストすると、その情報は運用責任者に送信されます。運用責任者がリクエストを確認し、承認を行うことで次のステップに進みます。承認されたリクエストはAmazon Q Developer in chat applicationsに送信され、AWS Lambda（以下 Lambda）を経由してAWS WAFのIPセットが更新される仕組みになっています。処理が完了すると、運用担当者に対してSlackを通じて完了通知が送信され、作業の進捗がリアルタイムで把握できるようになっています。このプロセスを導入することで、手作業によるミスを減らし、迅速なIPアドレスのブロックが可能になります。

この仕組みを運用する上で、承認プロセスの強化が重要なポイントです。Slackのワークフローを活用することで、承認ボタンを押せるユーザーを制限し、不要な承認が行われないようにすることが可能です。または、承認権限のあるユーザーのみが参加できる専用のSlackチャンネルを設けることで、リクエストの管理が一元化され、不適切な承認を防ぐ運用を実施できます。

このSlackを起点とした自動化には多くのメリットがあります。例えば、承認プロセスを簡単に組み込めるので承認プロセスを含めた自動化フローを簡単に作成することができますし、Slackを使って承認プロセスを組み込めることはSlackを多用している方々にとって、運用の手間の効率につながります。
一方で、いくつかの考慮すべき点もあります。ケースによっては、チェックボックスを採用したタスク依頼用の入力フォームにチェックボックスの選択肢を頻繁に追加する改修が頻繁に必要になることや、誤って承認ボタンを押してしまうリスクがあります。さらに、企業の内部ルールによっては、チャットツールを活用した承認フローが正式な承認手続きとして認められないケースもあるので注意が必要です。さらに、Slack自体に障害が発生した場合でもFWの更新が滞らないよう、別の手段で更新できる仕組みを用意しておく必要があります。

AWSサービスのみで作成する自動化パターン

Slackを活用したワークフローとは異なり、このパターンではAWSのサービスのみを使用することで、チャットツールの導入が難しい環境や、よりシンプルで安定した運用を求める場合に適した方法となります。まず、運用担当者が新たに追加すべきIPアドレスをファイルに記述します。このファイルをS3のバケットにアップロードすることで、処理のトリガーが発火します。S3にファイルが保存されたことをEventBridgeが検知し、Step Functionsを自動的に起動します。Step FunctionsはS3内のファイルを読み取り、IPアドレスのリストをFWに追加する処理を実行します。この仕組みにより、管理者が手動でFWの設定を変更する必要がなくなり、シンプルな操作でFWの管理が可能になります。

この方法のメリットについて説明します。まず、Slackなどのチャットツールを使ったワークフローと比較すると、誤操作によって処理が実行されるリスクが低い点が挙げられます。チャットツールでは、誤ってボタンを押してしまう可能性がありましたが、この方法ではS3へのファイルアップロードという明確なアクションをトリガーにしているため、意図しない処理の実行が発生しにくくなります。また、企業によってはチャットツールの利用が制限されている場合もありますが、この方法はAWSのサービスのみで完結するため、制約を受けずに運用することができます。

一方で、デメリットもいくつかあります。まず、Slackを活用したワークフローと比較すると、俊敏性に欠ける可能性があります。例えば、チャットツールを利用した場合は、運用担当者がフォームから直接リクエストを送り、承認者が即座にボタンを押すことでリアルタイムにIPセットの更新が行えます。しかし、S3を介したプロセスでは、ファイルの作成・アップロードという手間が発生するため、即時性がやや低下する可能性があります。また、AWSのリソースを直接管理する必要があるため、適切な権限設定や運用管理が求められます。

このように、AWSのサービスだけを活用したFWの自動更新は、安定性や汎用性に優れた運用が可能です。

更新したFWはどのように管理するのか

AWS Organizationsを活用してFirewall Managerを組織全体に適用し、WAFのポリシー管理を統一的に行う方法について説明しています。マルチアカウント環境では、各アカウントで個別にWAFを管理すると設定のバラつきが発生しやすくなり、ガバナンスを効かせるのが難しくなります。そこで、Firewall Managerを活用することで、組織内の組織単位（以下 OU）やアカウント単位で、一貫したWAFポリシーを適用することが可能になります。

上記の構成図は、まず監査アカウントでFirewall Managerを管理し、そこから各アカウントやOUにWAFポリシーを適用する仕組みを示しています。具体的には、「FMSPolicy：WAF-Block-A」「FMSPolicy：WAF-Block-B」「FMSPolicy：WAF-Block-C」といった複数のポリシーを定義し、それぞれのポリシーを適用したいOUのAWS WAFに配布する形になっています。これにより、統一されたポリシーを組織全体で適用できるため、管理の効率化が図れます。

Firewall Managerの利点の一つは、Security Hubと連携することで、ポリシーが適用されていないアカウントや、設定に不備があるリソースを簡単に特定できる点です。これにより、セキュリティのベースラインを組織全体で確立し、コンプライアンス違反のリソースを可視化しながら運用することが可能になります。

また、Firewall Managerではタグを利用してWAFポリシーを管理することができます。このタグを用いた管理の最大のメリットは、柔軟な運用を実現できる点です。例えば、現時点では「WAF-Block-A」というポリシーを適用しているが、将来的に「WAF-Block-B」や「WAF-Block-C」に移行したい場合、タグを変更するだけでスムーズにポリシーの適用範囲を変更することができます。これにより、運用の負担を最小限に抑えながら、組織のセキュリティポリシーを段階的に強化していくことができます。

GuardDuty Malware Protection for S3を最大限活用するための自動化

GuardDutyの制約の中でも特に重要な2つの課題に対処する方法を紹介しています。1つ目は「マルウェアを検出するだけで、ファイルの隔離や削除を行わない」という点です。このままでは、感染したファイルが残り続け、組織内の他のリソースに悪影響を及ぼす可能性があります。なので、マルウェアが検出された場合に自動的に隔離・削除する仕組みを導入する必要があります。2つ目の課題は、「AWS Security Hub（以下 Security Hub）に検知結果を集約できない」という点です。これを解決するために、GuardDutyの検出結果をSecurity Hubにインポートし、セキュリティ検知を一元管理する仕組みを構築することが必要になります。

GuardDutyがマルウェアを検出した際に、ファイルの隔離や削除を自動化するフローを示しています。具体的には、まずGuardDutyがS3バケット内のファイルをスキャンし、マルウェアが検出されるとEventBridgeがそのイベントをトリガーします。EventBridgeはAWS Lambdaを起動し、検出されたマルウェアファイルを別の隔離用S3バケットに移動させたり、削除する処理を実行します。このフローを導入することで、感染したファイルがそのまま残らないようにし、組織全体のセキュリティリスクを最小限に抑えることができます。

GuardDutyのデフォルト機能では、Security Hubへ直接結果を送信することができません。そのため、まずGuardDutyがマルウェアを検知すると、EventBridgeがその検知情報を取得し、AWS Lambdaを起動します。Lambdaが「Boto3」のbatch_import_findings APIを使用して検知結果をSecurity Hubにインポートすることで、セキュリティ検知の一元管理が可能になります。この仕組みによって、管理者はSecurity Hubのダッシュボード上でGuardDutyの検出結果を含む他のセキュリティアラートを一括管理できるようになり、対応漏れを防ぐことができます。

Configを活用した自動修復機能とそのポイント

AWS Config（以下 Config）を活用した自動修復について説明します。Configは、AWS環境内のリソース設定を継続的に監視し、設定の準拠状況を評価するためのサービスです。しかし、Configだけではリソースの設定を修正することはできません。そこで、LambdaとEventBridgeを組み合わせることで、非準拠なリソースを自動的に修復し、セキュリティリスクを軽減することができます。

例えば、セキュリティグループのインバウンドルールに「0.0.0.0/0」が含まれている場合、それを自動的に削除するフローを構築することができます。Configがこのルールを検出すると、EventBridgeがイベントを発生させ、それをトリガーにLambdaが起動し、問題のあるセキュリティグループの設定を修正します。これによって、手動での対応が不要になり、迅速なセキュリティリスクを低減できます。

ただ、この仕組みを導入する際には、いくつかの注意点があります。まず、修復対象のリソースを適切に制御する必要があります。すべてのリソースに対して一律に修復を行うと、意図しない設定変更が発生し、インシデントにつながる可能性があります。そのため、例えば「Config-AutoRepair: True」というタグが設定されているAWSリソースのみを修復対象とするルールを設定する必要があります。

また、Security Hubの「AWSリソースタグ付け標準」を活用することで、適切なタグが設定されていないリソースを特定することが可能です。「AWSリソースタグ付け標準」により、タグ管理の不備による修復ミスを防ぎ、組織全体で一貫した管理ができるようになります。

さらに、Configの記録頻度の設定も重要なポイントになります。記録頻度が低すぎると、非準拠リソースの検出や修復が遅れる可能性があります。一方で、記録頻度を高くしすぎると、思わぬコスト増加を招く可能性があります。そのため、環境に応じた適切な記録頻度を設定することが重要です。以下では、3つのケースごとにどのような設定をしていけばよいのか説明していきます。

ケース1：とにかく堅牢な環境を作成する

とにかく堅牢な環境を作成するためには、セキュリティを最優先し、できるだけ早くコンプライアンス違反のリソースを修復するための設定が必要です。この場合、「継続的な記録」を採用し、リソースの変更が発生すると即座に検出できるようにします。これにより、意図しない脆弱な設定が残ることを防ぎ、セキュリティリスクを最小限に抑えることが可能になります。しかし、この設定ではリソースの作成や削除が頻繁に行われる環境では記録頻度が高くなり、それに伴いConfigの利用コストが増加する可能性があります。運用環境によっては、1万円、5万円、10万円単位でのコスト増加が発生する可能性があるため、特にリソースの作成と削除が高頻度で繰り返されるような環境では慎重に設定する必要があります。

ケース2：コストが増加しにくい環境を作成する

コストが増加しにくい環境を作成するためには、コスト管理を優先し、Configの記録頻度を抑える設定が必要です。このケースでは「日次記録」を採用し、リソースの変更を1日単位で監視することで、記録頻度を抑えながら基本的なセキュリティ対策を維持します。これにより、リソースの作成と削除が頻繁に行われる環境でも、Configのコスト増加を最小限に抑えることができます。しかし、記録が1日単位になるため、24時間の間にAWSリソースが侵害されるリスクがあり、攻撃が発生した場合でもすぐに検知できない可能性があります。

ケース3：マルチアカウント環境で運用

マルチアカウント環境で運用で運用する際は、Organizationsを活用し、記録頻度の設定を一律にするのではなく、用途に応じた適用方法を検討することが重要になります。組織全体で「日次記録」を採用するケース、もしくは組織全体で「継続的な記録」を適用するケースがあります。しかし、どちらかに統一するのではなく、状況に応じて適切な記録方法を選択することが求められます。

ケースによってはハイブリッドの運用が選択肢に挙がってくると思います。組織全体では「継続的な記録」を採用し、非準拠リソースを迅速に修復できる環境を整えつつ、一部のアカウントでは特定のリソースタイプ（例えばEC2のセキュリティグループ）のみ「日次記録」にオーバーライドするという方法です。これにより、組織全体としてはセキュアな環境を維持しながら、特定のアカウントでのコストを抑えることが可能になります。

ここで重要なのは、Configの記録頻度をオーバーライドした場合、ドリフト検出の対象外となることです。ですので、AWS Control Towerを導入している環境でも導入することができます。こうした運用の柔軟性を活かしながら、適切な設定を行うことが、コストとセキュリティのバランスを取る上で重要になります。

まとめ

自動化を検討する際に重要なのは、「クリティカルな作業を自動化しすぎない」ということです。自動化は、運用負担を軽減し、効率的なセキュリティ対策を実現する手段として有効ですが、すべてを自動化すればよいわけではありません。特に、システムの安定性やセキュリティに直結するクリティカルな作業を過度に自動化すると、逆に運用負荷を増加させてしまいます。例えば、自動化したフロー自体に障害が発生すると、その障害対応に追われてしまい、結果としてより多くの人手が必要になる場合があります。さらに、障害発生時に即座に代替手段を用意できないと、業務に深刻な影響を及ぼすことになります。
そのため、自動化を進める際には、まずは小さな作業から段階的に自動化の仕組みを導入していくとよいです。例えば、定期的なログの取得やアラート通知といった単純な作業から自動化を進め、運用の安定性を確認しながら、徐々にプロセスの自動化を検討するということです。そして、自動化とガバナンスのバランスについても考慮が必要です。セキュリティ運用における自動化は、ガバナンス強化の観点からも重要ですが、単純にセキュリティを厳格にすればよいというわけではありません。過剰な自動化や厳格すぎるルール設定は、運用コストの増加につながる可能性があります。したがって、自動化の仕組みを設計する際には、セキュリティ対策とコストのバランスを意識したケースに応じた適切な運用が必要です。