シス

テ

ム 技 術 分 科 会

選 出2008 年度 システム技術分科会 第 1 回会合 より

日本大学における SaaS の導入－Google との協調による「NU-AppsG」の導入経緯・運用について－

日本大学総合学術情報センター
吉田 誠、 相川 成周

日本大学におけるSaaSの導入～Googleとの協調による「NU-AppsG」の導入経緯・運用について～

日本大学総合学術情報センター
情報企画課課長吉 田

日本大学について
z１４学部７９学科２０研究科
z学生数
約８１，０００人
z教職員数 約 ８，０００人

誠

法学部
郡山

大宮キャンパス
松戸歯学部

理工学部

東北新幹線

船橋キャンパス

芸術学部
所沢キャンパス

工学部
医学部

薬学部
法学部

芸術学部

経済学部

江古田キャンパス
歯学部
理工学部 駿河台キャンパス
通信教育部
文理学部

商学部
生産工学部
実籾キャンパス

国際関係学部

生物資源科学部

生産工学部

東
京

津田沼キャンパス
東海道新幹線
三
島

組

織

図

日本大学総合学術情報センターの役割
z本学の情報受発信基地としての役割
z情報関連の企画・立案
z学内ﾈｯﾄﾜｰｸやｼｽﾃﾑの管理・運用・保守
z映像制作・配信拠点（日大テレビ・遠隔授業）
z学術情報データベースの管理・運用・保守
zその他

部科校システムの統合化
学生向けサービス
メールシステム
NU-mailG
ｳｪﾌﾞｱﾌﾟﾘｹｰｼｮﾝｼｽﾃﾑ NU-AppsG
就職支援システム
NU就職ナビ
教職員ポータルシステム
情報共有システム「事務の友」
その他システム
入試願書一括受付システム，
全学共通図書システムetc..

→統合化することにより，経費節減を図っている

NU－AppsG（学生サービス向け）導入経緯
z導入前は学部独自でメールシステムを構築
課 題 点¾非効率なメールシステムの運用・管理¾システム管理経費の無駄遣い¾セキュリティレベルがまちまち¾学生サービスのレベル格差が著しい¾その他

導入までの流れ
2006年
z 9月

ﾒｰﾙｼｽﾃﾑ開発ﾜｰｷﾝｸﾞﾁｰﾑ立上げ

z11月

ﾜｰｷﾝｸﾞﾁｰﾑにてGoogle導入を決定

z12月中旬 常務理事会等諸会議にて導入承認

2007年
z1月 ｱｶｳﾝﾄ管理ｼｽﾃﾑ 構築開始
（2.5ヶ月で構築終了）
z3月 Google社と契約文書にて締結
4月 運用開始（８学部にて運用開始）
2008年
z4月 学部，研究科及び短期大学追加導入
現在：１１学部・４研究科・１短大・専門学校
にて運用中

NUメールのリースアップを機に，新システム移行の検討開始

検討テーマ「安全性・情報化経費節減・利便性・安定化・
学生サービス等の学部間格差の解消」①独自システム開発の検討②既存WEBサービスの活用
執行部の意識改革を求める！
メール送付は葉書郵便と同様である！！

学生データ提供プロセス
学生基本情報DB （全データ）
アカウント管理（IDデータ生成）システム
Googleメール（IDデータのみ提供）
システム

導入後の反響
zメディア取材
約２０社
z他大学からの問合せ 約３０校

今後の展開
z 全教職員向けて「NU-AppsG」の導入

zＮＵ－ＳＳＯの展開
図書・就職・ＳＮＳ・研究者情報等

ご静聴ありがとうございましたシ

ス

テム 技 術 分 科 会

選 出2008 年度 システム技術分科会 第 2 回会合 より

日本最大規模のキャンパス認証ネットワーク～HINET2007 の構築と運用～

広島大学情報メディア教育研究センター
西村 浩二

2009 年 1 月 29 日

サイエンティフィック・システム研究会
システム技術分科会 2008 年度第 2 回会合資料

日本最大規模のキャンパス認証ネットワーク～ HINET2007 の構築と運用 ～広島大学情報メディア教育研究センター
西村 浩二,
相原 玲二, 近堂 徹, 大東 俊博,
田島 浩一, 岸塲 清悟, 岩田 則和
kouji@hiroshima-u.ac.jp[Abstract]
広島大学では平成20 年度より新キャンパスネットワークHINET2007の運用を開始した。HINET2007では、全学約450 台のエッジスイッチが全学電子認証システムと連携してすべてのネットワーク利用者を認証するほか、全教員数に相当する約 2,000 個の独立したファイアウォール機能を有するなど、安全かつ柔軟な環境を提供している。
本報告では、HINET2007 の概要とその構築手法、それぞれの機能の性能評価の結果、移行を支援する体制やシステムについて述べる。
[Keyword]
利用者認証、仮想ネットワーク、アクセス制御、リナンバリング

1 はじめに大学などの高等教育研究機関では、さまざまな教育研究を実施するために高度かつ柔軟なネットワー
クが求められる。大規模な組織では、学部や学科などの部局単位でサブネットを構成し、サブネット内の管理運用は当該組織が責任を持つことを条件に、自由度の高い運用を許してきた経緯がある。
しかし、
ネットワークがライフライン化するにつれ、インターネット上で発生するセキュリティの問題も複雑化していることから、大幅な管理方針の見直しが迫られている。
このような背景のもと、広島大学では平成 19 年度からセキュアでスケーラブルなキャンパスネットワ
ーク HINET2007 の構築を開始し、平成 20 年 5 月から運用を開始した[1]。HINET2007 では、これまでの部
局単位でのサブネット管理体制から全学的な一元管理体制へ移行するとともに、利用形態により分類される「ゾーン」という概念を導入し、それぞれの目的に応じた学内外からのアクセス制御を提供する。
さらに、すべてのネットワーク接続点(ポート)において接続機器の利用者を特定するための認証を行うことで、セキュリティレベルの底上げ、維持を図っている。またこれらの運用管理を支援するための体制作りやシステムの開発を行っている。
本稿では、HINET2007 の概要と運用・移行の方針、設計・構築のポイント、移行の支援体制とシステ
ムについて述べる。

2 HINET2007 の概要
今回構築した HINET2007 の概要を図 1 に示す。主な特徴は以下のとおりである[2]。
(1) 全学的な一元管理体制
これまでのサブネット管理は多くがボランティアにより行われていた。その結果、サブネットにおいて発生したセキュリティの問題に対する責任の所在があいまいになったり、サブネットによって対応に違いが生じたりする原因となった。HINET2007 では全学的な一元管理体制をとるため、建物
集約スイッチやフロアスイッチの全ポートを管理対象とし、各部屋の情報コンセントへの接続状況を把握できるようにしている。
(2) VLAN による柔軟な仮想配線の提供
柔軟な組織体制で教育研究が行われる場合、同一の組織や研究グループが必ずしも同一の建物内や

フロアスイッチ（最寄のPS内など）
100Mbps～1Gbps

東広島キャンパス

SINET3SINET3などなど
霞キャンパス

建物集約スイッチ（主要建物内）
計画停電対策

対外接続ルータ

２重化により可用性向上

TagVLAN機能

キャンパス集約
10Gbpsスイッチ

データセンター内に設置

10Gbps

キャンパス間
光ファイバ
（整備済）
利用者認証
機能

キャンパス内基幹光ファイバ（整備済）

全キャンパス
合計約400台

部局整備・
部局管理

コアネットワーク装置（メディアセンター内）

キャンパス集約スイッチ

全学整備・全学管理

東千田キャンパス
部局整備・
部局管理

図 1 HINET2007 概要図
フロア内に分布しているとは限らない。HINET2007 では IEEE802.1q(Tag VLAN)を従来以上に積極的に活用し、地理的条件の影響を受けないネットワーク構築を可能としている。
(3) 個別ファイアウォール機能の提供
外部からのセキュリティの脅威からネットワーク機器を保護するため、研究室にファイアウォール
機能を持つ機器(ブロードバンドルータなどを含む)を設置するケースが多く見られた。しかし、複数の建物に部屋が分散している場合は機器間を VPN で接続するなど、設定や管理が煩雑であるという問題もあった。そこで HINET2007 では、約 2,000 個の個別ファイアウォールをネットワークの機能として提供している。
(4) すべての接続場所において利用者認証を要求
これまでサブネット管理者が行ってきた接続機器の管理を全学的な一元管理とするため、約 450 台のすべての建物集約スイッチとフロアスイッチに利用者認証機能を持たせ、ネットワークの利用に際して何らかの認証が要求されるようにしている。

3 管理・運用・移行の方針
3.1 ゾーン構成とアクセス制御
先に述べたように、HINET2007 では各部局等のセキュリティレベルの底上げと均一化を図るため、これまでのサブネット単位に分散した独自管理から全学的な一元管理へと大きく運用方針を転換した。これにともなって、利用形態により学内外からのアクセスの可否パターンで区別される「ゾーン」という概念を導入した。主要なゾーンは表 1 に示す 4 種類である。またこれらのゾーン間および外部ネットワーク(インターネット)間のアクセス制御の概要を図 2 に示す。IEEE802.1q を利用することで、ゾーンは
基本的にキャンパスや建物、フロアなどの地理的条件に影響を受けることなく、自由に構成することができる。
表 1 HINET2007 が提供するゾーン種別
ゾーン名
略称

グローバルゾーン
ゾーンA

ファイアウォールゾーン
ゾーンB

ローカルゾーン
ゾーンC

公衆ゾーン
ゾーンD

主な用途

学外向けサーバ接続

学内共有サーバ接続

一般クライアント接続

オープンスペース

外部IPアドレスグローバル 固定割当

グローバル 固定割当

グローバル 固定割当

グローバル DHCP割当

内部IPアドレス

外部IPアドレスと同じ

外部IPアドレスと同じ

プライベート（NAPT）
DHCPまたは固定割当

外部IPアドレスと同じ

ゾーン外からのアクセス

学内外とも制限なし

学外から不可ゾーンAを除く学内から可同一ローカルゾーン以外から不可

学外から不可ゾーンAを除く学内から可学外へのアクセス

制限なし

制限なし

原則制限なし（NAPTによる制限あり）

制限なし

端末認証

MACアドレス認証

MACアドレス認証

Web認証またはMACアドレス認証

Web認証

3.2 運用方針
表 1 に示すように、HINET2007 では原則としてすべての接続端末に認証が求められる。認証方式は Web
認証と MAC アドレス認証のいずれかで、ゾーンによって利用できる認証方式は異なっている。Web 認証
はネットワークを利用する都度 Web ブラウザを使用して利用者認証を行うが、MAC アドレス認証を行うには事前に利用者と被認証機器の MAC アドレスの対応を申請しておく必要がある。また図 2 におけるローカルゾーン(ゾーン C)では、約 2,000 個の個別ファイアウォール機能を提供している。基幹スイッチ
等の設定はあらかじめ行っておき、利用者の申請に応じてフロアスイッチ等の VLAN 設定を変更すること
で、希望する場所で個別ファイアウォール機能が利用できるようにしている。ただし、ファイアウォー
ルのポリシー設定については以下のような運用方針を定めている。
z 個別ファイアウォールの例外設定(特定ポートへのアクセス許可など)は受け付けない。
z 個別ファイアウォールのローカル側／グローバル側アドレスの希望は受け付けない(情報メディア教育研究センター(以下、メディアセンター)が指定)。
z 希望すればフロアスイッチの下流ポートへ Tagged で接続ができるが、VLAN ID の希望は受け付けない(メディアセンターが指定）。

インターネット

グローバルゾーン（ゾーンA）
全学ファイアウォール（ＩＰアドレスは維持）
外部IPアドレス
はゾーンにつき１個（固定）

個別ファイアウォール（ＮＡＰＴ）

IP固定 / MAC認証

×ファイアウォールゾーン（ゾーンB） IP固定 / MAC認証

××
公衆ゾーン（ゾーンD）
DHCP / Web認証

内部IPアドレス
はゾーンにつき約250個（最大）ローカルゾーン（ゾーンC）
DHCP / Web認証、IP固定 / Web認証
DHCP / MAC認証、IP固定 / MAC認証※ローカルゾーンからグローバルゾーン
およびインターネットへのアクセスは、
全学ファイアウォールをバイパスする。

図 2 ゾーン間のアクセス制御
3.2 運用方針
HINET2007 はこれまでのキャンパスネットワークに比べて、全端末の IP アドレスのリナンバリングが必要である、ネットワークの利用に先立って認証が必要であるなど、運用方法が大幅に異なるため、全学が一括して移行することは困難であると判断した。そのため、既存の HINET2001 との並行運用期間を定めた上で、その期間内で利用者が研究科や専攻、研究室の単位で移行時期を決定できるようにした。
並行運用の期限は 2008 年度末としており、2009 年 3 月末に HINET2001 を停止する予定である。
具体的な移行作業は、フロアスイッチ等の設定変更とフロア配線の差し替えである。フロアスイッチ
等の設定変更にはコネクタの指定を受けるための申請、ゾーンの指定を受けるための申請、そしてコネクタとゾーンとを関連づけるための申請の3 つのステップが必要であるが、手続きの詳細についてはMAC
アドレスの登録を含めて後述する。フロア配線の差し替えについては、ほとんどの場合はフロア内の最寄りのパイプスペースに新旧のスイッチが設置されているため、すべての申請が完了した後、利用者の都合がよいときに旧スイッチから新スイッチへ配線を差し替える。その後その配線に接続されている機器の IP アドレスを変更し、接続テスト(認証テスト)が完了すれば移行が完了となる。

4 設計・構築のポイント
本節では、HINET2007 を設計・構築する際に特に考慮した事項について概要を述べる。個々の事項の詳細については、それぞれで引用されている文献を参照されたい。
4.1 個別ファイアウォール機能の実現
HINET2007 のコアネットワーク装置周辺の構成を図 3 に示す。装置やリンクの故障に備えて、基幹部
分は概ね二重化されている。さらに L3 コアスイッチの内部構成を図 4 に示す。今回導入した L3 コアス
イッチ(Cisco Catalyst 6509)には、ファイアウォールモジュール(FWSM)を 3 基搭載している。さらに 2
つの独立した L3 機能(VRF と MSFC)とポリシールーティングを駆使して、各ゾーンに提供する接続性(アクセス可否の制御)を実現した。L3 コアスイッチに搭載する FWSM は、1 基を全学ファイアウォール用、2基を個別ファイアウォール用に割当てている。FWSM は 1 基あたり、20 の仮想ファイアウォール(VFW)が設定可能であり、それぞれの VFW には 50 の内部ネットワーク(内部インタフェース)が設定できる。FWSM
を 2 基使用することで、2,000 の内部ネットワークを構成した。ただしこの方法では、同一 VFW の内部
ネットワーク間は VFW のルーティング機能により通信可能となるため、互いの内部ネットワークが通信できないようにフィルタを設定している。各内部ネットワークは一部の例外を除いて /24 のサイズであり、原則として DHCP 機能が提供されている。外部へは NAPT 機能によりそれぞれ異なる外部 IP アドレスに変換されてアクセスを行う。
対外接続
ルータ

10Gbps
1Gbps

SINET3, 商用ISP等
L3コアスイッチ（２重化）

IPv4 L3
全学ファイアウォール
個別ファイアウォール
IDS, IPS

DHCP
Radius (MAC)

リンク
アグリゲーション

Radius (Web)
筐体内
２重化

フロアスイッチ

建物集約スイッチ

キャンパス集約スイッチ

Log
ネットワークサーバ（２重化）

図 3 基幹ネットワーク構成図

対外接続ルータ

L3コアスイッチ

ネットワーク
サーバ群

全学FW
サーバ接続スイッチ

L3 (VRF)

L3 (MSFC)

スイッチ管理用VLAN

個別FW
個別FW
VLAN ID
1600～
1699

全学FW (2001)
1800～
1899

2000～
3999

1700～
1799

建物集約/ﾌﾛｱｽｲｯﾁ

建物集約/ﾌﾛｱｽｲｯﾁ

建物集約/ﾌﾛｱｽｲｯﾁ

建物集約/ﾌﾛｱｽｲｯﾁ

ゾーンA

ゾーンB

ゾーンC

ゾーンD

L3スイッチ (2001)

HINET2001

図 4 L3 コアスイッチ設定概要図
コアネットワーク装置の設計にあたっては、ファイアウォールが通信に与える影響を調べるため、
HINET2007 導入の前後で通信速度の測定を行った[3]。HINET2007 を導入することによる HINET2001 への影
響は見られなかった。HINET2007 導入後の測定結果を図 5 に示す。利用者はクライアント 1,2 の環境からクライアント 3,4,5 の環境に移行することになる。クライアント 1, 2 からクライアント 3,4 へはほぼ

202.15.112.69
対外接続ルータ

ゾーンA

サーバA

クライアント３
ゾーンB

クライアント４

L3(VRF)
全学FW

ゾーンC

クライアント５

L3コア
スイッチ
個別FW

L3(MSFC)

133.41.17.238

サーバB

全学FW
(2001)

グローバル

クライアント１
全学FW(2001)配下

クライアント２L3スイッチ(サーバ接続)L3スイッチ(2001)

TCP（iperfによる30秒 3回測定平均）：Mbps
サーバA

サーバB

送信

受信

送信

受信

クライアント１

471

517

704

709

クライアント２

--

365

691

615

クライアント３

637

685

712

878

クライアント４

--

348

696

801

クライアント５

--

292

--

433

図 5 スループット(HINET2007 移行後)同様な結果となっているが、クライアント 5 の通信速度はやや低くなっている。これは 1 基の FWSM に
20 の VFW を設定し、1,000 の内部ネットワークを構成しているためと思われるが、実用上は問題ないと判断している。
4.2 利用者認証機能の実現
移行が完了するとHINET2007は広島大学の構成員約20,000名が日常的に利用する認証ネットワークとなる。認証システムの設計においては、次の 2 点を特に考慮した。1 点目は、大学には新旧さまざまな
OS、ネットワーク機器が混在している点である。広島大学では、以前より利用者認証機能を持つ情報コンセントシステムの開発、運用を行っていた経験[4]から、Web ブラウザを用いた利用者認証を基本とし、Web ブラウザを持たない機器に対しては利用者を特定した上で Mac アドレス認証を行うこととした。2
点目は、事務職員が利用する事務用端末の起動時間が始業時間前後に集中するという点である。図 6 に
HINET2001 において観測した端末増減数の時間推移を示す。この結果から、8 時 20 分から 35 分の 15 分
間に約 600 台の端末が接続されていることがわかる。またこの負荷は一部(事務棟)の認証スイッチに集中するため、認証スイッチ自身の性能も考慮する必要がある。
300

端末の増減数(差分) [台/5分]

250
200
150
100
50
0
-50
-100
7:00

8:00

9:00

10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00

時間

図 6 HINET2001 における端末の増減数

これらの要件を実現するため、図 7 に示す認証システムを構築した。DHCP サーバは約 2,000 の各ゾーンに対して最大 120 アドレスを割当てる機能を、ログサーバはフロアスイッチの認証ログやファイアウォールログを保存する機能を提供する。ホスト登録装置および Radius サーバは、MAC アドレス登録および利用者認証で利用する。各サーバは高可用性が要求されるため、HA(High Availability)クラスタを構成し、冗長化されている。フロアスイッチ(Alaxala AX2430S)は認証機能を持つ L2 スイッチで、本スイッチの各ポートが認証ポイントとなる。Web 認証と MAC アドレス認証に対応し、Web 認証では外部 Web
ページへのアクセスが認証ページにリダイレクトされる。
認証ページは https 接続でのみ提供しており、
約450 台の認証スイッチが使用するサーバ証明書には国立情報学研究所のサーバ証明書プロジェクト[5]が発行する中間 CA 証明書を採用した。
HAクラスタData replication

ログサーバ1Radiusサーバ１ Radiusサーバ２(Web認証用)(Web認証用)

ログサーバ2

ログ統計分析サーバ
VLAN管理用サーバ

ActiveStand-by

サーバ集約
スイッチ

HINET2007
ネットワーク監視サーバ

ActiveActiveStand-by

Radiusサーバ１ Radiusサーバ２(MAC認証用)(MAC認証用)

Activeホスト登録装置1 ホスト登録装置2

Data replication

HAクラスタStand-byStand-by

DHCPサーバ1

DHCPサーバ2

Data replication

Data Synchronize

HAクラスタ

HAクラスタ

図 7 認証システムの構成構築する認証システムが要求どおりに機能することを確認するため、仕様策定段階あるいは構築段階において、以下の性能評価を行った[6]。
(1) DHCP サーバの IP アドレス払い出し性能
同時リクエスト数を変化させて、すべてのリクエストへの応答が完了するまでの時間(最小／平均／最大)を測定した。測定結果を図 8 に示す。この結果から、450 台からの同時リクエストに対して最大 0.12 秒以内に処理が完了していることがわかる。
0.14

アドレス取得時間 [秒]

0.12
0.1
0.08
0.06
0.04
0.02
0
0

50

100

150

200
250
300
DHCPクライアント数350

図 8 DHCP サーバの応答時間

400

450

500

(2) Radius サーバの同時認証性能
Web 認証用 Radius サーバは外部 LDAP を、
MAC アドレス認証用 Radius サーバは内部 LDAP を参照する
ため、それぞれについて同時リクエスト数を変化させて、すべての認証が完了するまでの時間(最小／平均／最大)を測定した。測定結果を図 9 に示す。この結果から、600 台の同時認証でも 1 秒以内に処理を完了できる性能を有することがわかる。

a) RADIUS認証に要する平均時間 （内部DB参照）
0.02
0.018

認証時間 [秒]

0.016
0.014
0.012
0.01
0.008
0.006
0.004
0.002
0
0

50

100 150 200 250 300 350 400 450 500 550 600 650
リクエスト数b) RADIUS認証に要する平均時間（外部DB参照）

0.18
0.16

認証時間 [秒]

0.14
0.12
0.1
0.08
0.06
0.04
0.02
0
0

50

100 150 200 250 300 350 400 450 500 550 600 650
リクエスト数

図 9 Radius サーバの応答時間(3) 認証スイッチの同時認証性能
クライアントから http による外部 Web ページへのアクセス、
フロアスイッチ内の認証ページへのリダイレクト、https(鍵長 2,048 ビット)による認証情報の送信、認証応答メッセージの受信までの時間の和を認証時間とし、同時認証セッション数を変化させて、すべての認証が完了するまでの時間(最小／平均／最大)を測定した。測定結果を図 10 に示す。この結果から、同時 100 セッションの認証要求に対しても最大 23 秒程度で処理が完了できることがわかる。
以上の評価結果から、事務用端末の一斉認証要求のような状況においても実用的な時間で認証処理を完了できることが確認できた。

25

認証時間 [秒]

20
15
10
5
0
0

20

40

60

80

100

認証セッション数

図 10 同時認証セッションに対する応答時間(https 接続，鍵長 2,048 ビット)

5 移行の支援体制とシステム
5.1 申請手順
ゾーン C を利用するには、コネクタ ID 申請、ゾーン C 仮割当申請、ゾーン C 本割当申請の 3 つが必要であり、図 11 のような手順で申請する[7]。HINET2007 では建物集約スイッチ、フロアスイッチの各ポー
トまでを一元的に管理するため、スイッチとポートにスイッチ ID とコネクタ ID と呼ぶユニークな識別
番号を付している。利用者はコネクタ ID 申請において最寄りのスイッチ ID を指定するとポートが割り当てられ、コネクタ ID の通知と同時にコネクタ ID が印刷されたシールが送付される。利用者は指定されたポートに接続したフロア配線の情報コンセントにそのシールを貼り付け、以後のゾーン C 本割当申請でポートを指定するために使用する。ゾーン C 仮割当申請では VLAN ID の割当を行い、ゾーン C 本割
当申請ではコネクタ ID の VLAN ID への対応付けと、必要に応じて MAC アドレス認証をするためのホスト登録を行う。一方、ゾーン A,B はコネクタ ID 申請の後、ゾーン C 本割当申請と同様な処理を行う。なお、
ゾーン A,B は MAC アドレス認証のみである。

図 11 コネクタ ID とゾーン C の申請手順

5.2 支援体制
これまで支線ネットワークの整備およびサブネットの管理はそれぞれの部局等で独自に行われてきたことから、移行段階においてはさまざまな例外処理が必要になることが予想されたため、人手による申請受付を行うこととした。
コネクタ ID 申請およびゾーン申請は Excel で書かれた申請書に必要事項を記入し、電子メールで受付アドレスに送付する。メディアセンターでは教員 5 名が日替わりで受付処理を担当し、設定担当(外注業者)に指示している。申請書およびコネクタ ID やゾーンの管理台帳は WebDAVを利用して共有し、受付処理担当、設定担当および移行支援担当が常時参照できるようにしている。
設定が完了した後の HINET2001 から HINET2007 への接続変更、IP アドレスの変更は現場での作業となる。これらの作業は原則として申請者本人が行うこととしているが、申請者からの要請があった場合にはメディアセンターの職員のほか、技術センターの職員が支援を行う体制を構築した。技術センターには学内の全技術職員が所属し、派遣先の部局等でそれぞれの専門に基づいた技術支援業務を行う組織である。技術センター職員は全学に分散配置されており、派遣先の事情に詳しいため、彼らの力を有効活用することとした。HINET2007 の仕様が確定した約 1 年前から、技術センターの職員に対して新旧ネッ
トワークの違い、新ネットワークの特徴、運用方針などの講習会を実施して移行開始に備えた。

5.3 ホスト登録システム
移行段階ではコネクタ ID の割当、ゾーンの割当などを集中的に行うため、人手による受付処理を行っているが、申請から完了までに最大 2 営業日かかる。そのため、ゾーン C 移行後の認証方式の変更(Web認証から MAC アドレス認証へ)、ゾーン A,B のホストの入れ替え(MAC アドレスの変更)などの軽微な変更については、申請後すぐに変更が反映されるようホスト登録システムを構築した。管理者または副管理者は、利用者認証の後に自らが管理するゾーン C あるいはゾーン A,B のホストの属性(現在は MAC アドレ
スのみ)を変更できるようになっている。ホスト登録システムには、ゾーン C の申請を受け付け、VLAN ID
や IP アドレスの割り当てを行い、コネクタ ID の対応付けを行って、設定担当に設定依頼を自動的に送付する機能も持たせているため、移行期間終了後は順次機能の提供を開始する予定である

6 おわりに
本稿では、広島大学で構築した新キャンパスネットワーク HINET2007 の特徴、運用・移行の方針、設計・構築のポイント、移行の支援体制とシステムについて概要を述べた。HINET2007 の構築手法は、教育研究を遂行する上での自由度を一定のレベルで維持しつつ、全体的なセキュリティレベルの底上げを図る現実的なひとつのモデルとなると考えている。最後に、2008 年 5 月(申請受付は 4 月)から開始した移行の状況は表 2 のようになっており、2008 年 12 月末現在でコネクタ ID 登録数は 3,798、ゾーン C 割
当数は 832 である。一方、HINET2001 の残存ホスト数は図 12 のように推移しており、移行のペースが鈍ってきているため、2009 年 3 月末の HINET2001 停止に向けて各サブネットの管理者に残存ホスト(MAC
アドレス)の一覧を送付し、ラストスパートを呼びかけているところである。
［謝辞］
HINET2007 の構築および移行、運用に尽力いただいている広島大学総務室情報化推進グループ、技術センターおよび情報メディア教育研究センターの関係者に感謝します。
表 2 HINET2007 の移行状況
4月

5月

6月

7月

8月

9月

10月

11月

12月

申請メール受付数

28

126

100

140

173

183

110

100

126

コネクタ登録数

-

520

95

1215

608

493

230

178

530

コネクタ削除数

-

28

2

1

6

20

14

0

0

アドレス登録数

-

290

215

1044

745

934

354

173

83

アドレス削除数

-

8

11

16

9

32

34

10

2

ゾーンC割当数

76

322

56

36

154

61

42

33

52

1月

2月

3月

図 12 HINET2001 の接続ホスト数の状況

参考文献[1] 広島大学情報メディア教育研究センター：“HINET2007 情報”, http://home.hiroshima-u.ac.jp/infra/hinet2007info/．
[2] 相原 玲二, 西村 浩二, 岸塲 清悟, 田島 浩一,近堂 徹, “利用者認証機能を持つ大規模キャンパスネ
ットワークの構築”, 2008 年電子情報通信学会総合大会, BS-8-7, pp.S-116-S117（2008 年 3 月）．
[3] 相原 玲二, 西村 浩二, 近堂 徹, 岸塲 清悟,田島 浩一, “全教員に個別ファイアウォール機能を提供するキャンパスネットワークの構築”,情報処理学会研究報告, 2008-IOT-2-6,pp.29-34（2008 年 7 月）．
[4] 西村 浩二, 秋成 秀紀, 野村 嘉洋, 相原 玲二,“遠隔機器制御プロトコルを用いた有線／無線 LAN 用
情報コンセントシステム”, 情報処理学会論文誌, Vol.43, No.2, pp.662-670（2002 年 2 月）．
[5] 国立情報学研究所 UPKI イニシアティブ：サーバ証明書発行・導入における啓発・評価研究プロジェク
ト, http://upki-portal.nii.ac.jp/cerpj．
[6] 近堂 徹, 田島 浩一, 岸塲 清悟, 大東 俊博,岩田 則和, 西村 浩二, 相原 玲二, “利用者認証機能を備えた大規模キャンパスネットワークの性能評価”, 情報処理学会第 1 回インターネットと運用技術シンポジウム（IOTS2008）,pp.121-128（2008 年 12 月）．
[7] 大東 俊博, 近堂 徹, 岸塲 清悟, 田島 浩一,岩田 則和, 西村 浩二, 相原 玲二, “広島大学における新キャンパスネットワークへの移行手法”, 情報処理学会研究報告, 2008-IOT-3-6,pp.31-36（2008 年
9 月）．

2009年1⽉29⽇
サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

本報告の内容• HINET2007の構築と運⽤– 導⼊の背景– 概要と特徴– 管理・運⽤・移⾏の⽅針– 設計・構築のポイント– 移⾏の⽀援体制とシステム– 移⾏の進捗状況

⽇本最⼤規模のキャンパス認証ネットワーク〜HINET2007の構築と運⽤〜

⻄村 浩⼆，相原 玲⼆，近堂 徹，⼤東 俊博，
⽥島 浩⼀，岸塲 清悟，岩⽥ 則和
広島⼤学 情報メディア教育研究センター

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

2009年1月29日

キャンパス情報ネットワーク HINET2007

大学等のネットワークに対する要求

フロアスイッチ（最寄のPS内など）• ⾼度で柔軟なキャンパスネットワーク

100Mbps～1Gbps

東広島キャンパス
建物集約スイッチ（主要建物内）– 学部、学科、研究室等の単位でサブネット構築– ⽬的に応じて⽐較的⾃由な運⽤
VLAN機能VLAN機能キャンパス間光ファイバ（整備済）キャンパス集約スイッチ

コアネットワーク装置（メディアセンター内）

東千田キャンパス

全学整備・全学管理

部局整備・
部局管理

- 主要3キャンパス（東広島、霞、東千⽥）、附属学校、
⼩規模遠隔部局（東京，福⼭，尾道，⽵原，呉，宮島）

3・ 教員約1,800⼈、職員約3,300⼈、学⽣15,000⼈
サイエンティフィック・システム研究会
・
フロアスイッチ約400台（約14,000ポート）を全学整備
2009年1月29日
4
2008年度システム技術分科会第2回会合「ゾーン」の導入

HINET2007の特徴• 全学的な⼀元管理体制– ボランティアベースによるサブネット管理体制の破綻– 各フロアに設置するスイッチまで全学で⼀元管理– 同⼀研究室（グループ）が異なる建物等に分散する場合に対応– 学外向けサーバの設置、JGN2plusなどの利⽤に対応

グローバルゾーン
ゾーンA

主な⽤途

学外向けサーバ接続 学内共有サーバ接続 ⼀般クライアント接続 オープンスペース– 全学ファイアウォール（対学外）のみでは不⼗分– ブロードバンドルータ相当の機能を教員数程度（約2,000個）
提供• すべての接続場所において利⽤者認証を要求

固定割当

グローバル

固定割当

グローバル

固定割当

外部IPアドレスと同じ

外部IPアドレスと同じ

ゾーン外からのアクセス

学内外とも制限なし

学外から不可ゾーンAを除く
学内から可

同⼀ローカルゾーン以外
から不可

学外への
アクセス

制限なし

制限なし

原則制限なし（NAPTによる制限あり）

MACアドレス認証

Web認証またはMACアドレス認証

端末認証– 多様な機器に対応するためWeb／MACアドレス認証を採⽤– 認証後はワイヤレートでの通信が必要

グローバル

ローカルゾーン
ゾーンC

プライベート（NAPT）
DHCPまたは固定割当

内部IPアドレス• 個別ファイアウォール機能の提供

ファイアウォール
ゾーン
ゾーンB

ゾーン名
略称

外部IPアドレス• VLANによる柔軟な仮想配線の提供

2009年1月29日

10Gbps・2008年5⽉から本格移⾏開始
・規模– 研究室は独⽴した企業活動（教員は社⻑）– しかし、外部からは同⼀組織とみなされる– さらに、経営の効率化を求められる

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

全キャンパス合計約400台部局整備・
部局管理

キャンパス内基幹光ファイバ（整備済）

霞キャンパスキャンパス集約スイッチ

10Gbps対外接続ルータ

全キャンパス合
計約40台

利用者認証
機能

• 管理⽅針の根本的な⾒直しサイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

SINET3SINET3などなど
データセンター内に設置

計画停電対策２重化により可用性向上

ネットワークのライフライン化
セキュリティインシデントの多発2009年1月29日

2

MACアドレス認証

公衆ゾーン
ゾーンD

グローバル

DHCP割当外部IPアドレスと同じ
学外から不可ゾーンAを除く
学内から可
制限なし
Web認証

これまでのサブネット構成とは異なる
5

2009年1月29日

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

6ゾーン種別とアクセス制限

運用と移行の方針

インターネット
インターネット

IP固定（グローバル）
MAC認証• 運⽤⽅針– 個別ファイアウォールの例外設定は⾏わない• テレビ会議装置はグローバルゾーン（ゾーンA）に置く、など• 利⽤者が適切なゾーンを選択し、⾃⼰責任で守る

グローバルゾーン（ゾーンA）
グローバルゾーン（ゾーンA） VLAN1600～1699

×

全学ファイアウォール
外部IPアドレス
はゾーンにつき１つ（固定）

IP固定（グローバル）
MAC認証

ファイアウォールゾーン（ゾーンB）
ファイアウォールゾーン（ゾーンB） VLAN1700～1799

×

×

個別
ファイアウォール
（ＮＡＰＴ）• 仮想ポート（1本の物理配線に複数のゾーンを載せることが可能）• 移⾏⽅針公衆ゾーン（ゾーンD）
公衆ゾーン（ゾーンD）– 移⾏期間は平成20年度末（2009年3⽉末）まで

VLAN1800～1899
内部IPアドレス
はゾーンにつき約250個（最大）

DHCP（グローバル）
Web認証

最大2000
ローカルゾーン（ゾーンC）
ゾーン
DHCP or IP固定（ローカル）
VLAN2000～3999
Web認証 or MAC認証• 期間中はHINET2001とHINET2007を並⾏運⽤– IPアドレスのリナンバーが必要• 移⾏はポート単位で可能※ローカルゾーンからグローバルゾーン
およびインターネットへのアクセスは、
全学ファイアウォールをバイパスする。

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

2009年1月29日– 個別ファイアウォールのローカル側／グローバル側のＩＰアド
レスの希望は受け付けない– 希望すればスイッチの下流ポートへVLANをTaggedで提供（ただしVLAN IDはメディアセンターが指定）

7

基幹ネットワークの物理構成

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

2009年1月29日

L3コアスイッチの設定

対外接続
ルータ

10GbpsL3コアスイッチ

サーバ接続スイッチ

L3 (VRF)

スタンバイ

DHCP

スイッチ管理用VLAN

個別FW

筐体内
２重化

建物集約/ﾌﾛｱｽｲｯﾁ 建物集約/ﾌﾛｱｽｲｯﾁ 建物集約/ﾌﾛｱｽｲｯﾁ 建物集約/ﾌﾛｱｽｲｯﾁ

ネットワークサーバ（２重化）
ゾーンA

IPv4 L2
IPv6 L3
サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

9△：同一ゾーンC内ではアクセス可、異なるゾーンC間ではアクセス不可

ゾーンA

ゾーンB

ゾーンC

ゾーンD

全学
サーバ

2001
Global

2001
FW

学外

ゾーンA

○

×

×

×

○

○

×

○

ゾーンB

○

○

×

○

○

○

○

○

ゾーンC

○

○

△

○

○

○

○

○

ゾーンD

○

○

×

○

○

○

○

○

全学サーバ

○

○

×

○

○

○

○

○

HINET2001
Global

○

○

×

○

○

○

○

○

HINET2001
FW

○

○

×

○

○

○

○

○

学外

○

×

×

×

○

○

×

－

2009年1月29日

ゾーンC

ゾーンD

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

2009年1月29日

外部

10

スタンバイ

FWSM

11

FWSM

20

20

VFW
VFW

VFW
VFW

VFW
VFW

VFW
VFW

50

50

50

50

内部

全学サーバ： 全学電子認証システムなど全学的サーバ接続用
HINET2001 Global： HINET2001の全学ファイアウォールに入っていないサブネット
HINET2001 FW： HINET2001の全学ファイアウォールに入っているサブネット

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

ゾーンB

HINET2001

個別ファイアウォールの構成

HINET2007 / HINET2001間のアクセス
X

1800～
1899

2000～
3999

1700～
1799

L3スイッチ (2001)

Log

キャンパス集約スイッチ

X → Y 方向のアクセス可否

全学FW (2001)

個別FW

VLAN ID
1600～
1699

Radius (Web)

建物集約スイッチ

L3 (MSFC)

Radius (MAC)

リンク
アグリゲーション

Y

全学FW

L3コアスイッチ（２重化）

IPv4 L3
全学ファイアウォール
個別ファイアウォール
IDS, IPS

2009年1月29日

ネットワーク
サーバ群

対外接続ルータ

SINET3, 商用ISP等

1Gbps

フロアスイッチ8

2009年1月29日

2000 (VLAN ID: 2000～3999)
FWSM: 物理FW（ルータ内蔵モジュール）

VFW：仮想FW

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

12

移行前（HINET2001）の通信性能測定

仮想ファイアウォールの設定
外部

NAPTの設定
FWSM

VFW

VLAN 内部ネットワーク

外部IPアドレス2050

133.41.74.72

10.20.50.0 /24

2051

10.20.51.0 /24

133.41.74.73

2052

10.20.52.0 /24

133.41.74.74

2053

10.20.53.0 /24

133.41.74.75

:

:

:

2099

10.20.99.0 /24

133.41.74.121

133.41.10.40
グローバル

サーバA

全学FW
(2001)

クライアント１

L3スイッチ(サーバ接続)L3スイッチ(2001)

133.41.10.88

サーバB

全学FW(2001)配下

クライアント２
TCP（iperfによる30秒 3回測定平均）：Mbps
サーバA

フィルタの設定
内部ネットワーク間の通信不可

サーバB

送信

受信

送信

受信

クライアント１

505

444

672

620

クライアント２

--

360

680

645

133.41.74.64 /26
50

測定項目：
クライアント・
サーバ間のTCPデータ
転送性能
133.41.17.238

202.15.112.69

対外接続ルータ(2001)

内部
サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

2009年1月29日

13

2009年1月29日

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

14

利用者認証機能に対する要件（１）

HINET2007移行後の通信性能測定
202.15.112.69
対外接続ルータ

ゾーンA

測定項目：
クライアント・
サーバ間のTCPデータ133.41.17.238
転送性能

サーバA

クライアント３
ゾーンB

クライアント４

L3コア
スイッチ

L3(VRF)
全学FW

ゾーンC

個別FW

L3(MSFC)

クライアント５
グローバル

L3スイッチ(サーバ接続)全学FW(2001)

クライアント１
クライアント２

サーバA
送信

受信

471

517

704

709

クライアント２

--

365

691

615

クライアント３

637

685

712

878

クライアント４

--

348

696

801

クライアント５

--

292

--

433

クライアント１

2009年1月29日• ダムハブなども多数存在

サーバB
受信

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合• 複数OSが混在（Windows, Linux, Mac OS X/9など…）• PC以外のネットワーク機器も認証– 認証後でもワイヤスピードを確保

TCP（iperfによる30秒 3回測定平均）：Mbps
送信– 多様な機器に対応– 既存の研究室内ネットワークとの親和性

個別FW（約2000）の設定済
VLAN2000～3999の割当済

L3スイッチ(2001)

全学FW(2001)配下

サーバB• ネットワークインフラとしての認証ネットワーク• 認証を⼊れることによるパフォーマンス低下は×15

利用者認証機能に対する要件（２）2009年1月29日

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

16

利用者認証の概要
管理サーバ群（認証DBなど）• 短時間での⼀⻫認証要求への対応– 共同利⽤施設（演習⽤端末室）や事務職員⽤端末

NII UPKIイニシアティブが提供する中間CA証明書を利⽤（全フロアスイッチに導⼊）• 広島⼤学には事務職員⽤端末が約1,400台存在

Web認証

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

HINET2007

利用者

httpsによる利⽤者認証
初回接続時に認証ページをリダイレクト表⽰
全学電⼦情報基盤で管理するIDを利⽤
ARPポーリング/リンクダウンによるログアウト

HINET2001における端末増減数（５分間隔）※2007年1⽉29⽇（⽉）に採取
2009年1月29日※後ほど説明中間CA証明書172009年1月29日

フロアスイッチ

登録したMAC
全学認証システム
アドレスとVLANのIDとパスワード-IDで認証を利用

ネットワーク機器

MAC認証

MACアドレスは事前登録（登録システムを利⽤）
Web認証が困難な機器を対象（プリンタ，NAS等）

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

18

HINET2007サーバ群の構成
HAクラスタ

DHCPサーバのIPアドレス払い出し性能
駆動系

HAクラスタ

MACアドレス情報

Data
Synchronization

IPアドレス
払出情報

OpenLDAP(Slave)OpenLDAP(Slave)BerkeleyDB

スタンバイ

BerkeleyDB

ログ収集サーバ
ネットワーク監視サーバ

Radiusサーバ2（MAC認証用）

DHCPサーバ１– 計測⽤PCを稼働中のフロアスイッチに接続– 複数DHCPリクエストを同時に送信• PerlのDHCPクライアントライブラリを利⽤• 異なるMACアドレスでDHCP DISCOVERを送信

Data
Replication

Radiusサーバ1（MAC認証用）• 実験概要DHCPサーバ２– DHCPリクエストからアドレス取得時間までを計測
Data
Replication

MACアドレス
情報• DHCP-DISCOVER から DHCP-OFFER• DHCPサーバのIP払出しDB更新を含む

Data
Replication

広⼤ID情報

計測用PC
OpenLDAP(Master)

OpenLDAP(Master)

OpenLDAP(Slave)OpenLDAP(Slave)Data
Replication

ゾーン管理者
情報
PostgreSQL

PostgreSQL

Radiusサーバ1（WEB認証用）

ホスト登録装置2

2009年1月29日
HAクラスタサイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

DHCPサーバ

DHCP OFFER

Radiusサーバ2（WEB認証用）

CPU: Core2Duo 3GHz
Memory: 4GB
OS: Linux

HAクラスタホスト登録装置1

コアルータ

フロアスイッチ

DHCP DISCOVER

IMC LDAPサーバ（ゲストアカウント用）

全学電子認証システム（全学LDAPサーバ）

19

2009年1月29日

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

20

Radiusサーバの同時認証性能

DHCPサーバのIPアドレス払い出し性能• 実験概要– 計測⽤PCをサーバ集約スイッチに接続– 複数の認証リクエストを同時に送信• 異なるアカウント/パスワードで認証

ゲストアカウント情報

IMC LDAPサーバ（ゲストアカウント用）– 認証リクエストからRadiusサーバの応答時間まで計測• フロアスイッチでの認証は⾏われない– 内部DBと外部DBの場合で測定
計測用PC

外部DB（LDAP）参照

サーバ集約
スイッチ

内部DB（自LDAP）参照
広⼤ID情報OpenLDAP(Master)

認証要求
認証確認

Radiusサーバ1（WEB認証用）

CPU: Core2Duo 2.33GHz
Memory: 3GB
OS: Linux

2009年1月29日

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

21

2009年1月29日

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

22

認証スイッチの同時認証性能

Radiusサーバの同時認証性能• 実験概要– フロアスイッチを経由す
る同時Web認証性能– リダイレクトと認証処理時間の和を計算 Portal Server

フロアスイッチHINET2007

1000base-T × 4– 100個の個別リクエスト
内部DB参照（通常のWeb, MAC認証）

外部DB参照（ゲストのWeb認証）• IMCゲストアカウントを
利⽤– 同時接続セッション数• 1, 5, 10, 20, 30, 40, 81,
99– 認証リクエストは1秒以
内で同期
2009年1月29日

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

231000base-T

2009年1月29日

Diskless Linux : 34 machines
CPU: Pen-4 3GHz, Mem: 1GB
近堂ら，”PCクラスタによる認証スイッチの認証評価システム”,
2007-DSM-47(5), pp.25--30

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

24

認証スイッチの同時認証性能

現在の利用状況https接続証明書鍵⻑ 2,048bit

Web認証ログイン数 [台/5分]• Web認証の推移（5分間隔のログイン処理数）

時間

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

2009年1月29日

25

ネットワーク移行の概要（移行手順）

建物A

(4)

(3)

(4) 移行作業
・配線切替
・IPアドレスの
リナンバ

(3)

研究室A

2009年1月29日

メディアセンター
教員（5名交代制）
による申請受付

フロアスイッチ（HINET2007）

霞キャンパス(3) VLANを設定

コアネットワーク装置(3)
キャンパス集約スイッチ

研究室A
霞分室
(1)
(3)
サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

部局

部局

メディア
センター
コネクタID申請書

27

ポイント

2009年1月29日

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

28– 定常運⽤時での使⽤を想定• 移⾏初期は⼈海戦術による⼿動申請受付– 部局で連続したグローバルIPアドレスを取得したい（電⼦ジャーナル対策）

部局を
確認後
割り当て
本割当申請書（設定情報）の通知

2008年12月より、仮割当申請不要に本割当申請書
登録後
設定業者
へ依頼
設定完了通知サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

利用中

フロアスイッチ（HINET2001）• Webによる移⾏申請受付、設定変更の⾃動化

メディア
センター

申請者
コネクタID

研究室A
霞分室

ホスト登録システム

スイッチIDを確認後割り当て

本割当申請書差し替え

HINET2001との並行運用
利用者の都合が良いタイミングで移行可能

仮割当申請書コネクタIDの通知

メディアセンター・
技術センター職員による移行支援

建物集約スイッチ

コネクタIDとゾーンCの申請手順

2009年1月29日(1) コネクタ
ID申請

(3)

建物B
(4) 移行作業
・配線切り替え・IPアドレスのリナンバ(2) ゾーン申請
設定担当業者（外部委託）(3) VLANを設定

フロアスイッチ(2) ゾーン申請
・管理者情報・VLAN ID・設定コネクタ・MACアドレス登録

26

ネットワーク移行の概要（支援体制）

東広島キャンパス(1) コネクタ
ID申請

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

2009年1月29日

29• 2008年12⽉より
⼀部機能開放– 副管理者登録・変更– ホスト情報登録・変更・削除（ゾーンC）– MACアドレス登録・変更（ゾーンA,B）– 年度更新（ゾーンA,B）

2009年1月29日

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

30

移行進捗状況（2008年12月末現在）

ホスト登録システムの画面例

4⽉

5⽉

6⽉

7⽉

8⽉

9⽉

10⽉

11⽉

12⽉

申請メール受付数

28

126

100

140

173

183

110

100

126

108
6

コネクタID登録数

-

520

95

121
5

608

493

230

178

530

386
9

コネクタID削除数

-

28

2

1

6

20

14

0

0

71

MACアドレス登録
数

-

290

215

104
4

745

934

354

173

83

383
8

31

3⽉

計

-

8

11

16

9

32

34

10

2

122

ゾーンC割り当て数

76

322

56

36

154

61

42

33

52

832

ゾーンC
サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

2⽉

MACアドレス削除数

コネクタID 最⼤14,000ポート

2009年1月29日

1⽉

2009年1月29日

3,798ポート割当

最⼤2,000ゾーン

832ゾーン割当

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

32

まとめ

HINET2001 IP/MACアドレス数の推移• HINET2007の概要– 特徴• 全学的な⼀元管理体制• VLANによる柔軟な仮想配線の提供• 個別ファイアウォール機能の提供• すべての接続場所において利⽤者認証を要求– 管理・運⽤・移⾏の⽅針– 設計・構築のポイント

2009/4/20 頃

2009/5/15 頃• 個別ファイアウォール機能の実現– スループット測定• 利⽤者認証機能の実現– DHCPサーバのIPアドレス払い出し性能– Radiusサーバの同時認証性能– 認証スイッチの同時認証性能– 移⾏の⽀援体制とシステム– 移⾏状況

移行期限（2009/3/31）
サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

2009年1月29日

33

使用した機器の名称または仕様
装置

機器の名称または仕様

フロアスイッチ
建物集約スイッチ

Alaxala AX2430S

サーバ集約スイッチ
Radiusサーバ

CPU: Xeon X5355 2.66GHz x 2, Memory: 4GB
FreeRADIUS 1.1.7, OpenLDAP 2.3.41

DHCPサーバ

CPU: Xeon X5355 2.66GHz x 2, Memory: 4GB
ISC-DHCP 3.05

L3コアスイッチ（2007）

Cisco Catalyst 6509 w/ FWSM x 3, IDSM x 2

対外接続ルータ（2007）

Alaxala AX6304S

L3スイッチ（サーバ接続）

Cisco Catalyst 6506

L3スイッチ（2001）

Cisco Catalyst 6509

全学ファイアウォール（2001）

Alteon Switched Firewall Director/Accelerator
Checkpoint Firewall-1

対外接続ルータ（2001）

Hitachi GR2000-BH

サーバA, B

CPU: Pentium4 3.06GHz, Memory: 512MB

クライアント1〜5

CPU: Pentium4 2.8GHz, Memory: 512MB

2009年1月29日

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

35

2009年1月29日

サイエンティフィック・システム研究会
2008年度システム技術分科会第2回会合

34

シ

ス

テ

ム 技 術 分 科 会

選 出2008 年度 システム技術分科会 第 2 回会合 より

組織の壁を越える
利用者グループ概念の導入～農林水産研究における新しい認証基盤～

農林水産技術会議事務局筑波事務所
宮坂和孝

組織の壁を超える利用者グループ概念の導入～農林水産研究における農林水産研究における新における新しい認証基盤
しい認証基盤～認証基盤～

農林水産技術会議事務局筑波事務所(農林水産研究情報総合
農林水産研究情報総合センター
農林水産研究情報総合センター)
センター
宮坂 和孝

本日の内容
内容は
内容は「情報共有サービス
情報共有サービス」
サービス」 と「認証基盤」
認証基盤」です
利用者の所属組織の内部・外部を問わない、非常に柔軟な情報
共有サービスの事例紹介を行います
サービス実現に不可欠な認証基盤についても、詳しく紹介します

発表の
発表の流れ
1. はじめに(情報共有サービスについて)
2. 農林水産研究情報総合センターについて
3. 情報共有サービスの改善
1.
2.
3.
4.

現行システムの問題点
次期システムのコンセプト
認証基盤の実装
認証基盤を活用するアプリケーションの整備

4. 今後の課題(認証連携時代に向けて)
5. まとめ2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 2

はじめに
情報共有サービス
情報共有サービスについてサービスについて情報共有サービスについて産学官の産学官の連携はますます
連携はますます重要はますます重要に重要に緊密な連携には情報共有が不可欠
どうすれば外部組織との情報共有がスムーズに行えるのか– カギは認証とアクセス制限

内部利用者の内部利用者の情報共有パターン
情報共有パターン
MAFFIN
独法A

組織
内部

同⼀組織内部の利用者と・独法側導⼊グループウェア
・電⼦メール・メーリングリスト
・研究データ交換システム
2009-01-29

MAFFIN
内部大学・企業(共同研究先)独法B

MAFFIN内の他の組織の利用者と・電⼦メール・メーリングリスト
・研究データ交換システム

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

外部

他の組織の利用者と・電⼦メール・メーリングリスト
・研究データ交換システム
Page: 4

農林水産研究情報総合センター
について

農林水産研究情報総合センターとは
農林水産技術会議事務局筑波事務所が
農林水産技術会議事務局筑波事務所が運営
国の機関、所在地つくば、30年以上の歴史(名称変更あり)

農林水産省研究ネットワーク
を整備・
農林水産省研究ネットワーク(MAFFIN)を
ネットワーク
整備・運用
全国に展開する農林水産研究拠点を結ぶネットワーク「いつでも、どこからでも使える共同研究環境」の実現を目指す– "Anytime anywhere, Collaborative Research Environment"

ネットワークから
ネットワークから利用可能
から利用可能な
利用可能な各種サービス
各種サービスをサービスを運用

ロゴにも記載科学技術計算システム
ネットワークライブラリシステム
ネットワークサービスシステム– DNS、メール、利用者情報管理、情報共有サービス

AGROPEDIA(農学情報資源システム)など……
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 6

農林水産省研究ネットワーク: 農業・食品産業技術総合研究機構: 水産総合研究センター: 森林総合研究所

MAFFIN: Ministry of Agriculture, Forestry and FIsheries research Network: その他の組織・機関: MAFFIN NOC/AP
30M

札幌 WAN (1G)
北海道農業研究センター
札幌 NOC
動物衛生研究所 北海道支所

近畿中国四国農業研究センター (生野)20M

近畿中国四国農業研究センター (仙遊)10M

中央水産研究所 (高知)10M

森林総合研究所 四国支所 (高知)10M

JGN IISINET

DIX-IEAPAN

ISP’s ISP

札幌
WAN

10G

近畿中国四国農業研究センター (福山)100M

近畿中国四国農業研究センター (大田)10M

果樹研究所 (安芸津)10M

瀬戸内海区水産研究所 (大野)10M

つくば WAN100M

九州沖縄農業研究センター (久留米)100M

九州沖縄農業研究センター (筑後)100M

九州沖縄農業研究センター (都城)10M

動物衛生研究所 (鹿児島)10M

果樹研究所 (口之津)10M

野菜茶業研究所 (枕崎)

10M
10M

森林総合研究所 九州支所 (熊本)100M

近畿中国四国農業研究センター (綾部)5M

果樹研究所 (興津)10M

畜産草地研究所 (御代田)10M

野菜茶業研究所 (安濃)20M

野菜茶業研究所 (金谷)20M

野菜茶業研究所 (武豊)10M

中央水産研究所 (上田)10M

遠洋水産研究所 (清水)北海道農業研究センター (芽室)10M

北海道農業研究センター (美唄)10M

北海道農業研究センター (紋別)

150M
1G

1G

1G

100M
100M

北海道区水産研究所 (釧路)

盛岡 WAN (1G)
東北農業研究センター
盛岡 NOC
果樹研究所 リンゴ研究部

東京 XP

農林水産
研究情報総合センター

東日本
80M 広域イーサネット網

仙台 XP

東北
地域網

60M

10G
(同一ライン上)森林総合研究所 東北支所

北海道
地域網

札幌 XP

盛岡
WAN

80M

西海区水産研究所 (長崎)

10M

10M

10G

60M

九州沖縄農業研究センター (西合志)

森林総合研究所 北海道支所

MAFFIN owned
Philippine Link

The Internet

センターが提供する
各種サービス
・機関公式 Web・電子メール・文献検索
・科学技術計算・etc...

関東
地域網

100M

西日本広域イーサネット網
100M
60M

60M

60M

福岡 XP

広島 XP

高松 XP

10M

中央農研 北陸研究センター (上越)20M

東北農業研究センター (大仙)20M

東北農業研究センター (刈和野)20M

東北農業研究センター (福島)10M

動物衛生研究所 (七戸)20M

東北区水産研究所 (塩釜)10M

東北区水産研究所 (八戸)10M

日本海区水産研究所 (新潟)

10M

本省
専用網

10M

九州
地域網

中国
地域網

四国
地域網

20M

100M

筑波農林
研究団地 WAN

全国網

畜産草地研究所 (那須)10M

動物衛生研究所 (小平)10M

水産総合研究センター 本部 (横浜)20M

中央水産研究所 (横浜)10M

中央水産研究所 (横須賀)中央水産研究所 (日光)

20M

5M

養殖研究所 (南勢)

5M

20M

養殖研究所 (玉城)

10M

10M

森林総合研究所 関西支所 (京都)

10M

10M

森林総合研究所 (多摩)森林総合研究所 (木曽福島)

10M

10M

農業生物資源研究所 放射線育種場 (大宮)

農業生物資源研究所 (松本)

10M

5M

農業生物資源研究所 (小淵沢)

農業生物資源研究所 (岡谷)

10M

100M

HSD
1.5M

森林総合研究所 (十日町)

農林水産政策研究所 (西ヶ原)東京 NOC

九州沖縄農業研究センター (種子島)

5M

九州沖縄農業研究センター (名護)10M

国際農林水産業研究センター (石垣)
石垣 AP

10M

沖縄

石垣

4

森林総合研究所 多摩森林科学園 (八王子)

農林水産技術会議事務局 (霞が関)
霞が関 AP

筑波農林研究団地 WAN (1~10G)
農林水産研究情報計算センター
筑波 NOC

西海区水産研究所 (石垣)2008

水産工学研究所 (波崎)

1G+1G

農業・食品産業技術総合研究機構本部

1G+1G

食品総合研究所

1G+1G

中央農業総合研究センター

1G+1G

農村工学研究所

1G+1G

畜産草地研究所

10G+1G

森林総合研究所

1G+1G

花き研究所

1G+1G

農業生物資源研究所

森林総合研究所 (高萩)

1G+1G

果樹研究所

1G+1G

農業生物資源研究所 (大わし)8M

森林総合研究所 (千代田)

1G+1G

作物研究所

1G+1G

農業環境技術研究所

12M

水産工学研究所 (館山)

1G+1G

動物衛生研究所

1G+1G

国際農林水産業研究センター

VPN(ADSL)

8M

中央農業総合研究センター (谷和原/水田)

8M

中央農業総合研究センター (谷和原/畑)

12M

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

2009-01-29

Page: 7

当センターの内部利用者
規模
約10,000人(うち研究者は約4,500人)

範囲
農林水産省の職員
省の所管する独立行政法人の役職員と受け入れ職員
省が推進する競争的資金による研究・プロジェクト研究等に参画する都道府県・大学・民間の研究機関の職員※大学や企業の研究者でも当センターの「内部利用者」となることができます※大学や企業の研究者でも当センターの「内部利用者」となることができます
etc…
参考: http://www.affrc.go.jp/PDF/news/pdf/news_no26.pdf

内部利用者特典

参考: http://www.affrc.go.jp/PDF/news/pdf/news_no26.pdf(ただし、⼀部のサービスは利用できない場合があります)(ただし、⼀部のサービスは利用できない場合があります)

各種サービスが利用可能に– ネットワーク系サービス (メール、メーリングリスト、NAS、VPNなど)– 計算系サービス(スパコン、アプリケーションなど)– 図書館系サービス(文献複写依頼、オンラインジャーナルなど)
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 8

当センターの認証系システムの変遷
センター設立当初
センター設立当初から
設立当初から認証情報
から認証情報は
認証情報は一元管理
古くはメインフレームの利用者管理から
1993年に所属管理用の利用者管理データベースを作成
メールサーバが各地域に分散していた頃でも、認証情報はセン
ター側で集中管理して各サーバに反映

2000年度
年度システム
年度システムでのシステムでの改善
での改善
利用者管理システムを導入– 利用者管理データベースのWebフロントエンド

LDAPを導入– メール、ネットワークストレージ(FTP/CIFS)などの認証を一元化

2004年度
年度システム
年度システムでのシステムでの改善
での改善
WebSSO(Cookie有効範囲内で利用可能なSSO)を導入– 各システムをシームレスに渡り歩けるようになった
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 92008年度システム更新
システム更新年に一度
システム更新は
更新は4年
稼働から2年が経過した時点で取りまとめる「中間評価報告書」の内容に基づいてシステム設計を行う

2008年度
年度システム
年度システムのシステムの更新経緯
2005.03 現行システム(2004年度システム)稼働
2006.12 中間評価作業部会設置
大まかなシステム構想は2006年夏頃~2007年秋頃に2007.04 中間評価報告書
2007.09 システム設計作業部会設置
2007.12 資料招請2008.05 意見招請
2008.07 仕様書配布
2008.09 入札・受注者決定
2009.03 新システム稼働(予定)2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 10

現行システムの問題点
情報共有サービス
情報共有サービスのサービスの改善(1)改善

個人向け情報共有サービス
研究データ
システム
研究データ交換用
データ交換用Webシステム
交換用
概要– 個人用ネットワークストレージと連携したWebスペースの提供

利用ケース– 研究者プロフィール・業績などのWeb公開– メールでは送信できない大容量データの引き渡し

詳細– ファイルのアップロードは、FTPおよびWindowsファイル共有経由で、
MAFFIN内部からのみ可能– 容量上限10GB– 個人用フォルダ内の公開用フォルダが自動的にWeb公開される• http://cse.所属組織サブドメイン.affrc.go.jp/アカウント名/– CGI スクリプトなどの設置・実行は不可能– アクセス制限は自前でBASIC認証などを設定する必要あり• WebSSOとは連携していない(Cookie盗聴防止のため)
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 12

現行: 研究データ交換用Webシステム
HTTP
読込のみ可

個⼈

(MAFFIN内部から)

FTP/CIFS
読込・書込可Publiccontents

user1

検索エンジンなど(公開のみ)

pub・Samba (LDAP)
・ProFTPd (LDAP)

研究データ交換用
Webシステム利用者(内部利用者)

公開・Apache・mod_auth_basic
・mod_auth_digest※pubディレクトリ以外は利用者のみアクセス可能

未認証の利用者

アクセス制限は
必要に応じて各自設定
・BASIC認証
アクセス許可者・Digest認証

利用者LDAP・認証(内部利用者)
・認可情報提供(内部利用者)

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

2009-01-29

Page: 13

グループ向け情報共有サービス
メーリングリストシステム
概要– 多人数による電子メールを介した共同作業を円滑に進めるためのメーリングリスト機能の提供

利用ケース– 研究・業務グループ内での情報共有– 学会・シンポジウムの事務局連絡先– メールマガジン発行

詳細– メーリングリストマネージャはfml– 独自作成の管理用Webインタフェース– 過去記事Webアーカイブ• アクセス制限は、共通アカウントと共通パスワードによるBASIC
認証(パスワード設定はWebインタフェースから行える)• ただし、MAFFIN外部からのアクセスは不可能
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 14

現行: メーリングリストシステム
ML・fml
・独自管理用Webアプリ
アプリ
独自管理用
・単純な
単純なメンバ管理
メンバ管理

記事投稿
記事配信

アーカイブ

ログ

メーリングリスト
メンバ(MAFFIN内部から)

HTTPS(BASIC認証・共通パスワード)
読込のみ可

2009-01-29(公開可能)

・Apache・mod_auth_basic
・MHonArc・Namazu

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 15

問題点1: アクセス制限
アクセス制限アクセス制限の制限の設定が設定が難しいhtpasswdコマンド、htdigestコマンドを使えない利用者が多い
そもそも.htaccessという名前のファイルを作れない利用者も多い

簡単な
簡単なパスワードを
パスワードを設定しがち設定しがち
設定したユーザ名・パスワードをメールなどで相手に伝える必要があるため、「わかりやすいパスワード」を設定してしまう
相手から見ると、自分自身で設定したパスワードではないため、
パスワードを覚えにくい

多人数で多人数でファイルを
ファイルを供覧する
供覧する場合する場合でも場合でも、でも、一対の一対のユーザ名
ユーザ名・パス
ワードでで済ませがちワード
全員にパスワードを割り当てて全員に連絡するのは面倒すぎる
相手から見ると、「全員知っているパスワード」であるため、パスワードの機密意識が低くなる
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 16

問題点2: ファイルのアップロード
外部から
外部からファイル
からファイルをファイルをアップロードできない
アップロードできない
システム構成上、アップロードできるのは内部利用者だけ– 研究データ「交換用」 Webシステムなのに、実は「交換」できない– アップロード不能とした理由• 適切なアクセス制限が困難である• 「誰々がアップロードした」というログを残せない• CGIを許可するとセキュリティ管理が困難

ファイルを
ファイルをアップロードできないのは
アップロードできないのは外部できないのは外部だけではない
外部だけではない
内部利用者間のファイルの交換でも、お互いのファイルスペースに直接アップロードすることはできない

2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 17

問題点3: 情報公開管理
公開してはいけない
公開してはいけない情報
してはいけない情報をうっかり
情報をうっかり公開をうっかり公開してしまう
公開してしまう
研究データ交換用Webサービスの公開用フォルダ– システム構成の問題• 個人のフォルダの中に公開用フォルダを配置する現行の構成• 機密性の高いファイルをうっかり置いてしまう可能性– 利用者の意識の問題• 「誰もアクセスしないだろう」という思い込み• アクセス制限を掛けずに著作権を侵害するようなコンテンツを公開領域に置いてしまう可能性

公開したい
公開したい情報
したい情報を情報を公開できない
公開できないメーリングリストの過去記事アーカイブ– システム側でアクセスを「MAFFIN内からのみ」にIPアドレスで制限– インターネットの検索にも引っ掛からない– 貴重な農林水産研究情報が埋もれてしまう
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 18

次期システムのコンセプト
情報共有サービス
情報共有サービスのサービスの改善(2)改善

次期情報共有サービスのコンセプト
コンセプト「認証・アクセス制限・管理の強化」を行い、より柔軟なサービスを

具体的には
具体的には:には認証範囲を広げる

本⽇の発表の中⼼です– 外部組織の利用者でも認証可能な、懐の深い認証システムを提供– 各自が常に「自分のアカウントとパスワード」で認証できる環境づくり• 多人数へのアクセス許可時でも共通パスワードは不要とする

アクセス制限(認可)設定インタフェースを使いやすくする– 簡単にアクセス制限を設定できるようWebインタフェースを整備– 利用者／利用者グループを基本としたアクセス制限を徹底する• 権限さえあれば、誰でもファイルをアップロードできるように

情報公開管理機能を導入する– 公開したい情報をきちんと公開できるように– 意図しない公開はある程度抑止できるように
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 20

認証可能な利用者の範囲拡大
ほぼ誰
ほぼ誰でも認証対象
でも認証対象にできる
認証対象にできる下地にできる下地を下地を作る
メールアドレスをIDとする「外部登録利用者」区分を新設する
信頼はできないが、認証はできるように

内部利用者

外部登録利用者

利用者となる資格

必要(かなり限定)不要

ID

英数字3~31⽂字

メールアドレス

正確な情報(公⽂書申請)

偽名も可能(本⼈独自申請)

複雑

単純

利用者情報
管理DBの構造

IDとしてメールアドレスを採用することについて○ 電⼦メールは広く普及しており、誰でも登録できる○ 利用者が自分のIDを覚えやすい- 独自の外部登録利用者IDを割り当てても、たいてい忘れられる× IDに特殊記号が⼊るため、IDとして利用できないアプリもある- ただし、最近のWebアプリなどでは考慮されていることも多い- 特殊⽂字含有ID→アプリ側でのローカルIDへのマッピングなど

2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 21

認証サービスの拡大
内部利用者・
内部利用者・外部登録利用者に外部登録利用者に同じ使い勝手を勝手を提供
内部利用者・外部登録利用者を区別せず同一のインタフェース
でログインできる認証環境を整備する

内部
WebSSO
ログインなど

外部
user:
pass:

情報共有の相⼿が少⼈数なら、「外部登録利用者」区分の追加で認証・認可の問題は解決。
でも、相⼿が多⼈数の場合は?

情報共有サービス
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 22

利用者グループ概念の導入
既存の
既存のメーリングリストのメーリングリストの捉え方を変える「単なるメールアドレスの集合」から「認証可能な『利用者』の集合(利用者グループ)」へ
配信
内部

利用者
配信
投稿
管理
グループ (read) (write) (admin)

メーリングリスト
投稿
管理
内部

内部

内部メールアドレス

内部

変換可能

内部

内部利用者ID

内部

ML
外部

ML
外部

外部
外部メールアドレス
IDそのもの外部

2009-01-29

内部

外部登録利用者ID

外部

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 23

メーリングリストはグループとして優秀
基本的な
基本的な権限が権限が明確
グループの中での各メンバの役割が決まっている– 配信対象者(≒いわゆる読込権限を保持)– 投稿権限者(≒いわゆる書込権限を保持)– 管理者

この役割を他の情報共有ツールに当てはめることにより、非常に自然な形で情報共有サービスを拡充できる

その他
その他の良いところ
情報共有したい、という目的で集まったメンバから構成される– 単なる組織階層情報から切り出したグループとは趣向が異なる

メンバ管理の方法が確立されており、利用者も慣れている
管理者への連絡手段(専用メールアドレス)が用意されている
すでに約2,500個のメーリングリストがMAFFINに存在– 「農林水産系の研究者グループ」という財産の継承
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 24

認証基盤の実装
情報共有サービス
情報共有サービスのサービスの改善(3)改善

利用者LDAP
情報共有サービスを構築
情報共有サービスのサービスの認証基盤として認証基盤として、として、利用者 LDAPをLDAPに登録する情報は各DBからの二次情報
シンプルな構成、内部・外部利用者の一括認証も可能に
l=userou=inner
検索のbaseを深くして内部利用者だけの認証も可能

ou=システム番号…

ou=people…

ou=people

uid=内部利用者ID…

uid=外部登録利用者ID

userPassword=***…

(メールアドレス)検索のbaseを浅くして内部・外部の利用者の⼀括認証も可能…

userPassword=***…

内部利用者ツリー

外部登録利用者ツリー

内部利用者
管理DB

外部登録利用者
管理DB

反映

2009-01-29

ou=outer反映

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 26

グループ情報管理データベース
メーリングリストのメーリングリストのメンバ情報
メンバ情報を
情報を管理する
管理する
メンバ情報を利用した二次情報の作成元となる

現⾏
ML
投稿 配信 管理リスト リスト リスト

次期ML
投稿 配信 管理

MLの設定ファイルに直接反映

MLの設定ファイルにはグループ情報DBを経由して間接反映(※ML投稿権限の階層化なども可能に)メーリングリストメンバ管理UI

認可情報を提供する
グループLDAPにも情報を間接反映

グループ情報
管理DB

グループ
LDAP

メーリングリストメンバ管理UI

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

2009-01-29

Page: 27

グループLDAP
情報共有サービスを構築
情報共有サービスのサービスの認可基盤として認可基盤として、として、グループLDAPをグループ
1つのメーリングリストから4つのグループを生成– ML全体グループと、権限ごとのグループ(配信・投稿・管理)
ml-1@ml.affrc.go.jp
内部
ML

外部
未登録

配信
投稿
管理
(read) (write) (admin)

l=groupuser1@affrc.go.jp
ml-2@ml.affrc.go.jp

ou=ml

全体
cn=ml-1

ex3@example.com

memberUid=

ex4@example.co.jp

memberUid=
cn=ml-1&admin

管理

…

投稿

memberUid=

memberUid=
cn=ml-1&write…

配信

memberUid=

memberUid=
cn=ml-1&read…

memberUid=
memberUid=…

2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 28

メンバ情報のグループLDAPへの登録
・外部登録利用者でなくてもLDAPに登録可能
・外部登録利用者となれば、すぐに認可条件として利用可

親ML

ml-1@ml.affrc.go.jp
内部
ML

外部
未登録

配信
投稿
管理
(read) (write) (admin)

user1@affrc.go.jp

内部利用者メールアドレス:
内部利用者IDに変換して登録
MAFFINメーリングリスト:
1回だけメンバ展開してそれぞれ登録
それ以外のメールアドレス(外部登録利用者含む):
メールアドレスを「そのまま」登録

ml-2@ml.affrc.go.jp

ou=ml

ex3@example.com

cn=ml-1&write

ex4@example.co.jp

memberUid=user1

MLの場合はメンバ展開

⼦ML

ml-2@ml.affrc.go.jp
内部

外部
未登録

memberUid=ex4@example.co.jp

配信
投稿
管理
(read) (write) (admin)

memberUid=user6
memberUid=ex8@example.gov

user6@affrc.go.jp…

MLmemberUid=ex3@example.com

ml-7@ml.affrc.go.jp
ex8@example.gov

孫MLは、親MLのLDAPにはメンバ展開しない(⼦MLのLDAPにはメンバ展開する)

ex9@example.ac.jp

⼦MLの展開時には、権限ごとに論理積を取る
SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

2009-01-29

Page: 29

特殊グループ: プリセットグループ
ある拠点
ある拠点/組織
拠点 組織の組織の利用者に利用者に対応する対応するグループ
するグループを
グループを提供
組織コード・住所コードを元にバッチ処理でグループLDAPに登録
従来の「IPアドレス(拠点サブネット)」によるアクセス制限を代替– ネットワーク中心ではなく、利用者中心のアクセス制限を身近に
階層1

階層2

10265
(果樹研)

users.naro.***
8
(つくば)
9
(盛岡)
10
(興津)
11
(安芸津)
12
(⼝之津)
4
(つくば)
58
(つくば)
59
(沖縄)

10265
10265
10265
10265
11402
(農環研)
11454
(JIRCAS)
11454

users.naro.fruit.tsukuba
users.naro

users.naro.fruit.morioka
users.naro.fruit.okitsu

users.naro.fruitusers.naro.fruit.akitsu
users.naro.fruit.kuchinotsu
users.niaes
users.jircas.tsukuba
users.jircas.okinawa

users.jircas…

…

…
2009-01-29

users.naro.***

住所コード

…

組織コード

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 30WebSSO
WebSSO機能
機能も機能も内部・
内部・外部の外部の利用者に利用者に対応Cookieドメイン内で有効な独自方式のSSO
バックエンドは利用者/グループLDAP– 内部・外部の利用者を一括で認証可能

被認証側のWebSSOクライアントはApacheモジュールとして提供– 認証・認可機能を含有• Apacheのmod_authと同様にアクセス制限を記述可能

SSO

user:
pass:

Web
ブラウザ

内外の利用者・Apache・mod_ruby・独自WebSSOアプリ
アプリ
独自

利用者/グループ
LDAP

被認証

・Apache・独自Apacheモジュール
モジュール
独自
・各サーバ用
アプリ
サーバ用Webアプリ

認証状態管理DB

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

2009-01-29

Page: 31

ここまでのまとめ
この認証
この認証・
認証・認可基盤で認可基盤で実現できること実現できること
任意の利用者の認証
任意の利用者のグループ化(組織の壁を超えても、何千人でも)利用者グループ情報の認可条件への利用
MAFFIN
独法A

独法B

大学・企業
(共同研究先)次は、認証基盤を
認証基盤を利用する
利用する情報共有
する情報共有ツール
情報共有ツールのツールの整備について整備について2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 32

認証基盤を活用する
アプリケーションの整備
情報共有サービス
情報共有サービスのサービスの改善(4)改善

追加アプリケーションの選定
必要な必要な機能の機能の洗い出し外部組織から接続できること– 現状ではHTTP上のサービス一択

MAFFINの認証基盤と連携できること– 可能な限りWebSSO、ダメならLDAPと連携

権限として「アクセス不可」「読込」 「書込」を設定できること– 「アクセス不可」権限は結構重要(実装していないWiki多し)

権限として「誰でもアクセス可能」を設定できること– 「公開」は情報共有の延長線上に位置づけたい

アクセス制限設定インタフェースを統一できること– アクセス制限設定をPlain textで保存できるアプリだと都合がよい

DokuWikiととWebDAV(Apache+mod_dav)をを選定
DokuWikiは「ACL完備」「DBいらず」な優秀アプリ
WebDAVは大容量ファイルの交換に対応するため導入
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 34

権限とアクセス制限の連動
初心者に初心者に優しく、
しく、上級者に上級者に便利に便利に初期設定で「安全、かつ十分便利に」使えるように
個⼈用
情報共有サービス– 個人用Wiki• 読込: 本人のみ
• 書込: 本人のみ
– 個人用共有フォルダ• 読込: 本人のみ
• 書込: 本人のみ

グループ用
情報共有サービス

ML管理者グループはいずれのサービスも無条件で読込・書込可能– ML用Wiki• 読込: 投稿グループ・配信グループ• 書込: 投稿グループ– ML用共有フォルダ• 読込: 投稿グループ・配信グループ• 書込: 投稿グループ– ML過去記事アーカイブ(読込のみ)• 読込: 投稿グループ・配信グループ

Webから設定を行えば、どのようなアクセス制限でも可能に– 任意の利用者(内部利用者、外部登録利用者)– 任意のグループ(ML、プリセットグループ)
SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

2009-01-29

Page: 35

次期: 研究データ交換システム
Publiccontents

個⼈

公開(公開可能)
・Apache・mod_auth_basic
・mod_auth_digest

FTP/CIFS
読込・書込可private共有

publicshare

交換システム利用者(内部利用者)

検索エンジンなど
未認証の利用者

user1(MAFFIN内部から)

HTTP
読込のみ可

wiki

(公開不可)
・Apache・mod_dav
・mod_auth_ldap

・Samba (LDAP)
・ProFTPd (LDAP)[Wiki]
collabor
research

利用者/グループLDAP

Wiki(公開可能)
・Apache・DokuWiki・DokuWiki:ldap
・WebSSO

WebDAV/SSL(BASIC認証) アクセス許可者
読込・書込可 ・内部利用者
・外部登録利用者
・グループ所属者
HTTPS(WebSSO認証)
読込・書込可・認証(内部利用者・外部登録利用者)
・認可用情報提供(内部利用者・外部登録利用者・グループ)
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 36

次期: メーリングリストシステム
ML

アーカイブ

・fml
・グループ管理
グループ管理DBと管理 と連携した連携した独自した独自メンバ
独自メンバ管理
メンバ管理
記事投稿

ログ

記事配信

メーリングリスト
メンバ
WebDAV/SSL(BASIC認証)
読込・書込可検索エンジンなど
HTTPS(WebSSO認証)読込のみ可 未認証の利用者(公開可能)

・Apache・独自過去記事アプリ
独自過去記事アプリ
・WebSSOHTTPS(WebSSO認証)
読込のみ可[Wiki]
collabor
researchHTTPS(WebSSO認証)
読込・書込可共有(公開不可)
・Apache・mod_dav
・mod_auth_ldap

Wiki(公開可能)
・Apache・DokuWiki・DokuWiki:ldap
・WebSSO

アクセス許可者

・内部利用者
HTTPS(WebSSO認証) ・外部登録利用者
読込・書込可 ・グループ所属者

利用者/グループLDAP・認証(内部利用者・外部登録利用者)
・認可用情報提供(内部利用者・外部登録利用者・グループ)

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

2009-01-29

Page: 37

アクセス制限設定用インタフェース
Wiki、、共有フォルダ
共有フォルダ、
フォルダ、メーリングリスト過去記事
メーリングリスト過去記事アーカイブ
過去記事アーカイブでアーカイブで、ほぼ同ほぼ同じ体裁の体裁のアクセス制限設定用
アクセス制限設定用インタフェース
制限設定用インタフェースを
インタフェースを用意
このインタフェース以外からのアクセス制限設定は行えない
公開申請が承認されると、
この「無効」が無くなる

組織の組織の管理者による管理者による簡易公開制限
による簡易公開制限が
簡易公開制限が可能に可能に
次期システムでの「公開」は、「不特定多数への閲覧権限付与」(未認証の利用者への閲覧許可)という意味
上記以外は、「公開」ではないものとする– 人数の問題ではなく、認証の問題– 10,000人規模のグループへの閲覧権限付与は「公開」ではない
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 38

今後の課題認証連携時代に認証連携時代に向けて

OpenID への対応
OpenIDとはとは簡易なWebSSO方式、URIがIDとなる– 世界的にIdP数が増加している

対応
WebSSO機能にOpenIDのService Provider機能を組み込む– WebSSOに対応する全てのシステムがOpenID対応となる実現できること実現できること
MAFFINの情報共有サービス上でOpenIDをそのままIDとして利用するのは少し困難
パスワードをMAFFIN側に預けなくても良くなる効果はある– 外部登録利用者のパスワード管理の補助程度の効果– メールアドレスはOpenIDの属性情報から取得できるが、基本的に信頼できないため、メールアドレスの実在確認を行う必要がある– MAFFIN側ではOpenIDとメールアドレスの対応情報を保存
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 40

Shibboleth への対応
Shibbolethとはとは組織間のID連携(フェデレーション)の一手段、SAMLベース
欧米の学術機関で実績あり、日本ではUPKI Initiativeで実験中

対応
WebSSO機能にShibbolethのService Provider機能を組み込む実現できること実現できること
属性情報として取得できるメールアドレス情報を信頼すると……
– 得られたメールアドレスをMAFFIN認証のIDに設定することで、外部
登録利用者と同様に取り扱える
かなりイレギュラーな使い⽅ですが……
– 利用者登録作業が不要にもし学術系のフェデレーションに参加できれば……
– この情報共有サービスのメインターゲットである学術系の利用者と、より手軽に情報共有を行うことが可能に– 組織間のID連携が実現した場合でも小回りの効くグループは有用
SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

2009-01-29

Page: 41

Shibboleth への対応
構想図

IdP
フェデレーションによる信頼関係
実際のやり取りはかなり複雑です

user:
pass:

Web
ブラウザ

内外の利用者SSO・Apache・mod_ruby・独自WebSSOアプリ
アプリ
独自(+Shibboleth SP機能
機能)
機能

被認証

・Apache・独自Apacheモジュール
モジュール
独自
・各サーバ用
アプリ
サーバ用Webアプリ
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

属性情報から得られた
メールアドレスを信頼して認証セッションに登録

利用者/グループ
LDAP

セッション管理DB
Page: 42

まとめ

まとめ
利用者の
利用者の所属組織の所属組織の内部・
内部・外部を
外部を問わない、
わない、非常に非常に柔軟な
柔軟な
情報共有サービス
稼働予定)
情報共有サービスをサービスを構築した
構築した(2009.3稼働予定
した
稼働予定
メールアドレスをIDとする「外部登録利用者」という区分を設け、ほぼ誰でも認証できる環境を整備した
既存のメーリングリスト資産を活用することにより、内部組織・外部組織の利用者を含む農林水産系の研究者グループをLDAP上に表現することができた(認証・認可バックエンドの構築)
メーリングリストメンバの権限情報を活用することにより、自然な形でグループ向けの情報共有サービスを拡充できた
今後は認証連携への対応を検討している

農林水産系の農林水産系の研究情報交換が研究情報交換が活発になることを活発になることを祈念になることを祈念します
祈念します
2009-01-29

SS研
研 システム技術分科会
システム技術分科会 「組織と組織と認証 －誰を認証すべきか
認証すべきか－」すべきか－」

Page: 44