「安全に配慮」を要件に変える——セキュリティ要求の定義と要件の書き方｜支援士解説2の1

この記事の重要度：Cランク（主に午前II（科目A-2）で問われる論点。午後では問題文の前提として読めれば十分）

この記事で分かること：

• 業務のニーズと制約から、脅威分析を経てセキュリティ要求を導く流れ

• 「適切に」で終わらせず、受入れのときに確かめられる要件の書き方

• セキュリティ・バイ・デザイン、プライバシー・バイ・デザイン、機能要件と非機能要件の区別

シラバスとの対応：小項目2-1「企画・要件定義」。リスクの評価は支援士解説1の2、製品・サービスの選定と調達は支援士解説2の2、システムの構成は支援士解説2の3で扱います。

調達の仕様書に「セキュリティに十分配慮すること」と書いたとします。納品されたシステムが他人の申請を表示できてしまったとき、この一文を根拠に「要件を満たしていない」と言えるでしょうか。何を、どこまで、どう確かめれば満たしたことになるのかが書かれていなければ、受入れのときに判断できません。

午後の試験では、要件定義そのものが大問の主題になることは多くありません。一方、問題文には、要件定義の段階で脅威モデリングを行い、設計の段階で設計書を確かめる、といった開発の手順が前提として出てきます。午前IIでは、セキュリティ・バイ・デザインや品質の規格の用語が問われます。この記事では、セキュリティ要求を定義し、要件として書くまでの流れを整理します。

1. ニーズと制約を、守る条件に変える

ニーズは、システムで実現したい業務の目的です。架空の給付金申請なら、住民が窓口に来なくても申請できること、職員が期限内に審査できること、申請者が結果を確かめられることなどです。

まず、業務の流れと、扱う情報を確かめます。

• 誰が使うか：申請者、受付の職員、審査の担当、承認者、保守事業者を、一つの「利用者」にまとめない。まとめると、見てよい範囲と操作の違いが消える

• どんな情報が流れるか：申請書、添付資料、審査の結果、外部の機関から取得する情報、帳票や通知の出力まで追う

制約には、法令・条例、組織の規程、既存システムとの接続、予算、提供の開始日、担当者の人数、利用するサービスの仕様があります。制約は、必要な対策を省く口実ではありません。予算が足りないなら、「認可の確認を省く」と決める前に、対象の業務、公開の範囲、提供の時期を見直します。必要な保護を満たせない案は、影響と残るリスクを示し、権限を持つ人が採否を判断します。サービスを止めてよい時間を、技術の担当者や事業者だけで決めることはできません。

企画の段階では、業務の担当に「何が止まると誰が困るか」、情報システム部門に「どこへ接続し、誰が保守するか」、管理職に「どの影響と費用を許容するか」を聞きます。答えが出ない項目は、曖昧なまま仕様書に埋めず、判断する人と期限を残します。

2. 脅威分析から、要求の理由を示す

脅威分析（脅威モデリング）では、守る対象と、そこへ届く経路を整理し、どこで何が起きると困るかを洗い出します。

1. 情報の流れと境界を描く：住民の画面、受付のAPI、申請のデータベース、職員の画面、帳票、委託先の保守の経路。どこで利用者の権限を確かめ、どこで別のシステムへ情報を渡すかを示す

2. 脅威を洗い出す：たとえば、申請者がURLの申請番号を書き換えると、他人の添付資料を取得できるかもしれない

3. 影響を評価する：機密性・完全性・可用性と、後から操作を追えることを、業務の被害に結び付ける。審査の結果が書き換えられる、受付が止まって締切に間に合わない、調査に必要な記録が消される、では守る性質も対策も違う

4. 要求にする：上の例なら、ログイン済みかを確かめる認証だけでは足りない。その申請を見てよいかを要求ごとに確かめる認可が必要になる。画面で他人の申請を選べないようにしても、直接送られたAPIの要求を受け付けるなら守れない

