ソフトウェア > Lotus > Lotus Developer Domain > 製品別技術情報 > Lotus Notes/Domino >

LDD Today

Domino 6 を使用するセキュアなメッセージングのレッスン

by Timothy Speed, Consulting IT Architect, IBM
Raj Balasubramanian, Consulting IT Architect, IBM
レベル：初級
原文の掲載：2004年7月6日

LDD Today の原文（US）

インデックス

	SMTP
	メッセージの完全性
	閉鎖型と開放型の証明書発行システム
	Domino CA
	証明書を使用する
	まとめ
	リソース

この記事では、Notes/Domino 6 メッセージング・セキュリティーの主な要素がどのように連携して機能するかについて、オイル・ビジネスを例にとって簡潔にわかりやすく解説します。

まず、約 30 年の間、オイル・ビジネスに携わってきた Jed という男性から話を始めます。石油を発見するには、地面を何箇所も掘削することが必要です。このため、Jed は石油機器ベンダーから、掘削機、トラクター、石油ポンプなどの機器をしばしばレンタルしています。また、パイプや他のハードウェアも購入しています。

ある日、Jed の甥の Jethro が仕事を求めてオフィスにやってきました。Jed は彼を雇い入れ、「Hondo County におけるすべてのサービスのベンダー管理担当副社長」の肩書きを与えました (肩書きが長いのは Jethro の希望です)。数か月後、Jethro から Jed に、予期せぬ大量の機器が家の前に運ばれてきている、という電話がありました。最初、Jed は、うっかり屋の Jethro が実際に注文しておきながら、それを忘れているのではと疑いました。しかし、Jethro は、機器はまったく注文してないので、返却されるべきだと主張します。一方、機器のレンタル会社は、運搬料と 1 日分のレンタル料の支払いを求めています。この種のハードウェアのレンタル料は相当な額になります。このため、Jed がレンタル会社に連絡したところ、実際に Jethro から注文されていることが確認されました。

調査の結果、次のことがわかりました。まず、レンタル会社には Jethro のいとこの Ellie May が勤務していました。Ellie には、前のボーイフレンドである Bob Hacker がいて、彼は別れた後も彼女に怒りを持っていました。そこで、Bob は Jethro の名前を使用し、「30 台のタンク・ローリーと 14 台の掘削機を Jethro の自宅まで届けて欲しい」という偽の注文メールを Ellie に送ったのです。

事実が明らかなった直後、Jed はこのようなことが二度と起こらないようにするには何をすればよいのかを理解しました。もちろん、ビバリー・ヒルズに引っ越し、ボウリング場付きのマンションを購入したわけではありません。Jed は IBM に連絡し、Jethro とレンタル会社の双方にセキュアな Domino メッセージングを構築したのです。(この時点で、「各ベンダーに Web ページをセットアップし、SSL (Secure Sockets Layer) を使用すれば解決するのでは、と思われる読者もいるでしょう。確かにそれも 1 つの方法ですが、それでは、セキュア・メッセージングについての今後の説明につながりません。また、希なケースですが、Web サイトを持たない会社もあり、多くの会社では、ビジネスのバックボーンとして電子メールが使用されています。)

この記事では、この架空の登場人物が、ベンダーと自分自身にどのような方法でセキュアなメッセージングを実装したかについて解説します。ここでは、読者が Notes/Domino に慣れているものと想定します。(もちろん、昔のテレビ番組「The Beverly Hillbillies」を知っていなくてもかまいません。)

SMTP

Notes/Domino は、堅牢、セキュア、そしてスケーラブルなメッセージング・システムであることは誰もが知っています。しかし、誰もが Notes/Domino を持っているとは限りません。そこで、クロスベンダーのメッセージング・ソリューションである、セキュア SMTP メッセージングについて考えてみましょう。

SMTP (Simple Mail Transfer Protocol) （US）は、インターネットで送信されるメールのデファクト・スタンダードです。実際に、最初の仕様は、Web が登場する前の 1982 年に公開された標準 (RFC821) です。(なお、URL を定義する標準は 1994 年に公開されています。)インターネットでメールを送信するときは SMTP を使用します。Notes/Domino は SMTP メッセージングを完全にサポートし、メッセージをセキュアに保つための強力なメカニズムを数多く提供します。

SMTP が定義されたほぼ同じ時期に、PKI も開発されています。PKI (公開鍵基盤)（US）は、信頼された第三者 (認証機関または CA と呼ばれます) が、ユーザーとサーバーにデジタル ID を提供し、X.509 V3 デジタル証明書を使用してこれらの ID を発行するセキュアなシステムです。ID は、公開鍵と秘密鍵という非対称の鍵ペアで構成されます。公開鍵は誰もが使用でき (名前のとおりです)、秘密鍵はユーザーだけが知っている固有の鍵です。このデジタル ID を使用すると、鍵ペアを用いて暗号化することにより、テキストをセキュアに交換できます。

メッセージングで鍵ペアを使用する基本的な方法には、次の 2 通りがあります。

メッセージの完全性送信者は、メッセージの内容に基づいてメッセージ・ダイジェスト (ハッシュ値、指紋、または透かしと呼ばれることがあります) を作成します。送信者は、送信者自身の秘密鍵を使用してメッセージ・ダイジェストを暗号化します。ダイジェストは、送信するメールに添付されます。ダイジェストはあまり大きなサイズではなく、通常は 128 ビットです。非対称鍵暗号方式の特性により、受信者は送信者の公開鍵を使用して (公開鍵は誰でも使用可能) メッセージ・ダイジェスト (たとえば、MD5（US)(※現在リンク切れ)を検証し、メッセージが本当に正しい送信者から送られたものであるかを検証できます。同時に、送信中にメッセージが変更されていないかも検証できます。
メッセージの暗号化送信者は、受信者の公開鍵 (公開済みデジタル証明書を介して利用可能) を使用してメッセージを暗号化します。受信者は、受信者自身の秘密鍵を使用してメッセージの暗号化を解除します。

これらの技術は、インターネットの世界では S/MIME (セキュア MIME) として知られています。

否認防止
これらのことがどのように Jed の役に立つのでしょうか。それを明らかにする前に、否認防止について考えましょう。これは、エンド・ユーザーを行為または取引に結び付けることです。否認防止は、特定の行為が発生し、どのエンティティー (ユーザーまたは会社) がそれを行ったのかをたどることができる証拠を提供します。先ほどの Jethro と Jed の例では、Ellie は機器の注文を処理する前に、メッセージの完全性を検証できたのです。メッセージの検証は、デジタル署名を使用して行うことができます。これをメッセージの完全性といいます。

S/MIME は、この問題の解決方法の 1 つです。Jed とJethro は、インターネット経由で重要なメッセージを送信する必要があります。インターネットは公衆の場所なので、Bob Hacker のような悪意を持ったユーザーが、いとも簡単にメッセージをインターセプトできてしまいます。先ほどの例では、Bob は SMTP メールで、別のアドレスを Jethro のアドレスとして「なりすましていた」のです。メールは次のようになっていました。

隠されたヘッダー情報 (開始)

Return-Path: <JethroB@jedco.xyz>
Received: from relay.hondo.texas.vendor.biz ([10.11.12.13])
by amailserver.somecompanysomwhere.biz
(InterMail vM.6.00.05.02 201-2115-109-103-1231231231) with ESMTP
for <Ellie-May@thevendorcompany.xyz>; Tue, 23 Mar 2004 04:05:11 -0500

Date: Tue, 23 Mar 2004 04:04:13 -0500 (EST)
Message-Id: <11234234-23864-64000886-1234234>
From: Jethro VP at Jeds Company <Jethro@jedco.xyz>
To: <Ellie-May@thevendorcompany.xyz>
Subject: Please order all of this stuff for me
MIME-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: 7bit

隠されたヘッダー情報 (終了)

Dear Cousin Ellie:
Jed wants me to rent some equipment. We are going to drill for oil
over in front of my home. Send me this stuff -
30 tanker trucks
14 drilling rigs
Thanks,
Jethro

Ellie はメッセージを受信し、本物と思って、Jethro の自宅に機器を搬送する手続きをとったのです。

