話題の「パスキー」は「シングルサインオン」と何が違うのか?
パスワードだけの認証では安全とは言えない。そのため、多要素認証やパスキーなどの改善策が生まれた。シングルサインオンもその一つだ。パスキーとシングルサインオンは何が違うのだろうか。それぞれの利点と欠点は何だろうか。
パスワードは覚えにくく、サイバー攻撃を受けると漏えいしやすい。認証手段としては不完全だと言えるだろう。このような欠点を改善するために多要素認証やパスキー、シングルサインオン(SSO)といった技術が利用され始めた。
パスキーとSSO、何が違うのか
パスキーもSSOも、パスワードの欠点を改善するという点では似ている。ではどこが違うのだろうか。利点と欠点は何だろうか。
1Passwordのステイシー・ハリス氏(コンテンツクリエーター、ストラテジスト)は、パスキーとSSOについて次のように簡潔にまとめた。
「パスキーはパスワードでは決して実現できなかった、よりシンプルで安全な認証体験へと人々をシフトさせる有力候補だ。パスキーで保護されたアカウントにアクセスするために必要なのは、生体情報かデバイスのパスコードだけだ。パスキーは素早く簡単に使え、他の認証方法よりも安全だ」
ではSSOはパスキーとどこが違うのだろうか。
「SSOのユーザーはアカウントごとにID/パスワードといったクレデンシャルを個別に使用するのではなく、(「Amazon Web Services」(AWS)や「Microsoft Azure」などの)単一のIDプロバイダーを使用してアカウントにサインインできる。ユーザーはアカウントごとに固有の認証情報を覚える必要がない。SSOプロバイダーにログインするだけでよい」(ハリス氏)
パスキーとSSOはどちらが優れているのか
パスキーとSSOはパスワードを代替するという意味では似ているが、細部が異なる。まずはどのようなユーザーメリットがあるのかを比較してみよう。
短時間で認証が終わるか
認証の目的はユーザーのアカウントとデータを安全に保つために、ユーザーの身元を確認することだ。だが、ユーザーにとって認証は単なる面倒な作業に過ぎない。これはWebサービスごとに複雑なパスワードを入力しなければならないことを考えるとよく分かる。つまり、ユーザーや企業にとって優れた認証かどうかを判断する第一条件は手間が掛からないかどうかだ。
SSOを導入すると、SSOプロバイダーにログインするだけでSSOに対応した多数のWebサービスにアクセスできる。すぐに仕事を始めることができ、違うサービスにアクセスしたときに仕事が中断しにくいというわけだ。
パスキーもパスワードより速い。だが、パスキーとSSOのどちらが速いのかは場合による。パスキーで保護したアカウントにサインインする場合、プロセスは簡単でシームレスだ。ユーザーは指紋や顔をスキャンするか、デバイスのパスコードを入力するだけでよい。実際の認証プロセスはユーザーから見えないところで素早く実行される。だが、利用するサービスが多岐にわたるとサインイン作業が面倒になるかもしれない。
認証のセキュリティは強力か
認証がすぐに終わるのを目にすると、アカウントの安全性がどうなっているのかが心配になるかもしれない。SSOとパスキーはどちらも安全な認証方法であり、サイバー攻撃のリスクを減らす。だが、SSOとパスキーはやり方が違う。
SSOを導入すると1人のユーザーに必要なユーザー名とパスワードの数が減る。攻撃対象となるエントリーポイントが少なくなるという利点がある。一方で、欠点もある。SSOのセキュリティの最大のリスクは、単一障害点があることだ。SSOアカウントが漏えいした場合、そのSSOでアクセスできる全てのアカウントが危険にさらされる。SSOを利用する際は、強固でユニークなパスワードを選んで、それを安全な場所に保管しなければならない。
パスキーはアカウントごとにユニークな値が自動的に作成されるため、あるWebサイトが侵害されたとしても、別のWebサイトの情報は安全だ。漏えいする危険はない。これはパスキーが公開鍵暗号方式を採用していて、パスキーごとに異なる公開鍵と秘密鍵を持っているためだ。
パスキーでアカウントを保護した場合、WebサイトやWebアプリケーションはユーザーの公開鍵だけを保存する。パスキーを別のWebサイトと同期または共有しない限り、秘密鍵はユーザーのデバイスにのみ保存される。
攻撃者がユーザーのパスキーを使ってWebサイトなどにログインするには、(ユーザーが意図的に共有していない限り)秘密鍵を盗むためにユーザーのデバイス自体に(物理的に)アクセスする必要がある。遠隔地からの攻撃ではかなり困難だろう。
可用性はどうか
利便性、安全性の他にも認証では「可用性」が重要だ。一時的なものであっても、認証用の秘密へアクセスできなくなると、仕事が進まなくなるからだ。
SSOプロバイダーが障害を起こすと、そのプロバイダーに依存している全てのWebサイトにログインできなくなる。プロバイダーの復旧を待つしかない。
パスキーを使っている場合は、プロバイダーの停止は問題になりにくい。ただし、パスキーの保管方法によっては、問題が起きる。秘密鍵を保管しているデバイスにアクセスできなくなったり、故障した場合は、そのパスキーにのみ頼っていた認証は使えなくなったりするからだ。
実装しやすいのはどちらか
最後に考えなければならないのは、SSOとパスキーを実装する場合の条件だ。
ハリス氏によれば、SSOプロバイダーはそれぞれ独自のワークフローを定めていて、ユーザーが所属する組織によっては実装が複雑になり、コストがかかることもある。
パスキーはSSOよりも実装がたやすい。生体認証やデバイスのパスコードと連動するようにパスキーを設定するだけで、ログインプロセスはバックグラウンドでシームレスに機能するからだ。ただし、パスキーは成長途上にあるため、利用できないWebサイトやアプリケーションが残っている。これが実装上の問題になることがある。
SSOとパスキーのどちらを選ぶべきなのか
ハリス氏は「どちらか一方を選ぶ必要はない。パスキーはパスワードレスの未来を先導しており、SSOはビジネスと企業のセキュリティに必要な役割を(まだ)持っているからだ」とまとめた。
SSOを導入すると管理者は高度なアクセス制御を実行できる。どの従業員が職場のメールアドレスで「Google Workspace」のアカウントを作成できるかを、あらかじめ決めることが可能だ。ハリス氏によれば、この機能があるため、パスキーがビジネス環境でSSOに取って代わる可能性は低い。だが、SSOでカバーされない全てのサービスを保護するのに役立つだろう。
SSOのアカウント自体をパスキーで保護する方法をハリス氏は勧めている。多くのSSOプロバイダーが、ユーザー名とパスワードの組み合わせではなく、パスキーでサインインすることを認めている。企業にとっては従業員のパスワード問題を解決しつつ、SSOの管理権限を企業側で維持できることを意味する。
SSOとパスキーがうまく連動することで、ビジネス全体のセキュリティ確保に必要な運用コストを抑えることができる。大半のアカウントをSSOで保護し、その他のアカウント(SSOアカウントを含む)は強力なパスキーで保護する。これが結論だ。
Copyright © ITmedia, Inc. All Rights Reserved.
この記事の著者
関連記事
こんなメディアも見られています
キーマンズネットに関連する情報をお探しであれば、こちらのメディアもお役に立てるかもしれません。
SpecialPR
アクセスランキング
-
1
Googleの自動化ツール「Workspace Studio」×Gemini、4つの業務効率化アイデア
-
2
M365 Copilotを配っても「使われない」 でもAI活用が進んだ福島県庁の"逆張り"戦略
-
3
「Gemini 3.8 Flash」の狙いは“賢さ”ではない? 発表から見えた3つのポイント
-
4
「Copilot、Word文書まとめて」で社内全滅? 勝手に増殖するAIウイルスで大騒ぎ:895th Lap
-
5
SOAPはRESTに負けたのか? 「古いAPI」を残すか見直すか
-
6
AI議事録「精度98.86%」だけで決められない 5製品の比較表で分かる、選定の分かれ目
-
7
「作った本人しか使えない」を避けるには 文化祭POSが36校へ広がるまで
-
8
新SAP認定試験は「AIの利用OK」 実践型の新方式で備えるべきことは?
-
9
「AIを入れたのに、仕事が変わらない」 企業が見落としている"使い方"
-
10
AIは「使う」から「組み込む」へ — NOT A HOTELに学ぶ、Zoom×AI×API連携で実現する業務自動化と生産性100倍を目指す組織
キーマンズネット SNS
インフォメーション
注目情報をチェック
キーマンズネットをフォロー