Go to Qiita Advent Calendar 2024 Top
LoginSignup
6
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@risa_someya(risa someya)inＡＲアドバンストテクノロジ株式会社（ARI）

マルチアカウント環境でAWS Configのルール非準拠判定の通知を一元化させてみた

Last updated at Posted at 2021-04-27

#はじめに
AWSのマルチアカウントでのシステム構成も増えてきて、サービスの役割ごとにアカウントを使い分けるケースもあるかと思います。
構成例として、Configルールは各アカウントで設定するが、メール通知やログ管理は一つのアカウントに集約させるといったような構成があげられます。

本記事では、アカウントA（送信側アカウント）で非準拠判定されたConfigルールを、アカウントB（受信側アカウント）のSNSトピックを利用してEメール通知させる設定方法について書いていきたいと思います。

#構成図
構成図.JPG
アカウントAでAWS Configルールを「required-tags」で新規作成し、EC2インスタンスのタグに「Name」「Application」の2つが含まれているかを判定します。
判定結果が非準拠となると、アカウントAのEventBridgeで検知しアカウントBのEventBridgeへ連携され、紐づけられたSNSを使って対象者にメール通知されます。
（参考：AWS Configのルールで非準拠判定されたらメール通知したい）

アカウントBをバージニアリージョンにしていますが、受信側のイベントバスがバージニア、オレゴン、アイルランドリージョンに限定されてしまっているためです。
（参考：AmazonEventBridgeを使用したクロスリージョンイベントルーティングの紹介）

今回は送信側のアカウントAを東京リージョン、受信側のアカウントBをバージニアリージョンで構築していきます。

#構築順
本記事では以下の流れで環境構築を進めていきます。

アカウントA（送信側アカウント）

  1. Configルール作成

アカウントB（受信側アカウント）
2. KMSキー（カスタマー管理型 以降CMK）作成
3. SNSトピック作成
4. EventBridge作成

アカウントA（送信側アカウント）
5. EventBridge作成

以下に詳細な構築手順を記載していくので、実際に構築していってみましょう。

#環境構築手順
##1. Configルール作成
アカウントAにログインし、東京リージョンを選択した状態でAWS Configに移動し、「ルールの追加」をクリックします。
Config001_01.jpg

ルールタイプ「AWSによって管理されるルールの追加」を選択します。
「required-tags」を検索し、チェックを入れて「次へ」をクリックします。
Config002_01.jpg

以下でルールの設定を行い、「次へ」をクリックします。

  • 名前：任意の名前（ここでは「required-tags」）

  • 説明：任意の説明（ここではデフォルトのまま）
    Config003_01.jpg

  • 変更範囲：リソース

  • リソース：任意のリソース（ここでは「AWS EC2 Instance」）
    Config004_01.jpg

  • tag1Key：Name

  • tag2Key：Application

  • 上記以外は記載せず
    Config005_01.jpg

「確認と作成」で設定内容を確認し、「ルールを追加」をクリックします。
Config006_01.jpg
Config007_01.jpg

無事ルールが作成されたことを確認します。
Config009_01.jpg

##2. CMK作成
アカウントBにログインし、バージニアリージョンを選択した状態でKMSに移動します。カスタマー管理型のキーを選択し、「キーの作成」をクリックします。
バージニア001_01.jpg

以下でキーを設定し、「次へ」をクリックします。

  • キーのタイプ：対象
  • キーマテリアルオリジン：KMS
    バージニア002_01.jpg

以下でラベルの追加をし、「次へ」をクリックします。

  • エイリアス：任意のエイリアス名（ここでは「test-sns」）
    バージニア003_01.jpg

ステップ3とステップ4はデフォルト設定のまま「次へ」をクリックします。

ステップ5のキーポリシーに以下の内容を記載し「完了」をクリックします。

{
    "Id": "key-consolepolicy-3",
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<Account B>:root"
            },
            "Action": "kms:*",
            "Resource": "*"
        },
        {
            "Sid": "Allow_EventBridge_for_CMK",
            "Effect": "Allow",
            "Principal": {
                "Service": "events.amazonaws.com"
            },
            "Action": [
                "kms:Decrypt",
                "kms:GenerateDataKey"
            ],
            "Resource": "*"
        }
    ]
}

※「"Sid": "Allow_EventBridge_for_CMK"」以降の設定を記載することで、EventBridgeからKMSへのアクセスを許可します。見落としがちですが、SNSの暗号化をCMKで行う場合は、KMSのキーポリシーが原因で想定通りに動作できないといったことも起こり得るので設定内容には注意しましょう。

無事CMKが作成されたことを確認します。
Config010_01.jpg

##3. SNSトピック作成
###3-1.トピック作成
アカウントBにログインし、バージニアリージョンを選択した状態でAmazon SNSに移動し、トピックを選択し「トピックの作成」をクリックします。
バージニア007_01.jpg

詳細は以下の設定を行います。

  • タイプ：スタンダード
  • 名前：任意の名前（ここでは「test-sns」）
  • 表示名：任意の表示名（ここでは「AWSConfig-NON_COMPLIANT」）
    バージニア008_01.jpg

暗号化は以下の設定を行います。

  • 暗号化：暗号化の有効化
  • カスタマーマスターキー（CMK）：「2. CMK作成」で作成したKMSキー（ここでは「alias/test-sns」）
    バージニア009_01.jpg

アクセスポリシーは以下の設定を行います。

  • メソッドの選択：高度な
  • JSONエディタ：以下テキスト
    Config011_01.jpg 
{
  "Version": "2008-10-17",
  "Id": "__default_policy_ID",
  "Statement": [
    {
      "Sid": "__default_statement_ID",
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": [
        "SNS:Publish",
        "SNS:RemovePermission",
        "SNS:SetTopicAttributes",
        "SNS:DeleteTopic",
        "SNS:ListSubscriptionsByTopic",
        "SNS:GetTopicAttributes",
        "SNS:Receive",
        "SNS:AddPermission",
        "SNS:Subscribe"
      ],
      "Resource": "arn:aws:sns:us-east-1:<Account B>:test-sns",
      "Condition": {
        "StringEquals": {
          "AWS:SourceOwner": "<Account B>"
        }
      }
    },
    {
      "Sid": "AWSEvents_Allow",
      "Effect": "Allow",
      "Principal": {
        "Service": "events.amazonaws.com"
      },
      "Action": "sns:Publish",
      "Resource": "arn:aws:sns:us-east-1:<Account B>:test-sns"
    }
  ]
}

※「"Sid": "AWSEvents_Allow"」以降の設定を記載することで、EventBridgeからSNSへのアクセスを許可します。こちらもKMSのキーポリシー同様、アクセスポリシーが原因で想定通りに動作できないといったことも起こり得るので設定内容には注意しましょう。

無事トピックが作成されていることを確認します。
Config013_01.jpg

###3-2.サブスクリプションの作成
3-1で作成したSNSトピックに移動し、サブスクリプションタブを開いた状態で「サブスクリプションの作成」をクリックします。
バージニア013_01.jpg

詳細は以下の設定を行い、「サブスクリプションの作成」をクリックします。

  • トピックARN：3-1で作成したSNSトピック（ここでは「test-sns」）
  • プロトコル：Eメール
  • エンドポイント：通知させるメールアドレス

バージニア014_01.jpg

以下のようなメールが届くので、メール本文中の「Confirm subscription」をクリックします。
Config014_01.jpg

ブラウザに遷移し、以下の画面が表示されることを確認します。
Config015_01.jpg

マネジメントコンソール上でも、ステータスが「確認済み」になったことを確認します。
バージニア016_01.jpg

##4. EventBridge作成（受信側アカウントB）
###4-1.イベントバスのアクセス設定
アカウントBにログインし、バージニアリージョンを選択した状態でEventBridgeに移動し、イベントバスのdefaultを開きます。
「アクセス許可を管理」をクリックします。
Config016_01.jpg

リソースベースのポリシーに以下テキストを記載し、「作成」をクリックします。

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "allow_account_to_put_events",
    "Effect": "Allow",
    "Principal": {
      "AWS": "<Account A>"
    },
    "Action": "events:PutEvents",
    "Resource": "arn:aws:events:us-east-1:<Account B>:event-bus/default"
  }]
}

※このアクセス許可でアカウントAからのEventBridgeのアクセスを許可します。受信側のアカウントでは必要な設定となるので気を付けましょう。

イベントバスのARNは後述の5. EventBridge作成時に必要になるので、メモを取っておきましょう。

###4-2.ルールの作成
ルールを開き、イベントバスに「default」が選択されている状態で「ルールを作成」をクリックします。
Config017_01.jpg

名前と説明は以下を設定します。

  • 名前：任意の名前（ここでは「test-config」）
  • 説明：任意の説明（ここではデフォルトのまま）

バージニア020_01.jpg

パターンを定義は以下を設定します。

  • イベントパターンorスケジュール：イベントパターン
  • イベント一致パターン：カスタムパターン
  • イベントパターン：以下テキスト

バージニア021_01.jpg

{
  "source": ["aws.config"],
  "detail-type": ["Config Rules Compliance Change"],
  "detail": {
    "messageType": ["ComplianceChangeNotification"],
    "configRuleName": [
      "required-tags"
    ],
    "newEvaluationResult": {
      "complianceType": ["NON_COMPLIANT"]
    }
  }
}

※「"configRuleName"」の箇所は、作成したConfigルール名によって適宜書き換えてください。

イベントバスがデフォルトのものが選択されていることを確認します。
Config018_01.jpg

ターゲットを選択は以下の設定を行います。

  • ターゲット：SNSトピック
  • トピック：3-1で作成したSNSトピック（ここでは「test-sns」）
  • 入力の設定：入力トランスフォーマー

バージニア023_01.jpg

  • 入力トランスフォーマー
    • 入力パス：以下①テキスト
    • 入力テンプレート：以下②テキスト
①.txt
{
        "awsRegion": "$.detail.awsRegion",
        "resourceId": "$.detail.resourceId",
        "awsAccountId": "$.detail.awsAccountId",
        "compliance": "$.detail.newEvaluationResult.complianceType",
        "rule": "$.detail.configRuleName",
        "time": "$.detail.newEvaluationResult.resultRecordedTime",
        "resourceType": "$.detail.resourceType"
}
②.txt
"発生時刻 : <time>"
"ルール名 : <rule> "
"リソースタイプ : <resourceType>"
"リソースID : <resourceId>"
"AWSアカウント : <awsAccountId>"


"上記リソースが <compliance> 判定となりました。"
"詳細は以下URLよりご確認ください。"
"https://console.aws.amazon.com/config/home?region=<awsRegion>#/timeline/<resourceType>/<resourceId>/configuration"

上記入力が完了したら、「作成」をクリックします。

無事ルールが作成されていることを確認します。
EventBridge013_01.jpg

##5. EventBridge作成（送信側アカウントA）
アカウントAにログインし、東京リージョンを選択した状態でEventBridgeに移動します。
ルールを開き、イベントバスでdefaultが選択されている状態で「ルールを作成」をクリックします。
EventBridge001_01.jpg

「イベントバスを選択」までは4-2.ルールの作成と同様のものを設定します。（ここではルール名を「test-notice-config」とし、それ以外は4-2と同様の設定を行います。）

ターゲットを選択は以下の設定を行います。

  • ターゲット：別のアカウントまたはリージョンのイベントバス
  • イベントバス：「4-1.イベントバスのアクセス設定」で設定したイベントバスARN
  • IAMロール：この特定のリソースに対して新しいロールを作成する。
    EventBridge004_01.jpg

※IAMロールを別途手動で作成する場合は、アカウントBのイベントバスへのアクセスを許可する内容で作成された、以下IAMポリシーを含んだIAMロールを作成する必要があります。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "events:PutEvents"
            ],
            "Resource": [
                "arn:aws:events:us-east-1:<Account B>:event-bus/default"
            ]
        }
    ]
}

ターゲットを選択まで設定が完了したら「作成」をクリックし、ルールの作成を行います。

無事ルールが作成されていることを確認します。
EventBridge005_01.jpg

以上で環境構築は完了です。このあと動作確認をしていきます。

#動作確認
今回はEC2インスタンスのタグに「Name」「Application」が含まれているか判定するConfigルールを作成しているので、
アカウントA側の任意のEC2インスタンスから、タグ「Application」を削除してみます。

EC2の画面を表示し、任意のEC2インスタンスを選択したら、「タグを管理」をクリックします。
EventBridge006_01.jpg

キーがApplicationのタグを削除し、「保存」をクリックします。
EventBridge007_01.jpg

Configの画面を表示し、1. Configルール作成で作成した「required-tags」を表示します。
アクションから再評価をクリックします。
EventBridge014_01.jpg

数分後、非準拠のルールとしてApplicationタグを削除したEC2インスタンスが検知され、3-2.サブスクリプションの作成で設定したメールアドレスあてにメールが届くことを確認します。
EventBridge009_01.jpg
EventBridge011_01.jpg

以上で実装は完了です。

#おわりに
今回はマルチアカウントのシステムで活用できる、Configで非準拠ルールが検知された際に他アカウントのSNSトピックでメール通知させる構成を作成してみました。
複数アカウントのマルチアカウントシステムとなる場合、各アカウントでSNSトピックを管理するよりも圧倒的に管理工数が削減できるかと思います。
また、メール通知させるメール本文をEventBridgeで設定できるのがよいですね。
通知に必要な情報をピックアップして本文をカスタマイズするのもよいと思います。

以下に本構成を検討する際に参考にしたURLを貼っておきますので、こちらもあわせてご参照ください。

#参考記事
AWS リソースが準拠していない場合に AWS Config を使用して通知を受けるにはどうすればよいですか?

AWS Configのルールで非準拠判定されたらメール通知したい

AmazonEventBridgeを使用したクロスリージョンイベントルーティングの紹介

AWSアカウント間でAmazon EventBridgeイベントを送受信してみた

6
6
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
6
6

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?