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

VPC に関数をアタッチする

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

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

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

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

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

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 アカウント ID または特定の IAM プリンシパル (ユーザー、ロール、またはサービス) のみを指定して、Lambda 関数へのアクセスを制限します。リソースベースのポリシーは、プログラムでのみ変更できます。

Lambda 関数の脆弱性の特性

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

Lambda 関数にネットワークで悪用される可能性の高いソフトウェアの脆弱性がある

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

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

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

Lambda 関数にソフトウェアの脆弱性がある

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

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