[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[upki-fed:209] Re: UPKIフェデレーションの属性追加について



岡部です。

土屋先生、フォローありがとうございます。

「全国規模の一元的なシステムはやらない方が全体として安全」というご指摘に
は同感です。UPKIの最初の頃に日本全体の認証基盤をどういうアーキテクチャに
するかいろいろな可能性を考えましたが、少なくともNIIに集中させるような
のはあり得ないと確信しました;)

ただ一方で、Shibbolethのようなフェデレーションは大学間だけでなく大学内で
も用いられうるものであり(京大では実際そうしています)、そこで職員番号・
学生番号のようなデータをやりとりすることはアリだと思います。もちろんその
場合には大学で閉じた属性を使ってもいいわけですが、尾崎さんの提案のように
学認としての共通属性を決めておいて必要なときにはそれを使うことは、設定情
報の互換性の点でメリットがあります。もちろん、攻撃者に対してはどの属性名
でどういう情報が入っているかのヒントを与えるというセキュリティ上のマイナ
ス面もありトレードオフではありますが。

>> 大学で使われる個人番号には、大別して、職員番号に相当するものと、学生番号
>> とがあり、例外的とはいえそれらを同時に持つ人もいるし、派遣職員のようにど
>> ちらも持たない構成員もいるわけですが、学認ではどう扱うのがいいでしょうか?
> (中略)
>> いずれにせよ職員番号は取扱注意の個人情報で、漏洩すれば職員証偽造など犯罪
>> への悪用の恐れもありますので、真に必要な場合は慎重に設計し、それ以外にお
>> いてはなるだけ大学間フェデレーションのような枠組みでのやりとりは避けるの
>> が無難と思います。
> 
> 基本的にそのようにすべきだと思いますが、個人情報云々は別にして、(状況
> 証拠としては、)JISCはもともと20年近くAhtensを運用してきて、そこから
> Shibbolethに乗り換えたわけですが、技術的なことを除けば、これは、全国規
> 模の認証用のデータをEduservが一元的に運用してきたのをやめて、大学機関
> ごとの管理に換えたということであると思います。これは、いろいろな背景の
> ある決定(技術と財政)だったと思いますが、全国規模の一元的なシステムはや
> らないほうが全体として安全という決定として理解しています。日本も、規模
> のことを考えれば、これに習うべきではないかと思います。
> 
> フィンランドのような小規模な国の運用はあまり参考にならない(ヨーロッパで
> は、基本的に高等教育は国または州の直轄事業で、フランスでようやく法人化
> が進行中という事情を考えると、とくに)のではないかと思います。

-- 
Yasuo Okabe
Kyoto University
http://www.net.ist.i.kyoto-u.ac.jp