tencent cloud

Cloud Object Storage

最新情報とお知らせ
製品アップデート情報
製品のお知らせ
製品概要
製品概要
機能概要
応用シナリオ
製品の優位性
基本概念
リージョンとアクセスドメイン名
仕様と制限
製品の課金
課金概要
課金方式
課金項目
無料利用枠
記帳例
請求書の確認とダウンロード
お支払い遅れについて
よくある質問
クイックスタート
コンソールクイックスタート
COSBrowserクイックスタート
ユーザーガイド
リクエストの作成
バケット
オブジェクト
データ管理
バッチ処理
グローバルアクセラレーション
監視とアラーム
運用管理センター
データ処理
インテリジェントツールボックス使用ガイド
データワークフロー
アプリ統合
ツールガイド
ツール概要
環境のインストールと設定
COSBrowserツール
COSCLIツール
COSCMDツール
COS Migrationツール
FTP Serverツール
Hadoopツール
COSDistCpツール
HDFS TO COSツール
オンラインツール (Onrain Tsūru)
セルフ診断ツール
実践チュートリアル
概要
アクセス制御と権限管理
パフォーマンスの最適化
AWS S3 SDKを使用したCOSアクセス
データディザスタリカバリバックアップ
ドメイン名管理の実践
画像処理の実践
COSオーディオビデオプレーヤーの実践
データセキュリティ
データ検証
COSコスト最適化ソリューション
サードパーティアプリケーションでのCOSの使用
移行ガイド
サードパーティクラウドストレージのデータをCOSへ移行
データレークストレージ
クラウドネイティブデータレイク
メタデータアクセラレーション
データアクセラレーター GooseFS
データ処理
データ処理概要
画像処理
メディア処理
コンテンツ審査
ファイル処理
ドキュメントプレビュー
トラブルシューティング
RequestId取得の操作ガイド
パブリックネットワーク経由でのCOSへのファイルアップロード速度の遅さ
COSへのアクセス時に403エラーコードが返される
リソースアクセス異常
POST Objectの一般的な異常
セキュリティとコンプライアンス
データ災害復帰
データセキュリティ
クラウドアクセスマネジメント
よくある質問
よくあるご質問
一般的な問題
従量課金に関するご質問
ドメインコンプライアンスに関するご質問
バケット設定に関する質問
ドメイン名とCDNに関するご質問
ファイル操作に関するご質問
権限管理に関するご質問
データ処理に関するご質問
データセキュリティに関するご質問
署名付きURLに関するご質問
SDKクラスに関するご質問
ツール類に関するご質問
APIクラスに関するご質問
Agreements
Service Level Agreement
プライバシーポリシー
データ処理とセキュリティ契約
連絡先
用語集

条件キーの説明および使用例

PDF
フォーカスモード
フォントサイズ
最終更新日: 2025-10-09 14:41:22
アクセスポリシーを使用して権限承認を行う場合、ポリシーの発効条件を指定することができます。例えば、ユーザーのアクセス元、アップロードファイルのストレージタイプなどの制限があります。
ここでは、バケットポリシーにおけるCloud Object Storage(COS)条件キー使用の一般的な例について記載します。発効条件のドキュメント内で、COSがサポートするすべての条件キーおよび適用可能なリクエストを確認することができます。
説明:
条件キーを使用してポリシーを作成する際は、必ず最小権限の原則を遵守し、適用可能なリクエスト(action)のみに該当する条件キーを追加してください。アクション(action)を指定する際にワイルドカード「*」を使用すると、リクエストが失敗しますので避けてください。条件キーに関する説明は、発効条件のドキュメントをご参照ください。
Cloud Access Management(CAM)コンソールを使用してポリシーを作成する際は、構文形式にご注意ください。version、principal、statement、effect、action、resource、conditionの構文要素は全て小文字で記述してください。

ユーザーアクセスIPの制限(qcs:ip)

条件キー qcs:ip

条件キーqcs:ipを使用してユーザーアクセスIPを制限します。すべてのリクエストに適用可能です。

例:指定IPからのユーザーアクセスのみを許可

