Blog Banner - Why TLS May Not Be Enough for Your Email Encryption Strategy

なぜTLSだけではメール暗号化戦略に不十分なのか

デジタル時代は、私たちの生活やビジネスの運営方法を革命的に変えました。今日の企業は、顧客やクライアントとの関与が大幅に向上しています。また、これらの企業は、ビジネスをよりよく理解するためのデータを多く持っています。このデータは、企業が非効率性のギャップを埋め、成長の機会を特定し、顧客により良いサービスを提供するのに役立ちます。

このデータは、驚くべきことに非常に貴重です。したがって、非常に競争の激しい市場で企業が生き残るためには、データの保護が重要になっています。組織が個人識別情報(PII)、保護対象保健情報(PHI)、知的財産(IP)、その他の機密情報を保護することで、ビジネスの継続性を確保し、データプライバシー規制へのコンプライアンスを示し、評判を維持します。

企業は、機密情報をサーバーに保存する場合でも、メールや他の通信チャネルを介して共有する場合でも、保護する必要があります。トランスポート層セキュリティ(TLS)は、Payment Card Industry Data Security Standard(PCI DSS)、Health Insurance Portability and Accountability Act(HIPAA)、欧州連合のGeneral Data Protection Regulation(GDPR)などの規制に準拠するために、すべての組織のメールセキュリティ戦略の重要な部分となっています。

しかし、TLSを有効にするだけでは、メールが覗き見から安全であることを保証するものではありません。実際、多くの組織がTLSを誤って使用しており、その結果、メールが不正アクセスやデータ漏洩に対して脆弱になっています。

TLSはどのように機能するのか?

ウェブサイトやアプリケーションがTLSを使用するためには、TLS証明書がインストールされている必要があります。TLS証明書は、ドメインを所有する個人または企業に発行されます。この証明書には、ドメインの所有者とサーバーの公開鍵に関する重要な情報が含まれており、サーバーのアイデンティティを検証するために重要です。

TLS接続は、TLSハンドシェイクと呼ばれるシーケンスを使用して開始されます。誰かがTLSを使用するウェブサイトを訪れると、ユーザーのデバイス(クライアントデバイスとも呼ばれる)とウェブサーバーの間でTLSハンドシェイクが始まります。

TLSハンドシェイク中に、ユーザーのデバイスとウェブサーバーは次のことを行います:

  • 使用するTLSのバージョン(TLS 1.0、1.2、1.3など)を指定する、
  • 使用する暗号スイートを決定する、
  • サーバーのTLS証明書を使用してサーバーのアイデンティティを認証する、
  • ハンドシェイク完了後にユーザーのデバイスとウェブサーバー間でメッセージを暗号化するためのセッションキーを生成する。

証明書機関(CA)とは何か?

証明書機関(CA)は、エンティティ(例:ウェブサイト、メールアドレス、企業、個人)のアイデンティティを検証し、暗号鍵に結びつけるために電子文書(デジタル証明書)を発行する組織です。

デジタル証明書は以下を提供します:

  • 認証—発行されたエンティティのアイデンティティを検証するための資格情報として機能します。
  • 暗号化—安全でないネットワーク上での安全な通信のため。
  • 証明書で署名された文書の整合性を保証し、第三者が転送中にそれらを変更できないようにします。

TLSとSSLの違いは何か?

TLSは、Netscapeによって開発されたセキュアソケットレイヤー(SSL)という以前の暗号化プロトコルから進化しました。TLSバージョン1.0はSSLバージョン3.1として開発が始まりましたが、公開前にプロトコルの名前が変更され、Netscapeと関連付けられなくなりました。その結果、TLSとSSLは時折、同じ意味で使用されることがあります。

TLSの潜在的な脆弱性

TLSとSSLは、どの企業のデータセキュリティアプローチにおいても重要な基盤を形成しますが、それでも脆弱性を含んでいます。

主な弱点は、企業がメール暗号化について理解していないことに起因します。多くの企業は、TLSが使用されると、トランスポートチャネル、ひいてはメールが完全に保護されていると信じています。

しかし、企業は、メールメッセージが送信者と受信者のメールサーバー間を移動することを忘れてはなりません。このチャネルには、ネットワーク外のホップが含まれています。メールは次のメールホップまでしか保護されておらず、次の簡易メール転送プロトコル(SMTP)ホップに到達した後に何が起こるかを制御することはできません。

したがって、機密メッセージは企業のネットワーク内で露出する可能性があり、TLSはエンドツーエンドの暗号化を提供しません。TLSは送信者のデバイスから企業のメールサーバーまでのチャネルを保護するだけです。しかし、メールはしばしば追加のサーバーを介して転送され、そこで暗号化が保証されません。

例えば、アンチウイルスチェックやコンテンツスキャンの場合、データは途中で好奇心旺盛な管理者や他の従業員に露出する可能性があります。

もう一つのセキュリティリスクは、使用されるX.509証明書にあります。多くの企業は証明書を検証せず、すべての機密データが露出しています。

企業は、信頼できる評判の良い証明書機関(CA)によって証明書が発行されていることを確認する必要があります。これは決して簡単なことではなく、多くの企業が自分で証明書に署名しています。

企業はまた、証明書が有効であるかどうか、暗号化アルゴリズムと鍵の長さが最新であるか(つまり、最先端であるか)を確認する必要があります。

