免責事項:私はこれらのことについて書く資格を与えられていません。これらのことを記憶から暗唱することはできますが、私は情報セキュリティにまったく取り組みません。私の文章に不正確な点や誤解がある可能性があります。
apikeyを保護するという考えは、気が遠くなるようなものです
はい、そうです。情報セキュリティは、あなたと未知のスキルレベルの未知の加害者との間の精神的な戦いです。
しかし、時間をかければ、ある時点で、apikeyが使用中または呼び出されているときでも、だれでもキーを取得できます。
はい、そうです。可能性について偏執的であることは正しいことです。しかし、パラノイアが多すぎると私たちの思考が麻痺し、有用なものを作成できなくなるため、多すぎません。
具体的には:
- APIキーは、ユーザーとAPIプロバイダー(「スチーム」)の間の「共有秘密」です。
- 「共有シークレット」であるため、なんらかの方法でそれを入手したユーザーは、APIキー(および自分のアカウント)に関連付けられた特権(権限)と制限に従って、APIで任意のアクションを実行できます。
- APIキーを使用して(誰でも)アクションが実行されると、APIプロバイダーは、これらのアクションがそのAPIキーを使用して実行されることを(ロギングで)認識します。どの衆生がそれをしているのかはわかりません。猫でも犬でもかまいません。
- APIキーは暗号化キーではありません。 APIキーを手に持っているだけでは、何かを「暗号化」することはできません。
システムからAPIキーを取得する方法
- ディスクからコピー
- 防御:コンピュータの保護、ディスクの保護、オペレーティングシステムの保護、ファイルシステムの保護
- 多層防御:WebアプリケーションサーバーセキュリティとWeb非対応サーバーアプリケーションに個別のOSアカウントを作成し、シークレットを含むファイルへのアクセスをWeb非対応サーバーアプリケーションに制限することにより、OSアプリケーションセキュリティを使用します。
- 実行中のアプリケーションのメモリからコピー
- 防御:アプリケーションから悪用可能な脆弱性を排除します
- 例:脆弱性の脆弱性が少ないおよびプログラミング言語とランタイムを選択し、セキュリティについて推論しやすくなります。
- 例:優れたセキュリティと評価されていないモジュール、ライブラリ、依存関係、またはサービスの使用を避ける
- 例:できるだけ多くのバグを修正し、脆弱性のパッチが利用可能になり次第、サードパーティのモジュール、ライブラリ、または依存関係にパッチを当てます。
- 機密性の高い責任をより適切に構築されたシステムに委任する。これは、あなたが聞いた "OSキーストア"のアイデアです。
- 注:これは暗号鍵にのみ適用されます。 APIキーには適用されません。 (注意:APIキーは単に「共有シークレット」であり、暗号化操作は実行できません。)
- 多層防御:これは、あなたが聞いた「プロキシ」のアイデアです。
- 2つのアプリケーションを実行します。
- 安全なプログラミング言語とランタイム環境でプログラムされているという意味で、Webに対応する最初のものは強化されており、責任の分担を最小限に抑えることで攻撃対象領域を最小限に抑えます。
- たとえば、ユーザー認証と入力の検証とサニタイズのみを処理できます。正当で無害な要求と応答を2番目のアプリケーションに渡します。
- 2番目のアプリケーションには、APIキーを使用するコードを含む重要なアプリケーションロジックが含まれています。
- この2番目のアプリケーションはWeb向けではなく、WebサーバーのアプリケーションレベルのOSに統合されているファイアウォールによってネットワークから隔離されています。
- さらなる防御:2つ(またはそれ以上)のアプリケーションを用意し、2番目のアプリケーション(作業の機密部分を処理するアプリケーション)を別のコンピューターに配置します。 2番目のコンピューターをネットワーク層ファイアウォールで保護します。
- Javascript(または信頼できないクライアント側コード)はどうですか?それらは顧客のコンピューター(または、高度な加害者のコンピューター)で実行されるため、アクセスできるものはすべて「彼ら」と見なされます。多層防御が要件になりました。JavaScriptコードは、コンピューターでホストされているC#Webサービスと通信する必要があります。そうすれば、クライアント側のJavaScriptコードはAPIキーを知る必要がありません。
- 代替方法:顧客が認証を完了すると、APIサービスに顧客の短期間「セッション」を作成するよう要求できる場合があります。 「セッション」はAPIキーとまったく同じように使用されますが、APIキーを顧客に漏らすことはありません。あなたはこの「セッション」を乱用しないことを約束し、顧客はこの「セッション」のコピーを持つ唯一の相手です。
- 保護されていない状態でネットワーク上でAPIキーが送信されると傍受されます
- 防御:送信を暗号化し(例: トランスポート層セキュリティ(TLS) )、アプリケーションと信頼されたエンドポイント(「Steam」APIサーバー)のみがそれを復号化できるようにします。
- 基本要件:相互暗号化および暗号化認証の目的で使用される暗号化証明書(ユーザー、およびAPIプロバイダーの証明書)の有効性を作成、使用、および維持します。
- ウェブに接続しているサーバーを制御できるコンピュータからコピーしたもの
- 例:自分の(ホーム)ワークステーション。これから、Web向けサーバーで実行するソフトウェアの開発を含む、ほとんどのプログラミング作業を行います。
- 防御:所有しているすべてのコンピューター(自宅、職場)と、制御しているすべてのコンピューター(Webホスティングサービス)を保護します
人的要因によりAPIキーが漏洩する可能性がある方法
- APIキーを誤ってコピーして、保護されていない場所や漏洩しやすい場所に貼り付けました。たとえば、誤ってソース管理システムに追加し、それをインターネット上のリポジトリにプッシュすると、他のユーザーに表示される
- 防御:
.gitignore
- ベストプラクティス:APIキーをアプリケーションのソースコードに含めないでください。これをgit-ignoredのファイルに入れることは、このベストプラクティスを満たすための最も簡単な方法です(git-ignoreと組み合わせて)。
- ただし、コミットする理由がある場合は
app.config
(または一般的なアプリケーション構成ファイル)をソースコードリポジトリに追加すると、APIキーはそこに格納されません。
- APIキーを記憶し、それを他の人に教えた
- 防御:その人を非常に信頼しない限り、しないでください
- APIキーを書き留めると、紙が他人に見られたり、コピーされたり、取られたりしました
- 防衛:それをしないでください。パスワードマネージャを使用します。 (これは、自分のコンピュータが適切に保護されていることを前提としています。)
- APIキーを入力し、他の誰かがキーストロークを確認したか、キーストロークがキーロガーに記録されます
- 防御策:頻繁に実行しないでください。パスワードマネージャを使用して、暗唱して入力する回数を減らします。
- 防御:キーローテーション。 APIキーの有効期限を設定し、古いキーが期限切れになる前に新しいものに置き換えます。 (これは、キーリークの考えられない他の多くの方法に対する包括的な防御策です。)
文字通りに取られることなくAPIキーを偽装できる方法
- ランダムな推測。
- 防御:APIキーを十分に長くランダムにして、「ランダム推測」が使用可能なものを見つける確率が非常に低くなるようにします。これはAPIプロバイダーの責任であり、ユーザーの責任ではありません。
APIキーが盗まれたときの損傷を制限する方法
- APIキーを介して実行できる特権(権限、アクセス権)を制限します。
- キーローテーション。 APIキーの有効期限を設定し、古いキーが期限切れになる前に新しいものに置き換えます。
- ログ(レコード)を収集、保護、および精査し、侵入(試行と成功の両方)をできるだけ早く特定して、修正アクションをより早く実行できるようにします。
そして、もっとあります...