re:Invent 2024: AWSのシークレット管理の大規模展開と新機能
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - A proactive approach to secrets management at scale (SEC234)
この動画では、AWS Secrets Managerを活用したセキュアなアプリケーション開発について解説しています。Generative AIを活用した開発支援として、Amazon Q Developer Pluginによるハードコードされた認証情報の検出と改善提案機能を紹介しています。また、新機能のAWS Secrets Manager Agentにより、あらゆるコンピュート環境でシークレットを標準化して利用できる方法や、インメモリキャッシングによるレイテンシー削減について説明しています。さらに、AWS Secrets ManagerとAmazon GuardDutyの統合により、シークレットに関する異常な動作をリアルタイムで検出し、Amazon EventBridgeを通じて通知できる仕組みも紹介されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWS Secrets Managerの必要性と価値
みなさん、こんにちは。本日は、AWS Secrets Managerについて、エキサイティングな情報をお伝えしたいと思います。 本セッションでは、Generative AIを活用して、開発者がセキュアなアプリケーションを最初から構築する方法について詳しく見ていきます。私はAWS Secrets ManagerのSenior Product Manager TechnicalのAkshay Aggarwalです。 本日のセッションでは、まずSecrets管理ソリューションの必要性とその理由について理解を深めます。次に、Generative AIが組織の開発者のコーディング作業の開始時点から、セキュアなコードの構築をどのように支援できるかを見ていきます。その後、AWS Secrets Managerの最新機能の1つを詳しく見ていきます。これは、ワークロード全体でのSecretsの使用方法を規定するのに役立ちます。最後に、管理者がGenerative AIの力を活用して、Secretsのコンプライアンスを監視し、ガバナンスを構築する方法を見ていきます。
それでは、Secrets管理ソリューションの必要性から始めましょう。Common Weaknesses Enumerationの最も危険なソフトウェアの脆弱性トップ25を見ると、ハードコードされた認証情報が18位にランクインしています。 これは何を意味するのでしょうか？つまり、アプリケーションを構築する際には、ハードコードされた認証情報を避ける必要があり、Secretsはアプリケーションコードから切り離されているべきだということです。 でも、それだけで十分でしょうか？実は、Secretsはコードから切り離されていても見られる可能性があります。そのため、AWS Secrets Managerに保存する際には暗号化する必要があります。保存されるすべてのSecretは、FIPS 140-2レベル3のセキュリティ認証を受けたKMSキーを使用して暗号化されます。
さて、Secretsは別の場所に保存され、アプリケーションは別の場所で実行されています。ビジネスの継続性を確保するためには、Secrets管理ソリューションがアプリケーションが必要とするまさにその方法で、高スケールな取得を提供する必要があります。そして、アプリケーションはその実行にSecretsを必要とするため、アプリケーションがSecrets取得時にダウンタイムを経験しないよう、何らかの災害復旧メカニズムが必要です。これらがSecrets管理ソリューションが必要な理由ですが、ビジネスにどのような価値を付加できるのでしょうか？
2012年から2013年頃に時間を戻してみましょう。インターネット業界が成熟するにつれて、コンプライアンス基準はより規範的な性質を帯びるようになりました。 つまり、コンプライアンス基準では、Secretsの種類に応じて90日ごとまたは30日ごとにローテーションする必要があると規定し始めたのです。Secrets Managerでは、ローテーションは4クリックで設定できます：ローテーションを有効にし、スケジュールを定義し、名前を付け、送信するだけです。 これがSecrets Managerでのローテーション設定の全てです。コンプライアンス基準が規範的になったもう一つの例は、過度に許可的なSecretsを持つことができないという点です。Secretsの読み取り、書き込み、ローテーション、更新ができる人を明確にする役割の分離を構築する必要があります。Secrets Managerでは、IAMポリシー、リソースポリシー、属性ベースのアクセス制御を組み合わせることで、職務分掌を実現できます。
Secretsは組織の最も重要な資産であるデータを保護する王国の鍵です。私たちは常にSecretsで何が起こっているかについて、100%の透明性が必要です。Secrets管理システムは、Secretsで何が起こっているかについて完全な可視性を提供できる場合、ビジネスに価値を付加することができます。Secrets Managerでは、Secretsに対するすべてのアクションがCloudTrailに記録され、まもなくGenerative AIの力を活用して異常検知を構築する方法を見ていきます。
Generative AIとAWS Secrets Manager Agentによるセキュアな開発の実現
それでは視点を変えて、開発者の立場に立って考えてみましょう。 例えば、開発者がデータベースに接続してデータを取得する単純なLambda関数アプリケーションを構築する必要があるとします。ここで見ていただけるように、開発者はシークレットをハードコーディングしています。このような状況で、開発者にこれをしないように伝えるにはどうすればよいでしょうか？開発者は、コーディングを始める時点からこのような脆弱性を避けるべきです。そこで登場するのが、Visual Studio IDE用のAmazon Q Developer Pluginです。これを使用すると、コードを入力している最中にAmazon Qが「ハードコーディングされた認証情報が見つかりました。これは避けるべきです」と警告を出します。これはコードにおける一般的な脆弱性であり、開発者がコードを書く場所で直接指摘し、より良いコードを書くよう促すことができます。開発者に「何をしてはいけないか」を伝えただけでなく、「何をすべきか」も伝える必要があります。Visual Studioのウィンドウ内で、Amazon Qはチャットボットも開きます。このチャットボットを使用して、「ハードコーディングされた認証情報をSecrets Managerで置き換えるにはどうすればよいですか？」と簡単に質問できます。Amazon Qチャットボットは
実際にコード全体をリファクタリングしてくれます。Visual Studioウィンドウのコンテキストから、既存のコードで置き換える必要がある正確なコード行を提供し、必要な変更点を説明します。また、Secrets Managerでシークレットを適切に保管する方法や、Lambda関数の環境設定でシークレットを取得する方法についても説明します。さらに、コンピュート内でシークレットを簡単に取得できるよう、適切な権限スコープの設定方法についても案内します。
チャットボットはこのアプローチの利点も説明します。ご覧のように、シークレットは保存時も転送時も暗号化されており、保存されているシークレットはKMSキーによって保護されています。アプリケーションがそのシークレットを読み取る必要が生じるまで、TLSレイヤーの下で転送時も暗号化されています。シークレットは個別に保存されているため、ローテーションは非同期プロセスとなります。アプリケーションがシークレットを必要とする際には、常に最新の値を取得できます。このように、Amazon Q Developerは開発者の作業環境で直接支援し、セキュアなアプリケーションの構築をサポートします。
シークレットがアプリケーションとは別に保存されるようになった今、アプリケーションには何が必要でしょうか？まず、アプリケーションはシークレットの取得時にレイテンシーが発生してはいけません。シークレットの取得に時間がかかってアプリケーションが遅くなることは避けなければなりません。コード内でシークレットの高可用性が必要です。次に、シークレットが例えば24時間ごとにローテーションする場合、最新のシークレット値を取得するために24時間ごとにコードを再デプロイする必要があってはいけません。アプリケーションのダウンタイムなしでシークレットを取得、更新、利用できる必要があります。最後に、開発者にシークレットを取得するための複雑なコードの作成に注力させたくありません。開発者には実際のアプリケーション構築に集中してもらいたいのです。
AWSではこれらの課題をどのように解決するのでしょうか？新機能としてAWS Secrets Manager Agentを導入します。Secrets Manager Agentは、あらゆる種類のコンピュートでシークレットを利用する方法を標準化します。そうです - Lambda関数、EC2、コンテナ、さらにはオンプレミス環境でも動作します。インメモリキャッシングレイヤーを提供することで、アプリケーションでのシークレットの可用性を向上させます。アプリケーションはエージェントと通信し、コンピュート内のキャッシングレイヤーから値を取得できるため、アプリケーションのレイテンシーはほぼゼロになります。
エージェントはHTTPポートを使用してアプリケーションと通信するため、言語に依存しません。開発者はJava、Ruby、Python、または任意の言語でコードを作成できます - エージェントはどのシナリオでも動作します。セキュリティに関しては、エージェントにはServer-side Request Forgery（SSRF）に対するデフォルトの保護機能が組み込まれており、コンピュート環境内のシークレットへの制御されたアクセスを確保します。複数のアプリケーションがある場合、特定のシークレットへのアクセス権を持つアプリケーションを制御できます。
このエージェントの内部動作と、Secrets Managerとの通信方法がどのように変わるのかを見ていきましょう。アプリケーションが稼働しているコンピュートインスタンスを考えてみましょう。これまでは、アプリケーションがシークレットを取得するためにSecrets Managerと直接通信していました。エージェントを使用する場合は、コンピュート内にエージェントをデプロイし、アプリケーションはエージェントのHTTPサービスを使用してシークレットをリクエストします。HTTPサーバーは、インメモリキャッシュ内のシークレットをチェックし、有効かどうかを確認します。有効な場合は、そのシークレットをアプリケーションに返します。有効でない場合は、アプリケーションに代わってSecrets Managerを呼び出し、最新の値を取得してからアプリケーションに返します。
アプリケーションは常にローカルでシークレットを取得するため、レイテンシーがゼロになることに注目してください。さらに、シークレットにはTime-to-Live設定があるため、Secrets Managerが非同期でシークレットをローテーションする際、更新されたシークレット値が自動的にコンピュート環境内のアプリケーションに反映されます。これは複雑なサービスに聞こえるかもしれませんが、私たちは開発者に多くの設定オプションを提供することで権限を与えています。エージェントのメモリ使用量、ログレベル、HTTPポート、リージョン設定、キャッシュできるシークレットの数、通信できるアプリケーションの数など、多くのカスタマイズが可能です。
開発者がこれらの機能をどのように活用できるかをさらに説明するために、ハードコードされたシークレットを使用していた以前の例に戻って、このシナリオでエージェントを使用する方法を見てみましょう。AIに作業をさせてみましょう。チャットボットは、このLambda関数にエージェントをインストールする方法を説明し、さらにシークレットを適切に処理する方法、権限の設定方法、そして同じコードを以前のAPI呼び出しからエージェントを使用するように書き換える方法を説明します。
エージェントには複数の重要な利点があります。API呼び出しによるサービスへのアクセス回数が減少することに注目してください。どこでも動作し、すべての言語で動作し、コストも削減できます。もう一つの素晴らしい点は、このエージェント全体をGitHubでオープンソース化したことです。このエージェントのコードベース全体にアクセスでき、環境に合わせて好きな方法でデプロイできます。パブリックGitHubリポジトリに寄せられるすべてのプルリクエストと機能リクエストをレビューしています。お気軽にリクエストを出してください。私たちはこの製品に関するお客様からのフィードバックを大切にしており、すべてを慎重にレビューしています。
それでは、本日のトークの最後のセグメントに移りましょう。私たちは「Secretsは私たちの王国への鍵である」と述べてきました。Secretsは組織にとって最も重要な資産を保護します。Secretsに関して何らかの悪意のある活動が発生した場合、それを事前に把握する必要があります。同時に、それらが発生したらすぐに知りたいものです - Secretsのスプロール（無秩序な拡散）が発生していることを週次レポートで知らされるのを待つことはできません。また、将来同じことが起こらないようにするために、そのコンテンツについて十分な情報が必要です。
AWSではこれをどのように解決するのでしょうか？AWS Secrets ManagerとAmazon GuardDutyの統合をご紹介します。ご存知の通り、GuardDutyはアカウントの悪意のある活動を継続的に監視する脅威検出サービスです。今回、Secrets ManagerはGuardDutyと統合し、Secretのスプロールやアクセスに関して同様の機能を提供します。ここでは、GuardDutyがSecretに関する異常な動作を検出した場合の検出結果のサンプルをご紹介します。この検出結果は「credential access anomalous behavior（認証情報アクセスの異常な動作）」として分類されています。どこで活動が発生したか、どのアカウントが影響を受けたか、悪意のある行為者がどのようなアクションを取ったか、どのユーザーエージェントが使用されたか、そして具体的なIPアドレスとその活動が発生した正確な場所を示しています。この情報を活用することで、IAMポリシーやリソースポリシーを強化し、このような悪意のある活動を防ぐことができます。
毎日GuardDutyコンソールにアクセスして検出結果を確認したくはないでしょう。GuardDutyはAmazon EventBridgeと統合されており、これらの検出結果を自動的にメールボックスにリアルタイムで配信することができます。これにより、Generative AIを活用して開発者がセキュアなコードを構築できるようにし、Secrets Manager Agentを使用して組織内のすべての開発者にアプリケーション構築時の明確なガイダンスを提供し、Generative AIのパワーを活用してSecretsのガバナンスを構築する、というエンドツーエンドでスケーラブルなSecretのライフサイクル管理を実現できます。以上で本セッションを終了させていただきます。この後15分間、質問がある方はお答えしますので、セッションについてのフィードバックをアプリでお願いいたします。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion