ログインできれば、その先まで見てもいい？——認証・認可・特権ID・OAuth・SAMLを午後の問われ方で読む｜支援士解説3の8

この記事の重要度：Sランク（午後で繰り返し主役になる最重要の分野）

この記事で分かること：

• 識別・認証・認可の違いと、最小権限・アクセス制御の方式・権限のライフサイクル・特権ID

• 多要素認証・パスキー・パスワード攻撃・OAuth・OIDC・SAML・Kerberosで、何を確かめ、何が破られるか

• 解答欄に書く「原因」と「対策」の型

シラバスとの対応：小項目3-8「アカウント管理及びアクセス管理」。Webアプリでのセッション管理とAPIの認可は支援士解説2の4、認証のログの読み方は支援士解説3の4、人の管理（教育・内部不正）は支援士解説3の9で扱います。

午後の問題では、「ログインできた利用者に、何をどこまで許すか」がよく問われます。パスワードが盗まれた、多要素認証を突破された、退職者の権限が残っていた、管理者権限を悪用された。どれも、本人を確かめること（認証）と、操作を許すこと（認可）のどこかが崩れた結果です。

この記事では、認証と認可を分けたうえで、それぞれの仕組みと、攻撃者がどこを突くかを整理します。

1. 誰かを確かめることと、操作を許すこと

主体・対象・操作の三つを置く

アクセス制御では、アクセスする側を主体、アクセスされる情報や資源を対象と呼びます。主体は人だけでなく、プログラムや機器の場合もあります。

例えば、職員Aが申請データを閲覧するなら、主体は職員Aのアカウント、対象はその申請データ、操作は閲覧です。夜間の連携処理がデータを登録する場合には、主体が連携用プログラムのアカウントになります。

ここで「システムを使える」という一つの権限にまとめると、閲覧できれば削除もできるのか、担当外の申請も開けるのかが分かりません。対象と操作を具体的にすることが出発点です。

識別・認証・認可を区別する

識別は、ある利用者や処理を、他の主体と区別することです。ログイン画面に利用者IDを入力することが一例です。IDを名乗っただけでは、正当な利用者であることは確認できません。

認証は、その主体として正当であることを確かめることです。パスワード、認証器による署名などの証拠を検証します。登録時に実在する本人を確認する手続と、毎回のログイン時に登録済みの認証情報を確認する処理も、同じ作業ではありません。

認可は、その主体に、対象への特定の操作を許可することです。正しくログインできた職員でも、担当外の情報や管理者機能にはアクセスできないようにします。

最後に、誰が何をしたかを後からたどれるように記録します。これが責任追跡性に関わります。ただし、ログに個人のIDがあれば、常に本人が操作したと証明できるわけではありません。IDの貸し借りや認証情報の窃取があれば、追加の調査が必要です。

画面を隠すだけでは制御にならない

例えば、一般利用者の画面から管理ボタンを消しても、管理用のURLへ直接アクセスすると実行できるなら、認可が機能していません。同じように、申請番号を変えると担当外の申請が見える場合には、対象ごとの権限確認が不足しています。

画面から来た要求でも、外部のプログラムから来た要求でも、処理する側で権限を確認します。許可されていない操作は、明示的に許す理由がなければ拒否する設計が基本です。OWASPも、原則拒否と要求ごとの権限検証を挙げています。OWASP「Authorization Cheat Sheet」、Deny by Default／Validate the Permissions on Every Request

x

2. 最小権限は、必要性を具体的に説明する原則

need-to-knowとneed-to-use

need-to-knowは、業務上、その情報を知る必要のある主体だけに知らせる考え方です。職員である、役職が高い、同じ課にいるという理由だけで、すべての個人情報を見られるようにはしません。

need-to-useは、業務上、その資源や機能を使う必要のある主体だけに利用を認める考え方です。申請の審査をする人が、データベースの設定変更機能まで使う必要があるとは限りません。

両者は重なりますが、前者は情報を知る必要性、後者はシステムや機能を利用する必要性に着目すると整理できます。

最小権限の原則は、業務を遂行するために必要な最小限の権限を与えることです。「できるだけ何も許さない」とだけ理解すると、必要な業務まで止めてしまいます。何の仕事をするかを明らかにした上で、その仕事に必要な対象、操作、期間に絞ります。

同じデータでも、許す操作は違う

架空の給付システムを考えます。

• 受付担当：担当する申請の内容を登録し、不備を補正する。

• 審査担当：審査に必要な資料を閲覧し、審査結果を入力する。

• 決裁担当：審査結果を確認し、決裁する。

• 集計担当：業務集計に必要な範囲のデータを利用する。

• 保守担当：許可された保守作業を行う。

この区分は説明用です。実際には組織の業務に合わせて設計します。

例えば、集計担当に必要なのが件数の集計なら、氏名や口座番号を含む全件出力を認める必要があるかを検討します。保守担当にシステム設定の変更が必要でも、住民情報を日常的に閲覧する必要まであるとは限りません。

閲覧を認めることと、全件をCSVで出力することにも差があります。大量の情報を持ち出せる機能は、対象件数、項目、目的、承認を別に考える余地があります。

職務分離は、一人だけで完結させない工夫

職務分離は、不正や誤りを防ぐために、重要な一連の作業を複数の役割へ分けることです。申請者が自分の申請を承認できる状態では、承認手続があっても歯止めになりません。

権限変更なら、業務上の必要性を判断する人、設定を実施する人、結果を確認する人を区別します。少人数の組織では完全に担当者を分けられないこともあります。その場合も、兼務の範囲、別の責任者による確認、例外の記録などを具体化します。

最小権限は、一人に与える権限の範囲を絞る考え方です。職務分離は、権限の組合せや業務の完結の仕方を制約する考え方です。必要な権限を一つずつ付けても、その組合せで自己承認ができるなら、別の制約が必要です。

国の統一基準も、権限を必要最小限に設定することと、不要なアクセス権限を定期的に確認することを定めています。公的資料としての位置付けは後半で整理します。「政府機関等のサイバーセキュリティ対策のための統一基準（令和7年度版）」、7.1.3

3. DAC・MAC・RBAC・ABACを、判断の根拠で区別する

アクセス制御には、誰が許可を決め、何を判断材料にするかによって、複数の考え方があります。名称だけを並べず、同じ資料へのアクセスをどう決めるかで考えます。

DAC：所有者などの裁量で許可する

DAC（Discretionary Access Control：任意アクセス制御）は、対象の所有者などが、他の主体へアクセス権を与える裁量を持つ方式です。

例えば、資料を作成した利用者が、特定の同僚へ閲覧権限を付けます。共同作業には便利ですが、権限を与える人が業務上の必要性を誤ると、情報が広く共有されるおそれがあります。共有相手や再共有の範囲を管理することが課題になります。

任意という語は、アクセス制御がなく誰でも自由に使える、という意味ではありません。許可を決める裁量がどこにあるかを示しています。NIST CSRC用語集「Discretionary Access Control」、SP 800-192に基づく定義

MAC：組織の方針をシステムが強制する

MAC（Mandatory Access Control：強制アクセス制御）は、組織が定めた方針に従って、システムがアクセスを強制的に制御する方式です。一般利用者や対象の所有者が、自分の判断で制約を外すことはできません。

典型的な説明では、情報の機密区分と主体の許可区分などを照合します。例えば、ある機密区分の文書について、所有者が同僚に見せたいと思っても、組織のルールで許可されなければ共有できません。

情報の機密区分を付けることだけで、MACが実現するわけではありません。その区分を使い、制約を実際に強制する仕組みが必要です。ここでいうMACは、ネットワーク機器のMACアドレスとは別の用語です。NIST CSRC用語集「Mandatory Access Control」、SP 800-192に基づく定義

RBAC：役割を介して権限を付ける

RBAC（Role-Based Access Control：役割に基づくアクセス制御）は、役割であるロールへ権限を割り当て、利用者にそのロールを割り当てる方式です。

架空の給付システムなら、受付ロールに申請登録権限、審査ロールに審査結果入力権限を持たせます。担当者の交代時には、個々の機能の権限を一件ずつ設定し直す代わりに、割り当てるロールを変更します。

ただし、受付ロールに全件出力や管理者操作まで含めれば、そのロールを持つ全員に過剰な権限が広がります。人事上の役職名を、そのままシステム上のロール名にする必要もありません。業務で必要な操作を整理して設計します。

NISTのRBACモデルは、利用者とロール、ロールと権限の関係を基本とし、役割の階層や職務分離の制約も扱います。NIST「Role Based Access Control FAQs」、General／RBAC Models

実際の製品で、ロールに加えて個人へ直接権限を設定できる場合には、例外設定もレビューの対象です。「ロールを外したから権限は全部消えた」と決めつけず、有効な権限を確認します。

ABAC：属性と条件を組み合わせる

ABAC（Attribute-Based Access Control：属性に基づくアクセス制御）は、主体、対象、要求する操作、必要に応じて環境の属性を、方針やルールと照合して判断する方式です。NIST SP 800-162、2019年更新版、概要

例えば、次の条件を組み合わせます。

• 主体：現在、その案件の担当者として登録されている。

• 対象：その担当案件の審査資料である。

• 操作：閲覧である。

• 環境：組織が管理する端末からの利用である。

これらは本稿の説明用の条件です。部署やロールだけでは表しにくい、案件単位・端末状態などの制約を組み込めます。一方、担当者情報や端末状態が古ければ、判断も誤ります。属性を更新する責任者や、情報を取得できない場合の扱いまで設計します。

RBACとABACは、実際のシステムでは組み合わせることもあります。審査ロールを持つことを前提に、その案件の担当者であることをさらに確認する、といった設計です。

ACLは、許可を記述する仕組みとして捉える

ACL（Access Control List：アクセス制御リスト）は、対象へのアクセスを誰にどの範囲で許可・拒否するかを記述する一覧です。ファイルの利用者別・グループ別の権限設定などが例です。

ACLという語が出てきただけで、制御方針がDACかRBACかは決まりません。誰がその一覧を変更できるか、利用者と権限をどう対応付けるかまで確認します。ネットワークのACLでは通信元や通信先などを条件にしますが、通信が許可されたことだけで、アプリケーション内の全操作が許可されるわけではありません。

記述の型

• DACの弱点：「所有者の裁量で権限が決まるため、組織として十分な機密保護が難しい」

• MACの特徴：「所有者であっても、アクセス権を自由に変更できない」

• 権限を設定する担当者の権限：「権限を変更する権限だけを与え、ファイルの読込み・書込みは与えない」

4. 登録・異動・終了を、一つの管理としてつなぐ

登録時には、誰の何のためのアカウントかを確かめる

アカウントの管理は、利用開始、変更、利用終了というライフサイクルで考えます。採用・参加、異動、退職に対応して、Joiner・Mover・Leaverと表現されることもあります。

登録時には、少なくとも次を明らかにします。

• 利用者又は処理の識別情報と、所属・責任者。

• 利用するシステム、業務目的、必要なロールや操作。

• 開始日、期限がある場合の終了日。

• 申請者、承認者、設定担当者。

• 認証情報を本人へ安全に渡す方法。

単に、似た業務をしていた人の権限をコピーすると、その人だけの兼務や例外権限まで複製するおそれがあります。基準となるロールを用意し、例外を別に確認する方が、必要性を説明しやすくなります。

異動時は、追加と削除を同時に考える

異動のときに、新しい部署の権限を追加するだけでは、旧部署の権限が残ります。必要なのは、旧部署の権限の削除や変更も含めた見直しです。

例えば、旧業務の引継ぎのために二週間だけ閲覧が必要だとします。その場合には、旧権限を丸ごと残すのではなく、引継ぎ対象の情報、閲覧だけで足りるか、終了日、承認者を具体化します。期限まで更新権限を残す必要があるかも、別に判断します。

この二週間は説明用の例であり、共通の基準ではありません。期限が来たら自動で失効させられるか、自動化できないなら誰が解除を確認するかを決めます。

利用終了では、入口を漏れなく止める

雇用又は契約の終了時には、組織の共通IDだけでなく、個別の業務システム、クラウドサービス、保守用VPN、端末のローカルアカウントなども対象になります。

本稿での実務上の提案は、利用開始時から利用先を記録し、終了時にその一覧と突き合わせることです。最後に思い出して探す方式では、別契約のサービスや臨時の保守IDを見落としやすくなります。

利用停止とアカウントの削除も分けます。まずサインインや利用を止めた上で、業務データの引継ぎ、記録の保存、保有期間を確認し、不要なアカウントを削除する場合があります。記録を残すために、退職者がログインできる状態を維持する必要はありません。

また、過去の操作記録と主体の対応を壊さないようにします。表示名やメールアドレスを再利用する場合でも、内部の識別子と利用者の履歴を区別して管理することが大切です。

人事部門だけでは、すべての変更を把握できない

部署が変わらなくても、業務担当者の変更、兼務の終了、臨時プロジェクトの解散が起きます。委託先の担当者交代は、職員の人事情報には載らない場合もあります。

人事管理部門、業務責任者、契約担当、情報システム部門のうち、どこが変更を知るのかを確認し、通知先と期限を決めます。人事情報との自動連携があっても、その連携が対象にしていない変更は別に扱います。

記述の型

• 異動時の注意：「新しい権限の付与と同時に、不要になった権限を削除する」

• 離任者への対応（グループ単位で権限を付けている場合）：「利用者アカウントをグループから削除する」

5. レビューでは、名簿と実際の権限を突き合わせる

定期点検と、変更時の点検を組み合わせる

定期的なレビューは、申請漏れや設定漏れを見つける機会になります。一方で、次の定期点検まで退職者の権限を残してよいわけではありません。

異動、担当変更、契約終了などの出来事に応じて見直す運用を基本とし、定期的なレビューで取り残しを探します。システムの重要性や変更の多さに応じて頻度を決め、特権や外部利用者を重点的に確認する方法もあります。本稿では一律に月次・四半期・年次を義務とはしません。

レビューするものは、アカウントの有無だけではない

確認したい内容を、四つに分けてみます。

第一に、利用者や責任者が現在も存在するか。 退職者、契約終了者、所有者が分からない自動処理のアカウントなどを確認します。

第二に、今の業務に必要な権限か。 在籍している人でも、以前の部署や兼務の権限が残っている場合があります。利用者が現役であることだけでは合格にできません。

第三に、設定上どこまで操作できるか。 ロール、所属グループ、グループの入れ子、個人への直接付与、共有リンク、アプリケーション独自の権限などをたどります。拒否と許可の優先関係は製品によって異なるため、単純な足し算だけで決めず、実際に有効な権限を確認します。

第四に、方針自体が今の業務に合うか。 業務の統合や情報の機密性の変化で、従来のロール設計が広すぎることもあります。方針が古ければ、全員の設定が方針どおりでも問題は残ります。

業務の必要性と設定の正しさは、確認者が違う

情報システム部門が権限一覧を出しても、その人に審査業務が必要かどうかは、業務責任者に確認しないと分からない場合があります。逆に、業務責任者が不要と判断しても、実際に設定が解除されたかは、システム側の証跡が必要です。

そのため、本稿では次の役割分担を提案します。

• 業務責任者：誰にどの業務上の権限が必要かを確認する。

• システム管理者：実際の付与状況を提示し、承認された変更を反映する。

• 確認担当者：解除結果や例外の残りを確認する。

点検表へ一括して「全員必要」と記入するだけでは、どこまで確認したかが分かりません。継続理由、変更内容、承認者、実施日、未完了の理由を残します。

未使用だから不要、使っているから必要、とも限らない

未使用のアカウントは重要な確認対象ですが、災害対応や緊急復旧用など、普段は使わないものもあります。用途と責任者を確認せず一括削除すると、必要な対応ができなくなるおそれがあります。

反対に、毎日使われている権限でも、業務上の必要性があるとは限りません。過剰な権限で習慣的に作業している可能性もあります。利用履歴は判断材料であり、承認そのものの代わりにはなりません。

6. 特権IDは、申請から操作後の確認まで管理する

特権は、ほかの対策も変更できる

特権IDは、一般利用者より強い管理権限を持つアカウントです。OSの管理者、データベース管理者、クラウドの管理者などが該当します。ただし、すべての特権IDが同じ範囲の権限を持つわけではありません。

設定変更、利用者の追加、アクセス権の付与、監視の停止、ログの削除などが可能な権限は、業務データを直接操作する権限と同様に重要です。攻撃者が特権を取得すると、防御設定を無効にしたり、自分用の入口を作ったりするおそれがあります。

通常のメール閲覧などに強い管理者権限を使い続けると、日常の端末利用で起きた侵害が管理操作へ広がりやすくなります。通常用と管理用のアカウントや作業環境を分け、必要なときに必要な管理作業を行う設計を検討します。

特権利用の一連の流れを決める

架空の保守作業を例にすると、次のようになります。

1. 作業者が、対象機器、作業内容、必要な権限、作業時間、申請番号を示す。

2. 承認者が、必要性と影響、作業時間を確認する。

3. 本人を認証した上で、承認された範囲の特権利用を開始する。

4. 操作を記録し、時間超過や想定外の行動を監視する。

5. 終了時に権限や接続を解除し、作業結果を報告する。

6. 別の確認者が、申請・承認内容と実際の操作を照合する。

すべての操作を人が逐一承認する、という意味ではありません。定型作業の事前承認、リスクに応じた追加承認、緊急時の手順などを設計します。ただし、包括的な承認だけで無制限の操作ができる状態を作らないことが重要です。

常時保有する特権を減らす

PAM（Privileged Access Management）は、特権アクセスを管理する取組や仕組みを指します。製品によって、認証情報の保管、貸出し、接続の仲介、操作記録、承認、期限付きの権限付与など、提供する機能が異なります。

JIT（Just-in-Time）の考え方では、必要なときだけ、限られた時間、権限を有効にします。例えば、管理者になれる資格はあっても、普段は管理権限を有効にせず、承認後の作業時間だけ有効にする方法です。Microsoft Entra PIMにも、時間制限付きの権限有効化や承認の仕組みがあります。Microsoft Learn「What is Privileged Identity Management?」、What does it do?

時間を短くするだけで、許される操作が狭くなるわけではありません。一時間だけでも、全データを削除できる権限なら影響は大きいままです。対象、操作、時間をそれぞれ絞ります。

共用の管理者IDが残る場合の責任追跡

古い機器などでは、管理用IDを個人別に分けにくいことがあります。その場合に「管理者IDだから誰が使っても同じ」とすると、操作と個人を対応付けられません。

例えば、個人別に認証する管理基盤を入口にし、申請番号と接続先の管理者IDを結び付け、操作記録を保存する方法があります。同時利用の制約、認証情報を直接知らせない仕組み、必要に応じた利用後の更新なども検討します。

ただし、その管理基盤を通らず直接接続できる入口が残れば、追跡の前提が崩れます。コンソールや別の保守経路も含め、どの入口からの利用を管理しているか確認します。

緊急用アカウントも、設計と点検が必要

共通の認証基盤が故障したり、設定ミスで全管理者が締め出されたりした場合に備え、緊急アクセスの手段を用意することがあります。

これは、無条件にMFAを外し、弱いパスワードの管理者IDを残すことではありません。通常の認証と同時に使えなくならない経路、強い認証、認証情報の安全な保管、利用時の通知、定期的な動作確認を組み合わせます。Microsoftの緊急アクセス管理でも、通常の管理者と異なる認証手段の利用などが示されています。具体的な設定は製品に依存します。Microsoft Learn「Manage emergency access admin accounts」、Configuration requirements

午後での問われ方

• 令和3年度秋期 午後I問1：外部の保守員が中継サーバを経由して作業する構成で、操作ログの参照に特権が必要な設定のもと、中継サーバでの保守員のIDに一般利用者の権限だけを与える理由が問われました。解答例は「操作ログの改ざんや削除を防止するため」です。

• 令和7年度春期 午後問1：開発環境の踏み台サーバで共用アカウントを利用していることが、問題点として解答例に示されています。共用アカウントでは、誰が操作したかを特定できません。

記述の型

• 作業者に一般権限だけを与える理由（ログの操作に特権が必要な場合）：「操作ログの改ざんや削除を防止するため」

• 共用アカウントの問題：「操作を行った個人を特定できず、責任追跡性を確保できない」

• 特権IDの運用：「事前に申請・承認を受けて期間を限って使い、作業記録とログを突き合わせて確認する」

7. ログは、残す・守る・照合するまでが一組

ログイン記録だけでは、作業内容が分からない

ある管理者IDが午後九時にログインしたことは分かっても、何を変更したか分からなければ、承認された作業か判断できません。

特権操作の確認では、個人を識別できる入口の記録、特権の有効化や貸出しの記録、対象機器での操作記録、作業申請を結び付けます。利用開始と終了、接続元、操作対象、操作内容、成功・失敗、設定変更など、目的に必要な項目を選びます。

ログの時刻がずれると、別の機器の記録と対応させにくくなるため、時刻同期やタイムゾーンも確認します。ログを残す目的、保存期間、閲覧できる人を決めることも必要です。

操作者が、証跡まで自由に消せないようにする

監視対象の管理者が、自分の操作ログを消せる状態では、改ざんや隠蔽を見逃すおそれがあります。別の管理権限を持つ保管先へ送る、変更や削除を制限する、削除操作自体を記録するなど、システムの条件に合う保護を設計します。

転送先を分けるだけで、完全な記録が保証されるわけではありません。送信前のログを消されたり、転送を止められたりする場合も考えます。ログの欠落、転送の停止、監査設定の変更を検知することも、保護の一部です。

承認と実際の操作を突き合わせる

例えば、申請された作業が「設定値の確認」なのに、実際には利用者の追加や監査機能の停止が行われていたら、作業内容を確認する必要があります。

承認された時間内だったことだけで、正しい操作とは判断できません。対象機器、コマンドや管理画面の操作、変更前後の設定、申請された目的との対応を確認します。毎回すべての画面を手作業で見直す方法だけでなく、想定外の操作を抽出する仕組みも考えられます。

操作記録にパスワードや秘密鍵、不要な個人情報を大量に残すと、ログ自体が新たな漏えい源になります。何でも記録するのではなく、追跡に必要な情報と、記録すべきでない秘密を分けます。

国の統一基準7.1.4は、目的に応じたログの取得・管理と定期的な点検又は分析を定めています。上記の個人・作業・操作の対応付けは、それを特権管理へ具体化する本稿の説明です。「統一基準（令和7年度版）」、7.1.4

8. MFAとパスキーは、何を確かめているのか

認証要素は三つの種類で整理する

認証要素は、一般に次の三つで整理します。

• 知識情報：パスワードや暗証番号など、本人が知っているもの。

• 所持情報：認証用の秘密を保持するICカード、セキュリティキーなど、本人が持っているもの。

• 生体情報：指紋や顔など、本人の身体的な特徴。

MFA（Multi-Factor Authentication：多要素認証）は、異なる種類の要素を組み合わせる認証です。パスワードと別の暗証番号を二回入力しても、どちらも知識情報なら、それだけで二要素にはなりません。

一方、端末内の認証用の秘密を使う前にPINや生体認証で本人確認を行う方式では、一台の端末でも複数の要素を組み合わせられます。機器が二台あるか、画面が二つあるかで数えるものではありません。

二段階認証は、手続が二段階であることに着目した表現です。異なる要素を用いるならMFAになり得ますが、二段階という名称だけでは要素の独立性や強度は分かりません。NISTも、単一要素の認証器と複数要素を使う認証器を区別しています。NIST SP 800-63B-4、3.1 Authenticator Types

MFAでも、フィッシングへの強さは異なる

ワンタイムパスワード（OTP）は、一度だけ有効な認証用の値です。時間やカウンタなどを使って生成する方式があります。同じ値を繰り返し使いにくくしても、利用者が偽サイトへ入力した値を攻撃者が即座に本物のサイトへ中継する攻撃には、別の備えが必要です。

スマートフォンに承認要求が届く方式では、利用者が内容を見ずに承認してしまうことも考えます。大量の要求で誤承認を誘う、いわゆるMFA疲労攻撃への対策として、要求回数の制限や、要求元の確認、番号の照合などを検討します。ただし、番号照合を追加すれば、あらゆるフィッシングに耐えられるという意味ではありません。CISA「Require Multifactor Authentication」、No-Cost MFA Implementation Guides

「MFA対応」という表示だけで終わらず、実際の方式、認証が必要な入口、例外、再登録の手続を確認します。通常の画面ではMFAを求めても、別の古い接続方式がパスワードだけで通るなら、その入口が残ります。

パスキーの基本は、公開鍵による認証

パスキーは、パスワードなしで認証するためのFIDO認証情報です。秘密鍵と公開鍵の組を使い、サービス側は公開鍵を使って、認証器が作る署名を検証します。サービスへ同じ秘密のパスワードを送って照合する方式とは仕組みが異なります。

典型的な利用では、利用者が端末上のPINや生体認証で鍵の利用を許可します。指紋や顔の情報をログイン先のサービスへ送って照合するわけではありません。パスキーには、端末に結び付けるものと、利用者の端末間で同期できるものがあります。FIDO Alliance「Passkeys」、技術的説明・同期型と端末固定型・生体情報に関するFAQ

このため「秘密鍵はどの方式でも一台の端末から絶対に出ない」とは説明できません。組織で導入する際には、同期の可否、同期先のアカウント、端末紛失時の対応、退職時の管理を確認します。

FIDO2、WebAuthn、CTAPの関係

FIDO2は、WebAuthnとCTAPを組み合わせた技術の枠組みです。WebAuthnは、Webで公開鍵認証を利用するためのAPIなどを定めます。CTAPは、外付けのセキュリティキーなどの認証器と、利用者の端末側との通信を扱います。FIDO Alliance「Specifications Overview」、FIDO2

オリジンとは、Web上の通信方式、ホスト名、ポート番号の組で表すアクセス元の区別です。WebAuthnでは、認証先との結び付きやオリジンの検証などにより、別の偽サイトで得た認証応答を本物のサイトへそのまま転用する攻撃を防ぐ設計になっています。実装側がこれらの検証を正しく行うことが前提です。W3C「Web Authentication: Level 2」、7.2 Verifying an Authentication Assertion

それでも、認証後のセッションを盗まれる、端末上で不正な操作をされる、復旧手続を悪用される、といった問題まで自動的に解消するわけではありません。パスキーは認証の対策であり、権限の過剰付与を直す機能でもありません。

認証の強さは、扱う情報と影響に合わせる

公開情報の閲覧と、大量の個人情報の出力や管理者権限の変更では、不正利用された場合の影響が異なります。取り扱う情報、操作の影響、利用環境、復旧の必要性を評価し、認証方式を選びます。

さらに、重要な操作時に追加の認証を求める設計や、管理端末からだけ利用を認める設計も考えられます。ただし、利用者の所在地やIPアドレスといった状況情報を使うこと自体を、そのまま新たな認証要素として数えないようにします。

認証要素を増やすほど、登録・紛失・交換・復旧の運用も重要になります。強い入口を作るだけでなく、業務を継続できる正規の回復手段を用意します。

午後での問われ方

• 令和6年度春期 午後問2：VPNの多要素認証を突破する手口が問われました。解答例では、攻撃者が利用者からだまし取ったIDとパスワードを正規のVPNの画面に入力して、利用者のスマートフォンにセキュリティコードを送らせ、利用者が罠のWebサイトに入力したコードを攻撃者が読み取って正規の画面に入力する、という流れが示されています。対策は「認証情報の入力は、受信したメール内のURLリンクから起動した画面には行わず、VPNの画面にだけ行う」ことです。

• 平成31年度春期 午後I問2：攻撃者が通信を中継できる環境では、ワンタイムパスワードも中継されて悪用されることが問われました。解答例では、認証器の署名を使う方式が中継に強い理由として「認証サーバでオリジンの一致を確認しているから」が示されています。

• 令和5年度秋期 午後問3：WebAuthnの特徴として、「認証に用いる情報に含まれるオリジン及び署名をサーバが確認する仕組み」が解答例に示されています。

記述の型

• 多要素認証にならない例：「パスワードと秘密の質問は、どちらも知識情報なので多要素にならない」

