ソフトウェア > Lotus > Lotus Developer Domain >

Iris Today Archives

Web ベースのメールのセキュリティー：ケース・スタディー

by Frederic Dahm
レベル：すべて
対象：Domino 5.0
原文の掲載：2001年2月1日

Iris Today Archivesの原文（英語）

インデックス

	必要となるもの
	基本的なアーキテクチャー
	ステップ・バイ・ステップ・アプローチ
	危機モデルを理解する
	アーキテクチャー1用のセキュリティー・メカニズム
	アーキテクチャー2 用のセキュリティー・メカニズム
	アーキテクチャー3 のセキュリティー・メカニズム
	まとめ

Web の便利さとどこからでもアクセスできるという性格から、ノーツ/ドミノ・ユーザーの多くは、特に出張の際などの従業員のメール・アクセス方法として Web を使っています。Web メール、そして最近発表された iNotes Web Access は、ユーザーがアクセスできるインターフェースを提供し、ドミノが確実に、そして安全にデータをロードします。

とはいえ、ドミノ標準のセキュリティー機能でも、追加のセキュリティー上の手段を講じたほうがいい、あるいは講じなければならないというケースが多くあります。政府と契約を結ぶような会社や、金融会社など重要な情報を扱うような企業にとっては特にそうです。

このケース・スタディーでは、メールへの Web からのアクセスをセキュアーにしたり、顧客のネットワークのトラフィックをセキュアーにする基本点を見ていきます。この記事はもともと顧客の皆さんに、使えるサービスにはどのような選択肢があるのか、そしてその仕組みを理解してもらえるように書いたものです。アーキテクチャーに関する正式な文書としてではなく、顧客にはこのような選択肢があるということを紹介する記事として見てください。

この記事は、ノーツ、ドミノ・アーキテクチャーや、セキュリティー機能を理解していることを前提としています。

必要となるもの

従業員が出張していたり通常以外の場所で働く際には、セキュアーなメッセージング・アーキテクチャーが必要になります。そして eメール・サービスをつかさどるシステムにどこからでもアクセスでき、eメールをアクセスするクライアント (あるいはそのメカニズム) も同様でどこからでもアクセスできるものでなければなりません。

これらの基準を満たすのに最も簡単なのは、インターネットを通信手段として使い、Web ブラウザーをメッセージングのクライアント、Web アプリケーション・サーバーはメッセージング・サービスを提供するために使うことです。

Web ブラウザーは HTTP プロトコルを使って HTML を介してユーザーのメール・ファイルにアクセスします。Web アプリケーション・サーバーはメールを保管したり転送を行なったりするだけでなく (通常 SMTP を使って行なわれます)、HTTP プロトコルを使って HTML を介し、ユーザーのメール・ボックスにアクセスできるようにします。そして、ユーザーはメッセージの内容やインターフェースなどを利用することができるようになるというわけです。

Web ブラウザーは、空港のターミナルで利用できたり、航空会社のビジネス・クラスのラウンジで利用できることがありますし、インターネット・カフェでも使えます。さらに、会社が社員にモデムや必要なソフトウェアをインストールしたノート型PC を持たせるかもしれません。そして、ドミノ Web アプリケーションはこのようなサービスを Web アプリケーションで利用するのに適しています。

まず問題となるのが、どうすればできるだけセキュアーな方法でこれを実現できるのかということです。アクセスを与えるのはいいのですが、権限のあるユーザーだけアクセスできるようにするというのはまったく別物です。この記事では、これらのサービスのセキュリティーを強化したり、社外秘文書などについて会社で決めた方針にできるだけ従うにはどうすればよいかということについて、セキュリティー上の問題点について紹介していきます。

上に戻る

基本的なアーキテクチャー

ここで行ないたいサービスを実現するのに必要なセキュリティー関係の考慮点を挙げていく前に、まずどこからでもアクセスできるメールというソリューションはどのようなアーキテクチャーを持っているのかを詳しく理解することが重要です。そうすれば、必要なセキュリティー・サービスを加えていったり、注意点があればそれを理解するのに役立つはずです。ここでは説明し易くするために、会社にアリス、ボブ、キャロル、デニス、エヴァ、そしてフレッドという社員がいると仮定して話を進めていきましょう。

アーキテクチャー1
下の図は1つのワークステーションと1つのサーバー間の通信を示します。これは、ユーザー (ここではアリス) がインターネットを通じてメールにアクセスするときに最も見られる形です。

architecture 1

アーキテクチャー2
次の図は、同様に1つのワークステーションと1つのサーバー間の通信ですが、サーバーとユーザーを追加したものです。アリスはボブというノーツ・クライアントを使っている1人のユーザーと、インターネットを通じてメールにアクセスしたり交換しています。

architecture 2

アーキテクチャー3
次の図は、上と基本的には同じですが、さらにユーザーとサーバーが増えています。ここでは、Web ユーザー (アリスとフレッド) がノーツ・クライアントを使っている他のユーザー (ボブとキャロル) とインターネットを通じてメールにアクセスしたり交換しています。さらに、この2人は別ブランドのメッセージング・サーバー (SMTP のような一般的なメッセージング・プロトコルを使ってルーティングできればどのブランドでも構いません)、そして POP あるいは IMAP メッセージング・クライアントを使っているもう2人のユーザー (デニスとエヴァ) ともメールを交換しています。

architecture 3

上に戻る

ステップ・バイ・ステップ・アプローチ

アーキテクチャーがより複雑になっていくことを考えると、まずはステップごとに理解していって、危機モデル (誰が、なぜ、どのように攻撃してくるのか) を使って考え、どこからでもアクセスできるようにしながらも情報をできるだけ安全にするにはどのような手段を取ればいいかを割り出していくのがいいでしょう。

セキュリティー・アーキテクチャーを設計する上で、次のステップを踏むのがよいでしょう。

その情報がどのくらい機密性があるのか、そしてもし情報が漏れて悪用された際にどのような被害が出るのかということを考えます。
その情報がどのような危機にさらされているのかを考えます。これによって、ソリューションに関わるリスクや、そのリスクを最小限に抑えるには何をすればいいのかがわかります。最小限に抑える、といったのは、コンピューターのセキュリティーにおいては「絶対」はありえないからです。セキュリティー手段を講じたとしても、それを上回って防御を破るような方法が作られていくのです。ですから、防御方法を考えるのもいいですが、まずリスクを考えた上でそれでもそのソリューションを取り入れるのかどうかを決めるべきです。もしそのソリューションにともなうリスクが大きすぎるのであれば、そのソリューションを使わないか、リスクを希望に沿うまで小さくできるように別の手段を取ることになります。
システムを構築してモニタリングします。例えるなら、侵入者が入ってこないように柵を立てるのも重要ですが、その柵を守ることも重要なのです。そうすることでリスクを最小限にとどめ、もし防御よりも強力な攻撃があっても警戒していれば極力避けることが可能です。

さらにもう1つのステップとして、サード・パーティーの業者にテストを依頼して、見落としているセキュリティー上の穴がないかどうか、すべての設定パラメーターが正しく設定されているか、セキュリティー・メカニズムが正しく働いているかなどをチェックしてもよいでしょう。

このようなケースでは企業は重要な情報を扱っており、特別な注意を払うことが必要になってきます。次のステップでは前述の危機モデルを理解します。

上に戻る

危機モデルを理解する

アーキテクチャーの中でもっとも攻撃にさらされやすいのは企業のネットワークの外側、つまり情報が Web クライアントとサーバーの間で交換される部分です。しかし、企業ネットワークの内側にも注意を払うべきところがあります。この「危機」は企業内部の人間に関係がある場合もあるからです。

誰が、なぜ攻撃してくるのか
企業ネットワークの外側で交換される情報を扱う際には、Web クライアントと Web アプリケーション・サーバーの間で交換されるパケットを傍受することでインターネット上で攻撃されます。企業ネットワーク内でやりとりされる情報の場合は、社員や契約社員などが攻撃している可能性があります。

まず攻撃してくるユーザーをひとまとめに「ハッカー」と呼ぶことにします。そして、ここから分類していきます。すべてのハッカーが悪意を持ってやっているわけではなく、コンピューター・サイエンスをマスターしようとしている人や、変わった考え方を持った人なのかもしれません。ですから、ここで悪意あるハッカーを「クラッカー」として別に分類します。クラッカー達の目的は、良くて Web サイトへのいたずら、ひどいものになると情報や知識の横領、ばらまき、そして破壊におよびます。

近頃はさらに多くのカテゴリーにわたる、違う目的をもったハッカーが存在しており、さらに分類する必要が出てきています。最近のものとしては「スクリプトいじり」、「正義の味方を気取ったハッカー」、逆に「悪者を気取ったハッカー」、「ハクティビスト」、「企業スパイ」、「内部者ハッカー (社員など)」というカテゴリーがあります。ハッカーの分類でこれらのカテゴリーの詳細を参照してください。

どのように攻撃してくるのか？
セキュリティーにおける「危機」を、企業ネットワークの外側、内側という2つの視点から考えて見ましょう。

企業ネットワークの外側では、「盗み聞き」が主な攻撃手段となります。クライアントとサーバー間で交換されるパケットを傍受するといったものが基本的なものです。これは受動的攻撃と呼ばれ、情報は受動的に、つまりクライアントとサーバーの2つの間を行き来する情報を受け取るという方法で行われます。

この「盗み聞き」によって次の2つが傍受されてしまいます。

通信の情報内容
基本的な HTTP 認証しか使われていない場合の、ユーザーの ID やパスワード。これによって攻撃者がメッセージング・サーバーにログインしたり、ユーザー宛ての eメールを読めるようになってしまいます。

この他にも、ローカル DNS サーバーがハッキングされ、ユーザーが「にせ」のサーバーを気づかずに使って、そのサーバーに認証情報を流してしまうといった人が間に介在する攻撃方法もあります。

もう1つ、攻撃というわけではないのですが、Web ブラウザーのキャッシュには情報がためられますが、セッション中に交換された情報が Web ブラウザーのキャッシュに残ると、次にワークステーションを使う人がその情報を見ることができるということも考慮しておく必要があります。

誰かが攻撃をしかけて、サーバー上のデータにアクセスする恐れがあるので、サーバー自体もリスクを持っています。使っている OS 次第では、ファイル・システムや、その中のファイルにアクセスする方法はいくらでもあります (バッファー・オーバーフローや見つかってはいるもののまだ対抗策がとられていないセキュリティー上の穴などが原因となります) 。

ネットワーク内でも、ネットワーク外と同じようなリスクがあります。受動攻撃では通信内容が傍受されてしまいますし、内部者がサーバー上のメール・ファイルにアクセスしてメール・ファイルのコピーをとってメッセージング・クライアントを使ってローカルで見る、というような能動的な攻撃もありえます。

上に戻る

アーキテクチャー1用のセキュリティー・メカニズム

危機モデルを理解したところで、上で紹介したアーキテクチャー用のセキュリティー・メカニズムをどのように適用して、アクセスがどこから行われるか、あるいはどのクライアントから行われるかに関わらず重要な情報を保護するにはどうすればよいのかを見てみましょう。まず、最もシンプルなアーキテクチャーである、ユーザーがインターネットを使って eメールにアクセスする例を見てみます。

通信チャンネルを暗号化する
まずは通信チャンネルを暗号化して、傍受しようとする相手から情報を保護します。これを一貫して行うには、SSL (Secure Socket Layers) を使用します。ここで、サーバーの認証だけでなく、クライアント認証を使うのかどうかが問題になります。このうち1つだけなのか、それとも両方利用するかは、どのくらいのレベルのセキュリティーが必要なのか、またユーザーが手を加えられるメカニズムがどのようなものかによって決めます。

いずれにしても、SSL バージョン3を使うのがよいでしょう。ここに SSL の2つのバージョン間でどのような違いがあるのかを紹介します。

SSL バージョン2 はサーバー認証のみをサポートしています。つまり、サーバーの ID のみを認証するわけです。使用するブラウザーで信頼の置ける認証機関によって認められた X.509 認証を利用して認証を行います。インターネット上の商用サイトの多くは SSL バージョン2を使っています。
SSL バージョン3 はサーバー認証に加え、オプションとしてクライアント認証もサポートしています。両方を使用すれば、クライアントとサーバー両方の ID を確認することになります。サーバーには X.509 認証が必要となり、これが SSL セキュリティーを確保します。また、クライアント認証も利用すれば、個人のクライアントの身元を確認することができます。SSL バージョン3は暗号機能をサポートしており、クライアントの認証機関が有効になっていなくても使用することが可能です。

認証についていえば、X.509 サーバー認証は、各サーバーを非常にセキュアーな方法で見分けることができるので、SSL プロトコルを利用する際には必ず必要となります。X.509 クライアント認証はオプションなので使っても使わなくても構いませんが、クライアントを個別に認識できる、より強力なセキュリティー・モデルを実現できます。

ここで取り上げる顧客のケースでは、X.509 クライアント認証を取り入れるのはやや大変で、次のようなステップを踏む必要がありました。

クライアントは認証要求を発行する必要があります。これには、サーバーの Web サイトにいって、クライアント認証を要求するオプションを選択し、識別名コンポーネント、追加ユーザー情報を入力、そして暗号化の強度 (1024....512) を選択して、送信します。
認証を作成するためのメカニズムが必要ですが、これはクライアントがプライベート・キーのダイアログ・ボックスの OK ボタンをクリックして、次に出てくるダイアログ・ボックスで認証パスワードを入力することで行います。
次に、認証機関が認証に署名する必要があります。これには、管理者が認証機関データベースに行き、クライアント認証要求、そして署名されたクライアント認証要求を開き、署名するのであれば承認する、しないのならば拒否する、を押します。そして承認機関キー・リングのパスワードを入力します。
最後に、クライアントは認証を受け取ります。これには、クライアントはサーバーの Web サイトに行き、クライアント要求を受け取るオプションを選択、そしてクライアント認証を見分ける番号を入力し、署名済みクライアント証明の受け取りボタンを押したあと、受け取りを承認する、をクリックします。

これはやや面倒なプロセスですが、効率よく行う必要があります (クライアントが認証を受け取る場面でも)。さらに、認証はブラウザー特有の認証保管場所 (Internet Explorer と Netscape では異なっています) に置かれるので、自分のあとにワークステーションを使う人には見ることができ、ユーザーを信頼するかどうかは実はどのブラウザーを使うかということにかかってきます。ブラウザーを持ったワークステーションのあちこちに X.509 クライアント認証があったとしたら、ワークステーションを必要以上にまかせきりの形になり、ユーザーが信頼できるかどうかを確認するために何もしていないことになります。認証はパスワードで保護できるので、ぜひ保護するべきです。

上述の理由から、X.509 サーバー認証は取り入れたほうが賢明です。ただ、X.509 サーバー認証の認証チェックはただ傍受者がユーザー ID とパスワードを傍受できなくするという点に限られそれ以外のことはしない、いう欠点があります(ですから、HTTP 認証は性質的にセキュアーではないのです)。

通信チャンネルを暗号化するほかにも、このように X.509 サーバー認証を使って傍受を遮断することで信頼性をさらに向上させることができます。これで、ブラウザーは今見ているサーバーが、実際に接続したサーバーと同じものなのかどうかを確認することになり、人が介在する攻撃は防ぐことができます。

SSL が使われているときには、使っているサービスに応じて TCP/IP ポートが変わるということを覚えておいてください。次の表はデータが暗号化されていないときのポートと、SSL を使って暗号化されているときのポートを表しています。

サービス	ポート	SSL ポート
HTTP	80	443
POP	110	995
IMAP	143	993
SMTP	25	465
LDAP	389	636
NNTP	119	563
IIOP	53148	53149

これは、ファイアー・ウォールを使った接続を行っているときには特に重要です。ファイアー・ウォールの設定が、HTTP 要求はポート 80 になっていて、SSL が使われているなら、ポート 443 を開放してサーバーに転送された要求が通るようにする必要があります。

ブラウザーのキャッシュを削除する
セキュリティー・メカニズムというわけではないのですが、ブラウザーのキャッシュの削除についても話しておく必要があるでしょう。ユーザーに使い方などを教える際には、必ずブラウザーのキャッシュをいつも削除するように強調してください。共有しているワークステーションでは、次に誰が使うかは分からないのです。

サーバーを強化する
ここで最も大事なのは、攻撃からサーバーを保護できるように強化することです。1つ1つの可能性を考えることは不可能ですが、少なくともすべてのベンダーのパッチや、修正策をサーバーに適用するべきです。これは、メッセージング (Web アプリケーション) サーバー・パッチだけでなく、オペレーティング・システムやドライバー・パッチについても同様です。

システムがハッキングされてしまうのは、多くの場合システム管理者が、よくある問題点に対して必要なパッチを使わなかったことに原因があります。ですから、ベンダーが提供しているパッチを使うことによって、ハッカー (スクリプトをいじるハッカー) によるネットワークの外からの攻撃を防ぐことができるはずです。

メッセージを暗号化して保管する
ネットワークの外側で一貫したセキュリティーを実施するには、通信チャンネルだけでなく、サーバーやサーバー上のデータにも注意を払わなければなりません。これは、今まで通信チャンネルを保護することばかりに気をとられてしまったために被害を受けてしまった eコマースサイトの例を見ればわかります。攻撃者はこれらのサイトが通信チャンネルの保護に力を入れていることに気づき、通信チャンネルを攻撃するよりも、他の方法で攻撃できないか考えるようになりました。サイトの経営に関わる情報 (人の名前、住所、購入した商品名、さらにクレジット・カード番号、そしてその有効期限など) を保管しているデータベースの保護があまいことに気づき、そちらを攻撃するようになったのです。その結果、1人のユーザーのセッションを傍受してそのユーザーのクレジット・カード番号を得るよりもずっと効率よく、何百人という単位のユーザー情報を、より簡単に手に入れることができてしまいます。

ドミノサーバーに保管されているメッセージを暗号化するのは簡単です。まずデータベースのプロパティー・ボックスの [ローカルのデータベースを暗号化する] オプションを使い、サーバー ID を使ってサーバー上のデータベースを暗号化します。すると、そのサーバーのドミノ管理者は、暗号化したときに使ったサーバー ID を使ってのみ、データベースにアクセスできるようになります。これによって、なんらかの方法でサーバーが OS レベルでハッキングされて (このようなことはサーバーの保護を強化すれば起こらないはずですが) ファイル・システムにアクセスされ、データベースをコピーできたとしても、暗号化されているためにその内容を読むことはできないわけです。

では、攻撃者がサーバー ID も手に入れたとしたらどうなるでしょうか？もし管理者がサーバー ID にパス・フレーズ (パスワードではなく、記号や番号が混じった、例えば「t34m_m33ting@120'cl0ck%r00m-222D」のようなもので、ひたすら色々な文字の組み合わせと試してくるような攻撃を防ぎます) を付加していれば、サーバー ID を使うことはできません。ユーザーは、暗号化されたデータベースを解読するためのキーとなる内容を解読するには、パス・フレーズを持っている必要があるからです。

ここで、ドミノ ID にパス・フレーズを付けると、ドミノサーバーは自動で再起動することができなくなってしまうということに注意します。管理者は、コンソールで ID のパスワードを入力する必要があり、7ｘ24 の使用にも影響してきます。ですので、パス・フレーズの使用にあたってはよく考えるべきです。これには、SNMP (Simple Network Management Protocol) を使ってサーバーの再起動イベントを避け、コンソールで管理者へパスワード入力要求のメッセージを表示させるのも手でしょう。

どのように働くのか
アリスという社員が、出張の際に、空港ラウンジのビジネス・センターに行ったとしましょう。正しいセキュリティー設定がしてあれば、次のようにしてアリスはシステムにアクセスすることができます。

ワークステーションにログオンして、ドミノ Web アプリケーション・サーバーに接続します。
サーバーが要求を認識して、SSL ハンド・シェイク、つまり SSL セッションとセッション・キー間でネゴシエートします。
サーバー認証を使っているので、サーバーはアリスが身分を証明するように求めてきます (認証用に特別のログオン・フォームを作成するセッション・ベースの認証です)。
暗号化されたリンクを使って、サーバーとデータのやりとりが行なわれます。
セッションが終了したら、アリスはログオフし、セッションは閉じられます。そして、セッション・キーは破棄されます。
最後に、アリスはブラウザーのキャッシュを削除します。

上に戻る

アーキテクチャー2 用のセキュリティー・メカニズム

次のステップとして、ボブがメッセージを受信して必要ならばアリスへ返信するという、eメールがネットワークの外側から内側に入ってくる際のセキュリティーを見ます。

通信チャンネルを暗号化する
このケースでは、ボブのマシンとドミノ・メッセージング・サーバー間のリンクも暗号化するのがよいでしょう。ボブはノーツ・リモート・プロシージャー・コール (TCP/IP よりも NRPC が多いです) を使っているので、暗号化したいポートを選択します。これは、ユーザー・プリファレンス・ダイアログ・ボックスのポート部分で行います。

encrypting the port

ここで覚えておきたい点が3つあります。まず、ポートの暗号化のようなネットワークの暗号化は、そのプロトコルのネットワーク層で処理されるので、他の暗号化とは独立したものです。ネットワークのデータは、データが移動している間は有効ですが、データが相手に受け取られて保存されてしまうと、ネットワークの暗号化はもはや有効ではありません。

次に、SSL の他のサービスと違って、ポートは同じまま (登録されている通り 1352) です。つまり、暗号化した NRPC 専用のポートはありません。

3つ目に、これはユーザーが定義する設定 (この場合、ユーザーが自らポートの暗号化を無効にして、クライアントにセキュリティー・ホールを作ってしまうかもしれません) のように思われるかもしれませんが、ネットワークのデータ暗号化は、ネットワーク・コネクションのどちらか一方で有効にすれば発生するものです。ですから、サーバーで TCP/IP ポートを暗号化したなら、そのサーバーに接続しているワークステーションの TCP/IP ポートの暗号化を有効にする必要はありません。これにより、ユーザーが自分で暗号化の設定をしなくてすみます。

サーバーを強化する
ここでもやはりサーバーを攻撃に対して強化することがポイントになります。前述のように、ネットワーク内部からの攻撃の可能性もあります。少なくともすべてのベンダーのパッチや、修正策をサーバーに適用するべきです。これは、メッセージング (Web アプリケーション) サーバー・パッチだけでなく、オペレーティング・システムやドライバー・パッチについても同様です。

メッセージを暗号化して保管する
アーキテクチャー1での例と同様に、内部のドミノ・メッセージング・サーバーや、そのデータにも注意を払うべきです。情報の重要度によっては、メッセージング・サーバー上のデータを暗号化します。外部サーバーについては、単にデータベース・プロパティー・ボックスの [ローカルのデータベースを暗号化する] で、サーバー ID を使ってサーバーのデータベースを暗号化するようにします。

どのように働くのか
アリスが eメールをボブに送って、このメールがボブのメール・データベースがあるドミノ・メッセージング・サーバーに送られたとしましょう。ボブは次の方法に従ってこの eメールにアクセスすることができます。

ノーツ・クライアントをロードして、メール・データベースへのアクセスを試みます。
これには、ボブが認証してサーバーにアクセスすることが必要です。ノーツ・クライアントはパスワード入力ダイアログ・ボックスを表示します。
ボブはパスワードを入力し、このパスワードがパブリック、プライベート・キーのペアを解読します。
このパブリック、プライベート・キーを使うことで、ボブの認証が済みます。
暗号化されたリンクを使って、サーバーとデータのやり取りが行なわれます。
セッションが終了すると、ボブはログオフしてセッションが閉じられます。

上に戻る

アーキテクチャー3 のセキュリティー・メカニズム

顧客の内部ネットワークには2種類以上のメッセージング・サーバーが稼動している場合がほとんどなので、最後のステップとして、ユーザーがドミノ・メッセージング・サーバーを使って、他のメッセージング・サーバーを使うユーザーに eメールを送った場合のセキュリティーについて見てみましょう。

この説明をするにあたって、同じことの繰り返しにならないように、キャロルとデニスの間での暗号化されたメールのやりとりについてのみ話します。そして、上で説明したセキュリティー・メカニズムについてはすでに取り入れられて、他のメッセージング・サーバーを使っている側もデータを保護するために適切なセキュリティー・メカニズムをすでに取り入れたものとして説明していきます。

暗号化されたメールを送る
Web ブラウザーでの HTTP プロトコルにおける X.509 認証、そして Web ブラウザーと Web アプリケーション・サーバー間の通信チャンネルの暗号化については前述したとおりです。これと同じ手法を使い、X.509 認証を利用して、セキュアーな eメール通信を実現します。

メールでよく使われるインターネット・プロトコル
まず、インターネット・メールでよく使われるインターネット・プロトコルには、SMTP、MIME、POP3、そして IMAP4 があります。

SMTP (Simple Mail Transport Protocol) は、eメール・メッセージをホスト間でやり取りするプロトコルですが、DNS (Domain Names Service) や MX (Mail eXchange) レコードを使えば、ドメイン間のユーザーで eメールをやりとりする、とも考えられます。インターネット上でメールを送るシステムのほとんどはこの SMTP を使ってサーバー間でのメールのやりとりを行っています。さらに、SMTP はメール・クライアントからメール・サーバーへメッセージを送る際にもよく使われます。ホストが SMTP をサポートしていれば、他の SMTP ホストへメッセージを転送できる SMTP リレーとしても機能できます。

MIME (Multi-purpose Internet Mail Extensions) は、ASCII 形式でないメッセージをインターネット上でやりとりできるようにする書式の仕様です。もともとの SMTP の仕様では、eメールはテキストのみで成り立つと仮定しており、ASCII テキスト形式と特定していました。MIME はバイナリー・データをテキストの形でパッケージにしてもともとの仕様に従った eメール・メッセージにすることで、インターネット上でバイナリー・データをやりとりすることも可能にしました。大抵の場合、MIME をサポートする eメール・メッセージは、Subject フィールドの後にいくつかのヘッダー・メッセージが追加されています。最近のメール・クライアントのほとんどは MIME をサポートしており、画像や音声、動画といったバイナリー・データを、インターネット・メール・システムを使って送受信できます。加えて MIME では ASCII 以外の文字セットを使ったメッセージもサポートしています。

POP (Post Office Protocol, Version 3 または POP3) や IMAP (Internet Message Access Protocol, Version 4 または IMAP4) はインターネットのメール・ボックスやポスト・オフィスにアクセスするためのプロトコルを指定するプロトコルです。

POP3 は、ネットワークを超えて eメールを受け取る際に使用します。eメールを使うすべてのパソコンが毎日 24 時間常にインターネットに接続されているというわけではありません。必要なときのみプロバイダーに接続するユーザーもいるでしょうし、常時接続していても、常に電源が入っているとは限らない LAN につないでいるユーザーもいるでしょう。このような場合には、ユーザーに宛てられたメールは中心となる eメール・ポスト・オフィスに送られ、ユーザーが受け取るまで保管されます。POP3 を使うことで、ユーザーがネットワークを超えてポスト・オフィスにログオンして、ID とパスワードで認証を行い、メールをダウンロードすることが可能になるほか、任意でサーバーからメールを消す事ができます。

IMAP (Internet Message Access Protocol) はメール・クライアントをメール・サーバーのメール・ボックスから受信したり、手を加えたりするための新しいプロトコルです。最新のバージョンである IMAP4 は、POP3 に似ていますが、より多く、そして複雑な機能を持っています。例えば、IMAP を使えばサーバー上のメールの順序を変更したり、サーバー内のフォルダーでメールを管理することができます。

これらのプロトコルにどのような問題点があるか
これらのプロトコルはシンプルですが、その分アーキテクチャー3のような、異なったタイプのメッセージング・サーバー同士でメールの送受信を行う際にはセキュリティーの点でやや弱くなってしまいます。

SMTP は、他の SMTP ホストとの通信を確立する際に認証を行わずにメールのリレーや受信を行います。送信側のホストは「自分は何という名前のホストで、通信をしたい」という主旨のコマンドを受信側の SMTP ホストに送ります。そして、送信側のホストは「このメールの送信者は～という人です」というコマンドを送り、受信側 SMTP ホストはこれを受け取ります。同様に送信側は「そのメールは～宛てです」というコマンドを送り、受信側 SMTP ホストはまたこれを受け取ります。さらに送信側はメールの内容テキスト、そして最後にメッセージの終わりを示す文字列を送ります。

そして、送られる内容はテキストなので、ネットワーク探知器を持っていればネットワーク上のトラフィックを傍受できることがわかります。さらに、SMTP サーバーにあるメッセージにいたずらすることも可能です。SMTP ホストと通信を確立して、そのメールは他の人が送ったように見せかければいいのです。

POP3 や IMAP4 についてはどうでしょうか。元々の POP3 の仕様には SMTP 同様、認証手段がなく、POP3 クライアントと POP3 サーバーの間で行われる通信はテキストとして送られます。USER や PASS は、POP3 サーバーに接続してメールを受信するために必要なユーザー名と認証用のパスワードを送るためのコマンドで、明らかにそのままの意味を表しています。

SSL は、POP3 や IMAP4 を使って通信する際にセッションを暗号化するために使われます (HTTP などと一緒に使われます)。これにより、POP3 や IMAP4 を使った際に発生する認証上の弱点を克服できます。

メッセージの暗号化では、SMTP エクステンションをサポートした SMTP を使うことで、クライアントとサーバー間での通信が正しく認証されたことを確認できます。しかし、受け取り人にたどり着くまですべて同じ認証が一貫して行なわれることは保証できませんし、メッセージ自体が暗号化されたわけでもありません。この問題は、SMTP 通信 (クライアント、サーバー間、またはサーバー同士の通信) を、パブリック、プライベート・キーの組み合わせを使うことによって暗号化する、もう1つの SMTP エクステンションを取りいれることで解消できます。とはいえ、ここでもまた SMTP がメッセージを送る際に、受取人に到達するまでずっと暗号化されているということは保証できません。そして、仮に、メールが信頼の置ける SMTP サーバーで正しく認証され、クライアントにたどり着くまで暗号化されたとしても、メッセージが誰かにいたずらされてしまう可能性は常にあります。

ですから、メールの内容の保持や認証、あるいは機密性を守りたければ、メッセージの MIME の部分が正しく暗号化されていることを確認する必要があります。この解決策として、最近まで、PGP、S/MIME という2つの規格がありました。S/MIME について説明するまえに、まず PGP を簡単に紹介しましょう。

PGP (Pretty Good Privacy) は、セキュアーなメールを世界中に送れるように開発された、パブリック・キーを使った暗号法です。Mike Zimmerman が開発したこの PGP は、インターネットで自由に入手できます。PGP はキーを管理する能力は持たず、認証構造も非常にルーズです。認証機関を設けて個人に認証を発行する代わりに、自分の知り合いに署名してもらうことで認証が有効になるという「Web 上での信頼関係」に基づいて機能します。新しい規格の OpenPGP では、階層的アプローチも使えるようになっており、CA (Certificate Authorities：認証機関)、X.509 認証、そして他の一般的な規格もサポートしています。ただ、Diffie-Hellman というアルゴリズムを使っているため、この OpenPGP がどのくらい受け入れられるのかは疑問です。現在の PGP は RSA アルゴリズムを取り入れており、PGP を使っている 2000 万人のユーザーにとってはまったく別物となってしまいます。

S/MIME (Secure Multi-purpose Internet Mail Extension) は、メールを暗号化したり電子的に送信するために、RSA が開発したメール用のセキュリティー・テクノロジーです。ノーツやドミノ R5 は S/MIME をサポートしています。これは IETF (Internet Engineering Task Force) が提案した規格で、業界標準となった MIME プロトコルや、PKCS (Public-Key Cryptographic Standards) の上に、さらにセキュリティーを強化するものです。まず、メッセージの全体、あるいは MIME の部分を暗号化アルゴリズムにかけ、そのアルゴリズムが受け取り側のパブリック・キーを使って暗号化が行われます。

1999 年の6月に IETF の広報や権威が S/MIME v3 を標準として使っていこうという取り決めをしたのにも関わらず、S/MIME v2 が、セキュアーなメールをインターネット上で送る際のデファクト・スタンダードとなっています。S/MIME v2 はほとんどのベンダーに使われていますが、IETF 規格ではありませんし、これから規格としてみとめられることもないでしょう。S/MIME v2 は、アメリカで使われている RSA キー交換を採用しているほか、暗号法 (RC2/40) もやや弱くなっています。S/MIME v3 では、より強力な暗号法や暗号化アルゴリズムを取り入れることで、これらの問題点を解消しています。（ノーツ R5 は S/MIME v2 を使っています。） S/MIME では、キー交換や電子署名の際にパブリック・キー・アルゴリズムを使用しているほか、DES、Triple-DES、そして RC2 という3つの対称暗号化アルゴリズムを推奨しています。RC2 の、キーのサイズを変更できるという機能は、アメリカの外で使うアプリケーション、つまり RSA 以外のパブリック・キー・アルゴリズムも使えるアプリケーションには非常に便利です。

S/MIME を実際に使ってみる
実際にどのように S/MIME が働くのかを詳しく見て、先ほど紹介したキャロルがデニスにセキュアーな方法でメッセージを送る際にはどうすればいいのかを考えて見ましょう。

S/MIME には、次のような基本的な機能があります。

メッセージのプライバシーを保護するための暗号化
改ざんの検出
署名、デジタル認証を使った送信者の認証
他の S/MIME 対応ソフトウェアとの互換性
クロス・プラットフォームでのメッセージング

これらの機能によって、次のようなことが保証されます。

キャロルがメッセージを送信した瞬間からデニスに到着するまで、誰もメッセージの中身を見ることはできません。
デニスには、そのメールが、送信者の所に書いてあるキャロルから来たもので、その他の人が偽名を使って送ってきたものではない、ということが保証されます。
メールが配信された間に誰も内容を改ざん、変更していないということが保証されます。

メッセージのプライバシー、または機密性に関しては、S/MIME もノーツが今までずっとそうだったように、非対称キー (パブリック、プライベート・キー) を使っています。暗号化されたメッセージを送信するために、キャロルはデニスのパブリック・キーが必要で、このキーを使って暗号化を行ないます。そのキーに対応したプライベート・キーを持っているのはデニスしかいないので、デニスのみがそのメッセージを解読できる、ということが保証されるわけです。

メモ：

キャロルのディレクトリーの中に、送りたい相手のパブリック・キーを持っているとは限らないという点を考慮して、企業ネットワーク内のユーザーにセキュアーなメールを送るという傾向が見られます。使っているのが X.500、LDAP に限らず、企業内にはすべての社員の X.509 が保存されているディレクトリー・サービスがあるからです。企業ネットワーク外のユーザーにもセキュアーなメールを送れるようにするには、ディレクトリーの中身を交換し、その際にどの属性の中身を交換するかなど、双方で合意した上で行なう必要があり、簡単にできることではありません。

S/MIME では電子封筒とよばれる技術が採用されており、メッセージが、それよりも短い対称暗号文を使って暗号化されています。そしてその対称暗号文は、それ自体よりも長い非対称キーを使って暗号化され、暗号化されたメッセージとともに送られます。メッセージを長い非対称キーを使って暗号化するよりも、短い対称キーを使って暗号化したほうがはるかに速いためにこの手法がとられています。このアプローチも安全性には問題がなく、対称暗号化の速さと、非対称暗号化の安全性を兼ね備えていると言えます。

また、S/MIME ではメッセージが改ざんされたり変更されていない、ということが保証されます。これについても、ノーツですでに使われている手法を取っています。

S/MIME は、メッセージ署名にデジタル署名を採用しています。Message Digest という、各メッセージ用に自動計算された固有な値があり、メッセージが1文字でも変更されるとこの値は全く変わってしまうようになっています。この Message Digest はキャロルのプライベート・キーを使って暗号化され、キャロルのパブリック・キーが本物であることを示す認証とともに送られます。これをデニスが受け取ると、キャロルのパブリック・キー (パブリック・キーは誰にでも手に入れることができます) を使って Message Digest を解読します (先ほどのメッセージの暗号化と混同しないでください。メッセージの暗号化は、デニスのパブリック・キーを使って行なわれました)。ほとんどの場合、キャロルはメッセージに署名するだけで充分ですが、場合によってはメッセージを暗号化したうえで署名したいこともあるかもしれません。そのような場合には、メッセージはデニスのパブリック・キーを使って暗号化された後、キャロルのプライベート・キーを使って Message Digest が暗号化されます。S/MIME の仕様ではこの両方の暗号化を行なう際に、どちらを先に行なうかについては指定されていません。

では、キャロルの送ったメッセージが、自分の名前をかたる他人ではなく、自分が送ったものだと知らせるためにはどうすればいいでしょうか。

前述したように、メッセージはキャロルのプライベート・キーを使って暗号化しますが、署名をしたメッセージのほかに X.509 認証も送るので、認証はキャロルのパブリック・キーに署名をしたものと変わりません。これは、さらに信頼の置ける認証機関 (Certificate Authority) によっても署名されます。では、送信者のパブリック・キーに署名をした認証機関が信頼のおけるものなのかどうかはどのように分かるのでしょうか？S/MIME は「信頼の輪」 (Chain of trust) という方法を取っており、キャロルが暗号化したメッセージと (サード・パーティーの認証機関に署名されたパブリック・キーを持つ) 自分の証明書を送ると、サード・パーティーの認証機関の証明書も同時に送られます。このサード・パーティーの認証機関の証明書は、他の認証機関によって署名されたか、あるいは一番初めの証明書のどちらかです。ですから、このように階層構造になっている認証機関の証明書のうち、1つでもデニスにとって信頼の置けるものであれば、送信者のパブリック・キーに署名した認証機関も信用が置ける、と言えるわけです。

それでは、そもそもどうやって認証機関が信頼が置けるかどうかを判断すればいいのでしょうか？使っている S/MIME クライアントは、信頼の置ける認証機関と、そのパブリック・キーの一覧を持っています。これは認証機関の発行をよりスムーズにするために、クライアントがあらかじめ持っているものです。ここまでで、メッセージとキャロルの証明書に署名をして、デニスは自分の S/MIME クライアントにキャロルの証明書に署名した認証機関のパブリック・キーがあったためその認証機関が信頼の置けるものだと分かった、というところまできました。

ここまでで、送信された証明書はキャロルの S/MIME クライアントにある認証機関のパブリック・キーを使って解読することができたため、送信者がキャロルであるということを確証することができます。これが正しいと分かれば、送られてきた証明書とその内容、キャロルの名前、パブリック・キー、属する組織、国、そしてメール・アドレスなどは本物であるということも分かります。そして、キャロルのパブリック・キーは本物だと分かったので、これでメッセージを解読して、本当にそのメッセージが本人によって署名されたのかどうかを調べることができます。さらに、キャロルの証明書にはもう1つ重要な情報、eメール・アドレスがあります。これは、eメールがいたずらされたものでないことを確かめるために、キャロルのパブリック・キーで正しくメッセージが解読できた場合でも重要です。もし、証明書が本人のメール・アドレスを持っていなければ、そのメッセージは他のユーザーから送られたことになります。このような場合は、メッセージ自体や、送信者の信頼性が下がってしまいます。

これは、ユーザーが複数のメール・アドレスを取得するようなると問題を引き起こしてしまいます。仕事用と個人用のアドレス、オフィスが複数ある場合など、仕事用にもう1つアドレスを取得することもあるでしょう。これに対応するには、パブリック、プライベート・キーと証明書を3セット用意する必要があるのでしょうか？

この問題は、S/MIME 認証を別のクライアントにエクスポートするのは難しいということを考えると、なおさら複雑です。S/MIME v3 は、複数のメール・アドレスを同一の名前でもつという場合にも対応できるようになると期待されています。他のベンダー製のクライアント同士での互換性については、ユーザーが高いレベルでの互換性が必要ということを強くベンダーにアピールするようになれば改善されていくでしょう。

キャロルが、S/MIME クライアントを持たないユーザーに署名付きのメッセージを送ろうとした場合、送信側 S/MIME クライアントの性能によって、2つの可能性が考えられます。

メッセージが不可解な内容だったとしたら、署名が application/pkcs7-signature MIME 形式として送られています。S/MIME に対応していないクライアントは pkcs7-signature 形式を解読することはできません。S/MIME クライアントはまずメッセージを分割して、それから署名を確認します。
メッセージが空だとしたら、署名は multipart/signed MIME オブジェクト形式の中に挿入されたことを意味します。メッセージから切り離す形で署名が作られ、applicatioin/pkcs7-signature は MIME 形式の2番目に挿入されます。ですから、デニスのような受信側のクライアントはこのどちらの MIME 形式 (署名なしメッセージと、application/pkcs7-signature MIME 形式のアタッチメント) も受け取ることができます。

PKCS#12 によって、他の S/MIME 対応ソフトウェアとの互換性を保つことができます。PKCS#12 規格は、証明書のエクスポートとインポートの仕様を定めています。これはプライベート・キーのバックアップ用コピーを作る上で特に重要です。また、もし S/MIME eメールを他のマシンから、あるいは別の S/MIME クライアントから送る必要があれば、ただパブリック・キー、プライベート・キーのペアをもっていて、そのクライアントにインストールするだけで済みます。PKCS#12 規格の目的は、プライベート、パブリック・キーや認証に、他の S/MIME クライアントとの互換性を持たせることにあります。これは、ベリサイン社のような Web 認証機関に、Internet Explorer で証明書を要求した場合には Outlook Express から、Netscape Navigator から要求した場合には Netscape Messenger からしか証明書を受け取れないということを考えると非常に重要です。

S/MIME を使って署名したメールを送るためには、使っているクライアントに X.509 認証が必要になります。Netscape Messnger、ロータスノーツ、Microsoft Outlook Express といった最近の S/MIME 対応クライアントでは、Web ベースの認証機関から証明書を要求するための機能が充実しています。クライアントの証明書が要求されると、S/MIME クライアントにインストールされ、eメール・メッセージに署名できるようになります。また、そのアドレスに暗号化したメールを送信したいユーザー全員がその証明書を手に入れられるようにするのも大切です。例をあげると、キャロル宛ての暗号化されたメール・メッセージは、キャロルのプライベート・キーを使って暗号化されます。

クライアント認証を S/MIME クライアントにインストールする要求を出すには次のステップを踏みます。

S/MIME クライアント内 (ロータスノーツ、Netscape Messenger、Microsoft Outlook Express) でクライアント証明書が要求されます。ノーツ・ブラウザー、Netscape Navigator、あるいは Internet Explorer 4 が、信頼の置ける認証機関の Web サイトでクライアント認証要求を作成するように促します。
要求が送信されると、ブラウザーがプライベート・キーを作成し、ローカルに保存します (この処理は Internet Explorer の場合のみ異なります)。
対応したパブリック・キーが、Web 認証機関への認証要求 (PKCS #10 フォーマット) の HTTP ヘッダーの中に埋め込まれます。
認証機関は要求を処理し、どのように証明書を受け取ればいいかを eメールで知らせます。これには、署名付きのクライアント証明書を受け取る場所の URL と受け取り ID (PIN) が書かれています。
ユーザーは先ほどの URL に行って PIN を入力し、署名付きの証明書を受け取ります。
受け取った証明書は S/MIME クライアントにインストールされます。
公共のディレクトリー・プロバイダーに送信するなどしてこの証明書を発行します。これを行う認証機関もあります。

最後に、Netscape Messenger (4.x) と Microsoft Outlook Express では、受取人の証明書を得るためのメカニズムを2つ備えています。

まず、送信者は、送りたい相手に署名付きのメッセージを送ってもらいます。送信者がこのメッセージを受け取ると、Netscape Messenger (4.x) と Microsoft Outlook Express は、自動的にその証明書を、保存されている証明書の一覧に加えます。同様に、署名付きのメールが、別の Netscape Messenger (4.x) あるいは Microsoft Outlook Express ユーザーに送られた場合、そのユーザーは送信者の証明書を得ることになります。

もう1つは、LDAP を使って、Four11、Bigfoot、Switchboard といった、オンライン・ディレクトリーを検索する方法です。もし探している証明書がこれらのディレクトリーの中にあるなら、それを自分の個人アドレス帳に追加すればいいわけです。

暗号化された S/MIME メッセージを送受信する
セキュアーな eメールを送受信するテクノロジーの基本についてはもう説明しました。ここでは、キャロルの視点でロータスノーツ・クライアントを使ったときのプロセスを詳しく見ていきましょう。

キャロルが暗号化されたメッセージを送ろうとすると、デニスの X.509 認証が使われます。つまり、その証明書にアクセスしないとキャロルは暗号化されたメッセージをデニスに送ることはできません。キャロルの個人アドレス帳か、ドミノ・ディレクトリーにデニスの証明書がなければならないわけです。暗号化されたメッセージを送るには、[送信オプション] をクリックして、暗号化を選択します。あるいは、すべてのメール・メッセージを暗号化したいなら、[ファイル] - [プリファレンス] - [ユーザー] を選択して、[メールとニュース] をクリックし、暗号化を選択します。

キャロルは送信するメールの1つだけに署名したり、すべてに署名することができるほか、暗号化したメールにも署名できます。メッセージに署名をする前に、自分のノーツ ID ファイルに自分の X.509 認証があることを確認します。メールを作成したあと、そのうち1つに署名するには、 [送信オプション] をクリックして、署名するオプションを選択します。送信するすべてのメールに署名するなら、 [ファイル] - [プリファレンス] - [ユーザー] を選択して、[メールとニュース] をクリックし、[送信メールに署名] を選択します。そして、それが終わったらメールを送信します。ノーツ・メール・アドレスでないアドレスに送信した場合、あるいはメッセージが MIME 形式の場合には、メッセージは自動的に S/MIME として署名されます。

署名付きの S/MIME 形式のメッセージを受信するときも、同様に行なわれます。署名付きのメールを受信すると、ノーツはその署名が本物であるかどうかをチェックします。もし、キャロルが「認証の署名を信頼できる」とき、つまりキャロルが署名者の認証を持っているか、インターネット相互認証がある場合には、メッセージを受け取り、ステータス・バーには次のような署名が有効であることを示す文が表示されます。

Signed By: Dennis, at 10:52 AM, According To: CoCertAuthority

もしキャロルが「認証の署名を信頼しない」場合には、必要に応じてインターネット相互認証を作成するように促されます。メッセージ中の認証で、どれを信頼しているのかを指定することができます。署名付きの S/MIME メッセージには、送信者と受信者の一連の証明書が含まれていることを頭に入れておいてください。インターネット相互認証の結果は、キャロルの個人アドレス帳に保管されます。相互認証を作成することで、受け取った S/MIME 署名付きメッセージに含まれている証明書が信頼の置けるものだということを確証しているわけです。これが終わると、署名のチェックが行なわれます。ここで、送信者のアドレスや、X.509 認証を自分の個人アドレス帳に手動で保管することも可能です。S/MIME 署名付きメッセージを見る際には、[アクション] - [ツール] -[送信者をアドレス帳に追加] を選択します。この証明書はインターネット相互認証ではなく、S/MIME 署名付きメールを送受信したときに使われるものではないことに注意してください。自分から送信者へのメールを暗号化するために使われるのです。

どのように働くのか
キャロルがデニスに eメールを送り、そのメールがキャロルのメール・データベースがあるドミノ・メッセージング・サーバーにルーティングされ、さらに SMTP を介して S/MIME を使ってデニスが適切なクライアントを使うことで見ることができる自分のメール・サーバーに送るとしましょう。この、キャロルが eメールをデニスに送るという一連のタスクは次のように行なわれます。

キャロルはノーツ・クライアントを起動し、メール・データベースにアクセスします。
自分のサーバーにアクセスするために、キャロルは認証を受ける必要があります。ノーツ・クライアントは、パスワード入力画面を表示します。
キャロルは自分のパスワードを入力します。このパスワードがパブリック、プライベート・キーのペアを解読します。
パブリック、プライベート・キーの両方を使って、キャロルの認証が行なわれます。
暗号化されたリンクを使って、サーバーとデータのやりとりが行われます。
ノーツ・クライアントは、デニスの X.509 認証をディレクトリーから取得して、eメールを送れるようにします。
デニスの X.509 パブリック・キーを使ってメッセージを暗号化し、S/MIME 形式で送ります。
送られたメールはドミノサーバーに送られ、ドミノサーバーはノーツ・メッセージング・サーバーではないサーバーにも S/MIME 形式でメールを送ります。
デニスはメールを受け取り、自分の X.509 認証のキーを使って解読します。
セッションが終了すると、キャロルとデニスはログオフし、セッションを閉じます。

上に戻る

まとめ

3つの異なったアーキテクチャーを取り上げて、Web ベースのメールをセキュアーにするためのセキュリティー・オプションについて詳しく見てきました。最終的な決断は、その企業の置かれる状況や必要なものによって左右されるので、あなたの企業でセキュリティーに関する決定を下す際には、ネットワークの状態や、どのようなユーザーをかかえているのかをよく見る必要があります。

著者について
フレデリック・ダームは、約6年間ロータスノーツに関わり、ロータスの社員としては3年半たずさわってきました。ノーツやドミノに顧客として、そしてロータスの社員として関わった経験から、このテクノロジーに対して一味違った見方ができます。

ロータスの一員としては、カナダのオタワでシステム・エンジニアとして3年間活躍し、現在はスイスのチューリッヒで、ロータスプロフェッショナル・サービスのシステム・アーキテクトをつとめています。フレデリックは、IBM の Redbook 「Lotus Notes and Domino R5 Security Infrastructure Revealed, SG24-5341-00」（http://www.lotus.com/redbooks（英語）を参照）の著者の1人で、ノーツ、eセキュリティーに関わらず、セキュリティーに関して興味があります。

プロジェクトに関わったり、技術を磨いたりするのに忙しくないときには、家族と時間をすごしたり、最も好きな文学だという「スーバーマンのコミック本」を読んで人生の真実について悟るのが好きだそうです。

上に戻る