API キーは、Google Maps Platform API と SDK を使用するアプリとプロジェクトに必要です。安全性を最大限に高め、手間を最小限に省くため、API キーの作成時には保護してください。
API キーは、作成後と使用中に保護できますが、キーの使用方法に応じてさまざまな制約を伴う場合があります。モバイルアプリ（Android と iOS）内のキーを更新したり置き換えたりする場合、すべてのお客様がアプリを更新するまではすべてのキーが置き換えられないため、最も複雑です。それに比べると、JavaScript アプリやウェブサービス アプリ内のキーの更新や置き換えははるかに単純ですが、それでも、これらのキーを更新したり置き換えたりする場合には、慎重に計画し、迅速に作業を行うことが求められます。
Google Maps Platform の個々のサービス（Maps JavaScript API など）に適したセキュリティ保護策については、詳細情報セクションをご覧ください。
API キーの制限
API キーを最初に作成する際には、アプリケーションの制限と 1 つ以上の API の制限を使って API キーを制限します。
アプリケーションの制限では、特定のプラットフォーム（Android や iOS）や特定のサイト（公開 IP アドレスとウェブサイト）に API キーの使用を制限します。個々の API キーに追加できるアプリケーションの制限は 1 種類のみです。
API の制限では、API キーの使用を、1 つ以上の Google Maps Platform API または SDK に制限します。API キー、または API キーに関連付けられた SDK の使用リクエストのみが処理されます。任意の API キーについて、API の制限を必要なだけ指定できます。
API キーの作成時にキーを保護しなかった場合は、追加の API キーを作成して制限し、それから新しい API キーを使ってすべてのアプリを更新します。 セキュリティ上は、アプリケーションごとに 1 つのキーを使用することが理想的ですが、キーに対するアプリの制限の種類を原因としてキーを共有するアプリとの互換性の問題が発生する場合を除き、複数のアプリで制限付きのキーを使用できます。
作成後に API キーを制限する場合は、API キーの使用状況を確認して、既存のアプリに影響が出ないようにしてください。
Google Cloud Console の [指標] ページに移動します。
[フィルタを表示] を選択します。
[グループ条件] で、[認証情報] を選択します。どの API キーがどの Google サービスで使用されているかを確認できます。
[認証情報] をクリックします。
すべての認証情報の選択を解除します。
表示されるキーごとに、キーを選択して [OK] をクリックします。
[グループ条件] で、[API] を選択します。キーに適用される API 制限が表示されます。
[グループ条件] から [API メソッド] を選択すると、キーに適したアプリケーション制限のタイプを判断する手掛かりが得られることがあります。
API キーのアプリケーション制限の設定
- [認証情報] ページに移動します。
制限を設定する API キーを選択します。選択した API キーのプロパティ ページが表示されます。
[キーの制限] で [アプリケーションの制限] を選択します。
いずれかの制限タイプを選択し、制限リストに沿って必要な情報を指定します。
制限タイプ 説明 HTTP リファラー リファラー（流入元）ウェブサイトを 1 つ以上指定します。ワイルドカード文字を使ってサブドメインを一括承認することも可能です（たとえば *.google.comと指定すれば、末尾が.google.comのサイトをまとめて承認できます）。https://とhttp://はそのまま指定します。他のリファラー URL プロトコルを指定する場合は特殊な記法が必要になります。たとえばfile:///path/to/は__file_url__//path/to/*と記述します。リファラーを有効化した後は、使用量が想定内で推移しているか確認しましょう。サポートされているリファラー プロトコルは、about://, app://, applewebdata://, asset://, chrome://, content://, file://, ftp://, ionic://, local://, ms-appx://, ms-appx-web://, ms-local-stream://, prism://, qrc://, res://, saphtmlp://です。IP アドレス IPv4 アドレスまたは IPv6 アドレスを 1 つ指定するか、CIDR 表記法を使用したサブネットを指定します。 ウェブサービスのウェブサービス リクエストでは、外部 IP アドレスを API キーの制限と照合して比較するため、サーバーの公開 IP アドレスを使用してください。 Android アプリ SHA-1 署名証明書フィンガープリントと、 AndroidManifest.xmlファイルの Android パッケージ名を追加します。iOS アプリ タイプの下で、リストから適切な iOS バンドル ID を選択します。 [保存] を選択します。
API キーの API 制限の設定
[認証情報] ページに移動します。
制限する API キーを選択します。 [API キーの制限と名前変更] ページが表示されます。
[API の制限] で次の操作を行います。
[キーを制限] をクリックします。
[API を選択] プルダウンをクリックし、API キーを使用してアプリケーションからアクセスする API または SDK を選択します。
（API または SDK がリストにない場合は、それを有効にする必要があります）
[保存] をクリックします。
この制限は、このステップの後に API キーの定義の一部となります。適切な情報を入力しなかった場合、または [保存] をクリックしなかった場合、API キーは制限されません（詳しくは、使用する API または SDK の API キーの取得ガイドをご覧ください）。
未使用の API キーの削除
API キーを削除する前に、それが本番環境で使用されていないことを確認してください。正常なトラフィックがない場合は、キーを削除しても問題ないことが見込まれます。
API キーを削除するには:
[認証情報] ページに移動します。
削除する API キーを選択します。
ページ上部の [削除] ボタンを選択します。
[認証情報の削除] ダイアログが表示されたら、[削除] を選択します。
API キーの削除が反映されるまでには数分かかることがあります。削除の反映後、削除された API キーを使用するトラフィックは拒否されます。
API を保護するその他の方法
API キーの再生成時に注意する
API キーを再生成すると、古いキーに設定されていたすべての制限を含む新しいキーが作成されます。また、この際、古い API キーを無効にする 24 時間のタイマーが開始されます。
この間は、古いキーと新しいキーの両方が承認されるため、新しいキーを使用するようにアプリを移行できます。ただし、引き続き古い API キーを使用しているアプリは、この期間が経過すると機能しなくなります。
API キーのページに移動します。
[以前のキーに戻す] を選択します。
[元に戻す] ダイアログで [キーを元に戻す] をクリックします。
ロールバックすると、キーの以前の「新しい」バージョンが以前のバージョンになり、それを無効にする 24 時間のタイマーが新しく設定されます。キーを再生成するまでは、この 2 つのキーの値の間で元に戻すことができます。
この 2 回目の再生成では、無効な古いキーの値が上書きされます。
API 使用状況のモニタリング
API キーの使用状況を確認するには:
[指標] ページに移動します。
[フィルタを表示] をクリックします。
[グループ条件] で [API メソッド] を選択します。
[レスポンス コード] で [2xx] を選択して、このキーへの成功したリクエストをすべて表示します。
不正使用が検出された場合は、以下の手順を行います。
キーを制限します。
同じキーが複数のアプリで使用されている場合は、可能であればアプリごとに個別の API キーを使って、複数の API キーに移行します。
アプリごとに個別の API キーを使用
これにより、各キーのスコープが制限されます。API キーが不正使用された場合は、他の API キーを更新しなくても、対象のキーのみを削除して再生成することができます。
複数の API キーへの移行
複数アプリでの 1 つの API キーの使用から、アプリごとに固有の単一の API キーの使用に移行するには、以下の手順を行います。
新しいキーが必要になるアプリを特定します。
- ウェブアプリの場合は、すべてのコードを自身で管理するため、最も簡単に更新できます。ウェブベースのアプリのキーはすべて更新するように計画します。
- モバイルアプリの場合は、お客様がアプリを更新するまで新しいキーは使用可能にならないため、はるかに困難です。
新しいキーを作成して制限します。
- アプリケーションの制限と、1 つ以上の API の制限の両方を追加します。
さまざまなアプリに新しいキーを追加します。
- モバイルアプリの場合、すべてのユーザーが新しい API キーを使って最新のアプリに更新するまでに数か月かかることがあります。
Maps Web Service API または Static Web API を使用するアプリを保護する方法
API キーと署名シークレットをアプリケーションのソースコードの外部に保存します。API キーやその他の非公開情報を環境変数に格納するか、個別に保存されているファイルを含めてからコードを共有した場合、API キーや署名シークレットは共有ファイルに含まれません。
アプリケーションのソースツリーの外部にあるファイルに API キーや署名シークレットを保存します。API キーやその他の非公開情報をファイルに保存する場合は、キーがソースコード管理システムに保存されないように、アプリケーションのソースツリーの外部にファイルを保管します。これは特に、GitHub のような公開ソースコード管理システムを使用する場合に重要です。
Web Service API または Static Web API を使用するモバイルアプリを保護する方法
プロキシ サーバーを使用します。プロキシ サーバーは、適切な Google Maps Platform API と通信するための信頼できるソースとして機能します。プロキシ サーバーの使用方法の詳細については、代理実行: Google Data API クライアント ライブラリとプロキシ サーバーの併用をご覧ください。
API キーまたは署名シークレットを難読化または暗号化します。これにより、API キーやその他の非公開データをアプリケーションから直接取得することが難しくなります。
詳細情報
これらの表は、Google Maps Platform API、SDK、またはサービスごとに適切な API キーの制限と API の保護に関するベスト プラクティスをまとめたものです。
Maps JavaScript、Embed API、Static API を使用したウェブサイト
| API / SDK / サービス | アプリケーションの制限（1） | API の制限（1） | ベスト プラクティス |
|---|---|---|---|
| Maps JavaScript API（2） | HTTP リファラーの制限 | Maps JavaScript API | |
| ルートサービス、Maps JavaScript API | HTTP リファラーの制限 | Directions API、Maps JavaScript API | |
| Distance Matrix Service、Maps JavaScript API | HTTP リファラーの制限 | Distance Matrix API、Maps JavaScript API | |
| Elevation Service、Maps JavaScript API | HTTP リファラーの制限 | Elevation API、Maps JavaScript API | |
| Geocoding Service、Maps JavaScript API | HTTP リファラーの制限 | Geocoding API、Maps JavaScript API | |
| Places Library、Maps JavaScript API | HTTP リファラーの制限 | Places API、Maps JavaScript API | |
| Maps Embed API | HTTP リファラーの制限 | Maps Embed API | |
| Maps Static API | HTTP リファラーの制限 | Maps Static API | |
| Street View Static API | HTTP リファラーの制限 | Street View Static API |
ウェブサービスを使用するアプリとサーバー
| API / SDK / サービス | アプリケーションの制限（1） | API の制限（1） | ベスト プラクティス |
|---|---|---|---|
| Address Validation API | IP アドレスの制限（4） | Address Validation API | |
| Directions API | IP アドレスの制限（4） | Directions API | |
| Distance Matrix API | IP アドレスの制限（4） | Distance Matrix API | |
| Elevation API | IP アドレスの制限（4） | Elevation API | |
| Geocoding API | IP アドレスの制限（4） | Geocoding API | |
| Geolocation API | IP アドレスの制限（4） | Geolocation API | |
| Places API（5） | IP アドレスの制限（4） | Places API | |
| Roads API | IP アドレスの制限（4） | Roads API | |
| Routes API | IP アドレスの制限（4） | Routes API | |
| Time Zone API | IP アドレスの制限（4） | Time Zone API |
Android アプリ
| API / SDK / サービス | アプリケーションの制限（1） | API の制限（1） | ベスト プラクティス |
|---|---|---|---|
| Maps SDK for Android | Android の制限 | Maps SDK for Android | |
| Places SDK for Android | Android の制限 | Places API |
iOS アプリ
| API / SDK / サービス | アプリケーションの制限（1） | API の制限（1） | ベスト プラクティス |
|---|---|---|---|
| Maps SDK for iOS | iOS の制限 | Maps SDK for iOS | |
| Places SDK for iOS | iOS の制限 | Places API |
1 Google Maps Platform の API または SDK では、制限のない API キーを使用できます。ただし、特に以下の状況では、API キーを制限することを強くおすすめします。
テスト環境が今後一般公開される、または一般公開されている。
API キーを使用するアプリケーションを、本番環境で使用する準備が整っている。
2 モバイルアプリの場合は、ネイティブの Maps SDK for Android と Maps SDK for iOS を使用することをおすすめします。
3 Maps Static API と Street View Static API では、1 日あたりの地図の読み込みが割り当ての 25,000 回を超過する場合、API キーに加えて、デジタル署名も指定する必要があります。
リクエストに署名する場合は、1 日に許可される未署名のリクエストの数を確認し、それに応じて未署名のリクエストの割り当てを調整します。
4 IP の制限は、動的 IP アドレスを使用するモバイル アプリケーションやクラウド環境など、状況によっては現実的でない場合があります。こうしたシナリオで Maps Web Service API を使用する場合は、プロキシ サーバーや難読化を使ってアプリを保護します。
5 モバイルアプリの場合は、ネイティブの Places SDK for Android と Places SDK for iOS を使用することをおすすめします。