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