[レポート] Evaluate risk and automate remediation in your AWS environment に参加してきました！ #COP314 #AWSreInvent

AWS re:Invent 2024
#AWS Trusted Advisor
#AWS Systems Manager（SSM）
ヒラネ
2024.12.27
こんにちは！ AWS 事業本部オペレーション部の平根です。

re:Invent 2024 の Builders' session 「Evaluate risk and automate remediation in your AWS environment」に参加してきましたので内容をご紹介します。
 セッション概要セッションタイトル

COP314 | Evaluate risk and automate remediation in your AWS environment
セッションの説明

※機械翻訳
今日の急速に進化するクラウドコンピューティングの世界では、組織は安全性、効率性、そしてコスト効率の高いクラウドインフラを維持する上で多くの課題に直面しています。

AWS Trusted Advisorは、リスクを軽減し、リソースの利用を最適化し、Well-Architectedのベストプラクティスや業界標準への準拠を確保するための強力なツールです。

このビルダーセッションでは、Trusted Advisorの機能を深く掘り下げ、そのさまざまなチェックや、クラウド管理の異なる側面に合わせた推奨事項について探ります。

Trusted Advisorの自動チェック、カスタマイズ可能なアラート、実行可能な推奨事項などの機能を効果的に活用し、AWS環境内の潜在的なリスクを事前に特定し解決する方法を学びましょう。参加にはノートパソコンをご持参ください。
Level

300 – Advanced
スタッフ
Paul Dyar
SA Leader, CloudOps, AWS

Craig Edwards
World Wide Technologist, AWS

Carlos Perez
Solutions Architect, Amazon Web Services

Duncan Bell
SA Manager Cloud Optimization Success EMEA, AWS

Mohamed Al Omar
Cloud Optimization Success SA, Amazon Web Services

 事前説明初めに、今回の Builders' session のハンズオンで利用する AWS Trasted Advisor について以下の説明がありました。
AWS Trusted Advisor の概要
AWS Well-Architected の 6 つの柱 [1] について AWS 環境を評価し、推奨アクションを提供してくれるサービス
現在、500 を超えるチェック項目を提供している
Amazon EventBridge と連携し、チェック結果のモニタリングとモニタリング結果に応じたアクションの実行が可能

AWS Trusted Advisor へのアクセス方法
AWS Console
AWS Trusted Advisor API

[1]：AWS Well-Architected
ハンズオンでは、Systems Manager OpsCenter と Automation を 利用して Trusted Advisor の推奨事項に基づいて設定を修復する方法について学習しました。
 今回の環境以下が今回のハンズオンで利用する環境です。
以下の 2 つのワークフローが事前に設定されています。
Trusted Advisor (TA) チェック結果トラッカーワークフロー
TA のチェック結果が更新されるたびに、DynamoDB 内のテーブルを更新することでチェック結果をトラッキングします。

Trusted Advisor (TA) 結果チェック自動化ワークフロー
AWS Systems Manager Automation ドキュメントを使用して修復を自動化し、自動化の実行と Systems Manager 内の対応する OpsItems のライフサイクルを管理を行います。

上記のワークフローの詳細が解説されていたため、以下にご紹介します。
ワークフローの詳細（機械翻訳）Trusted Advisor の推奨事項チェックの結果は、侵害されたリソースの詳細 (セキュリティリスクなど) で更新されます。結果の更新は、Trusted Advisor が生成したイベントとして EventBridge に送信されます。
EventBridge ルールはチェック結果イベントを照合し、それらをTrustedAdvisorCheckTrackerFunction Lambda 関数と CloudWatch ロググループに転送します。
TrustedAdvisorCheckTrackerFunction Lambda関数は、 TrustedAdvisorCheckTrackerTable DynamoDB テーブルに Trusted Advisor チェックの最新のステータスを保持します。
TrustedAdvisorResultsHandlerFunctionは、新しい Trusted Advisor チェック結果を処理し、AutomationMappingTableをチェックして、その特定のチェックのマッピング構成があるかどうかを確認します。
AutomationMappingTableで見つかった場合、TrustedAdvisorResultsHandlerFunction関数は SSM 自動化ドキュメントをトリガーします。
TrustedAdvisorResultsHandlerFunction関数は、 AutomationExecutionTrackerTableを更新して、自動化の実行を追跡します。
TrustedAdvisorResultsHandlerFunction関数は、侵害されたリソースの詳細と、実行された自動化ドキュメント (存在する場合) の詳細を含むOpsItemを作成します。
SSM 自動化ドキュメントは、侵害されたリソースの問題を修正します。
SSM 自動化実行が完了すると、SSMAutomationExecutionEventsHandler Lambda 関数は実行の詳細で OpsItem を更新します。OpsItemは、自動化実行の結果に応じて閉じられるか、開いたままになります。

 ハンズオンで実施した内容以下がハンズオンで実施した演習項目となります。
※タイトルは機械翻訳
 ワークフローを接続するこの項目では、事前に設定されている 2 つのワークフローを接続し、 Trusted Advisor（TA）のチェック結果が "Yellow" または "Red" の場合に自動修復処理が実行されるように設定します。

