2004年度 情報システム構成論 第7回 ユーザ管理とディレクトリ サービス 2004年度 情報システム構成論 第7回 ユーザ管理とディレクトリ サービス 西尾 信彦 nishio@cs.ritsumei.ac.jp 立命館大学 情報理工学部 情報システム学科 ユビキタス環境研究室

Unix系サーバ ユーザ管理の基本 アカウント＋グループ ファイルによる制御 権限制御はアカウント・グループ単位 複数人で共同で作業する場合、同一グループに入れて、共同作業用ディレクトリを作成する ファイルによる制御 /etc/passwd ユーザ情報格納ファイル /etc/group グループ情報格納ファイル

Unix系ユーザ管理の基本属性 ユーザ情報 ユーザ名 ユーザID プライマリグループ名 GECOS 情報(いわゆるコメント) ホームディレクトリ ログインシェル パスワード /etc/passwd: nishio:x:505:502:Nobuhiko Nishio:/home/nishio:/bin/bash apache:x:48:48:Apache:/var/www:/sbin/nologin

Unix系サーバ ユーザ管理の基本 特権ユーザ：root サービス用ユーザ 一般ユーザ 管理者 特殊な権限を保持 ログインができないものが大多数 (パスワード不明：シェルがnologin,etc) 代表例： www(Linuxではapacheの場合が多い) ftp 一般ユーザ 普通のユーザ

Unix系サーバ ユーザ運用の基本 rootでの作業は極力行わない rootに移行できるユーザを限定する 事故防止のため 必要時でもrootに移行せず、sudo/suを使う rootに移行できるユーザを限定する 権限奪取阻止目的 Operator グループ /etc/ttysでの制約も可能 サービス用ユーザでのログインは禁止する サービスを利用しての攻撃に対する予防 サービス誤作動時の予防措置

ディレクトリサービス 複数のホストでユーザ情報を共有できる ユーザ管理の設定が散在せず、ユーザ管理のコストが削減できる ユーザ以外のものも管理可能 ホスト情報 分散ファイル管理情報 最近ではユーザの位置情報 代表的なユーザディレクトリ NIS NIS+ LDAP Active Directory

NIS(Network Information Service) Sun Microsystems社が作成したディレクトリサービス もともとはSun Yellow Pages (YP) Yellow Pagesが英国 British Telecom 社の登録商標だったため利用できなくなり、改名 サーバのファイル名やコマンド名などに名残がある ypserver (NISのサーバ) yppasswd 代表的なディレクトリサービス Unix系であれば、ほぼ実装ずみ

NISの動作原理 NIS独自にドメインを定義してそれ単位での管理 同一ドメイン内に複数のサーバを設置することも可能 マスターサーバ、スレーブサーバ スレーブサーバはマスターサーバのコピー すべてのクライアントの要求がマスターサーバを利用すると、 負荷に耐えられないため、大規模なシステムの場合は スレーブサーバを利用する マスターサーバの変更が随時スレーブサーバにコピーされる サブネットを含むドメインは利用できない バグではなく、仕様(Sun談) サブネットを越えて動作しないのはgroup情報だけ (本当に仕様？)

NISの利点欠点 利点 欠点 ほとんどのUnix系OSが対応 導入が簡単 文献が豊富 サブネットを越えて動作しない セキュリティ上の問題がある 通信内容が暗号化されない クライアント認証がアドレス制限以外にない Unix系用であるため、他の系統のOS、サービス間で併用しにくい

NIS+ (Network Information Service (Plus)) Sun Microsystems社がNISの後継として、 作成したディレクトリサービス セキュリティが強化されている 通信経路が暗号化されている クライアント認証あり 大きなシステムを導入するのに向いている Linux上のNIS+には多数のバグが残存 NIS+の開発は終了(中止)されている

NIS+の利点欠点 利点 欠点 大問題：バグが多い NISに比べて安全 NISの欠点が解消されている ネットワーク負荷が高い 管理が複雑 通信経路が暗号化されている NISの欠点が解消されている 欠点 ネットワーク負荷が高い 管理が複雑 大問題：バグが多い NIS+ を大規模に使うと原因不明のシステムダウンや、ネットワークの帯域幅を食い潰す等の現象が複数の団体で確認されている

X.500 シリーズ ITU-T(International Telecommunication　Union-Telecommunication sector)が定めた、ネットワーク上での分散ディレクトリサービスに関する規格 世界で統一したネームサービスが利用可能であり、データ検索が安易に行える 規格であるため、さまざまな実装が存在 システムの規模によって、導入するソフトが選択可能

X.500 シリーズ 勧告番号 規定内容 X.500 ディレクトリの概説 X.501 ディレクトリのモデル X.509 認証 X.511 抽象サービス X.518 分散操作 X.519 プロトコル (DAP) X.520 属性 X.521 オブジェクトクラス

X.500 シリーズのモデル 機能モデル 組織モデル 安全保護モデル 情報モデル ディレクトリサービスを提供するための機能をモデル化し，そのインタフェースを定義 組織モデル ディレクトリを複数の管理組織に分割して管理している場合のモデルを説明 安全保護モデル ディレクトリに管理されている情報の機密保持についての方針を説明 情報モデル ディレクトリに格納される情報の構造と，情報をディレクトリに格納する方法を規定

X.500 シリーズ 情報モデル ある情報の集合体を エントリと呼ぶ 例： ユーザ情報エントリの場合 １ユーザ情報内の属性 ユーザ名 ユーザID ホームディレクトリ Etc

X.500 シリーズの識別名モデル 表現例：CN=test,OU=ubi,OU=is,O=ritsumei,O=ac,C=jp

DAP(Directory Access Protocol) X.500用アクセスプロトコル 全部入りのプロトコルであるため複雑 複雑であるがゆえに重い TCP/IP用に開発されていなかったため(国際電話を実現するため)、TCP/IPとの相性が悪くインターネット上で利用しにくい

LDAP (Lightweight Directory Access Protocol) TCP/IP上でもストレスなく動くように設計 LDAPｖ２ 独自に分散化機能を持たず、分散化をX.500に頼っている 大規模システムではLDAP単体での運用が難しい セキュリティに問題がある 認証時にパスワードが平文で流れる LDAPv3 分散化に対応 セキュリティの強化 大規模なシステムでもLDAP単体で運用可能 プロトコルであるため、実装は多種多様

LDAP 情報モデル 図の挿入

LDAPの利点欠点 利点 欠点(？) プロトコルであるため、実装に依存しない 必要なレベルによってLDAPソフトを選べる X.500と連携しなくても、スタンドアロンで運用が可能 欠点(？) 特殊なディレクトリサービスに変われるものではない DNS、NFS、etc jpegなどを格納することもできるが、本来意図しない利用法であり、行うべきではない

LDAP適用事例 Unix系ホストのNISに変えての運用が可能 WindowsのレジストリやActiveDirectory MacOS XなどでNIS gatewayを利用した運用が可能 Windowsのレジストリのような運用が可能 MacOS XのNetInfo NISの欠点の克服 暗号化など WindowsのレジストリやActiveDirectory

Active Directory Windows2000から導入されたディレクトリサービス 物理的制約にとらわれず、論理単位で管理 代表的なプロトコルをサポート 名前解決用：DNS 検索用：LDAP 認証用：Kerberos 独自拡張されているため、相互運用時には注意が必要 ライセンス上の問題で、導入するにはWindows 2000 Serverが必要

ディレクトリサービスのまとめ 複数のホストで情報を統一的に提供することを目的としている ディレクトリサービスの利点 情報が一箇所に集まるため、管理、操作、整合性保持が安易 ディレクトリサービスの欠点 ディレクトリサービス提供サーバが故障してしまうと、全システムが利用できなくなってしまう ディレクトリサービス提供サーバがクラックされると全データが流れてしまう