AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと
•
2 likes•3,381 views
2021/02/09 第二回 AWSマルチアカウント事例祭り
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと
Similar to AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと (20)
Recently uploaded
Recently uploaded (7)
AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと
- 1. AWS導入から3年 AWSマルチアカウント管理で 変わらなかったこと変えていったこと 第二回 AWSマルチアカウント事例祭り 2021/02/09 ニフティ株式会社 基幹システムグループ 石川 貴之
- 2. ニフティ株式会社 基幹システムグループ N1! 石川 貴之 (Ishikawa Takayuki) 担当業務 AWS/GCP管理 Atlassian製品管理 WEBサービスのバックエンド 好きなAWSのサービス CloudFormation, Athena, Organizations 自己紹介 登壇するならカッコつくか と思ったので年末に ２つ資格取ってきました 2
- 4. 本日話す内容について 4 本日話すこと 1. AWS導入前にしっかり決めておいてよかったこと 2. AWS導入後に段階的に整えていったことの詳細 3. なんでこれを採用していないのか 本日話さないこと ● 導入前に決めたことの詳細 ○ すでに公開している資料の紹介のみ ● AWSの機能自体についての説明
- 6. AWS管理者としての方針 ● 権限のあるアカウントにはAdministratorレベルの権限を与える（権限移譲） ● 本当にやってほしくないものだけ制限する（予防） ● 危険な行為や設定があったら伝える（検知＆通知） 利用者の成長を見守る ゆるやかなセキュリティを敷く ● AWS管理においては なるべくAWSの機能だけで完結させる ● なるべく自動化する AWSの進化に期待しつつ推奨に沿う 6
- 7. AWS利用状況 AWS導入から3年 システムやサービス、 環境ごとに分割 AWSアカウント 200個 AWS管理者 1人 AWS依頼対応 2人 AWS利用者 240人 7
- 9. 導入前に決めたこと ● 気軽に分離や移行できないものや、絶対にカオスになるだろうものが対象 ● 少なくとも 3～5年 は持つだろう構成にしたい あとから変更しづらいものは先にしっかりした構成にしたい！ ● 導入時は最低限、あとから良くしていく ● 最初は速度を優先する あとから変更しやすいものは段階的に整えていく！ 9
- 10. あとから変更しづらいもの AWSアカウントの粒度 ● サービスやシステム単位で環境ごとに作成、一番の目的はコストの分割 ● 参考：15分で教えるAWSの複数アカウント管理 コンソールログインアカウント ● Idpを使用した SAML2.0 ベースのフェデレーション（ AWS SSOはこのときまだGA前） ● 参考：IDaaSを用いた複数AWSアカウントのログインで良かったこと困ったこと マルチアカウントへ設定配布 ● CloudFormation StackSetsに決め打ち ● Lambda＆AssumeRoleも併用 10
- 14. 本日はここについて導入時と現状どうなっているか話していきます。 AWS管理における運用改善 ● AWSアカウント払い出しと初期設定 共通セキュリティ設定 ● 情報取得・予防・検知・通知の 設定 ● マルチアカウント情報の 集約 ● 検知したアラートの通知 あとから変更しやすいもの 14
- 16. 大量に作らないといけなくなる前に自動化していきました。 PoC段階：完全手動 ● 全部GUIで実行して3時間はかかる 導入最初期：一部自動化＆フロー実行は手動 ● 1時間くらいかかる ● 実処理をセキュリティアカウントで実行 ○ Lambda＆CloudFormation StackSets 導入から1年後：ほぼ自動化 ● 新規アカウント情報を S3に投げて20分待つとできてる ● ワークフロー部分はマスターアカウントに設定（権限分離のつもりが少々歪だった） ○ StepFunction (Lambda＆CloudFormation StackSets) AWSアカウント払い出しと初期設定 16
- 19. ● アカウントエイリアス名の変更 ● IAMパスワードポリシーの変更 ● Idpの作成 ● AWSCloudFormationStackSetExecutionRole の作成 ● SSM Documentの作成 ○ 同一名DocumentがすでにあるとCFnでは対処できないため ● GuardDutyの有効化と招待 ○ 今はOrganizationsの機能で自動有効化 ● OUの変更 ○ 初期設定が終わったら SCPが効いているOUへ移動 Lambda+AssumeRoleで設定を入れているところ 19
- 20. ● AWSルートユーザーのパスワード再発行 ● ルートユーザーの物理MFAデバイスの登録 ○ リモートワークと相性が悪い。。 手動のままのところ 20
- 22. 導入初期のセキュリティ設定 ● 情報取得 ○ AWS CloudTrail ○ AWS Config ○ Personal Health Dashboard ● 予防 ○ AWS Organizations SCPs ● 検知 ○ AWS CloudWatch Events ○ Amazon GuardDuty ● 通知 ○ AWS CloudWatch Alarm リフト＆シフトがメインだったため、サービス環境というよりも AWS独特のもの（アカウントや IAM）を守ることを主として考えていた 22
- 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. ConfigRuleの導入 ● 2019年8月に安くなったのが導入したきっかけ ● コンプラチェックはほとんどこれで行っている ● 最初は CIS / Control Tower をベースにして抜粋して追加 ● その後 PCI DSS / AWS Foundational Security Best Practices から抜粋して追加 ● データロス事故が起きたのでバックアップ系のチェックも追加 検知したものを利用者向けに通知 ● 管理者向けには通知を送っていたが、利用者向けにも Slackで通知を送るようにした（後述） ● 情報の集約には Organizations と EventBus を利用 SCPによる共通設定内容の保護 ● 2019年3月にConditionやワイルドカードに対応、入れた設定の保護が簡単になった 追加要素ピックアップ 24
- 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. このあたりの構成は知らずと似通ってくるのでしょうか。 AWS Configなどもっと詳しく知りたい！という方は、以下の資料を参考にしてください。 課題や効果はうちも一緒でしたので、本資料からは割愛して構成だけの紹介としています。 ● ZOZOテクノロジーズ様 ○ AWS Configを用いたマルチアカウント・マルチリージョンでのリソース把握とコンプライアンス維持への取り組みにつ いて / Using AWS Config for Multi-Account, Multi-Region Resource Understanding and Maintaining Compliance ● アカツキ様 ○ 6000個 セキュリティポリシーを自動監査！アカツキ流、AWSセキュリティ 取り組み紹介 似たような構成をしています 30
- 32. アラートが多すぎて通知を見なくなることが習慣にならないようにする ● ConfigRule設定後、すぐに利用者に通知を送るのは控えた（全体で 1000近い非準拠があった） ● すべてのConfigRule内容や非準拠要素を見て、 本当に必要なルールなのか再選定 ● 自社独自の対応レベルをConfigRuleごとに定義、危険性の高いルールのみ通知対象とした 危険性と対処法が書かれたドキュメントを用意する ● 対応レベルはざっくりなので、利用者側で優先度を決められる情報を提供する（まだ一部） ● サイバーエージェント様の通知例を目指した ○ 参考：「これ危ない設定じゃないでしょうか」とヒアリングするための仕組み @AWS Summit Tokyo 2018 利用者へ通知する上で気をつけたこと 32
- 37. ● 対応レベルが高かった検知項目は Jira の issue にして解決まで管理する ● ConfigRuleで条件次第で必ず非準拠になる項目の対応 ● SIEM on Amazon Elasticsearch Service の利用 これからやりたいこと 37
- 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. なんでOU追加で自動で動くCloudFormation StackSets使っていないの？ ● OU移動で消されたくないものと消してもいいものを分類 ● 複数StackSetsあると実行順番が考慮されないため 1つのStackSetにまとめる ● これら結構しんどいため なんでTerraform使ってないの？ ● CFnで管理していた方が新機能などで恩恵受けられる可能性が高いかなという期待からです ● CDK使い出してからは辛さが減りましたし使い続けています ● Visional様がOrganizationsとTerraformをいいバランスで使って管理されていて、 これもいいなと思ってます。簡単には真似できそうにないですが。。 ○ 参考：100を超えるAWSアカウント運用におけるガードレール構築事例 ○ 参考：CUS-06：大規模な組織変遷と100以上のAWSアカウントの横断的セキュリティガードレール運用について デプロイ周り 40
- 41. なんでSecurityHub使っていないの？ ● SecurityHubで全部のConfigRuleを管理できないから ● 設定保護しようとしたら SecurityHub自体を自由に利用者側で使いにくくなるから ● しかしいいところも多いため割り切って使おうかと何度も考えました ○ StandardsのON/OFF、Standardsごとのリソースの例外設定 ○ Organizationによる有効化と集約、集約アカウントからの自動修復 なんでOrganizationConfigRule使っていないの？ ● 修復を入れることができないので、結局２カ所で管理することになるから ● デプロイと設定の保護はすでにできていたため利点があまりなかった なんで適合パック使っていないの？ ● ConfigRuleは修復も含めCDKで管理しており扱いに困っていなかったため ● Control Tower使い出したら使うかもしれません。 ○ 参考：AWS Config 適合パックを使用したAWS Control Tower発見的ガードレールの実装 | Amazon Web Services ConfigRule周り 41
- 42. いまはどれも使わず CDK + CloudFormation StackSets で管理していますが、 私も悩んでいます。 結局ConfigRuleはどこで管理するのがいいの？ ConfigRuleどこで管理するか問題 OrganizationConfigRule, SecuriyHub, 適合パック, Control Towerのガードレール と 管理できる場所が多々あり、それぞれに良し悪しがあります。 どれを選ぶか併用するかは、組織ごとになにを重視するかで決まると思います。 このあたりAWS側のマイルストーンがわかれば舵切りがしやすいんですが。。 42
- 43. Masterアカウントのコストエクスプローラーだけ使える権限設定 ● IDaaSから請求アカウントで費用だけ確認できる Roleで入れるようにした ● 費用確認の習慣付けや自社サービス間での費用比較が気軽にできる 導入してみて特に良かったものはある？ 43
- 44. AWS Budgets Alert ● 固定額で入れておいて自由に金額を変更してもらう想定で入れていた ● 現場的には日次で月額費用を Slack通知されるものに需要があった ○ 使った分だけというのが怖いので日次で総額と増分が分かる方が嬉しい Auto Tag ● リソース作成時に自動で作成者と時間を Tagに記述するLambda ● 主に開発環境で正体不明なリソースをなくしたかった ● CloudFormationは大丈夫だがTerraformと相性が悪いので削除 ○ IaCが一般的に使われているなら正体不明リソースはそんなに増えないだろうし 導入してみて失敗だったものはある？ 44
- 45. まとめ 45
- 46. ● 利用者の成長を阻害しないセキュリティを敷いている ● あとから変更しにくい要素はAWS導入前にしっかり構成を決めた、 3年経った今でも困らず運用で きている（アカウントの粒度、コンソールログインアカウント、マルチアカウントへの設定配布方法） ● 時間のかかる新規アカウントの初期設定は自動化、無理のない運用に改善していった ● はじめは速度優先、利用状況に合わせて必要なセキュリティを増やしていった ○ すぐに設定できてコストに見合うものを最初に導入 ○ 推奨されたものや、ヒヤリハット・障害の再発防止策として追加導入 ○ 通知は利用者視点を持って量と内容を考える ● AWSの新機能は都度検証するが、ROIを考えて導入や移行を決めていく まとめ 46
- 47. Copyright © NIFTY Corporation All Rights Reserved.