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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. 当社での実践例 

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

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

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

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

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

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

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

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

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 

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

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

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

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

No content

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

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

No content

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

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

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