追加された5項目の一覧は?公式の表記と学ぶ中身
全日本情報学習振興協会の試験内容ページでは、2026年2月度の追加項目として5つが示されています。トップページの告知では、追加する内容を「サイバーセキュリティ総論、サイバー攻撃の種類とその手法、WEBセキュリティとネットワーク防御技術、クラウド/モバイル/IoTのセキュリティ、インシデント対応とフォレンジック」とも説明しています(いずれも2026年9月27日確認)。下の表は、公式の項目名と、当サイトが考える学ぶべき中身の対応です。
外部委託・連携を点検するときはSaaS・OAuthの権限管理と2026年の注意喚起を、対象と所有者の観点で読み比べてください。
委託先との実務はSCS評価制度、チェックシートの根拠、外部委託の分担で、それぞれの対象と手順を確認できます。
具体的な判断へ進むには委託先のリモートアクセスを確認してください。

| 追加項目(公式) | 主な用語(当サイトの整理) | この記事での扱い |
|---|---|---|
| Web攻撃対策 | SQLインジェクション、XSS、CSRF、SSRF、WAF | 基本は第8章の記事、API側はこの記事 |
| ログ・インシデント対応 | SIEM、EDR、ログの保全、フォレンジック | この記事 |
| クラウド・API | 責任共有モデル、設定ミス、APIキー、認可の不備 | この記事 |
| ランサムウェア・標的型攻撃 | 二重脅迫、バックアップ、侵入後の横展開、BEC | この記事(IPA 10大脅威と合わせて) |
| サプライチェーン攻撃 | 委託先経由の侵入、SBOM、ソフトウェアの改ざん | この記事 |
トップページの告知にある「モバイル/IoTのセキュリティ」は、試験内容ページの5項目の名前には入っていませんが、告知で明記されているため、当サイトでは第9章に含めています。改称の経緯は改称で何が変わったかで扱います。
なお、公式には項目ごとの出題数は公表されていません。追加分が何問出るかも非公表です。
ランサムウェアと標的型攻撃は何が違う?10大脅威の順位で確認
IPAの「情報セキュリティ10大脅威 2026」組織編は、1位「ランサム攻撃による被害」、2位「サプライチェーンや委託先を狙った攻撃」、3位「AIの利用をめぐるサイバーリスク」(初選出)、4位「システムの脆弱性を悪用した攻撃」、5位「機密情報を狙った標的型攻撃」の順です(2026年1月29日公表、2026年9月27日確認)。追加項目のうち3つ(ランサムウェア、標的型攻撃、サプライチェーン攻撃)が上位に並んでいます。
ランサムウェアは、データを暗号化して使えなくし、元に戻す見返りに金銭を要求するマルウェアです。近年は暗号化に加えて、盗んだデータを公開すると脅す二重脅迫が広がりました。身代金を払っても、データが戻る保証も、盗まれたデータが消される保証もありません。備えの中心は、ネットワークから切り離したバックアップと、VPN装置などの外部に公開した機器の脆弱性をふさぐことです。
標的型攻撃は、特定の組織の機密情報を狙い、関係者を装ったメールなどで侵入し、長期間潜伏しながら内部の別の端末へ広がっていく(横展開する)攻撃です。取引先や経営者になりすまして送金させるビジネスメール詐欺(BEC)も10大脅威の10位に入っています。
ログとインシデント対応は?SIEM・EDR・フォレンジックの役割
インシデントに気づき、何が起きたかを後から確かめるには、ログが欠かせません。ただしログは、機器ごとに形式も保存場所も違い、そのままでは大量すぎて人が見切れません。そこで使われるのが次の仕組みです。
- 1
端末・機器のログ
サーバ・ネットワーク機器・端末が記録する。EDR は端末の挙動を記録し、端末を隔離できる
- 2
SIEM
ログを集めて関連付けて分析し、1つの画面で警告を出す
- 3
SOC
SIEM などの警告を常時監視し、分析する体制・組織
- 4
CSIRT
インシデントの報告を受け、対応を指揮・調整する
SIEM は 仕組み、SOC は 人と体制。SOC が見つけ、CSIRT が対応する分担が多い。
分担は組織によって異なります(当サイトの整理)。
| 用語 | 何をするか | 覚えるポイント |
|---|---|---|
| SIEM | サーバ・ネットワーク機器・端末などのログを集め、関連付けて分析し、1つの画面で警告を出す | NISTの用語集は「情報システムの構成要素からセキュリティのデータを集め、1つのインタフェースで対応可能な情報として示すアプリケーション」と説明 |
| EDR | パソコンやサーバ(エンドポイント)の挙動を記録し、不審な動きを検知・調査し、端末を隔離する | ウイルス対策ソフトのパターン照合だけでは見逃す攻撃を、侵入後の挙動から見つける |
| SOC | SIEMなどの警告を常時監視し、分析する体制・組織 | 「装置」ではなく「人と体制」 |
| CSIRT | インシデントの報告を受け、対応を指揮・調整するチーム | SOCが見つけ、CSIRTが対応する、という分担が多い |
| デジタルフォレンジック | 電子的な証拠を、証拠としての価値を損なわない方法で集め、調べ、報告する | 原本を触らず複製を調べ、ハッシュ値で同一性を示す |
ログを活かすには、機器の時刻をそろえる(NTPで同期する)ことと、改ざんされない場所に一定期間保存することが前提です。時刻がずれていると、複数の機器のログを突き合わせて攻撃の順序を追えません。
フォレンジックでは、調べる前に証拠を保全します。記憶媒体は原本を直接調べず、複製(イメージ)を作り、原本と複製のハッシュ値が一致することで同じものだと示します。誰がいつ証拠を扱ったかの記録(保管の連続性)も残します。NISTは SP 800-86(2006年8月)で、インシデント対応にフォレンジックの技術を組み込む手引を示しています(2026年9月27日確認)。
インシデント対応全体の流れ(検知→トリアージ→対応→報告)は、第8章の記事で扱っています。
クラウドの責任共有モデルとは?利用者が守る範囲はサービスで変わる
クラウドのセキュリティは、事業者と利用者が分担します。AWSはこれを責任共有モデルと呼び、事業者の責任を「クラウドのセキュリティ」(ハードウェア、ソフトウェア、ネットワーク、施設などの基盤)、利用者の責任を「クラウドにおけるセキュリティ」(利用者が選んだサービスの中での設定やデータ)と説明しています(2026年9月27日確認)。利用者の責任の範囲は、使うサービスの種類によって変わります。
IaaS
- OS(更新プログラムの適用など)
- ミドルウェア・実行環境
- アプリケーション
- データ・アカウント・アクセス権の設定
PaaS
- アプリケーション
- データ・アカウント・アクセス権の設定
SaaS
- データ・アカウント・アクセス権の設定
どの区分でも データ・アカウント・アクセス権の設定は利用者の責任 として残る。データセンターや物理サーバはどの区分でも事業者。
区分は NIST SP 800-145、分担は当サイトの整理です。
| 管理するもの | IaaS | PaaS | SaaS |
|---|---|---|---|
| データセンター・物理サーバ・ネットワーク | 事業者 | 事業者 | 事業者 |
| OS(更新プログラムの適用など) | 利用者 | 事業者 | 事業者 |
| ミドルウェア・実行環境 | 利用者 | 事業者 | 事業者 |
| アプリケーション | 利用者 | 利用者 | 事業者 |
| データ・アカウント・アクセス権の設定 | 利用者 | 利用者 | 利用者 |
クラウドの3つのサービス区分(SaaS・PaaS・IaaS)は、米国NISTの SP 800-145(2011年9月)が定義しています(2026年9月27日確認)。どの区分でも、データとアカウント、アクセス権の設定は利用者の責任として残ることが最大のポイントです。
実際の事故で多いのは、ストレージを誰でも読める公開設定にしてしまうといった設定ミスです。対策として、管理者アカウントへの多要素認証、権限を必要最小限にすること、設定を継続的に点検する仕組みを使うことが挙げられます。
APIのセキュリティは?「認証」と「認可」を分けて考える
API(アプリケーション・プログラミング・インタフェース)は、スマートフォンのアプリやほかのシステムがサーバの機能を呼び出す窓口です。画面を通らずに直接呼ばれるため、画面側でボタンを隠しても、サーバ側で権限を確かめなければ防げません。
OWASPの「API Security Top 10」2023年版は、1位にオブジェクトレベルの認可の不備(BOLA)を挙げています。これは、URLや要求の中のIDを書き換えるだけで他人のデータを取得できてしまう欠陥です(2026年9月27日確認)。
- API1 オブジェクトレベルの認可の不備:ログインした本人が、そのデータを扱ってよいかを毎回サーバで確かめる。
- API2 認証の不備:トークンやパスワードの扱いの欠陥。認証(本人か)と認可(してよいか)は別の確認。
- API4 無制限のリソース消費:回数や量の制限(レート制限)がないと、サービス停止や費用の急増を招く。
- API5 機能レベルの認可の不備:一般利用者が管理者向けの機能を呼び出せてしまう。
- API7 SSRF:利用者が渡したURLを、サーバが検証せずに取りに行ってしまう。
- API9 不適切なインベントリ管理:古い版や試験用のAPIが放置され、入口になる。
APIキーは、アプリの中やWebページのJavaScriptに埋め込むと、利用者側から読み取れてしまいます。秘密の値はサーバ側で管理し、権限を最小限にし、漏れたら無効にして作り直すのが基本です。なお、Webアプリ全体のリスクをまとめた OWASP Top 10 の2025年版では、1位が「アクセス制御の不備」、3位に「ソフトウェアのサプライチェーンの不備」が入っています。これは2021年版の「脆弱で古くなったコンポーネント」を、依存関係・ビルド・配布の仕組み全体に広げた項目です(2026年9月27日確認)。
サプライチェーン攻撃とSBOMとは?委託先と部品から入られる
サプライチェーン攻撃とは、守りの固い本命の組織を直接狙わず、取引先・委託先・子会社や、使っているソフトウェアの部品・更新の仕組みを経由して侵入する攻撃です。IPAの10大脅威では「サプライチェーンや委託先を狙った攻撃」が組織編の2位で、8年連続の選出です(2026年9月27日確認)。
ソフトウェア側の備えがSBOM(Software Bill of Materials)です。米国CISAはSBOMを、ソフトウェアを構成する部品の「入れ子になった一覧、材料のリスト」と説明しています。どの製品にどの版のオープンソースが入っているかが分かれば、部品に脆弱性が見つかったとき、影響を受ける製品をすぐに特定できます。
経済産業省は2024年8月29日に「ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引 ver2.0」を公表し、脆弱性管理の手順の具体化、導入の範囲を考えるための「SBOM対応モデル」、委託先との契約で決めておく事項をまとめた「SBOM取引モデル」を加えました(2026年9月27日確認)。
| 形式 | 位置づけ |
|---|---|
| SPDX | 国際規格 ISO/IEC 5962:2021 として認められている |
| CycloneDX | Ecma International の規格 ECMA-424(第2版、2025年12月) |
SBOMは一度作って終わりではなく、製品の版が変わるたびに更新しないと役に立ちません。委託先の管理(契約で求める水準、監査、事故時の報告)と組み合わせて考えるのが試験でも問われやすい点です。詳しくはSBOMとはへ。
モバイル・IoTのセキュリティは?端末管理とJC-STAR
モバイルでは、紛失・盗難と、不正なアプリが主なリスクです。組織の端末はMDM(モバイルデバイス管理)で、画面ロックの強制、OSの更新、紛失時の遠隔ロック・消去などを一括で管理します。アプリは公式ストアから入れ、位置情報や連絡先などの権限は必要なものだけ許可します。私物端末を業務に使う(BYOD)場合は、業務データと私的データを分ける仕組みが要ります。詳しくはMDMとMAMの違いへ。
IoT機器は、初期パスワードのまま使われたり、更新が止まったまま放置されたりしやすく、乗っ取られて攻撃の踏み台にされる例が繰り返されてきました。国内では、IPAが2025年3月25日にIoT製品のセキュリティのラベリング制度 JC-STAR(セキュリティ要件適合評価及びラベリング制度)の運用を始め、★1の申請受付を開始しました。★1・★2は事業者の自己適合宣言、★3・★4は第三者の評価による段階です(2026年9月27日確認)。IoTの脅威はIoTの脅威と対策、制度の詳細はJC-STARとはで扱っています。
間違えやすい所は?追加範囲の取り違えポイント
| 誤解 | 正しい整理 |
|---|---|
| クラウドを使えばセキュリティは事業者の責任になる | データ・アカウント・アクセス権の設定はどのサービスでも利用者の責任 |
| SaaSでも利用者がOSの更新を行う | SaaSではOSやアプリは事業者が管理する。利用者は設定とデータを管理する |
| ログインさえ確認すればAPIは安全 | 本人か(認証)とは別に、そのデータ・機能を使ってよいか(認可)を毎回確かめる |
| 身代金を払えばデータは確実に戻る | 戻る保証も、盗まれたデータが消される保証もない。備えはバックアップと侵入口の対策 |
| SBOMは一度作れば更新は不要 | 製品の版が変わるたびに更新し、脆弱性の管理に使う |
| SIEMは端末に入れる検知ソフト | SIEMはログを集めて相関分析する仕組み。端末の挙動を見るのはEDR |
| フォレンジックは原本を直接調べる | 原本は保全し、複製を調べる。ハッシュ値で同一性を示す |
確認問題1
IaaSで利用者が責任を負うものは?
IaaS型のクラウドサービスを利用する企業が、責任共有モデルにおいて自ら責任を負うものとして、最も適切なものはどれか。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解:2。IaaSでは、事業者が提供するのは基盤(施設・物理サーバ・ネットワーク・仮想化の基盤)までで、その上のOSから先は利用者が管理します。OSの更新は利用者の責任です。
1 の施設の入退室管理、3 の物理サーバの保守、4 の仮想化基盤(ハイパーバイザなど)の修正は、いずれも「クラウドそのもの」のセキュリティで、事業者の責任です。
確認問題2
SBOMの説明として適切なものは?
SBOM(ソフトウェア部品表)の説明として、最も適切なものはどれか。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解:4。SBOMは、ソフトウェアに含まれるライブラリなどの部品と、その版や依存関係をまとめた一覧です。部品に脆弱性が見つかったとき、影響を受ける製品を素早く特定するのに役立ちます。
1 はライセンス(使用許諾)の管理の話で、部品の一覧ではありません。2 は開発の見積りや実績の管理です。3 は個人情報の管理台帳(データの目録)に当たるもので、SBOMとは別物です。
確認問題3
IDを書き換えるだけで他人のデータが見える欠陥は?
ログインした利用者が、APIの要求に含まれる注文番号を別の番号に書き換えるだけで、他人の注文の内容を取得できてしまった。この欠陥に最も当てはまるものはどれか。
選択肢を準備しています。「正解と解説を見る」は先に開けます。
正解と解説を見る
正解:1。要求されたデータ(オブジェクト)をその利用者が扱ってよいかを、サーバが確かめていないために起きる欠陥です。OWASP API Security Top 10 2023 の1位に当たります。
2 のSSRFは、利用者が渡したURLをサーバが検証せずに取りに行ってしまう欠陥です。3 は回数や量の制限がないことによる、サービス停止や費用増のリスクです。4 は古い版や試験用のAPIが把握されずに放置される問題で、番号の書き換えとは別の欠陥です。
確認問題のあとは?新しい範囲は一次資料の言葉で固める
追加範囲は、公式の教材がまだ少ない一方で、IPA・経済産業省・NIST・OWASPなどが無料で資料を公開している分野です。迷った問題は「誰の責任か(事業者か利用者か、自社か委託先か)」「認証か認可か」「見つけるのか、証拠を残すのか」の3点で見直してください。
本番と同じ形式で確かめたい方は、登録不要の情報・サイバーセキュリティ管理士の無料お試しを使ってください。問題集の全体は対策ページで案内しています。
当サイトは全日本情報学習振興協会とは関係のない、非公式の個人運営の教材です。合格を保証するものではありません。公式テキスト・公式問題集・サンプル問題・実物形式問題集の文章は使っていません。