re:Invent 2025: AWS Secrets Managerのサードパーティシークレット自動ローテーション機能
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖re:Invent 2025: AWS re:Invent 2025 - Zero-Touch Secret Rotation, now available for your third-party secrets (SEC230)
この動画では、AWS Secrets Managerがサードパーティのシークレット管理に対応した新機能について解説されています。Ritesh DesaiとFannie MaeのRaj Parthajeが登壇し、従来はLambda関数を個別に構築する必要があったサードパーティAPIキーのローテーションが、管理された外部シークレット機能により完全マネージド化されたことを説明しています。Fannie Maeは開発初期からAWSと協力し、一元的なシークレット管理、自動ローテーション、マルチリージョンレプリケーション、コンプライアンス対応を実現しました。現在Salesforce、MongoDB、ServiceNowの3つのパートナーと統合されており、シークレット作成直後の自動ローテーションにより人の目に触れる機会を最小化し、CloudTrailによる完全な監査証跡を提供します。デモではコンソールからの設定手順とバージョン管理の仕組みが紹介されています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
AWS Secrets Managerの新機能：サードパーティシークレットのネイティブ管理への挑戦
皆さん、こんにちは。ようこそお越しくださいました。お集まりいただきありがとうございます。木曜日の終わりということで、ちょっと大変だと思いますが、お時間を割いて私たちとお話しするために来ていただき、感謝しております。本日は、AWS Secrets Managerが現在の機能を拡張し、AWSシークレットをネイティブに管理およびローテーションすることから、非AWSシークレット、つまりサードパーティのシークレットに対しても同様のことを行えるようになったことについてお話しする機会を持ちたいと思います。これは常に課題となっていたものです。
私の名前は、表示されている通り、Ritesh Desaiです。そして本日は、Fannie MaeのRaj Parthajeと一緒に登壇しております。Rajは、Fannie Maeのユースケースと、この管理された外部シークレットの提供が彼らにどのように役立っているかについてお話しする機会を持ちます。ちなみに、RajとFannie Maeは、何年にもわたって私たちのパートナーであり顧客であり、タイムリーで貴重なフィードバックを提供してくださっていることをお伝えしなければなりません。それが最終的に、お客様全体のセキュリティ体制を強化する多くのローンチにつながっています。ありがとうございます。
さて、明らかに、Amazonの伝統として、私たちはお客様の課題から始めます。そして、ソリューションへのアプローチについてどのように考えたかを少しお話しし、その後、最終的にローンチした管理された外部シークレットにどのように至ったかをお話しします。もちろん、その後、AWSの言葉だけを信じる必要はありません。お客様であるFannie Maeが、これが彼らにどのように役立ち、今後も彼らに利益をもたらし続けるかについてお話しします。その後、私が引き継ぎ、高レベルのワークフローについて少しお話しし、それから数分のデモを行い、そのデモで正確に何が起こっているかをお話しします。
さて、お客様の課題、サードパーティのシークレットです。多くのお客様が、例えばSalesforce APIキーなどのサードパーティのシークレットを保存していますが、このような他のシークレットに対して定期的なローテーションを設定するのは本当に難しいことがあります。Lambda関数を構築しなければならず、さらに各サードパーティごとに別々のLambda関数が必要です。ローテーションや可用性のリスクが本質的に存在します。Secrets Managerでローテーションされても、ソースでローテーションされなかったらどうなるでしょうか。そうするとダウンタイムのリスクがあります。それらすべてのLambda関数をセキュリティ面などで最新の状態に保ち続けるための継続的なコストもあります。
そこで私たちは、AWSシークレットについて考えてきた方法で問題について考え始めました。Secrets Managerは今日、お客様のシークレットを使用するすべてのAWSサービスと統合されており、ネイティブに統合してローテーションを行います。例えば、お客様がRDSインスタンスを作成する場合、単純にチェックボックスをクリックするだけで、自動的にシークレットをSecrets Managerに保存し、ローテーション用に設定されます。そこで私たちは考え始めました。なぜ非AWSシークレットに対してそれができないのか、と。なぜできないのか。そして、その後、お客様やパートナーと何ヶ月も協力した結果、最終的に、ローンチした管理された外部シークレットを構築する戦略を思いつきました。
これは先週ローンチされました。私たちは今日、段階的な性質を持つという精神で進めています。現在、積極的に統合している3つのパートナーがいます。もちろん、Fannie Maeがパイロットカスタマーとして、途中でフィードバックを提供してくれており、先週ついにローンチしました。ですので、これは私にとって、さあ、Fannie Maeと話をして学び、彼らのユースケースがこれによってどのように解決されているのかを見る時間です。
Fannie Maeが直面したシークレット管理の課題と望ましい機能
ありがとうございます、Ritesh。私の名前はRaj Parthajeです。この特定の機能の観点から、顧客のペインポイント、私たちが求めている成果、そしてこのソリューションを使用することで達成できる結果について、いくつかお話しします。
それでは、Fannie Maeについて少し概要をお伝えします。Fannie Maeは1938年に米国議会によって設立された認可組織です。Fannie Maeは、米国の借り手と賃借人に対して、手頃な価格の住宅ローン信用の信頼できる供給源を提供しています。
それでは、私たちの環境で観察したペインポイントのいくつかを見ていきましょう。サードパーティのシークレットマネージャーに関してですが、ちなみに、私たちはAWS Secrets Managerをその開始当初から使用しています。私たちはAWSと提携してサービスを構築しており、これは私たち全員にとって役立っています。皆さんの中で、シークレットの管理に関するこれらのペインポイントに実際に直面している方はどのくらいいらっしゃいますか？使用している方はどのくらいいますか？ええ、本当に...
シークレット管理のペインポイントは何でしょうか？そこの図を見ていただくと、サードパーティのシークレットを管理する必要がある場合、そのシークレットを管理およびローテーションするためのカスタム関数を書く必要があります。そして、その関数をスケジュールする必要があります。その周辺の可観測性も必要です。これらすべてがカスタム開発となるため、複雑さが増します。このカスタムソリューションの管理と保守には、追加のリソース容量が必要になります。非効率的な手動プロセスが関与します。例えば、そのシークレットをローテーションするためのLambda関数などを書いていない場合、どのようにシークレットをローテーションするつもりですか？手動で行う場合、その手動の複雑さと、それがビジネスプロセスにもたらすリスクについて考えてみてください。シークレットのローテーションが失敗したり、タイムリーに更新されなかったりしたら何が起こるでしょうか？手動プロセスを行う場合、ビジネスの中断リスクは非常に高くなります。そして、これらのシークレットの管理に費やす必要がある不適切な労力がオーバーヘッドを追加します。考えてみてください。統合するのは1つのISVや1つのサードパーティSaaSだけではありません。このクラウドの世界では、おそらく多くのものと統合する必要があります。つまり、管理および保守する必要があるカスタムのものがいくつもあるということです。これらがすべてペインポイントです。それだけでなく、バージョン変更がある場合は、それらも変更する必要があります。
それでは、これらの特定の課題を観察した際に、私たちが求めている望ましい機能について見ていきましょう。まず、これらの認証情報の一元的なオンボーディングと管理を可能にしたいと考えています。なぜこれが重要なのでしょうか?そうすることで、アプリケーションチームにセルフサービス機能を提供し、彼らがこれらの認証情報を管理できるようにすることができるからです。AWS Secrets Managerからアプリケーションがシークレットを消費するための、信頼性が高く安全な方法を確保したいと考えています。この機能はすでに利用可能ですので、これらの機能を活用していきます。ビジネスの中断を最小限に抑えるために、シームレスな認証情報のローテーションをサポートしたいと考えています。もう一つ検討する必要がある重要な機能は、シークレットをマルチリージョンにレプリケートする必要があるということです。なぜなら、アプリケーションがマルチリージョンで実行されている場合、あるリージョンから別のリージョンへシークレットを消費したくないからです。そのため、シークレットのレプリケーションは重要な望ましい機能となります。また、シークレットローテーション機能に対する完全なコンプライアンスとガバナンスを提供したいと考えています。これらが、私たちがプロダクトチームに提示したすべての望ましい機能であり、これらの新機能を統合した結果、以下のような成果が観察されました。
運用効率です。これにより、シークレットのオンボーディングとシークレット管理を効率化することができます。結局のところ、私が話している手動プロセスは、もはや本当に必要ありません。場合によっては物事を開始するために必要かもしれませんが、結局のところ、シークレットは自動管理されます。つまり、自動化されたコンプライアンスにつながります。ポリシーに基づいてシークレットを自動ローテーションする機能が組み込まれています。ポリシーを定義するだけです。何が良い点かというと、手動でシークレットをオンボーディングすると、オンボーディングした人がまだシークレットの知識を持っているということです。その知識にはリスクが伴いますよね?人々にシークレットを持たせたくないのです。システムにシークレットを持たせたいのです。これにより、自動化されたコンプライアンスが実現されます。
次に、一元的な可視性です。これにより、シークレット管理への統一された監視が提供されます。なぜなら、このサービスを通じて管理するのは内部のシークレットだけではなく、外部のシークレットやサードパーティのシークレットも提供しているからです。そして、セキュリティに関しては、今話しているシナリオについて考えてみてください。シークレットの知識という観点から、人間がループから外れています。システム間のやり取りになるため、これによりセキュリティ体制が大幅に向上し、手動での取り扱いが削減されます。結局のところ、運用効率の観点からも、セキュリティの観点からも、シークレットが適切に管理され、適切に保護されることになります。また、潜在的なビジネスの停止を削減することができます。なぜなら、ここで私たちがチームと協力してソリューションを提供する上で重要なことの一つは、シークレットがローテーションされたときにアプリケーションが壊れないようにすることだからです。アプリケーションを壊すことなくシークレットをローテーションできるようにする必要があります。これが、この新しいプロダクトを使用して達成した最終的な結果です。
管理された外部シークレットのワークフローとデモンストレーション
それでは、Riteshに締めくくりの言葉をお願いします。ええ、ありがとうございます。これは、顧客のユースケースの懸念事項について、特にFannie Maeという顧客の観点から、本当に良い洞察だと思います。しかし、正直なところ、これらの80%または90%は他の顧客にも非常に似ています。ですから、Fannie Maeと協力する私たちのアプローチは、すべての学びを取り入れて、他の顧客にも役立つように適用することでした。そして、この機能について素晴らしいフィードバックを得ています。それでは、簡単にハイレベルなウォークスルーを行います。
サードパーティとネイティブに統合するというこのメンタルモデルには、AWSのシークレットで行うこととは少し異なる側面があります。AWSサービスの場合、私はAWSサービスについて十分に理解しているので、どのタイプのシークレットが期待されているかを知っています。そして、このケースでは、特定のパートナーが特定の事前定義されたフォーマットを持つことを確実にするために、少しの初期設定が必要です。それが完了すれば、過去にSecrets Managerを使用したことがある方なら、残りのワークフローはまったく同じです。Secrets Managerから得られるすべての素晴らしいメリットは、そのまま変わりません。これには、KMSによるエンベロープ暗号化、Security Hubとの統合、CloudFormationとの統合、Configとの統合などが含まれ、これらすべてがまったく同じように維持されます。
そして、Rajが言及したことに加えて、コンプライアンスの部分ですが、すべてがCloudTrailで監査証跡として記録され、監査されます。つまり、すべてが監視されているということです。これは他のAWSサービスで見られるものと同様です。AWSサービスに対するあらゆる変更アクション、あらゆるアクションがそこで追跡されます。ですので、何も変わりません。このスライドの意図は、システムにシークレットを入れる方法に若干の違いがあるということを示すことでしたが、その後はすべてがそのまま流れていくということです。
では、これは取得に関する視点、つまりこのビューが取得の視点を示しています。ご覧のように、カスタマーアプリケーションがあり、それがSecrets Managerと同じ方法で対話しています。CLI、CDK、SDKを使用するのと同様です。最近リリースされたSecrets Managerエージェントを使用してシークレットを取得することもできます。すべての機能は同じままです。裏側で起こっていることは、AWSとパートナーによって承認され検証されたローテーションコードが、今やローテーションスケジュールに組み込まれているということです。
これはLambda関数ではありません。これは単に、私たちがカスタマーのロールを引き受けて、ISP側で実行するコードです。ですので、まず今日行っているのと同じプロセスに従って更新します。まず、ISPサイトにあるリソース内のシークレットを更新し、それが機能していることを確認してから、Secrets Managerで更新します。つまり、アプリケーションのダウンタイムやそのリスクについて言えば、私たちはその責任をAWSに移しているのです。つまり、このようなシナリオでアプリケーションがダウンしないことを私たちが確実にするということです。
これが重要な側面だと思います。ここには3つのポイントが書かれています。最後の2つは非常に重要です。ローテーションを望む人々がローテーションしたいかどうかの最大の問題は、常に「ローテーションするために多くの作業をしなければならない」ということでした。これにより、ローテーションに関してゼロオーバーヘッドが保証され、完全にマネージドされたローテーション体験が提供されます。パートナーシップの信頼エコシステムについては、AWSには私たちのシステムに参加するパートナーをしっかりと検証し保証する非常に堅固なフレームワークがあると信じていますので、それを継続して行っています。その観点から見ると、これは十分に信頼されたエコシステムの一部であり、Secrets Managerのローテーションを活用するために引き続き使用できるということです。それが現状です。
次のスライドでは、デモをご覧いただきます。録画されたデモですので、説明しながら進めます。ここでは音声を使いたくなかったので、私のナレーションで進めます。このボタンをクリックすることになっています。やってみます。 さて、このデモは明らかにコンソールのものです。ご覧のように、すでにadminシークレットが作成されています。次に、システムに入ると、まだご覧になっていない場合、manage external secretsという新しいシステムがあり、そこに3つのパートナーが表示されます。例えば、今Salesforceを選択します。そして、事前定義されたフォーマットと保存する必要があるメタデータについてお話ししたことを覚えていますか。これがそれを設定する場所です。ご覧のように、少し遅いですが、進んでいきます。
基本的に、これらすべての項目、例えばconsumer key、consumer secret、base URI、これらすべてが既に事前定義されたフォーマットでメタデータとして識別されています。それが設定されると、通常の画面に進みます。もちろん、お客様の会社や組織がチームに従わせるようにしている命名規則に従って進めていきます。そしてここで何か気づくことがあると思いますが、ローテーションがデフォルトで自動的に有効になっています。通常、普通のシークレットでは自動的に有効にはしませんが、これは既に有効になっています。そして先ほどお見せした作成されたadmin secretが、シークレットをローテーションするために使用されるものです。
さて、もちろんシークレットは作成されました。コンソールを見ていただくと、下にスクロールして保存する必要があり、最終的に表示されます。このデモでお見せしたかった重要なことの一つは、ここのバージョンを見ていただくことです。Secrets Managerは裏側で何百ものバージョンのシークレットを保持していますが、ここのバージョンを見ると、末尾にE01という番号があることに気づくでしょう。これは現在AWSCURRENTとしてマークされており、get secret valueを実行すると、そのシークレットまたはその値が返されます。初期セットアップでは、このタイプのセットアップシークレットは自動ローテーション用に設定されており、シークレットが作成された直後にローテーションされます。
今デモで行っているのは、ローテーションが開始されるようにリフレッシュしているところです。ご覧のように、E01はまだcurrentですが、新しいものが作成され、今currentに切り替わりました。つまり既にローテーションされています。ですから、例えばお客様がまだシークレットの手動部分を扱っていてコピー＆ペーストしている場合でも、作成直後にローテーションされるため、新しいシークレットは利用できなくなります。つまり、誰もそれについて知らないということです。人の目に触れる機会が少なくなります。これがその考え方で、ここで終わりにします。
これらは私のチームが追加するように言ったQRコードです。もしお客様がパートナー統合をお探しで、ご覧いただいている3つが要件に合わない場合は、ぜひお知らせください。SAに相談してください、チームに相談してください。優先的に対応させていただきます。そしてもちろん、技術ドキュメントも公開されています。それでは、ご参加いただきありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion