Lambda 関数の公開の修正

注記

Security Hub はプレビューリリースであり、変更される可能性があります。

AWS Security Hub は、 AWS Lambda (Lambda) 関数の公開結果を生成できます。

Security Hub コンソールでは、公開結果に関連する Lambda 関数とその識別情報が、検出結果の詳細のリソースセクションに一覧表示されます。プログラムでは、Security Hub API の GetFindingsV2オペレーションを使用してリソースの詳細を取得できます。

露出検出結果に関連するリソースを特定したら、不要なリソースを削除できます。不要なリソースを削除すると、露出プロファイルと AWS コストを削減できます。リソースが不可欠な場合は、以下の推奨される修復手順に従ってリスクを軽減します。修復トピックは、特性のタイプに基づいて分割されます。

1 つの公開結果には、複数の修復トピックで特定された問題が含まれます。逆に、1 つの修復トピックだけに対処することで、露出の検出結果に対処し、その重要度レベルを下げることができます。リスク修復へのアプローチは、組織の要件とワークロードによって異なります。

注記

このトピックで提供される修復ガイダンスでは、他の AWS リソースで追加の相談が必要になる場合があります。

注記

このトピックで提供される修復ガイダンスでは、他の AWS リソースで追加の相談が必要になる場合があります。

目次

• Lambda 関数の設定ミスの特性

  • Lambda 関数がサポートされていないランタイムを実行しています

  • Lambda 関数が Amazon VPC の外部にデプロイされる

  • Lambda 関数は IAM ロールを引き受けることができます

  • Lambda 関数に関連付けられた IAM ロールには管理アクセスポリシーがあります

  • Lambda 関数に関連付けられた IAM ロールには、 AWS サービスへの管理アクセス権を持つポリシーがあります

• Lambda 関数の到達可能性特性

  • Lambda 関数はパブリックに呼び出すことができます

• Lambda 関数の脆弱性特性

  • Lambda 関数にネットワークが爆発するソフトウェアの脆弱性がある

  • Lambda 関数にはソフトウェア脆弱性があります

Lambda 関数の設定ミスの特性

Lambda 関数の設定ミスの特徴と推奨される修復手順は次のとおりです。

Lambda 関数がサポートされていないランタイムを実行しています

Lambda を使用すると、開発者はマネージド環境でコードを実行するランタイムを通じてサーバーをプロビジョニングまたは管理することなくコードを実行できます。Lambda は、マネージドランタイムとそれに対応するコンテナベースイメージにパッチとセキュリティ更新プログラムを自動的に適用します。ランタイムバージョンがサポートされなくなった場合、セキュリティ更新、バグ修正、またはテクニカルサポートは受け取られなくなります。非推奨のランタイムで実行されている関数にはセキュリティの脆弱性があり、証明書の有効期限切れなどの問題により最終的に機能停止する可能性があります。さらに、サポートされていないランタイムは、利用可能なパッチなしで新しく検出されたセキュリティエクスプロイトに対して脆弱になる可能性があります。セキュリティのベストプラクティスに従って、Lambda 関数にはパッチが適用され、サポートされているランタイムを使用することをお勧めします。

関数ランタイムをアップグレードする

公開のリソースタブで、ハイパーリンクを使用してリソースを開きます。これにより、Lambda 関数ウィンドウが開きます。関数をサポートされているランタイムにアップグレードするには、ランタイム管理設定を構成します。関数を最新のランタイムバージョンに自動的に更新することを選択できますが、このオプションを選択する前に、自動アップグレードが実行中のアプリケーションに影響を与える可能性があるかどうかを評価してください。詳細については、「Lambda がランタイムバージョンの更新を管理する方法を理解する」を参照してください。

Lambda 関数が Amazon VPC の外部にデプロイされる

デフォルトでは、Lambda 関数はパブリックインターネットにアクセスできるようにデプロイされます。このデフォルト設定により、Lambda 関数は AWS サービスエンドポイントと外部 APIs にアクセスできますが、潜在的なセキュリティリスクにさらされます。インターネットアクセスのある関数は、データの流出、不正なサーバーとの通信、または侵害された場合の外部アクターのエントリポイントになるために使用できます。Amazon VPC は、定義されたプライベートネットワーク内のリソースとのみ通信するように Lambda 関数を制限することで、ネットワークを分離します。標準のセキュリティ原則に従って、ネットワーク分離によるセキュリティを向上させるために、VPC 内に Lambda 関数をデプロイすることをお勧めします。

VPC に関数をアタッチする

公開結果で、ハイパーリンクを使用してリソースを開きます。これにより、Lambda 関数ウィンドウが開きます。ネットワークアクセスを制限して Lambda 関数を保護するには、適切なネットワークコントロールが設定されている VPC にアタッチします。関数を VPC にアタッチする前に、必要な AWS サービスアクセスを計画してください。NAT ゲートウェイまたは VPC エンドポイントのないプライベートサブネットの関数は AWS サービス APIs に到達できないためです。アカウントの Amazon VPC に Lambda 関数をアタッチする方法については、「 の Amazon VPC に Lambda 関数をアタッチする AWS アカウント」を参照してください。関数がプライベートサブネット内からサービスにアクセスする必要がある場合は、インターネットアクセスなしで AWS サービス接続に VPC エンドポイントを使用することを検討してください。プライベートサブネットからのアウトバウンドインターネット接続が必要な場合は、NAT ゲートウェイを設定します。

Lambda 関数は IAM ロールを引き受けることができます

Lambda 関数は、IAM ロールを使用して AWS サービスとやり取りします。これらのロールは、実行中に AWS リソースにアクセスするためのアクセス許可を Lambda 関数に付与します。これらのロールは、Lambda 関数がタスクを実行するために必要になる場合がありますが、これらのロールは最小特権の原則に従う必要があります。標準のセキュリティ原則に従って、 は、関数の意図した機能に基づいて、ロールにアタッチされたアクセス許可が適切かどうかを確認する AWS ことをお勧めします。

1. アタッチされた IAM ロールが必要かどうかを判断する

   Lambda 関数で IAM 実行ロールを設定する必要があるかどうかを確認します。ほとんどの Lambda 関数には、CloudWatch へのログの書き込みなど、基本的な操作権限が必要です。関数の実行ロールにアタッチされているアクセス許可を確認し、関数に IAM ロールが必要かどうかを判断します。Lambda 実行ロールの詳細については、「 デベロッパーガイド」の「実行ロールを使用した Lambda 関数のアクセス許可の定義」を参照してください。 AWS Lambda

2. 最小特権アクセスの実装

   過度に寛容なポリシーを、関数が動作するために必要な特定のアクセス許可のみを付与するポリシーに置き換えます。IAM ロールのセキュリティのベストプラクティスについては、「 AWS Identity and Access Management ユーザーガイド」の「最小特権のアクセス許可を適用する」を参照してください。不要なアクセス許可を特定するには、IAM Access Analyzer を使用して、アクセス履歴に基づいてポリシーを変更する方法を理解します。詳細については、「 AWS Identity and Access Management ユーザーガイド」の「外部アクセスと未使用のアクセスの検出結果」を参照してください。または、新しい IAM ロールを作成して、既存のロールを使用している他の Lambda 関数に影響を与えないようにすることもできます。このシナリオでは、新しい IAM ロールを作成し、新しい IAM ロールをインスタンスに関連付けます。関数の IAM ロールを置き換える手順については、「 AWS Lambda デベロッパーガイド」の「関数の実行ロールを更新する」を参照してください。

Lambda 関数に関連付けられた IAM ロールには管理アクセスポリシーがあります

管理アクセスポリシーは、Lambda 関数に AWS サービスとリソースへの広範なアクセス許可を提供します。これらのポリシーには通常、機能に必要のないアクセス許可が含まれます。実行ロールに必要な最小限のアクセス許可のセットではなく、Lambda 関数の管理アクセスポリシーを IAM アイデンティティに提供すると、関数が侵害された場合に攻撃の範囲を広げることができます。標準のセキュリティ原則に従って、 AWS は最小権限を付与することをお勧めします。つまり、タスクの実行に必要なアクセス許可のみを付与します。

1. 管理ポリシーの確認と識別

   公開結果で、ロール名を特定します。IAM ダッシュボードに移動し、前に特定したロール名を持つロールを見つけます。IAM ロールにアタッチされているアクセス許可ポリシーを確認します。ポリシーが AWS マネージドポリシーの場合は、 AdministratorAccessまたは を探しますIAMFullAccess。それ以外の場合は、ポリシードキュメントで、 ステートメント"Effect": "Allow", "Action": "*"と ステートメントが"Resource": "*"一緒にあるステートメントを探します。