メッセージが本当に Jethro から送信されたものかどうかを確認するオープン・スタンダードな方法について見ていきましょう。前に説明したように、S/MIME はセキュアな MIME メッセージを送受信する方法を提供します。MIME (Multipurpose Internet Mail Extensions)（US）は、電子メッセージをどのようにフォーマットするかを定義します。MIME 仕様は、さまざまな文字セットやマルチメディアを介してテキストを配布する方法を規定しています。

メッセージの機密性
セキュアなメッセージは、デジタル証明書のシステムを介して作成されます。証明書は、特定のユーザーまたはサーバーに割り当てられたデジタル ID の一部です。先ほどの例では、デジタル ID (非対称鍵のペア) は各ユーザーのメール・システムに置かれていました。デジタル ID の最初の部分 (公開鍵) はデジタル証明書という形で公開ディレクトリーに置かれていて、2 番目の部分 (秘密鍵) はメール・クライアントに組み込まれています。

図 1. S/MIME の構成

先ほどの例では、Jethro はメッセージを Ellie に送信します。Jethro は、デジタル証明書によって公開された Ellie の公開鍵をディレクトリーで見つけ、彼女にメッセージを送信します。Jethro のコンピューターのソフトウェアはメッセージを暗号化し、インターネット (SMTP) 経由で Ellie のコンピューター宛てに送信します。Ellie がメッセージを開封すると、公開鍵に対応する Ellie の秘密鍵を使用してメッセージの暗号化が自動的に解除されます。今度は、Ellie が逆のプロセスを実行します。Ellie が Jethro の公開鍵を持っている (または、Jethro の鍵が保管されているディレクトリーにアクセスできる) 場合は、Ellie はメッセージを暗号化して Jethro に送り返すことができます。このプロセスは、S/MIME プロトコルによって行われます。実際の暗号化プロセスはもっと複雑ですが、上に示した例によって、概念が簡潔に示され、高度なレベルでプロセスが説明されています。

これまで、基本的な S/MIME 暗号化プロセスを見てきました。これによって、Bob Hacker が送信中のメッセージを盗み見ることを防げます。しかし、Bob が Jethro になりすましてメッセージを送信するのを防ぐにはどうすればよいでしょうか。昔は、これを防止する方法はありませんでした。しかし、現在では、DNS での逆引きチェックなどのいくつかの新しい方法が考案されています。この記事では、暗号化とデジタル署名を中心に考慮します。

上に戻る

メッセージの完全性

暗号化されたメールを読むときと同じデジタル証明書を使用して、文書にデジタル署名を行うことができます。デジタル署名は、自筆の署名または指紋とコンピューター的に等価なものとして機能します。デジタル署名は、個人の証明をメッセージに添付する数学的な方法です。デジタル署名は、公開鍵暗号方式に基づいています。通常、メッセージング・プログラムが、ユーザーの秘密鍵を使用してオリジナルのメッセージに署名することはありません。その代わり、メッセージの圧縮版を生成します。この圧縮版が、以前に説明したメッセージ・ダイジェストです。

署名するメッセージは、秘密鍵を使用してメッセージ・ダイジェストに変換されます (実際に署名されるのはメッセージ自身です)。受信者がそれを受信すると、送信者の公開鍵を使用してメッセージ・ダイジェストの変換が解除されます。一般的に、誰もが送信者の既知の公開鍵を使用して、署名されたメッセージ・ダイジェストを読むことができます。

メッセージ・ダイジェストを生成するには、変換のメカニズムが必要です。メッセージ・ダイジェストを作成するアルゴリズムは数多く存在します。たとえば、MD2、MD4、および MD5 は RSA Security によって開発されたハッシュ関数です。これらは、いずれも 128 ビットのダイジェストを生成します。MD5 アルゴリズムは、ダイジェストを生成するハッシュのデファクト・スタンダードです。パブリック・ドメイン・バージョンは、インターネットのほとんどのサイトで利用でき、完全性をチェックするシステムで幅広く使用されています。さらに、SHA-1 (Secure Hashing Algorithm) は NIST が後援して開発されたハッシュ関数で、米国政府によって標準として採用されました。SHA-1 は 160 ビットのダイジェストを生成します。

