シングルサインオン(SSO)は、ユーザーが一組の認証情報で複数のシステムにログインできるようにすることで、アクセスを簡素化します。これは認証プロセスに明確なメリットをもたらす一方で、その利便性がリスクを集中させる場合もあります。2025年に発生した米ペンシルベニア大学の情報漏えいがそれを示しています。
報道によると、攻撃者はPennKeyのSSOアカウントを侵害し、そのアクセス権を使ってVPN、Salesforce、Qlik、SAP、SharePointを含む内部システムに侵入しました。この攻撃では、120万人分のデータが盗まれる結果となりました。
だからといって、SSO自体が安全でないというわけではありません。適切に構成・保護されていれば、SSOはパスワードの乱立を減らし、アクセスポリシーを一元化し、多要素認証(MFA)を導入しやすくすることで、セキュリティを向上させることができます。
ただし、組織がこうしたメリットを享受できるのは、SSOを重要なセキュリティ制御として扱っている場合に限られます。一つのログインで複数のシステムへの扉が開くのであれば、そのログインには強固な保護が必要です。
では、貴社のSSOログインは十分に保護されているでしょうか。それを判断するには、SSOが有効になっているかどうかだけでなく、どのように保護されているかに目を向ける必要があります。
強力なSSOパスワードから始める
「強力なパスワードを導入する」というアドバイスは目新しいものではありませんが、一つの認証情報で複数のシステムのロックを解除できる場合には特に重要になります。とはいえ、強力であることが必ずしも使いにくさを意味するわけではありません。そもそもSSOは、認証時の手間を減らすために設計されているのですから。
NISTによる最新のガイダンスは、脆弱なパスワードや漏えい済みパスワードのスクリーニングとあわせて、長さと使いやすさを重視しています。単要素のパスワードがまだ許容されるシナリオでは、NISTは最低15文字を推奨しています。
MFAと併用するパスワードは最低8文字とし、システムは最大64文字までのパスワード作成をユーザーに許可すべきだとしています。また、NISTは新しいパスワードを、よく使われる・推測されやすい・過去に漏えいしたパスワードのブロックリストと照合してチェックするよう、組織に求めています。
同様に重要な点として、NISTは多くの組織で今も残っている旧来型のパスワードルールの一部を推奨していません。複雑さの義務付けや定期的なパスワードリセットは、数字を一つ変えるだけ、末尾に記号を追加するだけといった、予測可能なパターンにユーザーを誘導してしまう恐れがあるためです。
MFAを追加する、ただし最新の攻撃に耐えられるものを
強力なSSOパスワードだけを、攻撃者とアプリケーションの間に立つ唯一の防壁にすべきではありません。インフォスティーラーの登場により、攻撃者はパスワードやその他の認証情報をこれまで以上に容易に窃取できるようになっており、規制要件を満たすパスワードすら、こうしたログに定期的に出現しているのです。
MFAはさらにもう一段階の保護を加え、攻撃者が侵害済みのパスワードをログイン成功につなげることを難しくします。SSOにおいては、MFAを一貫して適用すべきです。つまり、一部の「高リスク」アカウントだけに有効化するのではなく、すべてのユーザー、アプリケーション、アクセスシナリオに適用する必要があります。
また、どのような種類のMFAを導入しているかにも目を向ける価値があります。SMSコードや基本的なワンタイムパスワードは、パスワードのみの場合よりは優れていますが、最も強力な選択肢とは言えません。
可能な限り、組織はFIDO2セキュリティキー、WebAuthn、パスキーといったフィッシング耐性のある方式へ移行すべきです。特に、特権を持つユーザーや機微なシステムへのアクセスにおいてはなおさらです。
Specopsで安全なMFAを導入する
Specops Secure Accessのようなソリューションは、組織がパスワード攻撃から身を守るのに役立つほか、OIDCおよびSAMLを介したSaaSアプリケーション向けのSSOにも対応しています。
Windowsログオン、RDP、VPN認証へのMFA追加に加え、Specops Secure Accessは組織が単一の場所からユーザーアクセスを管理できるようにし、アイデンティティ攻撃対象領域を縮小しながら、規制監査やサイバー保険の条件も満たせるよう支援します。
SSOの背後にある資産を保護する
組織はまた、SSOの背後にある資産を保護し、アイデンティティがどのように発行・信頼・委任されるかを制御する必要があります。
まずはIdP(アイデンティティプロバイダー)の管理者アカウントから始めましょう。これらのアカウントは、認証ポリシーの変更、アプリケーションの追加、ユーザーの追加・リセット、統合の承認を行うことができます。フィッシング耐性のあるMFA、専用の管理者アカウント、ジャストインタイムアクセス、そして厳重な監視によって保護すべきです。
署名証明書と鍵についても、厳格な管理が必要です。SAML証明書とトークン署名鍵は、アプリケーションがアイデンティティプロバイダーを信頼するための基盤となるものです。これらが漏えいしたり悪用されたりすると、攻撃者がユーザーになりすましたり、信頼されたセッションを悪用したりできる可能性があります。アクセスは厳しく制限し、変更があればアラートを発報させ、証明書は失効前にローテーションすべきです。
OAuthのシークレットや認証情報にも同様の注意を払う必要があります。クライアントシークレット、アプリケーションの認証情報、リフレッシュトークンは、攻撃者に長期間有効なアクセスを与えかねず、しかも対話的なログインを再度行わせずに済んでしまう場合すらあります。これらはシークレットボキュラーで保管し、定期的にローテーションし、アプリケーション登録に過剰な権限が付与されていないか見直しましょう。
最後に、同意付与と委任された権限を見直してください。攻撃者は初期侵害の後もアクセスを維持する方法を探すことが多く、リスクの高いサードパーティアプリケーションの権限が、その足がかりを与えてしまうことがあります。ユーザーの同意付与を制限し、機微な権限には管理者の承認を必須とし、古くなった、あるいは過剰な権限が付与された許可は削除してください。
SSOは安全なのか
適切に導入・保護されている限り、SSOには依然として利用する価値があります。ユーザーにとってのメリットはシンプルです。アクセスが容易になるのです。アプリケーションごとに別々のパスワードを覚えたり、忘れた認証情報を何度もリセットしたりする必要がなくなります。
多くの場合、SSOを使えば一度サインインするだけで、余計な手間をかけずに連携されたリソース間を移動できます。
これはサービスデスクの負担軽減にもつながります。パスワード忘れやアカウントロックが減れば、それだけサポートチケットも減り、IT部門はより価値の高い業務に時間を割けるようになります。
セキュリティの観点から見ると、SSOは組織に認証を一元管理できる場所を提供します。アプリケーション側でユーザーのパスワードを直接扱う必要がなくなり、代わりにアイデンティティプロバイダーから発行される信頼済みの認証トークンに依存できるようになります。これにより、さまざまなサービスにまたがるパスワードの露出が減り、セキュリティチームはMFA、条件付きアクセス、ログ記録、アカウント失効といった制御を一箇所で実施できるようになります。
SSOは、ビジネスクリティカルなリソースへのアクセスを高速化することにも役立ちます。ユーザーがツールごとに認証情報を入力する必要がなくなれば、必要なシステムへより速く、より少ない支障でたどり着けるようになります。
コンプライアンス面でのメリットもあります。アクセス管理を一元化することで、レポーティングや監査、強力な認証要件の遵守、そしてユーザーの退職や役割変更時の迅速なアクセス削除がしやすくなります。
SSOがすべてのサインインシナリオをカバーするわけではなく、デフォルトで安全というわけでもありません。しかし、適切に堅牢化すれば、ユーザー体験を向上させ、ヘルプデスクの負担を軽減し、セキュリティを強化し、アクセスの統制をしやすくすることができます。
Specopsで貴社のSSOを確実に保護する
現状、SSO環境のセキュリティは認証情報の強度に大きく依存しているため、ポリシーで強力なパスワードを義務付けることが極めて重要です。Specops Password Policyは、組織がポリシー管理を簡素化し、60億件を超える一意の漏えい済みパスワードを継続的にブロックできるよう支援することで、この点をカバーします。
Specops Secure Accessは、サードパーティのアイデンティティプロバイダーを介してフェデレーションされたものも含め、SAMLおよびOIDCベースのアプリケーションにMFAを適用することで、この保護をさらに拡張します。
貴社のSSO環境のセキュリティ強化についてご相談されたい場合は、今すぐお問い合わせいただくか、デモをご予約ください。
