為 Amazon Bedrock 實施最小特權訪問

生成式人工智慧應用程式通常涉及多種服務和功能的結合，例如Amazon Bedrock和大型語言模型（LLMs），以生成內容並存取可能的機密資料。這種結合需要強大的身份和存取管理控制，並且特別之處在於這些控制需要應用於各個層面。在這篇部落格文章中，您將審視使用Amazon Bedrock應用程式時可以應用最小特權存取的情境和方法。要充分受益於本文中的指導，您需要了解AWS API、AWS身份和存取管理（IAM）政策以及AWS安全服務。

讓我們從定義最小特權原則（PoLP）開始：PoLP是一個安全概念，建議為使用者、程式或系統授予執行其任務所需的最低存取級別或權限。主要思想是，實體擁有的權限越少，惡意或意外損害的風險就越低。將PoLP應用於AWS的使用有兩個目的：

安全性：

通過限制存取，您可以減少安全事件的潛在影響。如果使用者或服務擁有最小權限，任何損害的範圍都可以顯著減少。

操作簡單性：

如果未正確管理和維護，管理權限可能會變得複雜。及早將PoLP應用於您的存取控制有助於保持配置的可管理性。最後，還有一些監管框架要求角色之間的職責分離和存取控制的文件化策略，這可以通過遵循PoLP來部分實現。

Amazon Bedrock是一項完全管理的AWS服務，通過單一統一的API提供高效能的基礎模型（FMs）。您可以通過AWS API使用Amazon Bedrock，這些API公開控制平面和管理的操作，例如Amazon Bedrock Guardrails和Amazon Bedrock Agents的配置，此外還有數據平面的功能操作，例如推理。

通常，使用Amazon Bedrock進行生產工作負載的路徑包括以下階段：

模型選擇：

決定所需的功能（檢索增強生成（RAG）、微調等），評估並選擇模型，並在必要時批准EULA。

模型適應：

提示工程、將Amazon Bedrock整合到應用程式中，以及如果需要的話添加模型自訂。

模型測試：

驗證並測試解決方案。

模型運行：

部署解決方案並使其可用。監控並運行解決方案。

在接下來的部分中，我們將逐步介紹每個階段，並概述如何應用PoLP。

模型選擇

在這個階段，您選擇滿足需求所需的功能和模型，並定義如何應用PoLP。這些可以包括例如模型自訂、檢索增強生成（RAG）或代理的使用。

安全性應該整合到設計中，以便在開發階段可以實施定義的控制措施。定義必要的安全控制的一種方法是威脅建模。早期進行這項練習將簡化即將到來的階段。結果可以用於決定所需的護欄、潛在的架構變更和測試案例。

在這個階段，您還將決定如何部署解決方案。客戶通常在多帳戶設置中運作；因此，需要選擇目標組織單位（OUs）和帳戶。我們建議為生成式人工智慧應用程式創建一個新的OU。有關詳細資訊，請參閱AWS安全參考架構中的生成式人工智慧深入章節。我們稍後將討論服務控制政策（SCPs）以及如何使用它們來限制權限。生成式人工智慧OU是強制執行這些護欄的好地方。

Amazon Bedrock提供了來自領先人工智慧公司的多種高效能FMs的存取，例如AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI和Amazon。在這個階段，您需要選擇將使用的模型並批准它們。對於第三方FM，批准可能包括接受EULA。您可以限制身份和他們可以訂閱的模型，以遵循已由您的法律部門審核的EULAs。以下是一個基於身份的政策示例，允許帳戶操作員啟用所有Anthropic FMs和單個Meta Llama FM。

這種方法在您僅允許列出操作時效果良好，但您可能擁有已經對AWS Marketplace API擁有廣泛存取的高權限使用者。在這種情況下，您可以遵循一種拒絕所有但允許少數的方式。這樣的政策，使用與之前相同的模型，將如下例所示：

您可以在授予IAM權限以請求存取Amazon Bedrock基礎模型中找到條件中使用的所需產品ID。

模型適應

在這個階段，解決方案被構建，即編寫代碼。這與傳統軟體開發大致相同，但在生成式人工智慧中有一些特定的領域，例如提示工程、提示護欄、模型監控和代理設計。在這篇文章中，我們僅專注於身份和存取管理方面。

