クラウド プロフェッショナルであるあなたは、Azure Identity and Access Management(IAM)アーキテクチャにすでに精通しており、そのベスト プラクティスに従った経験があるかもしれません。IAM に関する一般的な懸案事項として、次のようなものがあります。
リソースへのアクセスを管理する一番良い方法
ユーザーが実際に必要なリソースにのみアクセスできるようにする方法
Azure では、組織は IAM、Azure Active Directory(Azure AD)ユーザー、ロールの組み合わせを、接続されているポリシーとともに使用して、さまざまな Azure アカウントへのアクセスを制御します。
Azure AD はマルチテナントのクラウドベースのディレクトリで、Azure リソースに対するアクセス制御と管理を提供する ID 管理サービスです。
次に、Google Cloud で IAM 制御を実装する方法を確認しましょう。
概要
このラボでは、サービス アカウント ユーザーのロールを使用する方法とロールを付与する方法について学習します。
目標
このラボでは、次のタスクの実行方法について学びます。
IAM を使用してアクセス制御を実装する
特定の機能やリソースへのアクセスを制限する
サービス アカウント ユーザーのロールを使用する
ラボの設定
各ラボでは、新しい Google Cloud プロジェクトとリソースセットを一定時間無料で利用できます。
[ラボを開始 ] ボタンをクリックします。ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。
左側の [ラボの詳細 ] パネルには、以下が表示されます。
[Google Cloud コンソールを開く ] ボタン
残り時間
このラボで使用する必要がある一時的な認証情報
このラボを行うために必要なその他の情報(ある場合)
[Google Cloud コンソールを開く ] をクリックします(Chrome ブラウザを使用している場合は、右クリックして [シークレット ウィンドウで開く ] を選択します)。
ラボでリソースが起動し、別のタブで [ログイン ] ページが表示されます。
ヒント: タブをそれぞれ別のウィンドウで開き、並べて表示しておきましょう。
注: [アカウントの選択 ] ダイアログが表示されたら、[別のアカウントを使用 ] をクリックします。
必要に応じて、下のユーザー名 をコピーして、[ログイン ] ダイアログに貼り付けます。
{{{user_0.username | "Username"}}}
[ラボの詳細 ] パネルでもユーザー名 を確認できます。
[次へ ] をクリックします。
以下のパスワード をコピーして、[ようこそ ] ダイアログに貼り付けます。
{{{user_0.password | "Password"}}}
[ラボの詳細 ] パネルでもパスワード を確認できます。
[次へ ] をクリックします。
重要: ラボで提供された認証情報を使用する必要があります。Google Cloud アカウントの認証情報は使用しないでください。
注: このラボでご自身の Google Cloud アカウントを使用すると、追加料金が発生する場合があります。
その後次のように進みます。
利用規約に同意してください。
一時的なアカウントなので、復元オプションや 2 要素認証プロセスは設定しないでください。
無料トライアルには登録しないでください。
その後、このタブで Google Cloud コンソールが開きます。
注: Google Cloud のプロダクトやサービスのリストを含むメニューを表示するには、左上のナビゲーション メニュー をクリックするか、[検索 ] フィールドにサービス名またはプロダクト名を入力します。
タスク 1. 2 人のユーザーを設定する
1 人目のユーザーとして Cloud コンソールにログインする
[接続の詳細 ] ダイアログでこのラボ用の 2 つのユーザー名が提供されています。Qwiklabs で提供されている Username 1 を使用して、シークレット ウィンドウで通常どおりに Cloud コンソールにログインします。なお、両方のユーザー名で、同じパスワードを使用します。
2 人目のユーザーとして Cloud コンソールにログインする
シークレット ウィンドウで別のタブを開きます。
console.cloud.google.com にアクセスします。
画面右上にあるユーザー アイコンをクリックし、[アカウントを追加 ] をクリックします。
Qwiklabs で提供されている Username 2 を使用して、Cloud コンソールにログインします。
注: このラボの途中で Username 1 アカウントからログアウトすると、Qwiklabs によって Username 2 アカウントが削除されます。そのため、Username 2 での作業が終わるまで、Username 1 にログインしたままにしてください。タスク 2. IAM コンソールを確認する
Cloud コンソールの [Username 1 ] タブを開いていることを確認します。
IAM コンソールに移動してロールを調べる
ナビゲーション メニュー ( )で、[IAM と管理 ] > [IAM ] をクリックします。
[アクセスを許可 ] をクリックして、プルダウン メニューでロールを確認します。[ロールを選択 ] では、各リソースに関連付けられているさまざまなロールを確認できます。
[キャンセル ] をクリックします。
Cloud コンソールの [Username 2 ] タブに切り替えます。
ナビゲーション メニュー ( )で、[IAM と管理 ] > [IAM ] をクリックします。リストを参照して、Qwiklabs の [接続の詳細 ] ダイアログの Username 1 と Username 2 に関連付けられている名前がある行を見つけます。
注: 現在、Username 2 はプロジェクトにアクセスできますが、プロジェクト オーナーのロールが割り当てられていないため、どのロールも編集できません。これについては、Username 2 の鉛筆アイコンにカーソルを合わせると確認できます。
Cloud コンソールの [Username 1 ] のタブに戻ります。
IAM コンソールで、Username 2 の鉛筆アイコンをクリックします。現在、Username 2 には閲覧者 のロールが付与されています。プロジェクトのロールは変更しないでください。
[キャンセル ] をクリックします。
タスク 3. アクセステストのためのリソースを準備する
バケットを作成してサンプル ファイルをアップロードする
Cloud コンソールの [Username 1 ] タブに切り替わっていない場合は、このタブに切り替えます。
ナビゲーション メニュー ( )で、[Cloud Storage ] > [バケット ] をクリックします。
[+ 作成 ] をクリックします。
次のように指定し、残りの設定はデフォルトのままにします。
プロパティ
値(値を入力するか、指定されたオプションを選択)
名前
グローバルに一意の名前を入力
ロケーション タイプ
マルチリージョン
注: バケット名をメモしておきます。この後のステップで [YOUR_BUCKET_NAME] という名前で参照されます。
[作成 ] をクリックします。
注: [パブリック アクセスの防止 ] ダイアログが表示され、オプション [このバケットに対するパブリック アクセス禁止を適用する ] がオンになっていることが確認できたら、[確認 ] をクリックします。
[ファイルをアップロード ] をクリックします。
ローカルマシンから任意のサンプル ファイルをアップロードします。
ファイルがアップロードされたら、そのファイルの名前が表示されている行の末尾にあるその他アイコンをクリックして、[名前を変更 ] をクリックします。
ファイルの名前を sample.txt に変更してから、[名前を変更 ] をクリックします。
[進行状況を確認 ] をクリックして、目標に沿って進んでいることを確認します。
バケットを作成してサンプル ファイルをアップロードする
プロジェクト閲覧者のアクセス権を確認する
Cloud コンソールの [Username 2 ] タブに切り替えます。
Cloud コンソールのナビゲーション メニュー で、[Cloud Storage ] > [バケット ] に移動します。
Username 2 がバケットを認識できることを確認します。
タスク 4. プロジェクトへのアクセス権を削除する
Username 2 のプロジェクト閲覧者のロールを削除する
Cloud コンソールの [Username 1 ] タブに切り替えます。
ナビゲーション メニュー ( )で、[IAM と管理 ] > [IAM ] をクリックします。
[Username 2 ] を選択し、[アクセス権を削除 ] をクリックします。
注: Username 2 のアクセス権を削除することを確認します。
Username 1 のアクセス権を誤って削除した場合は、このラボを最初からやり直す必要があります。
[確認 ] をクリックして確定します。
このユーザーがリストから消去されていると、アクセス権が取り消されていることになります。
[進行状況を確認 ] をクリックして、目標に沿って進んでいることを確認します。
プロジェクトへのアクセス権を削除する
Username 2 がアクセス権を失ったことを確認する
Cloud コンソールの [Username 2 ] タブに切り替えます。
ナビゲーション メニュー ( )で、[Cloud の概要 ] > [ダッシュボード ] をクリックします。
ナビゲーション メニュー ( )で、[Cloud Storage ] > [バケット ] をクリックします。エラーが表示されます。表示されない場合は、ページを更新します。Username 2 には引き続き Google Cloud アカウントがありますが、プロジェクトへのアクセス権はありません。
タスク 5. ストレージへのアクセス権を追加する
ストレージの権限を追加する
Qwiklabs の [接続の詳細 ] ダイアログから Username 2 の値をコピーします。
Cloud コンソールの [Username 1 ] タブに切り替えます。
ナビゲーション メニュー ( )で、[IAM と管理 ] > [IAM ] をクリックします。
[アクセスを許可 ] をクリックしてユーザーを追加します。
[新しいプリンシパル ] に、Qwiklabs の [接続の詳細 ] ダイアログからコピーした Username 2 の値を貼り付けます。
[ロールを選択 ] で、[Cloud Storage ] > [Storage オブジェクト閲覧者 ] をクリックします。
[保存 ] をクリックします。
[進行状況を確認 ] をクリックして、目標に沿って進んでいることを確認します。
ストレージの権限を追加する
Username 2 がストレージへのアクセス権を得たことを確認する
Cloud コンソールの [Username 2 ] タブに切り替えます。
注: Username 2 にはプロジェクト閲覧者のロールがないため、コンソールにプロジェクトやプロジェクトのリソースは表示されません。ただし、このユーザーには Cloud Storage に特化したアクセス権があります。
Cloud Shell を起動するには、Cloud Shell をアクティブにする アイコン( )をクリックします。プロンプトが表示されたら、[続行 ] をクリックします。
前に作成したバケットの内容を表示するには、次のコマンドを実行します。[YOUR_BUCKET_NAME]
は、作成した Cloud Storage バケットの一意の名前に置き換えます。
gcloud storage ls gs://[YOUR_BUCKET_NAME]
ここからわかるとおり、Username 2 の Cloud Storage へのアクセス権は一部が制限されています。
Cloud コンソールの [Username 2 ] タブを閉じます。
この後、このラボでの作業は Cloud コンソールの [Username 1 ] タブで行います。
Cloud コンソールの [Username 1 ] タブに切り替えます。
タスク 6. サービス アカウント ユーザーを設定する
ここでは、サービス アカウントに限定的な権限を割り当てます。また、サービス アカウント ユーザーのロールを使用する方法についても学習します。
サービス アカウントを作成する
ナビゲーション メニュー ( )で、[IAM と管理 ] > [サービス アカウント ] をクリックします。
[+ サービス アカウントを作成 ] をクリックします。
[サービス アカウント名 ] に「read-bucket-objects 」と入力します。
[作成して続行 ] をクリックします。
[ロールを選択 ] で、[Cloud Storage ] > [Storage オブジェクト閲覧者 ] をクリックします。
[続行 ] をクリックします。
[完了 ] をクリックします。
ユーザーをサービス アカウントに追加する
[read-bucket-objects ] サービス アカウントをオンにします。
サービス アカウント名の右にあるその他アイコンをクリックし、次に [権限を管理 ] をクリックします。
注: ユーザーにサービス アカウント ユーザーのロールを付与します。これにより、このユーザーに VM へのアクセス権があれば、その VM でサービス アカウントを使用できるようになります。この操作は特定のユーザー、グループ、ドメインに対して行うことができます。ここではトレーニングのため、Altostrat.com という会社の全従業員にサービス アカウント ユーザーのロールを付与します。Altostrat.com はデモとトレーニングのために使用する架空の会社です。
[アクセスを許可 ] ボタンをクリックします。次のように指定し、残りの設定はデフォルトのままにします。
プロパティ
値(値を入力するか、指定されたオプションを選択)
新しいプリンシパル
altostrat.com
ロール
[Service Accounts] > [サービス アカウント ユーザー]
[保存 ] をクリックします。
Compute Engine へのアクセス権を付与する
次に、Altostrat の組織全体に Compute Engine 管理者のロールを割り当てます。
ナビゲーション メニュー ( )で、[IAM と管理 ] > [IAM ] をクリックします。
[アクセスを許可 ] をクリックします。
次のように指定し、残りの設定はデフォルトのままにします。
プロパティ
値(値を入力するか、指定されたオプションを選択)
新しいプリンシパル
altostrat.com
ロールを選択
[Compute Engine] > [Compute インスタンス管理者(v1)]
[保存 ] をクリックします。
注: このステップは、特定のユーザーに対して行う操作の練習です。
このアクションにより、ユーザーには VM インスタンスに対する限定的な権限が付与されます。ユーザーは SSH 経由で VM に接続し、一部の管理タスクを実行できます。サービス アカウント ユーザーで VM を作成する
ナビゲーション メニュー ( )で、[Compute Engine ] > [VM インスタンス ] をクリックします。
[インスタンスを作成 ] をクリックします。
次のように指定し、残りの設定はデフォルトのままにします。
プロパティ
値(値を入力するか、指定されたオプションを選択)
名前
demoiam
リージョン
ゾーン
シリーズ
E2
マシンタイプ
e2-micro(2 個の vCPU、1 GB メモリ)
ブートディスク
Debian GNU/Linux 11(bullseye)
サービス アカウント
read-bucket-objects
アクセス スコープ
API ごとにアクセス権を設定
ストレージ
読み取り / 書き込み
[作成 ] をクリックします。
[進行状況を確認 ] をクリックして、目標に沿って進んでいることを確認します。
サービス アカウント ユーザーを設定して VM を作成する
タスク 7. サービス アカウント ユーザーのロールについて調べる
この時点で、ユーザーにアクセス権をテストさせるために、SSH 経由で VM に接続してこの後のアクションを実行してもらいます。プロジェクトのオーナーとして、あなたにはすでにサービス アカウント ユーザーのロールがあります。そのため、Cloud コンソールから SSH を使用して VM にアクセスするだけで、ユーザーと同じ動作をシミュレーションできます。
実行するアクションとその結果は、ターゲットのユーザーが行う場合と同じです。
サービス アカウント ユーザーを使用する
demoiam で [SSH ] をクリックし、ターミナルを起動して接続します。
次のコマンドを実行します。
gcloud compute instances list
結果(出力の例) :
ERROR: (gcloud.compute.instances.list) Some requests did not succeed:
- Required 'compute.zones.list' permission for 'projects/qwiklabs-gcp'
どうなりましたか?それはなぜでしょうか?
前に作成したバケットから sample.txt ファイルをコピーします。末尾のピリオドは以下のコマンドの一部です。これは「この場所」にコピーすることを表します。
gcloud storage cp gs://[YOUR_BUCKET_NAME]/sample.txt .
結果(出力の例) :
Copying gs://train-test-iam/sample.txt...
/ [1 files][ 28.0 B/ 28.0 B]
Operation completed over 1 objects/28.0 B.
コピーしたファイルの名前を変更するには、次のコマンドを実行します。
mv sample.txt sample2.txt
名前を変更したファイルを再度バケットにコピーするには、次のコマンドを実行します。
gcloud storage cp sample2.txt gs://[YOUR_BUCKET_NAME]
結果(出力の例) :
AccessDeniedException: 403 Caller does not have storage.objects.create access to bucket train-test-iam.
注: 事象の概要を説明します。
SSH 経由でインスタンスに接続しているため、基本的には同じ権限を引き継いだまま、「サービス アカウントとして機能」することができます。インスタンスの起動に使用したサービス アカウントには Storage 閲覧者のロールがあります。このロールでは、プロジェクトの GCS バケットからオブジェクトをダウンロードできます。
プロジェクトのインスタンスを一覧表示するには、compute.instance.list 権限を付与する必要があります。サービス アカウントにはこの権限がなかったため、プロジェクト内で実行されているインスタンスの一覧は表示できませんでした。
サービス アカウントにはオブジェクトをダウンロードする権限があった ため、バケットからオブジェクトをダウンロードすることはできました。オブジェクトを書き込む権限はなかったため、「403 access denied」というメッセージが表示されました。
ナビゲーション メニュー ( )で、[IAM と管理 ] > [IAM ] をクリックします。
リストを参照して read-bucket-objects の行を見つけ、鉛筆アイコンをクリックします。現在、read-bucket-objects には Storage オブジェクト閲覧者 のロールが付与されています。[ロール ] を [Cloud Storage ] > [Storage オブジェクト作成者 ] に変更します。
[保存 ] をクリックします。
demoiam の SSH ウィンドウに戻ります。
名前を変更したファイルを再度バケットにコピーするには、次のコマンドを実行します。
gcloud storage cp sample2.txt gs://[YOUR_BUCKET_NAME]
今回は、サービス アカウントに正しい権限が付与されているため、コマンドが成功します。
タスク 8. まとめ
このラボでは、IAM のロールをユーザーに付与してから取り消す演習を行いました。最初はユーザー Username 2 、次にサービス アカウント ユーザーを対象にしました。サービス アカウント ユーザーの認証情報を割り当てて VM に「ベイク」し、特定の目的で承認された踏み台インスタンスを作成しました。
概要
Azure と Google Cloud のどちらにおいても、IAM はさまざまなサービスやリソースへのアクセスを安全に制御できるようにするウェブサービスです。このツールを使用して、認証(アクセスできるユーザー)と認可(可能な操作)を管理できます。
また、次のようなさまざまなプリンシパルを作成、管理することもできます。
Google Cloud IAM と Azure AD は、その仕組みについて多くの類似点があります。どちらのシステムも、ロールベース アクセス制御、多要素認証、ユーザー管理など、クラウド インフラストラクチャのセキュリティ保護を容易にするさまざまな機能を提供しています。また、どちらのシステムでも、きめ細かいポリシーを使用して、管理タスクの委任やリソースへのアクセスの制御を行うことができます。
また、いくつかの相違点もあります。Google Cloud IAM は、直観的でわかりやすいユーザー インターフェースを使用します。一方で Azure AD は、条件付きアクセスや、他のアプリケーションとの統合シングルサインオンなどの機能を使用します。
ラボを終了する
ラボが完了したら、[ラボを終了 ] をクリックします。ラボで使用したリソースが Google Cloud Skills Boost から削除され、アカウントの情報も消去されます。
ラボの評価を求めるダイアログが表示されたら、星の数を選択してコメントを入力し、[送信 ] をクリックします。
星の数は、それぞれ次の評価を表します。
星 1 つ = 非常に不満
星 2 つ = 不満
星 3 つ = どちらともいえない
星 4 つ = 満足
星 5 つ = 非常に満足
フィードバックを送信しない場合は、ダイアログ ボックスを閉じてください。
フィードバックやご提案の送信、修正が必要な箇所をご報告いただく際は、[サポート ] タブをご利用ください。
Copyright 2020 Google LLC All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。