2004 年度 情報システム構成論 第 7 回 ユーザ管理とディレクトリ サービス
DESCRIPTION
2004 年度 情報システム構成論 第 7 回 ユーザ管理とディレクトリ サービス. 西尾 信彦 [email protected] 立命館大学 情報理工学部 情報システム学科 ユビキタス環境研究室. Unix 系サーバ ユーザ管理の基本. アカウント+グループ 権限制御はアカウント・グループ単位 複数人で共同で作業する場合、同一グループに入れて、共同作業用ディレクトリを作成する ファイルによる制御 /etc/passwd ユーザ情報格納ファイル /etc/group グループ情報格納ファイル. Unix 系ユーザ管理の基本属性. ユーザ情報 - PowerPoint PPT PresentationTRANSCRIPT
Unix 系サーバユーザ管理の基本
• アカウント+グループ– 権限制御はアカウント・グループ単位– 複数人で共同で作業する場合、同一グルー
プに入れて、共同作業用ディレクトリを作成する
• ファイルによる制御– /etc/passwd ユーザ情報格納ファイル– /etc/group グループ情報格納ファイル
Unix 系ユーザ管理の基本属性• ユーザ情報
– ユーザ名– ユーザ ID– プライマリグループ名– GECOS 情報 ( いわゆるコメント )– ホームディレクトリ– ログインシェル– パスワード
/etc/passwd:nishio:x:505:502:Nobuhiko Nishio:/home/nishio:/bin/bashapache:x:48:48:Apache:/var/www:/sbin/nologin
Unix 系サーバユーザ管理の基本
• 特権ユーザ: root– 管理者– すべてのことができるため、 root でログインしているときは
操作に注意が必要• サービス用ユーザ
– 特殊な権限を保持– ログインができないものが大多数
( パスワード不明:シェルが nologin,etc)– 代表例:
• www(Linux では apache の場合が多い )• ftp
• 一般ユーザ– 普通のユーザ
Unix 系サーバユーザ運用の基本
• 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+ を大規模に使うと原因不明のシステムダウンや、
ネットワークの帯域幅を食い潰す等の現象が複数の団体で確認されている
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 シリーズ 情報モデル
• ある情報の集合体をエントリと呼ぶ
• 例:ユーザ情報エントリの場合– 1ユーザ情報内の属性
• ユーザ名• ユーザ 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)
• 軽量 DAP– DAPから使われない機能を削除– TCP/IP 上でもストレスなく動くように設計
• LDAPv2– 独自に分散化機能を持たず、分散化を X.500 に頼っている
• 大規模システムでは LDAP 単体での運用が難しい– セキュリティに問題がある
• 認証時にパスワードが平文で流れる
• LDAPv3– 分散化に対応– セキュリティの強化– 大規模なシステムでも LDAP 単体で運用可能
• プロトコルであるため、実装は多種多様
LDAP 情報モデル
• 図の挿入
LDAP の利点欠点
• 利点– プロトコルであるため、実装に依存しない– 必要なレベルによって LDAPソフトを選べる
• 商用 LDAP サーバからオープンソースまで– X.500 と連携しなくても、スタンドアロンで運用が可
能• 欠点 ( ? )
– 特殊なディレクトリサービスに変われるものではない• DNS 、 NFS 、 etc
– jpeg などを格納することもできるが、本来意図しない利用法であり、行うべきではない
LDAP適用事例
• Unix 系ホストの NIS に変えての運用が可能– MacOS X などで NIS gateway を利用した運用
が可能– Windows のレジストリのような運用が可能
• MacOS X の NetInfo
– NIS の欠点の克服• 暗号化など
• Windows のレジストリや ActiveDirectory
Active Directory
• Windows2000から導入されたディレクトリサービス
• 物理的制約にとらわれず、論理単位で管理• 代表的なプロトコルをサポート
– 名前解決用: DNS– 検索用: LDAP– 認証用: Kerberos
• 独自拡張されているため、相互運用時には注意が必要
• ライセンス上の問題で、導入するには Windows 2000 Server が必要
ディレクトリサービスのまとめ
• 複数のホストで情報を統一的に提供することを目的としている
• ディレクトリサービスの利点– 情報が一箇所に集まるため、管理、操作、整合性
保持が安易
• ディレクトリサービスの欠点– ディレクトリサービス提供サーバが故障してしま
うと、全システムが利用できなくなってしまう– ディレクトリサービス提供サーバがクラックされ
ると全データが流れてしまう