ここでは、電子メールシステムを運用する上での脅威に対する技術的なセキュリティ対策を説明する（図表10）。ここに登場するセキュリティ対策は、リスクに応じて導入することが望ましい。

サーバーは常に攻撃される脅威に晒されているため、特にセキュリティ対策を万全にしておく必要がある。

攻撃者は攻撃する際に、まず公開Webサーバーに存在する脆弱性を突いてくると考えられる。したがって、公開Webサーバーにセキュリティホールを残しておくことは危険である。また、セキュリティホールは、公開Webサーバーを構成するOS、Webサーバー、Webアプリケーションなど構成要素の全てに存在する可能性がある。公開Webサーバーの管理者は、公開Webサーバーの構成要素の全ての脆弱性に関する情報を常日頃から収集しておくことが重要である。団体、企業などによってセキュリティホールの情報を収集・公開している代表的なサイトとして、次のサイトがある。

• SecurityFocus（英語）（http://www.securityfocus.com/）
• IPA（http://www.ipa.go.jp/security/）
• JPCERT/CC（http://www.jpcert.or.jp/）

セキュリティホールが発見され、セキュリティパッチが公開された場合は、速やかにセキュリティパッチを入手し、テストを行った上で適用する。セキュリティパッチは、各ベンダーのWebサイトから入手することもできる。

不要なサービスはサーバー管理者の意識から外れることが多く、脆弱性が放置されやすい。したがって、公開Webサーバー上では不要なサービスを停止するか、もしくはそのもの自体を削除することが必要である。さらには、サービスを提供しているポート以外に対する要求に対し応答を返さないよう、サーバーにおいてフィルタリングすることが望ましい。

管理者権限のアカウントは、サーバーに対してすべての操作を行うことができる権限を持つ。デフォルトの設定では、管理者権限のユーザーIDはWindows系OSではAdministrator、UNIX系OSではrootとなっている。これらは攻撃者に最も狙われやすいアカウントである。パスワードクラックツールなどによるパスワード推測攻撃においても、管理者権限のアカウントのユーザーIDがデフォルトの設定のままだと、パスワードのみを推測すればよく、攻撃が容易となるため、管理者権限のアカウントに対して不正アクセスを許す危険性が高くなる。したがって、管理者権限のアカウントのユーザーIDをデフォルト設定とは別のユーザーIDに変更しておくことが有効である。

サーバーを運用する上で、使用していないアカウントを残しておくと、そのアカウントがセキュリティホールになる危険性があるため、不要なアカウントは削除しておく必要がある。例えば、多くのUNIX系OSでは、インストールした状態で多数のアカウントが存在している。必要がなければ削除することが望ましい。

安全なパスワードとは、他人に推測されにくく、パスワードクラックツールなどでも割り出しにくいパスワードのことである。安全なパスワードには、アルファベットの大文字、小文字、数字や記号を含んでおり、名前などの個人の情報から推測されないものが望まれる。よりセキュリティ強度を高めるために、ワンタイムパスワードを導入することも検討すべきである。

Windows系OSの場合、パスワードに対するポリシーとして、長さや有効期間、複雑さやロックアウトの設定ができるため、ポリシーを決定し適切に設定しておくことが望まれる。
UNIX系OSの場合は、PAM（Pluggable Authentication Module）を使用することで、Windows系OSと同等の機能を実現することができる。

Windows系OSやUNIX系OSにはログを取得する機能がある。ログ取得機能を使用することで、ローカルやネットワークを介してサーバーに対して行われた操作内容をログとして記録することができる。ログを取得する際は、以下の点について留意しておくことが望ましい。


●ログの遠隔保存
攻撃者は、攻撃者自身の不正アクセスの履歴を消すために、ログを削除する場合がある。そのため、ログの格納場所をサーバー上だけではなく、ログ専用サーバー（ログサーバー）に飛ばすようにしておくことは有効な手段である。
●正確な時刻への同期
不正アクセスなどの攻撃を受けた場合の追跡調査は、他のログと突合せすることにより行うことが多い。したがって、ログを取得しているサーバーの時刻が正確でないと、ログの前後関係が狂うため事象の把握が困難となる。そのため、ログを取得する場合は、NTP ²サーバーから正確な時刻を定期的に取得し同期しておくことが望ましい。

●ログのローテーション
ログを取得するサーバーでは、一定の大きさのログファイルを保存しておくことができる。しかし、格納できる容量を超えてしまうと、新しいログが記録されない可能性がある。ログファイルが肥大化し、結果として新しいログが取得できないことを未然に防ぐため、ログのローテーションを行うことが有効である。ログのローテーションとは、一定のサイズや期間ごとにログファイル名を変更し、新しいものから一定の数だけ残して、古いものはサーバー上から消去することをいう。なお、消去する場合は、テープ等にバックアップすることで長期保管しておくことが望ましい。

第三者中継とは、電子メールの送信者が本来使用する送信サーバーとは異なる第三者のメールサーバーを不正に利用し、送信元を偽って電子メールを送信することをいう。多くは、メールサーバーの設定のミスを利用している。迷惑メールを受信しない、そもそも自社のメールサーバーを中継され迷惑メールに加担しないようにするために、メールサーバーにおいて適切に対策を行う必要がある。

メールサーバーを第三者中継に利用されないようにするには、第三者中継を無効にする必要がある。無効にするためには、少なくとも以下が正しく設定されていることが必要である。

第三者中継対策の詳細は、以下のWebサイトを参照していただきたい。

IPA UBE（迷惑メール）中継対策
http://www.ipa.go.jp/security/ciadr/antirelay.html

DNSBL(Distributed Sender Blackhole List、通称ブラックリスト)とは、spamhaus（http://www.spamhaus.org/）や、SORBS（Spam and Open Relay Blocking System、http://www.au.sorbs.net/）、MAPS RBL（Mail Abuse Prevetion System Realtime Blackhole List、http://www.mail-abuse.com/）等で提供されている、電子メールの第三者中継を許可、あるいは放置しているメールサーバーを登録したデータベースのことである。ブラックリストを利用することにより、受信する側はブラックリストに掲載されている情報をもとに受信した電子メールを制御することができる反面、利用者側にとっていくつかの問題点があることが指摘されている。

●誤登録をされてしまう可能性がある
  先にあげたSORBSでは、迷惑メールの送信元を特定するために、いくつかのメールアドレスをハニーポット（迷惑メール送信者を特定するためのメールアドレス）として運用している。ハニーポットに送信された電子メールは迷惑メールと判断される可能性がある。例えば、悪意のある第三者がそのハニーポットのメールアドレスを送信者としてなりすまして迷惑メールを送り、迷惑メールを送られた企業がそのメールアドレス（ハニーポットのメールアドレス）向けに返信あるいは配信不要通知を送ることにより、その企業をブラックリストに登録するという攻撃もある。
  また、一度ブラックリストに登録されてしまうと、登録解除までに時間がかかる場合がある。

●巻き添えで登録されてしまう場合がある
  迷惑メールを送る業者が「aaa.bbb.ccc.200」というIPアドレスを使用して迷惑メールを送信している場合、ブラックリスト上では「aaa.bbb.ccc.192/26」という範囲で登録されてしまう場合がある。これは「aaa.bbb.ccc.192-255」までの64個のIPアドレスすべてがブラックリストに登録されたことを意味する。中にはクラスC（256個分）単位で登録するものもある。この範囲内に企業の使用しているメールサーバーが存在する場合は、それらも全て迷惑メール送信元としてブラックリストに登録されてしまう。
  また、ブラックリストの登録はIPアドレス単位で行っているため、共用サーバーなど、ひとつのIPアドレスを複数の企業が使用している場合に、共用サーバー内に迷惑メールを送信する業者が含まれていれば、すべての企業がブラックリストの対象に含まれることになる。

  メールサーバーを立てている企業としては、ブラックリストを利用することにより、迷惑メール業者だけでなく正規の企業からの電子メールでさえも迷惑メールとみなしてしまう可能性があることに留意する必要がある。送信側ではエラーメールとして返信されることが多いため、トラブルに発展することが多い。

ドメイン認証とは、電子メール送信元を認証する技術であり、受信メールサーバー側で送られてきた電子メールが正規のメールサーバーから送信されていることを検証するための技術である。代表的な認証技術を以下に示す。

●SPF（Sender Policy Framework）／Sender ID
  SPFとは、Pobox.com社の創設者Meng Wong氏が提唱した方式であり、2006年にIETFによりRFC4408とし「実験的な」迷惑メール対策技術の提案として承認されている。Microsoft社が提唱していた同種の技術「Caller ID for E-Mail」とSPFを統合した「Sender ID」も同じくRFC4406として承認されている。これらの違いは、検証で使用する情報が異なる点にある。SPFはSMTP通信中にやりとりされるエンベロープ情報により送信ドメインを特定するのに対し、Sender IDは、Resent-Sender:、Resent-From:、Sender:、From:などのヘッダ情報とエンベロープ情報をもとに送信ドメインを特定する。以降、SPFについて説明する。

  SPFによるドメイン認証を実施する場合、送信側が送信メールサーバーのIPアドレスをDNSに登録しておく必要がある。そして、電子メールを受信した受信メールサーバー側では、送信元メールアドレスのドメインを管理するDNSに登録されたメールサーバーのIPアドレスを取得し、SMTP接続元のIPアドレスと比較することにより、正規のサーバーからの電子メールであることを検証することができる。これにより、迷惑メール業者が多様なドメイン名を含むメールアドレスを利用して送信することを防ぐことができる。
  ただし、多くの企業やプロバイダなどが参加しなければ効果が上がらないため、後述の迷惑メール検知システムとの併用や、受け取りを拒否するドメインのブラックリストを別途用意するなど、現在では他の対策を併用する必要がある。また、SPFリソースレコードに対応していないDNSサーバーでは、TXTリソースレコードで代用することが可能である。図表11にSPFによるドメイン認証の概要を示す。

DNSには、具体的に以下のように登録する。

MXリソースレコードに登録されたIPアドレスからのみ送信する場合の例

example.com. IN TXT "v=spf1 mx ~all"

個別にメールサーバーのIPアドレスを送信する場合の例

example.com. IN TXT "v=spf1 +ip4:xxx.xxx.xxx.xxx ~all"

ドメイン認証とは、電子メール送信元を認証する技術であり、受信メールサーバー側で送られてきた電子メールが正規のメールサーバーから送信されていることを検証するための技術である。代表的な認証技術を以下に示す。

●DKIM（DomainKeys Identified Mail）
  電子署名を利用した送信ドメイン認証を実現する方法として存在していた米Yahoo!社が提唱する「DomainKeys」とCisco Systems社が提案する「IIM（Identified Internet Mail）」の二つの規格がまとめられ「DKIM」が策定された。

  DKIMは、電子メールを送信するときに電子署名を行い、受信者がその電子署名を照合する仕組みである。さらに、電子署名に用いた暗号の公開鍵を電子メールのヘッダに添付する技術が追加されている。DomainKeysでは、個々の電子メールに暗号鍵が与えられていたため、ドメイン単位での認証しかできなかったが、DKIMでは個々のメールアドレス単位で認証を行うことが可能である。
  DKIMは電子メールのヘッダや本文を基に電子署名を作成するため、ウイルススキャンやメーリングリストなどにより電子メールのデータに変更が生じると、電子署名が壊れるため正しい送信元からの電子メールであっても認証できなくなるという点がある。図表12にDKIMによるドメイン認証の概要を示す。

DKIM-Signature:ヘッダの例を示す。

DKIM-Signature: a=rsa-sha1; d=example.com; s=tls.dkim; c=simple; q=dns; i=@example.com; t=1117583525; x=1118083525; h=from:to:subject:date; Subject:Hello%20World|Date;b=kWg0D03+zxCFdPlbCx0aeCf・・・

わが国では、WIDE（Widely Integrated Distributed Environment）プロジェクトによってドメイン認証技術の普及率を測定しており、その報告によるとSPFを採用しているDNSサーバーの増加が顕著であることが伺える（図表13）。

図表14に、SPFとDKIMの違いを示す。SPFとDKIMを比較すると、SPFは、DNSサーバー側の設定を変更することで、比較的容易に環境構築ができるので、ドメイン認証を新規で導入する企業にとっては導入しやすい。

攻撃やトラフィックの増加などによりメールサーバーがダウンした場合、利用者すべてに影響が出る。特に近年においては、企業における電子メールの障害が即業務の停止につながる場合が多い。したがって、複数のメールサーバーを使用し、片方が稼働していなくてもサービスに支障が出ないよう冗長化の構成を取ることが有効である。以下、外部用メールサーバーを冗長化する方法を示す。
  DNSにはメールサーバーを指定するMXリソースレコードがあるが、このMXリソースレコードには負荷分散や冗長化を実現する機能が実装されている。具体的な手順としては、DNSサーバーのMXリソースレコードを登録するだけである。

具体的には次のように登録する。

example.com. IN MX 10 aaa.bbb.ccc.1 example.com. IN MX 10 aaa.bbb.ccc.2

また、MXプリファレンス値を異なる値にし、

example.com. IN MX 10 aaa.bbb.ccc.1 example.com. IN MX 20 ddd.eee.fff.1

と記述した場合、外部からexample.com宛のメールは、通常MXプリファレンス値が10のメールサーバー（プライマリメールサーバー）へ送信されるが、このメールサーバーが何らかの事情によりサービスが提供できない状態にある場合は、MXプリファレンス値が20のメールサーバー（セカンダリメールサーバー）に送信される。このように冗長化を実現することが可能である（図表15）。

受信した電子メールによるウイルス感染を防ぐため、クライアントPCにウイルス対策ソフトを導入することが望ましい。しかし、業務上の制約等によりウイルス対策ソフトを導入できないクライアントPCがあったり、一部の従業員がウイルス対策ソフトの機能を勝手に無効にしたりすることがありうる。そのような場合に備え、インターネットと社内間のすべての電子メールをウイルススキャンするアンチウイルスゲートウェイを導入することが有効である（図表16）。こうすることで、インターネットから社内に侵入してくるウイルスから自社を守るだけでなく、社内から社外へウイルスが送出することを防ぐこともできる。

アンチウイルスゲートウェイを導入することにより、利用者が送受信する電子メールのデータや添付ファイルを監視し、ゲートウェイ上でウイルスメールや迷惑メールを遮断することができる。通常、アンチウイルスゲートウェイはSMTPサーバーとして動作し、配送された電子メールを解析する。解析した電子メールがウイルスであると検出された場合は、電子メールの破棄や隔離、ウイルス部分のみ削除、送信者への警告メッセージの送信、などの動作を設定することができる。

アンチウイルスゲートウェイは各セキュリティベンダーから様々な製品が発売されている。それらの特徴を図表17に示す。

情報漏洩防止の技術的対策として、メールフィルタリングソフトを導入することが有効である。メールフィルタリングソフトの主な機能は次のとおりである。

フィルタリング機能では、電子メールのタイトルや電子メール本文、添付ファイルをテキスト分析し、予め登録されたキーワードが含まれていれば、転送を拒否したり、発信者に警告を送信したりできる。また、派遣社員による社外への電子メール送信拒否など、特定の送受信者の電子メールを拒否できる。後の参照のため電子メールを保存することもできる。これらの機能により、電子メールによる誹謗中傷のメッセージや機密情報の漏洩を防止できる。
   保存した電子メールの検索・閲覧機能は、誹謗中傷や機密漏洩を後で確認する際に有効である。しかし、電子メールの内容を閲覧する場合、プライバシーの問題もあるため、あらかじめ電子メールを保存することを従業員へ通知しておくことが望ましい。
   また、レポート機能により、従業員一人一人の電子メールの利用状況を把握できる。利用状況が疑わしい従業員（例えば電子メールの送受信数が異常に多いことや電子メールの送受信サイズが異常に大きい）に対して管理者から警告を行うことで、私用目的での利用や情報漏洩を抑止できる。

主要なメールフィルタリングソフトとその特徴を図表18に示す。

2.1.6 迷惑メール検知システムの導入　サーバー

IDS（Intrusion Detection System）とは、侵入検知システムとも呼ばれ、ホストや通信回線を監視し、不正侵入を検知した場合に管理者へ通知を行うシステムである。IDSは監視対象により、ネットワーク型とホスト型の2つに分類される。

ネットワーク型IDSは、IDSセンサを設置したセグメント上のすべての通信パケットを監視する。トラフィックがあらかじめ登録された攻撃パターンと一致した場合は、侵入行為とみなし、ネットワーク管理者に警告を行う。

ホスト型IDSは、インストールされたホストに対する不正アクセスを検知する。ホスト内のOS、サーバープログラムなどが生成したログやコマンド履歴などを解析したり、ホストへの通信の監視を行う。

ネットワーク型IDSとホスト型IDSの比較を図表20に示す。

IPS（Intrusion Prevention System）とは、侵入防御システムとも呼ばれる。IDSでは侵入を「検知」することしかできないが、IPSは侵入を「防御」することが可能である。つまり、IPSはIDSが持つ検知機能に加え、防御機能を強化したものである。IDSでは、不正アクセスや不正侵入を検知した場合、警告を管理者に送り、それをもとに管理者が対応を行ってきた。IPSは不正アクセスや不正侵入の通信を自動的に遮断することができるため、IDSと比較して運用負荷を軽減することが期待できる。

   IDSおよびIPSにおいて、誤検知が少なからずとも発生する。正常な通信を不正な通信と認識してしまう誤検知のことを「False Positive」といい、不正な通信を正常な通信と認識してしまう誤検知のことを「False Negative」という。通常は、不正な通信を通してしまう「False Negative」の発生がセキュリティ上において問題となるが、IPSを利用している場合には、正常な通信が遮断されてしまう「False Positive」によりサービス提供を阻害してしまうことが問題となるため留意しておくことが必要である。

近年の企業ネットワークでは、外部からの社内ネットワークへの攻撃や侵入を防ぐため、ファイアウォールを導入することは必須となっている。ファイアウォールはネットワークを通過するパケットを監視し、フィルタを設定することにより通信を許可、遮断、あるいは制限することができる。また、Webサーバーを社外へ公開する場合は、DMZ（DeMilitarized Zone 非武装地帯）と呼ばれるネットワークセグメントに設置する。

   DMZとは、外部ネットワーク（インターネットなど）と内部ネットワーク（社内ネットワーク）の間に設置されたネットワークセグメントのことであり、非武装地帯とも呼ばれる。万が一DMZ上に設置されたサーバーが不正アクセスを受けて乗っ取られた場合にも、ファイアウォールにより内部ネットワークまで侵入されないよう防御することができる。

   DMZを設置する場合のファイアウォールにおける基本的なフィルタリングルールを図表21に示す。

ファイアウォール構築での留意点を下記に示す。

ファイアウォールで最も重要な機能は、フィルタリング機能である。必要な通信だけを許可するようフィルタリングルールを設定する。ただし、あまりにも強固なフィルタリングを行うと、想定しない通信障害によるトラブルが発生する可能性がある。サーバーや、使用しているアプリケーションの通信に関する仕様を理解し適切なフィルタリングルールの設定を行い、十分にテストすることが重要である。

最近のファイアウォールは、ログを収集する機能をもっているものが多い。万が一の事態に備えて、ログの取得機能は有効にし、定期的に取得したログの保存や、解析を行うことが望まれる。また、フィルタリングルールの設定に不備があり、サーバーへ接続できないなどの不具合があった場合にも、ログの解析を行うことで対処することができる可能性もある。ただし、ログの取得によりファイアウォールのパフォーマンスが劣化することがあるため、留意が必要である。

