昨年9月以来の「AWSマルチアカウント事例祭り」です。
前回の受講メモは こちら
マルチアカウントでのIAMユーザ把握と可視化 IAMユーザー棚卸しへの取り組み
講師： 株式会社ZOZOテクノロジーズ CTO室 / 技術開発本部 SRE部 テックリード 光野 達朗(@kotatsu360)さん
- 組織全体の AWS に関する話
- マルチアカウントでも IAM ユーザーの棚卸しはできる
- IAM ユーザーを把握、Slack へ通知
- Azure AD で SSO
- IAM ユーザーの問題
- どうやって把握するか？
- コンソールのパスワードをもたないユーザーを取りたい
- 「認証情報レポート」を活用
- IAM ユーザーと認証情報のステータス一覧を CSV で取得できる
- 取得データの加工するために活躍した AWS サービス
- 今後
- ホワイトリスト管理
- IAM ユーザー作成を検知
- まとめ
- AWS 全体で IAM ユーザーを最小限にしたかった
- 認証情報レポートでアカウント単位の IAM ユーザーを取得
- CFn StackSets / Athena / QuickSight で可視化
QA
- IAMユーザを作らざるを得ないケースもあるかと思いますが、どのようにコントロールされていますか？
- だいたいどれくらいのIAMユーザがいました？
- 3XX ぐらいいた
- SOO を使いだして 100 を切るぐらいになった
- 1割の 30 を目標に目指すは 0
- IAMの最終利用日時だけではIAMの必要性判断には情報不足すると思いますが、IAMの利用状況の把握は結局1つ1つ確認する以外に何かあるのでしょうか？まずは使っていないIAMを削除するという方針でしょうか？
- アクセストークンの有無と最終利用日を目安にする
- SSO 利用で不要になったユーザーも多い
- ログインのパスワードを無効化して調査をした
- IAM ユーザーを消すことで負の運用作用になると本末転倒なので注意した
- SSO の権限セット
- Admin と PowerUser と ReadOnly とわける
- ＋ Billing があれば対応
- 認証情報レポートの情報そのものはAPIで取得できない?
- アカウントIDからアカウント名を取得する際の「organizations:DescribeAccount」は、メンバーアカウントから実行してますでしょうか？
- Yes
- Lambda から Organizations の API を叩いて取得
- Organization 側に assume role を作って権限移譲して動くようにしている
- IAMユーザーを使用している理由で多かった理由を知りたいです。
- マネコンにログインするため
- 東京リージョンに AWS SSO が来る前はどのような運用をしていましたか？
- はじめからバージニアで運用しているが特に問題ない
AWS導入から3年 AWSマルチアカウント管理で変わらなかったこと変えていったこと
講師： ニフティ株式会社 基幹システムグループ 石川 貴之さん
www.slideshare.net
- 管理者方針
- Admin 権限をあたえる（移譲）
- 本当にやってほしくないものだけ禁止（予防）
- 危険な行為や設定は通知（検知＆通知）
- 導入前にきめたもの
- 運用を始めたあとにセキュリティの追加要素
- ConfigRule を値下げのタイミングで追加
- 通知系
- アラートが多すぎて通知を見なくならないように注意
- 通知に危険性と対処法のリンクを追加
- root の MFA
- まとめ
- 利用者の成長を阻害しないセキュリティ
- はじめは速度優先、利用状況にあわせてセキュリティ追加
- ROI を考えて導入や移行を決める
QA
- 二フクラとAWSをどう使い分けてるか知りたいです
- 得分野が違う
- IO 使うものはニフクラが安いのでそちらを使う
- 100を超えるAWSアカウントは、結局どのような粒度で作成されているのでしょうか？
- 1サービス1システムに開発と本番は作る
- サービス単位で分けるかは担当者に任せる
- セキュリティ通知されたものに対して実際にアクションされている割合はどんな感じでしょうか？
- 測っていない
- 緊急性の高いものはイシュー管理
- GuardDutyの結果もリスクの高いものだけ基幹チーム側でケアされてる感じでしょうか？その他は利用部門側に任せる感じでしょうか？
- レベルが GuardDuty できまっているので High だけケア
- controltowerはlamding zoneを有効化していないだけでしょうか？
- 全く使ってない
- 思想は参考にしている
- 二フクラもマルチアカウントできるの？
- 定義によるが複数は作れる
- 横断してはできないかも？
- マルチアカウントでのコスト管理についてもお時間があれば聞きたいです。例えば、RIやSPの購入や管理方針について。
- 各アカウントで RI や SP を買う
- ベストプラクティスを伝えて担当者任せ
- マスターで買うとどこがどれぐらい使ったか計算が必要なため
- 各アカウントで RI や SP を買う
- stacksetsの内容を更新する時は、各利用部門にメンテ通知を出して一斉にやられている感じでしょうか？
- メンテ用の Slack チャンネルで告知して実行
- 費用や通知がわかるようにメンテページを作って告知
- メンテ用の Slack チャンネルで告知して実行
セキュリティインシデントを乗り越えるために行ったマルチアカウントでの取り組みについて
講師： Classi株式会社 プロダクト開発部 大南 賢亮さん
- セキュリティインシデントについて
- 不正アクセスでサービス停止
- ユーザー情報流出の可能性
- 外部サイトで流出情報の確認
- Organizations Before
- OU/SCP を利用していない
- Production アカウントが Organization 管理アカウント
- Bastion アカウントを開発者がサンドボックス利用
- やったこと
- 管理アカウント切り替え
- 新規作成して移動
- OU 設計と配置
- Foudational OU
- Workloads OU
- Prod OU
- SDLS OU
- Infra OU
- PolicyStaging OU
- Workloads OU
- Meintenace OU
- Suspended OU
- Foudational OU
- 管理アカウント切り替え
- ID とアクセス管理
- ガードレール
- リージョン制限
- 監査操作の制限
- インフラは共通基盤操作制限
- Prodでの重要操作の制限など
- 今後
- ガードレールのチューニング
- ロギングとモニタリングの強化
- まとめ
- マルチアカウント構成を活かす形で対策
- AWS SSO 利用でアカウント管理コスト下げてSecureに
- ガードレールの導入
QA
- RoleとSCPの管理を行うのは負荷にならなかったでしょうか？
- それほど負荷にならなかった
- 予防的ガードレールとしてPermission Boundary使っていますでしょうか？
- 使ってない
- 本題ではないですがAAD × GSuiteという構成が気になりました。AADからAWSへのSSOは出来なかったのでしょうか。
- もともと AWS SSO できる前からこの構成だった
- Config Ruleは現在どの様なものを設定して運用しているのでしょうか？カスタムルールも運用してますか？どの様なルールを使われていますか？
- まだあまりチューニングできてない
- これでもかなり引っかかる
- 他のセキュリティ系のサービスで導入を検討しているものはありますか？
- IAM AccessAnalyzer
- コンテナではアクア
- ConfigRuleなどの検知設定のチューニング時の基準みたいなものはありますか？ 必要/不要の判断の際に参考にするバックグラウンドとなるセキュリティポリシーが存在するのでしょうか
- 基準を策定中
- セキュリティ対策の優先順位としてID管理、アカウント管理、アクセス管理
- ロギング、モニタリングのあとにポリシーをつめたい
- SCPはAWS導入の初期から実施されましたでしょうか？AWSを運用した途中からSCPを入れるとしたら苦労しましたか？
- 6年ぐらい AWS を運用していた
- 後からは大変だったがインシデントがあったのでやる必要があった
- 計画メンテナンスを入れて対応した
- SSOユーザのアカウントへの紐づけ情報の棚卸は実施されていますでしょうか？
- Spreadsheetで管理
- ユーザーとパーミッションセット
所感
複数アカウントを管理していますが、Organizations はうまいこと活用できてません。
新規 AWS アカウント作成時の CFn テンプレートは準備してますが、StackSets にもせず順番にスタックを作っている状況。
やったほうがいいのはわかっているのですが、そんなにも数が多くないと綺麗に作り直すモチベーションがでなくて難しいですね。
懇親会は Clubhouse という今どきの形です！
ということでこちらを聞きに移動します。
