午前I問題

アクセス制御モデルに関する記述として、適切なものはどれか。

ア）DAC（任意アクセス制御）は、リソースの所有者がアクセス権限を自由に設定できる方式であり、UNIX/Linuxのファイルパーミッションが代表例である。

イ）MAC（強制アクセス制御）は、リソースの所有者が任意にアクセス権限を設定できる方式であり、SELinuxのTargetedポリシーが代表例である。

ウ）RBAC（ロールベースアクセス制御）は、ユーザの役職や所属ではなく、個々のユーザ属性（年齢、所属組織、アクセス時刻など）に基づいて動的にアクセス権限を決定する方式である。

エ）ABAC（属性ベースアクセス制御）は、あらかじめ定義された「ロール」にユーザを割り当て、ロールに紐づく権限を一括付与する方式であり、最小権限の原則を実現しやすい。

午前I の解答・解説を見る

正解： ア

解説： DAC（Discretionary Access Control）はリソースの所有者が自身の裁量でアクセス権限を設定できる方式で、UNIX/Linuxのファイルパーミッション（chmod等）が代表例です。イ）MACはシステム管理者が定めたセキュリティポリシーに基づき強制的にアクセスが制御される方式で、所有者の裁量では変更できません。ウ）の説明はABACのものです。RBACはユーザの役職・職務に応じて定義された「ロール」に基づき権限を付与します。エ）の説明はRBACのものです。ABACはユーザ属性・リソース属性・環境属性（時刻・場所など）を組み合わせて動的に判定します。

モデル制御の主体代表例
DACリソース所有者UNIX/Linuxファイルパーミッション
MACシステム（強制）SELinux、機密区分ラベル
RBAC定義済みロール業務システムの役職別権限
ABAC属性の組み合わせゼロトラストの動的アクセス制御

午前II問題

SAML（Security Assertion Markup Language）2.0によるシングルサインオン（SSO）に関する記述として、適切なものはどれか。

ア）SAMLにおけるSP（Service Provider）は、ユーザの認証情報を検証してSAML Assertionを発行する役割を担う。

イ）SP-initiated SSOでは、ユーザがSPにアクセスするとSPがSAML AuthnRequestを生成してIdP（Identity Provider）にリダイレクトし、IdPでの認証後にSAML ResponseがSPへPOSTされる。

ウ）SAML AssertionはXML形式で記述され、デジタル署名による改ざん検知機構を持たないため、SAML ResponseはTLS通信のみで保護すれば十分である。

エ）Golden SAML攻撃とは、攻撃者がSPの秘密鍵を窃取し、任意のSAML AuthnRequestを偽造してIdPになりすます攻撃である。

午前II の解答・解説を見る

正解： イ

解説： SP-initiated SSOの標準的な流れは、①ユーザがSPにアクセス、②SPがAuthnRequestを生成しIdPへリダイレクト、③IdPでユーザ認証、④IdPがSAML Response（署名付きAssertionを含む）をブラウザ経由でSPへPOST、⑤SPがAssertionの署名・Audience・有効期限を検証してセッションを確立、という流れです。ア）Assertionを発行するのはIdPであり、SPはAssertionを検証して認可を行う側です。ウ）SAML AssertionはXML署名（XMLDSig）による改ざん検知が必須であり、SPは署名検証を必ず実施する必要があります。TLSは通信経路の保護のみでAssertion自体の真正性は保証しません。エ）Golden SAML攻撃は、攻撃者がIdPの署名用秘密鍵（ADFSのトークン署名証明書など）を窃取し、任意のユーザ・任意の権限を持つ偽造Assertionを作成してSPになりすます攻撃です（SolarWinds事件で悪用されたことで知られる）。

用語役割
IdP（Identity Provider）ユーザを認証し、署名付きSAML Assertionを発行する
SP（Service Provider）Assertionの署名・内容を検証し、ユーザをログインさせる
AuthnRequestSPがIdPに送る認証要求
Audience RestrictionAssertionの対象SPを限定し、他SPへの転用（リプレイ）を防止する仕組み

午後問題

F社は社内の複数の業務システムをSAML 2.0によるSSOで統合しており、IdPは自社構築、各業務システムはSPとして動作する。新規に追加されたSPの実装をセキュリティ担当のG氏がレビューしたところ、以下のコードと設定が見つかった。

def handle_saml_response(response_xml):
    root = etree.fromstring(response_xml)
    assertion = root.find(".//Assertion")
    # (A) 署名検証を実施せず、Assertionの内容をそのまま信頼している
    name_id = assertion.find(".//NameID").text
    user = get_or_create_user(name_id)

    session_token = generate_session_token()
    response = make_response(redirect("/dashboard"))
    response.set_cookie("session_id", session_token)
    # (B) Cookieに Secure・HttpOnly・SameSite 属性が設定されていない
    save_session(session_token, user)
    return response

