電子メールが本質的に安全でない理由の良い、シンプルなリスト
私はしばらくの間、機密データを電子メールで送信することの固有のリスクについての適切な情報を得ようと努めてきました。 「IT以外のビジネスリーダーのためのITセキュリティ101」トレーニングイニシアチブの一部として使用できる外部ソースからのすべての脆弱性の包括的なリストを本当に探しています。 （私は最初にこことGoogleの両方で検索を行いました。Googleでは長い記事をどんどん取得しています。また、Google検索だけでなく、ここでも良い部分を見つけましたが、探しているような完全なリストではありません。）
その背景には、私にはビジネスの面で色々な人がいます。彼らは電子メールの使用を主張し、それが安全でないという事実を受け入れることを拒否します。
現在のジレンマでは、レポート用にSSRSを実装しており、SSRSサイトでレポートを表示することを期待しています。その理由は、私たちが扱うほとんどのレポートには何らかの形式の機密データが含まれており、これらのレポートを電子メールで送信したくないからです。当社が運営する州の規制では、PIDを姓、名のイニシャルまたは名前、およびその他の形式の識別情報（住所、SSN、口座番号、電子メールなど）として識別します。州の法律では、漏えいが500かそのようなPIDを含むレコードをさらに州に報告する必要があります。
多くのレポートにはこの定義によるPIDが含まれており、ほとんどのレポートには500をはるかに超えるレコードがあります。したがって、IMOがスニファによって拾われた、または誤って間違った人に送信された単一のレポートは、報告可能な違反です-not対処したいもの。
しかし、私たちには特定の上位レベルの管理職がいて、ルールがそれらに適用されないと考えているようです。これは主に、彼らがリスクがどれほど現実であるかを理解していないためです。 goodニュースは、私たちが彼らの考えを変えることにおいて前進しているということです。悪いニュースは、私たちが技術的になりすぎると、彼らの目が眩しくなることです。また、彼らは私たちの言葉だけを受け取りたくないのです。
私が考えることができる例：
- スニファを使用して、ネットワークを移動する電子メールを読み取ることができます。
- 電子メールは、送信者と受信者の間の多くのサーバーを通じて送信されます。これらのサーバーのいずれかがそのメールを傍受して保存している可能性があります。
リストが技術的すぎることにあまり心配していません-技術的な概念を説明するためにビジネスが理解するアナロジーを私たちは私たちに教えてくれます。すべてのリスクがあるリストにもっと興味があります。
類推したければ、 これを読んでください 。
脆弱性のリストについては：
- 電子メールは暗号化されていないため、転送中に盗聴される可能性があります（someサイトは便宜的に転送に暗号化を採用しますが、これは確実にアクティブ化されません）。
- 電子メールは、操作に関与するサーバーの送信者の電子メールサーバー、受信者の電子メールサーバー、およびその間のサーバーの物理ディスクに保存されます。物理ディスクは、使用停止時またはバックアップテープを介して盗聴できます。これらのサーバーを管理する施設の退屈なインターンは、単に一見することができます。
- DNSを変更することで、電子メールを間違ったマシンに送るのは簡単です。
- 感染したマシンが受信した電子メールを定期的に検査し、パスワード、クレジットカードデータ、その他のジューシーな情報を探すウイルスがあります。
メールシステム全体では、誰もが正直であり、ニースで信頼できると想定しています。それがまったく機能するのは驚くべきことです（しかし道徳的に励みになります）。
シンプルで最も深い答えは、クライアントからメールサーバーへのメールの送信とメールサーバー間のメールの送信を処理するSMTP（Simple Mail Tranfer Protocol）（POP3やIMAPなどの他のプロトコルは、今日のメールの取得に通常使用されます）が最初に設計されたことです。 ARPANETで使用します。ARPANETは、それを使用できる誰もが最初にセキュリティクリアランスを持っていたときに動作しました。そのため、SMTPは、情報セキュリティの4つの主要な側面のallで失敗します。そうすることを試みるために更新されたことがない。
- Confidentiality：デフォルトでは、SMTP電子メールは転送中やその他の時点では暗号化されません。暗号化されていないチャネルを介して送信されている間、またはいずれかの当事者のメールサーバーに格納されて取得を待機している間、誰でもそれらを読み取ることができます。
- Integrity： SMTPは、送信に使用されるトランスポート層プロトコル以上のエラーチェックを提供しません。だれもメッセージを改ざんしていないことを確認したい場合、それはひどく不適切です。 TCPは、ネットワーク自体がデータの破損や損失を引き起こしていないことを確認するのに役立つように設計されています。ある場合は、転送中のTCPパケットの内容を変更することは簡単です送信されるネットワークノードの1つの制御。
- Authenticity： SMTPには、リストされた送信者が実際に送信者であることを確認する手段がありません。世界中の誰かが「差出人」フィールドにあなたのアドレスを記載した電子メールを作成できますが、その違いは誰にもわかりません。
- Non-Repudiation：送信者としてリストされた人が実際に送信したこと、または電子メール自体がその送信者によって送信された元のコンテンツであることを確認できないため、その人は非常に丁寧に拒否できますあなたが受け取ったものは彼らが送ったものである、または彼らが最初にあなたに電子メールを送ったということです。
SMTPにSSL/TLSセキュリティハンドシェイクを追加し、SMTPSを作成することで、旅行の最初の行程（コンピューターから "自宅"の電子メールサーバーへ）に機密性が提供されます。それで全部です;旅行の他の区間に沿って機密性を適用することはできません。InfoSecの他の3つの側面は影響を受けません。
機密情報の転送に電子メールを使用したくない主な理由の1つは、機密情報を含む電子メールが組織を離れると、それを制御できなくなったためです。
例えば
- ユーザーは受信トレイに機密の電子メールを置いており、そこに座っているだけです。アカウントが侵害された場合、あらゆる種類の機密情報が記載された電子メールを自由に支配できるようになります
- その受信ユーザーが、その情報を受信してはならない相手に電子メールを転送するかどうかについて、もはや知識がありません。
- これで、2つの潜在的な侵害のポイントがあります。電子メールを送信したサーバーと電子メールを受信したサーバーです。あなたはそれらのサーバーの管理者に多くの信頼を置き、あなたはただ希望彼らはスヌーピーではなく、彼らが見るべきではない情報を見ます
- 受信側での保持ルールやアーカイブプラクティスに対するガバナンスはありません。有効期間が制限されているはずのドキュメントは、アーカイブや削除の練習をせずにサーバー上で永久に存続する可能性があります
上記の理由から、ほとんどの場合、機密情報を電子メールで送信する別のソリューションをお勧めします。
insecureはどういう意味ですか？
- 機密性->はい、メールは安全ではありませんが、必要に応じて暗号化レイヤー（PGPなど）を使用できます。
- 効率的に->いいえ：メールは、特定の人に情報を送信する最も簡単で安全な方法の1つです。
securityには多くのベクトルがあることを忘れないでください。永続性と効率性は、セキュリティの重要な要素でもあります。
類推
メールシステムネットワークは、実際の投稿と同じように機能します。
- かつて紙の手紙で何かを書くことができた
- 有毒物質を紙に加える
- 偽の送信者アドレス
- 封筒の差出人アドレス
- 別の封筒でカプセル化して、別の都市の郵便局を介して送信します。
これはすべてvery unsecureですが、とにかく、誰もが実際の投稿で交換し続けます。
人々が再び害を及ぼす場合投稿のセキュリティ、それは手紙が他のものより緩いかもしれないという事実についてです...
主な違いは、1通のメールを送信するコストです。これはmoreがらくたを暗示するだけで、他には何もありません。
したがって、vueの私のポイントはと言うことです）smtpはうまく機能するプロトコルであり、元の目標について非常に説得力があります。
守秘義務について
実際の投稿を通じて機密情報を送信するようなものです。このようなことをしなければならないことは、その後の証券化の取り組みを暗示します。
したがって、単純に機密情報をクリアテキストで送信しないでください。
別の方法を使用して、キーと有効な指紋を優先順に交換します：会議、電話、ファックス、SMS（注意）。