IAM 認証

Google Cloud には Identity and Access Management（IAM）機能があり、特定の Google Cloud リソースに対するアクセス権を設定できるため、他のリソースへの不要なアクセスを防ぐことができます。このページでは、Cloud SQL を IAM と統合する方法と、IAM を使用して Cloud SQL リソースへのアクセスを管理し、データベース認証を行う方法について説明します。Google Cloud IAM の詳細については、IAM のドキュメントをご覧ください。

Cloud SQL リソースへのアクセス権を制御できるように、Cloud SQL には事前定義ロールが用意されています。事前定義ロールの中に必要な権限を付与するものがない場合は、独自にカスタムロールを作成することもできます。また、以前の基本ロール（編集者、閲覧者、オーナー）もまだ使用できますが、Cloud SQL ロールほど細かい制御はできません。特に、基本ロールは Cloud SQL だけではなく、Google Cloud 全体のリソースへのアクセス権を付与します。Google Cloud の基本ロールの詳細については、基本ロールをご覧ください。

IAM ポリシーは、リソース階層の任意のレベル（組織レベル、フォルダレベル、プロジェクト レベル）で設定できます。リソースは親リソースのポリシーをすべて継承します。

Cloud SQL 用 IAM リファレンス

IAM 認証のコンセプト

IAM 認証を使用する場合、リソース（Cloud SQL インスタンス）へのアクセス権はエンドユーザーに直接付与されません。代わりに、複数の権限をロールにまとめて、プリンシパルに付与します。詳細については、IAM の概要をご覧ください。

IAM データベース認証を使用してログインする管理者は、IAM ポリシーを使用してインスタンスへのアクセス制御を一元管理できます。

IAM ポリシーには、次のエンティティが含まれます。

  • プリンシパル。Cloud SQL では、ユーザー アカウント、サービス アカウント（アプリケーション用）またはグループという複数のタイプのプリンシパルを使用できます。詳細については、ID に関するコンセプトをご覧ください。
  • ロール。ロールとは、一連の権限のことです。プリンシパルにロールを付与して、特定のタスクの実行に必要な権限を付与できます。たとえば、IAM データベース認証では、プリンシパルがインスタンスにログインするために cloudsql.instances.login 権限が必要です。この権限は Cloud SQL インスタンス ユーザーロールに含まれています。この権限を取得するには、ユーザー、サービス アカウント、またはグループを Cloud SQL 事前定義ロールか、この権限を含むカスタムロールにバインドします。IAM ロールの詳細については、ロールについてをご覧ください。
  • リソース。プリンシパルがアクセスするリソースは Cloud SQL インスタンスです。デフォルトでは、IAM ポリシー バインディングはプロジェクト レベルで適用されるため、プリンシパルはプロジェクト内のすべての Cloud SQL インスタンスのロール権限を受け取ります。

IAM データベース認証

データベース認証とは、データベースにアクセスしようとしているユーザーの身元を確認するプロセスです。Cloud SQL では、データベース ユーザーに対して次の種類のデータベース認証を使用できます。

  • データベースの組み込み認証。ユーザー名とパスワードを使用してデータベース ユーザーを認証します。
  • IAM データベース認証。アクセス トークンと IAM を使用してユーザーの認証を行います。

データベース認証オプションを比較する

次の表は、Cloud SQL のさまざまなデータベース認証方法を比較したものです。

機能 組み込みデータベース認証 IAM データベース認証（個別） IAM グループ認証
認証方法 パスワード 一時的な認証トークン 一時的な認証トークン
ネットワーク トラフィックの暗号化 SSL 不要 SSL 必要 SSL 必要
ユーザー管理 手動 IAM で一元化 IAM と Cloud Identity グループで一元化

IAM グループ認証

IAM グループ認証を使用すると、グループレベルで Cloud SQL ユーザーを管理できます。グループの例として、Cloud Identity グループがあります。この機能により、データベースのユーザー管理が簡素化されます。複数のアカウントの Cloud SQL IAM ロールや権限を一度に管理できます。個々のユーザーまたはサービス アカウントを個別に更新する必要はありません。Cloud Identity グループに対してデータベース権限を付与するか、取り消すこともできます。Cloud Identity グループに追加した新しいアカウントは、そのグループの権限を継承します。

IAM グループ認証を使用すると、次のことができます。

  • グループにユーザーを追加し、そのユーザーが IAM ロールとデータベース権限を自動的に継承するようにします。
  • グループからユーザーを削除して、Cloud SQL データベースからログイン アクセスとデータベース権限を削除します。
  • 異なるユーザーに同じ権限を複数回付与する代わりに、グループにログイン権限またはデータベース権限を一度だけ付与します。
  • グループのログイン権限またはデータベース オブジェクトへのアクセスを一度に削除します。

