すべてのプロダクト
Search
ドキュメントセンター

Object Storage Service:権限とアクセス制御

最終更新日:Mar 25, 2026

Object Storage Service (OSS) は、データを保護するために、権限とアクセス制御のための多層的なシステムを提供します。このトピックでは、OSS のアクセス制御フレームワークの概要を説明し、利用可能なメソッドを理解・比較して、特定のニーズに最適なものを選択するのに役立ちます。

クイックガイド

シナリオ

推奨ソリューション

データを非公開に保ち、不正または匿名アクセスをブロックする

バケット ACL を非公開 (デフォルト) に設定します。

公開読み取り可能な静的リソースを提供する

バケット ACL を公開読み取りに設定し、ホットリンク保護 を構成して不正使用を防止します。

特定のバケットへのアクセスを複数のユーザーに許可する

バケットポリシー を使用します。単一のポリシーで許可されたユーザーのリストを指定できます。

ユーザーがアクセスできるすべてのリソースを一元管理する

ユーザーに RAM ポリシー をアタッチします。

他の Alibaba Cloud アカウントとリソースを共有する

バケットポリシー を使用するか、RAM ロールを使用して OSS へのクロスアカウントアクセスを実装します。

複数のアプリケーションまたはチームに同じバケットへの異なるアクセス権を提供する

アクセスポイント を使用します。各アプリケーションまたはチームは、専用のエントリポイントとポリシーを取得します。

設定ミスによる偶発的なデータ漏えいを防ぐ

公開アクセス禁止 を有効にします。

ブラウザのクライアントサイド JavaScript から OSS にアクセスする

オリジン間リソース共有 (CORS) を設定します。

マルチアカウント環境で権限の境界を定義する (例:公開アクセス禁止機能の強制)

コントロールポリシー を使用します。

認証メカニズム

OSS は、リクエストの種類に応じて異なる認証プロセスを使用します:

  • 署名付きリクエスト:OSS はまず署名を検証します。次に、コントロールポリシー (もしあれば) 、RAM ポリシー、バケットポリシー、およびアクセス制御リスト (ACL) を評価して、アクセスを許可するかどうかを決定します。

  • 匿名リクエスト:OSS は、コントロールポリシー (もしあれば) 、バケットポリシー、および ACL を評価して、パブリックアクセスが許可されているかどうかを判断します。

認証結果は、許可 (ポリシーによって明示的に許可) 、明示的な拒否 (ポリシーによって明示的に拒否され、最も高い優先度を持つ) 、および暗黙的な拒否 (どのポリシーもアクセスを許可しない場合にデフォルトで拒否) の 3 種類です。

完全な認証フローについては、「認証プロセスの詳細」をご参照ください。

アクセス制御メソッド

ACL

アクセス制御リスト (ACL) は、権限を制御する最も簡単な方法です。事前定義された権限レベルを使用して、リソースのアクセス状態を公開または非公開に設定します。

バケット ACL はバケットのデフォルトのアクセス権限を制御し、オブジェクト ACL は個々のオブジェクトの権限を制御し、より高い優先度を持ちます。オブジェクト ACL が指定されていない場合、オブジェクトはバケット ACL から権限を継承します。以下の権限レベルがサポートされています:

権限レベル

効果

private

データは非公開です。リソース所有者または許可されたユーザーのみがアクセスできます。

public-read

誰でもリソースを読み取ることができます。リソース所有者または許可されたユーザーのみが書き込みできます。

public-read-write

誰でもリソースを公開で読み書きできます。

ACL は事前定義されたレベルのみをサポートし、誰に、どのような条件下でアクセスを許可するかを指定することはできません。より詳細な制御を行うには、バケットポリシーまたは RAM ポリシーを使用します。

バケットポリシー

バケットポリシー は、バケットにアタッチされたリソースベースの権限付与ポリシーです。バケット内のリソースに誰がアクセスできるかを定義します。これを使用して、RAM ユーザー、他の Alibaba Cloud アカウント、または匿名ユーザーに権限を付与でき、IP アドレス、VPC、または時間などの条件を指定できます。

同じバケットへのアクセスを複数のユーザーに許可する必要がある場合、ユーザーごとに個別の権限を設定する代わりに、単一のバケットポリシーを使用できます。

チュートリアル: VPC エンドポイントポリシーとバケットポリシーを使用してデュアルアクセス制御を実装する | バケットポリシーを使用して部門間でデータを共有する

RAM ポリシー

RAM ポリシー は、ユーザー ID にアタッチされた ID ベースの権限付与ポリシーです。ユーザーがどの OSS リソースにアクセスできるかを定義し、複数のバケットにまたがるユーザーまたはアプリケーションの権限を一元管理するのに最適です。

