こんにちは。SCSKの井上です。
New Relicを導入する際には、いくつかの鍵を正しく設定する必要があります。この記事では、ライセンスキーとユーザーキーの概要、用途、発行手順、そしてセキュリティを確保するための管理方法を解説します。鍵の種類や管理方法を理解するための参考になれば幸いです。
はじめに
New Relicへデータを送る際に使用する鍵(ライセンスキー/ブラウザキー)と、データを操作する際に使用する鍵(ユーザーキー)があります。これらの鍵は、外部システムとの連携や内部操作を安全に行うために不可欠な要素です。特に、APIキーは発行したユーザーの権限を継承するため、誰が発行するかによって操作可能な範囲が大きく変わります。どんな鍵があり、どの点に注意すべきかを解説していきます。
この記事はNew Relicを全く触ったことがないかたを対象としています。New Relicの無料プラン※を利用して操作を行いますので、New Relicを費用無しで実施いただくことができます。
※無料プランに含まれる内容は、月間100GBまでのデータ容量と全機能にアクセスできるユーザー1名です(Basicユーザについては無償)。無料プランの場合、一部機能に制約がある可能性はあります。
New Relicで扱う設定鍵について
アプリやサーバーからNew Relicにデータを送るためには、License Keyが必要です。New Relicのコンソールで見るだけならUser Keyは不要ですが、NerdGraph APIを使ってアラート設定やダッシュボードをスクリプトで自動化やAWSやAzureなどの外部連携する場合は、必要になります。
| キータイプ | 意味 | 主な用途 | 発行対象 |
| Ingest – License Key | New Relicにデータを送る「入口の鍵」。
データ送信用のAPIライセンスキー。APM、Infrastructure、ログなどのデータをNew Relicに送るために使用。 |
エージェント設定ファイル、環境変数、サードパーティー製品との連携など | アカウント
(組織単位) |
| Ingest – Browser Key | New Relicにデータを送る「入口の鍵」。
ブラウザ監視用のAPIライセンスキー。Webページに埋め込まれたNew RelicのJavaScriptエージェントがデータを送るために使用。 |
Browser monitoring
Webページに埋め込むJavaScriptエージェント用 |
アカウント
(組織単位) |
| User Key | 送られたデータを分析や設定を操作する「操作の鍵」。
API操作用の個人キー。ユーザーがNew Relicの設定やデータにアクセス・操作するために使用。NRAK-から始まる規則となっている。 |
NerdGraph API、Terraform設定など | 個人
(ユーザー単位) |
New Relicに初めてサインアップすると、デフォルトのLicense KeyとBrowser Keyが自動で作成されます。この鍵はアカウントに紐づいており、削除や変更はできません。セキュリティ上の理由から、独自に新しい鍵を発行して使用することが推奨されています。デフォルトの鍵は、初期設定時に誰でも知り得る可能性や、デフォルトのライセンスキーは削除することができないため、外部に漏れた際にサポートに問い合わせて新たな鍵を発行いただく間に、脅威は進行してしまいます。Full platform user権限を持つユーザであれば、いくつでもLicense keyおよびBrowser keyを作成することができ、削除も可能ですので、デフォルトの鍵は使わないようにした方が良いですね。
エージェントがデータを送る対象が「サーバーやバックエンド」からのデータであればLicense Key、「フロントエンド」からのデータであればBrowser Keyになります。Browser KeyはWebブラウザに埋め込むため、不特定多数に閲覧されます。もし、License KeyとBrowser Keyを分けずに使用した場合、予期せぬデータをNew Relicへ大量に送信し、課金されてしまう恐れがあります。そのため、リスクを抑えるためにも二つに分かれている設計になっているのですね。
モバイルアプリトークン用の鍵もありますが、モバイルエージェント導入時に説明することとして、この記事では割愛します。
New Relicライセンスキーの発行方法
ここでは実際にNew Relicのライセンスキーの発行手順について解説していきます。Full platform user権限を持つユーザーがライセンスキーを何度でも作成することができます。ライセンスキーの発行にお金もかかりません。ライセンスキーがたくさん作成されてしまうと管理が大変になりますので、組織に一つ、環境ごとに一つ、チームで一つなどセキュリティのリスクに応じて使い分けることを推奨します。
ライセンスキーはアカウント単位で管理されるため、誰が作成したかはNew Relicのコンソールから確認できません。命名規則を設けるか、備考欄にどのような用途の鍵なのかを記載しておくことで鍵の管理がしやすくなります。以下の手順にて作成ができます。
New Relicユーザーキーの発行方法
ここでは実際にNew Relicのユーザーキーの発行手順について解説していきます。ユーザーキーも何度でも発行は可能です。お金もかかりません。ライセンスキーと異なり、ユーザーキーについては自身以外に開示しないでください。ユーザーキーの発行はUser API Keys (for self)のロール権限が付与されていれば、Full platform user権限がなくても作成することができます(Standard rolesにおいて、Billing Userロール以外は付与されています)。
ユーザーキーは、発行したユーザーに割り当てられたロールの権限に基づいて動作します。たとえば、管理者ロールを持つユーザーが発行した場合、そのキーには管理者権限が付与されます。一方、Read-onlyロールのみを持つユーザーが発行した場合、そのキーは読み取り専用の権限しか持ちません。必要に応じて外部連携との設定する際は、ロール権限を最小限に抑えた専用のユーザーを推奨します。
ユーザーキーはユーザー単位で管理されるため、誰が作成したかNew Relicのコンソールから確認できます。以下の手順にて作成ができます。
発行済のNew Relicライセンスキーの確認方法
発行した鍵はNew Relicにログインすることで見れてしまうのか気になりますね。以前まではNew Relicコンソールにログインすることで見ることができていましたが、セキュリティ向上のため見ることができなくなりました。発行済のライセンスキーはライセンスキーのIDとユーザーキーの2つをもって確認することができます。ユーザーキーもわからない場合は、ユーザーキーを新規発行いただいてから、この手順を実施することができます。他のユーザーが発行したライセンスキーも見ることができます。
※クエリ文
query {
actor {
apiAccess {
key(id: "INGEST_KEY_ID", keyType: INGEST) {
key
name
type
... on ApiAccessIngestKey {
ingestType
}
}
}
}
}
鍵の管理方法について
各種鍵について、定期的なローテーションや設定鍵の棚卸、誤って設定キーが外部に流出しないよう、環境変数で管理することを推奨します。これにより、セキュリティリスクを抑えられます。Ingest License Key をローテーションする場合、古い鍵を使っているエージェントやアプリケーションが新しい鍵に更新されるまで、データ送信が停止する可能性があります。そのため、ローテーションする際は、すべてのデータが転送できていることをコンソール上から確認した上で、古い鍵を消す考慮が必要です。
鍵を作成したユーザーを削除した場合、鍵はどうなるのでしょうか。ユーザーキーはユーザーに紐づいていますが、ユーザーを削除してもそのユーザーが作成した鍵は残っています。ユーザーキーを完全に削除するには、API Keys画面より削除が必要です。ライセンスキーは アカウントに紐づいています。ユーザーキー同様にユーザーが削除されても そのユーザーが作成したライセンスキーは引き続き有効です。誤って設定鍵が外部に流出しないためにも、環境変数で管理することでリスクを抑えることも重要です。
モバイルアプリトークンについては、トークンを削除したり、追加のトークンを作成したりすることはできない旨、記載されています。トークンが流出した場合の対処については、公式の情報がないため、New Relic サポートに連絡することが必要です。
さいごに
New Relicへデータを送る際に使用する「鍵」と、データを操作する際に使用する「鍵」について解説しました。特に、APIキーは発行したユーザーの権限を継承するため、誰が発行するかによって操作可能な範囲が変わることについて、この記事を読んで、New Relicの設定鍵の運用に少しでもお役に立てれば幸いです。
SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。















