ホスティングサービスの認証システム構築

統合認証基盤を用いた

ホスティングサービスの認証システム構築

針木剛¹、赤坂浩一¹、古村隆明²、永井靖浩² 京都大学情報環境部¹、京都大学学術情報メディアセンター²

1 _はじめに

京都大学では平成22_{年度より統合認証基盤}(_全学ID、シングルサインオン、認証局、統合ディレクトリデータ ベース、IC_カード)を本格運用している。例えば、全学の教職員向けID_{と学生向け}ID_{を統合した全学}ID_を格 納したディレクトリデータベース(_統合LDAP)を構築し、学内情報システムの認証等に活用している。また、シ ングルサインオンの１つとしてShibboleth[1]システムを稼動させるとともに、全教職員に対して電子証明書を格 納したIC身分証等を配付し、セキュアなWebサービスの多要素認証に利用している。

このような統合認証基盤を用いて、学内構成員向けのWebホスティングサービスに対して以下の3_{点の改善を} 実施し、よりセキュアな環境の提供と利用者の利便性向上が実現できたので報告する。

• ファイル更新時認証への活用

• WebシングルサインオンのためのShibboleth_の導入

• ICカードによるログイン認証の導入

2 Web_{ホスティングの概要}

Webホスティングサービスは共用サーバ型とVPS型のサービスを行っており、通常業務としてシステム運用管 理及び利用者対応がある。今回の改善は共用サーバ型のサービスを対象としており、このサービスでは、利用者は コンテンツの運用管理だけでWebサイトの運用が可能である。

システムは以下のように運用している。

• OS_は「Linux_」、Web_{サーバは「}Apache_」[2]

• Apacheの仮想ホスト機能により複数のホスト名の処理ができるため、複数の利用者がWeb_{サーバを共用}

• 仮想ホスト毎にUNIX系システムのユーザID(以下システムIDとする)を割り当て、CGIのような動的コ ンテンツの生成等機能は当該システムID_{の権限において実行}

3 ファイル更新時認証への活用

利用者A サイト1の システムID

システム 認証

利用者B

・・

利用者X BからXは不正利用

権限

図1 複数ユーザ利用での問題 3.1 _{従来の課題}

サイトの運用に関してそのコンテンツ管理を一人で行うと いうことは希であり、例えば研究室なら教員と学生、学科・

専攻なら複数の職員で行う。従来、Web_{ホスティングサー} ビスでは、システムIDを利用者アカウントとして利用者本 人への配布のみとしていたため下記のような課題があった。

• 複数利用者でのシステムIDとパスワードの使い回し が発生し、更新した利用者がわからない。(_図1_参照)

• 管理するサイトが増えるとその度にシステムID_が配 布され、IDやパスワードを管理する手間が増える。

(_図2_参照)

利用者A サイト1の システムID

システム 認証

・・ サイト2の システムID

サイトXの システムID 権限

図2 _{複数システム}ID_{利用での問題}

利用者A

システム AのID

認証

権限

・・

サイト1の システムID 利用者B

・・ 利用者X

BのID

XのID

図3 複数ユーザ利用での改善方法

利用者A

システム AのID

認証 権限

・・ サイト1の システムID サイト2の システムID

サイトXの システムID 権限を選択

図4 _{複数システム}ID_{利用での改善方法} 3.2 統合認証基盤を用いた対策

これをFTP_サーバ「ProFTPD_」[3]_の機 能を用いて、本人認証の機能とその認証した 利用者をシステムIDと紐付けした権限割り 当ての機能(_{認可及びアクセス許可})_とに分 離した。本人認証には学内構成員全員に割り 当てられた全学ID_{を格納した統合}LDAP を利用した。

これにより下記のように改善できた。

1. _{各利用者の全学}ID_{でログインしてい} るためIDとパスワードの使い回しが 抑制され、コンテンツ更新のトレーサ ビリティが可能になり、情報セキュリ ティが大きく改善された。(図3参照) 2. _{各利用者の}ID_は1_{つであるが、利用} 者に設定された権限によって複数のサ イトが管理できるため複数ID_を管理 する手間がなくなり、利用者及びホス

ティング管理者の稼働が軽減された。(図4参照)

3.3 FTPサーバの設定と具体的なファイル更新フロー

リクエストの中でホスト名を指定できるhttpでは仮想ホスト名毎に個別設定が可能だが、ftp_{ではポート番号や} IPアドレスでしか個別設定ができない。そのため今回の対策では、FTPサーバが複数のハイポートで待ち受ける ように設定して各ポートに個別設定を施した。

具体的な設定は以下の通りである。(_リスト1_参照)

• 認可する全学ID_のリスト

• 紐付けしてファイルオーナとなるシステムID

• 書き込む先のホームディレクトリ(Web公開用のディレクトリを含む)

設定した後、利用者は以下のフローでファイル更新を行う。

1. 利用者はまず統合認証基盤のLDAPサーバに接続し、本人認証を行う。

2. 本人認証後、ポート番号に設定された認可情報にマッチした全学ID_{だけが選別される。}

3. 認可処理後、ポート番号に設定されたシステムIDをアサインしその権限でファイル更新を行う。また、当 該システムIDのホームディレクトリがトップディレクトリとなっている。

リスト1 FTP_{サーバの設定}

D e f a u l t A d d r e s s 1 9 2 . 0 . 2 . 1 # ア ド レ ス

P o r t 0 # デ フ ォ ル ト の ポ ー ト は な し

D e f a u l t R o o t ~ # ト ッ プ デ ィ レ ク ト リ は ホ ー ム

...

< Global >

T L S E n g i n e on T L S P r o t o c o l S S L v 3 T L S R e q u i r e d on

A u t h O r d e r m o d _ a u t h _ f i l e . c m o d _ l d a p . c # フ ァ イ ル 認 証 とL D A P認 証

A u t h U s e r F i l e / p a t h / to / p a s s w d # フ ァ イ ル 認 証 用 フ ァ イ ル

A u t h G r o u p F i l e / p a t h / to / g r o u p

L D A P S e r v e r l d a p . e x a m p l e . kyoto - u . ac . jp : 6 3 6 # L D A P_{サ ー バ}

L D A P U s e S S L on # S S L_{を 使 う}

L D A P A u t h B i n d s on # B i n d_{す る}

L D A P D N I n f o " B i n d D N " " p a s s w o r d " # B i n d_{す る}D Nと パ ス ワ ー ド L D A P D o A u t h on " b a s e " " ( uid =% v ) " # _{認 証 の 入 力}I D_をD N_に

L D A P D o U I D L o o k u p s off # L D A Pか ら は シ ス テ ムI Dの 情 報 を 取 得 し な い

L D A P D o G I D L o o k u p s off L D A P F o r c e D e f a u l t U I D on L D A P F o r c e D e f a u l t G I D on

L D A P G e n e r a t e H o m e d i r on # L D A Pか ら は ホ ー ム の 情 報 を 取 得 し な い

L D A P G e n e r a t e H o m e d i r P r e f i x N o U s e r n a m e on ...

</ Global >

< V i r t u a l H o s t 1 9 2 . 0 . 2 . 1 > # ポ ー ト ご と のV i r t u a l H o s t設 定

P o r t 5 9 0 0 0 # ポ ー ト 番 号(ハ イ ポ ー ト)

L D A P D e f a u l t U I D 5 9 0 0 0 # ア サ イ ン す る シ ス テ ムID

L D A P D e f a u l t G I D 5 9 0 0 0

L D A P G e n e r a t e H o m e d i r P r e f i x / h o m e / 5 9 0 0 0 # ホ ー ム デ ィ レ ク ト リ

< L i m i t All >

O r d e r deny , a l l o w D e n y U s e r All

A l l o w U s e r OR 全 学ID1 全 学ID2 ... # 認 可 す る 全 学I Dリ ス ト

</ Limit >

</ V i r t u a l H o s t >

3.4 利用者からのコメントと対応

今回の新しいファイル更新方法を運用するにあたり利用者からのコメントとそれらの対応について記述する。