多くの企業、特にOpenSSLを使用する企業は、適切なCAからの証明書よりも便利でコスト効果が高いため、自分で証明書を作成します。はい、証明書には費用がかかります。購入し、更新する必要があります。企業が更新を忘れると、証明書は最終的に取り消され、新しい証明書のために再びCAに支払う必要があります。

企業はまた、”完全な前方秘匿性”を展開しない不正なTLSバージョンを使用すると、キーを発見した不正使用者によってメッセージが復号される可能性があることを知らないことがよくあります。

もう一つの既知のTLSの制限は、”オプションTLS”システム構成です。”必須TLS”では、発信システムはチェーン内の次のシステムがTLSをサポートしている場合にのみメールメッセージを転送します。そのシステムがTLSをサポートしていない場合、メッセージは転送されません。しかし、システムが”オプションTLS”を採用している場合、メッセージはとにかく転送され、チャネルが暗号化されず、メッセージが露出します。

ここに、TLSがメール通信を保護するのに不十分である理由がいくつかあります。

TLSは一部の攻撃からメールを守るが、すべての攻撃から守るわけではない

TLSだけではメールセキュリティには不十分であり、一部の形式のメール攻撃からしか保護しません。TLSは特に、データが転送中に発生する中間者攻撃や盗聴攻撃に対して効果的です。サーバーやデータベースに機密情報を保存している場合は、Pretty Good Privacy(PGP)やSecure/Multipurpose Internet Mail Extensions(S/MIME)などの追加の暗号化プロトコルを使用する必要があります。

これらの暗号化プロトコルは、ハッカーがサーバーにアクセスした場合でも、暗号化されたデータを読むことができないようにします。また、これらのプロトコルは平文を送信することに依存しないため、暗号化された通信ストリームを監視するトラフィック分析や他のサイドチャネル攻撃に対しても脆弱性が低くなります。

TLSはダウングレード攻撃に対して脆弱である可能性がある

TLSは通常、コンピュータとサーバー間の接続を保護するために使用されます。例えば、ブラウザを使用してメールにログインする場合などです。しかし、他の接続、例えばサーバー間でメールを送信する場合にも使用できます。

このアプローチの問題は、全体の接続が暗号化されていないことです。送信サーバーと受信サーバー間のデータのみが暗号化されており、それらのサーバーが強力なセキュリティを持っていない可能性があります。ダウングレード攻撃は、暗号化されていないリンク上のトラフィックを傍受し、メッセージを読み取ることができます。エンドツーエンドの暗号化がない限り、データと組織を危険にさらす可能性があります。

TLSにはより強力なハンドシェイクが必要

TLSは今日最も一般的に使用されている暗号化プロトコルですが、それでも制限があります。会社のメールが最初から安全で暗号化されていることを確認するために、PGPやS/MIMEなどの暗号化アルゴリズムを使用してSTARTTLSを使用してください。

これにより、誰かが転送中にメールを傍受しても、プライベートキーがなければ読むことができません。また、最初のTLSハンドシェイクの上に追加の暗号化層を持つことで、中間者攻撃が発生するのをより困難にします。

機密情報を安全に送信する必要がある場合は、サードパーティのサービスプロバイダーを通じてメールを暗号化することで、さらに保護層を追加することを検討してください。

Kiteworksによるエンドツーエンドのセキュリティと暗号化

Kiteworksは単なるセキュアメールプロバイダーではありません。組織内外で機密コンテンツを送受信する際のガバナンス、コンプライアンス、セキュリティに関連するプライベートコンテンツネットワーク(PCN)として機能します。

Kiteworksは、メール暗号化ゲートウェイやMicrosoft Outlookプラグイン、ウェブアプリケーション、エンタープライズアプリケーションプラグイン、モバイルアプリケーションを通じて、エンタープライズグレードの暗号化と統一されたセキュリティコントロールを提供します。また、組織の最も機密性の高い情報のセキュリティとコンプライアンスを確保するための役割ベースのポリシー自動化も提供します。

パーソナライズされたデモをスケジュールして、Kiteworksが機密情報を含むメールの送受信をどのように自動化するかを学び、使用される暗号化標準に関係なく、その方法を確認してください。

Get started.

It’s easy to start ensuring regulatory compliance and effectively managing risk with Kiteworks. Join the thousands of organizations who feel confident in their content communications platform today. Select an option below.

Lancez-vous.

Avec Kiteworks, se mettre en conformité règlementaire et bien gérer les risques devient un jeu d’enfant. Rejoignez dès maintenant les milliers de professionnels qui ont confiance en leur plateforme de communication de contenu. Cliquez sur une des options ci-dessous.

Jetzt loslegen.

Mit Kiteworks ist es einfach, die Einhaltung von Vorschriften zu gewährleisten und Risiken effektiv zu managen. Schließen Sie sich den Tausenden von Unternehmen an, die sich schon heute auf ihre Content-Kommunikationsplattform verlassen können. Wählen Sie unten eine Option.

Comienza ahora.

Es fácil empezar a asegurar el cumplimiento normativo y gestionar los riesgos de manera efectiva con Kiteworks. Únete a las miles de organizaciones que confían en su plataforma de comunicación de contenidos hoy mismo. Selecciona una opción a continuación.

始めましょう。

Kiteworksを使用すれば、規制コンプライアンスを確保し、リスクを効果的に管理することが簡単に始められます。今日、コンテンツ通信プラットフォームに自信を持つ数千の組織に参加しましょう。以下のオプションから選択してください。

Table of Content
Share
Tweet
Share
Explore Kiteworks