クラウドネイティブのCaaSプラットフォーム
高セキュリティのもとで、
圧倒的なユーザビリティで
マルチクラウドの開発・運用をサポート
- スピーディーにデプロイ
- コスト削減
- 高可用性
- 優れたスケーラビリティ
高セキュリティのもとで、
圧倒的なユーザビリティで
マルチクラウドの開発・運用をサポート
HTTPが安全でない理由
HTTPプロトコルは、TCP / IP 4層モデルのアプリケーション層にあり、それ自体は データ暗号化メカニズムを提供していません。
HTTPプロトコルは、TCP / IP 4層モデルのアプリケーション層にあり、それ自体は データ暗号化メカニズムを提供していません。クライアントとサーバー間の通信はすべてプレーンテキストです。仲介者がネットワークパケットを取得すると、情報漏洩が発生し、データが改ざんされ、下図のように、フィッシング目的でサーバーのIDが偽造できます。
HTTPS
HTTPSプロトコルは、HTTPのセキュリティ問題を解決するために導入されました。
データの機密性を高めるために、HTTPS通信を使用するときにデータが暗号化されます。暗号化アルゴリズムは、対称暗号化と非対称暗号化に分けることができます。
対称暗号化
対称暗号化アルゴリズムでは、データの暗号化と復号化に同じパスワードが使用されるため、仲介者がデータを盗んだとしても、パスワードがないため復号化できません。
一部の戦争映画やテレビの作品では、無線を使用して通信しているのを見たことがあると思います。これは、典型的な対称暗号化シーンです。戦闘指令は、無線局がコードブックを介して送信するのに適した一連のコードに変換され、受信機は、コードブックに従って元の戦闘コマンドにコードを変換します。 この過程で、敵がラジオ局から送られてきたコードを盗んだとしても内容を解読することはできませんが、コードブックを敵が入手すると情報が解読されてしまいます。
ネットワークでは、クライアントとサーバーも対称暗号化アルゴリズムを使用してデータを暗号化する場合、両方の当事者が最初にパスワードをネゴシエートする必要があり、その後のデータはパスワードを使用して暗号化および復号化されます。これにより、データのセキュリティはある程度向上しますが、ネゴシエーション パスワードプロセスはプレーンテキストのままであり、仲介者はパスワードを取得して情報を簡単に解読できます。
では、パスワードネゴシエーションプロセスを安全にする事をどのように保証するのでしょうか。 次に、非対称暗号化アルゴリズムを使用する必要があります。
非対称暗号化
非対称暗号化アルゴリズムでは、公開鍵と秘密鍵のペアの鍵を使用する必要があります。公開鍵を使用して暗号化されたデータは、対応する秘密鍵を使用して復号化する必要があり、秘密鍵を使用して暗号化されたデータは、対応する公開鍵を使用して復号化する必要があります。
ネットワーク通信中に、サーバーは公開鍵をクライアントに送信します。クライアントは公開鍵を使用してデータを暗号化し、サーバーに送信します。データを受信した後、サーバーは秘密鍵を使用して復号化します。このプロセスでは、仲介者がデータを盗んだとしても、サーバーの秘密鍵はクラックできません。これにより、クライアントからサーバーに送信されるデータの安全が保証されます。
サーバーの公開鍵がネットワークで送信されることを考慮して、仲介者はサーバーの公開鍵も取得できるため、仲介者はサーバーからクライアントに送信されたデータをクラックでき、サーバーがクライアントにデータを送信するときに秘密鍵を使用して暗号化できません、クライアントとネゴシエートされた対称キー暗号化のみを使用できます。さらに、対称暗号化アルゴリズムの効率は、非対称暗号化アルゴリズムの効率よりもはるかに高くなります。 クライアントとサーバーは非対称暗号化アルゴリズムを使用して、対称キーのネゴシエーションプロセスが安全であることを確認します。対称キーが使用可能になると、以降の通信で対称キーを使用してデータを暗号化できます。プロセス全体を次の図に示します。
ただし、この通信プロセスにはまだ抜け穴があります。仲介者はサーバーの公開キーを傍受し、それを仲介者の公開キーに置き換えることができます。仲介者は、秘密キーを使用して、ネゴシエートされた対称キーを解読できます。プロセス全体を次の図に示します。
この脆弱性で言えるのは、サーバーの受信した公開鍵が本物であるか、改ざんされているかをクライアントが知らないことです。実際には、書類を受け取ったときに真偽を区別できない場合がありますが、例えば官庁の公印が押されていれば、官庁に出向いて真正性を確認できるため、識別が容易です。HTTPSプロトコルを使用して通信する場合、 証明書の役割は公開鍵の正当性を証明することです。
証書
暗号化の分野では、証明書は公開鍵の所有権を証明する電子文書であり、デジタル証明書と呼ばれることもあります。 証明書には、公開鍵情報、公開鍵所有者情報、および認証局の署名が含まれています。
認証局CA（認証局）は証明書を発行でき、サーバーは証明書を申請するときに独自のID情報と公開鍵を提供する必要があります。 Webサイトで使用される証明書の場合、独自のID情報には、Webサイトのドメイン名、会社名、市、州、国が含まれ、公開鍵はWebサイトの管理者によって事前に生成されます。
CA認証局による証明書の発行プロセスは次のとおりです。
証明書のデジタル署名は、日常生活における政府の公式印鑑に似ており、証明書を認証するための鍵となります。 次の図に示すように、CA認証局はデジタル署名を生成するときに、最初に公開ハッシュアルゴリズムを使用してID情報と公開キーをハッシュし、証明書のダイジェスト情報を取得してから、CA認証局自体の秘密キーを使用してダイジェスト情報を暗号化します。
デジタル署名が証明書の信頼性を検証するための鍵である理由は、クライアントがCA認証局の公開鍵を使用してデジタル署名を復号化し、証明書の概要を取得できるためです。クライアントは、証明書からID情報と公開鍵を抽出して実行することもできます。2つの証明書の要約が一致している場合は、別の証明書の概要を入手してください。これは、証明書の内容が改ざんされていないことを意味します。
ID情報と公開鍵が改ざんされると、証明書ダイジェストが変更され、デジタル署名が改ざんされると、CA認証局の公開鍵を使用して復号化できなくなります。
要約すると、証明書は公開鍵の信憑性を証明するために使用され、クライアントが公開鍵の信憑性を区別できないという前述の問題を解決します。 クライアントとサーバーが対称鍵をネゴシエートすると、公開鍵はクライアントに直接送信されなくなりますが、公開鍵を含む証明書が送信されます。クライアントは、最初に証明書の信頼性を検証します。証明書がtrueの場合のみ、公開鍵は証明書から抽出されます。 重要なのは、完全な通信プロセスは次のとおりです。
多くの科学者がネットワークセキュリティを改善しようとしている一方で、ハッキングと攻撃の技術は常に進化しており、現在使用されているHTTPSプロトコルは完全に安全ではありません。
たとえば、HTTPSプロトコルをサポートするために、ブラウザはさまざまな権限のあるCA機関の公開鍵証明書をプレインストールして、サーバー証明書を検証します。フィッシングWebサイトが見つかった場合、ブラウザはセキュリティの通知を表示するか、アクセスを拒否します。ただし、ブラウザが誤ってハッカーの証明書をインストールすると、フィッシングWebサイトがブラウザを欺いてユーザーのプライバシーデータが盗まれてしまいます。