Upgrade to Pro — share decks privately, control downloads, hide ads and more …

プロダクトと組織の成長を見据えたスマートラウンドの AWSマルチアカウント戦略/AWS Multi Account Strategy

プロダクトと組織の成長を見据えたスマートラウンドの AWSマルチアカウント戦略/AWS Multi Account Strategy

shonansurvivors

August 26, 2022
Tweet

More Decks by shonansurvivors

Other Decks in Technology

Transcript

  1. 自己紹介 株式会社スマートラウンド SRE 山原 崇史 (やまはら たかし) 経歴  SIer・銀行・Web系ベンチャー →

    スマートラウンド 好きなAWSサービス  IAM Identity Center(AWS SSO) / Security Hub Twitter  @shonansurvivors
  2. 会社概要 会社名  株式会社スマートラウンド 代表者  砂川 大 設立  2018年5月 従業員数  約25名

    本社住所  東京都渋谷区 ※全員フルリモート勤務 ホームページ  https://jp.smartround.com
  3. アジェンダ 1. プロダクトとエンジニア組織について 2. AWSマルチアカウント戦略について 3. 当社での実践例 ◦ IAM Identity

    Center(AWS SSO)の導入 ◦ 組織単位(OU)とセキュリティ系アカウントの作成 ◦ Control TowerのIAM Identity Center(AWS SSO)への対応 ◦ 各種セキュリティサービスの導入 4. 振り返りと将来の展望
  4. マルチアカウント戦略を必要とする理由 前述の環境の分離に加え、急速な成長を遂げるスタートアップ特有の 変化に柔軟に適応するため 将来起こり得ることの例 個別アカウントに複数責務を負わせた時のリスク ➢ 独立した新規プロダクトと専任の開発チーム が生まれる ➢ 既存プロダクトの一部サービスをモノリスか

    ら別サービスとして切り出すとともに、専任 の開発チームを組成する • 複数開発チーム間の権限の境界が曖昧になる • プロダクトやサービスごとの費用管理が曖昧になる • セキュリティやコンプライアンス要件の違いに柔軟 に対応できない • 外部の監査やアセスメントに柔軟に対応できない ➢ プロダクトと開発チームの増大に伴い、複数 AWSアカウント横断での統制の高度化が求 められる • 統制をする側とされる側の権限の境界が曖昧にな る
  5. 責務に応じたマルチアカウント 責務 既存プロダクト アカウント横断の統制 将来の新プロダクト … 環境 本番 検証 補足:

    この検証アカウントは別Organizationsに属させ、 何かサンドボックス的アカウントを相手に統制に関する 設定内容の検証を実施するのが一般的なやり方と考える
  6. マルチアカウント戦略の推進ステップの一例 0. マルチアカウント未導入 (シングルアカウント管理 ) 1. Organizationsの導入と環境ごとのマルチアカウント 2. IAM Identity

    Center(AWS SSO)の導入 3. 組織単位(OU)とセキュリティ系アカウントの作成 4. 各種セキュリティ系サービスの導入 当社は最初期から この状態 登壇者自身が 対応したステップ
  7. 当初のアカウント構成とアイデンティティ運用 Organizationsは導入済みで、全4アカウント構成 組織Root management smartround-prd smartround-stg smartround-sandbox CTO & 開発者

    & SRE CTO & SRE 各アカウントに対し IAMユーザーを保有 (IAMポリシーは 職種によって異なる) バックオフィス (請求情報確認)
  8. IAM Identity Center(AWS SSO)の導入の狙い セキュリティと運用効率性の向上 • IAMユーザーの永続的なクレデンシャルを管理せず に済む • 複数のIAMユーザーの使い分けが不要となる

    • 当社は外部IdP側で二要素認証を必須化しており、その恩恵も受けられる • AWS CLIの利用も簡単・快適 ◦ 初期設定は、aws configure sso --profile {profile_name} ◦ 以降は、aws sso login --profile {profile_name} でブラウザが起動し、 1クリックで認証完了
  9. IAM Identity Center(AWS SSO)の設定関連のTips Google Workspaceを使う場合の初期設定 • AWS公式ブログが詳しい  https://aws.amazon.com/jp/blogs/security/how-to-use-g-suite-as-external-identity-provider-aws-sso •

    Google Workspace側の初期エラーに注意 ◦ 正しく設定しても最初数時間はGoogle側で403エラーになるので作業は翌日再開が良いかも Terraform • SSOユーザーやグループは Terraformでの作成に非対応なのでマネジメントコンソールでの作成要 ◦ 2022/9/30リリースのAWS Provider v4.33.0より作成可能となった 🎉 ▪ 解説記事: https://zenn.dev/smartround/articles/4-terraform-aws-sso • 許可セットと「AWSアカウント・許可セット・ SSOグループの紐付け情報」は Terraformで作成可 ◦ github.com/cloudposse/terraform-aws-ssoという3rd party moduleを使うと一気に作れて便利
  10. Tips 2. cloudposse/terraform-aws-ssoのサンプルコード module "aws_ssoadmin_permission_set" { for_each = local.aws_ssoadmin_permission_set source

    = "cloud-security-labs/sso/aws" version = "0.3.1" name = replace(each.key, "_", "-") description = each.value.description session_duration = each.value.session_duration managed_policy_arns = each.value.managed_policy_arns inline_policy = each.value.inline_policy account_assignments = each.value.account_assignments tags = { Name = replace(each.key, "_", "-") } } locals { aws_ssoadmin_permission_set = { admin = { # 略 } billing_manager = { # 略 } developer = { # 略 } } }
  11. どのようなOUを作るのがベストプラクティスなのか • AWSのWhitepaperの「Organizing Your AWS Environment Using Multiple Accounts(※)」では 推奨OUとして非常に多くの例が登場する

    (※https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment) ◦ Security OU / Infrastructure OU / Sandbox OU / Workloads OU / PolicyStaging OU / Suspended OU / Business Users OU / Exeptions OU / Transitional OU / Deployments OU • 一方で、同Whitepaperでは最小限のスターター環境 としてのOU構成例も示されている
  12. • Control Towerにより、ベストプラクティスに沿った OUとセキュリティ系アカウントが作成される • Whitepaperの「最小限のスターター環境」とも概ね同じ構成 (ただし、一部アカウント名が異なる ) Control Tower導入の検討

    Root Audit Log Archive management Security OU 他のOU Control Towerによる構成 Root security-tooling -prod log-archive -prod management Security OU 他のOU Prod OU Whitepaperの「最小限のスターター構成」
  13. auditアカウント VS. security-toolingアカウント • Control Towerのauditアカウントとは何か?これとは別に security-toolingアカウントが必要なのか? • Whitepaperの、スターターではない 「高度な組織」例ではSecurity

    OUに以下アカウントが登場。 解説はAWS公式ブログ(※1)にあり。 ◦ security-read-only : 監査やセキュリティテストや調査のためにセキュリティチームが使う ◦ security-break-glass : セキュリティインシデント時にセキュリティチームが使う ◦ security-tooling : Security HubやGuardDutyなどサービスの管理アカウントとして使う • auditアカウントは、security-read-onlyアカウントと同じ位置付けなのかもしれない • そこで、Control Towerを使いつつも、security-toolingアカウントを独自に作ろうと考えた ◦ しかし、そうすると当面 auditアカウントの使い道が無くなるのと、 他社事例(※2)ではauditアカウントをsecurity-tooling的に使用していたのでこれを参考にした ※1 https://aws.amazon.com/jp/blogs/mt/best-practices-for-organizational-units-with-aws-organizations ※2 NRIネットコム ウェビナー「大規模 AWS利用におけるセキュリティ環境自動整備 ~AWS Control TowerとAWS Organizationsの活用~ https://www.youtube.com/watch?v=3yqNmB77ll4
  14. Control Towerのデフォルトの構成を活かしつつ、既存アカウントは新規 OUに組み入れた 最終的なOU構成 Root audit log-archive management security OU

    general OU smartround -prd smartround -stg sandbox OU smartround -sandbox workloads OU SCP(サービスコントロールポリシー )を OU単位できめ細かく適用するか未定のため 全体適用可能な(ただし属させなければ適用されない ) 最上位のOUを作ることにした 自動作成
  15. Control TowerのIAM Identity Center(AWS SSO)への対応 • Control Towerを有効化するとデフォルトの SSOグループや許可セットが自動で多数作成される •

    既存アカウントをControl Tower配下に置くとルートユーザーと同名の SSOユーザーも作成される (はず) • 当社は既にIAM Identity Centerを独自の設定で運用しており、 Control Tower作成分は 自社のポリシーにフィットしなかったので無視することとした ◦ SSOユーザーは無効化した ◦ その他のSSOグループに関してもグループそのものは削除しないが 各アカウントへのアクセス権は今後削除する予定
  16. 振り返り 1 / 2 得られたこと • 全アカウント横断でリスクを 可視化し、これを改善するフィードバックループ を回せるように •

    今後のプロダクトと組織の成長を見据えた、一定の 「基盤」を構築することができた • 別途AWSファンデーショナルテクニカルレビュー (FTR)を受け、これを通過することができた ◦ 今回のマルチアカウント戦略を推し進めていたからこそ問題無くクリアできたと思う点が 多々あり