Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
AWS導入から3年
AWSマルチアカウント管理で
変わらなかったこと変えていったこと
第二回 AWSマルチアカウント事例祭り
2021/02/09
ニフティ株式会社
基幹システムグループ
石川 貴之
ニフティ株式会社
基幹システムグループ N1!
石川 貴之 (Ishikawa Takayuki)
担当業務
 AWS/GCP管理
 Atlassian製品管理
 WEBサービスのバックエンド
好きなAWSのサービス
 CloudFormati...
会社紹介:ニフティ株式会社
3

本日話す内容について
4

本日話すこと
1. AWS導入前にしっかり決めておいてよかったこと
2. AWS導入後に段階的に整えていったことの詳細
3. なんでこれを採用していないのか
本日話さないこと
● 導入前に決めたことの詳細
○ すでに...
はじめに
管理方針や利用状況
5

AWS管理者としての方針
● 権限のあるアカウントにはAdministratorレベルの権限を与える(権限移譲)
● 本当にやってほしくないものだけ制限する(予防)
● 危険な行為や設定があったら伝える(検知&通知)
利用者の成長を見守る ゆる...
AWS利用状況
AWS導入から3年

システムやサービス、

環境ごとに分割

AWSアカウント 200個

AWS管理者 1人

AWS依頼対応 2人

AWS利用者 240人

7

AWS導入前に
決めておいて
よかったこと
2018年1月当時
8

導入前に決めたこと
● 気軽に分離や移行できないものや、絶対にカオスになるだろうものが対象
● 少なくとも 3~5年 は持つだろう構成にしたい
あとから変更しづらいものは先にしっかりした構成にしたい!
● 導入時は最低限、あとから良くしていく
...
あとから変更しづらいもの
AWSアカウントの粒度
● サービスやシステム単位で環境ごとに作成、一番の目的はコストの分割
● 参考:15分で教えるAWSの複数アカウント管理
コンソールログインアカウント
● Idpを使用した SAML2.0 ベー...
参考:アカウントの粒度と役割
11

参考:コンソールへのログインは
IDaaS経由
12

AWS導入後に
段階的に
整えていったこと
2018年~現在
13

本日はここについて導入時と現状どうなっているか話していきます。
AWS管理における運用改善
● AWSアカウント払い出しと初期設定
共通セキュリティ設定
● 情報取得・予防・検知・通知の 設定
● マルチアカウント情報の 集約
● 検知したアラ...
15

AWSアカウント払い出しと初期設定
AWS管理における運用改善
大量に作らないといけなくなる前に自動化していきました。
PoC段階:完全手動
● 全部GUIで実行して3時間はかかる
導入最初期:一部自動化&フロー実行は手動
● 1時間くらいかかる
● 実処理をセキュリティアカウントで実行
○ Lambda&...
AWSアカウント新規作成と初期設定の自動化
17

AWSアカウント新規作成と初期設定の自動化
セキュリティ設定を追加・変更したいときは
StackSetsのテンプレートの更新で行う
18

● アカウントエイリアス名の変更
● IAMパスワードポリシーの変更
● Idpの作成
● AWSCloudFormationStackSetExecutionRole の作成
● SSM Documentの作成
○ 同一名Documentがす...
● AWSルートユーザーのパスワード再発行
● ルートユーザーの物理MFAデバイスの登録
○ リモートワークと相性が悪い。。
手動のままのところ
20

21

情報取得・予防・検知・通知の設定
共通セキュリティ設定
導入初期のセキュリティ設定
● 情報取得
○ AWS CloudTrail
○ AWS Config
○ Personal Health Dashboard
● 予防
○ AWS Organizations SCPs
● 検知
○ AWS Cl...
● 情報取得
○ AWS CloudTrail
○ AWS Config
○ Personal Health Dashboard
● 予防
○ AWS Organizations SCPs
○ ルートユーザーのMFA
現在のセキュリティ設定
●...
ConfigRuleの導入
● 2019年8月に安くなったのが導入したきっかけ
● コンプラチェックはほとんどこれで行っている
● 最初は CIS / Control Tower をベースにして抜粋して追加
● その後 PCI DSS / AW...
25

