Amazon Web Services ブログ

AWS Systems Managerオートメーションランブックを利用して非準拠ステータスのAWS Configルールを修復する

AWS Config は、AWS リソースの設定を評価、監査、審査できるサービスです。一般的なコンプライアンスシナリオに対してはAWS Configマネージドルールを使用することが出来ます。また独自のシナリオに対しては、カスタムルールを作成することも出来ます。

このブログでは、AWS Systems Manager Explorerを使ってAWS Configルールのコンプライアンスステータスを収集する方法について説明していきます。収集範囲は、AWSアカウント内のリージョン全体となります。加えて、Systems Managerオートメーションランブックを使用して、非準拠になっているAWS Configルールを修復する方法についても説明していきます。

AWS Systems Managerオートメーションは、Amazon Elastic Compute Cloud (Amazon EC2) インスタンスおよびその他の AWS リソースの一般的なメンテナンスやデプロイタスクをシンプルにします。オートメーションを使用することで、インスタンスやAWSリソースの設定、管理を自動化出来ます。カスタムのランブックを作成するか、ユースケース別に用意されているAWS管理のランブックを利用することが出来ます。

AWS Systems Manager Explorerは、AWSリソースの情報を表示するオペレーションダッシュボードです。ダッシュボードはカスタマイズ可能です。エクスプローラーはAWSアカウント間および、リージョン間のオペレーションデータ(OpsData)を集約して表示します。またエクスプローラーは運用上の問題について、その分散状況、時間経過に伴う傾向、カテゴリ別の変化を読み取るのに役立ちます。

以下の図は、本ブログで紹介するソリューションのアーキテクチャになります。

図1: オートメーションランブックを使った、非準拠AWS Configルールの修復

ソリューション概要

このブログでは、以下の設定手順について説明していきます。

  • Systems ManagerオートメーションワークフローにアクセスするためのAWS Identity and Access Management (IAM)の設定。オートメーションを利用して非準拠のAWS Configルールの修復を行います
  • 非準拠のAWS Configルールを修復するオートメーションランブックの設定

 

前提条件

Aggregate operational tasks with AWS Systems Manager Explorer and OpsCenterブログ参照の上、以下の手順を実施してください。

  • AWS Systems Manager Qucik Setupを使ったエクスプローラーの設定
  • AWS Configルールの作成。エクスプローラーは、AWS アカウント内の AWS Config ルールとリソースのコンプライアンスステータスを収集します

上記の手順が完了したら、図2のように各ルールのコンプライアンス状況サマリーがAWS Configのダッシュボードに表示されます。エクスプローラーのダッシュボードには数時間以内に反映されます。

図2: AWS Configルールのコンプライアンスステータスのサマリー

オートメーションの設定

AWSは、オートメーションランブックのリファレンスを提供しています。運用タスクに応じてAWSが提供するオートメーションランブックを選択することが出来ます。また、オートメーションランブックを独自で構築して実行することや、チーム内または組織内の他のユーザと共有することも出来ます。
図3からは、運用タスクに関するオートメーションランブックのカテゴリが確認出来ます。

図3: オートメーションランブック

 

IAMユーザ、IAMグループまたはIAMロールにadministrator権限が割り当てられている場合、Systems Managerオートメーションへのアクセスが可能です。administrator権限がない場合は、AmazonSSMFullAccessポリシーまたは、同等のアクセス権限を持ったポリシーをIAMユーザ、IAMグループまたはIAMロールに付与する必要があります。AmazonSSMFullAccessポリシーは、Systems Managerのアクションに対する権限を付与します。ただし、一部のランブックでは、他のサービスに対する権限が必要になることもあります。AWS-ReleaseElasticIPランブックは、ec2: ReleaseAddressの権限が必要になります。ランブックで実行されたアクションを確認して、ランブックの実行に必要な権限がIAMユーザ、IAMグループ、またはIAMロールに付与されているかを確認しましょう。

オートメーションはサービスロールまたはロールの引き受け(Assume Role)で実行することが出来るため、ユーザに代わってアクションを実行出来ます。ロールを指定しない場合は、オートメーションを呼び出したIAMユーザの権限情報を使用することになります。サービスロールの作成については、AWS Systems Manager ユーザーガイドの「AWS CloudFormation を使用してオートメーションのサービスロールを設定する」または、「IAMを使用して、オートメーションのロールを設定する」を参照してください。

