type
status
date
slug
summary
tags
category
icon
password
理論
AWS Organizationsの理解
AWS Organizations は、複数のAWSアカウントを一元的に管理するためのサービスです。大規模な企業や組織では、複数のAWSアカウントを使用して異なるプロジェクトや部門を分けることが一般的ですが、AWS Organizationsを使うことで、これらのアカウントをグループ化し、中央からポリシーを適用したり、請求を一元管理したりできます。
- Organizational Units (OUs) を使って、アカウントを論理的にグループ化し、各OUごとに異なる管理や制限を設定できます。これにより、セキュリティ、リソース管理、アクセス制御を効率的に行うことが可能です。
Amazon EventBridgeの活用
Amazon EventBridge は、AWSリソース間でリアルタイムのイベントを送信するためのサービスです。例えば、あるAWSリソースで特定のアクションが実行されたときに、EventBridgeを使ってそのイベントをトリガーし、他のAWSサービスや外部のシステムに通知を送ることができます。
- EventBridgeでは、ルール を設定して、特定の条件に合ったイベントをフィルタリングし、それに基づいてアクションを起こすことができます。これにより、運用管理を自動化したり、イベント駆動型のアーキテクチャを構築することが可能です。
種類:
機能 | 説明 | 具体例 |
EventBridge ルール | 受信イベントをルールで照合し、処理のためにターゲットに送信します。 | EC2 インスタンスが起動したイベントを検知し、SNS トピックに通知を送信する。 |
EventBridge パイプ | オプションのフィルタリングとエンリッチメントを使用してイベントソースをターゲットに接続します。 | Amazon DynamoDB ストリームからデータを取得し、一部の項目をフィルタリング後、AWS Lambda に送信する。 |
EventBridge スケジュール | ターゲットを一度だけ、または cron 式や rate 式で定義した間隔で定期的に呼び出します。 | 毎日午前9時に Lambda 関数を呼び出し、定期的に S3 バケットのデータを処理する。 |
EventBridge スキーマレジストリ | スキーマを収集し整理して、イベントデータの構造を明確化します。 | カスタムアプリケーションのイベントをスキーマレジストリに登録し、開発者がスキーマを参照してコードを生成する。
|
イベントバス (Event Bus) は、Amazon EventBridge のコアコンポーネントの一つで、イベントを受け取り、ルールによってターゲットにルーティングする仕組みです。イベントバスは、複数のイベントソース(AWSサービス、カスタムアプリケーション、SaaSアプリケーション)からイベントを受け取り、指定されたルールに従って処理します。
特徴
- イベントの集約ポイント 複数のソースからのイベントを一か所で受信。
- ルールによるルーティング ルールを設定することで、イベントを特定のターゲットに送信可能。
- デフォルトバスとカスタムバス AWSアカウントにはデフォルトのイベントバスがあり、必要に応じてカスタムイベントバスを作成可能。
具体例
- デフォルトイベントバスの使用
- ソース: AWS CloudTrail からの API 呼び出しイベント
- ルール: 特定の IAM ユーザーが S3 バケットにアクセスした場合のイベントを検知。
- ターゲット: SNS トピックに通知を送信。
- カスタムイベントバスの使用
- ソース: 独自アプリケーションから送信されたカスタムイベント。
- ルール: イベント内のデータに基づいて、重要度が「高」の場合のみ処理。
- ターゲット: AWS Lambda 関数を起動してイベントを処理。
- SaaS イベントの処理
- ソース: Zendesk や Shopify などの SaaS アプリケーションのイベント。
- ルール: 注文がキャンセルされたイベントを検知。
- ターゲット: カスタマーサポート用の通知を送信。
イベントバスとルールの関係
イベントバスはイベントを集約する場で、ルールがフィルターとなり、イベントの送信先を決定します。例えば、デフォルトイベントバスに届くすべてのイベントをそのまま送信することも、特定の条件でフィルタリングして処理することも可能です。
Amazon SNS (Simple Notification Service) の活用
Amazon SNS は、通知を送信するためのフルマネージドなメッセージングサービスです。SNSを使用することで、システムからのアラートやイベント通知を、異なるサブスクライバー(例えば、セキュリティチームや管理者)に送信することができます。
- SNSは、メールやSMS、他のAWSサービス、HTTPエンドポイントに通知を送信することができ、通知の配信方法を柔軟に選択できます。特に、セキュリティやシステム監視において、リアルタイムの通知を送信するためにSNSを活用することがよくあります。
AWS Configによる設定監視とコンプライアンス管理
AWS Config は、AWSリソースの設定を監視し、その変更履歴を追跡するサービスです。これにより、リソースが意図したとおりに設定されているかを確認したり、設定が変更された場合に通知を受けたりすることができます。
- AWS Config管理ルール を使用すると、特定の設定ポリシーに対してリソースが準拠しているかを評価できます。例えば、セキュリティグループの設定が適切かどうかを監視し、不正な設定が行われた場合にアラートを発生させることができます。
vpc-sg-open-only-to-authorized-ports
は、AWS Config の管理されたルールで、VPC内のセキュリティグループが承認されたポートのみを開放しているかどうかを評価します。このルールは、セキュリティグループに不必要なポート(例えば、全てのIPアドレスに対してポート0.0.0.0/0
を開放する設定)が含まれていないかを確認し、セキュリティリスクを減らすための警告を発します。

