fu3ak1&#39;s tech days

2021-01-14

AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法～7. Security Hub～

Organizationsシリーズ第七弾、SecurityHub編です。

AWS Security Hubとは

AWS Security Hub（以下、Security Hub）は、AWSアカウント内のセキュリティ状況やコンプライアンスの準拠状況を一箇所で確認できるサービスです。以下2種類の検出が可能です。

CIS AWS Foundations BenchmarkやPCI DSSといった基準に従ったコンプライアンスチェック
GuardDuty、Macie、Inspector、Firewall Manager、IAM Access Analyzerといった各種AWSのセキュリティサービスや3rd Partyのセキュリティサービスの検出、アラートの一元管理

過去に紹介したGuardDutyやIAM Access Analyzerの情報もこのSecurity Hubに集約して確認できます。

Organizationsを使用したマルチアカウント設定

Security Hubはアカウントの委任に対応しているため、マネジメント（親）アカウントではなくauditアカウントに集約する方針で設定していきます。

手順は以下のとおりです。

メンバーアカウントへ委任
Security Hubの有効
検出結果の確認

設定手順

実際にやっていきます。なお、前提としてSecurity Hubは全アカウントで無効状態から開始します。

1. メンバーアカウントへ委任

マネジメント（親）アカウントにログインし、Security Hubの画面へ遷移します。

初回は以下のように表示されるので、Security Hubに移動をクリックします。

f:id:fu3ak1:20210114221228p:plain

Security Hubの有効化画面が表示されますが、ここではまだ有効にせず、一番下に行きアカウントの委任を実行します。

f:id:fu3ak1:20210114221540p:plain

委任完了です。委任だけではSecurity Hubは有効になりません。

f:id:fu3ak1:20210114221652p:plain

2. Security Hubの有効

まずは、管理者として委任したauditアカウントにログインして有効にします。

f:id:fu3ak1:20210114221855p:plain

有効化後、設定ページを開くと以下のようにOrganization組織内のManagementアカウントとsystem01アカウントが表示されます。一括でSecurity Hubを有効化できそうなボタンが表示されたのでこれを押下してみます。

f:id:fu3ak1:20210114222429p:plain

以下のようなメッセージが表示されます。警告用途かと思いますが、組織内に一律自動有効したい場合にはありがたい内容ですね。

f:id:fu3ak1:20210114222558p:plain

有効化すると以下のとおり、system01のみ有効になりました。組織のManagementアカウントは自動有効とならないようです。

委任前にManagementアカウントで組織単位で有効化すれば一気に全有効化できたかもしれません。（少し後悔）

f:id:fu3ak1:20210114223218p:plain

Managementアカウントの有効は、Managementアカウント自身で行う必要があるようなので、ログインして有効化します。

f:id:fu3ak1:20210114224149p:plain

Managementアカウントで有効になったら、再びauditアカウントにログインして戻ってきて、Memberに追加します。

f:id:fu3ak1:20210114224503p:plain

無事Memberになりました。

f:id:fu3ak1:20210114224712p:plain

3. 検出結果の確認

1ヵ所で集約できるはずなので、結果を見てみます。

GuardDutyを見てみます。Managemenetアカウントで、GuardDutyのサンプルイベントを発行しました。 auditアカウントで以下のように表示されています。

f:id:fu3ak1:20210114232210p:plain

無事、別アカウントの結果が見れました。と思ったのですが、少し疑問が残ります。 GuardDuty側ですでに情報の集約をしているので、GuardDuty側でauditに集約された情報があがってきている可能性もあります。

とゆうことで、コンプライアンスチェックについても別アカウントの情報が見れるか確認してみます。

※コンプライアンスチェックは有効後、時間がかかるので1時間ほど待ちました。

以下のように、auditアカウントのSecurity Hubで、system01のコンプライアンスチェックが見えています。1アカウントに集約できていますね。

アカウントIDで情報をフィルタできるのでそれを使用しました。

f:id:fu3ak1:20210114233047p:plain

設定検証は以上です。

さいごに

今回はSecurity Hubの通知設定までは行いませんでしたが、EventBridgeを使用することで通知を行うことができます。すべての結果を通知してしまうとかなりの数になるので、あらかじめフィルタする情報は検討して通知を検討したほうが良いでしょう。

