大阪大学における学内認証基盤の構築
馬場健一

岡村真吾

寺西裕一

秋山豊和

中野博隆

大阪大学サイバーメディアセンター{baba, okamura, teranisi, akiyama, nakano}@cmc.osaka-u.ac.jp

概要 大阪大学では、多くの学内システムを統合的かつ安全に機能させるため、全学にわたる公開鍵認証（PKI）を用いた学内認証基盤（キャンパス PKI）を構築する計画を進めている。
公開鍵暗号を用いた認証を行うことにより、パスワードによる認証において問題となるパスワード解読の脅威に対する耐性を高めることができる。キャンパス PKI を構築するにあたり、ユーザ公開鍵・秘密鍵の管理方法や認証局の運用形態といった PKI の運用方法や、Web シングルサインオンや計算機ログイン認証といった PKI を利用したアプリケーションについての検討を行った。本稿では、それらの検討内容や構築中のキャンパス PKI の構成について述べる。

1. はじめに
近年の業務システム等のオンライン化に伴い、システムの複雑化、セキュリティに対する懸念が問題となっている。大阪大学においても、学務情報システム、経理システムといった業務システムのオンライン化が予定されており、シンプルかつ安全なシステム化が要求されている。こうしたオンラインサービスにおいては、個人認証が必須となる。特に、学務情報システ
ム等では、成績などの各個人の機密に関わる情報を扱わねばならないため、本人性を高いセキュリティのもと確認できる仕組みが必要となる。しかしながら、従来のユーザ ID とパスワードの組み合わせによる認証方法は、盗聴、解読による脅威に十分な耐性があるとはいい難い。また、従来のユーザ ID とパスワードの組み合わせによる認証では、個人がそれぞれのシステムに対応した ID や複雑なパスワードの管理を記憶に頼って行わねばならない。通常、解読防止のために、定期的にパスワードを更新する対処が行われるが、多数のシステムを使い分けることは困難である。
そこで、これらの問題を解決するために、大阪大学では、公開鍵認証（PKI）による学内認証基盤（キャンパス PKI）の構築を検討している。公開鍵暗号を用いた認証を行うことにより、パスワードによる認証において問題となるパスワード解読の脅威に対する耐性を高めることができる。また、PKI は Web におけるサーバ・クライアント間の通信の暗号化、サーバ認証の枠組みとしても採用されており、Web ベースのアプリケーションとの親和性も高い。さら
1に、メール暗号化・電子署名(S/MIME[1])、無線 LAN 認証といったさまざまなアプリケーションにおいても PKI は用いられており、応用範囲が広い特徴を持つ。
本稿では、大阪大学におけるキャンパス PKIの整備に向けた検討状況について報告する。以下、キャンパス PKI の構築にあたっての検討内容と構築中のシステム構成について述べる。

2. キャンパス PKI の検討
2.1. ユーザ公開鍵、秘密鍵の管理
PKI 認証環境を実現する上では、公開鍵、秘密鍵をいかにユーザに管理させるかが問題となる。本認証基盤では、専用デバイスに格納する方法を採用することとした。デバイスを用いて秘密鍵の生成、電子署名等を実行することで、外部に秘密鍵を取り出すことなく運用することが可能となる。また、万一盗難にあったとしても、デバイス自体が耐タンパ性を持ち、読み出すことが物理的にできないようになっており、かつ、PIN によるアクセス制御も行われるため、安全度はかなり高い。専用デバイスとしPKI アプリケーション(HTTPS 認証,無線LAN, etc)

非接触
アプリケー
ション

カードドライバ

非接触ドライバ

接触リーダ

非接触リーダ

非接触・接触ＩＣカード(ハイブリッド)

図 1 ハイブリッドカードを用いる形態

PKI アプリケーション(HTTPS 認証,無線LAN, etc)

ユーザ証明書を発行する認証局の運用方法として、次の 3 つが挙げられる。

非接触
アプリケーション

1) 第三者機関に RA および IA の全運用を委ねる

非接触ドライバ

