「隣の〇〇大学、Office 365を使い始めたらしい」
「もうそろそろメールをクラウドにしたい」
「VPN接続用の証明書管理が大変だからもうやめたい」
皆さんの周りでこんな声、ありませんでしょうか。
Office 365やG Suiteなどを代表とする多くのクラウドサービスは、自組織でのサーバー調達や設定、管理の工数をなくす、もしくは減らすことができます。また、インターネットにつながる環境であればシステムにアクセスできるため、効率良く仕事・学習をすることができます。
加えて、教育機関であれば数多くのクラウドサービスを無料もしくは格安で利用することができます。
このように、クラウドサービスの利用は管理者から見ても利用者から見てもメリットが大きいため、教育機関では加速度的に導入が進んでいます。
一方で、その“便利さ”の裏には注意しなければいけないことがたくさんあり、それらを無視してしまうと大惨事になりかねないのも事実なのです。
認証をひとつにまとめる
クラウドサービスのセキュリティレベルは製品によってさまざまです。中には、ユーザの初回サインイン時に、ID/パスワードとは別の認証要素（たとえば携帯電話へのパスコード送信）の設定を推奨するようなセキュリティレベルの高いクラウドサービスもありますが、大半のクラウドサービスはユーザ名とパスワードのみで認証しているのが実情です。
従来のようにオンプレミスにアプリケーションサーバーを構築し、学内のネットワークからしかシステムにアクセスできない環境であれば、ID/パスワードのみの認証で問題ない場合がありますが、クラウドサービスはインターネットに公開され、不特定多数の人間からアクセスされます。
インターネット上の悪意を持った攻撃者から標的にされ、ID/パスワードがリークした場合にどうなるか、想像は難しくありません。
情報セキュリティの説明をする際には、よく「桶の理論」という言葉が使われます。
下の図は、「桶の理論」を表します。丸い桶を構成する一枚一枚の板がセキュリティを構成する各システム。そして、板の高さ(深さ)が各システムにおける認証のセキュリティレベルの高さ、水位が組織全体のセキュリティレベルの高さとなっています。
左の桶は、各システムにおいて様々な対策を講じても、一番低いレベルが組織全体のセキュリティレベルになってしまうことを表しています。そのため、組織全体のレベルを上げるためには、右の桶のように例外なくすべてのシステムにおいて、認証のセキュリティレベルを上げることが必要になります。
とは言っても、各システムに実装されている認証の設定項目は様々で、それぞれの設定がどれほどセキュリティレベルを向上させているかは、非常に判断が難しいのが実情です。
そこで、各システムにアクセスする前に、クラウドベースの認証基盤においてユーザ認証を行うことで、組織全体の認証のセキュリティレベルを統一することができます。
また、認証ポイントを1箇所にまとめることで認証ポリシーも統一化され、セキュリティポリシーが変更になった際にも迅速かつ柔軟に対応することができます。
多要素認証（MFA）
前項までのように各システムの認証を単一の認証基盤にまとめることによって、組織内の認証のセキュリティレベルが一定に保たれます。次に、そのセキュリティレベルを上げるために有効な手段が多要素認証です。
そもそも個人を特定するための「認証の要素」には3種類あります。
Something You Know – 知識情報
Something You Have – 所持情報
Something You Are – 生体情報
ID/パスワードのように、個人が記憶しているものは記憶情報（Something You Know）、キャッシュカードのように個人しか持っていないものは所持情報（Something You Have）、指紋や虹彩などの個人の身体的特徴が生体情報（Something You Are）です。
そしてこれらの３つの認証要素を2つ以上組み合わせたものを多要素認証と呼び、認証要素が一つ破られても2つ目以降の認証要素によってデータが守られるため、ID/パスワードのみのようないわゆる単要素認証より安全な仕組みになっています。
多要素認証という言葉にはあまり馴染みがないかもしれませんが、銀行のATM（キャッシュカードと暗証番号）やパスワード再発行（秘密の質問とSMSでのワンタイムパスワード）のように、実は気づかないうちに日常生活の中で私たちは多要素認証を利用しています。
認証ポイントを一つにまとめ、そのポイントを多要素認証で強固にすることで、組織全体の認証セキュリティレベルが飛躍的に向上します。
シングルサインオン（SSO）
シングルサインオン(SSO)はユーザの利便性を向上させるための仕組みです。
認証のポイントを一つにまとめただけでは、ユーザは認証基盤の認証とアプリケーションの認証の2回にわたって認証を要求されます。シングルサインオン(SSO)とは、各アプリケーション側での認証を認証基盤に任せることにより、本来2回必要な認証を1回に省略することができます。
例えば、ユーザがアプリケーションAにアクセスする(①)と認証基盤での認証が要求(②)されID/パスワードとSMSへのワンタイムパスワード送信により多要素認証を実施(③)します。
その後、同じ認証基盤に認証をまとめているアプリケーションBを利用する際は、アプリケーションAを利用する際に実施した認証情報を引き継ぐため、認証不要でアプリケーションBに直接アクセスする(④)ことが可能です。
このように、シングルサインオン(SSO)を利用することによって、一度の認証手続きで各アプリケーションへの認証を省略することができます。
シングルサインオン(SSO)の仕組みは大きく分けて以下の4通りが存在します。
| エージェント方式 | システムに認証を代行するモジュールをインストール |
| 代理入力方式 | ID/パスワードを自動的に代理で入力 |
| フェデレーション方式 | パスワードの代わりにチケットを受け渡し |
| リバースプロキシ方式 | 認証を代行するリバースプロキシサーバを利用 |
システムの規模や予算に合わせてシングルサインオン(SSO)の方式を選ぶことができ、それぞれにメリット・デメリットが存在します。
また、シングルサインオン(SSO)を構築することによって、ユーザは認証基盤のID/パスワードを一組覚えるだけでいいので、パスワード忘れによる管理者への問い合わせは減り、簡単なパスワードの利用・パスワードの使いまわしも防止することができます。
これまでに説明した、「認証をひとつにまとめる」「多要素認証を設定する」「シングルサインオン(SSO)を構成する」ことによって、モバイルデバイスでクラウドサービスを活用する、次世代の教育ICT環境に対応できる認証基盤を構築することができます。
