認証統合および TLS 対応ウェブホスティングサービスの運用
中村 純哉 1) , 小林 真佐大 1) , 下條 詠司 1) , 土屋 雅稔 1)1) 豊橋技術科学大学 情報メディア基盤センター
junya@imc.tut.ac.jp

Operation of Single Sign On and TLS-enabled Web Hosting ServiceJunya Nakamura1) , Masahiro Kobayashi1) , Eĳi Shimojo1) , Masatoshi Tsuchiya1)
1) Information and Media Center, Toyohashi University of Technology

概要
大学の研究活動や業務をサポートするためのウェブサーバは，現代のネットワーク社会で不可欠だが，十分なメンテナンスが行われていないサーバも多く見られる．また，サイバー攻撃が増える中で，サーバメンテナンス技術の高度化も課題となっている．このような背景において，大学の情報系センターが提供するウェブホスティングサー
ビスの役割は増しており，特に認証統合（SSO）と安全な通信（TLS）の実現が重要となっている．SSO は業務効率とセキュリティの向上を目指すもので，TLS は通信のセキュリティを高めるものである．本論文では，豊橋技術科学大学における SSO と TLS に対応したウェブホスティングサービスについて，設計と運用状況を報告する．

1

上の要請である．ウェブサーバとクライアントは，はじめにHypertext Transfer Protocol （HTTP）[6] に従って通信

現代のネットワーク社会において，研究成果の広を行うが，TLS 化されていない HTTP は，大規模な盗報などの大学における各種業務を円滑に実施するに聴や検閲 [10, 17] などの各種の攻撃に対して脆弱であは，安定したウェブサーバが必要不可欠である．しかる．そのため，Google Chrome や Apple Safari などのし，学内組織や研究室に設置されたウェブサーバは，ブラウザは，2018 年から 2021 年にかけて，TLS 化さ専門外の職員や学生によって維持されている場合がれていないウェブサーバにアクセスすると警告を出力

多く，十分にメンテナンスされていないサーバも少なしたり，アクセスを拒否するようになった [3, 8, 9]．こくない．また，クラッキングなどのサイバー攻撃は高れら 2 つの理由から，情報系センターが提供するウェ度化かつ増加しており，サーバを維持するために必要ブホスティングサービスにおいても，SSO および TLSな技術は高度化する一方である．このような状況を改に対応する必要がある．

善するには，各大学の情報系センターがウェブサーバ

本論文では，豊橋技術科学大学にて構築した，SSOのホスティングサービスを提供することが有効であおよび TLS に対応したウェブホスティングサービス

る [19, 22, 26]．の概要と運用状況について報告する．2023 年 10 月

近年，2 つの理由から，ウェブホスティングサービス

現在，UPKI [24] を含む多くの認証局では 398 日よりの運用にあたって，認証統合（Single Sign On; SSO）と短い有効期限の TLS サーバ証明書しか発行できない．

安全な通信路の確保（Transport Layer Security; TLS）

TLS サーバ証明書は SSO に参加しているシステムのへの対応が要請されている．第 1 の理由は，組織内台帳でも必要となることから，サーバ証明書を定期的における各種業務情報システムの増加である．これらに更新する作業負荷は無視できない．そこで，ウェブの情報システムが，個別にユーザ情報を保存し独立にホスティングサービスでは TLS サーバ証明書の更新ユーザ認証を行うと，利用者の利便性が低下し，安易を自動化することで，この問題に対処する．

なパスワードを利用するなどの回避策を採る傾向が本論文の構成は，以下の通りである．2 節では，SSO強まり，情報システムのセキュリティに対して悪影響

参加システム台帳および TLS サーバ証明書の更新をを生じる．そのため，情報システムのユーザ情報を統自動化する方法について述べる．3 節では，更新の自合し，ユーザ認証を連携して，SSO を実現する必要動化に対応したウェブホスティングサービスのシステがある [20, 21, 23, 25]．第 2 の理由は，セキュリティム構成について述べる．4 節で本ホスティングサービ

254

図 1 Shibboleth における認証処理フロー（概要）スの運用状況について考察し，5 節で結論を述べる．

2

証することも考えられるが，遠隔地に SP 管理者がいる場合など，対応困難なケースが存在する．そこで，設計

本論文のウェブホスティングサービスでは，SSO 参加

豊橋技術科学大学（以下，本学）では，学内ウェブサーシステム台帳に登録する SP 鍵は，既知 SP のホスト名

バの SSO を実現する基盤システムとして Internet2を対象として，UPKI [24] または Let’s Encrypt [2] にMiddleware Initiative によって開発された Shibboleth

よって発行された TLS サーバ証明書に限る，という管[5] を採用している [20]．図 1 に，Shibboleth におけ理ポリシーを採用する．

る認証処理フローの概要を示す．本学の Shibboleth

2.2

TLS サーバ証明書更新の自動化

は，認証機能と利用者属性情報を提供する Identity

ブラウザのポリシー厳格化 [4, 12, 14] によって TLS

Provider（IdP）と，IdP によって認証された利用者に対サーバ証明書の有効期限が制限されているため，多数して実際にサービスを提供する Service Provider（SP）のドメインが利用するウェブホスティングサービスでからなり，WAYF サービス（DS）は利用していない．

は，TLS サーバ証明書の更新作業を自動化する必要でこの節では，SSO 参加システム台帳と TLS サーバ証ある．そのため，本論文のウェブホスティングサービ

明書の更新を自動化するための設計方針について述

スでは，一部の特殊ドメインを除いて，証明書発行がべる．

自動化されている認証局 Let’s Encrypt [2] に証明書の2.1 SSO 参加システム台帳の管理ポリシー発行を依頼する．

Shibboleth における SSO 参加システム台帳（メタLet’s Encrypt による証明書自動発行手順（Automatedデータ）は，SSO に参加している全ての IdP と SP のCertiﬁcate Management Environment; ACME）では，証公開鍵を，XML 形式で保持している．IdP が SP に対明書の対象となる識別名（ドメイン名等）の所有権をして利用者属性などを格納した認証応答を回答する時確認する方法が，3 種類ある．ACME クライアントソ（図 1 の第 4 段階），認証応答に含まれる情報が第 3 者

フトウェア [7] の標準的な方法は，HTTP-01 challengeによって窃取されないよう，SSO 参加システム台帳にと呼ばれる手順だが，ACME サーバからウェブサーバ格納されている SP の公開鍵によって暗号化し，IdP のに対するネットワーク到達性が必要である．しかし，秘密鍵によって署名する．Shibboleth の安全性は SSO

本学のホスティングサービスにはアクセスを組織内参加システム台帳に依存しているため，SSO 参加シスネットワークに限定しているウェブサーバも含まれる

テム台帳は適切に管理される必要がある．

ため，HTTP-01 challenge ではなく DNS-01 challenge

Shibboleth の SSO に参加する SP は，HTTPS で用を採用する．DNS-01 challenge では，ACME サーバかいられる TLS サーバ証明書と，その SP と IdP が通信ら通知されたランダムトークンを特定ドメインの TXTを暗号化するために用いる証明書（以下，SP 鍵と言レコードに設定することによって，当該識別名の所有う）の 2 つが必要となる．これら 2 つの証明書は，同権を証明する．TXT レコードの設定作業は，Dynamic一のものを用いる必要はない．しかし，別々の証明書

DNS [16] を用いることで自動化した．

を用いる場合，SSO 参加システム台帳に登録する SP

2.3

SSO 参加システム台帳更新の自動化鍵の真性であることを検証することが難しい．IdP 管

SSO 参加システム台帳および SP 鍵の更新手順は，理者と SP 管理者が対面で SP 鍵を手交することで検学術認証フェデレーションによる推奨手順 [1] に準拠

255

P0) 初期状態
P1) SP は，第 n − 1 世代の証明書を使う，かつ，第 n 世代の証明書を復号化のみに使う状態に遷移（SP1）
P2) IdP は，第 n 世代の証明書を SSO 参加システム台帳に追加（IdP2）
P3) SP は，第 n 世代の証明書を使う，かつ，第 n − 1 世代の証明書を復号化のみに使う状態に遷移（SP2）P4) IdP は，有効期限に基づいて，第 n − 1 世代の証明書をSSO 参加システム台帳から削除（IdP1）
P5) SP は，第 n 世代の証明書のみを使う状態に遷移，P0 に戻る（SP3）

図 2 証明書更新時の IdP/SP の挙動が得られる．SP 上で動作する ACME クライアントソフトウェアが第 n 世代の証明書を取得すると，この最新の証明書は SSO 参加システム台帳には未登録であるから，図 4 の SP1 によって図 2 の P1 に遷移する．
次に，IdP から SP に TLS 接続して取得できる証明書が SSO 参加システム台帳に未登録であるから，図 3の IdP2 によって図 2 の P2 に遷移する．すると，SSO
参加システム台帳には第 n 世代の証明書と第 n − 1 世代の証明書の両方が登録されている状態になるため，
図 4 の SP2 によって図 2 の P3 に遷移する．第 n − 1世代の証明書の有効期限の残り日数が閾値よりも短くなると，図 3 の IdP1 によって図 2 の P4 に遷移する．
すると，SSO 参加システム台帳には第 n 世代の証明書のみが登録されている状態になるため，図 4 の SP3によって図 2 の P5 に遷移する．以上の動作によって，SP の TLS サーバ証明書と SSO 参加システム台帳のSP 鍵を，安全かつ自動的に更新できる．

3

システム構成本学のホスティングサービスは，権限管理を担当する認証管理システムと，実際の各種サービスを提供する仮想化基盤システムの 2 種類からなる．このうち認証管理システムについては，[18, 19] で詳細が報告されているため説明は割愛し，ここでは仮想化基盤システムの構成について述べる．ホスティングサービス

図 3 IdP 上の SSO 参加システム台帳更新手順

は 2008 年に運用開始しており，これまでに 2 回システム更新を行っている．ここで紹介するシステム構成

する．以降では，SSO 参加システム台帳と SP 鍵を自は，2021 年より運用している第 3 期システムのもので動的に更新する方法について述べる．

ある．

SSO 参加システム台帳および SP 鍵の更新には，少図 5 にホスティングサービスにおける仮想化基盤シなくとも 2 ノード以上の異なるサーバ（IdP と SP）がステムの構成を，表 1 にシステム仕様を，それぞれ示関与する．複数のサーバ上でソフトウェアが同時に動す．仮想化基盤として，コンテナ型仮想化システムで作して，同期的に更新処理を進めるという設計は理論ある Docker [11] を採用する．サーバ OS には，Docker的には可能である．しかし，対象となるサーバが非常の実行に最適化された Container Linux [15] を用いた．に多数存在する状況では，更新処理中になんらかのト各ドメインのサービス稼働状況は，Nagios Core [13] をラブルが発生し，更新処理に失敗する可能性が無視で用いて遠隔監視する．ウェブサイトのデータは，NFSきない．そのため，本システムでは，IdP と SP が独立サーバに格納する．

Docker では，コンテナイメージの作成手順（パッして非同期に更新処理を行う方針を採る．

SP 上で動作する ACME クライアントソフトウェア

ケージのインストールや設定ファイルの修正など）をが第 n 世代の証明書を取得した時，SSO 参加システム

Dockerﬁle と呼ばれるテキストファイルに記述し，そ台帳に登録されている第 n − 1 世代の証明書を，第 nれを Docker に渡すことでコンテナイメージを生成す世代の証明書に更新する手順を，図 2 に示す．IdP とる．本学のウェブホスティングサービスでは，まず，SP が独立して非同期に更新処理を行えるよう，図 2 のすべてのドメインに共通したコンテナイメージを作成

手順を分解すると，IdP 上の SSO 参加システム台帳更し，このイメージを使って各ドメインのコンテナを実新手順（図 3）と SP 上の設定ファイル更新手順（図 4）

行する．一方で，利用者の要望は一様ではなく，異なる

256

図4

各ドメインのコンテナ

SP 側の設定ファイル更新手順

fleetクラスタ

表1NFS
サーバ

コンテナサーバ

OSDocker
レジストリ

コンテナランタイム
ノード仕様
ノード数

Git
リポジトリ

Container Linux 1409.9.0
Docker 1.12.6
CPU 4 コア，メモリ 12GB
5NFS サーバ

Nagiosサーバ

図5システム仕様

OSCPU

仮想化基盤システム構成

ソフトウェアスタックを使いたいという要請がある．*1
ドメインごとに異なる要請に応えるため，ホスティン
グサービスのコンテナイメージは，ドメインごとの固有設定が宣言的に記述された記述された設定ファイルを実行時に読み込み，反映する仕組みを備える．このメモリ
ディスク容量Debian GNU/Linux 9
2 コア
8GB
800GB

共通イメージ

コンテナ

NFSサーバ

共通設定

サイト
データ

宣⾔的固有設定

実⾏時に反映設定ファイル

ように，すべてのドメインで同一の仕様は共通コンテ

図 6 システムのデータ配置

ナイメージに集約し，ドメインごとの固有設定は設定ファイルとして管理することで，利用者の要望に応えられる柔軟なサービス提供体制を実現している．最後

その後 2014 年まで徐々にドメイン数が増加している．に，共通イメージを作成するための Dockerﬁle と，各

それ以後，ドメイン数の伸びは緩やかとなっており，ドメインの固有設定ファイルは Git でバージョン管理直近 5 年間は 110 ドメイン前後で推移している．学内

し，変更履歴を追跡できるようにする．のウェブサーバは，おおむね移行が完了したものと考えられる．

4

運用状況

ホスティングサービスのドメインの中で，TLS を利最初に，ホスティングサービスを開始した 2008 年

用しているドメイン数の変化を，図 8 に示す．本学はから 2023 年までの利用ドメイン数の推移を，図 7 に2011 年に UPKI に参加し，ホスティングサービスで示す．2008 年度は 34 ドメインの利用申込みがあり，も UPKI の TLS サーバ証明書を利用してきた．2022
年から，Let’s Encrypt の TLS サーバ証明書への移行*1 例えば，ドメイン A は DBMS として MySQL の利用を希望し，ドメイン B では PostgreSQL の利用を希望する場合など．

257を開始した．2023 年 7 月時点において，100 ドメインが Let’s Encrypt の TLS サーバ証明書に，移行完了し

100000

100

80000
認証回数

ドメイン数

120806040

その他

60000
40000
20000

2002008201020
1220
1420
16201820202022022

図 7 利用ドメイン数の推移

年10⽉

図 1023年

1⽉

23年

4⽉

23年

7⽉

Shibboleth 認証回数の推移

60120

ドメイン数

Let's Encrypt

100
ドメイン数

ホスティング

UPKI

8060402050

Shibboleth40

その他

30201000研

図 8 TLS 利用ドメイン数の変化

究室学内組織プロジ

ェ

クト業

務シス

テムその他

図 11 ホスティングサービス利用ドメインの分類

70
その他
ホスティング

60
SP数50

スでは構築されていることがわかる．

40

図 11 に，2023 年 10 月時点におけるホスティング

30

サービス利用ドメインの分類を示す．全体の半数を研

20

究室のウェブサイトが占め，学科やセンターなどの学10内組織，各種プロジェクトなどが続く．これらのサイ02012 2014 2016 2018 2020 2022

トにおける SSO の利用例としては，研究室所属の教員 · 学生のアカウントに対して個別に研究室専用掲示

図 9 Shibboleth SP 数の推移

板のアクセス権限を付与する，事務局ウェブサイトにおいて教員 · 職員というグループに対してアクセス権ており，情報メディア基盤センターが管理している特殊ドメイン 1 つのみが UPKI の TLS サーバ証明書を限を付与するなどがある．
図 12 に，2023 年 6 月の各ドメインのアクセス数の分布を示す．過半数のドメインは，1 ヶ月あたり 5 万利用している．
本学の SSO に参加している SP 数の推移を，図 9 にアクセス未満である．最もアクセス数の多かったドメ示す．本学において SSO の運用を開始した 2012 年

インは学内共同施設で，37 万アクセスだった．図 13から 2023 年まで一貫して，ホスティングサービスのに，アクセス数上位 30 ドメインの HTTP と HTTPS のSP がほぼ半数を占めている．SP を構築することは非割合を示す．図から，多くのドメインでは HTTPS へ経験者にとって非常に困難な作業だが，ホスティングの移行が完了していることがわかる．一方で，HTTPSサービスではサービスメニューとして予め用意されてへの移行が完了しておらず，引き続き HTTP を主としいるため，各ドメインにおいて Shibboleth によるユーて利用しているサイトも見られる．これは，これらのザ認証機能を容易に利用できる．

サイト内のリンクに URL スキームとして http:// が図 10 に，本学の SSO 参加システムにおける認証回明示的に書かれていることが原因である．この場合，数の推移を示す．先述のように Shibboleth SP のおお

たとえ HTTPS でサイトを表示しても，サイト内リンよそ半数がホスティングサービスによって構築されてクをクリックすると，HTTP のサイトに遷移してしまいるが，認証回数でみると全体の 20% 程度であり，比う．この問題を解決するため，これらのサイトでは既較的利用頻度の少ないシステムがホスティングサービ

存のウェブページの修正を進めている．

258

ドメイン数8060
4020〜万万25

25万2020〜万
1515〜

万
10

10〜

5〜〜

5万

0

アクセス数

アクセス数

図 12

ドメインごとのアクセス数（2023 年 6 月）

400000350000300000250000200000150000100000
50000
0

HTTP
HTTPS

1 3 5 7 9 11131517192123252729

図 13 アクセス数上位 30 ドメインの HTTPS の割合

5

おわりに
本論文では，認証統合（SSO）と安全な通信路の確保（TLS）に対応した大学組織向けウェブホスティン
グサービスの構築と，その運用状況について報告した．

SSO と TLS に対応するには，SSO 参加システム台帳と TLS サーバ証明書の自動更新が必要である．提案システムでは，Let’s Encrypt が提供する ACME クライアントを用いて，TLS サーバ証明書の自動更新を実現する．また，認証統合参加システム台帳で用いられる SP 鍵を，ウェブサービスで用いるサーバ証明書と共通化することで，安全かつ効率的に台帳を自動更新する仕組みを構築した．

参考文献[1] メ タ デ ー タ 記 載 の 証 明 書 更 新 手 順（SP）.
https://meatwiki.nii.ac.jp/confluence/display/
GakuNinShibInstall/SP+Key+Rollover, （2023 年 10月 9 日閲覧）.
[2] J. Aas, R. Barnes, et al. Let’s Encrypt: An Automated Certiﬁcate
Authority to Encrypt the Entire Web. In Proceedings of the 2019
ACM SIGSAC Conference on Computer and Communications
Security, pp. 2473–2487, 2019.
[3] Apple. Download macOS Mojave 10.14.4 update, 2019. https://support.apple.com/kb/DL1994, （2023 年 10 月 9 日閲
覧）.
[4] Apple. 信頼済み証明書に関する今後の制限について, 2020.
https://support.apple.com/ja-jp/HT211025, （2023 年10 月 9 日閲覧）.
[5] S. C. (Ed.). Shibboleth Architecture Protocols and Pro-259

ﬁles, 2005.
https://shibboleth.net/documents/
internet2-mace-shibboleth-arch-protocols-200509.
pdf, （2023 年 10 月 9 日閲覧）.
[6] R. T. Fielding, M. Nottingham, and J. Reschke. HTTP Semantics.
RFC 9110, 2022.
[7] E. F. Foundation. Certbot, 2019. https://certbot.eff.org/,（2023 年 10 月 9 日閲覧）.
[8] Google.
Chromium Blog:
A secure web is here
to stay, 2018.
https://blog.chromium.org/2018/02/
a-secure-web-is-here-to-stay.html, （2023 年 10 月 9日閲覧）.
[9] Google.
Chromium Blog:
Increasing HTTPS adophttps://blog.chromium.org/2021/07/
tion, 2021.
increasing-https-adoption.html, （2023 年 10 月 9 日閲覧）.
[10] G. King, J. Pan, and M. E. Roberts. How censorship in China
allows government criticism but silences collective expression.
American Political Science Review, 107(2):326––343, 2013.
[11] D. Merkel. Docker: lightweight linux containers for consistentdevelopment and deployment. Linux Journal, 239(2):2, 2014.
[12] Mozilla. Mozilla Root Store Policy version 2.8.1, 2023.
https://www.mozilla.org/en-US/about/governance/
policies/security-group/certs/policy/, （2023 年 10月 9 日閲覧）.
[13] Nagios Enterprises. Nagios Core. https://www.nagios.org/projects/nagios-core/, （2023 年 10 月 9 日閲覧）.
[14] R. Sleevi.
Enforce 398-day validity for certiﬁhttps:cates issued on-or-after 2020–09–01, 2020.
//chromium.googlesource.com/chromium/src/+/
ae4d6809912f8171b23f6aa43c6a4e8e627de784, （2023 年10 月 9 日閲覧）.
[15] The Fedora Project. The container optimized OS. https://fedoraproject.org/coreos/, （2023 年 10 月 9 日閲覧）.
[16] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates
in the Domain Name System (DNS UPDATE). RFC 2136, 2000.
[17] X. Xu, Z. M. Mao, and J. A. Halderman. Internet censorship in
China: Where does the ﬁltering occur? In N. Spring and G. F.
Riley eds., Passive and Active Measurement, pp. 133–142, 2011.
[18] 土屋. 認証基盤と連携したメールホスティング環境の構築. 学
術情報処理研究, (13):5–16, 2009.
[19] 土屋. 管理者が安全に交代できる学内ホスティングサービス.
電子情報通信学会論文誌, J95–B(10):1264–1272, 2012.
[20] 土屋, 中村. 事業継続性に配慮した認証基盤システムの構築と運用. 情報処理学会論文誌, 63(3):879–894, 2022.
[21] 河野, 稗田, 中村. Shibboleth と OpenAM の連携による認証レベルを制御可能なシングルサインオン基盤の構築. 学術情報処
理研究, 21(1):71–81, 2017.
[22] 赤尾. 京都大学で提供するホスティングサービスの改定. 大学
ICT 推進協議会 2013 年度年次大会論文集, 2013.
[23] 浜元, 井田, 齋藤, 小田切, 綿貫, 横山. 複数クラウドを利用した
2 段階認証対応全学認証基盤の構築と運用. 学術情報処理研究,
24(1):94–103, 2020.
[24] 島岡, 片岡, 谷本, 西村, 山地, 中村, 曽根原, 岡部. 大学間連携のための全国共同認証基盤 UPKI のアーキテクチャ設計. 電子情報通信学会論文誌, J94–B(10):1246–1260, 2011.
[25] 松平, 笠原, 高田, 東, 二木, 藤田. 金沢大学における統合認証基盤の現状と課題. 大学 ICT 推進協議会 2013 年度年次大会論文集, 2013.
[26] 平野. Web ホスティングサービス. 名古屋大学情報連携基盤センターニュース, 第 3 巻, pp. 7–8, 2004.