はじめに
健康診断の結果と忘年会の流れがとても怖いクラウド基盤チームのゲインです。
忘年する前に、AWS環境を健全にする話をします。
背景
ログラスではAWSを主に使用しており、AWS Organizationsの使用や、AWS IAM Identity Center(旧SSO)を利用したSSOなどに対応しある程度の利便性とセキュリティに配慮した構成になっていました。
以前は以下の図ようなアカウント体系でAWS Organizationsが構成されていました。
ここで本番環境では、お客様向けのアプリケーションが動いている環境と、請求、AWS Organizationsのアカウント管理やAWS CloudTrailの管理などが行われていました。
つまりアプリケーションワークロードとしての本番アカウントと、AWSの管理アカウントが役割として混在しており2つの役割を持ったアカウントとして今まで運用を行っていたのです。
今まではそれでも問題はなかったのですが、ありがたいことにエンジニアが増加したり、海外に開発拠点を設置する[1] などにより今までの少人数で仕事をしていたときの性善説での運用ではお客様の大事なデータを預かる身としては問題になります。
また通常業務としてIAMのポリシーを絞る運用が厳しくなっている現実もありました。
さらに別の要因として全社的にOktaの導入が行われたことによりIdentity CenterのIdPを変更したい欲求や、今後さらにセキュリティを強化していくためにCSPMを築いていくことが重要となりました。
そこでクラウド基盤チームとしてはまず既存のAWS Organizations環境を整理することにしました。
どのような方法があるのか
我々の最終ゴールはAWS環境を統制の効く状況にすることだったので、方針としては以下が考えられました。
- このまま本番アカウントと管理アカウントを同一として扱い、きちんとIAM PolicyやSCPなどを駆使して統制をかける
- 本番アカウントと管理アカウントを分けて、そもそもアクセスできるユーザーを管理する
クラウド基盤チームとしては当時2人しかおらず、アプリケーションワークロードを管理する仕事もしていたため、本番へアクセスできるユーザーと管理者としてアクセスできるユーザーの権限を精密に分けることは現実的ではありませんでした。
そのため、我々は2の本番アカウントと管理アカウントを分ける手法を取りました。
本番アカウントと管理アカウントを分ける方法は以下が考えられます。
- 顧客影響が出ても無視してガッと停止してごそっと移行する
- 管理アカウントからワークロードに関するものを全て新規のアカウントに移行する
- 新規にOrganizationのrootアカウントを作成して、そちらにワークロードのアカウントを移管する
まず1の手法は確実に取れません。
すでにお客様が使っている環境ですので気軽に落とすことは不可能です。
お客様が限りなく少ない調整が可能なベンチャーの初期段階ではこの方法も有用だと思います。
次に2の手法を取った場合には我々としては以下のような作業や考慮が求められます。
- 管理アカウントと新規アカウントでAurora Postgresの移行計画を立てる
- 深夜メンテでバチッと切り替えるのかVPC Peering + 論理レプリケーション等を使用するのかの検討から
- 管理アカウントと新規アカウントでアプリケーションの移行計画を立てる
- VPC Peeringして一旦DB等に接続したり、S3は別アカウントを見に行くなど段階的な移行が必須
- ドメインなどの管理
- パラメーターストアなど手動で登録した値の再登録
- S3のバケットの整理と移行
- 深夜メンテでバチッと移行できるか検証
- クロスアカウントでコピーして権限とか完全に問題ないかの検証
- バケットの名前はグローバルに重複が出来ないので、最終的にはバケットを別名に分けないといけない…
- 各種補助的なLambdaのDeployやStepFunctionsの移行
- 数が多すぎて全部移管できるか?
- その他なにか依存しているリソースは無い？
- わからないことはわからない…
- etc...
以上腰を据えて向き合うべきタスクが多く、二人しかいないなかで現実的な期間で終わらせることは不可能だと判断しました。
そこで我々は 3. 新規にOrganizationのrootアカウントを作成して、そちらにワークロードのアカウントを移管する という方法を取ることにしました。
やること自体はAWSのドキュメントにもまとめられておりますのでこちらをご覧ください。
AWS Organizations でアカウントを別の組織に移行する
新Organizationの設計
まずは全体像です。
基本的にはAWSのArchitectureを参考にしました。
現状のログラスではAWSの管理を分けるほど複数サービスを運用する形にはなっていないので会社の部署に合わせたOUではなく、あくまでワークロードごとでOUを作成しました。
また用途に合わせて新規にAWSアカウントも作成し、以下のように整理を行いました
- CCoE
- (new)user-management
- AWS IAM Identity Center(旧SSO)の権限管理。ユーザー作成自体はOktaのSCIMプロビジョニングを有効化
- (new)user-management
- Security
- (new)LogArchive
- Organization全体のCloudTrailのログ等、全体にまたがるログ自体を保管するアカウント
- (new)audit
- IAMのAnalyzerなどセキュリティや監査で全体で有効にしたい機能を有効にするためのアカウント
- (new)LogArchive
- Product
- 既存のアプリケーションが動いているアカウント群
- 本番
- ステージング
- 開発
- 社内向けシステム
- ...
- 既存のアプリケーションが動いているアカウント群
気をつけたポイント
旧環境のAWS IAM Identity Centerを削除したらカスタムURLは同じ値が使えるのか？
旧環境のAWS IAM Identity CenterでカスタムURLの設定を削除したら、別のAWS IAM Identity Centerで同じカスタムURLの作成が可能であることを事前にサポートで問い合わせて確認を行いました。
結果的に問題ないとのことでしたので、移行後無事に同じカスタムURLを使用しております。
Organizationの管理をすべて委任することは出来ないのか？
AWS Organizationsの機能自体でGuardDutyやCloudTrailなど管理系のサービス別のアカウントに権限を委任することが出来ます。
AWS Organizations を他の AWS のサービスで使用する - AWS Organizations
Organizations自体も委任をすることが出来るのですが、AWSアカウント自体の発行やOrganization Unitの作成は引き続き管理アカウントで行う必要がありそうでした。
部署がたくさんあるわけでもないので、Organization Unit単位で細かく委任管理者によって管理してもらうモチベーションも今の我々のフェーズにはなかったので現時点ではスコープ外としました。
AWS Control Towerは使わないのか？
AWS上でマルチアカウントを管理するためのサービスとしてAWS Control Towerがあります。
AWS Control Tower とは - AWS Control Tower
このサービスを導入することによって、対象とするアカウントへセキュリティ的なベースラインを担保したり、AWS Accountを新規で作るための統一的な設定をあらかじめ導入することが出来ます。
一見良さそうなサービスだなと感じたのですが以下の観点から導入を見送ることにしました。
- シリーズBのベンチャーなので現状は大量にAWSアカウントが増えるということはない
- Control Tower自体に知見を持った人材が社内にいない
- 一度環境を整備した後、必要なタイミングで導入が行えそう
- 逆に導入してしまったら辞めるのが大変そう(不可逆)
将来的に会社が大きくなった暁には再度検討する余地もありますが、現状ではスコープ外とすることにしました。
作業内容
では実際にどのような作業を行ったかを記載します。
移行自体は8月から着想を始め、実際にすべてが完了したのは10月末でしたのでおよそ3ヶ月ぐらいの期間で移行が完了しました。
AWSアカウントを新規に開設 & Organizationsを有効化
新しいアカウント側にAWS Organizationsの環境を整備したいので、当たり前ですがアカウントを作成します。
既存のAWSアカウントをスタンドアロンアカウントの要件を満たすために情報を設定する
一度Organizationsから離脱するために、各アカウントがスタンドアロンアカウントになっている必要があります。
スタンドアロンアカウントの条件は以下です。
- 連絡先名と住所
- 有効な支払い方法
- 電話番号による確認
- サポートプランオプション
現在だとOrganizationで作られたアカウントに関しては電話番号認証はConsoleから行うことは出来ないため、各アカウントでサポートにお願いしないといけません。
この作業が一番大変だったな〜と感じているので、アカウント作成時のようにAWSコンソールからボタンで架電出来るようになると嬉しいなと強く強く思っております。
AWS Organizations でメンバーアカウントから組織を退会する - AWS Organizations
管理アカウント用にTerraformを適用する準備
ログラスでは基本的に全てのインフラリソースをTerraformで管理しているため、tfstateを保存するためのバケット等を作成しました。
またワークロード用のインフラリソースの管理と分けたかったため、新規にterraformのコードを管理するためのGitHubのリポジトリも作成しました。
AWS IAM Identity CenterとOktaを連携
社内の情シスの方と連携し、OktaとAWS IAM Identity Centerとの連携や、SCIMの設定を行いました。
現状ではアクセス権限はOktaのグループと紐づけず、あくまでAWS側で誰に権限を与えるのかを管理しています。
各種新規アカウント作成
先述の通り管理をそれぞれのアカウントに分けたかったため、AWS Organizationsで以下のアカウントを作成しました。
- user-management
- LogArchive
- audit
CloudTrailの新規設定
新規に作成した管理アカウント側でCloudTrailを有効にしました。
移行にあたって、旧環境のCloudTrailをどうしようかと思ったのですが、一旦旧環境に残しておき、いざとなったら復元出来る状態にしておいてます。
CloudTrailの保存自体は新規に作成したLogArchiveアカウントにすべて保しております。
Rootアカウントで各アカウントへアクセスできるかを確認
移行するアカウント新Organizationsからの招待を受け取るために、すべてのアカウントでRootアカウントでのログインが行えるかを試しました。
移行周知 & 移行
Organizationsの移行を行うことで、一時的にAWS IAM Identity Centerのログイン用のURLが新旧混在してしまう時間が会ったため、エンジニアに周知を行い実際に移行を行いました。
移行後はportalのカスタムURLを以前のものと同じ値に設定することでエンジニアに特に対応していただくこともなく移行を終えることが出来ました。
移行時の失敗談
以上の手順を踏み何とか以降はできたのですが、残念ながらすんなり移行出来たわけではないのでいくつか失敗談を共有したいと思います。
作業漏れで電話番号認証が通っておらず、作業中断
実際に準備を整えて移行作業を行う当日に、手順に従ってアカウント移行をしたところ途中でエラーが発生してしまいました。
どうやら一部のテナントが先述したスタンドアロンアカウントとしての資格を持っていなかったようです。
サポート履歴等を確認したところ、どうやらそのアカウントだけ作業漏れで電話番号認証が通っておらず、また夜に作業したこともありサポートの対応時間からは外れていたのでその日は作業を中止することになってしまいました。
反省点としてはきちんと各アカウントで電話番号認証したエビデンスを管理しておけばよかったなと感じています。
AWS Organizationの初期の最大アカウント数のQuotaに引っかかる
初期段階ではAWS Organizationsのアカウント上限は10個です。
そのため、移行している途中でQuotaに引っかかり、アカウント移行ができない事態になりました。
検証用のダミーアカウントを削除し、本来移行したいアカウントと合わせて10個以下にすることが可能だったのでなんとか移行を終えることが出来ました。
このQuotaはあらかじめ上限を増やす申請が可能であったため、こちらも自分たちがどれぐらいアカウントを利用する想定があるのかを考慮し、Quotaを確認しておけばよかったと感じています。
過去のCost Expolerが見れなくなる
移行するまでに見えていたCost Expolerの値を見ることができなくなりました。
これはドキュメントにも書いてある通りバックアップを取って置く必要があります。
あるRootアカウントでMFAがない
ある創業初期に作られたアカウントでMFAが設定されていたのですが、MFAを紛失しておりRootでのログインが出来ない状態でした。
これはMFAの再設定を依頼して、海外からの自動電話を受け取ることで無事にリセットすることが出来ました。
まとめ
苦節ありましたがなんとかAWSのOrganizations移行を終えることができました。
こういった事態にならないように絶対にAWSを使い始めた段階で絶対に管理アカウントとアプリケーションを動作させるアカウントを分けましょう。
まだまだ権限管理をより良くしたりなど、より開発者が安心して使えるAWS環境を提供していきたいので、セキュリティやAWSが好きな人がいらっしゃいましたらカジュアル面接からいかがでしょうか。
株式会社ログラスは「良い景気を作ろう。」をミッションに、企業経営を推進する次世代型経営管理クラウド「Loglass 経営管理」を開発し提供しています。
Discussion