文書が署名されていると、誰が文書に署名したのか (そして、送信したのか) を検証できます。これまでに述べたように、インターネットで送信されるメッセージでは、送信者フィールドを改ざんし、別の送信者に容易になりすますことができます。Jed がすべての注文に対して送信者のデジタル署名を要求すれば、メッセージが本当にベンダーから発信されたものであることを証明できます。(ここでは、注文が到着した後、Jed の処理部門がミスを犯さないことを前提としています。)これにより、特定の行為が発生したことを示す疑いのない証拠が得られます (先ほどの例では、処理された取引は既知の会社から発信されたものであるという証拠になります)。これは、X.509 V3 形式で発行されたデジタル証明書を介して行われます (もちろん、ベンダーが証明書を完全に制御し、不正なユーザーが介入する余地がないことが前提です)。このプロセスは、注文を送信する側と受信する側のどちらでも使用できます。

(MD2 と MD5 メッセージ・ダイジェストを覚えていますか。メッセージ内の 1 文字でも変更された場合は、メッセージ・ダイジェストの半分近くが変更されてしまいます。メッセージを変更しながらメッセージ・ダイジェストを同じに保つことは非常に困難です。高等数学に精通していない限り、不可能でしょう。)

デジタル署名を検証するプロセスを図 2 に示します。

図 2. デジタル署名の検証プロセス

図 2 に示したサンプルでは、Mike がメッセージにデジタル署名をして Bubba に送信します。Bubba のソフトウェアは、パブリック・ディレクトリーを介して、署名が Mike から送信されたものであるかどうかを自動的に検証します。

上に戻る

閉鎖型と開放型の証明書発行システム

証明書を発行するシステムには、閉鎖型 (プライベート階層) と開放型 (パブリック階層) の 2 つの基本的なシステムがあります。

閉鎖型のプライベート証明書発行システム
閉鎖型システムは、認証機関を 1 つのエンティティーの一部として持ちます。理論的には、複数の組織と組織単位を管理できます。また、これらの組織認証者をサポートおよび維持する責任を分担できます。閉鎖型システムでは、自分の会社が CA としての役割を果たします。これを行うにはいくつかの理由があります。その 1 例として、複数の銀行支店を持ち、各支店間でのデータのやり取りを暗号化したい場合が考えられます。この場合、あなたが CA となり、証明書を発行します。現実には、鍵のかかる安全な場所に認証者を配置する必要があり、強力な制御方法のもとで鍵の持ち出しを監視する (実際の人によって) こともあります。会社全体をカバーする 1 つの CA または複数の CA を使用できます。

閉鎖型システムの利点は次のとおりです。

あなたが CA であり、すべての証明書を制御します。
ユーザーへの証明書の割り当てを制御します。(たとえば、あまりスケーラブルな方法ではありませんが、ユーザーの一人一人を実際に見てから証明書を発行することもできます。)
証明書の構造、命名、検証、および期限を管理します。
あなたの判断によって、すべてが制御されます。少なくとも理論的には、誰も証明書を使用したり、証明書を偽装することはできません。(この点については、後で詳しく説明します。)

閉鎖型 CA システムの最大の欠点は、CA であるがゆえに、その責任を果たすためのサポート構造が必要になることです。これには、解決のための適切なソフトウェアおよびハードウェアのインストールと管理も含まれます。また、証明書を管理するサポート・スタッフも必要です。(証明書の期限切れや、ユーザー名の変更なども発生します。)さらに、退社した人をどのように扱うかを定めたポリシーも必要です (後で詳しく説明します)。

あなたが CA となる場合は、他の人が CA にならない限り、その CA を自分自身で制御します。残念ながら、証明書を作成するには、誰か (または何か) が CA にアクセスし、認証者として動作する必要があります。CA 認証者は、いずれかの場所 (文書、ファイル、ハードドライブ、フロッピーなどの中) に存在する物理的なエンティティーです。このため、不正なユーザーは、防護されていない CA のコピーを常に入手することが可能です。また、CA ファイルにパスワードが設定されていても、管理者が退職または転職すると、その情報が漏れてしまう可能性もあります。さらに、CA 証明書が悪意のユーザーの手に渡ると、組織の正当なメンバーになりすますための証明書を部外者が作成できることになります。自分自身が CA になるときは、CA 証明書を保護する方法をソフトウェア・ベンダーと相談してください。

開放型のパブリック証明書発行システム
個人または会社は、パブリック・システムにアクセスし、証明書を要求できます。一般的に、パブリック CA は独立したエンティティーで、証明書を発行するサービスを提供します。この CA は、第三者 CA と呼ばれることもあります。

開放型のパブリック・システムの利点は次のとおりです。

あなた自身は CA ではありませんが、自分自身の代わりに証明書を提供するためにパブリック CA を介してサービスをセットアップできます。証明書を制御できますが、ルート証明書は制御できません。
ユーザーへの証明書の割り当てを制御できます。多くのベンダーは、ユーザーを登録して証明書を発行するシステムを自動化しています。
証明書の構造、命名、検証、期限を制御できますが、前にも述べたように、ルート証明書は制御できません。
全体的にみて、開放型のパブリック・システムの方が閉鎖型システムよりもコストが低くなります。これは、システムをサポートするためのインフラストラクチャーと人員を配備する必要がないからです。
よく知られているほとんどのパブリック・システムは、検証済みの追跡レコードを持っています。(パブリックなインフラストラクチャーが故障したケースは聞いたことがありません。)

開放型のパブリック・システムを使用することの欠点の 1 つは、証明書のルートを所有できないことです。このため、サービスに従事する何者かが不正な証明書を作成する可能性があります。会社がパブリック CA を使用するときは、ベンダーのサービス・レベル、法的な義務と責任、倫理規定、および CPS (Certificate Practice Statement: 認証実施規定) を考慮する必要があります。いずれも事前に検討し、同意しなければなりません。また、これらのいずれかの点に違反があった場合の対処方法についても定義しておきます。最後に、サービス提供者契約を締結しなければなりません。この契約は、サービス提供者およびサービスを要求または購入する企業の権利と義務を規定します。

結論 : パブリック CA を使用する前に、社内の法務部門に相談してください。

証明書発行システムを選択する
では、閉鎖型のプライベート・システムと開放型のパブリック・システムのどちらがよいのでしょうか。解決したいビジネス上の課題を考慮せずに、技術を選択してはいけません。決定する前に、次の課題について検討することをお勧めします。

ビジネスでの要件は何か?何が求められているか、そして何がサポートされているのか?
ユーザーの要件は何か?
何が負担なのか?
サポートの要件は何か?
解決すべきユーザーの課題は何か (ユーザー数、場所、ユーザーの種類--オフィス/ローミング/リモート、バンド幅、言語) ?
トレーニングの要件は何か (ユーザー、管理者、ヘルプ・デスク) ?
ルート証明書 CA が侵害されたときに何が起こるのか?(この質問は、パブリックとプライベートの両方のシステムになされるべきです。)
他のアプリケーションやビジネスにその技術が使用されることがあるか?
どのサービス・レベルが必要か?

ユーザーに証明書を割り当てるのにどのようなプロセスが使用されるか?(これは、認証実施規定で詳細に定義される必要があります。)

上に戻る

Domino CA

Notes/Domino 6 は、インバウンドとアウトバウンドの SMTP メッセージングの両方に使用できる数多くの機能を提供します。Domino 6 には、PKI 管理プロセスがあります。このプロセスは、認証機関 (CA) プロセスと呼ばれています。CA プロセスは、Notes 6 Client や Web ユーザーへの証明書の発行を自動化するたいへん強力なツールです。CA プロセスは、自動化されたサーバー・タスクとして Domino 6 Server 上で実行されます。このタスクによって、Domino CA をセットアップできます。この認証機関は、証明書を作成、管理、更新したり、サービス拒否 (証明書失効リストまたは CRL と呼ばれます) を提供できます。1 つのサーバーでは CA プロセスの 1 つのインスタンスだけを実行できますが、各サーバーごとに複数の認証者をセットアップできます。

デジタル署名の検証
Notes/Domino でデジタル署名プロセスがどのように機能するかを説明します。先ほどの例に戻ると、Jethro はメッセージを Ellie に送信します。Ellie は、メッセージが変更されていないことと、間違いなく Jethro から送信されたものであることを検証したいと思っています。メッセージは次のとおりです。

