今月は、前回示したセキュリティ・ポリシーに従って、 ては、できるかぎり抽幻勺に主しておく」と説明しまし FWTK ファイアウォールの、、セキュリティ・プラン " を たが、セキュリティ・プランではホストやプログラムなど 作成します。そして、 FWTK の設定と重川御裔忍をおこな の具イ勺な名称をどんどん書きます。そのセキュリティ・ うための工竟を作り、プログラムを起動してみます。いや プランに従ってイ 1 璞を進めれは、誰が作っても同しファイ あ、どきどきしますね ( せーへん、せーへん ) 。 アウォールができるくらい日寉に書きます。 以降では、 FWTK を用いたファイアウォールのセキュ - セキュリティ・プラン リティ・プランの例を紹介します。 いよいよファイアウォールを本翻勺に構築していくわけ どこに設置するか ですが、その前に、もうすこし考えなければならないこと 誰の机の上に置こうとか、どのラックに入れようとか があります。 いうことではありません。ネットワーク的な位置のことで 「前回、考えすぎて、もう頭がヘろへろやがな」 す。 まあまあ、そう言わすに。もうすこしだけ・・ ます、ホスト名やサーバー名を列挙し、ファイアウォー ます、ネットワークとファイアウォールの完成予想図 ルで、、守るもの " と、、守らないもの " を明確に区別します。 を描きます。そして、その完成予想図が本来の目的を寒見 言 t 算機は、ファイアウォールの内部ネットワークに接続す するために適しているか、かっセキュリティ・ポリシーに るグループと、外部ネットワークに接続するグループに分 沿ったものかを詔面しましよう。この竹喋を怠ると、効果 か 2 つのネットワークカそきるはすです。そして、そ 的なファイアウォールか構築できない ( 穴のあるファイア の 2 つのネットワークに FWTK のファイアウォール・ ウォールを作ってしまう ) 可能性があります。次に、現在 ホストを接続します。 のネットワークの状態を正確に把握し、ファイアウォー こでは、次の 2 つの点に注意してください。 ルの完成にいたるまでの作業引 1 画を立てます。これを怠る と、時間や労力を馮置いしてしまうかもしれません。 1. 組織内のユーサーにサーピスを提供するサーバーと外部 作りながら、、ここはこうしたらええんかな " などと考え のユーサーにサービスを提供するサーバーは、同一の計 たり、、、やつばり、ああしとかなあかんのやろか・ 算機十で運 . 用すべきではありません。このような運用形 迷いながら作っていると、たいして効果のないファイア 態はたいへん危険です。内部サービス用のサーバーは内 ウォールを作ってしまったり、竹喋の効率か落ちてしま 部ネットワークに接続する計算機上で、外部サーピス用 います。 ーは外部ネットワークに接続する計算機上 . で、 のサーノヾ このようなことを防ぐために、セキュリティ・プラン というように別々に運用します。たとえば、個人の机 ( ファイアウォールの構築引測 ) を作ります。前回とりあ の上にある日常作業用の言 t 算機で Web サーバーを運 げたセキュリティ・ポリシーでは、「ホスト名などについ 用し、これを組織外に公開しているような場合は、この ファイアウォールの作り方 白崎博生 17 UNIX MAGAZINE 1998.3

連載 UNIX Communication Notes ・管理竹喫に伺髄するイ 1 璞 ( 竹業報告など ) にはどのよう なものがあるか 誰が作成するか 管理ポリシーは、基本的にネットワーク環竟に関連のあ るすべての人が受け容れられるものでなくてはならない。 したがって、その作成にあたっては、さまざまな立場の人 びとの協力を得るべきである。たとえは、ネットワーク管 理者の都合だけを優先して、 「サーバーの管理作業は毎週月曜日の午前中におこなう」 と決めたとしても、毎週月曜日にサーバーが使えないので は、ユーザーから不の声が上がるのは必至である。 「管理竹璞に必喫な機材は速やかに購入する」 というポリシーを決めても、予算の決定、執行に責任をも つ管理耳祠意しなければ、とうてい実現できない。 したがって、さきほども述べたように、すくなくとも ューサーとネットワーク管理者、管工叫哉といった立場の人 たちが協力して作成すべきであろう。 里ポリシーの書き方 ネットワーク竟の規模、構成や、組織によっていろ いろな書き方があるだろう。管理ポリシーの書き方には、 ・・でなけれはならない " というルールはない。ただし、 以下に述べるようにいくつかの点に注意する必喫がある。 1. 書けることから書く 最初から完璧なものを作ろうとしても、なかなか思いど おりには書けないものである。管理するネットワークの 莫が大きければ大きいほど、検詞すべき項目は多くな るので、なおさらである。それに、完璧さを目孑尉 - あま り、いつまで経っても管理ポリシーができないのでは本 未転倒であろう。 誰もカ断等できる必要なことから順次言当していけは、 竹喋もスムースに進むはすである。とりあえす全体を書 き上げて、多くの人たちの意見を参考にしながら、必要 に応して追加したり、削除したりするのがいいだろう。 このような段階的な手順を踏めば、管理ポリシーの質を 上げることかでき、同時に多くの人たちの意見を央す ることもできる。 14 2. システムやネットワークの構成か変化しても、できるか ぎり変更が少ないような言当主を心掛ける たとえば、システム構成を示す具一勺な製品名やソフト ウェアのバージョン、管理者の名前などを書き入れて しまうと、なんらかの変更が生しるたびに書き換えなけ れはならなくなる。管理ポリシーは、いかなる立場であ れ、ネットワークエ竟にかかわるすべての人にとって、 管理に関する考え方の本罇余をなすものである。したがっ て、ネットワーク環竟にかかわりのあるすべての人に正 しく理解されるようにしなけれはならない。しかし、管 理ポリシーか頻繁に変更されるようではなかなか理解は 得られないだろう。 したがって、システム、ネットワーク、ソフトウェア などか変史されても、管理ポリシーの書換えが少なくて すむ記にすべきである。かといって、書換え箇所が少 なくなるようにと、あまりに抽象的に言当すると、わけ の分からない莫早なものになってしまうので、適度の具 体性も必要である。 3. 将来の変更も視野に入れる といった管理ポリシーを掲げることは理にかなってい しないこと」 「各ューザーは、作成したファイルをできるかぎり放置 用するワークステーションについて、 ることも必要になる。たとえば、大学の研究室て共同利 ときには、管理ポリシーにユーザーの努力目標を言己す 4. 実現 - 可能なことを言当主する るおそれがある。 れなかったり、主内容があまりに古くて役立たなくな ある。変更しにくくすると、現実の竟との整合性がと えて、管理ポリシーを変更できるようにしておくべきで シーも書き換えなけれはならない。このような事態に備 ムやネットワークが大きく変わった場合は、管理ポリ しないように努力したとしても、管理対象であるシステ は作るべきではない。たとえば、できるかぎり変更が生 いったん決めたら、二度と変えられないようなルール ステーションはほとんど使われなくなってしまう。努 というような極端なポリシーを設定すると、そのワーク 「各ューサーは、ファイルを作成してはならない」 る。しかし、 UNIX MAGAZINE 1998.3

画像や音声情報などのマルチメディア がネットワーク上でやり取りされるよう になったため、ネットワーク上のトラフ ィックは飛躍的に増大し、高速ネットワ ークの必要性は高まるばかりです。増 大・複雑化するトラフィックに対応する ための様々なソリューションが登場して ■高速ネットワークに対応 するソリューション います ATM ネットワークカードに は 622bps の製品も登場 ATM(AsynchronousTransferMode) の技術はもともと WAN ideA 「 ea Net work 、広士同 ) においてマルチメ ティアサーヒスを提供する B - ISDN ( B 「 0 a s b a n d a s p e c t s 0 f ー SDN 、 広帯域 S D N) サービスを実現するため ロ T U - T で標準化されました。これを 企業やキャンパスネットワークの L A N ( Local A 「 e a N e t w 0 r k ) で利用 するために T h e A T M Fo 「 u m で T M L A N の規格の標準化か進められています。 T h e ATM Foru m カ琺見定しているイン ターフェースには通信事業者が提供する公 衆網の A T M スイッチとユーザの A T M ス イッチを相互接続するバブリック U N Ⅱ P ubli c Use 「 - N e t w 0 「 k t e 「 f a c e ) や AT M スイッチと AT M ポ ードを内蔵したコンビュータを相互接続する ためのプライベート U N Ⅱ P r i v a t e Ca 第① U se r - t'&t w 0 「 k t e r f a c e ) 、 ATM インターフェースを持たないルータなどの装 置を ATM - LAN と接続するための ATM - D X Ⅱ A T M D a t a e X c h a n g e ー n t e 「 f a c e ) などがあります。このう ちプライベート U N ーの伝送速度は 2 5 M b p s 、 5 2 M b p s 、 1 0 0 M b p s 1 5 6 M b p s 、 6 2 2 M b p s となっていま す。 AT M ネットワークと既存の L A N を接 続するために規定しているのカエ A N 工ミュ レーション ( LLANE) と一 P over ATM で す。 LAN 工ミュレーションは MAC アドレス を A T M アドレスに変換する方式です P overATM'tl P を ATM ネットワークで扱 えるように一 P バケットを ATM セルに一 P アド レスを AT M アドレスに変換する方式です。 A T M - L A N は高速バックポーンを構 築するソリューションの一つです。コン ピュータに内蔵する ATM ネットワークカ ード ( N ー C ) は現在は 1 5 5 M b p s の製 品が主流ですが 62 2 M b p s の製品も 登場しています。 朝れ 3. Copyr«htCANON コ 996-1 的 7 AII Rghts R ・当物・′ ed. カルにできるなど豊富な機能を持つ。 PX 、 Appl eTa ー k などの設定が PC 上でグラフィ 紙切れやトナーの容量不足、 TCP/I P 、一 PX/S 管理やプリンタ管理を統一的にマネージメント。用 されているすべてのプリンタに対してネットワーク 従来の双方向通信とは異なり、ネットワークに接続 ネットワークプリンタのマネージメントソフト。 ■キヤノン販売 NetSpot を NetSpot ー管理者モード テシゞイス ( 0 ) 表示 ) 設定 ) ヘルア但 ) 6 個のテ。イス L ー 930 NetHawk W—LS k F—LS EO . SEONet Mt 〕〔に L605 工 VI .51 ( 6050 ) LBP—740 、 - に CT C ー 550 〕刊正 - F L 日 P -7 託ー 弋 H ョ F—LS 同ロ