• 同一の仮想ホストの中に複数の研究室や部署をディレクトリに分けてコンテンツ管理しても、他研究室や他 部署のディレクトリのコンテンツに対して書き込み制限ができないため、複数の組織のコンテンツの運用に は向かない。

⇒単一組織でサービスを利用するか、それが難しい場合は適宜バックアップにて対応を推奨

• コンテンツ作成業者にファイル更新を依頼したいが、学内構成員のみの全学ID_{を格納した統合}LDAP_に は業者のIDが存在しない。

⇒「ProFTPD_{」は認証に統合}LDAPを利用した認証に加えて、ローカルホストのファイル認証の併用が

可能なので、業者用アカウントをファイル上に作成して対応可能

• 従来はSCP_やSFTPでファイル更新をお願いしていたが、新しいファイル更新方法では暗号化したSSL 上のFTPを利用する。一部のコンテンツ作成ソフトがこのプロトコルに非対応で、サーバ同期機能を利用 することができない。

⇒まず自分のPC端末内に保存してから当該プロトコルに対応したソフトウェアで更新が可能

4 WebシングルサインオンのためのShibboleth_導入 4.1 _{サービス導入の経緯}

従来Webコンテンツの閲覧制限や動的コンテンツによるコンテンツマネジメントシステムでは認証や認可をそ れぞれ利用者側で準備してきたが、統合認証基盤の整備に伴い、これを利用したいといった要望が増えてきた。そ こでWebログイン環境としてシングルサインオンシステム(Shibboleth)をWebホスティングサービスに導入 した。

4.2 Shibboleth_とは

シングルサインオンは、複数のWebシステムを利用する際、一度ログイン操作しておくと、他のシステムでは ログイン操作をすることなくシステムを利用できるようにする仕組みである。Shibboleth_はSAML2.0_に準拠し たFederationシステムで、統合認証基盤の一つとして平成21年度より運用している。なお、Shibboleth_認証に は統合LDAP_{を利用している。}Shibbolethは国立情報学研究所で大学間連携のために利用されており、京都大学 も含め多くの大学で導入・運用の実績がある。

4.3 Shibboleth_の動作

Shibbolethは電子的なコンテンツ等リソースを提供するシステム(Service Provider_、SP)_{と認証・認可の判定} 及び属性情報を提供するシステム(Identity Provider_、IdP)_{が独立しており、}SP_とIdP_の組織(_ドメイン)_が違っ てもシングルサインオンが可能である。

ブラウザ IdP

SP1 SP2 ・・ SPX

(1) (2)

(3) (4) (5)

図5 Shibboleth_の動作 認証のフローを図5_に示す。

(1) クライアントのブラウザからSP1にWebアクセス (2) SP1_がIdPへリダイレクトするよう指示

(3) _{クライアントは}IdP_{にアクセス}

(4) IdP_{の認証済み「}cookie_{」があればそのまま}SP1_へリ ダイレクトを指示、なければIdP _{認証画面で認証後}

「cookie」をセットしてSP1へリダイレクトを指示 (5) SP1_にIdPから受けとった属性情報をPOST_する。ま

た、SP1_{の認証済みという「}cookie_{」がセットされるの} で以降はログイン状態で継続的にアクセス

このように、一度IdPで認証すれば、例えば次にSP2_{にアクセスした場合、}(4)の認証画面での入力が不要になる ため、利用者は意識せずにシングルサインオン状態となる。

またSPが受けとった属性情報はWebサーバの認可設定に利用できるだけでなく、CGI_{などの動的コンテンツ} ではWebサーバの環境変数の値として得られるので、コンテンツ管理システムなどで属性に対し閲覧者や編集者 のような権限を自動で割り当てることも可能となる。

なお通常はIdP_{へリダイレクトする}(2)_の前にDS(Discovery Service)_{により複数の}IdP_から当該IdP_を選択 する場合があるが、京都大学では運用していないため本稿では割愛する。

4.4 仮想ホスト環境での利用方法

Shibboleth_のSP_{は共用型の}Webホスティングサーバ内で動作させている。この際、複数の仮想ホスト名に対 応させるには各ホスト名に対し「ApplicationID_{」を設定し、さらに}Shibboleth SPではデフォルトの設定に加え、