G氏はさらに、社内ネットワークの一部にHTTP（非暗号化）でアクセス可能な区間が残っていること、また各SPがAssertionのAudience Restriction（対象SP限定）を検証していないことも確認した。

設問1

(A) の実装上の問題点を述べ、攻撃者がこの問題をどのように悪用できるかを70字以内で説明せよ。

設問1の解答・解説を見る

正解例： SAML Assertionの署名検証を行っていないため、攻撃者が任意のNameIDを含む偽造Assertionを送信し、他ユーザになりすましてログインできる。

解説： SPはIdPから受信したSAML Assertionについて、XML署名（XMLDSig）を用いてIdPの公開鍵証明書で署名検証を行い、改ざんされていないこと・正規のIdPが発行したものであることを確認する必要があります。署名検証を省略すると、ネットワーク上でAssertionを改ざんしたり、攻撃者が独自に偽造したAssertionを送信したりすることで、任意のユーザ（管理者を含む）になりすますことが可能になります。Audience Restriction未検証の場合は、他のSP向けに発行された正規のAssertionを当該SPに転用するリプレイ攻撃も成立し得ます。

採点基準：

  • 署名検証が行われていない点への言及（2点）
  • 偽造Assertionによるなりすまし・認証バイパスへの言及（2点）
  • Audience Restriction未検証によるAssertion転用（リプレイ）への言及（任意加点・1点）

設問2

(B) で設定漏れとなっている3つのCookie属性をそれぞれ挙げ、各属性が防止する攻撃または問題点を述べよ。

設問2の解答・解説を見る

正解例：

  • Secure属性： HTTPS接続でのみCookieを送信させる属性。未設定の場合、社内ネットワークのHTTP区間で通信が盗聴され、セッションIDが平文で漏洩する（中間者攻撃によるセッションハイジャック）。
  • HttpOnly属性： JavaScriptからのCookieアクセスを禁止する属性。未設定の場合、XSS脆弱性が存在するとスクリプト経由でセッションIDが窃取される。
  • SameSite属性： 他サイトからのリクエストにCookieを自動付与するかを制御する属性。未設定（またはNone）の場合、CSRF攻撃やクリックジャッキングと組み合わせた攻撃でセッションが悪用されるリスクが高まる。StrictまたはLaxを設定することでクロスサイトリクエストでの送信を制限できる。

解説： Cookieの3属性は防御対象が異なるため、いずれか1つではなく全てを設定する必要があります。Secureは通信経路の盗聴対策、HttpOnlyはXSS経由の窃取対策、SameSiteはCSRF・クロスサイト悪用対策と、それぞれ独立した脅威に対応します。F社のケースではHTTP区間が残っているためSecure未設定の影響が特に大きく、優先的な対応が必要です。

採点基準：

  • Secure属性とHTTP盗聴・中間者攻撃への言及（2点）
  • HttpOnly属性とXSS経由のCookie窃取への言及（2点）
  • SameSite属性とCSRF対策への言及（2点）

重要キーワード

用語説明
DAC / MAC / RBAC / ABACアクセス制御モデルの4分類。制御主体が所有者・システム・ロール・属性のいずれかで異なる
SAML AssertionIdPがXML形式で発行する認証・属性情報。XML署名による改ざん検知が必須
Audience RestrictionAssertionの利用対象SPを限定し、他SPへの転用（リプレイ攻撃）を防止する仕組み
Golden SAML攻撃IdPの署名用秘密鍵を窃取し、任意ユーザ・任意権限の偽造Assertionを作成する攻撃
Secure / HttpOnly / SameSiteセッションCookieを保護する3属性。それぞれ盗聴・XSS・CSRFに対応する
セッションハイジャック何らかの方法で正規ユーザのセッションIDを奪取し、なりすましてセッションを乗っ取る攻撃

まとめ

  • 午前I視点： DAC/MAC/RBAC/ABACの制御主体の違いを正確に区別する。特にRBACとABACの説明文の入れ替えは頻出のひっかけパターン
  • 午前II視点： SAMLのSP-initiated SSOの流れ（AuthnRequest→IdP認証→Assertion→署名検証）と、Golden SAML攻撃がIdPの署名鍵窃取である点を押さえる
  • 午後視点： SAML Assertionの署名検証漏れ・Audience Restriction未検証、CookieのSecure/HttpOnly/SameSite属性の不備はいずれも実装レビュー問題の定番。それぞれが防ぐ攻撃を対応付けて説明できるようにする