2. 最小特権アクセスの実装

   管理ポリシーを、関数の動作に必要な特定のアクセス許可のみを付与するポリシーに置き換えます。IAM ロールのセキュリティのベストプラクティスの詳細については、「 AWS Identity and Access Management ユーザーガイド」の「最小特権のアクセス許可を適用する」を参照してください。不要なアクセス許可を特定するには、IAM Access Analyzer を使用して、アクセス履歴に基づいてポリシーを変更する方法を理解します。詳細については、「 AWS Identity and Access Management ユーザーガイド」の「外部アクセスと未使用のアクセスの検出結果」を参照してください。または、新しい IAM ロールを作成して、既存のロールを使用して他の Lambda 関数に影響を与えないようにすることもできます。このシナリオでは、新しい IAM ロールを作成します。次に、新しいロールをインスタンスに関連付けます。関数の IAM ロールの置き換えについては、「 AWS Lambda デベロッパーガイド」の「関数の実行ロールの更新」を参照してください。

3. 安全な設定に関する考慮事項

   インスタンスに管理アクセス許可が必要な場合は、リスクを軽減するために、これらの追加のセキュリティコントロールを実装することを検討してください。

   • 多要素認証 (MFA) – MFA は、追加の形式の認証を要求することで、セキュリティレイヤーを追加します。これにより、認証情報が侵害された場合でも、不正アクセスを防ぐことができます。詳細については、「 AWS Identity and Access Management ユーザーガイド」の「多要素認証 (MFA) を要求する」を参照してください。

   • IAM 条件 – 条件要素を設定すると、ソース IP や MFA の経過時間などの要因に基づいて、管理アクセス許可をいつどのように使用できるかを制限できます。詳細については、「IAM ユーザーガイド」の「IAM ポリシーの条件を使用してアクセスをさらに制限する」を参照してください。

   • アクセス許可の境界 – アクセス許可の境界は、ロールが持つことができる最大アクセス許可を確立し、管理アクセスを持つロールのガードレールを提供します。詳細については、「 ユーザーガイド」の「アクセス許可の境界を使用してアカウント内のアクセス許可管理を委任する」を参照してください。 AWS Identity and Access Management

Lambda 関数に関連付けられた IAM ロールには、 AWS サービスへの管理アクセス権を持つポリシーがあります

サービス管理者ポリシーにより、Lambda 関数は特定の AWS サービス内のすべてのアクションを実行できます。これらのポリシーは通常、関数のオペレーションに必要な以上のアクセス許可を付与します。サービス管理者ポリシーを持つ Lambda 関数が侵害された場合、攻撃者はこれらのアクセス許可を使用して、 AWS 環境内の機密データまたはサービスにアクセスまたは変更する可能性があります。標準のセキュリティ原則に従って、最小権限を付与することをお勧めします。つまり、タスクの実行に必要なアクセス許可のみを付与します。

1. 管理ポリシーの確認と識別

   公開結果で、ARN 内のロール名を特定します。IAM ダッシュボードに移動し、ロール名を見つけます。ロールにアタッチされているアクセス許可ポリシーを確認します。ポリシーが AWS マネージドポリシーの場合は、 AdministratorAccessまたは を探しますIAMFullAccess。それ以外の場合は、ポリシードキュメントで、 ステートメント"Effect": "Allow", "Action": "*"と "Resource": "*" ステートメントを持つステートメントを探します。

2. 最小特権アクセスの実装

   管理ポリシーを、関数の動作に必要な特定のアクセス許可のみを付与するポリシーに置き換えます。詳細については、「AWS Identity and Access Management ユーザーガイド」の「最小特権アクセス許可を適用する」を参照してください。不要なアクセス許可を特定するには、IAM Access Analyzer を使用して、アクセス履歴に基づいてポリシーを変更する方法を理解します。詳細については、「 AWS Identity and Access Management ユーザーガイド」の「外部アクセスと未使用のアクセスの検出結果」を参照してください。または、新しい IAM ロールを作成して、既存のロールを使用している他の Lambda 関数に影響を与えないようにすることもできます。このシナリオでは、新しい IAM ロールを作成し、新しい IAM ロールをインスタンスに関連付けます。関数の IAM ロールを置き換える手順については、「 AWS Lambda デベロッパーガイド」の「関数の実行ロールを更新する」を参照してください。

3. 安全な設定に関する考慮事項

   インスタンスにサービスレベルの管理権限が必要な場合は、リスクを軽減するためにこれらの追加のセキュリティコントロールを実装することを検討してください。

   • 多要素認証 (MFA) – MFA は、追加の形式の認証を要求することで、セキュリティレイヤーを追加します。これにより、認証情報が侵害された場合でも、不正アクセスを防ぐことができます。詳細については、「 AWS Identity and Access Management ユーザーガイド」の「多要素認証 (MFA) を要求する」を参照してください。

   • IAM 条件 – 条件要素を設定すると、ソース IP や MFA の経過時間などの要因に基づいて、管理アクセス許可をいつどのように使用できるかを制限できます。詳細については、「 AWS Identity and Access Management ユーザーガイド」の「IAM ポリシーの条件を使用してアクセスをさらに制限する」を参照してください。

   • アクセス許可の境界 – アクセス許可の境界は、ロールが持つことができる最大アクセス許可を確立し、管理アクセスを持つロールのガードレールを提供します。詳細については、「 AWS Identity and Access Management ユーザーガイド」の「アクセス許可の境界を使用してアクセス許可の管理を委任する」を参照してください。

Lambda 関数の到達可能性特性

Lambda 関数の到達可能性特性と推奨される修復手順は次のとおりです。

Lambda 関数はパブリックに呼び出すことができます

Lambda リソースベースのポリシーは、関数を呼び出すことができるユーザーを決定します。プリンシパルとして「*」を含むリソースポリシーを持つ関数 (またはプリンシパルをまったく含まない) では、認証された AWS ユーザーが呼び出すことができます。これにより、特に機密データの処理、リソースの変更、またはアクセス許可の昇格を行う関数に重大なリスクが生じます。許可されていないユーザーは、この設定を悪用して、望ましくない操作を実行したり、データを公開したり、リソースを操作したり、関数機能を悪用したりする可能性があります。セキュリティのベストプラクティスに従って、Lambda 関数へのアクセスを承認されたプリンシパルのみに制限することをお勧めします。

関数のリソースベースのポリシーを変更する

公開のリソースタブで、ハイパーリンクを使用してリソースを開きます。これにより、Lambda 関数ウィンドウが開きます。リソースベースのポリシーで、承認された AWS アカウント IDsまたは特定の IAM プリンシパル (ユーザー、ロール、またはサービス) のみを指定して、Lambda 関数へのアクセスを制限します。リソースベースのポリシーは、プログラムでのみ変更できます。

Lambda 関数の脆弱性特性

Lambda 関数の脆弱性特性と推奨される修復手順は次のとおりです。

Lambda 関数にネットワークが爆発するソフトウェアの脆弱性がある

Lambda 関数コードで使用されるソフトウェアパッケージには、悪用される可能性が高い共通脆弱性識別子 (CVEs) を含めることができます。重要な CVEs AWS 、環境に重大なセキュリティリスクをもたらします。攻撃者は、こうしたパッチが適用されていない脆弱性を利用し、データの機密性、完全性、可用性を侵害したり、他のシステムにアクセスしたりする可能性があります。エクスプロイトコードはすでに公開されており、攻撃者や自動スキャンツールによってアクティブに使用されている可能性があるため、エクスプロイトの可能性の高い重大な脆弱性は即時のセキュリティ脅威を表します。セキュリティのベストプラクティスに従って、これらの脆弱性にパッチを適用して、 関数を攻撃から保護することをお勧めします。

影響を受ける関数を更新する

特性の脆弱性タブの「リファレンス」セクションを確認してください。ベンダーのドキュメントには、特定の修復ガイダンスが含まれている場合があります。ベンダーが推奨する手順に従って、脆弱なライブラリを最新の安全なバージョンに更新します。通常、修復ワークフローは、zip ファイルをアップロードするか、コンテナイメージで Lambda 関数を作成することによって Lambda パッケージをデプロイしたかによって異なります。ライブラリを更新したら、固定バージョンを使用するように Lambda 関数コードを更新します。その後、更新されたバージョンをデプロイします。

Lambda 関数にはソフトウェア脆弱性があります

Lambda 関数は、多くの場合、重要な CVEs と比較して重要度や脆弱性が低いセキュリティの脆弱性を含む可能性のあるサードパーティーのライブラリと依存関係を使用します。これらの重要でない脆弱性はすぐには悪用できないかもしれませんが、他の脆弱性と連鎖して関数を侵害する可能性があるセキュリティ上の弱点を表しています。時間の経過とともに、これらの脆弱性のリスクを高める新しいエクスプロイト手法も出現する可能性があります。標準的なセキュリティ原則に従って、安全な環境を維持するために、これらの脆弱性にパッチを適用することをお勧めします。

特性の脆弱性タブの「リファレンス」セクションを確認してください。ベンダーのドキュメントには、特定の修復ガイダンスが含まれている場合があります。ベンダーが推奨する手順に従って、脆弱なライブラリを最新の安全なバージョンに更新します。通常、修復ワークフローは、zip ファイルをアップロードするか、コンテナイメージで Lambda 関数を作成することによって Lambda パッケージをデプロイしたかによって異なります。ライブラリを更新したら、固定バージョンを使用するように Lambda 関数コードを更新します。その後、更新されたバージョンをデプロイします。