次のポリシーの記述例は、ルートアカウントID 100000000001(APPIDは1250000000)下のサブアカウントID 100000000002に対し、北京リージョンのバケットのexamplebucket-bjおよび広州リージョンのバケットのexamplebucket-gz下のオブジェクトexampleobjectについて、アクセスIPが192.168.1.0/24ネットワークセグメントにある場合およびIPが101.226.100.185または101.226.100.186である場合に、オブジェクトのアップロードおよびオブジェクトのダウンロード権限を許可するものです。
{
"version": "2.0",
"principal": {
"qcs": [
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"statement": [
{
"effect": "allow",
"action": [
"name/cos:PutObject",
"name/cos:GetObject"
],
"resource": [
"qcs::cos:ap-beijing:uid/1250000000:examplebucket-bj-1250000000/*",
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-gz-1250000000/exampleobject"
],
"condition": {
"ip_equal": {
"qcs:ip": [
"192.168.1.0/24",
"101.226.100.185",
"101.226.100.186"
]
}
}
}
]
}

オブジェクトの最新バージョンまたは指定されたバージョンへのアクセスのみを許可(cos:versionid)

リクエストパラメータ versionid

リクエストパラメータversionidはオブジェクトのバージョン番号を表します。バージョン管理に関する内容は、バージョン管理の概要をご参照ください。オブジェクトのダウンロード(GetObject)、オブジェクトの削除(DeleteObject)の際に、リクエストパラメータversionidを使用して、アクションを行いたいオブジェクトのバージョンを指定することができます。
versionidが含まれないリクエストパラメータの場合、リクエストはデフォルトでオブジェクトの最新バージョンに作用します。
versionidリクエストパラメータを空の文字列にすると、versionidが含まれないリクエストパラメータの場合と同じになります。
versionidリクエストパラメータが文字列"null"の場合、あるバケットにバージョン管理を有効にする前にオブジェクトをアップロードし、その後バージョン管理を有効にすると、それらのオブジェクトのバージョン番号はすべて文字列"null"となります。

条件キー cos:versionid

条件キーcos:versionidはリクエストパラメータversionidの制限に用いられます。

事例1:指定されたバージョン番号のオブジェクトの取得のみをユーザーに許可する

ルートアカウント(uin:100000000001)がバケットexamplebucket-1250000000を所有し、そのサブユーザー(uin:100000000002)に対し権限承認を行い、指定されたバージョン番号のオブジェクトの取得のみをサブユーザーに許可する必要があるとします。
次のバケットポリシーを採用した後、サブユーザー(uin:100000000002)がオブジェクトダウンロードリクエストを送信した場合、versionidパラメータが含まれ、なおかつversionidの値がバージョン番号「MTg0NDUxNTc1NjIzMTQ1MDAwODg」である場合にのみ、リクエストが成功します。
{
"version":"2.0",
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"name/cos:GetObject"
],
"condition":{
"string_equal":{
"cos:versionid":"MTg0NDUxNTc1NjIzMTQ1MDAwODg"
}
},
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
]
}
]
}

明示的な拒否の追加

上記のポリシーを使用してサブユーザーへの権限承認を行う場合、サブユーザーが他の手段によって何の条件もない同一の権限を取得しているために、より広範囲の権限が発効する可能性があります。例えば、サブユーザーがあるユーザーグループに所属しており、ルートアカウントがユーザーグループにGetObject権限を与え、それに何の条件も付け加えなかった場合、上記のポリシーはバージョン番号に対する制限の役割を発揮しません。
このような状況に対応するため、上記のポリシーをベースにした上で、明示的な拒否のポリシー(deny)を追加することで、より厳格な権限制限を行うことができます。下記におけるこのdenyポリシーは、サブユーザーがオブジェクトダウンロードリクエストを送信する際に、 versionidパラメータを含めなかった場合、またはversionidのバージョン番号が「MTg0NDUxNTc1NjIzMTQ1MDAwODg」ではなかった場合に、そのリクエストは拒否されることを意味します。denyの優先順位は他のポリシーより高いため、明示的な拒否の追加によって、権限の脆弱性を最も高いレベルで回避することができます。
{
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"name/cos:GetObject"
],
"condition":{
"string_equal":{
"cos:versionid":"MTg0NDUxNTc1NjIzMTQ1MDAwODg"
}
},
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
]
},
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"deny",
"action":[
"name/cos:GetObject"
],
"condition":{
"string_not_equal_if_exist":{
"cos:versionid":"MTg0NDUxNTc1NjIzMTQ1MDAwODg"
}
},
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
]
}
],
"version":"2.0"
}

事例2:最新バージョンのオブジェクトの取得のみをユーザーに許可する

ルートアカウント(uin:100000000001)がバケットexamplebucket-1250000000を所有し、そのサブユーザー(uin:100000000002)が最新バージョンのオブジェクトのみを取得できるように制限する必要があるとします。
リクエストパラメータversionidが含まれない場合、またはversionidが空の文字列の場合、GetObjectはデフォルトで最新バージョンのオブジェクトを取得します。このため、条件の中でstring_equal_if_existを使用することができます。
1. versionidが含まれない場合は、デフォルトでtrueとして処理し、allow条件にヒットすれば、リクエストはallowされます。
2. リクエストパラメータversionidが空、すなわち“”の場合も同様にallowポリシーにヒットし、最新バージョンのオブジェクト取得に対するリクエストのみ権限が承認されます。
"condition":{
"string_equal_if_exist":{
"cos:versionid": ""
}
}
明示的な拒否を追加した、完全なバケットポリシーは次のようになります。
{
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"name/cos:GetObject"
],
"condition":{
"string_equal_if_exist":{
"cos:versionid":""
}
},
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
]
},
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"deny",
"action":[
"name/cos:GetObject"
],
"condition":{
"string_not_equal":{
"cos:versionid":""
}
},
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
]
}
],
"version":"2.0"
}

事例3:バージョン管理の有効化前にアップロードしたオブジェクトの削除をユーザーに許可しない