集まる情報量も多いので、まずは定期的にセキュリティ情報を確認する場所としてSecurity Hubを使用するのもありだと思います。

次回はAmazon Detectiveの予定です。

2021-01-14

AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法～6. IAM Access Analyzer～

Organizationsシリーズ第六弾、IAM Access Analyzer編です。

IAM Access Analyzerとは

IAMの画面からアナライザーを作成することで、AWSアカウント外と共有しているIAMロールやS3バケットを一覧で確認することができます。無料です。

マルチアカウント運用となると、他のアカウントにIAMやS3を公開して利用することも多くなってきます。誤って意図しないアカウントやパブリックに公開することはセキュリティリスクとなりますので、最低限の公開（共有）を行い、定期的に見直しをしていくことが重要です。

IAM Access Analyzerを使用することで、公開状態の確認をかんたんに実施できます。

Organizationsを使用したマルチアカウント設定

IAM Access Analyzerはアカウントの委任に対応しているため、マネジメント（親）アカウントではなくauditアカウントに集約する方針で設定していきます。

1点注意なのは、組織単位でIAM Access Analyzerを設定した場合、検知されるリソースは組織外に共有されたリソースのみとなります。

今回はManagement、audit、system01という3アカウントになりますが、この3アカウント同士で許可したリソースは表示されません。

これらの内容も表示したい場合は、アカウント単体でもアナライザーを作成する必要があります。

手順は以下のとおりです。

メンバーアカウントへ委任（代表管理者を追加）
アナライザー作成
アカウント単体のアナライザー作成

設定手順

実際にやっていきます。なお、前提としてAccess Analyzerは全アカウントで無効状態（アナライザー未作成）から開始します。

1. メンバーアカウントへ委任（代表管理者を追加）

マネジメント（親）アカウントへログインし、IAM画面へ遷移します。

Access Analyzerをクリックすると、「代表管理者を追加」ボタンがあるのでそれをクリックします。

f:id:fu3ak1:20210113190559p:plain

追加を押します。

f:id:fu3ak1:20210113190824p:plain

委任するアカウントのIDを入力します。今回の例ではauditアカウントのIDです。

f:id:fu3ak1:20210113191223p:plain

以下のように委任の設定が完了します。

f:id:fu3ak1:20210113191628p:plain

委任完了時点では、各アカウントのアナライザーは自動作成されていませんでした。ここは個別に作成する必要があるようです。

2. アナライザー作成

アナライザーはauditアカウントに集約するため、auditアカウントにログインしてIAM Access Analyzerの画面へ遷移し、アナライザーの作成をクリックします。

f:id:fu3ak1:20210113223857p:plain

作成時に、組織全体か、アカウント単体で作成するか選択できるので組織を選択します。

f:id:fu3ak1:20210113224146p:plain

作成にはしばらく時間がかかるので待機します・・

作成が完了すると、以下のようにリソースの状況が表示されます。

今回は、意図的にアナライザーで検知させるために、全アカウントにアクセス許可を与えたS3バケットをsystem01アカウントに作成しておきました。最初の2行がそのバケットになります。（なぜか同じリソースが2行表示されました、仕様？）

IAM Role2つは、AWS SSOの設定時に自動作成されたIAMロールです。

f:id:fu3ak1:20210114003809p:plain

確認しているアカウントはauditなので以下のように複数のアカウントの状況を表示できていることになります。

f:id:fu3ak1:20210114003954p:plain

3.アカウント単体のアナライザー作成

auditアカウント単体でもアナライザーを作成してみます。手順はさきほどと同様で、作成時に「現在のアカウント」を選べばOKです。

f:id:fu3ak1:20210114002543p:plain

作成すると以下のように表示されます。1行目は組織のアナライザーに表示されていたものと同じです。

2つ目は、Organizationsの組織作成時に自動生成された、ManagementアカウントからスイッチできるIAMロールです。

3つ目は、CloudTrailを組織単位で設定したときに作成したS3バケットです。

組織のアナライザーでは、許可しているアカウントがOrganizationsの組織内であったため、表示されませんでした。組織内のアカウント間許可を表示したいかは、利用状況により異なるかもしれませんが、アナライザーは無料なので、一律全アカウントで有効にしておいて良いと思います。（作業の自動化は検討）

f:id:fu3ak1:20210114002749p:plain

設定作業はここまでです。

