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 峯岸純也
   

   View Slide

2. 突然ですが
   弥生のAWSアカウント数は
   いくつあるでしょうか？
   

   View Slide

3. ５８です
   マルチアカウント環境にする前のAWSアカウントは
   「４」個です
   

   View Slide

4. お話したいこと
    AWSを利用するにあたりAWSアカウント構成を考え直してみた
    【これまで】各環境ごとのAWSアカウント構成（本番環境、統合環境)
    【これから】サービスごとにAWSアカウントを払い出す
    AWSアカウントがマルチアカウント環境になった
    ガバナンス強化のためにしたこと
    インフラチームの役割と課題
   

   View Slide

5. 本日の登場人物
   佐々木淳志（ささきあつし）
   新サービス全体の
   アーキテクチャを考えたり、考えたり etc
   峯岸純也（みねぎしじゅんや）
   インフラチーム
   インフラ面の技術検討・構築 etc
   

   View Slide

6. 自己紹介
   弥生株式会社 開発本部 インフラチーム TechL （Technical Leader）
   峯岸 純也
    2020年1月に弥生にJoin
    インフラ経歴ゼロで入社させていただく
    弥生インフラ領域の何でも屋さんです
    過去のお仕事は、Java / C#メインで開発 etc
    プログラミングが嫌いで昔からインフラやりたかった
    自宅にCisco Catalyst 1000あります
    最近のお仕事内容
    AWSインフラ / セキュリティ / ガバナンス周り
    既存インフラ環境の運用保守（オンプレ・AWS・Azure）
    断捨離大臣、防衛大臣に任命される
    趣味
    犬、ウィスキーミニボトル集め
   アイコンは常に犬
   

   View Slide

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アカウントに
   なったら死人が出る
   

   View Slide

8. AWSアカウント数が現時点でも14倍に
    インフラチームの人数も14倍に・・・
    はならないので、これまでと異なる動きをしていかないとダメ
   新しいAWS環境は各製品サービスごとに
   AWSアカウントを持たせるマルチアカウント
   環境にしようと思っていますのでー
   それだとインフラ死んじゃいますって
   今までと同じく全部をインフラが担った場
   合はそうなるよね
   AWSはマルチアカウント環境向けに
   「ControlTower」っていうサービスがあるん
   だ
   そのサービスを使って製品サービスチー
   ムに渡したアカウントは管理してもらうよう
   にしよう
   了解です
   

   View Slide

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の設計・運用)
   セキュリティを維持・管理するための施策
   

   View Slide

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
    インフラ管理
    各チーム管理
    

    View Slide

11. Control Towerを使ってどうなっているか？
    Master Account (Control Tower / SSO)
    ステージング環境
    勉強用アカウント
    Audit (各ツール類) / LogArchive (ログ集約)
    開発環境
    本番環境
    Master Accountから見たAWS Organizationsの画面
    インフラ管理
    各チーム管理
    

    View Slide

12. Control Towerの嬉しいところ
     ガードレール機能
     自分で設定するとめんどくさい組織的な共通ルールを簡単に有効化できる
     ルートユーザとしてのアクションを許可しない
     CloudTrail証跡 / Config自動設定
     自動的に有効化
     ログをLogArchiveアカウントへ集約
    

    View Slide

13. Control Towerを使うと
    できるよー
    でも準備としてCFnでConfigやCloudTrailを
    自動的に有効化したり、Organizationsにア
    カウント作ったりを自分でやるの大変じゃ
    ない？
    自分で地道にポチポチやっても出来るし、
    ある程度の範囲を自動的にベストプラク
    ティスに沿って実行してくれるのが
    ControlTowerなんですね
    Yes！
    インフラチームを14倍の体制にしなくても、
    ControlTowerを使ったアカウント追加運用
    なら出来そうでしょ？
    確かにこれならやれそうです！
    ControlTowerを使ってアカウント発行や
    管理がしやすくなるのはなんとなくわか
    りました
    でもOrganizationsやCFnのStackSetsを使
    えば同じことできますよね？
    

    View Slide

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の設計・運用)
    セキュリティを維持・管理するための施策
    

    View Slide

15. IAMユーザからの脱却
    IAMユーザ止めましょう
    ControlTowerでSSOサービスとの連携があ
    るので、SSOやっちゃいましょうよ
    マルチアカウント環境にする前の運用で
    はIAMユーザの権限で大変な想いをして
    いるのでやるなら今ですね
    Azure ADもすでに運用されているようです
    し、連携はそこまで大変ではないかと
    やっちゃいましょう
    了解です
    各製品サービスのアカウントで、必要な
    人数分IAMユーザ作成していると大変に
    なっちゃいますよね
    

    View Slide

16. AWS Single Sign-On構成図
    Organizations
    Single Sign-On
    Azure AD
    プロビジョニング
    Master Account
    User Account
    権限・ユーザの配布
    ログイン用IAM
    リソース作成不要
     各人のIAMユーザ管理からの解放
     必要なIAMユーザは各チームへお任せ
    実際には
    権限が紐づいている
    AWSアカウントが表示される
    

    View Slide

17. デフォルトSSO権限セット問題
    どうしたのかな？
    AWSAdministratorAccess
    AWSPowerUserAccess
    AWSReadOnlyAccess
    の３つくらいしかありません ふむふむ
    これだと細かい権限、例えばあるS3バ
    ケットのみに絞るなどの要望がいっぱい
    きちゃいます
    インフラチームの体制を14倍にｗｗｗ
    大変です
    SSOを設定したらデフォルトの権限セット
    が！！？
    それは無理ｗｗｗ
    SSOの権限セットは最低限しか用意されて
    いない
    なので権限を作成できる権限を移譲できる
    か検討しよう
    

    View Slide

18. SSO権限セット作成の委任
    Organizations
    Master Account
    Other SSO User Account
    DelegatedOUAdmin
    権限セットの一時付与
     非常に多数になりがちなIAMポリシー管理からの解放
     必要な権限セット作成は各チームへお任せ
    役割分担
    ①各チームからインフラへ「DelegatedOUAdmin」付与依頼
    ②インフラで必要メンバーへ付与
    ③付与されたメンバーがSSO権限セットを作成
    ④作成したSSO権限セットを必要なメンバーへ付与する依頼をインフラへ
    ⑤インフラで必要メンバーへ作成されたSSO権限セットを付与
    

    View Slide

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の設計・運用)
    セキュリティを維持・管理するための施策
    

    View Slide

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
    

    View Slide

21. GuardDuty検知方法
    そうだね
    AWS独自基準で過去にアタックを仕掛けて
    きている有名なIPアドレスとかを検知してア
    ラートにしているからね
    既存商用サービスのほうだと、インフラ
    チームにメールが送付されるようになっ
    ているんですが、メール数が多くて見逃
    がしやすいかなと ふむふむ、いい案ある？
    EventBridgeとChatbotを使って、Slackに
    投稿しちゃうのはどうでしょうか？
    GuardDutyで検知したレベルにもよりま
    すけど、なるべく早く調査・対応したほう
    がいいですよね？
    いいんでない？
    チームが通常利用しているSlackに投稿さ
    れるのは嫌とかありそうだから、どのチャ
    ンネルが良いか取りまとめておくね
    

    View Slide

22. GuardDutyの検知
    Audit Account
    Amazon GuardDuty Amazon EventBridge AWS Chatbot Slack
     GuardDutyの検知 / 対応
     各チームに依頼出来る仕組みを提供出来た
     メールは1日の受信件数が多くて見逃がしやすいのでSlackへ
     全アカウントの検知内容を通知するチャンネル
     その他は各チームに合わせたSlackチャンネルへ通知
    GuardDutyのテスト投稿
    

    View Slide

23. AWSからの通知
    最終的には物理のマシンで動いているも
    のだからね
    老朽化したハードウェアに乗っているEC2
    インスタンスが運悪く当たったら、メンテナ
    ンスが連発しちゃうのかもね
    メールだと見逃しやすいんですよね。。
    誰かがキャッチすればいいんですけど
    メール＋αでの通知にしたいところだね
    AWS Helth Awareなるものがあるっぽい
    のでこいつ仕込んでみますね
    AWSからメールで、「メンテナンスするよ」
    とか通知が来るじゃないですか
    あれって、来るときはタイミングを図った
    ように連発で来るんですよね。。。
    

    View Slide

24. AWS Health Aware全体構成
    Master Account
    Amazon EventBridge
    Lambda
    Health
    AWS Secrets Manager Slack
    Amazon DynamoDB
    User Account
    

    View Slide

25. AWS Health Awareの効果
     AWSからの通知の見落とし予防
     メール & Personal Health Dashboardにも連絡は来ているが見落としがち
     障害情報をすばやくキャッチ
     Service Healthに関する情報も受け取るように設定
    以下のリージョンについてHealth関連の通知を受信するように設定
    東京リージョン、大阪リージョン、バージニアリージョン、グローバルリージョン
    ※全リージョンにすると通知が多くなりすぎるため
    

    View Slide

26. 検証用サブドメイン問題
    しつこい
    すみません
    今までDNS関連も全てインフラ管理に
    なっていたので・・・
    SSO権限セットと同じくDNSも移譲しちゃえ
    payroll.yayoi-kk.co.jpのNSレコードをAWS
    へ向けて
    xxx.payroll.yayoi-kk.co.jp
    のxxx部分を各チームにお任せしちゃう
    んですね？
    大変です
    各チームから検証用のサブドメインを、
    数十個程度必要という話が来てます
    インフラチームの体制を14倍にｗｗｗ
    そうそう
    DNSの要否だって各チームが一番詳しい
    から定期的な棚卸だってできるし
    yayoi-kk.co.jpは引き続きインフラ管理だけ
    ど、配下は各チーム任せでどうよ
    

    View Slide

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か
    ら発行してもらえる
    

    View Slide

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の設計・運用)
    セキュリティを維持・管理するための施策
    前半パート終了
    

    View Slide

29. 前半戦終わり
    

    View Slide

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の設計・運用)
    セキュリティを維持・管理するための施策
    

    View Slide

31. 何かあったとき問題
    何かインシデントが発生した際に
    LogArchiveアカウントから該当ログを提供
    するとかかな
    そうすると各種ログから何があったか？
    を確認出来るような仕組みも準備してお
    いたほうが良さそうですね
    SIEM on Amazon ESっていうのがあるみたい
    だよ
    SIEM on Amazon ES。。。
    調べてみます！
    インフラ管理のアカウントが限定的に
    なって、定型外の作業が発生するとした
    らなんでしょうかね・・・
    

    View Slide

32. SIEMとは
     Security Information and Event Management の略で、セキュリティ機
    器、ネットワーク機器、その他のあらゆる機器のデータを収集及び一
    元管理をして、相関分析によって脅威検出とインシデントレスポンス
    をサポートするためのソリューションです。
     Amazon OS は、オープンソースの Opensearchと Kibana を大規模か
    つ簡単でコスト効率の良い方法を使用してデプロイ、保護、実行する
    完全マネージド型サービスです。
    

    View Slide

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
    

    View Slide

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
    

    View Slide

35. SIEM VPC Flow logのダッシュボード
    

    View Slide

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に取り込まれな
    い
    

    View Slide

37. SIEM CloudTrailのダッシュボード
    

    View Slide

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
    

    View Slide

39. SIEM SecurityHubのダッシュボード
    

    View Slide

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
    

    View Slide

41. SIEM GuardDutyのダッシュボード
    

    View Slide

42. SIEM環境について
     注意点
     何かあった時の事象を解消してくれる万能ツールではない
     何かあった時にSIEMを検索して、該当の日時に怪しいログがあるとか、ここから調査を
    はじめればよいという位置づけ
     実際にはLogArchiveアカウントの生ログを見る必要が出てくる可能性もある
     その他のログ取り込み
     鋭意対応（検証）中
    

    View Slide

43. AWS利用料
    じゃあ、料金確認も各チームに任せられる
    ような仕組みを用意しちゃえ
    QuickSightで何か出来そうじゃないかな
    QuickSightのハンズオンしてもらって、
    さっそく作ってみました！
    いいね！
    色んなグラフのデザインとかあって、ハマる
    と沼になりそうだね
    画面でポチポチ簡単にグラフィカルな体
    裁変更が出来るので、延々とディテール
    に凝ってハマってしまいそうです・・・
    ほどほどにしましょう
    これまでだと、年間のAWS予算とか、都
    度どのサービスでどのくらいの料金が掛
    かっているか？とか問い合わせが多
    かったりします
    

    View Slide

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アプリケーション
    属性マッピング
    

    View Slide

45. 料金確認の内容
     日別の利用料とアカウント数 (週別、月別もあります)
    

    View Slide

46. 料金確認の内容
     日別のサービス別利用料 (週別、月別もあります)
    

    View Slide

47. 料金確認の内容
     日別のアカウント別利用料 (週別、月別もあります)
    

    View Slide

48. 料金確認の内容
     利用料割合 (サービス別 / アカウント別)
    

    View Slide

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
    

    View Slide

50. 料金確認の効果
     各チームで利用料を気にしてくれるようになった
     利用料割合から、「なぜ、こんな高いのか？」
     どうすればもっと安くなるか？
    これまでインフラチームから利用料を都度提供してきたが、これで都度各チー
    ムに確認、改善をしていただけるようなものを提供出来た
     今後はAWS予算も各チームで・・・やってもらえるかも？
    

    View Slide

51. AWSガバナンス
    もちのろん
    Security HubやInspector、AWS Configな
    ど、ある程度のルールに沿った検知
    サービスは有効化していますが、是正と
    なると、全体的にどれだけ守れているか
    とかそういったものを見れた方がいいで
    しょうか
    だれがやるかの部分は置いておくとして、
    どれだけ今守れているか、守れていない
    か、などの全体感は見れるようにしておい
    て、守れていないルールがどのアカウント
    で多いかとか、そういう確認は必要になる
    ね
    せっかくQuickSightを料金確認ツールとし
    て使えるようにしたので、この件も
    QuickSightでやりますか
    近いうちにマルチアカウント環境のガバ
    ナンス強化・是正活動も取り組むことに
    なりますよね
    

    View Slide

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
    

    View Slide

