「AWS Configルール」と「AWS Systems Manager」の「Automation」を利用したリスクあるリソースの自動検知、自動修復：AWSチートシート

AWS活用における便利な小技を簡潔に紹介する連載「AWSチートシート」。今回は、「AWS Configルール」と「AWS Systems Manager」の「Automation」を利用したリスクあるリソースの自動検知、自動修復を紹介する。

» 2021年02月15日 05時00分公開

[天野盛介，東京ITスクール]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　「Amazon Web Services」（AWS）活用における便利な小技を簡潔に紹介する連載「AWSチートシート」。今回は、「AWS Configルール」と「AWS Systems Manager」の「Automation」を利用して、あらかじめ設定したルールに違反する設定を自動で検知、修復する方法を紹介します。

　AWSにおけるインシデント対応では、想定されるリスクが発現することを事前に予防する「予防的統制」と、想定外のリスクの発現を検知して即座に対応する「発見的統制」の2つの考えが存在します。今回紹介するAWS Configルールを利用した非準拠リソースの自動修復は後者の発見的統制に当たるものです。

　どれだけ対策してもインシデントの発生を100％防ぐことは困難なので、「インシデントは発生するもの」としてインシデントが発生した際の対策を事前に施しておくことも重要になります。AWS Configルールの活用は、そういった対策の一つになるので本稿を通して利用方法を確認しておきましょう。

AWS Configルールの概要

　AWS Configルール（以下、Configルール）は、AWSリソースの設定履歴を保存するサービス「AWS Config」の一機能です。Configルールを利用することで、AWSリソースの設定がルールに準拠しているかどうかをチェックできます。

　このConfigルールには、AWSによって提供されている「マネージドルール」と「AWS Lambda」の関数を利用して実装できる「カスタマールール」があります。マネージドルールはコンピューティングやネットワーク、データベース、ストレージ、セキュリティといった多くのサービスを対象とするルールが存在していて、その数は2021年2月時点で165となっています。

　全てのマネージドルールについては公式レファレンスを確認してもらえればと思いますが、主なルールを一部抜粋して紹介するので参考にしてください。

表1　AWS Configマネージドルールから一部抜粋
ルール名	チェック内容
access-key-roatated	「AWS Identity and Access Management」（IAM）アクセスキーをローテーションしているかどうか
ec2-instance-no-public-ip	「Amazon EC2」インスタンスにパブリックIPアドレスが関連付けされていないかどうか
encrypted-volumes	「Amazon Elastic Block Store」（EBS）ボリュームが暗号化されているかどうか
root-account-mfa-enabled	ルートアカウントのMFA（Multi-Factor Authentication：多要素認証）が有効になっているかどうか
s3-bucket-public-read-prohibited	「Amazon S3」のパブリック読み込みが禁止されているかどうか

Configルールを利用した非準拠リソースの自動修復方法

　ここからは、セキュリティグループにおいてSSHが全開放された場合の自動修復設定を例にConfigルールを利用した非準拠リソースの自動修復方法を説明します。

　構成の概要としては、まずConfigマネージドルールの「restricted-ssh」を利用してSSHが全開放されたことを検知できるように設定します。その上で、SSHの全開放を検知した場合の自動修復には「AWS Systems Manager」を利用します。

Configルールを利用した非準拠リソースの自動修復方法の概要

　以前の記事『「Amazon EC2」インスタンスの設定ミスを防ぐ「AWS Systems Manager」によるリモートコマンド実行』ではAWS Systems Managerの「Run Command」を紹介しましたが、今回はAWS Systems Managerの「Automation」を利用してルール違反時の自動修復を行います。Automation機能には、特定の設定を自動実行する手順をテンプレート化したオートメーションドキュメントがAWSによって提供されています。

表2　AWS Systems Managerオートメーションドキュメントから一部抜粋
ドキュメント名	概要
AWS-ResizeInstance	EC2のインスタンスサイズを変更
AWS-ReleaseElasticIP	指定された「Elastic IP アドレス」を開放
AWS-DisableS3BucketPublicReadWrite	S3のパブリック公開を無効化
AWS-CreateDynamoDBBackup	「Amazon DynamoDB」テーブルのバックアップを作成
AWS-EnableCloudTrail	「AWS CloudTrail」を有効化

　今回は「AWS-DisablePublicAccessForSecurityGroup」を利用してSSHへのパブリックアクセスを自動で無効化します。

※注意

こちらのドキュメントは、以下の条件を両方とも満たす場合はエラーとなってしまって修復できないので、気を付けてください。

条件1：セキュリティグループがデフォルト以外のAmazon Virtual Private Cloud（VPC）に配置されている
条件2：セキュリティグループのインバウンドルールで、次の4つのパターンを全て使用するオープンポートが指定されていない
- 0.0.0.0/0
- ::/0
- SSH or RDP port + 0.0.0.0/0
- SSH or RDP port + ::/0

Configルールを利用した自動修復設定の実装

　以下のステップに沿ってConfigルールを利用した自動修復を設定していきます。

Systems Manager用IAMロールの作成
SSH全開放を検知するConfigルールの作成
違反検知時の自動修復設定
自動修復の確認

【ステップ1】Systems Manager用IAMロールの作成

　まずは、自動修復する際にSystems Managerが利用するIAMロールを作成します。IAMロールの作成画面でエンティティとユースケースを以下のように選択しましょう。

