今日は前回ご紹介したAWS DevOps Agent で異常の検知とリソース変更まで行っていきます
AIで障害の原因・分析を行なうAWS DevOps Agentを試す
DevOps Agent のデータソース
DevOps Agent は対話型でAWSアカウントの状況を把握できるとても便利なツールです。一方便利な銀の弾丸ではないことにも注意する必要があります。
DevOpsAgentが分析に利用できる各種データを図にしました。この中でも CloudWatch Logs CloudTrail Config Recorder あたりが分析の中核になります。
逆に言えばこれらが正しく設定されておらずAWS上で起きているログなどが散逸している場合、もしくは例えばEC2の中にだけアプリケーションログが存在している場合、DevOpsAgentは分析に必要なデータを正しく把握することができません。このため、利用の前にこれらのサービスが正しく設定されているか確認する必要があります。 CloudTrail はデフォルトで有効化されているはずですが、アプリケーションのログは CloudWatch Logsにはデフォルトで挿入されないため正しくせって押しておく必要があります。外部o11y系ツールを使っているなら、それらのログをDevOpsAgentにオプトインしておく必要があります。
AWS Configは使っていない方も多いかと思いますが、 Recoder を有効化しておくとすべてのAWSリソースの変更履歴がロギングされるため万が一のフォレンジックなどに有効です。
エージェントアクション
DevOpsAgentの設定には、デフォルトではオフになっている エージェントアクションが指定できます。これを有効化しておくとDevOpsAgentそのものがAWS上のリソースをチャットの指示をもとに有効化できます。
攻撃を想定したシナリオ
ではEC2上でテストアプリケーションをBasic認証付きで起動しておきます。状況を以下のように確認してみます。
そうすると以下のように不正なログイン試行が行われていることがわかります。
ヘルスチェックの可能性もありますが、であれば時間はもう少し定期的に並ぶはずです。また認証失敗が繰り返されているためブルートフォース型の不正ログイン施行と予想されます。
ここで重要な点ですがこれは xxx-ai-exam/app というCloudWatch Logs ロググループの分析内容です。つまりCloudWatch Logsにアプリケーションのログを送出しているからこそ発覚するということに注意してください。
調査のために一度インスタンスを停止します。
途中確認ダイアログが表示されます。承認を行うと以下の通りインスタンスが停止されます。
