1分で読了エンジニアリング

APIキーの権限: リンクツールの最小権限

リンクツールのAPIキー権限の正しい設計。ワークスペース単位のキー、ロールによる上限、ペッパー付きハッシュ、キーごとのレート制限。

Marius Voß
DevRel · edge infra

APIキーの権限は、漏えいしたキーが何を壊せるかを決めます。リンクツールでの安全な既定値は、1つのワークスペースに紐づき、その作業をこなせる最低のロールを上限とし、ペッパー付きハッシュで保存され、独自のレート制限があり、有効期限が設定されたキーです。リンクを作成するだけのキーが、Webhook、メンバー、課金に触れる理由はなく、管理者向けのエンドポイントを開けてもいけません。これが最小権限であり、その大半は、キーを作成する30秒間に行う選択で決まります。

この1年間、私は数多くの自動化の構成を読んできましたが、パターンは繰り返されます。金曜の午後に、誰かが自分の万能キーをn8nに貼り付けて、動作し、その人が退職するか、ワークフローのエクスポートが共有ドライブに置かれるまで、誰も気に留めなくなります。この記事の残りでは、短縮リンク製品でAPIキーのスコープとロールがどう働くか、各ロールが実際に何をできるか、そしてワークスペースを丸ごと渡さずにキーを自動化ツールへ渡す方法を扱います。

URLショートナーのセキュリティチェックリストと合わせてお読みください。そちらは、スキャン、Webhookの署名、監査ログなど、プラットフォーム全体を扱っています。この記事は、キーそのものに焦点を当てます。

リンクツールにおけるAPIキー権限の意味

リンクツールのAPIが扱うのは、リンクだけではありません。go.example.com/spring-saleを作成するのと同じトークンが、権限によっては、クリック分析の読み取り、カスタムドメインの追加、メンバーの招待、あらゆるイベントを外部のサーバーに送るWebhookの登録もできます。最後のものが、私にとっては怖い点です。Webhookは常設のデータフィードで、作成した人が好きなサーバーを宛先にでき、チームの誰も、数週間気づかないかもしれません。

そのため、権限には3つの軸があります。キーはどこで動作するか(どのアカウントまたはワークスペースか)。そこで何ができるか(読み取り、書き込み、管理)。そして、どのくらいの期間、どのくらいの速さで使えるか。NISTの用語集による最小権限の定義(2026-10-24 閲覧)は、各主体にその機能を果たすために必要な最小限の認可を与えるというもので、3つの軸はいずれもそこに含まれます。読み取り専用でも、期限がなくレート制限もないキーは、時間の面では過剰な権限を持っています。

Bearer トークンを作成する前に、名前、ロール、有効期限を選ぶ Elido の API キー生成フォーム

ワークスペース単位のAPIキー: 1つのキーは1つのワークスペース

Elidoでは、すべてのキーはワークスペース内で発行され、そこにとどまります。別のワークスペースのエンドポイントをそのキーで呼び出すと、存在しないワークスペースと同じ404が返るため、キーから他のワークスペースの存在を確認することすらできません。

これは見た目以上に重要です。代理店や大きなチームは、5つや10のワークスペースに所属していることがよくあります。個人のキーが、作成者がアクセスできるすべてを引き継ぐとしたら、1つのクライアントのプロジェクトから漏えいしたトークン1つで、すべてのクライアントが開いてしまいます。ワークスペース単位のAPIキーは、被害の範囲を1つのワークスペースに縮小します。

キーは、作成時に選んだロールを上限とし、作成者の現在のロールを超えることもありません。実効的なアクセスは、その2つのうち低いほうです。キーを作った管理者をeditorに降格すれば、キーも一緒に下がります。そのメンバーに付与されたカスタム権限も、キーのロールのほうが低い場合は適用されません。それらは、キーではなく人物に紐づくものだからです。

ElidoのロールベースのAPIキー: キーは1つのワークスペースに紐づき、実効ロールは、作成時に選んだロールと作成者の現在のロールのうち低いほうになる。ロールはviewerからeditor、admin、ownerへと上がる

ロールベースのAPIキー: 各ロールにできること

Elidoのキーは、人と同じ4つのロール(viewer、editor、admin、owner)を使います。ロールはキーの作成時に選びます。省略するとキーはeditorが既定になり、これは、リンクの作成と分析の読み取りという、典型的な自動化の作業を、管理者権限なしでカバーします。

連携がよく触れる対象について、実際にどうなるかを示します。

ロールリンクとキャンペーン分析Webhookドメイン、メンバー、キー
viewer読み取りのみ読み取り、CSVエクスポートジョブの開始エンドポイントの一覧ドメインとメンバーの閲覧
editor作成、編集、削除、一括作成読み取り、CSVエクスポートジョブの開始エンドポイントの一覧ドメインとメンバーの閲覧
admineditorができることはすべてさらにS3データエクスポートの設定、定期メールレポート作成、変更、リプレイドメイン、メンバー、キーの管理
ownerすべてすべてすべてすべて

クリック数をBIツールに取り込むレポートダッシュボードにはviewer、キャンペーンのリンクを発行するGoogleスプレッドシートのジョブにはeditorが必要です。日常の自動化で、adminが必要なものはほとんどなく、ownerのキーは危険信号だと考えます。ownerはワークスペースを運営する人間のためのもので、それを必要とする自動化の作業は思いつきません。

知っておくべき制限が2つあります。api_keys.manage権限を持つのはadminとownerだけなので、viewerやeditorのキーは、キーの一覧表示や失効ができません。また、キーの作成とレート制限の変更には、サインインした人間が必要です。どのロールのAPIキーでも、403(「この操作には対話型セッションが必要です」)になります。漏えいしたadminキーは、期限のない代わりのキーを作れませんが、キーの一覧表示と失効はできます。そして、どのロールのキーも、プラットフォームの管理者APIには届きません。その領域は、APIキーによる認証を403と「admin access requires an interactive session」というメッセージで拒否します。キーはワークスペースの連携のためのものであり、開けるのはそこまでです。

Webhookの管理にadminキーが必要な理由

これは、驚かれる点です。Webhookエンドポイントの一覧の読み取りは、viewerキーを含め、どのメンバーにも許可されています。しかし、エンドポイントの作成、宛先の変更、配信のリプレイにはworkspace.edit権限が必要で、それを持つのはadminとownerだけです。

理由は、前に述べた常設フィードの問題です。editorが1,000本のリンクを作成すれば、気づくでしょう。しかし、自分のサーバーを宛先にした包括的なWebhookをeditorが追加できるとしたら、その時点からすべてのリンクイベントを、気づかれないまま受け取れてしまいます。そのため、Webhookの変更は、ワークスペースの設定を変更できる人たちだけに委ねています。

実際には、Webhookはダッシュボードで管理者として一度だけ手動で設定します。その後、それを利用する自動化には、APIの呼び出し用にeditorまたはviewerのキーを渡します。リンクイベントのWebhookをSlackやCRMに接続する場合、受信側にElidoのキーは一切必要ありません。必要なのは、ペイロードを検証するための署名シークレットです。

何かを接続する前に確かめたいですか? 無料のワークスペースを作成し、viewerキーとeditorキーを発行して、同じ書き込み呼び出しをそれぞれで試してください。viewerキーで返る403は、どんな表よりも多くを教えてくれます。

キーの保存方法: ペッパー、ハッシュ、プレフィックス

トークンはelido_に、32バイトのランダムな値から生成した52文字のbase32が続く形です。全体を見られるのは、作成呼び出しのレスポンスで一度だけです。その後は、当社側から完全に消えます。

保存しているのは、トークンのHMAC-SHA256です。キーにはサーバー側のペッパーを使い、ペッパーはデータベースではなくアプリケーションの設定に置いてあります。リクエストのたびに、受け取ったBearerトークン(RFC 6750で定義された方式、2026-10-24参照)を同じ方法でハッシュ化し、ハッシュで検索します。つまり、盗まれたデータベースのダンプはハッシュの一覧にすぎず、ペッパーがなければ誰も照合できません。ペッパーがなければ起動もしません。本番サービスは、ペッパーが設定されていないと起動を拒否します。

