Cloud Access Management(CAM)はTencent Cloudがご提供するID認証および権限承認サービスです。これは主に、お客様がTencent Cloudアカウント下のリソースへのアクセス権限を安全に管理するために役立てられます。権限が与えられている場合、権限を持つオブジェクト、リソース、操作を管理できるほか、いくつかのポリシー制限を設定することもできます。
ルートアカウントのリソース権限は、サブアカウントまたは他のルートアカウントなどの他者に付与することができ、その際ルートアカウントに関連するID証明書を共有する必要はありません。
リソースごとに、異なる人に異なるアクセス権限を付与することができます。例えば、いくつかのサブアカウントにはあるCloud Object Storage(COS)バケットの読み取り権限を与え、別のいくつかのサブアカウントまたはルートアカウントにはあるCOSストレージオブジェクトの書き込み権限を与えることなどができます。上記のリソース、アクセス権限およびユーザーはすべて一括パッケージ化が可能です。
CAMは現在Tencent Cloudの複数のリージョンでサポートしています。ポリシーデータをコピーすることで、クロスリージョナルなデータ同期を実現します。CAMポリシーの変更はタイムリーに送信されますが、異なるリージョン間でポリシーの同期を行うとポリシーの発効に遅延が生じる場合があります。またCAMはキャッシュを使用してパフォーマンスを向上させているため(現在のキャッシュ時間は1分間)、更新はキャッシュが期限切れになってから発効します。
企業のサブアカウント権限管理
企業内の各職場の従業員に、その企業のクラウドリソースへの最小のアクセス権限を持たせる必要がある場合です。例えば、ある企業にCVM、VPCインスタンス、CDNインスタンス、COSバケットおよびオブジェクトなどの、多くのクラウドリソースがあるとします。この企業には開発要員、テスト要員、運用保守要員などの多くの従業員がいます。
一部の開発要員には、その所属プロジェクトに関連する開発マシンクラウドリソースの読み取り書き込み権限が必要であり、テスト要員にはその所属プロジェクトのテストマシンクラウドリソースの読み取り書き込み権限が必要です。運用保守要員はマシンの購入と日常的な運用を担います。社内で従業員の職責または参加プロジェクトに変更が生じた場合は、対応する権限を終了します。
異なる企業間での権限管理
異なる企業間でのクラウドリソースの共有が必要な場合です。例えば、多くのクラウドリソースを持つある企業が製品開発に特化するため、クラウドリソースの運用保守業務の権限を他の運営企業に委託して実施させる場合です。運営企業との契約の終了時に、対応する管理権限を回収します。
ポリシー(policy)はいくつかの要素で構成され、権限の具体的な情報を記述するために用いられます。中心となる要素には、プリンシパル(principal)、アクション(action)、リソース(resource)、発効条件(condition)およびエフェクト(effect)が含まれます。その他の詳細についてお知りになりたい場合は、アクセスポリシーの言語概要をご参照ください。
説明:
- ポリシー構文の記述に順序の要件はありません。アクション(action)の要素はアルファベットの大文字と小文字を区別する必要があります。
- ポリシーが特定の条件に制約されることがなければ、conditionの要素はオプション項目です。
- principalの要素はコンソールで書き込むことはできません。ポリシー管理API内およびポリシー構文関連パラメータ内でのみprincipalを使用することができます。
中心的要素 | 説明 | 入力必須かどうか |
---|---|---|
バージョン version | 記述するポリシー構文のバージョンです。現在許可されている値は2.0のみです | はい |
プリンシパル principal | ポリシーが権限を付与するエンティティの記述に用いられます。ユーザー(デベロッパー、サブアカウント、匿名ユーザー)、ユーザーグループが含まれます | ポリシー管理API内およびポリシー構文関連パラメータ内でのみこの要素を使用することができます |
ステートメント statement | 1つまたは複数の権限の詳細情報の記述に用いられます。この要素にはaction、resource、condition、effectなどのいくつかの他の要素の権限または権限セットが含まれます。1つのポリシーには1つのstatement要素しかありません | はい |
アクション action | 許可または拒否するアクションの記述に用いられます。アクションは単一のAPIのアクションまたは複数のAPIアクションのセットとすることができます。アクション(action)の要素はアルファベットの大文字と小文字を区別する必要があり、例えばname/cos:GetService などとします |
はい |
リソース resource | 権限の具体的なデータの記述に用いられます。リソースは6セグメント式で記述します。リソース定義の詳細は各製品によって異なります。リソース情報の指定方法については、作成したリソースステートメントに対応する製品ドキュメントをご参照ください | はい |
発効条件 condition | ポリシー発効の制約条件の記述に用いられます。条件はオペレーター、アクションキーとアクション値で構成されています。条件値には時間、IPアドレスなどの情報を含めることができます。一部のサービスは、条件に対しほかの値を指定することを認めています | いいえ |
エフェクト effect | ステートメントによる結果の記述に用いられます。allow(許可)とdeny(明示的な拒否)の2種類が含まれます | はい |
制限項目 | 制限値 |
---|---|
1つのルートアカウント内のユーザーグループ数 | 300 |
1つのルートアカウント内のサブアカウント数 | 1000 |
1つのルートアカウント内のロール数 | 1000 |
1つのサブアカウントに追加できるユーザーグループ数 | 10 |
1つのコラボレーターがコラボレートできるルートアカウント数 | 10 |
1つのユーザーグループ内のサブアカウント数 | 100 |
1つのルートアカウントが作成できるカスタムポリシー数 | 1500 |
1つのユーザー、ユーザーグループまたはロールに直接バインドできるポリシー数 | 200 |
1つのポリシー構文の最大文字数 | 4096 |
次のポリシーの記述例は、ルートアカウントID 100000000001(APPIDは1250000000)下のサブアカウントID 100000000011に対し、北京リージョンのバケットのexamplebucket-bjおよび広州リージョンのバケットのexamplebucket-gz下のオブジェクトexampleobjectについて、アクセスIPが10.*.*.10/24
セグメントの場合に、オブジェクトのアップロードおよびオブジェクトのダウンロード権限を許可するものです。
{
"version": "2.0",
"principal":{
"qcs": ["qcs::cam::uin/100000000001:uin/100000000011"]
},
"statement": [{
"effect": "allow",
"action": ["name/cos:PutObject", "name/cos:GetObject"],
"resource": ["qcs::cos:ap-beijing:uid/1250000000:examplebucket-bj-1250000000/*",
"qcs::cos:ap-guangzhou:uid/1250000000:examplebucket-gz-1250000000/exampleobject"
],
"condition":{
"ip_equal":{
"qcs:ip": "10.*.*.10/24"
}
}
}]
}
この記事はお役に立ちましたか?