• OTPでも防げない攻撃：「偽サイトで入力させたコードを、攻撃者がリアルタイムに本物のサイトへ入力する」

• パスキー（WebAuthn）がフィッシングに強い理由：「サーバが、署名に含まれるオリジンが正規のサイトと一致するかを確認するため」

9. 認証情報は、発行・保管・再発行・失効まで

最初の登録を、正しい相手に結び付ける

強い認証器でも、最初に攻撃者の端末を本人のアカウントへ登録してしまえば、以後は攻撃者が正しく認証されます。

アカウントの発行申請が正当か、誰に認証情報を渡すか、初期パスワードや登録用リンクを誰が受け取れるかを確認します。初期情報を部署の共有場所へ置いたままにするような運用は避けます。初回設定の期限、未使用の初期情報の失効、初期パスワードの変更なども具体化します。

利用者IDは識別のための情報であり、通常は秘密にすることだけで本人性を保証できません。秘密にすべき認証情報と区別します。

パスワードは、長さ・使い回し・漏えいへの備えを考える

長いパスワードでも、組織名と年度のように予測しやすいものでは、推測への備えとして不十分です。また、別のサービスで流出したIDとパスワードの組を試す攻撃では、使い回しが問題になります。

利用者に気を付けてもらうだけでなく、よく使われる値や流出済みの値を受け付けない仕組み、試行回数の制限、漏えい時の変更を組み合わせます。保存側も、平文で保管せず、ソルトと適切なパスワード用ハッシュ処理を使います。ソルトは利用者ごとなどに付加する値で、同じパスワードから同じ保存値が生じにくくするために使います。単に高速なハッシュ関数を一回使えば十分、という意味ではありません。

NIST SP 800-63B-4（2025年最終版）3.1.1.2は、単一要素のパスワードには15文字以上、MFAの一部としてのみ使う場合にも最低8文字を求めています。また、文字種の組合せの強制や、漏えいの根拠がない定期変更を要求しない方針です。これは当該文書の要求であり、日本のすべてのシステムに直接適用される法的義務ではありません。NIST SP 800-63B-4、3.1.1.2 Password Verifiers

自治体での具体的な運用は、自団体の規程やシステム要件も確認します。現行規程を利用者の判断で無視するのではなく、技術的な根拠、利用環境、移行方法を示して、規程と仕組みを合わせて見直します。

再発行は、普段と別の入口になる

例えば、電話で氏名と所属を名乗るだけで、MFAを解除して新しい認証器を登録できるとします。攻撃者が公開情報を使って本人を装えば、強い認証を迂回するおそれがあります。

再発行やアカウント復旧では、本人確認の方法、受付担当が参照する情報、承認、通知、旧認証情報の扱いを設計します。本人確認に必要な情報を、復旧できなくなったアカウントだけに依存させると、正規の利用者も戻れなくなります。

認証器の追加や変更を既存の連絡先へ通知する、本人確認済みの手続で復旧する、復旧用コードを安全に保管する、といった仕組みを組み合わせます。NISTも、認証器の結び付け、紛失・窃取への対応、復旧、失効を認証器の管理として扱っています。NIST SP 800-63B-4、4 Authenticator Event Management

紛失したら、認証器と既存の利用状態の両方を見る

認証器を紛失した場合には、紛失した認証情報を無効にし、必要に応じてアカウントの利用停止やセッションの終了を行います。新しい認証器を登録するだけでは、古い認証器が使える状態が残る場合があります。

端末ごと紛失したなら、端末のロック状態、保存された情報、ログイン済みのアプリケーションも関係します。認証器だけを失効させれば、端末内のデータも消えるわけではありません。

記述の型

• 認証器を紛失したときの対応：「紛失した認証器を無効にし、既存のセッションも終了させる」

• 再発行の手続の注意点：「本人確認の方法と承認を定め、認証器の変更を既存の連絡先に通知する」

10. SSO、アカウント連携、セッション終了を分ける

SSOは、何度も認証する負担を減らす

SSO（Single Sign-On：シングルサインオン）は、一度の認証を利用して、複数のサービスを使えるようにする仕組みです。実現方式はいくつかあり、同じパスワードを全サービスへ配ることと同義ではありません。

認証を担うIdP（Identity Provider）と、サービスを提供する側が認証結果等をやり取りする方式では、サービス側が信頼できる発行者、署名、宛先、有効期限などを確認します。認証を外部へ任せても、その利用者にどの機能を許すかという判断は残ります。

認証連携にはSAMLやOpenID Connectなどが用いられます。OpenID Connect（OIDC）は、OAuth 2.0の上に認証の仕組みを加えた仕様で、IDトークンなどを扱います。OAuth 2.0のアクセス許可の委譲を、そのまま本人の認証と同一視しないことがポイントです。OpenID Foundation「OpenID Connect Core 1.0 incorporating errata set 2」、Abstract／1 Introduction

アカウントを作る連携は、別に必要

SSOが使えても、連携先のサービスにアカウントやロールを作成・変更・停止する仕組みが自動で備わるとは限りません。

アカウントなどを用意する処理をプロビジョニング、不要になった利用を解除する処理をデプロビジョニングと呼びます。自動連携にはSCIMなどを使う場合があります。SCIMは、利用者やグループなどの識別情報をサービス間で管理するための標準です。RFC 7644は、そのためのHTTPベースのプロトコルを定めています。IETF RFC 7644「SCIM Protocol」、1 Introduction

製品がSCIM対応でも、どの属性・グループ・停止操作まで連携するかは別に確認します。設定漏れ、連携エラー、同期の遅延があれば、意図した停止が反映されないことがあります。連携先で受け付けた結果まで追う必要があります。

アカウント停止と、ログイン済みの状態の終了は別

セッションは、認証後に継続して利用している状態です。毎回パスワードを入力しなくても操作できるのは、Cookieやトークンなどを用いて、その状態を確認しているからです。

退職者のIdPアカウントを停止すると、新しい認証を阻止できても、連携先ですでに成立したセッションが直ちに終わるとは限りません。

• アクセストークン：資源へアクセスする際に提示する情報。停止後の受理可否は有効期限や失効確認の仕組みによる。

• 更新トークン：新しいアクセストークンを取得するために使われる情報。失効の対象と反映を確認する。

• アプリケーションのセッション：サービス自身が維持しているログイン状態。IdP側の停止だけで終了するとは限らない。

これは製品と構成に依存します。Microsoft Entraの利用停止に関する文書でも、トークンとアプリケーションのセッションを区別し、アプリケーション側の終了処理などを説明しています。Microsoft Learn「Revoke user access in Microsoft Entra ID」、Access tokens／Session tokens／Revoke access

本稿での実務上の提案は、アカウント停止、トークンの失効、連携先のセッション終了、サービス側の権限解除を、一つの終了手順へまとめることです。すべてを即時にできない場合には、残る利用可能時間や代替策を評価します。

一度取り出した情報は、権限の解除だけでは戻らない

閲覧権限を削除しても、以前にダウンロードされたファイルが端末から自動で消えるとは限りません。共有先へコピーされた資料も同様です。

だからこそ、利用中から出力権限、保存先、持出し、委託終了時の返却・消去などを管理します。アクセス制御と、情報の取扱いのルールをつなぐ必要があります。