脅威を見落としなく洗い出すには、六つの観点で問いを立てるSTRIDEが使えます（使い方は支援士解説1の2）。それぞれの脅威は、次の要求につながります。

• なりすまし（Spoofing）→ 認証の要求

• 改ざん（Tampering）→ 完全性を守る要求（改ざんの防止と検知）

• 否認（Repudiation）→ 操作を後から証明できるログの要求

• 情報漏えい（Information disclosure）→ 認可と暗号化の要求

• サービス妨害（Denial of service）→ 可用性の要求（負荷への備え、復旧）

• 権限の昇格（Elevation of privilege）→ 最小権限と認可の要求

脅威は攻撃者だけではありません。誤った権限の付与、連携先の障害、更新作業の失敗も考えます。設計が決まっていない段階でも、利用者、情報の流れ、外部との接点を仮に置いて分析し、設計や委託先が変わったら見直します。「脅威分析を実施した」という記録より、どの要求の理由になったかが大切です。リスクの評価の方法は支援士解説1の2で扱います。

3. 要件を、試せる文章にする

「適切なアクセス制御を行う」では、どの操作を誰に許すかが決まらず、受入れのときに同じ結果を判断できません。要件は、目的、対象、条件、求める結果、確かめる方法（証拠）、担当を一組にして書きます（図1）。次は架空のシステムの例です。

• 目的・対象：申請者が他人の申請を読めないようにする。申請者と申請の資料を特定し、画面だけでなくAPIでの取得も対象にする

• 条件・求める結果：申請の閲覧・取得の要求ごとに、ログインしている利用者と対象の申請の対応をサーバ側で確かめ、権限の外の要求を拒否する。正常な申請は利用できる

• 証拠・確認：自分の資料は取得でき、他人の申請番号を指定した要求は拒否されることを、画面の操作と、直接のAPIの要求の両方で試す

• 役割・運用：事業者が実装と試験の結果を示し、調達側が要求と照合する。利用者の異動など、変更のときの権限も見直す

実装の方法は設計で選べる部分があっても、どの状態を満たすかは発注のときに明確にしておきます。基準や製品の名前を指定するときも、どの版の何を満たすのかを示します。

ログの要件も目的から書きます。職員による申請情報の利用を追えるようにしたいなら、対象の操作（閲覧・更新・出力・権限の変更）、記録する項目（誰が、いつ、何に、何をして、結果はどうか）、保存期間、閲覧できる人、改ざんへの備えを決めます。共用のIDとIPアドレスだけでは、操作した個人をたどれないことがあります。反対に、申請書の全文やパスワードをログに残す必要はありません。

復旧の要件も「バックアップを取る」では足りません。業務を再開するまでの目標復旧時間（RTO）と、どの時点のデータまで戻すかという目標復旧時点（RPO）を、業務の締切、代わりの受付、費用とともに決め、想定した条件で戻せるかを試します（支援士解説3の3）。

要件の項目ごとに決めること

セキュリティ要件の項目ごとに、少なくとも次の点を決めます。

• 認証：対象の利用者、方式（多要素認証が必要か）、失敗が続いたときの扱い、パスワードを忘れたときの再発行での本人確認

• 認可：役割ごとに許す操作、サーバ側で確かめること、権限を与える・外す手続

• 入力と出力：受け付ける値の検証、画面やSQLへ出力するときの無害化（支援士解説2の5）

• 暗号化：通信中と保存中のどちらの、どの情報か。鍵を誰が管理するか

• ログと監視：上で述べた対象の操作と項目、保存期間、異常のときの連絡先

• 可用性と復旧：提供する時間帯、止めてよい時間、RTOとRPO

• 脆弱性への対応：更新の責任者と期限、製品のサポートの期間

• 委託とクラウド：責任の分担、事故のときの報告の期限とログの提供

要件には優先度（必須か、推奨か）を付け、決まっていない項目は判断する人と期限を記録します。要件を後から変えるときは、影響を評価し、承認を得て、仕様書と試験の項目を直します（変更の管理は支援士解説2の7）。

