Object Storage Service (OSS) のバケットやオブジェクトなどのリソースは、デフォルトではプライベートです。これらのリソースへのアクセスは、アクセスコントロールリスト (ACL)、認可ポリシー、およびセキュリティ保護機能を使用して制御します。このトピックでは、OSS がアクセスリクエストを評価する方法と、権限制御の方法を選択する方法について説明します。
クイックセレクション
シナリオに基づいて権限制御の方法を選択します。
シナリオ | 推奨ソリューション |
データをプライベートに保ち、不正なアクセスをブロックする | バケット ACL を |
複数のユーザーに特定のバケットへのアクセスを許可する | バケットポリシーを使用します。 |
ユーザーがアクセスできるすべてのリソースを集中管理する | ユーザーに RAM ポリシーをアタッチします。 |
他の Alibaba Cloud アカウントとリソースを共有する | バケットポリシーを使用するか、「RAM ロールを使用した OSS へのクロスアカウントアクセス」を利用します。 |
複数のアプリケーションやチームに、同じバケットへの異なるアクセス権を付与する | アクセスポイントを使用して、各アプリケーションまたはチームに独立したエンドポイントとポリシーを提供します。 |
マルチアカウントのシナリオで、パブリックアクセスブロックの強制などの権限の境界を集中管理する | コントロールポリシーを使用します。 |
誰でも読み取り可能な静的リソースを公開する | バケット ACL を |
設定ミスによるデータ漏洩を防止する | パブリックアクセスブロックを有効にします。ACL またはバケットポリシーで設定されたパブリックな認可は無効になります。 |
ブラウザ側の JavaScript から OSS にアクセスする | バケットにCORS ルールを設定します。CORS はブラウザのオリジン間アクセスのみを制御し、アクセス権限を付与または拒否するものではありません。 |
OSS による権限評価の仕組み
OSS は、各リクエストを、それに適用される権限制御の方法 (ACL、バケットポリシー、Resource Access Management (RAM) ポリシー、Resource Directory のコントロールポリシー、アクセスポイントポリシー (AP ポリシー)) に照らして評価します。各方法については、「権限制御の方法」で説明します。
OSS は、リクエストの種類ごとに異なる認可プロセスを使用します。
署名付きリクエスト — OSS は署名を検証した後、Resource Directory のコントロールポリシー (存在する場合)、RAM ポリシー、バケットポリシー、および ACL を評価します。
匿名リクエスト — OSS は、Resource Directory のコントロールポリシー (存在する場合)、バケットポリシー、および ACL がパブリックアクセスを許可しているかどうかを評価します。
すべての評価は、次のいずれかの結果を返します。
Allow — ポリシーが明示的にアクセスを許可します。
明示的な拒否 — ポリシーが明示的にアクセスを拒否します。明示的な拒否は最優先されます。
暗黙的な拒否 — アクセスを許可するポリシーがないため、リクエストは拒否されます。
複数の方法を設定する場合、次のルールが適用されます。
複数種類のポリシー — バケットポリシー、RAM ポリシー、コントロールポリシーを併用できます。OSS は適用可能なすべてのポリシーを評価し、適用可能なすべてのポリシーがリクエストを許可する場合にのみ、リクエストを許可します。コントロールポリシーは、それ自体でアクセスを許可するのではなく、権限の境界を設定します。
オブジェクト ACL の優先度 — オブジェクト ACL はバケット ACL よりも優先されます。オブジェクト ACL を指定しない場合、オブジェクトはバケット ACL を継承します。
アクセスポイントリクエスト — ユーザーがアクセスポイントを介してバケットにアクセスする場合、RAM ポリシーとバケットポリシーの統合評価結果が Allow であり、かつ AP ポリシーも Allow である必要があります。
パブリックアクセスブロック — パブリックアクセスブロックが有効になっている場合、ACL またはバケットポリシーで設定されたパブリックな認可は無効になります。
完全な認可プロセスの詳細については、「OSS 認可の詳細」をご参照ください。
権限制御の方法
ACL
ACL は、事前定義された権限レベルを通じて、OSS リソースがパブリックかプライベートかを制御します。
バケット ACL はバケットのデフォルトのアクセス権限を制御し、オブジェクト ACL は単一のオブジェクトの権限を制御し、優先度がより高くなります。オブジェクト ACL を指定しない場合、オブジェクトはバケット ACL を継承します。次の表に、サポートされている権限レベルを示します。
権限レベル | 適用対象 | 効果 |
| バケット ACL とオブジェクト ACL | データはプライベートです。リソースの所有者または認可されたユーザーのみがデータにアクセスできます。 |
| バケット ACL とオブジェクト ACL | 誰でもデータを読み取ることができます。リソースの所有者または認可されたユーザーのみがデータを書き込むことができます。 |
| バケット ACL とオブジェクト ACL | 誰でもデータを読み書きできます。 |
| オブジェクト ACL | オブジェクトはバケット ACL を継承します。 |
ACL は事前定義された権限レベルのみをサポートしており、認可されるプリンシパルや条件を指定することはできません。きめ細かいアクセス制御を行うには、バケットポリシーまたは RAM ポリシーを使用します。
バケットポリシー
バケットポリシーは、バケットに設定される認可ポリシーです。そのバケット内のリソースに誰がアクセスできるかを定義します。バケットポリシーは、RAM ユーザー、他の Alibaba Cloud アカウント、匿名ユーザーを認可でき、IP アドレス、VPC、時刻などの条件を課すことができます。
1 つのバケットポリシーで、複数のユーザーに同じバケットへのアクセスを認可できます。ユーザーごとに個別のポリシーを設定する必要はありません。
チュートリアル：「VPC とバケットポリシーによる二重のアクセス制御」 | 「バケットポリシーに基づく部門間でのデータ共有」
RAM ポリシー
RAM ポリシーは、ユーザーアイデンティティにアタッチされる認可ポリシーです。そのユーザーがどの OSS リソースにアクセスできるかを定義し、複数のバケットにまたがるユーザーやアプリケーションの権限を集中管理するのに適しています。
OSS は、AliyunOSSFullAccess や AliyunOSSReadOnlyAccess など、直接使用できるシステムポリシーを提供するほか、カスタムポリシーもサポートしています。RAM ロールにより、クロスアカウントアクセスと STS の一時的な権限付与が可能になります。
チュートリアル：「OSS へのクロスアカウントアクセスのための RAM ロールの使用」 | 「RAM ポリシーによる OSS アクセスの制御」
コントロールポリシー
コントロールポリシーは、Resource Directory 内のフォルダーやメンバーなどのリソース階層に基づくアクセス制御ポリシーであり、主に権限の境界を定義するために使用されます。マルチアカウント管理のシナリオでは、カスタムコントロールポリシーを使用して、パブリックアクセスブロックの有効化を要求するなど、メンバーアカウントのバケットセキュリティポリシーに対する制限を一体的に強制できます。詳細については、「コントロールポリシー」をご参照ください。
アクセスポイント
アクセスポイントは、バケットに独立したアクセスエンドポイントを提供します。複数のアプリケーションやチームが異なる権限で同じバケットにアクセスする必要がある場合、各関係者用に個別のアクセスポイントを作成し、アクセスポイントポリシー (AP ポリシー) を使用してその関係者の権限を管理します。このアプローチにより、単一のバケットポリシーで複雑なルールを維持する必要がなくなります。
各アクセスポイントには、独立したエンドポイント、AP ポリシー、およびネットワーク制限設定があります。アクセスポイント経由のリクエストは、RAM ポリシーとバケットポリシーに加えて、AP ポリシーに対しても評価されます。評価ルールについては、「OSS による権限評価の仕組み」をご参照ください。
一時的なアクセス
OSS リソースへの一時的なアクセスを提供する 2 つの方法があります。
STS の一時的な認可 — RAM ロールは、クロスアカウントアクセスと STS の一時的な認可を可能にします。
署名付き URL — HTTP リクエストヘッダーの Referer フィールドは偽造される可能性があるため、署名付き URL はホットリンク保護よりも高いセキュリティを確保できます。
権限制御の方法の比較
次の表は、OSS が提供する権限制御の方法を比較したものです。
方法 | 設定場所 | 管理の観点 | 粒度と条件 | 設定要件 |
ACL | バケットまたは単一のオブジェクト | リソース中心：リソースがパブリックかプライベートか | 事前定義された権限レベルのみ。認可されるプリンシパルや条件は指定不可。 | バケットの所有者のみがバケット ACL を設定または変更可能。 |
バケットポリシー | バケット | リソース中心：バケット内のリソースに誰がアクセスできるか | 認可されるプリンシパル、アクション、リソース、および IP アドレス、VPC、時刻制限などの条件 | RAM ポリシーよりも設定が簡単で、コンソールでグラフィカルに設定可能。バケットの所有者は RAM の操作権限なしで直接アクセス権限を付与可能。 |
RAM ポリシー | RAM アイデンティティ | アイデンティティ中心：アイデンティティがどの OSS リソースにアクセスできるか | アイデンティティに対するアクションとリソース、およびオプションの条件を定義します。システムポリシーとカスタムポリシーの両方がサポートされています。 | RAM の操作権限が必要。 |
コントロールポリシー | Resource Directory のリソース階層の各レベル (フォルダーやメンバーなど) | 組織ガバナンス中心：Resource Directory 全体で権限の境界を一元的に制限 | オプションの条件を含む、メンバーアカウントのアクセス許可境界。 | Resource Directory で管理。 |
AP ポリシー | アクセスポイント | エンドポイント中心：同じバケットにアクセスする各アプリケーションまたはチームの権限を分離 | アクセスポイント経由のリクエストに対するアクション、リソース、プリンシパル、および条件。ネットワーク制限は別途設定。 | アクセスポイントで管理。 |
これらの方法の中から選択するには、次のガイダンスを参考にしてください。
同じリソースへのアクセスを複数のユーザーに認可する — バケットポリシーがより効率的です。1 つのポリシーで許可されたユーザーのリストを指定します。
単一ユーザーのすべてのリソース権限を管理する — RAM ポリシーがより直感的です。
匿名アクセスの許可 — ポリシータイプのうち、匿名アクセスをサポートしているのはバケットポリシーのみです。ACL でも、
public-readおよびpublic-read-writeレベルで匿名アクセスが許可されます。複数のアカウントにまたがる権限を制限する — コントロールポリシーは権限の境界を一元的に制限します。これは、アクセスを許可するのではなく、メンバーアカウントに許可できる操作を制約するものです。
複数のアプリケーションまたはチームのアクセスを分離する — AP ポリシーは、各関係者の権限を独立させ、単一のバケットポリシー内の複雑なルールを回避します。
セキュリティ保護
パブリックアクセスブロック
パブリックアクセスブロックを有効にすると、ACL またはバケットポリシーで設定されたパブリックな認可は無効になります。既存のパブリックアクセス権限は無視され、新しいパブリックアクセス権限を作成することはできなくなります。これにより、設定ミスによるデータ漏洩を防ぎます。
パブリックアクセスブロックは、すべてのバケットに適用されるアカウントレベル、およびバケット、アクセスポイント、オブジェクト FC アクセスポイントレベルで設定できます。優先度はこの順序で低くなり、アカウントレベルの設定が最も優先度が高くなります。
機密データを保存し、匿名アクセスが不要な場合は、アカウントレベルでパブリックアクセスブロックを有効にしてください。
パブリックアクセスブロックとパブリックアクセスは相互に排他的です。アカウント、バケット、またはアクセスポイントでパブリックアクセスブロックが有効になっている場合、public-read ACL またはパブリックバケットポリシーは有効になりません。リソースをパブリックに公開する前に、パブリックアクセスブロックの設定を確認してください。
ホットリンク保護
ホットリンク保護は、Referer や User-Agent ヘッダーなどの HTTP リクエストのソースを検証して、不正なウェブサイトが OSS リソースを参照するのを防ぎます。ホットリンク保護は、ホワイトリスト、ブラックリスト、または正規表現を使用して設定できます。ホワイトリストは指定されたドメイン名のみを許可し、ブラックリストは指定されたドメイン名を拒否します。ホットリンク保護を使用して、画像や動画などのリソースの不正利用を防止します。
Referer フィールドは偽造される可能性があります。より高いセキュリティを確保するには、一時的なアクセス方法である署名付き URL を使用してください。
オリジン間リソース共有 (CORS)
デフォルトでは、ブラウザはウェブページ上の JavaScript が異なるドメイン名のリソースにアクセスすることを防ぎます。CORS ルールを設定すると、OSS はレスポンスにオリジン間ヘッダーを返すため、ブラウザはリクエストを許可します。CORS は、フロントエンドからの直接ファイルアップロードやリソースの取得などのシナリオに適用されます。
CORS はブラウザの同一オリジンポリシーによる制限を解決するだけであり、アクセス権限を付与または拒否するものではありません。そのため、権限制御の方法の代わりとしてではなく、それに加えて CORS を設定してください。
関連資料
OSS の権限とアクセス制御に関する詳細については、次のトピックをご参照ください。