よっしー
こんにちは。よっしーです(^^)
今日は、GCPにおけるIAMについて解説しています。
スポンサーリンク
背景
GCPにおけるIAMについて調査する機会がありましたので、その時の内容を備忘として記事に残しました。
GCPにおけるIAMとは
GCP（Google Cloud Platform）におけるIAM（Identity and Access Management）は、クラウドリソースへのアクセス制御を管理するためのサービスです。以下にIAMの主要な概念と特徴をまとめます：
- 基本概念
- Who（誰が）: アイデンティティ
- Can do what（何ができるか）: 権限
- On which resource（どのリソースに対して）: リソース
- アイデンティティ
- Google アカウント
- サービスアカウント
- Google グループ
- G Suite ドメイン
- Cloud Identity ドメイン
- ロールとその種類
- 基本ロール: Owner、Editor、Viewer（非推奨）
- 事前定義ロール: 特定のサービスやリソースに対する細かな権限セット
- カスタムロール: 組織固有のニーズに合わせて定義可能
- リソース階層
- 組織 > フォルダ > プロジェクト > リソース
- 権限は上位から下位に継承される
- ポリシー
- メンバー、ロール、条件（オプション）の組み合わせ
- リソースに対して設定され、そのリソースへのアクセスを制御
- サービスアカウント
- アプリケーションやVMインスタンス用の特別なアカウント
- 特定の権限を付与し、セキュアな認証を提供
- 条件付きアクセス
- アクセス時の条件（時間、IPアドレスなど）を指定可能
- IAM Recommender
- 機械学習を使用して、過剰な権限の削除を推奨
- Policy Analyzer
- 特定のリソースに対する権限を持つアカウントを可視化
- IAM監査ログ
- Cloud Auditログと統合され、アクセス履歴を記録
GCPのIAMを適切に利用することで、セキュリティを強化しつつ、必要な権限を効率的に管理できます。
ユースケース
GCPのIAMの主要なユースケースをいくつか紹介します：
- 開発チームの権限管理
- 開発者に必要最小限の権限を付与
- 例：開発環境のCompute Engineインスタンスへのアクセス権限
- 本番環境のセキュリティ強化
- 運用チームに特定のサービスの管理権限を付与
- 例：Cloud SQLの管理者権限、ただしネットワーク設定変更は不可
- 外部監査対応
- 監査者に読み取り専用の権限を一時的に付与
- 例：特定プロジェクトのCloud Auditログへの閲覧権限
- マルチテナント環境の分離
- 各顧客に独立したプロジェクトと権限を設定
- 例：共有VPCを使用しつつ、各顧客のリソースを分離
- CI/CDパイプラインの自動化
- デプロイ用のサービスアカウントに必要な権限を付与
- 例：Cloud BuildからGKEへのデプロイ権限
- データアナリストのアクセス制御
- BigQueryの特定のデータセットへの読み取り権限
- 例：匿名化されたデータへのアクセスは許可、生データへのアクセスは制限
- 時限的なアクセス権限
- 緊急時や特定のタスク用に一時的な権限を付与
- 例：障害対応時の24時間限定の管理者権限
- リソース階層を活用した権限管理
- 組織レベルでのポリシー設定
- 例：全プロジェクトでの公開ストレージバケットの作成禁止
- サードパーティツールの統合
- 監視ツールに必要最小限の権限を付与
- 例：Prometheusに特定のメトリクスの読み取り権限のみを付与
- コスト管理
- 財務チームに請求情報への閲覧権限を付与
- 例：Billing Accountへの閲覧権限、ただしプロジェクトリソースへのアクセスは不可
これらのユースケースは、組織のニーズや規模に応じて適用できます。IAMを効果的に活用することで、セキュリティを強化しつつ、業務効率を向上させることができます。
AWSとの違い
GCPのIAMとAWSのIAMには、いくつかの重要な違いがあります。以下に主な相違点をまとめます：
- リソース階層構造
- GCP: 組織 > フォルダ > プロジェクト > リソース
- AWS: アカウント > リソース（組織は別サービスのAWS Organizationsで管理）
- ポリシー管理
- GCP: リソースにポリシーを直接アタッチ
- AWS: IAMユーザー/グループ/ロールにポリシーをアタッチ
- 事前定義ロール
- GCP: 細かく分類された事前定義ロールが多数存在
- AWS: 比較的少数の管理ポリシーが存在、詳細な権限はカスタムポリシーで定義
- サービスアカウント
- GCP: プロジェクトレベルで管理されるリソース
- AWS: IAMロールとインスタンスプロファイルの組み合わせで実現
- グループ管理
- GCP: Google Groupsを利用
- AWS: IAMグループ機能が組み込まれている
- 一時的な認証情報
- GCP: サービスアカウントキーまたはCloud Identity-Aware Proxy
- AWS: 一時的なセキュリティ認証情報（STS）
- クロスアカウントアクセス
- GCP: リソース共有（例：共有VPC）、IAMポリシー
- AWS: クロスアカウントロール、リソースベースのポリシー
- 条件付きアクセス
- GCP: IAMポリシーに直接条件を組み込む
- AWS: IAMポリシーの条件キーを使用
- 権限の推奨
- GCP: IAM Recommenderが機械学習を用いて提案
- AWS: IAM Access Analyzerがポリシーの分析と推奨を提供
- 認証方法
- GCP: OAuth 2.0とOpenID Connectを主に使用
- AWS: 独自の認証システムを使用
- ネイミング規則
- GCP: リソース名に階層的な命名規則（projects//topics/など）
- AWS: ARN（Amazon Resource Name）を使用
- 権限の継承
- GCP: 上位階層から下位へ権限が継承される
- AWS: 明示的な権限付与が必要、継承はない
これらの違いは、クラウド環境の設計やセキュリティポリシーの実装方法に影響を与える可能性があります。どちらのプラットフォームを選択するかは、具体的なプロジェクト要件や既存のインフラストラクチャ、チームのスキルセットなどによって決まります。
おわりに
今日は、 GCPにおけるIAMについて解説しました。
よっしー
何か質問や相談があれば、コメントをお願いします。また、エンジニア案件の相談にも随時対応していますので、お気軽にお問い合わせください。
それでは、また明日お会いしましょう(^^)
コメント