こんにちは！ AWS 事業本部コンサルティング部のトクヤマシュンです。
フィラデルフィアで開催されている AWS re:Inforce 2024 に参加しています。
本記事は AWS re:Inforce 2024 のセッション「Evaluate risk and automate remediation in your AWS environment」のセッションレポートです。 AWS Trusted Advisorを使ってAWS環境を評価し、手動もしくは自動での修復を行うハンズオン形式のセッション（Builders'session）でした。
セッション概要
In today’s fast-paced cloud computing landscape, organizations face numerous challenges when maintaining a secure, efficient, and cost-effective cloud infrastructure. AWS Trusted Advisor is a powerful tool that helps mitigate risks and optimize resource utilization to support compliance with AWS Well-Architected best practices and standards. In this builders’ session, dive deep into the capabilities of Trusted Advisor and explore its checks and recommendations that are tailored to different aspects of cloud management. Learn how to effectively utilize Trusted Advisor features like automatic checks, customizable alerts, and actionable recommendations so that you can proactively identify and address potential risks within your AWS environments. You must bring your laptop to participate.
構成図
このBuilders'sessionでは次のような構成をとります。
大きく2つのワークフローに分かれます。
TA Check Results Tracker Workflow
リスク評価のためのワークフローです。
Trusted Advisorのチェック結果に更新があると、それを契機にEventbridgeによってLambda Functionを起動し、Trusted Advisorのチェック結果をDynamoDBに格納します。
Trusted Advisoreからは最新のチェック結果と1つ前のチェック結果のイベントが送信されます。これにより、状態変化が起こったかトラッキングできます。
TA Check Results Automation Workflow
修復自動化のためのワークフローです。
リスク評価のワークフローからDynamoDB StreamsによってLambdaを起動します。
修復の実行状況はOpsItemを用いて管理します。
検知されたリスクの修復に利用できるSSM Automationドキュメントが定義されていればそれを用いて自動修復し、なければ手動で修復を実施します。
AWS Seucirity Hub の自動修復ソリューションは提供されていますが、そのTrusted Advisor版を自前で構築するようなイメージですね。
個人的にはOpsItemを使って修復状況の管理を行うのが新鮮です。
いざ、ハンズオン
環境構築
ハンズオンは各ワークフローをデプロイ済みのAWSアカウントが提供された状態から始まりました。
ただ、2つのワークフローつなげる部分だけは設定がなかったので、手順にそってTACheckTrackerTableのDynamoDB StreamsからTA ResultHandlerFunctionを呼び出す部分だけを構築しました。ここではチェック結果のステータスが「Red」もしくは「Yellow」の時のみ呼び出しを行うよう設定します。
評価・修復
構築が終われば、実際にリスク評価と修復を試してみます。ここでは「手動での評価・修復」と「自動での評価・修復」の2つを行いました。
手動での評価・修復
この章ではパブリックIPアドレスを持つEC2インスタンスを検知し、手動での修復を行ないます。
はじめに、AutoScaling GroupによってEC2インスタンスを起動します。このAutoScaling Groupの起動テンプレートではAssociatePublicIpAddressがtrueとなっており、EC2にパブリックIPアドレスが割り当てられます。
EC2はパブリックIPアドレスを持たないことが推奨されているため、Trusted Advisorがそれを検知し、Redとしてチェック結果を更新します。
OpsCenterを確認すると、アイテムがOpenされています。
そのため、起動テンプレートのAssociatePublicIpAddressをfalseに変更し、インスタンス更新を行うとEC2のパブリックIPアドレスを持たないEC2インスタンスへの置き換えが発生します。
この状態でしばらく待つと、Trusted Advisorのチェック結果がOKになるとともに、OpsCenterのアイテムがResolvedに変更されます。
このようにして、ひととおりの手動修復の流れを確認できました。
自動での評価・修復
この章ではポート22に対して0.0.0.0/0をを許可するイングレスルールを持つセキュリティグループを検知し、自動での修復を行います。
自動修復にはAWS-DisablePublicAccessForSecurityGroupというAWSが提供するSSM Automationドキュメントを使います。
Trusted Advisorの検知結果と関連づけるために、AWS Cludshellで次のコマンドを実行して、AutomationMappingTableにマッピング用のアイテムを追加します。
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
}
}'この状態でポート22に対して0.0.0.0/0をを許可するイングレスルールを持つセキュリティグループを作成すると、TrustedAdvisorによって検知された後にAutomationが自動実行され、イングレスルールが削除されます。
しばらく待ってOpsCenterを確認すると、すでに状態がResolvedとなったアイテムが確認できます。
以上でハンズオンは終了です。
おわりに
以上、「Evaluate risk and automate remediation in your AWS environment 」のセッションレポートでした！
Trusted Advisorを有効化しているアカウントは多いと思いますが、このハンズオンのように一歩踏み込んで自動修復まで行なってみてはいかがでしょうか。SSM Automationドキュメントも結構な数用意されているので、まずはそれらを利用した自動修復から始めてみるのがオススメです。
この記事がどなたかの参考になれば幸いです。
4