「ApplicationID」毎に下記情報の上書きが可能である。(_リスト2_参照)

• 仮想ホスト名のサーバ証明書とその秘密鍵

• 取得する属性情報に関する設定(_{環境変数名など})

• IdP_{に関する設定}(_{サーバ証明書、}URL_など)

リスト2 ApplicationID_{を上書きする設定}

<! - - A p p l i c a t i o n I Dの 設 定 - - >

< R e q u e s t M a p a p p l i c a t i o n I d = " d e f a u l t " >

< H o s t n a m e = " www . e x a m p l e . kyoto - u . ac . jp " a u t h T y p e = " s h i b b o l e t h "

r e q u i r e S e s s i o n = " t r u e " / >

< H o s t n a m e = " w w w 1 . e x a m p l e . kyoto - u . ac . jp " a p p l i c a t i o n I d = " v h o s t 1 "

a u t h T y p e = " s h i b b o l e t h " r e q u i r e S e s s i o n = " t r u e " / >

</ R e q u e s t M a p >

...

< A p p l i c a t i o n D e f a u l t s id = " d e f a u l t " p o l i c y I d = " d e f a u l t "

e n t i t y I D = " h t t p s :// www . e x a m p l e . kyoto - u . ac . jp / s h i b b o l e t h - sp " ... >

<! - - デ フ ォ ル ト のA p p l i c a t i o n I D_{の 設 定} - - >

< C r e d e n t i a l R e s o l v e r t y p e = " F i l e "

key = " / etc / pki / tls / p r i v a t e / www . e x a m p l e . kyoto - u . ac . jp . key "

c e r t i f i c a t e = " / etc / pki / tls / c e r t s / www . e x a m p l e . kyoto - u . ac . jp . cer " / >

< S e s s i o n s ... / > <! - - I d Pへ の 接 続 方 法 - - >

< M e t a d a t a P r o v i d e r t y p e = " XML " f i l e = " idp - m e t a d a t a . xml " / >

< A t t r i b u t e E x t r a c t o r t y p e = " XML " f i l e = " a t t r i b u t e - map . xml " / >

<! - - A p p l i c a t i o n I Dの 上 書 き 設 定 - - >

< A p p l i c a t i o n O v e r r i d e id = " v h o s t 1 "

e n t i t y I D = " h t t p s :// w w w 1 . e x a m p l e . kyoto - u . ac . jp / s h i b b o l e t h - sp " >

< C r e d e n t i a l R e s o l v e r t y p e = " F i l e "

key = " / etc / pki / tls / p r i v a t e / w w w 1 . e x a m p l e . kyoto - u . ac . jp . key "

c e r t i f i c a t e = " / etc / pki / tls / c e r t s / w w w 1 . e x a m p l e . kyoto - u . ac . jp . cer " / >

< S e s s i o n s ... / >

< M e t a d a t a P r o v i d e r t y p e = " XML " f i l e = " idp - m e t a d a t a _ f o r _ v h o s t 1 . xml " / >

< A t t r i b u t e E x t r a c t o r t y p e = " XML " f i l e = " a t t r i b u t e - m a p _ f o r _ v h o s t 1 . xml " / >

</ A p p l i c a t i o n O v e r r i d e >

</ A p p l i c a t i o n D e f a u l t s >

SPでの各種設定後、利用者はWeb公開用のディレクトリの「.htaccess」ファイルの設定だけで利用可能となる。

4.5 利用者からのコメントと対応

Webホスティングサービス上でShibbolethサービスの実運用を始めてから日が浅くまだ利用者も少数である が、新しい技術であるため技術的な質問や運用方法に関する質問が多い。特にSP_でWeb_{アプリケーションを利} 用する場合、そのアプリケーションでの設定方法もアドバイスする必要があるため、利用者と同じテスト環境を サービス運用側でも準備して対応している。

5 ICカードによるログイン認証の導入 5.1 _{サービス導入の狙い}

全教職員に配布したICカードに含まれる電子証明書を利用して、IDとパスワードに比べてよりセキュリティの 高いWebログイン環境を利用者に提供できる。具体的には、社会的影響の大きな学内Web_{コンテンツに対する} 制限に適用することを想定している。

5.2 ICカードログイン認証方法

本サービスはWeb_サーバのSSLによるクライアント認証を利用する。

京都大学のICカードの電子証明書は学内でプライベートCAを構築し、そこで発行している。従って通常の WebサーバにバンドルされているパブリックCAの証明書リストに、大学のルート証明書も追加して設定する必 要がある。あとは利用者がWeb公開用のディレクトリの「.htaccess_{」ファイルに}SSLクライアント認証する設定 をするだけで利用可能となる。(_リスト3_参照)

ブラウザからICカードを用いて接続するとWeb_サーバのSSL関係の環境変数でクライアント証明書の内容が 得られるのでその中にあるID情報で本人確認ができる。

リスト3 ICカードログイン認証をする設定 S S L V e r i f y C l i e n t r e q u i r e

S S L V e r i f y D e p t h 2 #京 都 大 学 は2階 層

S S L R e q u i r e ( %{ S S L _ C L I E N T _ S _ D N _ C N } in { "全学ID1 " , "全学ID2 " . . . } and \

%{ S S L _ C L I E N T _ S _ D N _ O U } eq " K y o t o U n i v e r s i t y F a c u l t y CA " and \

%{ S S L _ C L I E N T _ S _ D N _ O } eq " K y o t o U n i v e r s i t y " and \

%{ S S L _ C L I E N T _ S _ D N _ C } eq " JP " ) #こ こ で 証 明 書 を 制 限 す る こ と も 可 能 S S L O p t i o n s + S t d E n v V a r s \ # C G Iな ど でS S L関 係 の 環 境 変 数 が 利 用 可 能

+ F a k e B a s i c A u t h # B a s i c認 証 と 併 用 も 可 能

# 以 下 はB a s i c認 証 と 併 用 す る 場 合 A u t h N a m e " I C c a r d a u t h "

A u t h T y p e B a s i c

A u t h B a s i c P r o v i d e r f i l e

A u t h U s e r F i l e " / p a t h / to /. h t p a s s w d "

r e q u i r e valid - u s e r

# / p a t h / to /. h t p a s s w dに は 下 記 の よ う に 全 学I Dを 羅 列

# / C = JP / O = K y o t o U n i v e r s i t y / OU = K y o t o U n i v e r s i t y F a c u l t y CA / OU = R e g u l a r / CN =全 学ID1 : x x j 3 1 Z M T Z z k V A

# # こ こ で’ x x j 3 1 Z M T Z z k V ’は文字列’ p a s s w o r d ’のD E Sハ ッ シ ュ 値 で 固 定 値

5.3 利用者からの要望と対応

ICカード及び電子証明書を用いたIC_{カード認証}(_{多要素認証})_{は人事給与等の}Webサービスで運用中である が、Webホスティングサービスに対しては、まだ利用者へのアナウンスが十分でない。本方式はより高いセキュ リティが必要となるコンテンツには有効な手段であるので利用者にその旨アナウンスしていきたい。

6 _まとめ

Webホスティングサービスに対して統合認証基盤を適用させ、以下の事を明らかにした。

• セキュリティに関して

(1) _{ファイル更新時の}IDの使い回しを抑制ができた。

(2) ICカード認証でより高いセキュリティが必要になるWebコンテンツの保護が可能になった。

• 利用者の利便性に関して

(3) _{ファイル更新時の}ID_{を統合認証基盤の全学}IDに変更し、複数のサイトの更新も可能になった。

(4) _全学ID_及びShibboleth_{システムにより、}Webシングルサインオン環境が提供できた。

今後、システムの安定運用に加え、Shibboleth_{システムや}ICカード認証について利用者の認知度を向上させ利用 を促進する。また対応事例を増やすとともに、安全性や利便性の観点から有効性を検証していく。

参考文献

[1] Shibboleth http://shibboleth.internet2.edu/

[2] Apache http://httpd.apache.org/

[3] ProFTPD http://www.proftpd.org/