こんにちは、エンジニアをしている wa6sn です。開発組織を横断した課題を解決する、Platform Unit というところに所属しています。

この記事では、ギフティにおける AWS アカウント管理運用の考え方について述べます。

「今も増え続ける」プロダクトとAWSアカウント

実は、以前にも AWSアカウント管理をコード化する という記事で AWS アカウント管理について触れられています。記事中では、AWS アカウントの運用方針について、以下のように述べています。

ギフティのエンジニアリング組織は「自己組織的」であることを大事にしているので、CTO室側でやっているインフラ業務はかなり限定的です。また基本的にインフラは全てAWS上で動いており、AWSの提唱するベストプラクティスも参照しつつ、各チームが自律的に動けるように、プロダクト単位でAWSアカウントを作成する形式を選択しています。

多少の変遷はありつつも、「自己組織的」であることを大事にしている という大きな方針は現在も変わりません。そして、2024/03 時点のギフティには 150 以上の AWS アカウントが存在します。（たまに社員向けの勉強会などで「弊社に AWS アカウントはいくつあると思いますか？」と聞いていますが、正答はおろか 100 以上と回答されたことはありません……。）メンバーとプロダクトの関係は多対多であり、メンバーによっては（SRE のような横断的な職種でなくとも）10 以上の AWS アカウントを利用することもあります。

現存する AWS アカウントがどのように増えていったか、おおよその推移を見てみます。なお、「Sandbox アカウント」とは、希望者に配布している、個々人が一定金額枠の中で自由に使えるアカウントです。「プロダクトアカウント」はそれ以外のアカウントです。

年々、順調に増加していることが分かります。前述の 2020 年の記事に比べると、単にプロダクトやメンバーが増えたこと以外にも、「プロダクトによっては production, staging 環境を異なる AWS アカウントにするケースが主流になってきた」ことも要因でしょう。後述する AWS IAM Identity Center や AWS 自身のアップデートなど、複数のアカウントを運用したり、クロスアカウントでリソースにアクセスするためのハードルが下がっていることも大きいです。

大量の AWS アカウントを運用する

AWS IAM Identity Center（AWS SSO） が便利

大量の AWS アカウントが存在する環境で、各チームが自律的に動くとなると、気になるのはやはりセキュリティではないでしょうか。

まずは IAM です。少し前の言説ですが、クラウドの攻撃経路の 75 % は IAM となるだろう という説もあったほど、攻撃表面として IAM は意識せざるを得ません。厳格な運用ポリシーを定めるにしても、社員の入退職に合わせて IAM user を棚卸しするのは手間ですし、長命なアクセスキーが払い出されがちな点も好ましくありません。

そこで、現在は AWS IAM Identity Center（AWS SSO） の利用を推奨しています。以前より、会社としては OneLogin を IdP に利用しており様々な SaaS に OneLogin 経由でログイン出来ます。IAM Identity Center もその一つです。以下が概要図です。

IAM Identity Center 運用の概要。 「A さん（緑）は productA に携わっており、ReadOnlyAccess と AdmininstratorAccess の両方の権限を持っています。B さん（赤）は productA と productB の両方に携わっていますが、まだ不慣れなために ReadOnlyAccess 権限だけを付与しています」という様子。

OneLogin が「あなたが誰か」すなわち 認証 を担っています。IAM Identity Center が「どのアカウントに、何が出来るか」すなわち 認可 を担っています。退職時には OneLogin ユーザの削除が行われることが確実なため、IAM user 運用時にあった「IAM user を消し忘れたため、棚卸しを行うまでアクセス経路が残ってしまう」という懸念を解消することが出来ています。また、IAM Identity Center の Permisson Sets および、どのアカウントに誰のどの権限が紐づいているかは、terraform による IaC 管理を行っています。

IAM Identity Center 管理リポジトリに PR が作成された図

各メンバーが権限を必要としたとき、IaC 管理を行っているリポジトリへ Pull Request を作成してもらいます。Pull Request が作成されると CI による terraform plan が実行され、その結果を tfcmt という OSS によってお互いが目線を合わせて確認出来るようにしています。IAM Identity Center で集約管理されることで、「どのアカウントに」「誰が」「どのような権限を持つか」を俯瞰した棚卸しも実現できるようになりました。2 年ほど前からこの運用は続いており、IAM user の数も着実に減り続けています。

セキュリティガードレールの整備

その他にも、各 AWS アカウントは一定のセキュリティ系サービスを有効にした上で払い出しています。今回の記事からは詳細は省きますが、GuardDuty, CloudTrail, Security Hub, AWS Config といったサービスが AWS Organizations 配下のアカウント全てで有効となっています。これら “セキュリティ向上のためにデフォルトで有効になっているサービス群” を総称して「セキュリティガードレール」と呼んでいます。

「セキュリティガードレール」に関しては、社内でも定期的に「CloudTrail といったサービスがありまして……」といった啓蒙活動を意識的に行っています。その上で、セキュリティガードレールで検知されたものに対応する責任は各チームが持ちます。各チームが独立に動いているギフティでは、中央集権的なブロッカーを立ててレビューするよりも、開発プロセスの途中で脆弱な設定・仕様を検知できて、その対応までセルフサービスで完結する ほうがフィットするだろうと判断したためです。

この方針で進めるにあたり、プロダクト開発に携わるメンバーからは「セキュリティに関しては当然重要だとは考えているものの、具体的に何をすればよいのかが分かりづらい」という意見を多く聞きました。そこで、セキュリティ対策の基礎的な概念・ギフティ社内で行われているセキュリティに関する取り組みを説明する勉強会を各チーム向けに行ったり、セキュリティガードレールについて対応すべき内容をドキュメントに記したり、といったリテラシーの底上げを地道に行っています。

セキュリティガードレールの概要図を社内ドキュメントから抜粋したもの

とはいえ、各チームがそれぞれに対処していく現状のスタイルでは、個別の知見をまとめてベストプラクティスに昇華していくような力学が働きづらい、という課題も感じています。各チームの開発スピードと技術選定の自由度を保ちつつ、ガバナンスを強化する方策を目下検討中です。

おわりに

ギフティの AWS アカウント運用事情を簡単に説明しました。AWS アカウント事情からも、ギフティが「自己組織的である」ことを大事にしていて、積極的に権限委譲を行っていることがある程度伝わったのではないでしょうか。今回は概要にとどまりましたが、コスト管理などまだ語られていないトピックもたくさんあります。お楽しみに！