2) 組織内にて RA を運用し、IA の運用を第三者機関に依頼する（図 3）

非接触リーダ3) 組織内で RA および IA を運用する
1)は第三者機関に証明書を発行してもらう
ため、大学には CA が存在しない、すなわち、本人確認を第三者機関に委ねることとなる。2),3)は大学において本人確認を実施する。ユーザ
証明書は、大学としてユーザが大学の一員であることを証明するものであるため、大学が本人確認を行う必要がある。よって、2), 3)のように大学内で RA を運用する必要がある。
また、CA の運用形態をパブリック CA とするかプライベート CA とするかについても選択しなければならない。ここで言うパブリックCA とは、一般的な Web ブラウザや PC に承認済みルート証明書として証明書が埋め込まれた CA もしくはその子 CA を指す。
キャンパス内のシステムにおいてユーザ認証を行う上では、必ずしもパブリック CA が発行したユーザ証明書を用いる必要はない。ユー
ザ証明書を発行したプライベート CA の証明書を、ユーザ認証を行うシステムに対して正しく配布できれば、その証明書を用いてユーザ証明書を検証できる。ただし、証明書を正しく配布するには、配布元と配布先の間で決められた手順で正確に運用がなされねばならない。
一方、ユーザ証明書を S/MIME[1]の公開鍵証明書として用いる上では、プライベート CA では不十分となる。プライベート CA から発行されたユーザ証明書の場合、このプライベートCA の証明書を承認済みルート証明書として認非接触ＩＣカード

図 2 デュアルカードを用いる形態ては、現在 IC カード、USB キーという選択肢が取り得る。本認証基盤では、· 身分証明書を兼ねることができる· 非接触のインタフェースを共存させることで電子マネーや簡易システムにおける本人認証などにも利用できるなどの利点から IC カードを選択することとした。
非接触アプリケーションと、PKI 認証との双方を IC カードにおいて用いて実現する方法として、次の 3 つの形態が考えられる。
1) 接触・非接触で別々のカードを用いる
2) ハイブリッドカードを用いる（図 1）
3) デュアルカードを用いる（図 2）1)は実現が最も容易であるが、ユーザに複数枚のカード管理を強いることとなり、利便性が低い。2)は 1 枚のカードの上に接触・非接触の機能が独立して共存する形態であり、3)は共通のカ ード上の機能を 接触・非接触の インタフェースを通じて利用する形態である。これら
は 1)の問題である複数枚のカード管理の手間を避けることができる。うち、3)は、現状ではWindows OS 以外の OS では利用できないものがほとんどである。一方 2)の方法は、Windows以外の OS での運用実績があるものが存在するが、ひとつのカードに複数の記憶領域へのインタフェースが共存する形となり、カード単価が高価となる可能性がある。したがって、利用OS や、コストに応じてどの形態を利用するかを選択する必要がある。

ＣＡ秘密鍵
ＣＡベンダ
（IA）

個人証明書
個人秘密鍵

カード
ベンダ

カード発行
郵送

安全な通信路申請

2.2. 認証局の運用形態

ＲＡ端末

認証局(CA: Certificate Authority)の機能は、登録局(RA: Registration Authority)の機能と発行局(IA: Issuing Authority)の機能に分けられる。

アカウントＤＢ
証明書レポジトリ

ユーザ

運用者

図 3

2

IA の運用を第三者機関に委託

識できているユーザ間でしか、安全に電子署名や暗号化が施されたメールのやりとりを行なえない。キャンパス内でのみメールをやりとりするのであれば問題ないが、他大学、個人、企業とやりとりするメールにおいて S/MIME を利用できないのではその意義が薄れる。よって、
S/MIME ではパブリック CA が発行した証明書を用いることが望ましい。
したがって、本認証基盤では少 なくともS/MIME の証明書はパブリック CA の形態でユーザへ発行、ユーザ認証用の証明書はパブリック CA もしくはプライベート CA の形態で発行することを目指す。ポリシーをあわせることができれば、S/MIME 証明書とユーザ認証の証明書は同一のものとしたいが、柔軟に対応することとしている。
運用の方法としては、3)を採用すると IA の運用も含め学内で行わなければならないが、パブリック CA の IA の運用には WebTrust for CA認定[2]が要求されるため、莫大なコストと設備が必要となり、かつ手続きに長大な期間がかかる。したがって、本認証基盤では 2)の IA の運用を第三者機関に依頼する方法を採用することとする。

2.3. Web シングルサインオンの実現
キャンパス内の情報システムは Web ブラウ
ザを クライアントと して用いたアプ リケーションが主流である。通常、大学においては各部局が必要に応じて独自のシステムを構築するため、それぞれ独自の方式、ID、パスワードで認証が行われてきた。大阪大学では、これを改善し、利用者がシステム毎に異なるユーザID とパスワードの組み合わせで認証を行わずとも、統一的なユーザ ID とパスワードの組み合わせを用いて認証を行えるよう、統一アカウントによる認証連携の仕組みを整備してきた。
本認証基盤では、この枠組みをさらに進めたシングルサインオンを、PKI によるユーザ認証を含めて実現する。て認証サーバで PKI 認証を行い、その認証結果を各 Web サーバへ再リダイレクトして引き継ぐ形態のシングルサインオンを実現する。認証サーバにおいて一定時間 PKI 認証の状態を記録しておくセッション Cookie を発行すれば、PKI 認証をサーバ毎に行なうオーバヘッドを軽減することができる。認証サーバへリクエス
トをリダイレクトさせ、認証結果を引き継ぐ仕組みを実現するため、各 Web サーバに専用のエージェント（プラグイン）を設置する。このエージェントがリダイレクト、認証処理の引き継ぎなどを受け持ち、各アプリケーションでは、それらの処理を意識せずに済むようにする。
2.3.2. 本人性保証レベルに基づく認証システムによっては、キャンパス内のユーザだけでなく、海外の元留学生などの IC カードを配布することが困難なユーザが含まれる場合がある。このようなシステムでは ID・パスワードによる認証を認めざるを得ない。ID・パスワードによる認証と、IC カードを用いた PKI認証を行う場合では、なりすましの脅威への耐性が違うため、本人性の保証レベルが異なる。
そこで本認証基盤では、シングルサインオンを導入する際、各アプリケーションはどれだけの本人性の保証レベルを求めるかというポリシーを決め、それを満たさなければ認可しない、といった設定を可能とする。これにより、ID・パスワードと PKI 認証とを共存させ、かつそれら認証処理の違いを各アプリケーションから隠蔽することができる。また、新たな認証方式が追加された場合も、各アプリケーションは直接対応せずとも、その認証方式に対応することが可能となる。
2.3.3. 属性による認可
業務システムによっては、職種（教員、職員、学生等）、役職、所属といったユーザの属性に応じて、アクセスの認可を与えるか否かを変更しなければならない場合がある。例えば、教員には、成績データベースへのアクセスを許可するが、学生にはアクセスを許可すべきではない。
最も単純な属性管理法として、ユーザ証明書に各属性を埋め込む方法が考えられる。しかし、この方法では、職員の異動や学生の所属変更などにより証明書更新が発生してしまう。また、ID・パスワードによる認証には対応できない。
そこで、本認証基盤においては、ユーザ証明書には最低限の属性のみを保持し、ほとんどの属性は、LDAP によるディレクトリサービスにおいて管理を行うこととする。属性を得るには、

2.3.1. 認証プロセスの簡略化
キャンパス内の情報システム全てを PKI 認証対応に改造すれば、パスワードをシステム毎に入力する手間を解消できる 。しかしながら、
PKI 認証は複雑な処理であるため、キャンパス内の情報システムを渡り歩く過程で、各システムで毎回認証処理を行っていてはブラウジングに時間を要する。
本認証基盤では、Web サーバに対するアクセスは、いったん認証サーバへリダイレクトさせ3

