乐胖代购免代理版

こんにちは！イーゴリです。

この記事は下記の記事の続きとなりますので、この記事を読む前に必ず下記の記事をご一読ください。

blog.serverworks.co.jp

この記事では、AWSのセキュリティサービスを使うことで自分のAWS環境を守る方法を紹介したいと思います。今回は、AWS環境の基本セキュリティサービスを紹介しますが、次の記事では、サイバー攻撃やその対策方法について紹介したいと思います。

リスクの把握
- リスクへの対処法の検討
AWS環境の基本セキュリティサービスを有効にする
各AWSサービスのログ収集
シークレットの安全保管、使用、管理

リスクの把握

注意事項：この記事と次の記事では、AWS Well-Architected Frameworkのセキュリティの柱・ベストプラクティス・他の資料・個人的な意見に基づいた、理想的なセキュリティシステムの構築方法を紹介したいと思います。しかし、前回の記事で説明しましたが、「こうしないといけない」というような正解はありません。最終的にはビジネス的な判断が必要です。

脆弱性やリスクを理解した上で、どのサービスを使用するか、どの部分にリソース(人・お金・時間など)を集中させるかを決定することが重要です。ITシステムを完璧に守ることは不可能であり、どの程度の投資を行うか、どのリスクを受け入れるかは、各企業やプロジェクトの事情や価値観により異なります。

リスクマネジメントの一例ですが、下記のようにリスクの発生率と影響の度合いを評価し、判断するという方法があります。

(a)×(b) = 重要度

	(a) 発生頻度：高	(a) 発生頻度：中	(a) 発生頻度：低
(b) 影響度：高	9	6	3
(b) 影響度：中	6	4	2
(b) 影響度：低	3	2	1

リスクへの対処法の検討

下記の表のような観点から考えてみてもいいかもしれません。例えば、「MFAの有効化」という改善はすぐ実現できますし、料金もかかりません。しかも環境へのインパクトが大きいので、優先度:[高]と考えてもよいでしょう！

https://aws.amazon.com/jp/blogs/news/how-to-perform-a-well-architected-framework-review-part3/

Well-Architected Framework Review の実施方法について詳しくは下記の記事をご参照ください。

aws.amazon.com aws.amazon.com aws.amazon.com

AWS環境の基本セキュリティサービスを有効にする

まずは下記のサービスを有効にしましょう。

※AWS料金が発生するので、AWS料金ページで確認した上で、予算的に問題なければ有効にしてください。

AWS Shield Standard（すべてのアカウントでデフォルトで有効になっているので対応不要^※1）
AWS CloudTrail（すべてのリージョン^※2）
AWS Config（同上^※2）
Amazon GuardDuty (保護プランを含む)（同上^※2）
AWS IAM Access Analyzer（同上^※2）
Amazon Detective（同上^※2）
Security Hub（同上^※2）

^※1 AWS Shield Standard (無料版)は、L3(ネットワーク層)およびL4(転送層)のDDoS攻撃を防御できますが、L7(アプリケーション層)のDDoS攻撃は防御できません。L7(アプリケーション層)を守るにはAdvancedプラン (SEC01-BP04)が必要です。但し、Advancedプランは高額なサービスのため、規模や予算に応じて他のAWSサービス（例：AWS WAFなど）を検討することも有効ですので、後ほど紹介します。

^※2 「◯◯リージョン以外のリージョンは使わないので、◯◯は必要ない」と思う方もいらっしゃるかもしれませんが、自分が使わなくても、攻撃者は使えるので、各リージョンで◯◯を有効にする必要があると思います（例：別のリージョンで攻撃者がこっそりビットコインや他の仮想通貨をマイニングする）。AWS Organizationがある場合、使わないリージョンは無効にしたほうが良いですが、AWS Organizationがない場合、慎重にすべてのリージョンを監視する必要があります。

AWS CloudTrail

AWSアカウント内のすべてのAPIコール（＝すべて^※3のコンソール、AWS CLI、SDKなどの操作）を記録し、監査やセキュリティ分析のためにログを保存するサービスです。これは欠かせないサービスなので、有効にすることを必須にしましょう。