バージョン管理を有効化する前に、一部のオブジェクトがバケットにアップロードされている可能性があり、それらのオブジェクトのバージョン番号は“null”となります。これらのオブジェクトに対しては、場合によっては追加の保護を有効化する必要があります。例えば、ユーザーに対しこれらのオブジェクトの完全削除操作を禁止する、すなわちバージョン番号があるものの削除操作を拒否するなどです。
次に挙げるこのバケットポリシーの例には、2つのポリシーが含まれます。
1. DeleteObjectリクエストを使用してバケット内のオブジェクトを削除する権限をサブユーザーに承認します。
2. DeleteObjectリクエストの発効条件を制限しています。DeleteObjectリクエストにリクエストパラメータversionidが含まれ、なおかつversionidが「null」の場合は、このDeleteObjectリクエストを拒否します。
このため、バケットexamplebucket-1250000000に先にオブジェクトAをアップロードし、その後バケットのバージョン管理を有効化した場合、オブジェクトAのバージョン番号は文字列の「null」となります。
このバケットポリシーを追加すると、オブジェクトAは保護されます。サブユーザーがオブジェクトAに対しDeleteObjectリクエストを送信し、リクエストにバージョン番号が含まれていない場合、バージョン管理を有効化しているため、オブジェクトA自体は完全削除されず、削除マーカーだけが付与されます。リクエストにAのバージョン番号「null」が含まれていた場合、このリクエストは拒否され、オブジェクトAは完全削除されることなく保護されます。
{
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"name/cos:DeleteObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
]
},
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"deny",
"action":[
"name/cos:DeleteObject"
],
"condition":{
"string_equal":{
"cos:versionid":"null"
}
},
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
]
}
],
"version":"2.0"
}

アップロードファイルサイズの制限(cos:content-length)

リクエストヘッダーContent-Length

RFC 2616で定義されたHTTPリクエストのコンテンツの長さ(バイト)です。PUTおよびPOSTリクエストで頻繁に使用されます。詳細については、リクエストヘッダーリストをご参照ください

条件キーcos:content-length

オブジェクトをアップロードする際、条件キーcos:content-lengthによってリクエストヘッダーContent-Lengthを制限することができます。それによりアップロードするオブジェクトのファイルサイズを制限することで、ストレージスペースをより柔軟に管理し、大きすぎるファイルや小さすぎるファイルのアップロードによる、ストレージスペースやネットワーク帯域幅の浪費防止に役立ちます。
下記の2つの例では、ルートアカウント(uin:100000000001)がバケットexamplebucket-1250000000を所有している場合、cos:content-length条件キーによってサブユーザー(uin:100000000002)のアップロードリクエストのContent-Lengthヘッダーのサイズを制限することができます。

事例1: リクエストヘッダーContent-Lengthの最大値を制限する

PutObjectおよびPostObjectのアップロードリクエストには必ずContent-Lengthヘッダーが含まれなければならず、かつこのヘッダーの値を10バイト以下とするよう制限します。
{
"version":"2.0",
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"name/cos:PutObject",
"name/cos:PostObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"numeric_less_than_equal":{
"cos:content-length":10
}
}
},
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"deny",
"action":[
"name/cos:PutObject",
"name/cos:PostObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"numeric_greater_than_if_exist":{
"cos:content-length":10
}
}
}
]
}

事例2: リクエストヘッダーContent-Lengthの最小値を制限する

PutObjectおよびPostObjectのアップロードリクエストには必ずContent-Lengthヘッダーが含まれなければならず、かつContent-Lengthの値を2バイト以上とするよう制限します。
{
"version":"2.0",
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"name/cos:PutObject",
"name/cos:PostObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"numeric_greater_than_equal":{
"cos:content-length":2
}
}
},
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"deny",
"action":[
"name/cos:PutObject",
"name/cos:PostObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"numeric_less_than_if_exist":{
"cos:content-length":2
}
}
}
]
}

アップロードファイルタイプの制限(cos:content-type)

リクエストヘッダーContent-Type

RFC 2616で定義されたHTTPリクエストのコンテンツタイプ(MIME)であり、例えばapplication/xmlimage/jpegなどです。詳細については、リクエストヘッダーリストをご参照ください。

条件キーcos:content-type

条件キーcos:content-typeを使用すると、リクエストのContent-Typeヘッダーを制限することができます。

事例: オブジェクトのアップロード(PutObject)のContent-Typeを必ず「image/jpeg」とするよう限定する

ルートアカウント(uin:100000000001)がバケットexamplebucket-1250000000を所有している場合、cos:content-type条件キーによってサブユーザー(uin:100000000002)のアップロードリクエストのContent-Typeヘッダーの具体的な内容を制限することができます。
以下のこのバケットポリシーの意味は、PutObjectを使用してオブジェクトをアップロードする場合に、必ずContent-Typeヘッダーを含め、かつContent-Typeの値を「image/jpeg」とするよう制限するものです。
注意すべきは、string_equalはリクエストに必ずContent-Typeヘッダーを含め、なおかつContent-Typeの値が規定値と完全に一致することを要求するという点です。実際のリクエストでは、リクエストのContent-Typeヘッダーを明確に指定する必要があります。それを行わず、リクエストにContent-Typegヘッダーが含まれない場合、リクエストは失敗します。また、何らかのツールを使用してリクエストを送信し、Content-Typeを明確に指定しなかった場合、ツールが想定と異なるContent-Typeヘッダーを自動的に追加する可能性があり、この場合もリクエストの失敗につながる可能性があります。
また、大文字と小文字を区別しない条件演算子string_equal_ignore_casestring_not_equal_ignore_caseの使用を推奨します。その理由はstring_equalstring_not_equalを使用した場合、text/htmlタイプのアップロードを禁止する目的であっても、 Content-Typeをtext/HtmltExt/htmlに設定した場合に厳密な制限ができないからです。大文字と小文字を区別しない演算子を使用すれば、より厳密な制限が可能です。詳細については、条件演算子 をご参照ください。
{
"version":"2.0",
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"name/cos:PutObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"string_equal_ignore_case":{
"cos:content-type":"image/jpeg"
}
}
},
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"deny",
"action":[
"name/cos:PutObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"string_not_equal_ignore_case_if_exist":{
"cos:content-type":"image/jpeg"
}
}
}
]
}

