:RAM および STS の概要

RAM および STS を使用する必要性

RAM および STS は、プライマリアカウントの AccessKey を公開せずに他のユーザーに安全にアクセス許可を付与する方法など、コアな問題を解決するように設計されています。 不正なユーザーがアカウントのリソースを操作する可能性があるため、AccessKey の公開は深刻なセキュリティ上の脅威となり、データ漏洩や重要な情報の盗難のリスクが高くなります。

反対に、STS は一時 AccessKey とトークンを返すことにより、一時的なアクセス許可を提供します。 この情報は一時的なアカウントに直接提供され、一時的なアカウントが OSS にアクセスできるようにします。 一般的に、STS から取得されたアクセス許可はより制限されており、限られた期間で有効です。 したがって、一時 AccessKey とトークンの情報が公開されても、システムにほとんど影響を与えません。

各機能について、例を用いてより詳しく説明します。

基本概念

以下は、基本概念の説明です。

• サブアカウント: サブアカウントは Alibaba Cloud のプライマリアカウントから作成されます。 作成されると、固有のパスワードとアクセス許可が割り当てられます。 各サブアカウントには独自の AccessKey があり、プライマリアカウントと同様に許可された操作を実行することができます。 一般的に、サブアカウントは、特定の権限を持つユーザー、または特定の操作を実行する権限を持つオペレーターです。 　
• ロール: ロールは、特定の操作権限の仮想概念です。 ただし、固有のログインパスワードやアクセスキーはありません。
  説明 サブアカウントはロールを引き受けることができます。 ロールを引き受けた場合、サブアカウントに付与される権限はそのロールの権限になります。
• ポリシー: ポリシーは権限を定義するために使用されるルールです。たとえば、ユーザーが特定のリソースを読み書きすることを許可します。
• リソース: リソースは、すべての OSS バケット、特定の OSS バケット、または特定の OSSバケット 内の特定のオブジェクトなど、ユーザーがアクセスできるクラウドリソースです。

概念の理解を深めるため、以下に例を示します。

• アリスは Alibaba Cloud ユーザーで、2 つのプライベート OSS バケット alice_a と alice_b を持っているとします。 アリスは両方のバケットに対する完全な権限を持っています。

• アリスの Alibaba Cloud アカウントの AccessKey が漏洩し、セキュリティ上の大きなリスクにさらされるのを防ぐため、アリスは RAM を使用して 2 つのサブアカウント、ボブとキャロルを作成します。 ボブは alice_a に対する読み取り / 書き込み権限を持ち、キャロルは alice_b に対する読み取り / 書き込み権限を持っています。 ボブとキャロルはどちらも独自のアクセスキーを持っています。 このようにすることで、片方の AccessKey が漏洩した場合、対応するバケットのみが影響を受け、アリスはコンソール上で漏洩したユーザーのアクセス許可を簡単に取り消すことができます。

• たとえば何らかの理由で、アリスは alice_a 内のオブジェクトの読み取りを、他のユーザーに許可する必要があるとします。 この場合、アリスはボブのアクセスキーを公開する必要があるだけではありません。 代わりに、アリスは AliceAReader のような新しいロールを作成し、このロールに alice_a の読み取り権限を付与します。 ただし、現時点では、AccessKey がこのロールに対応していないため、AliceAReader を使用することができません。 AliceAReader は現在、alice_a にアクセスする権限を持つ仮想エンティティにすぎません。

• 一時的な許可を得るため、アリスは STS の AssumeRole インターフェイスを呼び出し、STS に対してボブが AliceAReader のロールを引き受けることを通知します。 ロールの引き受けが成功すると、STS は一時的な AccessKeyId、AccessKeySecret、およびSecurityToken を返します。これらはアクセス認証情報として機能します。 これらの認証情報が一時的なアカウントに与えられると、そのユーザーは alice_a にアクセスするための一時的なアクセス許可を取得します。 認証情報の有効期限は、AssumeRole インターフェイスが呼び出されたときに指定されます。

RAM および STS の操作が複雑に見える理由

最初は、RAM および STS の概念は複雑に見えるかもしれません。 これは、単純さを犠牲にすることで、アクセス許可制御に柔軟性を与えるためです。

サブアカウントとロールは、操作を実行するエンティティと権限セットを表す仮想エンティティとに分けるため、分離されています。 ユーザーが複数のアクセス権限 (読み取りと書き込みのアクセス権限など) を必要としているものの、実際には各操作に必要な権限は全体の権限の一部のみである場合、2 つのロールを作成します。 次に、アクセス許可の権限を持っていないものの、これら 2 つのロールを引き受けることができるユーザーを作成します。 ユーザーがデータの読み取りまたは書き込みを行う必要がある場合、ユーザーは読み取り権限を持つロール、または書き込み権限を持つロールを一時的に引き受けます。 これにより、各操作に対する権限が漏洩するリスクが軽減されます。 さらに、ロールを使用して他の Alibaba Cloud ユーザーに権限を付与することで、コラボレーションを容易にすることができます。

なお、"柔軟性" とは、これらすべての機能を使用する必要があるという意味ではありません。 必要に応じて機能のサブセットを使用します。 たとえば、有効期限のある一時的なアクセス認証情報を使用する必要がない場合、STS を使用することなく、 RAM サブアカウント機能のみを使用します。

以下では、例を用いて RAM および STS のユーザーガイドを作成し、手順を説明します。 以下の例における操作では、使用する必要がある実際のコードの量を減らすために、コンソール操作とコマンドライン操作を極力使用しています。 RAM および STS の操作を実行するためにコードを使用する必要がある場合、「RAM および STS API マニュアル」をご参照ください。

テストツール

テスト中、OSS PythonSDK 内のツール osscmd を使用します。このツールを使用すると、コマンドラインから直接 OSS を操作することができます。osscmd は PythonSDK から入手します。

一般的な osscmd の使用方法

ファイルのダウンロード
./osscmd get oss://BUCKET/OBJECT LOCALFILE --host=Endpoint -i AccessKeyId -k AccessKeySecret
ここでは、BUCKET と OBJECT をユーザーのバケットとオブジェクトに置き換えます。エンドポイントの形式は oss-cn-hangzhou.aliyuncs.com と同様である必要があります。 AccessKeyId および AccessKeySecret には、ユーザーのアカウントに対応する情報を使用します。
ファイルのアップロード
./osscmd put LOCALFILE oss://BUCKET/OBJECT --host=Endpoint -i AccessKeyId -k AccessKeySecret
各フィールドの意味はダウンロードの例と同様です。