適應是創建詳細權限集的階段。數據周界可以用作定義和實施護欄的概念工具。由於數據周界通常是粗粒度的，因此它們不足以實現PoLP的目標。然而，結合細粒度政策，它們支持深度防禦方法。以下是存在的數據周界：

身份：

只有受信任的身份才能進入我的網絡，只有受信任的身份才能存取我的資源。

資源：

我的身份只能存取受信任的資源，只有受信任的資源才能從我的網絡存取。

網絡：

我的身份只能從預期的網絡存取資源，我的資源只能從預期的網絡存取。

對於使用Amazon Bedrock的應用程式，您可以使用虛擬私有雲（VPC）網絡結構與Amazon Virtual Private Cloud（Amazon VPC）來託管它們。這樣做意味著您可以使用AWS PrivateLink創建數據和控制平面API的VPC端點。使用PrivateLink創建端點，可以為VPC綁定的計算資源（例如Amazon Elastic Compute Cloud（Amazon EC2）或AWS Lambda）提供存取Amazon Bedrock的功能，而無需網際網路閘道。換句話說，您可以將這些資源完全部署在私有子網中。通過在這些端點上使用基於資源的政策，您可以限制與API調用相關的主體、操作、資源和條件。

假設您有一個VPC，其中一個EC2實例運行在私有子網中，託管一個使用Amazon Bedrock模型調用的應用程式，並創建了一個介面VPC端點以連接到Amazon Bedrock數據平面。EC2實例配置為使用一個實例配置文件，使用<rolename> IAM角色，需要能夠通過Amazon Bedrock InvokeModel API調用單個Anthropic的Claude Instant FM。您可以將PoLP應用於包含的VPC，從而應用於EC2實例，並在Amazon Bedrock介面VPC端點上設置自訂政策。要在您自己的帳戶中使用以下政策，請用以下示例替換默認的介面VPC端點政策，將<rolename>替換為您想要允許的角色，將<account-id>替換為您的12位數帳號。

查看安全目標2：使用VPC端點政策實施數據周界以獲取有關此數據周界方法的更多資訊。

您可以直接在政策中定義可以在Amazon Bedrock中使用的允許模型。然而，如果您有多個使用Amazon Bedrock的應用程式，當允許使用新模型時，您可能需要更新多個政策。為了補充數據周界方法，您可以添加SCP以限制可以用於推理的模型。由於Amazon Bedrock使用簡單的API（InvokeModel和Converse）進行推理，IAM政策中的條件元素可以用來拒絕使用未經批准的模型。請注意，儘管這兩個政策（SCP和VPC端點政策）看起來相似，但它們的工作方式不同：VPC端點政策是在通過PrivateLink強制執行網絡路徑的情況下強制執行的；SCP適用於附加到的帳戶或OU中的主體。如果呼叫身份駐留在您的帳戶之外，請格外小心，因為只有VPC端點政策將適用。

例如，假設您想要在AWS Organizations中阻止在所有AWS區域內調用所有Anthropic FMs。以下應用於範圍內的OUs或AWS帳戶的SCP示例將實現該結果：

您可以使用相同的模式存取應用程式所需的數據，例如駐留在Amazon Simple Storage Service（Amazon S3）中的數據。

模型自訂

基於Amazon Bedrock構建的解決方案可能包括模型自訂。不同自訂方法的共同點是它們包括數據，這些數據被假定為機密，因此在PoLP的應用範圍內。在這裡，我們採用一個場景，其中數據存儲在Amazon S3中，可以使用客戶管理的AWS Key Management Service（AWS KMS）密鑰進行加密。

可以在多個層面上採取措施，如數據周界中所概念化的：網絡、身份和資源。Amazon Bedrock模型自訂使用服務角色，這使您可以從頭到尾應用細粒度和最小特權存取。這些服務角色將由Amazon Bedrock服務主體假定，以便它可以代表您執行操作。要允許Amazon Bedrock服務主體在您的帳戶中假定角色，您需要將信任政策附加到角色上。

假設您在us-east-1（N. Virginia）區域運行Amazon Bedrock自訂作業。使用以下信任政策示例將僅允許Amazon Bedrock服務主體假定您的角色。