ダウンロードリクエストに返されるファイルタイプの制限(cos:response-content-type)

リクエストパラメータresponse-content-type

GetObjectインターフェースは、リクエストパラメータresponse-content-typeを追加し、レスポンスのContent-Typeヘッダーの値を設定するために用いることができます。

条件キーcos:response-content-type

条件キーcos:response-content-typeを使用すると、リクエストにリクエストパラメータresponse-content-typeのパラメータ値を必ず含めるかどうかを制限することができます。

事例: Get Objectのリクエストパラメータresponse-content-typeを必ず「image/jpeg」とするよう限定する

ルートアカウント(uin:100000000001)がバケットexamplebucket-1250000000を所有している場合、以下のバケットポリシーの意味は、サブユーザー(uin:100000000002)のGet Objectリクエストに必ずリクエストパラメータresponse-content-typeを含め、かつリクエストパラメータの値を必ず「image/jpeg」とするよう制限するものです。response-content-typeはリクエストパラメータであるため、リクエストの送信時にurlencodeを経る必要があり、response-content-type=image%2Fjpegとなります。そのため、Policyを設定する際は、「image/jpeg」にもurlencodeを行って「image%2Fjpeg」と入力する必要があります。
{
"version":"2.0",
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"name/cos:GetObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"string_equal":{
"cos:response-content-type":"image%2Fjpeg"
}
}
},
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"deny",
"action":[
"name/cos:GetObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"string_not_equal_if_exist":{
"cos:response-content-type":"image%2Fjpeg"
}
}
}
]
}

HTTPSプロトコルを使用したリクエストのみ承認する(cos:secure-transport)

条件キーcos:secure-transport

条件キーcos:secure-transportを使用して、リクエストが必ずHTTPSプロトコルを使用するよう制限することができます。

事例1:ダウンロードリクエストにHTTPSプロトコルの使用を必須とする

ルートアカウント(uin:100000000001)がバケットexamplebucket-1250000000を所有している場合、以下のバケットポリシーの意味は、サブユーザー(uin:100000000002)からのHTTPSプロトコルを使用したGetObjectリクエストに対してのみ権限承認を行うことを表します。
{
"version":"2.0",
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"name/cos:GetObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"bool_equal":{
"cos:secure-transport":"true"
}
}
}
]
}

事例2:HTTPSプロトコルを使用していないあらゆるリクエストを拒否する

ルートアカウント(uin:100000000001)がバケットexamplebucket-1250000000を所有している場合、以下のバケットポリシーの意味は、サブユーザー(uin:100000000002)からの、HTTPSプロトコルを使用していないあらゆるリクエストを拒否することを表します。
{
"version":"2.0",
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"deny",
"action":[
"*"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"bool_equal":{
"cos:secure-transport":"false"
}
}
}
]
}

指定されたストレージタイプの設定のみを許可(cos:x-cos-storage-class)

リクエストヘッダーx-cos-storage-class

ユーザーはリクエストヘッダーx-cos-storage-classによって、オブジェクトをアップロードする際にストレージタイプを指定したり、オブジェクトのストレージタイプを変更したりすることができます。

条件キーcos:x-cos-storage-class

条件キーcos:x-cos-storage-classによって、リクエストヘッダーx-cos-storage-classを制限し、それによりストレージタイプを変更する可能性のあるリクエストを制限することができます。
COSのストレージタイプフィールドには、STANDARDMAZ_STANDARD, STANDARD_IAMAZ_STANDARD_IAINTELLIGENT_TIERINGMAZ_INTELLIGENT_TIERINGARCHIVEDEEP_ARCHIVEがあります。

事例:PutObjectの際にストレージタイプを必ず標準タイプに設定するよう要求する

ルートアカウント(uin:100000000001)がバケットexamplebucket-1250000000を所有している場合、バケットポリシーによって、サブユーザー(uin:100000000002)からのPutObjectリクエストには必ずx-cos-storage-classヘッダーを含めなければならず、かつヘッダー値はSTANDARDとするよう制限します。
{
"version":"2.0",
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"name/cos:PutObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"string_equal":{
"cos:x-cos-storage-class":"STANDARD"
}
}
},
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"deny",
"action":[
"name/cos:PutObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"string_not_equal_if_exist":{
"cos:x-cos-storage-class":"STANDARD"
}
}
}
]
}

指定されたバケット/オブジェクトACLの設定のみを許可(cos:x-cos-acl)

リクエストヘッダーx-cos-acl

リクエストヘッダーx-cos-aclを使用すると、オブジェクトのアップロード、バケットの作成時にアクセス制御リスト(ACL)を指定するか、またはオブジェクト、バケットACLを変更することができます。ACLに関する説明については、ACLの概要をご参照ください。
バケットのプリセットACL:privatepublic-readpublic-read-writeauthenticated-read
オブジェクトのプリセットACL:defaultprivatepublic-readauthenticated-readbucket-owner-readbucket-owner-full-control

条件キーcos:x-cos-acl

条件キーcos:x-cos-aclによって、リクエストヘッダーx-cos-aclを制限し、それによりオブジェクトまたはバケットACLを変更する可能性のあるリクエストを制限することができます。

事例:PutObjectの際に必ず同時にオブジェクトのACLをプライベートに設定する

ルートアカウント(uin:100000000001)がバケットexamplebucket-1250000000を所有し、サブユーザー(uin:100000000002)にプライベートオブジェクトのみをアップロードできるよう制限する必要があるとします。以下のポリシーによって、PutObjectリクエストの送信時に必ずx-cos-aclヘッダーを含め、かつヘッダー値をprivateとするよう要求します。
{
"version":"2.0",
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"name/cos:PutObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"string_equal":{
"cos:x-cos-acl":"private"
}
}
},
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"deny",
"action":[
"name/cos:PutObject"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"string_not_equal_if_exist":{
"cos:x-cos-acl":"private"
}
}
}
]
}

指定ディレクトリ下のオブジェクトのリストアップのみを許可する(cos:prefix)

条件キーcos:prefix

条件キーcos:prefixによってリクエストパラメータprefixを制限することができます。
注意:
prefixの値が特殊文字(中国語、/など)の場合は、バケットポリシーに書き込む前にurlencodeを経る必要があります。

事例:バケットの指定ディレクトリ下のオブジェクトのリストアップのみを許可する

ルートアカウント(uin:100000000001)がバケットexamplebucket-1250000000を所有し、サブユーザー(uin:100000000002)にバケットのfolder1ディレクトリ下のオブジェクトのみをリストアップできるよう制限する必要があるとします。以下のストレージバケットポリシーでは、サブユーザーがGetBucketリクエストを行う際、必ずprefixパラメータを含み、その値をfolder1/である必要があります。prefixの値には特殊文字/が含まれるため、バケットポリシーに記述する前にurlencodeする必要があります。したがって、ポリシー内の記述はfolder1%2Fとなります。
{
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"name/cos:GetBucket"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"string_equal":{
"cos:prefix":"folder1%2F"
}
}
},
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"deny",
"action":[
"name/cos:GetBucket"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"string_not_equal_if_exist":{
"cos:prefix":"folder1%2F"
}
}
}
],
"version":"2.0"
}

指定されたバージョンのTLSプロトコルの使用のみを許可(cos:tls-version)

条件キー cos:tls-version

条件キーcos:tls-versionによってHTTPSリクエストのTLSバージョンを制限することができます。この条件キーはNumricタイプであり、1.0、1.1、1.2などの浮動小数点数の入力が可能です。

事例1:TLSプロトコルのバージョンが1.2であるHTTPSリクエストにのみ権限を承認する

リクエストのシナリオ
予測
HTTPSリクエスト、TLSバージョンは1.0
403、失敗
HTTPSリクエスト、TLSバージョンは1.2
200、成功
ポリシーの例は次のとおりです。
{
"version":"2.0",
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"*"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"numeric_equal":{
"cos:tls-version":1.2
}
}
}
]
}

事例2:TLSプロトコルのバージョンが1.2より低いHTTPSリクエストを拒否する

