Web-APIセキュリティ：SSL？

Question

web-apiのリクエストを特定のクライアントに制限する方法を知りたいと思います。

ウェブAPI

は（今だけのために）コンピュータA.

クライアント上でホストされます - コンピュータB上でホストされることになります。コンピュータB上のクライアントへの私のWeb-APIのみの "応答" を作る方法など

異なるサーバ、マシン、

？ SSLを使用していますか？

1. これはどのように機能しますか？
2. サーバー側で何か処理する必要がありますか？
3. 今後同じモバイルアプリを使用するにはモバイルアプリが必要な場合があります。この場合、どうすれば私のアプリのリクエストにweb-apiが答えることを「許可する」ことができますか？
4. SSLが問題を解決する場合は、サーバーとクライアントにのみ証明書をインストールする必要がありますか？

Answer 1

複数のオプションがあり、マシンが動作する環境によって多かれ少なかれ異なります。 （また相互認証または2ウェイTLSとして知られている）

1. クライアント証明書認証：一般的に、私は3のメカニズムに見てね。これは、基本的に、両方のマシンが検証のために相互に証明書を提示することを意味します。このアプローチは、サーバー間の通信では非常に一般的です。これは一般的にはきわめて安全なアプローチですが、新しい信頼できるクライアントを追加することは、証明書を発行する必要があるため、少し面倒です。
2. IPまたはホスト名（またはサブネット全体）のホワイトリスト化。言い換えれば、許可されたクライアントのプールをその出所別に制限するようにサーバー上に構成する必要があります。このアプローチには暗号化は含まれておらず、クライアントはその起源を簡単に偽装することができますが、他のメカニズムへの追加（余分なレイヤー）として使用されることがあります。
3. APIキー。 APIを使用するためのキーベースの認証を統合または実装します。これは、Web APIを使用するモバイルアプリケーションの認証によく使用されます。 APIキーの最も一般的な問題の1つは、その保護です。誰かがそれらのキーを盗むのを合理的に難しくする方法を見つける必要があります。最終的には、モバイルアプリケーションでは不可能なことが多いですが、常にリスク評価を行い、発見されたリスクをどのように緩和するかを確認する必要があります。

これらのメカニズムを組み合わせてレイヤーを追加することができます。また、さらに多くのレイヤーに対してファイアウォールやネットワークの制限を設定することもできます。しかし、常にあなたが保護しようとしているもののリスクと価値を評価するために瞬間を取ってください。次に、保護のために使用するための合理的なコストと努力を知ります。

これはすべての可能性を網羅したリストではありませんが、使い始めるための参考になることを願っています。