確保在上述信任政策示例中將<account-id>替換為您自己的12位數帳號。該政策包含一個條件，通過添加aws:SourceAccount條件提供跨服務混淆代理防護。混淆代理問題是一種情況，其中沒有權限執行操作的實體可以強迫更高權限的實體執行該操作。在AWS中，跨服務偽裝可能導致混淆代理問題。跨服務偽裝可能發生在一個服務（呼叫服務）調用另一個服務（被調用服務）時。AWS提供工具來幫助您保護您的數據，對於所有具有服務主體的服務，這些服務主體已獲得存取您帳戶中資源的權限。角色的信任政策中的aws:SourceArn和aws:SourceAccount全局條件上下文鍵限制了Amazon Bedrock授予另一個服務（在上述情況中，授予自訂作業）的權限。aws:SourceArn是這裡更具限制性的方法，因為它定義了假定請求的具體來源，而不僅僅是AWS帳戶。

您應該僅提供完成模型自訂任務所需的權限。例如，假設您想要限制對您的訓練數據、驗證數據桶和輸出桶（Amazon Bedrock將在其中提供輸出指標）的存取。以下政策，附加到相同的服務角色上，僅提供這些權限。將<training-bucket>佔位符替換為包含您訓練數據的桶名稱，將<validation-bucket>替換為您的驗證桶，將<output-bucket>替換為您想要存儲指標的桶。

補充這種方法，我們建議使用VPC進行模型自訂作業，以限制對訓練數據的存取。從技術上講，這再次涉及VPC端點資源政策，因為網絡使用介面VPC端點來存取您的S3桶。這使您可以定義另一個網絡控制，具體來說是一個S3桶政策，該政策僅允許通過特定的VPC端點進行存取。因此，對於您想要限制自訂作業本身存取的情況，您可以應用如下示例的桶政策，將<training-bucket>替換為包含您訓練數據的桶名稱，將<vpce-id>替換為駐留在您VPC中的VPC端點ID：

此外，您將限制可以存取您的VPC端點的主體以及他們在Amazon S3中允許執行的操作。為了簡化，我們在這裡省略了一個示例政策，因為它與我們在本文前面的Amazon Bedrock調用部分中的政策非常相似。

如果您需要在Amazon S3中使用客戶管理的AWS KMS密鑰（SSE-KMS）強制加密，您需要執行以下操作：

• 使用一個聲明更新桶政策，拒絕未加密的內容被上傳。
• 更新KMS密鑰政策以允許服務角色解密和描述密鑰。

以下政策示例應添加到桶政策中，並演示如何拒絕未加密的對象被添加到S3桶中。同樣，將<training-bucket>替換為包含您訓練數據的S3桶的名稱：

最後，在KMS密鑰政策中，您需要一個類似於以下的聲明，以允許Amazon Bedrock服務角色存取KMS密鑰。將<account-id>替換為您的12位數帳號，將<bedrock-service-role>替換為您創建的角色，該角色將由Amazon Bedrock服務主體假定。確保僅給予所需的存取權限，以使用KMS密鑰解密數據給IAM角色：

Amazon Bedrock還可以使用客戶管理的KMS密鑰加密自訂模型。Amazon Bedrock使用KMS密鑰授權來加密自訂模型，並在您部署它以進行推理時解密它。因此，您需要授予相同的IAM角色權限，以在KMS密鑰政策中創建KMS密鑰授權。您用於此目的的KMS密鑰通常與您用於加密訓練數據的密鑰不同，以允許對兩個密鑰進行細粒度權限。

因此，假設您想要使用兩個不同的角色來加密和解密自訂模型。要允許執行模型自訂作業的角色使用您的KMS密鑰，您需要將以下政策聲明添加到KMS密鑰政策中，將<account-id>替換為您的12位數帳號，將<region>替換為您運行Amazon Bedrock的區域，將<bedrock-model-customization-role>替換為您用於運行模型自訂作業的角色名稱，將<invocation-role>替換為您用於推理的角色名稱。

通過使用KMS密鑰授權，您可以在自訂作業完成後撤銷授予服務角色的權限，從而將權限減少到最小特權。此外，Amazon Bedrock使用次級KMS密鑰授權進行模型加密，這意味著它們會在Amazon Bedrock代表客戶執行的操作完成後自動退休。模型自訂作業和工件的加密更詳細地描述了如何使用授權。

為了補充這些IAM政策護欄，您可以添加網絡控制以減少過程的權限範圍。由於我們在本文中專注於IAM政策，我們不會在這裡詳細介紹，但僅提及該過程的工作方式。

