290 likes | 374 Views
計算機システム概論・6回目. 本日のトピック:ユーザ管理 ユーザ管理の仕組み UNIX ベースシステムのユーザ管理 ネットワークでの利用を想定したユーザ管理 アクセス制御機能 仕組みとしては別のものだが,かなり密接な関係がある. ユーザ管理の必要性. コンピュータの持つ資源 ... 基本的には,ユーザ全員が利用するもの 独立性,安全性確保のため, 特定の資源と 特定 のユーザとを対応付けたい 場合もある 個人や特定のグループに由来するデータ 管理用データ,ハードウェア 計算資源へのアクセス制御を実現するには ... 個々のユーザを区別 し,管理する
E N D
計算機システム概論・6回目 本日のトピック:ユーザ管理 • ユーザ管理の仕組み • UNIXベースシステムのユーザ管理 • ネットワークでの利用を想定したユーザ管理 • アクセス制御機能 仕組みとしては別のものだが,かなり密接な関係がある
ユーザ管理の必要性 コンピュータの持つ資源... • 基本的には,ユーザ全員が利用するもの • 独立性,安全性確保のため,特定の資源と 特定のユーザとを対応付けたい場合もある • 個人や特定のグループに由来するデータ • 管理用データ,ハードウェア 計算資源へのアクセス制御を実現するには... • 個々のユーザを区別し,管理する • 保護したい資源に,アクセス条件を付与する 両方の仕組みが必要になる
ユーザを管理し,区別する仕組み ユーザ管理の基本: • 正規のユーザをあらかじめ登録しておく • 計算機利用時に,本人であることを立証してもらう プラスアルファとして... • 複数のユーザから構成されるグループの概念を導入 • グループ間に階層構造を導入する • ユーザに対し属性を付与する etc.
UNIX系OSにおけるユーザ情報の管理 UNIX系OSのユーザ管理: • その後のOSのユーザ管理方式に大きな影響を与えた • 当時の開発背景をよく反映した方式となっている • 複数のユーザが一台のマシンを利用 • ユーザ間の協調が早くから意識されていた • 管理者と一般ユーザの垣根が低い • シンプルで「軽い」仕組みとなっており,導入が容易
初期のUNIXにおけるユーザ管理 • ユーザに関する情報を,特別なファイル(/etc/passwd)に格納 • ログイン時には,ユーザから入力されたパスワードと, passwdファイルに格納されたパスワード情報を比較する root:j1yadaj2:0:1:Super-User:/:/sbin/sh bin:sa5g56d:2:2::/usr/bin: sys:sdas5442s:3:3::/: nobody:fd4f2faa1:60001:60001:Nobody:/: user10:da453f:10002:1998::/summer/user10:/bin/csh 1行につき1ユーザ : : : ユーザ名 パスワード ユーザID : : : グループID コメント ホーム シェル
passwdファイルの中身 ユーザに関連付けるべき全ての情報を格納: • ユーザ名:人間にとって認識の容易な,一意識別子 • パスワード:暗号化されたパスワード • ユーザID:ユーザを識別する番号 • グループID:そのユーザの所属するグループの番号 • コメント:ユーザの本名等 • ホーム:そのユーザのホームディレクトリの場所 • シェル:ログイン後に実行するプログラム名
パスワードファイルについて パスワードは,一方向性関数で暗号化してファイルに格納 • 一方向性関数 • 順方向計算は容易...h(x)の計算は簡単に行える • 逆方向計算は困難...h–1(x)の計算は難しい パスワード 暗号化されたパスワード h abc123 s92ksr passwd 事前登録 • ファイルの中を見られても,パスワードそのものは秘密 • 小規模システムでは,ユーザが管理者を兼ねるケースも多い ⇒ 管理者から,他のユーザの秘密を守る仕組みとなっている
ログイン時の取り扱いについて 一方向性関数: • 暗号化データから,パスワードを復元することができない ユーザがログインする際には... • ユーザに,ユーザ名とパスワードを入力してもらう • 入力されたパスワードに一方向性関数をかける • 一方向性関数の結果と,passwdファイルの中身とを比較する passwd 一致? h s92ksr abc123 s92ksr 他人による「なりすまし」を防ぐ仕組みとなっている
アクセス制御 アクセス制御: 誰が,どの資源を,どのように利用するかを制御すること • Aさんはこのファイルを読み書きできる • Bさんは読むだけならOK • Cさんは読むのもダメ • ファイル × ユーザで「アクセス表」を作ればよい? file 1 file 2 file 3 : • 問題点: • 表のサイズが膨大になる • ユーザやファイルの追加が困難 • ユーザの削除,権限変更が困難 ○ × ○ ○ ○○ ×× ○ ユーザ a ユーザ b ユーザ c :
グループについて アクセス制御の柔軟性と,管理の容易さを両立するため, • グループの概念を導入する • グループ=ユーザの集合 • 一人のユーザは,複数のグループに所属可能 • /etc/group ファイルに,グループのメンバを列挙 root:x:0:root bin:x:1:root,bin,daemon daemon:x:2:root,bin,daemon staff:x:8:sato,nakamura student:x:9:yamada,tanaka • グループ名 • グループパスワード • グループID • (passwdファイルと同じ) • グループメンバ
グループを用いたアクセス制御 file 1 file 2 file 3 : グループの概念を用いることで, アクセス制御とユーザ管理を分離 ⇒ ユーザの削除等も簡単に ○ × ○ × ○○ ×× ○ グループA グループB グループC : + /etc/group: グループA:ユーザ a, b グループB:ユーザ b グループC:ユーザ a, b, c file 1 file 2 file 3 : ○ × ○ ○ ○○ ×× ○ ユーザ a ユーザ b ユーザ c :
UNIXにおけるファイルへのアクセス制御 file 1 file 2 file 3 : file 1 file 2 file 3 : UNIXでは... • 各ファイルにグループが一個だけ対応づけられる • アクセス制御の対象は,対応付けられたグループだけ (この制限は,運用により回避可能) ○ × ○ × ○○ ×× ○ ○× × ×○ × ×× ○ グループA グループB グループC : グループA グループB グループC : % ls –lg rw-r--r-- 1 kaji is-staff 88 Oct 27 2008 .cshrc
グループの使い分け • ユーザは,複数のグループに所属することが可能 • 自分の立場を「使い分ける」ことが可能 student グループ /etc/group: student:tanaka, yamada dormitory:tanaka, suzuki tennis:nakamura, tanaka 現実社会での実態にあわせた アクセス制御が可能だが... 階層型グループ等には非対応 ⇒ 比較的小規模な組織での運用向き dormitory グループ tennis グループ
ファイルへのアクセス制御 アクセス制御: • 誰が,どの資源を,どのように利用するかを制御すること • ファイルへの「アクセス」 • ファイルに書かれたデータを読みだす(read) • ファイルにデータを書き込む(write) • ファイルをプログラムと解釈し,実行する(execute) • その他(コピー,追記,プリントアウト etc) • UNIXでは,read, write, execute の3タイプのアクセスのみ考慮
UNIXにおけるファイルアクセス % ls –lg rw-r--r-- 1 kaji is-staff 88 Oct 27 2008 .cshrc ユーザ (オーナー) グループ グループ外のユーザに許可されたアクセスの種類 このグループに属するユーザに許可されたアクセスの種類 このユーザ自身に許可されたアクセスの種類 アクセスの種類(パーミッション)の例 r - - r w – r - x 読み出しのみ許可する 読み書きを許可する 実行を許可する(読み出し許可も必須) パーミッションの変更は,オーナー(と管理者)だけが可能
管理者アカウント ユーザ ID が 0 のユーザ: • 特別な権限を持つ管理者(root, スーパーユーザ) • パスワードなしで,他のユーザに「変身」することができる ⇒ 通常のアクセス制御よりも「強い」存在 • 通常は,管理者だけがシステム管理用のリソースを 利用できるよう,アクセス制御の設定を行う % ls –lg/var/log/maillog rw------- 1 root root 4096 May 20 18:01 /var/log/maillog ...メイルの送受信ログを見ることができるのは,管理者だけ
プログラムの実行権限 プログラム実行時,プロセスは... • そのプログラムを格納したファイルのオーナーではなく, • プログラムを起動したユーザの権限で動作する userA 実行形式ファイル(プログラム) rwxr-xr-x userB word ○ × r-------- userA r-------- userB
アクセス制御のジレンマ 例:パスワードの変更を行いたい • /etc/passwdには root しか書き込むことができない • パスワード変更用プログラムは,ユーザ権限で実行される ⇒ ユーザは,パスワードを変更できなくなってしまう... 対策法: 特定のプログラム実行時に,ユーザの権限を一時的に変更する ⇒ UNIX 系の OS では setUID(suid) と呼ばれる % ls –lg/usr/bin/passwd r-s--x--x 1 root root 26816 Aug 7 2001 /usr/bin/passwd 実行時にはファイルオーナーの権限で動作
ネットワークへの対応 ここまでは基本的に,一台のコンピュータの内部のお話 計算機ネットワークの発達 ⇒ 同一管理体制下に,複数のコンピュータが所属 ⇒ 管理情報を一元的に取り扱いたい ⇒ NIS(Network Information Server),YP(Yellow Page) 別々にパスワード情報を持ってると, 同期・整合性をとるのが大変 一台のマシンにパスワード情報の 原本が存在し,他は原本を参照する
NIS • ネットワークの中に,サーバとなるマシンを一台定める • 各コンピュータは, • 自分自身が持っているpasswdファイル • root等,そのコンピュータ固有のユーザ情報 • サーバが公開するpasswdファイル • コンピュータをまたがって存在するユーザの情報 の両方を参照する • passwdのほか,group 情報等も共有 • 基本的には,UNIXの伝統的なアクセス制御を踏襲 + +
NISの問題点(1) セキュリティ上の問題点 • passwdファイルの中身が見えることは,安全上問題 • ユーザ名がわかるだけで,攻撃の糸口になることも • ユーザ IDの一意性を保証できない • ローカルpasswdファイル vs. NIS passwdファイル • 一台の計算機の安全性が,他の計算機の安全性に強く影響 • ネット経由でファイルを共有していると,危険性が高い • ユーザ認証方式に自由度がない • より強力・安全な認証方式も使えない
NISの問題点(2) 運用上の問題点 • 比較的単純なグループ構造しか表現できない • 階層型グループの実現には,一工夫が必要 • 管理者の知らないユーザアカウントが存在しうる • ローカルpasswdファイルの中身までの把握は困難 • UNIX系以外の計算機との親和性が低い • Microsoft系 OSとの融合が難しい ⇒ 大規模・厳密なアクセス制御には,あまり適さない ...と思われるようになってきた
NISからディレクトリサービスへ NIS: • 本質的には,他の計算機に情報を提供する機能を有するだけ • 提供できる情報が passwdファイル(+α)に特化されている より一般的な形で情報を提供する仕組みがあれば, NISの代わりとして利用することができる ⇒ ディレクトリサービス
ディレクトリサービス 登録情報を,ネットワークを介して検索できるようにする機能 • LDAP, Active Directory ... • 特定のフォーマットを前提としない汎用的な仕組み • 「ネットワーク上の資源に関する情報提供」を想定 • パスワードを含むユーザ情報 • 計算機やプリンタの名前 etc. (検索にあたって,通信路を暗号で保護する機能も) • あくまでも情報を提供するサービス • 提供された情報をどのように利用するかは,計算機次第
ディレクトリサービスを用いたユーザ認証 パスワード情報を,ディレクトリサービスで取得すると... • パスワード情報の提供方法に自由度が生じる • OSの違い,認証手順の違い等を吸収できる • 機種の違いを超え,統一的な情報管理が可能 • 「OS側が対応すれば」より高度なユーザ管理も可能になる • 階層化されたグループ構造 • ユーザの詳細な属性に応じたアクセス制御 ディレクトリサービスの機能を有効に活用するか否かは, あくまでもOS側の対応
Windowsにおけるユーザ管理 Windows系のOS • 個人で使用するパソコン向けのOSとして発展してきた • 最近まで「ユーザ管理」「ネットワーク」の概念が希薄 • 後発の強みを生かし,新しい技術を大胆に導入 ワークグループ vs. ドメイン • ワークグループ • 独立性の高い機械が,必要に応じて協調動作 • NIS導入以前の UNIXのユーザ管理と,ほぼ同様の枠組 • ドメイン • 強力なサーバにより,厳密なユーザ管理を行う
Windowsドメインにおけるユーザ管理 • ディレクトリサービス(Active Directory)によるユーザ管理 • ドメインコントローラ(サーバ)が,ユーザ情報を集約管理 • クライアント計算機は,サーバに事前登録する必要アリ • 未登録端末には,ユーザ情報を参照させない • 階層グループ等,高度なグループ構造を構成可能 • ファイル等へのアクセス制御について,UNIX よりも詳細な 設定を可能としている
Windowsでのアクセス制御 UNIXでのファイルアクセス: • 「ファイルの所有者」「所有者に属するグループ」「その他」 • 「グループ Aまたは Bに属するユーザ」といった指定は不可 Windowsでのファイルアクセス: • アクセスコントロールリスト(Access Control List, ACL)の利用 • (ユーザ,操作),(グループ,操作) の形式で,「誰が」 「何を」して良いか指定 • きめ細かいアクセス制御が可能となっている
本日のまとめ • ユーザ管理,アクセス管理について • 基本的には,ユーザ管理とアクセス管理は独立したもの • ユーザ管理の仕組みは,目的とするアクセス管理を実現 できる必要最小限のものとなるケースが多い • 汎用性の高い仕組みが多く検討されている • 次回:その他の話題 • 実験課題(提出不要):Windows のファイルのアクセス制御が どのように設定されているか確認せよ