SEC04-BP01 サービスとアプリケーションのログ記録を設定する
<省略>
AWS CloudTrail は、AWS のサービスアクティビティをキャプチャする AWS アカウントに対して API コールをトラッキングするログサービスです。これは、デフォルトで有効になっており、管理イベントは 90 日間保持され、AWS Management Console、AWS CLI、または AWS を使用して CloudTrail イベント履歴から検索することが可能です。データイベントをより長く保持および確認するには、CloudTrail 証跡を作成して、Amazon S3 バケットと、そしてオプションで Amazon CloudWatch ロググループと関連付けます。または、CloudTrail Lake を作成できます。これは、CloudTrail ログを最長 7 年間保持し、SQL ベースのクエリ施設を提供します。
<省略>
このベストプラクティスが確立されていない場合のリスクレベル: 高
docs.aws.amazon.com

^※3 未サポートのリソースについて、下記のページにて最新情報をご参照ください[→CloudTrail サポートされていないサービス]。

docs.aws.amazon.com CloudTrail サポートされていないサービス
まだプレビュー中であるか、一般提供 (GA) 用にまだリリースされていないサービス、またはパブリックがないサービスはAPIs、サポート対象とは見なされません。
さらに、以下の AWS サービスとイベントはサポートされていません。
■AWS Import/Export
■Amazon VPCエンドポイントポリシー固有のイベント

AWS Config

AWSリソースの設定変更を追跡し、コンプライアンスやセキュリティの監査をサポートするためのサービスですので、有効にすることを必須にしましょう。

例えば、誰かがセキュリティグループのルールを変更したら、下記のように変更された部分が表示されます。

上記の結果を見ると、ユーザーが下記の設定を行ったということが分かります。

ちなみに、このサービスに基づいて他のサービス (AWS Security Hub) や機能 (AWS Config Rules, Conformance Packなど) が動いています。

なお、AWS Configで未サポートのリソースがあるので、下記のページにて最新情報をご確認ください。[サポートされているリソースタイプ]に書いていないリソースタイプは未サポートのリソースタイプとなります。

重要
このページは、毎月の初めに毎月更新されます。 docs.aws.amazon.com

Amazon GuardDuty

AWS CloudTrail管理イベント、VPCフローログ、DNSクエリログの分析を行い、異常な動作や悪意のあるアクティビティを検出するための脅威検出サービスですので、必ず必ず有効にすることを必須にしましょう。そして、GuardDutyのイベント(検出結果)を常に監視しましょう！

上記の例だと、誰かがBroute Forceをしようとしたことが検出結果で確認できます。

下にスクロールすると、攻撃者についての様々な情報が表示されます。

「... VPCフローログ、DNSクエリログの分析を行い」と記載しましたが、そもそもの話ですが、VPCフローログやDNSクエリログを有効にしない限り、これらに関わっている異常な動作や悪意のあるアクティビティは検出されないので、ご注意ください（各項目で詳しく説明します）。

検出結果の重要度について

High (7.0 - 8.9)：

AWSの説明：

高の重要度は、問題になっているリソース (EC2 インスタンスや IAM ユーザーサインイン認証情報) が侵害され、不正な目的で活発に使用されていることを示します。

重要度が [High] (高) の検出結果のセキュリティの問題は、優先事項として処理し、リソースのそれ以上の不正使用を防ぐために直ちに修復を行うことをお勧めします。

私の感覚値：非常に危険で、至急対処が必要な状態です。例えば、リソースが不正使用されている可能性が高い場合などです。このレベルの問題は、優先的に解決する必要があります。

Medium (4.0 - 6.9)：

AWSの説明：

[Medium] (中) の重要度は、通常観察される動作から逸脱する不審なアクティビティを示し、場合によってはリソースが侵害されていることを示します。

できるだけ早く、関連するリソースを調査することをお勧めします。

私の感覚値：50/50の状態で、要確認です。異常な動作が見られるものの、すぐに重大なリスクにはならない場合もあります。調査を行い、必要に応じて対策を講じる必要があります。

Low (1.0 - 3.9)：

AWSの説明：

すぐに推奨されるアクションはありませんが、この情報は、誰かがネットワークの弱点を探していることを示している可能性があるので、念のためメモしてください。

