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

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

3. 当社での実践例

View Slide

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

View Slide

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

View Slide

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

View Slide

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 Slide

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 Slide

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

View Slide

どのような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 Slide

● 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 Slide

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 Slide

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 Slide

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

View Slide

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

View Slide

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

View Slide

View Slide

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

View Slide

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

View Slide

View Slide

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

View Slide

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

View Slide

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

View Slide

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

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

shonansurvivors

More Decks by shonansurvivors

Other Decks in Technology

Featured

Transcript