re:Invent 2024: ULAとAWSがGovCloudでのIDとコンプライアンス管理を革新
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - ULA accelerates innovation by lowering cloud compliance risk at scale (AES309)
この動画では、United Launch AllianceとAWS Professional Servicesによる、GovCloud環境でのアイデンティティ管理とコンプライアンスへの革新的なアプローチが紹介されています。ULAのロケット打ち上げ事業における100%の成功率という実績を背景に、クラウド導入における課題、特にユーザープロビジョニングの複雑さと最小権限の定義の難しさに焦点を当てています。Service Control Policies、Identity Policies、Boundary Policiesを組み合わせたEffective Permissionsの実装方法と、「Principle of Leash Privilege」という独自の考え方を用いて、セキュリティを確保しながらプロビジョニング時間を数日から数分に短縮した具体的な取り組みが説明されています。また、AWS IAM Access Analyzerを活用したCLIツールの開発など、実践的な解決策も詳しく解説されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
ULAとAWSによるGovCloud環境でのIAM管理セッション紹介
よし、それでは始めましょう。United Launch AllianceとAWS Professional Servicesによるセッション「AES 309」へようこそ。このセッションは主に、高度に規制された GovCloud 環境をご利用の方、あるいはそのような環境で苦労された経験のある方を対象としています。ただし、該当しない方でも心配はいりません。これからお話しする内容やフレームワークの概念は、Commercial側でもほぼ同じように適用できますし、その点については途中で触れていきます。始める前に運営からのお知らせですが、質疑応答の時間は最後に設けていますが、会場の規模と参加者数を考慮して、オフラインでの対応とさせていただきます。次のセッションがありますので、終了後はステージか廊下で対応させていただきます。
まずはチームの紹介をさせていただきます。私はJeff McLainで、United Launch Allianceのクラウドセキュリティアーキテクトです。 Bryan Gunterです。AWS Professional Servicesのシニアコンサルタントとして勤務しています。こんにちは、Cody Hartmanです。United Launch AllianceでCloud Engineerとして働いています。re:Invent 2024の素晴らしい週の幕開けに、皆様にお越しいただき、ありがとうございます。まず、今週最初のセッションという方は手を挙げていただけますか？...あまり良いスタートとは言えませんね、ここから始めるべきでしたよ。それから、この1時間AIの話を聞かなくて済むことを楽しみにしている方は？
United Launch Alliance（ULA）の事業概要と宇宙ミッション
それでは、アジェンダを見ていきましょう。ULAが、GovCloud環境におけるアイデンティティ管理とコンプライアンスに対して、私たちが革新的だと考えるアプローチをどのように採用し、かつてない速度でイノベーションを実現してきたかについてお話ししたいと思います。この機能的な特権アーキテクチャを使用することで、高いセキュリティ基準とコンプライアンス態勢を維持しながら、プロビジョニング時間を数時間あるいは数日から文字通り数分にまで短縮することができました。しかし、それらの詳細やIAM王国の鍵をお渡しする前に、 ULAのミッションと具体的な事業内容について少しお時間をいただきたいと思います。
ULAは実は2006年に、Lockheed MartinとBoeing Space Companyの合弁事業として設立されました。簡単に言えば、私たちは様々な商業用および政府用ミッションをサポートするためのロケットを製造し、打ち上げています。製造はすべてミシシッピ川へのアクセスが良いAlabama州のDecaturで行っています。この施設だけでも約300エーカー、つまり長さ約800メートル、幅約400メートルの広さがあり、常時約20機のロケット製造を管理しています。工場を出たロケットは、 R/S RocketShipに積み込まれます。そして2026年には新しいRRS Spaceshipが加わります - 気の利いた名前でしょう？ロケットは積み込まれた後、FloridaのCape Canaveral、もしくはCaliforniaのVandenberg Space Force Baseまで海上輸送され、そこで垂直統合施設で組み立てられ、打ち上げの準備が行われます。
ロケットに搭載されるペイロードは様々な目的を持っています。太陽系の探査を行うものもあり、最近の注目すべき成果としては、Mars Perseverance Roverがあります。また、米国による火星ミッション20件すべてがULAのロケットで打ち上げられました。NASA Solar Orbiterも私たちが打ち上げました。現在のAtlasシリーズと最近引退したDeltaシリーズのロケットは、宇宙探査の黎明期にまで遡る歴史と伝統を持っています。写真には、1962年にJohn Glennが初期のAtlasロケットで打ち上げられたFriendship Seven Mercuryカプセルの前に立っている様子が写っています。
私たちは世界をつなぐ役割も担っています。ここre:Inventの場で触れないわけにはいきませんが、Amazonは、ULAをProject Kuiperのローンチプロバイダーの一つとして提携しています。このプロジェクトは、世界中の通信環境が整っていない、あるいは十分でないコミュニティに、高速で手頃な価格のブロードバンドインターネットを提供することを目指しています。 また、私たちのペイロードは、最も正確な気候データを使用して気象予測を行い、多くの命を救うことにも貢献しています。しかし、私が最も誇りに思っているのは、私たちの軍人の方々のために行っている仕事と提供しているサービスです。正確な位置情報や、彼らの安全を確保し、最も重要な無事な帰還を可能にするために必要な情報を提供しています。
これまでに合計163のミッションを実施し、100%の成功率を達成しています。これも私たちが誇りにしていることの一つです。 ULAでは、100%の成功率でロケットを打ち上げています。
私たちは、他社にはできない宇宙船を打ち上げるためのロケットを設計・製造しています。 すべてのロケットが同じというわけではありません。業界で最も経験豊富で信頼性が高く、正確な打ち上げプロバイダーとして、United Launch Allianceは 比類のない価値を提供しています。私たちは毎日、命を救い、宇宙を探査し、世界をつなぐという使命を果たすために働いています。Vulcanロケットの導入により、 ULAは、より高性能で、よりコスト効率が高く、世界で唯一の高エネルギーアーキテクチャを持つ ロケットで、いつでも、どんなペイロードでも、どんな軌道にも投入できる、新しい宇宙時代に突入します。絶え間ない改善への意欲と、卓越性への私たちのコミットメントが、ULAを形作っているのです。
ULAのクラウド導入における課題とアプローチ
18年以上にわたってロケットを打ち上げてきましたが、特にクラウドの導入とクラウドジャーニーに関して、皆さんが経験された、あるいは現在経験している多くの課題と同じような課題に私たちも直面してきました。 私が約1年半前にULAに入社した時、私たちのクラウドジャーニーは まだ初期段階でした。最初のアカウントを設定したばかりで、Cloud Center of Excellenceの構築を始めたところでした。私たちが直面した最も緊急の課題の一つは、ユーザープロビジョニングの複雑さとそれが業務に及ぼす影響でした。プロビジョニングに何時間も、時には何日もかかり、大幅なダウンタイムと生産性の低下を引き起こし、その結果、私たちに大きな損失をもたらしていました。
特に、今日お話しするアイデンティティコンポーネントに関して、スケーリングが大きな課題となっていることがわかりました。 また、最小権限の定義が困難であることも判明しました。これは主に、フライトコンピュータやその他のロケットコンポーネントのソフトウェア開発から、工場の現場の技術者まで、ユーザーベースが多様であることが原因でした。さらに、プロセスの初期段階で採用されたリフト＆シフトとオンプレミス的な考え方により、ワークロードの管理が困難になっていました。 加えて、ユーザーベース全体にクラウドの知識が不足していたため、初期段階で直面したこれらの質問や問題に対処することが困難でした。
このような問題にどのようにアプローチすればよいのでしょうか？私たちは、環境とユーザーベースをより深く理解するため、まずポリシーの詳細な分析から始めました。クラウドで何を使用しているか、どのように使用しているか、課題は何か、そして今後クラウドをどのように活用していきたいと考えているかについて、ユーザーやチームリーダーと広範な議論を重ねました。成熟度に関係なく、どのようなプログラムでも、このプロセスにおけるユーザー教育は極めて重要でした。アーキテクトとして、ユーザーとの対話は非常にエキサイティングなものでした。なぜなら、マネージドサービスやサーバーレステクノロジーといったコンセプトを紹介し、ワークロードの可能性やクラウドがもたらすメリットに気付いていく彼らの熱意を目の当たりにできたからです。
私たちは、ユーザーアカウントやサービス承認を含むリクエストプロセスに大きな非効率性があることを特定しました。これらは重大なボトルネックを引き起こしていました。私たちは、野放しになっていたスター権限の整理を開始し、制御を改善するためにより多くの条件付きアクセスを実装し始めました。当初、Role-Based Access Controlを使用してULAのDeveloper、Engineer、Data Scientistの意味を定義し、このプロセスを標準化できると考えていました。しかし、権限が広すぎて最小権限とコンプライアンス要件を満たさないか、あるいは制限が厳しすぎて、特にDeveloperやEngineeringチームがSprintを進めるにつれて数週間ごとに見直しが必要になるという問題に直面しました。これは全員にとって大きな課題となり、Architecture Communityと共に異なるアーキテクチャのアイデアに取り組むことになりました。
このArchitecture Community Practiceは、CCoEの機能横断的なサブグループです。私たちはより多くの支援と異なる視点が必要だと認識しました。そこで、AWS Professional Servicesのパートナーや友人たちに協力を仰ぎ、最終的に私たちのFunctional Privilegeモデルとアプローチとなるものについて話し合いました。
Effective Permissionsモデルの構築と実装
ありがとうございます、Jeff。United Launch Allianceに参加できたことを光栄に思います。彼らの重要なミッションに関わることができ、とても素晴らしい経験でした。今日皆さんとお話できることを大変嬉しく思います。なぜなら、これは多くのお客様が直面している問題だからです。私は多くのお客様と仕事をさせていただく機会に恵まれていますが、これは何をしているかに関係なく難しい課題です。オンプレミスだけの環境でも、他のクラウドプロバイダーを使用している場合でも、AWSを使用している場合でも、開発チームに開発を任せながら、最小権限の原則に従ってアイデンティティに権限を付与する方法が課題となります。
組織内の典型的なグループを見てみましょう。ビジネスを存続させることに重点を置くSecurityチームがいます。彼らはデータソースをロックダウンし、脆弱性を防ぎ、ビジネスを保護するための素晴らしい取り組みを行いたいと考えています。一方で、Developmentチームがいます。Developmentチームは迅速に行動し、物事を壊すことも厭いません。おそらく、それが私たちの多くがre:Inventに参加している理由でしょう。最新のテクノロジーを学び、最先端の技術に触れていたいのです。
よくあるシナリオをご紹介します。開発チームが新しいAWSアカウントを手に入れて、セキュリティチームに「権限が必要なんですが、このアカウントにアクセスするためのポリシーを書いてもらえませんか？」と相談に行きます。セキュリティチームは「どんな権限が必要なんですか？」と尋ねます。開発チームは「分かりません。AWSを使ったことがないので、必要な権限なんて分かるはずがないじゃないですか」と答えます。すると、セキュリティチームは「アクセス拒否です。残念でした」と言います。では、この行き詰まりをどうやって打開すればいいのでしょうか？開発者が素晴らしいものを開発できるようにしながら、組織の安全性とビジネスの継続性を確保するにはどうすればよいのでしょうか？
最初のステップは、Effective Permissionsと呼ばれるものです。これが私たちのソリューションの出発点となります。3つの柱は、Service Control Policies、Identity Policies、Boundary Policiesに基づいています。このVenn図で、3つが重なり合う中心部分が、実効的な権限となります。これらのポリシーに馴染みがない方も大丈夫です。これから一つ一つの意味について詳しく見ていきましょう。
ULAでは、この図の左上にLZA Pipelineがあります。これはLanding Zone Acceleratorと呼ばれるAWSソリューションです。LZAはガバナンス、セキュリティ、そしてオプションでネットワーキングのプロビジョニングなど、様々なことができます。今日は、Boundary PoliciesとService Control Policiesをどのようにデプロイできるかという一部分についてお話しします。右側にOUがありますが、これはOrganizational Unitのことで、Service Control PolicyはLZAを通じてAWS Organizationsに接続されています。
私たちのDev、Test、Prodアカウントでは（アカウントの設定方法は組織によって異なるかもしれませんが）、Boundary Policiesが異なるロールに紐付けられています。左下にはAWS IAM Identity Centerがあります。これはアイデンティティ管理サービスで、Active DirectoryなどのサードパーティのIdentity Providerと連携することができます。ULAではそのように運用しています。仕組みとしては、IAM Identity Centerで定義されたPermission Setがあり、これらのPermission SetにはIAMポリシーが含まれています。これらが全て機能すると、異なるアカウントにロールがデプロイされます。従業員やユーザーがログインすると、バックグラウンドでこれらのロールが割り当てられます。これが、これらのポリシーがどのように定義され、どこから来るのかという問題の核心部分です。
セキュリティチームと開発チームの項目が、この問題の本質に迫ります。これは難しい部分なので、Identity Policies、Service Control Policies、Boundary Policiesについて、一つずつ見ていきましょう。ここでの例では、緑色のグラフィックは何かを実行できることを示し、赤色は実行できないことを示しています。
最初のレイヤーは、Identity Policyです。AWSを初めて使い始めた時に馴染みがあるのは、このIAM Policyでしょう。これは、異なるリソースに対して実行できるアクションのリストを定義し、オプションで条件を付けることができます。この例では、大きな緑色の部分で示されているように、これはPower User Identity Policyのようなものになります。
次のレイヤーでは、Service Control Policies（SCPs）を追加します。SCPについては、いくつか重要なポイントがあります。まず、SCPは非常に強力です - SCPとBoundary PolicyやIdentity Policyの間で競合が発生した場合、常にSCPが優先されます。SCPはRoot Userにも影響を与えます。Organizationを立ち上げる際は注意が必要です。というのも、Management AccountにはSCPを実装していないため、企業全体をロックアウトする可能性があるからです。Management Accountへのアクセス権を付与する相手は非常に特権的な役割を持つことになるので、慎重に扱う必要があります。
背景が依然として緑色であることにお気づきでしょう。デフォルトでは、OrganizationのSCPを設定すると、デフォルトSCPが適用され、ULAでも現在これを使用しています。デフォルトSCPではすべてが許可されています。このデフォルトを解除して、SCPを許可ベースのみにすることもできます。私たちがULAで行っているのは、SCPを使用して、セキュリティポリシーフレームワークを明示的で的確な拒否ステートメントを通じて実装することです。例えば、開発者がInternet Gatewayを立ち上げたり、適切なタグ付けなしでEC2インスタンスを作成したりすることを防ぐといった具合です。これがULAでのSCPの実装方法であり、企業レベルでセキュリティフレームワークを実装するのに役立っています。
3番目の最後のレイヤーは、Boundary Policyです。これはSCPとは逆の関係にあるようなもので、Boundary Policyで定義したものはすべて許可されます。組織が検証し承認した20のサービスを開発者が使用できるようにBoundary Policyで定義し、確信が持てない新しいサービスは単に除外しておけば、自動的に制限されます。図では、この楕円形の内側が許可される領域で、外側は許可されない領域です。これにより、赤い背景は私たちのセキュリティポリシーに違反する行為を示し、開発者はLambdaやECSなど、必要なものを使用できる緑色の領域を持つという興味深いシナリオが生まれます。そして、セキュリティチームは初めからセキュリティ上の危険性を心配する必要がありません。
これをどこで実装すべきでしょうか？すべてのアカウントにPower User Policyを展開することは、決してお勧めしません - それは大きな間違いです。状況は異なるかもしれませんが、右側にOnboarding Accountと呼ばれるアカウントがあります。考え方としては、開発者がOnboarding Accountに入り、1ヶ月なり必要な期間なり、そこで作業を行います。彼らが作業を行っている間、CloudTrailが彼らの行動を記録し、IAM Access Analyzerを使用して、彼らが実際に何を行い、どのようにIAM Policyを決定できるかを判断することができます。
この後Codyが詳しく説明しますので、私からは控えめにしておきます。基本的な考え方としては、オンボーディングアカウントにはPower User Roleが設定され、Service Control PoliciesとBoundary Policiesが実装されていて、権限の昇格を防止します。これで良いスタートが切れます。では、このあとJeffに交代して、ULAでの実装についてさらに詳しく説明してもらいます。
Functional Privilegeモデルの開発と実装プロセス
ありがとうございます、Brian。Effective Permissionsは、私たちが抱えていた問題に対する非常に効果的なアプローチでした。というのも、やや広範なIdentity Policyを使用する自由を確保しながら、要件を満たすために必要なセキュリティコントロールも提供してくれたからです。しかし、私たちはEffective Permissionsを超えて、新しいものを作り出す機会も見出しました。AWSのツールとULAのスクリプトを活用して、現在私たちが「Functional Privilege」と呼んでいるものを開発したのです。
Brianが説明した実装の観点から見ると、技術的な側面と非技術的な側面の両方があります。非技術的な面から始めると、まず私たちは有効化組織としてのCloud Center of Excellenceを通じて、オンボーディングアカウントの可用性、機能、目的を広く周知しました。開発者たちにそこで作業を始めてもらい、今後必要なものを理解してもらうことが非常に重要だと考えたからです。また、先ほど話した Architecture グループとも連携しました。なぜなら、そこでの機能の一つが、標準やポリシーを作成するためのクロスファンクショナルグループを活用することだからです。
サービス承認プロセスは、特に目新しいものではありません。環境に導入する前に承認を得るというのは、特にGovCloudの場合、皆さんも実施していることと思います。幸いなことに、私たちは私が着任する前から、これを最初から実施していました。しかし、これは基盤となり、おそらく最も重要な要素となって、このようなフレームワークを高度なセキュリティの確信を持って実装することを可能にしました。
新しいサービスのリクエストを受け取ると、セキュリティチームに送られ、そのサービスについて可能な限り詳しく調査を開始します。必要となるすべてのコントロールを書き出し、最終的にCSOの承認を得るための文書にまとめます。エグゼクティブサマリー、サービス概要、提案された使用事例、そして共有責任モデルに関する考慮事項（レジリエンシー、アイデンティティ、暗号化、それぞれの責任など）を含めます。
CSO（最高セキュリティ責任者）によってそのドキュメントがレビューされ承認されると、Brianが説明したLZA Pipelineを使用して、すべてのアカウントに対してPermission Boundaryポリシーの実装を開始できます。そうすれば、Permission Boundaryが各サービスに対するAllow Listとして機能するため、新しいサービスの利用が可能になります。私たちは通常、サービス全体を承認するようにしています。つまり、ポリシーにservice:*と設定することができ、Permission Boundaryとしてそれで問題ありません。ただし、セキュリティチームと特定のサービス機能について、まだ完全には安心できないという議論になることもあります。
Identity Policyでより細かい制御が可能であり、同様にBoundary Policyでもそれが可能なので、本当に厳密に制限することができます。
次に、BrianがService Control Policies（SCP）について説明した際に触れた、標準化されたBlock Listとしての機能についてです。繰り返しになりますが、これは特権の昇格やログの削除など、ユーザーや企業に害を及ぼす可能性のある操作を組織全体で防止するものです。私たちは政府請負業者としてCUIデータを扱っているため、インターネットゲートウェイの管理は最も重要な課題の一つと言えます。
この特権管理へのアプローチから、私たちは「Principle of Leash Privilege」という言葉を生み出しました。これは実際、Codyが標準化文書で述べたコメントから生まれました。言い換えると、ユーザーに自由に探索させながらも、必要に応じて制限を強められる紐（リーシュ）のようなもので、道路に飛び出すことは防ぐという考え方です。私の個人的な見解では - 他のメンバーは異論があるかもしれませんが - このセッションで何も覚えていられないとしても、Principle of Leash Privilegeだけは覚えておいてください。これが全てを要約しているからです。
冒頭で述べたように、このIdentity管理戦略を実装することで、セキュアなユーザーオンボーディングを自動化しながら、より優れたRole-Based Access Controlを使用することが可能になりました。この自動化とツールについて、さらに詳しく説明するために、私の尊敬する同僚のCody Hartmanを紹介したいと思います。「Jeffさん、私のことを尊敬するなんて言わないでください。でも、お褒めの言葉は頂戴しますよ」
IAMポリシー生成のためのCLIツールの開発と活用
さて、ここからが本題の楽しい部分についてお話しします。 主に、これまで説明してきたポリシーを構築するために使用しているツールについてです。その前に、Jeffが話していた組織全体の同意を得たガバナンスと戦略の重要性を強調しておきたいと思います。適切な戦略がなければ、ツールは役に立ちません。また、IAMポリシーの基盤となるアーキテクチャ、適切なSEP、Permission Boundaryなど、これらの基盤はツールよりもはるかに重要です。なぜなら、これらがツールの在り方を決定するからです。
ここで質問ですが、IAMポリシーを一から作成した経験のある方は手を挙げてください。私たちが2年前に開発者との協業を始めた時、彼らがどのサービスを使いたいのかを確認し、それをポリシーに実装し、そして実は他のサービスも必要だということを発見するという作業を行っていました。AWS Managed Policyの使用も検討しましたが、問題は「」「」のような広範な権限設定になってしまうことでした。コンプライアンスのために目指している最小権限の機能を実現しようとすると、より細かな制御が難しく、開発者の作業を妨げてしまう結果となりました。
ここで私たちは、開発者がイノベーションを起こせるような方法を考え始めました。そこで重要になってくるのが戦略であり、基盤であり、そしてポリシーを手動で作成・デプロイすることなく、AWSアカウントでイノベーションを行う開発者とより迅速なサイクルで連携できるようにするためのツールです。 ツールを検討する際、少なくとも私の視点では、最初に見るのはAWSです。ここでCommercialという言葉を使っていることには意味があり、後ほど説明します。AWSのサービスを検討する際、私たちは最小権限のポリシーを生成できる他のサービスと連携可能なサービスを探していました。多くの方がご存知だと思いますが、AWS IAM Access Analyzerがあります。まだ使用したことがない方は、ぜひ検討してみてください。IAMだけでなく、S3やCloudTrailなど、多くのサービスと統合されており、その使用状況に基づいて最小権限のポリシーを生成することができます。
私たちのユースケースでは、特にIAMに注目していました。私たちが実現したかったのは、あるロールが実際に使用しているサービスを把握することでした。Bryanが話していたOnboarding Accountに関連して、開発者により自由な環境を提供し、そこでのアクションやリソースの使用を把握して、すべての権限を与えるのではなく、実際に使用しているものを特定できるようにすることです。そこでIAM Access Analyzerを活用しました。アカウントに存在するアクションに基づいて、新しいロールとポリシーを生成したいと考えました。アクセスレポートと呼ばれるものを基に、アカウントでのアクションを発見していきました。
IAM Access Analyzerには、最後にアクセスされたサービスとその時期を示すAPI機能があり、これは非常に重要な機能です。しかし、Jeffが話したように、私たちはGovCloud側を使用しており、新しいロールとポリシーを生成する機能がまだGovCloudに導入されていないという問題に直面しました。ここで私たちは、 ツールの実際の姿と、この機能をどのように補完できるかを詳しく検討する必要がありました。私たちは、先ほど説明した機能的な権限を実装できるスケーラブルなポリシー生成の方法を探っていました。
左側を見ると、このツール群がどのようなものか、そして実際にどのように使用したいのかを詳しく分析しました。私たちはこれらをCLIツールとして作成することを決めました。EventBridgeが新しいポリシーやロールが使用されるたびにLambda関数を起動する方法もありましたが、私たちの場合、開発者向けのCI/CDパイプラインがあるため、柔軟性を重視しました。CI/CDパイプラインに統合する機会を得たいと考え、また手動でツールを実行することも可能にしたかったのです。これがCLIツールを作成した大きな利点でした。将来的にはLambdaレイヤーに組み込んでLambda関数として実行することも検討していますが、基本的な機能は既に揃っています。
次に検討する必要があったのは、CloudTrailログとService Last Accessedレポートからポリシーを生成するIAM Access Analyzerから必要な機能でした。右側のモデルを見ると、ユーザーとどのように対話したいかというサイクルを構築しています。Onboardingアカウントでユーザーがアクションを生成します。最初は、コンソールでEC2インスタンスを起動したいと考えるかもしれません。それらのアクションを記録し、より多くのサービスを使用するようになるにつれて、CLIツールでそれらのアクションを捕捉します。CloudTrailとロールレポートからモニタリングして取得し、Onboardingアカウントでの作業が完了し、より恒久的な環境に移行したい場合は、それらのロールを本番アカウントに追加します。
注目すべき点は、サイクルの最後でポリシーを調整しますが、それで終わりではないということです。作成されたポリシーに基づいて継続的に統合を行います。開発者が統合を進めるにつれて、私たちも対応する必要があります - 新しいサービスを追加したり、サービスを削除したりする可能性があります。これらのポリシーは本質的に生きた文書であり、完全に固定されることはありません。元の図に戻ると、AWS GovCloudの部分とツールをどのように補完するかを見ています。AWSには豊富なAPIがあり、先ほど説明したService Last Accessedなどのレポートを取得するためにIAM Access Analyzer APIにアクセスできます。このAPIを通じて、サービスが最後に使用された時期、どのサービス名前空間が使用されたか、実際にどのアクションが使用されたかを確認し、IAMのロール使用状況を分析して、ルールとポリシーを生成・更新することができます。
私たちはその補完にとどまらず、コードリポジトリとも統合しました。つまり、AWSで行われているアクションを読み取るだけでなく、Infrastructure as Codeも確認しています。例えば、Terraformを見ることで、将来どのようなリソースがデプロイされ、どのようなAPIコールが行われるかを把握し、それに基づいてポリシーを生成できます。
このアプローチにより、開発者をブロックすることなく、より柔軟に対応できるようになりました。2年前を振り返ると、開発者が使用すると思われるサービスについてセッションを持ち、ポリシーを更新する必要がありました。現在は、開発者をブロックするのではなく、より柔軟性を提供し、彼らのニーズにより迅速に対応できるようになっています。
では、実際にCLI toolingではどのように見えるのでしょうか？実はとてもシンプルな入力です。CloudTrailから収集したアクションとInfrastructure as Codeが、サービスのnamespaceとそこで実行されたアクションに集約されます。右側にあるポリシーをご覧いただくと分かりますが、基本的にAmazonのポリシー標準に従ってポリシーが生成されています。アクションがあり、そしてリソースにはスターが付いているのが分かります。私たちのCLI toolingの優れている点は、CloudTrail logsから情報を取得することで、実際にAWSアカウントで使用されているリソースを確認できることです。例えば、S3のget objectであれば、実際に使用されているものを確認してリソースに追加できます。ただし、run instancesのような実行後のアクションについては、スターリソースとなります。
これらすべてを統合する方法についてお話ししたいと思います。ここでは、toolingを活用して機能的な権限を構築するプロセスを見ていきます。まず、AWSアカウントへのアクセスを必要とするエンジニアと協力します。彼らをOnboarding Accountでオンボーディングし、チームがアカウント内で作業を行い、アクションを生成する際に、CLI toolingを使用してそれらを必要に応じてキャプチャしています。Infrastructure as Codeで必要なポリシーを手作業で入力する代わりに、バックグラウンドでこれを行っています。
とはいえ、チームや他のエンジニアとの協力が不要になるわけではありません。実際、チームが成熟し、より恒久的な方向に進み始め、Infrastructure as Codeの作業を開始する際には、多くの協力が必要です。デプロイメントのテスト時には、数日間あるいは数時間にわたって使用された最新のアクションを把握するためにCLI toolを使用します。この方法の素晴らしい点は、非常に柔軟性が高いことです。例えば、1ヶ月ほど使用していたロールで、もう使用していないサービスがある場合、実際に使用されたアクションの期間を指定してフィルタリングすることができます。
また、インフラストラクチャーの解体時にもチームと協力します。というのも、私たちのInfrastructure as Codeパイプラインでは、インフラストラクチャーのデプロイとテスト完了後の解体が必要なアクションが多いからです。例えば、クラスターをデプロイしてジョブを実行し、コスト削減のために解体するといったケースがあります。その後、チームとともにより恒久的なアカウントへの移行を進め、生成されたポリシーとロールをデプロイします。このOnboarding Accountにより、開発が加速し、私たちの作業時間が大幅に削減されました。数年前にポリシーを手作業で書いていた頃の作業量は膨大でした。特に、ULAでAWS Cloudへの関心が高まり、多くのチームが参加するようになってからは顕著でした。
toolingについて多く話してきましたが、このtoolingは今すぐにでも実装できることを強調したいと思います。商用環境をお使いの方は、AWS Access Analyzerの利用をお勧めします。GovCloud環境の方は追加作業が必要かもしれません。しかし、重要なのはtoolingそのものではなく、その背後にあるプロセスと適切な戦略です。JeffがCloud Center of Excellenceについて話したように、ユーザーのエンパワーメントについて多くの支持を得ることができました。そして、BryanがIAMインフラストラクチャーで実現したことで、Onboarding Accountで適切なポリシーとロールを設定できるようになりました。
以上で発表を終わります。質問がございましたら、この場で、あるいは後ほど廊下でお受けいたします。こちらが Jeff、Bryan、そして私の連絡先となっております。モバイルアプリ内にアンケートがございますので、お時間がございましたらぜひご回答いただければ幸いです。本日はご来場いただき、ありがとうございました。re:Invent での残りの一週間もどうぞお楽しみください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion