AppleInsider: Mac OS X Leopard に向かって: ペアレンタルコントロールおよびディレクトリサービス

Mac OS X Leopard に向かって: ペアレンタルコントロールおよびディレクトリサービス

Published: Tuesday, October 23, 2007 10:05 AM EST

Mac OS X Leopard は、簡単に新しいことができるだけでなく、権限に応じて機能の制限もできるようになっている。家庭環境では、この機能はペアレンタルコントロールとして提供されている。ビジネス環境では、同じテクノロジが Managed Preferences を提供するために利用されており、子供ではなく従業員を対象とした実質的な制限およびガイドラインを設定するものだ。これは、製品のクライアント側およびサーバ側の両方にテクノロジを適用するというもうひとつの例で、Apple が新しい分野へと拡張するために、どのようにして自社のコアマーケットにおける自らの強みを梃にしているかを示すものだ。ここでは、同機能が Leopard および Leopard Server で機能するのか、その機能で何ができるのか、そして管理設定の背後にあるアイデア -- そしてそれらをサポートしているディレクトリサービス -- の出自について見ていこう。

このレポートは、管理設定およびペアレンタルコントロールの起源、歴史、そして成熟の過程にかなりのスペースを割いている。時間のない人、あるいは Leopard で予定されている機能に興味のある人は、本レポートのページ 3 へとジャンプされたい。

ネットワークディレクトリサービスの起源

コンピューティングの黎明期、クライアントユーザは中央のコンピューティングシステムについているターミナルで作業していた。これによって、ログインしているユーザに何ができるのかを簡単に管理できた。というのも、中央のコンピュータにアップデートを施せば、即座にアクセスを制限でき、簡単に接続ユーザをシステムから排除できたからだ。

Mac OS X Leopard Server に向かって: コラボレーション情報共有サービスにあるように、ミニコンピュータ用の Unix が開発されたことで、既存システムにあった規則の多くが、中央で権限が管理された複数ユーザをサポートする移植可能なオペレーティングシステムをビルドするために流用された。

80 年代にパーソナルコンピュータが登場すると、コンピューティングリソースが中央集権化されたモデルから分散化されたものへと移行し、シンプルなターミナルはより強力な PC に置き換えられ、ワークステーションシステムは独自に完結したコンピューティング環境を実行するようになった。この流れはまた、デバイスやアプリケーションの設定をはじめ、アクセス権限の管理といった作業を、一カ所ですべての作業を管理するのではなく、多数の独立したクライアントシステムへと分散化した。

分散設定ファイル管理: NIS

Unix ベースのワークステーションがシンプルなターミナルに置き換わるようになると、複雑なソフトウェアインストール管理のための労力が爆発的に増えることになった。ユーザおよびアプリケーション設定、アカウントパスワード、そしてネットワーク上の他のホストのアドレスは、すべて、システム上のテキストファイルで設定されていた。そのため、これら設定のいずれかにシステムワイドな変更を行うには、管理者が走り回って、すべてのシステムを手動でアップデートしなければならなかった。

単にネットワークに新しいクライアントシステムを一台追加するだけでも、その新しいシステムの設定だけでなく、そのネットワーク上の他のあらゆるシステムの設定を更新して、その新しいマシーンの存在とそのネットワークアドレスを認識できるようにする必要があった。

Sun は、クライアントシステム間で情報の更新を自動化するため、Yellow Pages と呼ばれるネットワークサービスを開発し、一所にいながら設置されているすべてのワークステーションへとテキスト設定ファイルを送り込めるようにした。 Sun は後にこのサービスを Network Information Service (ネットワークインフォメーションサービス) を表す NIS へと名称変更した。 Sun の NIS は、ネットワーク管理を大幅に簡素化し、他の Unix ベンダーにも瞬く間に採用された。しかし NIS は、信頼でき安全であるとみなすことができる内部ネットワークでの利用を主な目的としてビルドされていたことから、限られたセキュリティ機能しか提供していなかった。

分散名前管理 (Distributed Name Management): DNS

インターネットの到来がこうしたことすべてを変えた。というのも、コンピュータシステムは今や信頼できないホストに曝されることになったからだ。個々のシステムに向けて密かに悪意を持って設計された設定ファイルが送り込まれかねない広く開かれた環境のなかで、セキュリティ侵害の可能性は無視できないものとなった。インターネットはまた、ネットワーク設定を管理するのに必要な作業量を大幅に増やすことになった。というのも、企業内の数百台のシステムからの需要に応えるだけでなく、インターネットに接続している何千という企業も、自社の何千台とあるクライアントコンピュータとの間のトラフィックを管理するためのシステムを必要とするようになったからだった。

1983 年に Paul Mockapetris が Domain Name System を開発する以前、インターネットにつながっているコンピュータは、知っているすべてのシステムの名前およびネットワークアドレスをリストしたローカルな「Host ファイル」を持っていなければならなかった。パスワード、アプリケーション、そしてデバイス設定とちょうど同じように、これらテキストファイルは、ネットワークに変更が施されるたびに手動で更新する必要があった。 DNS は、インターネットユーザのためのこうしたアドレス関連の問題を、コンピュータの名前記録を中央管理するサーバの階層を設定することで解決した。