図1　エンティティの種類で「AWS サービス」を選択

図2　ユースケースの一覧から「Systems Manager」を選択

図3　「ユースケースの選択」で「Systems Manager」を選択

　IAMロールにアタッチするポリシーには、EC2のオープンになっているポートを修復できるように、「ec2:RevokeSecurityGroupIngress」の権限を付与します。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": "ec2:RevokeSecurityGroupIngress",
            "Resource": "*"
        }
    ]
}

【ステップ2】SSH全開放を検知するConfigルールの作成

　Configのダッシュボードで「ルール」→「ルールを追加」をクリックして、SSHの全開放を検知するConfigルールを作成します。

図4　Configのダッシュボードで「ルール」→「ルールを追加」をクリック

　「ルールタイプの指定」では「AWSによって管理されるルールの追加」が選択されていることを確認して、検索ウィンドウから「restricted-ssh」を検索して選択します。

図5　「ルールタイプの指定」

　続いて、ルールに準拠しているかどうか評価するタイミングをトリガーとして指定します。今回はセキュリティグループの作成や設定変更を自動検知したいので、トリガータイプは「設定変更時」、変更範囲は「リソース」、リソースは「AWS EC2 SecurityGroup」をそれぞれ選択します。

図6　トリガーの設定

　以上の設定でConfigルールの作成は完了です。

【ステップ3】違反検知時の自動修復設定

　Configルールの作成が完了したら、ルールに準拠していないリソースを発見した際の自動修復を設定します。Configルールの一覧から「restricted-ssh」を選択して「アクション」→「修復の管理」とクリックします。

図7　Configルールの修復アクションを設定

　修復アクションでは「自動修復」を選択し、Systems Manager Automationを利用した修復アクションとして「AWS-DisablePublicAccessForSecurityGroup」を選択します。

図8　「修復方法」と「修復アクション」を選択

　続いて、自動修復に利用するパラメーターを設定します。ここで指定する「リソースIDパラメータ」とは、自動修復の実行時にConfigルールからSystems Manager Automationに渡される検知リソースの情報です。今回は修復対象となるセキュリティグループのIDが必要なので、プルダウンから「GroupID」を選択します。

　また、Automationからセキュリティグループを修復する際に利用するIAMロールとして、【ステップ1】で作成した「ARN」（Amazon Resource Name）を指定しましょう。

図9　「リソースIDパラメータ」と「パラメータ」を指定

　以上で、Systems Manager Automationを利用した自動修復設定は完了です。

【ステップ4】自動修復の確認

　自動修復を確認してみましょう。今回はデフォルトの「VPC」を選択して、以下のようにSSHを開放したセキュリティグループを作成してみました。

図10　SSHを開放したセキュリティグループ

　作成からしばらくたつと、Configルールの詳細画面でルールに非準拠のリソースとして上記のセキュリティグループが検出されます。

図11　Configルールでの非準拠リソースの検知

　さらにそこから数分たってから検知状況を更新してみると、ステータスが「準拠」に変わっていることを確認できます。

図12　Configルールでの非準拠リソースの検知

　作成したセキュリティグループの情報を再度確認すると、「0.0.0.0/10」を指定していたインバウンドルールが削除されていました。

図13　Configルールによって自動修復されたセキュリティグループ

　CloudTrailのイベント履歴を併せて確認すると、ユーザーによって作成、承認されたセキュリティグループがSystems Managerによって修復（RevokeSecurityGroupIngress）されていることが分かります。

図14　自動修復に関するCloudTrailのイベント履歴

終わりに

　今回は、ConfigルールとSystems Manager Automationを利用してルールに準拠していないリソースを自動で検知、修復する方法を紹介しました。今回利用したConfigルール、オートメーションドキュメントは共にAWSによって非常に多くの種類が提供されています。

　また、オートメーションドキュメントを利用した自動修復以外にも、「AWS CloudWatchイベント」とLambda関数を組み合わせることで独自の修復処理を実装することもできるので一度利用を検討してみてはいかがでしょうか。

筆者紹介

天野盛介（あまのせいすけ）

株式会社システムシェアード

マルチクラウドへの閉域接続サービスのサービスマネジメント業務に従事した後、AWS案件での基盤構築支援などを担当。社内では、検証・学習用にAWSを完全定額で利用できるサービス「安心サンドボックス」の立ち上げや東京ITスクールのAWS研修におけるコンテンツ開発、Java・AWS研修の講師などを歴任。

「AWS Lambda」が拡張機能を介して各種運用ツールと統合可能に
サーバのプロビジョニングや管理をすることなくコードを実行できる「AWS Lambda」サービスが利用しやすくなった。AWS Lambda拡張機能を使うことでモニタリングや可観測性、セキュリティ、ガバナンスのための運用ツールをAWS Lambdaと統合して利用できる。
パッチを当てよーっと――クラウド上でセキュリティの運用・監視を行うための基礎知識
親子の会話で出てくるような素朴な疑問点から、クラウド環境における情報セキュリティの技術を学習する連載。今回は、クラウド上でセキュリティの運用・監視を行うための基礎知識について。
「AWS Control Tower」の正式提供を開始、サービスの一元管理に役立つ
Amazon Web Services（AWS）は、マルチアカウントAWS環境を簡単にセットアップ、管理できるサービス「AWS Control Tower」の正式提供を開始した。企業環境の全てのアカウントで、AWSサービスを一元管理し、活用できる。