なお、IAM Access Analyzerはリージョンサービスです。IAMの情報は表示されますが、S3バケットなど別リージョンでも作成されるリソースを検知する場合は、すべてのリージョンで有効にする必要があります。

さいごに

マルチアカウント運用となると重要度が増してくるIAM Access Analyzerについて紹介しました。共有されたリソースを、どう運用の中で定期的に確認していくかが重要になりますね。

確認したリソースは確認済みとしてアーカイブする機能もあるので、定期的に確認を行い全てアーカイブされるようにするのが理想な運用かと思います。

次回はAWS Security Hubの予定です。

2021-01-08

AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法～5. GuardDuty～

Organizationsシリーズ第五弾、Amazon GuardDuty編です。

GuardDutyとは

マネージド型の脅威検出サービスです。AWSアカウント内で発生している脅威を検出してくれます。たとえば以下のような事象を検知してくれます。

ルートユーザの使用
IAMユーザーの不正利用(大量の操作実行など)
EC2の不正通信

検知する仕組みはAWS側で管理されるので、利用者はそれをどう検知、管理していくか運用面を検討して利用すればOKです。デフォルトで有効にしたいサービスの１つですね。

Organizationsを使用したマルチアカウント設定

GuardDutyもAWS Configと同じく、アカウントの委任に対応しています。よって以下のようにauditアカウントに情報を集約できます。

f:id:fu3ak1:20210107224929p:plain

手順の流れは以下のとおりです。

メンバーアカウントへ委任
メンバーアカウントのGuardDuty有効化、新規アカウントの自動有効化
(Option) 検知の設定

設定手順

実際にやっていきます。

1.メンバーアカウントへ委任

マネジメント（親）アカウントへログインし、GuardDuty画面へ遷移します。

まだマネジメント（親）アカウントでGuardDutyが有効でない場合は有効化しておきます。

f:id:fu3ak1:20210107225835p:plain

有効にした後、設定＞委任された管理者欄に委任先のアカウントIDを入力し、委任ボタンを押します。

f:id:fu3ak1:20210107230152p:plain

委任が完了すると以下のような画面表示になります。

f:id:fu3ak1:20210107230315p:plain

2.メンバーアカウントのGuardDuty有効化、新規アカウントの自動有効化

委任後、委任したアカウントauditにログインしてGuardDuty画面へ遷移します。すると、audit以外のアカウントが表示されます。

組織単位でGuardDutyを有効にできるボタンが表示されるので、有効化を押します。

※なお、auditアカウントはGuardDuty無効状態でしたが、委任をした時点で自動的に有効化されました。

f:id:fu3ak1:20210107230914p:plain

確認が以下のように出るので有効化します。有効にすることで今後新規で追加されるAWSアカウントもGuardDutyが有効になります。

f:id:fu3ak1:20210107231019p:plain

しばらくすると以下のように各アカウントのステータスが有効になります。

f:id:fu3ak1:20210107231337p:plain

GuardDutyにはS3へのデータアクセスに対する脅威も検出できる（最近できるようになった）のですが、この有効化は別管理となっています。これの自動有効化も同画面からできそうなのでやってみます。

f:id:fu3ak1:20210107231633p:plain

チェックを入れて更新。

f:id:fu3ak1:20210107231742p:plain

と、これで既存のアカウントも有効になると思ったのですが、そうではないようです。新規アカウントの自動有効設定でした。

既存アカウントはS3保護の設定から有効化します。

f:id:fu3ak1:20210107232003p:plain

できました。

f:id:fu3ak1:20210107232052p:plain

アカウント側にも反映されています。

f:id:fu3ak1:20210107232312p:plain

GuardDuty有効の設定はここまでです。

なお、ここまでの設定では東京リージョンのみ有効となっています。脅威はどのリージョンでも発生する可能性があるため、可能であれば全リージョンでの有効も検討したほうが良いでしょう。具体的なやり方は自動化の検討をする機会があれば書いてみたいと思います。（全サービス書き終えて余裕があれば書いてみる予定です）

3. 検知の設定

有効化しただけではGuardDutyの本来の脅威検出の機能が見れないので、サンプルイベントの検知を行ってみます。

通知の設定はEventBridgeから行います。

f:id:fu3ak1:20210107233354p:plain

イベントパターンで以下のようにGuardDuty Findingを設定します。これによりGuardDutyのすべての検知がイベントとしてトリガーされます。

f:id:fu3ak1:20210107233509p:plain

ターゲットに通知用のSNSを指定して、ルールを作成します。今回はあらかじめChatbotを設定しておいたSNSを指定します。（Chatbotの設定方法は本記事では割愛）

メールを設定したSNSでもOKです。

f:id:fu3ak1:20210107233615p:plain

ルールができました。

f:id:fu3ak1:20210107233756p:plain

サンプルイベントを発行してみます。全アカウントのGuardDuty検知がauditアカウントに集約されて検知されるはずなので、今回は別アカウントのsystem01でサンプルイベントを発行してみます。

system01アカウントにログインし、GuardDuty画面からサンプルイベントを発行します。

f:id:fu3ak1:20210107234038p:plain

しばらくすると以下のように通知が飛んできます。Accountのところに対象のアカウント、今回でいうとsystem01のアカウントIDが表示されます。

f:id:fu3ak1:20210107235016p:plain

つまり、以下のように、集約されたauditアカウント経由で通知されたことになります。

アカウントが増えても自動的に有効になるので組織単位の通知運用が可能になりますね。

f:id:fu3ak1:20210108000746p:plain

すべてのFindingを通知すると量も多くなりますのでフィルタの検討も必要にはなるかと思います。

以上、検知も含めた設定の検証はここまでです。

さいごに

AWS Config、CloudTrailに比べてすんなり設定できた印象です。マルチアカウントの要望が強いサービスなのかもしれませんね。

GuardDutyは有効にするだけで、AWSが裏側で色々動いて色々な脅威を検知してくれるので、私もとても好きなサービスです。この機能を使ってうちの組織はデフォルトでONだから！といった管理運用も良いですね。

次回はIAM Access Analyzerの予定です。

2021-01-05

AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法～4. AWS Config～

Organizationsシリーズ第四弾、AWS Config編です。

AWS Configとは

AWSリソースの設定変更履歴を保存できるサービスです。たとえばあるセキュリティグループに対して、誰がどのような変更を行ったのか履歴で確認できます。

また、Configルールと修復アクションを使用することで、リソースが指定された状態になっているかチェックを行い、自動的に修復することも可能です。たとえば、セキュリティグループで0.0.0.0/0が設定されてインターネットに公開された場合に検知して自動削除するといった運用も可能になります。

Organizationsを使用したマルチアカウント設定

前提として、Config記録が全アカウント、全リージョンで有効になっている必要があります。以下の手順で実施していきます。

Organizationsの「信頼されたアクセス」有効化
メンバーアカウントへ委任
アグリゲータの作成
(Option) Configルールの組織適用

Configはアカウントの委任をサポートしているため、集約するアカウントをマネジメントアカウント以外のアカウントに設定できます。

f:id:fu3ak1:20210105103315p:plain

設定手順

1. 「信頼されたアクセス」有効化

Organizationsの設定のため、マネジメントアカウントで実行します。 Configルールで必要なconfig-multiaccountsetup.amazonaws.comの設定が現状CLIのみ実行可能なようなので、CLIで実行します。今回は手軽にCLIが実行できるCloudShell上で実行しました。

有効化コマンド：

$ aws organizations enable-aws-service-access --service-principal config.amazonaws.com
$ aws organizations enable-aws-service-access --service-principal config-multiaccountsetup.amazonaws.com

確認コマンド：

$ aws organizations list-aws-service-access-for-organization --output text | grep config
ENABLEDSERVICEPRINCIPALS        2020-12-22T04:00:11.418000+00:00        config-multiaccountsetup.amazonaws.com
ENABLEDSERVICEPRINCIPALS        2020-12-22T02:27:53.842000+00:00        config.amazonaws.com

2. メンバーアカウントへ委任

こちらも同じくCLIで実行します。

※コマンド上の[委任アカウントID]は実際の環境に合わせて修正が必要です。

委任コマンド：

$  aws organizations register-delegated-administrator --account-id [委任アカウントID] --service-principal config.amazonaws.com
$  aws organizations register-delegated-administrator --account-id [委任アカウントID] --service-principal config-multiaccountsetup.amazonaws.com

確認コマンド：