また、認証を集約すると、IdPの設定誤りや障害の影響が複数のサービスへ広がる可能性があります。管理者の保護、変更時の検証、復旧手段まで合わせて設計します。

11. 人が使わないアカウントも、持ち主を決める

自動処理にも、権限と認証情報がある

夜間のデータ連携、バックアップ、監視、外部サービスとの接続などでは、人がログイン画面を操作せずに動くアカウントが使われます。サービスアカウントやワークロードのIDなど、呼び方は製品によって異なります。

利用者名簿だけを点検すると、こうした主体が抜けます。人が退職していなくても、業務の廃止や接続先の変更によって不要になることがあります。

本稿では、用途、責任者、利用元、接続先、許される操作、認証情報の保管場所、有効期限、停止時の影響を管理することを提案します。ある担当者の個人アカウントを自動処理に流用すると、その人の異動やMFA設定変更が、夜間処理の停止につながる場合があります。

人のMFAを外して流用する以外の方法を考える

自動処理は、毎回人がスマートフォンで承認する方式に適さない場合があります。だからといって、人の管理者アカウントからMFAを外し、パスワードをプログラムへ埋め込む設計にする必要はありません。

サービス専用のID、証明書、実行環境に結び付いたID、一時的な認証情報など、基盤が提供する方式を検討します。AWS IAMの公式資料も、ワークロードではロールを使った一時的な認証情報を優先する考え方を示しています。これはAWS上の具体例であり、すべての製品で同じ機能が使えるわけではありません。AWS IAM User Guide「Security best practices in IAM」、Require workloads to use temporary credentials

長期の秘密情報が必要な場合には、安全な保管、参照権限の制限、更新、漏えい時の失効と切替えを設計します。更新した後で処理が止まらないよう、利用先と切替え手順も把握します。

短い有効期限だけで、最小権限にはならない

短時間で失効する認証情報でも、その間に全データを読み出せるなら、影響は小さくありません。必要な接続先と操作に絞ることが必要です。

また、一時的な認証情報を発行できる元の権限が侵害されると、攻撃者が新しい認証情報を取り続けるおそれもあります。発行元、実行環境、権限を変更できる人まで含めて管理します。

12. 不正ログインとパスワード攻撃

攻撃の種類

• 総当たり攻撃（ブルートフォース）：一つのIDに対して、パスワードの候補をすべて試す

• 辞書攻撃：よく使われる単語やパスワードの一覧を試す

• パスワードリスト攻撃：別のサービスから流出したIDとパスワードの組を、そのまま試す。利用者が複数のサービスで同じパスワードを使い回していると成功する

• パスワードスプレー攻撃：よく使われるパスワードを一つ決め、多数のIDに対して少しずつ試す。IDごとの失敗回数が少ないので、アカウントロックにかかりにくい

• リバースブルートフォース攻撃：パスワードを固定して、IDのほうを次々に変えて試す

どの攻撃かは、ログの形で見分けます。一つのIDに失敗が集中していれば総当たり、多数のIDに少数ずつの失敗が広がっていればパスワードスプレー、失敗が少ないのにログインの成功が急に増えていればパスワードリスト攻撃を疑います（ログの読み方は支援士解説3の4）。

対策

• 多要素認証を導入する（8節）。パスワードが漏れても、それだけではログインできなくなる

• 一定回数の失敗でアカウントをロックする、または試行の間隔を空けさせる。ただし、ロックはパスワードスプレーには効きにくく、攻撃者に正規の利用者をロックさせる妨害にも使われる

• 同じ送信元IPアドレスからの大量の試行を検知・遮断する。送信元を分散させる攻撃もあるので、IDをまたいだ傾向も見る

• 流出済みのパスワードや、よく使われるパスワードの登録を受け付けない

• 普段と違う環境（国、時間帯、端末）からのログインを利用者に通知する。リスクの高いログインには追加の認証を求める（リスクベース認証）

不正ログインされたときの初動

• 該当アカウントのパスワードを変更させ、ログイン済みのセッションやトークンを無効にする

• ログイン後に何が行われたか（情報の閲覧・ダウンロード、設定の変更、メールの転送設定など）をログで確かめる

• 同じ手口がほかのアカウントに及んでいないかを確かめる

インシデントとしての対応の流れは支援士解説4の3で扱います。

採点講評で指摘されたつまずき

• 令和3年度春期 午後II問1では、パスワードリスト攻撃の知識を問う設問の正答率が低く、総当たり攻撃やパスワードスプレー攻撃と区別できていない解答が多かったと指摘されています。違いは、別のサービスから流出したIDとパスワードの組を使う点です。

記述の型

• パスワードリスト攻撃が成功する理由：「利用者が、複数のサービスで同じパスワードを使い回しているため」

• パスワードスプレー攻撃の特徴：「IDごとの試行回数が少なく、アカウントロックにかからない」

• 不正ログイン後の対応：「パスワードを変更させ、既存のセッションを無効にし、ログイン後の操作をログで確認する」

13. OAuth・OIDC：認可を任せる、認証を任せる

OAuth 2.0は「認可」の仕組み

OAuth 2.0は、利用者のパスワードを預からずに、利用者が同意した範囲で、別のサービスのAPIを使う許可をもらう仕組みです。登場人物は次の4者です。

• リソースオーナー：データの持ち主である利用者

• クライアント：利用者の代わりにAPIを使うアプリケーション

• 認可サーバ：利用者を認証し、同意を得て、アクセストークンを発行する

• リソースサーバ：APIを提供し、アクセストークンを確かめてデータを返す

クライアントが要求する権限の範囲（スコープ）は、必要最小限にします。

認可コードフロー

代表的な流れは次のとおりです（図8）。

1. 利用者がクライアントで連携を選ぶと、クライアントは利用者のブラウザを認可サーバに転送する。このとき、推測できない値（state）を作って利用者のセッションと結び付けて保存し、一緒に送る

2. 利用者が認可サーバで認証し、権限の付与に同意する

3. 認可サーバは、ブラウザをクライアントに戻し、一時的な認可コードとstateを渡す

4. クライアントは、戻ってきたstateが保存しておいた値と一致するかを確かめる。一致すれば、認可コードを認可サーバに送り、アクセストークンを受け取る

5. クライアントは、アクセストークンを付けてリソースサーバのAPIを使う

アクセストークンは、ブラウザを通らず、クライアントと認可サーバの間で直接受け渡されます。攻撃者がブラウザの通信を見て認可コードを知っても、トークンを受け取るにはクライアントの認証などが必要です。スマートフォンのアプリのように秘密を安全に持てないクライアント（パブリッククライアント）では、この確認をPKCE（次の項）で補います。アクセストークンの有効期限は短くし、更新にはリフレッシュトークンを使います。

state・nonce・PKCE：それぞれ何を防ぐか

• state：攻撃者が、自分のアカウントで取得した認可コードを、罠を使って利用者のブラウザからクライアントに送らせる攻撃（CSRFの一種）を防ぐ。防がないと、利用者のセッションが攻撃者のアカウントに結び付き、利用者がアップロードしたファイルが攻撃者のアカウントに保存されてしまう、といった被害が起きる

