re:Invent 2024: NetflixのマルチAWSアカウント移行 - CAMPとIAM革新
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Netflix's massive multi-account journey: Year two (NFX402)
この動画では、Netflixが大規模なマルチAWSアカウント移行を実現した取り組みについて解説しています。Principal Solutions ArchitectのPrateek SharmaとNetflixのセキュリティエンジニアであるJoseph KjarとPatrick Sandersが、IAMロールをコンピューティングリソースから切り離す革新的なアプローチを紹介しています。Cloud Application Migration Platform (CAMP)と呼ばれる移行オーケストレーションツールを開発し、405のアプリケーションと1,100以上のIAM Roleの移行を実現しました。Attribute-Based Access Control (ABAC)やService Control Policy (SCP)を活用したIAMパターンの設計、リスク削減効果の測定方法など、大規模な移行プロジェクトの具体的な実装手法と得られた知見を詳しく共有しています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Netflixのマルチアカウント戦略：背景と目的
皆様、こんにちは。本日はご参加いただき、ありがとうございます。これまでのre:Inventを楽しんでいただけていることを願っています。私はAWSのPrincipal Solutions ArchitectのPrateek Sharmaです。過去5年間、Netflixのセキュリティチームと密接に協力させていただく特別な機会に恵まれ、re:Invent 2022では、セキュリティとスピードを重視したマルチAWSアカウントのデプロイメントの再考について議論を始めました。 この間、私たちはNetflixと協力して一つのアイデアを練り上げてきました。今日はそれについてお話ししたいと思います。彼らは懸命に取り組み、大きな進展を遂げ、多くの学びを得ました。
本題に入る前に、簡単な振り返りをさせていただきます。NetflixはAWSを2008年に採用し、初期の成長は少数のAWSアカウントで実現されました。Netflixはこれが持続可能ではないことを認識し、運用とセキュリティのリスクを軽減し、開発者体験を向上させ、ベストプラクティスを採用するために、マルチAWSアカウントアーキテクチャを活用したいと考えました。AWSアカウントは強力な分離境界を提供し、マルチAWSアカウントのデプロイメントにより、関心事の論理的な分離とインパクトの範囲を縮小することができます。 これを踏まえて、NetflixはAWSと協力し、2022年の講演で議論した革新的なアプローチを生み出しました。このQRコードから、まだ見ていない方はぜひご覧ください。
歴史的に見ると、ここに示す上部の三角形は、AWSアカウント、IAMロール、コンピューティングリソースの間で強く結合されており、それには正当な理由がありました。Netflixは以前、少数の大規模アカウントから小規模なアカウントへワークロードを移行しようと何度か試みました。 しかし、コンピューティングリソースを、それらのリソースが関連するすべてのロールやその他の要素と共に移動させることは非常に大変な作業です。ここでNetflixは新しいアイデアを思いつき、AWSアカウントが提供する強力な分離境界を活用しながら、コンピューティングリソースを含むAWSアカウントからIAMロールを切り離すという興味深い技術的アプローチの実現可能性を実証しました。
リスク削減とアクセス効率の向上：新たなアプローチ
これがNetflixの大規模なマルチアカウントAWSの取り組みの礎石となりました。そして、私が出会った中で最も優秀な方々を2人ご紹介したいと思います。彼らは非常に優秀なセキュリティエンジニアのJoseph KjarとPatrick Sandersです。NetflixのCloud InfrastructureチームとCloud Infrastructure Securityチームのメンバーで、これを実現するために多大な努力を重ねてきました。それでは、より詳しく見ていきましょう。Prateek、ありがとうございます。Prateekと一緒に仕事ができることは喜びであり特権です。彼を知る人なら誰でもそれを保証できるでしょう。そして、本日ここにお集まりの皆様にお会いできることを嬉しく思います。このようなトピックに興味を持っていただけるのは珍しい機会です。おそらく、このような話題で本当に興奮していただけるのは、このような場だけでしょう。家族に話すと、たいてい虚ろな目で見られてしまいます。
今日なぜここにいるのか、この実存的な問いの2つ目について話すとき、その多くは現在の問題に帰着します。それは多くのワークロードが同居する大規模な単一アカウントに根ざしています。このようなアカウントを持つと、この図が示すような悲しい結果は避けられません。アプリケーションやワークロード間に意味のないアクセスが発生してしまいます。このようなアカウント設定で、これらの要素間に細かい粒度のセキュリティ分離を作成しようとすることは、非常に時間がかかり、複雑で、まさに苦痛を伴うため、結果としてすべてがすべてにアクセスできる状態になってしまうのです。
ユーザーアクセスは、その上にさらなる複雑さを加える要素です。適切なサイズのアクセス権限を実現することは非常に困難です。そして、私たちのような中央セキュリティチームの場合、対処すべき接点が数多くあります。すべてのリソースに対するポリシー、IAMロールポリシー、信頼ポリシー、そしてユーザーアクセスを管理するポリシーなど、これらすべてを細かく管理しなければなりません。これはもはやスケールしません。この図に足りないのは、パンダから流れ出る涙の滝が巨大な貯水池に注ぐ様子だけですね。もうこれ以上続けられません。この状況には新しいアプローチが必要です。
では、このトークと Netflixの今後の方向性はどうなるのでしょうか？ 願わくば、このような世界を目指したいと思います。PTIは前回お話したように、IAMロールをコンピューティングリソースから切り離すという概念を導入しました。これまで溶接されていたような結びつきを切り離すことで、ここに示すような環境を構築できます。各ワークロードは、専用アプリケーションアカウントと呼ばれる独立したアカウントで動作し、一方で複雑で重要なコンピューティングやネットワークインフラは、現在の場所にとどまります。
すべてのコンピューティングとネットワークを1つのアカウントに集中させる必要があるとは言っていません。そのような誤解は避けていただきたいと思います。重要なのは、ワークロードアプリケーションのIAMロールを分離できれば、柔軟性が得られるということです。必要がなければこれらに手を加える必要はありませんし、必要な場合は、これまでにない方法で整理することができます。そうすることで、コンピューティングとネットワークインフラに関して、非常にエキサイティングな可能性が開けてくるのです。
私たちにとって、これは多くの未知数を含む大きな賭けでした。理論上は素晴らしく聞こえますが、実際にどうやってそこにたどり着くのか？これが過去2年間、私たちが直面してきた課題でした。そして、もし本当にそこにたどり着けたとして、その価値はあったのでしょうか？これは私たちセキュリティエンジニア全員に共通するテーマです。興味深い技術的アイデアを耳にしても、複雑なエンタープライズクラウド環境で大きな変革を推進するのは別の話です。 幸いなことに、それが今日のトークのテーマです。興味深いアイデアとエンタープライズグレードの実装との間のギャップをどのように埋めたのかについてお話ししたいと思います。そして、皆さんがワークロードとアカウント分離戦略について、実行可能なパターンとインスピレーションを持ち帰っていただければと思います。
移行のための技術的基盤：認証情報配信とポリシー管理
走る前に、這い、歩くところから始めなければなりません。先ほどの図のパターンに最初のワークロードを移行する前に、いくつかの基礎的な技術的能力が整っている必要があります。そして最も重要な技術的な要となるのが、アカウントに依存しない認証情報の配信です。 この短いスライドには多くの内容が詰め込まれていますが、PTIが言及した前回のトークでより詳しく説明されています。基本的に、AWS IAMが社内のトークン発行者または証明書発行者を信頼するための方法と、それを活用してワークロードに任意のIAMロール認証情報を配信する方法が必要になります。
EC2のインスタンスをAPIやWebコンソールから起動する際、AWSはそのコンピュートインスタンスに関連付けるロールを選択するよう求めてきます。アカウントに存在しないロールは選択できないため、このような解決策が必要となってきます。私たちは、この問題に対してシンプルなアプローチを選択しました。CloudFrontで前面を守られたS3バケットという非常にシンプルなセットアップを使用して、軽量なOIDCプロバイダーを構築したのです。CloudFrontは、フェイルオーバーバケットを設定できるため、さらなる耐障害性を追加してくれます。S3バケットは、公開されたJSON Web Key SetとOpenID設定をホストするだけです。
これが整えば、各アカウントのIAMサービスでこの軽量なOIDCプロバイダーを信頼するように設定できます。これにより、内部のトークン発行サービスによって発行され、そのOIDCプロバイダーによって署名されたトークンが、AWS IAMの目から見て有効となります。最後のピースがIMDSプロキシです。EC2上のコンテナプラットフォームでアプリケーションコードを実行する場合、AWS SDKsを使用していれば、IAMロールの認証情報を探すためにデフォルトの認証情報プロバイダーチェーンを使用します。私たちは、この戦略の一環としてコードの変更を強制したくありませんでした。アプリケーションの所有者にとって完全に透過的であることを望んでいたのです。そのため、このネイティブな期待される動作を維持することが不可欠でした。そこで、カスタムIMDSプロキシを構築しました。
このIMDSプロキシは、内部で発行されたトークンをSTSのassume role with web identity APIを使用してIAMロールの認証情報と交換し、それらをIMDSプロキシ上で公開します。アプリケーションのAWS SDKが認証情報を探すとき、期待される場所でそれらを見つけますが、見つかる認証情報は今や私たちの管理下にあります。私たちは、望むAWSアカウントにそれらを配置できます。
この問題を解決する方法は他にもあり、これらの代替案の方があなたにとってより適している可能性があります。良い選択肢の一つが、比較的新しいAWSのサービスであるIAM Roles Anywhereです。これをIMDSプロキシや外部認証情報プロセスと組み合わせることで、同様の透過的な認証情報配信を実現できます。KubernetesのIAM roles for service accountsも同様にOIDCベースなので、これも実行可能な代替案となります。
移行前に必要となる2番目の重要な機能は、ターゲットについて考える方法です - どのアプリケーションをターゲットにし、それらをどのようにグループ化して考えるのか？私たちは、移行の複雑さに着目することが非常に有効だと分かりました。各アプリケーションについて、移行の複雑さ、セキュリティリスク、運用リスクという3つの要素を評価しようとしました。セキュリティリスクは高いが移行の複雑さが非常に低いアプリケーションをターゲットにすることで、最大の効果が得られることが分かりました。ここでいう効果とは、労力に対するリスク削減の比率を指します。複雑なアプリケーション1つの移行に1ヶ月かけるよりも、同じ期間でよりシンプルな50のアプリケーションを移行する方が望ましいのです。
これは、どのアプリケーションをターゲットにしてその理由を考える上で、非常に役立つ方法でした。社内アプリケーションに関するメタデータがあれば、とても有用です。例えば、私たちはアプリケーションの特性を追跡しています。そのアプリケーションがインターネットに面しているかどうかや、Video on Demandをお客様に提供するための重要なストリーミングパスの一部であるかどうかなどです。これらの情報は、セキュリティやオペレーショナルリスク、複雑さを判断する際に役立ちます。
最後に、実際の移行を実現するための技術的なコンポーネントが必要になります - アプリケーションやそのアイデンティティを新しいアカウントに移行することです。これには何らかのCDフックが必要になり、このソリューションの中でもビジネスロジックが最も重要な部分になります。皆さんに対して具体的にどうすべきかを推奨するのは難しいのですが、アプリケーションのデプロイやロールバックなどを行うシステムにフックを入れる方法が必要です。最初の移行では、そのフックは単にアプリケーションオーナーへのSlack DMで「再デプロイをお願いできますか？」というメッセージを送るだけかもしれません。
堅牢なアカウントベンディングソリューションが必要です - ボタンを押すだけでAWSアカウントを取得できるようにする必要があります。アカウントベンディングマシンについては、前回の講演で詳しく説明しています。ここで重要な点は、アカウントのプロビジョニングとオンデマンドでの提供だけでなく、誰がこのアカウントを受け取ったのか、誰がオーナーなのか、このアカウントがどのワークロードに関連しているのかといった情報をすべて記録するメカニズムも必要だということです。このために何らかのアカウントインベントリシステムを使用することを強く推奨します。そのようなメタデータをすべて保持するためにアカウントタグを使用することはお勧めしません。OrganizationsのAPIを使用するのは少し面倒で、うまくスケールしないからです。最後に、先ほど説明した新しいクレデンシャル配信メカニズムのオン・オフスイッチが必要です。これにより、新しいクレデンシャル配信の動作とAWSのデフォルトの動作を簡単に切り替えることができます。
データ収集と移行計画：複雑さの評価と自動化
そして後ほど、これらの各要素をスケールアップする方法について説明します。さて、最初の移行に向けて必要なことを多く説明してきました。少し気が重くなるかもしれません。しかし、他の要件を満たすことができれば、やる必要のないことを覚えておくことが重要です。最大のポイントは、多くのクラウドエンジニアを苦しめてきたネットワーク移行という怪物から遠く離れていられることです。ネットワークインフラストラクチャを管理する必要はありません。EC2インスタンスを移動する必要もありません。データストアを移動する必要もありません。作成する各新規アカウントにVPCを拡張する必要もありません。ルーティングルール、Security Group、DNSレコードなどについて心配する必要もありません。リストは延々と続きます。
大規模なマルチアカウント移行を経験した人なら、そこにある多くの落とし穴をよく知っているでしょう。要するに、これらの問題は、ブラウンフィールドやレガシー環境では本当に大きな課題なのです。そのため、移行プロセスを進める中で、これらのことについて考える必要がないのは本当に素晴らしいことです。それでは、アプリケーションの移行における進捗の測定方法について、Patrickに説明してもらいます。ありがとう、Joseph。では、リスクについて話しましょう。あなたの大好きなものですよね？Josephが先ほど示した例に戻って、もう少し詳しく見ていきましょう。
同じアカウント内に3つのアプリケーションがあります。 それぞれのアプリケーションには2つのリソースがあります。アプリケーションロールとリソース間には18のパスが存在します。長年の自然発生的な成長と過度に寛容なポリシーにより、これらのリソース間にはこれだけのアクセスパスが存在していますが、アプリケーションが自身のリソースにのみアクセスする必要があると仮定すると、必要なパスは6つだけです。点線の赤い矢印で示されているものはすべて不要なアクセスパスです。さらに、これらのアプリケーションはすべて同じAWS APIレート制限を共有しています。
Netflixでは、リスクについて話す際によく使う用語がいくつかあります。このシナリオでは、アクセスエクスポージャーとは、アプリケーションロールとリソース間の許可されたパスの数を指します。この例では、最初のアクセスエクスポージャーは18ですが、必要なパスは6つだけです。リスクについて話す際は数字が小さいほど良いので、18より6の方が望ましいのです。しかし、6という数字がどれだけ良いのかをどうやって知ることができるでしょうか？そのために、意図したアクセスと実際のアクセスを比較するアクセス効率を計算します。エクスポージャーが18で、必要なパスが6つの場合、アクセス効率は約33%となります。そして、意図した6つのパスだけを残して他をすべて排除できれば、アクセス効率は100%になります。
1つのアプリケーションが専用アカウントに移行すると、8つのエッジが削除され、そのアプリケーションは独自のAWS APIレート制限を得ることができます。これにより、エッジは10個になります - 新しいアプリケーションのアカウントに2つ（これは望ましい）、マルチテナントアカウントに8つです。この時点でアクセス効率は60%になります。なぜなら、望ましいアクセスエクスポージャーが6で、実際には10あるからです。そこでもう1つのアプリケーションを移行すると、さらに4つのエッジが削除されます。つまり、18から始まって6まで減少し、残っているのは意図したアクセスのみとなります。これでアクセス効率は100%になりました。さらに嬉しいことに、各アプリケーションに独自のAWS APIレート制限を与えることで、ノイジーネイバーの問題も軽減されました。
3つのアプリケーションのうち2つしか移行していないことにお気づきかもしれませんが、同じアカウント内に他のアプリケーションのリソースへのクロスアクセスがなくなったため、リスク削減の効果は既に実現されています。そしてこの間、コンピュートインフラストラクチャには一切手を触れていません。すべて同じ場所にあります。では、これを1000のアプリケーションに拡大してみましょう。各アプリケーションが10個のリソースを持ち、すべて同じアカウントにある場合、1000万のエッジが存在することになります。最初の移行で約2万のエッジが削除されます。次の移行では2万よりは少し小さくなりますが、それでもかなりの数のエッジが削除されます。この減少パターンは移行が進むにつれて続き、リスク削減の効果は徐々に小さくなっていきます。そしてここで、この減衰パターンのために少し直感に反することが分かります。
アプリケーションの半分を移行した時点で、アクセスエッジの4分の3が削除されているのです。このように、移行が進むにつれて限界リスク削減効果は減少していきます。リスクの観点からは、早期の移行の方が価値が高く、リスク削減のレバレッジも大きいのです。しかし、アクセス効率についてはどうでしょうか？半分の時点でも、効率はわずか0.4%です。これは、大規模で複雑なマルチテナント環境で意味のあるリスク削減を達成することの難しさを物語っています。
マルチテナント環境では効率が低い一方で、私たちが移行している専用アカウントではすべて実質的に100%の効率を達成しています。 これはバランスの問題です。多くのアクセス露出を排除していますが、大きなアカウントでの効率はあまり改善されません。ただし、専用アカウントでは素晴らしい効率を実現しています。 ここで注意点がいくつかあります。これは非常に単純化された説明です。実際のリスクを測定するのは非常に難しく、この方法ではそれを完全に把握することはできませんが、私たちの進捗状況を確認する指標としては役立ちます。同様に、ここでは AWS リソースへのアクセスに関する IAM アイデンティティのリスクについてのみ話しており、ネットワークを介した横方向の移動については、それは別の問題であり、ここでは具体的に扱っていません。
このような移行に伴い、ポリシーの更新が必要になります。これはリスクについて話すことの次に好きな作業かもしれませんね。ここで私たちが目指しているのは、これらの専用アカウントにおける開発者の自由度と開発速度を向上させることです。 また、Attribute-Based Access Control を活用してリソースアクセスの制御を簡素化したいと考えています。さらに、開発者のための Infrastructure as Code をサポートしたいと考えています。これは、IAM 権限を厳重に管理しなければならない大規模なマルチテナントアカウントでは、これまで実現が難しかった機能です。
これらの目標を達成するために、Service Control Policy、Resource Control Policy、パーミッションバウンダリー、そして ABAC を組み合わせたシンプルでスケーラブルな方法を採用しています。 アカウントの境界線の強固さと堅牢性により、アプリケーション間の望ましくないリソースアクセスを防ぐことができるため、専用アカウント内でアプリケーションとそのオーナーに広範な権限を提供することが可能になります。組織全体のポリシーである SCP と RCP は、重大な問題を防ぐバックストップとして引き続き使用します。セキュリティ関連のサービスとインフラストラクチャを保護し、権限昇格を防止し、タグ付けのプレフィックスをロックダウンし、リソースのパブリックな露出を制限します。専用アプリケーションアカウントに特有の SCP は、主に VPC 関連のものをブロックするだけです。これは、管理されていないネットワークやコンピューティングリソースの増加を防ぐためです。これらのポリシーは、一般的に組織を安全な運用環境として維持するためのものです。
次に、パーミッションバウンダリーについて説明しましょう。パーミッションバウンダリーには大きな目的がありますが、他にも多くの利点があります。特に、アプリケーションオーナーが独自の IAM ロールを作成・管理できるようにしたいのですが、セキュリティサービスを乗っ取るような権限昇格はできないようにしたいと考えています。これまでは、IAM アクセスを非常に厳しく制限してきました。実際、このプロジェクトまでは、非常に限られたユースケースを除いて、IAM ロールの作成と管理は私たちのチームにのみ許可されていました。また、可能な限り IAM ユーザーは使用しないようにしています - 皆さんもそうすべきです。この新しいアカウント戦略では、パーミッションバウンダリーが適用されている場合に限り、ロールの作成と管理をアプリケーションオーナーに委譲することができます。パーミッションバウンダリー自体は、管理下のすべてのロールに同じバウンダリーを添付する必要があることで、権限昇格を制限します。このバウンダリーでは、これらのロールが組織外のリソースにアクセスすることを防ぎ、アプリケーションオーナーが既存の権限以上のロールを作成できないようにするなどのガードレールを追加することもできます。
Cloud Application Migration Platform (CAMP)：移行オーケストレーションツールの開発
これにより、専用アカウント内のアプリケーションは、リソースポリシーで明示的に許可された場合にのみ、他のアプリケーションのリソースにアクセスできます。スター・オン・スターの権限があっても、アプリケーションはデフォルトでアカウント内の自身のリソースにしかアクセスできません。このように、最小権限には程遠いものの、私たちのリスク許容度に基づいて IAM リスクを適切なサイズに調整することができました。
Attribute-Based Access Controlを使用することで、より汎用的なポリシーを作成し、アプリケーションが移行中および移行後もすべてのリソースにアクセスできるようにすることができます。通常であれば、アプリケーションの移行後のロールにアクセスを許可するようにリソースのポリシーを更新するだけです。しかし、移行プロセスの一部としてそれを行うことは避けたいと考えています。なぜなら、それが移行中に問題を引き起こす可能性があるからです。事前に対応できれば、物事がよりシンプルになります。
具体例を見てみましょう。画面の左側に、特定のロールにアクセスを許可するバケットポリシーステートメントがあります。この移行シナリオには2つの問題があります。移行が完了するまで移行先アカウントのロール、特にアカウントIDが分からないことと、リソースポリシーのプリンシパルが存在していないとAPIによって拒否されてしまうことです。この代わりに、保護されたプリンシパルタグとOUパスに基づいてアクセスを許可するABACベースのステートメントをポリシーに追加することができます。このタグの名前空間はService Control Policyを使用して保護します。
右側の例では、ワイルドカードプリンシパルに2つの条件があります。1つは特定のOUパス内のプリンシパルに制限するもの、もう1つはアプリケーション名「reinvent-app」でタグ付けされたプリンシパルに制限するものです。アプリケーション名タグに対する厳密な制御があれば、このポリシーは「テストOU内のreinventアプリケーションロールにこのバケットへのアクセスを許可する」と解釈できます。別のアプリケーションにこのバケットへのアクセスを許可したい場合は、タグ条件にそのアプリケーション名を追加するだけです。これにより、ポリシーを汎用的に保ち、ユーザーにとって自然な抽象化として機能します。このパターンを使用することで、準備段階の一部として、移行前にリソースポリシーの変更を確実に適用することができます。
IAMパターンが整理できたところで、移行のためのデータ収集と計画に移りましょう。Josephが先ほど述べたように、AWSサービスの使用状況は移行の複雑さを示す良い指標となることが分かりました。S3やSQSのような一部のサービスは、リソースポリシーを更新するだけでクロスアカウントでの対応が非常に簡単です。一方、Route 53、CloudFront、EC2コントロールプレーンAPIなどは、リソースと同じアカウントのプリンシパルからしかアクセスできません。クロスアカウントアクセスをサポートしていないこれらのサービスを使用するアプリケーションは、移行後に元のアカウントのロールを引き受けるようにコードを変更する必要があります。
ポリシーの変更は容易ですが、コードの変更は非常にコストがかかります。これを踏まえて、私たちは3つの複雑さに基づくグループを設定しました。まず、AWS APIを全く使用しないアプリケーション - これらは非常に簡単で、今すぐ移行できます。次に、リソースポリシーを介してクロスアカウントアクセスをサポートするAWSサービスを使用するアプリケーション - これらのアプリケーションは、先ほど示したABACポリシーによる単純なリソースポリシーの更新で移行できます。最後に、クロスアカウントアクセスをサポートしていないAWSサービスを使用するアプリケーション - これらはコードの変更が必要です。移行候補をグループ化するために、2つの似て非なるデータニーズがあることが分かりました。アプリケーションがアクセスするAWSサービスを知る必要があり、移行自体のために、各アプリケーションがアクセスするAWSリソースを知る必要があります。前者はサービス、後者はリソースです。サービスは簡単で、各ロールに対してIAM generate service last access infoを呼び出し、その結果を保存します。後者は、特に大規模な場合により困難です。管理呼び出しについては、CloudTrailから大規模にその関係性を導き出すことができます。
私たちはアプリケーションがどのBucketにアクセスしているかを把握するためにS3アクセスログを使用しています。そこで問題に直面したのですが、通常であればCloudTrailのData Eventsを有効にすれば良いのですが、これがかなり高額になってしまいます。実際、S3とSQSのData Eventsを有効にするだけでAWS料金が約15%増加すると試算しました。しかも、私たちの請求額は既にかなりの金額なのです。
この問題を回避するため、私たちはカスタムのAWS SDKインストルメンテーションを開発し、APIコールを検査して使用状況データを集中ログプラットフォームに送信しています。私の同僚たちがre:Invent 2022でこれについて素晴らしい講演を行いました。後で視聴したい方のために、そのコードも公開されています。このSDKインストルメンテーションから得られるデータを分析して、アプリケーションがアクセスしたリソースのマッピングを生成しています。さらに、Continuous DeploymentプラットフォームからアプリケーションとそのIAMロールのマッピングも取得しています。また、インターネットに面しているかどうかの重要度や、機密データを扱うかどうかなど、アプリケーションに関する他のメタデータも収集しています。これらすべてを組み合わせることで、必要なリソースポリシーの変更点や、リソース間の相互作用について良く理解することができます。
このデータを収集し始めると、第1グループと第2グループが私たちのアプリケーションの大部分を占めていることが分かりました。実は最も複雑な移行が必要なのは最小のグループだったため、それは後回しにすることにしました。より大きくてシンプルなグループに自動化の取り組みを集中させることで、より効果的にリスクを削減できます。第1グループは変更が不要で、すぐに進めることができます。第2グループは、主にリソースポリシーの変更という簡単な修正で移行できます。先ほどのグラフで見たように、この時点でアクセスの露出をかなり削減できており、より複雑で長期間マルチテナントアカウントに留まる必要のあるアプリケーションにとって、より安全な環境を実現できます。
ここまでで、移行の基本、リスクに基づく進捗測定の考え方、いくつかのIAMパターン、そしてデータの取り扱いについて説明してきました。ここでJosephに戻したいと思います。ここまでお分かりの通り、移行したい各アプリケーションに対してこれらの要素を手作業で組み合わせるのは大変な作業です。そこで私たちは、この作業を支援する移行オーケストレーションツールの開発を決定しました。私たちはこれをCloud Application Migration Platform、略してCAMPと名付けました。
プロジェクトの成果と学んだ教訓：数字で見る移行の実績
ご覧の通り、これが主な機能です。基本的に、これは私たちの移行状態に関する内部的な信頼できる情報源です。どのアプリケーションが未着手で、進行中で、完了しているのか、どのアプリケーションのどの環境が完了しているのか、そしてアプリケーションオーナーに代わってどのようなタスクを実行したのかを示してくれます。また、対象となるアプリケーションがシンプルなカテゴリーに属するのか、手を付けるべきでないものなのかも教えてくれます。さらに、SpinnakerなどのContinuous Deploymentプラットフォームとの統合も、すべてここで一元的に行っています。
CAMPのもう1つの重要な側面は、私たちの活動の安全性を確保するために行うバリデーションです。 Patrickがデータ収集について話していましたが、そのデータは2つの場所に保存されています：私たちのBig Data PlatformとCAMPが読み取るS3バケットです。これらのデータソースは主に、SDKテレメトリー、各アプリケーションが使用しているAWSサービスに関するIAMのlast accessed情報、そして各アプリの様々な特性を含む社内のアプリケーションメタデータです。アプリケーションは日々変化する生き物なので、それらの変更に対応する調整プロセスを持つことが非常に重要です。例えば、今日はAWS APIを全く使用していないアプリケーションが、明日になってS3とSQSを使い始めるかもしれません。
そうなると、移行の複雑さは変わってきます。Route 53を使い始めると、さらに複雑さが増します。CAMPの仕事の一つは、1時間ごとにこのデータを取り込み、アプリケーションに関するすべての情報を更新することです。変更があれば即座に把握し、それに応じて移行計画を調整します。
次は、私たちのContinuous Deployment プラットフォームであるSpinnakerとの統合についてです。 ここで、先ほど話したアプリケーションの再デプロイ、新しい認証情報配信の仕組み（IMDSプロキシ）のオン・オフ切り替え、再デプロイ時に問題が発生しないようにアプリケーションの健全性をモニタリングし、必要に応じてロールバックを行うといった機能を組み込んでいます。ここで重要なのは、移行ツールに機能を実装するのではなく、CDプラットフォームの既存機能をできるだけ活用するということです。デプロイとモニタリングについては、CAMPで独自にプロセスを実装するよりも、Spinnakerの機能に依存する方がはるかに堅牢です。私たちの実装では、Spinnaker側での変更をIMDSプロキシのトグルだけに限定することができ、それが唯一変更が必要だった部分でした。他のすべてはオーケストレーションツール側で対応できました。
アカウント管理は移行プロセスの重要な部分となります。興味深いのは、CAMPはこれに直接関与しないということです。そしてそれは一般的に良いアイデアだと考えています。アカウントの払い出しプロセスやプロビジョニングプロセスは、単一の移行作業によって主導されるのではなく、独立した堅牢なものであるべきです。移行作業を円滑にするために何らかの変更が必要になるかもしれませんが、これを独立したプロセスとして維持することは良いパターンだと考えています。私たちのシステムでは、Spinnakerが各アプリケーションやワークロードに対して、関連するアプリケーションのコンテキストを提供しながら、Account Vending MachineにどのようなIAMロールを使用すべきかを問い合わせます。すると、Account Vending Machineは、アカウントインベントリを使用してそのアプリケーションにマッピングされているアカウントを見つけるか、プールから新しいアカウントを取得し、アカウントタグの追加や必要に応じて新しいOUへの移動など、AWS Organizationsで必要な更新を行い、ロール情報をSpinnakerに返します。これが、アカウントの払い出しからIMDSプロキシが認識できるところまで、最終的なロールの割り当てが行われる仕組みです。アカウントインベントリを使用することで、作業がとても簡単になりますよ。
最後に、このシステムとやり取りする方法が必要です。 どのようなオペレーター体験を目指すのでしょうか？それは主に2つに集約されます：先ほど説明したカテゴリーと基準に基づいて移行対象のリストを生成すること、そしてCAMPに移行を指示して後は手を離すことです。私たちは飲み物でも飲んでリラックスしながら、CAMPに重い作業を任せたいのです。そのために、CAMPのシンプルなAPIと、後で説明するバリデーション層を構築しました。CAMPにアプリケーションの移行を指示すると、先ほど説明したすべての要素を活用します。適格性データや複雑さのデータを参照して、どのリソースポリシーを更新する必要があるかを判断し、適切なリソースにABACポリシーを適用します。Spinnakerと通信してIMDSプロキシのトグルと再デプロイのタイミングを伝えます。これは移行作業なので、新しいアカウントの払い出しとそのアプリケーション用のロールの取得も行います。そして再デプロイ後は、システムが健全な状態を維持しているかモニタリングし、問題があれば通知を受け取ります。
検証に関しては、多くの場面で問題が発生する可能性があり、大量のアプリケーションを一括で処理する場合、環境に重大な影響を及ぼす可能性があります。CAMP APIに実装した非常に有用な検証チェックには、ターゲットが適格なグループに属しているかの確認が含まれています。アプリケーションが前日には使用していなかったサービスを使用するようになり、安全でなくなるような状態変化が発生した場合、CAMPにそのターゲットを送信しても、操作は拒否されます。
また、本番環境をテスト環境より先に移行しようとしていないかもチェックします。アプリケーションが複数の環境にデプロイされている場合があり、すべてのテスト環境のデプロイメントが完了して安定していることを確認せずに本番環境を移行すると、不要な影響を引き起こす可能性があります。さらに、アプリケーションが適格で、テスト環境の移行も完了し、すべてのチェックが問題なく通過したとしても、本番環境のデプロイメントでEC2インスタンスに問題がある場合はどうでしょうか？そこには何か問題が発生している可能性が高く、インフラの健全性に問題がある時点でリデプロイを行うと、問題をさらに悪化させる可能性があります。これは、問題をより深刻化させないために実装した別のタイプの検証です。
これで一連の仕組みについて見てきましたが、ここからはPatrickが学んだ教訓と数字についてまとめます。私たちが得た教訓として、アプリケーションオーナーの関与を最小限に抑えた設計が大きな成果を上げました。期待していた効果は現実のものとなりました。多くの未知数を抱えながら大きな賭けに出ましたが、セキュリティの向上、運用の安定性、プラットフォームの柔軟性という面で成果が出ています。このUXのメリットにより、専用アカウントへの自発的な需要が生まれています。ユーザーは自分たちのアプリケーションを移行したいと考え、私たちに依頼してくるようになっています。
特にセキュリティチームとエンジニアリングチームからの組織的な支持とコミットメントは、私たちにとって最も助けになった要素の一つです。このようなプロジェクトに着手する場合、これを最優先事項とすべきです。というのも、大きな障壁やパートナーシップの課題に直面することになり、トップの支援が必要になるからです。また、これは多大な労力を要する作業でした。JosephとI私の2人を中心に、このプロジェクトに3年ほど取り組んできました。振り返ってみて、もう一度やるかと聞かれれば、間違いなくイエスです。いくつかの点は変えたいと思いますが、全体的なソリューションには本当に満足しています。
変更したい点としては、できるだけ早く移行のフィードバックループに入ることです。最初の移行の前にCAMPを完璧にしようとしすぎて、それが大きな遅延要因となりました。可能であれば、同時に多くの他のことを行わず、この取り組みに専任のヘッドカウントを割り当てることです。私たちのチームは忙しく多くの業務を抱えていたため、それができず、かなりの遅れが生じました。特にリソースと人員が限られているプロジェクトの場合、プロジェクトマネジメントの渦に巻き込まれないようにすることが重要です。これも遅延の原因となります。同様に、外部依存関係は最小限に抑えるべきです。これらはすべて、プロセスに足を取られ、組織間のコミュニケーションに苦心する原因となるだけです。
いくつか数字をご紹介しましょう。Netflixのユーザーの皆様が日頃利用されているサービスの多くを移行しました。具体的には、405のアプリケーションと1,100以上のIAM Roleを移行しました。 並行して処理した最大のバッチは現在進行中のもので、277件です。このバッチまでは障害件数はゼロでしたが、今は1件となっています。それでも、これは非常に成功的な結果だと考えています。私たちも人間であり、ミスを犯すことがあるということをお見せできたと思います。幸い、この障害は最小限に抑えられ、社内チームのサービスに影響が出ただけで、Netflixユーザーへの影響は全くなく、Netflix開発チームへの影響もほとんどありませんでした。
以上で発表を終わります。AWSのアカウントチームには本当に感謝しています - 彼らは素晴らしく、彼らの協力なしではこのプロジェクトを実現できませんでした。過去から現在に至るまで、NetflixのCloud Infrastructure Securityチームは一緒に働くのが本当に素晴らしい仲間たちです。会場でご視聴の皆様、オンラインでご視聴の皆様、ありがとうございました。いいねとチャンネル登録をお忘れなく。それでは質疑応答に移りたいと思います。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion