その製品、安全に使えますか？——選定・評価制度・要塞化・クラウドの責任分担・受入れを午後の問われ方で読む｜支援士解説2の2

この記事の重要度：Aランク（午後の大問・設問でよく問われる重要な分野）

この記事で分かること：

• 製品・サービスを選ぶとき、機能・利用条件・運用を分けて照合する方法と、評価・認証制度の読み方

• 要塞化、更新と設定の維持、クラウドの責任分担と設定不備、受入れでの確認

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

シラバスとの対応：小項目2-2「製品・サービスのセキュアな導入」。要求の定義は支援士解説2の1、ネットワークの構成は支援士解説2の3、脆弱性への対応とパッチは支援士解説3の6、委託先とサプライチェーンの管理は支援士解説3の10で扱います。

午後の問題では、製品やクラウドサービスを導入する場面がよく題材になります。「多要素認証に対応」「ログを取得できる」と書かれた製品を選んでも、契約したプランで使えるか、初期設定のままで安全か、導入後も設定が保たれるか、事業者と利用者のどちらが何を管理するかによって、安全かどうかが変わります。工場出荷時のパスワードのまま公開された機器や、誰でも見られる状態にしたクラウドのストレージは、その典型です。

この記事では、架空の自治体が個人情報を含む資料を委託先と共有するサービスを導入する場面を例に、選定、評価制度の読み方、要塞化、更新、クラウドの責任分担、受入れ、費用の比較を順に整理します。

1. 要件と仕様を、利用する条件まで照合する

比較の出発点は、製品名でなく要件

支援士解説2の1で「指定した受取人だけが資料を読める」と定めたなら、選定で問うのは「共有機能があるか」だけではありません。受取人を個人単位で指定できるか、組織外の利用者をどう確認するか、期限を設定できるか、期限後にアクセスを拒むか、操作を記録できるかまで確認します。要求が変われば、ふさわしい候補も変わります。

オンプレミスのファイルサーバ、完成したファイル共有SaaS、他のクラウド上で自ら構築する仕組みには、管理する範囲が違います。現場が設定・監視を担えるか、既存の認証基盤と連携するか、障害時の代替手段があるかを確認し、初期費用だけで選びません。「オンプレミス」「SaaS」は選択肢の種類であって、安全性の順位ではありません。

「ある」「使える」「維持できる」を分ける

候補の仕様を見るときは、次の三段階を分けます。

1. 機能：受取人限定、管理者の多要素認証、操作記録などが提供されるか。

2. 利用条件：必要な契約プラン、利用者数、外部共有・ログ保存の制限、追加費用はどうか。

3. 運用：初期設定、異動時の権限削除、ログの点検、障害時の連絡、利用終了時の返却・削除を誰が担うか。

「多要素認証に対応」と書かれていても、管理者には適用でき、外部受取人には適用できないかもしれません。ログの画面があっても、必要な操作が残らず、契約期間中に出力できなければ調査に使えません。候補ごとに、要求ID、製品仕様の該当箇所、契約条件、設定方法、確認の証拠を結びます。未対応を「代替策あり」とする場合は、代替策の対象、効果、運用担当も確認します。

サポートと終了条件も選定の一部

更新の提供期間、脆弱性の連絡窓口、保守時間、委託先による遠隔作業の範囲が分からなければ、稼働後に保護を維持できるか判断できません。契約終了時には、データとログを取り出せる形式、引継ぎ期間、削除の確認方法も必要です。選定時に終了を考えるのは、後で利用を続けられなくなったときに住民サービスを止めないためです。

調達の進め方：RFIとRFP

要件に合う候補を探すとき、いきなり価格の見積りを取るのではなく、段階を踏みます。

• RFI（情報提供依頼）：調達の前に、事業者から製品・サービスの情報を集める。要件を満たす方法がどれだけあるかを知り、仕様書の書き方に反映する

• RFP（提案依頼書）：要件、守るべき条件、評価の方法を示して、事業者に提案を求める

• 提案の評価では、要件ごとに、対応の方法、契約の条件、設定と運用の担当、未対応と代替策を並べて比べる

選定の結果は、要求ごとに「対応する・プランの変更で対応する・代替策で対応する・対応しない」を分け、確認結果の証拠と結びます。画面に「対応」と表示されることと、指定先だけに渡せることは、別の確認です。

仕様書には「セキュリティに配慮すること」ではなく、要件を確かめられる形（受取人を個人単位で指定できる、期限後は取得を拒否する、など）で書きます。要件の書き方は支援士解説2の1で扱います。

記述の型

• 製品の比較：「機能の有無だけでなく、契約するプランで使えるか、誰が設定・運用するかを要求ごとに確かめる」

• 終了の条件：「契約終了時に、データとログを取り出せる形式と、削除の確認方法を選定時に確かめる」

2. 評価・登録の意味を、対象範囲で読む

認証、評価、登録は、候補を調べる有力な材料です。ただし、何を、どの版・構成で、どの要件に照らして評価したかが違います。製品に付いた名称だけから、調達するシステム全体の安全性を推論しません。

例えば、ITセキュリティ評価・認証制度JISECは、ISO/IEC 15408に基づき、特定の評価対象とセキュリティ目標を評価します。認証製品なら、公開されるセキュリティターゲットや報告書で、機能、版、利用条件、評価の範囲を確認します。「認証済み」という語だけでは、自団体が使う全機能や設定まで評価されたことにはなりません。IPA「JISECの認証製品の活用」

クラウドのISMAPは政府情報システム向けの評価・登録制度、JC-STARは対象となるIoT製品の適合性を示すラベルです。対象と評価方法が異なり、一つを取得すれば他の要件まで満たすわけではありません。JC-STARは★1・★2が自己適合宣言、★3・★4は第三者評価・認証という違いもあります。調達の場面では、対象製品・サービス、登録されている範囲、有効性、利用者が行う設定を別々に確かめます。ISMAPポータル、IPA「JC-STAR制度の詳細」

評価制度を調達の条件に使うなら、「登録されていること」だけでなく、登録の対象となるサービス名・範囲・有効期限を、契約するものと照合する手順まで決めます。登録や認証が失効・更新されたときに、事業者から知らせてもらう取り決めも必要です。導入側で行う設定や運用は、評価の外に残ります。制度の名称だけで、導入する構成全体の安全を判断しないことが大切です。

クラウドサービスの事業者の管理体制を確かめる材料には、第三者による保証報告書もあります。委託先の内部統制を監査人が評価した報告書には、財務報告に関わる統制を対象とするSOC 1（基準は国際的にはISAE 3402、米国ではSSAE 18。SSAE 16はSSAE 18に置き換えられた）と、セキュリティや可用性などの規準で評価するSOC 2があります。組織の情報セキュリティマネジメントシステムを認証するISMS認証（ISO/IEC 27001）も材料になります。ここでも、報告書や認証が対象とするサービス・期間・範囲が、利用するサービスと一致するかを確かめます。

供給過程に関する不正な変更や、サポートが終了した後の更新停止も選定リスクです。ソフトウェア部品表であるSBOMを求めるなら、何の製品・版の一覧か、更新を誰が行うか、脆弱性の通知を受けて誰が影響を調べるかまで決めます。部品表を受領しただけで、製品の安全性が証明されるわけではありません。

午後での問われ方

• 令和3年度春期 午後II問2：利用部門が使うクラウドサービスをIT部門が統制する場面が題材でした。サービスを選ぶ要件に関連して、規格又は認証の例として、解答例には「ISAE3402/SSAE16」と「ISMS認証」が挙げられています。

• 令和2年度10月 午後II問2：マルチクラウドを使うテレワーク環境のリスク評価が題材でした。クラウドサービスの事業者が、サービスへの影響を理由に利用者による脆弱性検査を許可しなかったため、その代わりに対策を確かめる方法として、解答例は「セキュリティ対策についての第三者による監査報告書で確認するという方法」です。

記述の型

• 事業者の対策の確認：「第三者による監査報告書や認証で確認し、対象の範囲と期間が利用するサービスと一致するかを確かめる」

• 認証製品の扱い：「評価対象の版・構成・利用条件と、自組織で使う範囲を照合する」

3. 要塞化：必要な機能を守りながら入口を減らす

ハードニング（要塞化）は、サーバ、ネットワーク機器、ソフトウェアの設定を用途に合わせて見直し、不要な攻撃の入口や過剰な権限を減らすことです。業務に必要な通信まで止めれば、サービスは使えません。設定を強くした数ではなく、想定する脅威を減らし、必要な業務を保てるかで評価します。

サーバで確認するもの

• ソフトウェアと更新：OS、ミドルウェア、追加した部品がサポート中か。必要な修正を、影響の確認と適用結果まで含めて管理する。

• サービスと通信：使わないサービス、サンプル画面、不要な管理インタフェースを無効にする。必要な通信は接続元・宛先・用途を明らかにする。

• アカウントと権限：使わない初期・構築用アカウントを処理し、共通の初期認証情報を変更する。管理者権限を必要な人・作業に絞る。

• ファイルと記録：データ、設定ファイル、鍵、ログの読取り・変更権限を分ける。必要な操作が記録され、保存先が枯渇しないか確かめる。

• 復旧：設定変更や更新が失敗したときに戻せるよう、構成情報とバックアップ、復元手順を確認する。

ポートは、通信の行先となるサービスを区別する番号です。不要なサービスを止めれば、その待受けもなくせることがあります。一方、外側のファイアウォールで通信を遮断していても、内部から到達できるサービスや、許可したWeb通信の先にはサーバの弱点が残り得ます。ファイアウォールとサーバ側の更新・設定は、互いの代わりではありません。

ネットワーク機器なら、管理画面へ到達できる場所、初期認証情報、管理プロトコル、通信許可規則、設定変更の記録を見ます。一時的な保守のための許可が残っていないか、不要な管理機能が外部に公開されていないかも確かめます。必要な通信は拒否しない一方、意図していない接続は拒否する設定にします。

構築用・保守用の経路を閉じる

構築のときに使った一時的なアカウント、テスト用のデータ、保守のために開けた通信は、稼働の前に閉じます。閉じ忘れは、納品後に気付きにくい入口になります。管理画面や管理用の通信は、管理元を限定した場所からだけ接続できるようにし、遠隔保守が必要なら、使う時間・経路・承認を決めます。稼働後の準備として、設定変更の記録と、変更を戻す手順も整えておきます。

初期値も、推奨値も、目的に照らす

初期設定が必ず危険とは限りません。ただし、対象の利用者と情報を知らずに定められた値が、自団体の要求を満たすとは限りません。例えば「リンクを知る人が共有できる」は、公開資料なら便利でも、審査前の個人情報を含む資料には合いません。逆に、厳しい設定がすべて正解ではなく、正当な受取人まで拒むなら業務を妨げます。

安全な構成の参考としてCIS Benchmarksがあります。OSやクラウド等の技術ごとの推奨設定で、Level 1は利用可能性を保ちながら攻撃面を下げる基本設定、Level 2はより防御を重視し、環境への影響が大きい場合があります。CIS自身も、どのプロファイルでも試験環境で影響を確認することを勧めています。製品・版に合う資料を選び、採用・例外の理由を残します。CIS「CIS Benchmarks FAQ」

午後での問われ方

• 令和2年度10月 午後I問1：店舗の無線LANルータを、決済アプリを使う利用者に開放する計画が題材でした。ルータには、インターネット側から管理画面にアクセスできてしまう既知の脆弱性があり、管理者機能のパスワードが工場出荷時のままの可能性もありました。攻撃者がルータの設定を変えると、利用者が攻撃者のサーバに接続しても気付かないおそれがあり、変更される設定として、解答例は「DNSプロキシ」の参照先を「攻撃者のDNSサーバのIPアドレス」にすることです。対策は、脆弱性を修正した最新のファームウェアへの更新と、管理者機能のパスワードの変更です。

記述の型

• 初期設定の見直し：「工場出荷時の管理者パスワードを変更し、管理画面へ接続できる場所を限定する」

• 要塞化の考え方：「不要なサービス・アカウント・権限を減らし、業務に必要な通信と更新・復旧の手段は残す」

• 稼働前の確認：「構築用の一時的なアカウントや、保守のために開けた通信が残っていないかを確かめる」

• ファイアウォールとの関係：「外側で通信を遮断していても、許可した通信や内部からの通信に対して、サーバの更新と設定は必要」

4. 更新と設定の基準を、稼働後も維持する

購入時に新しい製品でも、納品する版に修正プログラムが反映されているとは限りません。更新プログラムは不具合や脆弱性を修正しますが、適用によって連携が止まる可能性もあります。脆弱性の影響と悪用可能性、公開範囲、代替策、更新の緊急度を調べ、検証、適用、結果確認、必要なら切戻しを一つの手順として考えます。危険が差し迫るときと、十分に検証時間を取れるときで進め方は変わります。

設定の基準値をベースラインとして残します。これは、採用した版・設定値と、その理由、例外を記録した基準です。導入後に設定が変わることを設定ドリフトと呼びます。すべての変更が不正とは限りませんが、保守のために開けた通信、退職者の権限、期限切れの例外が放置されていないかを差分で見ます。製品の自動点検は役立ちますが、警告の意味と業務への影響を判断する人が要ります。

更新を見送る場合は、「古いから危険」「更新できないから仕方ない」で止めません。対象の版、更新できない理由、代替策、期限、残るリスク、判断者を記録します。暫定的な通信制限をしたとしても、脆弱性そのものが修正されたとは言いません。

設定の基準と点検を、仕組みにする

設定の基準（ベースライン）は、文書に書くだけでなく、設定の管理ツールやクラウドの点検機能で、現在の設定との差を定期的に検出できるようにします。差が見つかったら、変更の申請と承認の記録と照らし、理由のない変更は戻します。点検の結果は、誰が確認し、いつまでに直すかまで決めます。

製品の脆弱性情報を受け取る

更新を適用するには、まず脆弱性が公表されたことを知る必要があります。製品の提供元の通知、JVNなどの脆弱性情報、保守事業者からの連絡を、誰が受け、どの製品・版に影響するかを誰が調べるかを決めます。保守の契約には、影響の有無を回答する期限や、緊急時の連絡の方法も含めます。修正プログラムの適用では、動作確認、失敗時の切戻し、適用の成否の確認まで手順にし、ベースラインには採用理由も残します。未修正の期間が長くなるなら、その間の業務動作への影響と代替策を記録します。

更新を配り、適用を確かめる仕組み

台数が多いと、更新を一台ずつ手作業で適用することはできません。配信の仕組みを使う場合は、次の流れで考えます。

1. 検証用の端末に先に適用し、業務の動作に問題がないことを確かめる

2. 一部の端末へ先行して配信し、問題がなければ全体へ広げる

3. 電源が入っていない端末、持ち出している端末など、配信が届かない端末を把握する

4. 適用の結果を集め、未適用の端末とその理由を確かめる

午後での問われ方

• 令和3年度春期 午後I問3：組織に適した脆弱性修正プログラムの配信手順が題材でした。修正プログラムを組織内に展開する前に確かめることとして、解答例は「PCの動作に問題がないこと」です。夜間に電源の入っていないPCを起動して配信する仕組み（Wake on LAN）の制約と、その解決方法も問われています。

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

• 令和3年度春期 午後I問3では、Wake on LANの制限事項と、その解決方法を問う設問の正答率が低かったとされています。セキュリティ対策を進める中で構成による制限に直面したら、その要因となる仕組みを理解する必要があります。

記述の型

• 設定ドリフトの点検：「採用した設定の基準（ベースライン）と現在の設定を比べ、理由・期限・承認のない変更を戻す」

• 更新を見送るとき：「対象の版、理由、代替策、期限、残るリスク、判断者を記録する」

• 組織内へ展開する前：「検証用の端末で、更新を適用しても業務の動作に問題がないことを確かめる」

脆弱性への対応の優先度とパッチの管理は支援士解説3の6で扱います。

5. クラウドサービスの利用：責任分担と設定不備

サービスモデルと分担

クラウドのIaaSは仮想サーバ等の基盤、PaaSはアプリケーションを動かす環境、SaaSは完成したアプリケーションを提供するサービスモデルです。公開先が広いパブリッククラウドか、自組織向けのプライベートクラウドかという分類とは別の軸です。NIST「SP 800-145 The NIST Definition of Cloud Computing」

• IaaSの例：事業者が物理設備や基盤を管理し、利用者はゲストOS、導入したソフトウェア、通信許可、データなどを管理する。

• PaaSの例：事業者がOSや実行環境を管理し、利用者は持ち込むアプリケーション、構成設定、データ、権限を管理する。

• SaaSの例：事業者がサービス本体を管理し、利用者は契約で使える機能を確かめ、利用者・共有範囲・データの取扱いを設定する。

これは典型的な目安で、PaaSのデータベースの更新、SaaSのログ保存や暗号化の選択などはサービスごとに異なります。誰が行うかを「クラウドだから」で推測せず、サービス仕様、管理画面、契約、委託先との役割分担を読みます。利用組織に残る仕事の一つが、架空の資料共有で「指定した受取人」を実際に設定し、異動や委託終了時に外すことです。

事業者が冗長な設備を持つことと、利用者の誤削除から必要な期間に復元できることも同じではありません。保護の対象、復元可能期間、試験の方法を確認します。外部の監視製品を足す前には、現状の管理画面や契約でどの設定と記録が見えるかを調べます。

事故の多くは、利用者側の設定から起きる

クラウドでは、事業者が基盤を守っていても、利用者の設定の誤りで情報が漏れる事故がよく起きます。典型的なのは次のような不備です。

• ストレージの公開設定：オブジェクトストレージのバケットや共有フォルダを、誰でも読める設定にしてしまう

• 管理画面や管理用の通信の公開：仮想サーバの管理用ポートや、データベースをインターネットから接続できる状態にしてしまう

• 広すぎる権限：利用者や外部連携に、必要以上の権限を与える。外部のサービスに渡すトークンにも、必要な操作の権限だけを付ける

• 認証情報の扱い：長期間有効なアクセスキーをプログラムやリポジトリに置き、漏れても気付かない

• 記録の無効：監査ログを有効にしていない、保存期間が短いので、事故が起きても調べられない

利用者は、事業者が提供する設定のうち、自分が担う範囲（導入側の仕事）を把握し、初期値のまま使ってよいかを確かめます。

設定を点検する仕組みと、使われ方を見る仕組み

• CSPM（Cloud Security Posture Management）：クラウドの設定を継続的に点検し、公開設定や広すぎる権限などの設定不備やガイドライン違反を見つける

• CASB（Cloud Access Security Broker）：利用者とクラウドサービスの間で、どのサービスがどう使われているかを可視化し、利用を制御する。IT部門の許可を得ずに業務で使われるサービス（シャドーIT）の把握にも使う

クラウドサービス側にも、接続元のIPアドレスを限定する機能（送信元制限）を備えるものがあります。組織のネットワークからだけ接続を許せば、盗まれたIDとパスワードを社外で使われる危険を下げられます。ただし、拠点や接続経路を変えたときには、許可する接続元の見直しが必要です（ネットワークの構成は支援士解説2の3）。

クラウドの認証を、組織の管理下に置く

クラウドサービスごとに別のIDとパスワードを使うと、退職や異動のときに止め忘れが起きます。組織の認証基盤（IdP）とSAMLなどで連携すれば、認証を組織の管理下に置き、多要素認証もまとめて適用できます。あわせて、サービス側で接続元のIPアドレスを限定すれば、IdPの認証を通らない経路や、組織の外からの利用を防げます。ID連携の仕組みは支援士解説3の8で扱います。

シャドーITへの対応

部署が独自に契約したクラウドサービスは、台帳に載らず、設定の点検や退職者の権限削除から漏れます。プロキシやCASBの記録から、実際に使われているサービスを把握し、必要なものは正式な審査と契約に乗せ、不要なものは利用を止めます。禁止するだけで代わりの手段がなければ、利用は隠れて続きます。業務に必要な機能を、承認した経路で使えるようにすることも対策の一つです。

外部サービスとの連携

クラウドサービス同士をつなぐと、連携のためのAPIキーやトークンが生まれます。これらは利用者のパスワードと同じように守り、連携に必要な操作の権限だけを与え、使わなくなったら失効させます。連携先の事業者が侵害されたときに、自組織のデータにどこまで届くかも確かめます。APIの保護は支援士解説2の4で扱います。

事業者の障害と、利用の終了に備える

• 障害：事業者の障害で使えなくなったときの代替手段と、連絡の経路を決める。事業者の状況を知らせるページや通知の受け方も確かめる

• データの保護：事業者と利用者の分担、事業者のバックアップの対象と期間、利用者の誤削除から戻せる範囲を確かめる。必要なら、自組織でも別に保管する

• 終了：契約を終えるときに、データとログを取り出せる形式、期間、削除の証明を確かめる。特定の事業者から移れなくなる状態（ロックイン）を、選定の時点で考える

午後での問われ方

• 令和3年度春期 午後II問2（2.と同じ問題）：会社が管理するPCからだけクラウドサービスを使えるように、クライアント証明書で端末を認証する場面が問われました。個人所有の機器で使われないようにする設定として、解答例は「秘密鍵を書き出しできないように設定する」です。その設定を従業員に無効にされないよう、「管理者が、Pソフトを、一般利用者権限では変更できないように設定する」ことも示されています。

• 平成29年度春期 午後I問3：クラウドサービスへの認証をSAMLで連携する設計が題材でした。社外からのアクセスを判定する条件として、解答例は「接続元IPアドレスがF社のグローバルIPアドレスではないこと」です。グループウェアのサービスに社外から接続できない理由として、「クラウドサービス側で接続元IPアドレスの制限が行われているから」も示されています。

• 令和5年度春期 午後I問3：社内のプロキシをクラウドのサービスへ移行する場面が題材でした。業務で使うクラウドサービスは、送信元制限機能で本社のUTMからのアクセスだけを許可していたので、営業所から使えるようにするには「送信元制限機能で、営業所のUTMのグローバルIPアドレスを設定する」必要があります。移行後のサービスのルールでは、研究開発部の従業員だけに特定のサイトを許可し、外部ストレージサービスは全て禁止する設定が問われています。

• 令和5年度春期 午後II問2：Webサイトのクラウドサービスへの移行と、外部サービスとの連携が題材でした。クラウドのイベントを検知するルール（システム・アカウント・サービス・イベントを指定する形式）で、オブジェクトストレージのオブジェクトの削除を検知する設定が問われています。外部のサービスに渡すトークンの権限について、解答例は「Xトークンには、ソースコードのダウンロード権限だけを付与する」です。

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

• 令和3年度春期 午後II問2では、個人所有の機器の利用を禁止するために、秘密鍵を会社が管理するPCからコピーできないようにする設問の正答率が低く、パスワードによる利用者認証など、効果のない解答が多かったとされています。

• 令和5年度春期 午後I問3では、見直しの前後の通信経路を理解していないと思われる解答が散見されたとされています。クラウドサービスのセキュリティを確保するには、通信経路がどう変わるかを把握する必要があります。また、ルールの番号を逆に答えた解答も散見され、フィルタリングのルールは適用の順番で動作が変わることに注意してほしいとされています。

記述の型

• 責任分担の確認：「サービス仕様と契約で、事業者と利用者のどちらが、更新・設定・ログ・復元を担うかを確かめる」

• 設定不備への対策：「ストレージの公開設定と権限を点検し、CSPMなどで継続的に検出する」

• 接続元の限定：「送信元制限機能で、自組織のグローバルIPアドレスからの接続だけを許可する」

• 外部連携の権限：「連携に使うトークンには、必要な操作の権限だけを付与する」

• 管理する端末に限る：「クライアント証明書の秘密鍵を書き出しできない設定にし、利用者権限では変更できないようにする」

連携の権限（OAuth）の仕組みは支援士解説3の8、DNSの設定不備は支援士解説3の5で扱います。

6. 受入れでは、設定値と動作の両方を見る

仕様に合う候補を選んでも、設定したつもりの状態で納品されることがあります。受入れでは、要求IDに対し、設定画面や構成ファイルなどの設定の証拠と、実際の操作による動作の証拠をそろえます。前者だけでは設定の範囲や例外を見落とし、後者だけでは再現条件や保守時の基準が分からない場合があります。

架空の資料共有なら、次のように試します。

• 許可：指定した受取人が、定めた方法で資料を取得できる。

• 拒否：別のアカウント、未ログイン、期限を過ぎたリンクでは取得できない。

• 記録：共有、閲覧、権限変更、失敗など、要求で定めた操作が必要な項目で残る。

• 運用：担当者が共有先を変更・終了でき、担当交代後も手順と権限が分かる。

機器の導入なら、設定ファイルと実際の通信を照合します。許可する接続だけでなく、許可しない接続と、一時的な保守経路が閉じていることも確認します。脆弱性診断を行った場合は、実施した対象・版・条件と、未実施の範囲を読みます。診断済みという一語では、本番の全設定を検証したことになりません。

検査が終わったら、設定の基準、管理者アカウントの保管、更新・障害・ログ点検の手順、連絡先を運用担当へ渡します。構築事業者と運用事業者が違うなら、両者の引継ぎ範囲も明記します。受入れは納品書の確認だけでなく、運用を始められる状態かを判断する節目です。

確認の項目を、要求から作る

受入れの試験項目は、事業者が用意した一覧をそのまま使うのではなく、要求から作ります。要求ごとに、指定先は取得可、別人・期限後は拒否、変更時も守られるか、対象操作が記録されるか、業務手順どおりに使えるかを並べ、試験結果を証拠として残します。期限内に正しく使えることと、期限後に拒否されることの両方を確かめて、初めて運用開始を判断できます。運用者への引継ぎも、受入れの一部です。

記述の型

• 受入れの確認：「指定した利用者が使えること、許可しない利用者・期限後は拒否されること、必要な記録が残ることを試す」

• 受入れの条件：「脆弱性診断に合格することを、受入れの条件にする」（診断の対象と範囲を確かめたうえで）

• 引継ぎ：「設定の基準、管理者アカウントの保管、更新・障害・ログ点検の手順と担当を、運用者へ引き継ぐ」

• 診断結果の読み方：「実施した対象・版・条件と、未実施の範囲を確認する」（脆弱性診断は支援士解説2の6）

7. 投資対効果は、総費用と残るリスクで考える

セキュリティの対策は、購入した時だけで終わりません。TCO（総保有費用）は、利用期間にわたる初期費用、利用料、設定、保守、監視、教育、更新、契約終了時の移行などを合わせて見る考え方です。同じ要求を満たす候補でも、初期費用が低い案が総費用まで低いとは限りません。

例えば、以下の金額は架空の比較条件です。両案とも、受取人限定と必要なログを実現できるとします。期間は3年で、終了時の移行費をそれぞれ20万円と仮定します。

• 案A：初期90万円、年間の利用・運用140万円。3年の総費用は90＋140×3＋20＝530万円。

• 案B：初期180万円、年間の利用・運用85万円。3年の総費用は180＋85×3＋20＝455万円。

この仮定の3年比較なら、年額の低い案Bは初期費用が90万円高くても、3年の総費用の差額は75万円で、案Bが有利という計算です。ただし、数字だけでは採用を決められません。委託先が安全に使えるか、障害時に再開できるか、設定の例外を誰が扱うか、サポートが終了しないかも見ます。安い案が要件を満たさないなら、比較の前提が崩れます。

効果も「事故が起きなかった」だけでは測れません。受取人以外への取得を拒否できる、権限削除までの時間を短縮できる、異常を調べる記録が残るなど、何が改善するかを示します。発生確率と損失額を仮定して期待損失を計算する方法もありますが、仮定の幅が大きい場合は、数値を精密な予測のように扱いません。必須要件を満たし、総費用と運用体制を比較したうえで、残るリスクの採否を権限者が判断します。

記述の型

• 費用の比べ方：「初期費用だけでなく、利用期間全体の総費用（TCO）で比べる」

• 採用の判断：「必須要件を満たす案の間で、総費用、運用体制、残るリスクを比べ、権限者が判断する」

8. 架空の資料共有で、導入を一通り判断する

冒頭の架空の自治体の要求を、もう一度整理します。個人情報を含む資料は指定した委託先だけへ渡し、期限後は閲覧させず、誰が共有したかを後から調べられるようにします。住民向けの実在サービスや調達事例ではありません。

選定では、候補サービスの受取人限定、期限、ログが、必要なプランと利用者数で使えるか確認します。認証を既存の職員IDと連携するなら、連携方法と停止時の影響を聞きます。ISMAPなどの登録情報があっても、契約するサービスと登録範囲が一致するかを見ます。サーバを自ら用意する案も比較するなら、OS更新や管理経路を誰が担当するかを含めます。

設定では「リンクを知る人」の公開リンクを無効化し、受取人指定で期限付きの共有にします。構築用の管理権限を整理し、外部共有の例外には承認者と期限を設けます。受入れでは、指定した人が取得できるだけでなく、別の人が取得できないこと、期限後に拒否されること、記録が残ることを試します。設定変更後に既存リンクがどうなるかも確認します。

運用では、新しい委託先を追加する人、契約終了時に権限とリンクを消す人、共有ログを点検する人、サービス停止時に連絡する人を決めます。最終判断では、これらに必要な費用と担当、残るリスクを示します。機能を買ったことと、組織で使える状態にしたことを分けるのが、この項目の中心です。

ファイル共有サービスで確かめること

ファイル共有やオンラインストレージは、便利な反面、設定一つで情報が外へ出ます。

• 「リンクを知っている人なら誰でも」の共有を、組織として許すか。許すなら、対象の資料と期限を限る

• 共有先を、個人・組織の単位で指定できるか。共有の作成や変更を、誰ができるか

• 共有の期限、ダウンロードの可否、閲覧の記録を設定できるか

• 退職・異動・委託終了のときに、共有と権限をまとめて外せるか

• 組織が許可していない外部のストレージサービスへの持出しを、どう防ぐか（CASBやプロキシでの制限）

委託先に資料を渡す前に

