WEB問題集
あるプロジェクトでデータ分析者に BigQuery のクエリ実行と参照のみを許可したい場合、最小権限の原則に最も合致する設計はどれですか。
解説
【正解: B】の理由
最小権限の原則では、やりたいことに必要な権限だけを持つ事前定義ロールを選びます。クエリを実行する行為は BigQuery ではジョブの作成にあたり、roles/bigquery.jobUser がプロジェクト内でクエリを含むジョブを実行する権限を提供します。データを読む行為はこれとは別で、roles/bigquery.dataViewer をデータセットやテーブルに付与するとテーブルデータの取得やエクスポートができます。この 2 つを組み合わせると、分析者は自分でクエリを走らせて結果を参照できる一方、テーブルの作成や削除、他サービスの操作はできません。事前定義ロールは新機能の追加に合わせて Google が権限を更新するため、保守の手間もかかりません。
【サービス比較】
| 付与する内容 | 付与する階層 | 与えられる操作 |
|---|---|---|
| roles/bigquery.jobUser | プロジェクト | クエリなどジョブの実行 |
| roles/bigquery.dataViewer | データセット・テーブル | テーブルデータの参照とエクスポート |
| roles/editor | プロジェクト | BigQuery 以外も含むほぼ全リソースの変更 (過剰) |
| カスタムロール + resourcemanager.projects の全権限 | プロジェクト | IAM ポリシーの変更を含む管理操作 (過剰) |
| roles/owner + IAM Conditions | プロジェクト | 条件に合致しない経路では最上位の権限がそのまま残る |
【他の選択肢が不適切な理由】
- A: roles/editor はプロジェクト内のほぼすべてのリソースを変更できる基本ロールで、BigQuery 以外の操作まで許してしまい、必要な権限だけを与えるという要件から大きく外れます。
- C: resourcemanager.projects の権限を全付与すると IAM ポリシーの変更まで可能になり、カスタムロールを使っていても分析者に不要な管理権限を渡すことになります。
- D: roles/owner を付与したうえで条件式で絞る設計は、条件の記述漏れや対象外の経路が残れば最上位の権限がそのまま効いてしまうため、絞り込みの前提として危険です。
【参考】
BigQuery IAM roles and permissions本番環境の Compute Engine 管理者ロールを、緊急対応時のみ業務時間外に IP 制限付きで一時的に付与したい場合、最も適切な仕組みはどれですか。
解説
【正解: C】の理由
緊急対応のときだけ、業務時間外に、許可した IP からという複数の制限を同時にかけたいので、ロールの付与そのものに条件を付ける IAM 条件が適切です。IAM 条件は属性に基づく条件付きの認可を定義する仕組みで、request.time で要求の日時を、request.auth.access_levels で Access Context Manager のアクセスレベル (許可した IP 範囲や端末の属性) を参照できます。この 2 つを組み合わせた条件式を Compute Engine の管理者ロールのバインディングに付けておけば、条件を満たさない通常の時間帯や許可外の場所からの操作では権限が働きません。恒久的な特権を残さずに済み、期限も条件式によって自動的に切れます。
【サービス比較】
| 方式 | 時間帯と接続元を同時に条件化できるか | 補足 |
|---|---|---|
| IAM 条件 (request.time と request.auth.access_levels) | できる | 条件を満たさない時間帯や場所では権限が働かず、期限も自動的に切れる |
| サービスアカウントの鍵を共有して使わせる | できない | 期限のない認証情報を人手で回すことになり、操作者も特定できない |
| 基本ロール roles/owner を恒久的に付与する | できない | 緊急時以外も最上位の権限が有効なままで最小権限に反する |
| VPC Service Controls の境界を全許可にする | できない | API 呼び出しの境界制御であり、ロール付与の時間限定はできない |
【他の選択肢が不適切な理由】
- A: 鍵を共有して必要なときに使わせる運用は、有効期限のない認証情報を人の手で回すことになり、時間帯や接続元の条件を課すことも操作者を特定することもできません。
- B: 恒久的に owner を付与しておく設計は、緊急時以外も最上位の権限が有効なままとなり、一時的に付与するという要件にも最小権限の原則にも反します。
- D: VPC Service Controls は API 呼び出しの境界を制御する仕組みで、ロールの付与を時間帯で限定する機能はなく、境界を全許可にすれば防御そのものも失われます。
【参考】
IAM Conditions overviewGKE 上で動くアプリケーションが Cloud Storage にアクセスする必要があります。鍵を発行せずに最も安全な方式はどれですか。
解説
【正解: C】の理由
GKE の Workload Identity 連携を有効にすると、Pod からの認証情報の要求を GKE のメタデータサーバが受け取り、Kubernetes のサービスアカウントのトークンを Security Token Service で短命の連携アクセストークンに交換します。鍵ファイルをクラスタに置く必要がないため、鍵の配布や失効という運用そのものがなくなります。Kubernetes のサービスアカウントに Google のサービスアカウントを対応付けて借用させる構成に加えて、現在は Kubernetes のサービスアカウントのプリンシパルへ IAM のロールを直接付与する方式も使えます。いずれの場合も権限は名前空間とサービスアカウントの単位で分かれるため、Pod ごとに必要な権限だけを与えられます。
【サービス比較】
| 方式 | 使われる認証情報 | 権限の粒度 |
|---|---|---|
| Workload Identity 連携 | 短命の連携トークン (鍵なし) | Kubernetes のサービスアカウント単位 |
| SA 鍵を Secret に保存 | 期限のない鍵 | その Secret を読める Pod すべて |
| ノードの既定 SA | ノードに紐づく認証情報 | 同じノード上の Pod すべてで共有 |
| ユーザー個人の OAuth トークンを Pod へ渡す | 個人に紐づく一時トークン | その個人の権限のまま。監査上の主体も個人になる |
【他の選択肢が不適切な理由】
- A: 鍵を Kubernetes の Secret に保存する方式は、期限のない認証情報がクラスタ内に残り、その Secret を読める権限があれば持ち出せてしまうため、鍵を発行しないという要件から外れます。
- B: ノードに紐づく既定のサービスアカウントを使うと、同じノード上のすべての Pod が同じ権限を共有することになり、ワークロードごとの最小権限が成り立ちません。
- D: 個人の OAuth トークンを Pod に渡す方式は、担当者の異動や権限変更で動かなくなるうえ、監査上の実行主体も個人になってしまい、自動化された処理には適しません。
【参考】
Workload Identity Federation for GKEAWS EC2 上で稼働する CI システムから GCP の Artifact Registry に push したいです。鍵不要で実現する仕組みはどれですか。
解説
【正解: C】の理由
AWS 上の CI システムから鍵を持ち出さずに Google Cloud を操作させたいので、Workload Identity 連携で AWS をプロバイダとして登録します。EC2 に付いた AWS の IAM ロールが発行する一時的な認証情報をワークロードが提示すると、Google Cloud は AWS の呼び出し元を確認する API を用いてその正当性を検証します。Workload Identity プールに AWS のプロバイダを作り、引き受けたロールの ARN を主体の識別子として対応付ければ、特定のロールやインスタンスからの呼び出しだけを受け入れられます。その後は短命の認証情報でサービスアカウントを借用して Artifact Registry へ push でき、鍵の発行も配布も不要です。
【サービス比較】
| 方式 | 必要になる資格情報 | 鍵不要という要件との適合 |
|---|---|---|
| Workload Identity 連携で AWS をプロバイダ登録 | EC2 の IAM ロールが発行する一時的な認証情報 | 鍵の発行も配布も不要で要件に合致 |
| サービスアカウントキーを AWS 側の保管庫に保存 | 期限のない鍵 | 保管場所を変えただけで鍵は存在し続ける |
| 踏み台へ SSH して gcloud を実行 | 踏み台に置く資格情報と接続経路 | 新たな管理対象が増え CI にも組み込みづらい |
| EC2 用に Cloud Identity ユーザーを作成 | 人向けのパスワードと二段階認証 | 人の仕組みを機械に流用し管理主体もあいまいになる |
【他の選択肢が不適切な理由】
- A: 踏み台へ SSH で入って作業する方式は自動化された CI の流れに組み込みづらく、踏み台に置いた資格情報や接続経路そのものが新たな管理対象になってしまいます。
- B: 鍵を AWS 側の保管庫に置く方式は保管場所を変えただけで、期限のない認証情報が存在し続けるため、鍵を不要にするという要件を満たしません。
- D: 人が使うアカウントを EC2 用に発行する運用は、管理の主体があいまいになるうえ、パスワードや多要素認証を前提とする人向けの仕組みを機械に流用することになります。
【参考】
Workload Identity Federation with AWS組織階層で全プロジェクト共通に SecurityAdmin ロールを継承させ、特定 Folder ではそれを取り消したい要件があります。最も適切な実装はどれですか。
解説
【正解: C】の理由
上位で付与したロールを下位のフォルダだけで無効にしたいという要件です。IAM の許可ポリシーは階層に沿って継承され、下位で継承された付与を取り消すという操作はできません。これに対して拒否ポリシーは組織、フォルダ、プロジェクトへ添付でき、IAM は関連する拒否ポリシーを許可ポリシーより先に評価します。対象のフォルダに、そのロールが持つ権限を拒否する拒否ルールを添付すれば、組織から継承された付与が残っていても、その配下では権限が働かなくなります。拒否条件を書いて対象を絞ったり、例外とするプリンシパルを指定して一部の担当者だけを残したりすることもできます。
【サービス比較】
| 方式 | 下位での取り消し | 評価の順序 |
|---|---|---|
| 拒否ポリシーをフォルダへ添付 | できる | 許可より先に評価される |
| 許可ポリシーの継承 (フォルダで再付与しない) | できない | 上位の付与がそのまま継承される |
| プロジェクトのバインディングを手動削除 | できない | 継承された付与は削除の対象外 |
| Workforce Identity Federation で属性を切り替え | 該当しない | 外部 ID の連携で階層の権限評価には関与しない |
| 例外プリンシパル (拒否ルール内で指定) | 拒否の対象から外せる | 拒否ルールの評価時に適用される |
【他の選択肢が不適切な理由】
- A: 組織で付与したロールは配下へ継承されるため、フォルダで再付与しないという対応をとっても、継承された権限はそのまま有効に残ります。
- B: プロジェクトのバインディングを手で削除しても、上位から継承された付与そのものは消せないため、目的とする遮断にはなりません。
- D: Workforce Identity Federation は外部の ID を連携させる仕組みで、リソース階層のどこで権限を止めるかを制御する機能ではありません。