電子メールの利用によりクライアントPCへのウイルス感染を防ぐため、ウイルス対策ソフトを導入することが有効である。以下、ウイルス対策ソフトの基本的な動作に関する考慮事項について述べる。

ウイルス対策ソフトがウイルスをチェックするタイミングには、主に次の2つがある。

●リアルタイムスキャン
  電子メールの送受信時や保存している電子メールへのアクセス時などにウイルススキャンを実行する。すべてのファイルへのアクセスをリアルタイムにチェックすると、クライアントPCの動作速度を低下させてしまうため、特定の種類のファイルだけスキャンすることが多い。

●定期的なスキャン
  利用者が指定した時刻に定期的にディスク上にある全てのファイルをスキャンする。

   ウイルスに感染しているファイルが見つかった場合は、ウイルスを駆除あるいは隔離することで、クライアントPCやサーバーのセキュリティを保つことができる。ウイルス対策ソフトは、日々新しく生まれる様々なウイルスに対応するために、最新のパターンファイルをネットワーク経由で定期的に取得し更新することで、新種のウイルスにも対応することができる。

ウイルス対策ソフトでウイルスを検出する方法は主に次の2つがある。

●パターンマッチングによる検出
  ウイルスにはそれぞれパターン（特徴）があり、ウイルス対策ソフトはこのパターン（ウイルスパターン）を記録したウイルス定義データベースを保持している。ウイルス定義データベースは、各ベンダーからウイルスパターンファイルとして配信されている。パターンマッチングとは、ウイルス定義データベースに記録されたウイルスパターンと検査対象のファイルを比較することにより、ウイルスの存在を検出する方法である。ウイルスパターンが検査対象のファイルに存在した場合、ウイルス対策ソフトはそのファイルをウイルスとして検出する。
  この方式によるウイルススキャンは、すでに明らかになっているウイルスパターンとの照合であるため、ウイルスの誤認識が少ない反面、ウイルス定義データベースに登録されていない未知のウイルスは検知できない。新しいウイルスが発見された場合は、各ベンダーによりウイルス定義ファイルが作成され、クライアントPCやサーバーのウイルス定義ファイルを更新しなければならず、この間にウイルスに感染してしまう危険性がある。

●プログラム動作の監視による検出（ヒューリスティック・スキャン）
パターンマッチングによる検出は、未知のウイルスを検出できないという弱点がある。これに対し、ウイルスに感染したプログラムをメモリ上の仮想環境下で実際に実行し、ウイルス独特の動作をすることを監視することで検出する方式がある。この方式をヒューリスティック・スキャンと呼ぶ（図表22）。ヒューリスティック・スキャンでは、システム領域やライブラリの書き換えなど、通常のプログラムが実行しないようなウイルス特有の挙動を検出することでウイルスを検出する。これによりウイルス定義データベースに登録されていない未知のウイルスであっても検出することが可能になる。

図表23に、パターンマッチングとヒューリスティック・スキャンの比較を示す。

ウイルスの中には、電子メールソフトの脆弱性を突くものがあるため、電子メールソフトに対しウイルスに感染しないための設定を行うことが重要である。ここでは、推奨すべき電子メールソフトの設定を以下に示す。

電子メールソフトがHTML形式メールの表示に利用するレンダリングエンジンに脆弱性がある場合、HTML形式メールを開くだけでその脆弱性を突きウイルスに感染する場合がある。また、企業では一般的にテキスト形式メールを利用することが多いことから、テキスト形式にて電子メールを利用することが望ましい。

ウイルスの中には、電子メールソフトのプレビューウィンドウに電子メールの内容を表示するだけで、その表示機能の脆弱性を突いて感染するウイルスの存在が報告されている｡このようなウイルスの感染を防ぐためには、OSやブラウザのセキュリティパッチを適切に適用しておくことや、不審な電子メールをそもそも開かないことが重要である。また、必要がなければ、電子メールソフトのプレビュー機能をオフにしておくことも有効な手段である。

電子メールを盗み読まれることを防止することや電子メールの送り主の正当性を確認するために、暗号メールを使用することが有効である。暗号メールの基本的な技術は、共通鍵暗号方式と公開鍵暗号方式を組み合わせたものである。
送信者側は、共通鍵を使用して電子メール本文の暗号化を行い、その共通鍵を受信者の公開鍵で暗号化したものを暗号化された電子メール本文と結合し送信する。
   受信者側は、受信者の公開鍵で暗号化された共通鍵を受信者の秘密鍵で復号し、次に、暗号化された電子メール本文をその共通鍵で復号する。電子メールが改ざんされていた場合は、復号処理が失敗するため、改ざんされたことを確認することができる。
   電子署名は、電子メール本文をメッセージダイジェスト関数にかけることによりメッセージダイジェストを生成し、送信者の秘密鍵により暗号化することで作成する。送信者は、電子署名を電子メール本文に結合し送信する。受信者側では、電子署名を送信者の公開鍵により復号しメッセージダイジェストを取り出す。この際、送信者の公開鍵により復号できることで送信者本人が送信したことを確認することができる。また、受信者側でも電子メール本文からメッセージダイジェストを生成し、先のメッセージダイジェストと一致していることにより改ざんされていないことを確認することができる。

暗号メールには以下に示す2種類の方法がある。

公開鍵は、その所有者が本当にその本人であることを保証する人や組織によって署名される。これらの暗号メールでは、誰によって電子署名された公開鍵を信用するかというモデル（信頼モデル）が異なっている。それぞれの特徴は以下の通りである。

PGP（Pretty Good Privacy）は、米国のPhilip R. Zimmermann氏を中心に開発された暗号化ソフトウェアである。PGPで用いられる信頼モデルは「信頼の輪」と称される（図表24）。公開鍵の信頼性を人間の信頼関係に委ねているところに特徴がある。PGPの場合、公開鍵は自身で作成するため、取得に費用がかからず、比較的狭い範囲で手軽に利用するのに適している。また、PGP公開鍵を一般に広く公開し、公開鍵の交換を円滑にすることを目的としたPGP鍵サーバーが存在する。日本においては、「PGP Public Keyserver」が日本ネットワークインフォメーションセンター（JPNIC）により実験的に提供されているが、あくまで公開鍵の利用は、利用者本人の責任において行なうものとしている。

S/MIME は 1995 年に RSA Data Security 社を中心としたベンダーのコンソーシアムの手により生まれた。その後IETFのS/MIME Working Groupで議論され、 S/MIME v2として規定された。その後 S/MIME v3の標準化が進められ、1999 年S/MIME Version 3 は、S/MIMEの機能を拡張するためにIETFによって提案された。RFC 2632は、S/MIMEメッセージの標準の仕様を規定し、RFC 2633は、証明書処理の仕様を拡張し、RFC 2634は、S/MIMEへサービスを追加し全体的な機能を拡張している。また、S/MIME v3 では Diffie-Hellman/DSS を暗号化、署名アルゴリズムとして SHA-1 をメッセージダイジェスト関数として採用する方向で標準化されている。

   先述のPGPは暗号化ソフトウェアとして実装されているのに対し、S/MIMEは規格であることが異なる。S/MIME規格で定められた仕様にそって実装された電子メールソフトを使うことにより、電子メールの暗号化や電子署名が可能となる。

   また、PGPでは公開鍵を個人で作成するのに対し、S/MIMEは認証局が発行した公開鍵証明書を使用する。したがって、利用者がS/MIMEによる電子メール本文の暗号化や電子署名を利用するには、公開鍵の証明書を認証局から交付してもらう必要がある。公開鍵の正当性は、認証局が証明している点がPGPとは異なる。

PGPとS/MIMEの比較を図表25に示す。