$ aws organizations list-delegated-services-for-account --account-id [委任アカウントID] --output text | grep config
DELEGATEDSERVICES       2020-12-22T04:31:39.050000+00:00        config-multiaccountsetup.amazonaws.com
DELEGATEDSERVICES       2020-12-22T04:31:31.375000+00:00        config.amazonaws.com

3. アグリゲータの作成

委任が完了したので、委任した監査アカウント上でアグリゲータを作成します。Configの画面上から作成できるため、GUIで実行します。

アグリゲータとは、複数アカウントのConfigの情報を集約して確認、設定できる機能です。

f:id:fu3ak1:20201222141256p:plain

データレプリケーションを許可して、任意のアグリゲータ名を入力します。

f:id:fu3ak1:20201222141807p:plain

組織を追加するを選択して、IAMロールを選択します。IAMロールはあらかじめ用意されているものを選びました。

f:id:fu3ak1:20201222142103p:plain

すべてのリージョンを選択して保存します。

f:id:fu3ak1:20201222142325p:plain

しばらく時間を置いて、アグリゲータの画面を見てみると、組織内の全アカウントのリソースが表示されます。リソース名をクリックすると、各リソースの詳細も確認できます。

f:id:fu3ak1:20201222143917p:plain

4. Configルールの組織適用

Configルールの組織単位の適用は、Configの画面上から設定できそうな項目は出てきませんでした。CLIで実行できそうなので、委任アカウントのCloudShellを使用してルールを作成してみます。

