re:Invent 2024: AWSによるServerlessアプリケーションのセキュリティ実装
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Implementing security best practices for serverless applications (SVS324)
この動画では、Serverlessアプリケーションのセキュリティに関するベストプラクティスについて、AWS ServerlessのTech LeaderであるJosh KahnとPrincipal Solutions ArchitectのHeeki Parkが解説します。AWS IAMを活用した最小権限の原則の実装、Amazon API GatewayとLambda Authorizerを組み合わせた認証認可の実現、AWS InspectorやGuardDutyによる脆弱性検知など、具体的な実装方法を紹介します。また、Permission Boundariesを使った開発者の権限制御や、Amazon Verified PermissionsでのCedarポリシー言語の活用など、セキュリティチーム、プラットフォームチーム、開発チームが協力してServerlessアプリケーションのセキュリティを確保する方法について詳しく説明します。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Serverlessアプリケーションのセキュリティ：イントロダクション
こんにちは、ようこそ。おはようございます。照明が一段と明るくなりましたね。本日は、Serverlessアプリケーションのセキュリティに関するベストプラクティスについてお話しさせていただきます。セキュリティとコンプライアンスは、クラウドであれ他の環境であれ、私たちが構築するすべてのものにおいて常に最重要事項となります。しかし、イノベーションの境界を押し広げていく中で、高いセキュリティ基準も維持していく必要があります。
私は、Serverlessを使った開発が大好きです。なぜなら、これから数分後にお話しする安全な基盤の上に構築しながら、必要な時にスケールするシステムを実現し、素早く顧客価値を届けることができるからです。本日のセッションでは、スピーディなイノベーションとセキュリティのバランスを取りながら、その安全な基盤の上にどのように構築していけるのか、そのベストプラクティスについて探っていきます。私はAWSのServerless担当のワールドワイドTech LeaderのJosh Kahnです。そして、同じくServerlessを担当するPrincipal Solutions ArchitectのHeeki Parkも同席しています。
Serverlessの特徴と共有責任モデル
私たちはServerlessを、開発者の皆さんが価値の提供に集中できるようにする戦略、つまり運用モデルとして捉えています。AWSが、セキュリティの様々な側面を含む、差別化につながらない重労働の多くを担当します。AWS Lambda、Amazon EventBridge、AWS Step Functionsのようなサービスを利用する際に、AWSがそれらの作業を引き受けます。
Serverlessを戦略として選択すると、アプリケーションのアーキテクチャとセキュリティの両方へのアプローチが変わります。お客様とAWSの間の共有責任モデルもシフトします。Serverlessでは、安全な基盤から構築を始め、セキュリティ運用の負担の多くをAWSに移行します。暗号化、ポートアクセスの分離、特権ユーザーの制限など、多くの機能がデフォルトで、あるいはチェックボックスを1つクリックするだけで対応できます。また、GuardDutyやAmazon Inspectorなど、他のAWSサービスとの深い統合も活用できます。Serverlessで開発する際の私のお気に入りの特徴の1つは、これらのサービス全体で細かなアクセス制御を管理できる共通システム、AWS IAM（Identity and Access Management）を使用できることです。IAMを使用して、これらのサービスのコントロールプレーンとデータプレーンの両方へのアクセスを制御できます。
Serverlessでの開発において、変わらない側面もある一方で、異なる部分もあります。まず、これらのサービスは比較的短命です。Lambdaを使用する場合、Lambda関数の実行環境やサンドボックスは起動し、特定の実行を処理し、要求された作業を実行した後、しばらくすると消えてしまいます。また、これらのアプリケーションはモノリスを構築しているわけではありません。図の中の1つの大きなブロックではなく、小さな構成要素を組み合わせているのです。これは、それらのサービス全体に分散したペリメータがあることを意味します。しかし、ここでもIAMを使用して、それらのサービスがお客様に代わって実行できることや、誰がそれらを設定できるかを制御できます。
従来のアプリケーションでは、開発者は.NET、Java、Node、Pythonなど、何らかの形でコードを書いていたことでしょう。しかし、Serverlessで構築する場合、開発者はアプリケーションコードだけでなく、インフラストラクチャの設定も行うことになります。実際、設定だけを行う場合もあります。変わらないのは何でしょうか？データのセキュリティは依然として確保する必要があります。適切な権限を持つ当事者のみがアクセスできるようにする必要があります。また、品質の高いコードを書き、脆弱な依存関係から保護する必要もあります。Heekiさんは後ほどその方法について説明してくれますが、Least Privilegeはクラウドでは一般的な概念です。組織内でものを作る人々に、その責任の一部をどのように移行するかについても話し合っていきましょう。
セキュアなベースラインと組織内の役割分担
これらの個人にとって、私が言い続けているセキュアなベースラインには多くの機能が付属しています。IAMによるアクセス制御、転送中および保存時の暗号化（標準またはチェックボックス一つで設定可能）、ランタイムの分離、様々なコンピューティングリソースへのネットワークアクセスの防止、特権ユーザーの排除などの機能が無料で提供されます。
私たちが常に皆様にお伝えしたいのは、セキュリティは協力して実現するものだということです。組織によっては、セキュリティチームやこれらの原則を体現する担当者がいて、集中型の機能として存在するか、デリバリーチームに組み込まれているかもしれません。おそらくセキュリティチームは、ポリシーやコンプライアンス要件の遵守を確認し、IAMポリシー、ロール、または各種権限を定義しているでしょう。また、多くの組織にはPlatformチームや、私たちが「Platform Builder」と呼ぶチームがあり、ガードレールを構築しています。開発者やビルダーに新しいことを試す柔軟性を与えたいので、このガードレールについて話し合っていきます。
私たちが話すすべてのサービスは時間とともに進化し、改善されていきます。開発環境で少なくともテストができないほど、人々を制限したくはありません。Platform Builderは、ネットワーキング、コードスキャン、およびそれらの責任も担うかもしれません。そして開発チームは、アプリケーションコードとインフラストラクチャ定義の開発と提供を行います。AWS CloudFormation、AWS SAM、CDK、Terraformのどれを使うかは、皆さんにとって何が最適かが重要です。 イノベーションとセキュリティのバランスを取り、顧客価値を提供することが私たちの目標です。
このセッションの残りの部分では、そのバランスを見つけるために使用できるベストプラクティスのいくつかに焦点を当てていきます。セキュリティは非常に大きなトピックです。HeekiさんとI私は、55分から1時間程度で何を話せるかを考えるのに多くの時間を費やしました。そして、今日お話しする内容を絞り込むのに役立つ論文を見つけました。これは、これらの研究者が発見したマイクロサービスにおける最も重要な、あるいは一般的な脆弱性の実証的なレビューです。残りの1時間、これら6つのトピックを軸に話を進めていきます。
今回は、この非常にシンプルなアーキテクチャを私たちの指針として使用していきます。フロントエンドとしてAmazon API Gatewayがあり、おそらくWeb APIのために使用されています。API GatewayはAWS Lambda関数を呼び出し、そのLambdaがAmazon DynamoDBにデータを書き込み、さらに他のサービスを呼び出す可能性もあります。これは重要なポイントで、IAMを使用してサービス間通信を保護することができます。また、インフラストラクチャの定義とアプリケーションコードについても説明します。右下には、セキュリティチーム、プラットフォーム構築チーム、開発チームという3つのチームを示すキーがあり、各項目の主な担当者が分かるようになっています。
インジェクション攻撃からの保護：API GatewayとLambdaの活用
これは公開されているWeb APIなので、まずは実証的なレビューで最も一般的な脆弱性の1つとして挙げられたインジェクション攻撃からの保護について説明していきます。 これらのサービスには、組み込みのセキュリティ機能を活用するためのツールが用意されています。Amazon API Gatewayでは、JSONペイロードの形式を指定することで、APIリクエストを受け付ける前に入力を検証することができます。ボディのみを検証する、クエリ文字列パラメータとヘッダーを検証する、またはそれらすべてを検証するという3つの設定があり、OpenAPIを使用して指定します。
これは、ファーストネーム、ラストネーム、そしてアカウントIDを持つモデルを定義したシンプルなOpenAPI定義を使用して指定します。必要に応じて、そのアカウントIDのパターンも指定できます。これは素晴らしい第一歩です。なぜなら、API Gatewayは期待された形式と一致しないものを検出し、Lambda関数を呼び出すことなくユーザーにエラーを返すからです。開発者はあまり頻繁に行わない傾向にあるため、これは主にセキュリティプラットフォームの領域に該当します。
また、API GatewayにAWS WAFを接続して、SQLインジェクション、クロスサイトスクリプティング、コマンドインジェクション型の攻撃から保護するためのマネージドルールを使用することもできます。WAFにはOWASP Top 10に焦点を当てたマネージドルールセットがあり、サードパーティのルールセットも利用可能です。ここには詳しく説明する時間がないほど豊富なオプションがありますが、おそらくre:Inventの今週中に別のセッションで取り上げられているでしょう。
開発チームが関わるLambdaについては、Lambda関数内でも入力の検証や確認を行うべきです。これはWeb APIに限らず、どのようなイベントソースが関数を呼び出す場合でも、ペイロードの検証を行うことをお勧めします。これを支援する優れたツールが利用可能です。私のお気に入りの1つは、同僚が構築したオープンソースプロジェクトのPower Tools for AWS Lambdaです。現在、TypeScript、Python、Java、.NETで利用可能で、入力バリデータが含まれています。この例ではJavaで、入力のスキーマをJSONで指定しています。TypeScriptでは、別のオープンソースパッケージであるZodを使用して、ペイロードをチェックし、期待通りでない場合はエラーをスローします。
最小権限の原則とIAMの重要性
また、より厳格な型付けを提供するAWS AppSyncのようなマネージドGraphQLサービスや、API Gatewayでのモデリングの利用も検討できます。可能な限りすべてのイベントソースでこれを活用することを私は強く推奨しています。問題を早期に発見できる素晴らしい方法だからです。 ここで、コアコンセプトである最小権限の原則について話しましょう。私はこのシステムを構築する開発者に対して、 最小権限の原則を理解するためのトレーニングを始めることを推奨しています。現代のシステム開発では、 アプリケーションコードだけでなく、インフラストラクチャの定義も提供する必要があり、そのインフラストラクチャの定義には多くの場合、何らかのIAMポリシーが関連付けられています。
ここで示しているようなLambda関数を構築する場合でも、Step Functionsのワークフローでも、あるいはEventBridgeでも、他のAWSサービスとやり取りするための実行ロールが必要になることがあります。お客様からよく聞くのは、開発者が「とりあえず動くから」という理由で、過度に広い権限のポリシーを選んでしまうことを懸念しているということです - 私自身もそういう経験があります。この問題については後ほど、管理するためのアプローチについて説明します。 私たちは開発者に対して、そのリソースが必要とする必要最小限の権限セットだけを許可する、具体的なポリシーに焦点を当てるよう指導したいと考えています。ここで言っているのは、開発者自身の作業に関する権限ではありません - 開発者には革新的なことを試す能力を持ってもらいたいのですが、彼らが作成する権限セットやポリシーは制限したい場合があります。
Lambda関数やワークフローの実行ロールについては、可能な限りリソースごとに固有のロールを作成することをお勧めします。ただし、非常に大規模な場合には制限があります。また、できるだけ細かい粒度の権限を割り当てることも重要です。ポリシーを本当によく吟味してください - アスタリスク（*）がある場合は、サービスによっては有効なユースケースもありますが、何が起こっているのかよく考える必要があります。これは一朝一夕にはいかないプロセスだということを覚えておいてください - 最初から最小権限を完璧に設定できるとは限りません。実際、私は時々権限を少なすぎるくらいに設定してしまい、アクセス拒否エラーが発生してから調整することがあります。これは悪い問題ではありませんが、権限を設定し、アクセスをテストし、ローカルでのテストだけでなく、実際にAWSにデプロイして統合テストを実行し、期待通りに動作することを確認し、時間をかけて改善していく必要があります。
先ほど触れた、過剰な権限や、ロールのエスカレーションや権限のエスカレーションを可能にするポリシーの作成という問題に戻りましょう。
AWS Identity and Access Management (IAM)には、permissions boundariesという強力な機能があり、これはかなり前から利用可能です。多くのお客様がこれを活用しているのを見かけます。基本的に、permissions boundariesを使用すると、開発者が作成するロールやポリシーに対して、有効な権限の最大値を設定することができます。つまり、開発者が管理者アクセスなど、大量の権限を持つものを作成したとしても、permissions boundariesを使用してそれらの権限を制限することができます。
これはビルダーのためのガードレールであり、実際にコードを書いて何をしているか理解している人々に、ポリシーやロールの作成を任せることができるようにすることが目的です。中央のIAMチームがいる場合、これらの作成や管理のボトルネックにならないようにします。というのも、先ほどの制限が厳しすぎる設定の話に戻りますが、あるチームに何度も戻って調整を繰り返さなければならないとすれば、それには時間がかかってしまいます。Permissions Boundariesについては、私自身理解するのに少し時間がかかったので、ここで数分かけて説明させていただきます。実際、CLIコマンドを使用した実演は対面では難しいので、デモビデオを用意しました。
Lambda関数の簡単な例を見てみましょう。 このLambda関数はDynamoDBテーブルに何かを書き込む必要があるので、このようなロールやパーミッションセットを作成するかもしれません。セキュリティ担当の方がこの部屋にいらっしゃれば、今ドキドキしているかもしれませんね。この時点で、EventBridgeに対してあらゆるPut操作を実行できてしまいます。DynamoDBのスターは、DynamoDBに何があるかによっては少し怖いですね - デモでやってみますが、テーブルを削除することもできてしまいます。さらにSNSのパブリッシュまでできます。これは機能します。テストすれば動作しますし、クラウドにデプロイしても動作します。ただし、最小権限の原則には従っていません。
では、これはどのように機能するのでしょうか？ 開発者用のロールを作成する際、彼らはおそらくIdentity Centerや他のツールを使用してログインし、Lambda関数の作成、DynamoDBテーブルの作成、EventBridgeルールの作成などの作業を行うためのロールを引き受けます。私たちはそれらの作業をする柔軟性を彼らに与えたいと考えています。彼らを止めたくはありません。しかし、開発者ロールに複数の異なるポリシーをアタッチして、ポリシーを作成する時とロールを作成する時の両方で要件を課すことにします。
私たちは彼らにそれらの作業を許可したいのですが、開発者がロールを作成したり、ロールポリシーを設定したり、ロールにロールポリシーをアタッチしたりする際には、必ずPermissions Boundary（これは単なる別のIAMポリシーです）がアタッチされることを要求したいと考えています。質問がありましたら、後ほど最後にお答えします。もう一つ重要なのは、開発者が自分のロールからPermissions Boundaryを削除したり、Permissions Boundary要件ポリシーを解除したりできないようにする複数のポリシーを、このデベロッパーロールに関連付けることです。
開発者が何かを作成する際には、必ずPermissions Boundaryが存在するという考えを本当に徹底したいと思います。それでは、AWSコンソールに移動してみましょう。この関数はPythonで書かれており、DynamoDBテーブルを削除しようとします - Lambda関数でやりたいことではおそらくありませんが、ポリシーが許可していることです。コードはこちらで、私は今CloudShellにいて、これはいくつかのCLIコマンドを実行するだけです。
先ほどのスライドで見たのと同じDynamoDBにすべての権限を与える関数ポリシーがあります。このポリシーをアタッチしようとしてみましょう。ポリシーを作成したところ、問題なく作成できました。次に、この関数用に既に作成しておいたロールにポリシーをアタッチしようとしますが、アクセス拒否されてしまいます。 なぜでしょうか？それは、このDeveloperロールに関連付けられているポリシーが、開発者が管理するロールにPermission Boundaryポリシーを必ずアタッチすることを要求しているからです。
そこで、Lambda関数のロールにPermission Boundaryをアタッチしてみましょう。そして再度ロールポリシーのアタッチを試みると、Permission Boundaryが設定されているため、今度は成功しました。関数の設定を確認してみると、ロールが正しくアタッチされているのが分かります。
では、Lambda関数をテスト実行してみましょう。ここでは特に入力を必要としないので、空のテストイベントを使用します。ポリシーを呼び出すと、うまくいけばエラーが発生するはずです。案の定、アクセス拒否されました。テーブルの削除を許可するはずのポリシーがロールに関連付けられていたにもかかわらず、Permission Boundaryによってこの機能が実行できる有効な権限が制限されたのです。私自身、この仕組みを理解するのに苦労しました。QRコードからリンクされているGitHubに素晴らしい例があり、開発者ロールのタイプや、使用したい広範なPermission Boundaryポリシーのタイプについての優れた例が示されています。これらのスライドは後で参照できるようになります。Permission Boundaryは広く再利用可能であるべきで、大量のPermission Boundaryポリシーを作成することは避けたいものです。
開発者の権限を制限したい場合は、IAMやService Control Policies（SCP）の使用をお勧めします。これについては後ほど簡単に触れますが、アプリケーションの領域からは少し外れるため、SCPについて深く掘り下げることはしません。SCPはOrganizationレベルで適用され、基本的に管理者を除くOrganization内のすべてのユーザーが実行できることを制限します（許可ではなく制限です）。権限を付与する際、IAMユーザーとロールの最大権限を定義します。この例では、作成されるすべてのLambda関数にOwnerタグを関連付けることを要求しています。これにより、デプロイメントの観点から特定の関数の所有者を見つけやすくなります。Ownerタグが空であるか、関数の作成時に含まれていない場合は、拒否されます。
こちらはもっと興味深いSCPの例です。このSCPは、パブリックなAPI Gatewayエンドポイントの作成を防ぎます。実際にこれを行っているお客様もいます - 開発者にプライベートAPI Gatewayのみを構築させたい場合です。このSCPを使用すると、プライベートエンドポイント以外の作成が実際に防止されます。このように、SCPはより広範な制御が可能です。これらは主にセキュリティチームやプラットフォームチームの領域になります。今回は、アプリケーションのベストプラクティスにより焦点を当てたいと思います。ここからさらに詳しく説明するために、Heekiさんにバトンを渡したいと思います。
認証情報管理とデータベースアクセスのベストプラクティス
ありがとうございます、Josh。私はHeekiと申します。これまでServerlessについて担当してきました。Joshが説明していた最小権限の概念、IAMの使用方法、そして一時的な認証情報について、さらに掘り下げて考えていきたいと思います。リソースにアクセスするために使用する認証情報は、すべて短期間で失効する一時的なものです。これらはすべてIAMを通じて制御され、様々な操作に対して共通のポリシー言語を使用できるという特徴があります。
AWSとの対話には2つの方法があります。1つ目はコントロールプレーンのアクションです。これは、アカウント内で行う管理アクションのことです。例えば、AWS Lambda関数の作成、Step Functionsステートマシンの作成、EventBridgeバスの作成などが該当します。これらの管理アクションについて、誰が、あるいは何がこれらのアクションを実行するのかを考える必要があります。開発者環境やサンドボックス環境など、本番データを含まない下位環境では、本番ネットワークから隔離されており、開発者のテスト以外には特に何も行われていないため、開発者にこれらのコントロールプレーンアクションへのアクセスを許可することもあるでしょう。しかし、UAT環境、ステージング環境、プリプロダクション環境、本番環境になると、開発者が直接これらのコントロールプレーンアクションを操作することは許可されません。代わりに、CI/CDパイプラインのようなオートメーションパイプラインがあり、ビルドステップやデプロイステップが、これらのコントロールプレーンアクションへのアクセスを許可されたIAMロールを持つことになります。
もう一方は、次のスライドで詳しく説明するデータプレーンアクションです。これらは、アプリケーションが実際に行う操作で、Serverlessアプリケーションを構築する際のLambda関数の呼び出し、ステートマシンの開始、EventBridgeバスやSQSキューへのイベントの配置などが含まれます。
先ほど、APIがLambda関数を呼び出し、DynamoDBテーブルに書き込み、さらに他の内部APIにアクセスするというアーキテクチャ図を見ました。Joshが先ほど述べたように、Serverlessアーキテクチャを構築する際、これらのコンポーネントそれぞれの周りには分散したセキュリティ境界があります。これらを様々なIAMポリシーで保護したいと考えています。Joshは既にSCPについて触れましたが、この後のスライドで説明するリソースベースのポリシーもあります。また、すぐにご説明するVPCエンドポイントポリシーや、IAM実行ロールについても触れていきます。
ここでLambda関数について説明します。先ほど何人かの方々と話をしていた際に、本番環境でコンピューティングワークロードを実行するためにLambdaを使用している方が多数いらっしゃることを知りました。考慮すべき2つのポリシーまたはIAMの概念があります。1つ目はリソースベースのポリシーです。簡単に言えば、このLambdaのコンテキストで誰が私の関数を呼び出せるかを定義するものです。これは同期呼び出しと非同期呼び出しの両方に適用されます。例えば、Joshがさきほどのアーキテクチャーダイアグラムで示したように、API GatewayでRESTリクエストがRESTエンドポイントに到着した際に、そのメソッドが呼び出されたためにバックエンドのLambda関数を呼び出したい場合があります。ここで、Lambda関数にリソースベースのポリシーを設定し、API Gatewayをサービスプリンシパルとして定義します。特定のLambda関数からの呼び出しを指定したり、さらに詳細に、修飾されたARNを使用してLambda関数のバージョンやエイリアスまで指定することができます。Joshが先ほど述べたように、アスタリスク（*）の使用は避け、リソースポリシーではできるだけ具体的に指定することを心がけましょう。
一方で、実行ロールについて説明しましょう。簡単に言えば、Lambda関数が実行できることを定義するものです。先ほどのアーキテクチャ例では、Lambda関数がDynamoDBテーブルの読み書きを行うため、そのテーブルに対するPutItem、GetItemなどの特定のアクションを許可する必要があります。また、内部APIにアクセスする場合、API Gatewayの特定のリソースやメソッドの呼び出しを許可する必要があります。さらに、これはLambda環境のポーリングベースの呼び出しにも適用されます。Lambdaは、KinesisやKafka、MSK、SQSなどからの読み取りを行うポーラーを提供します。
EventBridgeを使用する別の例を見てみましょう。 ここでも、誰がこのデータプレーンのアクションを実行できるかを指定するリソースベースのポリシーと、実際にアクションを実行するために引き受けられる実行ロールが存在します。例えば、マルチアカウント戦略でAWS環境を構築する場合、イベントが発生する共有アカウント（アカウントA）と、アクションを実行するビジネスライン用のアカウント（アカウントB）があるかもしれません。中央アカウントがこのビジネスラインアカウントにイベントを発行したい場合、アカウントBは、信頼ポリシーの中でアカウントAがこのロールを引き受けることを許可する実行ロールを作成できます。そうすると、共有アカウントであるアカウントAがイベントを発行する際に、このロールを引き受けることができ、アカウントBのイベントバスにイベントを送信することが可能になります。
このようなサービス統合リソースを使用してアプリケーションを構築する際 、永続化層も必要になるかもしれません。特にLambdaについて考えると、Lambda実行環境はステートレスな環境であり、関数実行環境やサンドボックス環境内に状態を保存すべきではありません。代わりに、他のタイプの永続化層に状態を外部化する必要があります。AWSには、ご存知かもしれませんが、様々なデータベースオプションが用意されています。
AWSでは、データベースがIAM認証情報をサポートしています。利用可能な場合は、これらの短期的な認証情報の使用を推奨しています。例えば、Amazon Neptune、ElastiCache、DynamoDBなどのサービスを使用する場合、データベースの認証情報について考える必要はなく、実行ロールでIAMを使用するだけで済みます。
IAMをネイティブにサポートしていないデータベースを使用している場合もあると認識しており、そのような場合は何らかの方法で認証情報を管理する必要があります。このシナリオでは、環境変数を使用するのではなく、認証情報プロバイダーや認証情報マネージャーを使用することをお勧めします。環境変数には確かに利便性がありますが、環境変数にアクセスできる人がそれらの認証情報を見ることができてしまうため、この方法は避けたいと考えています。また、認証情報をコードにハードコーディングしてリポジトリにチェックインすることは絶対に避けてください。
私たちの顧客の中で見られるもう一つのパターンは、データベースの前段にAPIを配置するというものです。JDBCプロバイダーを使って直接データベースにアクセスするのではなく、APIとして接続します。このAPIフロントエンドを使用することで、IAMや短期間有効なSTSトークンのメリットをすべて活用できます。これにはAPI Gateway、AppSync、ALB、その他のサービスが含まれます。APIキーの追加、スロットリングやアイデンティティ管理の実装、あるいはOAuth 2.0の実装も可能です（ただしこれはかなり複雑になる可能性があります）。また、この後すぐに説明するAWS Secrets ManagerやParameter Storeについても触れていきます。
Lambda関数の実行ライフサイクルに詳しい方にとって重要なポイントは、コールドスタートや初期化と呼ばれる概念です。コードを書く際には、関数実行で後で使用するシークレットや認証情報をいつ取得するかを考慮する必要があります。このコールドスタートや初期化は、その特定の実行環境のライフタイム中に一度だけ発生するため、この情報や認証情報をメモリに保存しておくことができます。これにより、後続の関数呼び出しで認証情報を再取得する必要がなくなります。
認証情報をグローバルメモリからアクセスするだけなので、コードの実行が速くなり、下流の認証情報プロバイダーに負荷をかけすぎることもありません。これは特に、Lambda関数が大規模に実行される場合に重要です。Lambda関数の同時実行数、つまり並列で実行される関数の数を考えてみてください。Black FridayやCyber Mondayのような時期に、amazon.comのような小売組織で多くの顧客が商品を購入する場合、毎回認証情報にアクセスすると、内部の認証情報プロバイダーに過負荷がかかる可能性があります。これは、認証情報を一度取得して関数実行中に再利用できる機会となります。
先ほどJoshが話したAWS Lambda Powertoolsは、AWSがお客様のアプリケーション構築を容易にするために開発したものです。また、私たちはLambda extensionと呼ばれるものも提供しています。Secrets ManagerとParameter Store用のextensionがあり、これをより簡単に使えるようにしています。extensionでは、関数環境、つまり関数コードとプロセスの隣に追加のプロセスを立ち上げます。これは基本的に、Secrets ManagerやParameter Storeのような認証情報プロバイダーから認証情報を取得する作業を行うHTTPエンドポイントとして考えることができます。どのシークレットや認証情報をプリロードしたいかを指定できます。
また、TTLを設定することもできます。認証情報が60秒、5分、10分、あるいは組織に適切な値で期限切れにならないことがわかっている場合、そのTTLを設定できます。そうすると、関数コードはAWS Secrets ManagerやParameter StoreにSDKコールを直接行う代わりに、ローカルエンドポイントにHTTPコールを行うだけでよくなります。ローカルエンドポイントにコールを行うと、認証情報を取得できます。ただし、認証情報が期限切れの場合に備えて、関数コード内にtry-catch例外処理を必ず含めるようにしてください。このextensionは指定されたTTLに基づいて認証情報の更新も行いますが、extensionではまだ期限切れになっていないものの、取得時に期限切れになっているというレースコンディションが発生する可能性があります。このように、認証情報管理を容易にするために私たちが提供するサポートについて、注意すべき点があります。
Serverlessアプリケーションのセキュリティ強化ツールと戦略
それでは次のトピックに進みましょう。アプリケーションへの認可されたアクセスのみを許可することを確実にしたいと思います。その方法の1つとして、フロントドアとしてAmazon API Gatewayを使用している場合や、あるいはAWS AppSyncをフロントドアとして使用している場合があります。先ほどJoshが紹介した例に戻りますが、これを単純化しつつ、関心事を分離することができます。Joshは、Platform Builder、アプリ開発者、そしてセキュリティチームについて話しました。このセキュリティチームは、組織内のすべてのセキュリティポリシーや、ポリシーの記述方法について考えているかもしれません。開発者からこれらのセキュリティの懸念事項を切り離すことができます。開発者がセキュリティを全く考えていないというわけではありませんが、セキュリティには多くの深い考慮と設計が必要です。
APIの認可では、セキュリティチームが多くの懸念事項を処理し、それをLambda Authorizerとして公開することができます。Amazon API GatewayにAPIリクエストが入ってきた時、バックエンドのLambda関数にリクエストを渡す前に、このAuthorizerが実行され、適切な認可ロジックを実行します。認可が許可されると、Lambda関数の呼び出しが許可されます。Lambda関数自体は、先ほど説明したように、API GatewayがこのLambda関数を呼び出すことを許可するリソースベースのポリシーを使用して、Amazon DynamoDBテーブルにアクセスする実行ロールを持っています。
Amazon Verified Permissionsについてより詳しく見ていきましょう。このサービスは、セキュリティチームがエンドユーザーの細かい権限を定義するために、オープンソースのポリシー言語であるCedarを使用します。例えば、ヘルスケアアプリケーションでAudreyという名前のユーザーに対して細かい権限ポリシーを定義する場合を考えてみましょう。AudreyはクリニックIL-123に所属しており、追加の属性を持っています。Audreyが作成または更新できるリソースを、ヘルスレコードや個人プロファイルなどの特定のものに制限したい場合があります。このフローでは、Audreyはウェブブラウザやモバイルクライアントから、Amazon Cognitoや組織が使用している他のIDプロバイダーに認証リクエストを行います。トークンを受け取った後、クライアントアプリケーションはこのトークンを使用してAmazon API GatewayにAPIリクエストを行います。
次に、セキュリティチームが作成したLambda Authorizerを呼び出し、これがAmazon Verified Permissionsに呼び出しを行います。Audreyのトークンを取得し、セキュリティチームが作成したCedarポリシーに対して評価を行い、Audreyが個人プロファイルを更新できるかどうかをチェックします。Amazon Verified Permissionsは許可または拒否のアクションで応答し、Lambda AuthorizerがそれをAPI Gatewayに返します。API Gatewayはこの応答を受け取り、リクエストが許可されるか拒否されるかを判断します。許可された場合、そのAPIコールに関連するすべての作業を実行するLambda関数の呼び出しを許可します。こちらがCedarポリシーの例です。これはオープンソースの言語で、GitHubリポジトリでより詳しく学ぶことができます。permit関数内の最初の行を見ると、これが他のIAMポリシーと非常によく似ていることに気付くでしょう。
このポリシーでは、まずプリンシパルから始まります。私のAPIは、IDプロバイダー内で定義されている名前空間です。Cognitoを使用している場合、これはユーザープールになるかもしれません。次に、このユーザーグループのプロパティについて説明します。最後のUS-East-1_ABC1234はIDプールで、そのIDプール内に特定の開発者がいます。つまり、このユーザーがCognitoにいて、特定のプールまたはユーザーグループに属していることを確認するということです。次に、このmy APIスペース内でのアクションが、このAPIリクエストで特定のアクションを実行することを示します。ここではusersリソースに対するgetメソッドを指定しています。アクションですでにリソースを指定しているため、ここではリソースをそのままにしています。これが、AuthorizerがAmazon Verified Permissionsを呼び出す際に、バックエンドでCedarを使用し、評価されるポリシーの例となります。
私たちは先ほど、受信リクエストの認可について話しました。Joshが先ほど言及した論文からのもう一つのトピックは、機密データへの意図しないアクセスを防ぐことについてです。AWSには共有責任モデルがあり、AWSが基盤となるインフラストラクチャのセキュリティを確保します。しかし、アプリケーションを構築する際に最小権限の原則をどのように適用するかについて、今日お伝えしようとしている共有責任の現実があります。これからServerlessアプリケーションの構築とデプロイに関連する周辺的な事項について、いくつかの戦略や手法をお話ししていきます。
Joshが先ほど言及した保存時のデータ暗号化について、Lambdaが最近、ZIPパッケージに対するCMK（Customer Managed Key）のサポートを発表しました。Serverlessリソース内の特定の要素を暗号化する際にサービスキーを使用することを気に入っているお客様もいますが、組織によってはセキュリティとガバナンスポリシーの一環として、それらのキーを管理する必要があると言う場合もあります。CMKによってそれが可能になります。Step FunctionsもこのようなCMKサポートを提供しています。これは、オペレーターがステート遷移データを見ることを懸念していた私のあるお客様にとって非常に重要でした。彼らはそのデータを暗号化し、オペレーターが一部のステート遷移データを見ることをブロックしたいと考えていました。CMKを有効にし、オペレーターにCMKを使用した復号化のアクセス権を与えないことで、オペレーターはそのステート遷移データを空白としてしか見ることができなくなります。
考慮すべきもう一つの点は、プライベートエンドポイントの使用についてです。AWS PrivateLinkについてはもっと深く掘り下げることができますが、もう一つのセキュリティ対策として、Amazon VPC内のプライベートネットワークを使用することが考えられます。API Gatewayでは、VPC境界内にクライアントが存在し、プライベートRESTAPIを作成することができます。そしてPrivateLinkエンドポイントを使用してそれを実現します。ここには追加のセキュリティ上の利点があります：特定のVPCからのリクエストを制限するセキュリティポリシーをVPCエンドポイントに適用できる他、PrivateLinkエンドポイントにセキュリティグループを適用して、特定のソースセキュリティグループからのトラフィックのみを許可することもできます。
先ほどJoshはクロスサイトスクリプティングに関連してAWS WAFについて話しましたが、ネットワークの観点からもAWS WAFを使用することができます。パブリックエンドポイントがあり、APIを特定のリージョンにロックしたいシナリオがある場合、それも可能です。さらに、特定のIPアドレスや悪意のある攻撃者からのAPIアクセスをブロックするためのIP拒否リストを作成したい場合も、Amazon API Gatewayエンドポイントの前にAWS WAFを使用して実現できます。
私たちのお客様の中で見られるもう一つの事例は、機密データの取り扱いです。PCIデータを扱う金融サービスのお客様や、PHI（個人健康情報）や一般的なPII（個人識別情報）を扱うヘルスケアおよびライフサイエンスのお客様がいます。これは、Amazon SNSを使用してアプリケーションを通過するデータをマスクまたはブロックしたい場合があるかもしれません。これらのコントロールを適用する機能が用意されています。
正規表現を適用する機能があります。多数の管理された正規表現をすぐに使える形で提供していますが、開発チームが独自の正規表現を作成することもできます。これにより、SNS Topicを通過するデータに機密情報が含まれている場合、シャープ記号でマスキングするか、完全にブロックすることで対処できます。この機能は、特定のデータセキュリティ要件がある状況で特に役立ちます。
最小権限の原則についての説明を続けます。Joshが先ほど述べたように、セキュリティチーム、プラットフォームチーム、開発チームという異なるペルソナを考慮する必要があります。セキュアなベースラインを持って開発者のイノベーションを可能にしたい一方で、プラットフォームに関する考慮事項もあります。プラットフォーム構築者は、デプロイメントパイプラインにセキュリティガードレールを実装することになります。 一つのアプローチとして、AWS Accountを境界として使用する方法があります。マルチアカウント戦略による影響範囲の制限についてよく議論します。例えば、事業部門チームがアプリケーションをデプロイする際、特定のアカウント内に制限したいと考えます。別のアカウントに機密データがある場合は、このトーク全体で説明してきたIAMの原則を使用してアクセスを許可します。
ソフトウェアデリバリーのプロセス全体を通じて、セキュリティとガバナンスの両面から適切なガードレールを確保したいと考えています。開発者がコードやインフラストラクチャテンプレートを提供する際に、不適切な設定やプロパティを防ぐために実施する必要のあるコンプライアンスルールやポリシーがあるかもしれません。これらのチェックはソースコードリポジトリへのコミット時やプロセス全体を通じて実装でき、そのためのツールについても説明していきます。
セキュリティの観点から、AWSアカウントに何百、何千ものLambda関数をデプロイしている可能性があり、その中には定期的に変更されないものもあります。私には、組織内の他のAPIプロバイダーからポリシーを動的に読み取っているため、コードが静的なままの環境でインフラストラクチャ監査にLambdaを使用しているお客様がいます。例えば、オープンなCVEが報告されているrequestsライブラリのバージョン2.19.0を使用しているシナリオを考えてみましょう。このLambda関数を1年前にデプロイし、積極的なメンテナンスを行っていない場合、このセキュリティ脆弱性に気付いていない可能性があります。Amazon Inspectorは標準スキャンを使用して、このrequestsライブラリのような脆弱なライブラリを特定するために、Lambda関数内の依存関係をスキャンできます。アクティブなCVEに関する情報とセキュリティ脆弱性を解決するための推奨事項を含む通知とレポートを提供します。
Inspectorのもう一つの側面はコードスキャンです。先ほど、誰も認証情報をハードコードしないと言いましたが、私が最悪の開発者として、このようなコードを書いて何らかの形で本番環境にデプロイしてしまったとします。コードスキャン機能を備えたAmazon Inspectorは、関数コード内の認証情報のハードコーディングを検出し、修正が必要な脆弱性を示すレポート通知を提供します。
さらに、Amazon GuardDutyを使用してランタイムの異常検知を実装することができます。例えば、数年前にAWSのコンピューティングリソースを不正利用しようとする大規模な暗号通貨マイニング活動がありました。GuardDutyは、VPC Flow Logsを通じて、組織が望まないような異常な動作を検知することができます。この機能は、RDSデータベースやAmazon ElastiCacheを利用するために、VPCへのアクセスが必要な関数など、VPCにアタッチされた関数に対して有効です。
この機能は、VPCにアタッチされていない関数に対しても有効です。すべての関数は特定のVPC内で動作しますが、パブリックインターネットにのみアクセスする関数もあります。このようなトラフィックもセキュリティチームによって監視されていることを確認する必要があります。
最後に、まとめに入る前にAWS Security Hubについて説明しましょう。 Security Hubは、Amazon GuardDutyやInspector、そしてAWSで提供している他の多くのセキュリティ集約サービスからのセキュリティインサイトを確認できる統合ダッシュボードです。これらのインサイトを集約し、ダッシュボードで情報を要約することで、セキュリティチームが即座に対処すべき重要なセキュリティ課題を優先順位付けできるようにしています。例えば、先ほどデプロイしたレイヤーに関連する新しいゼロデイ脆弱性が発見された場合、そのリストを特定して組織として対応することができます。
まとめと今後の学習リソース
ここで、Joshにバトンタッチしたいと思います。ありがとうございます、Heeki。まとめとして、いくつかの重要なポイントを確認しましょう。 まず、セキュリティはチーム間の協力が不可欠だということを覚えておいてください。最後に魔法の粉のようにセキュリティを振りかければいいというものではありません。組織の形態に関係なく、今日お話しした様々なベストプラクティスを活用するには、協力関係が非常に重要です。
考慮すべき原則をいくつか挙げましょう： 最小権限の原則を実装すること - これは全員が訓練を受け、常に意識する必要があります。可能な限りAWS Identity and Access Managementを使用することを推奨します。様々なデータソースでの使用方法や、異なる認証情報を使用する代わりにIAMを活用できるAPIエンドポイントでの使用方法について説明しました。多層防御を適用すること - これらのベストプラクティスを組み合わせて活用できます。AWSサービス間の深い統合を活用すること - 特にAmazon GuardDutyとAWS Lambdaの連携は私のお気に入りの一つで、Lambda関数がVPCに関連付けられているかどうかに関係なく機能します。そして可能な限り自動化を活用してください。
今週のre:Inventでは、他にも興味深いセッションがいくつか予定されています。 その1つが、先ほどお話しした内容を実際に体験できるハンズオンワークショップです。1時間後にちょうど上の階で開催されますので、ご興味のある方はぜひご参加ください。また、木曜日にも注目のセッションがいくつかあり、その中にはHeekiによるAmazon API Gatewayを使用したプライベートワークロードに関するセッションも含まれています。
さらに学びを深めたい方のために、Digital Learning Badgeなど、様々なリソースをご用意しています。以上で本日のセッションを終了させていただきます。お時間を取っていただき、ありがとうございました。アンケートへのご協力をお願いできれば幸いです。もちろん5点満点の評価をいただければ嬉しいのですが、改善点などのフィードバックをいただくことで、今後のセッションをより良いものにしていくことができます。ご協力ありがとうございました。re:Inventでの残りの日程もお楽しみください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion