この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。
あってはならないですが、本番環境でいつのまにかセキュリティグループのインバウンドルールが追加されていることがあります。
偶然気づけばいいですが、気づかずにそのままポートが空き続けていたらゾッとしますよね。
今回の記事では、Amazon EventBridgeを使って、セキュリティグループの作成・変更・削除を検知する仕組みを紹介します。
Amazon EventBridgeでセキュリティグループの変更を検知
構築の流れは以下の通りです。
- Amazon SNSトピック作成
- Amazon EventBridgeルール作成
■Amazon SNSトピック作成
検知した際に通知してくれるAmazon SNSトピックを作成します。
↓Amazon SNSコンソール画面に行きます。
↓左のコンソール画面から[トピック] 、[トピックの作成]をクリックします。
↓[タイプ]を[スタンダード]を選択し、[名前]・[表示名]を入力します。
項目 | 設定値 |
---|---|
名前 | saitou-test-topic |
表示名 | SG変更検知 |
↓[トピックの作成] をクリックします。
↓トピックの一覧から、作成したトピックを選択します。[サブスクリプション]タブから[サブスクリプションの作成] をクリックしてください。
↓[プロトコル]で、[Eメール]を選択します。[エンドポイント]で、通知を受け取るEメールアドレスを入力し、[サブスクリプションの作成]を押してください。
↓入力したメールアドレスに確認メールが来るので、メール本文にある[Confirm subscription]をクリックします。
↓
Amazon SNSトピックの作成は以上です。
■Amazon EventBridgeルール作成
セキュリティグループが作成・変更・削除される際のAPIコールをトリガーにAmazon SNSに通知を送信するためのAmazon EventBridgeルールを作成します。
↓Amazon EventBridgeコンソール画面にいきます。
↓左のナビゲーションペインから[ルール]をクリックし、[ルールを作成]を押します。
↓ルールの [名前]を入力します。[説明]は任意で入力します。[イベントパス]はdefault、[ルールタイプ]は[イベントパターンを持つルール]を選択し、[次へ]をクリックします。
項目 | 設定値 |
---|---|
名前 | saitou-test-rule-securitygroup-change |
説明 | 任意 |
↓[イベントソース]を[AWS イベントまたは EventBridge パートナーイベント]を選択します。
↓[作成のメソッド]で[パターンフォームを使用する]を選択します。
↓[イベントソース]で、[AWSサービス]を選択し、[AWSのサービス]で、[EC2]を選択します。
↓[イベントタイプ]で、[AWS API Call via CloudTrail] を選択します。
↓[特定のオペレーション]を選択し、以下のAPIコールを一つずつ追加していきます。
- AuthorizeSecurityGroupIngress:インバウンドルールを追加
- AuthorizeSecurityGroupEgress:アウトバウンドルールを追加
- RevokeSecurityGroupIngress:インバウンドルールを削除
- RevokeSecurityGroupEgress:アウトバウンドルールを削除
- ModifySecurityGroupRules:セキュリティグループルールを変更
- CreateSecurityGroup:セキュリティグループを作成
- DeleteSecurityGroup:セキュリティグループを削除
↓入力が完了したら、[次へ]をクリックします。
↓[ターゲットタイプ]で[AWSのサービス]を選択し、[ターゲットを選択]で[SNSトピック]を選択、[トピック]で作成したトピックを選択します。
↓[追加設定]で[ターゲット入力を設定]から[入力トランスフォーマー]を選択し、[入力トランスフォーマーを設定]をクリックします。
↓[ターゲット入力トランスフォーマー]の[入力パス]で以下を入力します。
{
"ModifySecurityGroupRulesRequest": "$.detail.requestParameters.ModifySecurityGroupRulesRequest",
"userName": "$.detail.userIdentity.userName",
"eventID": "$.detail.eventID",
"eventName": "$.detail.eventName",
"eventTime": "$.detail.eventTime",
"accountId": "$.account",
"groupId1": "$.detail.requestParameters.groupId",
"groupId2": "$.detail.requestParameters.ModifySecurityGroupRulesRequest.GroupId",
"groupId3": "$.detail.responseElements.groupId",
"awsRegion": "$.region"
}
↓[テンプレート]で以下を入力します。
"セキュリティグループで以下のイベントが発生しました。"
"イベント名 : <eventName> "
"イベントID : <eventID> "
"セキュリティグループID : <groupId1> <groupId2> <groupId3> "
"発生アカウントID : <accountId> "
"発生時間 : <eventTime> UTC "
"発生リージョン : <awsRegion> "
"ユーザーID : <userName> "
"変更内容 : <ModifySecurityGroupRulesRequest> "
"※作成・削除の場合、変更内容は空白です。"
↓入力が完了したら、[確認]します。
↓[次へ]をクリックします。
↓[タグ]は任意で設定し、[次へ]をクリックします。
↓問題なければ、[ルールの作成]をクリックします。
構築は以上です。
■動作確認
動作確認をしていきます。今回トリガーになるAPIコールは以下の通りです。作成・変更・削除作業を行い、通知が来るのか試してみましょう。
- AuthorizeSecurityGroupIngress:インバウンドルールを追加
- AuthorizeSecurityGroupEgress:アウトバウンドルールを追加
- RevokeSecurityGroupIngress:インバウンドルールを削除
- RevokeSecurityGroupEgress:アウトバウンドルールを削除
- ModifySecurityGroupRules:セキュリティグループルールを変更
- CreateSecurityGroup:セキュリティグループを作成
- DeleteSecurityGroup:セキュリティグループを削除
1,セキュリティグループ作成
まずはセキュリティグループを作成します。
項目 | 設定値 |
---|---|
セキュリティグループ名 | saitou-test-change-notification-SG |
↓
作成しましたら、メールボックスを見てみましょう。
来てますね。
2,インバウンドルール作成
作成したセキュリティグループにインバウンドルールを作成します。
作成しましたら、メールボックスを見てみましょう。
3,アウトバウンドルール作成
アウトバウンドルールを作成します。
↓
4,セキュリティグループルール変更
作成したインバウンドルールのソースを変更します。
↓
メールボックスを見てみると、
変更に関してだけは、変更後内容をメールで記載しています。変更前も通知したかったのですが、APIコールの電文に変更前内容がないので無理でした。
5,インバウンドルール削除
作成したセキュリティグループのインバウンドルールを削除します。
↓
6,アウトバウンドルール削除
アウトバウンドルールを削除してみます。
↓
7,セキュリティグループ削除
さいごに、セキュリティグループを削除します。
↓
↓
確認は以上です。
まとめ:Amazon EventBridgeでセキュリティグループの変更を検知してみる
セキュリティグループはAWS環境にあるインスタンスにおいて、ファイアウォール的な役を担っています。
悪意のある外部・内部の人がセキュリティグループにルールを追加したら、即対応できるようにしておきたいですよね。
ルートテーブルの変更検知にも応用できますので、次回の記事で紹介します。
参考リンク:AWS公式ドキュメント、aws re:Post
↓ほかの協栄情報メンバーもAmazon EventBridgeに関する記事を公開しています。ぜひ参考にしてみてください。
■EventBridgeとLambdaを使用してRDS自動停止を作成する(watanabe)
https://cloud5.jp/autostop-rds/
■APIGateway + Lambda + DynamoDB を利用したサーバレス構築ハンズオン(INAMURA)
https://cloud5.jp/apigateway-lambda-dynamodb-serverless/
■『タグなしポイ捨てリソース、ダメ絶対!!』Config非準拠判定でSNSメール通知構築ハンズオン(INAMURA)
https://cloud5.jp/sns-notification-at-config/