ローカルネットワークサーバー間の通信にはHTTPSが必要ですか
私は顧客の会社のWebアプリケーションを構築しています。サーバー側では、サーバー間ネットワーク通信の2種類があります。
- 分離REST相互にリクエストを行うAPIサーバー。
- アプリケーションロードバランサー（特にAWS ALB）からそれらの自動スケーリングEC2インスタンスへの通信。
現在、これらの通信はすべてHTTPプロトコルを使用しています。ユーザー向けノード（ロードバランサーやWebサーバーのリバースプロキシなど）のみが、有効な証明書を使用してHTTPSを提供します。
すべての場所で常にHTTPではなくHTTPSを使用することが最新のベストプラクティスであると信じているため、お客様からすべてをHTTPSに変更するように依頼されました。
お客様と異議を申し立てたいのですが、セキュリティの専門家ではありません。以下の私の理解を確認し、間違っている場合は修正してください。
私の見解では、HTTPSプロトコルの目的は、信頼できない環境（インターネットなど）で信頼できるチャネルになることだと思います。そのため、すでに信頼されているチャネルをHTTPSに変更することのメリットはありません。さらに、すべてのサーバーに証明書をインストールする必要があるため、維持が難しくなる可能性があります。おそらく、一部のサーバーの証明書の有効期限が切れていて誰も知らないため、顧客はいつかアプリケーションサーバーが壊れることに気付くでしょう。
別の問題、HTTPSを提供するために負荷分散の背後にあるすべてのアプリケーションサーバー（Apacheなど）を構成する必要がある場合、ServerNameはVirtualHost内に何を配置する必要がありますか？現在、HTTP VirtualHostにmy-website.example.comなどのドメイン名を使用しても問題ありません。しかし、HTTPSの場合、my-website.example.comの証明書をロードバランサーの背後にあるすべてのインスタンスにインストールする必要がありますか？ my-website.example.comであると主張する多くのサーバーがあるので、それは奇妙だと思います。
あなたの質問に対する答えは、脅威のモデリングに帰着します。 HTTPSのような暗号化プロトコルを使用することは、特定の脅威から保護するためのセキュリティメカニズムです。これらの脅威があなたに関連している場合、分析する必要があります：
- 内部ネットワークに潜在的な脅威の攻撃者はいますか？質問に基づいて、内部ネットワークは完全に信頼できると想定しているようです。内部ネットワークが危険にさらされる可能性があるいくつかの方法があるため、これは多くの場合誤解です（たとえば、このネットワークへのアクセス権を持つ有効なユーザーが悪意のあるものになり、このネットワーク内のシステムが危険にさらされ、設定ミスによりネットワークセグメントが開かれるなど）。
- アーキテクチャは変更される可能性がありますか？システムは時間の経過とともに変化し、以前のセキュリティの前提（たとえば、内部ネットワークは信頼されている）が保持されなくなる可能性があります。それが妥当なシナリオである場合は、事前に必要なセキュリティメカニズムを構築することをお勧めします。これがセキュリティのベストプラクティスです。不確実な領域にセキュリティを提供する。
- 満たす必要のある規制、法的、またはコンプライアンスの要件はありますか？お客様はHTTPSを最新の/最新のベストプラクティスと見なしているとおっしゃっていました。この友好的な言葉による発言の源は、実際には外部からの要求であり、満たされなければならない場合があります。非準拠は脅威であり、脅威分析でもカバーする必要があります。
これらは分析する価値のある重要なトピックです。システムアーキテクチャを設計しているときに疑問がある場合は、セキュリティの面で誤解することを好みます。この場合、アプリケーションに大きな影響（パフォーマンスへの影響など）がない限り、状況に関係なく、通信にHTTPSを使用するのがベストプラクティスのアプローチです。
これは一般的な慣行であるため、サーバー証明書を維持するのが困難であることは、今日では問題になりません。これは、通常のスケジュールされた操作アクティビティの一部である必要があります。
以上のことをすべて述べた上で、HTTPではなくHTTPSを使用するために必要な追加の作業はもちろんあります。この追加の作業について顧客に請求するのはあなたの権利です。開発中および運用中に時間の経過に伴うコストを計算し、コストにメリットがあるかどうかをお客様に判断していただくことをお勧めします。
HTTPとHTTPSを混合して一致させることは良い考えではありません。構成を常に調整していることになります。
通常、システムへのコンポーネントの追加は、非常に具体的な理由がある場合にのみ行う必要があります-誰かがそれを良いアイデアは特定の理由ではないと思ったからです。
HTTPSが悪い考えだと言っているわけではありません-まったく逆ですが-あなたは多くのことを学ぶ必要があります。あなたが提案するモデルは、そもそもTLSを使用する主な理由である信頼関係を損なうものです。また、PKIの計画方法について考えたことがないようです。
一部のサーバーの証明書が期限切れで誰も知らないため、将来的にサーバーが壊れる
サービスを提供する場合は、証明書の有効期限を含め、サービスの監視を構成する必要があります。
証明書のロールアウトのアプローチについて議論する理由を探しているようです。ここの行の間を読んで、あなたは現在あなたがこれを実装するために必要なスキルと計画を欠いているようです。
はい、それは多くの仕事ですが、それはビジネスモデルです-あなたは仕事の量、あなたが獲得する必要があるスキルとあなたが買うことができるそれらを評価し、そしてあなたはそのために顧客に請求します。 （Sergeは証明書のコストを強調していますが、これはこの演習全体で最小のコストです）。
内部ネットワークは安全ではありません
一般に、内部ネットワークは一般向けのシステムよりも安全ですが、完全に安全であると見なすべきではありません。攻撃の大部分は内部から発生します-スピアフィッシング、ソーシャルエンジニアリング、インサイダー攻撃はすべて、ネットワーク内部の足場から始まる人気のあるベクターです。
したがって、内部ネットワークを介しても、秘密情報やプライベート情報の暗号化されていないトラフィックが発生する正当な理由はありません。必ずしもパブリック名やCA階層は必要ありません。明確に定義された双方向通信チャネルがある場合は、ロードバランサーが特定の自己署名証明書を信頼するように構成されている明示的な信頼関係を持つ方が簡単な場合があります。バックエンドサーバーのみ。
専門家として、あなたはクライアントに助言する義務がありますが、自分で決定を下すべきではありません。
クライアントに提示する引数は次のとおりです。
- サーバーネットワーク内でHTTPSを使用する利点は何ですか？このネットワークが他のシステムから分離されており、sysadminsだけがアクセスできる場合、すでに管理者権限を持っている人からシステムを保護しているだけなので、利益は無視できると主張するかもしれません。管理者権限のない他のスタッフメンバーがアクセスできる場合、利益はnullではなく、他のクライアントがアクセスできるシステムでもありません。
- それを行うリスクは何ですか？証明書に関する反論は主に...反論です。しかし実際には、HTTPSはHTTPよりも複雑なプロトコルであり、複雑さを追加すると実装エラーのリスクが高まります。前のステップでゲインが無視できると結論付けた場合、クライアントにそれを行わないようアドバイスするのに十分です。
- 追加コストはいくらですか？ここでは、直接コストと間接コストを考慮する必要があります。直接費用には、外部証明書を使用する場合の追加の証明書の価格、またはプライベートPKIを使用する場合のプライベート証明書の作成にかかる時間が含まれる場合があります。また、システムの構成時間も含まれます。そして、証明書のプログラムされた更新を含め、メンテナンス時間を繰り返し費用として含める必要があります-この部分isは責任ドメイン内ですが、クライアントに時間を請求できます。間接的なコストを確立することは困難ですが、複雑さの追加とそれらの考えられる結果によるエラーのリスクを評価するには、自分の経験を使用する必要があります。そして私見あなたは彼らがあなたのアドバイスに従わないことを主張するならば、あなたはそのためにあなたのクライアントに請求するかもしれません。
しかし、あなたがすべてを言ったとき、クライアントは決定に責任があります。
暗号化は安価です。データ漏洩やデータ損失はありません。
サーバー間で暗号化を使用します（サーバー間でTLS認証を使用することをお勧めします）。
安いと言っても、鍵や証明書の管理を考えても安いです。両方のサーバーに自己署名証明書と有効期間の長い証明書を発行するのが妥当な場合があります。
ルールにはいくつかの例外があります。
クライアントまたはサーバーのいずれかが、既知のSSL/TLS脆弱性を持つレガシーです。脆弱なコードを更新することは常に優れていますが、常に可能であるとは限りません。脆弱なコードを完全に無効にし、プレーンテキストを実行し、何らかの方法でリスクを軽減する方が良い場合もあります（まだ良くはありませんが、優れています）。
非常に大量のデータを交換している、または非常に低いレイテンシが必要である。暗号化は、ボトルネックやリソースの独占になる可能性があります。暗号化しないことを選択し、それを保護するために他のことをすることもできます。
「https」は、ネットワークを通過する通信を保護するだけでなく、サーバーによって提示されるcertificateを検証します。これにより、実際に正しいサイトと話していることを知ることができます。そして、私の意見では、これが「https」の真の利点です。
無料で署名付き証明書を発行する「letsencrypt.org」には、これらの利点について説明する多くの資料がWebサイトに掲載されています。彼らは...かなり正しいと私は思います...「その素材が実際に機密であるかどうかにかかわらず、すべてがhttpsである必要があります。」
（mod_sslet alはclient側でも証明書の所有を強制することができますが、これはめったに行われません。ただし、安全な内部アプリケーションの場合は、そのようなことを行う必要があります。次に、サーバーはどのコンピューターがサーバーに接続できるかを制限し、資格情報によってそれらを制限することができますtheyが所有する必要があります。）