仕様書のレビュー

仕様書のレビューでは、専門用語があるかだけでなく、要求の根拠、対象、達成の条件、確認の方法、担当を追います。

• 「情報を適切に暗号化する」なら、通信中か保存中か、どの情報か、鍵を誰が管理するかが決まっていないかもしれない

• 「必要に応じて監視する」なら、必要と判断する条件、監視の対象、時間帯、異常のときの連絡先を確かめる

• 要求にIDを付け、「根拠→要求→設計・実装→確認の結果」をたどれるようにする（トレーサビリティ）。逆向きに、試験の結果がどの要求を確かめたものかも追う

• 正常な利用だけでなく、拒否すべき操作、連携先が応答しないとき、ログの保存先がいっぱいになったときも確かめる

架空の申請システムで組み立てる

ここまでを、架空の給付金申請に当てはめます。

1. 脅威として、申請者による他人の資料の取得と、職員による担当外の申請の閲覧を挙げる

2. 申請者と職員の認可を別々の要求にし、それぞれ「許す操作」と「拒む操作」を試験で確かめる

3. 申請情報の閲覧・更新・出力の記録を要求する。Webサーバの接続の記録だけで足りるとしないよう、対象の操作と項目を明記する

4. 締切があるので、業務の担当と、止まったときの代わりの受付、RTOとRPOを決め、復元の試験を求める

5. 集める情報の必要性、初期の閲覧権限、保存の終了のときの扱いを、プライバシーの観点で見直す

6. 各要求に、事業者の実装と提出資料、発注者の設定と受入れの判断、運用を始めた後の担当を対応させる

監視の機能を買っても、見る担当者がいなければ異常に対応できません。バックアップがあっても、戻す条件が分からなければ業務の再開を判断できません。運用できない機能を要件にしても、守りにはなりません。

4. 機能要件と非機能要件、品質の規格

• 機能要件：申請を受け付ける、審査する、通知するなど、システムが何をするか

• 非機能要件：必要なときに使える、決めた時間で応答する、安全に運用できるなど、品質や条件

セキュリティは非機能要件として整理されることがありますが、実現には認証、権限の制御、ログの出力といった具体的な機能も要ります。どちらに分類するかにこだわるより、要求の抜けと矛盾をなくします。厳しい認証で申請者を守ろうとしても、正当な利用者が手続を終えられなければ、使えないという問題が残ります。

品質を話し合う道具として、次のものがあります。

• SQuaRE（ISO/IEC 25000シリーズ）：システムとソフトウェアの品質の要求と評価の規格群。ISO/IEC 25010は製品の品質モデルを示し、2023年版では九つの品質特性を定めている（2011年版は製品の品質特性が八つで、利用時の品質モデルも含んでいた）。セキュリティは品質特性の一つ。規格の名前を仕様書に書くだけで、個々のシステムの安全が証明されるわけではない

• 非機能要求グレード（IPA）：発注者と開発者が、非機能要求の項目と水準の認識を合わせるための資料。可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジーの大項目で整理している。すべての項目で最も高い水準を選ぶためのものではない

5. セキュリティ・バイ・デザインとプライバシー・バイ・デザイン

セキュリティ・バイ・デザインは、システムの企画・設計の段階からセキュリティ対策を組み込み、開発、試験、運用でも確かめ続ける考え方です。稼働の直前に診断を一度するだけでは、権限の単位、データの分け方、委託先との接続、ログの保存先など、早く決めるべき構造を変えにくくなります。早く考えることは、後の検証を省くことではありません。

委託やクラウドを使う場合も、責任の分担を要件にします。SaaSが権限管理の機能を持っていても、誰に審査の権限を与え、異動のときに外すかは、利用する組織の判断と作業になることがあります。ソフトウェアの部品の一覧（SBOM）を求めるなら、受け取るだけでなく、更新の時期と、脆弱性が見つかったときの連絡と対応まで決めます（支援士解説3の10）。

プライバシー・バイ・デザインは、本人への影響を、業務とシステムの設計の段階から考え、運用・廃棄まで扱う考え方です。カナダのオンタリオ州の情報・プライバシー・コミッショナーが提唱し、事後の対応より予防、初期設定での保護、設計への組込み、情報の一生を通じた保護などの七つの原則を示しています。

• 収集：審査に必要な情報だけを求めているか。「将来使うかもしれない」で項目を増やしていないか

• 利用：どの部署が何の目的で使うか。初期設定で、必要のない職員に見えていないか

• 保存・終了：保存期間、連携先、バックアップ、業務の終了のときの削除や引継ぎ

暗号化やアクセス制御は、プライバシーの保護にも役立ちますが、不要な情報を集める設計を正当化しません。法令上の利用目的や手続は、個人情報保護法などで別に確かめます（支援士解説3の11）。

午後で出てくる場面

• 令和7年度春期 午後問1：システム開発企業のサプライチェーンのリスク対策が題材だった。作成中のガイドライン案に、仕様と機能を精査して不要な機能やセキュリティ上の欠陥がないことを設計書から確かめる、という項目があり、そこに取り入れた考え方が問われた。解答例は「企画・設計工程からセキュリティ対策を組み込むという考え方」で、セキュリティ・バイ・デザインのこと。問題文の前提には、要件定義の段階での脅威モデリングも示されていた

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

• 「セキュリティ・バイ・デザインとは、稼働の直前に脆弱性診断を行うことである」→ 誤り。企画・設計の段階から対策を組み込むこと

• 「プライバシー・バイ・デザインでは、まず多くの情報を集め、後から保護する」→ 誤り。必要な情報だけを集め、初期設定で保護する

• 「ログイン済みであることを確かめれば、他人の申請を見せない対策になる」→ 誤り。それは認証。対象を見てよいかの認可が要る

• 「画面で他人の申請を選べなければ、認可の要件は満たしている」→ 誤り。直接のAPIの要求もサーバ側で確かめる

• 「セキュリティは非機能要件なので、機能として実装するものはない」→ 誤り。認証、権限の制御、ログの出力などの機能が要る

• 「非機能要求グレードでは、すべての項目で最高の水準を選ぶ」→ 誤り。業務に合う水準を、発注者と開発者で合意する

• 「仕様書に『適切に対策すること』と書けば、受入れの判断ができる」→ 誤り。対象、条件、結果、確かめ方を書く

• 「要件定義でいうトレーサビリティとは、ログで操作を追跡できることである」→ 誤り。根拠・要求・設計・確認の結果の対応をたどれること。ログで操作を後から追えることとは別の概念

• 「脅威分析は、攻撃者による脅威だけを対象にする」→ 誤り。誤操作、連携先の障害、更新の失敗も考える

• 「STRIDEの否認（Repudiation）への対策は、暗号化である」→ 誤り。操作を後から証明できるログ（否認防止）

• 「ISO/IEC 25010は、ISMSの要求事項の規格である」→ 誤り。システムとソフトウェアの製品の品質モデル。セキュリティはその品質特性の一つ

理解度チェック

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

問1　要件の書き方

申請システムの仕様書の要件として、受入れのときに判断しやすいものはどれか。

• ア：個人情報の保護に十分配慮すること

• イ：最新のセキュリティ技術を用いること

• ウ：申請情報の取得の要求ごとに、利用者と対象の申請の対応をサーバ側で確かめ、権限の外の要求を拒否すること。他人の申請番号を指定した要求が拒否されることを試験で示すこと

• エ：国の基準に準拠すること

正解：ウ。対象、条件、求める結果、確かめ方が書かれています。ア、イ、エは、何を満たせば要件を満たしたことになるかが分かりません。

問2　認証と認可

ログインした申請者が、URLの申請番号を書き換えると他人の資料を取得できた。必要な要件として、最も適切なものはどれか。

• ア：パスワードを長くする

• イ：申請番号を推測しにくい値にするだけでよい

• ウ：取得の要求ごとに、その利用者が対象の申請を見てよいかをサーバ側で確かめる

• エ：画面のメニューから他人の申請を選べないようにする

正解：ウ。問題は認可の欠落です。アは認証の強化で、イは推測を難しくするだけで認可の代わりになりません。エは画面の操作だけで、直接の要求を防げません。

問3　セキュリティ・バイ・デザイン

セキュリティ・バイ・デザインの説明として、最も適切なものはどれか。

• ア：運用を始めた後に、見つかった脆弱性を修正する考え方

• イ：企画・設計の段階からセキュリティ対策を組み込み、開発・試験・運用でも確かめ続ける考え方

• ウ：セキュリティ製品を設計の最後に追加する考え方

• エ：設計書を作らずに開発を進める考え方

正解：イ。アは事後の対応、ウは後付けの対策です。エは設計の段階で確かめる機会をなくします。

問4　プライバシー・バイ・デザイン

給付金の申請の画面で、審査に使わない勤務先の情報も「将来使うかもしれない」として必須の項目にする案が出た。プライバシー・バイ・デザインの考え方に沿った対応はどれか。

• ア：暗号化して保存すれば、集めてよい

• イ：審査に必要かを確かめ、必要でなければ集めない

• ウ：本人の同意欄があれば、どの項目でも集めてよい

• エ：集めた後で、使わない項目を年に一度削除すればよい

正解：イ。必要な情報だけを集めることが出発点です。アの暗号化は、不要な収集を正当化しません。ウの同意欄だけで、利用目的の適法性が満たされるわけではありません。エは、不要な情報を一度は集めています。

実務と国・自治体では

• 政府機関等の統一基準：業務や扱う情報の格付けなどを考えて、セキュリティ要件を策定することを求めている。主体認証、アクセス制御、権限の管理、ログの管理、暗号化などの機能のほか、運用時の監視、可用性、ネットワークの構成にも及ぶ。政府機関等向けの基準なので、自治体や企業の直接の義務として読み替えない

• 自治体向けガイドライン：総務省のガイドラインの例文は、調達の仕様書に必要な技術的なセキュリティ機能を明記することと、導入のときに試験と受入れの確認を行うことを扱っている

• デジタル庁のDS-200：政府情報システムのセキュリティ・バイ・デザインについて、企画から運用までの対策と関係者の役割を示す参考資料

• 実務の注意：「国の基準に準拠」と書くだけでは、どの画面の権限をどう確かめるかは決まらない。要求ごとに根拠、対象、達成の条件、確認の方法、担当を並べ、決まっていない項目に期限を付ける

まとめ

• ニーズと制約から脅威を分析し、要求の理由を示す。 制約は対策を省く口実ではない。

• 要件は、目的・対象・条件・結果・証拠・担当を一組にして、試せる文章にする。

• 認証と認可を分け、画面だけでなく直接の要求も確かめる。

• セキュリティ・バイ・デザインは企画・設計から組み込むこと。 プライバシー・バイ・デザインは必要な情報だけを集め、初期設定で守ること。

さらに深く学ぶなら

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

• 脅威モデリングを軸に、セキュアな設計の原則を学べる

• 設計の工夫で脆弱性を生みにくくする考え方（ドメイン駆動設計寄り）

関連記事

• 前提：そのリスク対応をなぜ優先するのか？｜支援士解説1の2（リスクの評価）

• 次に読む：その製品、安全に使えますか？｜支援士解説2の2（要求から製品・サービスの選定へ）

• あわせて読む：安全な機器も、つなぎ方で守りは変わる｜支援士解説2の3（構成の設計）

• あわせて読む：ログインできれば、安全なのか｜支援士解説2の4（認証と認可の実装）

2026年10月改訂：午前IIで問われる設計の考え方と品質の規格、要件を試せる文章にする書き方に絞って構成を見直しました。