今回の手順では、AWS CloudFormationを使用してオートメーションのサービスロールを作成していきます。

  1. AWS-SystemsManager-AutomationServiceRole.zipをダウンロードします。このフォルダーには、AWS-SystemsManager-AutomationServiceRole.yamlというCloudFormationテンプレートが含まれています。
  2. AWS CloudFormationのコンソールにサインインして、スタックの作成を選択します。
  3. テンプレートの指定にて、テンプレートファイルのアップロードを選択します。
  4. 先ほどダウンロードしたAWS-SystemsManager-AutomationServiceRole.yamlを選択して、次へをクリックします。

図4: オートメーションサービスロールの作成

  1. スタック名には、automation-roleと入力します。
  2. スタックオプションの設定は、デフォルトのままとして次へをクリックします。
  3. レビューページで、「AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。」のチェックボックスにチェックを入れて、CloudFormationスタックを作成します。

図5: オートメーションサービスロール

  1. オートメーションサービスロールのARNを確認するには、IAMロールのページから、AutomationServiceRole を選択することで確認できます。ARNは、arn:aws:iam::AWSアカウントID:role/AutomationServiceRoleという形式になっています。
  2. ランブックによっては、ほかのサービスに対する権限が必要になります。図6にようにEC2、S3、およびDynamoDBのフルアクセス権限をオートメーションサービスロールに追加します。管理者が運用タスクを実行するケースでは、フルアクセスの権限を持った状態で運用出来ます。そうでない場合は、オートメーションランブックが行うアクションを確認し、必要なポリシーのみをオートメーションサービスロールに付与していきましょう。詳細についてはコチラを参照してください。

図6: オートメーションサービスロールのIAMポリシー

以上でランブックの実行に必要なオートメーションサービスロールが作成出来ました。独自にオートメーションランブックを作成する場合の詳細については、New Automation Features In AWS Systems Managerブログを参照してください。

ユースケースに応じて、様々なセキュリティモデル、様々なターゲット指定、及びレート制御によるオートメーションの実行が出来ます。また承認付きでのオートメーションや手動でのオートメーション実行も可能となります。

ここからは、オートメーションランブックを使って非準拠のAWS Configルールを修復する方法について説明していきます。

 

非準拠のAWS Configルールを修復する

AWS Configは、AWSアカウント内のリソースが互いにどのように関連しているか、過去にどのような設定がされたかを可視化します。そのため、AWSリソースの設定やリソース間の関連性の変化について時系列で確認することが出来ます。

一般的なコンプライアンスシナリオに対してはAWS Configマネージドルールを使用することが出来ます。また独自のシナリオに対しては、カスタムルールを作成することも出来ます。非準拠のAWSリソースを見つけた時は、AWS Systems Managerオートメーションランブックをを使用して、修復アクションを実行出来ます。

前提条件のパートで、5つのAWS Configルールをすでに作成しているかと思います。ここからは、オートメーションランブックを使用して、非準拠になっているルールを自動で修復する方法について説明していきます。修復アクションは手動で実行することも出来ます。またここで説明する手順は、マルチアカウント運用ではなく、一つのAWSアカウントでの実施を前提としています。

  1. AWS Systems Managerコンソールの左側メニューからエクスプローラーを選択してください。

図7: エクスプローラー上に表示される非準拠のルール

  1. エクスプローラーのページ内にあるAWS Configコンプライアンスの概要から、5と表示されているリンクを選択しましょう。これは非準拠の設定ルール数を示しています。

図8: 修復アクションが設定されていない非準拠のルール

  1. s3-bucket-versioning-enabledを選択し、図9のように詳細ページのアクションから、修復の管理を選択してください。

図9: s3-bucket-versioning-enabledの詳細ページ

  1. 修復アクションの編集画面にて、以下の値を入力して変更を保存をクリックしてください。
    • 修復方法を選択にて、自動修復を選択してください。再試行までの時間はデフォルト設定のままにしてください
    • 修復アクションの選択では、AWS-ConfigureS3BucketVersioningを選択してください
    • レート制限では、同時実行率を25、エラー率を35と入力してください
    • リソースIDパラメータでは、BucketNameを選択してください。この設定により、ランブックは非準拠のS3バケット全てを自動的に修復します
    • パラメータでは、AutomationAssumeRoleに、事前に作成したサービスロールのARNを指定してください

