【図解】認証技術の種類やSSOを徹底解説|パスワード・FIDO・OAuth

セキュリティ

認証は、システムやネットワークにアクセスしようとするユーザが「正しい利用者かどうか」を確認するプロセスです。
パソコンやスマホの電源を入れた場合にIDやパスワードを入力したり、顔や指紋認証などがあります。
本書はパスワード認証、スマホ認証(FIDO)の認証技術と、SAML、KerberosのSSO、OAuthの認可技術について仕組みを説明します。

認証とは

認証(Authentication)とは、「その人(またはシステム)が本当に名乗っている本人であるか」を確認する仕組みのことです。
セキュリティの基本中の基本で、アクセス制御の最初の関門になります。
たとえば会社のシステムにログインする場合、誰かを名乗り、パスワードでそれを証明しますが、この「証明する」プロセスが認証です。

認証の種類

名称説明
知識認証本人しか知らない情報を使うことでパスワードなどがあります。
生体認証代表的なものに指紋、顔、虹彩(目)があります。
それ以外に筆跡、まばたきなどの行動パターンも生体認証です。
所有情報スマートフォンなどがあります。
SMSにメッセージが送られそれに書かれているコードで認証するのも所有情報を使った認証です。

認証と認可の違い

・認証(Authentication):あなたは誰かを確認する
・認可(Authorization):その人が何をしていいかを決める

認証と認可

本人認証技術

パスワード認証

パスワード認証はIDとパスワードを使って認証をすることです。
パスワードが他に人にバレてしまうと悪用されてしまう可能性があるため、最近ではパスワード認証だけのサービスは減ってきています。

パスワード認証

スマホ認証(FIDO)

スマホ認証(FIDO)(ファイド)はパスワードを使用せず、スマートフォンの本人確認情報を利用するものです。

FIDOの構成

実際は、サービス提供サーバ=認証サーバのケースも多い。

FIDOの事前準備と認証時の流れ

FIDOが最初に事前準備として、秘密鍵と公開鍵のセットを生成し、認証サーバへ公開鍵とユーザIDを登録します。

スマホ認証(FIDO)の事前準備

認証時にはスマートフォンからWEBサービスなどのサービス提供サーバへ認証要求(①)し、認証サーバへ渡されます。(②)
認証サーバはランダムな値を生成してサービス提供サーバ経由でスマートフォンまで返します。(③④)
スマートフォンで生体認証してスマートフォン利用者が本人であることが確認できたら、これに秘密鍵でディジタル著名して認証サーバへ返します。⑤
認証サーバは公開鍵でディジタル著名を確認して認証完了となります。⑦

  • スマートフォンから「サービス提供サーバ」へ認証要求
  • 「サービス提供サーバ」は「認証サーバ」へ認証を依頼
  • 「認証サーバ」はチャレンジ(ランダムな値)を生成して、オリジン(サーバのURLなど)と一緒に「サービス提供サーバ」へ送信
  • 「サービス提供サーバ」は、チャレンジとオリジンをスマートフォンへ返す
  • スマートフォンで生体認証(またはPIN)してスマートフォン利用者が本人であることが確認
  • 本人確認ができたら、チャレンジとオリジンを秘密鍵で署名
  • ランダムな値に秘密鍵でディジタル著名して「認証サーバ」へ返す
FIDO認証の流れ

■ポイント
・オリジン(「スキーム(httpsなど)+ドメイン+ポート」の識別情報)で、フィッシング攻撃対策
・生体認証を使用
・生体情報は、どこへも流れない(スマートフォンのブラウザや、サービス提供サーバ、認証サーバへ流れない)
・利用者からの応答はディジタル署名を使用して

リスクベース認証とは

普段と異なる環境から認証要求があった場合、通常の認証に認証方法追加することです。

シングルサインオン(SSO)とは

シングルサインオン(SSO)とは、一度のログインで複数のWebサービスやアプリケーションに対しログインできる仕組みです。

例えば、あなたが Google アカウントで Gmail、YouTube、Googleドライブ を使っているとします。
1回Googleアカウントにログインしたら、Gmailも、YouTubeも、Googleドライブも、もう一回ログインしなくて済みます。

SSOの概要

社内システムですと、パソコンにログインしたWindowsのアカウント(ActiveDirectoryのアカウント)で、社内のシステムへログインすることで、社内のシステムログインのためのIDやパスワードの入力を省略できます。
これがシングルサインオン(SSO)の考え方です。

シングルサインオン(SSO)にはいくつかやり方(技術)があります。
次の章からはそのやり方を説明します。

SAMLとは

SAML(サムル)は、SSOに用いる通信プロトコルの一つで、異なるインターネットドメイン間でユーザーの認証、認可に関する情報交換をするための仕様です。
1回の認証で複数のサービスにログインできるようになるので、朝一にパソコンへ社内のAzure AD(Microsoftが提供するクラウド型の認証・ディレクトリサービス)でログインすれば、企業が利用している、Gmail(Google Workspace)やZoomなどのサービスをログインせずに利用できます。

SAMLの構成

SAMLは下のようにサービスプロバイダ(SP)(WEBサーバなど)と、アイデンティティプロバイダー(IdP)から構成されています。
また、情報はXML形式のデータであることが特徴です。

SAMLの流れ

SAMLを使った認証の流れは次の通りです。

  • クライアントがSPへアクセス
  • IdPへリダイレクト
  • クライアントはIDとパスワードを入力
  • IdPがIDとパスワードで認証し、成功するとアサーションが生成
  • IdPがが生成したアサーションをクライアントへ送信
  • クライアントは受け取ったアサーションでSPへログイン
SAMLの流れ

なお、すでにIdPにログイン済み(セッションあり)なら、再認証せずにすぐアサーションが発行されます(シームレスSSO)。

また、SAML情報交換の際に使用するアサーションはXML形式であるという特徴があります。

SAMLの情報はXML

Kerberos(ケルベロス)認証

Kerberos認証は、Windows、Linux、macOSなど、OSの種類にかかわらず利用できる認証技術です。
Kerberos認証はActive Directoryで推奨される認証方式のため、Windowsを中心とした社内システムのSSOで利用されています。
ケルベロス認証は認証時にチケットを使用することでアカウント(ユーザ ID、パスワード)の漏洩を防いでいます。

  • ユーザがユーザIDとパスワードをAS(Authentication Server)に送信
  • 認証に成功するとASからTGTというTGS利用用チケットが発行されクライアントへ送る
  • クライアントはTGTをTGSへ提出して社内サーバ(WEBサーバ等)利用用のチケット発行を要求
  • TGSはTGTを確認して社内サーバ(WEBサーバ等)利用用のサービスチケット発行してクライアントへ送る
  • クライアントはWEBサーバへサービスチケットを提示して利用可能となる

社内にある他のサーバを利用したい場合、TGTが有効である間は③~⑤を繰り返してサービスチケットを発行する。

ケルベロス認証の流れ

⑤のサービスチケットを使った通信は暗号化がされていないのでHTTPSなどで暗号化が必要です。

Kerberos を実装するにあたり、ActiveDirectoryサーバにユーザ、グループ、コンピュータなどのプリンシパルを保管が必要です。
ActiveDirectoryであればActiveDirectoryサーバに一元管理されていますが、この情報にあくせすするためにはLDAPというプロトコルが使用されています。


LDAPについて

LDAPとは、ネットワーク機器やユーザーID、パスワードを管理する「ディレクトリサービス」の維持やアクセスを行うプロトコルのことです。

名称説明
dcドメイン構成要素(下の例だとabc.co.jp)
ou組織(グループ)
cn一般名
dn識別名(下の一番右のsuzukiの場合、dn: cn=Suzuki , ou=Group1 , dc=jp , dc=co , dc=jp のように表現する。)
LDAP