そうすればクライアントシステムは、必要なときにアドレス情報を DNS サーバに問い合わせることができる。 DNS 唯一の問題は、サーバに到達可能でなければならなかったことだ。つまり、到達できないと、コンピュータはアドレスを解決できず、ローカルの Host ファイルを参照しなければならなかったのだ。

自動設定およびアドレス参照: AppleTalk

1984 年 Apple は、AppleTalk と呼ばれるオリジナルの Macintosh のために自動化されたネットワークシステムを導入した。あるシステムがネットワークに接続されると、そのシステムは独自のアドレスを生成し、それが一意であることを確認する。また、ネットワーク上にある他のシステムを自動的に発見し、変更があるたびにそれを反映させた。つまり、Mac の管理者は、ローカルネットワーク上では NIS や DNS のようなサービスを管理して、ユーザがファイルサーバやプリンタサーバを見つけられるようにする必要はなかったのだ。

ローカルエリアネットワークに接続している PC は一般的に、Banyan Vines、Novell NetWare、あるいは Microsoft の LANManager を利用していたが、これらすべては AppleTalk とは異なり、DNS と同じように中央集権化されたサーバでネットワーク上の名前を管理する必要があった。 AppleTalk も DOS PC「Network Operating Systems」も、ローカルシステム間での基本的なファイル共有を超えたユーザ、アプリケーション、または設定項目の管理をするようには設計されておらず、いずれも独自のネットワークプロトコルを利用していた。これがために、80 年代に Unix システムの間で急速に普及したオープンなインターネットプロトコルを統合できないでいた。

これら以外のネットワークプロトコルはすべて、1996 年になると瞬く間に IP によって置き換えられていった。 Apple は自社の AppleShare サーバで同製品のネットワークプロトコルとして IP を利用するようになったものの、自動発見のために AppleTalk も継続して利用した。 Mac OS X では、AppleTalk はネットワークを閲覧するためだけに利用されていた。つまり、実際のサーバ接続は IP 越しに行われていたのだ。

1997 年 Apple は、AppleTalk の自動ネットワーク設定および名前解決機能を実装して、Multicast DNS および DNS-Service Discovery を利用する標準的な IP 上で動作するようにすると共に、同技術を Zeroconfig と呼ばれるオープンスタンダードとして提供し始めた。 Mac OS X 10.2 Jaguar では、これらの機能が Rendezvous、後に Bonjour という名称のもとでまとめて市場に送り出された。 Apple はまた Bonjour を Windows に移植し、他の Linux および他の Unix ライクなオペレーティングシステムで利用できるようににオープン仕様およびオープンソースコードとして提供している。この経緯については A Global Upgrade for Bonjour: AirPort、iPhone、Leopard、.Mac に詳しい。

分散ディレクトリ管理 (Distributed Directory Management): NetInfo

80 年代後半 NeXT は、DNS のコンセプトを取り入れて、マシーンのアドレス配布だけでなく、まとめてディレクトリサービスと言われる他の情報を配布するために、同コンセプトを NetInfo (下図、NetInfo Manager からの設定) と呼ばれる新しいシステムに応用した。

例えば、ディレクトリサービスはネットワーク環境でユーザアカウントを探すために利用される。ローカルのユーザアカウントはクライアントシステム上に作成できるものの、システム間でのアカウントリスト管理は難しくなる。というのも、2 つのシステムにはアカウントの重複があり得るからだ。さらに例えば、2 台の独立したシステムがたまたま同じユーザ名を持ちながら、異なる人々を指していることもあり得る。ディレクトリサービスシステムは、ネットワークアカウント情報のためのリポジトリとして機能する中央集権化されたサーバを利用する。これは、DNS サーバが中央集権化された名前サービスを提供するやり方に似ている。

そのため管理者は、一カ所にあるアカウント情報を管理するだけで良くなる。ネットワークアカウントを持つユーザがクライアントマシーンにログインする時には、ユーザ名とパスワードを入力し、その情報はユーザのローカルリストではなくディレクトリサーバに照会される。ディレクトリサービスはまた、そのネットワーク上で利用可能なプリンタ / ファイルサーバのリスト、あるいはユーザの部署、所属グループ、さらには連絡先といったような、他のネットワーク情報も提供できる。

NeXT の NetInfo は、典型的な Unix システムにあるようなテキスト設定ファイルを、ユーザのディレクトリやグループアカウント、マシーン設定、およびネットワークサービスを管理するローカルデータベースに置き換えた。 NeXTSTEP 上のアプリケーションは、システム上のテキストファイルを参照してこれら設定項目を探すのではなく、NetInfo を参照した。そのローカルデータベースが要求された情報を持っていない場合は、そのクエリを中央集権化された NetInfo Directory Servers へと転送した。 NetInfo はまた、Sun NIS サーバに接続してそのネットワークに関する情報を入手することもできた。

ページ 2 / 3: NetInfo の問題; 標準化された Directory Management: X.500; 標準化された Directory Management: LDAP; Mac OS X の LDAP; そして Managed Preferences の起源。

次のページへ　