100アカウントを見据えたAWSマルチアカウント運用 / AWS multi-account operation for 100 accounts

弥生株式会社　もくテク
『100アカウントを見据えた』AWSマルチアカウント運用（2022/05/19）
https://mokuteku.connpass.com/event/241715/

Transcript

1. 100アカウントを見据えた AWSマルチアカウント運用 2022年05月19日(木) 弥生株式会社 開発本部 インフラチーム TechL 峯岸純也
2. 突然ですが 弥生のAWSアカウント数は いくつあるでしょうか？
3. ５８です マルチアカウント環境にする前のAWSアカウントは 「４」個です
4. お話したいこと  AWSを利用するにあたりAWSアカウント構成を考え直してみた  【これまで】各環境ごとのAWSアカウント構成（本番環境、統合環境)  【これから】サービスごとにAWSアカウントを払い出す  AWSアカウントがマルチアカウント環境になった  ガバナンス強化のためにしたこと  インフラチームの役割と課題
5. 本日の登場人物 佐々木淳志（ささきあつし） 新サービス全体の アーキテクチャを考えたり、考えたり etc 峯岸純也（みねぎしじゅんや） インフラチーム インフラ面の技術検討・構築 etc
6. 自己紹介 弥生株式会社 開発本部 インフラチーム TechL （Technical Leader） 峯岸 純也  2020年1月に弥生にJoin  インフラ経歴ゼロで入社させていただく  弥生インフラ領域の何でも屋さんです  過去のお仕事は、Java / C#メインで開発 etc  プログラミングが嫌いで昔からインフラやりたかった  自宅にCisco Catalyst 1000あります  最近のお仕事内容  AWSインフラ / セキュリティ / ガバナンス周り  既存インフラ環境の運用保守（オンプレ・AWS・Azure）  断捨離大臣、防衛大臣に任命される  趣味  犬、ウィスキーミニボトル集め アイコンは常に犬
7. これまでのインフラチーム 本番アカウント 統合アカウント Service A Service B Service C Service D Service E Service A Service B Service C Service D Service E インフラチーム 各チーム担当者 IAMユーザ作成・削除 IAMユーザ権限変更 本番 / 検証環境構築・削除 EC2停止・起動 メンテナンス作業 問い合わせ etc これが58アカウントに なったら死人が出る
8. AWSアカウント数が現時点でも14倍に  インフラチームの人数も14倍に・・・  はならないので、これまでと異なる動きをしていかないとダメ 新しいAWS環境は各製品サービスごとに AWSアカウントを持たせるマルチアカウント 環境にしようと思っていますのでー それだとインフラ死んじゃいますって 今までと同じく全部をインフラが担った場 合はそうなるよね AWSはマルチアカウント環境向けに 「ControlTower」っていうサービスがあるん だ そのサービスを使って製品サービスチー ムに渡したアカウントは管理してもらうよう にしよう 了解です
9. AWSセキュリティの大きな観点３つ AWS Management Console AWS Command Line Interface (AWS CLI) Amazon Simple Storage Service (Amazon S3) AWS Lambda Role VPC Endpoints VPN gateway Internet gateway subnet Role AWS Service Catalog AWS Config AWS Trusted Advisor AWS Systems Manager AWS CloudTrail AWS上に構築するシステムのセキュリティ AWSアカウント自体の管理 (IAMの設計・運用) セキュリティを維持・管理するための施策
10. ControlTowerの構成 Master Account Log Archive Account Audit Account User Account ControlTower CloudFormation CloudFormation CloudFormation CloudFormation VPC SNS Config S3 CloudTrail & Config Log Service Catalog Single Sign-On Organizations インフラ管理 各チーム管理
11. Control Towerを使ってどうなっているか？ Master Account (Control Tower / SSO) ステージング環境 勉強用アカウント Audit (各ツール類) / LogArchive (ログ集約) 開発環境 本番環境 Master Accountから見たAWS Organizationsの画面 インフラ管理 各チーム管理
12. Control Towerの嬉しいところ  ガードレール機能  自分で設定するとめんどくさい組織的な共通ルールを簡単に有効化できる  ルートユーザとしてのアクションを許可しない  CloudTrail証跡 / Config自動設定  自動的に有効化  ログをLogArchiveアカウントへ集約
13. Control Towerを使うと できるよー でも準備としてCFnでConfigやCloudTrailを 自動的に有効化したり、Organizationsにア カウント作ったりを自分でやるの大変じゃ ない？ 自分で地道にポチポチやっても出来るし、 ある程度の範囲を自動的にベストプラク ティスに沿って実行してくれるのが ControlTowerなんですね Yes！ インフラチームを14倍の体制にしなくても、 ControlTowerを使ったアカウント追加運用 なら出来そうでしょ？ 確かにこれならやれそうです！ ControlTowerを使ってアカウント発行や 管理がしやすくなるのはなんとなくわか りました でもOrganizationsやCFnのStackSetsを使 えば同じことできますよね？
14. AWSセキュリティの大きな観点３つ AWS Management Console AWS Command Line Interface (AWS CLI) Amazon Simple Storage Service (Amazon S3) AWS Lambda Role VPC Endpoints VPN gateway Internet gateway subnet Role AWS Service Catalog AWS Config AWS Trusted Advisor AWS Systems Manager AWS CloudTrail AWS上に構築するシステムのセキュリティ AWSアカウント自体の管理 (IAMの設計・運用) セキュリティを維持・管理するための施策
15. IAMユーザからの脱却 IAMユーザ止めましょう ControlTowerでSSOサービスとの連携があ るので、SSOやっちゃいましょうよ マルチアカウント環境にする前の運用で はIAMユーザの権限で大変な想いをして いるのでやるなら今ですね Azure ADもすでに運用されているようです し、連携はそこまで大変ではないかと やっちゃいましょう 了解です 各製品サービスのアカウントで、必要な 人数分IAMユーザ作成していると大変に なっちゃいますよね
16. AWS Single Sign-On構成図 Organizations Single Sign-On Azure AD プロビジョニング Master Account User Account 権限・ユーザの配布 ログイン用IAM リソース作成不要  各人のIAMユーザ管理からの解放  必要なIAMユーザは各チームへお任せ 実際には 権限が紐づいている AWSアカウントが表示される
17. デフォルトSSO権限セット問題 どうしたのかな？ AWSAdministratorAccess AWSPowerUserAccess AWSReadOnlyAccess の３つくらいしかありません ふむふむ これだと細かい権限、例えばあるS3バ ケットのみに絞るなどの要望がいっぱい きちゃいます インフラチームの体制を14倍にｗｗｗ 大変です SSOを設定したらデフォルトの権限セット が！！？ それは無理ｗｗｗ SSOの権限セットは最低限しか用意されて いない なので権限を作成できる権限を移譲できる か検討しよう
18. SSO権限セット作成の委任 Organizations Master Account Other SSO User Account DelegatedOUAdmin 権限セットの一時付与  非常に多数になりがちなIAMポリシー管理からの解放  必要な権限セット作成は各チームへお任せ 役割分担 ①各チームからインフラへ「DelegatedOUAdmin」付与依頼 ②インフラで必要メンバーへ付与 ③付与されたメンバーがSSO権限セットを作成 ④作成したSSO権限セットを必要なメンバーへ付与する依頼をインフラへ ⑤インフラで必要メンバーへ作成されたSSO権限セットを付与
19. AWSセキュリティの大きな観点３つ+α AWS Management Console AWS Command Line Interface (AWS CLI) Amazon Simple Storage Service (Amazon S3) AWS Lambda Role VPC Endpoints VPN gateway Internet gateway subnet Role AWS Service Catalog AWS Config AWS Trusted Advisor AWS Systems Manager AWS CloudTrail AWS上に構築するシステムのセキュリティ AWSアカウント自体の管理 (IAMの設計・運用) セキュリティを維持・管理するための施策
20. その他の自動化  StackSetsとOrganizationsの連携  ControlTowerでアカウント追加時に、CloudFormationのStackSetsを実行  必要なサービスを自動的に有効（+最低限必要の設定を投入） Master Account AWS CloudFormation Stack AWS CloudTrail AWS Security Hub AWS Config AWS IAM Access Analyzer Amazon GuardDuty Amazon Inspector ControlTower StackSetsで自動有効化 (設定投入) されるサービス AWS Compute Optimizer Amazon Detective
21. GuardDuty検知方法 そうだね AWS独自基準で過去にアタックを仕掛けて きている有名なIPアドレスとかを検知してア ラートにしているからね 既存商用サービスのほうだと、インフラ チームにメールが送付されるようになっ ているんですが、メール数が多くて見逃 がしやすいかなと ふむふむ、いい案ある？ EventBridgeとChatbotを使って、Slackに 投稿しちゃうのはどうでしょうか？ GuardDutyで検知したレベルにもよりま すけど、なるべく早く調査・対応したほう がいいですよね？ いいんでない？ チームが通常利用しているSlackに投稿さ れるのは嫌とかありそうだから、どのチャ ンネルが良いか取りまとめておくね
22. GuardDutyの検知 Audit Account Amazon GuardDuty Amazon EventBridge AWS Chatbot Slack  GuardDutyの検知 / 対応  各チームに依頼出来る仕組みを提供出来た  メールは1日の受信件数が多くて見逃がしやすいのでSlackへ  全アカウントの検知内容を通知するチャンネル  その他は各チームに合わせたSlackチャンネルへ通知 GuardDutyのテスト投稿
23. AWSからの通知 最終的には物理のマシンで動いているも のだからね 老朽化したハードウェアに乗っているEC2 インスタンスが運悪く当たったら、メンテナ ンスが連発しちゃうのかもね メールだと見逃しやすいんですよね。。 誰かがキャッチすればいいんですけど メール＋αでの通知にしたいところだね AWS Helth Awareなるものがあるっぽい のでこいつ仕込んでみますね AWSからメールで、「メンテナンスするよ」 とか通知が来るじゃないですか あれって、来るときはタイミングを図った ように連発で来るんですよね。。。
24. AWS Health Aware全体構成 Master Account Amazon EventBridge Lambda Health AWS Secrets Manager Slack Amazon DynamoDB User Account
25. AWS Health Awareの効果  AWSからの通知の見落とし予防  メール & Personal Health Dashboardにも連絡は来ているが見落としがち  障害情報をすばやくキャッチ  Service Healthに関する情報も受け取るように設定 以下のリージョンについてHealth関連の通知を受信するように設定 東京リージョン、大阪リージョン、バージニアリージョン、グローバルリージョン ※全リージョンにすると通知が多くなりすぎるため
26. 検証用サブドメイン問題 しつこい すみません 今までDNS関連も全てインフラ管理に なっていたので・・・ SSO権限セットと同じくDNSも移譲しちゃえ payroll.yayoi-kk.co.jpのNSレコードをAWS へ向けて xxx.payroll.yayoi-kk.co.jp のxxx部分を各チームにお任せしちゃう んですね？ 大変です 各チームから検証用のサブドメインを、 数十個程度必要という話が来てます インフラチームの体制を14倍にｗｗｗ そうそう DNSの要否だって各チームが一番詳しい から定期的な棚卸だってできるし yayoi-kk.co.jpは引き続きインフラ管理だけ ど、配下は各チーム任せでどうよ
27. サブドメインの委任 ホストゾーン xxx.yayoi-kk.co.jp作成 nsレコードA nsレコードB nsレコードC nsレコードD Amazon Route 53 yayoi-kk.co.jp管理DNS NSレコード登録 nsレコードA nsレコードB nsレコードC nsレコードD DNSレコード登録 subdomainA.xxx.yayoi-kk.co.jp subdomainB.xxx.yayoi-kk.co.jp subdomainA.xxx.yayoi-kk.co.jp subdomainB.xxx.yayoi-kk.co.jp インフラは NSレコードの登録のみで、 後は各チームで必要な分だ けサブドメインをRoute53か ら発行してもらえる
28. AWSセキュリティの大きな観点３つ+αパート2 AWS Management Console AWS Command Line Interface (AWS CLI) Amazon Simple Storage Service (Amazon S3) AWS Lambda Role VPC Endpoints VPN gateway Internet gateway subnet Role AWS Service Catalog AWS Config AWS Trusted Advisor AWS Systems Manager AWS CloudTrail AWS上に構築するシステムのセキュリティ AWSアカウント自体の管理 (IAMの設計・運用) セキュリティを維持・管理するための施策 前半パート終了
29. 前半戦終わり
30. AWSセキュリティの大きな観点３つ+αパート2 AWS Management Console AWS Command Line Interface (AWS CLI) Amazon Simple Storage Service (Amazon S3) AWS Lambda Role VPC Endpoints VPN gateway Internet gateway subnet Role AWS Service Catalog AWS Config AWS Trusted Advisor AWS Systems Manager AWS CloudTrail AWS上に構築するシステムのセキュリティ AWSアカウント自体の管理 (IAMの設計・運用) セキュリティを維持・管理するための施策
31. 何かあったとき問題 何かインシデントが発生した際に LogArchiveアカウントから該当ログを提供 するとかかな そうすると各種ログから何があったか？ を確認出来るような仕組みも準備してお いたほうが良さそうですね SIEM on Amazon ESっていうのがあるみたい だよ SIEM on Amazon ES。。。 調べてみます！ インフラ管理のアカウントが限定的に なって、定型外の作業が発生するとした らなんでしょうかね・・・
32. SIEMとは  Security Information and Event Management の略で、セキュリティ機 器、ネットワーク機器、その他のあらゆる機器のデータを収集及び一 元管理をして、相関分析によって脅威検出とインシデントレスポンス をサポートするためのソリューションです。  Amazon OS は、オープンソースの Opensearchと Kibana を大規模か つ簡単でコスト効率の良い方法を使用してデプロイ、保護、実行する 完全マネージド型サービスです。
33. SIEM全体構成図 各Account Amazon Kinesis Data Firehose Amazon OpenSearch Service Log Archive Account Delivery Stream S3 Export S3 Export Replication S3 ログ集約用S3 Audit Account SIEM取込み用S3 Lambda Function es-loader Replication
34. ログ取り込み別SIEM VPC Flow log(難易度★) 各Account Amazon Kinesis Data Firehose Amazon OpenSearch Service Log Archive Account Delivery Stream S3 Export S3 Export Replication S3 ログ集約用S3 Audit Account SIEM取込み用S3 Lambda Function es-loader Replication VPC
35. SIEM VPC Flow logのダッシュボード
36. ログ取り込み別SIEM CloudTrail(難易度★) 各Account Amazon Kinesis Data Firehose Amazon OpenSearch Service Log Archive Account Delivery Stream S3 Export S3 Export Replication S3 ログ集約用S3 Audit Account SIEM取込み用S3 Lambda Function es-loader Replication ControlTower環境で作成したアカ ウントであれば、自動的に LogArchiveアカウントに保存される ハマりPoint トリガーにS3が設定されているが、プレフィックスに 組織IDが入っていない ControlTowerの場合は、組織IDが付与されるので、 トリガーの設定も変更しないとSIEMに取り込まれな い
37. SIEM CloudTrailのダッシュボード
38. ログ取り込み別SIEM SecurityHub(難易度★★) 各Account Amazon Kinesis Data Firehose Amazon OpenSearch Service Log Archive Account Delivery Stream S3 Export S3 Export Replication S3 ログ集約用S3 Audit Account SIEM取込み用S3 Lambda Function es-loader Replication ハマりPoint Kinesis Data Firehoseはマネジメントコンソール上からは、別アカウ ントのS3は指定できない AWS CLIから指定する必要がある (※2021年12月現在) AWS Security Hub
39. SIEM SecurityHubのダッシュボード
40. ログ取り込み別SIEM GuardDuty(難易度★★★) 各Account Amazon Kinesis Data Firehose Amazon OpenSearch Service Log Archive Account Delivery Stream S3 Export S3 Export Replication S3 ログ集約用S3 Audit Account SIEM取込み用S3 Lambda Function es-loader Replication ハマりPoint KMSキーのポリシー、S3バケットのポリシー、es-loaderのポリシー が正しく付与されていないと暗号化 / 複合化が出来ずにSIEM環境に取り込ま れない 特にS3レプリケーションのステータスは「FAILED」という表記のみで、サポートに 問い合わせしても、クロスアカウントレプリケーションのため、それぞれのアカ ウントでサポート起票が必要という部分で苦戦した AWS KMS key AWS KMS key Amazon GuardDuty
41. SIEM GuardDutyのダッシュボード
42. SIEM環境について  注意点  何かあった時の事象を解消してくれる万能ツールではない  何かあった時にSIEMを検索して、該当の日時に怪しいログがあるとか、ここから調査を はじめればよいという位置づけ  実際にはLogArchiveアカウントの生ログを見る必要が出てくる可能性もある  その他のログ取り込み  鋭意対応（検証）中
43. AWS利用料 じゃあ、料金確認も各チームに任せられる ような仕組みを用意しちゃえ QuickSightで何か出来そうじゃないかな QuickSightのハンズオンしてもらって、 さっそく作ってみました！ いいね！ 色んなグラフのデザインとかあって、ハマる と沼になりそうだね 画面でポチポチ簡単にグラフィカルな体 裁変更が出来るので、延々とディテール に凝ってハマってしまいそうです・・・ ほどほどにしましょう これまでだと、年間のAWS予算とか、都 度どのサービスでどのくらいの料金が掛 かっているか？とか問い合わせが多 かったりします
44. 料金確認の全体構成 Master Account Log Archive Account ログ集約用S3 Audit Account AWS Cost & Usage Report S3 Amazon QuickSight AWS Glue Amazon Athena Crawler IAM IdP Single Sign-On Client PC Single Sign-Onアプリケーション 属性マッピング
45. 料金確認の内容  日別の利用料とアカウント数 (週別、月別もあります)
46. 料金確認の内容  日別のサービス別利用料 (週別、月別もあります)
47. 料金確認の内容  日別のアカウント別利用料 (週別、月別もあります)
48. 料金確認の内容  利用料割合 (サービス別 / アカウント別)
49. 料金データ (CUR) のイケてないところ  アカウント名がデータにない（アカウントIDを覚えてないといけない）  そこで・・・サーバーレスで自動化してアカウントリストを取得 Master Account Audit Account S3 Amazon QuickSight Amazon Athena Amazon EventBridge AWS CodeBuild S3 File system AWS CLIを活用して AccountId, AccountName <12桁のアカウント>, アカウント名 <12桁のアカウント>, アカウント名 といったCSVファイルを作成 CUR Table AccountListTable QuickSightの各グラフでアカウント 名を表示させるために両テーブル をアカウントIDで結合 ControlTower
50. 料金確認の効果  各チームで利用料を気にしてくれるようになった  利用料割合から、「なぜ、こんな高いのか？」  どうすればもっと安くなるか？ これまでインフラチームから利用料を都度提供してきたが、これで都度各チー ムに確認、改善をしていただけるようなものを提供出来た  今後はAWS予算も各チームで・・・やってもらえるかも？
51. AWSガバナンス もちのろん Security HubやInspector、AWS Configな ど、ある程度のルールに沿った検知 サービスは有効化していますが、是正と なると、全体的にどれだけ守れているか とかそういったものを見れた方がいいで しょうか だれがやるかの部分は置いておくとして、 どれだけ今守れているか、守れていない か、などの全体感は見れるようにしておい て、守れていないルールがどのアカウント で多いかとか、そういう確認は必要になる ね せっかくQuickSightを料金確認ツールとし て使えるようにしたので、この件も QuickSightでやりますか 近いうちにマルチアカウント環境のガバ ナンス強化・是正活動も取り組むことに なりますよね
52. AWS Configダッシュボードの全体構成 Master Account Log Archive Account ログ集約用S3 Audit Account Amazon QuickSight Amazon Athena IAM IdP Single Sign-On Client PC Single Sign-Onアプリケーション 属性マッピング AWS Config 各Account
53. コンプライアンス全体
54. EC2情報
55. RDS情報
56. IAM情報
57. VPC情報
58. AWS Configダッシュボード化ワンポイント Master Account Audit Account Amazon Athena Amazon EventBridge AWS CodeBuild ControlTower Amazon EventBridge  AWS Config用のAthenaテーブル更新自動化  アカウントが追加されたり、削除されたりした場合に、アカウントID情報を Athenaのテーブルプロパティとして連携する必要がある  EventBridgeでアカウント追加、削除のクロスアカウント連携  CodeBuildでAthenaのテーブルを更新するクエリを生成・実行
59. AWS Configダッシュボードの効果  コンプライアンス違反の全体感  今後の是正活動時にコンプライアンス違反が減ってきているかを確認可能  コスト管理  高額なEC2 / RDSインスタンスタイプを使用していないか  リスク管理  不要なIAMユーザ / ロールがないか などをざっくり確認出来る
60. ここまでの振り返り
61. スケジュール感 21/08 21/09 21/10 21/11 21/12 22/01 22/02 22/03 22/04 22/05 22/06 22/07 ControlTower構築 Single Sign-On設定 SIEM on Amazon ES GuardDuty検知 AWS Health Aware 料金確認QuickSight AWS Config QuickSight Security違反自動検知v1 構成図自動描画 是正活動 別 件 で 忙 し か っ た
62. 効果 これまで マルチアカウント環境 AWSアカウント作成 ー 最短30分 IAMユーザ作成 依頼によるが1week程度かかる時も 最短5分 SIEM ー AWS各種ログの調査 GuardDuty メール Slackで関係各所へメンション AWS Health Aware メール Slackで関係各所へメンション 料金確認QuickSight インフラチームにて予実を確認 各チームでコスト削減対応 AWS Config QuickSight ー 今後の是正活動に活用予定 Security違反自動検知v1 レビューで発見された危ないセキュリ ティ設定を連絡して対応 自動検知 （場合によっては）自動削除 構成図自動描画 ー 全アカウントの構成図を日次で更新 開発止めないスピーディーを！何かあれば調査を！検知もスピーディーに！ 利便性のあるツール類も！是正活動の視覚化！リスクコントロールもするぞ！ 結果盛りだくさんに・・・よく一人でやったなと自分を褒めたい（褒めて佐々木さん！ついでにお給料も上げてｗ）
63. インフラチームの新しい役割  AWS100アカウント規模の環境を見据えた運用を考える  2021年8月から2022年5月の10か月でアカウント数「58」、今後も増加が加速 していくと思われる  全てを担わない、けど全てを見て各チームで利用しやすいものを提 案改善していく  各アカウントの管理を各チームにお任せしているが、全てのアカウントの Admin権限をインフラチームも持っている  何かあれば相談してもらって、実際に環境を見て回答することが可能  誰かからこれをやろうと具体的な指示があるわけでもない、でも誰か がやらないといずれ大変な目に合う
64. 課題  ある程度の検知の仕組みは出来てきた  検知から是正の方法やルールを決めていく必要がある  目指せ定型完全自動化！  自動化への改善余地はまだまだある  定型作業で工数を使わず、非定型に集中していく土台を  構成管理  100アカウントレベルの構成管理  運用属人化  徐々に引継ぎ 妥協しない ここをがんばらないと自分、 または引き継ぐ人が大変
65. Coming Soon <是正活動> AWS Trusted Advisorの内容を QuickSightダッシュボード化 AWSからの改善提案を見える化 <構成管理> AWS構成図の最新化・維持管理の自動化 <調査> 膨大な量となるCloudTrailログをAthenaでパーティション化 該当日、イベントがわかれば調査がスピーディーに AWS Security Hub AWS Lambda <リスク検知→自動復旧> フルオープンのセキュリティグループを設定してしまった 場合に自動的に検知→削除
66. 識別 防御 アイコンで何のサービスかわかるかな？ 検知 調査 自動化 復旧 and SIEM 最後に
67. 安全で快適な マルチアカウント環境を 目指して
69. メモ  参考URL ▪マルチアカウントのベストプラクティス https://aws.amazon.com/jp/builders-flash/202007/multi-accounts-best-practice/?awsf.filter- name=*all ▪マルチアカウントのベストプラクティス2 https://aws.amazon.com/jp/builders-flash/202009/multi-accounts-best-practice-2/?awsf.filter- name=*all ▪SIEM on Amazon ES https://github.com/aws-samples/siem-on-amazon-opensearch- service/blob/main/README_ja.md ▪AWS Config QuickSight https://aws.amazon.com/jp/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and- amazon-quicksight/ ▪AWS Health Aware https://dev.classmethod.jp/articles/organizations-phd-notifies-aha/