本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 中的安全性 AWS Lambda 的雲端安全性 AWS 是最高優先順序。身為 AWS 客戶，您可以受益於資料中心和網路架構，這些架構專為滿足最安全敏感組織的需求而建置。 安全性是 AWS 與您之間的共同責任。[‬共同責任模型‭](https://aws.amazon.com/compliance/shared-responsibility-model/)‬ 將此描述為雲端*‬的‭*‬安全和雲端*‬內*‬的安全： + **雲端的安全性** – AWS 負責保護在 AWS Cloud AWS 服務 中執行的基礎設施。 AWS 也為您提供可安全使用的服務。在 [AWS 合規計畫](https://aws.amazon.com/compliance/programs/)中，第三方稽核員會定期測試並驗證我們的安全功效。若要了解適用的合規計劃 AWS Lambda，請參閱[AWS 服務 合規計劃範圍中的](https://aws.amazon.com/compliance/services-in-scope/) 。 + **雲端內部的安全** – 您的責任取決於所使用的 AWS 服務。您也必須對其他因素負責，包括資料的機密性、您公司的要求和適用法律和法規。 本文件有助於您了解如何在使用 Lambda 時套用共同責任模型。下列主題將示範如何設定 Lambda 以達到您的安全和合規目標。您也會了解如何使用其他 AWS 服務 來協助您監控和保護 Lambda 資源。 如需有關將安全性原則套用至 Lambda 應用程式的詳細資訊，請參閱無伺服器園地中的[安全性](https://serverlessland.com/content/service/lambda/guides/aws-lambda-operator-guide/security-ops)。 **Topics** + [AWS Lambda 中的資料保護](security-dataprotection.md) + [使用 Lambda 的服務連結角色](using-service-linked-roles.md) + [的 Identity and Access Management AWS Lambda](security-iam.md) + [建立 Lambda 函數和層的控管策略](governance-concepts.md) + [的合規驗證AWS Lambda](security-compliance.md) + [AWS Lambda 中的恢復能力](security-resilience.md) + [中的基礎設施安全AWS Lambda](security-infrastructure.md) + [使用公有端點保護工作負載](security-public-endpoints.md) + [使用程式碼簽署來驗證 Lambda 的程式碼完整性](configuration-codesigning.md) # AWS Lambda 中的資料保護 AWS [共同的責任模型](https://aws.amazon.com/compliance/shared-responsibility-model/)適用於 AWS Lambda 中的資料保護。如此模型所述，AWS 負責保護執行所有 AWS 雲端 的全球基礎設施。您負責維護在此基礎設施上託管內容的控制權。您也同時負責所使用 AWS 服務 的安全組態和管理任務。如需資料隱私權的詳細資訊，請參閱[資料隱私權常見問答集](https://aws.amazon.com/compliance/data-privacy-faq/)。如需有關歐洲資料保護的相關資訊，請參閱 *AWS 安全性部落格*上的 [AWS 共同的責任模型和 GDPR](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) 部落格文章。 基於資料保護目的，建議您使用 AWS IAM Identity Center 或 AWS Identity and Access Management (IAM) 保護 AWS 帳戶 憑證，並設定個人使用者。如此一來，每個使用者都只會獲得授與完成其任務所必須的許可。我們也建議您採用下列方式保護資料： + 每個帳戶均要使用多重要素驗證 (MFA)。 + 使用 SSL/TLS 與 AWS 資源通訊。我們需要 TLS 1.2 並建議使用 TLS 1.3。 + 使用 AWS CloudTrail 設定 API 和使用者活動日誌記錄。如需使用 CloudTrail 追蹤擷取 AWS 活動的相關資訊，請參閱「AWS CloudTrail 使用者指南」**中的[使用 CloudTrail 追蹤](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html)。 + 使用 AWS 加密解決方案，以及 AWS 服務 內的所有預設安全控制項。 + 使用進階的受管安全服務 (例如 Amazon Macie)，協助探索和保護儲存在 Amazon S3 的敏感資料。 + 如果您在透過命令列介面或 API 存取 AWS 時，需要 FIPS 140-3 驗證的加密模組，請使用 FIPS 端點。如需有關 FIPS 和 FIPS 端點的更多相關資訊，請參閱[聯邦資訊處理標準 (FIPS) 140-3](https://aws.amazon.com/compliance/fips/)。 我們強烈建議您絕對不要將客戶的電子郵件地址等機密或敏感資訊，放在標籤或自由格式的文字欄位中，例如**名稱**欄位。這包括透過主控台、API、AWS CLI 或 AWS SDK，使用 Lambda 或其他 AWS 服務時。您在標籤或自由格式文字欄位中輸入的任何資料都可能用於計費或診斷日誌。如果您提供外部伺服器的 URL，我們強烈建議請勿在驗證您對該伺服器請求的 URL 中包含憑證資訊。 **Topics** + [傳輸中加密](#security-privacy-intransit) + [AWS Lambda 的靜態資料加密](security-encryption-at-rest.md) ## 傳輸中加密 Lambda API 端點僅支援透過 HTTPS 的安全連線。當您使用 AWS 管理主控台、AWS 開發套件或 Lambda API 來管理 資源時，所有通訊都會使用 Transport Layer Security (TLS) 加密。如需完整的 API 端點清單，請參閱《AWS 一般參考》中的[AWS 區域和端點](https://docs.aws.amazon.com/general/latest/gr/rande.html)。 當您[將您的函數連線至檔案系統](configuration-filesystem.md)時，Lambda 會針對所有連線使用傳輸中加密。如需詳細資訊，請參閱 *Amazon Elastic File System 使用者指南*中的 [Amazon EFS 的資料加密](https://docs.aws.amazon.com/efs/latest/ug/encryption.html)。 使用[環境變數](configuration-envvars.md)時，您可以啟用主控台加密協助程式以使用用戶端加密來保護傳輸中的環境變數。如需更多詳細資訊，請參閱 [保護 Lambda 環境變數](configuration-envvars-encryption.md)。 # AWS Lambda 的靜態資料加密 Lambda 一律使用 [AWS 擁有的金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-owned-cmk)或 [AWS 受管金鑰](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) 為下列資源提供靜態加密： + 環境變數 + 您上傳到 Lambda 的檔案，包括部署套件和層封存 + 事件來源映射篩選條件物件 您可以選擇將 Lambda 設定為使用客戶受管金鑰來加密[環境變數](configuration-envvars-encryption.md)、[.zip 部署套件](encrypt-zip-package.md)和[篩選條件物件](invocation-eventfiltering.md#filter-criteria-encryption)。 根據預設，Amazon CloudWatch Logs 和 AWS X-Ray 也可加密資料，並可設定為使用客戶受管金鑰。如需詳細資訊，請參閱[在 CloudWatch Logs 中加密日誌資料](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/encrypt-log-data-kms.html)和[AWS X-Ray 中的資料保護](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-encryption.html)。 ## 監控 Lambda 的加密金鑰 當您搭配 Lambda 使用 AWS KMS 客戶受管金鑰時，您可以使用 [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html)。下列範例是 Lambda 為存取客戶受管金鑰加密的資料而進行的 `Decrypt`、 `DescribeKey` 和 `GenerateDataKey` 呼叫的 CloudTrail 事件。 ------ #### [ Decrypt ] 如果您使用 AWS KMS 客戶受管金鑰來加密[篩選條件](invocation-eventfiltering.md#filter-criteria-encryption)物件，Lambda 會在您嘗試以純文字存取該金鑰時 (例如，從 `ListEventSourceMappings` 呼叫)，代表您傳送 `Decrypt` 請求。下面的範例事件會記錄 `Decrypt` 操作： ``` { "eventVersion": "1.09", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:example", "arn": "arn:aws:sts::123456789012:assumed-role/role-name/example", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::123456789012:role/role-name", "accountId": "123456789012", "userName": "role-name" }, "attributes": { "creationDate": "2024-05-30T00:45:23Z", "mfaAuthenticated": "false" } }, "invokedBy": "lambda.amazonaws.com" }, "eventTime": "2024-05-30T01:05:46Z", "eventSource": "kms.amazonaws.com", "eventName": "Decrypt", "awsRegion": "eu-west-1", "sourceIPAddress": "lambda.amazonaws.com", "userAgent": "lambda.amazonaws.com", "requestParameters": { "keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "encryptionContext": { "aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==", "aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source", "aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function" }, "encryptionAlgorithm": "SYMMETRIC_DEFAULT" }, "responseElements": null, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb", "readOnly": true, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management", "sessionCredentialFromConsole": "true" } ``` ------ #### [ DescribeKey ] 如果您使用 AWS KMS 客戶受管金鑰來加密[篩選條件](invocation-eventfiltering.md#filter-criteria-encryption)物件，Lambda 會在您嘗試存取該金鑰時 (例如，從 `GetEventSourceMapping` 呼叫)，代表您傳送 `DescribeKey` 請求。下面的範例事件會記錄 `DescribeKey` 操作： ``` { "eventVersion": "1.09", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:example", "arn": "arn:aws:sts::123456789012:assumed-role/role-name/example", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::123456789012:role/role-name", "accountId": "123456789012", "userName": "role-name" }, "attributes": { "creationDate": "2024-05-30T00:45:23Z", "mfaAuthenticated": "false" } } }, "eventTime": "2024-05-30T01:09:40Z", "eventSource": "kms.amazonaws.com", "eventName": "DescribeKey", "awsRegion": "eu-west-1", "sourceIPAddress": "54.240.197.238", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36", "requestParameters": { "keyId": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" }, "responseElements": null, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb", "readOnly": true, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management", "tlsDetails": { "tlsVersion": "TLSv1.3", "cipherSuite": "TLS_AES_256_GCM_SHA384", "clientProvidedHostHeader": "kms.eu-west-1.amazonaws.com" }, "sessionCredentialFromConsole": "true" } ``` ------ #### [ GenerateDataKey ] 當您使用 AWS KMS 客戶受管金鑰來加密 `CreateEventSourceMapping` 或 `UpdateEventSourceMapping` 呼叫中的[篩選條件](invocation-eventfiltering.md#filter-criteria-encryption)物件時，Lambda 會代表您傳送 `GenerateDataKey` 請求，以產生資料金鑰來加密篩選條件 ([封套加密](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#enveloping))。下面的範例事件會記錄 `GenerateDataKey` 操作： ``` { "eventVersion": "1.09", "userIdentity": { "type": "AssumedRole", "principalId": "AROA123456789EXAMPLE:example", "arn": "arn:aws:sts::123456789012:assumed-role/role-name/example", "accountId": "123456789012", "accessKeyId": "ASIAIOSFODNN7EXAMPLE", "sessionContext": { "sessionIssuer": { "type": "Role", "principalId": "AROA123456789EXAMPLE", "arn": "arn:aws:iam::123456789012:role/role-name", "accountId": "123456789012", "userName": "role-name" }, "attributes": { "creationDate": "2024-05-30T00:06:07Z", "mfaAuthenticated": "false" } }, "invokedBy": "lambda.amazonaws.com" }, "eventTime": "2024-05-30T01:04:18Z", "eventSource": "kms.amazonaws.com", "eventName": "GenerateDataKey", "awsRegion": "eu-west-1", "sourceIPAddress": "lambda.amazonaws.com", "userAgent": "lambda.amazonaws.com", "requestParameters": { "numberOfBytes": 32, "keyId": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "encryptionContext": { "aws-crypto-public-key": "ABCD+7876787678+CDEFGHIJKL/888666888999888555444111555222888333111==", "aws:lambda:EventSourceArn": "arn:aws:sqs:eu-west-1:123456789012:sample-source", "aws:lambda:FunctionArn": "arn:aws:lambda:eu-west-1:123456789012:function:sample-function" }, }, "responseElements": null, "requestID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEaaaaa", "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLEbbbbb", "readOnly": true, "resources": [ { "accountId": "AWS Internal", "type": "AWS::KMS::Key", "ARN": "arn:aws:kms:eu-west-1:123456789012:key/a1b2c3d4-5678-90ab-cdef-EXAMPLE11111" } ], "eventType": "AwsApiCall", "managementEvent": true, "recipientAccountId": "123456789012", "eventCategory": "Management" } ``` ------ # 使用 Lambda 的服務連結角色 Lambda 使用 AWS Identity and Access Management (IAM) [服務連結角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role)。服務連結角色是直接連結至 Lambda 的唯一 IAM 角色類型。服務連結角色由 Lambda 預先定義，並包含服務代表您呼叫其他 AWS 服務所需的許可。 Lambda 定義其服務連結角色的許可，只有 Lambda 可以擔任其角色。定義的許可包括信任政策和許可政策，且該許可政策無法附加至其他 IAM 實體。 您必須先刪除服務連結角色的相關資源，才能將其刪除。這可保護您的 Lambda 資源，因為您不會不小心移除存取資源的許可。 如需有關支援服務連結角色的其他 服務的資訊，請參閱[AWS 使用 IAM 的服務](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)，並在**服務連結角色**欄中尋找具有**是**的服務。選擇具有連結的**是**，以檢視該服務的服務連結角色文件。 ## Lambda 的服務連結角色許可 Lambda 使用名為 **AWSServiceRoleForLambda** 的服務連結角色。 服務連結角色信任下列服務以擔任角色： + `lambda.amazonaws.com` 名為 AWSLambdaServiceRolePolicy 的角色許可政策可讓 Lambda 對指定的資源完成下列動作： + 動作：`ec2:TerminateInstances`在 上`arn:aws:ec2:*:*:instance/*`，條件`ec2:ManagedResourceOperator`等於 `scaler.lambda.amazonaws.com` + 動作：`ec2:DescribeInstanceStatus` 和 `*` 的 `ec2:DescribeInstances` 您必須設定許可，以允許您的使用者、群組或角色建立、編輯或刪除服務連結角色。如需詳細資訊，請參閱 *IAM 使用者指南*中的[服務連結角色許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions)。 如需受管政策更新，請參閱 [Lambda 受管政策](security-iam-awsmanpol.md#lambda-security-iam-awsmanpol-updates)。 ## 為 Lambda 建立服務連結角色 您不需要手動建立服務連結角色，當您在 AWS 管理主控台、 AWS CLI或 AWS API 中建立 Lambda 容量提供者時，Lambda 會為您建立服務連結角色。 若您刪除此服務連結角色，之後需要再次建立，您可以在帳戶中使用相同程序重新建立角色。當您建立 Lambda 容量提供者時，Lambda 會再次為您建立服務連結角色。 您也可以使用 IAM 主控台建立具有 **AWSServiceRoleForLambda** 使用案例的服務連結角色。在 AWS CLI 或 AWS API 中，使用服務名稱建立`lambda.amazonaws.com`服務連結角色。如需詳細資訊，請參閱《IAM 使用者指南》**中的「[建立服務連結角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#create-service-linked-role)」。如果您刪除此服務連結角色，您可以使用此相同的程序以再次建立該角色。 ## 編輯 Lambda 的服務連結角色 Lambda 不允許您編輯 AWSServiceRoleForLambda 服務連結角色。因為有各種實體可能會參考服務連結角色，所以您無法在建立角色之後變更角色名稱。然而，您可使用 IAM 來編輯角色描述。如需詳細資訊，請參閱《*IAM 使用者指南*》中的[編輯服務連結角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role)。 ## 刪除 Lambda 的服務連結角色 若您不再使用需要服務連結角色的功能或服務，我們建議您刪除該角色。如此一來，您就沒有未主動監控或維護的未使用實體。然而，在手動刪除服務連結角色之前，您必須先清除資源。 **注意** 如果 Lambda 服務在您嘗試刪除資源時使用角色，則刪除可能會失敗。若此情況發生，請等待數分鐘後並再次嘗試操作。 **刪除 AWSServiceRoleForLambda 使用的 Lambda 資源** 1. 從您的帳戶中移除所有 Lambda 容量提供者。您可以使用 Lambda 主控台、CLI 或 API 來執行此操作。 1. 在嘗試刪除服務連結角色之前，請確認您的帳戶中沒有 Lambda 容量提供者。 **使用 IAM 手動刪除服務連結角色** 使用 IAM 主控台 AWS CLI、 或 AWS API 來刪除 AWSServiceRoleForLambda 服務連結角色。如需詳細資訊，請參閱《*IAM 使用者指南*》中的[刪除服務連結角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#delete-service-linked-role)。 ## Lambda 服務連結角色支援的區域 Lambda 不支援在提供服務的每個區域中使用服務連結角色。下列區域支援 AWSServiceRoleForLambda。 | 區域名稱 | 區域身分 | Lambda 支援 | | --- | --- | --- | | 美國東部 (維吉尼亞北部) | us-east-1 | 是 | | 美國東部 (俄亥俄) | us-east-2 | 是 | | 美國西部 (加利佛尼亞北部) | us-west-1 | 是 | | 美國西部 (奧勒岡) | us-west-2 | 是 | | Africa (Cape Town) | af-south-1 | 否 | | 亞太地區 (香港) | ap-east-1 | 是 | | 亞太地區 (雅加達) | ap-southeast-3 | 是 | | 亞太區域 （曼谷） | ap-southeast-7 | 是 | | 亞太區域 (孟買) | ap-south-1 | 是 | | 亞太區域 (大阪) | ap-northeast-3 | 否 | | 亞太區域 (首爾) | ap-northeast-2 | 否 | | 亞太區域 (新加坡) | ap-southeast-1 | 是 | | 亞太區域 (雪梨) | ap-southeast-2 | 是 | | 亞太區域 (東京) | ap-northeast-1 | 是 | | 加拿大 (中部) | ca-central-1 | 否 | | 歐洲 (法蘭克福) | eu-central-1 | 是 | | 歐洲 (愛爾蘭) | eu-west-1 | 是 | | 歐洲 (倫敦) | eu-west-2 | 是 | | 歐洲 (米蘭) | eu-south-1 | 否 | | Europe (Paris) | eu-west-3 | 否 | | Europe (Stockholm) | eu-north-1 | 否 | | Middle East (Bahrain) | me-south-1 | 否 | | 中東 (阿拉伯聯合大公國) | me-central-1 | 否 | | 南美洲 (聖保羅) | sa-east-1 | 否 | | AWS GovCloud （美國東部） | us-gov-east-1 | 否 | | AWS GovCloud （美國西部） | us-gov-west-1 | 否 | # 的 Identity and Access Management AWS Lambda AWS Identity and Access Management (IAM) 是一種 AWS 服務 ，可協助管理員安全地控制對 AWS 資源的存取。IAM 管理員會控制誰經過身分*身分驗證* (已登入) 並得到*授權* (具有許可) 來使用 Lambda 資源。IAM 是您可以免費使用 AWS 服務 的 。 **Topics** + [目標對象](#security_iam_audience) + [使用身分驗證](#security_iam_authentication) + [使用政策管理存取權](#security_iam_access-manage) + [AWS Lambda 如何使用 IAM](security_iam_service-with-iam.md) + [的身分型政策範例 AWS Lambda](security_iam_id-based-policy-examples.md) + [AWS 的 受管政策 AWS Lambda](security-iam-awsmanpol.md) + [對 AWS Lambda 身分和存取進行故障診斷](security_iam_troubleshoot.md) ## 目標對象 使用方式 AWS Identity and Access Management (IAM) 會根據您的角色而有所不同： + **服務使用者** — 若無法存取某些功能，請向管理員申請所需許可 (請參閱 [對 AWS Lambda 身分和存取進行故障診斷](security_iam_troubleshoot.md)) + **服務管理員** — 負責設定使用者存取權並提交相關許可請求 (請參閱 [AWS Lambda 如何使用 IAM](security_iam_service-with-iam.md)) + **IAM 管理員** — 撰寫政策以管理存取控制 (請參閱 [的身分型政策範例 AWS Lambda](security_iam_id-based-policy-examples.md)) ## 使用身分驗證 身分驗證是您 AWS 使用身分憑證登入 的方式。您必須以 AWS 帳戶根使用者、IAM 使用者或擔任 IAM 角色身分進行身分驗證。 您可以使用身分來源的登入資料，例如 AWS IAM Identity Center (IAM Identity Center)、單一登入身分驗證或 Google/Facebook 登入資料，以聯合身分的形式登入。如需有關登入的詳細資訊，請參閱《AWS 登入 使用者指南》**中的[如何登入您的 AWS 帳戶](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html)。 對於程式設計存取， AWS 提供 SDK 和 CLI 以密碼編譯方式簽署請求。如需詳細資訊，請參閱《IAM 使用者指南》**中的 [API 請求的AWS 第 4 版簽署程序](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html)。 ### AWS 帳戶 根使用者 當您建立 時 AWS 帳戶，您會從一個名為 AWS 帳戶 *theroot 使用者的*登入身分開始，該身分具有對所有 AWS 服務 和 資源的完整存取權。強烈建議不要使用根使用者來執行日常任務。有關需要根使用者憑證的任務，請參閱《IAM 使用者指南》**中的[需要根使用者憑證的任務](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks)。 ### 聯合身分 最佳實務是要求人類使用者使用聯合身分提供者，以 AWS 服務 使用臨時憑證存取 。 *聯合身分*是您企業目錄、Web 身分提供者的使用者，或使用來自身分來源的 AWS 服務 憑證存取 Directory Service 。聯合身分會擔任角色，而該角色會提供臨時憑證。 若需集中化管理存取權限，建議使用 AWS IAM Identity Center。如需詳細資訊，請參閱 *AWS IAM Identity Center 使用者指南*中的[什麼是 IAM Identity Center？](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html)。 ### IAM 使用者和群組 *IAM 使用者*[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)是一種身分具備單人或應用程式的特定許可權。建議以臨時憑證取代具備長期憑證的 IAM 使用者。如需詳細資訊，請參閱《*IAM 使用者指南*》中的[要求人類使用者使用聯合身分提供者來 AWS 使用臨時憑證存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) 。 [IAM 群組](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html)**會指定 IAM 使用者集合，使管理大量使用者的許可權更加輕鬆。如需詳細資訊，請參閱《IAM 使用者指南》**中的 [IAM 使用者的使用案例](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html)。 ### IAM 角色 *IAM 角色*[https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)的身分具有特定許可權，其可以提供臨時憑證。您可以透過[從使用者切換到 IAM 角色 （主控台） ](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html)或呼叫 AWS CLI 或 AWS API 操作來擔任角色。如需詳細資訊，請參閱《IAM 使用者指南》**中的[擔任角色的方法](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html)。 IAM 角色適用於聯合身分使用者存取、臨時 IAM 使用者許可、跨帳戶存取權與跨服務存取，以及在 Amazon EC2 執行的應用程式。如需詳細資訊，請參閱《*IAM 使用者指南*》中的 [IAM 中的快帳戶資源存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。 ## 使用政策管理存取權 您可以透過建立政策並將其連接到身分或資源 AWS 來控制 AWS 中的存取。政策定義與身分或資源相關聯的許可。當委託人提出請求時 AWS ， 會評估這些政策。大多數政策會以 JSON 文件 AWS 形式存放在 中。如需進一步了解 JSON 政策文件，請參閱《*IAM 使用者指南*》中的 [JSON 政策概觀](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json)。 管理員會使用政策，透過定義哪些**主體**可在哪些**條件**下對哪些**資源**執行**動作**，以指定可存取的範圍。 預設情況下，使用者和角色沒有許可。IAM 管理員會建立 IAM 政策並將其新增至角色，供使用者後續擔任。IAM 政策定義動作的許可，無論採用何種方式執行。 ### 身分型政策 身分型政策是附加至身分 (使用者、使用者群組或角色) 的 JSON 許可政策文件。這類政策控制身分可對哪些資源執行哪些動作，以及適用的條件。如需了解如何建立身分型政策，請參閱《*IAM 使用者指南*》中的[透過客戶管理政策定義自訂 IAM 許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。 身分型政策可分為*內嵌政策* (直接內嵌於單一身分) 與*受管政策* (可附加至多個身分的獨立政策)。如需了解如何在受管政策及內嵌政策之間做選擇，請參閱《IAM 使用者指南》**中的[在受管政策與內嵌政策之間選擇](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html)。 ### 資源型政策 資源型政策是附加到資源的 JSON 政策文件。範例包括 IAM *角色信任政策*與 Amazon S3 *儲存貯體政策*。在支援資源型政策的服務中，服務管理員可以使用它們來控制對特定資源的存取權限。您必須在資源型政策中[指定主體](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)。 資源型政策是位於該服務中的內嵌政策。您無法在資源型政策中使用來自 IAM 的 AWS 受管政策。 ### 其他政策類型 AWS 支援其他政策類型，可設定更多常見政策類型授予的最大許可： + **許可界限** — 設定身分型政策可授與 IAM 實體的最大許可。如需詳細資訊，請參閱《 IAM 使用者指南》**中的 [IAM 實體許可界限](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)。 + **服務控制政策 (SCP)** — 為 AWS Organizations中的組織或組織單位指定最大許可。如需詳細資訊，請參閱《AWS Organizations 使用者指南》**中的[服務控制政策](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)。 + **資源控制政策 (RCP)** — 設定您帳戶中資源可用許可的上限。如需詳細資訊，請參閱《AWS Organizations 使用者指南》**中的[資源控制政策 (RCP)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html)。 + **工作階段政策** — 在以程式設計方式為角色或聯合身分使用者建立臨時工作階段時，以參數形式傳遞的進階政策。如需詳細資訊，請參《*IAM 使用者指南*》中的[工作階段政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)。 ### 多種政策類型 當多種類型的政策適用於請求時，產生的許可會更複雜而無法理解。若要了解如何 AWS 在涉及多種政策類型時決定是否允許請求，請參閱《*IAM 使用者指南*》中的[政策評估邏輯](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html)。 # AWS Lambda 如何使用 IAM 在您使用 IAM 管理 Lambda 的存取權之前，請了解搭配 Lambda 使用的 IAM 功能有哪些。 | IAM 功能 | Lambda 支援 | | --- | --- | | [身分型政策](#security_iam_service-with-iam-id-based-policies) | 是 | | [資源型政策](#security_iam_service-with-iam-resource-based-policies) | 是 | | [政策動作](#security_iam_service-with-iam-id-based-policies-actions) | 是 | | [政策資源](#security_iam_service-with-iam-id-based-policies-resources) | 是 | | [政策條件索引鍵 (服務特定)](#security_iam_service-with-iam-id-based-policies-conditionkeys) | 是 | | [ACL](#security_iam_service-with-iam-acls) | 否 | | [ABAC(政策中的標籤)](#security_iam_service-with-iam-tags) | 部分 | | [臨時憑證](#security_iam_service-with-iam-roles-tempcreds) | 是 | | [轉送存取工作階段 (FAS)](#security_iam_service-with-iam-principal-permissions) | 否 | | [服務角色](#security_iam_service-with-iam-roles-service) | 是 | | [服務連結角色](#security_iam_service-with-iam-roles-service-linked) | 部分 | 若要全面了解 Lambda 和其他 AWS 服務如何與大多數 IAM 功能搭配使用，請參閱《[AWS IAM 使用者指南》中的與 IAM 搭配使用的 服務](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。 ** ## 適用於 Lambda 的身分型政策 **支援身分型政策：**是 身分型政策是可以附加到身分 (例如 IAM 使用者、使用者群組或角色) 的 JSON 許可政策文件。這些政策可控制身分在何種條件下能對哪些資源執行哪些動作。如需了解如何建立身分型政策，請參閱《*IAM 使用者指南*》中的[透過客戶管理政策定義自訂 IAM 許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html)。 使用 IAM 身分型政策，您可以指定允許或拒絕的動作和資源，以及在何種條件下允許或拒絕動作。如要了解您在 JSON 政策中使用的所有元素，請參閱《*IAM 使用者指南*》中的 [IAM JSON 政策元素參考](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html)。 ### 適用於 Lambda 的身分型政策範例 若要檢視 Lambda 身分型政策範例，請參閱[的身分型政策範例 AWS Lambda](security_iam_id-based-policy-examples.md)。 ## Lambda 內的資源型政策 **支援資源型政策：**是 資源型政策是附加到資源的 JSON 政策文件。資源型政策的最常見範例是 IAM *角色信任政策*和 Amazon S3 *儲存貯體政策*。在支援資源型政策的服務中，服務管理員可以使用它們來控制對特定資源的存取權限。對於附加政策的資源，政策會定義指定的主體可以對該資源執行的動作以及在何種條件下執行的動作。您必須在資源型政策中[指定主體](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html)。委託人可以包含帳戶、使用者、角色、聯合身分使用者或 AWS 服務。 如需啟用跨帳戶存取權，您可以在其他帳戶內指定所有帳戶或 IAM 實體作為資源型政策的主體。如需詳細資訊，請參閱《*IAM 使用者指南*》中的 [IAM 中的快帳戶資源存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。 您可以將資源型政策連接至 Lambda 函數或層。此政策定義哪些主體可以對函數或層執行動作。 若要了解如何將資源型政策連接到函數或層，請參閱[在 Lambda 中檢視資源型 IAM 政策](access-control-resource-based.md)。 ## 適用於 Lambda 的政策動作 **支援政策動作：**是 管理員可以使用 AWS JSON 政策來指定誰可以存取內容。也就是說，哪個**主體**在什麼**條件**下可以對什麼**資源**執行哪些**動作**。 JSON 政策的 `Action` 元素描述您可以用來允許或拒絕政策中存取的動作。政策會使用動作來授予執行相關聯動作的許可。 如要查看 Lambda 動作的清單，請參閱*《服務授權參考》*中的 [Actions defined by AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions)。 Lambda 中的政策動作會在動作之前使用以下字首： ``` lambda ``` 若要在單一陳述式中指定多個動作，請用逗號分隔。 ``` "Action": [ "lambda:action1", "lambda:action2" ] ``` 若要檢視 Lambda 身分型政策範例，請參閱[的身分型政策範例 AWS Lambda](security_iam_id-based-policy-examples.md)。 ## 適用於 Lambda 的政策資源 **支援政策資源：**是 管理員可以使用 AWS JSON 政策來指定誰可以存取內容。也就是說，哪個**主體**在什麼**條件**下可以對什麼**資源**執行哪些**動作**。 `Resource` JSON 政策元素可指定要套用動作的物件。最佳實務是使用其 [Amazon Resource Name (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html) 來指定資源。若動作不支援資源層級許可，使用萬用字元 (\$1) 表示該陳述式適用於所有資源。 ``` "Resource": "*" ``` 若要查看 Lambda 資源類型及其 ARN 的清單，請參閱《服務授權參考》**中的 [Resource types defined by AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-resources-for-iam-policies)。若要了解您可以使用哪些動作指定每個資源的 ARN，請參閱 [AWS Lambda定義的動作](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions)。 若要檢視 Lambda 身分型政策範例，請參閱[的身分型政策範例 AWS Lambda](security_iam_id-based-policy-examples.md)。 ## 適用於 Lambda 的政策條件索引鍵 **支援服務特定政策條件金鑰：**是 管理員可以使用 AWS JSON 政策來指定誰可以存取內容。也就是說，哪個**主體**在什麼**條件**下可以對什麼**資源**執行哪些**動作**。 `Condition` 元素會根據定義的條件，指定陳述式的執行時機。您可以建立使用[條件運算子](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html)的條件運算式 (例如等於或小於)，來比對政策中的條件和請求中的值。若要查看所有 AWS 全域條件索引鍵，請參閱《*IAM 使用者指南*》中的[AWS 全域條件內容索引鍵](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html)。 如要查看 Lambda 條件索引鍵的清單，請參閱《服務授權參考》**中的 [Condition keys for AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-policy-keys)。若要了解您可以使用條件索引鍵的動作和資源，請參閱 [定義的動作 AWS Lambda](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html#awslambda-actions-as-permissions)。 若要檢視 Lambda 身分型政策範例，請參閱[的身分型政策範例 AWS Lambda](security_iam_id-based-policy-examples.md)。 ## Lambda 中的 ACL **支援 ACL：**否 存取控制清單 (ACL) 可控制哪些主體 (帳戶成員、使用者或角色) 擁有存取某資源的許可。ACL 類似於資源型政策，但它們不使用 JSON 政策文件格式。 ## 使用 Lambda 的 ABAC **支援 ABAC (政策中的標籤)：**部分 屬性型存取控制 (ABAC) 是一種授權策略，根據稱為標籤的屬性定義許可權。您可以將標籤連接至 IAM 實體 AWS 和資源，然後設計 ABAC 政策，以便在委託人的標籤符合資源上的標籤時允許操作。 如需根據標籤控制存取，請使用 `aws:ResourceTag/key-name`、`aws:RequestTag/key-name` 或 `aws:TagKeys` 條件索引鍵，在政策的[條件元素](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)中，提供標籤資訊。 如果服務支援每個資源類型的全部三個條件金鑰，則對該服務而言，值為 **Yes**。如果服務僅支援某些資源類型的全部三個條件金鑰，則值為 **Partial**。 如需 ABAC 的詳細資訊，請參閱《*IAM 使用者指南*》中的[使用 ABAC 授權定義許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)。如要查看含有設定 ABAC 步驟的教學課程，請參閱《*IAM 使用者指南*》中的[使用屬性型存取控制 (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html)。 如需標記 Lambda 資源的詳細資訊，請參閱[使用 Lambda 中的屬性型存取控制](attribute-based-access-control.md)。 ## 將臨時憑證與 Lambda 搭配使用 **支援臨時憑證：**是 臨時登入資料提供對 AWS 資源的短期存取，並在您使用聯合或切換角色時自動建立。 AWS 建議您動態產生臨時登入資料，而不是使用長期存取金鑰。如需詳細資訊，請參閱《*IAM 使用者指南*》中的 [IAM 中的臨時安全憑證](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html)與[可與 IAM 搭配運作的AWS 服務](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。 ## 轉送 Lambda 的存取工作階段 **支援轉寄存取工作階段 (FAS)**：否 轉送存取工作階段 (FAS) 使用呼叫 的委託人許可 AWS 服務，並結合 AWS 服務 請求向下游服務提出請求。如需提出 FAS 請求時的政策詳細資訊，請參閱[轉發存取工作階段](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html)。 ## Lambda 的服務角色 **支援服務角色：**是 服務角色是服務擔任的 [IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)，可代您執行動作。IAM 管理員可以從 IAM 內建立、修改和刪除服務角色。如需詳細資訊，請參閱《*IAM 使用者指南*》中的[建立角色以委派許可給 AWS 服務](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html)。 在 Lambda 中，服務角色稱為[執行角色](lambda-intro-execution-role.md)。 **警告** 變更執行角色的許可有可能會讓 Lambda 功能出現故障。 ## Lambda 的服務連結角色 **支援服務連結角色：**部分 服務連結角色是連結至 的一種服務角色 AWS 服務。服務可以擔任代表您執行動作的角色。服務連結角色會出現在您的 中 AWS 帳戶 ，並由服務擁有。IAM 管理員可以檢視，但不能編輯服務連結角色的許可。 Lambda 沒有服務連結角色，但 Lambda@Edge 則有。如需詳細資訊，請參閱《Amazon CloudFront 開發人員指南》**中的 [Lambda@Edge 的服務連結角色](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-edge-permissions.html#using-service-linked-roles)。 如需建立或管理服務連結角色的詳細資訊，請參閱[可搭配 IAM 運作的AWS 服務](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)。在資料表中尋找服務，其中包含**服務連結角色**欄中的 `Yes`。選擇**是**連結，以檢視該服務的服務連結角色文件。 # 的身分型政策範例 AWS Lambda 根據預設，使用者和角色不具備建立或修改 Lambda 資源的許可。若要授予使用者對其所需資源執行動作的許可，IAM 管理員可以建立 IAM 政策。 如需了解如何使用這些範例 JSON 政策文件建立 IAM 身分型政策，請參閱《*IAM 使用者指南*》中的[建立 IAM 政策 (主控台)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html)。 如需 Lambda 所定義之動作和資源類型的詳細資訊，包括每種資源類型的 ARN 格式，請參閱*《服務授權參考》*中的[適用於 AWS Lambda的動作、資源和條件索引鍵](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awslambda.html)。 **Topics** + [政策最佳實務](#security_iam_service-with-iam-policy-best-practices) + [使用 Lambda 主控台](#security_iam_id-based-policy-examples-console) + [允許使用者檢視他們自己的許可](#security_iam_id-based-policy-examples-view-own-permissions) ## 政策最佳實務 身分型政策會判斷您帳戶中的某個人員是否可以建立、存取或刪除 Lambda 資源。這些動作可能會讓您的 AWS 帳戶產生費用。當您建立或編輯身分型政策時，請遵循下列準則及建議事項： + **開始使用 AWS 受管政策並邁向最低權限許可** – 若要開始將許可授予您的使用者和工作負載，請使用將許可授予許多常見使用案例的 *AWS 受管政策*。它們可在您的 中使用 AWS 帳戶。我們建議您定義特定於使用案例 AWS 的客戶受管政策，進一步減少許可。如需更多資訊，請參閱《*IAM 使用者指南*》中的 [AWS 受管政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)或[任務職能的AWS 受管政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html)。 + **套用最低權限許可** – 設定 IAM 政策的許可時，請僅授予執行任務所需的許可。為實現此目的，您可以定義在特定條件下可以對特定資源採取的動作，這也稱為*最低權限許可*。如需使用 IAM 套用許可的更多相關資訊，請參閱《*IAM 使用者指南*》中的 [IAM 中的政策和許可](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html)。 + **使用 IAM 政策中的條件進一步限制存取權** – 您可以將條件新增至政策，以限制動作和資源的存取。例如，您可以撰寫政策條件，指定必須使用 SSL 傳送所有請求。如果透過特定 ，例如 使用服務動作 AWS 服務，您也可以使用條件來授予存取 CloudFormation。如需詳細資訊，請參閱《*IAM 使用者指南*》中的 [IAM JSON 政策元素：條件](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html)。 + **使用 IAM Access Analyzer 驗證 IAM 政策，確保許可安全且可正常運作** – IAM Access Analyzer 驗證新政策和現有政策，確保這些政策遵從 IAM 政策語言 (JSON) 和 IAM 最佳實務。IAM Access Analyzer 提供 100 多項政策檢查及切實可行的建議，可協助您撰寫安全且實用的政策。如需詳細資訊，請參閱《*IAM 使用者指南*》中的[使用 IAM Access Analyzer 驗證政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html)。 + **需要多重要素驗證 (MFA)** – 如果您的案例需要 IAM 使用者或 中的根使用者 AWS 帳戶，請開啟 MFA 以提高安全性。如需在呼叫 API 操作時請求 MFA，請將 MFA 條件新增至您的政策。如需詳細資訊，請參閱《*IAM 使用者指南*》中的[透過 MFA 的安全 API 存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html)。 如需 IAM 中最佳實務的相關資訊，請參閱《*IAM 使用者指南*》中的 [IAM 安全最佳實務](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html)。 ## 使用 Lambda 主控台 若要存取 AWS Lambda 主控台，您必須擁有一組最低許可。這些許可必須允許您列出和檢視 中 Lambda 資源的詳細資訊 AWS 帳戶。如果您建立比最基本必要許可更嚴格的身分型政策，則對於具有該政策的實體 (使用者或角色) 而言，主控台就無法如預期運作。 對於僅呼叫 AWS CLI 或 AWS API 的使用者，您不需要允許最低主控台許可。反之，只需允許存取符合他們嘗試執行之 API 操作的動作就可以了。 如需針對函式開發授予最低存取權的範例政策，請參閱 [授予使用者對 Lambda 函數的存取權](permissions-user-function.md)。除了 Lambda API，Lambda 主控台會使用其他服務來顯示觸發組態，並讓您新增新的觸發。如果您的使用者搭配其他服務使用 Lambda，他們就必須也要存取這些服務。如需透過 Lambda 設定其他服務的詳細資訊，請參閱 [使用來自其他服務的事件叫用 Lambda AWS](lambda-services.md)。 ## 允許使用者檢視他們自己的許可 此範例會示範如何建立政策，允許 IAM 使用者檢視附加到他們使用者身分的內嵌及受管政策。此政策包含在主控台或使用 或 AWS CLI AWS API 以程式設計方式完成此動作的許可。 ``` { "Version": "2012-10-17", "Statement": [ { "Sid": "ViewOwnUserInfo", "Effect": "Allow", "Action": [ "iam:GetUserPolicy", "iam:ListGroupsForUser", "iam:ListAttachedUserPolicies", "iam:ListUserPolicies", "iam:GetUser" ], "Resource": ["arn:aws:iam::*:user/${aws:username}"] }, { "Sid": "NavigateInConsole", "Effect": "Allow", "Action": [ "iam:GetGroupPolicy", "iam:GetPolicyVersion", "iam:GetPolicy", "iam:ListAttachedGroupPolicies", "iam:ListGroupPolicies", "iam:ListPolicyVersions", "iam:ListPolicies", "iam:ListUsers" ], "Resource": "*" } ] } ``` # AWS 的 受管政策 AWS Lambda AWS 受管政策是由 AWS AWS 受管政策建立和管理的獨立政策旨在為許多常用案例提供許可，以便您可以開始將許可指派給使用者、群組和角色。 請記住， AWS 受管政策可能不會授予特定使用案例的最低權限許可，因為這些許可可供所有 AWS 客戶使用。我們建議您定義特定於使用案例的[客戶管理政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies)，以便進一步減少許可。 您無法變更 AWS 受管政策中定義的許可。如果 AWS 更新受 AWS 管政策中定義的許可，則更新會影響政策連接的所有委託人身分 （使用者、群組和角色）。 AWS 服務 當新的 啟動或新的 API 操作可用於現有服務時， AWS 最有可能更新 AWS 受管政策。 如需詳細資訊，請參閱 *IAM 使用者指南*中的 [AWS 受管政策](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies)。 **Topics** + [AWS 受管政策：AWSLambda\$1FullAccess](#lambda-security-iam-awsmanpol-AWSLambda_FullAccess) + [AWS 受管政策：AWSLambda\$1ReadOnlyAccess](#lambda-security-iam-awsmanpol-AWSLambda_ReadOnlyAccess) + [AWS 受管政策：AWSLambdaBasicExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaBasicExecutionRole) + [AWS 受管政策：AWSLambdaBasicDurableExecutionRolePolicy](#lambda-security-iam-awsmanpol-AWSLambdaBasicDurableExecutionRolePolicy) + [AWS 受管政策：AWSLambdaDynamoDBExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaDynamoDBExecutionRole) + [AWS 受管政策：AWSLambdaENIManagementAccess](#lambda-security-iam-awsmanpol-AWSLambdaENIManagementAccess) + [AWS 受管政策：AWSLambdaInvocation-DynamoDB](#lambda-security-iam-awsmanpol-AWSLambdaInvocation-DynamoDB) + [AWS 受管政策：AWSLambdaKinesisExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaKinesisExecutionRole) + [AWS 受管政策：AWSLambdaMSKExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaMSKExecutionRole) + [AWS 受管政策：AWSLambdaRole](#lambda-security-iam-awsmanpol-AWSLambdaRole) + [AWS 受管政策：AWSLambdaSQSQueueExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaSQSQueueExecutionRole) + [AWS 受管政策：AWSLambdaVPCAccessExecutionRole](#lambda-security-iam-awsmanpol-AWSLambdaVPCAccessExecutionRole) + [AWS 受管政策：AWSLambdaManagedEC2ResourceOperator](#lambda-security-iam-awsmanpol-AWSLambdaManagedEC2ResourceOperator) + [AWS 受管政策：AWSLambdaServiceRolePolicy](#lambda-security-iam-awsmanpol-AWSLambdaServiceRolePolicy) + [AWS 受管政策的 Lambda 更新](#lambda-security-iam-awsmanpol-updates) ## AWS 受管政策：AWSLambda\$1FullAccess 此政策也會授予完整存取權給 Lambda 動作。它還將許可授予用於開發和維護 Lambda 資源的其他 AWS 服務。 您可以將 `AWSLambda_FullAccess` 政策連接至使用者、群組與角色。 **許可詳細資訊** 此政策包含以下許可： + `lambda`：允許委託人完整存取 Lambda。 + `cloudformation` – 允許主體描述 AWS CloudFormation 堆疊並列出這些堆疊中的資源。 + `cloudwatch`：允許委託人列出 Amazon CloudWatch 指標並取得指標資料。 + `ec2`：允許委託人描述安全群組、子網路和 VPC。 + `iam`：允許委託人取得政策、政策版本、角色、角色政策、連接角色政策以及角色清單。此政策也允許委託人將角色傳遞給 Lambda。將執行角色指派給函數時，便會使用 `PassRole` 許可。建立服務連結角色時，會使用 `CreateServiceLinkedRole`許可。 + `kms` – 允許主體列出別名並描述磁碟區加密的金鑰。 + `logs`：允許主體描述日誌串流、取得日誌事件、篩選日誌事件，以及開始和停止 Live Tail 工作階段。 + `states` – 允許主體描述和列出 AWS Step Functions 狀態機器。 + `tag`：允許委託人根據其標籤取得資源。 + `xray` – 允許主體取得 AWS X-Ray 追蹤摘要，並擷取 ID 指定的追蹤清單。 如需有關此政策的詳細資訊 (包括 JSON 政策文件和政策版本)，請參閱《*AWS 受管政策參考指南*》中的 [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)。 ## AWS 受管政策：AWSLambda\$1ReadOnlyAccess 此政策授予對 Lambda 資源和用於開發和維護 Lambda 資源之其他服務 AWS 的唯讀存取權。 您可以將 `AWSLambda_ReadOnlyAccess` 政策連接至使用者、群組與角色。 **許可詳細資訊** 此政策包含以下許可： + `lambda`：允許委託人取得和列出所有資源。 + `cloudformation` – 允許主體描述和列出 AWS CloudFormation 堆疊，並列出這些堆疊中的資源。 + `cloudwatch`：允許委託人列出 Amazon CloudWatch 指標並取得指標資料。 + `ec2`：允許委託人描述安全群組、子網路和 VPC。 + `iam`：允許委託人取得政策、政策版本、角色、角色政策、連接角色政策以及角色清單。 + `kms`：允許委託人列出別名。 + `logs`：允許主體描述日誌串流、取得日誌事件、篩選日誌事件，以及開始和停止 Live Tail 工作階段。 + `states` – 允許主體描述和列出 AWS Step Functions 狀態機器。 + `tag`：允許委託人根據其標籤取得資源。 + `xray` – 允許主體取得 AWS X-Ray 追蹤摘要，並擷取 ID 指定的追蹤清單。 如需有關此政策的詳細資訊 (包括 JSON 政策文件和政策版本)，請參閱《*AWS 受管政策參考指南*》中的 [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)。 ## AWS 受管政策：AWSLambdaBasicExecutionRole 此政策授予將日誌上傳至 CloudWatch Logs 的許可。 您可以將 `AWSLambdaBasicExecutionRole` 政策連接至使用者、群組與角色。 如需有關此政策的詳細資訊 (包括 JSON 政策文件和政策版本)，請參閱《*AWS 受管政策參考指南*》中的 [AWSLambdaBasicExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicExecutionRole.html)。 ## AWS 受管政策：AWSLambdaBasicDurableExecutionRolePolicy 此政策提供 CloudWatch Logs 的寫入許可，以及 Lambda 耐用函數使用的耐久執行 APIs讀取/寫入許可。此政策提供 Lambda 耐用函數所需的基本許可，其使用耐用APIs 來保留進度，並維持函數叫用之間的狀態。 您可以將 `AWSLambdaBasicDurableExecutionRolePolicy` 政策連接至使用者、群組與角色。 **許可詳細資訊** 此政策包含以下許可： + `logs` – 允許主體建立日誌群組和日誌串流，並將日誌事件寫入 CloudWatch Logs。 + `lambda` – 允許主體檢查持久性執行狀態，並擷取 Lambda 持久性函數的持久性執行狀態。 若要檢視政策的詳細資訊，包括最新版本的 JSON 政策文件，請參閱《 *AWS 受管政策參考指南*》中的 [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html)。 ## AWS 受管政策：AWSLambdaDynamoDBExecutionRole 此政策授予從 Amazon DynamoDB 串流讀取記錄和寫入 CloudWatch Logs 的許可。 您可以將 `AWSLambdaDynamoDBExecutionRole` 政策連接至使用者、群組與角色。 如需有關此政策的詳細資訊 (包括 JSON 政策文件和政策版本)，請參閱《*AWS 受管政策參考指南*》中的 [AWSLambdaDynamoDBExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaDynamoDBExecutionRole.html)。 ## AWS 受管政策：AWSLambdaENIManagementAccess 此政策授予建立、描述和刪除已啟用 VPC 之 Lambda 函數所使用之彈性網路界面的許可。 您可以將 `AWSLambdaENIManagementAccess` 政策連接至使用者、群組與角色。 如需有關此政策的詳細資訊 (包括 JSON 政策文件和政策版本)，請參閱《*AWS 受管政策參考指南*》中的 [AWSLambdaENIManagementAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaENIManagementAccess.html)。 ## AWS 受管政策：AWSLambdaInvocation-DynamoDB 此政策授予 Amazon DynamoDB Streams 的讀取存取權。 您可以將 `AWSLambdaInvocation-DynamoDB` 政策連接至使用者、群組與角色。 如需有關此政策的詳細資訊 (包括 JSON 政策文件和政策版本)，請參閱《*AWS 受管政策參考指南*》中的 [AWSLambdaInvocation-DynamoDB](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaInvocation-DynamoDB.html)。 ## AWS 受管政策：AWSLambdaKinesisExecutionRole 此政策授予從 Amazon Kinesis 資料串流讀取事件和寫入 CloudWatch Logs 的許可。 您可以將 `AWSLambdaKinesisExecutionRole` 政策連接至使用者、群組與角色。 如需有關此政策的詳細資訊 (包括 JSON 政策文件和政策版本)，請參閱《*AWS 受管政策參考指南*》中的 [AWSLambdaKinesisExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaKinesisExecutionRole.html)。 ## AWS 受管政策：AWSLambdaMSKExecutionRole 此政策授予從 Amazon Managed Streaming for Apache Kafka 叢集中讀取和存取記錄、管理彈性網絡界面，以及寫入 CloudWatch Logs 的許可。 您可以將 `AWSLambdaMSKExecutionRole` 政策連接至使用者、群組與角色。 如需有關此政策的詳細資訊 (包括 JSON 政策文件和政策版本)，請參閱《*AWS 受管政策參考指南*》中的 [AWSLambdaMSKExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaMSKExecutionRole.html)。 ## AWS 受管政策：AWSLambdaRole 此政策授予調用 Lambda 函數的許可。 您可以將 `AWSLambdaRole` 政策連接至使用者、群組與角色。 如需有關此政策的詳細資訊 (包括 JSON 政策文件和政策版本)，請參閱《*AWS 受管政策參考指南*》中的 [AWSLambdaRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaRole.html)。 ## AWS 受管政策：AWSLambdaSQSQueueExecutionRole 此政策授予從 Amazon Simple Queue Service 佇列中讀取和刪除訊息以及寫入 CloudWatch Logs 的許可。 您可以將 `AWSLambdaSQSQueueExecutionRole` 政策連接至使用者、群組與角色。 如需有關此政策的詳細資訊 (包括 JSON 政策文件和政策版本)，請參閱《*AWS 受管政策參考指南*》中的 [AWSLambdaSQSQueueExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaSQSQueueExecutionRole.html)。 ## AWS 受管政策：AWSLambdaVPCAccessExecutionRole 此政策授予在 Amazon Virtual Private Cloud 中管理彈性網路界面和寫入 CloudWatch Logs 的許可。 您可以將 `AWSLambdaVPCAccessExecutionRole` 政策連接至使用者、群組與角色。 如需有關此政策的詳細資訊 (包括 JSON 政策文件和政策版本)，請參閱《*AWS 受管政策參考指南*》中的 [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)。 ## AWS 受管政策：AWSLambdaManagedEC2ResourceOperator 此政策可為 Lambda 容量提供者啟用自動化 Amazon Elastic Compute Cloud 執行個體管理。它將許可授予 Lambda 擴展器服務，以代表您執行執行個體生命週期操作。 您可以將 `AWSLambdaManagedEC2ResourceOperator` 政策連接至使用者、群組與角色。 **許可詳細資訊** 此政策包含以下許可： + `ec2:RunInstances` – 允許 Lambda 以 ec2：ManagedResourceOperator 等於 scaler.lambda.amazonaws.com 的條件啟動新的 Amazon EC2 執行個體，並將 AMI 用量限制為僅限 Amazon 擁有的映像。 + `ec2:DescribeInstances` 和 `ec2:DescribeInstanceStatus` – 允許 Lambda 監控執行個體狀態並擷取執行個體資訊。 + `ec2:CreateTags` – 允許 Lambda 標記 Amazon EC2 資源以進行管理和識別。 + `ec2:DescribeAvailabilityZones` – 允許 Lambda 檢視執行個體置放決策的可用區域。 + `ec2:DescribeCapacityReservations` – 允許 Lambda 檢查容量保留，以獲得最佳執行個體放置。 + `ec2:DescribeInstanceTypes` 和 `ec2:DescribeInstanceTypeOfferings` – 允許 Lambda 檢閱可用的執行個體類型及其方案。 + `ec2:DescribeSubnets` – 允許 Lambda 檢查子網路組態以進行網路規劃。 + `ec2:DescribeSecurityGroups` – 允許 Lambda 擷取網路介面組態的安全群組資訊。 + `ec2:CreateNetworkInterface` – 允許 Lambda 建立網路介面和管理子網路和安全群組關聯。 + `ec2:AttachNetworkInterface` – 允許 Lambda 將網路介面連接到條件`ec2:ManagedResourceOperator`等於 [scaler.lambda.amazonaws.com](http://scaler.lambda.amazonaws.com/) 的 Amazon EC2 執行個體。 如需此政策的詳細資訊，包括 JSON 政策文件和政策版本，請參閱《 *AWS 受管政策參考指南*》中的 [AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html)。 ## AWS 受管政策：AWSLambdaServiceRolePolicy 此政策會連接到名為 AWSServiceRoleForLambda 的服務連結角色，以允許 Lambda 終止作為 Lambda 容量提供者一部分管理的執行個體。 **許可詳細資訊** 此政策包含以下許可： + `ec2:TerminateInstances` – 允許 Lambda 終止條件為 ec2：ManagedResourceOperator 等於 scaler.lambda.amazonaws.com 的 EC2 執行個體。 + `ec2:DescribeInstanceStatus` 和 `ec2:DescribeInstances` – 允許 Lambda 描述 EC2 執行個體。 如需此政策的詳細資訊，請參閱[使用 Lambda 的服務連結角色](using-service-linked-roles.md)。 ## AWS 受管政策的 Lambda 更新 | 變更 | 描述 | Date | | --- | --- | --- | | [AWSLambdaManagedEC2ResourceOperator](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaManagedEC2ResourceOperator.html) – 新政策 | Lambda 新增了新的受管政策，為 Lambda 容量提供者啟用自動化 Amazon EC2 執行個體管理，允許擴展器服務執行執行個體生命週期操作。 | 2025 年 11 月 30 日 | | [AWSLambdaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaServiceRolePolicy.html) – 新政策 | Lambda 新增了服務連結角色的新受管政策，以允許 Lambda 終止做為 Lambda 容量提供者一部分管理的執行個體。 | 2025 年 11 月 30 日 | | [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html) – 變更 | Lambda 已更新`AWSLambda_FullAccess`政策，以允許 `kms:DescribeKey`和 `iam:CreateServiceLinkedRole`動作。 | 2025 年 11 月 30 日 | | [AWSLambdaBasicDurableExecutionRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaBasicDurableExecutionRolePolicy.html) – 新受管政策 | Lambda 發佈了新的受管政策`AWSLambdaBasicDurableExecutionRolePolicy`，為 CloudWatch Logs 提供寫入許可，並為 Lambda 耐用函數使用的持久執行 APIs提供讀取/寫入許可。 | 2025 年 12 月 1 日 | | [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html) 和 [AWSLambda\$1FullAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_FullAccess.html)：變更 | Lambda 更新了 `AWSLambda_ReadOnlyAccess` 和 `AWSLambda_FullAccess` 政策，允許 `logs:StartLiveTail` 和 `logs:StopLiveTail` 動作。 | 2025 年 3 月 17 日 | | [AWSLambdaVPCAccessExecutionRole](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambdaVPCAccessExecutionRole.html)：變更 | Lambda 更新了 `AWSLambdaVPCAccessExecutionRole` 政策以允許動作 `ec2:DescribeSubnets`。 | 2024 年 1 月 5 日 | | [AWSLambda\$1ReadOnlyAccess](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AWSLambda_ReadOnlyAccess.html)：變更 | Lambda 已更新`AWSLambda_ReadOnlyAccess`政策，允許主體列出 CloudFormation 堆疊。 | 2023 年 7 月 27 日 | | AWS Lambda 開始追蹤變更 | AWS Lambda 已開始追蹤其 AWS 受管政策的變更。 | 2023 年 7 月 27 日 | # 對 AWS Lambda 身分和存取進行故障診斷 請使用以下資訊來協助您診斷和修正使用 Lambda 和 IAM 時可能遇到的常見問題。 **Topics** + [我未獲授權，不得在 Lambda 中執行動作](#security_iam_troubleshoot-no-permissions) + [我未獲得執行 iam:PassRole 的授權](#security_iam_troubleshoot-passrole) + [我想要允許 以外的人員 AWS 帳戶 存取我的 Lambda 資源](#security_iam_troubleshoot-cross-account-access) ## 我未獲授權，不得在 Lambda 中執行動作 如果您收到錯誤，告知您未獲授權執行動作，您的政策必須更新，允許您執行動作。 下列範例錯誤會在`mateojackson` IAM 使用者嘗試使用主控台檢視一個虛構 `my-example-widget` 資源的詳細資訊，但卻無虛構 `lambda:GetWidget` 許可時發生。 ``` User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: lambda:GetWidget on resource: my-example-widget ``` 在此情況下，必須更新 `mateojackson` 使用者的政策，允許使用 `lambda:GetWidget` 動作存取 `my-example-widget` 資源。 如果您需要協助，請聯絡您的 AWS 管理員。您的管理員提供您的簽署憑證。 ## 我未獲得執行 iam:PassRole 的授權 如果您收到錯誤，告知您無權執行 `iam:PassRole` 動作，則必須更新您的政策，以允許您將角色傳遞至 Lambda。 有些 AWS 服務 可讓您將現有角色傳遞給該服務，而不是建立新的服務角色或服務連結角色。如需執行此作業，您必須擁有將角色傳遞至該服務的許可。 當名為 `marymajor` 的 IAM 使用者嘗試使用主控台在 Lambda 中執行動作時，發生下列範例錯誤。但是，動作請求服務具備服務角色授予的許可。Mary 沒有將角色傳遞給服務的許可。 ``` User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole ``` 在這種情況下，Mary 的政策必須更新，允許她執行 `iam:PassRole` 動作。 如果您需要協助，請聯絡您的 AWS 管理員。您的管理員提供您的簽署憑證。 ## 我想要允許 以外的人員 AWS 帳戶 存取我的 Lambda 資源 您可以建立一個角色，讓其他帳戶中的使用者或您組織外部的人員存取您的資源。您可以指定要允許哪些信任物件取得該角色。針對支援基於資源的政策或存取控制清單 (ACL) 的服務，您可以使用那些政策來授予人員存取您的資源的許可。 如需進一步了解，請參閱以下內容： + 若要了解 Lambda 是否支援這些功能，請參閱 [AWS Lambda 如何使用 IAM](security_iam_service-with-iam.md)。 + 若要了解如何 AWS 帳戶 在您擁有的 資源之間提供存取權，請參閱《[IAM 使用者指南》中的在您擁有 AWS 帳戶 的另一個 IAM 使用者中提供存取權](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)。 ** + 若要了解如何將資源的存取權提供給第三方 AWS 帳戶，請參閱《*IAM 使用者指南*》中的[將存取權提供給第三方 AWS 帳戶 擁有](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html)。 + 如需了解如何透過聯合身分提供存取權，請參閱《*IAM 使用者指南*》中的[將存取權提供給在外部進行身分驗證的使用者 (聯合身分)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html)。 + 如需了解使用角色和資源型政策進行跨帳戶存取之間的差異，請參閱《IAM 使用者指南》**中的 [IAM 中的跨帳戶資源存取](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html)。 # 建立 Lambda 函數和層的控管策略 若要建置和部署無伺服器、雲端原生應用程式，您必須透過適當的控管和防護機制來確保敏捷性和加速上市。您要設定商業級別優先順序，可以強調敏捷性做為首要任務，或者透過控管、防護機制和控制項來強調風險規避。實際上，您不能採用「非此即彼」的策略，而要選擇能在軟體開發週期中平衡敏捷性和防護機制的「兼顧」策略。無論這些要求位於公司生命週期的哪個階段，控管功能都有可能成為您的流程和工具鏈當中的一項實作要求。 以下是一些組織可能為 Lambda 實作的控管控制項範例： + Lambda 函數不可公開存取。 + Lambda 函數必須附加到 VPC。 + Lambda 函數不應使用已棄用的執行期。 + Lambda 函數必須有一組必要標籤進行標記。 + Lambda 層不可在組織外部存取。 + 附加安全群組的 Lambda 函數必須在函數和安全群組之間有配對的標籤。 + 具有附加層的 Lambda 函數必須使用核准的版本 + Lambda 環境變數必須使用客戶自管金鑰進行靜態加密。 下圖是深入控管策略的範例，此類策略會在軟體開發和部署過程當中實作控制項和政策： ![\[Governance strategy that uses AWS CloudFormation Guard, AWS Config, and Amazon Inspector.\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-concepts.png) 下列主題說明如何針對新創公司和企業在組織中實作開發和部署 Lambda 函數的控制項。您的組織可能有現成的工具。下列主題採用模組化方法來實作這些控制項，可讓您挑選實際需要的元件。 **Topics** + [使用 AWS CloudFormation Guard 的 Lambda 主動式控制項](governance-cloudformation-guard.md) + [使用 實作 Lambda 的預防性控制 AWS Config](governance-config.md) + [使用 偵測不合規的 Lambda 部署和組態 AWS Config](governance-config-detection.md) + [使用 AWS Signer 的 Lambda 程式碼簽署](governance-code-signing.md) + [使用 Amazon Inspector 自動化 Lambda 的安全評估](governance-code-scanning.md) + [實作 Lambda 安全性與合規性的可觀測性](governance-observability.md) # 使用 AWS CloudFormation Guard 的 Lambda 主動式控制項 [AWS CloudFormation Guard](https://docs.aws.amazon.com/cfn-guard/latest/ug/what-is-guard.html) 是一種開放原始碼的通用型政策即程式碼評估工具。透過比照政策規則驗證基礎設施即程式碼 (IaC) 範本和服務組合，它可被用於實現預防性控管與合規。這些規則還可以依據您的團隊或組織要求進行自訂。對於 Lambda 函數，Guard 規則可透過在建立或更新 Lambda 函數時定義所需的必要屬性設定，控制資源建立和組態更新。 合規管理員會定義部署和更新 Lambda 函數所需的控制項和控管政策清單。平台管理員在 CI/CD 管道中實作控制項，做為程式碼儲存庫的預遞交驗證 Webhook，並為開發人員提供用於在本機工作站驗證範本和程式碼的命令列工具。開發人員使用命令列工具編寫程式碼並驗證範本，然後將程式碼遞交到儲存庫。儲存庫隨後會在將這些程式碼部署到 AWS 環境前透過 CI/CD 管道自動對其進行驗證。 Guard 讓您可以使用特定領域的語言，如下[編寫您的規則](https://docs.aws.amazon.com/cfn-guard/latest/ug/writing-rules.html)並實作您的控制項。 ![\[Guard rules include resource type, property name, operator, expression value, and optional comment\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-cloudformation-guard.png) 例如，假設您希望確定開發人員僅選擇最新的執行期。您可以指定兩種不同的政策，一種用來識別已棄用的[執行期](lambda-runtimes.md)，另一種則用來確定即將棄用的執行期。為此，您可能要編寫以下 `etc/rules.guard` 檔案： ``` let lambda_functions = Resources.*[ Type == "AWS::Lambda::Function" ] rule lambda_already_deprecated_runtime when %lambda_functions !empty { %lambda_functions { Properties { when Runtime exists { Runtime !in ["dotnetcore3.1", "nodejs12.x", "python3.6", "python2.7", "dotnet5.0", "dotnetcore2.1", "ruby2.5", "nodejs10.x", "nodejs8.10", "nodejs4.3", "nodejs6.10", "dotnetcore1.0", "dotnetcore2.0", "nodejs4.3-edge", "nodejs"] <> } } } } rule lambda_soon_to_be_deprecated_runtime when %lambda_functions !empty { %lambda_functions { Properties { when Runtime exists { Runtime !in ["nodejs16.x", "nodejs14.x", "python3.7", "java8", "dotnet7", "go1.x", "ruby2.7", "provided"] <> } } } } ``` 現在，假設您要編寫定義 Lambda 函數的以下 `iac/lambda.yaml` CloudFormation 範本： ``` Fn: Type: AWS::Lambda::Function Properties: Runtime: python3.7 CodeUri: src Handler: fn.handler Role: !GetAtt FnRole.Arn Layers: - arn:aws:lambda:us-east-1:111122223333:layer:LambdaInsightsExtension:35 ``` 在[安裝](https://docs.aws.amazon.com/cfn-guard/latest/ug/setting-up.html) Guard 公用程式後，驗證您的範本： ``` cfn-guard validate --rules etc/rules.guard --data iac/lambda.yaml ``` 輸出如下： ``` lambda.yaml Status = FAIL FAILED rules rules.guard/lambda_soon_to_be_deprecated_runtime --- Evaluating data lambda.yaml against rules rules.guard Number of non-compliant resources 1 Resource = Fn { Type = AWS::Lambda::Function Rule = lambda_soon_to_be_deprecated_runtime { ALL { Check = Runtime not IN ["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"] { ComparisonError { Message = Lambda function is using a runtime that is targeted for deprecation. Error = Check was not compliant as property [/Resources/Fn/Properties/Runtime[L:88,C:15]] was not present in [(resolved, Path=[L:0,C:0] Value=["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"])] } PropertyPath = /Resources/Fn/Properties/Runtime[L:88,C:15] Operator = NOT IN Value = "python3.7" ComparedWith = [["nodejs16.x","nodejs14.x","python3.7","java8","dotnet7","go1.x","ruby2.7","provided"]] Code: 86. Fn: 87. Type: AWS::Lambda::Function 88. Properties: 89. Runtime: python3.7 90. CodeUri: src 91. Handler: fn.handler } } } } ``` Guard 可讓您的開發人員透過本機開發工作站即可了解，他們需要更新範本以便使用組織允許的執行期。這發生在遞交至程式碼儲存庫之前，隨後會使 CI/CD 管道中的檢查失敗。因此，您的開發人員將取得此回饋，以便了解如何開發合乎規範的範本，並且將他們的時間轉移到編寫可創造商業價值的程式碼。此控制可套用到本機的開發人員工作站，在預遞交驗證 Webhook 和/或在部署前的 CI/CD 管道中套用。 ## 警告 如果您使用 AWS Serverless Application Model (AWS SAM) 範本定義 Lambda 函數，注意您需要如下更新 Guard 規則以便搜尋 `AWS::Serverless::Function` 資源類型。 ``` let lambda_functions = Resources.*[ Type == "AWS::Serverless::Function" ] ``` Guard 還預期屬性會包含在資源定義當中。同時，AWS SAM 範本允許在單獨的[全域](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/sam-specification-template-anatomy-globals.html)區段指定屬性。「全域」區段裡定義的屬性不使用您的 Guard 規則進行驗證。 如 Guard 故障診斷[文件](https://docs.aws.amazon.com/cfn-guard/latest/ug/troubleshooting.html)中所述，應注意 Guard 不支援簡寫形式的內部函數 (例如 `!GetAtt` 或 `!Sub`)，而要求使用展開形式：`Fn::GetAtt` 和 `Fn::Sub`。([先前的範例](#guard-iac-yaml)不會評估 Role 屬性，因此為了簡便起見而使用簡寫形式的內部函數。) # 使用 實作 Lambda 的預防性控制 AWS Config 儘早在開發過程中確保無伺服器應用程式的合規性至關重要。在本主題中，我們將說明如何使用 [AWS Config](https://docs.aws.amazon.com/config/latest/developerguide/WhatIsConfig.html) 實作預防性控制項。這可讓您在開發過程的早期實作合規檢查，並且使您可以在 CI/CD 管道中實作相同的控制項。這也會標準化 規則集中受管儲存庫中的控制項，讓您可以在 AWS 帳戶中一致地套用控制項。 例如，假設您的合規管理員定義了一項要求，以確保所有 Lambda 函數都包含 AWS X-Ray 追蹤。使用 AWS Config的主動模式，您可以在部署之前對 Lambda 函數資源執行合規檢查，藉由提供更快速的基礎設施意見回饋作為程式碼範本，降低部署設定不當的 Lambda 函數並節省開發人員時間的風險。以下是使用 進行預防性控制的流程視覺化 AWS Config： ![\[CloudFormation requests must pass AWS Config rules before provisioning.\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-config-1.png) 考慮所有 Lambda 函數都必須啟用追蹤功能的要求。為了回應，平台團隊會識別在所有帳戶中主動執行特定 AWS Config 規則的需求。此規則會將任何未設定 X-Ray 追蹤組態的 Lambda 函數標記為不合規資源。團隊開發規則，將其封裝在[一致性套件](https://docs.aws.amazon.com/config/latest/developerguide/conformance-packs.html)中，並將一致性套件部署到所有 AWS 帳戶，以確保組織中的所有帳戶統一套用這些控制項。您可以採用 AWS CloudFormation Guard 2.x.x 語法編寫該規則，它將採用以下形式： ``` rule name when condition { assertion } ``` 以下是檢查以確保 Lambda 函數已啟用追蹤功能的範例 Guard 規則： ``` rule lambda_tracing_check { when configuration.tracingConfig exists { configuration.tracingConfig.mode == "Active" } } ``` 平台團隊透過強制每個 AWS CloudFormation 部署叫用預先建立/更新[掛](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/hooks-structure.html)鉤，採取進一步的動作。他們會全權負責開發此勾點和設定管道、強化合規規則的集中控制，並確保在所有部署中一致地套用這些規則。若要開發、封裝和註冊掛鉤，請參閱 CloudFormation 命令列界面 (CFN-CLI) 文件中的[開發 AWS CloudFormation 掛鉤](https://docs.aws.amazon.com/cloudformation-cli/latest/hooks-userguide/hooks-develop.html)。您可以使用 [CloudFormation CLI](https://docs.aws.amazon.com/cloudformation-cli/latest/userguide/initiating-hooks-project-python.html) 來建立勾點專案： ``` cfn init ``` 此命令會要求您提供有關勾點專案的一些基本資訊，並在其中建立包含下列檔案的專案： ``` README.md .json rpdk.log src/handler.py template.yml hook-role.yaml ``` 做為勾點開發人員，您需要在 `.json` 組態檔案中新增所需的目標資源類型。在下列組態中，勾點被設為在使用 CloudFormation 建立任何 Lambda 函數之前執行。您也可以為 `preUpdate` 和 `preDelete` 動作新增類似的處理常式。 ``` "handlers": { "preCreate": { "targetNames": [ "AWS::Lambda::Function" ], "permissions": [] } } ``` 您也需要確保 CloudFormation 勾點具有呼叫 AWS Config APIs的適當許可。您可以透過更新名為 `hook-role.yaml` 的角色定義檔案來執行該動作。角色定義檔案預設具有下列信任政策，以允許 CloudFormation 擔任相關角色。 ``` AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - hooks.cloudformation.amazonaws.com - resources.cloudformation.amazonaws.com ``` 若要允許此勾點呼叫組態 API，您必須將下列許可新增至政策陳述式。然後，您可以使用 `cfn submit` 命令提交勾點專案，CloudFormation 會在其中為您建立具有所需許可的角色。 ``` Policies: - PolicyName: HookTypePolicy PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - "config:Describe*" - "config:Get*" - "config:List*" - "config:SelectResourceConfig" Resource: "* ``` 接下來，您需要在 `src/handler.py` 檔案中編寫 Lambda 函數。在此檔案中，您將在啟動該專案時發現已建立的名為 `preCreate`、`preUpdate` 和 `preDelete` 的方法。您旨在撰寫一個常用、可重複使用的函數，使用 在 AWS Config 主動模式下呼叫 `StartResourceEvaluation` API 適用於 Python (Boto3) 的 AWS SDK。此 API 呼叫會將資源屬性做為輸入，並且比照規則定義評估資源。 ``` def validate_lambda_tracing_config(resource_type, function_properties: MutableMapping[str, Any]) -> ProgressEvent: LOG.info("Fetching proactive data") config_client = boto3.client('config') resource_specs = { 'ResourceId': 'MyFunction', 'ResourceType': resource_type, 'ResourceConfiguration': json.dumps(function_properties), 'ResourceConfigurationSchemaType': 'CFN_RESOURCE_SCHEMA' } LOG.info("Resource Specifications:", resource_specs) eval_response = config_client.start_resource_evaluation(EvaluationMode='PROACTIVE', ResourceDetails=resource_specs, EvaluationTimeout=60) ResourceEvaluationId = eval_response.ResourceEvaluationId compliance_response = config_client.get_compliance_details_by_resource(ResourceEvaluationId=ResourceEvaluationId) LOG.info("Compliance Verification:", compliance_response.EvaluationResults[0].ComplianceType) if "NON_COMPLIANT" == compliance_response.EvaluationResults[0].ComplianceType: return ProgressEvent(status=OperationStatus.FAILED, message="Lambda function found with no tracing enabled : FAILED", errorCode=HandlerErrorCode.NonCompliant) else: return ProgressEvent(status=OperationStatus.SUCCESS, message="Lambda function found with tracing enabled : PASS.") ``` 現在，您可以從處理常式為預先建立的勾點呼叫常用的函數。以下是處理常式的範例： ``` @hook.handler(HookInvocationPoint.CREATE_PRE_PROVISION) def pre_create_handler( session: Optional[SessionProxy], request: HookHandlerRequest, callback_context: MutableMapping[str, Any], type_configuration: TypeConfigurationModel ) -> ProgressEvent: LOG.info("Starting execution of the hook") target_name = request.hookContext.targetName LOG.info("Target Name:", target_name) if "AWS::Lambda::Function" == target_name: return validate_lambda_tracing_config(target_name, request.hookContext.targetModel.get("resourceProperties") ) else: raise exceptions.InvalidRequest(f"Unknown target type: {target_name}") ``` 在此步驟之後，您可以註冊勾點並將其設定為接聽所有 AWS Lambda 函數建立事件。 開發人員會使用 Lambda 為無伺服器微服務準備基礎設施即程式碼 (IaC) 範本。此準備工作包括遵守內部標準，然後進行本機測試並將範本遞交至儲存庫。以下是範例 IaC 範本： ``` MyLambdaFunction: Type: 'AWS::Lambda::Function' Properties: Handler: index.handler Role: !GetAtt LambdaExecutionRole.Arn FunctionName: MyLambdaFunction Code: ZipFile: | import json def handler(event, context): return { 'statusCode': 200, 'body': json.dumps('Hello World!') } Runtime: python3.14 TracingConfig: Mode: PassThrough MemorySize: 256 Timeout: 10 ``` 做為 CI/CD 程序的一部分，當部署 CloudFormation 範本時，CloudFormation 服務會在佈建 `AWS::Lambda::Function` 資源類型前直接調用預先建立/更新勾點。勾點利用以主動模式執行的 AWS Config 規則來驗證 Lambda 函數組態是否包含必要的追蹤組態。來自勾點的回應將決定下一個步驟。如果合規，勾點將發出成功訊號，CloudFormation 會繼續佈建資源。若不合規，CloudFormation 堆疊部署將會失敗，管道立即停止，而系統會記錄詳細資訊以供後續審核。合規通知將傳送至相關的利害關係人。 您可以在 CloudFormation 主控台中找到勾點成功/失敗的資訊： ![\[Hook success/fail information in the CloudFormation console\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-config-2.png) 如果已經為 CloudFormation 勾點啟用日誌，您可以擷取勾點評估結果。以下是狀態為失敗的勾點範例日誌，表示 Lambda 函數未啟用 X-Ray： ![\[Sample log for a hook with a failed status\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-config-3.png) 如果開發人員選擇將 IaC 變更為將 `TracingConfig Mode` 值更新為 `Active` 並重新部署，勾點將成功執行且堆疊將繼續建立 Lambda 資源。 ![\[CloudFormation console shows successful resource deployment\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-config-4.png) 透過這種方式，您可以在 AWS 帳戶中開發和部署無伺服器資源時， AWS Config 以主動模式使用 實作預防性控制。透過將 AWS Config 規則整合到 CI/CD 管道，您可以識別並有針對性地封鎖不合規的資源部署，例如缺少主動追蹤組態的 Lambda 函數。這可確保只有符合最新控管政策的資源才會部署到您的 AWS 環境中。 # 使用 偵測不合規的 Lambda 部署和組態 AWS Config 除了[主動評估](governance-config.md)之外， AWS Config 也可以被動偵測不符合控管政策的資源部署和組態。這一點很重要，因為控管政策會隨著您的組織學習和實作新的最佳實務而演進。 請考慮在部署或更新 Lambda 函數時設定全新政策的情形：所有 Lambda 函數都必須始終使用特定且經過核准的 Lambda 層版本。您可以將 AWS Config 設為監控新的或更新函數的層組態。如果 AWS Config 偵測到未使用已核准 layer 版本的函數，則會將該函數標記為不合規資源。您可以選擇使用 AWS Systems Manager 自動化文件指定修復動作， AWS Config 以設定 自動修復資源。例如，您可以使用 在 Python 中撰寫自動化文件 適用於 Python (Boto3) 的 AWS SDK，這會更新不合規函數以指向核准的 layer 版本。因此， 同時 AWS Config 做為偵測和修正控制，自動化合規管理。 我們將此過程分解為三個重要的實作階段： ![\[The three implementation phases are identify, notify, and deploy remediation.\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-config-detective-1.png) ## 階段 1：確定存取資源 首先在您的帳戶 AWS Config 中啟用 ，並將其設定為記錄 AWS Lambda 函數。這可讓 AWS Config 觀察何時建立或更新 Lambda 函數。然後，您可以設定[自訂政策規則](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config_develop-rules_cfn-guard.html)，以檢查使用 AWS CloudFormation Guard 語法的特定策略違規情況。Guard 規則採用下列一般形式： ``` rule name when condition { assertion } ``` 以下是一條範例規則，用於檢查確保層未被設為舊的層版本： ``` rule desiredlayer when configuration.layers !empty { some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn } ``` 我們來了解一下規則語法和結構： + **規則名稱：**在提供的範例中，規則的名稱為 `desiredlayer`。 + **條件：**此子句指定應該檢查規則的條件。在提供的範例中，條件為 `configuration.layers !empty`。這意味著只有當組態中的 `layers` 屬性不為空時，才應評估資源。 + **聲明：**在 `when` 子句後，聲明將決定檢查什麼規則。聲明 `some configuration.layers[*].arn != CONFIG_RULE_PARAMETERS.OldLayerArn` 會檢查任何 Lambda 層 ARN 是否與 `OldLayerArn` 值不相符。如果不相符，聲明為 true 且規則通過；否則，它將會失敗。 `CONFIG_RULE_PARAMETERS` 是一組使用 AWS Config 規則設定的特殊參數。在這種情況下，`OldLayerArn` 是 `CONFIG_RULE_PARAMETERS` 內的一項參數。它允許使用者提供其認為舊的或已棄用的特定 ARN 值，然後，規則會檢查任何 Lambda 函數是否使用這個舊的 ARN 值。 ## 階段 2：視覺化與設計 AWS Config 會收集組態資料，並將該資料存放在 Amazon Simple Storage Service (Amazon S3) 儲存貯體中。您可以使用 [Amazon Athena](https://aws.amazon.com/athena/) 直接從 S3 儲存貯體查詢這些資料。藉助 Athena，您可以在組織層級彙整此類資料，為所有帳戶產生資源組態的整體全貌。若要設定資源組態資料的彙總，請參閱 AWS 雲端操作和管理部落格上的[使用 Athena 和 Amazon Quick 視覺化 AWS Config 資料](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/)。 以下是使用特定層 ARN 識別所有 Lambda 函數的範例 Athena 查詢： ``` WITH unnested AS ( SELECT item.awsaccountid AS account_id, item.awsregion AS region, item.configuration AS lambda_configuration, item.resourceid AS resourceid, item.resourcename AS resourcename, item.configuration AS configuration, json_parse(item.configuration) AS lambda_json FROM default.aws_config_configuration_snapshot, UNNEST(configurationitems) as t(item) WHERE "dt" = 'latest' AND item.resourcetype = 'AWS::Lambda::Function' ) SELECT DISTINCT region as Region, resourcename as FunctionName, json_extract_scalar(lambda_json, '$.memorySize') AS memory_size, json_extract_scalar(lambda_json, '$.timeout') AS timeout, json_extract_scalar(lambda_json, '$.version') AS version FROM unnested WHERE lambda_configuration LIKE '%arn:aws:lambda:us-east-1:111122223333:layer:AnyGovernanceLayer:24%' ``` 以下是查詢的結果： ![\[Query results in Athena console.\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-config-detective-2.png) 透過彙總整個組織 AWS Config 的資料，您可以使用 [Amazon Quick](https://aws.amazon.com/quicksight/) 建立儀表板。透過將 Athena 結果匯入 Quick，您可以將 Lambda 函數遵循 layer 版本規則的程度視覺化。此儀表板可以突出顯示合規和不合規的資源，依[下一個區段](#governance-config-detective-implement)中所述協助您確定強制政策。下圖是一個範例儀表板，它會報告在組織內部套用至函數的層版本的分佈情況。 ![\[Example Quick dashboard shows distribution of layer versions in Lambda functions.\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-config-detective-3.png) ## 階段 3：實作與強制執行 您現在可以選擇性地將您在[階段 1](#governance-config-detective-identify) 中建立的層版本規則與透過 Systems Manager 自動化文件執行的修補動作配對，該自動化文件是您使用 適用於 Python (Boto3) 的 AWS SDK編寫的 Python 指令碼。此指令碼會為每個 Lambda 函數呼叫 [UpdateFunctionConfiguration](https://docs.aws.amazon.com/lambda/latest/api/API_UpdateFunctionConfiguration.html) API 動作，使用新的層 ARN 更新函數組態。或者，您可以讓指令碼提交提取請求至程式碼儲存庫，以更新層 ARN。這樣，未來的程式碼部署也會使用正確的層 ARN 進行更新。 # 使用 AWS Signer 的 Lambda 程式碼簽署 [AWS Signer](https://docs.aws.amazon.com/signer/latest/developerguide/Welcome.html) 是一項全受管程式碼簽署服務，可讓您對照數位簽章驗證您的程式碼，以確認該程式碼未經變更且來自受信任的發布者。AWS Signer 可與 AWS Lambda 搭配使用，以便驗證函數和層在部署到您的 AWS 環境前未經變更。這可以保護您的組織免受惡意行為者侵害，這些行為者可能已取得憑證以建立新的或更新現有的函數。 若要為 Lambda 函數設定程式碼簽署，請先建立啟用版本控制的 S3 儲存貯體。之後，使用 AWS Signer 建立簽署設定檔，將 Lambda 指定為平台，然後指定簽署設定檔的有效天數。範例： ``` Signer: Type: AWS::Signer::SigningProfile Properties: PlatformId: AWSLambda-SHA384-ECDSA SignatureValidityPeriod: Type: DAYS Value: !Ref pValidDays ``` 接下來使用簽署設定檔和 Lambda 來建立簽署組態。當簽署組態遇到與預期的數位簽章不相符的成品時，您必須指定要執行何種操作：警告 (但允許部署) 或強制執行 (並封鎖部署)。以下範例設為強制執行並封鎖部署。 ``` SigningConfig: Type: AWS::Lambda::CodeSigningConfig Properties: AllowedPublishers: SigningProfileVersionArns: - !GetAtt Signer.ProfileVersionArn CodeSigningPolicies: UntrustedArtifactOnDeployment: Enforce ``` 您現有的 AWS Signer 設定為由 Lambda 封鎖不受信任的部署。假設您已經完成功能請求的編碼，現在已準備好部署函數。第一個步驟是壓縮程式碼及適當相依性，然後使用您建立的簽署設定檔簽署成品。為此，您可以上傳壓縮成品到 S3 儲存貯體，然後開始簽署任務。 ``` aws signer start-signing-job \ --source 's3={bucketName=your-versioned-bucket,key=your-prefix/your-zip-artifact.zip,version=QyaJ3c4qa50LXV.9VaZgXHlsGbvCXxpT}' \ --destination 's3={bucketName=your-versioned-bucket,prefix=your-prefix/}' \ --profile-name your-signer-id ``` 您將取得如下輸出，其中 `jobId` 是在目的地儲存貯體和字首中建立的物件，`jobOwner` 是執行該任務的 12 位數 AWS 帳戶 ID。 ``` { "jobId": "87a3522b-5c0b-4d7d-b4e0-4255a8e05388", "jobOwner": "111122223333" } ``` 現在，您可以使用已簽署的 S3 物件和您建立的程式碼簽署組態來部署您的函數。 ``` Fn: Type: AWS::Serverless::Function Properties: CodeUri: s3://your-versioned-bucket/your-prefix/87a3522b-5c0b-4d7d-b4e0-4255a8e05388.zip Handler: fn.handler Role: !GetAtt FnRole.Arn CodeSigningConfigArn: !Ref pSigningConfigArn ``` 或者，您還可以使用原始未簽署的來源壓縮成品測試函數部署。部署會失敗並顯示以下訊息： ``` Lambda cannot deploy the function. The function or layer might be signed using a signature that the client is not configured to accept. Check the provided signature for unsigned. ``` 若您使用 AWS Serverless Application Model (AWS SAM) 建置與部署您的函數，套件命令將處理壓縮成品上傳到 S3，還會開始簽署任務並取得已簽署成品。您可以使用以下命令和參數來執行此動作： ``` sam package -t your-template.yaml \ --output-template-file your-output.yaml \ --s3-bucket your-versioned-bucket \ --s3-prefix your-prefix \ --signing-profiles your-signer-id ``` AWS Signer 會協助您確認部署到帳戶中的壓縮成品是否受信任用於部署。您可以在 CI/CD 管道中包含上述程序，並要求所有函數都使用先前主題中所述的技術附加程式碼簽署組態。透過搭配 Lambda 函數部署使用程式碼簽署，您可以防止可能已取得憑證的惡意行為者建立或更新函數，將惡意程式碼注入函數中。 # 使用 Amazon Inspector 自動化 Lambda 的安全評估 [Amazon Inspector](https://aws.amazon.com/inspector/) 是一項漏洞管理服務，可持續掃描工作負載，以尋找已知的軟體漏洞和意外的網路暴露。Amazon Inspector 會建立調查結果以描述漏洞、識別受影響的資源、評定漏洞嚴重性並提供修補指引。 Amazon Inspector 支援為 Lambda 函數和層提供持續的自動化安全性漏洞評估。Amazon Inspector 為 Lambda 提供兩種掃描類型： + **Lambda 標準掃描 (預設)：**掃描 Lambda 函數及其層內的應用程式相依性，以尋找[套件漏洞](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-package)。 + **Lambda 程式碼掃描**：掃描函數和層內的自訂應用程式程式碼，以尋找[程式碼漏洞](https://docs.aws.amazon.com/inspector/latest/user/findings-types.html#findings-types-code)。您可以啟動 Lambda 標準掃描，或同時啟動 Lambda 標準掃描和 Lambda 程式碼掃描。 若要啟用 Amazon Inspector，請導覽至 [Amazon Inspector 主控台](https://console.aws.amazon.com/inspector/)，展開**設定**區段，然後選擇**帳戶管理**。在**帳戶**索引標籤上，選擇**啟動**，然後選取其中一個掃描選項。 您可以為多個帳戶啟用 Amazon Inspector，並在設定 Amazon Inspector 時為特定帳戶的組織委派管理 Amazon Inspector 的許可。啟用時，您需要透過建立以下角色來授予 Amazon Inspector 許可：`AWSServiceRoleForAmazonInspector2`。Amazon Inspector 主控台允許您使用一鍵式選項建立此角色。 對於 Lambda 標準掃描，Amazon Inspector 會在下列情況下啟動 Lambda 函數的漏洞掃描。 + 一旦 Amazon Inspector 發現現有 Lambda 函數。 + 當您部署新的 Lambda 函數時。 + 當您對現有的 Lambda 函數或其層的應用程式程式碼或相依性部署更新時。 + 每當 Amazon Inspector 新增一個常見漏洞和暴露 (CVE) 項目到其資料庫，而該 CVE 與您的函數相關時。 對於 Lambda 程式碼掃描，Amazon Inspector 會使用自動推理和機器學習來評估您的 Lambda 函數應用程式程式碼，以分析您的應用程式程式碼是否符合整體安全規範。若 Amazon Inspector 在您的 Lambda 函數應用程式程式碼中偵測到漏洞，Amazon Inspector 會產生一份詳細的**程式碼漏洞**調查結果。如需檢視可能偵測項目的清單，請參閱 [Amazon CodeGuru Detector 程式庫](https://docs.aws.amazon.com/codeguru/detector-library/)。 若要檢視調查結果，請前往 [Amazon Inspector 主控台](https://console.aws.amazon.com/inspector/)。在**調查結果**選單上，選擇**依 Lambda 函數**以顯示對 Lambda 函數執行的安全性掃描結果。 若要從標準掃描中排除 Lambda 函數，請使用以下鍵值對標記函數： + `Key:InspectorExclusion` + `Value:LambdaStandardScanning` 若要從程式碼掃描中排除 Lambda 函數，請使用以下鍵值對標記函數： + `Key:InspectorCodeExclusion` + `Value:``LambdaCodeScanning` 例如，如下圖所示，Amazon Inspector 會自動偵測漏洞並將發現的漏洞分類為**程式碼漏洞**類型，這表示這些漏洞存在於函數的程式碼中，而不是在其中一個程式碼相依程式庫中。您可以一次檢查一個特定函數或多個函數的這些詳細資訊。 ![\[Amazon Inspector finds vulnerabilities in Lambda code.\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-code-scanning-1.png) 您可以深入研究每項結果，並了解如何修補問題。 ![\[Amazon Inspector console displays code vulnerability details.\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-code-scanning-2.png) 在使用您的 Lambda 函數時，確認您遵守 Lambda 函數的命名慣例。如需更多詳細資訊，請參閱 [使用 Lambda 環境變數](configuration-envvars.md)。 您要負責執行自己接受的修補建議。在接受前，請務必檢閱修補建議。您可能需要編輯修補建議，以確保您的程式碼符合您的預期。 # 實作 Lambda 安全性與合規性的可觀測性 AWS Config 是尋找和修正不合規 AWS Serverless 資源的實用工具。您對無伺服器資源所做的每個變更都會記錄在其中 AWS Config。此外， AWS Config 可讓您在 S3 上存放組態快照資料。您可以使用 Amazon Athena 和 Amazon Quick 建立儀表板並查看 AWS Config 資料。在 [使用 偵測不合規的 Lambda 部署和組態 AWS Config](governance-config-detection.md) 中，我們討論了如何視覺化 Lambda 層等特定組態。本主題將展開介紹這些概念。 ## Lambda 組態的可見性 您可以使用查詢來提取重要的組態，例如 AWS 帳戶 ID、區域、 AWS X-Ray 追蹤組態、VPC 組態、記憶體大小、執行時間和標籤。以下是您可以用來從 Athena 提取這些資訊的範例查詢： ``` WITH unnested AS ( SELECT item.awsaccountid AS account_id, item.awsregion AS region, item.configuration AS lambda_configuration, item.resourceid AS resourceid, item.resourcename AS resourcename, item.configuration AS configuration, json_parse(item.configuration) AS lambda_json FROM default.aws_config_configuration_snapshot, UNNEST(configurationitems) as t(item) WHERE "dt" = 'latest' AND item.resourcetype = 'AWS::Lambda::Function' ) SELECT DISTINCT account_id, tags, region as Region, resourcename as FunctionName, json_extract_scalar(lambda_json, '$.memorySize') AS memory_size, json_extract_scalar(lambda_json, '$.timeout') AS timeout, json_extract_scalar(lambda_json, '$.runtime') AS version json_extract_scalar(lambda_json, '$.vpcConfig.SubnetIds') AS vpcConfig json_extract_scalar(lambda_json, '$.tracingConfig.mode') AS tracingConfig FROM unnested ``` 您可以使用查詢來建置快速儀表板並視覺化資料。若要彙總 AWS 資源組態資料、在 Athena 中建立資料表，並在 Athena 的資料上建置快速儀表板，請參閱 AWS 雲端操作和管理部落格中的[使用 Athena 和 Amazon Quick 視覺化 AWS Config 資料](https://aws.amazon.com/blogs/mt/visualizing-aws-config-data-using-amazon-athena-and-amazon-quicksight/)。注意，此查詢還會擷取函數的標籤資訊。這可讓您更深入地了解工作負載和環境，尤其當您使用自訂標籤時。 ![\[Query results in Quick dashboard\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-observability-1.png) 如需有關可採取之動作的詳細資訊，請參閱本主題稍後的 [處理可觀測性調查結果](#governance-observability-addressing) 區段。 ## Lambda 合規可見性 使用 產生的資料 AWS Config，您可以建立組織層級儀表板來監控合規性。這允許您一致地追蹤與監控： + 依合規分數劃分的合規性套件 + 依不合規資源劃分的規則 + 合規狀態 ![\[AWS Config console dashboard\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-observability-2.png) 檢查每條規則，以便為該規則識別不合規的資源。例如，如果您的組織要求所有 Lambda 函數都必須與 VPC 建立關聯，而且您已部署 AWS Config 規則來識別合規，您可以在上面的清單中選取`lambda-inside-vpc`規則。 ![\[View non-compliant resources in AWS Config console\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-observability-3.png) 如需有關可採取之動作的詳細資訊，請參閱下方的 [處理可觀測性調查結果](#governance-observability-addressing) 區段。 ## 使用 Security Hub CSPM 對 Lambda 函數邊界的可見性 ![\[Diagram of example AWS Security Hub CSPM inputs for Lambda, such as resource policy, runtime, and code\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-observability-4.png) 為了確保安全使用包括 Lambda 在內的 AWS 服務， AWS 推出了基礎安全最佳實務 1.0.0 版。這組最佳實務提供明確的準則，以保護 AWS 環境中的資源和資料，強調維護強式安全狀態的重要性。透過提供統一的安全和合規中心來 AWS Security Hub CSPM 補充這一點。它會彙總、組織 Amazon Inspector 和 Amazon GuardDuty 等多項 AWS 服務的安全性調查結果 AWS Identity and Access Management Access Analyzer，並排定其優先順序。 如果您在 AWS 組織中啟用 Security Hub CSPM、Amazon Inspector、IAM Access Analyzer 和 GuardDuty，Security Hub CSPM 會自動彙總這些服務的問題清單。例如，我們來考慮一下 Amazon Inspector。使用 Security Hub CSPM，您可以有效地識別 Lambda 函數中的程式碼和套件漏洞。在 Security Hub CSPM 主控台中，導覽至標記**來自 AWS 整合的最新調查結果的**底部區段。在這裡，您可以檢視和分析來自各種整合 AWS 服務的問題清單。 ![\[Security Hub CSPM console "Latest findings from AWS integrations" section\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-observability-5.png) 若要查看詳細資訊，請選擇第二欄中的**查看調查結果**連結。這會顯示依產品 (如 Amazon Inspector) 篩選的調查結果清單。若要將搜尋限定於 Lambda 函數，請將 `ResourceType` 設為 `AwsLambdaFunction`。這會顯示 Amazon Inspector 中與 Lambda 函數相關的調查結果。 ![\[Filter for Amazon Inspector results related to Lambda functions\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/governance-observability-6.png) 對於 GuardDuty，您可以識別可疑的網路流量模式。此類異常可能表明 Lambda 函數中存在潛在的惡意程式碼。 藉助 IAM Access Analyzer，您可以檢查政策，特別是那些包含條件陳述式的政策，這些陳述式會授予函數存取外部實體的權限。此外，當 IAM Access Analyzer 在 Lambda API 中使用 [AddPermission](https://docs.aws.amazon.com/lambda/latest/api/API_AddPermission.html) 操作並結合 `EventSourceToken` 時，還會對許可集合進行評估。 ## 處理可觀測性調查結果 考慮到 Lambda 函數可能的廣泛組態及其獨特要求，一種標準化的自動修補解決方案可能不適用於所有情況。此外，在各種環境中，變更的實作方式也存在差異。如果您遇到任何看似不合規的組態，請考慮下列指導方針： 1. **標記策略** 我們建議實作全面的標記策略。每個 Lambda 函數都應使用關鍵資訊進行標記，例如： + **擁有者：**對函數負責的人員或團隊。 + **環境：**生產、整備、開發或沙盒。 + **應用程式：**此函數所屬的更廣泛上下文 (如果適用)。 1. **擁有者外展** 有別於自動執行重大變更 (如 VPC 組態調整)，主動聯絡不合規函數的擁有者 (透過擁有者標籤識別) 可為其提供充足的時間，以便其： + 調整 Lambda 函數的不合規組態。 + 提供說明並請求例外狀況，或完善合規標準。 1. **維護組態管理資料庫 (CMDB)** 雖然標籤可以提供直接上下文，但維護集中式 CMDB 可以提供更深入的洞見。它可以保留有關每個 Lambda 函數的更精細資訊、它的相依性和其他關鍵中繼資料。CMDB 是稽核、合規性檢查和識別函數擁有者的重要資源。 隨著無伺服器基礎設施的不斷演進，採用主動的監控策略變得至關重要。透過 AWS Config Security Hub CSPM 和 Amazon Inspector 等工具，可以快速識別潛在的異常或不合規組態。然而，單純使用工具無法確保完全的合規性或最佳化組態。將這些工具與妥善記載的程序及最佳實務進行配對至關重要。 + **回饋迴圈：**一旦執行修補步驟，務必確保有回饋迴圈。這意味著定期重新檢視不合規的資源，以確定它們是否已更新或仍存在相同的問題。 + **記錄：**始終記錄可觀測性、所執行的動作以及任何授予的例外狀況。適當記錄不僅有助於稽核，還可協助強化該程序以便在未來提高合規性與安全性。 + **培訓和認知：**確保所有利害關係人，尤其是 Lambda 函數擁有者，定期接受培訓並了解最佳實務、組織政策以及合規性要求。定期舉辦研討會、網路研討會或提供培訓課程，可進一步確保每個人在安全性和合規性方面取得共識。 總之，儘管工具和技術提供了強大的偵測與標記潛在問題的功能，但人的因素 (理解、溝通、培訓和記錄) 仍然是關鍵。它們共同構成一個強效的組合，可確保您的 Lambda 函數和更廣泛的基礎設施保持合規、安全並針對您的商業需求提供最佳化。 # 的合規驗證AWS Lambda 在多個 AWS Lambda 合規計劃中，第三方稽核人員會評估 AWS 的安全與合規。這些計劃包括 SOC、PCI、FedRAMP、HIPAA 等等。 如需特定合規計劃範圍內的 AWS 服務清單，請參閱[合規計劃內的 AWS 服務](https://aws.amazon.com/compliance/services-in-scope/)。如需一般資訊，請參閱 [AWS 合規計劃](https://aws.amazon.com/compliance/programs/)。 您可使用 AWS Artifact 下載第三方稽核報告。如需詳細資訊，請參閱[在 AWS Artifact 中下載報告](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html)。 您使用 Lambda 的合規責任，取決於資料的機密性、您公司的合規目標及適用法律和法規。您可以實作控管控制項，以確保公司的 Lambda 函數符合您的合規需求。如需更多詳細資訊，請參閱 [建立 Lambda 函數和層的控管策略](governance-concepts.md)。 # AWS Lambda 中的恢復能力 AWS 全球基礎設施是以 AWS 區域與可用區域為中心建置的。AWS區域提供多個分開且隔離的實際可用區域，它們以低延遲、高輸送量和高度備援聯網功能相互連結。透過可用區域，您所設計與操作的應用程式和資料庫，就能夠在可用區域之間自動容錯移轉，而不會發生中斷。可用區域的可用性、容錯能力和擴充能力，均較單一或多個資料中心的傳統基礎設施還高。 如需 AWS 區域與可用區域的詳細資訊，請參閱 [AWS 全球基礎設施](https://aws.amazon.com/about-aws/global-infrastructure/)。 除了 AWS 全球基礎設施，Lambda 還提供數種功能，可協助支援資料的彈性和備份需求。 + **版本控制** - 您可以在 Lambda 中使用版本控制，在開發時儲存您函數的程式碼和組態。搭配別名，您可以使用版本控制來執行藍綠和輪流部署。如需詳細資訊，請參閱 [管理 Lambda 函數版本](configuration-versions.md)。 + **擴展** - 當您的函數在處理先前請求的同時收到請求，Lambda 會啟動函數的另一個執行個體來處理增加的負載。Lambda 會自動擴展以處理每個區域 1,000 個並行執行，如果需要，可以增加[配額](gettingstarted-limits.md)。如需詳細資訊，請參閱 [了解 Lambda 函數擴展](lambda-concurrency.md)。 + **高可用性** - Lambda 會在多個可用區域中執行您的函數，確保單一區域的服務中斷時，其可用於處理事件。如果您將函式設定為連接到您帳戶中的虛擬私有雲端 (VPC)，請在多個可用區域中指定子網路，以確保高可用性。如需詳細資訊，請參閱 [讓 Lambda 函數存取 Amazon VPC 中的資源](configuration-vpc.md)。 + **預留並行** - 若要確保您的函數可隨時擴展以處理額外的請求，您可以為其預留並行。為函式設定預留並行，確保其可擴展為 (但不超過) 指定的並行叫用數目。這可確保您不會因為取用所有可用並行的其他函式而遺失請求。如需詳細資訊，請參閱 [設定函數的預留並行](configuration-concurrency.md)。 + **重試** - 對於非同步叫用以及其他服務所觸發的叫用子集，Lambda 會在發生錯誤時重試，且重試之間有延遲。同步調用函數的其他用戶端和 AWS 服務負責執行重試。如需詳細資訊，請參閱 [了解 Lambda 中的重試行為](invocation-retries.md)。 + **無效字母佇列** - 對於非同步叫用，您可以設定 Lambda，以便在所有重試都失敗時，將請求傳送到無效字母佇列。無效字母佇列是可接收事件以便排除故障或重新處理的 Amazon SNS 主題或 Amazon SQS 佇列。如需詳細資訊，請參閱 [新增無效字母佇列](invocation-async-retain-records.md#invocation-dlq)。 # 中的基礎設施安全AWS Lambda 做為一種受管服務，AWS Lambda 受 AWS 全域網路安全的保護。如需 AWS 安全服務以及 AWS 如何保護基礎設施的相關資訊，請參閱 [AWS 雲端安全](https://aws.amazon.com/security/)。若要使用基礎設施安全性的最佳實務以設計您的 AWS 環境，請參閱*安全性支柱 AWS 架構良好的框架*中的[基礎設施保護](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/infrastructure-protection.html)。 您可使用 AWS 發佈的 API 呼叫，透過網路來存取 Lambda。使用者端必須支援下列專案： + Transport Layer Security (TLS)。我們需要 TLS 1.2 並建議使用 TLS 1.3。 + 具備完美轉送私密(PFS)的密碼套件，例如 DHE (Ephemeral Diffie-Hellman)或 ECDHE (Elliptic Curve Ephemeral Diffie-Hellman)。現代系統(如 Java 7 和更新版本)大多會支援這些模式。 # 使用公有端點保護工作負載 對於可公開存取的工作負載，AWS 提供了許多有助於降低特定風險的功能和服務。本節涵蓋應用程式使用者的身分驗證和授權，以及保護 API 端點。 ## 身分驗證和授權 身分驗證與身分相關，授權涉及動作。使用身分驗證來控制誰可以調用 Lambda 函數，然後使用授權來控制調用者可以執行的動作。對於許多應用程式，IAM 足以管理這兩個控制機制。 對於具有外部使用者的應用程式 (例如 Web 或行動應用程式)，通常使用 [JSON Web 權杖](https://jwt.io/introduction/) (JWT) 來管理身分驗證和授權。與傳統的伺服器型密碼管理不同，JWT 在每次請求時都會從用戶端傳遞。它們是一種加密的安全方式，可使用從用戶端傳遞的資料來驗證身分和宣告。對於 Lambda 型應用程式，這可讓您保護對每個 API 端點的每次呼叫，而無需依賴中央伺服器進行身分驗證。 您可以[使用 Amazon Cognito 實作 JWT](https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-with-identity-providers.html)。Amazon Cognito 是一種使用者目錄服務，可以處理註冊、身分驗證、帳戶復原及其他常見帳戶管理操作。[Amplify Framework](https://docs.amplify.aws/start/getting-started/auth/q/integration/react) 提供了一些程式庫，可簡化將此服務整合到前端應用程式的程序。您也可以考慮使用第三方合作夥伴服務，例如 [Auth0](https://auth0.com/)。 鑑於身分提供者服務的關鍵安全角色，請務必使用專業工具來保護您的應用程式。不建議您自己編寫服務，來處理身分驗證或授權。自訂程式庫中的任何漏洞都可能對您的工作負載及其資料的安全性產生重大影響。 ## 保護 API 端點 對於無伺服器應用程式，公開為後端應用程式提供服務的偏好方式是使用 Amazon API Gateway。這可協助您保護 API 免受惡意使用者或流量激增的侵害。 API Gateway 為無伺服器開發人員提供兩種端點類型：[REST API](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-rest-api.html) 和 [HTTP API](https://docs.aws.amazon.com/apigateway/latest/developerguide/http-api.html)。兩者都支援[使用 AWS Lambda、IAM 或 Amazon Cognito 進行授權](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-use-lambda-authorizer.html)。使用 IAM 或 Amazon Cognito 時，會評估傳入請求，如果這些請求缺少所需的權杖或包含無效的身分驗證，則請求會遭到拒絕。您無需為這些請求付費，並且這些請求不計入任何限流配額。 公有網際網路上的任何人皆可存取未驗證的 API 路由，因此建議您限制使用未驗證的 API。如果必須使用未進行身分驗證的 API，請務必保護這些 API 免受常見風險，例如[拒絕服務](https://en.wikipedia.org/wiki/Denial-of-service_attack) (DoS) 攻擊。[將 AWS WAF 套用](https://docs.aws.amazon.com/apigateway/latest/developerguide/apigateway-control-access-aws-waf.html) 至這些 API，有助於保護應用程式免受 SQL injection 隱碼攻擊和跨網站指令碼 (XSS) 攻擊。使用 API 金鑰時，API Gateway 還會在 AWS 帳戶層級和每個用戶端層級實作[限流](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-request-throttling.html)。 在許多情況下，未驗證的 API 提供的功能可以透過替代方式來實現。例如，Web 應用程式可以向未登入的使用者提供來自 DynamoDB 資料表的客戶零售店清單。此請求可能源自前端 Web 應用程式或任何其他呼叫 URL 端點的來源。此圖表比較了以下三種解決方案： ![\[安全營運圖 5\]](http://docs.aws.amazon.com/zh_tw/lambda/latest/dg/images/security-ops-figure-5.png) 1. 網際網路上的任何人都可以呼叫此未驗證的 API。在拒絕服務攻擊中，可能會耗盡基礎資料表上的 API 限流限制、Lambda 並行或 DynamoDB 佈建讀取容量。 1. 在 API 端點前面使用適當的[存留時間](https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html) (TTL) 組態的 CloudFront 分佈將承受 DoS 攻擊中的大部分流量，而無需變更用於擷取資料的底層解決方案。 1. 或者，對於很少變更的靜態資料，CloudFront 分佈可以提供來自 Amazon S3 儲存貯體的資料。 # 使用程式碼簽署來驗證 Lambda 的程式碼完整性 程式碼簽署可協助確保僅受信任的程式碼部署到您的 Lambda 函式中。您可以使用 AWS Signer為您的函數建立數位簽章程式碼套件。當您[將程式碼簽署組態新增至函式](configuration-codesigning-create.md)時，Lambda 會驗證所有新的程式碼部署是否皆由信任的來源簽署。由於程式碼簽署驗證檢查會在部署時執行，因此不會影響函式執行。 **重要** 程式碼簽署組態只能防止新部署未簽署的程式碼。如果將程式碼簽署組態新增至具有未簽署程式碼的現有函式，該程式碼會持續執行，直到您部署新的程式碼套件為止。 當您為函式啟用程式碼簽署時，新增至函式的所有[層](chapter-layers.md)也必須由一個允許的簽署設定檔來簽署。 使用 AWS Signer 或 程式碼簽署無需額外費用 AWS Lambda。 ## 簽署驗證 在您將已簽署的程式碼套件部署至函數時，Lambda 會執行下列驗證檢查： 1. **完整性**：驗證程式碼套件自簽署後未被修改。Lambda 將套件的雜湊與簽章中的雜湊作比較。 1. **有效期**：驗證程式碼套件的簽章尚未到期。 1. **一致性**：驗證程式碼套件是透過允許的簽署設定檔進行簽署 1. **撤銷撤銷**：驗證程式碼套件的簽章未被撤銷。 建立程式碼簽署組態時，您可以使用 [UntrustedArtifactOnDeployment](https://docs.aws.amazon.com/lambda/latest/api/API_CodeSigningPolicies.html#lambda-Type-CodeSigningPolicies-UntrustedArtifactOnDeployment) 參數，指定 Lambda 如何因應有效期、一致性或撤銷狀態檢查失敗。您可以選擇下列動作之一： + `Warn`：此動作是預設設定。Lambda 允許部署程式碼套件，但會發出警告。Lambda 會發出新的 Amazon CloudWatch 指標 (`SignatureValidationErrors`)，還會將警告儲存在 CloudTrail 日誌中。 + `Enforce`：Lambda 會發出警告 (與 `Warn` 動作相同) 並阻止程式碼套件的部署。 **Topics** + [簽署驗證](#config-codesigning-valid) + [建立 Lambda 的程式碼簽署組態](configuration-codesigning-create.md) + [針對 Lambda 程式碼簽署組態設定 IAM 政策](config-codesigning-policies.md) + [在程式碼簽署組態上使用標籤](tags-csc.md) # 建立 Lambda 的程式碼簽署組態 若要啟用函數的程式碼簽署，您可以建立*程式碼簽署組態*並將其附加至函數。程式碼簽署組態會定義允許簽署描述檔的清單，以及在任何驗證檢查失敗時要採取的政策動作。 **注意** 定義為容器映像的函數不支援程式碼簽署。 **Topics** + [組態先決條件](#config-codesigning-prereqs) + [建立程式碼簽署組態](#config-codesigning-config-console) + [啟用函數的程式碼簽署](#config-codesigning-function-console) ## 組態先決條件 在您可以設定 Lambda 函數的程式碼簽署之前，請使用 AWS Signer 執行下列動作： + 建立一或多個[簽署設定檔](https://docs.aws.amazon.com/signer/latest/developerguide/signing-profiles.html)。 + 使用簽署設定檔[為函式建立簽署的程式碼套件](https://docs.aws.amazon.com/signer/latest/developerguide/lambda-workflow.html)。 ## 建立程式碼簽署組態 程式碼簽署組態會定義允許的簽署描述檔和簽署驗證政策。 **建立程式碼簽署組態 (主控台)** 1. 開啟 Lambda 主控台中的 [Code signing configurations](https://console.aws.amazon.com/lambda/home#/code-signing-configurations) (程式碼簽署組態) 頁面。 1. 選擇**建立組態**。 1. 針對 **Description (描述)**，輸入組態的描述性名稱。 1. 在 **Signing profiles (簽署描述檔)** 下，可將多達 20 個簽署描述檔新增至組態。 1. 針對 **Signing profile version ARN (簽署描述檔版本 ARN)**，選擇描述檔版本的 Amazon Resource Name (ARN)，或輸入 ARN。 1. 若要新增額外的簽署描述檔，選擇 **Add signing profiles (新增簽署描述檔)**。 1. 在 **Signature validation policy (簽署驗證政策)** 下，選擇 **Warn (警告)** 或 **Enforce (強制)**。 1. 選擇**建立組態**。 ## 啟用函數的程式碼簽署 若要為函式啟用程式碼簽署，需將程式碼簽署組態與函式建立關聯。 **重要** 程式碼簽署組態只能防止新部署未簽署的程式碼。如果將程式碼簽署組態新增至具有未簽署程式碼的現有函式，該程式碼會持續執行，直到您部署新的程式碼套件為止。 **將程式碼簽署組態與函數 (主控台) 關聯** 1. 開啟 Lambda 主控台中的[函數頁面](https://console.aws.amazon.com/lambda/home#/functions)。 1. 選擇您要啟用程式碼簽署的函數。 1. 開啟 **Configuration** (組態) 索引標籤。 1. 向下捲動並選擇**程式碼簽署**。 1. 選擇**編輯**。 1. 在 **Edit code signing (編輯程式碼簽署)** 中，選擇此函數的程式碼簽署組態。 1. 選擇**儲存**。 # 針對 Lambda 程式碼簽署組態設定 IAM 政策 若要授予使用者存取 Lambda 程式碼簽署 API 操作的許可，請將一或多個政策陳述式附加至使用者政策。如需使用者政策的詳細資訊，請參閱[Lambda 適用的身分型 IAM 政策](access-control-identity-based.md)。 下列範例政策陳述式會授予建立、更新及擷取程式碼簽署組態的許可。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "lambda:CreateCodeSigningConfig", "lambda:UpdateCodeSigningConfig", "lambda:GetCodeSigningConfig" ], "Resource": "*" } ] } ``` ------ 管理員可以使用 `CodeSigningConfigArn` 條件金鑰，來指定開發人員必須用於建立或更新函數的程式碼簽署組態。 下列範例政策陳述式會授予建立函數的許可。政策聲明包括 `lambda:CodeSigningConfigArn` 條件以指定允許的程式碼簽署組態。如果 [CodeSigningConfigArn](https://docs.aws.amazon.com/lambda/latest/api/API_CreateFunction.html#lambda-CreateFunction-request-CodeSigningConfigArn) 參數遺失或不符合條件中的值，Lambda 會阻止 `CreateFunction` API 請求。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "AllowReferencingCodeSigningConfig", "Effect": "Allow", "Action": [ "lambda:CreateFunction" ], "Resource": "*", "Condition": { "StringEquals": { "lambda:CodeSigningConfigArn": "arn:aws:lambda:us-east-1:111122223333:code-signing-config:csc-0d4518bd353a0a7c6" } } } ] } ``` ------ # 在程式碼簽署組態上使用標籤 您可以標記程式碼簽署組態來整理和管理您的資源。標籤是與跨 AWS 服務支援的資源相關聯的自由格式索引鍵值對。如需標籤使用案例的詳細資訊，請參閱*《標記 AWS 資源和標籤編輯器指南*》中的[常見標記策略](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#tag-strategies)。 您可以使用 AWS Lambda API 來檢視和更新標籤。也可以在 Lambda 主控台中管理特定程式碼簽署時檢視和更新標籤。 **Topics** + [使用標籤所需的許可](#csc-tags-required-permissions) + [搭配使用標籤與 Lambda 主控台](#tags-csc-console) + [搭配 使用標籤 AWS CLI](#tags-csc-cli) ## 使用標籤所需的許可 若要允許 AWS Identity and Access Management (IAM) 身分 (使用者、群組或角色) 讀取或設定資源上的標籤，請為其授予相應許可： + **lambda:ListTags**：當資源具有標籤時，將此許可授予給需要對其呼叫 `ListTags` 的任何人員。對於已標記函數，`GetFunction` 也需要此許可。 + **lambda:TagResource**：將此許可授予給需要呼叫 `TagResource` 或在建立時執行標記的任何人員。 或者，也可以考慮授予 **lambda：UntagResource** 許可，以允許對資源進行 `UntagResource` 呼叫。 如需詳細資訊，請參閱[Lambda 適用的身分型 IAM 政策](access-control-identity-based.md)。 ## 搭配使用標籤與 Lambda 主控台 可以使用 Lambda 主控台建立具有標籤的程式碼簽署組態、將標籤新增至現有程式碼簽署組態，以及依標籤篩選程式碼簽署組態。 **若要在您建立程式碼簽署組態時新增標籤** 1. 開啟 Lambda 主控台中的[程式碼簽署組態](https://console.aws.amazon.com/lambda/home#/code-signing-configurations)。 1. 從內容窗格的標頭中，選擇**建立組態**。 1. 在內容窗格頂端的區段中，設定程式碼簽署組態。如需關於設定程式碼簽署組態的詳細資訊，請參閱[使用程式碼簽署來驗證 Lambda 的程式碼完整性](configuration-codesigning.md)。 1. 在 **標籤** 區域，選擇 **新增**。 1. 在**索引鍵**欄位中，輸入標籤索引鍵。如需有關標記限制的資訊，請參閱《* AWS *[標記資源和標籤編輯器指南》中的標記命名限制和要求](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices)。 1. 選擇**建立組態**。 **若要將標籤新增至現有程式碼簽署組態** 1. 開啟 Lambda 主控台中的[程式碼簽署組態](https://console.aws.amazon.com/lambda/home#/code-signing-configurations)。 1. 選擇程式碼簽署組態的名稱。 1. 在**詳細資訊**窗格下方的索引標籤中，選擇**標籤**。 1. 選擇**管理標籤**。 1. 選擇 **Add new tag** (新增標籤)。 1. 在**索引鍵**欄位中，輸入標籤索引鍵。如需有關標記限制的資訊，請參閱《* AWS *[標記資源和標籤編輯器指南》中的標記命名限制和要求](https://docs.aws.amazon.com//tag-editor/latest/userguide/best-practices-and-strats.html#id_tags_naming_best_practices)。 1. 選擇**儲存**。 **若要依標籤篩選程式碼簽署組態** 1. 開啟 Lambda 主控台中的[程式碼簽署組態](https://console.aws.amazon.com/lambda/home#/code-signing-configurations)。 1. 選取搜尋方塊。 1. 從下拉式清單中的**標籤**子標題下方，選取您的標籤。 1. 選取**使用：「tag-name」**以查看所有標記有此索引鍵的程式碼簽署組態，或選擇**運算子**以進一步依值篩選。 1. 選取標籤值，依標籤索引鍵和值的組合進行篩選。 搜尋方塊也支援搜尋標籤索引鍵。輸入索引鍵的名稱，以便在清單中尋找該索引鍵。 ## 搭配 使用標籤 AWS CLI 可以使用 Lambda API 在現有的 Lambda 資源 (包括程式碼簽署組態) 上新增和移除標籤。也可以在建立程式碼簽署組態時新增標籤，這可讓您在整個生命週期中標記資源。 ### 使用 Lambda 標籤 API 來更新標籤 可以透過 [TagResource](https://docs.aws.amazon.com/lambda/latest/api/API_TagResource.html) 和 [UntagResource](https://docs.aws.amazon.com/lambda/latest/api/API_UntagResource.html) API 操作來新增和移除受支援 Lambda 資源的標籤。 可使用 AWS CLI來呼叫這些操作。若要將標籤新增至現有資源，請使用 `tag-resource` 命令。此範例會新增兩個標籤，一個包含索引鍵 *Department*，另一個包含索引鍵 *CostCenter*。 ``` aws lambda tag-resource \ --resource arn:aws:lambda:us-east-2:123456789012:resource-type:my-resource \ --tags Department=Marketing,CostCenter=1234ABCD ``` 若要移除標籤，請使用 `untag-resource` 命令。此範例會移除具有索引鍵 *Department* 的標籤。 ``` aws lambda untag-resource --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier \ --tag-keys Department ``` ### 在建立程式碼簽署組態時新增標籤 若要建立帶有標籤的新 Lambda 程式碼簽署組態，請使用 [CreateCodeSigningConfig](https://docs.aws.amazon.com//lambda/latest/api/API_CreateCodeSigningConfig.html) API 操作。指定 `Tags` 參數。您可以使用 `create-code-signing-config` AWS CLI 命令和 `--tags`選項來呼叫此操作。如需關於 CLI 命令的詳細資訊，請參閱《AWS CLI 命令參考》**中的 [create-code-signing-config](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/lambda/create-code-signing-config.html)。 將 `Tags` 參數與 `CreateCodeSigningConfig` 搭配使用之前，請確保您的角色除了此操作所需的一般許可外，還擁有標記資源的許可。如需有關標記許可的詳細資訊，請參閱[使用標籤所需的許可](#csc-tags-required-permissions)。 ### 使用 Lambda 標籤 API 來檢視標籤 若要檢視套用至特定 Lambda 資源的標籤，請使用 `ListTags` API 操作。如需詳細資訊，請參閱 [ListTags](https://docs.aws.amazon.com/lambda/latest/api/API_ListTags.html)。 您可以使用 `list-tags` AWS CLI 命令呼叫此操作，方法是提供 ARN (Amazon Resource Name)。 ``` aws lambda list-tags --resource arn:aws:lambda:us-east-1:123456789012:resource-type:resource-identifier ``` ### 依標籤篩選資源 您可以使用 AWS Resource Groups Tagging API [GetResources](https://docs.aws.amazon.com/resourcegroupstagging/latest/APIReference/API_GetResources.html) API 操作，依標籤篩選資源。`GetResources` 操作可接收最多 10 個篩選條件，每個篩選條件皆包含標籤索引鍵與最多 10 個標籤值。為 `GetResources` 提供一個 `ResourceType`，即可依特定資源類型進行篩選。 您可以使用 `get-resources` AWS CLI 命令呼叫此操作。如需使用 `get-resources` 的範例，請參閱《AWS CLI 命令參考》中的 [get-resources](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/resourcegroupstaggingapi/get-resources.html#examples)。**