ーレの ハードウェア障害への対応 り Telnet 、 rlog ⅲ、 FTP などのプロキシー・サービスを ューサーごとに制限する場合は、 FWTK のプロキシー サーバーに接続したときにユーサー認証をおこなうように 設定します。つまり、 FWTK のアカウントはプロキシー サービスの利用を許可するユーサーに与えます。ただし、 計算機やネットワークを単位としてユーザー認証を省略す ることもできます。たとえば、ファイアウォール内部の計 算機から外部の言算櫞、は誰でも TeInet できるが、外部 から内部へは FWTK のアカウントをもつューザーしか できないといった設定が可能です。 こでは、アクセスポリシー ( 2 月号 53 ページ参照 ) に 従ってアカウントを発行するユーサーをリストアップし、 それぞれのログイン名とアカウントの不頁を決めます。 アカウントの発行は厳しく制限すべきです。正当な理由 をもつューザーに対してのみ発行し、そのアカウントには 必要最小限の権限を与えます。さらに、アカウントの発行 状況 ( 現在、誰がアカウントをもっているか ) をつねに把 握しておかねばなりません。 UNIX のアカウントと FWTK のアカウントの違いを 正しく理解し、日用寉に区別して発行してください。そして、 イ腰になったアカウントは速やかに削除します。 意 1 アカウントを 1 つ発行するごとに、セキュリティ・ホール も 1 つ増えると考えるべきです。いくら万全と思われるセキュ リティ対策を施しても、推測しやすいパスワードを設定すると いったユーサーの不注意によって侵入される危険性は無見でき ません。 1 つのアカウントが 1 つの不注意に、 1 つの主意が 1 つのセキュリティ・ホールにつながる、と肝に銘しておきま しよう。 FWTK のアカウントは、プロキシー・サーバーの利用 を許可したユーサーに対して発行します。このときのユー サー認証のガ去は、認証ポリシー ( 2 月号 54 ページ参照 ) に従って決定します。そして、 FWTK のアカウントをも っューザーには、ネットワーク上での盜聴の危険性を寸分 に理解してもらいましよう。 UNIX のアカウントは、ファイアウォールを管理する ューサーに対して発行します。このときのユーサー認証の ガ去も認証ポリシーに従って決定します。 UNIX のアカ ウントの発行はとくに厳しく制限すべきであり、 FWTK ( び青通したユーザーだけに限定したはうがいいでしよう。 UNIX MAGAZINE 1998.3 ファイアウォールのサーピス停止は、困った事態を惹 き起こします。ファイアウォールの内部ネットワークが、 外部のネットワークから遮断されてしまうのです。 「ネットワークカ砌れたら、侵入者は入ってこれへんし、 これでセキュリティは元璧や」 間違っても、そんな言い逃れをしてはいけません。袋叩 きに遭います。 そこで、可能なかぎり矢可間て復旧できるように、交換 用部品を備えたり、ハードディスクのバックアップをと るスケジュールなどを決めておきます。もちろん、スケ ジュールに沿って実行することが大切なのはいうまでもあ りません。 電子メールの中継 ファイアウォールの内部から外部へあるいはその逆に 外部から内部へのメール中継を許可する場合は、 FWTK の smap と smapd を利用します ( これらのプログラムに ついては、いすれ説明します ) 。 外部から内部の計算機へのメールは、すべてファイア ウォール・ホストに酉己医するように設定します。これは、 DNS の MX レコードや系目系哉のメールサーノヾーの成疋ファ イル (sendmail.cf など ) を適切に設定することで実現で きます。このとき、系騰哉のネットワーク管理者に変更許可 をもらうのはもちろん、変更予定日も正しく伝えておきま しよう。次に、ファイアウォール内部のユーザーのメー ルをスプールするためのメールスプール・サーバーを構築 します。サーバーにする計算機を選び、メールのスプール サーピスを提供するための設定をおこないます。 ファイアウォールの内部から外部へのメール中継は許可 するが、外部から内部へのメール中継は許可しない場合、 内部のユーサーがメールを読む手段を提供する手だてを考 えなけれはなりません。これには、次のようなガ去があり ます。 ・ファイアウォール内部から外部のメールサーバーに対し て POP でアクセスする。 ・ファイアウォール外部のメールサーバーにログインす る。 19

連載 UNIX Communication Notes— 1 1 7 つまり、今日のネットワーク管理者は、以下のような業 務をおこなうことを求められている。 ・ UNIX マシンからノヾーソナル・コンピュータまで、多 様なシステムを管理対象とする。 ・急増する管理豫の機器を把屋し、十分な管理をおこな わなけれはならない。 ・ネットワーク環境を前提とした業務か増えたため、ネッ トワークを安定的かっ安全に運用しなければならない。 ・ネットワーク・ユーサーか技ヤ勺な知識を有することを 前提とした管理はできない。これは、前述のようにコン ヒュータやネットワーク技術に疎いユーサーが急増して いるからである。 このような状況の変化にともない、ネットワーク管理者 カリ用する技術も大きく変わり始めている。そこで、今回 から数回にわたり、ネットワーク管理に関するツールや手 ネットワーク管理とは 法を紹介していく。 さらに、ネットワーク管理にともなうイ 1 璞を、次の 5 つ に、ネットワークの状態を糸財寺する作業」 「接続されているシステムカ財は圧に円滑に通信できるよう ワーク管理の定義が一化した。 準化か積極的に進めらその過程で次のようなネット 1980 年 ( 鷺変半からは、ネットワーク管理プロトコルの標 理についてさまざまなアイデアを提案してきた。とくに これまでに、多くの研究者・技術者がネットワーク管 従来のネットワーク管理 ます、ネットワーク管理とは何かを考えてみよう。 のカテゴリーにう頁した。 UNIX MAGAZINE 1998.3 ト転送レートやエラー発生回数などのデータを収集し、 ルータやスイッチなどのネットワーク機器から、バケッ 的には、以下のような作業が含まれる。 く機能するように機器を設定・管理するイ 1 喋である。具体 ネットワークの運用状態を把握し、ネットワークが正し ( 1 ) 里 (configuration management) ネットワークの運用状態を孑当屋する竹業 ( ー搬に、、モニ タリング (monitoring)" と呼ばれる ) 収集したデータにもとづくネットワーク構成の最適化 ( ネットワークの利用目的によって、最商化の対象は異 なる ) 収集したデータにもとづくレポートの作成 ( 2 ) 障害褌里 (fault management) ネットワークで発生した障害の原因を特定し、その障害 を除去する竹璞である。障書カ起きると、ネットワーク管 理者は、 ・発生した障の原因ク寺定 ・ネットワーク内のほかの部分に景彡響を莎えないように、 障害の原因となっている部分をう隹する ・障書の原因の除去 といった竹業をおこない、通常のネットワーク運用状態に 回復させる。、、ネットワーク管理 " と聞いて多くの人が田 い浮かべるのはこの「ド業であろう。 ( 3 ) 性能里 (performance management) 管理しているネットワークにおいて、ネットワークの設 言判に目標とした性能が達成されているかどうかを調べ、 間題があれは必要な対策を講しる。これには、次のような 作業がある。 ・ネットワーク機器のバケット処理数などのモニタリング による、ネットワークの利用率やエラー率の訓 ・ネットワークへの負荷が : 則値より高くないか、エラー 率か高くなりすぎていないかク寉認 ・ネットワーク言 11 こ想定していたスルーブットなどの 性能が、達成できているかの石忍 ・ネットワーク性能が目標値を一 FI 可っていた場合、改善策 を検帋ける。さらに、その有効性をシミュレーションや システム角財斤によって確認 ( 4 ) アカウント褌里 (account management) ューサーが適正にネットワークを使うために必要な管理 である。具ー勺には、次のような作業がある。 ・ネットワーク資源の利用状況に関する情報の収集 ・必要に応してネットワークの利用制限を実施 ( 特定の ューサーやシステムによるネットワークの濫用を防ぎ、 11

UNIX Communication Notes 山口英 ネントワーク管理 ネットワーク管理の変遷 10 年はど前は、ネットワークといっても数台の UNIX ワークステーションと Ethernet からなる LAN がーイ殳 的であった。当時のネットワーク管理にかかわる竹喋は、 JUNET の UUCP 接続を安定的に糸早し、電子メール と USENET ニュースの酉占医に目を光らせる程度であっ た。多くの UNIX ワークステーションは、はばスタンド アローン状態で漣用されており、ネットワークに依存する 度合いはきわめて低かった。 1980 年代末になると、 NFS によるディスクや NIS ( 当 時は (P) によるアカウントの共有が一ヨ殳化した。これに ともない、ネットワーク管理者の仕事に NFS サーバー のディスクの保守や、 NFS クライアント側でのマウント ポイントの管理、 NIS によるアカウント管理などか加わっ た。さらに、ネットワーク経由でのプリンタの共有が一 - ー - ・ 掬難勺になり、プリンタスプールの設定やフィルタの整備と いった仕事も重視され始めた。とはいえ、ネットワークは 現在とくらべるとごく小規模で、少数の管理者でも十分に 対応できた。 ところが 1990 年代に入ると、ネットワーク管理者の仕 事が急激に増加した。その要因の 1 つは、多くの大学での キャンパス・ネットワークの整備や、企業における糸目織 内ネットワークの整備が急に進み、さらにインターネッ ト接続がひろく普及したからである。ネットワーク管理者 は、 UNIX システムだけではなく、ルータなどのネット ワーク機器も管理する必要に迫られた。なかでも経路缶リ御 は重要な業務となり、ネットワーク運用の安定性か強く求 10 められるようになった。 1990 年代半はになると、大きな変化か起きる。 Win- dows 95/NT や Macintosh などのネットワーク機能を もつパーソナル・コンピュータの大量導入である。これに よって、ネットワーク管理者にとっては頭の痛い問題が生 した。 1 つは、管理対象の大幅な増加である。それまでの ネットワークでは、接続されているコンピュータの大部分 は UNIX システムであり、管理業務の大半は UNIX を 対象としたものであった。しかし、上記のパーソナル・コ ンヒュータ群の導入により、これらのシステムに特有な管 理のノウハウも習得しなければならなくなった。接続され る機器の台数も急激に増加している。たとえは、 100 台以 上のシステムカ甘妾続されているネットワークを 1 人で管理 するといったことが、現在では当然のようにおこなわれて いる。 もう 1 つの間題は、ネットワークよューサーの質の変 化である。それまでのネットワーク・ユーザーは、コン ピュータ関連の技術者・研究者がはとんどで、その多くは コンピュータやネットワークの基礎知識をもっていた。し たがって、ユーサーにみすから問題を鮹夬しようという姿 勢があり、彼ら自身がネットワーク管理の能力をもってい ることもしばしばであった。しかし、 1990 年代の半ば以 降は、ネットワークやコンピュータ技術に関する知識のな い人がシステムやネットワークを利用する状況が一鍛化し つつある。 去も匠は、セキュリティというさらに頭の痛い間題も生じ ている。現在のインターネットでは、システムに対する不 正アクセスや、情報の漏洩などへのセキュリティ対策をい かに施すかが重要な課題となってきた。そして、さまざま なセキュリティ間題に対処するために、新たな技術か積極 的に導入されつつある。 UNIX MAGAZINE 1998.3

連載 FreeBSD/—トー⑩ fxp0" は、 lntel の Fast Ethernet カード EtherEx- press Pro 100 / B である。、、 1 。 0 " は自分自身にデータが 返ってくるルーフ。バック・デバイスで、対応するハード ウェアをもたす、データはカーネル内だけて処理される。 受け取ったデータは、それぞれのデバイスからカーネル 内の仕分け処理を経てポート番号が対応するソケットのあ るプログラムに渡る。 ネットワークの場合はこのようにカーネルがデータの仕 分けを制御するので、プログラムは自分の利用するデバイ スをとくに意識する必要がない。 ただし、ネットワーク・テンヾイスから滷鮟ネットワーク のデータを読み書きする bpf (BerkeIey Packet Filter) は例外である。 bpf は、ネットワークに流れているデータ を監視する tcpdump のようなプログラムて利用されてい る。 bpf はそれ自体疑イ勺なデバイスドライバとして働 き、それぞれのネットワーク・デバイスに設けられた特殊 な出入り口を通じてデータをやりとりすることかできる。 また、 FreeBSD 標準の PPP ドライバ iij-ppp はユ ーサープロセスとして働くが、カーネル外にある未なネ ットワーク・デバイスと考えることかできる。カーネル内 とのデータのやりとりにはトンネルデバイス (/dev/tun0 など ) と呼はれる孑鬮以デバイスを利用する。これにより、 シリアル・インターフェイスにつないだモデムや、場合 によっては既存のネットワーク接続を利用して、 2 点間の ネットワーク接続を : 見することができる。 BSD カーネルのネットワークまわりがこのような特殊 な構造になっているのは歴史的な事清による。 SystemV 系の UNIX では、テンヾイスまわりには STREAMS とい う冫冓か広く採り入れられている。ネットワーク・デバ イスは特別扱いされていない。 STREAMS には、さまざ まなレベルのモジュールを層状に組み合わせて処理がおこ なえるという目立った特徴があり、ネットワーク・デバ イスを自然に扱うことができる。ネットワークに関する処 理は、ユーサーレベルのライプラリと、上層に位置するモ ジュールがおこなっている。 単純な上交では、 STREAMS のような機構のはうが先 練されているといえるだろう。 BSD のネットワークのデ バイスドライバをいじっていると、処理のレベルの切分け がはっきりしない部分があるのに気づく。たとえば、個々 のデバイスドライバて処理しなくてもいいはすの共通の部 80 分までコードに含まれるといったことだ。また、 TCP/IP のほか IPX や AppIeTaIk といったプロトコルによる切 分けにも判然としない部分がある。こうした事のため、 BSD のネットワーク・ドライバは理解しづらい。 FreeBSD では、 BSD の世界で継承されてきたコード の堅実性を尊重しながらすこしすっ改良を加えているのが 朋大である。このように、古いものと新しいものとのバラ ンスをとりながら実用性の高いものを作っていくところに FreeBSD の特色があるといえるかもしれない。 もちろん、これには限界がある。たとえは、現状では ネットワーク・デバイスを取り外したときの処理をおこ なうコードを追加するのはかなり面倒である。きちんとモ ジュール化された層 : 伏の構成ならば自然に決まる、どのレ ベルでどのように変化を伝えていくかといったことか明確 になっていないからである。 BSD はもともと重加勺に構成が変化する場合を前提に設 計されていないので仕方がないとはいえ、今後モバイル・ コンヒューティングなどへの本勺な対応が必要となるの でなんとかしたいところである。 ネットワーク・デバイスを STREAMS として扱うの はきれいにみえる。しかし Solaris 2.6 では、ネットワー クまわりは STREAMS では扱わなくなった。やはりな んらかの理由があるのだろう。 テータの流れ 次に、データの流れという観点からデバイスドライバを 眺めてみることにしよう。基本的な部分はネットワーク・ デバイスでもそオ LJ ユ外でも同しである。 ます、データの流れは出力と入力とに分けることかて、き る。ごく単純化すると、デバイスドライバはカーネルから の出力をデバイスに、デバイスからの出力をカーネルに渡 せばよいことになる。 現実には、デバイスへのアクセスは物理的な牛に左右 されるので、カーネルが必要としているときにタイミング よく入出力がおこなえるとはかぎらない。そこで、両者の あいだのタイミングを調整することが必要になる。 例として Ethernet を考えてみよう。 Ethernet の帯域 は毎秒 10Mbit と決まっている。さらに、他のマシンが 送信していることを検出すると送信できないなど、さまざ まな制約がある。一方、カーネルはそれよりもはるかに速 UNIX MAGAZINE 1998.3

連載 UNIX Communication Notes—・ への安全なアクセスを実現している。さらに、個人に対 のような環境では、証明書を発行する CA の管理・運 ロ 0 、・一 クセスを効果的に制限するイ督はみか利用され始めた た証明書を発行し、各種ネットワーク・サーピスへのア 先端的なネットワーク竟では、公開音号技術を用い CA (Certificate Authority) の運用 視されている。 増えたため、安全生の高い Web サーバーの運用は当然 内ネットワークでは、 Web システムに依拠した業務が アクセス管理も実現できるようになった。去も匠の組織 して暗号技術を利用した証明書を発行することにより、 ( 9 ) ユーサー竟備 用も管理竹喋の範疇に含まれる。 うかという引を立てるのもネットワーク管理者の仕事で 何を知識として教え、どのように教育・啓発活動をおこな キュリティ上の問題発生を防止する効果がある。具ー勺に リケーションの謝巣作によるトラブルの発生あるいはセ くる。技術に疎いユーサーか起こしがちな、ツールやアプ でのセキュリティ意識を高める啓発活動も重要になって 用するために必要な知識に関する教育や、ユーサーレベル システムやネットワークが複雑化すると、これらを利 ( 10 ) ユーサー育と啓発 る。 ューザーの謝巣作によるトラブルを防止する意味合いもあ ある。セキュリティ保全の意味からも重要な作業であり、 ワーク・ユーサーか業務に専じ、できるような竟の構築で うにする設定などの作業がある。基本は、これらのネット るいは、業務には不要なアプリケーション群を使えないよ ステムのセットアッフ。や業務に必要なツールの確保、あ ク管理者の仕事である。これには、ユーサーの利用するシ 務でネットワークを使うューサーの環境整備もネットワー コンピュータ技術者やネットワーク研究者ではない、業 管理ポリシーの策定 ある。 UNIX MAGAZINE 1998.3 ment policy) の作成である。 初に着手しなければならないのカ理ポリシー (manage- こまでに述べたネットワーク管理をおこなう場合、最 管理ポリシーとは、管理対象のシステムやネットワーク 竟をいかに管理するかを明確に規定した方針である。作 成にあたっては、どのような管理作業が必要か、そして、 竹喋をいかに進めるかを明記する必要がある。さらに、ネ ットワーク管理者だけではなく、管理に必要なコストの負 担についての決定権をもつ管理ネットワークを利用す るユーザーの三者が協力して作成すべきである。作成した 管理ポリシーについては、管理ネットワーク管理者、 ューサーか 1 司意し、かっ、それを遵守するという合意を得 なけれはならない。 管理対象の機器が数台しかなく、ネットワークも単一 の Ethernet セグメントだけからなるような小規模なネ ットワーク環竟では、厳格なポリシーは不要と思われるか もしれない。しかし、その竟て暮らす人か複数いるのな ら、その工竟をどのように管理するかの方針、すなわち管 理ポリシーを決定し、利用者全員がその方針に従うように したはうがよい。それによって、管理作業の抜け落ちを防 ぎ、ユーザーにとって使いやすい環境カ辭財寺できるように なる。 一方、大莫なネットワーク竟では、管理竹喋に複数 の人間か従事するのか普通である。このような場合、管理 ポリシーを作成しておけは、各ネットワーク管理者が商切 な竹喋をしているか、一 - ト・分な管理竹喋がおこなわれている かといった点について、つねにポリシーに照らして考える ことができる。逆に、このような管理ポリシーがないと、 ネットワーク管理者ごとに作業の質・量がは・らついたり、 必要な作業カ皺け落ちた管珊本制を作ってしまうことがあ る。 このように、規模の大小にかかわらす、管理ポリシーの 作成は必頭の要件といえるだろう。 管理ポリシーの内容 管理ポリシーでは、すくなくとも次のような要素につい て具イ勺に言己主すべきである。 ・何を管理豫とするか ・どのような管理作業をおこなうか 管理竹喋の担当者、責任者は誰か ・トラブルが発生した際に、どのような手順で対応するか ・どこまでがユーザーの責イ嘛囲か 13

リスト 1 ネットワーク・インターフェイスの (a) FreeBSD ・ /etc/sysconfig の変更例 network_interfaces="edO edl 100 ” ifconfig—edO=" inet 192.168.1.100 netmask ifconfig—edl=" inet 192.168.255.1 netmask ifconfig—IoO=" inet localhost" defau1trouter="192. 168.1. 1 ” (b) BSD/OS 2.1 : /etc/netstart の変更例 255.255.255.0 " 255.255.255 . 0 ←使用するネットワーク・インターフェイスのリスト ←外側の IP アドレスとネットマスク ←内側の IP アドレスとネットマスク ( 追加 ) ← - ノレーフ。ノヾック iface=neO ipaddr=192.168.1.100 1 inkarg= " netmask = 255.255.255.0 defroute = 192.168.1. 1 ←外側のネットワーク・インターフェイス ← neO の IP アドレス ←デフォルトルート ← ne0 のネットマスク ← neO インターフェイスのリンクパラメータ # P1ace configuration commands for additional interfaces above , # before the loopback interface is configured. ifconfig nel inet 192.168.255.1 netmask 255.255.255.0 (c) BSD/OS 3.1 : /etc/netstart の変更例 ←内側の IP アドレスとネットマスク ( 追加 ) interfaces="neO pr imary= " neO " defroute="192. 168. 1 . 1 " # neO: ipaddr—neO="192.168.1.100 " netmask_neO="255.255.255.0 " 1 inkarg—neO= additiona1_neO= # ne 1 : ipaddr-ne1="192.168.255.1 " netmask ー nel = " 255.255.255.0 ” linkarg—nel= additional_nel= 使用するネットワーク・インターフェイスのリスト ←外側のネットワーク・インターフェイス ← nel インターフェイスのノ、ラメータ ← nel のネットマスク ← nel の IP アドレス ← ne0 インターフェイスのノヾラメータ ← neO のネットマスク ← neO の IP アドレス ←デフォルトルート 目で OS をインストールしたときに割り当てたアドレス 192.168.1.100 を neO に設定しています。このインター フェイス (ne0) は、変ファイアウォールの、、外側のネッ トワーク " として設定イ乍業をおこないます。デフォルトル ートも、同様に OS のインストール時に設定したアドレス です。ホスト名は、、 sugar. raccoon. doubutsu. co. jp に 変更しました。 前回インストールした 2 枚目のネットワーク・カード ( インターフェイス nel) に IP アドレス 192.168.255.1 を割り当て、今後はファイアウォールの、、内側のネッ トワーク " として設定作業をおこないます。もちろん、 192.168.255.0 / 24 がサイト内のほかのネットワークで使 22 用されていないことか前提です。 FreeBSD では ( リスト 1 ー a ) 、 network-interfaces のエントリで、 1 枚目のネットワーク・カードとループ バック (loopback) のインターフェイス名か轂定されて いるリストに 2 枚目のネットワーク・カードのインター フェイス名を追加します。そして、 1 つ目のネットワー ク・インターフェイスのアドレスの聢と同様に、 2 つ目 のネットワーク・インターフェイスの設定を追加します。 BSD/OS 2.1 では ( リスト 1 ー b ) 、すでに iface のエン トリに 1 枚目のネットワーク・カードのインターフェイス 名が、そして ipaddr 、 linkarg 、 netmask の各工ント リに、インターフェイスに割り当てた IP アドレス、リン UNIX MAGAZINE 1998.3

連載 UNIX Communication Notes そ也の注意事項 管理ポリシーとそれに合わせたガイドラインを作成した ら、残るのは実施だけである。ポリシーとガイドラインに 沿って管理竹璞をおこなう場合は、次のような点に注意す べきである。 ・どのようなかたちであガイドラインどおりに管理作 業がおこなわれているかどうかを石忍する手段を定めて おく必要がある。たとえは、管理者グルーフ。内で定期的 にミーティングを開き、柤にチェックする体制を作 ってもよい。大莫な管理グループの場合は、管理竹喋 を石忍する担当者を設けたほうがよい。さらに、障害復 旧のための手順などについて定期的に石忍するのも重要 だ。定められたイ乍喋を確実に実施するための仕掛けを考 える必要がある。 ・ネットワーク管理をおこなう過程で、ガイドラインに不 備があったり、管理ポリシーか大に合わないことカ吩 かったら、ガイドラインの改訂や管理ポリシーの変更を ためらってはならない。ホリシーやガイドラインをいっ たん作成すると、それを教条目三均に守ろうとする管理 者も多い。しかし、伏に合わないものを使い続けるの は不合理である。そのような状況が生したら、改善に向 けて積昀に努力すべきである。 ・教育・硎多 ネットワーク竟を利用するユーサーを対象として定期 的に硎多を実施する場合、各ューサーに硎タの参加を 義務つ財るように明記することもある。その場合には、 アカウント管理との整合性を保つようにじ掛けるべきで ある。 今日のネットワーク里の管理竹喋のなかでとくに重要 なのは、セキュリティ管理である。したがって、管理ポリ シーの作成と並行してセキュリティ・ポリシー ( どのよう にシステム / ネットワークを守るか ) の作成も進めるべき である。セキュリティ・ポリシーの作成方法については、 前号の「ファイアウォールの作り方」 [ 1 ] で詳細に解説さ れているので、参考にするとよいだろう。 管理ポリシーが決まったら 管理ポリシーを作成し、ネットワーク管理者とユーサ 、管理職の三者間で合意か得られたら、次は、管理ポリ シーを基礎として管理竹喋のガイドラインを作成する。 のガイドラインには、管理作業やイ乍業分担などを具ー勺に 当する。 ー搬に、ガイドラインは、ネットワーク管理者を対象と したイ乍業マニュアルとして言当する。このようなマニュア ◆ ルを用意しておけは、ネットワーク管理者がおこなう竹喋 今回は、ネットワーク環竟の急漣な拡大につれて変化し の手順か明確になるだけでなく、管理者が代わったときも てきたネットワーク管理作業の内容について述べさらに スムースに業務の移管かできる。マニュアルの作成は面倒 ネットワーク管理竹業の根幹をなす管理ポリシー、および ではあるが、作っておいて損はない。ネットワーク管理者 ポリシーとの整缶生を保ったガイドラインの作成ガ去につ か退職したとき、イ 1 璞ガイドライン ( マニュアル ) がなく、 前任者がどのような竹喋をしていたかがまったく把握でき いて説明した。 次回から、ネットワーク竟の管理に利用できる具イ勺 すに管理体制をゼロから作りなおすことはよくある。昔か な技術をとりあげ、その概要や導入ガ去などについて角見 ら、、、転ばぬ先の杖 " ともいう。このようなガイドライン する。 作成は、ネットワーク管理者に対して、、管理職 " の責任で ( やまぐち・すぐる奈良科 ! 物支術大完大学 ) 義務つ。けるべきである。 管理ポリシーの一墻 ; は、一ヨ殳のユーザーに対しても適用 [ 赭文献 ] される。これは、一殳ユーサーを対象とした、、システム利 [ 1 ] 白崎博生「ファイアウォールの作り方 ( 4 ) 」、 UNIX MAG- 用マニュアル " の一にとして言当すればよい。 AZINE 、 1998 年 2 月号 このように、ガイドラインの作成とは、管理ポリシーと の整合性を保ちながら管理作業の内容を具イ勺にして いくことである。 一三ロ 16 UNIX MAGAZINE 1998.3