Hello Ellie: How are you today?I would like to order 100 units of oil equipment.Please send it to the office on the 5th.Thanks, Jethro

メッセージ内の各文字を ASCII、16 進、およびバイナリー・コードで示すと下表のようになります。

図 3. ASCII 、16 進、およびバイナリー・コード

この時点で、Jethro はメッセージに署名します。MD5 ユーティリティーを使用することにより、次のメッセージ・ダイジェストが生成されます。

64b26c7702f7151a321c07bf767abcf3
ハッカーが「man in the middle」攻撃を使用したものとして、メッセージを変更してみましょう。

Hello Ellie: How are you today?I would like to order 1000 units of oil equipment.Please send it to the office on the 5th.Thanks, Jethro

変更点は 1 文字だけです。つまり、数字の 100 の後に余分な 0 が追加されています。この結果、Jethro の本当の希望よりも 10 倍多い注文になっています。この 1 文字のコードは次のようになります。

Letter ASCII Hex Binary 0 48 30 110000
1 文字の追加で、メッセージ・ダイジェストは、次のように完全に変更されています。

22e5f55fc05dbd816efbec72df8ff73f
Ellie が Jethro からのメッセージを受信すると、Ellie の Lotus Notes Client は Jethro のデジタル証明書を使用してメッセージの署名を検証します。このデジタル証明書には、ディレクトリーで公開されている Jethro の公開鍵が含まれています。Jethro の署名が正当な場合は、メッセージの正当性を検証するために、メッセージが再びハッシュ化され、比較されます。

CA をセットアップする
このプロセスを配備するために、まず、Ellie の立場として、Domino 6 CA プロセスを使用して Ellie 用の X.509 証明書を作成しましょう。この例では、署名と暗号化 (S/MIME) の両方に 1 つの証明書を使用します。数か月前に Jed が Notes/Domino 6 をアップグレードしたとき、彼はスタンドアロンの登録サーバーをセットアップしました。これは、CA サーバー・タスクを使用する特殊な Domino Server です。このタスクは、証明書要求 (Notes 証明書とインターネット証明書の両方) を管理および処理します。Jed は、Notes およびインターネット証明書を発行する統一されたメカニズムを会社に提供するために、CA プロセスをセットアップしました。また、[registration authority (RA)] ロールをセットアップしました。このロールは、組織内のより下位レベルの管理者 (たとえば Bubba など) に、証明書の承認/否認プロセスを委任する際に使用します。

この方法を使用すれば、認証者 ID と ID パスワードへの直接のアクセスを各管理者に与える必要がありません。CA プロセスの認証者を有効にした後、Jed は [registration RA] ロールを管理者の一人に割り当てました。RA を割り当てられた管理者は、認証者 ID とパスワードに直接アクセスしなくても、ユーザーを登録したり、証明書要求を管理できます。各認証者は、[発行済み証明書リスト (ICL)] データベースを持ちます。このデータベースは、認証者が CA プロセスに移行されるときに作成されます。ICL データベースには、このデータベースが発行し、期限切れになっていない各証明書のコピーが保存されています。

Jed が Notes/Domino 6 アーキテクチャー用に採用した基本的な構成を図 4 に示します。

図 4. Notes/Domino 6 セキュリティー・アーキテクチャーの例

このアーキテクチャーには、信頼されたネットワークを保護する DMZ レイヤーが含まれています。外部の世界から送信されてきたメッセージは、DMZ によって処理および検討され、いずれかの SMTP サーバーに配信されます。SMTP サーバーは、このメッセージをいずれかのメッセージング・サーバーに配信します。送出されるメッセージも同じように処理されます。エンド・ユーザー (Jethro) は自分自身のクライアントからメッセージを送信します。メッセージは、いずれかの SMTP サーバーに転送されます。そこから DMZ へとメッセージが転送されます。DMZ では、スマート・ホスト・デバイスが宛先の受信者に向けてメッセージを転送します。

Jed は、スタンドアロンの CA 登録サーバーをセットアップすることを決定しました。これにより、CA は他のすべてのサーバーから分離されることになります。次に、Jed は server.id ファイルにパスワードを設定しました。パスワードによって、サーバーのセキュリティーがさらに高められます。(もちろん、このサーバーは自動的に再起動できなくなります。このように、CA サーバーを分離する理由の 1 つは、CA サーバーがダウンした場合でも、SLA ベースの実動サーバーに影響を与えないためです。)さらに、このサーバーへのアクセスは、サーバー文書のアクセス制限を介して、CA と RA だけに制限されています。また、このサーバーの相互認証は発行されません。結果として、このサーバーは分離され、サーバーへのアクセスはごく少数のユーザーまたはサーバーだけに限定されます。(Jed はこのサーバー上で IDPR プロセスもセットアップしています。)

次に、Jed はスタンドアロンの X.509 CA サーバーをセットアップしました。CA の作成後、Jed はメインの管理者と共に作業し、X.509 CA を Domino CA プロセスに移行しました。これを行うために、2 つの CA ロールを作成しました。1 つは Jed 自身用のロールで、もう 1 つは、いとこの Billy Joe Bob 用のロールです。次に、Billy Joe Bob、Bubba、および自分自身用にそれぞれ 1 つの RA ロール、つまり全部で 3 つの RA ロールを設定しました。

上に戻る

証明書を使用する

証明書を導入するために、Jed は、Ellie に X.509 証明書を与えるよう Bubba に指示します。これを行うために、Bubba は Domino Administrator Client を開き、[ユーザーとグループ] タブを選択します。次に、Ellie の名前を選択し、[アクション] - [選択ユーザーへのインターネット認証の追加] を選択します。

図 5. インターネット認証の追加

次に、Bubba は正しい認証者を選択し、[OK] をクリックします。プロセスの実行後、証明書の割り当てに成功したことを示す次のメッセージが表示されます。

図6. [統計] メッセージ

基本的に、ここまでが一連の操作です。次回に、Ellie がサーバーにアクセスするとき、新しい X.509 証明書が Ellie の Notes ID ファイルに格納されます。必要であれば、Ellie は Notes Client で [ファイル] - [セキュリティ] - [ユーザーセキュリティ] ドロップダウンメニューを選択することで、ID ファイルの内容を見ることができます。

図 7. [ID のプロパティ] 画面

[拡張オプション] ボタンをクリックすると、証明書に関する追加情報が表示されます。Ellie は 1 つの証明書しか持たないので、[この証明書をデフォルト署名として使用する] はグレー表示となります。

図 8. [証明書拡張詳細] 画面

Jethro は管理者から Microsoft Outlook 用の証明書も入手しました。現在、Ellie と Jethro のどちらも、X.509 証明書を持っています。

パブリックキー (公開鍵)
規定により、パブリックキーは共有できます。大規模な企業では、パブリックキーの共有はディレクトリアシスタントと LDAP を介して行われています。この例では、ローカルの Microsoft Outlook アドレス帳と Lotus Notes 個人アドレス帳を使用する簡単な方法を紹介します。

最初のステップとして、Ellie と Jethro がお互いに署名付きのメッセージを送信できるようにします。まず、Jethro は Outlook で新規のメッセージを作成します。[メッセージオプション] ダイアログボックスを開き、[このメッセージにデジタル署名を追加する] を選択します。

図 9. Microsoft Outlook でメッセージに署名する

次に、Notes 6 Client で、Ellie は署名したメッセージを Jethro に送信します。

図 10. Notes 6 でメッセージに署名する

このテンプレートには、署名フラグをセットする 2 つのオプションがあります。操作が必要なのはこれだけです。後は、Notes Client が、受信者はインターネットベースのユーザーであると判断します。これによって、Notes.id ファイルの代わりに X.509 証明書を使用してメッセージが署名されます。

このプロセスでは、各ユーザーのパブリックキーにアクセスすることになります。これは、Lotus Notes を使用することで自動的に行われます。Notes Client はメッセージを受信し、相互認証を入手します (ユーザーに操作の確認を求めた後)。そして、送信者のパブリックキーをアドレス帳に追加します。パブリックキーが利用可能になると、暗号化した (S/MIME) メッセージをユーザー間で送信できます。

Notes 6 Client で Ellie が Jethro からのメッセージを初めて受信したとき、Ellie はインターネット相互認証を個人アドレス帳に作成するよう求められます。

図 11. [相互認証の発行] プロンプト

Ellie が [相互認証] ボタンをクリックすると、Notes 6 Client の個人アドレス帳に相互認証が作成されます。次に、 Ellie は [アクション] - [ツール] - [送信者をアドレス帳に追加] を選択し、Jethro の情報をアドレス帳に追加 (または更新) します。これによって、次のダイアログボックスが表示されます。

図 12. [送信者をアドレス帳に追加] ダイアログボックス

[OK] をクリックすると完了です。これで、Jethro のパブリックキーが保存されました。今度は、Jethro が Ellie のパブリックキーを入手します。これもたいへん簡単な手順です。Ellie は署名付きのメッセージを Jethro に送信していることを思い出してください。Jethro は、メッセージを開き、署名付きのメッセージを受信したことを確認します。Outlook では、次のような表示となります。

図 13. Outlook での署名付きのメッセージ

Jethro はメッセージ内の Ellie のメール・アドレスを右クリックし、[連絡先フォルダに追加] を選択します。これによって、Ellie の名前とパブリックキーが Jethro のアドレス帳に追加されます。これで、Jethro は暗号化した S/MIME メッセージを Ellie に送信できるようになりました。Ellie も同様に暗号化したメッセージを Jethro に送信できます。Jethro が Ellie に送信する注文メッセージを下図に示します。

図 14. 暗号化した注文を送信する

上に戻る

まとめ

これまでに説明したように、Notes/Domino 6 ではたいへん簡単なプロセスでセキュアなメールを送信できます。Jethro はメッセージを作成し、アドレス帳から Ellie を選択します。次に、[送信オプション] メニューで、[署名] と [暗号化] を選択し、メッセージを送信します。Ellie がメッセージを受信すると、メッセージの暗号化は自動的に解除されます。そして、Ellie は署名および暗号化した確認書を返信します。

これで、Jethro は機器の注文を署名および暗号化して Ellie に送信することが可能になりました。この方法を採用すると、Bob Hacker や彼の仲間たちは、Jethro になりすますことができません。また、注文の機密が保たれるので、Jethro が裏庭で発見した大きな油田のことが外部に漏れる心配もありません。これらのすべてのことが、Notes/Domino 6 と X.509 証明書を使用することで実現できます。

上に戻る

リソース

SMTP の詳細を理解したい場合は、SMTP (Simple Mail Transfer Protocol) Web ページ（US）にアクセスしてください
MIME (Multipurpose Internet Mail Extensions) Web ページ（US）には、MIME プロトコルに関する詳細な情報が掲載されています。

筆者について
Timothy Speed :
IBM Software Services for Lotus (ISSL) のインフラストラクチャーおよびセキュリティー設計者。1992 年より、インターネットとメッセージングのセキュリティーに取り組む。また、長野オリンピックの Domino インフラストラクチャーに参加し、シドニー・オリンピックでは Lotus Notes システムを支援した。MCSEc、VCA (VeriSign Certified Administrator)、Lotus Domino CLP Principal Administrator、および Lotus Domino CLP Principal Developer などの資格を持つ。また、『The Internet Security Guidebook』(ISBN: 0122374711、2001 年 2 月)、『The Personal Internet Security Guidebook』(ISBN: 0126565619、2001 年 10 月)、『Enterprise Directory and Security Implementation Guide: Designing and Implementing Directories in Your Organization』(ISBN:0121604527)、『Internet Security: A Jumpstart for Systems Administrators and IT Managers』(ISBN 1555582982)、という 4 冊の書籍の共著者でもある。

Raj Balasubramanian :
IBM Software Services for Lotus (ISSL) の Consulting IT 設計者。顧客と提携した配布アプリケーションおよびインフラストラクチャー関連のプロジェクトに携わる。顧客先への出張や数学関連の読書以外の時間は、息子たちとロボットや火星探査機ローバーの話をしている。

上に戻る