現代の企業活動において、業務システムが単一であることは稀です。メール、チャット、ファイル共有、顧客管理、勤怠管理と、従業員は日々複数のアプリケーションを行き来しています。これらすべてのシステムに対して、個別にIDとパスワードを入力し直すことは、業務効率を著しく低下させるだけでなく、パスワードの使い回しやメモ書きによる管理といったセキュリティリスクを誘発します。
ここで重要となる技術が「シングルサインオン（Single Sign-On：以下SSO）」です。一度の認証手続きを行うだけで、許可された複数のシステムやサービスを利用可能にするこの仕組みは、利便性と安全性を両立する現代セキュリティの必須要件といえます。
情報処理安全確保支援士試験においても、SSOは頻出のテーマです。単に「便利にするもの」という理解だけでは太刀打ちできません。認証情報の受け渡し方、各方式のメリット・デメリット、そして技術的な構成要素（Cookie、チケット、トークン、SAML、OIDCなど）を正確に把握する必要があります。本記事では、SSOの基本概念から、オンプレミス環境で主流のケルベロス認証、そしてクラウド時代のフェデレーション方式まで、試験合格レベルの知識を徹底的に解説します。
シングルサインオン（SSO）の基本概念と導入方式
SSOが解決する課題とリスク
SSOの導入目的は明確です。ユーザーにとっては「ログオンの手間削減」であり、管理者にとっては「ID管理の一元化」です。しかし、セキュリティの観点からは「リスクの集約」という意味も持ちます。
もしSSOの認証基盤（マスターキーを持つ場所）が侵害された場合、紐づいているすべてのシステムへの不正アクセスを許すことになります。これを「単一障害点（SPOF）」および「攻撃の集中点」と呼びます。したがって、SSOを導入する場合、その入り口となる認証システムには、多要素認証（MFA）の導入や厳格なログ監視など、通常以上の強固なセキュリティ対策が求められます。
この二面性を理解することが、SSO設計における最初の重要ポイントです。利便性を追求するあまり、セキュリティの脆弱性を作り出してしまっては本末転倒です。
代表的な4つのSSO実装方式
SSOを実現する技術的アプローチは、システムの環境（Webアプリか、クライアントサーバか、クラウドか）によって異なります。試験対策として押さえておくべき主要な方式は以下の4つです。
- エージェント方式
- リバースプロキシ方式
- フェデレーション方式（SAML, OIDC）
- ケルベロス認証方式
それぞれの方式には明確な特徴があり、適用すべきシーン、メリット、デメリットが異なります。システム構成や運用体制に応じて最適な方式を選択することが、実務でも試験でも求められる判断力です。
エージェント方式
Webサーバ（Webアプリケーション）自体に、認証代行を行う専用ソフトウェア（エージェント）を導入する方式です。
仕組み クライアントがWebサーバにアクセスすると、エージェントがリクエストをインターセプト（横取り）します。認証が済んでいない場合、SSO認証サーバへリダイレクトし、認証後に発行されるトークンやCookieを用いてセッションを維持します。このプロセスは、ユーザーからは透過的に行われます。
メリット ネットワーク構成を大きく変更する必要がないため、既存のネットワーク環境に導入しやすい点が挙げられます。特に、複雑なネットワーク構成を持つ企業や、DMZ（非武装地帯）に配置されたWebサーバへの影響を最小限にしたい場合に有効です。
デメリット すべての対象Webサーバに、OSやWebサーバソフト（Apache, IIS, Nginxなど）に対応したエージェントをインストールする必要があります。Webサーバのバージョンアップ時にエージェントの互換性を検証する工数が発生し、運用負荷が高くなる傾向があります。サーバ台数が多い環境では、この負荷は無視できないレベルになります。
リバースプロキシ方式
WebブラウザとWebサーバの間に、認証を一手に引き受ける「リバースプロキシサーバ」を設置する方式です。
仕組み ユーザーからのアクセスはすべてリバースプロキシが受け取ります。ここで認証を行い、許可されたリクエストのみを背後のWebサーバへ中継します。認証情報はHTTPヘッダなどに付与されてバックエンドへ渡されます。Webサーバ側は、信頼できるリバースプロキシからのリクエストであることを前提に処理を行います。
メリット Webサーバ側にエージェントを入れる必要がないため、OSやアプリケーションに依存せず導入可能です。レガシーなシステムや、ソースコード改修が困難なパッケージ製品でもSSO化しやすい利点があります。セキュリティポリシーの集中管理も実現できます。
デメリット すべてのトラフィックがリバースプロキシを経由するため、ここがボトルネックになりやすく、高性能なサーバやロードバランサによる冗長化が不可欠です。また、ネットワーク経路の変更が必要となり、DNS設定やファイアウォールルールの見直しも伴います。
クラウド時代の標準「フェデレーション方式（SAMLとOIDC）」
組織を跨ぐ認証連携の必要性
エージェント方式やリバースプロキシ方式は、主に「自社内（同一ドメイン内）」のWebシステムを束ねるのに適していました。しかし、SaaS（Salesforce、Microsoft 365、Google Workspaceなど）の利用が当たり前になった現在、自社のActive Directoryなどの認証情報を使って、外部のクラウドサービスにログインしたいというニーズが爆発的に増えました。
ドメインが異なるサービス間で認証情報を安全に受け渡す技術、それが「フェデレーション（ID連携）」です。この分野で試験によく出るのがSAMLとOpenID Connectです。どちらもインターネット標準として策定されており、グローバル企業での採用実績も豊富です。
SAML（Security Assertion Markup Language）
SAMLは、異なるインターネットドメイン間でユーザー認証情報をXML形式で交換するための標準規格です。「OASIS」によって策定されました。主にエンタープライズ向けのSaaS連携でデファクトスタンダードとなっています。
登場人物
- IdP (Identity Provider): 認証情報を提供する側。ID管理を行う（例：Azure AD, Okta, 自社のAD FSなど）。ユーザーの身元を保証する信頼の起点となります。
- SP (Service Provider): サービスを提供する側。ユーザーが利用したいアプリ（例：SaaSアプリ）。IdPからの情報を信頼して、ユーザーにサービスを提供します。
認証フロー（SPイニシアチブの場合）
試験では、このフローの順番と、何が（XML）受け渡されているかが問われます。各ステップで交換される情報と、その暗号化・署名の方法を正確に理解することが重要です。
1. アクセス ユーザーがSP（利用したいSaaS）にアクセスします。この時点では、ユーザーはまだ認証されていない状態です。
2. リダイレクト SPはユーザーの認証状態を確認し、未認証であれば認証要求（SAML Request）を作成し、ユーザーをIdPへリダイレクトさせます。このリクエストには、SPの識別情報やコールバックURL（認証後の戻り先）が含まれます。
3. 認証 ユーザーはIdPの画面でID・パスワードを入力し、認証を行います。ここで多要素認証を要求することも可能です。IdPの画面は、企業のブランディングに合わせてカスタマイズされることが一般的です。
4. アサーション発行 認証に成功すると、IdPは「このユーザーは誰々であり、認証に成功した」という情報を含む「SAMLアサーション（Assertion）」を作成します。このアサーションはデジタル署名が付与され、改ざん検知が可能になっています。アサーションには、ユーザー名、メールアドレス、所属部署、権限情報（属性情報）なども含めることができます。
5. 送信 IdPはユーザーのブラウザを経由して、SAMLアサーションをSPへ送信（POST）します。この際、HTTPのPOSTメソッドを使ってブラウザをSPへリダイレクトさせ、フォームデータとしてアサーションを送る方法が一般的です。
6. 検証とログイン SPはアサーションのデジタル署名を検証し、正しければユーザーをログインさせます。署名検証により、アサーションがIdPから発行された正規のものであり、途中で改ざんされていないことを確認できます。
SAMLのセキュリティポイント
SAMLにおいて最も重要なのは「信頼関係」と「署名」です。IdPとSPは事前に証明書を交換し、信頼関係（Trust）を結んでいます。アサーションには有効期限や宛先が含まれており、リプレイ攻撃（再送攻撃）を防ぐ仕組みも組み込まれています。
試験では、「アサーションに含まれる情報は何か」「誰が署名し、誰が検証するか（IdPが秘密鍵で署名し、SPが公開鍵で検証）」という点が問われます。この非対称暗号の仕組みを理解していることが前提となります。
さらに、アサーションには以下の要素が含まれます。
- Subject: 認証されたユーザーの識別子
- Conditions: 有効期限、利用条件（例：特定のSPでのみ有効）
- AuthnStatement: 認証方法、認証時刻
- AttributeStatement: ユーザー属性（部署、役職、メールアドレスなど）
OpenID Connect (OIDC)
SAMLがXMLベースの重厚なプロトコルであるのに対し、OIDCはOAuth 2.0をベースに拡張された、より軽量でAPIフレンドリーな認証プロトコルです。データ形式にはJSONが使われます。モバイルアプリやSPA（Single Page Application）との親和性が高く、近年の新規開発ではこちらが主流になりつつあります。
OAuth 2.0との違い OAuth 2.0は「認可（権限を与える）」のプロトコルであり、本来は認証（誰かを確認する）ためのものではありませんでした。OIDCは、OAuth 2.0の認可フローに「IDトークン（ID Token）」という身分証明書のような情報を追加することで、「認証」を実現しています。この区別は試験でも実務でも重要です。
IDトークン JWT（JSON Web Token）形式で記述されており、ヘッダー、ペイロード、署名の3部構成になっています。ペイロードには、ユーザーのID（sub）、発行者（iss）、有効期限（exp）、発行対象（aud）などが含まれます。JWTはBase64エンコードされた文字列として扱われ、デコードすることで内容を確認できます。
OIDCでは、認証フローの中で「認可コード」を取得し、それをアクセストークンとIDトークンに交換するという手順を踏みます。この仕組みにより、クライアント側に直接IDトークンを渡さず、バックエンドサーバを経由させることでセキュリティを高めることができます。
ケルベロス認証（Kerberos）の詳細メカニズム
なぜケルベロス認証が重要なのか
WindowsのActive Directory環境における標準認証プロトコルであり、オンプレミス環境のLAN内でのSSOを実現する基盤技術です。米国MITのアテナプロジェクトで開発されました。名前の由来はギリシャ神話の「地獄の番犬（3つの頭を持つ犬）」であり、これはネットワーク上の「クライアント」「サーバ」「KDC（Key Distribution Center）」の3者が関与することを示唆しています。
KDCの構成要素
ケルベロス認証の特徴は、パスワードそのものをネットワークに流さず、チケットと呼ばれる暗号化されたデータを用いて相互認証を行う点にあります。試験では、このチケットのやり取りの流れと、どの鍵で何が暗号化されているかが非常に詳細に問われます。ここは最重要ポイントです。
KDC（鍵配布センター）は、信頼できる第三者機関として機能し、通常はドメインコントローラ上に存在します。KDCは内部で2つの機能に分かれています。
1. AS (Authentication Server) 最初のログオン認証を担当し、TGT（Ticket Granting Ticket）を発行します。ASは、ユーザーのパスワードをデータベースで照合し、本人確認を行います。
2. TGS (Ticket Granting Server) TGTを確認し、個別のサービスを利用するためのST（Service Ticket）を発行します。TGSは、ユーザーが既に認証済みであることをTGTで確認した上で、リクエストされたサービスへのアクセス権を付与します。
この2段階の仕組みにより、ユーザーは一度認証されれば、以降は複数のサービスにパスワード入力なしでアクセスできるようになります。
認証とアクセスの完全フロー
ユーザーがPCにログオンし、ファイルサーバを利用するまでの流れを追います。各フェーズで、どのような情報が、誰の鍵で暗号化されて送られるかを正確に把握することが、試験攻略の鍵です。
フェーズ1：認証とTGTの取得（ASとのやり取り）
1. 認証要求 (KRB_AS_REQ) ユーザーがIDとパスワードを入力すると、クライアントPCはパスワードをハッシュ化し、それを鍵として現在時刻を暗号化し、ASへ送信します。この時点でパスワードそのものは送信されません。
2. 認証とTGT発行 (KRB_AS_REP) ASはデータベースにあるユーザーのパスワードハッシュを使って復号を試みます。復号に成功し、時刻が許容範囲内であれば本人と認めます。
ASは、「TGT（チケット発行用チケット）」と「ログオンセッション鍵」を生成します。
- TGTは「KDC自身の秘密鍵（krbtgtの鍵）」で暗号化されています（クライアントには中身が見えません）。TGTには、ユーザー名、有効期限、ログオンセッション鍵などが含まれます。
- ログオンセッション鍵等は「ユーザーのパスワードハッシュ」で暗号化されて返送されます。クライアントは、自身が持つパスワードハッシュでこれを復号し、ログオンセッション鍵を取り出します。
フェーズ2：サービス利用チケットの取得（TGSとのやり取り）
3. チケット要求 (KRB_TGS_REQ) ユーザーがファイルサーバにアクセスしようとすると、クライアントは「TGT」と、ログオンセッション鍵で暗号化した「オーセンティケータ（本人確認情報）」をTGSに送ります。
ここで重要なのは、パスワードはもう入力不要であることです。TGTが身分証の役割を果たします。オーセンティケータには、ユーザー名とタイムスタンプが含まれており、リプレイ攻撃を防ぐ役割を担います。
4. サービスチケット発行 (KRB_TGS_REP) TGSは、自身の鍵（krbtgtの鍵）でTGTを復号して内容を検証します。正当であれば、ファイルサーバ用の「ST（サービスチケット）」と「サービスセッション鍵」を作成します。
- STは「ファイルサーバの秘密鍵」で暗号化されます。クライアントはこのSTの中身を見ることはできません。
- クライアントには、STとサービスセッション鍵（ログオンセッション鍵で暗号化）が送られます。
フェーズ3：サービスへのアクセス（サーバとのやり取り）
5. アクセス要求 (KRB_AP_REQ) クライアントは、受け取った「ST」と、サービスセッション鍵で暗号化した新たな「オーセンティケータ」をファイルサーバへ送ります。
6. 相互認証 ファイルサーバは、自身の秘密鍵でSTを復号し、中からサービスセッション鍵を取り出します。その鍵でオーセンティケータを復号し、検証成功ならアクセスを許可します。
さらに、相互認証を有効にしている場合、サーバはクライアントに対して自身の正当性を証明するために、サービスセッション鍵で暗号化したメッセージを返送します。これにより、クライアントは接続先が本物のサーバであることを確認できます。
ケルベロス認証のセキュリティ対策ポイント
時刻同期の重要性 リプレイ攻撃を防ぐため、ケルベロス認証ではチケットやオーセンティケータにタイムスタンプが含まれます。サーバとクライアントの時刻が大きくずれている（デフォルトで5分以上）と認証に失敗します。NTPによる時刻同期が必須要件となるのはこのためです。
辞書攻撃への耐性 最初のASへの要求段階では、事前認証（Pre-Authentication）が行われない場合、KDCが存在しないユーザーIDに対してもエラーを返す挙動を利用した列挙攻撃のリスクがありました。現在のActive Directoryでは事前認証が必須化されており、タイムスタンプをユーザーの鍵で暗号化して送らせることで、パスワードを知らない攻撃者の要求を門前払いします。
チケットの有効期限管理 TGTとSTには有効期限が設定されており、期限切れのチケットは使用できません。デフォルトでは、TGTの有効期限は10時間、更新可能期限は7日間に設定されています。これにより、盗まれたチケットが長期間悪用されるリスクを低減します。
SSO環境におけるセキュリティリスクと対策
SSOは「一本の鍵で全ての扉を開ける」仕組みであるため、その鍵が盗まれた際の影響は甚大です。ここでは、SSO環境特有のリスクと、支援士試験で問われる対策技術について解説します。
セッションハイジャックとCookieの保護
WebベースのSSO（エージェント型、リバースプロキシ型、SAML/OIDCの一部フロー）では、認証後に発行されるセッションID（Cookie）が、実質的な通行手形となります。
リスク 攻撃者がネットワーク盗聴やXSS（クロスサイトスクリプティング）によってセッションCookieを盗み出すと、ユーザーになりすましてサービスを利用できてしまいます。SSO環境では、一つのセッションが複数のサービスへのアクセス権を持つため、被害範囲が拡大します。
対策
- Secure属性: CookieにSecure属性を付与し、HTTPS通信のみで送信されるようにします。これにより、平文通信での盗聴を防ぎます。
- HttpOnly属性: JavaScriptからのCookieアクセスを禁止し、XSSによる奪取を防ぎます。documentCookie経由でのアクセスが不可能になります。
- SameSite属性: クロスサイトリクエストフォージェリ（CSRF）を防ぐため、Cookieの送信範囲を制限します。Strict、Lax、Noneの3つのモードがあり、セキュリティ要件に応じて選択します。
IdP（Identity Provider）の堅牢化
SAMLやOIDCにおいて、IdPは信頼の起点（Trust Anchor）です。IdPが侵害されることは、全システムへの不正アクセスを意味します。そのため、IdPのセキュリティ対策は最優先事項となります。
対策
- 多要素認証（MFA）: ID/パスワードだけでなく、スマホアプリや生体認証を組み合わせます。SSOの入り口でMFAを行うことで、連携する全アプリのセキュリティレベルを一括で向上させることができます。TOTP（Time-based One-Time Password）やFIDO2対応のハードウェアキーの利用が推奨されます。
- 条件付きアクセス: 接続元のIPアドレス、デバイスの状態（セキュリティパッチが当たっているか）、アクセス時間帯などを評価し、不審なアクセスであれば認証を拒否する動的な制御を導入します。ゼロトラストセキュリティモデルの実現において重要な要素です。
- 監査ログの記録と分析: すべての認証試行を記録し、異常なパターン（短時間での多数の失敗、通常と異なる場所からのアクセスなど）を検知するSIEM（Security Information and Event Management）システムとの連携が有効です。
チケットの有効期限とリプレイ攻撃対策
ケルベロス認証やSAMLアサーションには、必ず有効期限が設定されています。この仕組みは、攻撃者が盗んだ認証情報を長期間使い続けることを防ぐために不可欠です。
リスク ネットワーク上で盗聴されたチケットやアサーションを、攻撃者が再送（リプレイ）することで認証を突破しようとする攻撃。特に無線LAN環境では、パケットキャプチャが容易なため、このリスクが高まります。
対策
- タイムスタンプとNonce: メッセージに含まれる作成日時や、使い捨てのランダムな値（Nonce）を検証することで、古いメッセージや一度使われたメッセージの再利用を拒否します。受信側は、既に処理したNonceを一定期間記録し、重複を検出します。
- 有効期限の短縮: TGTやアクセストークンの有効期限を必要最小限に設定し、万が一盗まれた場合の影響時間を極小化します。業務の継続性とのバランスを考慮した設定が求められます。
- 暗号化通信の徹底: ケルベロス認証自体はパスワードを送らない設計ですが、チケットの盗聴を防ぐためにIPsecやTLSによるネットワーク暗号化を併用することが推奨されます。
アカウント管理とアクセス権の定期見直し
SSO環境では、一つのアカウントが多くのシステムにアクセスできるため、退職者や部署異動者のアカウント管理が極めて重要です。
対策
- プロビジョニング/デプロビジョニング: 人事システムとIdPを連携させ、入社時のアカウント作成、異動時の権限変更、退職時のアカウント削除を自動化します。SCIM（System for Cross-domain Identity Management）などの標準プロトコルを活用します。
- 最小権限の原則: ユーザーには業務遂行に必要な最小限の権限のみを付与し、不要なシステムへのアクセス権は与えません。定期的なアクセス権レビューを実施し、不要になった権限を剥奪します。
- 特権アカウントの分離: 管理者権限を持つアカウントは通常業務用とは別に管理し、PAM（Privileged Access Management）ツールを用いて、アクセスの都度承認と記録を行います。
学んだ知識を定着させよう
ここまでの内容が理解できたか、簡単なクイズで確認してみましょう。
まとめ：SSOを制する者が認証を制する
本記事では、シングルサインオン（SSO）の主要な方式から、特に試験で重視されるケルベロス認証、そしてクラウド連携に不可欠なSAML/OIDCについて解説しました。
重要なポイントを振り返ります。
- 実装方式の違い : エージェント型、リバースプロキシ型、フェデレーション型のそれぞれのアーキテクチャとメリット・デメリットを整理しました。システム環境に応じた最適な選択が求められます。
- ケルベロスの3要素 : クライアント、サーバ、KDC（AS/TGS）の役割と、チケット（TGT/ST）の流れ、そしてどの鍵で暗号化されているかを完全に理解することが試験攻略の鍵です。
- フェデレーションの信頼関係 : IdPとSPの関係、署名による改ざん検知、XMLやJSONといったデータ形式の違いを把握しました。SAMLとOIDCの使い分けも重要です。
- セキュリティリスク : SSOはSPOFになり得るため、IdPの多要素認証や可用性確保、セッション管理の厳格化がセットで必要になります。
情報処理安全確保支援士試験の午後問題では、これらの知識が実際の事例（「社内システムをクラウド移行する際の認証統合」など）と絡めて出題されます。「ログオンの手間が省ける」というユーザー視点だけでなく、「認証チケットがどのようにネットワークを飛び交い、どう守られているか」というエンジニア視点で認証フローを脳内でトレースできるようにしておくことが合格への近道です。
SSOは、現代のシステムインフラにおいて避けて通れない技術です。その仕組みを深く理解することで、セキュリティ設計における判断力が飛躍的に向上します。次回の記事では、これらの認証基盤を支える暗号技術、特に「PKI（公開鍵基盤）」と認証の深い関係について、週次復習として整理していきます。