2005年度 情報システム構成論 第14回 Case Study: 研究室ネットワーク構築

Presentation on theme: "2005年度 情報システム構成論 第14回 Case Study: 研究室ネットワーク構築"— Presentation transcript:

1 2005年度 情報システム構成論 第14回 Case Study: 研究室ネットワーク構築
西尾 信彦 立命館大学 情報理工学部 情報システム学科 ユビキタス環境研究室

2 要求定義/解決法決定(1) Webページは独自に提供したい メールサーバも独自に提供したい メールサーバは重要なので出来る限り止めたくない
WWWサーバ構築決定 メールサーバも独自に提供したい メールサーバ構築決定 メールサーバは重要なので出来る限り止めたくない メールサーバの多重化決定 各自のHome(ファイル置き場)はどのホストからでも利用できるようにしたい NFSの利用決定

3 要求定義/解決法決定(2) メールの本体(メールボックス)はどのホストからでも利用可能にしたい
各自のHomeにメール本体を格納したい Maildir形式メールボックスの利用決定 どのホストでも同じアカウント情報(ユーザ管理)を利用したい ディレクトリサービスの利用 Unix系端末が大多数であるため、Active Directoryは却下 NIS、もしくはLDAPの利用決定

4 要求定義/解決法決定(3) 今後作成するアプリケーション(ユビキタス系の)でも同じアカウント情報を利用したい
NISはUNIX系のログイン情報以外では利用しにくい アプリケーションで利用する場合、ログイン情報以外のものもディレクトリサービスに格納したい NISが却下され、ディレクトリサービスには柔軟性のあるLDAPを利用することに決定

5 要求定義/解決法決定(4) データ(Homeの)は非常に重要であるため、物理的障害対策も入れたい NASはNFS以外のアクセスを許したくない
NFS用ホストにRAIDを導入することに決定 信頼性向上用ではないRAID0は却下 RAID1はディスク利用効率から棄却 RAID0＋1かRAID5の二択となるが、RAID5搭載NASが存在したため、RAID5の導入を決定 NASはNFS以外のアクセスを許したくない NAS自体にファイアウォールがない NAS用にファイアウォールのホストの設置決定

6 要求定義/解決法決定(5) 今後多くのマシンが導入され、アドレスが足りなくなる(RAINBOWグローバルなIPアドレスは8つ)ことは目に見えているので、始めから対策を立てておきたい とりあえずは、NAPTとプライベートネットワーク( /16)を利用することに決定 将来的に順次IPv6に移行予定(予定は未定) 内部ネットワーク(プライベートネットワーク)ではIPアドレスではなくホスト名を使いたい DNSサーバ構築が決定

7 要求定義/解決法決定(6) 内部ネットワークにはノートPCなど、動的に追加されるホストが多いため、動的IPアドレス割り振りを利用したい
DHCPサーバ導入決定 内部ネットワークは外部から守りたい ファイアウォールの導入 ノートPCはもちろんWireless Wireless Access Pointの導入(802.11gで統一) もちろんWirelessは暗号化 WEPの導入

8 構築決定サーバ一覧(1) 外部向けサーバ(いわゆるDMZに設置) WWWサーバ メールサーバ 緊急時用メールサーバ LDAPサーバ
外部にアプリケーションを設置する可能性があるため(普通は内部ネットワークのためのサーバとなる) NFSサーバ WWW，メールなど(外部サーバ)でも利用するため アクセス制御用ファイアウォール設置(NAS自身にないため) ルータ(NAPT)用ホスト 内部ネットワークと外部ネットワークを結ぶ

9 構築決定サーバ一覧(2) 内部向けサーバ DHCPサーバ 内部用DNSサーバ ルータ(NAPT)用ホスト
ファイアウォール付き Wireless Access Point WEP付き

10 要求定義から作ったネットワーク図 ルータ-FW WWW mail 緊急用 mail LDAP NFS-FW NAS DHCP DNS WAP
各学生ホスト