- AWS Lambda関数と統合して、AWS Configの違反が検出された際に自動的に修正を実行する仕組みを導入することもできます。

Service Control Policies (SCP)によるアクセス制御
Service Control Policies (SCPs) は、AWS Organizations内でアカウントやOUに対するアクセス制御を行うための機能です。SCPは、アカウント内でどのAWSサービスにアクセスできるか、どのアクションを実行できるかを制御することができます。
- SCPを利用することで、特定の操作やアクションを制限することができます。たとえば、あるOUに対してセキュリティグループ設定を変更するアクションを制限することができ、セキュリティリスクを低減させることができます。
セキュリティグループとインバウンドルールの管理
セキュリティグループ は、AWS EC2インスタンスのネットワークアクセスを制御するための仮想ファイアウォールです。セキュリティグループは、インスタンスへのインバウンドおよびアウトバウンドトラフィックを許可または拒否するルールを設定できます。
- インバウンドルール の設定には、IPアドレス(例えば
0.0.0.0/0
)を指定することができますが、これを不適切に設定すると、インターネット全体からのアクセスを許可してしまい、セキュリティリスクが増大します。セキュリティグループの適切な管理が、AWS環境におけるセキュリティの要となります。
まとめ
これらのサービスや機能を組み合わせることで、AWS環境でのリソースの管理、セキュリティ、監視を効率的に行うことができます。特に、AWS Organizationsを使ったアカウント管理、Amazon EventBridgeとSNSを利用した通知システム、AWS Configによる設定監視、そしてSCPを利用したポリシー制御により、企業はセキュリティやコンプライアンスを強化し、運用負荷を減らすことができます。
実践
参照元:
AWS Configルールを使用してEC2インスタンスとS3バケットのタグを検証し、通知を送信する
概要:
このハンズオンでは、AWS Configルール「required-tags」を作成し、EC2インスタンスとS3バケットに「Name」と「Application」のタグが付与されているかを判定します。判定結果がNGの場合、Amazon EventBridgeを使って通知を検知し、Amazon SNSを通じてEメールで通知される仕組みを構築します。
1. 前提条件
以下のサービスを事前に設定しておく必要があります:
- AWSアカウントにサインイン
- IAMロールが必要な権限を持っていること
- SNSトピックを作成するための設定が整っていること
- EC2インスタンスとS3バケットが存在していること
2. AWS Configルールの作成
- AWS Configダッシュボードに移動:
- AWSマネジメントコンソールにログインし、
AWS Config
を検索して選択します。
- 新規ルールの作成:
- 「Rules」メニューに移動し、「Add rule」をクリックします。
- ルールテンプレートで「
required-tags
」を選択します。
- ルールの設定:
- リソースタイプで「EC2インスタンス」と「S3バケット」を選択します。
- 必要なタグとして「Name」と「Application」を指定します。
- ルールを有効にし、「Save」をクリックして設定を保存します。
これで、指定したタグが付与されていないEC2インスタンスとS3バケットが検出されるようになります。
3. Amazon EventBridgeの設定
- EventBridgeの作成:
- AWSマネジメントコンソールから
Amazon EventBridge
を検索し選択します。 - 「Create rule」をクリックし、新しいルールを作成します。
- ルールの設定:
- 「Event Pattern」で「AWS Config」を選択します。
- イベントパターンに「
ConfigRuleComplianceChange
」を設定します。
- ターゲット設定:
- 「Select targets」で「SNS topic」を選択します。
- 先ほど作成したSNSトピックを選択します。
- ルールの保存:
- ルールを有効にして、「Create」をクリックします。
4. Amazon SNSの作成と設定
- SNSトピックの作成:
- AWSマネジメントコンソールから
Amazon SNS
を検索して選択します。 - 「Create topic」をクリックし、「Standard」を選択します。
- トピック名を指定(例:
RequiredTagsNotification
)し、「Create topic」をクリックします。
- サブスクリプションの作成:
- SNSトピックの詳細ページに移動し、「Create subscription」をクリックします。
- プロトコルとして「Email」を選択し、通知を受け取るメールアドレスを入力します。
- 送信された確認メールを承認します。
5. テストと確認
- タグの不正なEC2インスタンスとS3バケットの作成:
- タグ「Name」と「Application」が設定されていないEC2インスタンスまたはS3バケットを作成します。
- AWS Configルールが非準拠を検出:
- AWS Configがリソースを評価し、タグが不足している場合は、非準拠として検出されます。
- EventBridgeの通知確認:
- EventBridgeがAWS Configからの非準拠イベントを受信し、設定したSNSトピックに通知を送信します。
- メール通知が届いたことを確認します。
6. まとめ
このハンズオンでは、AWS Configルール「required-tags」を使用して、EC2インスタンスとS3バケットに必要なタグが付与されているかを確認し、非準拠の場合にAmazon EventBridgeを通じてAmazon SNSに通知を送信する仕組みを構築しました。これにより、タグの管理が効率的に行えるようになります。
この手順で設定を進めることで、タグ管理が強化され、EC2インスタンスやS3バケットが適切なタグを持っていない場合に自動で通知が届く仕組みが完成します。
一問道場
問題文
ある会社が AWS Organizations の組織に属する 10 のアカウントを持っています。
AWS Config は各アカウントで設定されています。すべてのアカウントは、Prod OU または NonProd OU のいずれかに属しています。
この会社では、Amazon EC2 のセキュリティグループにおいて、インバウンドルールでソースとして
0.0.0.0/0
が指定された場合、Amazon Simple Notification Service (Amazon SNS) トピックに通知を送信する Amazon EventBridge ルールを各 AWS アカウントで設定しています。セキュリティチームは、この SNS トピックを購読しています。
NonProd OU に属するすべてのアカウントについて、セキュリティチームは、
0.0.0.0/0
をソースとするセキュリティグループのインバウンドルールを作成する機能を削除する必要があります。要件
次のうち、最小限の運用負荷でこの要件を満たすソリューションはどれですか?
選択肢
A.
EventBridge ルールを修正して、AWS Lambda 関数を呼び出し、セキュリティグループのインバウンドルールを削除し、SNS トピックに通知を送信するように設定します。この更新されたルールを NonProd OU にデプロイします。
B.
vpc-sg-open-only-to-authorized-ports
AWS Config のマネージドルールを NonProd OU に追加します。C.
Service Control Policy (SCP) を設定して、
aws:SourceIp
条件キーの値が 0.0.0.0/0
ではない場合に ec2:AuthorizeSecurityGroupIngress
アクションを許可するようにします。この SCP を NonProd OU に適用します。D.
SCP を設定して、
aws:SourceIp
条件キーの値が 0.0.0.0/0
の場合に ec2:AuthorizeSecurityGroupIngress
アクションを拒否するようにします。この SCP を NonProd OU に適用します。解説
A. EventBridge + Lambda:
セキュリティグループのルールをリアルタイムで削除する仕組みを作成するが、Lambda のデプロイや管理が必要で運用負荷が高い。
B. AWS Config のマネージドルール:
AWS Config のルールはルール違反を検出するのみで、制限を強制する機能はないため要件を満たさない。
C. SCP (許可ベース):
特定条件での許可を設定するが、条件を反転するため設定が複雑になり、ミスが起きやすい。
D. SCP (拒否ベース):
aws:SourceIp
が 0.0.0.0/0
の場合のアクションを拒否するポリシーを設定。明確でシンプル、運用負荷が最も低い。正解: D
SCP を使った拒否ベースのアプローチが要件を最も効率的に満たします。
- 作者:みなみ
- 链接:https://tangly1024.com/資格勉強/167d7ae8-88e2-8016-a2f5-d12cdd95c2e2
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。
相关文章