コンテンツに移動
データベース

Cloud SQL IAM データベース認証によるアプリケーションのセキュリティ

2023年2月16日
Google Cloud Japan Team

※この投稿は米国時間 2023 年 2 月 8 日に、Google Cloud blog に投稿されたものの抄訳です。

複雑なアプリケーションのセキュリティを強化するのは簡単なことではありません。異なる認証スキームを使用した複数のレイヤーを含むアプリケーションの場合はなおさらです。お客様からはよく、「Cloud SQL for PostgreSQL または MySQL を認証フローに統合する方法は?」というご質問をいただきます。

Cloud SQL は常にパスワードベースの認証をサポートしてきました。ただし、このアプローチには次のような多くの問題があります。

  • パスワードをどこに保存すべきか。

  • 環境ごとに異なるパスワードをどのように管理するか。

  • パスワードの複雑さを監査するのは誰か。

理想的には、パスワードについてまったく心配する必要がないことが望ましいでしょう。ユーザー名とパスワードによる認証を使用すると、ID チェーンも壊れることになります。パスワードを知っていれば誰でもデータベース ロールになりすますことができるため、監査ファイルに対するアクションを特定の人物(またはサービス アカウント)に帰することは、実質的に不可能です。さらに、アカウントを無効にするには、関連付けられているすべてのデータベース ログイン情報を見つけて無効にする必要があります。しかし、同一のログイン情報を他の誰も共有していないことをどう確認したらよいでしょうか。

このアプローチでは、うまくスケールできないことは明らかです。一例として、複数のアプリケーションで複数のデータベース インスタンスを管理すれば、作業は途方もなく困難になります。こうした課題を解決するために、Cloud SQL for PostgreSQL と MySQL のユーザーは、自動認証を備えた Cloud SQL Proxy で、Cloud SQL Identity and Access Management(IAM)にマッピングされたログイン情報を使用できます。

Cloud SQL IAM にマッピングされたログイン

Cloud SQL の IAM データベース認証機能を使用すると、既存の Cloud IAM プリンシパル(ユーザーまたはサービス アカウント)をデータベース ネイティブ ロールにマッピングできます。IAM プリンシパルのメールアドレスに一致するログイン情報を作成するよう、Google Cloud Platform(GCP)にリクエストすることができるのです。

また、パスワードの処理も GCP が行います(保存とローテーションを含む)。では、どうすればこの機能を使用できるのでしょうか。

アカウントに有効な IAM 認証情報(cloudsql.instances.login)がある場合、認証に使用できるトークンが Google Cloud から提供されます。基本的には、Google Cloud から Cloud SQL のパスワードが提供されます。このパスワードを使用すれば、Cloud SQL for PostgreSQL と MySQL に直接接続できます。

この操作は、(手動の IAM データベース認証を介して)自分で行うこともできますが、gcloud sql generate-login-token を発行するときなどに、自動的に処理されるようにするのが最善です。Google Cloud には、このタスクを自動化する多くの言語用のコネクタが用意されています(この処理の一例として、こちらで PostgreSQL 用の Golang ドライバの動作を確認できます)。こうしたコネクタを使用すると、Cloud SQL for PostgreSQL と MySQL の認証を安全かつ便利に行うことができます。

残念ながら、新しいドライバを利用するためにアプリケーション コードを変更する余裕が常にあるとは限りません。その場合は、Cloud SQL Auth Proxy と呼ばれる Google Cloud が提供するプロキシを使用できます。このプロキシを使用すると、コードベースを変更することなく、アプリケーションで新しい自動 IAM データベース認証を利用できます。

Cloud SQL Auth Proxy

Cloud SQL Auth Proxy には、自動 IAM データベース認証機能が備わっています。これにより、Cloud SQL IAM プリンシパルを認識しないアプリケーションでも IAM プリンシパルとして認証できるようになります。

たとえば、Cloud SQL Auth Proxy がサービス アカウントのコンテキストで実行されている場合(それが実行されている Compute Engine からサービス アカウントが継承された場合など)、プロキシに接続するすべての接続をそのサービス アカウントとして認証できます。

次の図は、アプリケーションを Cloud SQL に直接接続する代わりに、同じ Compute Engine インスタンスで実行されている Cloud SQL Auth Proxy プロセスに接続する方法を示しています。Proxy は、安全な TLS 接続を介して Cloud SQL インスタンスへの認証と接続を処理します。

https://storage.googleapis.com/gweb-cloudblog-publish/images/1_Cloud_SQL_IAM.max-1500x1500.jpg

TCP または Linux ドメイン ソケットを使用したローカルホスト接続のみを受け入れるように Cloud SQL Auth Proxy を構成することが重要です。アプリケーションは、パスワードを使用せず、サービス アカウント名のみを指定します(サービス アカウントの場合、これは .gserviceaccount.com ドメイン サフィックスを除くサービス アカウントのメールです)。パスワードは、Cloud SQL Auth Proxy によって透過的に追加されます。

サイドカーを介した Cloud SQL Auth Proxy の追加

Cloud SQL Auth Proxy を使用して、GKE 接続を保護することもできます。これをサイドカー コンテナとして追加すると、上記と同じ結果が得られます。この場合、Kubernetes ネットワークの分離に依拠して、許可された接続のみが Cloud SQL Auth Proxy に到達するようにします。

https://storage.googleapis.com/gweb-cloudblog-publish/images/2_Cloud_SQL_IAM.max-1500x1500.jpg

例として、以下を含む下記の YAML Kubernetes テンプレート ファイルを参照できます。

  • Workload Identity を使用して GKE サービス アカウントを使用するための構成

  • Cloud SQL for PostgreSQL に接続するアプリケーションの空のデプロイ仕様の例

  • Cloud SQL Proxy をサイドカー コンテナとして実行するためのデプロイ仕様

アプリケーションは、localhost 接続を使用して PostgreSQL データベースにアクセスするように構成する必要があります。アプリケーションとサイドカー コンテナが同じネットワークを共有することで、セキュリティが保証されます。接続のユーザー名は、サービス アカウントのメールアドレスから .gserviceaccount.com ドメイン サフィックスを除いたものにする必要があります。

https://storage.googleapis.com/gweb-cloudblog-publish/images/3_Cloud_SQL_IAM.max-1600x1600.jpg

Cloud SQL for PostgreSQLMySQL の詳細なドキュメントをご覧ください。また、サイドカー コンテナとして実行される Cloud SQL Proxy の例については、こちらをご覧ください。

Cloud SQL for PostgreSQL の自動監査

Cloud SQL for PostgreSQL と MySQL は、データプレーンとコントロール プレーンの両方のアクセスを監査するように構成できます。これは、関連する機能を有効にすることで実行できます。PostgreSQL の場合はこちら、MySQL の場合はこちらで概要をご確認いただけます。

監査証跡を調べる

Google Cloud の監査の非常に重要な側面のひとつは、すべての収集されたすべてのデータが 1 か所に集約されることです。同じことが Cloud SQL for PostgreSQL の監査証跡にも当てはまります。お客様は複雑でエラーが発生しやすい監査パイプラインを管理する必要がありません。このことは、セキュリティ タスク、特に規制の対象となるタスクではきわめて重要です。データは Google Cloud Log Explorer で調べることができます。また、SQL を好むユーザーは、新しい Log Analytics エンジンを利用することもできます。Log Analytics を使用すれば、監査証跡から貴重な情報を簡単に抽出できます。

以下の例では、直近の 1 時間に構成済みの Cloud SQL for PostgreSQL インスタンスに対して発行されたユーザー、データベース、ステートメントをクエリで抽出しています。

https://storage.googleapis.com/gweb-cloudblog-publish/images/4_Cloud_SQL_IAM.max-1600x1600.jpg
https://storage.googleapis.com/gweb-cloudblog-publish/images/6_Cloud_SQL_IAM.max-2000x2000.jpg

これだけではありません。同じクエリを BigQuery で実行できるため、Looker Studio または Looker を BigQuery に接続して、便利なダッシュボードを作成できます。Looker を活用することで、特定のイベントが発生するたびに自動アラートが作成されるようにすることもできます。たとえば、週末の異常なアクセスや、特定のユーザーによる短期間での異常な数の操作などにアラートを設定することが可能です。

次の画像は、Looker で構築されたデモ ダッシュボードを示すものです。プルダウン フィルタを使用すれば、SQL に精通していない人でも簡単にデータを探索できることに注目してください。

https://storage.googleapis.com/gweb-cloudblog-publish/images/5_Cloud_SQL_IAM.max-900x900.jpg

まとめ

統合された IAM 認証の最新の機能により、お客様はアプリケーションでエンドツーエンドの認証を活用できるほか、Google Cloud のクラス最高の監査機能を利用できます。Google Cloud に必要なツールが用意されているため、アプリケーションのソースコードにアクセスできない場合でも、IAM 認証の利用をすぐに開始できます。

他の機能と同様に、Google Cloud とそのパートナーが実装をサポートいたします。お気軽にお問い合わせください。


- Google Cloud データ管理担当 CE、Francesco Cogno
Google Cloud データ管理担当 CE、Davide Malagoli
投稿先