User KeyとLicense Keyの違いとは？ APIキーの役割と適切な管理方法を解説

1. はじめに

New Relicを使い始めると、各種エージェントの導入やクラウドインテグレーションなど、様々な場面でAPIキーが必要になります。中でも「User Key」と「License Key」は、最も基本的でありながら、その役割の違いを混同しやすいキーではないでしょうか。

これらのキーを正しく理解し使い分けることは、New Relicを効果的かつセキュアに活用するための第一歩です。本記事では、User KeyとLicense Keyの明確な違いを中心に、それらを含むNew RelicのAPIキー全体の体系、そして安全な管理方法までを体系的に解説します。

2. 2つのキーの最も重要な違い

詳細に入る前に、2つのキーの最も重要な役割の違いを理解しましょう。

• License Key (投入用): 監視対象からのデータを、New Relicに「入れる（投入する）」ための鍵です。
• User Key (操作用): New Relicに蓄積されたデータや設定を、API経由で「操作・管理する」ための鍵です。

この「投入」と「操作」という目的の違いが、全ての基本となります。

3. データを取り込むための「Ingest Keys」

データをNew Relicに送信（Ingest）するためのキー群を総称して「Ingest Keys」と呼びます。License Keyは、その最も代表的なものです。

3-1. バックエンド監視の基本「License Key」

License Keyの役割 エージェントから送信された監視データが、どのNew Relicアカウントに紐づくものかを認証・識別するための情報です。

より正確に言えば、エージェントは共通のデータ収集エンドポイントへデータを送信します。データを受け取ったNew Relicプラットフォーム側が、このLicense Keyを検証することで、リクエストが正規のものであることを確認し、お客様の特定アカウントへデータを振り分けています。このキーがなければ、New Relicは誰からのデータかを判断できず、データを受け付けることができません。

License Keyの取得方法 License Keyは、UI左下にあるご自身のユーザー名をクリックし、表示されるメニューから API Keys を選択することで管理画面にアクセスし、そこから確認・取得できます。

利用シーン 主にエージェントに設定して利用します。設定ファイルや環境変数として設定します。

• Infrastructureエージェントの設定例 (newrelic-infra.yml)

• 環境変数としての設定例

3-2. (補足) Browser/Mobileキーが分離されている理由

License Keyもデータ投入用ですが、ブラウザ監視やモバイルアプリ監視では、それぞれ「Browser Ingest Key」と「Mobile Application Token」という専用のキーが使われます。これらが分離されているのには、明確な理由があります。

最も大きな理由は、キーが使用される**「環境」と、それに伴う「セキュリティリスク」**の違いです。

1. キーの「公開範囲」とセキュリティリスク

• License Key（サーバーサイド）:
  • お客様が完全に管理できるサーバーやコンテナ環境（信頼できる環境）の内部で使用されます。適切に管理されていれば、外部に漏洩するリスクは非常に低いです。
• Browser / Mobile Key（クライアントサイド）:
  • これらのキーは、エンドユーザーのWebブラウザやスマートフォンアプリ（信頼できない環境）に埋め込まれます。つまり、ブラウザの開発者ツールやアプリの解析によって、悪意のあるユーザーを含む不特定多数に閲覧されることが前提となります。

もしサーバーサイドと同じ強力なLicense Keyをクライアントサイドで使い回した場合、キーが漏洩すると、偽のサーバーパフォーマンスデータなどを大量に送りつけられるリスクがあります。このリスクを避けるため、公開されても影響が限定的になるよう、クライアントサイド専用のキーが分離されているのです。

2. 最小権限の原則

セキュリティの重要な考え方である「最小権限の原則」に基づき、各キーにはそのタスク遂行に必要な最小限の権限のみが与えられています。

• Browser Ingest Keyに与えられているのは、「ブラウザ監視データを投入する」という最小限の権限のみです。
• Mobile Application Tokenには、「特定のモバイルアプリのデータを投入する」権限のみが与えられています。

これにより、万が一クライアントサイドのキーが漏洩しても、攻撃者がそのキーを使ってサーバーエージェントになりすますことはできません。影響範囲を最小限に抑えるための設計なのです。

このように、キーを分離することは、New Relicプラットフォーム全体のセキュリティとデータの信頼性を維持するために不可欠な仕組みとなっています。

4. データや設定を操作するための「User Key」

4-1. User Keyの役割

User Keyは、NerdGraph (GraphQL API) などを介して、New Relicのデータ取得やアラート設定の変更などをプログラムから行うための認証情報です。

このキーの最も重要な特徴は、その名の通り特定のユーザーに紐づけて発行される点です。これにより、User Keyを使って行われたAPI操作は、すべて「誰が」実行したかという情報と共に監査ログに記録されます。これは、システムの変更履歴を追跡し、セキュリティとガバナンスを維持する上で非常に重要です。

また、User Keyで実行できる操作の範囲は、キーに紐づくユーザーの権限によって厳密に決まります。具体的には、以下の2つの要素に制限されます。

1. ユーザータイプ (User Type): Basic User, Core User, Full Platform Userといったユーザーの種類によって、アクセスできる機能の範囲が異なります。
2. ロール (Role): All product admin, Standard user, Read onlyなど、割り当てられた標準の役割（ロール）によって、データの閲覧、作成、更新、削除といった操作の可否が定義されます。

