キヤノンMJ/サイバーセキュリティ情報局
長らく使われてきたシングルサインオン「ケルベロス認証」のしくみや認証技術の最新動向を解説
本記事はキヤノンマーケティングジャパンが提供する「サイバーセキュリティ情報局」に掲載された「ケルベロス認証？シングルサインオンの認証方式の定番と新技術はどう違う？」を再編集したものです。
ケルベロス認証はサービスへのログイン時に用いられる認証方式のひとつであり、シングルサインオンを実現する手段として長きにわたり利用されてきた。この記事では、ケルベロス認証および、関連する認証技術の仕組みを紹介した上で、「パスワードレス」認証を含めた最新の技術動向について解説する。
ケルベロス認証とは
ケルベロス認証は、ネットワーク経由でアクセスするユーザーを認証する方式のひとつとして古くから用いられてきた。ケルベロスの名は、ギリシャ神話に登場する冥界の番犬「ケルベロス」に由来して命名されたと言われている。
ケルベロス認証は主に、シングルサインオンの認証方式として利用されてきた。つまり、社内ネットワークのようにひとつのドメイン内で複数のサーバーへアクセスしなければならない場合でも、1度のログインで対象のサーバーへすべて認証が完了するシングルサインオンが実現できる。1980年代にマサチューセッツ工科大学（MIT）で開発され、現在に至るまで広く使われている。
ケルベロス認証が用いられている代表例として、Active Directoryが挙げられる。Active Directoryは Windowsを中心とした社内ネットワークを構築している企業ではよく用いられているもので、ネットワーク上の機器を一括で管理することを目的とする。このActive Directoryの認証プロトコルとして推奨・採用されているのがケルベロス認証だ。
ケルベロス認証のようなシングルサインオンの仕組みを導入するのは、ユーザー、管理者双方にメリットがある。ユーザーにとっては管理するパスワードがひとつで済むため、複雑なパスワードを忘れないよう記憶する手間を省き、利便性が向上する。また、管理者にとっては、複数のサーバーがあっても認証システムを一元化できるため、管理作業が軽減される。
ケルベロス認証の仕組み
ケルベロス認証では、はじめにIDとパスワードで認証に成功すると、証明のための「チケット」が発行される仕組みになっている。そして、そのチケットが有効な間は、各サーバーにアクセスした際に「そのサーバーにアクセスするためのチケット」が発行される。その都度、認証が要求されることはなく、シングルサインオンが実現される。ユーザーから見ると、チケットの存在を意識せず、認証作業だけ行なえばよい。
具体的には、以下のような流れとなる。
・ユーザーがIDとパスワードを入力して、認証サーバーへ認証を要求する。
・事前に登録された利用者資格を確認し、認証に成功するとTGT（Ticket Granting Ticket）が発行される。
・ユーザーはTGTを送信し、利用したいサーバーへのアクセスを要求する。
・TGTが有効であれば、該当サーバーへアクセスするためのチケットが発行される。
・ユーザーは、利用したいサーバーへチケットを送信する。
・チケットが有効期間内であれば、サーバーが利用可能となる。
ケルベロス認証ではチケットが盗み見られてしまうと、なりすましの被害を受け、不正にサーバーへアクセスされるリスクがある。そのため、チケットには送信時刻が含まれており、時刻に一定のズレがあるとアクセスできないよう対策が講じられている。
加えて、サーバー間の通信は暗号化され、チケットのやり取りが保護されている。共通鍵暗号方式が採用されており、サーバー側とユーザー側で同じ鍵を用いて暗号化・復号を行なっている。共通鍵はセッションごとに生成され、認証サーバーで管理されるのが特長だ。Active Directoryの場合、一般的に、利用者資格や共通鍵の管理にLDAPが利用されている。
シングルサインオンの仕組みと導入のメリット・デメリット
https://eset-info.canon-its.jp/malware_info/special/detail/220322.html
シングルサインオンの認証方式とは
ケルベロス認証は主にドメイン内で管理される社内のサーバーを対象としていた。一方、ウェブアプリケーションをシングルサインオンへ対応させるための方式としては、エージェント方式やリバースプロキシ方式などが開発されている。
ケルベロス認証の場合、シングルサインオンの連携対象が自社ネットワーク内に限られるという制約があった。しかし、近年はクラウドサービスを業務で利用する場面が増え、社外のサーバーを含めた認証方式が求められるようになっている。そこで、異なるネットワークでも統一されたシングルサインオンの仕組みを構築する規格として、SAML（Security Assertion Markup Language）が利用されるようになった。
図1：SAML認証要求のプロセス
SAMLは主に、ウェブアプリケーションのシングルサインオンを実現する規格だ。ユーザーはIDプロバイダー（IdP、Identity Provider）と呼ばれるサーバーへリダイレクトされ、ID・パスワードを使った認証を実施する。ログインに成功するとSAML認証情報に基づいて、クラウドサービスなどが利用できるようになる。ここで連携対象となるクラウドサービスはサービスプロバイダー（Service Provider）と呼ばれる。
また、ケルベロス認証のような認証方式は、企業のネットワークに用いることを想定していたが、SNSのログインアカウントを活用した認証（ソーシャルログイン）や、認可を簡素化する仕組みも浸透してきている。代表的な規格が、認可の仕組みを提供するOAuthだ。
図2： OAuth認証のプロセス
ユーザーがOAuthに対応するサービスへアクセスすると、SNSへリダイレクトされる。認証のプロセスにて、ユーザーはアカウント情報をログインに利用することを許可する。認証に成功すれば、SNSの情報を連携したサービスが利用できるようになる。
これらの認証方式では、認証に成功したユーザーには認証済みとしてCookieが発行される。利用するウェブブラウザーにてCookieを有効にしておくことが前提となっており、認証済みCookieを送信するユーザーは、ID・パスワードを再度入力する必要なく、アクセス可能となる。
Cookieを削除するとどうなるのか？
https://eset-info.canon-its.jp/malware_info/special/detail/210921.html
進化を続ける認証の技術
シングルサインオンは複数のサーバー、サービスを一度の認証で利用できる点がメリットであり、ユーザーが管理するパスワードもひとつにまとめられる。しかし、最近ではそもそもパスワードを使用しない「パスワードレス認証」の利用も増えている。
パスワードは「知識要素」、すなわちユーザーが知っている情報を用いる認証方式にて用いられる。一方、パスワードレス認証は、知識要素以外の認証要素を用いるのが特徴だ。具体的には、以下の手段が利用される場合が多い。
1） 生体認証
指紋・静脈・顔などの身体的特徴を用いる。スマホやパソコンにも導入が進んでおり、すばやく本人確認する手段として期待されている。
2）所持認証
セキュリティキーやハードウェアトークンを利用する。物理的に所有するため、紛失・盗難に備えて、対策を講じておく必要がある。
3）マジックリンク
一定期間有効なログイン用リンクをメールで送信する。ウェブサービス登録の初期ステップで利用されることが多い。
パスワードレス認証のメリットは、パスワードに起因するセキュリティ上のリスクを軽減できる点にある。推測されやすい単純なパスワードの利用、パスワードの使い回し、ブルートフォース攻撃など、不正アクセスの要因が知られている。パスワードレス認証であれば、こうしたリスクを軽減できるだろう。
一定の導入コストを要するなど、パスワードレス認証の利用にはデメリットも存在するのが実情だ。しかし、最近ではパソコンとスマホの両方を業務利用し、それぞれでサービスへログインするというように、認証に対する要件が複雑化する状況もあり、それを簡素化するためにパスワードレス認証へのニーズが高まっている。
また、パスワード認証も含めた複数の認証方式を併用した多要素認証を利用するケースも増えている。企業や組織においてはセキュリティを向上させるため多要素認証を必須とする場合もあるだろう。
さらに、最近ではアクセスごとにセキュリティリスクを判断し、認証に求める要素を変更する「適応型認証」と呼ばれる仕組みも開発されている。例えば、ユーザーが普段と異なる場所やデバイスからアクセスした場合に高リスクであると自律的に判断し、追加の認証情報をユーザーに要求する、といった仕組みだ。
金融サービスなどでは未登録のデバイスでアクセスした際に、先述のマジックリンクを用いたログインを要求するものもある。機械学習の技術を用いて、普段通り使用しているユーザーの手間を増やすことなく、疑わしい挙動を検知し、高リスクのアクセスのみを検証できるのだ。
社外のクラウドサービスを含め、セキュリティを司る認証システムは重要性を増している。認証方式それぞれで異なる特徴を理解し、利便性・安全性を考慮した上で、最適な方法を選択するようにしたい。
企業はパスワードレス認証に適応できるのか？
https://eset-info.canon-its.jp/malware_info/special/detail/220202.html