53. コンプライアンス全体
    

    View Slide

54. EC2情報
    

    View Slide

55. RDS情報
    

    View Slide

56. IAM情報
    

    View Slide

57. VPC情報
    

    View Slide

58. AWS Configダッシュボード化ワンポイント
    Master Account Audit Account
    Amazon Athena
    Amazon EventBridge AWS CodeBuild
    ControlTower Amazon EventBridge
     AWS Config用のAthenaテーブル更新自動化
     アカウントが追加されたり、削除されたりした場合に、アカウントID情報を
    Athenaのテーブルプロパティとして連携する必要がある
     EventBridgeでアカウント追加、削除のクロスアカウント連携
     CodeBuildでAthenaのテーブルを更新するクエリを生成・実行
    

    View Slide

59. AWS Configダッシュボードの効果
     コンプライアンス違反の全体感
     今後の是正活動時にコンプライアンス違反が減ってきているかを確認可能
     コスト管理
     高額なEC2 / RDSインスタンスタイプを使用していないか
     リスク管理
     不要なIAMユーザ / ロールがないか
    などをざっくり確認出来る
    

    View Slide

60. ここまでの振り返り
    

    View Slide

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
    構成図自動描画
    是正活動
    別
    件
    で
    忙
    し
    か
    っ
    た
    

    View Slide

62. 効果
    これまで マルチアカウント環境
    AWSアカウント作成 ー 最短30分
    IAMユーザ作成 依頼によるが1week程度かかる時も 最短5分
    SIEM ー AWS各種ログの調査
    GuardDuty メール Slackで関係各所へメンション
    AWS Health Aware メール Slackで関係各所へメンション
    料金確認QuickSight インフラチームにて予実を確認 各チームでコスト削減対応
    AWS Config QuickSight ー 今後の是正活動に活用予定
    Security違反自動検知v1 レビューで発見された危ないセキュリ
    ティ設定を連絡して対応
    自動検知
    （場合によっては）自動削除
    構成図自動描画 ー 全アカウントの構成図を日次で更新
    開発止めないスピーディーを！何かあれば調査を！検知もスピーディーに！
    利便性のあるツール類も！是正活動の視覚化！リスクコントロールもするぞ！
    結果盛りだくさんに・・・よく一人でやったなと自分を褒めたい（褒めて佐々木さん！ついでにお給料も上げてｗ）
    

    View Slide

63. インフラチームの新しい役割
     AWS100アカウント規模の環境を見据えた運用を考える
     2021年8月から2022年5月の10か月でアカウント数「58」、今後も増加が加速
    していくと思われる
     全てを担わない、けど全てを見て各チームで利用しやすいものを提
    案改善していく
     各アカウントの管理を各チームにお任せしているが、全てのアカウントの
    Admin権限をインフラチームも持っている
     何かあれば相談してもらって、実際に環境を見て回答することが可能
     誰かからこれをやろうと具体的な指示があるわけでもない、でも誰か
    がやらないといずれ大変な目に合う
    

    View Slide

64. 課題
     ある程度の検知の仕組みは出来てきた
     検知から是正の方法やルールを決めていく必要がある
     目指せ定型完全自動化！
     自動化への改善余地はまだまだある
     定型作業で工数を使わず、非定型に集中していく土台を
     構成管理
     100アカウントレベルの構成管理
     運用属人化
     徐々に引継ぎ
    妥協しない
    ここをがんばらないと自分、
    または引き継ぐ人が大変
    

    View Slide

65. Coming Soon
    <是正活動>
    AWS Trusted Advisorの内容を
    QuickSightダッシュボード化
    AWSからの改善提案を見える化 <構成管理>
    AWS構成図の最新化・維持管理の自動化
    <調査>
    膨大な量となるCloudTrailログをAthenaでパーティション化
    該当日、イベントがわかれば調査がスピーディーに
    AWS Security Hub AWS Lambda
    <リスク検知→自動復旧>
    フルオープンのセキュリティグループを設定してしまった
    場合に自動的に検知→削除
    

    View Slide

66. 識別 防御
    アイコンで何のサービスかわかるかな？
    検知
    調査
    自動化
    復旧
    and SIEM
    最後に
    

    View Slide

67. 安全で快適な
    マルチアカウント環境を
    目指して
    

    View Slide

68. View Slide

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/
    

    View Slide