この記事では、Google Cloud における”認証”、”認可”の仕組みや
IAMの基本用語からOAuth2やサービスアカウントなど
よく使う用語をわかりやすく解説します。
簡単なまとめ
認証：本人確認を行うこと
認可：誰が何をできるかの権限管理
IAM（Identity and Access Management）：
リソースに対して”誰”が”何”をできるかを定義する仕組み
プリンシパル：”誰”の部分（ユーザー、グループ、サービスアカウントなど）
サービスアカウント：サーバー間通信や自動化処理で用いる「非人間ユーザー」
権限：”何”の部分（閲覧、編集、管理など）
ロール：関連する複数の権限をひとまとまりにしたもの
OAuth2：エンドユーザーが自分のデータにアクセス権をアプリに与える仕組み
ADC（Application Default Credentials）：
認証方法は様々だけど、ADCはその環境が持っている情報（JSON キーやユーザー認証情報）を使って良い感じに認証してくれる
1. 認証（Authentication）と認可（Authorization）の違い
1.1 認証（Authentication）
認証とは「あなたは誰ですか？」を確かめるプロセスです
- ユーザー認証：ADCなどでユーザー認証情報を受け取り認証する
- サービスアカウント認証：サービスアカウントキーを使い認証する
-
OAuth2：
Webやモバイルのアプリで、ユーザーがGoogle Driveなどの自分のサービスへ
アクセス許可を与える際に使います
OAuth2の典型的なフローは以下のとおりです- Google API Console で OAuth2 クライアント ID とシークレットを取得
- 認可サーバーにリクエストを送り、承認画面を経て認可コードを取得
- 認可コードでアクセストークンを交換し、API 呼び出し時にトークンを添付する
1.2 認可（Authorization）
認可とは「この主体がこのリソースに対して何をできるか」を管理する仕組みです
- IAM ポリシー：リソース階層（組織 > フォルダ > プロジェクト > リソース）ごとにポリシーを結びつけ、プリンシパル（ユーザーやサービスアカウント）と ロール（権限のまとまり）を紐づけます
- 権限：API メソッドや操作などを行うための権限
-
ロールの種類：
- 基本ロール：全権限、読み書き、読み取りのみなどの基本的な権限セット
- 事前定義ロール：BigQuery 管理者などのGoogle 提供の細かな権限セット
- カスタムロール：権限をカスタムした自作ロール
2. 主な認証方法とその使いどころ
2.1 gcloud CLI を使ったユーザー認証
-
gcloud auth login：個人ユーザーとして CLI を認証 -
gcloud auth application-default login：ADC 用にユーザー認証トークンを設定
2.2 サービスアカウント認証（サーバー間通信向け）
- 長期認証：ダウンロードした JSON キーを環境変数に設定（簡単、キー流出リスク大）
- 短期認証：トークン（一定期間有効なキーのようなもの）を取得し使用
- Workload Identity Federation：Kubernetes や他クラウド上の ID プロバイダー（OIDC/SAML）と連携し、サービスアカウントキー不要でトークンを発行
2.3 Application Default Credentials（ADC）
ADC はライブラリが実行環境に応じて以下の順序で認証情報を探索します
- 環境変数
GOOGLE_APPLICATION_CREDENTIALSが指す JSON キー - ローカルに
gcloud auth application-default loginで設定したユーザー情報 - GCE／GKE 上で割り当てられたサービスアカウント
- Cloud Shell や Cloud Functions／Cloud Run などのランタイム用自動付与アカウント
3. 権限の注意点
-
最小権限の原則（Least Privilege）
ロールは必要最低限の権限に留める -
サービスアカウントキーの管理
可能な限りキーではなくトークンや Workload Identity を使う -
カスタムロールの活用
ロールの権限が余分な場合は必要な権限のみのカスタムロールを作成する -
監査ログの有効化
Cloud Audit Logs で実際の認証・認可イベントを記録し、異常検知に役立てる