ユーザ証明書の ID 属性（CN 属性など）をキーとして、ディレクトリサーバに対して属性の検索を行なえばよい。このとき、ユーザ証明書のID 属性と、ID・パスワード認証における ID とは一致させておく必要がある。属性の取得は、前記各 Web サーバに設置するエージェントが行って、HTTP リクエストヘッダ等を通じてアプリケーションへ引き渡す。

リのユーザエントリが削除されたとしても、アプリケーション側でそれを認識することができない。したがって、頻繁にユーザエントリが削除される場合には、アプリケーションのレポジトリとマスターとなる LDAP レポジトリを比較し、マスターにないエントリを削除するガベージコレクションを一定期間おきに行う等の対処が必要となる。
2)は、LDAP レポジトリが更新されるたびにアプリケーションのレポジトリを反映させる方法である。この方法は、1)の方法と異なり、ユーザエントリの削除についても反映することができる。しかし、LDAP のエントリが変更されるたびに、ユーザ属性レポジトリのエントリも更新しなければならないため、頻繁に更新される場合や、アプリケーションが大量にある場合に、更新のオーバヘッドが大きくなる問題がある。また、アプリケーション側で全ユーザの数をカウントする必要がある場合や、ログインしたことがないユーザについても情報を得なければならない場合には、この方法を取らざるを得ない。
本認証基盤では、アプリケーションに応じて1), 2)のいずれの方法を取るかを選択することとする。現在のところ、e-Learning システムのようなユーザ申請型のアプリケーションは 1)の形態、教員データベースのように、ユーザの情報を強 制的に登録する 必要があるアプリ
ケーションは 2)の形態といった使い分けとなるのではないかと考えている。

2.3.4. 各 Web アプリケーションの対応
Web アプリケーションをシングルサインオン対応とするには、各 Web アプリケーションの改造が必要となる。必要な改造の度合いは、アプリケーションがユーザ毎に独自の属性を保持する必要があるか否かによって異なる。
アプリケーションがユーザ毎に独自の属性を保持することがない場合は、単純にシングルサインオンエージェントを Web サーバに組み込むのみでよい。各アプリケーションはエージェントで認証され、認可ポリシーを満たしているかどうかのみをチェックする。例えば、学生と教員でそれぞれ異なるアクセス制限を設けるなど、ユーザの属性に応じてアプリケーションの動作を変える必要があれば、エージェントが LDAP 経由で得るユーザ属性を HTTP
ヘッダ経由で取得する設定を行い、アプリケーションの動作を変更すればよい。
一方、アプリケーションがシングルサインオンのエージェントから得られる属性以外に独自の属性を管理する必要がある場合（例えば、e-Learning システムにおける各ユーザの受講状態や成績など）、ユーザ属性管理のためのレポジトリをアプリケーション内に持つ必要がある。このユーザ属性レポジトリを、マスターとなる LDAP レポジトリに同期させるための手法として、次の 2 種類が考えられる。

2.4. 計算機ログインの統合

1) 認証時に同期
2) 更新時に同期
1)は、シングルサインオンで認証が成功した際、認証された ID に対応するユーザをユーザ属性レポジトリに追加する方法である。例えば、
ID1000 の阪大太郎という名前を持つユーザが、初めてシングルサインオンのエージェントで認証されたとき、アプリケーションのレポジトリに「ユーザ ID：1000、名前：阪大太郎」というユーザエントリが追加される。2 回目以降、このユーザが認証に成功したとき、認証されたユーザ ID1000 を基にユーザ属性レポジトリを検索して得られるユーザエントリを用いる。この方法では、マスターとなる LDAP レポジト
4

学内の計算機ログインを本認証基盤の ICカードを 用いて統合的に 行える仕組みは、
Windows におけるスマートカードログオンの仕組みや Linux における PAM モジュールとスマートカードを用いた PKI 認証の仕組みを用いることで実現する予定であるが、当面は、ID・パスワードによるログイン認証は継続する。
リモートログインについては、PKI 対応の SSHを用いるなどの方策も考えられるが、まずはVPN のレベルで PKI に基づくユーザ認証を実施し、その後計算機へは ID・パスワードによりログインすることで対応することを考えている。