上の絵には描かれていませんが、パスワードもLDAPサーバー上で管理されます。
LDAPは認証の際にパスワードが暗号化されないため、ケルベロス認証などと組み合わせて使用します。

他社サービス認可

あるサービスが他のサービスのリソースにアクセスする権限を与えるための仕組みを認可と言います。
この認可を実現するための技術を説明します。

OAuth

OAuthはSNSなどのアカウントで他のサービスへアクセスを許可できる仕組みです。

あるサービスを利用する際、「Googleでサインインしますか?」などのメッセージが表示されたことがある場合、それはOAuthが使われています。
OAuthは、新しいアカウントを作成することなく、さまざまなアプリやサービスにシームレスに接続するためのアクセス許可を付与できます。

OAuthでは、ユーザをリソースオーナー、すでに登録済みのサービス(連携元)リソースサーバ、連携先のサービスをクライアントと表現します。

OAuth

OAuthは登場人物を次のように表現しています。

  • リソースオーナー:ユーザ
  • クライアント:Webサービスなどを提供するアプリケーション
  • 認可サーバ:認証をする
  • リソースサーバ:リソースオーナーのデータを保持

OAuthの流れ

  • リソースオーナーがクライアントへログイン要求
  • クライアントは認可サーバへリダイレクトして許可要求を出す
  • 認可サーバは許可確認画面を表示し、このクライアントへアクセストークンを発行してよいのか確認する
  • リソースオーナーが許可
  • 認可ーサバはアクセストークンを発行
OAuth

無線LANやネットワーク機器への認証技術

前回までの章は、主にWEBアプリケーションやクラウドを使用する前の認証で使われる認証技術を説明しましたが、ここからは社内のネットワーク機器に接続する場合などに使用される認証技術を紹介します。

IEEE802.1X

IEEE802.1Xは有線LANや無線LANでネットワーク機器におけるユーザ認証の規格で、データリンク層(Layer 2)のプロトコルです。
IEEE802.1Xはユーザ(PC)をサプリカント、ネットワーク機器を認証装置(オーセンティケータ)、認証をする機器を認証サーバと呼びます。

IEEE802.1Xの構成

RADIUS

RADIUSは主にネットワーク機器(ルーター、スイッチ、VPNなど)へのアクセス制御を提供するために使用されるプロトコルでIP層以上で動作します。
リモートアクセス環境において、認証情報やアカウンティング情報をやり取りします。

<認証の流れ>

RADIUSはユーザ、RADIUSクライアント(ネットワーク機器等)、RADIUSサーバ(認証するサーバ)という構成になっています。
①ユーザがRADIUSクライアントへログイン要求
②RADIUSクライアントがユーザへIDとパスワードを要求
③ユーザがIDとパスワードをRADIUSクライアントへ送信
④RADIUSクライアントは、IDとパスワードをもとにRADIUSサーバへアクセス認証をリクエスト
⑤RADIUSサーバが認証結果をRADIUSクライアントへ返す
⑥RADIUSクライアントは認証結果をユーザへ返す

RADIUS認証の流れ

RADIUSは一般的にEAP-TLSなどと併用してパスワードを暗号化します。

まとめ

主な用途プロトコル(方式)備考
パスワードレス認証FIDO
社内システムシングルサインオン
Kerberos
RADIUS、LDAPサーバと組み合わせ使用することが多い
社内システム、クラウドサービスのシングルサインオン
SAML
RADIUS、LDAPサーバと組み合わせ使用することが多い
他社サービス認可OAuth
無線LANやネットワーク機器への認証IEEE802.1X
 EAP-TLS
 EAP-PEAP
 RADIUS
RADIUSサーバと組み合わせて使用することが多い

腕試し(理解テスト)

腕試し(理解テスト)に挑戦する場合はこちらをクリック。

コメント

タイトルとURLをコピーしました