企業内で内部APIキーを共有しないようにするにはどうすればよいですか？

新しいサービスに取り組んでいます。このサービスは、ユーザーのデバイス上のアプリケーションから直接呼び出される可能性があります。これらのアプリケーションは、提供するデータに応じて、組織全体の複数の開発チームによって開発およびサポートされます。

使用パターンと責任のある開発者を特定できるように、どのアプリケーションがどのリクエストを送信しているかを特定したいと考えています。（疑念を避けるため、ユーザー認証は個別に処理されます。）

私たちのソリューションは、アプリケーションごとに1つのAPIキーを必要とすることです。その後、開発チームの連絡先の詳細を取得します。

APIキーを摩擦の原因にしたくはありませんが、開発者がそれらを他のチームの同僚と共有するのではないかと心配しています。つまり、1つのアプリケーションだけのトラフィックを識別できなくなります。

APIキーを内部で共有しないように開発者にインセンティブを与えるにはどうすればよいですか？

これらのキーをチーム間で共有するには、チームが互いに話し合い、共有することに同意してから共有する必要があります。これには時間がかかります。したがって、チームがより迅速かつ簡単にAPIキーをリクエストできる場合、共有するインセンティブはありません。

そして、彼らがそれらの鍵を要求する最も簡単な方法は、それらを先取りすることです。APIキーを必要とする他のすべてのチームを知っていると仮定して、それらを作成し、共有してからサービスを利用できるようにします。

提供できるもう1つのインセンティブがあります：デバッグサポート。これらのチームは、自分の仕事をサービスに統合するときに物事が適切に機能しない場合にあなたの助けを必要とします。これらのAPIキーを使用すると、特定のリクエストを追跡できるため、問題のデバッグに役立ちます。そのため、「使用パターンと責任のある開発者を特定する」のではなく、キーの理由としてそれを販売してください。

良い答えはすでにあります。私はあなたのために働くかもしれないし、そうでないかもしれない別のアプローチを考えました。

含まれるキーを発行するのではなく、Webブラウザーのように、フロントエンドアプリケーションの開発者が作成およびフォーマットするために、リクエストのヘッダーにフロントエンドアプリケーションの名前を含めることを要求できます。そうすれば、フロントエンドはまだ別のアプリケーションのふりをすることができますが、そうすることにはメリットがないので、そうは思えません。フロントエンドが自分自身を識別し、空でない文字列を受け入れるようにします。

要するに：

最初：円滑化と利点。必要に応じて：摩擦と警察。

もう少し言葉

円滑化：まず、チームが新しいAPIキーを簡単に取得できるようにします。たとえば、新しいプロジェクトを立ち上げるための企業手順にリマインダーを追加し、正当化を求めることなく、新しいキーを要求する使いやすいサービスを提供します。

利点：独自のAPIキーを使用することは、チームまたは製品所有者の利益になります。たとえば、そのキーに基づいてアプリの使用に関するフィードバックを提案します。

摩擦：キー機能に応じて、たとえばキーがアプリ定義ドメインにリンクされている場合に摩擦を作成できます（つまり、キーを再利用しても、必要なすべてのサービスにアクセスできるとは限りません）。

ポリシング：最後に、いくつかのポリシング対策を予測する必要がある場合があります。たとえば、APIキーごとにAPI関数の使用状況を監視し、一定時間後にベースラインを確立して、ベースラインの観点からは予期されないAPIパーツの使用に関する問い合わせを行うことができます。または、これが現実的でない場合は、有効なキーが使用されたことの検証を企業のプロジェクトレビューチェックリストに含めるだけです。

注：APIキーポリシーについて明確にする必要がある場合があります。新しいメジャーバージョンには独自のAPIキーが必要ですか？フォークの場合、またはアプリが分割されている場合はどうなりますか？他のチームが担当している場合など

一般に、開発者に「正しいことをさせる」最も簡単な方法は、開発者がそれを簡単に行えるようにすることです。

そのために、Webページ/サイトを発行するAPIキーを作成することをお勧めします。最も単純な形式では、ログイン（企業のAD / LDAPに関連付けられていることが理想的）と、アプリケーション名を要求してキーを発行するページだけです。

一日の終わりにはいつでもキーを取り消すことができるので、サイトに本当に必要なことは、キーを要求したユーザー（ユーザー名）と、キーで何をしたいのか（アプリケーション名）を記録することです。後でキーを取り消します。

チケットシステムでも同様のことができますが、1日の終わりに1つのアプリから別のアプリにキーをコピーして貼り付けるのは非常に簡単です。したがって、悪いキーを避けるために、新しいキーを要求するのは本当に簡単でなければなりません動作。

積極的に。

可能性のある開発者を特定し、安全なチャネルで一意のAPIキーを事前に提供します。新しいAPIキーをリクエストする簡単な手段を提供します。新しい人々が新しいAPIキーを要求する簡単な手段を提供します。新しいインターンまたは採用者がチームに参加する場合、説明の手順とともにJIRAチケットまたは同様の「APIキーのリクエスト」を提供します。

使用されているAPIキーと使用されていないAPIキーを追跡します。ボブがプロジェクトでチケットを送信したが、自分のAPIキーを使用していない場合は、おそらく他の誰かのものを借りているでしょう。

経営陣のサポートを受ける。関係のないルールを作るノシィナンシーになるな。文字通り経営陣にそれが重要であると納得させ、そして彼らはそれが重要であることをグループに納得させるものです。皆を納得させるために努力しないでください。

そして、最も迷惑で専制的な傾向がある提案：誤用に注意し、同じ日に取り締まります。同じ時間が最適です。「悪いいたずらな開発者」と言ってはいけません。「ここに適切な手順があります」と言ってはいけません。繰り返し行う場合は、誤用されたキーを無効にします。これは共有者と借りた人の両方の面倒なことであり、共有者は将来「いいえ、正しくやる」と言うでしょう。ライブプロジェクトにあるキーを無効にしないでください。

APIキーを内部で共有しないように開発者にインセンティブを与えるにはどうすればよいですか？

• セルフサービスアプリケーション登録の結果としてキーを生成します。
• キーがアクティブになる前に連絡先を要求します。
• そして、共有しないよう依頼してください。（利用規約を作成するか、共有しないほうがよい理由を説明します。）

レート制限も実装する必要があります。これ自体は、キーの共有を妨げる可能性があります。不正なアプリケーションからシステムをある程度保護します。（そして実に悪意のあるもの。）そして、それはあなたがサービス可能なトラフィックの大規模な増加の前にいくらか情報を与えられることを保証します。（容量を追加する時間を与えてください！）

また、レート制限では、アプリケーションがより高い制限を必要とする場合、キーに登録されたPOCでダイアログが開きます。キーが共有されているかどうかを尋ねる機会があり、それがなぜ有害なのかなどを説明し、要求されたレート制限の変更の代わりに適切なときに追加のキーを提供できます。等。

特にチームが共有ビルドシステム（または少なくとも十分に一般的なもの）を使用する場合、物事を行う1つの方法は、APIキーを作成および発行する内部サーバーをセットアップすることです（それを使用する製品に関する基本的な情報をいくつか与えます）。次に、ビルドごと、またはバージョンの更新ごとに、サーバーから新しいAPIキーを取得するスクリプトを使用します。開発者がスクリプトを実行して、ローカルビルド用に別のキーを取得することもできます。（可能な場合は、ビルドの一部としてこれを自動化するので、彼らはそれについて考える必要さえありません。）

これにより、それが実稼働、QA、または開発のいずれにあるのか、およびどのバージョン/ビルドで問題が始まったのかがわかります。

できる最初の最善の方法は、キーをフォーマットして、アプリケーション名が読みやすい形式で含まれるようにし、変更すると機能しないようにすることです。

チームが間違ったキーを使用していることが明らかな場合、彼らはそうしないよう努力します。

次に、キーを定期的に期限切れにします。とにかくこれを行う必要があり、キーの有効期限が近づくと、キーを所有するチームに新しいキーを送信できます。キーを使用するチームは、キーが期限切れになったときに新しいキーを取得できるように、キーを所有するチームであることを確認するようになります。