AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～まとめ～
ひととおり、各サービスについてOrganizationsを使用した集約設定方法をまとめました。本記事でまとめていきます。
Organizationsの復習
Organizationsは元々、複数アカウントの利用料請求を一括にまとめる機能でしたが、現在では各サービスの情報を組織内で一括管理できる機能があります。
デフォルトではManagement（親）アカウントに情報が集約されます。（以下CloudTrailの例）
アカウントの委任という機能に対応しているサービスもあり、これを利用することで集約するアカウントをOrganizations配下のメンバーアカウントに変更できます。（以下Configの例）
また、いくつかのサービスは、組織へアカウントが追加されたときに、そのアカウントでサービスを自動有効化する機能もありました。（以下GuardDutyの例）
各サービスの対応状況
- Organizations集約に対応
- メンバーへの委任
- アカウント追加時の自動有効
の３点について、各サービスがどう対応しているか表にまとめました。各サービス名をクリックすると設定方法の記事へ遷移します。
| サービス名 | 1.Organizations対応 | 2.メンバー委任 | 3.メンバー自動有効 | 補足 |
|---|---|---|---|---|
| ルートユーザーの保護 | × | × | × | 各アカウントで個別に実施する必要あり |
| AWS SSO(IAM) | 〇 | × | - | 権限セットとしてグループごとにIAMポリシー管理 |
| Cost Explorer | 〇 | × | 〇 | |
| AWS Budgets | 〇 | × | - | メンバーアカウント単独で予算設定は可能 |
| CloudTrail | 〇 | △ | 〇 | 証跡S3バケットをメンバーアカウントに設定することは可能 メンバーアカウントから閲覧は追加設定が必要 |
| AWS Config | 〇 | 〇 | × | メンバーアカウントはあらかじめ有効が必要 |
| GuardDuty | 〇 | 〇 | 〇 | |
| IAM Access Analyzer | 〇 | 〇 | × | 組織とメンバーのアナライザーは別扱い |
| AWS Security Hub | 〇 | 〇 | 〇 | |
| Detective | × | × | × | Organizations未対応、個別にアカウントを招待 |
| Personal Health Dashboard | 〇 | × | - | PHD単体は自動有効 |
| Trusted Advisor | 〇 | × | - | TrustedAdvisor単体は自動有効 |
※アカウント単体で一律有効にするサービスではないAWS SSO、AWS Budgetsの③は「-（対象外）」としています。
※PHDとTrustedAdvisorはアカウント単体で自動有効なので同じく「-（対象外）」としました。
一括設定の方針
もし新規のOrganizationsでこれらの設定を一気にやるにはどうやったら良いのか考えてみます。
流れとしては以下のとおりです。私の1案となります。
-
これを行うことで、Organizationsの組織が作成され、各サービスでOrganizationsと連携ができるようになります。 AWS CLIでも実行できますが、特に初めての方はマネジメントコンソールがわかりやすいです。
CloudFormationテンプレートの作成、CloudFormation StackSetsのデプロイ
AWS Config、IAM Access Analyzerはメンバーアカウントでサービスを手動で有効にする必要があります。
アカウントの追加時に自動で有効になってほしいこの2つは、有効にするCloudFormationテンプレートを作成しておきます。
それをCloudFormation Stack Setsとして登録しておくことで、アカウント追加時に自動有効化することができます。
※佐々木さんのブログより拝借しました。StackSetsの詳細はこのブログで書かれています。
各サービスのOrganizations機能有効化
これまでの記事で紹介してきた手順のとおり、各AWSサービスでOrganizationsを使用した集約設定をやっていきます。記事のとおりマネジメントコンソールでやるのもわかりやすいし、面倒な方はCLIでも良いと思います。ルートユーザの保護（MFA設定）は手動で行う必要があります。
一度設定すると変更する機会も少ないので、CloudFormationまで作るのは微妙かもしれませんが、複数のOrganizationsでやるには良いかもしれません。CloudFormationが各Organizationsの機能に対応しているかは確認する必要があります。
初期の設定はここまでやっておけば大丈夫かと思います。そのほか環境に応じて必要なサービスがあれば合わせて有効にすると良いでしょう。
新規アカウント追加時の対応
自動有効でもなく、CloudFormation StackSetsでも有効にできない以下のサービスおよび設定はアカウント追加時に手動で作業を行う必要があります。
- ルートユーザーの保護
- AWS SSO(IAM) ⇒必要に応じて権限セットも追加
- AWS Budgets ⇒予算額を設定して設定。組織のみで管理であれば不要
- Detective ⇒1アカウントに集約する場合は招待、承認の作業が必要
SSO、Budgetsは本来アカウント単位で権限や予算を設定すべきものなので、手動なのは仕方ないかなと思います。
ルートユーザーの保護は、悩ましいです・・。作成時は利用者がわからない自動生成されたパスワードが設定されますが、 きちんと手動でMFA設定が良いと私は考えています。
Detectiveは、そのうちOrganizations対応すると思いますｗ
今後期待する新機能
一つ前に書いたルートユーザーの自動保護と、DetectiveのOrganizations対応に期待しています。
また、請求情報をまとめたり、ボリュームディスカウントを効かせるために、プロジェクトA、プロジェクトBといった複数プロジェクトを1つのOrganizations組織に入れることも多いのですが、この場合AWS SSOやセキュリティサービスはプロジェクト単位で実施したくなります。
※ボリュームディスカウントやSavingsPlansの割引は、組織全体で効かせることができます。
紹介したサービスはOrganizationsの1組織全体で行う前提なので、今後、たとえばOU単位でサービスの設定ができたり、複数のOrganizations組織の請求部分だけ1つにまとめるといった機能に期待しています。
さいごに
Organizationsを活用したサービスシリーズ、10サービスについて書きました。謎の達成感を感じております。
今回はセキュリティをトピックにサービスをピックアップしましたが、他のサービスでもOrganizationsは活用できます。
たとえばAWS Backupで使用すると組織単位でバックアップ管理ができたり、AWS RAM（Resource Access Manager）を使用してTransit Gateway等のリソースを組織内に承認なく共有できたりします。
アカウント間の連携で課題を感じる部分があれば、このOrganizationsを活用することで幸せになれることがあるかもしれません。
それでは良いマルチアカウントライフを！
AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～10. Trusted Advisor～
Organizationsシリーズ第十弾、Trusted Advisor編です。
今回でサービス別の紹介は最後になります。
AWS Trusted Advisorとは
AWS Trusted Advisor（以下Trusted Advisor）を使用すると、AWSが推奨するベストプラクティスに従い、以下5点の観点でアドバイスを受けることができます。セキュリティのサービスというよりは、セキュリティのアドバイス機能を含むサービスという感じです。
- コスト
- パフォーマンス
- セキュリティ
- フォールトトレランス
- サービス制限
すべてのチェック結果を確認するためにはビジネスサポート以上のサポートプランが必要です。
Organizationsを使用したマルチアカウント設定
Trusted AdvisorはOrganizationsに対応しているため、複数アカウントの情報を1アカウントに集約できます。アカウントの委任には対応していないため、確認はManagement（親）アカウントで行う必要があります。
Organizationsを使用した組織ビューを有効にするには、Managementアカウントでビジネスサポート以上のサポートプランに加入する必要があります。
また、組織ビューは単体アカウントで確認するときのように画面上から情報を見るのではなく、レポートとしてJSONまたはCSV形式でダウンロードする機能のようです。今後は画面上で見れる機能も追加されるかもしれません。
設定手順
設定方法は簡単です。Trusted Advisorの画面から、組織ビューを有効化するだけです。
有効化すると、レポートを作成できるので作成してみます。
レポートの形式や含める情報を入力します。今回はCSV形式で、すべての情報を含めます。
レポート対象のアカウントを指定します。今回はすべてのアカウントを含めるためRootを選択します。
アカウントの一覧はOUごとに表示され、OU別で選択もできます
しばらくするとレポートの作成が完了し、ダウンロードできるようになります。
レポート名をクリックすると、要約を表示できます。
以下のように要約が表示されましたが、Managementアカウントのダッシュボードの数よりも少ないため、情報が一部反映されていないように見えます。
ダッシュボードは以下のとおりで、↑の要約よりも多くなっています。
どうやら、反映に時間がかかるようで、5日ほどたってまた見ると以下のようにGreen以外は一致していました。
Greenについては、AWS公式ドキュメントに以下の記載があり、組織ビュー側では表示されない項目があるようです。
一部のチェック項目では、リソースが Red または Yellow である場合にのみ表示されます。すべてのリソースが Green である場合は、レポートに表示されない場合があります。
次にレポートをダウンロードしてみます。
以下のように検知されたアカウントID、チェック内容がCSVファイルとして出力されます。
このままでは見にくいので、Excelでうまくまとめるか、JSONでS3に格納してAthenaやQuickSightで可視化するなどの工夫が必要そうです。
CSV以外にも以下の2ファイルがセットでダウンロードされます。
ダウンロードしたレポートには、Managemenetアカウントの情報しか含まれませんでした。 AWSサポートにも確認したところ、Managemenetアカウントだけではなくメンバーアカウントの情報も含まれるとのことでしたが、反映に時間がかかっているようです。
今後はこの更新が早くなると良いですね。
※5日後にダウンロードしたレポートも、メンバーアカウントの情報は含まれませんでした。
検証はここまでです。
さいごに
現時点では、組織全体の情報はCSV or JSONのレポートダウンロード形式となるため、きちんと分析するためにはもうひと工夫必要そうです。 まだOrganizationsに対応したばかりのため、今後、有効化するだけでいい感じに見えるようになるかもしれませんね。期待です。
次回はこれまでのサービスのOrganizations対応をまとめて振り返りたいと思います。
July Tech Festa 2021 winter で Infrastructure as Codeについて話をしてきました
AWS Organizationsシリーズは今回一旦休憩です。
1/24(日)に行われた、インフラエンジニア向けのカンファレンスJuly Tech Festa 2021 winterでお話しました。せっかくなのでブログにも内容をまとめます。
発表資料
なぜこのテーマでしゃべろうと思ったのか
Infrastructure as Code（以下IaC）は、構築や環境の複製を楽にするもの。
だけではない！
インフラ環境の品質UPにもつながるはずだ！と私は信じております。
私はオンプレミスのインフラ構築も多く行ってきており、手動のインフラ構築・運用も行ってきました。IaCでは多くの手動管理の課題が解決できるなと感じているのですが、まだまだIaCが浸透せずに手動管理となっている現場を多く見かけます。
この発表をきっかけにIaC始めてみよう、難しくないんだ！と思ってもらえると良いなと思い発表に至りました。（CFP通って良かった）
発表内容
資料を貼りながら補足部分を書いていきます。
対象は先ほど書いたとおりIaC初心者としております。ここでいう初心者とはインフラ・クラウド構築の初心者ではなく、AWSなどクラウド環境の構築経験はありつつも、手動管理を行っているIaC初心者ということになります。
IaCを使わない手動インフラ管理
まずはIaCを使わない場合（＝手動でインフラ構築、管理）どういった流れになるのかをお話しました。
最初はまずインフラってなんだっけというところです。
そしてインフラ構築の流れ。V字モデルですね。
手動管理では通常、パラメータ設計で設定するパラメータを決定しそれに従い構築、構築ができたら設計したパラメータ通りになっているかテストする。という流れで構築を行っていきます。
具体的なパラメータ内容は構築してみないとわからない部分もあり、設計と構築を行ったり来たりすることも多いですね。
手動管理の課題
1つ目の課題です。
この課題が1番わかりやすいかなと思います。すべて手作業になるため、環境数分の作業時間（手間）がかかります。
また、環境をコピーしている訳ではないため、すべての環境で想定通りのパラメータになっているかテストする必要があります。
実際の開発現場では、アプリ開発チームに、「開発環境もう一つ必要だから作って」と言われることもあります。予定してないから無理と断るか、同じ手間をかけて作るかの2択です。
2つ目の課題。
これも手動構築の現場ではよく見てきました。開発でうまくいっていた設定が、本番では入っていない！？というやつです。
こういった事象を無くすために、各環境できちんとテストをしていくのですが、テストするのも人間であるため、100%ミスを無くすのは難しいです。
3つめの課題。
設計どおり構築をしてもうまくいかない、本番運用中に障害があった場合、その場で急遽設定変更をします。その場でうまく動いたことがとても嬉しいので、たいていの場合設計書への反映が忘れられます。
「たいていの場合」は言い過ぎかもしれませんが、私もこういった経験はあり、「この設計書本当にあってるの？実環境見てくるわ」ということもありました。今でもオンプレ環境だとあったりしますね。
4つめの課題。
「設定の履歴が残らない」です。
これが無いとどういった場合に困るのか、というところですが、たとえば、ファイアウォール（SGでもOK）で見知らぬIPアドレスからアクセス許可の設定が入っていたとします。 IPアドレスの値が入っているのみで、どこのIPアドレスなのかわかりません。
そうなると、誰が、いつ設定したんだ？となりますが、改定履歴がないとそれを聞く相手もわかりません。
そして、その設定は消していいのか、変更していいのかわからないため、怖くていじれなくなります・・
ということでいつ、誰が、何のために設定したのか履歴情報を残すことはとても重要です。
が、資料管理をきちんとやるのはとても難しです。人により履歴の書き方も変わってきます。
ということで課題4つ紹介しました。
IaCが解決する課題
いくつかIaCのツールはありますが、今回はAWSのCloudFormaitonを前提としてお話しました。
1つ目の課題解決。
1番わかりやすいIaCのメリットかと思います。テンプレートベースになるので環境の複製が容易にできますね。
2つ目の課題解決。
1つ目と似ていますが、ここは品質観点です。同じテンプレートベースになるため、環境間で差があるといったミスが発生しにくくなります。
ポイントとして書いているリソースを同一にというのは、たとえばサブネットの数が本番と開発で異なると、テンプレートも環境ごとに書き換えたり工夫をする必要があります。サブネット数など料金に影響を与えない部分は基本的に全環境同じにしたほうがテンプレートとして書きやすいのでおススメです。
また、人のミスを減らすという目的においては、CloudFormaitonのデプロイ作業もパイプラインからコマンド経由で行ったほうが良いです。
3つ目の課題解決。
これは、リポジトリで管理しているテンプレートから正しくリリースしている前提になりますが、実環境を見に行かなくても、テンプレートを見れば設定内容がわかるという点です。
特に運用する方にとって嬉しいポイントかと思います。
4つ目の課題解決。
IaCをGitリポジトリ管理にすることで、強制的に履歴を残せます。
コミットメッセージについては組織でルールを決めて正しく運用でカバーする必要がありますが、少なくとも「誰が、いつ」という情報は残るようになります。その人に聞きにいくことができますね。
課題の解決まとめです。
元々あった課題が完全に無くなるわけではないですが、かなり減らせる部分はあると思います。
CloudFormationの使い方
実際の書き方に入っていきます。
まずパラメータシート。手動管理の場合Excelを使用して以下のような資料を作りますね。VPCを例としています。
これをCloudFormaiton（YAML）で書くとこうなります。（右側）
太字で書いている部分が一番のポイントです。パラメータシートの場合も、CloudFormaitonの場合も書いている内容はほぼ同じです。
おそらくここで難しいと感じる場合は、CloudFormaitonが難しいのではなく、AWSの設定がわからなくて難しいと感じているのだと思います。
CloudFormaitonはYAMLの場合コメントも残せるため、設計で大事となる根拠や補足なども書き込むことができます。
CloudFormtaionのポイント
書き方を覚えたら活用のポイントです。
まずParameters。ほぼ必須で使用する機能です。
環境ごとに変わる値（名前で使用する環境名Env、VPCのCidr）をParametersとして別出ししています。
コードも貼っておきます。
Parameters: Env: Description: "Environment" Type: String Default: "dev" VpcCidr: Description: "VPC CIDR" Type: String Default: "10.0.0.0/16" Resources: vpc: Type: "AWS::EC2::VPC" Properties: CidrBlock: !Ref VpcCidr InstanceTenancy: default EnableDnsSupport: true EnableDnsHostnames: true Tags: - Key: Name Value: !Sub "${Env}-sys-vpc"
次にテンプレートの分割です。実際の運用では1システムすべてを1テンプレートで書くことはあまりなく、いくつかのテンプレートに分割します。
たとえばネットワークのまとまりであるVPCやサブネットを1テンプレートにしたりします。
一方で、VPCの情報は他のリソースでもIDをインプット情報として与える必要があるため、テンプレート間で参照できる必要があります。
そこで紹介したのがOutPutとImportValueの機能です。
コードは以下のとおりです。
- VPC（参照される側）
Outputs: vpc: Value: !Ref vpc Export: Name: vpc
- Security Group（参照側）
Resources: SecuritygroupEC2: Type: "AWS::EC2::SecurityGroup" Properties: GroupName: !Sub "${Env}-ec2-sg" GroupDescription: "for EC2" VpcId: !ImportValue vpc
その他には、SSM Parameter StoreやSecrets Managerを使用するやり方もあります。
次からは運用面。
テンプレートのデプロイやテストも人の手から離れて自動化したいため、以下のようなパイプラインを作ります。
パイプラインの要素ごとに見ていきます。まずはChange Sets。
aws cloudformation deployコマンドを実行すると、すぐさま変更が反映されるのですが、CloudFormaitonでは重要なリソースを管理している場合も多く、変更対象を間違えると意図しない変更や削除が発生する可能性もあります。
そのために本番環境へ反映される前に、事前に反映予定の内容を確認できる機能がChange Setsです。本番環境のパイプラインでは入れることをおススメします。
つづいてCloudFormaitonのテストツール。
cfn-nagやcfn-python-lintはコード解析のツールであるため、テンプレート開発中もローカルで実行することができます。各テストツールのリンクを貼っておきます。
TaskCatは、実環境にデプロイできるかという観点でテストができます。CloudFormaitonはテンプレート内容としてOKでも、実際の環境によってNGになることもあるため、デプロイを事前確認することで品質UPにつながります。
パラメータチェックのツールです。
たとえばCLIでVPCの情報を見たい場合はaws ec2 describe-vpcsというコマンドで確認できます。
awspecはテスト用のツールです。
以下のように書いてVPCのあるべき状態を書いてテストが可能です。
require 'spec_helper' describe vpc('my-vpc') do it { should exist } it { should be_available } its(:cidr_block) { should eq '10.0.0.0/16' } it { should have_tag('Name').value('my-vpc') } end
テスト手法について書きましたが、2つ目に書いたパラメータチェックは必要なのかというところについての考察です。
どちらが正解という結論はここでは出していませんが、私としては、IaCではテンプレートの内容がとても重要になるため、できればまず複数名でレビューを行って、テンプレートの品質UPを目指すのが良いと思っています。
テストツールを使ってパラメータチェックをするのも良いと思いますが、全パラメータをやみくもにチェックするのではなく、ポイントを絞って方針を決めることをおススメします。
たとえばセキュリティに関わるところとか、環境ごとに差が出そうなところです。
テストケース数や実施状況を報告しなきゃいけないという状況となり、関係者の品質共通認識としてテストツールを使うことが良い場合もあるかと思います。
まとめ
少しでもIaCで解決できそうな課題がありましたら是非ご使用を！
手動管理をやってきたインフラな方は、CloudFormaitonが取っ付きやすいと思います。
いただいた質問
「Go Formationのように、プログラム言語でCloudFormationを書く機能もあるがそれについてどう思うか。」
という質問をいただきました。ありがとうございます。
CloudFormation、全設定を見るという面では非常に優れていると思うのですが、これがツライ部分もあります。 たとえばマネジメントコンソールでは自動設定くれる場所も書かないといけないので、記述量が多くなりがちです。
また、ループのような処理もCloudFormation単体では難しいです。
そういった記述の柔軟さで言うと、Terraformのほうが優れているかなと思います。
AWS CDKも使ってみたいです。
ただ、組織全体で考えると、まだIaCに慣れていないメンバーがいる場合は、CloudFormationが入りやすいと思い選ぶことが多いです。
自分1人であれば、次はCDKで頑張ってみたいなという気持ちもあります。
登壇してみて
私にとってはとても大きなイベントでの登壇でした。
他の方の発表はとても専門性が高くて素晴らしく、私のはあまり見られないなと予測しておりましたが、それなりに見ていただけて良かったです。
運営されていた方、発表された方、視聴してくれた方、機会をいただき本当にありがとうございましたm(__)m
アーカイブされたらほかの方の発表もじっくり見たいと思います。
AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～9. Personal Health Dashboard～
Organizationsシリーズ第九弾、Personal Health Dashboard編です。
AWS Personal Health Dashboardとは
AWSアカウント内のAWSリソースの障害やイベントが発生した（する）場合に、このPersonal Health Dashboardを経由して通知されます。アカウント内のリソースではなく、AWSサービス全体としての稼働状況はService Health Dashboardとして公開されています。Service Health Dashboardの内容（パブリックイベント）は、Personal Health Dashboardにも表示されます。
たとえば使用しているEC2インスタンスが稼働するハードウェアの障害であったり、RDSのメンテナンス予定日や内容がこのPersonal Health Dashboardに表示されます。
セキュリティサービスなのか？と言われると微妙なところですが、大事なサービスなので書いておきます。
Organizationsを使用したマルチアカウント設定
Personal Health DashboardはOrganizationsに対応しているため、組織内の全アカウントの障害やメンテナンス情報を一括で表示できます。
ただし、アカウントの委任には対応していないため、イベントの確認はManagement（親）アカウントで行う必要があります。
設定手順
組織ビューを有効にするところだけやってみます。というのも、特に私の検証環境では通知されているイベントが無いので、アカウント間の通知確認は現状できませんでした。（サンプルイベントも思いつかず）
Personal Health Dashboardの画面へ遷移し、組織ビュー（organizational view）を有効にします。
Successとなり、組織ビューのメニューが追加されています。
DashBoardは以下のようになっています。特にissueは無いですが、きっとAWSリソースの障害やメンテナンスがあるとここに表示されるはずです。 見え方はシングルアカウントのときと同様ですね。
Event logは以下のように表示されています。ここに表示されているのはAWS全体のパブリックイベントですね。過去の障害情報が表示されていました。
短いですが設定検証はここまでです。
さいごに
組織ビューを有効にするだけだったため、すぐに終わってしまいました。障害イベント等見せれずですいません。
AWS側の障害は、CloudWatch等の監視では気づけない場合もありますので、通常の監視と合わせてPersonal Health Dashboardの監視も行いたいところです。
次回はTrusted Advisorの予定です。
AWS Organizationsを活用したマルチアカウントのセキュリティサービス使用方法 ～8. Detective～
Organizationsシリーズ第八弾、Detective編です。
Amazon Detectiveとは
Amazon Detective（以下、Detective）は、VPC Flow Logs、CloudTrail、GuardDuty などの他のAWSサービスの情報をインプットに、潜在的なセキュリティ問題や不信なアクティビティを分析、調査できるサービスです。
GuardDutyは発生したセキュリティイベントを検知するため、発生したイベントベースでの調査を行うことになりますが、Detectiveでは過去のログやイベント情報をといった時系列の観点を含み、グラフ等で視覚化することが可能です。
個人的には、探偵のサービスアイコンが好きですｗ
Organizationsは対応していない ※2021年1月現在
Detectiveは、Organizationsに対応していないようです。よって組織内の全アカウントの情報を自動的に集約することはできません。
今回はは手動で各アカウントを追加して集約する方法を試してみます。手順は以下のとおりです。
- 監査アカウントで有効化
- メンバーアカウントの招待
- サンプル調査
設定手順
やっていきます。
1. 監査アカウントで有効化
auditアカウントにログインし、Detectiveページに遷移します。
有効化（Enable）
できました。有効直後はまだ情報が表示されません。
2. アカウントの招待
auditアカウントに情報を集約するため、system01アカウントとManagementアカウントを招待していきます。
Account management ＞ Invite individual accountsの順で進みます。csvファイルで一括招待もできるようですが、今回は数も少なく流れを見たいので1つずつやっていきます。
招待するアカウントIDとメールアドレスを入力して招待します。メールの文章も書けるようなので紳士的な文章を書いておきました。
以下のようなメールが届きます。（日本語を入れたら英語と入り混じりました）
メールのリンクをクリックします。このとき、招待されたManagemenetアカウントにログインする必要があります。
Acceptします。
同じ流れで、system01アカウントも招待→承認の流れを実行しておきます。
2アカウントとも承認が終わると、以下のとおり3アカウントがEnabled状態になります。
3. サンプル調査
有効後すぐでは情報が見れなかったため、1時間ほど待機して見てみました。
また、履歴情報を使用するベースラインの使用は2週間ほどかかるようです。履歴が無い（短い）のでまぁそうかという感じです。
アカウントIDで検索して情報が見れるので、ManagemenetアカウントIDでフィルタして情報を見てみました。
APIの実行状況が表示されています。検証程度で使っているだけなので、あまり面白さが無いですが、一応見えています。
有効化して時間があまり経っていないのでまだ集約しきれていない情報もあるのだと思います。
1点注意なのが、集約したauditアカウント以外のsystem01やManagementアカウントのDetective画面では、以下のように情報が見れませんでした。
各アカウントの情報は集約したアカウントのみで見る必要があるようです。
検証はここまでとします。
さいごに
Organizationsには現時点で未対応ですが、そのうち対応しそうな画面のインターフェースですねｗ Organizationsに対応したら招待も不要で集約できるかもしれません。比較的新しいサービスなので、Organizations対応以外にも追加の機能がこれからも出てきそうです。
メール確認→承認のフローを考えると、CloudFormation StackSetsを使用したアカウント追加時の自動化も難しそうです。ここも自動有効化など今後に期待です。
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に移動をクリックします。
Security Hubの有効化画面が表示されますが、ここではまだ有効にせず、一番下に行きアカウントの委任を実行します。
委任完了です。委任だけではSecurity Hubは有効になりません。
2. Security Hubの有効
まずは、管理者として委任したauditアカウントにログインして有効にします。
有効化後、設定ページを開くと以下のようにOrganization組織内のManagementアカウントとsystem01アカウントが表示されます。 一括でSecurity Hubを有効化できそうなボタンが表示されたのでこれを押下してみます。
以下のようなメッセージが表示されます。警告用途かと思いますが、組織内に一律自動有効したい場合にはありがたい内容ですね。
有効化すると以下のとおり、system01のみ有効になりました。組織のManagementアカウントは自動有効とならないようです。
委任前にManagementアカウントで組織単位で有効化すれば一気に全有効化できたかもしれません。（少し後悔）
Managementアカウントの有効は、Managementアカウント自身で行う必要があるようなので、ログインして有効化します。
Managementアカウントで有効になったら、再びauditアカウントにログインして戻ってきて、Memberに追加します。
無事Memberになりました。
3. 検出結果の確認
1ヵ所で集約できるはずなので、結果を見てみます。
GuardDutyを見てみます。Managemenetアカウントで、GuardDutyのサンプルイベントを発行しました。 auditアカウントで以下のように表示されています。
無事、別アカウントの結果が見れました。と思ったのですが、少し疑問が残ります。 GuardDuty側ですでに情報の集約をしているので、GuardDuty側でauditに集約された情報があがってきている可能性もあります。
とゆうことで、コンプライアンスチェックについても別アカウントの情報が見れるか確認してみます。
※コンプライアンスチェックは有効後、時間がかかるので1時間ほど待ちました。
以下のように、auditアカウントのSecurity Hubで、system01のコンプライアンスチェックが見えています。1アカウントに集約できていますね。
アカウントIDで情報をフィルタできるのでそれを使用しました。
設定検証は以上です。
さいごに
今回はSecurity Hubの通知設定までは行いませんでしたが、EventBridgeを使用することで通知を行うことができます。すべての結果を通知してしまうとかなりの数になるので、あらかじめフィルタする情報は検討して通知を検討したほうが良いでしょう。
集まる情報量も多いので、まずは定期的にセキュリティ情報を確認する場所としてSecurity Hubを使用するのもありだと思います。
次回はAmazon Detectiveの予定です。
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をクリックすると、「代表管理者を追加」ボタンがあるのでそれをクリックします。
追加を押します。
委任するアカウントのIDを入力します。今回の例ではauditアカウントのIDです。
以下のように委任の設定が完了します。
委任完了時点では、各アカウントのアナライザーは自動作成されていませんでした。ここは個別に作成する必要があるようです。
2. アナライザー作成
アナライザーはauditアカウントに集約するため、auditアカウントにログインしてIAM Access Analyzerの画面へ遷移し、アナライザーの作成をクリックします。
作成時に、組織全体か、アカウント単体で作成するか選択できるので組織を選択します。
作成にはしばらく時間がかかるので待機します・・
作成が完了すると、以下のようにリソースの状況が表示されます。
今回は、意図的にアナライザーで検知させるために、全アカウントにアクセス許可を与えたS3バケットをsystem01アカウントに作成しておきました。 最初の2行がそのバケットになります。（なぜか同じリソースが2行表示されました、仕様？）
IAM Role2つは、AWS SSOの設定時に自動作成されたIAMロールです。
確認しているアカウントはauditなので以下のように複数のアカウントの状況を表示できていることになります。
3.アカウント単体のアナライザー作成
auditアカウント単体でもアナライザーを作成してみます。手順はさきほどと同様で、作成時に「現在のアカウント」を選べばOKです。
作成すると以下のように表示されます。1行目は組織のアナライザーに表示されていたものと同じです。
2つ目は、Organizationsの組織作成時に自動生成された、ManagementアカウントからスイッチできるIAMロールです。
3つ目は、CloudTrailを組織単位で設定したときに作成したS3バケットです。
組織のアナライザーでは、許可しているアカウントがOrganizationsの組織内であったため、表示されませんでした。 組織内のアカウント間許可を表示したいかは、利用状況により異なるかもしれませんが、アナライザーは無料なので、一律全アカウントで有効にしておいて良いと思います。（作業の自動化は検討）
設定作業はここまでです。
なお、IAM Access Analyzerはリージョンサービスです。IAMの情報は表示されますが、S3バケットなど別リージョンでも作成されるリソースを検知する場合は、すべてのリージョンで有効にする必要があります。
さいごに
マルチアカウント運用となると重要度が増してくるIAM Access Analyzerについて紹介しました。共有されたリソースを、どう運用の中で定期的に確認していくかが重要になりますね。
確認したリソースは確認済みとしてアーカイブする機能もあるので、定期的に確認を行い全てアーカイブされるようにするのが理想な運用かと思います。
次回はAWS Security Hubの予定です。