私の感覚値：重大なリスクはないものの、注意が必要です。例えば、不正アクセスの試みやポートスキャンなど。急ぎではないですが、時間がある時に確認すると良いと思います。

詳しくは下記の記事をご参照ください。

docs.aws.amazon.com

SEC01-BP04 セキュリティの脅威と推奨事項の最新情報を入手する
<省略>
例えば、Amazon GuardDuty には、アカウント内の異常な行動や脅威の兆候の検出に関し、業界の脅威インテリジェンスの最新情報が常に反映されます。
このベストプラクティスが確立されていない場合のリスクレベル: 高
docs.aws.amazon.com

なお、Amazon GuardDutyの保護プランも有効にすることをおすすめします。

下記の対象サービス(EKS/S3/RDSなど)を使わなければ、課金は発生しませんが、例えば、RDSを構築することになった→RDS Protectionを有効にすることを忘れた→不正アクセスが発生した→何のアラートもなかった→何の対策もしないまま、という流れで終わる可能性が高いです。

各保護プランのFindings(検出結果)を説明すると、非常に長い文章になりますので、各項目に対して対象Findings(検出結果)のURLを記載致しますので、ご参照ください。

EC2 の Malware Protection

GuardDuty EC2 の Malware Protectionの特徴は他のマルウェア対策ソフトウェアと異なり、EBSのスナップショットに対してスキャンしているので、サービスに影響なくEC2を利用できます。

注意点としてはGuardDutyが検知した特定のFingingのトリガーに対してスキャンを行っていますので、リアルタイムのスキャンのためには、別の対策を考える必要があります。そのため、3rd partyの製品 (例：Trend Vision One)と合わせて使ったほうがよいのではないかなと思います。

項目	Amazon GuardDuty EC2 の Malware Protection	3rd party製品
スキャン対象	EBSスナップショットに対してスキャンを実施	EC2インスタンスの実行中のファイルシステムをスキャン
影響	スナップショットのスキャンであり、稼働中のサービスに影響なし	実行中のインスタンスに対するリアルタイムのスキャンのため、影響が発生する可能性あり
リアルタイム保護	ー	リアルタイムのマルウェア検出とブロック
対応する脅威	比較的対象範囲が狭い	比較的対象範囲が広い
使用コスト	AWSサービスの一部として追加コストは最低限	別途ライセンス費用が必要
管理の複雑さ	管理が容易で、AWSコンソールで統合管理が可能	サードパーティ製品の管理コンソールが必要
追加機能	AWS環境全体の脅威検出、その他のAWSサービスと統合	仮想パッチ、脆弱性スキャン、ネットワークセキュリティなどの様々な追加機能あり

Amazon GuardDuty EC2のMalware Protectionは、スナップショットに対するスキャンを行い、稼働中のシステムに影響を与えない点が特徴です。ただし、リアルタイムの保護を必要とする場合は、サードパーティ製品の使用が推奨されます。
TrendMicroなどのサードパーティ製品は、リアルタイムのマルウェア保護を提供し、さまざまなセキュリティ機能を備えていますが、追加のコストがかかり、リアルタイム検索によるスキャンのため、パフォーマンスに影響が発生する可能性があります。

リアルタイム検索は、ファイルサーバでファイルのバックアップが予約されているときなど、パフォーマンスへの影響が大きいときを避けて実行するように設定できます。 cloudone.trendmicro.com

Amazon GuardDuty EC2 の Malware Protectionと3rd partyのソリューションの強いところを合わせて、Amazon GuardDuty EC2 の Malware Protectionを3rd partyのソリューションと組み合わせたほうがよりよいですね。

GuardDuty実行型マルウェアスキャンを呼び出す検出結果： docs.aws.amazon.com

なお、EC2 Malware Protectionは制限事項(ファイルシステムタイプ、サイズ上限など)があるので、下記のページをご参照ください。

docs.aws.amazon.com

S3 Protection

新規アカウントでGuardDutyを有効にするとデフォルトで有効になる
アカウント内の全ての S3 バケットを継続的に監視する
管理イベントとデータイベントのモニタリングをする

GuardDuty S3 Protection は、Amazon S3に保存されたデータへの不正アクセス(送信元が、Torでのアクセス/漏洩した認証情報の使用/不正なIPアドレスなどを利用していないか確認する)を防ぐためのサービスです。

デフォルトでは、S3バケットはプライベートですが、バケットが公開されないようにS3 Protectionに監視されています。特に、機密データが含まれる場合、誤って公開してしまうと大変なので、必ずS3 Protectionを既存のアカウントでも有効にする必要があります。

下記の場合なども、既存のアカウントでも有効にしましょう。

企業がS3バケットに機密データを保存し、誤って公開されるリスクを避けたい場合
怪しい送信元からの動作を感知したい場合
異常なふるまいを検知したい場合

GuardDuty S3 検索タイプ： docs.aws.amazon.com

S3 の Malware Protection

GuardDuty S3のMalware Protection は、S3バケットにアップロードされるファイルをスキャンしてマルウェアを検出します。特に、外部からのファイルアップロードがある場合に役立ちます。

マルウェアがシステムに侵入するリスクがあるため、S3にアップロードされるファイルをスキャンし、潜在的な脅威を検出し、オブジェクトにタグを付けたり、悪意のあるオブジェクトを検疫バケットに移動する（パターン1）/ 削除する（パターン2）サービスです。

詳しくは下記のAWS記事をご参照ください。 aws.amazon.com

S3 検出結果タイプの Malware Protection： docs.aws.amazon.com

Runtime Monitoring

GuardDuty ランタイムモニタリングは、EC2、ECS、EKSなどのシステムで稼働中のOSレベルのアクティビティをリアルタイムで監視し、潜在的な脅威や異常を検出する機能です。この機能を利用することで、不正アクセスやマルウェアの活動、その他の疑わしい動作を検知することが可能です。

blog.serverworks.co.jp

Runtime Monitoring の検出結果タイプ： docs.aws.amazon.com

EKS Protection

新規アカウントでGuardDutyを有効にするとデフォルトで有効になる

GuardDuty EKS Protection は、Kubernetesクラスターのセキュリティを強化するために使用します。EKSクラスターは、外部からの攻撃や不正アクセス(利用者がTorでのアクセス, 漏洩した認証情報の使用, 不正なIPアドレスなどを利用している)のリスクがあるため、EKS Protectionが必要です。また、GuardDutyを使用して、クラスター内の異常な活動やトラフィックを検出し、早期に対応することが可能になります。

なお、誤設定がないか(Anonymousユーザーに権限付与など)も検知しています。

下記の場合、EKS Protectionを使いましょう。

ふさわしいふるまいを検知したい場合
怪しいソースからの動作を検知したい場合
誤設定を検知したい場合

docs.aws.amazon.com

EKS Runtime Monitoring は Runtime Monitoring の一部として管理されます。詳細については、「でのランタイムモニタリング GuardDuty」を参照してください。

RDS Protection

新規アカウントでGuardDutyを有効にするとデフォルトで有効になる

GuardDuty RDS Protection は、Aurora MySQL / Aurora PostgreSQL および RDS Postgre 用SQL のログイン活動を監視し、異常なログイン試行を検出する機能です。データベースを狙った攻撃を早期に発見し、対応することができます。

サポートされているデータベースの最新情報については下記のページをご参照ください。 docs.aws.amazon.com

検知について下記のページをご参照ください。 docs.aws.amazon.com

Lambda 保護

GuardDuty Lambda 保護は、AWS Lambdaの関数のセキュリティを強化するためのものです。関数は最小限の権限で実行するようにIAMロールを設定し、CloudTrailを使って関数の呼び出し履歴を監視します。これにより、予期しない操作や異常な動作を早期に発見できます。

Lambdaの異常検知をしたい場合、Lambda 保護をご検討ください。

Lambda Protection の検出結果タイプ： docs.aws.amazon.com

AWS IAM Access Analyzer

AWS IAM Access Analyzerは色々できるので、まとめにくいのですが、箇条書きで主な機能を紹介します。

AWSアカウントのリソースに対するアクセス権限を分析し、誤設定や不適切なアクセスを検出することで、セキュリティとコンプライアンスを強化するサービスです。

アクセス活動に基づくポリシー生成
CloudTrailログからアクセス活動を分析し、最小権限のポリシーを自動生成します。これにより、アプリケーションに必要な最低限の権限のみを付与することができます。
カスタムポリシーチェック
IAM Access Analyzerは、IAMポリシーがセキュリティ標準に準拠しているかどうかを検証します。特に、セキュリティ警告、エラー、一般的な警告、およびAWSのベストプラクティスに基づく提案を提供し、ポリシーの健全性を確認します。
外部アクセスの分析
自動化された論理と推論技術を使用して、リソースポリシーを分析し、外部からのアクセスパスを特定します。これにより、リソースが意図せず外部に公開されていないかを確認できます。
未使用のIAMロールやアクセスキーの特定
使用されていないIAMロール、アクセスキー、コンソールパスワード、サービスおよびアクションレベルの権限を特定し、最小権限の原則に基づいて権限を削減することを支援します。
リアルタイムの分析サポート
ポリシーの変更をリアルタイムで監視し、潜在的なセキュリティリスクについて通知します。これにより、迅速な対応が可能となり、セキュリティを強化します。
開発段階でのアクセスの問題を検出
CI/CDプロセスと統合することで、問題が本番環境に移行する前にセキュリティリスクを特定し、修正することができます。(AWSブログ)

なお、セキュリティインテグレーションに関しても強いサービスです。AWS Security Hubとの統合によって、IAM Access Analyzerの検出結果をAWS Security Hubに送信し、セキュリティ業界の標準やベストプラクティスに基づいて追加の分析を行うことができます。Amazon EventBridgeとの統合によってイベントが発生した際に通知を自動化し、権限の見直しを促進します。

docs.aws.amazon.com

SEC03-BP02 最小特権のアクセスを付与します
アクセス許可をレビューする定期的スケジュールを確立し、不要なアクセス許可を削除する: ユーザーアクセスを定期的にレビューして、過度に寛容なアクセスがないことを検証する必要があります。AWS Config および IAM Access Analyzer は、ユーザーアクセス許可を監査するときに役立ちます。
このベストプラクティスが確立されていない場合のリスクレベル: 高
docs.aws.amazon.com

参考記事： blog.serverworks.co.jp blog.serverworks.co.jp blog.serverworks.co.jp

Amazon Detective

セキュリティデータを自動的に収集、分析し、AWS環境で発生する潜在的なセキュリティ問題や異常なアクティビティの根本原因を迅速に特定するためのセキュリティ調査サービスです。ユーザーはまずAmazon GuardDutyのイベントを調査し、次にAmazon Detectiveで対象イベントのスコープをロックして、さらに詳しく調査することができます。

下記のAmazon GuardDutyのスクリーンショットの通り、GuardDutyの検出結果に[Detective で調査する]というボタンがあるのでクリックしますと、調査に役に立ちそうな情報が出てきます。

例えば、検出結果のIDをクリックすることで、Amazon Detectiveに入ってこの検出結果に関連するリソースの調査ができます。

詳しくは下記のAWSブログをご覧ください。

aws.amazon.com

Amazon Detectiveを使うことで、攻撃者が CloudTrail の証跡の作成を停止したとしても、Detective は API コールを含む CloudTrail のログを収集して調査が可能になるので、環境の異常なアクティビティ調査には必要なサービスとなっています。

Amazon Detective は自動的に AWS CloudTrail のログを取り込みます。攻撃者が CloudTrail の証跡の作成を停止したとしても、Detective は API コールを含む CloudTrail のログを収集して調査が可能です。(URL)

AWS Security Hub

AWS Security Hub有効化の前提条件：対象リージョンのAWS Configの有効化が必須

AWS環境全体のセキュリティ状況を一元的に管理し、さまざまなAWSセキュリティサービス（Amazon GuardDuty、Amazon Inspector、AWS Firewall Manager、AWS Systems Manager、AWS IAM Access Analyzer、Amazon Macie, AWS Config, AWS Health, パートナーの3rd party製品）からのデータを統合・分析して、セキュリティの脅威やコンプライアンスの問題を可視化および管理するためのサービスです。

２つ注意点があります。

①AWS Security Hubは様々なサービスからの情報を１つのサービス(Security Hub)に収集できますが、AWS Security Hubから他のサービスの操作ができませんので、ご承知おきください。

②対象サービスを有効にしない限り、AWS Security Hubを有効にしても情報の収集はできないのでご注意ください。例：Security Hubを有効にしてもAmazon Inspectorを有効にしない限り、Amazon Inspectorからの情報収集はできません。

AWS Security Hubの２つ目の重要な役割は選んだセキュリティのベストプラクティス基準に対象環境が準拠しているかチェックし、環境を評価します。

現時点のAWS Security Hubの中に下記のセキュリティ基準がありますので、お客様の要件に合わせてセキュリティ基準を選択することで、AWSアカウントが該当しているセキュリティ基準に準拠されているか確認できます。スコア100%を目指しましょう！

セキュリティ基準の一覧：

AWS 基礎セキュリティのベストプラクティス v1.0.0
AWS リソースタグ付け標準 v1.0.0
CIS AWS Foundations Benchmark v1.2.0
CIS AWS Foundations Benchmark v1.4.0
CIS AWS Foundations Benchmark v3.0.0
NIST Special Publication 800-53 Revision 5
PCI DSS v3.2.1

なお、上記の基準が足りない場合、AWS Config Conformance Packs (AWS Config 適合パック)をご検討ください。

SEC01-BP03 管理目標を特定および検証する
<省略>
最初の選択肢として、AWS Security Hub の標準の利用を検討してください。AWS Foundational Service Best Practices (FSBP) 標準と CIS AWS Foundations Benchmark は、複数の標準フレームワークに共通の多数の目標に沿った統制を実現できるため、出発点として優れています。望ましい統制の検知機能が Security Hub に組み込まれていない場合は、AWS Config 適合パックで補完できます。
<省略>
docs.aws.amazon.com

参考記事：

blog.serverworks.co.jp

Amazon Macie

Amazon Macieは、AWS Well-Architected Frameworkのセキュリティの柱で推奨されているサービスですが、2024年8月時点での日本の制度や日本語対応は完全ではありません。そのため、利用するかどうかはお客様のデータの内容に依存します。ご自身で十分に検証した上で、Amazon Macieの利用をご検討ください。

docs.aws.amazon.com

Amazon Macieは機械学習とパターンマッチングを使用して、S3バケットに保管された個人情報などの機密情報の検出と保護に役立つフルマネージドサービスです。

機密データの自動検出
Macieは機械学習を使用して、S3バケットに保存されている機密データ（例：個人情報、クレジットカード情報）を自動的に検出します。
セキュリティリスクの軽減
機密データの場所やアクセス状況を把握することで、不正アクセスやデータ漏洩のリスクを減らすことができます（例：S3バケットのパブリックアクセスや暗号化の確認など）。
コンプライアンスのサポート
規制要件に対応するためのデータ監視と報告が容易になります。
他のサービスとの統合
AWSの他のサービス（例：AWS Security Hub）と連携し、包括的なセキュリティ管理が可能です。

各AWSサービスのログ収集

必要に応じて各サービスごとにログを収集します。前の記事にて説明しましたので、ご参照ください。

blog.serverworks.co.jp

SEC04-BP01 サービスとアプリケーションのログ記録を設定する
<省略> docs.aws.amazon.com

VPCフローログを設定する

個人的には、すべての本番環境の各VPCでフローログを設定したほうが良いと思います。GuardDutyの分析項目が＋１つになるからです。

例えば、下記のAWS公式ページの項目に「データソース: VPC フローログ」と書いてある場合、VPCフローログを有効にしないと下記のようなイベントを発見できなくなるので、VPC フローログを有効にしないといけないと思っています。

CryptoCurrency:EC2/BitcoinTool.B

EC2 インスタンスが暗号通貨関連のアクティビティに関連付けられている IP アドレスをクエリしています。
デフォルトの重要度: [High] (高)

データソース: VPC フローログ docs.aws.amazon.com

また、VPC フローログはトラブルシューティング時にも役立ちます。

Elastic Load Balancing及びWeb Application Firewall のアクセスログ収集を設定する

ELBログの目的

ELBのアクセスログは、ロードバランサーを通過するリクエストに関する情報を提供します。これには、リクエストの詳細、送信元IPアドレス、リクエストのタイムスタンプなどが含まれます。

ELBのアクセスログは、主にトラフィックの監視とバックエンドのパフォーマンス分析に使用されます。

WAFログの目的

WAFのアクセスログは、WAFが検査し、ブロックまたは許可したリクエストに関する詳細な情報を提供します。これには、WAFルールに基づいてフィルタリングされたリクエストの詳細が含まれます。

WAFのアクセスログは、セキュリティイベントの監視と分析に使用され、特定の攻撃パターンや不正アクセスの検出に役立ちます。

ELBのログはリクエストの全体的なパフォーマンスと利用状況を監視するのに対し、WAFのログはセキュリティ関連の詳細を提供し、潜在的な脅威からアプリケーションを保護するための情報を提供します。

Amazon CloudWatch エージェントを設定する

Amazon CloudWatch エージェントをインストール、設定すると、OSのログをCloudWatch Logsで見られるようになります。それによってアプリの担当者が必要に応じていろいろな閾値を設定できます。

具体的にどのような項目を取得するべきかアプリの担当者と相談したほうが良いと思いますが、最低でもエラーログ、Secureログ、メッセージログを取得したほうが良いのではないかと思います。そしてそのログに対してアラートを設定します(例：ログに「../../etc/passwd」が出た場合、アラートを飛ばすなど)。

その他のAWSサービスのログ収集

その他のAWSサービスのログがあるので、各サービスのログが何を収集できる/できないかを事前に把握することが重要です。
なぜなら、AWS ConfigなどもすべてのAWSリソースに対応しているわけではないので、対応している/していないリソースを把握する必要があります。

AWS Configがサポートされているリソースタイプの一覧： docs.aws.amazon.com

詳しくは（SEC04-BP01）の項目を御覧ください。

SEC04-BP01 サービスとアプリケーションのログ記録を設定する
省略
このベストプラクティスが確立されていない場合のリスクレベル: 高 docs.aws.amazon.com

ログ保持期間

ログ保持期間については十人十色ですが、特に会社の要件や従わないといけないコンプライアンスがなければ、最低でも1年〜1年半以上のログ保持期間を設定する必要があると思います。

シークレットの安全保管、使用、管理

シークレットの安全保管、使用、管理のためにAWS Secret ManagerやAWS Parameter Storeを使いましょう。

AWS Secret ManagerとAWS Parameter Storeの違いについて簡易な表を作成しましたのでご参考ください。

	AWS Secrets Manager	AWS Systems Manager Parameter Store
用途	認証情報の管理・自動ローテーション	様々な設定値や認証情報の管理（APIキー、パラメーターなど）
シークレットの自動ローテーション	可能。Lambdaを使用したカスタムローテーションも可能。	不可。手動またはカスタムスクリプトを使用してローテーションする必要がある。
暗号化のデフォルトサポート	可能(KMS)	可能(KMS)
料金	使用量に基づいた従量課金制（シークレット数とAPIコールに依存）シークレットあたり 0.40USD/月 10,000 件の API コールあたり0.05USD。	パラメーターの数に基づく無料枠(スタンダード)あり、一部の機能(アドバンスド)に追加コスト(0.05 USD/月)がある
アクセス制御	IAMポリシーで詳細なアクセス制御が可能	IAMポリシーでアクセス制御が可能。よりシンプルな設定。
シナリオ	高セキュリティ環境、シークレットの自動ローテーションが必要な場合	シンプルな設定管理や低コストのシークレット管理が求められる場合

SEC02-BP03 シークレットを安全に保存して使用する
省略
このベストプラクティスが確立されていない場合のリスクレベル: 高 docs.aws.amazon.com

一例ですが、

RDS作成時に「認証情報管理」としてAWS Secrets Managerを指定する（デフォルトの選択肢になった）。
アプリのコード内に認証情報 (パスワードを含む)をハードコードするのではなく、AWS Secrets Managerを使う。またはリポジトリに（プライベートリポジトリを含めて）認証情報などを置かないこと。代わりにAWS Secrets Manager及びParameter Storeを使う。