第三者によるAWS Lambda関数URLの不正実行を防ぐ - Prisma^® Cloudから考えるセキュリティ（2）

クラウドサービス部の石井です。

ラックでは、Prisma^® Cloud（プリズマクラウド）を用いたクラウドセキュリティ統制支援サービスを提供しています。Prisma^® Cloudは、パロアルトネットワークス社が展開する、マルチクラウドやハイブリッドクラウド環境におけるクラウドリソースの設定上の脆弱性や不審な挙動を、業界標準の各種コンプライアンス基準や独自の基準に従い、継続的に監視・可視化するSaaS型のサービスです。

機能の1つとして、Prisma^® Cloud側で事前定義されたアラートポリシーに基づいて、不適切な設定や不審な挙動を検知・アラートします。非常に多くのアラートポリシーが定義されておりますので、そのなかでも特に注意していただきたいものを連載でお届けします。

連載2回目となる本記事では、「Unauthorized function invocation risk due to a publicly exposed (via resource based policies) and unauthenticated AWS Lambda function」というアラートポリシーを参考に、第三者によるAWS Lambdaの不正実行のリスクを抑える方法を紹介します。

アラートの内容

このアラートは、AWS Lambdaの関数URLに関連しています。関数URLとは、Lambda関数に直接アクセスできるHTTP(S)エンドポイントです。これは2022年に追加された機能です。それまではAPI GatewayとLambdaを組み合わせてHTTP(S)エンドポイントを作成する必要がありましたが、関数URLを使用することで簡単にHTTP(S)エンドポイントを作成できるようになりました。

想定されるリスク

アラートの条件としては、関数URLの認証タイプがNONEに設定され、リソースベースのポリシーによって誰でも関数を呼び出せる状態にあるAWS Lambdaを検知します。これは、第三者によってLambda関数が自由に実行されるリスクがあることを意味します。

詳細なリスクはLambdaの実装によりますが、例えばクレデンシャル情報が盗まれるといったリスクが想定されます。攻撃者にクレデンシャルが盗まれた場合、攻撃者はLambda関数に代わってAPIコールを発行できるようになります。

過去にあった攻撃事例では、攻撃者によって悪意のあるリソース作成が行われたケースがありました。このケースでは作成されたリソースによる被害拡大は発生しませんでしたが、状況や設定が少し異なっていれば、大きな被害をもたらす可能性もありました。

アラートの検知条件

詳細なアラートの条件は以下の通りです。以下の全てを満たしたAWS Lambdaを検知します。

関数URLの認証タイプがNONEに設定されている

関数URL作成時には、以下のいずれかの認証タイプを選択します。

• AWS_IAM：認証されたIAMユーザーとロールのみが、関数URLへリクエストできる設定。
• NONE：関数URLへのリクエストに対してIAM認証を行わない設定。

NONEを選択した場合、Lambda側で独自の認可ロジックを実装しない限りは、URLを知る全ての人がLambdaへのリクエストを送信できます。

以下画像は、リクエストに"success"を返すLambdaを作成し、認証タイプをNONEとした関数URLを設定した場合の動作を確認したものです。AWSの認証プロセスが発生しないcurlコマンドにて処理が成功しており、誰でも処理を実行できる状態にあることが分かります。

なお、認証タイプがAWS_IAMに設定されている場合は、curlではAWSの認証プロセスが発生しないので、Lambda側でリクエストが拒否されて、処理は実行できません。

リソースベースのポリシーでNONEによる関数実行を許可している

認証タイプがNONEに設定された関数URLを作成すると、以下のようなリソースベースのポリシー（Lambda関数に直接アタッチされるポリシー）も同時に作成されます。このポリシーに含まれる「"lambda:FunctionUrlAuthType": "NONE"」によって、誰でも関数URLを使用した処理を実行できます。

対処方法

ここからは、アラート条件に合致したLambda関数の修正方法を、実際の画面操作を含めて紹介します。

認証タイプをAWS_IAMに変更する

認証タイプをAWS_IAMに変更することで、認証されたIAMユーザーとロールのみが関数URLへリクエストできるようになります。誰でも実行できることが要件となっていない場合は、認証タイプをAWS_IAMに設定します。マネジメントコンソール経由で操作する場合は、以下のような手順を実施します。

①Lambda関数の一覧から対象リソースをクリックし、設定＞関数URLから認証タイプの値がNONEとなっていることを確認します。

②関数URLの編集を開き、認証タイプをAWS_IAMに変更した上で、保存をクリックします。

「①」の画面に戻り、認証タイプがAWS_IAMになったことを確認します。

③設定＞アクセス権限＞リソースベースのポリシーステートメントから、「"lambda:FunctionUrlAuthType": "NONE"」を含むポリシー（関数URL作成と同時に作られるポリシーのデフォルトの名称は「FunctionURLAllowPublicAccess」）を選択し、削除します。

上記の手順を実施することで、関数URLを経由して誰でもLambdaを実行できる状態が解消されます。

手順実施後は、IAMの認証情報と紐づけたリクエストが必須です。そのため個々の利用者がリクエストを行う場合は、awscurl、Postman、AWS SigV4 Proxy等のSigV4署名プロセスが含まれたツールを使用する必要があります。

また、クロスアカウント構成となる場合は、Lambdaを呼び出すIAMロール・ユーザー側でlambda:InvokeFunctionUrlのアクセス許可を行い、Lambda関数のリソースベースポリシー側では実行するIAMロール・ユーザーのプリンシパルを明示的に許可する必要があります。

認証タイプ変更以外の緩和策

要件や状況によっては、認証タイプをAWS_IAMに変更できない場合もあります。その場合、API GatewayのバックエンドにLambda関数を配置する構成に変更することで、セキュリティ関連の設定を加えられます。

例えば、アクセス元IPアドレスの制限ができるため、特定IPアドレスからのみアクセスを許可する設定が可能です。また、API GatewayにAWS WAFを関連付けることで、悪意のある通信を拒否するルールを適用できます。さらに、Lambda関数に付与するIAMロールを最小権限に抑え、権限を厳格に管理することも基本的ながら重要な対策です。

おわりに

今回紹介したアラート以外にも、Prisma^® Cloudは多数のセキュリティリスクを検知します。そして、ラックの長年にわたるシステム開発とセキュリティのノウハウを集め提供する「クラウドセキュリティ統制支援サービス」は、検知したアラートの対応を支援するサービスも提供しています。

ラックならではの知見を活かし、セキュリティトレンドやメーカーの対応状況を踏まえたラック独自のポリシーを提供することで、継続的に最新のセキュリティ対策を行えます。AWS含め、パブリッククラウドのセキュリティに不安がありましたら、ぜひラックにご相談ください。

プロフィール