まず、自動修復ワークフローを実行する Lambda 関数 "TrustedAdvisorResultHandlerFunction" のトリガーに DynamoDB を設定します。
フィルタリング条件にて以下を入力し、DynamoDB に記録されている TA のステータスが "Red" または "Yellow" に更新された場合に Lambda 関数がトリガーされるように設定します。
{ "dynamodb": { "NewImage": { "resourceStatus": { "S": ["Red", "Yellow"] } } } }
その後、AWS Sysytem Manager の OpsCenter を有効化します。

事前に用意されている "TrustedAdvisorResultsHandlerFunction" 関数 により、修復すべき課題として OpsItem が作成され、対応の管理を行うことができます。
 手動修復この項目では、TA の検出結果に基づいて手動で設定を修復する手順について学習をしました。

Public IPv4 アドレスを持つ EC2 インスタンスを作成し、TA によって Public IPv4 を持つインスタンスの存在が検知されるかを確認し、手動で設定を修復します。
以下、詳細です。
まず、事前に準備された CloudFormation テンプレートを利用して Public IPv4 アドレスを持つ EC2 インスタンスを作成しました。

CloudFormation テンプレートでは、Autoscaling 起動テンプレートの AssociatePublicIpAddress が true となっており、インスタンスに Public IPv4 アドレスが割り当てられます。
その後、TA のセキュリティチェック項目を確認すると、ステータス Red として Public IPv4 アドレスを持つ EC2 インスタンスの存在が検知されました。
また、Opscenter の OpsItem を確認すると、"EC2 instances should not have a public IPv4 address" という項目が新規作成されており、未解決となっていることが確認できました。
EC2 インスタンスの Public IPv4 を削除するため、作成済のスタックの "AssociatePublicIpAddress" パラメータの値を true から false へ変更し、Auto Scaling グループがらインスタンスを更新します。

これにより、Public IPv4 を持たないインスタンスに置換されます。
最後に、未解決となっている OpsItem を手動で解決済みへ変更しました。
 自動修復この項目では、ワークフローを利用して、0.0.0.0/0 からの SSH (ポート 22) の受信トラフィックを許可するセキュリティグループのルールを自動で無効化する手順を学習しました。

セキュリティグループの無効化には Systems Manager Automation ドキュメント [2] を利用しました。
[2]：AWS-DisablePublicAccessForSecurityGroup
以下、詳細です。
まず、DynamoDB の AutomationMappingTable に対して以下のコマンドを実行し、セキュリティグループを修復する自動化ワークフローと TA の検出結果をマッピングします。

<AutomationRoleArn-output> には CloudFormation StackSet事前に設定されている IAM ロールを入力しました。
マッピングの作成aws dynamodb put-item 

--table-name AutomationMappingTable 

--item '

{

"checkName": {

"S": "Security groups should not allow unrestricted access to ports with high risk"

},

"ssmAutomationDocument": {

"S": "AWS-DisablePublicAccessForSecurityGroup"

},

"automationParameters": {

"S": "{"GroupId": ["$resourceId"], "AutomationAssumeRole": ["<AutomationRoleArn-output>"]}"

},

"regexPattern": {

"S": "(sg-\w+)"

},

"automationStatus": {

"BOOL": true

}

}'
続いて、0.0.0.0/0 からの SSH (ポート 22) の受信トラフィックを許可するセキュリティグループを作成します。

その後、CloudWatch ログ の Log Tailing 機能を利用すると以下のような TA のログを確認することができたため、自動化ワークフローがトリガーされることが期待されます。
Opscenter を確認すると "Security groups should not allow unrestricted access to ports with high risk" という OpsItem が作成されていました。
上記の OpsItem が作成されて数分後、SystemsManager の Automation ドキュメント "AWS-DisablePublicAccessForSecurityGroup" が実行されていることを確認できました。
Automation ドキュメントの実行完了後、セキュリティグループを確認すると、0.0.0.0/0 からの SSH (ポート 22) の受信トラフィックを許可するインバウンドルールが削除されていました。

また、Opscenter をみると、先ほど確認した OpsItem が自動で解決済みとなっていることを確認できました。
 感想今回の Builders' session を通して、AWS Trusted Advisor を活用した自動修復ワークフローの設定や動作を学習することができました。

Trusted Advisor は AWS のベストプラクティスに基づいて問題を検出してくれるため、AWS を利用し始めたばかりのユーザーにとっても利用しやすいサービスだと感じました。
一方、自動修復ワークフローに利用する Lambda 関数や DynamoDB テーブルは事前に作成されていた状態のため、自身の環境で自動修復ワークフローを作成するためには、更なる学習が必要だと感じました。
AWS のベストプラクティスに沿った環境を維持したいとお考えの方は Trusted Advisor を利用した自動修復ワークフローの運用を検討してみてはいかがでしょうか。
この記事がどなたかの参考になれば幸いです。
以上、ヒラネでした！