本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
使用 IAM 政策條件進行精細定義存取控制
您在 DynamoDB 中授予許可時,可以指定條件,以決定許可政策的生效方式。
概觀
在 DynamoDB 中,您可以選擇在使用 IAM 政策授予許可時指定條件 (請參閱 Amazon DynamoDB 的 Identity and Access Management)。例如,您可以:
-
授予許可,允許使用者唯讀存取資料表或次要索引中的特定項目和屬性。
-
授予許可,允許使用者根據該使用者的身分唯寫存取資料表中的特定屬性。
在 DynamoDB 中,您可以使用條件金鑰在 IAM 政策中指定條件,如下節中的使用案例所述。
許可使用案例
除了控制對 DynamoDB API 動作的存取之外,您也可以控制對個別資料項目和屬性的存取。例如,您可以執行下列動作:
-
授予資料表的許可,但根據特定主索引鍵值來限制存取該資料表中的特定項目。範例可能是遊戲的社交聯網應用程式,而所有使用者的已儲存遊戲資料都會存放在單一資料表中,但使用者無法存取他們未擁有的資料項目,如下圖所示:
-
隱藏資訊,讓使用者只能看到一部分的屬性。範例可能是根據使用者位置來顯示附近機場之航班資料的應用程式。航空公司名稱、到達和起飛時間,以及航班編號全部會顯示。不過,會隱藏駕駛員名稱或乘客數目這類屬性,如下圖所示:
若要實作這類精細定義存取控制,您可以撰寫 IAM 許可政策,以指定條件來存取安全憑證和相關聯許可。您接著將政策套用至使用 IAM 主控台所建立的使用者、群組或角色。您的 IAM 政策可以限制對資料表中個別項目的存取、對這些項目中屬性的存取,或同時限制兩者的存取。
您可以選擇性地使用 Web 聯合身分來控制透過 Login with Amazon、Facebook 或 Google 進行身分驗證之使用者的存取。如需詳細資訊,請參閱 使用 Web 聯合身分。
您可以使用 IAM Condition 元素來實作精細定義存取控制政策。將 Condition 元素新增至許可政策,即可根據特定商業需求來允許或拒絕存取 DynamoDB 資料表和索引中的項目和屬性。
例如,試想有一個能讓玩家選取和玩各種不同遊戲的手機遊戲應用程式。應用程式會使用名為 GameScores 的 DynamoDB 資料表記錄高分和其他使用者資料。資料表中的每個項目都是依使用者 ID 和使用者所玩遊戲的名稱進行唯一識別。GameScores 資料表的主索引鍵包含分割區索引鍵 (UserId) 與排序索引鍵 (GameTitle)。使用者只可存取與其使用者 ID 建立關聯的遊戲資料。想要玩遊戲的使用者必須屬於名為 GameRole 且已連接安全政策的 IAM 角色。
若要管理應用程式中的使用者許可,您可以撰寫下列這類許可政策:
除了授予 GameScores 資料表 (Action 元素) 上特定 DynamoDB 動作 (Resource 元素) 的許可之外,Condition 元素還會使用 DynamoDB 特有的下列條件金鑰來限制許可,如下所示:
-
dynamodb:LeadingKeys:此條件金鑰可讓使用者只存取分割區索引鍵值符合其使用者 ID 的項目。此 ID${www.amazon.com:user_id}是替換變數。如需替換變數的詳細資訊,請參閱 使用 Web 聯合身分。 -
dynamodb:Attributes:此條件金鑰會限制對所指定屬性的存取,因此只有許可政策中所列的動作才能傳回這些屬性的值。此外,StringEqualsIfExists子句可以確保應用程式必須一律提供要處理的特定屬性清單,以及確保應用程式無法請求所有屬性。
評估 IAM 政策時,結果一律是 true (允許存取) 或 false (拒絕存取)。如果 Condition 元素的任一部分是 false,則整個政策會評估為 false,並拒絕存取。
重要
如果您使用 dynamodb:Attributes,則必須指定政策中所列資料表和任何次要索引之所有主索引鍵和索引鍵屬性的名稱。否則,DynamoDB 無法使用這些索引鍵屬性來執行所請求的動作。
IAM 政策文件只能包含下列 Unicode 字元:水平定位字元 (U+0009)、換行字元 (U+000A)、歸位字元 (U+000D),以及 U+0020 到 U+00FF 範圍內的字元。
指定條件:使用條件金鑰
AWS 為支援 IAM 進行存取控制的所有 AWS 服務提供一組預先定義的條件金鑰 (AWS全條件金鑰)。例如,您可以使用 aws:SourceIp 條件金鑰先檢查申請者的 IP 位址,再允許執行動作。如需詳細資訊和 AWS全局金鑰清單,請參閱《IAM 使用者指南》中的可用條件金鑰。
下表顯示適用於 DynamoDB 的 DynamoDB 服務專屬條件金鑰。
| DynamoDB 條件金鑰 | 描述 |
|---|---|
dynamodb:LeadingKeys |
代表資料表的第一個索引鍵屬性,換言之,即分割區索引鍵。索引鍵名稱 |
dynamodb:FirstPartitionKeyValues |
代表資料表的第一個索引鍵屬性,也就是第一個分割區索引鍵。索引鍵名稱 |
dynamodb:SecondPartitionKeyValues |
類似於 |
dynamodb:ThirdPartitionKeyValues |
類似於 |
dynamodb:FourthPartitionKeyValues |
類似於 |
dynamodb:Select |
代表
|
dynamodb:Attributes |
代表請求存取的最上層屬性清單。如果請求或其包含的任何巢狀屬性是在請求參數中指定或從請求傳回,則會由請求存取頂層屬性。例如,指定 |
dynamodb:ReturnValues |
代表請求的
|
dynamodb:ReturnConsumedCapacity |
代表請求的
|
限制使用者存取
許多 IAM 許可政策可讓使用者只存取資料表中分割區索引鍵值符合使用者識別符的項目。例如,遊戲應用程式先前限制是使用此方式所存取,因此使用者只能存取與其使用者 ID 建立關聯的遊戲資料。IAM 替換變數 ${www.amazon.com:user_id}、${graph.facebook.com:id} 和 ${accounts.google.com:sub} 包含用於 Login with Amazon、Facebook 及 Google 的使用者識別符。若要了解應用程式如何登入其中一個身分提供者,並取得這些識別符,請參閱 使用 Web 聯合身分。
重要
不支援使用精細存取控制來限制全域資料表的複寫。將精細存取控制的原則條件套用至用於全域資料表複寫的 DynamoDB 服務主體或服務連結角色,可能導致全域資料表內的複寫中斷。
注意
下節中的每個範例都會將 Effect 子句設定為 Allow,而且只指定允許的動作、資源及參數。只允許存取 IAM 政策中明確列出的項目。
在某些情況下,有可能會重新撰寫這些政策,讓它們成為拒絕類型 (即,將 Effect 子句設定為 Deny,並反轉政策中的所有邏輯)。不過,建議您避免在 DynamoDB 中使用以拒絕為基礎的原則,因為這類原則比以允許為基礎的原則更難正確撰寫。此外,DynamoDB API 的未來變更 (或現有 API 輸入的變更) 也可能會導致無效的拒絕類型政策。
範例政策:使用條件進行精細定義存取控制
本節顯示數個政策,來實作 DynamoDB 資料表和索引上的精細定義存取控制。
注意
所有範例都會使用 us-west-2 區域,並且包含虛構帳戶 ID。
以下影片說明如何在 DynamoDB 中透過 IAM 政策條件實作精細存取控制。
1:授予許可,以限制存取具有特定分割區索引鍵值的項目
下列許可政策授予許可,以允許 GamesScore 資料表上的一組 DynamoDB 動作。它會使用 dynamodb:LeadingKeys 條件金鑰,只限制下列項目的使用者動作:其 UserID 主索引鍵值符合此應用程式之 Login with Amazon 唯一使用者 ID 的項目。
重要
動作清單不包含 Scan 的許可,因為 Scan 會傳回所有項目,不論前導索引鍵為何。
注意
使用政策變數時,您必須在政策中明確指定版本 2012-10-17。存取政策語言的預設版本 2008-10-17 不支援政策變數。
若要實作唯讀存取權,您可以移除任何可修改資料的動作。在下列政策中,條件中只會包含提供唯讀存取權的動作。
重要
如果您使用 dynamodb:Attributes,則必須指定政策中所列資料表和任何次要索引之所有主索引鍵和索引鍵屬性的名稱。否則,DynamoDB 無法使用這些索引鍵屬性來執行所請求的動作。
2:授予許可,以限制存取資料表中的特定屬性
下列許可政策透過新增 dynamodb:Attributes 條件金鑰,來允許只存取資料表中的兩個特定屬性。在條件式寫入或掃描篩選條件中,可以讀取、寫入或評估這些屬性。
注意
政策會採用允許清單方式,以允許存取一組指定的屬性。您可以撰寫同等的政策,改為拒絕存取其他屬性。我們不建議使用此拒絕清單方式。使用者可以決定這些受拒絕的屬性,請遵循最低權限政策,如 Wikipedia (網址為 http://en.wikipedia.org/wiki/Principle_of_least_privilege
此政策不允許 PutItem、DeleteItem 或 BatchWriteItem。這些動作一律會取代整個先前項目,以允許使用者刪除不允許它們存取之屬性的先前值。
許可政策中的 StringEqualsIfExists 子句確保下列狀況:
-
如果使用者指定
Select參數,則其值必須是SPECIFIC_ATTRIBUTES。此需求防止 API 動作傳回任何不允許的屬性,例如來自索引投影。 -
如果使用者指定
ReturnValues參數,則其值必須是NONE、UPDATED_OLD或UPDATED_NEW。這是必要項目,因為UpdateItem動作也會執行隱含讀取操作來檢查項目在取代前是否存在,因此,請求時可以傳回先前的屬性值。以這種方式限制ReturnValues可確定使用者只能讀取或寫入允許的屬性。 -
StringEqualsIfExists子句可確保在允許動作內容中,一個請求只能使用其中一個參數:Select或ReturnValues。
以下是此政策的某些變化:
-
若只要允許讀取動作,您可以從允許動作清單中移除
UpdateItem。因為其餘動作不接受ReturnValues動作,所以您可以從條件中移除ReturnValues。您也可以將StringEqualsIfExists變更為StringEquals,因為Select參數一律會有值 (除非特別指定,否則為ALL_ATTRIBUTES)。 -
若只要允許寫入動作,您可以從允許動作清單中移除所有項目,但
UpdateItem除外。因為UpdateItem未使用Select參數,所以您可以從條件中移除Select。您也必須將StringEqualsIfExists變更為StringEquals,因為ReturnValues參數一律會有值 (除非特別指定,否則為NONE)。 -
若要允許名稱符合某模式的所有屬性,請使用
StringLike,而非StringEquals,並使用多字元模式相符萬用字元 (*)。
3:授予許可,防止特定屬性的更新
下列許可政策限制只更新 dynamodb:Attributes 條件金鑰所識別之特定屬性的使用者存取。StringNotLike 條件防止應用程式更新使用 dynamodb:Attributes 條件金鑰所指定的屬性。
注意下列事項:
-
UpdateItem動作 (如同其他寫入動作) 需要項目的讀取存取,以便其傳回更新前後的值。在政策中,您會限制只存取特定屬性的動作,且這些屬性僅限於允許藉由指定dynamodb:ReturnValues條件金鑰來進行更新者。條件金鑰會限制請求中的ReturnValues,只指定NONE、UPDATED_OLD或UPDATED_NEW,而且未包含ALL_OLD或ALL_NEW。 -
PutItem和DeleteItem動作會取代整個項目,因此允許應用程式修改任何屬性。因此,限制應用程式只更新特定屬性時,您不應該授予這些 API 的許可。
4:授予許可,只查詢索引中的投影屬性
下列許可政策使用 dynamodb:Attributes 條件金鑰,允許對次要索引 (TopScoreDateTimeIndex) 進行查詢。政策也會限制只請求已投影到索引之特定屬性的查詢。
若需要應用程式在查詢中指定屬性清單,政策也會指定 dynamodb:Select 條件金鑰需要 DynamoDB Query 動作的 Select 參數是 SPECIFIC_ATTRIBUTES。屬性清單限制為使用 dynamodb:Attributes 條件金鑰所提供的特定清單。
下列許可政策類似,但查詢必須請求所有已投影到索引的屬性。
5:授予許可,以限制存取特定屬性和分割區索引鍵值
下列許可政策允許資料表和資料表索引 (指定於 Action 元素) 的特定 DynamoDB 動作 (指定於 Resource 元素)。此政策使用 dynamodb:LeadingKeys 條件金鑰來限制分割區索引鍵值符合使用者 Facebook ID 之項目的許可。
注意下列事項:
-
政策 (
UpdateItem) 所允許的寫入動作只能修改attribute-A或attribute-B。 -
因為政策允許
UpdateItem,所以應用程式可以插入新項目,而隱藏屬性在新項目中會是 Null。如果這些屬性投影到TopScoreDateTimeIndex,則政策將有助於防止會致使從資料表擷取的查詢。 -
應用程式無法讀取
dynamodb:Attributes中所列屬性以外的任何屬性。在此政策下,應用程式必須將讀取請求中的Select參數設定為SPECIFIC_ATTRIBUTES,而且只能請求列於允許清單上的屬性。對於寫入請求,應用程式無法將ReturnValues設定為ALL_OLD或ALL_NEW,而且無法根據任何其他屬性來執行條件式寫入操作。