リクエストのシナリオ
予測
HTTPSリクエスト、TLSバージョンは1.0
403、失敗
HTTPSリクエスト、TLSバージョンは1.2
200、成功
ポリシーの例は次のとおりです。
{
"version":"2.0",
"statement":[
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"allow",
"action":[
"*"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"numeric_greater_than_equal":{
"cos:tls-version":1.2
}
}
},
{
"principal":{
"qcs":[
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect":"deny",
"action":[
"*"
],
"resource":[
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition":{
"numeric_less_than_if_exist":{
"cos:tls-version":1.2
}
}
}
]
}

バケット作成時に指定のバケットタグを強制的に設定(qcs:request_tag)

説明:
条件キーrequest_tagはPutBucket、PutBucketTagging操作にのみ適用可能です。GetService、PutObject、PutObjectTaggingなどの操作はこの条件キーをサポートしていません。

条件キー qcs:request_tag

条件キーqcs:request_tagによって、ユーザーがPutBucket、PutBucketTaggingリクエストを送信する際に、必ず指定したバケットタグを含めるよう制限することができます。

事例:ユーザーのバケット作成時に必ず指定したバケットタグを含めるよう制限する

多くのユーザーはバケットタグによってバケットを管理しています。次のポリシーの例は、ユーザーがバケットを作成する際、指定のバケットタグ<a,b>および<c,d>を設定した場合にのみ権限を取得できるよう制限するものです。
バケットタグは複数設定することができ、バケットタグのキー値、タグの数が異なると、それらはすべて異なるセットとなります。ユーザーの持つ複数のパラメータ値をセットA、条件で規定する複数のパラメータ値をセットBと仮定します。この条件キーを使用する際、限定語for_any_value、for_all_valueの組み合わせによって異なる意味を表すことができます。
for_any_value:string_equalはAとBに共通部分が存在する場合に発効することを表します。
for_any_value:string_equalはAがBのサブセットである場合に発効することを表します。
for_any_value:string_equalを使用する場合、対応するポリシーとリクエストは次のように表されます。
リクエストのシナリオ
予測
PutBucket、リクエストヘッダーx-cos-tagging: a=b&c=d
200、成功
PutBucket、リクエストヘッダーx-cos-tagging: a=b
200、成功
PutBucket、リクエストヘッダーx-cos-tagging: a=b&c=d&e=f
200、成功
ポリシーの例は次のとおりです。
{
"version": "2.0",
"statement":[
{
"principal":{
"qcs": [
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect": "allow",
"action":[
"name/cos:PutBucket"
],
"resource": "*",
"condition":{
"for_any_value:string_equal":{
"qcs:request_tag": [
"a&b",
"c&d"
]
}
}
}
]
}
for_all_value:string_equalを使用する場合、対応するポリシーとリクエストは次のように表されます。
リクエストのシナリオ
予測
PutBucket、リクエストヘッダーx-cos-tagging: a=b&c=d
200、成功
PutBucket、リクエストヘッダーx-cos-tagging: a=b
200、成功
PutBucket、リクエストヘッダーx-cos-tagging: a=b&c=d&e=f
403、失敗
ポリシーの例は次のとおりです。
{
"version": "2.0",
"statement":[
{
"principal":{
"qcs": [
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect": "allow",
"action":[
"name/cos:PutBucket"
],
"resource": "*",
"condition":{
"for_all_value:string_equal": {
"qcs:request_tag": [
"a&b",
"c&d"
]
}
}
}
]
}

ファイルアップロード時にファイルの上書きを禁止するリクエストヘッダー(cos:x-cos-forbid-overwrite)を含めることの必須化を強制する

条件キーcos:x-cos-forbid-overwrite

条件キーcos:x-cos-forbid-overwriteを使用すると、アップロードリクエスト(PutObject、PutObject-Copy、InitiateMultipartUpload、CompleteMultipartUpload)にリクエストヘッダーx-cos-forbid-overwriteを含めることの必須化を制限することで、既存のオブジェクトを上書きする可能性があるリクエストを厳格に禁止することができます。

例:ファイルアップロードリクエストでは、x-cos-forbid-overwriteをtrueに設定する必要がある

メインアカウント(uin:100000000001)がバケットexamplebucket-1250000000を有しており、サブユーザー(uin:100000000002)に対して、同名の既存オブジェクトを上書きできないように制限する場合、以下のポリシーを設定します。このポリシーでは、サブユーザーがアップロードリクエスト(PutObject、PutObject-Copy、InitiateMultipartUpload、CompleteMultipartUpload)を行う際、必ずヘッダーx-cos-forbid-overwriteを付与し、その値が文字列trueである必要があります。
{
"version": "2.0",
"statement": [{
"principal": {
"qcs": [
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect": "allow",
"action": [
"name/cos:PutObject"
],
"resource": [
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition": {
"string_equal": {
"cos:x-cos-forbid-overwrite": "true"
}
}
},
{
"principal": {
"qcs": [
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect": "deny",
"action": [
"name/cos:PutObject"
],
"resource": [
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition": {
"string_not_equal_if_exist": {
"cos:x-cos-forbid-overwrite": "true"
}
}
}
]
}

リクエストのアクセスドメインを制限する(cos:host)

条件キーcos:host

条件キーcos:hostを使用することで、ユーザーリクエストのHostヘッダーを制限し、アクセスできるドメインを制御することが可能です。

例1:ユーザーが指定したドメイン経由でCOSにアクセスすることを禁止する

以下のポリシーは、ユーザーがデフォルトドメインexamplebucket-1250000000.cos.ap-guangzhou.myqcloud.comを介してCOSにアクセスすることを禁止し、他のドメインを使用してアクセスすることは許可されるという内容です。
{
"version": "2.0",
"statement": [{
"principal": {
"qcs": [
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect": "deny",
"action": [
"*"
],
"resource": [
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition": {
"string_equal": {
"cos:host": "examplebucket-1250000000.cos.ap-guangzhou.myqcloud.com"
}
}
},
{
"principal": {
"qcs": [
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect": "allow",
"action": [
"*"
],
"resource": [
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/*"
],
"condition": {
"string_not_equal": {
"cos:host": "examplebucket-1250000000.cos.ap-guangzhou.myqcloud.com"
}
}
}
]
}

例2:ユーザーがカスタムドメイン経由でのみオブジェクトをダウンロードできるように制限する

以下のポリシーは、ユーザーがカスタムドメインmydomain1.comを使用して、バケット内のディレクトリfolder1からのみオブジェクト(GetObject)をダウンロードできるように制限するという内容です。
{
"version": "2.0",
"statement": [{
"principal": {
"qcs": [
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect": "allow",
"action": [
"name/cos:GetObject"
],
"resource": [
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/folder1/*"
],
"condition": {
"string_equal": {
"cos:host": "mydomain1.com"
}
}
},
{
"principal": {
"qcs": [
"qcs::cam::uin/100000000001:uin/100000000002"
]
},
"effect": "deny",
"action": [
"name/cos:GetObject"
],
"resource": [
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-1250000000/folder1/*"
],
"condition": {
"string_not_equal": {
"cos:host": "mydomain1.com"
}
}
}
]
}

オブジェクトロックのモードを制限する(cos:object-lock-mode)

条件キーcos:object-lock-mode

条件キーcos:object-lock-modeを使用することで、ユーザーがオブジェクトをアップロードする際に必ずオブジェクトロックを設定し、指定したロックモードを使用するように制限できます。

例:ユーザーにCOMPLIANCEモードの設定のみを許可する

{
"statement": [
{
"action": [
"name/cos:PutObject",
"name/cos:InitiateMultipartUpload",
"name/cos:PutObjectRetention"
],
"effect": "allow",
"principal": {
"qcs": [
"qcs::cam::uin/1250000000:uin/1250000001"
]
},
"resource": [
"qcs::cos:ap-beijing:uid/1250000000:bjtest-1250000000/*"
],
"condition": {
"string_equal": {
"cos:object-lock-mode": "COMPLIANCE"
}
}
}
],
"version": "2.0"
}

オブジェクトのロック日数を制限する(cos:object-lock-remaining-retention-days)

条件キーcos:object-lock-remaining-retention-days

条件キーcos:object-lock-remaining-retention-daysを使用することで、ユーザーがオブジェクトをアップロードする際に必ずオブジェクトロックを設定し、一定のロック日数を設定するように制限できます。
ロック日数の判定ロジック
この条件キーで指定できる値は整数のみ(仮にAとする)です。実際のリクエストにおけるretain-until-dateのタイムスタンプをts1(秒)、現在時刻のタイムスタンプをts2(秒)とし、ロック日数(仮にBとする)は次の式で計算されます。
ロック日数(B)= 切り捨て[(ts1 - ts2)/(3600*24)]
例1:retain-until-dateが2022-11-17T10:10:11、現在時刻が2022-11-15T09:00:00の場合、ロック日数(B)は2となります。
例2:retain-until-dateが2022-11-17T10:10:11、現在時刻が2022-11-15T12:00:00の場合、ロック日数(B)は1となります。
条件を満たしているかどうかは、指定値Aと算出値Bの大小を比較することで判断されます。

例:PutObjectによるアップロード時、オブジェクトのロック日数はN日を超える必要がある

例えば、ロックの残り日数が3日(3日を含まない)を超えなければならないと制限するなど。
説明:
条件キーで指定された残り日数は3日を超える、つまり4日以上である必要があります。リクエスト時刻が2022年10月1日16:00:00である場合、ユーザーがリクエストで指定するRetainUntilDateは2022年10月5日16:00:00以降でなければなりません。
{
"statement": [
{
"action": [
"name/cos:PutObject",
"name/cos:InitiateMultipartUpload",
"name/cos:PutObjectRetention"
],
"effect": "allow",
"principal": {
"qcs": [
"qcs::cam::uin/1250000000:uin/1250000001"
]
},
"resource": [
"qcs::cos:ap-beijing:uid/1250000000:bjtest-1250000000/*"
],
"condition": {
"numeric_greater_than": {
"cos:object-lock-remaining-retention-days": 3
}
}
}
],
"version": "2.0"
}
異なる条件演算子を使用すると、RetainUntilDateの有効な設例は以下の通りです。
条件キー
意味
リクエスト時の現在時刻
入力パラメータ:retain-until-dateの有効な日時
備考
"numeric_equal":
{
"cos: x-cos-object-lock-remaining-retention-days": 3
}
3日に等しい
2022-11-01T12:00:00Z
[ 2022-11-04T12:00:00Z, 2022-11-05T11:59:59Z ]
閉区間
"numeric_greater_than":
{
"cos: x-cos-object-lock-remaining-retention-days": 3
}
3日より大きい(3日を含まない)
2022-11-01T12:00:00Z
[ 2022-11-05T12:00:00Z, 以降 ]
閉区間
"numeric_less_than":
{
"cos: x-cos-object-lock-remaining-retention-days": 3
}
3日未満(3日を含まない)
2022-11-01T12:00:00Z
[ 2022-11-01T12:00:01Z, 2022-11-04T11:59:59Z ]
閉区間

オブジェクトのロック期限に基づくアクセス制御(cos:object-lock-retain-until-date)

条件キーcos:object-lock-retain-until-date

条件キーcos:object-lock-retain-until-dateを使用することで、ユーザーがオブジェクトをアップロードする際に必ずオブジェクトロックを設定し、秒単位で指定された保持期限を設定するように制限することができます。

例:PutObjectによるアップロード時に、指定されたロック期限を制限する

以下のリクエストは、RetainUntilDateを2022-11-11T12:00:00Zより後に設定する必要があることを示しています。
{
"statement": [
{
"action": [
"name/cos:PutObject",
"name/cos:InitiateMultipartUpload",
"name/cos:PutObjectRetention"
],
"effect": "allow",
"principal": {
"qcs": [
"qcs::cam::uin/1250000000:uin/1250000001"
]
},
"resource": [
"qcs::cos:ap-beijing:uid/1250000000:bjtest-1250000000/*"
],
"condition": {
"date_greater_than": {
"cos:object-lock-retain-until-date": "2022-11-11T12:00:00Z"
}
}
}
],
"version": "2.0"
}

リクエストに含まれるACL権限ヘッダーを制限する

条件キー

リクエストヘッダーx-cos-grant-full-control、x-cos-grant-read、x-cos-grant-write、x-cos-grant-read-acp、x-cos-grant-write-acpは、オブジェクトのアップロード、オブジェクトのコピー、オブジェクトACLの変更リクエスト時に使用され、ACL権限情報を指定するために利用されます。詳細は PutObjectのリクエストヘッダー をご参照ください。以下の表に示すように、各条件キーは、対象ヘッダーの有無や値の内容を制御するために使用できます。
条件キー
対応リクエストヘッダー
cos:x-cos-grant-full-control
x-cos-grant-full-control
cos:x-cos-grant-read
x-cos-grant-read
cos:x-cos-grant-write
x-cos-grant-write
cos:x-cos-grant-read-acp
x-cos-grant-read-acp
cos:x-cos-grant-write-acp
x-cos-grant-write-acp
以下は、cos:x-cos-grant-full-controlを例に、ACL権限関連ヘッダーの制御方法を示します。他の条件キーの使用方法も同様です。この種の条件キーには主に2つの利用ケースがあります:
このヘッダーが特定のアカウントへの権限付与にのみ使用されるように制限するケース。詳細は 例1 をご参照ください。
このヘッダーを使用して一切の権限付与を禁止し、一部のユーザーが PutObject権限を悪用してオブジェクトのACL権限を改ざんすることを防ぐケール。詳細は 例2 をご参照ください。

例1:x-cos-grant-full-controlによる権限付与が可能なアカウントを制限する

以下のポリシーは、サブアカウントに対してオブジェクトのアップロード権限を付与しつつ、アップロード時には必ずx-cos-grant-full-control ヘッダーを含め、その値としてメインアカウント100000000001を指定しなければならないという内容です。x-cos-grant-full-controlヘッダーには"記号が含まれる場合があり、ポリシー記述時には文字列として指定する必要があるため、エスケープ\\"を使用してください。
{
"statement": [{
"action": [
"name/cos:PutObject",
"name/cos:PostObject",
"name/cos:AppendObject",
"name/cos:InitiateMultipartUpload"
],
"effect": "allow",
"principal": {
"qcs": [
"qcs::cam::uin/1250000000:uin/1250000001"
]
},
"resource": [
"qcs::cos:ap-beijing:uid/1250000000:bjtest-1250000000/*"
],
"condition": {
"string_equal": {
"cos:x-cos-grant-full-control": "id=\\"100000000001\\""
}
}
},
{
"action": [
"name/cos:PutObject",
"name/cos:PostObject",
"name/cos:AppendObject",
"name/cos:InitiateMultipartUpload"
],
"effect": "deny",
"principal": {
"qcs": [
"qcs::cam::uin/1250000000:uin/1250000001"
]
},
"resource": [
"qcs::cos:ap-beijing:uid/1250000000:bjtest-1250000000/*"
],
"condition": {
"string_not_equal_if_exist": {
"cos:x-cos-grant-full-control": "id=\\"100000000001\\""
}
}
}
],
"version": "2.0"
}

例2:x-cos-grant-full-controlによる権限付与を禁止する

以下のポリシーは、サブアカウントにオブジェクトのアップロード権限を付与するものの、アップロード時にx-cos-grant-full-controlヘッダーを含めることを禁止するか、このヘッダーの値が空であることのみを許可します。
{
"statement": [{
"action": [
"name/cos:PutObject",
"name/cos:PostObject",
"name/cos:AppendObject",
"name/cos:InitiateMultipartUpload"
],
"effect": "allow",
"principal": {
"qcs": [
"qcs::cam::uin/1250000000:uin/1250000001"
]
},
"resource": [
"qcs::cos:ap-beijing:uid/1250000000:bjtest-1250000000/*"
],
"condition": {
"string_equal_if_exist": {
"cos:x-cos-grant-full-control": ""
}
}
},
{
"action": [
"name/cos:PutObject",
"name/cos:PostObject",
"name/cos:AppendObject",
"name/cos:InitiateMultipartUpload"
],
"effect": "deny",
"principal": {
"qcs": [
"qcs::cam::uin/1250000000:uin/1250000001"
]
},
"resource": [
"qcs::cos:ap-beijing:uid/1250000000:bjtest-1250000000/*"
],
"condition": {
"string_not_equal": {
"cos:x-cos-grant-full-control": ""
}
}
}
],
"version": "2.0"
}


ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック