会社内で内部APIキーを共有しないようにするにはどうすればよいですか？
現在、新しいサービスに取り組んでいます。このサービスは、ユーザーのデバイス上のアプリケーションから直接呼び出される可能性があります。これらのアプリケーションは、提供するデータに応じて、組織全体の複数の開発チームによって開発およびサポートされます。
どのアプリケーションがどのリクエストを送信しているかを特定することで、責任を負う使用パターンと開発者を特定できます。 （誤解を避けるために、ユーザー認証は個別に処理されます。）
私たちのソリューションは、アプリケーションごとに1つずつAPIキーを要求することです。そうすると、開発チームの連絡先の詳細がわかります。
APIキーが摩擦の原因になるのは望ましくありませんが、開発者がそれらを他のチームの同僚と共有することを懸念しています。つまり、1つのアプリケーションだけのトラフィックを特定できなくなりました。
内部でAPIキーを共有しないように開発者にインセンティブを与えるにはどうすればよいですか？
これらのキーをチーム間で共有するには、チームが互いに話し合い、共有に同意してから共有する必要があります。これには時間がかかります。したがって、チームがより迅速かつ簡単にAPIキーをリクエストできる場合、共有するインセンティブはありません。
そして、それらのキーを要求する最も簡単な方法は、キーを横取りすることです。 APIキーを必要とする他のすべてのチームを知っていると仮定して、サービスを提供する前に、それらを作成して共有します。
あなたが提供できるもう一つのインセンティブがあります：デバッグサポートです。それらのチームは、作業をサービスと統合するときに物事が適切に機能しない場合に、あなたの助けを求めます。これらのAPIキーを使用すると、特定の要求を追跡できるため、問題のデバッグに役立ちます。したがって、「使用パターンと開発者の責任を特定」ではなく、キーの理由としてそれを販売してください。
良い答えはすでにあります。私はあなたのために働くかもしれないし、そうでないかもしれない別のアプローチを考えました。
含まれるキーを発行するのではなく、リクエストのヘッダーにフロントエンドアプリケーションの名前を含めるよう要求し、フロントエンドアプリケーションの開発者がWebブラウザーのように作成およびフォーマットするようにすることができます。そうすれば、フロントエンドが別のアプリケーションのふりをすることができますが、そうすることには利点がないので、そうは思われません。フロントエンドがそれ自体を識別し、空でない文字列を受け入れるようにします。
要するに：
まず、円滑化と利点。必要に応じて、摩擦と警察。
もう少し言葉
ファシリテーション：まず、チームが新しいAPIキーを簡単に取得できるようにします。たとえば、新しいプロジェクトを開始するための社内手続きにリマインダーを追加し、正当な理由を尋ねることなく、新しいキーを要求するための使いやすいサービスを提供します。
メリット：独自のAPIキーを使用すると、チームまたは製品の所有者にとってメリットになります。たとえば、そのキーに基づいてアプリの使用に関するフィードバックを提案します。
Friction：キー機能に応じて、たとえばキーがソンムアプリ定義ドメインにリンクされている場合（つまり、キーの再利用が必ずしも必要ではない場合）、摩擦を作成できます必要なすべてのサービスへのアクセスを許可します）。
ポリシング：最後に、いくつかのポリシング対策を予測する必要があるかもしれません。たとえば、APIキーを使用してAPI関数の使用状況を監視し、ベースラインを確立するための一定の時間の後、ベースライン上では予期されないAPIパーツの使用について問い合わせることができます。または、これが現実的でない場合は、企業のプロジェクトレビューチェックリストに、有効なキーが使用されたことの確認を含めるだけです。
備考：APIキーポリシーを非常に明確にする必要がある場合があります：新しいですか- メジャーバージョン 独自のAPIキーが必要ですか？フォークの場合、またはアプリが分割されている場合はどうなりますか？他のチームが担当している場合などは...
一般に、開発者に「正しいこと」を行わせる最も簡単な方法は、開発者がそうすることを簡単にすることです。
そのためには、APIキーを発行するWebページ/サイトを作成することをお勧めします。最も単純な形式では、ログイン（理想的には企業のAD/LDAPに関連付けられている）と、アプリケーション名を要求してキーを発行するだけのページである可能性があります。
1日の終わりにいつでもキーを取り消すことができるので、サイトに本当に必要なのは、キーを要求したユーザー（ユーザー名）とキーをどのようにしたいか（アプリケーション名）を記録することだけです。後でキーを取り消します。
チケットシステムでも同様のことができますが、結局のところ、あるアプリから別のアプリにキーをコピーして貼り付けるのは非常に簡単なので、新しいキーをリクエストするのは非常に簡単でなければなりません。動作。
内部でAPIキーを共有しないように開発者にインセンティブを与えるにはどうすればよいですか？
- セルフサービスアプリケーション登録の結果としてキーを生成します。
- 連絡先が必要キーがアクティブになる前。
- そして共有しないように依頼します。（利用規約を作成するか、利用者により良い理由を伝えます共有。）
rate-limitedも実装する必要があります。これ自体は、鍵の共有を妨げる可能性があります。それは乱用アプリケーションからシステムをある程度保護します。 （そして実に悪意のあるものです。）そして、それはあなたがサービス可能なトラフィックの大幅な増加の前にいくらか知らされることを確実にします。 （容量を追加する時間を与えてください、お願いします！）
また、レート制限を使用すると、アプリケーションがより高い制限を必要とする場合、キーに登録されたPOCでダイアログが開きます。キーが共有されているかどうかを尋ねる機会があり、それが有害である理由などを説明し、要求されたレート制限の変更の代わりに、適切な場合は追加のキーを提供できます。等。
積極的に。
見込みのある開発者を特定し、事前に安全なチャネルで一意のAPIキーを提供します。新しいAPIキーをリクエストする簡単な手段を提供します。新しい人々が新しいAPIキーをリクエストする簡単な手段を提供します。新しいインターンまたは採用担当者がチームに参加する場合、説明の手順に従って、JIRAチケットまたは同様の「APIキーをリクエスト」してください。
使用されたAPIキーと使用されなかったAPIキーを追跡します。ボブがプロジェクトでチケットを提出したが、自分のAPIキーを使用していない場合は、おそらく他の誰かを借りています。
経営陣のサポートがあります。重要ではないルールを作成するせんさく好きなナンシーにならないでください。それが重要であることを経営陣に文字通り説得し、それから彼らはそれが重要であることをグループに説得します。みんなを納得させることに取り組んではいけません。
そして、最も迷惑で暴政的な傾向のある提案：誤用に注意し、同じ日に取り締まる。同じ時間が一番いいです。 「Bad Naughty Developer」が「ここに適切な手順があります」と言ってはいけません。繰り返し使用する場合は、誤用されたキーを無効にします。これは、共有者と借りた人の両方を面倒にし、共有者は将来的に「いいえ、適切に実行します」と言うでしょう。ライブプロジェクトにあるキーを無効にすることは避けてください。
特にチームが共有ビルドシステム（または少なくとも十分に一般的なビルドシステム）を使用している場合は、APIキーを作成して発行する内部サーバーをセットアップする（それを使用する製品に関するいくつかの基本的な情報が与えられている場合） ）。次に、ビルドごと、またはバージョン更新ごとに、サーバーから新しいAPIキーを取得するスクリプトを使用します。開発者がスクリプトを実行して、ローカルビルド用の別のキーも取得できるようにします。 （可能な場合は、ビルドの一部としてこれを自動化して、ユーザーがそれについて考える必要がないようにします。）
これにより、それが本番、QA、または開発のいずれであるか、およびどのバージョン/ビルドで問題が始まったかを知ることができます。
最初にできる最善の方法は、アプリケーション名が読みやすい形式で含まれるようにキーをフォーマットし、変更しても機能しないようにすることです。
チームが間違ったキーを使用していることが明らかな場合は、そうしないように努力します。
その後、定期的にキーを期限切れにします。これを行う必要がありますとにかく。キーが有効期限に近づいたら、それを所有するチームに新しいキーを送信できます。キーを使用するチームは、そのキーを所有するチームであることを確認するよう動機付けられ、期限が切れたときに新しいキーを取得します。