- はじめに
- AWS Organizationsとは
- AlphaDriveのOrganization管理例
- AWS Organizationsと組み合わせて導入したサービス
- まとめ
- カジュアル面談に関して
はじめに
AlphaDrive/NewsPicksのアカザワです。
AlphaDriveではCTOとしてエンジニアリング組織の立ち上げ、拡大や新規事業の創出を支援するSaaS Incubation Suite の開発をしています。また、NewsPicksでは法人向けサービスの NewsPicks Enterprise や NewsPicks ＋ｄ , NewsPicks for Microsoft Teams などの連携サービスの開発等も行なっております。
さっそく本題に入ります！ 本記事は、Uzabase Advent Calendar 2021 22日目の記事です。
AlphaDriveとNewsPicksの開発で何を題材にしようかと考えた際、AWS Organizations及び連携したAWSサービスの導入によって組織統制・セキュリティの強化、組織全体の快適性・開発効率の向上、この２つをトレードオフにすることなく両方実現できた点が今年開発組織を拡大した中でメリットが大きかった（今実施したことで今後のコスト増加も防げた）と感じるため共有したいと思います。
AWS Organizationsとは
そもそもAWS Organizationsとは、という点に関しては以下の公式ドキュメントと少し古い日付ですがブラックベルトの資料が非常に参考になるためこちらで割愛し、自分として重要なポイントだけ記載します。
ポイント
- 複数のAWSアカウントをOrgnizationとして一元管理（組織内からのアカウント追加、削除だけでなく既存AWSアカウントの組織追加、離脱も可能）
- 組織単位でコスト状況や請求もまとめて管理
- 組織とアカウントの間に階層構造及びOrganization Unit（OU）という単位を用いて管理、ポリシーで制限
- いくつかの機能の管理（後述）は最上位の管理アカウント以外に、「委任」という形式で別アカウントで実施することが可能
- リソース共有などの対象に組織を指定でき、管理を効率化
AWSアカウントの一元管理は、組織内からの新規アカウント追加、削除だけでなく既存AWSアカウントの組織追加、離脱も可能です。
AlphaDriveのOrganization管理例
現在、AlphaDriveではAWSアカウントを10管理しており、そのうち7がAWS Organizationsで管理、既存製品の3アカウント（dev, stg, prod）を組織に連結予定となっています。 そのうち、5アカウントを取り出して図にしたものが以下です。
製品を管理するOUとその配下にランドスケープ単位での各アカウントを配置しています。 製品以外では代表的なものとしてセキュリティや監査機能の委任先としてのSecurityアカウント、最低限の制限だけ加え、開発者全員がAdmin権限をもち自由に試せるSandboxアカウントがあります。
AWS Organizationsと組み合わせて導入したサービス
上記の構造で管理したAWS Organizationsで組み合わせて便利だったサービスを4点以下にまとめました。
- AWS Organizations × AWS SSOで楽かつセキュアにアカウント管理
- Security Hubでのセキュリティ設定状況を一元管理
- AWS Resource Access Managerで組織内にリソース共有
- SCP（Service Control Policy）で不要なアクションを制限
AWS Organizations × AWS SSOで楽かつセキュアにアカウント管理
とにもかくにも、AWS Organizations × AWS SSO！AWSでマルチアカウント管理で運用するために大前提となる機能です。 AlphaDriveでは基本的な運用としてSSOユーザーのみ作成し、IAMユーザーは利用していません。また、Production環境などはSCPでIAMユーザーの作成も制限しています。（後述）
AWS SSOでは、ユーザー（SSOユーザ）とグループ（SSOグループ）を用います。 その上で、「どのアカウントで」「誰が」「何をできるか（できないか）」という設定の組み合わせを割り当てます。 誰 = SSOユーザ または SSOグループ、何をできるか = アクセス権限セット、となります。
AlphaDriveで開発にジョインした場合にAWSのアカウントで行う場合は以下の2ステップのみです。
- SSOユーザを作成する
- 適切なSSOグループに1で作成したSSOユーザを追加する
この2ステップで必要なAWSアカウントに必要な権限で操作することができます。 以下の場合は、実物を少しサンプルとして加工したものになりますが、SSOのポータル画面になります。開発者はこのポータルから適切なアカウントに適切な権限で簡単に利用できます。例えばProductionのアカウントには制限されたMemberAccessで利用可能、Sandboxは自由な技術検証アカウントとしてAdministratorAccessで、といった感じです。
権限セットとSCP（後述）を適切にメンテし続ければあとは開発者の新規参加時なども「適切なSSOグループに所属しているか」この一点に留意すれば良いので管理コストも下げることができます。
Security Hubでのセキュリティ設定状況を一元管理
AWS Security Hubは複数のAWSサービスのアラートを集約し一元的にチェック、管理できるサービスです。 aws.amazon.com
AWS Organizationsと統合される以前は、個別のアカウント × 個別のリージョンで個別に有効化する必要があったため、一括有効にするスクリプトを各自で書いて対応などがありましたが、2021年12月時点ではAWS Organizationsとともに非常に簡単に導入できるようになっています。
- AWS Organizationsの組織内で一括有効化し、各アカウントの管理状況を把握・対応できる*1
- 組織に追加されたアカウントに自動で同様の対応を行うことができる（Auto-enable）
- AWS Organizationsの管理アカウントから別の組織内アカウントにSecurity Hubの管理を委任できる
- 集約リージョンを指定して、一部または全てのリージョンの検出結果を確認、管理できる
AlphaDriveでも最上位のManagementアカウントではなくSecurityアカウントに委任して管理しているため、Security Hubの全体状況を確認、対応するためにManagementアカウントにログインする必要はありません。また、このSecurityアカウントに全リージョンの検知情報を集約し管理しています。 AlphaDrive Management（Organization管理アカウント） -- 委任 --> AlphaDrive Security
AlphaDriveでは標準設定に従い、以下の2基準を有効にしています。 * CIS AWS Foundations Benchmark v1.2.0 * AWS 基礎セキュリティのベストプラクティス v1.0.0
AWS Resource Access Managerで組織内にリソース共有
AWS Resource Access Managerは複数のAWSアカウント間、IAMユーザー、IAMロールでリソースを共有できるサービスですが、その共有単位にAWS Oraganizationsの組織及びOUを指定して共有することができます。これもとても便利。 docs.aws.amazon.com
AlphaDriveでもいくつかのリソースを組織共有できますが、その中でライトな内容だけれど意外に便利だったリソース共有の例を紹介します。
VPN情報を設定したプレフィックスリストを組織内で共有し再利用する 昨年のAWSアップデートで1つ以上のCIDRをまとめてプレフィックスリストとして管理、セキュリティグループやVPCルートテーブルで利用できるようになりました。
docs.aws.amazon.com このプレフィックスリストを用いてUzabaseで管理している各拠点のVPNを設定する、といったケースがたびたびあったのですが、この必要な拠点のVPN情報をまとめたプレフィックスリストを組織共有することで毎回、付与しなくても選択肢から共有されたプレフィックスリストを選択するだけ、メンテも1箇所！というように、少しなんだけど絶妙に面倒だった設定コストを下げることができました。
SCP（Service Control Policy）で不要なアクションを制限
SCP自体の説明は以下の公式が大変参考になります。SCP自体はOUまたはアカウントにアタッチ可能です。 docs.aws.amazon.com
また、自身が作成、設定する上で非常に勉強になったのがクラスメソッド様のSCPの継承の仕組みについて書かれた記事です。めちゃくちゃ参考になります。フィルターである（通すものであり許可を与えるものでない）点が複数パターンで丁寧に記載されており、IAMだけでなくSCPで制御する意味が明快に理解できます。
AlphaDriveではdev, stg, prodなどを束ねる製品単位のOUにアタッチしたり、prodのアカウントにより強い制約をかけるためにアタッチしたりしています。 SCPの１つの特徴は、ルートユーザーも対象とする制約の強さです。不要な操作を除外できますが誤ると、あれ！？ルートでも操作できない！？という事態もありますのでご留意ください。
AlphaDriveで利用しているSCPを2つポリシーのコンテンツとあわせて紹介いたします。 これらの制限しているポリシーは、「開発者が操作したいけれど危険！」というよりも「行う必要はないが行えてしまうことが不安」という内容で、制限することでより開発者の心理的安全性を高めて必要な権限と操作を提供することが目的となります。
ProductDevelopmentPolicy
- 製品開発を束ねるOUにアタッチするポリシー
- 代表的なポリシー内容：ルートユーザーでのec2やs3, rdsなど主要なリソースへの操作を禁止する
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictActionsForRootUser",
"Effect": "Deny",
"Action": [
"ec2:*",
"rds:*",
"lambda:*",
"s3:*"
],
"Resource": [
"*"
],
"Condition": {
"StringLike": {
"aws:PrincipalArn": [
"arn:aws:iam::*:root"
]
}
}
}
]
}
ProductionPolicy
- 各製品のproduction環境を管理するアカウントにアタッチするポリシー
- 代表的なポリシー内容：AWS Resource Access Managerを用いての外部アカウントへのリソース共有禁止、特定のSSOユーザー以外のIAM操作禁止
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RestrictShareResourcesToExternal",
"Effect": "Deny",
"Action": [
"ram:CreateResourceShare",
"ram:UpdateResourceShare"
],
"Resource": "*",
"Condition": {
"Bool": {
"ram:RequestedAllowsExternalPrincipals": "true"
}
}
},
{
"Sid": "DenyOperateIAMExceptAdmin",
"Effect": "Deny",
"Action": [
"iam:CreateUser",
"iam:DeleteUser",
"iam:CreateLoginProfile",
"iam:CreateAccessKey",
"iam:AttachRolePolicy",
"iam:DeleteRole",
"iam:DeleteRolePermissionsBoundary",
"iam:DeleteRolePolicy",
"iam:DetachRolePolicy",
"iam:PutRolePermissionsBoundary",
"iam:PutRolePolicy",
"iam:UpdateAssumeRolePolicy",
"iam:UpdateRole",
"iam:UpdateRoleDescription"
],
"Resource": [
"*"
],
"Condition": {
"StringNotEqualsIfExists": {
"identitystore:UserId": [
"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
]
}
}
}
]
}
ConditionではIAMユーザーではなくSSOユーザーを指定しています。ここにSSOグループを設定すればバッチリ！と思い、以下を試しましたが動作しなかったです、AWSの対応に期待、、、
"Condition": {
"StringNotEqualsIfExists": {
"identitystore:GroupId": [
"SSO AdminグループのID"
]
}
}
まとめ
まだまだAlphaDriveでもAWS Organizationsを使いこなしているレベルではありませんが導入してすぐに、組織としての管理の効率化やセキュリティの向上、各エンジニアの開発やAWS操作の効率化の両方を感じることができました。適切な単位でアカウントを分割してAWS Organizationsで管理する、ぜひオススメです！AlphaDirveもOrganizationsをまだまだ使いこなせておらず、次のステップとして、AWS Control Tower、AWS CloudFormation StackSets、Baseline Environment on AWSあたりを導入予定です。
カジュアル面談に関して
NewsPicksのプロダクト開発は「経済を、技術でもっとおもしろく。」をミッションに複数のポジションを募集中です！私が現在開発している法人向けNewsPicks Enterpriseの開発も拡大しております！自身で良いと思える機能やUXを考えて開発しるサービス開発の面白さ、新しい技術への導入や挑戦の両方を楽しむことができる開発チームですのでぜひカジュアルにお声がけください！ meety.net
また、AlphaDriveのプロダクト開発では「新規事業が日本中で立ち上がる、をテクノロジーで実現する！」「ビジネスパーソンがやりたくないことをやらず、やりたいこと・やるべきことに集中できる世界を作る！」をミッションに新SaaSを立ち上げ中です！まだまだ初期設計と開発中なのでど真ん中で開発を推進してくださるエンジニア（バックエンド、フロントエンド、SRE、全方位）採用中です！基盤はAWS、フロントはNext.js + TypeScript、サーバサイドはGo + Ginという構成です！ meety.net
*1:内部ではAWS Configを用いているため、各メンバーアカウントでAWS Configが有効化されていることが前提となります。