• nonce：OIDCで、IDトークンの再利用を防ぐ。クライアントが送ったnonceと、IDトークンの中のnonceが一致するかを確かめる

• PKCE：認可コードの横取りを防ぐ。クライアントは、毎回作る秘密の値（検証コード）のハッシュ値（チャレンジコード）を最初に送り、トークンを要求するときに検証コードそのものを送る。認可サーバは、検証コードのSHA-256のハッシュ値をbase64urlエンコードした値が、チャレンジコードと一致するかを確かめる。スマートフォンのアプリで、偽のアプリが同じカスタムURLスキームを登録して認可コードを横取りしても、検証コードを知らないのでトークンを得られない

OIDCは「認証」を加える

OAuth 2.0は、APIを使う許可の仕組みで、利用者の本人確認の結果を伝える方法は決めていません。OpenID Connect（OIDC）は、OAuth 2.0の上に認証の仕組みを加え、認証の結果をIDトークンとして渡します。IDトークンはJWT（署名付きのトークン）で、クライアントは、署名、発行者（iss）、自分宛てか（aud）、有効期限（exp）、nonceを確かめます。

「SNSのアカウントでログイン」のように、認証を別のサービスに任せる方式には、利点と欠点があります。

• 利点：連携先が多要素認証に対応していれば、自社で多要素認証を実装しなくてよい

• 欠点：連携先が障害で止まると、自社のサービスにもログインできなくなる

午後での問われ方

• 令和3年度春期 午後I問1：OAuthを使ったソーシャルログインの実装が題材でした。解答例には、利点として「多要素認証の実装をSサービス側に用意しなくてよい」、欠点として「Tサービスの障害時にSサービスを利用できない」が示されています。利用者が攻撃者のアカウントに結び付けられ、利用者のアップロードしたファイルが攻撃者にダウンロードされる流れも問われています。

• 令和5年度春期 午後II問2：外部サービスとの連携で、OAuthとPKCEが問われました。解答例には、クライアントの秘密情報が漏えいしても特定の利用者のトークンを取りにくい理由として「アクセストークン要求に必要なcodeパラメータを不正に取得できないから」、PKCEの確認方法として「検証コードのSHA-256によるハッシュ値をbase64urlエンコードした値と、チャレンジコードの値との一致を確認する」が示されています。

記述の型

• OAuthとOIDCの違い：「OAuthは認可の仕組みで、OIDCはその上に認証の仕組みを加えたもの」

• stateの確認：「利用者のセッションと結び付けて保存したstateと、戻ってきたstateが一致するかを確かめる」

• nonceの確認：「送ったnonceと、IDトークンの中のnonceが一致するかを確かめ、IDトークンの再利用を防ぐ」

• PKCEの検証方法：「検証コードのSHA-256のハッシュ値をbase64urlエンコードした値と、チャレンジコードの一致を確認する」

• 認証を外部に任せる利点と欠点：「自社で多要素認証を実装しなくてよい」「連携先の障害時に自社のサービスも利用できない」

API側でアクセストークン（JWT）を検証するときの注意点は支援士解説2の4で扱います。

14. SSOの方式とSAML

SSOの方式

• エージェント型：各サーバに入れたエージェントが、Cookieなどで認証済みかを確かめる。Cookieを共有できる同じドメインの中でしか使えない

• リバースプロキシ型：利用者のアクセスをすべてリバースプロキシに集め、そこで認証してからサーバに中継する。リバースプロキシにアクセスが集中し、経由させるためのネットワーク構成の変更も必要になる

• フェデレーション型：IdPが発行した認証結果（SAMLのアサーションやOIDCのIDトークン）を、サービス側が検証する。ドメインや組織をまたいで使える

SAMLによるSSOの流れ

1. 利用者がサービス（SP）にアクセスする

2. SPは認証要求を作り、利用者のブラウザをIdPに転送する

3. IdPが利用者を認証する

4. IdPは、認証結果を書いて署名したアサーションを、ブラウザ経由でSPに送らせる

5. SPは、IdPの証明書で署名を検証し、宛先・有効期限・発行者を確かめてから、ログインさせる

SPとIdPは、直接通信しなくてもよいのが特徴です。認証に関する情報は、利用者のブラウザが中継します。そのため、IdPを社内ネットワークに置くと、社外の端末のブラウザはIdPに届かず、クラウドサービスにログインできなくなります。クラウドサービスに接続元を制限する機能がなくても、SAMLを使えば接続元を社内に絞れます。

IdPとSPは、事前に信頼関係を結んでおきます。アサーションで受け渡す属性、転送先のURL、署名を検証するための証明書などを、あらかじめ共有します。

午後での問われ方

• 平成29年度春期 午後I問3：SAMLによる認証連携を使って、クラウドサービスへの接続元を制限する構成が題材でした。解答例には、SPとIdPが直接通信できなくても連携できる理由として「認証に関する情報を利用者端末のWebブラウザが中継するから」、社外からログインできない理由として「社外からIdPへの通信がファイアウォールによって遮断されるから」が示されています。

記述の型

• SAMLでSPとIdPが直接通信しなくてよい理由：「認証に関する情報を、利用者端末のWebブラウザが中継するから」

• SPがアサーションで確かめること：「IdPの証明書で署名を検証し、IdPが発行したものであること、改ざんされていないことを確認する」

• IdPを社内に置いた効果：「社外の端末からはIdPに接続できず、クラウドサービスにログインできない」

15. Active Directoryと、特権の悪用

社内のWindows環境では、Active Directory（AD）のドメインコントローラが、利用者とPCの情報と認証を一手に担っています。侵入した攻撃者が最終的に狙うのは、ADの管理者権限です。

Kerberos認証の流れ

1. 利用者がPCにログオンすると、ドメインコントローラの認証サービスが利用者を確かめ、TGT（チケットを発行してもらうためのチケット）を渡す。TGTは、チケット発行用のアカウントの鍵で暗号化されている

2. 利用者がサーバの資源を使うとき、PCはTGTをチケット発行サービスに示し、そのサーバ用のST（サービスチケット）を受け取る。STは、アクセス先のサーバのアカウントの鍵で暗号化されている

3. PCはSTをアクセス先のサーバに示し、資源を使う

利用者は、一度ログオンすれば、パスワードを何度も入力せずに複数のサーバを使えます。

ADを狙う攻撃

• Pass the Hash：PCのメモリなどから盗んだパスワードのハッシュ値を、パスワードの代わりに使って、ほかのサーバに認証する

• ゴールデンチケット：チケット発行用のアカウントの鍵を盗み、任意の利用者のTGTを偽造する。正規のチケットと見分けがつかず、任意の利用者になりすませる

• シルバーチケット：サーバのアカウントの鍵を盗み、そのサーバ用のSTを偽造する。STはドメインコントローラに送られないので、ドメインコントローラ側では検知しにくい（午後の問題文では「認証サーバ側で検知することができません」とされた）

• Kerberoasting：サーバのアカウント用のSTを正規に要求して手に入れ、手元で総当たりしてそのアカウントのパスワードを割り出す。総当たりはオフラインで行われるので、ログインの失敗が起きず、アカウントロックが効かない

対策は、特権の扱いそのものを絞ることです。

