本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
其他護欄
當解決方案建置器和使用者適當使用預先簽章的請求時,它們會提供安全機制,讓使用者存取資料。此外,產生預先簽章請求的能力不會為委託人提供他們尚未擁有的存取權。
在這種情況下,是否需要額外的控制? 其他控制的理由並非基於需要拒絕存取,而是提供監控功能、核准用量和設定界限,以及降低使用者錯誤的風險。透過這種方式,您可以協助確保用量是適當且必要的。
下列護欄可協助您實現此目標。在啟用這些控制項之前,您可能想要透過識別預先簽章的請求來判斷現有的用量。此識別可協助您準備護欄對現有用量的影響,或視需要規劃例外狀況。
s3:signatureAge 的護欄
預先簽章請求的一個定義特徵是它們描述過期時間。請求的簽章包含日期。此日期會以預先簽章 URLs 的X-Amz-Date查詢字串參數傳輸,並以預先簽章 POST 的日期或 x-amz-date 標頭傳輸。
Amazon S3 提供條件金鑰 s3:signatureAge,可用來限制簽署日期與請求有效過期之間的最長時間。此條件永遠不會增加有效期間,但可以減少有效期間。
在下列政策中,s3:signatureAge條件索引鍵會將預先簽章的請求限制為 15 分鐘的有效時間。下列範例全都使用 15 分鐘,將有效性限制為與標準簽署支援類似的時間範圍。
政策的第二個陳述式拒絕任何 Signature 第 2 版存取。此版本的簽署通訊協定已被取代,但在某些 中仍然支援 AWS 區域。我們建議您在完全棄用之前明確封鎖它。
您可以套用下列政策做為 AWS Organizations 服務控制政策 (SCP)。只要簽章產生和使用之間的時間少於 15 分鐘,使用者仍然可以使用預先簽章的請求並部署相依於這些請求的解決方案。視實作而定,此限制可能沒有任何影響、可能導致解決方案無法使用,或偶爾可能會導致重試的失敗。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" } } }, { "Sid": "DenySignatureVersion2", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringEquals": { "s3:signatureversion": "AWS" } } } ] }
例外狀況
如果解決方案在過期前需要較長的時間,因此受到上述政策的影響,建議您提供核准例外狀況的方法。若要避免在 SCP 中列舉例外狀況,請使用 aws:PrincipalTag,如下列政策所示,以可擴展的方式管理例外狀況。其他 AWS 範例,例如 AWS 資料周邊政策範例
如果您使用 實作例外狀況政策aws:PrincipalTag,則必須控制在主體上設定標籤的存取權。此類型的標籤可以直接來自主體,並且可以由 SCP 控制,如控制可以設定哪些標籤值的這個範例aws:PrincipalTag是一個複雜的主題。不過,具有屬性型存取控制 (ABAC) 使用經驗的組織,將具有經驗和控制,可aws:PrincipalTag針對此使用案例適當使用 。
在下列範例中, aws:PrincipalTag條件會建立例外狀況,以允許任何已指派具名標籤 (long-presigned-allowed) 且設定為 的委託人true。在此情況下,不會套用對簽章存留期的限制。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15Minutes", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } } } ] }
儲存貯體政策
您可以使用政策將儲存貯體政策套用至所有或選取的儲存貯體,如下列範例所示。與 SCP 不同,儲存貯體政策也會以服務主體用量為目標。附錄 A 不會記錄預先簽章請求的任何預期服務主體用量,但如果您想要實作控制項來證明限制,下列政策會提供該控制項。此外,與 SCP 不同,儲存貯體政策可以套用至您管理帳戶中的主體。
ABAC 型例外狀況在儲存貯體政策中的運作方式與 SCP 相同。儲存貯體政策的目標可能是適用於組織外部的委託人,因此 ABAC 例外狀況應限於適用 ABAC 控制的委託人。
在下列範例中,第一個陳述式中的 aws:PrincipalTag條件會為已指派具名標籤 (long-presigned-allowed) 且設定為 的委託人建立例外狀況true。在此情況下,不會套用對簽章存留期的限制。第二個陳述式會將此限制套用至組織外部 AWS 擁有儲存貯體的所有委託人。第二個陳述式的範圍應與 ABAC 控制項相符,以設定主體的具名標籤。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15MinWithExceptions", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true" } } }, { "Sid": "DenyPresignedOver15MinutesOutsideOrg", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalOrgID": "${aws:ResourceOrgID}" } } } ] }
資源控制政策
您可以使用資源控制政策 (RCPs) 大規模將政策套用至儲存貯體。與 SCPs和與儲存貯體政策不同,RCPs不會以服務主體用量為目標。RCPs會影響任何帳戶中的非服務主體,但不會影響管理帳戶中的資源。如需詳細資訊,請參閱 AWS Organizations 文件。
如同儲存貯體政策,如果您使用 aws:PrincipalTags為委託人建立例外狀況,請記住標記委託人的 ABAC 控制範圍。
下列 RCP 會將組織中所有 S3 儲存貯體的預先簽章 URL 用量限制為 15 分鐘。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyPresignedOver15MinWithExceptions", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::*/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalTag/long-presigned-allowed": "true", } } }, { "Sid": "DenyPresignedOver15MinutesOutsideOrg", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::*/*", "Condition": { "NumericGreaterThan": { "s3:signatureAge": "900000" }, "StringNotEquals": { "aws:PrincipalOrgID": "${aws:ResourceOrgID}" } } } ] }
s3:authType 的護欄
預先簽章URLs 使用查詢字串身分驗證,而預先簽章POSTs 一律使用 POST 身分驗證。Amazon S3 支援透過 s3:authType 條件金鑰根據身分驗證類型拒絕請求。 REST-QUERY-STRING 是查詢字串s3:authType的值,而 POST是 POST s3:authType的值。
您可以套用下列政策做為 SCP。政策使用 s3:authType只允許以標頭為基礎的身分驗證。它也會設定 方法,為個別使用者或角色提供例外狀況。
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Action": "s3:*", "Resource": "*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] }
根據身分驗證類型拒絕請求會影響使用拒絕身分驗證類型的任何解決方案或功能。例如,拒絕REST-QUERY-STRING可防止使用者從 Amazon S3 主控台執行上傳或下載。如果您希望使用者使用 Amazon S3 主控台,請勿使用此護欄,或對使用者進行例外處理。另一方面,如果您不希望使用者使用 Amazon S3 主控台,您可以拒絕 REST-QUERY-STRING 使用者。
也許您已經拒絕使用者直接存取 Amazon S3 資源。在這種情況下,身分驗證類型的護欄是多餘的。不過,s3:authType拒絕陳述式提供defense-in-depth公用程式,因為拒絕直接存取的實作通常跨越許多控制陳述式,有些則例外。
用於工作負載的角色通常不需要存取查詢字串或POST身分驗證。例外狀況是支援使用預先簽章請求之服務的角色。您可以為這些角色建立特定例外狀況。
您也可以使用如下所示的政策,將儲存貯體政策套用至所有或選取的儲存貯體:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" } } } ] }
此儲存貯體政策具有拒絕使用 CopyObject 和 UploadPartCopy APIs 進行跨區域複製的效果。Amazon S3 複寫不受影響,因為它不依賴這些 APIs。
如果您想要使用儲存貯體政策,例如上述政策,但仍支援跨區域 CopyObject 或 UploadPartCopy API,請新增 的條件,aws:ViaAWSService如下所示:
{ "Version": "2012-10-17", "Statement": [ { "Sid": "DenyNonHeaderAuth", "Effect": "Deny", "Principal": "*", "Action": "s3:*", "Resource": "arn:aws:s3:::{bucket-name}/*", "Condition": { "StringNotEquals": { "s3:authType": "REST-HEADER", "aws:PrincipalTag/non-header-auth-allowed": "true" }, "Bool": { "aws:ViaAWSService": "false" }, } } ] }
結合預先簽章的護欄和其他護欄的例外狀況
如果您不打算將護欄一般套用到您的使用者和角色,建議您將其套用到其他常見護欄的例外狀況,因此這些例外狀況不支援預先簽章的請求。
如果您有網路限制,但允許外部合作夥伴的例外狀況或特殊使用案例,您應該在套用這些例外狀況時封鎖查詢字串或POST身分驗證,除非特別將其識別為必要。
s3:signatureAge 的限制
管理員會發現s3:signatureAge更完整地了解 的影響非常有用。每個已簽章的請求都包含 X-Amz-Date,應指出目前的時間。此值是由用戶端和請求 signer. AWS rejects 視為具有無效時間的請求所填入。不過,簽署者可以在未來的時間預先產生簽章。如果傳送時間太早,Amazon S3 會拒絕指定未來時間的請求。不過,如果請求在登入簽章之前不會傳送,則可以更早產生並稍後傳送簽章。
s3:signatureAge 只會針對預先簽章的請求限制簽章X-Amz-Date中 的最長存留期。 即使過期時間超過指定的存留期,或X-Amz-ExpiresPOST政策已宣告有效, 仍會拒絕請求。 s3:signatureAge 不會變更未包含明確過期的請求的有效期間。它也不會控制用戶端用於簽章X-Amz-Date的 值。
如果系統時鐘錯誤,或用戶端刻意提出未來日期請求,簽署時間可能不是產生簽章的時間。 這會限制s3:signatureAge控制解決方案的程度。產生簽章時使用目前時間的解決方案會以預期的方式受到限制:簽章在 中指定的毫秒數內仍然有效s3:signatureAge。不使用目前時間 的解決方案會有不同的限制。其中一個限制是用來簽署簽章的登入資料仍然有效。身為管理員,您可以控制發行的臨時登入資料的最大有效性。 您可以允許登入資料有效長達 36 小時,或將有效性限制為低至 15 分鐘。臨時登入資料 過期不取決於 的值X-Amz-Date。
永久登入資料沒有此限制。 僅使用臨時登入資料是最佳實務,您可以明確撤銷任何永久登入資料,這也會使根據該登入資料的任何簽章失效。
雖然 s3:signatureAge 是以毫秒為單位測量,但即使您有良好的同步時鐘和低延遲用量,將其設定為少於 60 秒並不實際。低於 60 秒 的設定具有拒絕有效請求的風險。如果您預期簽章產生和請求提交之間的延遲,或時鐘同步問題,您應該在 的管理中考慮這些問題s3:signatureAge。
大規模鎖定儲存貯體
SCPs和 RCPs可以使用 aws:PrincipalTag 為使用者進行例外狀況。您無法在儲存貯體上使用標籤來透過 aws:ResourceTag― 僅物件標籤來控制存取,只會用於存取控制。為您要套用此控制項的每個物件新增標籤通常無法擴展。
適合許多使用案例的解決方案是在帳戶層級套用政策和例外狀況,方法是變更 SCP 或 RCP 套用的帳戶,或使用 aws:ResourceAccount、aws:ResourceOrgPaths 或 aws:ResourceOrgID。例如,SCP 或 RCP 可能會套用至一組生產帳戶。
另一個解決方案是使用自訂 AWS Config 規則來實作偵測性控制或回應式控制。目標是讓每個儲存貯體包含具有適當護欄的儲存貯體政策。除了測試儲存貯體政策的內容之外,自訂 AWS Config 規則還可以從儲存貯體擷取標籤,並在儲存貯體加上特定值的標籤時,從規則中排除儲存貯體。如果該規則未通過其合規檢查,則可以將儲存貯體標記為不合規,或叫用修復,將護欄新增至儲存貯體的政策。
注意
您無法限制 PutBucketTagging 請求的標籤內容。若要維持對儲存貯體標籤方式的控制,您必須限制對 PutBucketTagging和 DeleteBucketTagging 的存取。