11 本ネットワークの高負荷ポイント Performance Bottleneck
全員(全ホスト)がアクセスしファイル転送することになるNAS NASを保護しているファイアウォール NASを使うホストは内部ネットワークにも外部ネットワークにも，さらにRits外部にも多数存在 内部ネットワークと外部ネットワークへの接続を全て引き受けるルータ兼NAPTホスト

12 高負荷ポイント ルータ-FW WWW mail 緊急用 mail LDAP NFS-FW NAS DHCP DNS WAP 各学生ホスト

13 負荷の分散 NASが外部ネットワークに所属しているため、ファイル転送トラフィックがルータとNFS-FWにかかってくる
NASに二つEthernet Cardを持たせる たまたま2つGbEのNICをもっているNAS(RAID5)であった 応用問題：もし2つNICがついてなかったらどうしますか？

14 改善後ネットワーク図 ルータ-FW WWW mail 緊急用 mail LDAP NFS-FW NAS DHCP DNS WAP
各学生ホスト

15 高負荷が解消された ルータ-FW WWW mail 緊急用 mail LDAP NFS-FW NAS DHCP DNS WAP 各学生ホスト

16 その他の改良点 緊急時用Mailサーバが常時遊んでいるのはもったいないため、他サーバと共有
WWWが緊急用メールサーバを兼任するように設定 NASのデータは物理的障害にも耐えうるが、壊れている状態から復旧するまでは利用できなくなる 別にもう一つバックアップ用NASを用意する

17 最終的なネットワーク図 ルータ-FW WWW 緊急用mail mail LDAP NFS-FW Backup用NAS NAS DHCP
DNS WAP 各学生ホスト

18 実際には．．． DMZ(外部ネットワーク)に， 内部ネットワークに， 有線ネットワークは可能な限りGbE接続
TV会議用ホストを設置 内部ネットワークに， Linuxクラスタ (IBM BladeCenter) ソフトウェア開発用CVSサーバ アドホックモード用無線基地局を設置 /8のプライベートネットワーク WAPとDHCPは同一ホスト 有線ネットワークは可能な限りGbE接続 無線ネットワークは802.11gと11bを分割

19 メールサービスの要求定義 複数のホストから同時に自分のメールを利用する必要がある (ノートPCと据え置きホスト,etc)
IMAP4rev1を採用 メールサーバを多重化する メールボックスはNFS上に置く NFSを利用するため、メールボックスはMaildir形式 セキュリティは出来る限り確保する IMAP over SSL, SMTP over SSL, SMPT Authの利用決定

20 ファイアウォール設定一覧(1) ファイアウォールが必要なホストは5つ ルータ兼NAPT WWW/緊急用Mail
ルータ，WWW/緊急用Mail，Mail，LDAP，NFS-FW ルータ兼NAPT 内部から外部へのIPマスカレード(POSTROUTINGでフック) 外部から内部への接続は、TCP接続確立済みのものは通す、それ以外は拒否(SYN:× ACK: ○) ルータへのアクセスは内部からのSSH(22)のみ許可 WWW/緊急用Mail SSH:22， IMAP:143, IMAPS:993, SMTP:25, SMTPS:465

21 ファイアウォール設定一覧(2) Mail LDAP NFS-FW
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へ転送(バックアップへは送らない)

22 構成手順 該当ネットワークで出ている要求をまとめる 各要求について、実現法を決定する ネットワーク上のボトルネックを検出し、対策を立てる
機材や資金などと相談して、マシン構成を考える 各種ソフトの設定を行う

23 最終的なネットワーク図 ルータ-FW WWW 緊急用mail mail LDAP NFS-FW Backup用NAS NAS DHCP
DNS WAP 各学生ホスト

24 もしも．．． ルータホストがウィルスに感染してRAINBOW内を攻撃しているといわれたら．．．

25 どうしてこうなったか？ まず原因は何か？ ルータのファイアウォールの設定が不十分 ルータ自身ではないことが多い
内部ネットワークの中に犯人がいる ルータのファイアウォールの設定が不十分 外向きの攻撃ポートは塞がないといけない

