RAM ポリシーは、ID ベースの権限付与ポリシーであり、さまざまなユーザー ID に対する Object Storage Service (OSS) リソースへのアクセスを一元管理するために使用されます。RAM ポリシーは、どの ID が、どのような条件下で、どの OSS リソースに対して、どのような操作を実行できるかを正確に定義します。これにより、詳細な権限コントロールが可能になり、企業のデータセキュリティを確保するのに役立ちます。
仕組み
RAM ポリシーは、ID ベースの権限付与モデルを使用します。権限を付与されるエンティティは、RAM ユーザー、ユーザーグループ、RAM ロールなどの Resource Access Management (RAM) ID です。権限の評価は、明示的な拒否を優先する原則に厳密に従います。OSS がアクセスリクエストを受信すると、システムは RAM ポリシーやバケットポリシーを含むすべての関連ポリシーを評価します。その後、以下の順序で権限が決定されます。
明示的な拒否を優先:いずれかのポリシーにリクエストと一致する明示的な
"Effect": "Deny"ルールが含まれている場合、リクエストは直ちに拒否されます。明示的な許可の検索:一致する Deny ルールが存在しない場合、システムはリクエストと一致する明示的な
"Effect": "Allow"ルールを検索します。一致が見つかった場合、リクエストは許可されます。デフォルトで拒否:一致する Deny または Allow ルールが存在しない場合、リクエストはデフォルトで拒否されます。
OSS は、システムポリシーとカスタムポリシーの 2 種類のアクセスポリシーをサポートしています。システムポリシーは Alibaba Cloud によって作成および維持されます。これらは使用のみ可能で、変更はできません。カスタムポリシーはユーザーが作成および維持します。必要に応じて作成、更新、削除が可能です。
システムポリシーを使用した権限付与
システムポリシーは Alibaba Cloud によって作成されます。これらの権限は、Resource Access Management (RAM) コンソールで ID に直接付与できます。以下の手順では、RAM ユーザーに権限を付与する方法について説明します。
RAM ユーザーリストに移動します。対象ユーザーの [操作] 列で、権限の追加 をクリックします。
検索ボックスにシステムポリシーの名前を入力して選択します。OSS は、以下の 2 つのシステムポリシーをサポートしています。
AliyunOSSFullAccess:Object Storage Service (OSS) に対する完全制御権を付与します。
AliyunOSSReadOnlyAccess:Object Storage Service (OSS) に対する読み取り専用権限を付与します。
[新規承認の確認] をクリックして、権限設定を完了します。
カスタムポリシーを使用した権限付与
カスタムポリシーを作成および維持できます。カスタムポリシーを使用して権限を付与するには、まずカスタムポリシーを作成し、次に対象の ID に付与する必要があります。
ステップ 1:カスタムポリシーの作成
ポリシーリストに移動します。ポリシーの作成 をクリックします。
スクリプトの編集 を選択します。エディターに、JSON 形式で権限付与ポリシーを入力します。RAM ポリシーエディターを使用すると、権限付与ポリシーを迅速に生成できます。
以下のポリシー例では、
example-bucketバケットとその中のすべてのリソースに対する完全制御権を付与します。{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": "oss:*", "Resource": [ "acs:oss:*:*:example-bucket", "acs:oss:*:*:example-bucket/*" ] } ] }完全な権限付与ポリシーには、Version と 1 つ以上の Statement が含まれます。
Version:アクセスポリシーのバージョンです。値は
1に固定されており、変更できません。Statement:ポリシーの本体です。1 つ以上の特定の許可または拒否ルールが含まれます。各ステートメントには、Effect、Action、Resource、および Condition が含まれます。
ポリシー要素
説明
Effect
ポリシーの効果です。有効な値は
AllowとDenyです。Action
リソースに対して実行する特定の操作です。ワイルドカード文字
*がサポートされています。Resource
ポリシーが適用されるリソースの範囲です。
Condition
ポリシーが有効になるための条件です。
複数の条件を設定した場合、すべての条件が満たされた場合にのみポリシーが有効になります (論理 AND)。
権限付与要素の完全なリストについては、「OSS 権限付与の構文と要素」をご参照ください。
OK をクリックします。ポリシー名 を入力し、OK をクリックしてカスタムポリシーを作成します。
ステップ 2:ID への権限付与
カスタムポリシーを作成した後、対象の ID に付与する必要があります。以下の手順では、RAM ユーザーに権限を付与する方法について説明します。
RAM ユーザーリストに移動します。対象ユーザーの [操作] 列で、権限の追加 をクリックします。
検索ボックスにカスタムポリシーの名前を入力して選択します。
[新規承認の確認] をクリックして、権限設定を完了します。
一般的な権限付与シナリオ
以下のシナリオは、実際のビジネスにおける RAM ポリシーの典型的な適用例を示しています。権限付与、アクセス制限、セキュリティ制御など、さまざまなニーズをカバーしています。各シナリオには、完全なポリシー構成例が提供されています。必要に応じてバケット名やフォルダパスなどのパラメーターを変更し、ポリシーを直接使用できます。
シナリオ 1:RAM ユーザーへのバケットに対する完全制御権の付与
以下の例では、mybucket という名前のバケットに対する完全制御権を RAM ユーザーに付与します。
モバイルアプリケーションの場合、ユーザーにバケットの完全制御権を付与することは、セキュリティリスクが非常に高いため、可能な限り避けるべきです。
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "oss:*",
"Resource": [
"acs:oss:*:*:mybucket",
"acs:oss:*:*:mybucket/*"
]
}
]
}シナリオ 2:バケット内の特定のパターンに一致するファイルの削除権限を RAM ユーザーに拒否する
以下の例では、mybucket という名前のバケット内で、プレフィックスが `abc` で `.txt` 形式のすべてのファイルを削除する権限を RAM ユーザーに拒否します。
{
"Version": "1",
"Statement": [
{
"Effect": "Deny",
"Action": [
"oss:DeleteObject"
],
"Resource": [
"acs:oss:*:*:mybucket/abc*.txt"
]
}
]
}シナリオ 3:RAM ユーザーへのバケット内のすべてのリソースを一覧表示および読み取る権限の付与
以下の例では、OSS SDK またはコマンドラインインターフェイス (CLI) を使用して、
mybucketという名前のバケット内のすべてのリソースを一覧表示および読み取る権限を RAM ユーザーに付与します。説明`ListObjects` 操作 (Action) は、リソースとしてバケット全体を使用する必要があります。
{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": "oss:ListObjects", "Resource": "acs:oss:*:*:mybucket" }, { "Effect": "Allow", "Action": "oss:GetObject", "Resource": "acs:oss:*:*:mybucket/*" } ] }以下の例では、OSS コンソールを使用して、
mybucketという名前のバケット内のすべてのリソースを一覧表示および読み取る権限を RAM ユーザーに付与します。{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:ListBuckets", "oss:GetBucketStat", "oss:GetBucketInfo", "oss:GetBucketTagging", "oss:GetBucketLifecycle", "oss:GetBucketWorm", "oss:GetBucketVersioning", "oss:GetBucketAcl" ], "Resource": "acs:oss:*:*:*" }, { "Effect": "Allow", "Action": [ "oss:ListObjects", "oss:GetBucketAcl" ], "Resource": "acs:oss:*:*:mybucket" }, { "Effect": "Allow", "Action": [ "oss:GetObject", "oss:GetObjectAcl" ], "Resource": "acs:oss:*:*:mybucket/*" } ] }
シナリオ 4:バケットの削除権限を RAM ユーザーに拒否する
以下の例では、mybucket という名前のバケットを削除する権限を RAM ユーザーに拒否します。
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "oss:*",
"Resource": [
"acs:oss:*:*:mybucket",
"acs:oss:*:*:mybucket/*"
]
},
{
"Effect": "Deny",
"Action": [
"oss:DeleteBucket"
],
"Resource": [
"acs:oss:*:*:mybucket"
]
}
]
}シナリオ 5:RAM ユーザーへのバケット内の複数のフォルダへのアクセス権限の付与
mybucket という名前のバケットが写真の保存に使用されているとします。このバケットには、写真の場所を表すいくつかのフォルダが含まれています。各場所のフォルダには、年のサブディレクトリが含まれています。
mybucket[Bucket]
├── beijing
│ ├── 2014
│ └── 2015
└── hangzhou
├── 2014
└── 2015 mybucket/hangzhou/2014/ および mybucket/hangzhou/2015/ フォルダへの読み取り専用権限を RAM ユーザーに付与する必要があります。フォルダレベルの権限付与は高度な機能です。権限付与ポリシーの複雑さはシナリオによって異なります。以下の例は参考用です。
mybucket/hangzhou/2014/およびmybucket/hangzhou/2015/フォルダ内のファイルのコンテンツのみを読み取る権限を RAM ユーザーに付与します。RAM ユーザーはファイルの完全なパスを知っているため、ファイルのコンテンツを読み取るには完全なファイルパスを使用することを推奨します。
{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:GetObject" ], "Resource": [ "acs:oss:*:*:mybucket/hangzhou/2014/*", "acs:oss:*:*:mybucket/hangzhou/2015/*" ] } ] }OSS CLI を使用して
mybucket/hangzhou/2014/およびmybucket/hangzhou/2015/フォルダにアクセスし、その中のファイルを一覧表示する権限を RAM ユーザーに付与します。RAM ユーザーがフォルダ内にどのファイルがあるかを知らない場合、OSS CLI または API を使用してフォルダ情報を直接取得できます。このシナリオでは、
ListObjects権限を追加する必要があります。{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:GetObject" ], "Resource": [ "acs:oss:*:*:mybucket/hangzhou/2014/*", "acs:oss:*:*:mybucket/hangzhou/2015/*" ] }, { "Effect": "Allow", "Action": [ "oss:ListObjects" ], "Resource": [ "acs:oss:*:*:mybucket" ], "Condition":{ "StringLike":{ "oss:Prefix": [ "hangzhou/2014/*", "hangzhou/2015/*" ] } } } ] }OSS コンソールを使用してフォルダにアクセスする権限を RAM ユーザーに付与します。
OSS コンソールを使用して
mybucket/hangzhou/2014/およびmybucket/hangzhou/2015/フォルダにアクセスする場合、RAM ユーザーはルートディレクトリから開始し、レイヤーをナビゲートしてターゲットフォルダに移動できます。{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:ListBuckets", "oss:GetBucketStat", "oss:GetBucketInfo", "oss:GetBucketTagging", "oss:GetBucketLifecycle", "oss:GetBucketWorm", "oss:GetBucketVersioning", "oss:GetBucketAcl" ], "Resource": [ "acs:oss:*:*:*" ] }, { "Effect": "Allow", "Action": [ "oss:GetObject", "oss:GetObjectAcl" ], "Resource": [ "acs:oss:*:*:mybucket/hangzhou/2014/*", "acs:oss:*:*:mybucket/hangzhou/2015/*" ] }, { "Effect": "Allow", "Action": [ "oss:ListObjects" ], "Resource": [ "acs:oss:*:*:mybucket" ], "Condition": { "StringLike": { "oss:Delimiter": "/", "oss:Prefix": [ "", "hangzhou/", "hangzhou/2014/*", "hangzhou/2015/*" ] } } } ] }
シナリオ 6:バケット内の任意のファイルを削除する権限を RAM ユーザーに拒否する
以下の例では、mybucket という名前のバケット内の任意のファイルを削除する権限を RAM ユーザーに拒否します。
{
"Version": "1",
"Statement": [
{
"Effect": "Deny",
"Action": [
"oss:DeleteObject"
],
"Resource": [
"acs:oss:*:*:mybucket/*"
]
}
]
}シナリオ 7:特定のタグを持つオブジェクトへのアクセス権限を RAM ユーザーに拒否する
以下の `Deny` ポリシーは、examplebucket バケット内でタグ status:ok および key1:value1 を持つオブジェクトへのアクセス権限を RAM ユーザーに拒否します。
{
"Version": "1",
"Statement": [
{
"Effect": "Deny",
"Action": [
"oss:GetObject"
],
"Resource": [
"acs:oss:*:174649585760xxxx:examplebucket/*"
],
"Condition": {
"StringEquals": {
"oss:ExistingObjectTag/status":"ok",
"oss:ExistingObjectTag/key1":"value1"
}
}
}
]
}シナリオ 8:特定の IP アドレスからの OSS へのアクセス権限を RAM ユーザーに付与する
Allow権限付与に IP アドレス制限を追加します。以下の例では、
Allow権限付与に IP アドレス制限を追加します。192.168.0.0/16および198.51.100.0/24の IP アドレス範囲からのみ、mybucketという名前のバケット内のすべてのリソースを読み取る権限を RAM ユーザーに付与します。{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:ListBuckets", "oss:GetBucketStat", "oss:GetBucketInfo", "oss:GetBucketTagging", "oss:GetBucketAcl" ], "Resource": [ "acs:oss:*:*:*" ] }, { "Effect": "Allow", "Action": [ "oss:ListObjects", "oss:GetObject" ], "Resource": [ "acs:oss:*:*:mybucket", "acs:oss:*:*:mybucket/*" ], "Condition":{ "IpAddress": { "acs:SourceIp": ["192.168.0.0/16", "198.51.100.0/24"] } } } ] }Deny権限付与に IP アドレス制限を追加します。以下の例では、
Deny権限付与に IP アドレス制限を追加します。ソース IP アドレスが192.168.0.0/16の範囲外である RAM ユーザーが OSS 上でいかなる操作も実行することを拒否します。{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:ListBuckets", "oss:GetBucketStat", "oss:GetBucketInfo", "oss:GetBucketTagging", "oss:GetBucketAcl" ], "Resource": [ "acs:oss:*:*:*" ] }, { "Effect": "Allow", "Action": [ "oss:ListObjects", "oss:GetObject" ], "Resource": [ "acs:oss:*:*:mybucket", "acs:oss:*:*:mybucket/*" ] }, { "Effect": "Deny", "Action": "oss:*", "Resource": [ "acs:oss:*:*:*" ], "Condition":{ "NotIpAddress": { "acs:SourceIp": ["192.168.0.0/16"] } } } ] }説明アクセスポリシーの認証ルールは「Deny 優先」であるため、ユーザーが
192.168.0.0/16範囲外の IP アドレスから mybucket のコンテンツにアクセスしようとすると、OSS は権限エラーを報告します。
シナリオ 9:RAM または STS を介して他のユーザーに権限を付与する
IP アドレス 192.168.0.1 を持つユーザーに、RAM またはセキュリティトークンサービス (STS) を介して Java SDK クライアントを使用して以下の操作を実行する権限を付与します。
mybucketバケット内でプレフィックスがfooのオブジェクトを一覧表示します。mybucketバケット内でプレフィックスがfileのオブジェクトをアップロード、ダウンロード、削除します。
{
"Version": "1",
"Statement": [
{
"Action": [
"oss:GetBucketAcl",
"oss:ListObjects"
],
"Resource": [
"acs:oss:*:177530505652xxxx:mybucket"
],
"Effect": "Allow",
"Condition": {
"StringEquals": {
"acs:UserAgent": "java-sdk",
"oss:Prefix": "foo"
},
"IpAddress": {
"acs:SourceIp": "192.168.0.1"
}
}
},
{
"Action": [
"oss:PutObject",
"oss:GetObject",
"oss:DeleteObject"
],
"Resource": [
"acs:oss:*:177530505652xxxx:mybucket/file*"
],
"Effect": "Allow",
"Condition": {
"StringEquals": {
"acs:UserAgent": "java-sdk"
},
"IpAddress": {
"acs:SourceIp": "192.168.0.1"
}
}
}
]
}シナリオ 10:バケットとオブジェクトの ACL をパブリックアクセスに設定することを禁止する
以下の例では、OSS データのセキュリティを確保するために、バケットとオブジェクトのアクセス制御リスト (ACL) をパブリックに設定することを禁止します。
{
"Version": "1",
"Statement": [
{
"Effect": "Deny",
"Action": [
"oss:PutBucket",
"oss:PutBucketAcl"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"oss:x-oss-acl": "private"
}
}
},
{
"Effect": "Deny",
"Action": [
"oss:PutObject",
"oss:PutObjectAcl"
],
"Resource": "*",
"Condition": {
"StringNotEquals": {
"oss:x-oss-object-acl": [
"private",
"default"
]
}
}
}
]
}シナリオ 11:RAM ユーザーに IMM 関連機能の使用権限を付与する
以下の RAM ポリシーは、RAM ユーザーに Intelligent Media Management (IMM) のドキュメント処理機能を使用する権限を付与します。
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": [
"oss:GetObject",
"oss:PutObject",
"oss:PostProcessTask",
"oss:ProcessImm"
],
"Resource": "*"
},
{
"Action": [
"imm:CreateOfficeConversionTask",
"imm:GetWebofficeURL"
],
"Resource": "*",
"Effect": "Allow"
},
{
"Effect": "Allow",
"Action": "ram:PassRole",
"Resource": "acs:ram:*:*:role/aliyunimmdefaultrole"
}
]
}シナリオ 12:RAM ユーザーにストレージ冗長タイプの変更権限を付与する
特定のバケットのストレージ冗長タイプを変更する権限を RAM ユーザーに付与します。
以下の例では、
mybucketバケットのストレージ冗長タイプを変更する権限を RAM ユーザーに付与します。{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:CreateBucketDataRedundancyTransition", "oss:GetBucketDataRedundancyTransition", "oss:ListBucketDataRedundancyTransition", "oss:DeleteBucketDataRedundancyTransition" ], "Resource": "acs:oss:*:*:mybucket" } ] }すべてのバケットのストレージ冗長タイプを変更する権限を RAM ユーザーに付与します。
重要以下の例では、Alibaba Cloud アカウント配下のすべてのバケットのストレージ冗長タイプを変更する権限を RAM ユーザーに付与します。慎重に進めてください。
{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "oss:CreateBucketDataRedundancyTransition", "oss:GetBucketDataRedundancyTransition", "oss:ListBucketDataRedundancyTransition", "oss:DeleteBucketDataRedundancyTransition" ], "Resource": "acs:oss:*:*:*" } ] }
シナリオ 13:RAM ユーザーに OSS リソースプランの注文を作成する権限を付与する
以下の RAM ポリシーは、RAM ユーザーに OSS リソースプランの注文を作成する権限を付与します。
RAM ユーザーが OSS リソースプランの注文を作成した後、Alibaba Cloud アカウントのオーナーに連絡して支払いを完了させることができます。RAM ユーザーに注文の支払いを許可するには、Alibaba Cloud アカウントのオーナーが RAM ユーザーに bss:PayOrder 権限を付与する必要があります。bss:PayOrder 権限は財務操作に関わる高リスクな権限です。必要でない限り、この権限を付与しないでください。
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "oss:CreateOrder",
"Resource": "acs:oss:*:*:*"
}
]
}シナリオ 14:RAM ユーザーに OSS をアクティベートする権限を付与する
以下の RAM ポリシーは、RAM ユーザーに OSS をアクティベートする権限を付与します。
{
"Version": "1",
"Statement": [
{
"Effect": "Allow",
"Action": "oss:ActivateProduct",
"Resource": "acs:oss:*:*:*"
}
]
}シナリオ 15:特定のタグを持つバケット内のデータの読み書き権限を RAM ユーザーに付与する
以下の RAM ポリシーは、特定のタグを持つバケット内のデータを読み書きする権限を RAM ユーザーに付与します。タグキーは `key1` で、タグ値は `value1` です。
{
"Version": "1",
"Statement": [
{
"Action": [
"oss:ListBuckets",
"oss:GetBucketStat",
"oss:GetBucketInfo",
"oss:GetBucketAcl",
"oss:ListObjects",
"oss:PutObject",
"oss:GetObject"
],
"Resource": [
"acs:oss:*:*:*"
],
"Effect": "Allow",
"Condition": {
"StringEquals": {
"oss:BucketTag/key1": "value1"
}
}
}
]
}ポリシーが有効になると、RAM ユーザーはタグ key1=value1 を持つ OSS バケットに対してのみ指定された操作を実行できます。動作はアクセス方法によって異なります。
OSS SDK または ossutil を使用して
ListBucketsリクエストを送信する場合、tag-key=key1,tag-value=value1などのタグフィルタリングパラメーターを追加する必要があります。ポリシーが正しく設定されていれば、応答は指定されたタグ条件に一致するバケットのみを返します。OSS コンソールを使用して
ListBucketsリクエストを送信する場合、コンソールはタグパラメーターをアタッチできないため、リクエストは拒否されます。リクエストはポリシー条件 (oss:BucketTag/key1=value1) を満たさず、システムは権限エラーを報告します。PutObjectやGetObjectなどの他の操作もタグ条件の対象となります。操作の対象バケットにはタグkey1=value1が必要です。
本番環境におけるベストプラクティス
RAM ポリシーを設定し、RAM ID を管理する際には、以下のセキュリティのベストプラクティスに従ってください。これにより、データ漏洩のリスクを効果的に低減し、正確な権限コントロールを確保できます。
最小権限の原則に従う:常にタスクを実行するために必要な最小限の権限セットのみを付与してください。絶対に必要な場合を除き、
oss:*のような広範な権限は避けてください。最小権限の原則は、潜在的な攻撃対象領域を減らし、権限の乱用や操作ミスのリスクを低減します。RAM ロールと STS の一時的な認証情報を使用する:アプリケーション、特に ECS インスタンスやコンテナーにデプロイされたアプリケーションでは、RAM ロールを使用し、STS から一時的な認証情報を取得して OSS にアクセスしてください。長期的な AccessKey ペアとは異なり、一時的な認証情報は自動的に有効期限が切れます。この方法は、コードや構成ファイルに長期的な AccessKey ペアをハードコーディングする必要がなくなり、AccessKey ペアの漏洩リスクを大幅に低減します。
人間ユーザーとプログラムユーザーを分離する:異なる人物やアプリケーションごとに別々の RAM ユーザーを作成してください。これにより、専門的な ID 管理と詳細な権限コントロールが可能になります。
人間ユーザー:コンソールアクセスを設定します。アカウントとパスワードを使用して製品コンソールにアクセスします。多要素認証 (MFA) を有効にすることを推奨します。
プログラムユーザー:永続的な AccessKey ペアによるプログラムアクセスを設定します。AccessKey ペアを使用して API を呼び出し、クラウドリソースにアクセスします。
AccessKey ペアのセキュリティ管理:
RAM ユーザーの AccessKey ID と AccessKey Secret をプロジェクトコードに保存しないでください。この行為は AccessKey ペアの漏洩につながる可能性があります。
STS や環境変数などの方法を使用してアクセス権限を取得することを推奨します。
AccessKey ペアを定期的にローテーションしてください。
RAM ロールのセキュリティに関する推奨事項:
RAM ロールを作成した後、慎重な検討なしに信頼できるエンティティを変更しないでください。この変更は、ビジネスに影響を与えたり、過剰な権限付与のリスクを生み出したりする可能性があります。
STS トークンには合理的な有効期間を設定してください。セキュリティリスクを防ぐため、長い有効期間は避けてください。
権限の定期的な監査:不要な RAM ユーザーとアクセスポリシーを定期的に見直し、クリーンアップしてください。この実践により、権限が現在のビジネスニーズに合致していることを確認できます。
Condition を使用してセキュリティを強化する:ポリシーに
Condition要素を追加できます。例えば、ソース IP アドレスや VPC を制限することができます。多次元の条件付き制約を使用することで、データアクセスにさらなるセキュリティ層を追加できます。