今回はAWSが管理しているルールであるguardduty-enabled-centralized (GuardDutyが有効になっているか）を使用します。Description内容はConfigマネージドルールで記載されている内容そのままです。

実行コマンド：

aws configservice put-organization-config-rule \
--organization-config-rule-name org-guardduty-enabled-centralized \
--organization-managed-rule-metadata \
Description="AWS アカウントおよびリージョンで、Amazon GuardDuty が有効になっているかどうかを確認します。一元管理用の AWS アカウントを指定した場合、ルールはそのアカウントでの GuardDuty の結果を評価します。GuardDuty が有効であれば、ルールは準拠しています。",\
RuleIdentifier="GUARDDUTY_ENABLED_CENTRALIZED"

実行結果：

{
    "OrganizationConfigRuleArn": "arn:aws:config:ap-northeast-1:[委任アカウントID]:organization-config-rule/org-guardduty-enabled-centralized-tvymtmkq"
}

しばらくしてConfigの集約ビューからルールを確認すると、以下のとおり組織内の3アカウントのルール準拠状況が確認できます。2アカウントでGuardDutyが有効になっていないです。良くないですね。

f:id:fu3ak1:20201222173049p:plain

なお、ルール単体ではなくルールの集合である適合パックを適用する場合は、以下のコマンドで実行できます。

今回の例ではAWS側のサンプルにある「Operational Best Practices for Amazon S3」を適用しています。コードはgithub上に上がっているのでそれをダウンロードしておきます。以下のコマンドではcurlコマンドでテンプレートをダウンロードしています。

実行コマンド：

# テンプレートダウンロード
$ curl -LO https://raw.githubusercontent.com/awslabs/aws-config-rules/master/aws-config-conformance-packs/Operational-Best-Practices-for-Amazon-S3.yaml

# 適合パック適用
aws configservice put-organization-conformance-pack \
 --organization-conformance-pack-name org-s3-bestpractice \
 --template-body "file://Operational-Best-Practices-for-Amazon-S3.yaml"

実行結果：

{
    "OrganizationConformancePackArn": "arn:aws:config:ap-northeast-1:[委任アカウントID]:organization-conformance-pack/org-s3-bestpractice-52tw7yqa"
}

適用された適合パックは以下のように見えます。適合パックに含まれる複数のルールが表示されています。

f:id:fu3ak1:20201222174940p:plain

設定手順はここまでです。

さいごに

個人的には、ConfigはCloudTrailと同じくらいセキュリティ的に重要なサービスです。今回の記事ではOrganizationsを使用して組織内のすべてのアカウントに対して情報集約、ルール設定する方法を紹介しました。

Configルールを合わせて活用することで、組織全体の予防的統制、発見的統制に役立つことができると思います。AWSからも様々なルールが公開されていますので、まずは自分の組織に適用できるルールがないか確認し使用していくところから始めると良いと思います。

次回はGuardDutyの予定です。

2021-01-04

AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法～3. CloudTrail～

あけましておめでとうございます。2021年1つ目のブログは、Organizationsシリーズ第三弾です。今回はCloudTrailです。

CloudTrailとは

AWS上の操作履歴を保存し、可視化できるサービスです。デフォルト状態で、特に何もしなくても過去90日分は操作履歴を確認できます。追加で証跡という設定を行うことで、すべての操作履歴をS3バケットに保存して確認できるようになります。

シングルアカウントの場合、当たり前ですが有効にすると自アカウントの操作証跡が指定したS3バケットに保存されます。

f:id:fu3ak1:20201231003011p:plain

Organizationsを使用した証跡の有効

Organizationsを使用すると、組織内のすべてのアカウントに対してCloudTrailの証跡を有効にして、指定したS3バケットにすべてのアカウントの証跡が保存されます。

f:id:fu3ak1:20201231003426p:plain

なお、現時点でCloudTrailはアカウントの委任機能に対応していないため、組織単位の証跡有効および保存先の設定はマネジメントアカウントで実行する必要があります。

設定方法

実際の設定方法は簡単です。CloudTrailの証跡を有効化する際に、「組織内のすべてのアカウントについて有効化」にチェックを入れればOKです。その他の設定項目はシングルアカウントの設定時と同様のため詳細手順は割愛します。基本は画面のとおり進めていけばOKです。

f:id:fu3ak1:20201231003925p:plain

作成が完了すると、以下のように組織の証跡が「はい」の状態で表示されます。

f:id:fu3ak1:20201231004213p:plain

連結（メンバー）アカウントからの見え方

Organization配下の連結アカウントからCloudTrailの証跡を見ると、マネジメントアカウントと同じように証跡が設定されています。

ただし、証跡の削除や設定変更ができない旨も合わせて表示されます。強制的にマネジメントアカウントによって証跡が残るのは良いですね。

f:id:fu3ak1:20201231005631p:plain

S3バケット内の証跡ファイルを確認しようとすると、以下のようにエラーとなります。これはバケットポリシーでマネジメントアカウント外のアカウントから許可がされていないためです。

f:id:fu3ak1:20201231005953p:plain

連結アカウントから自アカウントの証跡を確認するためには、別途追加の設定が必要になります。方法はいくつかあるため後ほど考察してみます。

ひとまず、全アカウントでの証跡強制有効、マネジメントアカウントでの一元管理ができました。

監査アカウント上のバケットに保存

マネジメントアカウント上のS3バケットではなく、ログやセキュリティ情報を格納する監査（audit）アカウントのS3バケットにCloudTrailの証跡を集約してみます。

まず、監査アカウントにログインしてS3バケットを作成します。名前以外はデフォルトで設定しておきます。

今回はバケット名に「202012cloudtrail-audit-organization」という名前を設定しています。

f:id:fu3ak1:20210103230603p:plain

アクセス許可のタブに移動し、

f:id:fu3ak1:20210103230943p:plain

バケットポリシーを編集します。

f:id:fu3ak1:20210103231035p:plain

ポリシーは以下のとおり設定します。マネジメントアカウントで証跡有効をした際に自動設定されたバケットポリシーを参考にしています。

※[ManagementAccountID]と[OrganizationID]は置き換えが必要です。OrganizationIDは、Organizations>アカウントの整理画面で右側のARN情報に見える、「o-」で始まる文字列です。

※バケット名は今回「202012cloudtrail-audit-organization」としているのでそのまま記載していますが、ここも実環境に応じて変更が必要です。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AWSCloudTrailAclCheck20150319",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:GetBucketAcl",
            "Resource": "arn:aws:s3:::202012cloudtrail-audit-organization"
        },
        {
            "Sid": "AWSCloudTrailWrite20150319",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::202012cloudtrail-audit-organization/AWSLogs/[ManagementAccountID]/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        },
        {
            "Sid": "AWSCloudTrailWrite20150319",
            "Effect": "Allow",
            "Principal": {
                "Service": "cloudtrail.amazonaws.com"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::202012cloudtrail-audit-organization/AWSLogs/[OrganizationID]/*",
            "Condition": {
                "StringEquals": {
                    "s3:x-amz-acl": "bucket-owner-full-control"
                }
            }
        }
    ]
}

バケットポリシーの設定が完了したら、マネジメントアカウントに戻ります。

※アカウントを行ったり来たりするので間違えないように注意です。

先ほどの手順と同じく、組織のCloudTrail証跡を作成します。

このとき、バケット名に先ほど監査アカウントで作成したバケット名「202012cloudtrail-audit-organization」を既存のバケットとして指定します。

f:id:fu3ak1:20210103233534p:plain

作成が完了すると以下のようにauditと名前のついた証跡が作成されていることが確認できます。比較用に先ほどマネジメントアカウント上で作成した証跡も残しています。

f:id:fu3ak1:20210103233937p:plain

以下のように、監査アカウントにCloudTrail証跡を集約することができました。バケット内のオブジェクトは、監査アカウント内からしか見えません。マネジメントアカウントからも見えなくなります。

f:id:fu3ak1:20210103233834p:plain

CloudTrailはサービスとしてアカウントの委任機能に未対応ですが、このようにバケットを意図的に他アカウントに指定することで委任のような設定を行うことができます。

他アカウントでの証跡の確認方法

1アカウントに証跡を集約できましたが、集約されたアカウント以外はS3バケット内の証跡を確認できませんでした。これを確認できるようにするにはどうすれば良いでしょうか。いくつか考えてみます。

1. 証跡確認用IAMロールを作成する

これはAWSの公式ドキュメントにも記載のある方法です。図もそこから引用させてもらいます。

f:id:fu3ak1:20210103235052p:plain

集約されたアカウントにIAMロールを作成し、そのロールに別アカウントからスイッチしてくるという運用ですね。

アカウントが増えるたびに、専用のロールも合わせて作成する必要があります。

2. バケットポリシーを変更する

集約されたS3バケットのバケットポリシーで他アカウントからのs3:GetObjectとs3:ListBucketを許可すれば参照が可能です。アカウントIDで許可する必要があるため、こちらもアカウントが増えるたびにバケットポリシーの変更が必要になります。

f:id:fu3ak1:20210103235544p:plain

もしくは、組織内全体でログが確認できてOK（自分のアカウント以外のログが見えてもOK）であれば、OrganizationのIDを指定してアクセス許可することも可能です。

運用ポリシーとして全てのログが見えてOKであれば、おススメの設定です。具体的には以下のようにバケットポリシーに追加すればOKです。

※Statementの1ブロックを抜粋しています

※[OrganizationID]にはご自身のOrganizationID（o-で始まる文字列）の入力が必要です。バケット名も環境に合わせて修正してください

        {
            "Sid": "FromOrganization",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket"
            ],
            "Resource": [
                "arn:aws:s3:::202012cloudtrail-audit-organization",
                "arn:aws:s3:::202012cloudtrail-audit-organization/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalOrgID": "[OrganizationID]"
                }
            }
        },

設定が完了すると組織内のすべてのアカウントから以下のようにS3内のオブジェクトが確認できます。

f:id:fu3ak1:20210104002038p:plain

3. 各アカウントごとに証跡を作成する

CloudTrailの証跡は複数作成できるので、組織設定で全体として取得しつつ、各アカウントごとに単独で設定することも可能です。こうすることで、各アカウント内で自分のアカウントのみ証跡を確認できるといった運用も可能です。

f:id:fu3ak1:20210104002501p:plain

証跡が重複して作成されますので、S3の料金が多くなる点には注意が必要です。個人的には、S3の料金は高くないので大きく気にするほどでもないかと思います。

アカウント単位の設定が必要にもなりますが、これはCloudFormationのStaclSetsを活用することでアカウント作成時に自動化することも可能です。アカウント単独で証跡の運用が必要な場合は、おススメな構成です。

他アカウントからの参照方法は以上３パターンです。どれにするかは私としても悩みどころですが、マッチするパターンがあれば幸いです。

さいごに

セキュリティおよび監査要件ではとても重要であるCloudTrail。証跡機能は基本的に有効化するものとして、それをどう運用していくか検討が必要ですね。特にマルチアカウントになった場合は一元管理の方法も要検討です。

今回はS3に集約するところまで確認しましたが、実際の運用ではAmazon Athenaなどを使用して、可視化を行って運用していく必要があります。

今回はここまで。次回はConfigの予定です。

2020-12-29

AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法～2. コスト管理～

Organizationsシリーズ第二弾です。今回はコスト（利用料）管理についてです。