OSS は、AliyunOSSFullAccessAliyunOSSReadOnlyAccess などのシステムポリシーを提供しており、直接使用できます。カスタムポリシーを作成することもできます。RAM ロールを使用してクロスアカウントアクセスを有効にし、セキュリティトークンサービス (STS) を介して一時的な権限付与を行うことができます。

チュートリアル: RAM ロールを使用して Alibaba Cloud アカウント間で OSS リソースにアクセスする | RAM ポリシーを使用して OSS へのアクセスを制御する

コントロールポリシー

リソースディレクトリの コントロールポリシー は、リソースフォルダーやメンバーなどのリソース構造に基づくアクセス制御ポリシーです。主に権限の境界を定義するために使用されます。マルチアカウント環境では、カスタムコントロールポリシーを使用して、すべてのバケットで公開アクセス禁止を有効にすることを要求するなど、メンバーアカウント全体でセキュリティ要件を強制できます。

ポリシーの比較

観点

バケットポリシー

RAM ポリシー

コントロールポリシー

設定範囲

バケット上

RAM ID (ユーザー、グループ、またはロール) 上

リソースディレクトリ内のリソース構造 (リソースフォルダーまたはメンバー) 上

管理の観点

リソース中心:「このリソースに誰がアクセスできるか?」

ID 中心:「この ID はどのリソースにアクセスできるか?」

組織中心:「リソースディレクトリ全体の権限の境界は何か?」

匿名アクセス

サポートされています

サポートされていません

サポートされていません

推奨事項:同じリソースへのアクセスを複数のユーザーに効率的に許可するには、バケットポリシーを使用します。単一ユーザーのすべてのリソース権限を直感的に管理するには、RAM ポリシーを使用します。匿名アクセスを許可するには、バケットポリシーを使用する必要があります。マルチアカウント環境では、コントロールポリシーを使用して権限の境界を定義できます。これらのメソッドは併用できます。OSS は、適用可能なすべてのポリシーが許可する場合にのみリクエストを許可します。

アクセスポイント

アクセスポイント は、バケットにアクセスするための専用のエントリポイントを提供します。単一のバケットに異なる権限を持つ複数のアプリケーションやチームがアクセスする必要がある場合、それぞれに個別のアクセスポイントを作成できます。その後、アクセスポイントポリシーを使用して各アクセスポイントの権限を個別に管理できるため、単一の複雑なバケットポリシーを維持する必要がなくなります。

各アクセスポイントには、一意のアクセスドメイン名、アクセスポイントポリシー、およびネットワーク制限があります。ユーザーがアクセスポイントを介して OSS にアクセスする場合、リクエストはアクセスポイントポリシー、バケットポリシー、および適用可能な RAM ポリシーによって許可されている場合にのみ許可されます。

セキュリティ機能

公開アクセス禁止

有効にすると、公開アクセス禁止 は、ACL またはバケットポリシーによって付与されたすべての公開権限をオーバーライドし、設定ミスによるデータ漏えいを防ぎます。この機能は、アカウントレベル (すべてのバケット) 、バケットレベル、またはアクセスポイントレベルで設定でき、上位レベルが優先されます。

機密データを保存し、匿名アクセスを必要としない場合は、この機能をアカウントレベルで有効にすることを推奨します。

ホットリンク保護

ホットリンク保護 は、HTTP リクエストの Referer ヘッダーをチェックすることで、不正な Web サイトが OSS リソースにリンクするのを防ぎます。ホワイトリスト (指定されたドメインのみを許可) またはブラックリスト (指定されたドメインを拒否) を設定できます。この機能は、画像や動画などのリソースの不正使用を防ぐのに役立ちます。

説明

Referer ヘッダーはなりすましが可能です。より高いセキュリティを確保するためには、署名付き URL の使用を推奨します。

オリジン間リソース共有 (CORS)

デフォルトでは、ブラウザは Web ページ内の JavaScript が異なるドメインのリソースにアクセスするのを防ぎます。CORS ルールを設定することで、OSS にレスポンスにクロスオリジンヘッダーを含めるように指示できます。これにより、ブラウザはリクエストを続行できます。これは、フロントエンドからの直接ファイルアップロードや Web アプリケーションのリソースのフェッチなどのシナリオで役立ちます。

ポリシーの構文

バケットポリシー、RAM ポリシー、コントロールポリシー、およびアクセスポイントポリシーはすべて JSON 形式で定義されます。コア要素は次のとおりです:

要素

説明

Effect

ポリシーの効果:Allow または Deny

Principal

権限を付与される ID (RAM ポリシーまたはコントロールポリシーでは不要) 。

Action

許可または拒否される操作 (例:oss:GetObject) 。

Resource

ポリシーが適用されるリソース。

Condition

ポリシーが有効になる条件 (オプション) 。

完全な構文とアクションのリストについては、「ポリシーの構文と構造」をご参照ください。

参考文献