2005年度 情報システム構成論 第10回 メイルシステム 西尾 信彦 [email protected] 立命館大学 情報理工学部 情報システム学科 ユビキタス環境研究室 MTAとMUA Mail Transfer Agent Mail Server Mail User Agent Mail Client メイルBox • サーバ上のメイルを貯めておく場所 • 構築するシステムに沿ったものにする必要がある （特にNFSを利用する場合は注意が必要） • 古くからさまざまな種類がある • 古株（というより絶滅危惧種） – MMDF • おそらく一番単純なメイルBox形式 • 現存しているかどうか不明・子孫がSCO システムで使われている？ – BABYL • MIT の昔のメイルシステムが起源 • Emacs のメイルリーダモードで使われている場合があります （Emacsの仕様変更によっては使われていないかも） MH形式 • • • • • • 古くからあるメイルBox形式 MH系ソフトが利用している メイルが一つ一つ別々のファイルに保管される ファイル名は連番で記述される 管理用のファイルを編集する必要がある 管理用ファイル編集を同時に行うなどするとメイ ルが正しく管理されなくなる場合がある • NFSの場合、正常に書き込まれない場合がある mbox形式 • • • • 比較的古くからあるメイルBox形式 UnixのメイルBox形式としては一般的 全メイルがひとつのファイルに凝縮 メイルとメイルの基本的な区切りはFromで始まる 行があるかどうかで判断する （メイルの途中でFromから始まる行があると>が 頭に付く） • 未対応のメイルソフトが少ないので導入が比較 的楽 mbox形式（問題点） • 配送途中で（つまりファイル編集中に）サーバが 落ちる、他のソフトが同時に書き込む、NFSのマ ウントが切れるなどするとメイル消失の危険性が ある。 • ファイル中でFrom行が消失すると、複数のメイル がひとつに融合してしまう可能性がある • さまざまな亜種が存在するが、その亜種間での 互換性は保障されていない • NFSを利用している場合、ファイルロックを別々 のホストで実行すると無意味 Maildir形式 • • • • 別名, qmail-maildir形式 比較的新しいメイルBox形式 メイルが一つ一つ別々のファイルに保管される NFSを意識してNFS上で利用した場合にも、正常 に処理されるようにしている • 中央制御ファイルを置かないためファイルロック を行う必要がなく、複数のプロセスで利用した場 合においても安全 Maildir形式が安全な理由 • 下記のアルゴリズムを利用しているため 1. maildir ディレクトリに 移動する 2. 名前 tmp/time.pid.host の存在をチェック • • • time は GMT で1970年の開始からの秒数 pid はプログラムのプロセスID host はMTAのホスト名 3. すでに同名ファイルがあった場合は、数秒待ち再試 行する、これを、回数の上限まで繰り返す 4. tmp/time.pid.host を生成 5. ファイルを NFS 書き込み(NFS-writing)する 6. ファイルを new/time.pid.host に linkする この瞬間、メッセージは正常に配送される Maildir形式が安全な理由（2） • NFS 書き込み(NFS-writing) とは 1. いつものように、各 write() コールから返されたバイ ト数をチェックする 2. fsync() を呼び出し、戻り値をチェックする 3. close() を呼び出し、戻り値をチェックする • • などを意味します。 標準的な NFS の実装では、fsync() を誤って処 理するが、 close() して書き込みを強要している （qmail実装） 実際のアルゴリズムは実装による 受信用プロトコル • POP3 – サーバ上のメイルBoxから受信 – サーバ上のメイルBoxからメイルを削除する – サーバ上からメイルを削除するため、メイルBoxの容量が 少ない場合などに有効 – 単一のマシンでしか同一のメイルを扱うことができない APOP（Authenticated POP) • POPはパスワードを暗号化せずに流すため安全 ではない • APOPはPOPのパスワードを暗号化して通信する • 多くのメイルクライアントが対応済み – Outlook, Outlook Express, Becky!, Sylpheed, Wanderust, etc • 問題 – 多くの場合, サーバ上のアカウントとは別にパスワー ドを保存するため, 別途パスワードが必要になる – パスワードのみ暗号化できるが、メイル本文は暗号化 しないため、通信内容は丸見えである(SSL利用に） 受信用プロトコル • IMAP４ – サーバ上のメイルBoxを閲覧 – サーバ上のメイルBoxからメイルを削除せず、 手元にはキャッシュのみを残す • 携帯電話・Webメイルなどで利用されている • 複数のマシンで同一のメイルを扱うことができる IMAPのユーザ認証 • IMAP標準のユーザ認証は暗号化したパ スワードを利用しない • 暗号化したパスワードを利用する方法とし て、CRAM-MD5などが用意されている • APOPと同様に、暗号化したパスワードを 利用する場合はアカウント用パスワードと は別にパスワードが必要になる場合が多 い メイル配送 • SMTPプロトコル • DNSのMXレコードを参照して、リレー形式 であて先まで配送する MXレコード •A宛はAまで •B宛はBまで •C宛はCまで •D宛はBまで B A C D MTAとMUA Mail Transfer Agent Mail Server Mail User Agent Mail Client SMTPが抱える問題点 • 古くに作られたプロトコルであり, 性善説にのっ とって作られたプロトコル • 送り元の判定をしていない – どのSMTPサーバにメイル送信を頼んでも, 目的地に 届く – この特性をSPAMなどに利用され、踏み台にされてい るサーバが多数存在する • 暗号化されていないため、内容は丸見えである ユーザ認証機構を付加した SMTP • POP before SMTP – SMTP送信を行う前にPOPにて認証を行う – SMTPサーバはPOP認証を行ったホストに対し て認証後、規定時間以内のメイル送信を許可 する POP認証 規定時間以内にメイルを送信 POP認証をしていない （正規の権限がない）ホスト） POP before SMTPの問題点 • 毎回POP認証を行うため、ネットワークトラフィック の増加と、スループットの低下を招く • 送信元を偽ってメイルを出すことによって、誰かが 行ったPOP認証にまぎれて、メイルを飛ばすことが 可能である POP認証 ホストA 規定時間以内にメイルを送信 送信元偽装メイルは送信可能 私はA ホストB ユーザ認証機構を付加した SMTP • SMTP Authentication（SMTP AUTH） – 文字通り、SMTP接続時に認証機構を組み込 んだもの – SMTP接続時に認証を実行する （暗号化 or plain） 認証 ＋ メイル送信 認証されない限り、 メイル送信は不可能 ホストA ホストB SMTP Authの問題点 • パスワード認証を提供するが、パスワードが暗号 化されて利用されるとは限らない • 暗号化する場合はチャレンジ-レスポンス認証で CRAM-MD5を利用することになる • 暗号化したパスワードを利用する場合、アカウン ト用パスワードとは別にパスワードが必要になる • たとえ、暗号化したパスワードを利用したとしても、 通信内容は暗号化されず、内容は丸見えである チャレンジ-レスポンス認証 • APOPやSMTP/IMAPの暗号化パスワード利用時に使 われる認証方法（CRAM-MD5） • パスワードを直接暗号化したものは利用しない • パスワードを特定方法で符号化（MD5などと同様）し、 符号化後のものと符号化の鍵を送信する • サーバ側では、クライアント側と同様に保存してある生 のパスワードを送られてきた符号化の鍵を使って符号 化し、値を比較して成否を判定する • APOP/SMTP/IMAPなどで暗号化パスワードを利用する 場合に別途パスワードが必要になるのはこのためであ る チャレンジ-レスポンス認証図解 生パスワード ②不可逆変換 生パスワード ③不可逆変換 ランダム鍵 ④比較して成 否判定 ①乱数発生 チャレンジ-レスポンス認証 利点・欠点 • 利点 – パスワードそのものを暗号化して送らないため、途中で盗聴さ れたとしても、復号してパスワードを取得することはできない – 鍵をランダムに決めることにより毎回異なる文字列が生成で きる • 欠点 – 双方が生のパスワードを保管しておく必要がある – 保管されているパスワードの管理に注意が必要 – サーバ側がクラックされた場合は、すべてのパスワードが流 出する – サーバ・クライアント双方であらかじめ利用する符号化方式を あわせておく必要がある SSL/TLSの利用 • 通信経路すべてを暗号化する • 暗号化された通信経路内で、生のパスワードを 利用しても問題ない • 通信経路すべてが暗号化されるため、パス ワードのみではなくメイルの内容自体も暗号化 することができる • SSL/TLS証明書により接続先の安全性を検証 することができる SSL/TLSとは • SSL (Secure Sockets Layer) – Netscape Communications社が開発した通信経路暗号化 プロトコル – はじめに公開鍵暗号化方式で共有鍵を交換し高速な暗 号化経路を実現している – 第三者認証機関が発行した開鍵（電子証明書）を利用 することで、サーバ・クライアントが公的に正規のもので あることを証明することができる • TLS (Transport Layer Security) – SSL3.0に若干の拡張と改良を加えたもの – RFC 2246としてIETFで標準化されている 暗号化非対応クライアントとの共存 • SMTPにSSLのみを組み込むと、SSL未対応の SMTPサーバからのメイルを受け取ることができ ない • SSL未対応クライアントが利用できない • はじめにSSLを利用するか（できるか）を選択す ることを可能にする – SSL対応SMTPサーバ間の通信はセキュアに、SSL 未対応のSMTPサーバからの通信は今までどおり行 うことができる – SSL対応・SSL未対応クライアント双方を同一サーバ で利用することができる メイルまとめ • メイルBoxの信頼性確保のためにシステムに あったメイルBox形式を選ぶ • POPはサーバ容量が少なくても利用可能 • IMAPは複数のマシンで同一メイルが利用可能 だが、多くのサーバ容量が必要 • SMTPメイルのスパム対策は必須 • パスワードなどセキュリティ項目の検討 （利用者のクライアントソフト・ネットワーク構成 上利用できない場合など） 2005年度 情報システム構成論 第11回バックアップと多重化 西尾 信彦 [email protected] 立命館大学 情報理工学部 情報システム学科 ユビキタス環境研究室 バックアップ(頻度・メディア) • 要求の種類から必要頻度・メディア種類を選択する – 研究などで一週間前のスナップショットが必要になることが ある ⇒ 一週間に一回 – HDDなどの故障対策で即時復旧が必要 ⇒ 再構築に時間がかかるテープなどは不要 ⇒ ランダムアクセス可能なメディアを選択する – メールデータなど、現在の状態をリアルタイムにミラーリング する必要がある ⇒ ミラーリングシステム、RAIDなどを利用する ⇒ 全利用者の合意のものとであれば、一日一回程度とし その間のデータ損失は許容するという方法もある バックアップ(時期・必要事項) • 誰(何)も利用していないときに実行する – – – – 深夜・休日・事前に告知した時刻に実施する 可能ならばネットワークを切断して実施する 背後で動いているソフトは可能な限り終了する 可能であれば、singleモード起動が理想的 • 所有者・権限などをそのまま保存する – 保存先メディアがufsを利用できない場合(一部テープメディ アなど)、権限・所有者情報などを別途保存しておく必要が ある – 各種バックアップコマンドのオプションを適切に設定するｓ バックアップの利点・欠点 • 利点 – 常時(適時)の情報コピー(スナップショット)を保持で きる – コピーからオリジナルを復旧可能 • 欠点 – 故障時に断続利用が可能なわけではない – 故障時に即座に復旧を開始できるわけではない – 一時的にであれ、ネットワーク切断・利用停止などが 必要になる • 多重化することにより、上記の欠点を克服可能 メイルサーバの多重化 • メイルサーバはリアルタイムで情報が届く ため、一度稼動させると停止させることが 難しい – メンテナンスや故障時など • 二重化し、一方が停止している場合、バッ クアップ用のサーバが稼動するように設計 することが必要になる メイルサーバの多重化 • MXレコードを利用して転送先を制御する – MXレコードは複数設定可能 – 優先順位により、転送先が自動的に変更される • 実際のMXレコードの例 （***.ubi.is.ritsumei.ac.jp宛のメイル配送先） ubi.is.ritsumei.ac.jp IN IN MX 50 mail1.ubi.is.ritsumei.ac.jp. MX 90 mail2.ubi.is.ritsumei.ac.jp. メイルサーバ多重化時の注意点 • メイルサーバごとにメイルBoxが異なると障害 時やメンテナンス時にメイルが分散する – NFSを利用して同一のメイルBoxを利用する – NFSを利用するため、メイルBox形式はMaildirが望 ましい • 双方で同一アカウントを利用する必要がある – NIS/LDAPなどで同一アカウントが存在する状態に しておく • 導入してあるソフトを同一のものにしておく必要 がある メイルサーバ多重化時の構成例 ①メイル配送 上流 メイル サーバ メイル サーバ ②共通のメイル ボックスに追加 ①’メイル配送 メイルサーバダウン時 メイル サーバ バックアップ NFS NIS ファイルシステムの多重化 • ファイルシステムがクラッシュすると全データが消滅 する可能性がある • 定期的にバックアップを取ることである程度防ぐこと が可能 – ロールバックはどうしても発生する • ファイルシステムを多重化する利点 – ひとつが壊れた場合でも、正常にサービスを提供し続ける ことができる – サービスを提供しながら、壊れているものを途中で取り替え るなどして、再度多重化状態を構築することができる RAID （Redundant Arrays of Independent Disks） • 高速かつ大容量・高信頼性ディスクを構築する方法 • 1987年にカリフォルニア州バークレー大学で発表された 「A Case for Redundant Arrays of Inexpensive Disks」 という論文が基礎となっている • 上記のように、もともとは安価（Inexpensive）なディスクを 利用することを前提にしていたものであるが、現在は個別 （Independent）のディスクを用いてという意味になっている • 専用ハードウェアを利用する方法 – 効果、高速、高信頼性 • ソフト上でエミュレートする方法 – 安価、オーバーヘッドが大きい、信頼性はソフトと実行環境依存 RAID0 • 2台以上のディスクをひとつのディスクとして扱う • 書き込み、読み込み時は複数のディスクにひとつ のファイルを分散し、並列アクセスすることにより 高速アクセスを可能にする (striping) • 理論上、おおよそ接続台数倍のアクセス速度向 上が見込まれる • 分散して書き込むため、ひとつのディスクが壊れ た時点で全ファイルが読み出せなくなる – 信頼性という面では期待できず、信頼性は接続台数 が多いほど低下する RAID1 • 2台以上のディスクをひとつのディスクとして扱 う • ミラーリングを行い、複数のディスクに同一の 情報を書き込む • 最悪一台のディスクが生き残っていれば、処理 を続行することができる • 信頼性は接続台数を増やすほど向上する • ディスク利用効率は接続台数に反比例する – 2台同時に利用すれば1/2、3台同時に利用すれば 1/3となる RAID5 • データに対してパリティを作成する • 作成したパリティとデータを分散して配置する – ディスクが壊れた場合でも、他のディスク上のパリティか ら壊れたデータを復旧することが可能 • 専用機器の場合、ディスク故障を自動検出し、自動 的に修復するものもある • 書き込み速度はパリティ計算のため多少低下する • 読み込み速度は並列アクセス可能なため向上する • ディスク利用効率は、ディスク一台分がパリティで 利用されるが、 ストライピングされるためほぼ接続 台数に比例する その他のRAID • RAID2,3,4が存在するがほとんど使われていない • RAID0+1 – ミラーリングし、それをさらにストライピングしたもの – 最低4台以上での構成となる • RAID6 – RAID5に独立パリティを追加し、複数台異常のディスクが同 時に壊れた場合で、修復可能にしたもの クラスタリングシステム • 複数のマシンを相互に接続し、ひとつのマシンの ように見せる • ひとつのサービスに対してサーバを複数用意す ることにより、一部のマシンが故障しても、全体と してはパフォーマンスが落ちたように見える （サービスそのものは停止しない） • パフォーマンスや信頼性の向上は単に接続台数 を増やすことによって実現できる • ネットワークトラフィックには注意が必要 クラスタリングシステム図解 一つのシステムと して利用 一部ホストが故 障中でも全サー ビスが利用可能
© Copyright 2024 ExpyDoc
