2005年度情報システム構成論第14回 Case Study: 研究室ネットワーク構築西尾信彦 [email protected] 立命館大学情報理工学部情報システム学科ユビキタス環境研究室要求定義/解決法決定(1) • Webページは独自に提供したい – WWWサーバ構築決定 • メールサーバも独自に提供したい – メールサーバ構築決定 • メールサーバは重要なので出来る限り止めたくない – メールサーバの多重化決定 • 各自のHome(ファイル置き場)はどのホストからでも利用できるようにしたい – NFSの利用決定要求定義/解決法決定(2) • メールの本体(メールボックス)はどのホストからでも利用可能にしたい – 各自のHomeにメール本体を格納したい – Maildir形式メールボックスの利用決定 • どのホストでも同じアカウント情報(ユーザ管理)を利用したい – ディレクトリサービスの利用 – Unix系端末が大多数であるため、Active Directoryは却下 – NIS、もしくはLDAPの利用決定要求定義/解決法決定(3) • 今後作成するアプリケーション(ユビキタス系の)でも同じアカウント情報を利用したい – NISはUNIX系のログイン情報以外では利用しにくい – アプリケーションで利用する場合、ログイン情報以外のものもディレクトリサービスに格納したい – NISが却下され、ディレクトリサービスには柔軟性のあるLDAPを利用することに決定要求定義/解決法決定(4) • データ(Homeの)は非常に重要であるため、物理的障害対策も入れたい – – – – NFS用ホストにRAIDを導入することに決定信頼性向上用ではないRAID0は却下 RAID1はディスク利用効率から棄却 RAID0＋1かRAID5の二択となるが、RAID5搭載 NASが存在したため、RAID5の導入を決定 • NASはNFS以外のアクセスを許したくない – NAS自体にファイアウォールがない – NAS用にファイアウォールのホストの設置決定要求定義/解決法決定(5) • 今後多くのマシンが導入され、アドレスが足りなくなる (RAINBOWグローバルなIPアドレスは8つ)ことは目に見えているので、始めから対策を立てておきたい – とりあえずは、NAPTとプライベートネットワーク (192.168.0.0/16)を利用することに決定 – 将来的に順次IPv6に移行予定(予定は未定) • 内部ネットワーク(プライベートネットワーク)ではIPアドレスではなくホスト名を使いたい – DNSサーバ構築が決定要求定義/解決法決定(6) • 内部ネットワークにはノートPCなど、動的に追加されるホストが多いため、動的IPアドレス割り振りを利用したい – DHCPサーバ導入決定 • 内部ネットワークは外部から守りたい – ファイアウォールの導入 • ノートPCはもちろんWireless – Wireless Access Pointの導入(802.11gで統一) – もちろんWirelessは暗号化 • WEPの導入構築決定サーバ一覧(1) • 外部向けサーバ(いわゆるDMZに設置) – – – – WWWサーバメールサーバ緊急時用メールサーバ LDAPサーバ • 外部にアプリケーションを設置する可能性があるため (普通は内部ネットワークのためのサーバとなる) – NFSサーバ • WWW，メールなど(外部サーバ)でも利用するため • アクセス制御用ファイアウォール設置(NAS自身にないため) – ルータ(NAPT)用ホスト • 内部ネットワークと外部ネットワークを結ぶ構築決定サーバ一覧(2) • 内部向けサーバ – DHCPサーバ – 内部用DNSサーバ – ルータ(NAPT)用ホスト • ファイアウォール付き – Wireless Access Point • WEP付き要求定義から作ったネットワーク図ルータ-FW WWW mail 緊急用 mail LDAP NFS-FW NAS DHCP DNS WAP 各学生ホスト本ネットワークの高負荷ポイント Performance Bottleneck • 全員(全ホスト)がアクセスしファイル転送することになるNAS • NASを保護しているファイアウォール – NASを使うホストは内部ネットワークにも外部ネットワークにも，さらにRits外部にも多数存在 • 内部ネットワークと外部ネットワークへの接続を全て引き受けるルータ兼NAPTホスト高負荷ポイントルータ-FW WWW mail 緊急用 mail LDAP NFS-FW NAS DHCP DNS WAP 各学生ホスト負荷の分散 • NASが外部ネットワークに所属しているため、ファイル転送トラフィックがルータとNFS-FWにかかってくる • 内部ネットワークは直接NASと通信可能にする • NASに二つEthernet Cardを持たせる – たまたま2つGbEのNICをもっているNAS(RAID5)であった – 応用問題：もし2つNICがついてなかったらどうしますか？改善後ネットワーク図ルータ-FW WWW mail 緊急用 mail LDAP NFS-FW NAS DHCP DNS WAP 各学生ホスト高負荷が解消されたルータ-FW WWW mail 緊急用 mail LDAP NFS-FW NAS DHCP DNS WAP 各学生ホストその他の改良点 • 緊急時用Mailサーバが常時遊んでいるのはもったいないため、他サーバと共有 – WWWが緊急用メールサーバを兼任するように設定 • NASのデータは物理的障害にも耐えうるが、壊れている状態から復旧するまでは利用できなくなる – 別にもう一つバックアップ用NASを用意する最終的なネットワーク図ルータ-FW WWW 緊急用mail mail DNS NFS-FW NAS Backup用NAS DHCP LDAP WAP 各学生ホスト実際には．．． • DMZ(外部ネットワーク)に， – TV会議用ホストを設置 • 内部ネットワークに， – Linuxクラスタ (IBM BladeCenter) – ソフトウェア開発用CVSサーバ – アドホックモード用無線基地局を設置 • 10.0.0.0/8のプライベートネットワーク – WAPとDHCPは同一ホスト • 有線ネットワークは可能な限りGbE接続 • 無線ネットワークは802.11gと11bを分割メールサービスの要求定義 • 複数のホストから同時に自分のメールを利用する必要がある (ノートPCと据え置きホスト,etc) – IMAP4rev1を採用 • メールサーバを多重化する – メールボックスはNFS上に置く – NFSを利用するため、メールボックスはMaildir形式 • セキュリティは出来る限り確保する – IMAP over SSL, SMTP over SSL, SMPT Authの利用決定ファイアウォール設定一覧(1) • ファイアウォールが必要なホストは5つ – ルータ，WWW/緊急用Mail，Mail，LDAP，NFS-FW • ルータ兼NAPT – 内部から外部へのIPマスカレード(POSTROUTINGでフック) – 外部から内部への接続は、TCP接続確立済みのものは通す、それ以外は拒否(SYN:× ACK: ○) – ルータへのアクセスは内部からのSSH(22)のみ許可 • WWW/緊急用Mail – HTTP:80, HTTPS:443, SSH:22， IMAP:143, IMAPS:993, SMTP:25, SMTPS:465 ファイアウォール設定一覧(2) • Mail – IMAP:143, IMAPS:993, SMTP:25, SMTPS:465, SSH:22 • LDAP – LDAP:389, LDAPS:636, SSH:22 • NFS-FW – 外部ネットワークからNASネットワークへの接続：TCP接続確立済みのものは通す – 外部ネットワークからNASネットワークへの接続：NFS(2049) をメインNASへ転送(バックアップへは送らない) 構成手順 • 該当ネットワークで出ている要求をまとめる • 各要求について、実現法を決定する • ネットワーク上のボトルネックを検出し、対策を立てる • 機材や資金などと相談して、マシン構成を考える • 各種ソフトの設定を行う最終的なネットワーク図ルータ-FW WWW 緊急用mail mail DNS NFS-FW NAS Backup用NAS DHCP LDAP WAP 各学生ホストもしも．．． • ルータホストがウィルスに感染してRAINBOW 内を攻撃しているといわれたら．．．どうしてこうなったか？ • まず原因は何か？ – ルータ自身ではないことが多い – 内部ネットワークの中に犯人がいる • ルータのファイアウォールの設定が不十分 – 外向きの攻撃ポートは塞がないといけないまず何をするか • ルータをネットワークから切離す – 外部ネットワークの足を抜く • ルータのファイアウォールの設定を行なう – – – – ルータのファイアウォールのログを見て現状を把握する適切なフィルタを入れてまたログを見て効果があることを確認 • 同時に内部ネットワークの全てのホストについて – ウィルススキャン – OSアップデート原因を探す，今後の対処 • なぜ汚染されたか – どこから来たか – 対策は万全だったのか？ • アップデートなどはできていたか？ • ファイアウォールの設定は大丈夫だったか？ • 今後はどうすべきか – – – – すべてに処置をほどこすのはもちろん穴のあいた原因をつぶすシステム作り現状を把握できるシステム作り経験を共有できる環境さらに「天災」の対策：UPS(1) （Uninterruptible Power Supply） • 落雷，瞬断，停電．．． • 簡単に言い表すと，大容量電池 • 電源と機器の間に配置して，電源からの供給が途切れた場合に，自身が蓄えている電気により機器を動かし続ける • 不測の事態により，電気の供給が切れた場合の強制終了によるシステム崩壊や物理的に破損を防ぐ UPS(2) （Uninterruptible Power Supply） • 停電対策 – 瞬間的停電時に – システムを停止するまでの時間を稼ぐ – 電源供給再開後にシステムを自動稼動する • UPSを選択する上での注意点 – 電力容量が利用する機器に対して十分か – どの機能を搭載しているか/していないか – 利用機器のOSが対象UPSに対応しているか • ドライバがあるかどうかなど最終的なネットワークでの課題ルータ-FW WWW 緊急用mail mail DNS NFS-FW NAS Backup用NAS DHCP LDAP WAP 各学生ホスト • 悪意ある第三者が物理的に内部ネットワークに接続出来る場合のセキュリティが確保できていない． – 対策法を提案せよ．また，その対策法について述べることがあれば書け． • Webアクセスを高速化したい．どのような改良を施せばいいか． • 現在，このネットワークはRAINBOWの中にあるため，直接インターネット経由で接続することは出来ない． – この問題を解決する方法を提案せよ，また，その方法の問題点についても述べよ． • 内部ネットワークが肥大化し，ルータにかかる負荷が軽視できない状態になってきた． – 対処法を提案せよさらなる落穂拾い Ad-hoc モード（無線ネットワーク） • 無線ネットワークの形態の一つ – 特定のアクセスポイントを持たず，二つの機器のみでネットワークを構築する • もともと軍事用用途のネットワーク • 街中や，たまたま出会った人同士など，特定インフラが無い状態でネットワークを確立する • One-Hopで届く範囲内のみで利用可能な, Peer to Peer 接続 Ad-hocにおけるルーティング • Ad-Hocモードでは直接通信可能なノード同士でしか通信が出来ない • ルーティングプロトコルを利用することで，直接は通信できないノード同士が間のノードを利用して通信することが可能になる • Ad-Hocモードのノードは常に動き回っている可能性が高いため，毎回同じルートが使えるかどうかわからない • 複数のルートが存在しうる • 通信速度は，n-hopすると大体1/nに低下する Ad-Hocにおけるルーティング例余計に距離がかかるため，棄却されたルート公開鍵暗号化方式 • 二つの鍵を利用する暗号方式 • 一方の鍵で暗号化すると，他方の鍵で復号化することができる • 一方の鍵で暗号化しても，同一の鍵では復号化できない • 鍵発行者が秘密鍵を保持し，公開鍵のみを配布することにより， – クライアント側が，公開鍵を使って暗号化して情報が発行者しか読めない状態にする – 発行者側が，秘密鍵を使って暗号化して，発行者が発行した情報であると証明する電子署名 • 電子的にファイルに署名を残して，特定期間から発行された電子文書であることを証明する • 特定情報を公開鍵暗号化方式を使って，符号化して利用する方法が一般的 • 第三者の認証機関を設けるのが普通 – 認証局（Certificate Authority） – 例：ベリサイン認証局：電子証明書 • 電子署名を利用したとしても，その電子署名自体が正規のものであるかどうかが判別できない • 法的に整備された認証局によって，電子署名自体が正規のものであるかどうかをチェックする • 公的認証局の無い電子署名はあまり信用できない認証局利用の電子署名の動き共有鍵暗号方式 • 一つの鍵を暗号化，復号化の両方に同一の鍵を利用する • 一番初めに，対象クライアントへ，どのようにして『安全』に『確実』に鍵を渡すかが重要 • 鍵のやり取りの時に，鍵を傍受されるとその後の通信や，同一の鍵を利用しているシステム全てが危険にさらされる共有鍵か公開鍵か？ • やり取りの難しい共有鍵方式よりも公開鍵方式があれば，それで十分ではないか？ • ビット数問題 – 必要十分ビット数が大きい – 共有鍵方式と同等の強度を得る場合，場合の数倍～十数倍程度のビット数が必要になる • 計算速度問題 – 公開鍵暗号化方式のほうが計算量が多い – 弱いCPUの場合，実用に耐え得ないことが多い • 現在は，一番初めのみ，公開鍵暗号で共有鍵を送り，以後は共有鍵方式を利用することが多い RFID • 小型無線ICタグのこと • 小さいものは1cm平方程度であり，非常に小さい • 今後はありとあらゆるものに付加されていくのでは？と考えられている • 方式には大きく分けると下記の二つがある – 外部から電波を受けて発生する電界から電気を生み出し，電池なしで動くパッシブ形 – 自身が電池などを保持し，電波を発生させるアクティブ型 • 利点パッシブタグ – 非常に小さく，薄い – 電池が要らないため，ほぼ無期限に稼動 – 電界に対して正確に決められた方向を向かないと反応しないため，誤動作が起きにくい • 欠点 – 電波の届く範囲が狭い（およそ１ｍ, 遠距離専用でも最大10m程度） – 電界に対して正対しないと反応してくれない • 利用場面 – 電子バーコード，機材管理アクティブタグ • 利点 – 電池を搭載しているため，遠距離でも通信が出来る – 電界の向きに関係しない • 欠点 – 電池の寿命がタグの寿命になる（1月～1年程度が普通） • 利用場面 – ユーザに配布して，ユーザの位置情報を取得する – 店舗内での，物の場所を知るなどセキュアOS • セキュリティの高いOSに対する総称だったが，現在ではセキュアOS研究会によって，最低限下記の二点を持つもの定義がされている – MAC（強制アクセス制御） • リソース（ファイル，IO，etc）へのアクセス権をセキュリティ管理者以外が変更できなくするものたとえ，リソース保持者であってもアクセス権の変更は行えない – 最小特権 • 普通，管理者が保持する無数の特権を，A プログラム実行権，ファイルアクセス権などに分け，プロセスやサーバソフトなどに個別に付与する仕組み • たとえ，同じ管理者が実行している場合においても，各プロセスが保持している権限は異なるリアルタイムOS • 処理を特定の時間内で処理することを確約しているOS • WindowsやLinuxなどは出来る限り処理を早く実行するが，リアルタイムOSでは，特定時間以内に終了しない動作は実行を許可しない • 電話やロボットなど，特定時間内に処理が終了することを要求されるものに搭載されることが多い • 代表例：TRON グリッドコンピューティング • ネットワークを介して複数のコンピュータを結ぶことで仮想的に高性能コンピュータを作る手法 • 空いているマシンのCPUパワーを並列的に利用して，大規模演算を実行する • 家庭用マシンなどを利用して行うdistributed.netや SETI@homeなどが存在する • ひょっとしたら，夜中の大学では流体力学計算などがされているのかもしれない