クラウドのサーバー側での https Web リクエストの舞台裏

クラウドのサーバー側での https Web リクエストの舞台裏

SRE/DevOps の面接でも頻繁に聞かれる質問である Web リクエストの処理の舞台裏に関する投稿をいくつか読みました。その一般的な流れについては、DNS 解決 -> TCP 接続 -> SSL 接続 -> HTTPS リクエスト -> ロード バランサ -> ファイアウォール -> Web サーバー、そしてそこからリクエストが返されるという、優れた説明ページがたくさんあります。

しかし、クラウドに特化したサーバー側の舞台裏での疑問に対する答えは見つかりませんでした。たとえば、リクエストがグローバル ロード バランサーに到達すると何が起こるのでしょうか。そこで SSL は終了しますか、それとも内部ロード バランサー (構成されている場合) に送られてそこで終了しますか。そこから特定の VM へのリクエストは安全ではありません。他のベンダーも VM と内部ロード バランサーをホストしているからです。リクエストは ACL/ファイアウォールまたは内部 VPC メカニズムによって保護されていますか。

セキュリティを強化するために、暗号化されたトラフィックを再暗号化したり、Web サーバーに転送したりすることはできますが、リソース コストが高くなります。しかし、そうしない場合はどうなるでしょうか。容易なアクセスを回避するために、他のセキュリティ メカニズムが使用されると思います。

前もって感謝します。

答え1

コメントを待ちます:

このような面接の質問は、学校の理科の試験とは異なり、正解は1つだけなので、"合格"ランダムなインターネット プラットフォームで見つかった回答をそのまま繰り返すだけでは不十分です。また、通常は、興味も知識もないものを見逃しても「不合格」にはなりません (特定の職務要件でない限り)。

私の同僚は独自のキーボードを作っていますが、キーボードのキーを押すことで発生する電気信号から一連のイベントを開始したとしたら、きっと大喜びするでしょう。私はまったく気にしません。

もしあなたが私と面接していたら、あなたの答えはすぐに失格になるほど十分なものではなかったでしょう (しかし、私も、例えば DNSSEC 仕様について、あなたが説明した一連の出来事の最初のリンクですぐにあなたに異議を唱えるほど詳しくはありません)。しかし、私はあなたの発言に憤慨するでしょう:「トラフィックを暗号化するとセキュリティは向上するが、リソースコストは高くなる」それはよく言われることですが私は個人的に疑問を抱いているその主張の真実性について。

セキュリティ設計とセキュリティのトレードオフに関して、設計したい対策は、リスク分析で決定された実際の脅威と認識された脅威、およびその費用対効果比への対応です。
これらのリスクは普遍的な真実ではありません (一部は非常に一般的ですが)。企業ごとに異なり、すでに実装されている対策に基づいてリスクが変わることもよくあります。
現実には、さまざまな状況に基づいて、一般的な設計パターンが異なって実装されているのを目にするでしょう。負荷分散の実装方法や TLS の終端場所も、その 1 つです。最後に、次のことを述べます。「IPSEC を使用している場合でも、HTTPS は必要ですか?」

関連情報