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. AWS Startup Community Conference 2022
    プロダクトと組織の成長を見据えた
    スマートラウンドの
    AWSマルチアカウント戦略
    株式会社スマートラウンド
    山原 崇史(@shonansurvivors)

    View full-size slide

  2. 自己紹介
    株式会社スマートラウンド SRE
    山原 崇史 (やまはら たかし)
    経歴
     SIer・銀行・Web系ベンチャー → スマートラウンド
    好きなAWSサービス
     IAM Identity Center(AWS SSO) / Security Hub
    Twitter
     @shonansurvivors

    View full-size slide

  3. 会社概要
    会社名  株式会社スマートラウンド
    代表者  砂川 大
    設立  2018年5月
    従業員数  約25名
    本社住所  東京都渋谷区 ※全員フルリモート勤務
    ホームページ  https://jp.smartround.com

    View full-size slide

  4. 事業紹介
    ミッション
     スタートアップが可能性を最大限に発揮できる世界をつくる
    課題
     1. スタートアップ経営者の多くが初めての起業経験で
      株主管理や資本政策等の事務作業に時間を浪費
     2. 投資家は投資先スタートアップに対して
      独自のスプレッドシート入力を依頼するため非効率
    smartroundが実現する世界
     統一化・標準化されたデータ管理によって
     スタートアップと投資家双方の業務を効率化し、
     スタートアップが事業により専念できる環境を実現

    View full-size slide

  5. 本日のテーマ
    プロダクトと組織の成長を見据えたAWSマルチアカウント戦略
     アーリーステージのスタートアップであるスマートラウンドが
     今後の成長を見据えてどのような AWSマルチアカウント戦略を
     推進していったかについてお話しします。
     
     マルチアカウントをどのように管理していくか、
     これから検討予定あるいは現在検討中のスタートアップの参考になれば幸いです。

    View full-size slide

  6. アジェンダ
    1. プロダクトとエンジニア組織について
    2. AWSマルチアカウント戦略について
    3. 当社での実践例
    ○ IAM Identity Center(AWS SSO)の導入
    ○ 組織単位(OU)とセキュリティ系アカウントの作成
    ○ Control TowerのIAM Identity Center(AWS SSO)への対応
    ○ 各種セキュリティサービスの導入
    4. 振り返りと将来の展望

    View full-size slide

  7. 1. プロダクトとエンジニア組織について

    View full-size slide

  8. プロダクト
    モジュラモノリス構成で複数のサービスを提供
    会社経営支援・IRサービスを提供
    IRデータ共有
    投資管理smartround
    案件管理smartround
    顧客支援smartround
    ※新サービスも企画中
    資本政策smartround
    経営管理smartround
    株主総会smartround
    SO管理smartround
    優待特典smartround
    ※新サービスも企画中
    スタートアップ
    投資家
    投資先・投資案件管理サービスを提供

    View full-size slide

  9. 開発チーム
    エンジニア組織
    エンジニアは全6名
    CTO テックリード
    エンジニア エンジニア
    CRE
    SREチーム
    SRE
    AWS全般の
    主担当
    SREとして
    各種支援

    View full-size slide

  10. 2. AWSマルチアカウント戦略について

    View full-size slide

  11. マルチアカウント化による代表的なメリット
    環境の分離により、権限管理を容易にするとともに、オペレーションミスのリスクを低減させる
    責務
    プロダクト
    環境
    本番
    検証
    責務
    プロダクト
    環境
    本番
    検証

    View full-size slide

  12. マルチアカウント戦略を必要とする理由
    前述の環境の分離に加え、急速な成長を遂げるスタートアップ特有の 変化に柔軟に適応するため
    将来起こり得ることの例 個別アカウントに複数責務を負わせた時のリスク
    ➢ 独立した新規プロダクトと専任の開発チーム
    が生まれる
    ➢ 既存プロダクトの一部サービスをモノリスか
    ら別サービスとして切り出すとともに、専任
    の開発チームを組成する
    ● 複数開発チーム間の権限の境界が曖昧になる
    ● プロダクトやサービスごとの費用管理が曖昧になる
    ● セキュリティやコンプライアンス要件の違いに柔軟
    に対応できない
    ● 外部の監査やアセスメントに柔軟に対応できない
    ➢ プロダクトと開発チームの増大に伴い、複数
    AWSアカウント横断での統制の高度化が求
    められる
    ● 統制をする側とされる側の権限の境界が曖昧にな

    View full-size slide

  13. 責務に応じたマルチアカウント
    責務
    既存プロダクト アカウント横断の統制 将来の新プロダクト …
    環境
    本番
    検証
    補足:
    この検証アカウントは別Organizationsに属させ、
    何かサンドボックス的アカウントを相手に統制に関する
    設定内容の検証を実施するのが一般的なやり方と考える

    View full-size slide

  14. マルチアカウント戦略の推進ステップの一例
    0. マルチアカウント未導入 (シングルアカウント管理 )
    1. Organizationsの導入と環境ごとのマルチアカウント
    2. IAM Identity Center(AWS SSO)の導入
    3. 組織単位(OU)とセキュリティ系アカウントの作成
    4. 各種セキュリティ系サービスの導入
    当社は最初期から
    この状態
    登壇者自身が
    対応したステップ

    View full-size slide

  15. 3. 当社での実践例

    View full-size slide

  16. 当初のアカウント構成とアイデンティティ運用
    Organizationsは導入済みで、全4アカウント構成
    組織Root
    management smartround-prd smartround-stg smartround-sandbox
    CTO & 開発者 & SRE
    CTO & SRE
    各アカウントに対し
    IAMユーザーを保有
    (IAMポリシーは
    職種によって異なる)
    バックオフィス
    (請求情報確認)

    View full-size slide

  17. IAM Identity Center(AWS SSO)の導入
    当社は社員全員にGoogleアカウントを配布済みのため、これを外部 IDとして使い、IAMユーザーは廃止
    management
    smartround-prd
    smartround-stg
    smartround-sandbox

    View full-size slide

  18. IAM Identity Center(AWS SSO)の導入の狙い
    セキュリティと運用効率性の向上
    ● IAMユーザーの永続的なクレデンシャルを管理せず に済む
    ● 複数のIAMユーザーの使い分けが不要となる
    ● 当社は外部IdP側で二要素認証を必須化しており、その恩恵も受けられる
    ● AWS CLIの利用も簡単・快適
    ○ 初期設定は、aws configure sso --profile {profile_name}
    ○ 以降は、aws sso login --profile {profile_name} でブラウザが起動し、 1クリックで認証完了

    View full-size slide

  19. 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を使うと一気に作れて便利

    View full-size slide

  20. 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 = {
    # 略
    }
    }
    }

    View full-size slide

  21. 組織単位(OU)とは何か
    ● OU(Organizational Unit)は、Organizations内のアカウントを束ねる論理的なグループ
    ● OU単位で異なるSCP(サービスコントロールポリシー )を適用できる

    View full-size slide

  22. どのような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構成例も示されている

    View full-size slide

  23. ● 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の「最小限のスターター構成」

    View full-size slide

  24. 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

    View full-size slide

  25. 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を作ることにした
    自動作成

    View full-size slide

  26. Control TowerのIAM Identity Center(AWS SSO)への対応
    ● Control Towerを有効化するとデフォルトの SSOグループや許可セットが自動で多数作成される
    ● 既存アカウントをControl Tower配下に置くとルートユーザーと同名の SSOユーザーも作成される (はず)
    ● 当社は既にIAM Identity Centerを独自の設定で運用しており、 Control Tower作成分は
    自社のポリシーにフィットしなかったので無視することとした
    ○ SSOユーザーは無効化した
    ○ その他のSSOグループに関してもグループそのものは削除しないが
    各アカウントへのアクセス権は今後削除する予定

    View full-size slide

  27. 各種セキュリティ系サービスの導入
    ● Security Hub等はmanagementアカウントで管理せず、
    auditアカウントに委任
    ● Security Hubはバージニア北部リージョンも有効化
    (CloudFrontの非準拠検知のためにも )
    ● Security Hubのセキュリティ基準は 3種類あるが
    「AWS基礎セキュリティのベストプラクティス」が
    カバー範囲が広く有用

    View full-size slide

  28. 通知(アラート)について
    ● auditアカウントのSecurity Hubの集約リージョンに
    各アカウントの各サービスからの検知結果が
    集まるので、そこから EventBridgeで
    フィルタリングしつつ通知させるのが効率的
    ● 既存のワークロード用 Slackチャンネルとは別に、
    auditアカウント用Slackチャンネルを新設し、
    そこに通知させた

    View full-size slide

  29. 4. 振り返りと将来の展望

    View full-size slide

  30. 振り返り 1 / 2
    得られたこと
    ● 全アカウント横断でリスクを 可視化し、これを改善するフィードバックループ を回せるように
    ● 今後のプロダクトと組織の成長を見据えた、一定の 「基盤」を構築することができた
    ● 別途AWSファンデーショナルテクニカルレビュー (FTR)を受け、これを通過することができた
    ○ 今回のマルチアカウント戦略を推し進めていたからこそ問題無くクリアできたと思う点が
    多々あり

    View full-size slide

  31. 振り返り 2 / 2
    課題
    ● auditアカウント(統制する側)と他のメンバーアカウント (統制される側)を
    同一チームで管理しているため、統制される側への
    啓蒙やモチベーション向上などを意識しなくても 成立してしまっている

    View full-size slide

  32. 開発チーム
    将来の展望
    開発チームに必要な権限を移譲しつつ、 改善のループを回せるように
    SREチーム
    開発チーム
    開発チーム
    開発チーム
    SREチーム
    改善の
    仕組み作り・支援

    View full-size slide

  33. スマートラウンドでは新しいメンバーを募集中です!
    私たちと一緒にスタートアップが可能性を最大限に発揮できる世界をつくりませんか?
    jobs.smartround.com

    View full-size slide