當您啟動模型自訂作業時，模型訓練作業會在模型部署帳戶中觸發。訓練作業從其S3桶中提取基礎模型，然後連接到持有自訂訓練數據的S3桶以開始自訂。這可以通過您的VPC完成，您可以在其中指定VPC配置，例如子網和安全組，訓練作業將彈性網絡介面（ENI）放置到指定的VPC中。現在，對S3桶的讀取訓練數據的請求將遵循該ENI在VPC中存在的任何路由規則。附加到ENI的VPC路由和安全組可用於限制對模型自訂作業的網絡存取。

Amazon Bedrock Agents

Amazon Bedrock Agents提供了為應用程式構建和配置自主代理的能力。您可以在使用AI代理自動化應用程式中的任務中找到有關Amazon Bedrock Agents的更多資訊。

使用Amazon Bedrock代理還提供了應用於推理任務的某些安全屬性。例如，在撰寫本文時，bedrock:InvokeModel API沒有IAM條件鍵來要求將Amazon Bedrock護欄附加到同一調用中。然而，您可以要求通過調用具有特定Amazon Bedrock護欄配置的代理來調用推理。

假設您想要創建一個角色，該角色僅被明確允許通過特定的Amazon Bedrock代理調用Amazon Bedrock模型。以下IAM主體權限政策示例意味著指定的Amazon Bedrock代理已配置了批准的Amazon Bedrock護欄。同樣，將<region>、<account-id>、<bedrock-agent-id>和<bedrock-agent-alias-id>替換為您的Amazon Bedrock代理的值。

假設Amazon Bedrock代理由系統管理員或操作員配置了批准的Amazon Bedrock護欄，附加了上述政策的主體將能夠使用提示調用它，並且不會直接調用Amazon Bedrock模型。這種確保Amazon Bedrock護欄應用於所有Amazon Bedrock調用的策略目前無法與bedrock:InvokeModel和bedrock:InvokeModelWithResponseStream API一起使用，因為它們沒有條件鍵來匹配Amazon Bedrock護欄。此外，拒絕bedrock:InvokeModel和bedrock:InvokeModelWithResponseStream也拒絕了Converse API和StartAsyncInvoke API，因此不需要單獨將這些添加到Deny聲明中。

由於此策略驗證了特定Amazon Bedrock護欄的使用，您還可以將其用於強制執行特定提示、IAM服務角色、知識庫、提示和完成內容限制、KMS密鑰以及推理調用中的FMs。為了使這種方法有效，您還需要限制可以創建和更新Amazon Bedrock代理配置的主體。同樣，這可以通過附加到特定主體的IAM政策來限制。

以下是一個IAM政策聲明示例，該聲明賦予附加的IAM主體更新特定Amazon Bedrock代理配置的能力，將<region>、<account-id>和<agent-id>替換為您正在使用的區域、帳戶和標識符以及代理標識符。如果您希望這適用於所有代理，請將<agent-id>替換為星號（*）。

在代理不合適的情況下，對Amazon Bedrock模型進行推理的使用者或應用程式將需要權限來調用bedrock:InvokeModel、bedrock:InvokeModelWithResponseStream或bedrock:CreateModelInvocationJob操作。在這些情況下，限制目標模型是可取的，遵循允許列表方法。此外，這些權限將僅附加到需要使用它們的角色或應用程式。

以下是一個限制調用Anthropic的Claude Instant的政策示例。

您可以使用Amazon CloudWatch EventBridge規則來檢測未使用適當Amazon Bedrock護欄的模型調用，但這超出了本文的範圍。

模型測試

測試是解決方案部署前的最後一步。測試類型包括單元測試、整合測試、使用者接受測試、滲透測試等。在這個階段，您可以再次驗證分配的權限確實是最小特權。

特別是在涉及數據的功能測試中，考慮到用於測試的數據可能是機密的這一點很重要。當沒有為測試過程生成合成測試數據時，這通常是正確的。限制對數據和可能包含這些數據片段的日誌的存取的控制需要與您在生產環境中應用的控制相同。您僅僅是在測試解決方案並不自動意味著不需要數據存取控制。

如本文前面所述，控制不僅在身份上激活，還在網絡和資源上激活。所有這些都應在此階段進行驗證並確認其有效性。測試包括但不限於：