図10: s3-bucket-versioning-enabledの修復アクション

(訳注：以降、手順3と同様に対象のルールを選択し、修復アクションの設定を行っていきます。)

  1. s3-bucket-server-side-encryptionルールの修復アクションは以下の設定を行います。
    • 修復方法を選択にて、自動修復を選択してください。再試行までの時間はデフォルト設定のままにしてください
    • 修復アクションの選択では、AWS-EnableS3BucketEncryptionを選択してください
    • レート制限では、同時実行率を25、エラー率を35と入力してください
    • リソースIDパラメータでは、BucketNameを選択してください。この設定により、ランブックは非準拠のS3バケット全てを自動的に修復します
    • パラメータでは、AutomationAssumeRoleに、事前に作成したサービスロールのARNを指定してください

図11: s3-bucket-server-side-encryptionの修復アクション

  1. rds-instance-deletion-protection-enabledルールの修復アクションは以下の設定を行います。
    • 修復方法を選択にて、自動修復を選択してください。再試行までの時間はデフォルト設定のままにしてください
    • 修復アクションの選択では、AWS-ConfigRemediation-EnableRDSInstanceDeletionProtectionを選択してください
    • レート制限では、同時実行率を25、エラー率を35と入力してください
    • リソースIDパラメータでは、DbInstanceResourceIdを選択してください。この設定により、ランブックは非準拠のRDSインスタンス全てを自動的に修復します
    • パラメータでは、ApplyImmediatelyをtrueに、AutomationAssumeRoleに、事前に作成したサービスロールのARNを指定してください

図12: rds-instance-deletion-protection-enabledの修復アクション

  1. eip-attachedルールの修復アクションは以下の設定を行います。
    • 修復方法を選択にて、自動修復を選択してください。再試行までの時間はデフォルト設定のままにしてください
    • 修復アクションの選択では、AWS-ReleaseElasticIPを選択してください
    • レート制限では、同時実行率を25、エラー率を35と入力してください
    • リソースIDパラメータでは、AllocationIdを選択してください。この設定により、ランブックは非準拠のEIPアドレス全てを自動的に修復します
    • パラメータでは、AutomationAssumeRoleに、事前に作成したサービスロールのARNを指定してください

図13: eip-attachedの修復アクション

  1. dynamodb-pitr-enabledルールの修復アクションは以下の設定を行います。
    • 修復方法を選択にて、自動修復を選択してください。再試行までの時間はデフォルト設定のままにしてください
    • 修復アクションの選択では、AWSConfigRemediation-EnablePITRForDynamoDBTableを選択してください
    • レート制限では、同時実行率を25、エラー率を35と入力してください
    • リソースIDパラメータでは、TableNameを選択してください。この設定により、ランブックは非準拠のDynamoDBテーブル全てを自動的に修復します
    • パラメータでは、AutomationAssumeRoleに、事前に作成したサービスロールのARNを指定してください

図14: dynamodb-pitr-enabledの修復アクション

以上でオートメーションランブックを使った非準拠のAWS Configルールの修復作業は完了です。

(訳注：以上の設定で非準拠のAWS Configルールが検出されると、自動的にオートメーションランブックが実行され、修復処理が行われます。検出のタイミングは使用するConfigルールによって異なります。詳しくはこちらをご参照ください。本ブログで設定した修復アクションは数分を目安に実行され、修復後のステータスが反映されます。)

図15: 修復アクション実行後のAWS Configルール

まとめ

このブログでは、非準拠のAWS Configルールをオートメーションランブックを使って自動的に修復する方法について説明してきました。このブログの情報を活用することで、独自のAWS Configルールを作成して、修復アクションの設定も出来るかと思います。AWS Systems Manager の機能の詳細については、AWS Systems Manager ユーザーガイドを参照してください。

 

著者

Raghavarao Sodabathina

Raghavarao Sodabathina は AWS のエンタープライズソリューションアーキテクトです。彼のフォカースエリアは、データ分析、AI/ML、サーバーレスプラットフォームです。彼はお客様のビジネス上の問題に対処し、AWS サービスの導入を加速する革新的なソリューションを開発しています。暇な時に、Raghavaraoは家族と過ごしたり、本を読んだり、映画を見たり楽しんでいます。

 

こちらのブログはSA上野が翻訳しました。原文はこちら