s3：signatureAge 的護欄 s3：authType 的護欄結合預先簽章的護欄和其他護欄的例外狀況 s3：signatureAge 的限制大規模鎖定儲存貯體

其他護欄

當解決方案建置者和使用者適當使用預先簽章的請求時，它們會提供安全機制，讓使用者存取資料。此外，產生預先簽章請求的能力不會為委託人提供他們尚未擁有的存取權。

在這種情況下，是否需要額外的控制？其他控制的理由並非基於需要拒絕存取，而是提供監控功能、核准用量和設定界限，以及降低使用者錯誤的風險。透過這種方式，您可以協助確保用量是適當且必要的。

下列護欄可協助您實現此目標。在啟用這些控制項之前，您可能想要透過識別預先簽章的請求來判斷現有的用量。此識別可協助您準備護欄對現有用量的影響，或視需要規劃例外狀況。

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 控制，如控制可以設定哪些標籤值的這個範例所示。此類型的標籤也可以來自工作階段標籤，這些標籤是由身分提供者 (IdP) 或使用時所設定 AWS STS。控制對的存取aws:PrincipalTag是一個複雜的主題。不過，具有屬性型存取控制 (ABAC) 使用經驗的組織，將擁有經驗和控制項，可aws:PrincipalTag針對此使用案例適當使用。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPresignedOver15Minutes",
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": {
        "NumericGreaterThan": {
          "s3:signatureAge": "900000"
        },
--- Example exception ---
        "StringNotEquals": {
          "aws:PrincipalTag/long-presigned-allowed": "true"
        }
--- Example exception end ---
      }
    }
  ]
}

儲存貯體政策

您可以使用政策將儲存貯體政策套用至所有或選取的儲存貯體，如下列範例所示。與 SCP 不同，儲存貯體政策也會以服務主體用量為目標。附錄 A 不會記錄預先簽章請求的任何預期服務主體用量，但如果您想要實作控制項來證明限制，下列政策會提供該控制項。此外，與 SCP 不同，儲存貯體政策可以套用至您管理帳戶中的主體。ABAC 型例外狀況在儲存貯體政策中的運作方式與 SCP 相同。


{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyPresignedOver15Minutes",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::{bucket-name}/*",
      "Condition": {
        "NumericGreaterThan": {
          "s3:signatureAge": "900000"
        },
--- Example exception ---
        "StringNotEquals": {
          "aws:PrincipalTag/long-presigned-allowed": "true"
        }
--- Example exception end ---
      }
    }
  ]
}

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可以使用 aws:PrincipalTag 為使用者進行例外狀況。您無法在儲存貯體上使用標籤來透過 aws:ResourceTag― 只有物件標籤用於存取控制來控制存取。將標籤新增至您要套用此控制項的每個物件通常無法擴展。

適合許多使用案例的解決方案是在帳戶層級套用政策和例外狀況，方法是變更 SCP 套用的帳戶，或使用 aws：ResourceAccount、aws：ResourceOrgPaths 或 aws：ResourceOrgID。例如，SCP 可能會套用至一組生產帳戶。

另一個解決方案是使用自訂 AWS Config 規則來實作偵測性控制或回應式控制。目標是讓每個儲存貯體都包含具有適當護欄的儲存貯體政策。除了測試儲存貯體政策的內容之外，自訂 AWS Config 規則還可以從儲存貯體擷取標籤，如果儲存貯體已標記特定值，則從規則中排除儲存貯體。如果該規則未通過其合規檢查，則可以將儲存貯體標記為不合規，或叫用修復，將護欄新增至儲存貯體的政策。

注意

您無法限制 PutBucketTagging 請求的標籤內容。若要維持對儲存貯體標籤方式的控制，您必須限制對 PutBucketTagging和 DeleteBucketTagging 的存取。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

基礎最佳實務

記錄互動和緩解措施