共有の仕組みを用意しても、渡す資料そのものの扱いが決まっていなければ、事故は防げません。委託契約で、資料の利用目的、保存場所、再委託の可否、返却・削除の方法を決め、渡す資料は業務に必要な範囲に絞ります。個人情報を含む資料なら、委託先が受け取った後の取扱いも確かめます（委託先の管理は支援士解説3の10）。

サーバを自前で用意する案と比べるなら、OSの更新や管理経路も分担に含めます。別人や期限後の取得を拒否できるかを試し、採用時には担当、総費用、残るリスクを示します。

記述の型

• 共有の設定：「公開リンクを無効にし、受取人を指定し、期限を設定する」

• 共有の運用：「異動・委託終了のときに、共有と権限をまとめて削除し、共有ログを点検する」

9. IoT機器を導入するとき

ネットワークカメラ、ルータ、NAS（ネットワークにつなぐ記憶装置）などのIoT機器は、パソコンやサーバに比べて、設定や更新が後回しにされがちです。導入では、次を確かめます。

• 初期の認証情報：工場出荷時の管理者パスワードを変える。機器ごとに異なる初期パスワードを設定している製品かも確かめる

• 管理機能の公開：管理画面をインターネットから使えるようにしない。検索エンジンに管理画面が登録されないようにする

• 自動設定の機能：UPnPのように、LAN側の機器からの要求でルータのポートの開放やファイアウォールの設定を変えられる機能は、悪用されると外から内への通信が許可されてしまう。不要なら無効にする

• 更新：ファームウェアの更新が提供される期間と、利用者が更新を知る方法、適用の手順

• 物理的な取扱い：設置場所、記憶装置の取り外し、廃棄時のデータ消去

IoT製品のセキュリティ要件への適合を示すラベルとして、JC-STARがあります（2.）。

午後での問われ方

• 令和4年度春期 午後I問2：ルータとNASを題材に、IoT機器のインターネット接続とWeb機能のセキュリティが問われました。ルータのUPnP機能はLAN側だけ有効で、WAN側では有効にできない仕様でした。WAN側でも有効にできた場合の問題として、解答例は「外部からLAN側への通信の許可設定が変更される」です。機器の管理画面がインターネットの検索エンジンに登録されないようにする設定（robotsメタタグ）として、「noindex」又は「none」が問われています。

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

• 令和4年度春期 午後I問2では、検索エンジンの設定を問う設問の正答率が低く、インターネット上でIoT機器を検出する方法と、それを抑止する方法を知っておいてほしいとされています。

記述の型

• UPnPの危険：「外部からLAN側への通信を許可する設定を、認証なしに変更される」

• 管理画面の扱い：「インターネットから接続できないようにし、検索エンジンにも登録させない」

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

• 「IaaSでは、ゲストOSの更新は事業者が行う」→ 誤り。一般に利用者が担う

• 「SaaSを利用すれば、利用者の権限管理やデータの取扱いは事業者の責任になる」→ 誤り。利用者が設定・判断する範囲が残る

• 「IaaS・PaaS・SaaSは、パブリッククラウドとプライベートクラウドの区別である」→ 誤り。サービスモデルと配置モデルは別の軸

• 「CASBは、クラウドサービスの利用状況を可視化し、利用を制御する」→ 正しい

• 「CSPMは、クラウドの設定を点検し、設定不備を検出する」→ 正しい

• 「ISMAPは、政府情報システムのためのクラウドサービスの評価・登録制度である」→ 正しい

• 「ISO/IEC 15408の認証を受けた製品は、どの版・設定で使っても評価範囲内である」→ 誤り。評価対象の版と構成に限られる

• 「ハードニングでは、業務に必要な通信も含めて、すべてのサービスを停止する」→ 誤り。不要なものを減らし、必要な機能は残す

• 「設定ドリフトとは、導入後に設定が基準から変わっていくことである」→ 正しい

• 「事業者の設備が冗長化されていれば、利用者の誤削除からも必ず復元できる」→ 誤り。復元の対象と期間を確かめる

• 「RFIは、事業者に提案を依頼する文書である」→ 誤り。RFIは情報提供の依頼。提案の依頼はRFP

• 「UPnPは、認証なしにルータの設定を変更できる仕組みである」→ 正しい

• 「TCOは、導入時の初期費用だけを指す」→ 誤り。利用期間全体の費用

• 「シャドーITとは、IT部門の許可を得ずに業務で使われる機器やクラウドサービスのことである」→ 正しい

• 「SOC 2の報告書があれば、そのサービスの全ての機能と期間が評価されたとみなせる」→ 誤り。対象の範囲と期間を確かめる

理解度チェック

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

問1　仕様と要件の照合

個人情報を含む資料を、指定した委託先だけに渡したい。候補のサービスの説明には「外部共有に対応」とある。選定時に最も適切な確認はどれか。

• ア：共有のボタンが画面にあれば、受取人の限定も満たすと判断する

• イ：価格表で最も安いプランを選び、設定は稼働後に考える

• ウ：契約するプランで受取人を指定できるか、初期設定と拒否の動作を確認する

• エ：事業者が提供するSaaSなので、共有範囲の設定は不要と判断する

正解：ウ。機能の名前だけでなく、契約条件と実際の設定・動作まで照合します。エは、利用組織に残る設定を見落としています。

問2　認証・登録の範囲

ある製品がセキュリティの評価・認証を受けている。調達での扱いとして最も適切なものはどれか。

• ア：認証済みなら、別の版や追加の機能も同じ範囲で評価されたとみなす

• イ：評価対象の版・構成・利用条件と、自組織で使う範囲を照合する

• ウ：評価があるので、納入時の設定の確認と受入れ試験を省略する

• エ：認証や登録があれば、運用上のリスクはすべてなくなるとみなす

正解：イ。評価には対象と条件があります。アは範囲を広げすぎ、ウは個別の設定の確認を省いています。

問3　工場出荷時の設定

店舗に設置したネットワーク機器の管理者パスワードが、工場出荷時のままだった。最も適切な対応はどれか。

• ア：機器が社内にあるので、そのまま使い続ける

• イ：管理者パスワードを変更し、管理画面に接続できる場所を限定し、ファームウェアを更新する

• ウ：機器の電源を毎日入れ直す

• エ：利用者に、機器に近づかないよう注意喚起だけを行う

正解：イ。初期の認証情報は広く知られています。変更に加え、管理画面への到達経路と既知の脆弱性にも対処します。機器が社内にあっても、利用者の端末や、脆弱性を突いた外部からの接続で管理画面に届くことがあります。

問4　クラウドの設定不備

クラウドのオブジェクトストレージに保存した資料が、インターネットから誰でも閲覧できる状態だったことが分かった。再発を防ぐ対策として、最も適切なものはどれか。

• ア：事業者の責任なので、事業者に再発防止を求めるだけにする

• イ：資料の名前を推測しにくいものに変える

• ウ：公開設定と権限を見直し、設定を継続的に点検する仕組み（CSPMなど）で不備を検出する

• エ：ストレージの容量を増やす

正解：ウ。公開設定は利用者が担う範囲です。イは補助的で、リンクが漏れれば閲覧されます。

問5　受入れ試験

指定した受取人だけが資料を開ける設定にした。受入れ時に最も有効な確認はどれか。

• ア：事業者が「設定済み」と報告したので、それ以上は試さない

• イ：指定した人が取得でき、別の人や期限後のリンクでは拒否され、必要な記録が残ることを試す

• ウ：指定した人が一度取得できれば、ほかの条件は確認しない

• エ：管理画面の設定名だけを見て、実際の動作は確認しない

正解：イ。許可と拒否、記録を、要求と結び付けて確かめます。アとエは動作の証拠を欠き、ウは守るべき条件を確かめていません。

実務と国・自治体では

実務では、要求ごとに、候補の対応範囲、必要な契約、設定値、受入れの証拠、運用の担当、費用を一続きで示し、未対応や例外を判断者へ渡します。同じ製品名でも、版やプランが変われば、機能、ログの保存期間、管理画面が変わります。保守用の管理経路や外部共有の例外には、対象、理由、許可する人、期限、終了時の戻し方を決めます。サービスをやめるときに、資料・共有先・権限・ログを取り出せるかも、選定の時点で確かめます。構築と運用の事業者が違うなら、受入れの時点で何を引き継ぐかを契約に書いておきます。RFIの段階で、管理者の多要素認証、操作ログの項目と保存期間、脆弱性の通知と更新の提供期間、データの返却・削除の方法を質問しておくと、提案の比較が具体的になります。

政府機関等の統一基準は、機器等の選定基準と納入時の確認・検査の手続、受入れ時の確認と運用保守への引継ぎを扱っています。自治体向けのガイドラインも、調達仕様書への技術的なセキュリティ機能の明記、導入前の試験、受入れ時の確認を例文で示しています。資料の位置付けは支援士解説1の1で整理しています。

まとめ

• 機能が「ある」と「使える」「維持できる」は違う。 契約するプラン、設定、運用の担当、終了時の扱いまで照合する。

• 評価・認証は、対象の範囲を読む。 版・構成・期間・サービスが、使うものと一致するかを確かめる。

• 要塞化は、不要な入口を減らし、必要な業務を残す。 工場出荷時のパスワードや、一時的な許可の残りに注意する。

• クラウドでも、利用者の仕事は残る。 公開設定、権限、認証情報、ログは利用者が管理する範囲。CSPMやCASBで点検・可視化する。

• 受入れでは、許可と拒否の両方を試す。 設定の証拠と動作の証拠をそろえ、運用へ引き継ぐ。

関連記事

• 前提：「安全に配慮」を要件に変える｜支援士解説2の1（セキュリティ要求の定義）

• 次に読む：安全な機器も、つなぎ方で守りは変わる｜支援士解説2の3（ネットワークの構成）

• あわせて読む：脆弱性対応の優先順位はどう決める？｜支援士解説3の6（パッチと脆弱性管理）

• あわせて読む：委託すれば、任せて安心？｜支援士解説3の10（委託先とサプライチェーン）

2026年10月改訂：午後の出題例と記述の型を加え、クラウドの責任分担と設定不備、ファイル共有サービスの確認事項を補い、構成を見直しました。