例えば、閲覧権限しかないユーザーのキーでは設定変更のAPI呼び出しは失敗し、Full Platform UserかつAll product adminロールを持つユーザーのキーであれば、広範な管理操作が可能になります。

4-2. User Keyの取得方法

User Keyは、License Key同様に、UI左下にあるご自身のユーザー名をクリックして表示されるメニューから API Keys を選択し、管理画面で作成・管理します。

4-3. 主な利用シーン

• NerdGraph APIによるデータ照会・操作
• Terraform New Relic Providerでのリソース管理
• 自作のスクリプトやアプリケーションとの連携

4-4. (補足) ガイド付きインストールに関するよくある質問

User Keyの利用シーンとして、利用者から特に多く寄せられるのが、ガイド付きインストールに関する次のような質問です。

• 「なぜデータ投入用のエージェントをインストールする際に、操作・管理用のUser Keyが必要なのですか？」
• 「インストール時に使ったユーザーを後から削除した場合、監視エージェントは止まってしまいますか？」

ここでは、これらの疑問に回答します。このプロセスは、巨大な物流倉庫の管理システムに例えると非常に分かりやすくなります。

• User Key: 倉庫全体のオペレーションを司る「倉庫管理システムの管理者ID」です。管理者はこれを使って、在庫の配置変更や保管ルールの設定など、倉庫全体を操作します。
• License Key: 登録された運送トラック（エージェント）が、荷物（データ）を搬入するためだけに使用する「専用搬入ゲートの認証キー」です。

ガイド付きインストローラーは、まず管理者ID（User Key）を使ってシステムに正規アクセスし、「このトラック（エージェント）に、このゲートの利用を許可する」という設定を行います。そして、そのトラックに対して正式な搬入ゲートの認証キー（License Key）を発行・設定しているのです。

この仕組みを理解すれば、先ほどの質問の答えが明確になります。

結論として、インストール時に使用したUser Keyや、それに紐づくユーザーアカウントを後から削除しても、すでに稼働しているエージェントには一切影響はありません。

なぜなら、一度認証キー（License Key）を受け取ったトラック（エージェント）は、インストール作業を行った管理者（ユーザー）がその場にいなくなったとしても、自身のキーを使って正当に荷物を搬入し続けるからです。User Keyとそれに紐づくユーザーはインストールという「設定作業」にのみ関与し、その後のエージェントの「監視データの送信」には関与しないのです。

5. セキュアなキー管理のためのベストプラクティス

キー管理の重要性

これらのキーは、システムの機密情報へのアクセス権そのものです。万が一漏洩した場合、設定の不正な変更・削除や、意図しないデータ送信による課金など、重大なセキュリティインシデントに繋がるリスクがあります。

具体的な管理方法

• 作成時に必ずキーを安全な場所に保管する New Relicの各種APIキーは、セキュリティ上の理由から、UI上で表示されるのは作成時の一度きりです。画面を閉じてしまうと、その後UIからキーの文字列を再度確認することはできません。そのため、キーを作成したら、ただちにパスワードマネージャーやAWS Secrets Manager、HashiCorp Vaultといったキー管理ソリューションに保管することが不可欠です。もし既存のキーの文字列が必要になった場合は、NerdGraph APIを介して参照するか、事前に保管した場所から取得する必要があります。
• ソースコードに直接記述しない User KeyやLicense Keyをコードに直接書き込む（ハードコーディング）のは避け、環境変数や前述のシークレット管理ツールを利用しましょう。

• Gitリポジトリにコミットしない .gitignore に設定ファイルを追加するなど、誤ってキー情報をコミットしないための仕組みを導入することが不可欠です。
• User Keyには必要最小限の権限を付与する User Keyは、紐づくユーザーの権限を引き継ぎます。APIで利用するキーには、その目的に応じた最小限の権限を持つ専用のユーザーを割り当てることを推奨します。
• 定期的な棚卸しとローテーション 担当者の退職や異動など、不要になったUser Keyは速やかに削除し、定期的にキーを見直して再発行（ローテーション）する運用が理想的です。
• デフォルトキーの使用を避け、自身でキーを作成する New Relicのアカウントを開設すると、いくつかのAPIキーが自動的に作成されます。これらのデフォルトキーは、ユーザー自身で削除したり再発行（ローテーション）したりすることができず、変更が必要な場合はNew Relicのサポートへ依頼する必要があります。 この制約のため、セキュリティのベストプラクティスとして、デフォルトキーは使用せず、目的ごとに自身で管理できる新しいAPIキーを作成して利用することを強く推奨します。これにより、キーのライフサイクル（作成、ローテーション、削除）を完全にコントロール下に置くことができます。

6. まとめ

本記事の要点を振り返ります。

• APIキーは、データを「入れる」ためのLicense Key (Ingest Keys)と、データを「操作する」ためのUser Keyに大別されます。
• License Keyは、エージェントがデータを投入するための、搬入ゲートの認証キーのようなものです。
• User Keyは、API経由でNew Relicを管理するための、倉庫管理システムの管理者IDのようなものです。
• クライアントサイド（ブラウザ/モバイル）では、セキュリティリスクを考慮し、権限が限定された専用のキーが使われます。
• 全てのキーは重要な認証情報であり、漏洩を防ぐためのセキュアな管理が不可欠です。

キーの適切な管理は、オブザーバビリティ環境の安定性とセキュリティの土台となります。これを機に、Terraformによる監視のコード化など、一歩進んだ活用法にも挑戦してみてはいかがでしょうか。