IAM ロールと権限はグループレベルで割り当てられますが、ユーザーとサービス アカウントは、ログインに共有グループ アカウントではなく、個々の IAM アカウントと認証情報を使用します。Cloud SQL は、最初のログイン後に、そのユーザーまたはサービス アカウントのデータベース アカウントをインスタンスに作成します。

監査ログには、各ユーザーまたはサービス アカウントの個別のログイン アクティビティとデータベース アクティビティが表示されます。監査目的で、どのアカウントがデータベースでどのアクションを実行したかを表示できます。

Cloud Identity グループの操作の詳細については、Cloud Identity の概要をご覧ください。

グループにユーザーまたはサービス アカウントを追加すると、Cloud SQL で次の変更が行われます。

  • グループに IAM ログイン権限をすでに付与している場合、ユーザーまたはサービス アカウントはグループに属しているため、ユーザーまたはサービス アカウントは Cloud SQL インスタンスにログインできます。
  • ユーザーは、グループに付与されているデータベース権限を自動的に継承します。

グループからユーザーまたはサービス アカウントを削除すると、Cloud SQL で次の変更が行われます。

  • ユーザーは、グループのメンバーになることによって以前継承されたデータベース権限を失います。
  • ユーザーが他のグループ メンバーを通して Cloud SQL インスタンスに対する IAM ログイン権限を受け取ると、ログインできる場合があります。ただし、ユーザーはログイン時に、以前のグループ メンバーのデータベース権限を失います。

IAM グループ認証のベスト プラクティス

  • Cloud Identity で IAM グループのログイン権限（cloudsql.instances.login）を取り消す場合は、Cloud SQL インスタンスからもグループを削除してください。
  • Cloud Identity からグループを削除する場合は、そのグループを Cloud SQL インスタンスからも削除してください。
  • グループを使用して、データベースにロールベース アクセス制御を構成します。グループには常に必要最小限の権限を付与します。
  • 組み込みユーザーに IAM グループ認証ロールを付与しないでください。たとえば、組み込みのユーザー user-a があり、IAM グループ認証ユーザー user-b@example.com を作成した場合、user-b@example.com ロールを user-a に付与しないでください。

IAM グループ認証の制限

  • IAM グループ認証を使用していて、リードレプリカを含む Cloud SQL インスタンスがある場合は、リードレプリカ インスタンスにログインする前に、プライマリ インスタンスにログインする必要があります。プライマリ インスタンスに初めてログインすると、グループ ユーザー情報が読み取りレプリカに複製されます。その後のログインでは、リードレプリカに直接ログインできます。
  • 1 つのインスタンスに追加できる IAM グループは 200 個までです。
  • 同じインスタンスのグループに属する個々の IAM ユーザーまたはサービス アカウントを追加することはできません。つまり、CLOUD_IAM_GROUP_USER または CLOUD_IAM_GROUP_SERVICE_ACCOUNT タイプの同一のアカウントがすでに存在する場合、CLOUD_IAM_USER または CLOUD_IAM_SERVICE_ACCOUNT タイプのアカウントは追加できません。
  • CLOUD_IAM_USER または CLOUD_IAM_SERVICE_ACCOUNT タイプのインスタンスに個人アカウントがすでに存在する場合、そのアカウントを IAM グループ認証に使用することはできません。これらのユーザータイプは、グループから IAM ロールとデータベース権限を継承しません。

    この問題を修正して、アカウントを IAM グループ認証で使用するには、個々の IAM ユーザーまたはサービス アカウントを削除します。

    詳細については、既存の IAM ユーザーまたはサービス アカウントが、そのグループに付与されているデータベース権限を継承しないをご覧ください。
  • アカウントの追加など、Cloud Identity のグループ メンバーの変更が反映されるまでに約 15 分かかります。これは、IAM の変更に必要な時間とは別のものです。

IAM データベースの自動認証と手動認証

Cloud SQL for PostgreSQL には、IAM データベース認証に 2 つのオプション（自動と手動）があります。

IAM データベースの自動認証

IAM データベースの自動認証を使用すると、Cloud SQL Auth Proxy や Cloud SQL 言語コネクタなどの中間の Cloud SQL コネクタにアクセス トークンのリクエストと管理を任せることができます。IAM データベースの自動認証では、ユーザーは、クライアントからの接続リクエストで IAM データベースのユーザー名のみを渡す必要があります。コネクタは、クライアントに代わってパスワード属性のアクセス トークン情報を送信します。

IAM データベースの自動認証では、Cloud SQL コネクタを使用する必要があります。これは、Cloud SQL Auth Proxy、Go コネクタ、Java コネクタ、Python コネクタでサポートされています。

安全性と信頼性を確保するには、IAM データベース自動認証を使用することをおすすめします。IAM データベース認証では OAuth 2.0 アクセス トークンを使用します。このアクセス トークンは有効期間が短く、1 時間のみ有効です。Cloud SQL コネクタは、これらのトークンをリクエストして更新できます。これにより、有効期間が長いプロセスや接続プールに依存するアプリケーションの接続を安定させることができます。手動認証ではなく、IAM データベースの自動認証を行うことを強くおすすめします。

詳細については、IAM データベースの自動認証によるログインをご覧ください。

IAM データベースの手動認証

IAM データベースの手動認証では、IAM プリンシパルは、クライアント接続リクエストでパスワード属性のアクセス トークンを明示的に渡す必要があります。プリンシパルはまず Google Cloud にログインし、IAM からのアクセス トークンを明示的にリクエストする必要があります。

gcloud CLI を使用すると、データベースにログインするために使用される Cloud SQL Admin API スコープで OAuth 2.0 トークンを明示的にリクエストできます。IAM データベース認証でデータベース ユーザーとしてログインする場合は、メールアドレスをユーザー名として使用し、アクセス トークンをパスワードとして使用します。この方法は、データベースへの直接接続または Cloud SQL コネクタで使用できます。

IAM データベース認証を使用したログインは、SSL 接続経由でのみ実行できます。

詳しくは、IAM データベースの手動認証によるログインをご覧ください。

ユーザーとサービス アカウントの管理

IAM データベース認証を使用して、インスタンスのデータベースに対するユーザーとサービス アカウントのアクセスを許可するには、そのユーザーをインスタンスに追加するか、インスタンスにアクセスできるグループに追加する必要があります。詳細については、IAM を使用するユーザーまたはサービス アカウントの追加をご覧ください。

Google Cloud コンソールを使用してユーザーまたはサービス アカウントを追加する場合、Cloud SQL から「Cloud SQL ユーザー」ロールを追加するよう求められます。このロールは、ユーザーがインスタンスにログインするために必要です。

gcloud または API を使用してユーザーを追加する場合は、ログイン権限を手動で付与する必要があります。PostgreSQL GRANT コマンドを使用してデータベース権限を付与します。

Cloud SQL IAM データベース認証のインスタンス構成

インスタンスで IAM データベース認証を有効にするには、cloudsql.iam_authentication フラグを使用します。このフラグを有効にすると、インスタンスで IAM データベース認証用に構成されたアカウントのログインが有効になります。

このフラグは、IAM グループ認証と IAM データベース認証に必要です。

このフラグを設定した場合でも、IAM を使用しない既存のユーザーは、ユーザー名とパスワードを使用してログインできます。ただし、このフラグをインスタンスで無効にすると、以前に IAM データベース認証を使用して追加したユーザーはインスタンスにアクセスできなくなります。詳しくは、IAM データベース認証のインスタンスの構成をご覧ください。

さまざまなインスタンス シナリオに対する Cloud SQL IAM データベース認証

リードレプリカ プライマリ インスタンスで IAM データベース認証が有効になっている場合でも、リードレプリカでは自動的に有効になりません。作成したリードレプリカに IAM データベース認証を追加する必要があります。詳細については、IAM データベース認証のリードレプリカ ログインを構成するをご覧ください。
復元されたインスタンス 以前にバックアップされたインスタンスを同じプロジェクト内の同じインスタンスまたは別のインスタンスに復元した場合、現在のユーザー ログイン認証が適用されます。別のプロジェクトの新しいインスタンスにバックアップを復元する場合は、新しいインスタンスのユーザー認証を設定する必要があります。詳細については、IAM データベース認証を使用するユーザーまたはサービス アカウントの追加をご覧ください。

IAM Conditions について

IAM Conditions を使用すると、さまざまな属性に基づいてロールを付与できます。たとえば、特定の日時にのみアクセスを許可することや、特定の名前の Cloud SQL リソースにのみアクセス権を付与することが可能です。

IAM Conditions の詳細については、IAM Conditions の概要をご覧ください。また、Cloud SQL での IAM Conditions の使用の詳細（例を含む）もご覧ください。

Cloud Audit Logs を使った操作

監査ログを使用すると、ログインなどのデータアクセスの記録を保持できます。デフォルトでは、Cloud Audit Logs は無効になっています。ログインをトラッキングするには、データアクセスの監査ログを有効にする必要があります。この目的で監査ロギングを使用すると、データロギングの費用が発生します。詳細については、監査ログ、データアクセス監査ログの構成、データロギングの料金をご覧ください。

制限事項

  1. IAM データベース認証ユーザー アカウントのログインはすべて小文字にする必要があります。例: example-user@example.comExample-User@example.com は許可されません。
  2. セキュリティ上、IAM データベース認証を使用したログインは SSL 接続でのみ使用できます。暗号化されていない接続は拒否されます。
  3. 各インスタンスには分単位のログイン割り当てがあります。これには、成功したログインと失敗したログインの両方が含まれます。割り当てを超過すると、一時的にログインできなくなります。頻繁なログインを避けるとともに、承認済みネットワークを使用してログインを制限することをおすすめします。ログインの承認の割り当ては、インスタンスごとに 1 分あたり 12,000 です。

次のステップ