お客様自身の記録用には、elido_ の後ろの最初の8文字を表示用プレフィックスとして保存します。APIキーのページには、そのプレフィックスがキーの名前、ロール、作成日、有効期限、最終使用時刻、最後に使われたIP、そしてリクエストの総数と失敗数と並んで表示されます。どこかのログにキーが現れたとき、プレフィックスを見ればどのキーかが分かります。完全なシークレットを見る必要は誰にもありません。

レート制限、有効期限、APIキーのローテーション

各キーは、ワークスペース単位の制限とは別に、独自のトークンバケットを持つため、暴走した1つのワークフローが、ほかのすべての予算を食い潰すことはありません。サインインした管理者は、1つのキーのレートを毎秒1から10,000リクエスト、バーストを1から20,000の範囲で上書きでき、上書きを解除して既定値に戻すこともできます。上限を超えると、キーにはRetry-After: 1とX-RateLimit-Scope: api_key付きの429が返るため、再試行のロジックで、キーの上限とワークスペースの上限を区別できます。適切にバックオフする方法は、レート制限と冪等性のガイドで説明しています。

有効期限は任意で、作成時にRFC 3339のタイムスタンプとして設定します。期限が過ぎると、キーは単に一致しなくなります。失効はDELETE 1回で、冪等でもあります。

「ローテーション」という単一のボタンはありませんが、不便だとは思いません。ローテーションは3つのステップです。

  1. 同じロールと新しい有効期限で、新しいキーを作成する。
  2. ツールの認証情報ストアのキーを入れ替え、呼び出しが成功することを確認する。
  3. 古いキーを失効させ、一覧で、その最終使用時刻が動かなくなったことを確認する。
APIキーのローテーションのライフサイクル: 有効期限付きの新しいキーを作成し、自動化ツールに入れ替え、呼び出しを確認し、古いキーを失効させる。すべてのステップがワークスペースの監査ログに記録される

どのステップも、ワークスペースの監査ログに記録されます。名前とロールが付いたapi_key.created、api_key.revoked、上書きに対するapi_key.rate_limit_setです。バックグラウンドのスキャンも5分ごとに実行され、リクエストが1,000件を超え、そのうち30%以上が失敗したキーにフラグを立てます。フラグは監査ログとキーに記録されます。自動失効はしません。404が連続するのは、攻撃者よりも壊れたワークフローのことのほうが多いため、キーを無効にするかどうかは人間が判断します。

最小権限のAPIキーをn8n、Make、Zapierに渡す

自動化プラットフォームは、キーが忘れ去られる場所です。キーは認証情報ストアに置かれ、エクスポートされたワークフローのJSONにコピーされ、設定した人より長く生き残ります。次の2つの習慣が役立ちます。

  • ツールごと、ワークフローのグループごとに1つのキーを用意し、その名前(「n8n: campaign sheets」)を付けます。失効させても壊れるのは1つだけで、監査ログからどのツールが何をしたかが分かります。
  • リンクを作成するものにはeditor、読み取るだけのものにはviewerを使い、どちらにも有効期限を設定します。

一覧としてはこれだけで、残りは判断です。OWASPのSecrets Management Cheat Sheet(2026-10-24 閲覧)は、トークンをログやエクスポートから遠ざける方法を学ぶのに適しています。自動化のキーが漏れるのは、たいていそこだからです。

ツールごとの設定については、n8nのURLショートナーガイドがキーをHeader Authの認証情報に設定する方法を、Make、IFTTT、n8n、Zapierの比較が各プラットフォームでの保管場所を扱っています。Zapierは、Zapierの自動化ウォークスルーにあるとおり、同じトークンで接続します。CIや、担当者が退職しても残る必要があるものには、マシンユーザーが適しています。人間のキーとは別の、独自のトークンを持つサービスアカウントです。キーと同様に、マシンユーザーもトークンではなく、サインインした管理者が作成します。

キーが管理者向けのエンドポイントを開けてはならない理由は、まさにこの受け渡しにあります。トークンがサードパーティのツールにある以上、そのツールのワークフローを編集できる人なら誰でも使えます。信頼するのは、自社だけでなく、相手側の全員です。

スコープ単位のトークンは計画中で、未提供

ロールは意図的に粗くしてあり、時にはそれが粗すぎます。リンクの作成しかしないeditorキーでも、削除はeditorロールの一部なので、リンクを削除できます。解決策は、ロールの上に重ねて、links:writeやanalytics:readのようなスコープ単位のトークンをキーに直接付けることです。

これはロードマップに入っていますが、提供はされていません。現時点で、キーの権限はワークスペースとロールだけで、それより細かいものはありません。今すぐ厳しく制御したい場合の手段は、低いロールと短い有効期限の2つで、あわせて作業ごとに別のキーを用意し、各キーの被害範囲を小さくします。APIクイックスタートとAPIとSDKのリファレンスで、現在のキーのモデルを動くコードで確認できます。IDレベルの制御も必要なチームは、マーケティングツールのSCIMとSSOをお読みください。

コーナーストーン記事はこちら: URLショートナーのセキュリティチェックリストは、URLスキャンからIP許可リストまで、キーを取り巻く対策を扱っています。

ブログの関連記事

よくある質問

APIキーの権限とは何ですか?

キーがAPIに対して実行を許可されている操作の集合です。どのリソースを読めるか、どれを変更できるか、どのアカウントでそれができるかが含まれます。Elidoでは、キーの権限は、発行されたワークスペースと、作成時に選んだロールによって決まるため、同じキーが別のワークスペースで動作したり、そのロールを超えて動作したりすることはできません。

APIキーにおける最小権限とは何ですか?

各キーには、その役割に必要な最小限の権限だけを与え、それ以上は与えないという考え方です。クリック数を読むだけのダッシュボードにはviewerキー、リンクを作成するワークフローにはeditorキーを与え、adminキーは、Webhook、ドメイン、メンバーを管理するまれな作業のためにとっておきます。そうすれば、キーが漏えいしても、その1つの作業ができたことしかできません。

APIキーのスコープとロールの違いは何ですか?

スコープは、links:writeのような狭い権限をトークンに直接付けたもので、ロールはeditorのように名前を付けた権限のまとまりです。ロールのほうが理解しやすく、スコープのほうが細かく制御できます。Elidoのキーは現在ワークスペースのロールを使っており、スコープ単位のトークンはその上に計画していますが、まだ提供していません。

APIキーはどのくらいの頻度でローテーションすべきですか?

一般的な指針は30日から90日ごとです。加えて、キーを見たことのある人が退職したとき、キーがログに現れたとき、トラフィックに異常があるときは、すぐに行います。作成時に有効期限を設定しておくと、そのスケジュールが、人々が無視するカレンダーのリマインダーではなく、確実な停止点になります。

APIキーで管理者向けのエンドポイントにアクセスできますか?

Elidoではできません。プラットフォームの管理者APIは、サインイン済みの対話型セッションしか受け付けず、キーを作った人のロールにかかわらず、APIキーには403を返します。管理者権限が必要なワークスペースの設定には引き続きアクセスできますが、adminまたはownerロールで作成したキーに限られます。

プロバイダー側ではAPIキーをどのように保存すべきですか?

平文での保存は絶対に避けるべきです。プロバイダーはトークンの鍵付きハッシュを保存し、その後は短いプレフィックスだけを表示するようにして、データベースのコピーだけではAPIを呼び出せないようにします。Elidoは、各トークンをHMAC-SHA256とサーバー側のペッパーでハッシュ化し、完全なトークンは一度だけ表示します。

Elidoを試す

URLを貼り付けて短縮リンクを取得

登録不要。リンクは30日間有効。永久に保存するには登録してください。

登録不要。無料登録すると月 50 件のリンクを作成できます。

Elidoを試す

EUホスティングのURL短縮サービス。カスタムドメイン、詳細な分析、オープンAPI付き。無料プラン - クレジットカード不要。

タグ
api key permissions
least privilege api keys
api key scopes
api key rotation
role-based api keys
workspace-scoped api keys

続きを読む