• ドメインの管理者権限を使える人と端末を限定し、普段の業務とは別のアカウントと管理専用の端末で作業する

• サーバのアカウントのパスワードを長く複雑にする

• 管理者権限で一般のPCにログオンしない（ハッシュ値を盗まれる機会を減らす）

• ドメインコントローラの認証のログ（イベントID）を監視する（支援士解説3の4）

午後での問われ方

• 令和4年度春期 午後II問2：クラウドサービスへの移行が題材で、Kerberos認証とそれを狙う攻撃が問われました。解答例には、STの偽造をドメインコントローラ側で検知できない理由として「STは認証サーバに送られないから」、Kerberoastingにアカウントロックが効かない理由として「総当たり攻撃はオフラインで行われ、ログインに失敗しないから」が示されています。

記述の型

• STの偽造を認証サーバで検知できない理由：「STは認証サーバに送られないから」

• Kerberoastingにアカウントロックが効かない理由：「総当たり攻撃はオフラインで行われ、ログインに失敗しないから」

• ゴールデンチケットの危険：「正規のチケットと見分けがつかず、任意の利用者になりすませる」

16. 午前II（科目A-2）で正誤を見分けるポイント

• 「パスワードと秘密の質問を組み合わせれば、多要素認証になる」→ 誤り。どちらも知識情報

• 「パスワードスプレー攻撃は、一つのIDに対して多数のパスワードを試す」→ 誤り。多数のIDに対して、少数のパスワードを試す

• 「OAuth 2.0は、利用者を認証してその結果をクライアントに伝える仕組み」→ 誤り。OAuthは認可。認証の結果を伝えるのはOIDC

• 「SAMLでは、SPとIdPが直接通信して認証結果を受け渡す必要がある」→ 誤り。ブラウザが中継する

• 「RBACでは、利用者に権限を直接付ける」→ 誤り。利用者にロールを割り当て、ロールに権限を付ける

• 「MACでは、データの所有者がアクセス権を自由に変更できる」→ 誤り。それはDACの特徴

• 「シングルサインオンでIdPのアカウントを停止すれば、連携先のログイン済みのセッションも必ず即座に終わる」→ 誤り。製品と構成によるので、連携先のセッションやトークンの扱いも確かめる

• 「リスクベース認証は、普段と異なる環境からのログインに追加の認証を求める」→ 正しい

理解度チェック

本文の理解を確かめるためのオリジナル問題です。実際の過去問ではありません。

問1　認証と認可

職員Aが正しいIDとパスワードでログインし、担当外の申請データを閲覧できた。最も適切な判断はどれか。

• ア：認証に成功したので、閲覧は問題ない

• イ：認証は成功しているが、担当外の申請を見せない認可の確認が不足している

• ウ：パスワードを長くすれば解決する

• エ：画面に担当外の申請へのリンクを表示しなければ解決する

正解：イ。本人であることと、その対象への操作を許すことは別です。エは画面を隠すだけで、処理する側の確認になっていません。

問2　ログの傾向から攻撃を見分ける

ログイン失敗のログを調べると、多数のIDに対して、それぞれ1〜2回ずつ、同じパスワードで失敗していた。最も疑われる攻撃はどれか。

• ア：総当たり攻撃

• イ：パスワードスプレー攻撃

• ウ：パスワードリスト攻撃

• エ：Kerberoasting

正解：イ。IDごとの失敗が少ないので、アカウントロックにかかりにくい手口です。アは一つのIDに失敗が集中し、ウは流出したIDとパスワードの組を使うので成功が増えやすくなります。

問3　多要素認証

多要素認証に当たるものはどれか。

• ア：パスワードと、秘密の質問への回答

• イ：パスワードと、別の暗証番号

• ウ：パスワードと、スマートフォンの認証アプリが表示するワンタイムパスワード

• エ：パスワードを2回入力する

正解：ウ。知識情報（パスワード）と所持情報（スマートフォン）を組み合わせています。ア・イ・エは、すべて知識情報です。

問4　PKCE

スマートフォンのアプリでOAuthの認可コードフローを使う。偽のアプリに認可コードを横取りされても、アクセストークンを取得させないための仕組みはどれか。

• ア：state

• イ：PKCE

• ウ：リフレッシュトークン

• エ：スコープ

正解：イ。認可コードを要求したアプリだけが知る検証コードを、トークン要求のときに確かめます。アのstateは、攻撃者の認可コードを送り込まれる攻撃への対策です。

問5　SSO利用者の退職

SSOを使っている職員が退職し、IdPのアカウントを停止した。適切な対応はどれか。

• ア：IdPを停止したので、ほかに確認することはない

• イ：連携先のサービスで、ログイン済みのセッションやトークン、サービス側のアカウントと権限が残っていないかも確かめる

• ウ：連携先のアカウントは、次の定期点検まで残しておく

• エ：退職者のパスワードを公開して、再利用を防ぐ

正解：イ。IdPの停止は新しい認証を止めますが、連携先で成立済みの状態や、サービス側のアカウントが残る場合があります。

実務と国・自治体では

実務で権限の問題が残りやすいのは、変化のときです。異動で新しい権限だけを足して古い権限が残る、委託先の作業者が交代しても前任者のIDが残る、自動連携が失敗しても誰も気付かない、復旧の手続だけが古いまま弱い、といった場面です。調達では「担当者は必要な操作ができること」と「担当外の対象や操作は拒否されること」の両方を、受入れで確かめます。

政府機関等の統一基準は、主体認証、必要最小限の権限と定期的な確認、特権への対策とログの取得・点検を求めています。自治体向けのガイドラインも、人事と連携した未使用IDの点検や、特権IDの管理の例文を示しています。資料の位置付けは支援士解説1の1で整理しています。

まとめ

• 認証と認可は別。 ログインできたことは、何でも見てよいことを意味しない。処理する側で、対象と操作を毎回確かめる。

• 権限は変化のときに崩れる。 異動・退職・委託先の交代・自動連携の失敗で、不要な権限が残る。特権は申請・期限・記録・照合で管理する。

• 認証は要素の種類とフィッシングへの強さで選ぶ。 OTPは中継されうる。パスキーはオリジンを確かめるので中継に強い。登録と再発行が弱点になる。

• 連携の仕組みは、何を確かめているかで読む。 OAuthは認可、OIDCは認証、SAMLはブラウザが署名付きの結果を運ぶ。state・nonce・PKCEは、それぞれ別の攻撃を防ぐ。

さらに深く学ぶなら

この記事の範囲を超えて、仕組みをもっと深く知りたい人向けの本です（試験対策の本ではありません）。

• OAuth 2.0の仕組みと、各構成要素の脆弱性と回避策を詳しく学べる

関連記事

• 前提：暗号化すれば全て安全？｜支援士解説3の1（署名・証明書・ハッシュ）

• 次に読む：ログインできれば、安全なのか｜支援士解説2の4（セッション管理・APIの認可）

• あわせて読む：ログを取るだけで攻撃に気付ける？｜支援士解説3の4（認証のログの読み方）

2026年10月改訂：午後の出題例と記述の型を加え、不正ログイン・OAuth/OIDC・SAML・Active Directoryの節を新設し、構成を見直しました。