26 まず何をするか ルータをネットワークから切離す ルータのファイアウォールの設定を行なう 同時に内部ネットワークの全てのホストについて
外部ネットワークの足を抜く ルータのファイアウォールの設定を行なう ルータのファイアウォールのログを見て 現状を把握する 適切なフィルタを入れて またログを見て効果があることを確認 同時に内部ネットワークの全てのホストについて ウィルススキャン OSアップデート

27 原因を探す，今後の対処 なぜ汚染されたか 今後はどうすべきか どこから来たか 対策は万全だったのか？ すべてに処置をほどこすのはもちろん
アップデートなどはできていたか？ ファイアウォールの設定は大丈夫だったか？ 今後はどうすべきか すべてに処置をほどこすのはもちろん 穴のあいた原因をつぶすシステム作り 現状を把握できるシステム作り 経験を共有できる環境

28 さらに「天災」の対策：UPS(1) （Uninterruptible Power Supply）
落雷，瞬断，停電．．． 簡単に言い表すと，大容量電池 電源と機器の間に配置して，電源からの供給が途切れた場合に，自身が蓄えている電気により機器を動かし続ける 不測の事態により，電気の供給が切れた場合の強制終了によるシステム崩壊や物理的に破損を防ぐ

29 UPS(2) （Uninterruptible Power Supply）
停電対策 瞬間的停電時に システムを停止するまでの時間を稼ぐ 電源供給再開後にシステムを自動稼動する UPSを選択する上での注意点 電力容量が利用する機器に対して十分か どの機能を搭載しているか/していないか 利用機器のOSが対象UPSに対応しているか ドライバがあるかどうかなど

30 最終的なネットワークでの課題 ルータ-FW WWW 緊急用mail mail LDAP NFS-FW Backup用NAS NAS DHCP
DNS WAP 各学生ホスト

31 悪意ある第三者が物理的に内部ネットワークに接続出来る場合のセキュリティが確保できていない．
対策法を提案せよ．また，その対策法について述べることがあれば書け． Webアクセスを高速化したい．どのような改良を施せばいいか．

32 現在，このネットワークはRAINBOWの中にあるため，直接インターネット経由で接続することは出来ない．
この問題を解決する方法を提案せよ，また，その方法の問題点についても述べよ． 内部ネットワークが肥大化し，ルータにかかる負荷が軽視できない状態になってきた． 対処法を提案せよ

33 さらなる落穂拾い

34 Ad-hoc モード（無線ネットワーク） 無線ネットワークの形態の一つ もともと軍事用用途のネットワーク
特定のアクセスポイントを持たず，二つの機器のみでネットワークを構築する もともと軍事用用途のネットワーク 街中や，たまたま出会った人同士など，特定インフラが無い状態でネットワークを確立する One-Hopで届く範囲内のみで利用可能な, Peer to Peer 接続

35 Ad-hocにおけるルーティング Ad-Hocモードでは直接通信可能なノード同士でしか通信が出来ない
ルーティングプロトコルを利用することで，直接は通信できないノード同士が間のノードを利用して通信することが可能になる Ad-Hocモードのノードは常に動き回っている可能性が高いため，毎回同じルートが使えるかどうかわからない 複数のルートが存在しうる 通信速度は，n-hopすると大体1/nに低下する

36 余計に距離がかかるため，棄却されたルート
Ad-Hocにおけるルーティング例 余計に距離がかかるため，棄却されたルート

37 公開鍵暗号化方式 二つの鍵を利用する暗号方式 一方の鍵で暗号化すると，他方の鍵で復号化することができる
一方の鍵で暗号化しても，同一の鍵では復号化できない 鍵発行者が秘密鍵を保持し，公開鍵のみを配布することにより， クライアント側が，公開鍵を使って暗号化して情報が発行者しか読めない状態にする 発行者側が，秘密鍵を使って暗号化して，発行者が発行した情報であると証明する

