バケットポリシーは、バケットにアタッチする権限付与ポリシーです。バケットポリシーを使用すると、他の Alibaba Cloud アカウント、RAM ユーザー、または匿名ユーザーにバケットへのアクセス権を付与できます。これにより、クロスアカウント承認、匿名アクセスコントロール、IP アドレスや VPC に基づくアクセス制限を実装できます。
仕組み
バケットポリシーは、リソースベースの認可モデルを使用します。このポリシーはバケットに直接アタッチされ、特定の条件下で、どのプリンシパルがどのリソースに対してどのアクションを実行できるかを定義します。
ユーザーがアクセスリクエストを送信すると、OSS はバケットポリシーと RAM ポリシーを含む、関連するすべてのポリシーを評価します。権限評価は 拒否優先の原則 に従います。明示的な拒否ルールが 1 つでもある場合、リクエストは直ちにブロックされ、すべての許可ルールよりも優先されます。拒否ルールと許可ルールのいずれも存在しない場合、リクエストはデフォルトで拒否されます。
バケットポリシーには、バケット所有者に関する特別なルールがあります:
プリンシパルがワイルドカード文字 (*) に設定され、ポリシーに 条件が含まれない 場合、ポリシーは バケット所有者以外のユーザーにのみ適用 されます。
プリンシパルがワイルドカード文字 (*) に設定され、ポリシーに 条件が含まれる 場合、ポリシーは バケット所有者と匿名ユーザーを含むすべてのユーザーに適用 されます。拒否ルールはバケット所有者にも適用されるため、バケット全体にアクセスできなくなる可能性があります。許可ルールは匿名ユーザーにもアクセスを付与するため、データが公開される可能性があります。
同一ユーザーに対して複数のバケットポリシーのステートメントを設定した場合、ユーザーの権限は、拒否優先の原則 に従い、すべてのステートメントの和集合となります。
acs:SourceIp条件キーは、リクエストのソース IP アドレスのみに一致し、その IP アドレスがパブリックネットワーク由来か VPC 由来かを区別しません。つまり、アクセス制限にacs:SourceIpのみを使用した場合、同じ IP アドレス範囲を使用する別の VPC からのリクエストも許可され、不正アクセスのリスクが生じます。したがって、バケットポリシーを設定する際にacs:SourceIpを指定する場合は、リクエストのネットワークソースを明示的に識別するために、acs:SourceVpcも指定する必要があります。この制約は、新規のバケットポリシーにのみ適用されます。既存のバケットポリシーは影響を受けません。ただし、既存のバケットポリシーを変更する場合は新規の送信として扱われるため、この制約が適用されます。
バケットポリシーの設定
OSS では、さまざまなシナリオに合わせてポリシーを設定するための2つの方法 (グラフィカルメソッドと構文メソッド) を提供しています。
グラフィカルメソッド:一般的な権限付与シナリオ向けに、直感的なフォーム形式の操作を提供し、設定を簡素化します。
構文メソッド:JSON 形式を使用してポリシーを作成します。この方法では、すべての高度な機能と複雑な条件の組み合わせに対応しており、最大限に柔軟な設定が可能です。
グラフィカルメソッド
バケットの一覧に移動し、対象のバケットをクリックします。
左側メニューで、 の順にクリックします。
GUI で追加 を選択し、新規権限 をクリックします。
パラメーター
説明
[関連リソース]
バケット全体 または 指定されたリソース のどちらに権限を付与するかを選択します。
[リソースパス]
関連リソース を バケット全体 に設定した場合、リソースパス は
bucket-name/*に設定されます。関連リソース を 指定されたリソース に設定した場合、権限を付与するディレクトリまたはオブジェクトを入力します。複数の項目を追加できます。
[ユーザー]
権限を付与するプリンシパルを指定します。
[すべてのアカウント (*)]:匿名ユーザーを含む、すべてのユーザーに権限を付与します。
[RAM ユーザー]:現在の Alibaba Cloud アカウントに属する RAM ユーザーを選択します。
現在ログインしているアカウントは、Alibaba Cloud アカウント (ルートアカウント) か、バケットに対する管理権限と RAM コンソールでの
ListUsers権限を持つ RAM ユーザーである必要があります。それ以外の場合、現在のアカウントの RAM ユーザー一覧を表示できません。[他のアカウント]:権限を付与する他のアカウントまたは RAM ユーザーの UID、あるいは
arn:stsで始まる認証情報を持つ一時ユーザー (例:arn:sts::1798************:assumed-role/role-name/session-name) を入力します。複数のユーザーに権限を付与できます。1行につき1ユーザーを入力します。RAM ロールに権限が付与された場合、そのロールを使用して OSS コンソールから権限が付与されたリソースにアクセスすることはできません。ossutil などのコマンドラインツール、SDK、または API を使用してリソースにアクセスする必要があります。
[許可された操作]
[シンプル設定]:一般的な権限付与操作の組み合わせを選択します。オプションには、読み取り専用 (ListObject を除く)、読み取り専用 (ListObject を除く)、[読み取り/書き込み]、フルコントロール、アクセス拒否 があります。
[詳細設定]:効果 (許可する または 拒否) と [アクション] をカスタマイズします。
[条件] (オプション)
ポリシーが有効になる条件を設定します。
[アクセス方法]:オプションには [HTTPS] と [HTTP] があります。オプションを選択すると、ポリシーは選択した方式を使用するアクセスリクエストに対してのみ有効になります。
[IP=]:IP アドレスの一覧を入力します。このオプションを選択すると、ポリシーは指定された IP アドレスからのアクセスリクエストに対してのみ有効になります。
[IP≠]:IP アドレスの一覧を入力します。このオプションを選択すると、ポリシーは指定された IP アドレス以外からのアクセスリクエストに対してのみ有効になります。
[VPC=]:現在のアカウントに属する VPC を選択するか、他のアカウントに属する VPC を入力します。このオプションを選択すると、ポリシーは指定された VPC からのアクセスリクエストに対してのみ有効になります。
[VPC≠]:現在のアカウントに属する VPC を選択するか、他のアカウントに属する VPC を入力します。このオプションを選択すると、ポリシーは指定された VPC 以外からのアクセスリクエストに対してのみ有効になります。
複数の条件を設定した場合、すべての条件を満たす必要があります (AND 条件)。
設定が正しいことを確認したら、[OK] をクリックしてバケットポリシーを適用します。
構文メソッド
バケットの一覧に移動し、対象のバケットをクリックします。
左側メニューで、 の順にクリックします。
構文で追加 を選択し、[編集] をクリックします。エディターで、権限付与ポリシーを JSON 形式で入力します。
ポリシーの例:アクセスリクエストの送信元が VPC
vpc-t4nlw426y44rd3iq4xxxxでない場合、ユーザー20214760404935xxxxによるexample-bucketへのすべての操作を拒否します。{ "Version": "1", "Statement": [ { "Effect": "Deny", "Action": "oss:*", "Principal": [ "20214760404935xxxx" ], "Resource": [ "acs:oss:*:174649585760xxxx:example-bucket", "acs:oss:*:174649585760xxxx:example-bucket/*" ], "Condition": { "StringNotEquals": { "acs:SourceVpc": "vpc-t4nlw426y44rd3iq4xxxx" } } } ] }完全な権限付与ポリシーには、バージョンとステートメントが含まれます。
バージョン:アクセスポリシーのバージョンです。値は
1に固定されており、変更できません。ステートメント:ポリシーの本体です。1つ以上の特定のルールで構成されます。各ルールには、エフェクト、アクション、プリンシパル、リソース、条件が含まれます。
ポリシー要素
説明
例での意味
エフェクト
ポリシーのエフェクト。有効な値は
AllowとDenyです。リクエストを拒否します。
アクション
リソースに対して実行する特定のアクション。ワイルドカード文字
*がサポートされています。すべての OSS アクション (
oss:*) を拒否します。プリンシパル
ポリシーが適用されるユーザー、アカウント、またはロール。
Principal フィールドを空のリスト (
) に設定することは、すべてのアカウント (Principal:[]) に設定することと同じです。Principal:["*"]ポリシーは Alibaba Cloud アカウント
20214760404935xxxxにのみ適用されます。リソース
ポリシーが適用されるリソース。
ポリシーは
example-bucketバケット自体と、バケット内のすべてのオブジェクトに適用されます。条件
ポリシーが有効になる条件。
複数の条件を設定した場合、すべての条件を満たす必要があります (AND 条件)。
この拒否ポリシーは、リクエストの送信元 VPC が
vpc-t4nlw426y44rd3iq4xxxxでない場合にのみ有効になります。ポリシー要素の完全な一覧については、「権限付与の構文と要素」をご参照ください。
権限付与ポリシーが正しいことを確認したら、[保存] をクリックし、画面の指示に従います。
ベクターバケットポリシーの設定
ベクターバケットでは現在、構文によるバケットポリシーの設定のみをサポートしています。
[Vector Buckets] リストに移動し、対象のベクターバケットをクリックします。
左側メニューで、 をクリックします。
[Edit] をクリックします。エディターで、JSON 形式のアクセスポリシーを入力します。
ポリシー例:ユーザー
20816353761158****に対して、vector-bucket-example内のインデックステーブルindextestのベクターデータを読み書きする権限を付与します。{ "Version": "1", "Statement": [{ "Effect": "Allow", "Action": [ "oss:PutVectors", "oss:GetVectors" ], "Principal": [ "20816353761158****" ], "Resource": [ "acs:ossvector:*:*:vector-bucket-example/indextest" ] }] }完全なアクセスポリシーには、Version と ステートメント が含まれます。
Version:アクセスポリシーのバージョンです。値は
1に固定されており、変更できません。ステートメント:ポリシーの本文です。1 つ以上の具体的なルールが含まれます。各ルールには、エフェクト、アクション、プリンシパル、リソース、および 条件 が含まれます。
ポリシー要素
説明
例での意味
エフェクト
ポリシーの効力です。有効な値は
AllowとDenyです。リクエストを 許可 します。
アクション
リソースに対して実行する具体的な操作です。ワイルドカード
*を使用できます。ベクターデータの読み取りと書き込み。
プリンシパル
ポリシーが適用されるユーザー、アカウント、またはロールです。
Principal フィールドを空のリスト(
)に設定することは、すべてのアカウント(Principal:[])に設定することと同じです。Principal:["*"]このポリシーは、RAM ユーザー
20816353761158****にのみ適用されます。リソース
ポリシーが適用されるリソースです。
このポリシーは、
vector-bucket-exampleバケット内のインデックステーブルindextestに適用されます。条件
ポリシーが有効になる条件です。
複数の条件を設定する場合、すべての条件を満たす必要があります(AND 関係)。
なし。
ポリシー要素の一覧については、権限付与の構文と要素 をご参照ください。
アクセスポリシーが正しいことを確認したら、[Save] をクリックし、画面の指示に従ってください。
OSS-HDFS ポリシーの設定
OSS-HDFS サービスのユーザーが .dlsdata/ ディレクトリとそのオブジェクトにアクセスできるようにするため、OSS-HDFS が有効化されたバケットにバケットポリシーを設定する際は、許可対象の操作を[アクセス拒否]に設定しないでください。詳細については、「OSS-HDFSを使用するための前提条件」をご参照ください。
セキュリティ上の理由から、特定のネットワーク IP アドレスまたは VPC へのアクセスを制限する場合は、すべての Deny ステートメントに以下の条件を追加してください。これにより、OSS-HDFS バックエンドサービスがクラシックネットワーク経由でバケットの読み取りと書き込みを行えるようになります。
"StringNotLike": {
"oss:ClassicIntranet": [
"true"
]
}一般的なシナリオ:権限の付与
以下のシナリオでは、バケットポリシーを使用して、特定のユーザー、ロール、またはすべてのユーザーにアクセス権限を付与する方法を示します。各シナリオには、要件に基づいて変更できる完全なポリシー例が含まれています。
シナリオ 1:読み取り/書き込み権限の付与
特定のチームメンバーやパートナーがバケット内のファイルをアップロード、ダウンロード、管理できるようにするには、バケットポリシーを使用して、対応する RAM ユーザーに権限を付与できます。以下の例では、UID が 27737962156157xxxx および 20214760404935xxxx の RAM ユーザーに、example-bucket バケットに対する読み取り/書き込み権限を付与します。
このポリシーでは、RAM ユーザーにバケットをリストする権限を付与していません。そのため、指定された RAM ユーザーは、バケット ページですべてのバケットを表示したり、バケットをクリックして開いたりすることはできません。RAM ユーザーは、コンソールの左側メニューにある に対象のバケットを追加することで、アクセスできます。
{
"Version":"1",
"Statement":[
{
"Effect":"Allow",
"Action":[
"oss:GetObject",
"oss:PutObject",
"oss:GetObjectAcl",
"oss:PutObjectAcl",
"oss:AbortMultipartUpload",
"oss:ListParts",
"oss:RestoreObject",
"oss:GetVodPlaylist",
"oss:PostVodPlaylist",
"oss:PublishRtmpStream",
"oss:ListObjectVersions",
"oss:GetObjectVersion",
"oss:GetObjectVersionAcl",
"oss:RestoreObjectVersion"
],
"Principal":[
"27737962156157xxxx",
"20214760404935xxxx"
],
"Resource":[
"acs:oss:*:174649585760xxxx:example-bucket/*"
]
},
{
"Effect":"Allow",
"Action":[
"oss:ListObjects"
],
"Principal":[
"27737962156157xxxx",
"20214760404935xxxx"
],
"Resource":[
"acs:oss:*:174649585760xxxx:example-bucket"
],
"Condition":{
"StringLike":{
"oss:Prefix":[
"*"
]
}
}
}
]
}シナリオ 2:特定のディレクトリへの読み取り専用権限の付与
バケット内の特定のプロジェクトファイルを変更から保護しながら、プロジェクトメンバーがそれらを読み取れるようにするには、対応する RAM ユーザーに読み取り専用権限を付与できます。以下の例では、UID が 20214760404935xxxx の RAM ユーザーに、example-bucket バケット内の特定のディレクトリ (プレフィックス hangzhou/2020 および shanghai/2015) に対する読み取り専用権限を付与します。
このポリシーでは、RAM ユーザーにバケットをリストする権限を付与していません。そのため、指定された RAM ユーザーは、バケット ページですべてのバケットを表示したり、バケットをクリックして開いたりすることはできません。RAM ユーザーは、コンソールの左側メニューにある に対象のバケットを追加することで、アクセスできます。
{
"Version":"1",
"Statement":[
{
"Action":[
"oss:GetObject",
"oss:GetObjectAcl",
"oss:GetObjectVersion",
"oss:GetObjectVersionAcl"
],
"Effect":"Allow",
"Principal":[
"20214760404935xxxx"
],
"Resource":[
"acs:oss:*:174649585760xxxx:example-bucket/hangzhou/2020/*",
"acs:oss:*:174649585760xxxx:example-bucket/shanghai/2015/*"
]
},
{
"Action":[
"oss:ListObjects",
"oss:ListObjectVersions"
],
"Condition":{
"StringLike":{
"oss:Prefix":[
"hangzhou/2020/",
"shanghai/2015/"
]
}
},
"Effect":"Allow",
"Principal":[
"20214760404935xxxx"
],
"Resource":[
"acs:oss:*:174649585760xxxx:example-bucket"
]
}
]
}シナリオ 3:表示およびリスト権限の付与
特定のチームメンバーやパートナーがバケットに関するすべての情報を表示し、そのオブジェクトをリストできるようにするには、バケットポリシーを使用して、対応する RAM ユーザーに権限を付与できます。以下の例では、RAM ユーザーに、example-bucket バケットに関するすべての情報を表示し、その中のオブジェクトをリストする権限を付与します。
このポリシーでは、RAM ユーザーにバケットをリストする権限を付与していません。そのため、指定された RAM ユーザーは、バケット ページですべてのバケットを表示したり、バケットをクリックして開いたりすることはできません。RAM ユーザーは、コンソールの左側メニューにある に対象のバケットを追加することで、アクセスできます。
{
"Version":"1",
"Statement":[
{
"Action":[
"oss:Get*",
"oss:ListObjects",
"oss:ListObjectVersions"
],
"Effect":"Allow",
"Principal":[
"20214760404935xxxx"
],
"Resource":[
"acs:oss:*:174649585760xxxx:example-bucket"
]
}
]
}シナリオ 4:RAM ロールへの読み取り権限の付与
RAM ユーザーまたはアプリケーションがバケットオブジェクトに一時的にアクセスできるようにするには、RAM ロールを作成し、必要な権限を付与できます。RAM ユーザーまたはアプリケーションは、ロールを引き受けることで一時的なアクセス認証情報を取得し、バケットオブジェクトを読み取ることができます。以下の例では、1 つの RAM ロール配下のすべてのセッションと、別の RAM ロール配下の特定のセッションに、example-bucket バケット内のすべてのオブジェクトを読み取る権限を付与します。
Principal は次の形式に従う必要があります: arn:sts::<uid>:assumed-role/<role-name>/<session-name>。 <role-name> と <session-name> の値は大文字と小文字が区別されます。
{
"Version": "1",
"Statement": [
{
"Action": [
"oss:GetObject"
],
"Effect": "Allow",
"Principal": [
"arn:sts::10323xxxxx72056:assumed-role/role-name/session-name",
"arn:sts::10323xxxxx72056:assumed-role/role2-name/*"
],
"Resource": [
"acs:oss:*:10323xxxxx72056:example-bucket/*"
]
}
]
}シナリオ 5:すべてのユーザーへのリスト権限の付与
バケットが公開リソース共有に使用され、すべてのユーザーがオブジェクト名を表示できるようにする一方で、コンテンツへのアクセスは許可しない場合、プリンシパルをワイルドカード (*) に設定できます。次に、プリンシパルにすべてのオブジェクトをリストする権限を付与します。以下の例では、すべてのユーザーに、example-bucket バケット内のすべてのオブジェクトをリストする権限を付与します。
{
"Version":"1",
"Statement":[
{
"Action":[
"oss:ListObjects",
"oss:ListObjectVersions"
],
"Effect":"Allow",
"Principal":[
"*"
],
"Resource":[
"acs:oss:*:174649585760xxxx:example-bucket"
]
}
]
}一般的なシナリオ:ネットワークアクセスの制限
以下のシナリオでは、バケットポリシーを使用して、パブリック IP アドレスや VPC などのネットワークソースに基づいてバケットへのアクセスを制限する方法を示します。IP アドレスまたは VPC に基づいて条件を設定する場合は、acs:SourceIp および acs:SourceVpc 条件キーを使用する必要があります。以下の表では、一般的なネットワーク制限要件、ポリシーのアプローチ、および対応するシナリオについて説明します。これにより、それぞれの違いを理解し、適切な設定を見つけやすくなります。
アクセス元 | ポリシーのアプローチ | シナリオ |
任意の VPC |
| |
特定の VPC |
| |
特定のパブリック IP | ステートメント 1 で指定外の IP アドレスからのパブリックネットワークリクエストを拒否し、ステートメント 2 ですべての VPC リクエストを拒否。 | |
特定の VPC 内の特定の IP アドレス範囲 | ステートメント 1 で指定外の VPC からのリクエストを拒否し、ステートメント 2 で指定された VPC 内の指定外の IP アドレス範囲からのリクエストを拒否。 | |
特定のパブリック IP または特定の VPC | ステートメント 1 で指定外の IP アドレスからのパブリックネットワークリクエストを拒否し、ステートメント 2 で指定外の VPC からの VPC リクエストを拒否。 | |
特定の IP を拒否 (ブラックリスト) | 指定された IP からのリクエストを拒否。制約を満たすため、 |
シナリオ 1:パブリックネットワークアクセスの制限
パブリックネットワークから特定のバケットへのアクセスをブロックするには、acs:SourceVpc 条件キーを含む拒否ステートメントを作成し、そのステートメントをバケットポリシーに追加します。このステートメントは、VPC からではないリクエストをブロックし、すべてのパブリックネットワークアクセスを効果的に拒否します。以下の例では、VPC 外部のすべてのユーザーからの example-bucket バケットへのネットワークアクセスを拒否します。
{
"Version": "1",
"Statement": [
{
"Effect": "Deny",
"Action": "oss:*",
"Principal": [
"*"
],
"Resource": [
"acs:oss:*:174649585760xxxx:example-bucket/*",
"acs:oss:*:174649585760xxxx:example-bucket"
],
"Condition": {
"StringNotLike": {
"acs:SourceVpc": [
"vpc-*"
]
}
}
}
]
}シナリオ 2:特定の VPC へのアクセス制限
バケットへのアクセスを特定の VPC に制限するには、acs:SourceVpc 条件キーを使用してバケットポリシーに拒否ステートメントを作成できます。このステートメントは、他の VPC またはパブリックネットワークからのリクエストをブロックします。以下の例は、ID が t4nlw426y44rd3iq4xxxx である指定された VPC の外部のすべてのユーザーが、example-bucket バケット内のオブジェクトを読み取ることを拒否します。
以下の拒否ステートメントは、プリンシパルがワイルドカード文字 (
*) で、かつ条件が含まれているため、バケットの所有者を含むすべてのユーザーに適用されます。以下の拒否ステートメントはアクセスを制限するだけで、権限を付与しません。プリンシパルに権限が付与されていない場合は、許可ステートメントを追加して必要な権限を付与できます。
{
"Version":"1",
"Statement":[
{
"Effect":"Deny",
"Action":[
"oss:GetObject"
],
"Principal":[
"*"
],
"Resource":[
"acs:oss:*:174649585760xxxx:example-bucket/*"
],
"Condition":{
"StringNotEquals":{
"acs:SourceVpc":[
"vpc-t4nlw426y44rd3iq4xxxx"
]
}
}
}
]
}シナリオ 3:特定のパブリック IP アドレスへのアクセス制限
バケットアクセスを特定のパブリック IP アドレスに制限するには、2 つの拒否ステートメントを作成する必要があります。
ステートメント 1 (指定外の IP アドレスからのパブリックネットワークリクエストを拒否): このステートメントは、
StringNotLike: {"acs:SourceVpc": "vpc-*"}を使用してパブリックネットワークリクエストを識別します (パブリックネットワークリクエストのacs:SourceVpc値はvpc-で始まりません)。次に、NotIpAddress: {"acs:SourceIp": "..."}を使用して、指定された IP アドレス以外からのリクエストを拒否します。両方の条件が満たされた場合にリクエストが拒否されます。ステートメント 2 (すべての VPC リクエストを拒否): このステートメントは、
StringLike: {"acs:SourceVpc": "vpc-*"}を使用して、任意の VPC からのすべてのリクエストを照合して拒否します。目標は、指定されたパブリック IP アドレスからのアクセスのみを許可することです。
これら 2 つの拒否ステートメントをバケットポリシーに追加すると、いずれかのステートメントの条件に一致する場合にリクエストが拒否されます。以下の例では、パブリック IP アドレス 203.0.113.5 を持つユーザーを除くすべてのユーザーからの、example-bucket への読み取りアクセスを拒否します。
以下の拒否ステートメントは、プリンシパルがワイルドカード文字 (
*) で、かつ条件が含まれているため、バケットの所有者を含むすべてのユーザーに適用されます。以下の拒否ステートメントはアクセスを制限するだけで、権限を付与しません。プリンシパルに権限が付与されていない場合は、許可ステートメントを追加して必要な権限を付与できます。
{
"Version": "1",
"Statement": [{
"Effect": "Deny",
"Action": [
"oss:GetObject"
],
"Principal": [
"*"
],
"Resource": [
"acs:oss:*:174649585760xxxx:example-bucket/*"
],
"Condition": {
"NotIpAddress": {
"acs:SourceIp": [
"203.0.113.5"
]
},
"StringNotLike": {
"acs:SourceVpc": [
"vpc-*"
]
}
}
},
{
"Effect": "Deny",
"Action": [
"oss:GetObject"
],
"Principal": [
"*"
],
"Resource": [
"acs:oss:*:174649585760xxxx:example-bucket/*"
],
"Condition": {
"StringLike": {
"acs:SourceVpc": [
"vpc-*"
]
}
}
}
]
}シナリオ 4:VPC 内の IP アドレス範囲へのアクセス制限
特定の VPC 内の特定の IP アドレス範囲へのバケットアクセスを制限するには、2 つの拒否ステートメントを作成する必要があります。
ステートメント 1 (指定された VPC の外部からのすべてのリクエストを拒否): このステートメントは、
StringNotEquals: {"acs:SourceVpc": "..."}を使用して、他の VPC およびパブリックネットワークからのリクエストを拒否します。ステートメント 2 (VPC 内の指定された IP アドレス範囲外からのリクエストを拒否): このステートメントは、
StringEquals: {"acs:SourceVpc": "..."}を使用して指定された VPC からのリクエストを照合し、次にNotIpAddress: {"acs:SourceIp": "..."}を使用して指定された IP アドレス範囲外からのリクエストを拒否します。両方の条件が満たされた場合にリクエストが拒否されます。
これら 2 つの拒否ステートメントをバケットポリシーに追加すると、いずれかのステートメントの条件に一致する場合にリクエストが拒否されます。以下の例では、ID が t4nlw426y44rd3iq4xxxx の VPC 内の IP アドレス範囲 192.168.0.0/16 からのアクセスを除き、example-bucket バケットへのすべての読み取りアクセスを拒否します。
以下の拒否ステートメントは、プリンシパルがワイルドカード文字 (
*) で、かつ条件が含まれているため、バケットの所有者を含むすべてのユーザーに適用されます。以下の拒否ステートメントはアクセスを制限するだけで、権限を付与しません。プリンシパルに権限が付与されていない場合は、許可ステートメントを追加して必要な権限を付与できます。
{
"Version":"1",
"Statement":[
{
"Effect":"Deny",
"Action":[
"oss:GetObject"
],
"Principal":[
"*"
],
"Resource":[
"acs:oss:*:174649585760xxxx:example-bucket/*"
],
"Condition":{
"StringNotEquals":{
"acs:SourceVpc":[
"vpc-t4nlw426y44rd3iq4xxxx"
]
}
}
},
{
"Effect":"Deny",
"Action":[
"oss:GetObject"
],
"Principal":[
"*"
],
"Resource":[
"acs:oss:*:174649585760xxxx:example-bucket/*"
],
"Condition":{
"StringEquals":{
"acs:SourceVpc":[
"vpc-t4nlw426y44rd3iq4xxxx"
]
},
"NotIpAddress":{
"acs:SourceIp":[
"192.168.0.0/16"
]
}
}
}
]
}シナリオ 5:パブリック IP または VPC へのアクセス制限
バケットへのアクセスを特定のパブリック IP アドレスまたは特定の VPC に制限するには、2 つの拒否ステートメントを作成する必要があります。
ステートメント 1 (パブリックネットワークリクエストにおいて、指定外の IP を拒否): このステートメントは、
StringNotLike: {"acs:SourceVpc": "vpc-*"}を使用してパブリックネットワークリクエストを識別し、次にNotIpAddress: {"acs:SourceIp": "..."}を使用して指定外のパブリック IP アドレスからのリクエストを拒否します。両方の条件が満たされた場合にリクエストが拒否されます。VPC リクエストは、acs:SourceVpc値がvpc-で始まるため、このステートメントに一致しません。ステートメント 2 (VPC リクエストにおいて、指定外の VPC を拒否): このステートメントは、
StringLike: {"acs:SourceVpc": "vpc-*"}を使用して VPC リクエストを識別し、次にStringNotEquals: {"acs:SourceVpc": "..."}を使用して指定外の VPC からのリクエストを拒否します。両方の条件が満たされた場合にリクエストが拒否されます。パブリックネットワークリクエストは、acs:SourceVpc値がvpc-で始まらないため、このステートメントに一致しません。
これら 2 つの拒否ステートメントをバケットポリシーに追加すると、いずれかのステートメントの条件に一致する場合にリクエストが拒否されます。以下の例では、パブリック IP アドレス 203.0.113.5 からのアクセス、または ID が t4nlw426y44rd3iq4xxxx の VPC からのアクセスを除き、すべてのユーザーからの example-bucket バケットへの読み取りアクセスを拒否します。
以下の拒否ステートメントは、プリンシパルがワイルドカード文字 (
*) で、かつ条件が含まれているため、バケットの所有者を含むすべてのユーザーに適用されます。以下の拒否ステートメントはアクセスを制限するだけで、権限を付与しません。プリンシパルに権限が付与されていない場合は、許可ステートメントを追加して必要な権限を付与できます。
{
"Version":"1",
"Statement":[
{
"Effect":"Deny",
"Action":[
"oss:GetObject"
],
"Principal":[
"*"
],
"Resource":[
"acs:oss:*:174649585760xxxx:example-bucket/*"
],
"Condition":{
"StringNotLike":{
"acs:SourceVpc":[
"vpc-*"
]
},
"NotIpAddress":{
"acs:SourceIp":[
"203.0.113.5"
]
}
}
},
{
"Effect":"Deny",
"Action":[
"oss:GetObject"
],
"Principal":[
"*"
],
"Resource":[
"acs:oss:*:174649585760xxxx:example-bucket/*"
],
"Condition":{
"StringLike":{
"acs:SourceVpc":[
"vpc-*"
]
},
"StringNotEquals":{
"acs:SourceVpc":[
"vpc-t4nlw426y44rd3iq4xxxx"
]
}
}
}
]
}シナリオ 6:IP ブラックリストの設定
特定の IP アドレスからバケットとそのオブジェクトへのアクセスを拒否するには、IP ブラックリストポリシーを使用できます。バケットポリシーに拒否ステートメントを設定することで、指定された IP アドレスまたは IP アドレス範囲からのすべてのアクセスリクエストをブロックできます。
ポリシー内の StringLike: {"acs:SourceVpc": "*"} は、ワイルドカード文字を使用してすべての値を照合するため、実際には VPC スコープを制限しません。この条件は、acs:SourceIp を指定する場合は acs:SourceVpc も指定する必要があるという制約を満たすためのものです。
以下の拒否ステートメントは、プリンシパルがワイルドカード文字 (
*) で、かつ条件が含まれているため、バケットの所有者を含むすべてのユーザーに適用されます。複数の IP アドレスおよび IP アドレス範囲を設定できます。カンマで区切ってください。
{
"Version": "1",
"Statement": [{
"Effect": "Deny",
"Action": "oss:*",
"Principal": [
"*"
],
"Resource": [
"acs:oss:*:174649585760xxxx:example-bucket/*",
"acs:oss:*:174649585760xxxx:example-bucket"
],
"Condition": {
"IpAddress": {
"acs:SourceIp": [
"101.***.***.100"
]
},
"StringLike": {
"acs:SourceVpc": [
"*"
]
}
}
}]
}一般的なシナリオ:セキュリティコントロール
次のシナリオでは、バケットポリシーを使用して、認証情報の種類の制限、パブリックアクセスの防止、保持ポリシーの制御などのセキュリティポリシーを適用する方法を示します。
Scenario 1: Require temporary credentials for API calls
To require that API calls use temporary access credentials, you can use the acs:AccessId condition key to create a deny statement. This statement blocks access from non-temporary credentials, such as a long-term access key of an Alibaba Cloud account or a RAM user. Access attempts that use non-temporary credentials trigger the deny rule. The following example denies all users who do not use temporary access credentials (starting with TMP. or STS.) from viewing the example-bucket bucket and listing its objects.
{
"Version": "1",
"Statement": [
{
"Effect": "Deny",
"Action":[
"oss:Get*",
"oss:ListObjects",
"oss:ListObjectVersions"
],
"Principal":[
"*"
],
"Resource":[
"acs:oss:*:174649585760xxxx:example-bucket/*"
],
"Condition": {
"StringNotLike": {
"acs:AccessId": [
"TMP.*",
"STS.*"
]
}
}
}
]
}シナリオ2:パブリック ACLの禁止
バケットおよびオブジェクトの ACL がパブリックに設定されないようにするには、2 つの拒否ステートメントを作成します:
oss:x-oss-acl条件キーを使用して、バケット ACL をプライベート以外の権限に設定できないようにする拒否ステートメントを作成します。public-read または public-read-write ACL を設定しようとする操作は、拒否ルールをトリガーします。oss:x-oss-object-acl条件キーを使用して、オブジェクト ACL をプライベートおよびdefault以外の権限に設定できないようにする拒否ステートメントを作成します。
これら 2 つの拒否ステートメントをバケットポリシーに追加すると、いずれかのステートメントの条件に一致するリクエストは拒否されます。次の例では、example-bucket バケットに対してパブリックアクセス ACL を設定する操作を拒否します。
{
"Version": "1",
"Statement": [
{
"Effect": "Deny",
"Action": [
"oss:PutBucketAcl"
],
"Principal": [
"*"
],
"Resource": [
"acs:oss:*:*:example-bucket"
],
"Condition": {
"StringNotEquals": {
"oss:x-oss-acl": "private"
}
}
},
{
"Effect": "Deny",
"Action": [
"oss:PutObjectAcl"
],
"Principal": [
"*"
],
"Resource": [
"acs:oss:*:*:example-bucket/*"
],
"Condition": {
"StringNotEquals": {
"oss:x-oss-object-acl": [
"private",
"default"
]
}
}
}
]
}シナリオ3:ObjectWorm の保持期間の制限
バケットでオブジェクトレベルの保持ポリシー (ObjectWorm) を有効にした後、バケットポリシーを使用して、ユーザーが設定できる保持日数の最大値を制限できます。たとえば、次のポリシーでは、ユーザーが設定できる保持期間の最大値を 30 日に制限します。30 日を超える PutObjectRetention リクエストは拒否されます。
{
"Version": "1",
"Statement": [
{
"Effect": "Deny",
"Action": [
"oss:PutObjectRetention"
],
"Principal": [
"*"
],
"Resource": [
"acs:oss:*:174649585760xxxx:example-bucket/*"
],
"Condition": {
"NumericGreaterThan": {
"oss:object-remaining-retention-days": "30"
}
}
}
]
}oss:object-remaining-retention-daysは ObjectWorm ポリシーの条件キーです。リクエストで指定された残りの保持日数を表します。このポリシーではプリンシパルがワイルドカード文字 (*) に設定されており、条件が含まれているため、このポリシーはバケット所有者を含むすべてのユーザーに適用されます。
開発とツールの統合
コンソールでの手動設定に加えて、グラフィカルツール、コマンドラインツール、SDK を使用してバケットポリシーを設定できます。
グラフィカルツール ossbrowser の使用
ossbrowser は、バケットレベルのポリシー操作をサポートしており、コンソールと同様の視覚的なエクスペリエンスを提供します。ossbrowser をインストールしてサインインし、画面の指示に従ってバケットポリシーを設定します。
コマンドラインツール ossutil の使用
put-bucket-policy コマンドを実行して、権限付与ポリシーを設定できます。
説明ベクターバケットに権限付与ポリシーを設定するには、
ossutil vectors-api put-bucket-policyコマンドを実行します。SDK の使用
Java SDK、Python SDK、Go SDK、Node.js SDK など、さまざまなプログラミング言語を使用してポリシーを設定できます。サポートされている SDK の詳細については、「SDK リファレンス」をご参照ください。
API の直接呼び出し
PutBucketPolicy API を呼び出して、バケットの権限付与ポリシーを設定します。
クォータと制限
ポリシーサイズ:1 つのバケットに複数のバケットポリシーのステートメントを設定できますが、すべてのポリシーの合計サイズは 16 KB を超えることはできません。
フィールド長:バケットポリシー内の各フィールドの長さは 4,095 バイトを超えることはできません。