コンテンツに移動
Google Cloud

ハイブリッド クラウドのセキュリティ : Cloud Endpoints による API 呼び出しの認証

2017年10月19日
Google Cloud Japan Team

オンプレミスからクラウドへのシフトが一気に行われたり、完全に行われたりすることはまずありません。新しいワークロードはクラウドで構築されるものの、古いワークロードがそのままオンプレミスで運用されることもあります。また、一部のサービスだけをとりあえず移行し、新規の開発については引き続き自前のインフラストラクチャで行うことも珍しくありません。そしてもちろん、デプロイ先として複数のクラウドを利用している企業はたくさんあります。

サービスをさまざまなリソースやロケーションで実行するときは、それらのサービス間で通信のセキュリティを確保する必要があります。とはいえ、それは容易ではないでしょう。一部の問題はネットワーキングで解決できるかもしれませんが、困難なケースも多くあるはずです。たとえば、コンテナ化されたワークロードを 3 社の異なるハードウェアで実行している場合、そのトラフィックを保護する VPN のセットアップは至難の業です。

ネットワーキングを介して API 呼び出しのセキュリティを確保しようとするのではなく(あるいはそれに加えて)、Google Cloud Endpoints を使って API 呼び出しの認証や認可を行うお客様が増えています。実際、ハイブリッド環境全体にわたって API 呼び出しのセキュリティを強化することは、Cloud Endpoints を導入した企業の最初のユース ケースの 1 つでした。

Google Cloud Platform(GCP)へのワークロードの移行過程では、複数のデータセンター間で通信のセキュリティを強化することが必要でした。ファイアウォールや場当たり的な認証といった旧来の方法では、あっという間に ACL がぐちゃぐちゃになってしまい、とても対応できません。一方、Cloud Endpoints は標準化された認証システムを提供してくれました。

Laurie Clark-Michalek 氏、Qubit のインフラストラクチャ エンジニア

Cloud Endpoints は、NGINX をベースとするオープンソースの Extensible Service Proxy(ESP)を使用しており、JSON Web Token(JWT)や API キーなどさまざまな認証スキームに対応しています。App Engine flexible environment で Cloud Endpoints を使う場合は自動的にこのプロキシがデプロイされますが、Google Container Engine やオンプレミス、他社クラウドでも Google Container Registry を介してデプロイできます。

https://storage.googleapis.com/gweb-cloudblog-publish/images/8wpgWldtugr-rHEVZyfF9UE6nAC4FhwY-s2JajpT0Y.max-1000x1000.PNG

JWT による API 保護

JWT の要求は最も一般的で比較的セキュアな API 保護方法の 1 つです。通常、個々のサービスはサービス アカウントで表され、それぞれのサービス アカウントには JWT の署名に使用できる秘密鍵を付与します。

呼び出し元サービスが GCP 上で実行されている場合は、Google がお客様のために鍵を自動的に管理します。JWT の IAM.signJwt メソッドを呼び出し、結果として得られる署名済み JWT を呼び出しの OAuth Authorization: Bearer ヘッダに書き込みます。

サービスがオンプレミスで実行されている場合は、サービスに対するすべてのトラフィックのプロキシとして ESP をインストールしてください。ESP は、どのサービス アカウントが呼び出しを行っているかを API 設定から判断し、そのサービス アカウントの公開鍵を使用して、署名の正しさと JWT のその他のフィールドの正しさをチェックします。

オンプレミスのサービスがクラウドを呼び出す場合も JWT の署名が必要になりますが、お客様がご自身で秘密鍵を管理しなければなりません。その場合は(秘密鍵のセキュアな格納を可能にするベスト プラクティスに従い)Cloud Console から秘密鍵をダウンロードして JWT に署名します。

詳細は、サービス間認証に関するコードおよびドキュメント(gRPC を使っている場合はこちら)を参照してください。

API キーによる API 保護

API キーは、厳密に言うと認証トークンではありません。認証トークンよりも寿命が長く、盗まれればより危険です。とはいえ、ヘッダかクエリ パラメータを使って呼び出しに API キーを付加すれば、手っとり早く簡単に API を保護できるのです。

API キーを使用すると、API のコンシューマーが自分の認証情報を生成することもできます。個人情報を必要としない Google Maps や JavaScript API などの Google API を呼び出したことがあれば、そのときに API キーを使っています。

API へのアクセスを API キーによって制限するときは、こちらの指示に従ってください。そのあとでキーの生成が必要になります。キーは同じプロジェクトで生成できます(こちらの指示に従います)。

もしくは、ほかのデベロッパーとプロジェクトを共有し、API を呼び出すプロジェクトで API キーを生成して、API を有効にすることも可能です。API 呼び出しのキーは、クエリ パラメータ(リクエストへの key=${ENDPOINTS_KEY} の付加)または x-api-key ヘッダに追加できます(詳細はこちらのドキュメントを参照してください)。

まとめ

どこで実行するかにかかわらず、API の保護はグッド プラクティスです。Google では、両方のサービスが自社の本番ネットワークで実行されている場合でも、サービス間通信には認証を使っています。しかし、ハイブリッド クラウドの世界では、すべての呼び出しを認証することはもっと重要になります。

Cloud Endpoints を使い始めるときには、こちらのチュートリアルを参考にしてください。Cloud Endpoints は、さまざまなクラウドやオンプレミス環境にまたがって展開される、スケーラブルでセキュアなアプリケーションを構築するうえでとても役に立ちます。

* この投稿は米国時間 9 月 18 日、Product Manager である Dan Ciruli によって投稿されたもの(投稿はこちら)の抄訳です。

- By Dan Ciruli, Product Manager

投稿先