3. キャンパス PKI の構築
3.1. CA システム
CA システムでは電子証明書の発行及び失効を行う。本認証基盤では、CA システム（IA）

シングル
サインオン
システム
証明書情報、無効化情報（ＣＲＬ）

CA（ホスティング）

シングルサインオン
エージェント
要認証
Webシステム

ディレクトリサーバ
各種
認証レポジトリ

証明書発行、失効、更新

登録
端末

アカウント
発行、失効、属性更新

ディレクトリ統合管理システム

ユーザ
端末

ICカード配信RA

本人確認は RA を操作する職員が行う。初期発行時は、事務登録局（学生の場合は、学務情報システム、職員の場合は、人事給与システム）からエントリとして追加すべきユーザの情報が CSV 形式で得られる。本認証基盤では、この情報が得られた時点で証明書を発行する。発行された証明書が正しく本人に渡るよう、ICカード配布時の運用は慎重に行う必要がある。

3.3. ディレクトリサーバシステム
認証

ディレクトリサーバシステムは、本学内に設置し、2.3.3 節等で述べた属性情報を提供するために、RA システムなどにおいて登録された情報と統一アカウントの ID を対応付ける機能を提供するものである。また、CDP として証明書情報および CRL の配布機能を提供する。

要ログイン認証システム

監視・管理システム

ＣＳＶ

事務登録局の情報

図 4 全学 IT 認証基盤システムの構成

3.4. シングルサインオンシステム

は第三者機関に委託する前提であるため、システムとしてはホスティングの形態で構築することとなる。CA が行う主な業務内容は、次に示すものである。

認証連携する全学サービス（Web アプリケーション）に対して、ID・パスワードおよび PKIによるシングルサインオン機能を提供する。大阪大学では現在いくつかの学内システムで統一アカウントによる認証連携機能が実現されており、それらを本認証基盤のシングルサインオンに対応できるよう改造する必要がある。ただし、Web サーバに組み込まれるシングルサインオンのエージェントがほとんどの処理を行うため、改造の規模はそれほど大きくはならないものと考えている。また、計算機ログインについては、ID・パスワードによる認証を行うため、ディレクトリ統合管理システムを用いてパスワード配信を行う。

· 教職員用電子証明書発行、失効· 学生用電子証明書発行、失効· 内部サーバ用電子証明書発行、失効· 電子証明書失効情報等の情報開示· CP/CPS 及びサービス内容などの情報開示· IC カード発行ベンダと連携したカード発行
本格運用のためには、CA と連携して IC カード発行を行うための方法を検討する必要がある。大量に IC カードを発行する場合は、外部の発行ベンダに委託する必要があるが、利用者が IC カードを紛失した場合であっても即日再発行が可能となるよう、大学内で IC カードを発行できる方法も用意する。

3.5. ディレクトリ統合管理システム

3.2. RA システム
RA では、CA のフロントエンドとして、CAと連携したユーザや証明書の登録、管理を行うユーザインタフェースを提供する。RA が持つ主な機能は、次の通りである。
· ユーザの登録、削除· CA への証明書の発行要求、失効要求の発行· ユーザの属性変更
個別に IC カード再発行などの対応を行う際、5ディレクトリ統合管理システムは、シングルサインオンのためのユーザエントリの更新時同期を実現する。また、計算機ログインのためのパスワード配信も実施する。
当面対象としている Web アプリケーション
としては、教員基礎 DB（大学内教員の業績等を管理、公開するためのシステム）[3]、学務情報システム（学生の履修登録、教員によるシラバス登録、成績登録など、講義に関連する業務を支援するためのシステム）
や図書館 DB（利用者に文献データベースを提供するシステム）などが挙げられる。うち、図書館 DB は、学外の文献データベースシステムを利用するシステムであるため、それらの文献データベースをシングルサインオン対応に改造することは不可能となっている。よって、学内にシングルサインオン対応のリバースプロキシ機能を設置し、ユーザはこのリバースプロキシを経由して学外の文献データベースシステムにアクセスする構成を考えている。
また、計算機ログイン認証を行う端末として、情報教育用端末や図書館端末などが想定されている。これらは当面ディレクトリ統合管理シ
ステムから配信される ID・パスワードによりログイン認証を行う予定である。多くの端末はWindows および Linux で動作している。学務情報システムへの履修登録などをこれらの端末を通じて行える必要があるため、IC カードリーダが Windows、Linux で利用できることは必須となる。

3.6. 監視・管理システム
監視・管理システムでは、設置されるシステム全体の各サーバの監視・管理を統合的に行える機能を提供する。また、各サーバで得られるログ情報の収集や、バックアップなども実施し、システム全体の安定運用を支援する。

利用者管理サーバ
利用者管理サーバ
利用者情報登録

計算資源用 CA
(NAREGI CA)

VOMSProxy証明書格納

アカウント登録MyProxy
MyProxy

VO情報

Kerberos
Kerberos
Domain
Domain Server
Server（ADS）

計算機リソース
利用者証明書

証明書管理サーバ
証明書管理サーバUMS
UMS

PKI−Kerberos
ログオン認証シングルサインオン

Kerberos
TicketNAREGIポータル
NAREGIポータル
WFT
WFT

エンドユーザProxy証明書取得

PSE
PSE
GVS
GVS

スーパーコンピュータ
スーパーコンピュータ
Front-EndFront-End

図 5 計算機資源利用者認証（案）など、連携する予定である。
さらに、全国共同利用の計算資源へは、計算資源用認証局で発行した証明書を用いてKerberos チケットを取得し、そのチケットを用いてアクセスするシステムを構築する予定である（図 5）。

4.2. 全国大学共同電子認証基盤（UPKI）

3.7. IC カードシステム

現在、国立情報学研究所を中心に、大学間で認証連携を行うための全国大学共同電子認証基盤（UPKI）構想が検討されている。UPKI
構想では、例えば、大阪大学の証明書を持った利用者が認証連携により他大学のシステム（無線 LAN や図書館など）が利用できるようになることが想定されている。本学の認証基盤シス
テムも UPKI との連携を進めていく予定である。

IC カードを用いて CA システムで発行された電子証明書及び秘密鍵を安全に格納し、他のシステムと併せて大学情報資産アクセス時の厳密な利用者認証を実現する。カード形状を採用することで、学生証・教職員証、図書館貸出カードなど複数のサービスが 1 枚に集約され、利用者の利便性と可搬性も得ることができる。
また、入退室管理にも利用できるようにすることで、情報セキュリティのみならず物理的セキュリティも確保可能とする。

5. まとめ
本稿では、大阪大学における PKI に基づく認証基盤システムの整備に向けた検討状況について述べた。本認証基盤の整備により、安全な学内の電子情報、オンライン情報の取り扱いが可能となり、学内の研究・教育環境の発展を支えていく非常に重要な基盤技術のひとつであると考えている。

4. 関連する認証システム
4.1. 全国共同利用システムにおける認証サイバーメディアセンターは、全国共同利用施設であり、スーパーコンピュータ等の計算資源を全国の利用者に提供している。計算資源提供方法のうち、グリッドによる資源提供およびユーザによる資源利用の際には、証明書を用いて認 証を行いながら 複数の組織を利 用してジョブ実行を行う。そのため、学内認証基盤とは異なる計算資源用の認証局や証明書の発行、管理を行うシステムを構築している。これらの認証局は NAREGI-CA ソフトウェアを用いており、学内に準備した物理的にセキュリティの高い部屋に設置している。
また、学内認証基盤と連携して、例えば、学内の利用者については学内の個人証明書を利用した計算資源用証明書の発行などができる

参考文献[1] B. Ramsdell, “Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.1
Message Specification,” RFC3851 (2004)[2] AICPA, WebTrust Program for Certification
Authorities, http://www.webtrust.org/.
[3] 大西克彦, “大阪大学における基礎データ収集のためのデータベース構築事例,” 大学評
価（大学評価・学位授与機構 研究紀要）, 第3 号, pp.21-30 (2003)

6