• 驗證您只能通過VPC端點在Amazon Bedrock中執行允許的操作，並且不使用VPC端點的操作被阻止。
• 通過確保VPC端點上的資源政策只能由經過身份驗證和授權的主體使用來驗證其有效性。
• 使用知識庫時，驗證只有Amazon Bedrock服務主體可以存取它們。
• 使用Amazon Bedrock護欄時，評估其有效性。由於生成式人工智慧應用程式的性質，輸入和輸出數據的多樣性可能很大。因此，請確保使用合理大量的提示來測試護欄。
• 如果啟用了模型調用日誌記錄，驗證日誌是否正確寫入並受到IAM權限和加密的保護。
• 驗證只有需要的相關人員可以存取這些日誌，因為它們可能包含敏感數據。考慮自動清理並將它們轉發到新的CloudWatch日誌組。
• 驗證所有相關的Amazon Bedrock API調用是否在AWS CloudTrail中正確記錄，並且您可以有效地監控和警報任何可疑活動。
• 確保敏感資訊（例如提示和回應）不會存儲在CloudTrail日誌或任何跟踪輸出中。

您在設計階段可能創建的威脅建模可以提供有價值的輸入，您可以將其用於與安全相關的測試案例。

模型運行

在這個階段，解決方案最終部署到生產環境中。操作員需要Amazon Bedrock控制平面權限來配置和管理Amazon Bedrock資源，例如代理、護欄、提示庫和知識庫。他們應該僅獲得控制平面權限來配置和管理正在使用的Amazon Bedrock功能。這些相同的操作員應該只能通過授權的管道存取或配置Amazon Bedrock服務功能或其資源（Amazon Bedrock Agents、Amazon Bedrock Guardrails和提示庫）。這種不可變基礎設施方法限制了人類使用者創建可能允許未經批准的存取數據平面的情況或配置，未跟踪的控制平面更改或可能中斷應用程式的更新。

或者，為了將分配的權限減少到絕對最低限度，可以使用管道和管道角色進行自動化部署。這不僅提供了版本化的基礎設施，還通過不向人類身份提供存取權限來遵循PoLP。

部署後，解決方案已經上線並被實際使用者存取。此時，監控、日誌記錄和事件響應等主題變得相關。雖然Amazon Bedrock默認不存儲推理或回應數據，但建議您啟用這些元素的日誌記錄，以不斷驗證您的生成式人工智慧應用程式的準確性。

通過使用此解決方案，您將存取權限減少到以下方面的最低限度：

• 記錄的提示和回應
• 通過知識庫、RAG或類似來源可用的數據
• 更改基礎設施的能力

為每個任務使用多個、專用的最小特權角色。這有助於將權限範圍減少到最低限度。此外，由於最小特權強制使用特定角色來執行特定任務，它通過要求假定特定角色來降低意外更改的風險。

通過遵循AWS安全參考架構，安全監控數據集中在一個中央安全帳戶中。這允許對您的基礎設施的安全狀態進行全面的中央概覽。

記錄敏感資訊

一個重要的操作方面是記錄可能發送到或從LLM接收的敏感數據。雖然Amazon Bedrock不存儲提示或回應，但您可以使用模型調用日誌記錄來收集調用日誌、模型輸入數據和模型輸出數據，用於在Amazon Bedrock中使用的所有調用。模型調用日誌記錄默認未啟用。啟用後，所有已批准模型的所有調用的提示、完成或兩者都將記錄到配置的日誌目標。提示和完成日誌的有效日誌目標是Amazon S3和CloudWatch。將日誌寫入這些目標時，可以選擇使用提供的KMS密鑰進行加密。

這些日誌的內容可能包含使用者提供的提示或模型生成的回應中的敏感資訊。因此，對這些日誌的存取應限制在需要並被授權存取此類數據分類的員工和機器過程。有一些策略，例如在Amazon S3日誌上使用Amazon Macie和CloudWatch日誌數據保護功能來檢測、監控和編輯這些日誌中的敏感資訊，但這超出了本文的範圍。

即使有Amazon Bedrock護欄，這些日誌的內容仍包含護欄前的使用者輸入，因此您必須假設這些提示和完成日誌包含敏感資訊。在這種情況下，最佳做法是使用KMS密鑰加密日誌數據，將數據保護政策應用於日誌組，並定義至少三個IAM角色：

