AXIES 2023 認証基盤部会 企画セッション「多様なサービスの活⽤に向けたID連携におけるID管理に求められるもの」

⼤学としてのID管理の実情(京都⼤学の場合)
京都⼤学 情報環境機構 情報環境⽀援センター
センター⻑・准教授
森村吉貴

京都⼤学におけるID管理の概要• 全学的な情報システム・サービス利⽤のIDとして「全学アカウント」があり「統合認証システム」が100を超えるSPに認証機能を提供• Shibboleth/SAML または LDAP
• 主要SP：Microsoft 365, Google Workspace, 教職員グループウェア,
学内Wi-fi, 電⼦ジャーナル・データベース, LMS, 財務会計システム…

• アカウント種別は教員⽤／学⽣⽤／その他に⼤別• 教員⽤は⼈事給与システム、学⽣⽤は教務情報システムをTrusted DBとみなして情報取り込み• その他として、名誉教授等の雇⽤に基づかない称号付与対象者等にも利⽤可能SPが限定されたアカウントを付与

情報環境機構／情報環境⽀援センターの役割• 情報環境機構• 全学のITサービスに係る企画・設計・運⽤を⾏う• 全学アカウント・統合認証システムを管理する• 情報環境⽀援センター（以降、センターとする）※発表者の所属先• 情報環境機構のITサービス全般のヘルプデスクを担当• 全学アカウントの発⾏・運⽤を担当
アカウント関係のサポート・トラブル対応は全⾯的に担当

Know Your Customer (※直訳の意味で)• そもそも、センターは“顧客”をどの程度知っているのか？
• 学⽣は教務情報システム／教職員は⼈事給与システムをTrusted DBとみなす → センターは⾝元検証の⼿段を持たない• では、教務／⼈事はTrusted DBを構築している意識はあるか？
→⾝元情報を管理するためのDBではなく、あくまで業務⽤DB
本⼈確認は「業務の必要に応じて」⾏う• ならば、アカウントリカバリは？
本⼈から直接センターに問い合わせが来るが、本⼈確認をどうするのか？
名前や職員（学⽣）番号・⽣年⽉⽇を聞く？
内線番号・学内便で折り返す？ 部局の教務・⼈事に照会する？

アカウント種別やリカバリ対象に応じて上記を組み合わるが、どの⽅法が最適か確信が持てないKnow Your Customer (※直訳の意味で)• そもそも、センターは“顧客”をどの程度知っているのか？
• 雇⽤・学籍がない関係者には「その他」のアカウントを発⾏するが、Trusted DBがないため発⾏時にセンターが直接⾝元確認を⾏う• センターにできる「⾝元確認」とは？
1. 名誉教授証など⼤学側が発⾏する⾝元証明書を確認
2. 本⼈の公的⾝分証＋⼤学側との関係を⽰す書類を確認
3. 各部局の事務担当者からの依頼に基づき発⾏し、アカウント有効化書類を送り返す(Trusted DB取込に準ずる⼿続き)
場合に応じて上記を使い分けるが、ポストコロナでは3.の⽐重が増加

全学情報システム利⽤規則の⼀例（全学アカウントの発⾏根拠）• 【学⽣等】 学部学⽣及び⼤学院学⽣、外国学⽣、委託⽣、科⽬等履
修⽣、聴講⽣、特別聴講学⽣、特別研究学⽣、特別交流学⽣等(京都⼤学通則（昭和２８年達⽰第３号)第５章に定めるもの）、研究⽣、研修員等（京都⼤学研修規程（昭和２４年達⽰第３号）に定めるもの）その他本学規程に基づき受け⼊れる研究者等をいう。
• 【利⽤者】教職員等及び学⽣等で、全学情報システム⼜は特定部局情報システムを利⽤する者をいう。

→その他本学規程・・・？

職名・称号の多様性• 当学で確認された教授⼀覧• 教授・特定教授・特定拠点教授・特定外国語担当教授・特任教授・特命教授特別教授・名誉教授・客員教授・招へい教授・特別招へい教授・招聘特別教授・病院教授・臨床教授・法科⼤学院特別教授・専⾨職⼤学院特別教授• 雇⽤はあったり（職名）なかったり（称号）する• 利⽤者対応時の切り分けが直感的にできない• 概ね規定に「教育研究に携わる」的な⽂⾔がある• 何らかの情報サービスを利⽤する必然性がある

全学情報システム利⽤規則• 第６条 情報環境機構⻑は、教職員等及び学⽣等以外の者について、次の各号のいずれかに該当し必要があると認めるときは、全学情報システム臨時利⽤者として、全学情報システムの利⽤の許可を与えるものとする。
(1) 部局情報セキュリティ責任者（＝本学においては部局⻑指定）より臨時利⽤の⽬的・範囲・期間等を明⽰して申請があったとき。

全学アカウントの利⽤資格について考える• 規定に基づく研究員であったり、部局⻑の申請であれば、雇⽤や学籍の有無に関わらずアカウントを発⾏可能な制度である• もちろん個別に必要性を判断することは担保されているが、必要性の事前の定義はない
制度運⽤開始時には敢えて踏み込まなかったと考えられるが学内のあらゆるリソースの利⽤が情報システム・サービスに基づくようになるとその判断の意味が⾮常に重くなる• 情報技術の枠内での「認証・認可」だったつもりが、⼤学の構成員としての資格そのものの「認証・認可」を意味しかねない→情報系のセンター単体では判断しづらい・してはいけない状況が顕在化

ID発⾏⼿続きのケーススタディ：
新⼊⽣へのアカウント発⾏の電⼦化• 京都⼤学では⼊学⼿続きの電⼦化推進、履修登録の迅速化のため2016年より学⽣アカウントの⼊学前発⾏を実施• ３⽉末までに以下の⼿続きを実施[当該図表は資料共有時に割愛]

ID発⾏⼿続きのケーススタディ：
新⼊⽣へのアカウント発⾏の電⼦化• 業務効率化／紙ベース配布物の削減のため
本⼈へのアカウント情報の提供を電⼦化• 本⼈確認に利⽤可能な情報を慎重に検討・再整理→ ⼊試・⼊学業務全体の流れの把握が必要だった[当該図表は資料共有時に割愛]

新構成員のKYCはさらなる検討が必要

認証に付随するアカウント属性情報• 統合認証システムは認証成功時にアカウント属性情報をSPに提供可能• 姓名、職種、ID、仮名化ID、⼤学メールアドレス…

• 別途、部局担当者向けの⼀括ダウンロード提供システムを準備• SP側のユーザープロビジョニング等に活⽤可能• 源泉DBである⼈事・教務情報の取り出し⼿段として汎⽤に⽤いられるように（100件弱の利⽤者）→ ⼈に関する全学DB的な性質を帯びて来たが、完全・無⽭盾ではない• 属性情報の信頼性• 海外姓名表記への対応、改姓対応、などで⼀貫したポリシーが敷けていない• 「その他」アカウントの属性情報は⾃⼰申告でセンターで正確性を検証できていない

統合認証DBを⼈に関する全学DBとして⽤いる場合の問題• 教務情報と⼈事情報に由来する⾮整合性の問題• 利⽤⽬的が異なるため、部局の単位やコードなどが⼀致しない• TAやRAなどで学⽣・教職員の⾝分の⼆重化が発⽣するが完全な解決はされない（全学アカウント⾃体は学⽣側に⽚寄せ）• 必要に応じてSP側で運⽤による解決• 短時間雇⽤教職員は財源単位の雇⽤となり、複数財源雇⽤者は⼈事給与システム上は複数エントリが存在する→センターが属性⼊⼒する「その他」アカウントと合わせ、名寄・紐づけを⾏わないと「⼈」ベースの情報とならない

多要素認証の導⼊時の課題• パスワードのみの単要素認証を⾏う場合に⽐べ、利⽤者の習熟が必要なケースが多い• 教育的な情報提供から問題発⽣時のリカバリまでが必要になるが、利⽤者・センターともに⾼負担• 教職員側のコアサービスでの多要素必須化は完了、学⽣・その他アカウントのスケジューリング中• オンライン授業等で緊急対応が必要！等の危急の要請は個別SPや所属部局の都合によって⽣じるが、どこまでサポートするか？の程度について全学的に合意があるとは⾔えない→しかし、この程度は確実に体制的コストに直結• 宣伝：明⽇「午前２」のユーザーコミュニケーション部会
企画セッション【多要素認証を「使ってもらう」ためのユーザーコミュニケーションとは】でも関連の議論を⾏います！

今後の展望• 諸課題は情報環境機構／情報環境⽀援センターが単体では解決できないフェイズに⼊っている→全学的な対応が必要• 今⽉、情報担当理事直下に「認証次世代化・ID体系化タスクフォース」発⾜• 部局⻑級教員および事務本部の⼈事・教務・情報の部⻑級職員を委員に• 部局との対話の場を設定• 事務本部のDXプロジェクトと併⾛し、相互協⼒することを明記• ⼤学全体として以下の⽬標を検討することに• 本⼈確認⽅法の基準の提⽰• ID情報の体系化（当⾯は ≠ ⼀元化 ）を推進
• 上記を活⽤したID情報や⾼度認証の積極的活⽤