38 電子署名 電子的にファイルに署名を残して，特定期間から発行された電子文書であることを証明する
特定情報を公開鍵暗号化方式を使って，符号化して利用する方法が一般的 第三者の認証機関を設けるのが普通 認証局（Certificate Authority） 例：ベリサイン

39 認証局：電子証明書 電子署名を利用したとしても，その電子署名自体が正規のものであるかどうかが判別できない
法的に整備された認証局によって，電子署名自体が正規のものであるかどうかをチェックする 公的認証局の無い電子署名はあまり信用できない

40 認証局利用の電子署名の動き

41 共有鍵暗号方式 一つの鍵を暗号化，復号化の両方に同一の鍵を利用する
一番初めに，対象クライアントへ，どのようにして『安全』に『確実』に鍵を渡すかが重要 鍵のやり取りの時に，鍵を傍受されるとその後の通信や，同一の鍵を利用しているシステム全てが危険にさらされる

42 共有鍵か公開鍵か？ やり取りの難しい共有鍵方式よりも公開鍵方式があれば，それで十分ではないか？ ビット数問題 計算速度問題
必要十分ビット数が大きい 共有鍵方式と同等の強度を得る場合，場合の数倍～十数倍程度のビット数が必要になる 計算速度問題 公開鍵暗号化方式のほうが計算量が多い 弱いCPUの場合，実用に耐え得ないことが多い 現在は，一番初めのみ，公開鍵暗号で共有鍵を送り，以後は共有鍵方式を利用することが多い

43 RFID 小型無線ICタグのこと 小さいものは1cm平方程度であり， 非常に小さい
今後はありとあらゆるものに付加されていくのでは？と考えられている 方式には大きく分けると下記の二つがある 外部から電波を受けて発生する電界から電気を生み出し，電池なしで動くパッシブ形 自身が電池などを保持し，電波を発生させるアクティブ型

44 パッシブタグ 利点 欠点 利用場面 非常に小さく，薄い 電池が要らないため，ほぼ無期限に稼動
電界に対して正確に決められた方向を向かないと反応しないため，誤動作が起きにくい 欠点 電波の届く範囲が狭い （およそ１ｍ, 遠距離専用でも最大10m程度） 電界に対して正対しないと反応してくれない 利用場面 電子バーコード，機材管理

45 アクティブタグ 利点 欠点 利用場面 電池を搭載しているため，遠距離でも通信が出来る 電界の向きに関係しない
電池の寿命がタグの寿命になる （1月～1年程度が普通） 利用場面 ユーザに配布して，ユーザの位置情報を取得する 店舗内での，物の場所を知るなど

46 セキュアOS セキュリティの高いOSに対する総称だったが，現在ではセキュアOS研究会によって，最低限下記の二点を持つもの定義がされている
MAC（強制アクセス制御） リソース（ファイル，IO，etc）へのアクセス権をセキュリティ管理者以外が変更できなくするもの たとえ，リソース保持者であってもアクセス権の変更は行えない 最小特権 普通，管理者が保持する無数の特権を，A プログラム実行権，ファイルアクセス権などに分け，プロセスやサーバソフトなどに個別に付与する仕組み たとえ，同じ管理者が実行している場合においても，各プロセスが保持している権限は異なる

47 リアルタイムOS 処理を特定の時間内で処理することを確約しているOS
WindowsやLinuxなどは出来る限り処理を早く実行するが，リアルタイムOSでは，特定時間以内に終了しない動作は実行を許可しない 電話やロボットなど，特定時間内に処理が終了することを要求されるものに搭載されることが多い 代表例：TRON

48 グリッドコンピューティング ネットワークを介して複数のコンピュータを結ぶことで仮想的に高性能コンピュータを作る手法
空いているマシンのCPUパワーを並列的に利用して，大規模演算を実行する ひょっとしたら，夜中の大学では流体力学計算などがされているのかもしれない