• BasicCompletionLogReviewer：一個IAM角色，其唯一目的是存取和審查這些日誌的編輯版本。
• SensitiveDataCompletionLogReviewer：一個受限的IAM角色，其唯一目的是存取和審查這些日誌的未編輯版本。
• CompletionLogAdmin：一個受限的IAM角色，其唯一目的是創建、查看和刪除數據保護政策，這些政策可以將審核結果發送到Amazon S3和CloudWatch目標。

要允許在特定日誌組中讀取日誌事件，請使用如下政策並將其附加到BasicCompletionLogReviewer角色，將<region>、<account-id>、<log-group-name>和<alias-name>替換為與您的CloudWatch日誌組和加密它的KMS密鑰匹配的值。

如果有活動的數據保護政策，上述政策將不允許存取這些日誌的未編輯版本。要允許對SensitiveDataCompletionLogReviewer角色存取未編輯版本，您需要添加一個額外的操作，將<region>、<account-id>、<log-group-name>和<alias-name>替換為與您的CloudWatch日誌組和加密它的KMS密鑰匹配的值。

CompletionLogAdmin角色的政策需要不同的權限；以下示例政策允許使用者創建、查看和刪除數據保護政策，這些政策可以將審核結果發送到所有三種類型的審核目標。它不允許使用者查看未編輯的數據。此政策將如下例所示，將<delivery-stream-id>、<bucket-name>、<log-group-name>和<alias-name>替換為與您的設置匹配的值。請注意，這包括一個明確拒絕附加角色使用配置的KMS密鑰解密日誌的聲明，符合PoLP：

這種方法有助於避免無意中存取或暴露此敏感數據源，並通過分離職責來維護PoLP。

定期審查IAM權限

管理權限是一項持續的工作，因為需求和功能會隨著時間的推移而改變。因此，我們建議定期審查分配的權限並驗證它們不過於寬泛。例如，如果您有一個Lambda函數調用Amazon Bedrock的API，並且對該函數進行了更改，需要額外的權限（可能是使用新模型），那麼更新附加到該函數使用的IAM角色的政策是可以接受的。並不總是明顯的是，使用早期模型的權限在同一政策中仍然是必要的；或者權限可能被不必要地擴大到包括所有模型。應用PoLP時，重要的是在部署時測試政策，以確保它們滿足確切的應用程式需求而不超過，但也要定期審查假定的需求。

使用AWS IAM存取分析器，您可以審查和模擬對IAM政策的建議更改，以確保它們適合於給定的應用程式或功能。您還可以使用IAM存取分析器來審查未使用的權限。這為系統操作員提供了一個機會來檢查然後通知刪除在Amazon Bedrock應用程式中使用的政策中的未使用權限。請記住，一些權限是休眠的，準備定期使用，例如事件響應、恢復和其他罕見的用例，因此您的審查不應假設未使用的權限是不必要的，而是審查權限需求的機會。

最後，將新Amazon Bedrock API的監控與您的IAM策略對齊。特別是在使用拒絕列表方法時，重要的是要考慮到服務將隨著時間的推移宣布新的API、功能和FMs。這方面的一個例子是宣布了新的Converse API。此API提供了類似於Invoke的功能，但以一致且因此更簡單的方式。因此，考慮此類更改是您定期政策審查過程的組成部分。

強大的身份和存取管理是一個旅程，而不是一次性行動。

結論

在這篇文章中，我們展示了一些您可以將最小特權原則（PoLP）應用於使用Amazon Bedrock的大型語言模型（LLM）應用程式的方法。我們討論了開發生命週期每個階段的安全考量，並提供了一些您可以用作實施自己PoLP策略的起點的示例。重要的是，安全性不應在過程中晚期開始；盡早考慮風險和所需的行動，以確保您的策略在應用程式上線時有效。

最後，請記住，生成式人工智慧領域正在迅速發展。我們相信它有潛力改變幾乎每一個客戶體驗。從安全的角度來看，這意味著威脅環境將隨著時間的推移而改變和發展。確保不斷適應新風險；評估並將它們整合到您的PoLP策略中。

您的AWS帳戶團隊和專家很樂意在這段旅程中為您提供幫助。

如果您對本文有反饋，請在下方的評論區提交評論。如果您對本文有疑問，請聯繫AWS支持。

Michael Tschannen
Michael是AWS的EMEA資深專家SA安全，駐瑞士。在職業生涯初期擔任滲透測試員後，他決定轉向防禦方面。從那時起，他每天都在通過將安全和隱私作為他構建的每個解決方案的組成部分來保護客戶及其數據。