マルチアカウント情報の集約
共通セキュリティ設定
導入初期:組織のアカウント情報の検知と集約・通知
26

導入中期:組織のアカウント情報の検知と集約・通知
27

現在:組織のアカウント情報の検知と集約・通知
28

なぜEventBusを使っているのか
リソースベースのポリシーに大量の
SNSからの権限を与えていくと20KB 制
限に引っかかる(70アカウント弱が限界)
Conditionに aws:PrincipalOrgID を使いたいが、Lambda...
このあたりの構成は知らずと似通ってくるのでしょうか。
AWS Configなどもっと詳しく知りたい!という方は、以下の資料を参考にしてください。
課題や効果はうちも一緒でしたので、本資料からは割愛して構成だけの紹介としています。
● ZOZOテ...
31

検知したアラートの通知
共通セキュリティ設定
アラートが多すぎて通知を見なくなることが習慣にならないようにする
● ConfigRule設定後、すぐに利用者に通知を送るのは控えた(全体で 1000近い非準拠があった)
● すべてのConfigRule内容や非準拠要素を見て、 本当に必要なル...
通知例:CloudWatch Alarm
なるべくメッセージ本文に
アラートの内容を日本語で記載する
33

アカウントIDだけでなくエイリアス名も記
載する
通知例:GuardDuty
GuardDutyのように通知パターンが
多い場合は定型文言で通知
本当は日本語でしっかり書きたい。。
34

通知例:ConfigRule
35

非準拠になったときのアラート以外に加え、定期
的に非準拠項目を伝える
ドキュメントサンプル
36

なにをチェックしているか 本来どうなっているべきか
非準拠の場合の危険性
対処する場合の方法など
● 対応レベルが高かった検知項目は Jira の issue にして解決まで管理する
● ConfigRuleで条件次第で必ず非準拠になる項目の対応
● SIEM on Amazon Elasticsearch Service の利用
これから...
なぜなにコーナー
検証したが
採用しなかったものなど
38

Control Towerに移行しないの?
● 運用管理がそこそこ変わり、その工数に見合うリターンが今はないため
● 既存Organization対応と既存アカウントの追加ができるようになったので、移行できる最低条件は整って
きたかなと思います...
なんでOU追加で自動で動くCloudFormation StackSets使っていないの?
● OU移動で消されたくないものと消してもいいものを分類
● 複数StackSetsあると実行順番が考慮されないため 1つのStackSetにまとめる
...
なんでSecurityHub使っていないの?
● SecurityHubで全部のConfigRuleを管理できないから
● 設定保護しようとしたら SecurityHub自体を自由に利用者側で使いにくくなるから
● しかしいいところも多いため割...
いまはどれも使わず CDK + CloudFormation StackSets で管理していますが、
私も悩んでいます。
結局ConfigRuleはどこで管理するのがいいの?
ConfigRuleどこで管理するか問題

Organizatio...
Masterアカウントのコストエクスプローラーだけ使える権限設定
● IDaaSから請求アカウントで費用だけ確認できる Roleで入れるようにした
● 費用確認の習慣付けや自社サービス間での費用比較が気軽にできる
導入してみて特に良かったものは...
AWS Budgets Alert
● 固定額で入れておいて自由に金額を変更してもらう想定で入れていた
● 現場的には日次で月額費用を Slack通知されるものに需要があった
○ 使った分だけというのが怖いので日次で総額と増分が分かる方が嬉しい...
まとめ
45

● 利用者の成長を阻害しないセキュリティを敷いている
● あとから変更しにくい要素はAWS導入前にしっかり構成を決めた、
3年経った今でも困らず運用で
きている(アカウントの粒度、コンソールログインアカウント、マルチアカウントへの設定配布方法)...
Copyright © NIFTY Corporation All Rights Reserved. 

Upcoming SlideShare
Loading in …5
×

of

AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 1 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 2 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 3 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 4 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 5 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 6 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 7 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 8 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 9 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 10 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 11 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 12 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 13 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 14 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 15 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 16 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 17 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 18 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 19 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 20 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 21 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 22 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 23 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 24 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 25 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 26 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 27 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 28 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 29 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 30 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 31 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 32 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 33 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 34 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 35 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 36 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 37 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 38 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 39 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 40 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 41 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 42 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 43 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 44 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 45 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 46 AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと Slide 47
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

2 Likes

Share

Download to read offline

AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと

Download to read offline

2021/02/09 第二回 AWSマルチアカウント事例祭り

Related Books

Free with a 30 day trial from Scribd

See all

AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと

  1. 1. AWS導入から3年 AWSマルチアカウント管理で 変わらなかったこと変えていったこと 第二回 AWSマルチアカウント事例祭り 2021/02/09 ニフティ株式会社 基幹システムグループ 石川 貴之
  2. 2. ニフティ株式会社 基幹システムグループ N1! 石川 貴之 (Ishikawa Takayuki) 担当業務  AWS/GCP管理  Atlassian製品管理  WEBサービスのバックエンド 好きなAWSのサービス  CloudFormation, Athena, Organizations 自己紹介 登壇するならカッコつくか と思ったので年末に 2つ資格取ってきました 2

  3. 3. 会社紹介:ニフティ株式会社 3

  4. 4. 本日話す内容について 4
 本日話すこと 1. AWS導入前にしっかり決めておいてよかったこと 2. AWS導入後に段階的に整えていったことの詳細 3. なんでこれを採用していないのか 本日話さないこと ● 導入前に決めたことの詳細 ○ すでに公開している資料の紹介のみ ● AWSの機能自体についての説明
  5. 5. はじめに 管理方針や利用状況 5

  6. 6. AWS管理者としての方針 ● 権限のあるアカウントにはAdministratorレベルの権限を与える(権限移譲) ● 本当にやってほしくないものだけ制限する(予防) ● 危険な行為や設定があったら伝える(検知&通知) 利用者の成長を見守る ゆるやかなセキュリティを敷く ● AWS管理においては なるべくAWSの機能だけで完結させる ● なるべく自動化する AWSの進化に期待しつつ推奨に沿う 6

  7. 7. AWS利用状況 AWS導入から3年
 システムやサービス、
 環境ごとに分割
 AWSアカウント 200個
 AWS管理者 1人
 AWS依頼対応 2人
 AWS利用者 240人
 7

  8. 8. AWS導入前に 決めておいて よかったこと 2018年1月当時 8

  9. 9. 導入前に決めたこと ● 気軽に分離や移行できないものや、絶対にカオスになるだろうものが対象 ● 少なくとも 3~5年 は持つだろう構成にしたい あとから変更しづらいものは先にしっかりした構成にしたい! ● 導入時は最低限、あとから良くしていく ● 最初は速度を優先する あとから変更しやすいものは段階的に整えていく! 9

  10. 10. あとから変更しづらいもの AWSアカウントの粒度 ● サービスやシステム単位で環境ごとに作成、一番の目的はコストの分割 ● 参考:15分で教えるAWSの複数アカウント管理 コンソールログインアカウント ● Idpを使用した SAML2.0 ベースのフェデレーション( AWS SSOはこのときまだGA前) ● 参考:IDaaSを用いた複数AWSアカウントのログインで良かったこと困ったこと マルチアカウントへ設定配布 ● CloudFormation StackSetsに決め打ち ● Lambda&AssumeRoleも併用 10

  11. 11. 参考:アカウントの粒度と役割 11

  12. 12. 参考:コンソールへのログインは IDaaS経由 12

  13. 13. AWS導入後に 段階的に 整えていったこと 2018年~現在 13

  14. 14. 本日はここについて導入時と現状どうなっているか話していきます。 AWS管理における運用改善 ● AWSアカウント払い出しと初期設定 共通セキュリティ設定 ● 情報取得・予防・検知・通知の 設定 ● マルチアカウント情報の 集約 ● 検知したアラートの通知 あとから変更しやすいもの 14

  15. 15. 15
 AWSアカウント払い出しと初期設定 AWS管理における運用改善
  16. 16. 大量に作らないといけなくなる前に自動化していきました。 PoC段階:完全手動 ● 全部GUIで実行して3時間はかかる 導入最初期:一部自動化&フロー実行は手動 ● 1時間くらいかかる ● 実処理をセキュリティアカウントで実行 ○ Lambda&CloudFormation StackSets 導入から1年後:ほぼ自動化 ● 新規アカウント情報を S3に投げて20分待つとできてる ● ワークフロー部分はマスターアカウントに設定(権限分離のつもりが少々歪だった) ○ StepFunction (Lambda&CloudFormation StackSets) AWSアカウント払い出しと初期設定 16

  17. 17. AWSアカウント新規作成と初期設定の自動化 17

  18. 18. AWSアカウント新規作成と初期設定の自動化 セキュリティ設定を追加・変更したいときは StackSetsのテンプレートの更新で行う 18

  19. 19. ● アカウントエイリアス名の変更 ● IAMパスワードポリシーの変更 ● Idpの作成 ● AWSCloudFormationStackSetExecutionRole の作成 ● SSM Documentの作成 ○ 同一名DocumentがすでにあるとCFnでは対処できないため ● GuardDutyの有効化と招待 ○ 今はOrganizationsの機能で自動有効化 ● OUの変更 ○ 初期設定が終わったら SCPが効いているOUへ移動 Lambda+AssumeRoleで設定を入れているところ 19

  20. 20. ● AWSルートユーザーのパスワード再発行 ● ルートユーザーの物理MFAデバイスの登録 ○ リモートワークと相性が悪い。。 手動のままのところ 20

  21. 21. 21
 情報取得・予防・検知・通知の設定 共通セキュリティ設定
  22. 22. 導入初期のセキュリティ設定 ● 情報取得 ○ AWS CloudTrail ○ AWS Config ○ Personal Health Dashboard ● 予防 ○ AWS Organizations SCPs ● 検知 ○ AWS CloudWatch Events ○ Amazon GuardDuty ● 通知 ○ AWS CloudWatch Alarm リフト&シフトがメインだったため、サービス環境というよりも AWS独特のもの(アカウントや IAM)を守ることを主として考えていた 22

  23. 23. ● 情報取得 ○ AWS CloudTrail ○ AWS Config ○ Personal Health Dashboard ● 予防 ○ AWS Organizations SCPs ○ ルートユーザーのMFA 現在のセキュリティ設定 ● 検知 ○ AWS CloudWatch Events ○ Amazon GuardDuty (+ S3保護) ○ AWS ConfigRule ○ IAM Access Analyzer ● 通知 ○ AWS CloudWatch Alarm State Change ○ ConfigRule Compliance Change ○ Amazon GuardDuty Findings ○ Health Event このほかにもAWSアカウント個別に入れている設定もあります (記載したのは共通で入れているもの) 23

  24. 24. ConfigRuleの導入 ● 2019年8月に安くなったのが導入したきっかけ ● コンプラチェックはほとんどこれで行っている ● 最初は CIS / Control Tower をベースにして抜粋して追加 ● その後 PCI DSS / AWS Foundational Security Best Practices から抜粋して追加 ● データロス事故が起きたのでバックアップ系のチェックも追加 検知したものを利用者向けに通知 ● 管理者向けには通知を送っていたが、利用者向けにも Slackで通知を送るようにした(後述) ● 情報の集約には Organizations と EventBus を利用 SCPによる共通設定内容の保護 ● 2019年3月にConditionやワイルドカードに対応、入れた設定の保護が簡単になった 追加要素ピックアップ 24

  25. 25. 25
 マルチアカウント情報の集約 共通セキュリティ設定
  26. 26. 導入初期:組織のアカウント情報の検知と集約・通知 26

  27. 27. 導入中期:組織のアカウント情報の検知と集約・通知 27

  28. 28. 現在:組織のアカウント情報の検知と集約・通知 28

  29. 29. なぜEventBusを使っているのか リソースベースのポリシーに大量の SNSからの権限を与えていくと20KB 制 限に引っかかる(70アカウント弱が限界) Conditionに aws:PrincipalOrgID を使いたいが、Lambdaのリソースベース ポリシーでは使えない SNSアクセスポリシーなら Conditionに aws:PrincipalOrgID を使えるが、 CloudWatch Alarmからのアクセスに関してはaws:PrincipalOrgID が機能 しない仕様 参考:Unable to get aws:PrincipalOrgID to work with creating subscription filter EventBusならConditionに aws:PrincipalOrgID を問題なく使える EventBusのターゲットはクロスアカウントには対応しているが、 クロスリージョンには未対応 なので一旦それぞれのリージョンの 集約アカウントに集めて SNSで通知用Lambdaに送る 参考:AWS アカウント間のイベントの送受信 29

  30. 30. このあたりの構成は知らずと似通ってくるのでしょうか。 AWS Configなどもっと詳しく知りたい!という方は、以下の資料を参考にしてください。 課題や効果はうちも一緒でしたので、本資料からは割愛して構成だけの紹介としています。 ● ZOZOテクノロジーズ様 ○ AWS Configを用いたマルチアカウント・マルチリージョンでのリソース把握とコンプライアンス維持への取り組みにつ いて / Using AWS Config for Multi-Account, Multi-Region Resource Understanding and Maintaining Compliance ● アカツキ様 ○ 6000個 セキュリティポリシーを自動監査!アカツキ流、AWSセキュリティ 取り組み紹介 似たような構成をしています 30

  31. 31. 31
 検知したアラートの通知 共通セキュリティ設定
  32. 32. アラートが多すぎて通知を見なくなることが習慣にならないようにする ● ConfigRule設定後、すぐに利用者に通知を送るのは控えた(全体で 1000近い非準拠があった) ● すべてのConfigRule内容や非準拠要素を見て、 本当に必要なルールなのか再選定 ● 自社独自の対応レベルをConfigRuleごとに定義、危険性の高いルールのみ通知対象とした 危険性と対処法が書かれたドキュメントを用意する ● 対応レベルはざっくりなので、利用者側で優先度を決められる情報を提供する(まだ一部) ● サイバーエージェント様の通知例を目指した ○ 参考:「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み @AWS Summit Tokyo 2018 利用者へ通知する上で気をつけたこと 32

  33. 33. 通知例:CloudWatch Alarm なるべくメッセージ本文に アラートの内容を日本語で記載する 33
 アカウントIDだけでなくエイリアス名も記 載する
  34. 34. 通知例:GuardDuty GuardDutyのように通知パターンが 多い場合は定型文言で通知 本当は日本語でしっかり書きたい。。 34

  35. 35. 通知例:ConfigRule 35
 非準拠になったときのアラート以外に加え、定期 的に非準拠項目を伝える
  36. 36. ドキュメントサンプル 36
 なにをチェックしているか 本来どうなっているべきか 非準拠の場合の危険性 対処する場合の方法など
  37. 37. ● 対応レベルが高かった検知項目は Jira の issue にして解決まで管理する ● ConfigRuleで条件次第で必ず非準拠になる項目の対応 ● SIEM on Amazon Elasticsearch Service の利用 これからやりたいこと 37

  38. 38. なぜなにコーナー 検証したが 採用しなかったものなど 38

  39. 39. Control Towerに移行しないの? ● 運用管理がそこそこ変わり、その工数に見合うリターンが今はないため ● 既存Organization対応と既存アカウントの追加ができるようになったので、移行できる最低条件は整って きたかなと思います ○ 参考:Launch AWS Control Tower in an Existing Organization ○ 参考:既存のAWSアカウントを AWS Control Tower へ登録する | Amazon Web Services ● 自前Control Towerみたいな今の構成を維持・改善していくよりも、 Control Towerに乗っかった方が楽 だったり、Control Tower特有の利点が大きくなったら移行を検討すると思います Organizations周り 39

  40. 40. なんでOU追加で自動で動くCloudFormation StackSets使っていないの? ● OU移動で消されたくないものと消してもいいものを分類 ● 複数StackSetsあると実行順番が考慮されないため 1つのStackSetにまとめる ● これら結構しんどいため なんでTerraform使ってないの? ● CFnで管理していた方が新機能などで恩恵受けられる可能性が高いかなという期待からです ● CDK使い出してからは辛さが減りましたし使い続けています ● Visional様がOrganizationsとTerraformをいいバランスで使って管理されていて、 これもいいなと思ってます。簡単には真似できそうにないですが。。 ○ 参考:100を超えるAWSアカウント運用におけるガードレール構築事例 ○ 参考:CUS-06:大規模な組織変遷と100以上のAWSアカウントの横断的セキュリティガードレール運用について デプロイ周り 40

  41. 41. なんでSecurityHub使っていないの? ● SecurityHubで全部のConfigRuleを管理できないから ● 設定保護しようとしたら SecurityHub自体を自由に利用者側で使いにくくなるから ● しかしいいところも多いため割り切って使おうかと何度も考えました ○ StandardsのON/OFF、Standardsごとのリソースの例外設定 ○ Organizationによる有効化と集約、集約アカウントからの自動修復 なんでOrganizationConfigRule使っていないの? ● 修復を入れることができないので、結局2カ所で管理することになるから ● デプロイと設定の保護はすでにできていたため利点があまりなかった なんで適合パック使っていないの? ● ConfigRuleは修復も含めCDKで管理しており扱いに困っていなかったため ● Control Tower使い出したら使うかもしれません。 ○ 参考:AWS Config 適合パックを使用したAWS Control Tower発見的ガードレールの実装 | Amazon Web Services ConfigRule周り 41

  42. 42. いまはどれも使わず CDK + CloudFormation StackSets で管理していますが、 私も悩んでいます。 結局ConfigRuleはどこで管理するのがいいの? ConfigRuleどこで管理するか問題
 OrganizationConfigRule, SecuriyHub, 適合パック, Control Towerのガードレール と 
 管理できる場所が多々あり、それぞれに良し悪しがあります。 
 
 どれを選ぶか併用するかは、組織ごとになにを重視するかで決まると思います。 
 このあたりAWS側のマイルストーンがわかれば舵切りがしやすいんですが。。 
 42

  43. 43. Masterアカウントのコストエクスプローラーだけ使える権限設定 ● IDaaSから請求アカウントで費用だけ確認できる Roleで入れるようにした ● 費用確認の習慣付けや自社サービス間での費用比較が気軽にできる 導入してみて特に良かったものはある? 43

  44. 44. AWS Budgets Alert ● 固定額で入れておいて自由に金額を変更してもらう想定で入れていた ● 現場的には日次で月額費用を Slack通知されるものに需要があった ○ 使った分だけというのが怖いので日次で総額と増分が分かる方が嬉しい Auto Tag ● リソース作成時に自動で作成者と時間を Tagに記述するLambda ● 主に開発環境で正体不明なリソースをなくしたかった ● CloudFormationは大丈夫だがTerraformと相性が悪いので削除 ○ IaCが一般的に使われているなら正体不明リソースはそんなに増えないだろうし 導入してみて失敗だったものはある? 44

  45. 45. まとめ 45

  46. 46. ● 利用者の成長を阻害しないセキュリティを敷いている ● あとから変更しにくい要素はAWS導入前にしっかり構成を決めた、 3年経った今でも困らず運用で きている(アカウントの粒度、コンソールログインアカウント、マルチアカウントへの設定配布方法) ● 時間のかかる新規アカウントの初期設定は自動化、無理のない運用に改善していった ● はじめは速度優先、利用状況に合わせて必要なセキュリティを増やしていった ○ すぐに設定できてコストに見合うものを最初に導入 ○ 推奨されたものや、ヒヤリハット・障害の再発防止策として追加導入 ○ 通知は利用者視点を持って量と内容を考える ● AWSの新機能は都度検証するが、ROIを考えて導入や移行を決めていく まとめ 46

  47. 47. Copyright © NIFTY Corporation All Rights Reserved. 

  • MadokaItamoto

    Feb. 12, 2021
  • syuichitsuji

    Feb. 11, 2021

2021/02/09 第二回 AWSマルチアカウント事例祭り

Views

Total views

2,321

On Slideshare

0

From embeds

0

Number of embeds

1,632

Actions

Downloads

19

Shares

0

Comments

0

Likes

2

×