はじめに
セキュリティ要件を検討するとき、暗号化する、MFAを導入する、アクセス経路を制限する、ログを取得するといった、具体的な対策から考え始めてしまうことがあります。
もちろん、これらは重要なセキュリティ対策です。しかし、対策そのものを先に並べても、
なぜ、この対策が必要なのか
どこまで対策する必要があるのか
なぜ、この対策は実施しないのか
までは決まりません。
同じ「個人情報を扱うシステム」でも、インターネットへ公開するシステムと閉域網だけで利用するシステムでは、想定する攻撃経路が異なります。24時間停止できない基幹システムと、数時間停止しても業務影響が小さい情報提供サイトでは、可用性に対する要求も変わります。
暗号化やMFAといった対策が一般的に有効だからといって、すべてのシステムに同じ方式・同じ水準で実装すればよいわけではありません。
必要なのは、最初に、
何を守るのか
何が起こり得るのか
その結果、どの程度の影響があるのか
を明らかにすることです。
その中心になるのが、リスクアセスメントです。
本記事では、セキュリティ全体の評価・確認を広く「セキュリティアセスメント」と呼び、その中核となるリスクアセスメントを、脅威・脆弱性・影響からリスクを分析・評価するプロセスとして扱います。
具体的には、次の4ステップでセキュリティ要件を導きます。
図 セキュリティ要件を導く4ステップ
- 脅威を分析する
- 脆弱性・設定不備・統制不足を分析する
- リスクを分析・評価する
- リスク対応を決め、必要な対策へ落とす
このうち、STEP1〜3がリスクアセスメントです。STEP4では、その評価結果をもとにリスクを低減・回避・移転・保有のどれで扱うかを決め、必要なセキュリティ対策へ落とします。
リスクアセスメント
→ リスク対応
→ セキュリティ要件
という順序です。
4ステップに入る前には、何を評価対象にするのか、誰がどのセキュリティコントロールを担うのかを明確にするため、対象範囲と責任分界を整理します。要件を決めたあとも、構成変更や新しい脅威に応じてリスクを見直します。
ここで「セキュリティ要件定義」の位置づけを確認しておく必要があります。
本記事では、RFPや提案書、見積前提、顧客のセキュリティ標準、業界基準など、一定の上位要求が既にインプットとして存在することを前提としています。
ただし、これらの要求は、そのまま実装できる粒度まで具体化されているとは限りません。「強固な認証を行う」「通信を暗号化する」「災害時の業務継続を検討する」といった要求を、対象システムの構成やリスクに合わせて具体化する必要があります。
本記事で扱うのは、こうした上位要求を入力として、リスクアセスメントを行い、個々のセキュリティ要件、責任分界、上位基準との差異、残存リスクまで具体化していく工程です。
RFP・上位要求
→ 提案段階で主要な実現可能性を検討
→ 要件定義で要求・差異・責任分界を具体化
→ 基本設計以降で実装方式を具体化
という流れを前提に、以降の説明を進めます。
要件定義と設計の役割も分けて考えます。
要件定義で決めるのは「どのリスクに、どこまで対応するか」です。基本設計以降では、その要求をどの方式で実現するかを具体化します。
具体的な対策を先に選ぶのではなく、リスクアセスメントによってリスクを明らかにし、その結果から必要な対策を導く。
これが、本記事で説明するセキュリティ要件定義の基本です。
要件定義全体の位置づけや、RFP・提案内容・見積前提との関係は、次の記事で整理しています。
4ステップの前に、セキュリティ対策の範囲と責任分界を決める
リスクアセスメントを始める前に、まずセキュリティ対策の対象範囲と責任分界を整理します。
どこまでを評価対象にするのか、誰がどのセキュリティコントロールを担うのかが曖昧なままだと、その後に脅威や脆弱性を洗い出しても検討漏れが生じます。
これは、後述するリスクアセスメントの前提条件を決める作業です。その前提を整理したうえで、「何を守るのか」「何から守るのか」を明確にしていきます。
システム構成を俯瞰して対象を決める
Webシステムであれば、アプリケーションやサーバだけが対象ではありません。
利用端末、運用管理端末、ネットワーク、外部接続先、認証基盤、バックアップ、CI/CD、SaaSなど、対象システムに関係する構成要素を確認します。業務上重要な情報を紙で扱うのであれば、それも情報資産として評価対象になり得ます。
要件定義の段階では、詳細な物理構成図まで作る必要はありません。
主要な構成要素と接続関係、信頼境界、外部との接点が分かる程度の概念図を用意し、まだ決まっていない部分は想定であることを明記します。
図 主要な構成要素、接続関係、信頼境界、外部との接点を示したWebシステム構成例
この図のように、利用者からWeb/AP、DB、バックアップ、外部接続先までの経路だけでなく、運用管理端末からの管理経路も見えるようにしておくと、後の脅威分析で「どこから、どこへ到達できるのか」を考えやすくなります。
早い段階で実装方式まで固定しすぎると、後続の設計自由度を狭めます。
要件定義では、リスクを判断するために必要な粒度まで構成を見えるようにすることが目的です。
クラウドでは「誰が構築するか」より「どの層で、誰がコントロールするか」を見る
クラウドでは、マネージドサービスだから利用者側のセキュリティ検討対象外、とは考えられません。
クラウド事業者が物理設備やサービス基盤を管理していても、IAM権限、データ、ネットワーク公開範囲、暗号化設定、ログ、アプリケーションなどは利用者側に残ることがあります。
確認したいのは、
このサービスを誰が作るのか
だけではなく、
このリスクを、どの層で、誰がコントロールするのか
です。
例えば、外部からの攻撃を共通のCDNやWAF、ネットワーク基盤で十分に防御できるのであれば、同じ対策を個別システムごとに重複して実装する必要はありません。反対に、共通基盤では実現できない、あるいは構成上利用できない対策については、個別システム側で代替コントロールを検討します。
複数ベンダや共通基盤が関係する案件では、この責任分界が特に重要です。
端末は別ベンダ、ネットワークは共通基盤、アプリケーションは自チームという構成なら、セキュリティ要件ごとに実施主体が変わります。
責任分界が曖昧なままだと、
相手が対応すると思っていた
という「責任の空白」が生まれます。
アセスメントの開始時点で大まかな責任範囲を整理し、個々の対策を検討するときにも、必要に応じて担当主体を残しておきます。
リスクアセスメントで理解しておく「資産・脅威・脆弱性・リスク」
対象範囲と責任分界を整理したら、リスクアセスメントで使う基本用語を確認します。
守る対象は機密性だけではない
情報セキュリティでは、機密性（Confidentiality）、完全性（Integrity）、可用性（Availability）の3つを基本的な観点として扱います。この3つは、それぞれの英語の頭文字を取ってCIAと呼ばれます。
これは、情報を守るには「漏れないこと」だけでは不十分だからです。 情報や処理結果が正しく保たれ、必要なときに利用できることまで含めて考える必要があります。
- 機密性：許可されていない人に情報を見せない
- 完全性：情報や処理結果を不正に変更・破壊されない
- 可用性：必要なときにシステムや情報を利用できる
例えば、情報が外部へ漏れていなくても、不正に書き換えられていれば安全とはいえません。内容が正しくても、攻撃や障害によって必要なときに利用できなければ、業務を継続できません。
リスクアセスメントでは、この3つのうち何が失われるのかを見ながら、脅威と影響を整理します。
個人情報の漏洩は機密性の問題です。データの不正書き換えは完全性、DoS攻撃によるサービス停止は可用性に関係します。
災害や設備破壊も、可用性設計だけの話とは限りません。悪意ある破壊行為によってサービスを停止させるケースを含めれば、セキュリティの観点でも評価対象になります。
可用性とセキュリティを別々の非機能要求として整理する場合でも、実際のリスクは重なります。分類の境界より、どの事象によって何が失われるのかを見る方が重要です。
脅威と脆弱性を混同しない
脅威は、情報資産へ悪影響を与える可能性がある事象や主体です。
例えば、不正アクセス、マルウェア、内部不正、DoS攻撃、災害、機器の破壊などが該当します。
脆弱性は、脅威に利用される可能性のあるシステム・設定・運用上の弱点です。
「機密性が低いこと」が脆弱性なのではありません。
例えば、
外部の攻撃者が管理画面へ不正アクセスする
という脅威に対して、
MFAが設定されていない
管理画面がインターネットから直接到達可能
管理者権限が過大
といった状態は、攻撃を成立させやすくする脆弱性・統制不足です。
ここでいう脆弱性は、ソフトウェアそのものの欠陥だけを指すわけではありません。
ソフトウェアの脆弱性には、CVE（Common Vulnerabilities and Exposures）という共通の識別番号が付与されて公表されるものがあります。CVEは脆弱性そのものの重大度を表す点数ではなく、既知の脆弱性を識別するための番号です。深刻度の評価には、0.0〜10.0で表すCVSSなどが使われます。
セキュリティアセスメントでは、
既知のソフトウェア脆弱性
＋設定不備
＋管理・運用上の統制不足
まで見ます。
リスクは「脅威＋弱点＋影響」で考える
脅威や脆弱性を単独で並べても、対策の優先順位は決まりません。
例えば、管理画面にMFAがないという弱点があったとしても、その管理画面が外部から到達できるのか、どの情報へアクセスできるのか、侵害されたときにどの程度の影響が出るのかによってリスクは変わります。
実務では、
誰が、どこから、どの弱点を利用して、何を起こし、業務や情報資産にどのような影響を与えるのか
というシナリオとして整理すると、対策へつなげやすくなります。
図 脅威からリスク対応までの評価フローイメージ
同じ脅威でも、実際に起きたときの影響によってリスクは変わります。
例えば、インターネット上ですでに公開している情報が第三者に閲覧されても、機密性の観点では大きな損失にはつながりません。反対に、顧客の個人情報や認証情報が漏洩すれば、顧客への被害、法令対応、信用低下など大きな影響が生じる可能性があります。
重要なのは、情報が重要そうだから一律に強い対策をするのではなく、その情報が漏れた、改ざんされた、利用できなくなったときに何が起こるのかを考えることです。
リスクの大きさは、発生可能性と影響度の2軸などを使って評価します。評価尺度や判定基準は組織やプロジェクトによって異なります。
対策を実施してもリスクが完全にゼロになるとは限りません。この「対策後にも残るリスク」が残存リスクです。残存リスクについては後半で具体例とともに説明します。
具体的な評価方法はSTEP3で説明します。
セキュリティアセスメントはどこまでやればよいのか
すべてのシステムに、同じ深さのアセスメントを行う必要はありません。
アセスメントの深さは、システム規模だけでなく、扱う情報の重要度、外部公開の有無、停止が許容できる時間、特権IDの有無、外部システムとの接続、法令・業界基準などによって変わります。
例えば、社内向けの小規模な情報提供システムと、顧客の個人情報を扱い24時間稼働する外部公開システムでは、求められるアセスメントの深さは異なります。
後者では、構成要素や接続経路を細かく分け、管理経路や可用性、バックアップ、特権権限まで含めて評価する必要があります。前者では、重要な資産と主要な攻撃経路に絞って評価する方が現実的な場合もあります。
アセスメントそのものにも、品質、時間、コストのバランスがあります。重要なのは、すべてを同じ粒度で調べることではなく、そのシステムで大きな影響につながるリスクを見落とさない粒度を選ぶことです。
このあと例にするのは、顧客情報を保持し、インターネットへ公開するWebシステムです。小規模な社内ツールよりも、外部からの攻撃経路、内部者の権限、データ保護、復旧などを広く見る必要があるケースとして扱います。
ゼロから項目を考えない
実務では、白紙から脅威や対策を洗い出すより、組織内で実績のあるアセスメントシートや公的なガイドラインをベースラインとして使う方が効率的です。
ただし、過去のシートをそのままコピーして終わりにはしません。
クラウド管理プレーン、SaaS、API、CI/CD、サプライチェーンなど、対象システム固有の構成や現在の脅威に合わせて観点を追加します。
実績のあるシートを再利用する価値は、対策例が並んでいることだけではありません。
「どの構成要素に対して、どの脅威を見るのか」という分析軸を再利用できることに大きな価値があります。
対策には技術的対策だけでなく、物理的対策、組織的な統制、運用手順、教育などもあります。すべてをシステム機能で解決しようとせず、リスクに対して適切な手段を組み合わせます。
セキュリティ対策を導く4ステップ
セキュリティ対策の範囲と責任分界を決め、アセスメントの深さを決めたら、具体的なリスクアセスメントへ進みます。
中心となるのは、はじめにで述べた次の4ステップです。
（再掲）図 セキュリティ要件を導く4ステップ
- 脅威を分析する
- 脆弱性・設定不備・統制不足を分析する
- リスクを分析・評価する
- リスク対応を決め、必要な対策へ落とす
ここで重要なのは、最初からWAF、MFA、暗号化といった対策を並べないことです。
まず何が起こり得るのかを考え、その事象を成立させる弱点を確認し、発生した場合のリスクを評価します。その結果として必要な対策を決めます。
対策からリスクを考えるのではなく、リスクから対策を導く。
これが4ステップをこの順番で行う理由です。
以降では、顧客情報を保持する外部公開Webシステムを一つの例として、4ステップを順番に追っていきます。
（再掲）図 主要な構成要素、接続関係、信頼境界、外部との接点を示したWebシステム構成例
この図を、以降のSTEP1〜4で共通して使います。利用者からの通常経路だけでなく、運用管理端末からの管理経路、バックアップ、外部接続先までをアセスメント対象として見ます。
STEP1 脅威を分析する
最初に、対象となる資産やシステムに対して、どのような脅威が存在するのかを洗い出します。
今回のWebシステムで守るべき重要な資産の一つは顧客情報です。
ここで、
不正アクセス
とだけ書いても、何を設計すればよいのか分かりません。
もう少し具体化して、
外部の攻撃者がWebシステムへ侵入し、顧客情報を参照・持ち出す
という攻撃シナリオとして考えます。
外部からの攻撃だけではありません。
正規の権限を持つ内部者についても、
内部者が運用管理端末から必要以上の権限を利用し、顧客情報を取得する
というシナリオが成立する可能性があります。
同じ「情報流出」でも、外部攻撃者による侵入と、内部者による不正利用では攻撃経路が異なるため、必要な対策も変わります。
構成要素 × 脅威で検討漏れを減らす
脅威を網羅的に考えるために、実務で有効なのが構成要素と脅威を掛け合わせる方法です。
私が実際に利用していたアセスメントでも、脅威だけを一覧にするのではなく、サーバ、利用端末、運用管理端末、ネットワークなどの構成要素ごとに確認していました。
例えば、次のように考えます。
| 構成要素 | 不正アクセスのシナリオ | 情報流出のシナリオ |
|---|---|---|
| Web／AP | 管理機能への不正ログイン | アプリケーション経由での顧客情報取得 |
| DB | DB管理権限の不正利用 | DBデータの持ち出し |
| 利用端末 | 他利用者の権限を使った操作 | ダウンロードしたファイルの持ち出し |
| 運用管理端末 | 特権IDの不正利用 | 管理作業を利用した情報取得 |
| ネットワーク | 不正端末からの接続 | 通信の盗聴 |
この表は、対策の要否を判定する表ではありません。
「この構成要素について、この脅威を検討したか」を確認するための分析軸です。
例えばサーバ上の情報流出だけを考えていると、正規の操作で利用端末へダウンロードされたデータが持ち出されるシナリオを見落とす可能性があります。
実績のあるアセスメントシートを使う価値も、対策例が大量に書かれていることだけではありません。
どの構成要素に対して、どの種類の脅威を見るのかという分析軸が既に整理されていることに価値があります。
外部者だけでなく内部者・第三者も見る
不正アクセスや情報流出では、外部攻撃者だけを想定すると検討が偏ります。
今回のWebシステムでも、
外部攻撃者がインターネット経由で侵入する
シナリオだけでなく、
正規権限を持つ内部者が、その権限を不正に利用する
シナリオを見る必要があります。
外部攻撃を防ぐネットワーク制御は、正規の経路からアクセスする内部者には効かない場合があります。
また、情報漏洩は悪意のある内部者だけが原因になるわけではありません。誤送付、誤操作、端末や書類の持ち出しなど、人的・運用上のミスからも発生します。
令和7年度（2025年度）個人情報保護委員会年次報告では、行政機関等の漏えい等事案の発生原因について、誤交付、誤送付、誤廃棄、紛失といったヒューマンエラーが、国の行政機関等で54.8％、地方公共団体等で69.0％を占めています。
さらに、社員だけでなく、運用委託先や外部サービス事業者など正規の権限を持つ第三者、関係者を装って施設へ入り込む人物、利用者をだまして認証情報を取得するソーシャルエンジニアリングも考える必要があります。
セキュリティ対策は、ファイアウォールや認証といったシステム上の対策だけでは完結しません。入退室管理、権限付与・剥奪、操作記録、教育、承認手続きなど、人と運用を含めて考えます。
STEP1の目的は、脅威名を数多く挙げることではありません。
誰が、どこから、どの資産に、どのような影響を与える可能性があるのかをシナリオとして整理することです。
STEP2 脆弱性・設定不備・統制不足を分析する
次に、STEP1で整理したシナリオを成立させる弱点を確認します。
今回の、
外部攻撃者がWebシステムへ侵入し、顧客情報を取得する
というシナリオを考えてみます。
例えば、
- 管理機能へインターネットから到達できる
- MFAが設定されていない
- 一つの管理者IDに必要以上の権限がある
といった状態があれば、攻撃シナリオを成立させやすくなります。
内部者による情報持ち出しであれば、
- 運用管理者に必要以上の参照権限がある
- 操作ログを取得していない
- 重要な操作を後から追跡できない
といった統制不足が問題になります。
ここでいう「脆弱性」は、ソフトウェアそのものの欠陥だけを意味しません。
先ほど説明したように、既知のソフトウェア脆弱性にはCVEという識別番号が付くものがあります。実務では、それらの既知脆弱性に加えて、
ソフトウェアの脆弱性
＋設定不備
＋管理・運用上の統制不足
まで見ます。
例えばソフトウェア脆弱性についても、CVSSが高いから機械的にパッチを当てるのではなく、対象システムでその脆弱性が実際に悪用可能か、対象機能を利用しているか、外部から到達できるか、既存の対策があるかまで確認してリスクを評価します。
機能が存在しているだけでは十分ではない
例えば操作ログを取得する機能があっても、必要な操作が記録されていなければ意味がありません。
ログを取得していても、異常を検知する必要があるのに誰も確認していなければ、早期発見には使えません。
アクセス権を適切に設定していても、異動や退職に伴う権限の棚卸しが行われなければ、時間の経過とともに不要な権限が残ります。
セキュリティ対策では、
機能があるか
だけでなく、
その機能によって必要な統制が実際に成立しているか
まで確認します。
クラウドでは設定不備の観点が増える
クラウドでは、クラウド事業者が基盤を管理していても、利用者が設定するセキュリティ項目は数多く残っています。
今回のWebシステムをAWS上に構築するなら、IAMの権限、ネットワーク公開範囲、暗号化、ログ取得などは利用者側の設計対象になります。
クラウドサービス自体にソフトウェア脆弱性がなくても、利用者側の設定によって攻撃経路が作られる可能性があります。
代表的なのがIAMなどの権限設定です。「最小権限にする」だけではなく、誰に（Principal）、どの操作を（Action）、どのリソースまで（Resource）、どの条件で（Condition）許可しているのかを確認します。さらに、ロールを引き受けられる主体、認証情報の扱い、重要操作のログまで含めて見ます。
権限が過大であれば、一つの認証情報や実行環境が侵害されたときに、攻撃者が到達できる範囲も広がります。
オンプレミス向けの古いアセスメントシートをそのまま流用すると、OSやネットワーク機器は細かく確認しているのに、IAMやクラウド管理コンソールのような管理プレーン側の観点が抜けることがあります。
実績のあるシートはベースラインとして使いながら、対象システムの構成に合わせて更新する必要があります。
STEP3 リスクを分析・評価する
ここまでで、今回のシナリオは次のように整理できます。
資産：顧客情報
脅威：外部攻撃者による不正アクセス
脆弱性・統制不足：管理機能へ外部から到達可能、MFA未設定、権限過大
想定される事象：管理者権限を不正利用され、顧客情報が取得される
リスク：顧客情報の漏洩
ここから、そのリスクがどの程度重要なのかを評価します。
基本となるのが、発生可能性と影響度です。
| 想定リスク | 発生可能性 | 影響度 | リスク評価 |
|---|---|---|---|
| 管理機能への侵入による顧客情報の大量漏洩 | 中 | 高 | 高 |
| リージョン障害によるサービスの長期停止 | 低 | 高 | 中※ |
| 公開情報ページの短時間停止 | 中 | 低 | 低 |
※発生可能性と影響度からリスク評価を決める基準は、組織やプロジェクトによって異なります。
この表で重要なのは、High／Middle／Lowという文字そのものではありません。
なぜその評価になったのかを説明できることです。
現行対策を考慮して評価する
次に、STEP1で挙げたもう一つのシナリオである、内部者による顧客情報の持ち出しを考えてみます。
仮に運用管理端末が自由に利用できるのであれば、発生可能性は高く評価されるかもしれません。
しかし、
- 運用管理端末が限定されている
- 利用者が限定されている
- 操作記録を取得している
といった現行対策が既に存在するのであれば、その効果を考慮します。
ここを無視すると、アセスメントシート上では常に最悪条件でリスクを評価することになり、必要以上の対策を導きやすくなります。
反対に、
対策があるから安全
と評価するだけでも不十分です。
その対策によって、
発生可能性がどこまで下がったのか
発生した場合の影響は変わるのか
まだ何が残っているのか
を見る必要があります。
発生可能性が低く、影響度が大きいリスク
実務で判断が難しいのが、
発生可能性は低いが、発生すれば影響が非常に大きい
リスクです。
例えばリージョン全体の長期停止や、バックアップを含むデータの完全喪失などです。
この場合、
発生可能性が低いから対策しない
とも、
影響が甚大だから最大限の対策を必ず行う
とも機械的には決められません。
ただし、対策水準をゼロから自由に決めるわけではありません。まず、RFPや適用基準、顧客標準などの上位要求を確認します。
そのうえで、上位要求だけでは決まらない部分について、システムの重要度、復旧可能性、既存対策、追加対策によって得られるリスク低減効果や費用を踏まえて判断します。上位要求どおりに実現できない場合は、その差異によって何ができなくなり、どのリスクが残るのかまで評価します。
STEP4では、こうした評価結果をもとに、そのリスクを低減・回避・移転・保有のどれで扱うかを決めます。リージョン障害のような可用性リスクについては、後述する残存リスクの節で具体例を示します。
STEP4 リスク対応を決め、セキュリティ対策へ落とす
リスクを評価したら、そのリスクをどのように扱うかを決めます。
代表的なリスク対応は、低減、回避、移転、保有の4種類です。
低減
セキュリティ対策を実施し、リスクの発生可能性や影響度を小さくします。
今回の、
外部から管理機能へ侵入され、顧客情報を取得される
というリスクであれば、アクセス経路の限定、MFA、最小権限化、操作ログ取得などが候補になります。
回避
リスクを発生させる活動自体をやめます。
例えば、インターネット公開によるリスクが許容できないため、サービスをインターネットへ公開しないという判断です。
インターネット公開を続けながらWAFなどを利用するのであれば、リスクそのものは残るため「低減」です。
移転
契約や保険などによって、リスクによる金銭的な影響の一部を第三者へ移します。
ただし、保険へ加入したり外部事業者を利用したりしても、事故発生時の顧客や監督機関への説明責任まで移転できるわけではありません。
クラウドサービスを利用する場合も、単純に「クラウド事業者へリスクを移転した」と考えるのではなく、事業者が担う範囲と利用者に残る範囲を責任分界に沿って切り分けます。
基盤設備の管理などクラウド事業者が担うリスクもあれば、IAM、データ、アプリケーション、利用者側の設定など、利用者に残るリスクもあります。
保有
リスクが残ることを理解したうえで、追加対策を行わず受け入れます。
これは、
対策し忘れた
こととは全く異なります。
リスクを認識し、既存対策、発生可能性、影響度、追加対策による効果や費用を評価したうえで、
この水準の残存リスクなら許容する
と判断することです。
例えば、DMZに配置したWebサーバが一般に公開されている情報だけを提供し、機密情報を保持せず、内部システムへの接続経路も持たないとします。さらに、侵害された場合でも初期状態から再構築できるようにしていれば、情報漏洩や内部システムへの横展開による影響は限定できます。
それでも、Webページの改ざんや一時的なサービス停止といったリスクは残ります。追加対策によるリスク低減効果と構築・運用コストを比較した結果、そこまでの対策は行わず、この残存リスクを保有する判断もあり得ます。
リスクを保有するとは、「侵害されても構わない」と考えることではありません。侵害された場合の影響を把握し、既存対策で影響を限定したうえで、追加対策までは行わないと判断することです。
この判断は技術者だけで完結させず、残るリスクを前提にどの方式で進めるのかを関係者で確認します。
リスク対応を決めて、初めて具体的な対策を選ぶ
ここが4ステップの最終地点です。
今回のWebシステムについて、
顧客情報漏洩のリスクを「低減」する
と決めただけでは、まだ設計は終わっていません。
次に、
どのリスクを
どのコントロールによって
どこまで下げるのか
を決めます。
例えば、
- 管理機能へのアクセス経路を限定する
- 管理者認証にMFAを要求する
- 管理者権限を必要最小限にする
- 重要操作を記録・監視する
といったセキュリティ要件が導かれます。
AWSを利用するのであれば、ここで初めてIAMやSecurity Groupなどの具体的なサービスや機能が実装候補として登場します。
順番は、
AWSにこの機能がある
↓
使っておこう
ではありません。
リスクを評価する
↓
リスク対応を決める
↓
必要なセキュリティコントロールを決める
↓
それを実現する方式・サービスを選ぶ
です。
AWSやサードパーティが提供する機能は、セキュリティ対策を実現するための手段です。機能を使うこと自体が目的ではありません。
同じリスクでも、AWSネイティブの機能、サードパーティ製品、共通ネットワーク側の対策、運用統制など、複数の実現方式があります。重要なのは製品名ではなく、必要なセキュリティコントロールを満たし、責任分界や運用まで含めて成立することです。
セキュリティ製品やクラウドサービスは、リスクアセスメントの出発点ではなく、設計判断の結果として選ばれるものです。
上位基準がある案件では「差異」をリスクとして評価する
本記事で想定する案件では、法令や業界基準、組織のセキュリティ標準、顧客の標準仕様、上位システムの要求など、既に一定の上位基準が与えられています。
ただし、これらはすべて同じ扱いではありません。法令や契約上の義務は、リスクが低いという理由だけで不適用にはできません。 業界基準、顧客標準、組織内部の標準についても、差異を認める場合には、正式な例外承認や関係者との合意が必要になることがあります。
まず、その要求が何を根拠としているのか、変更や例外が認められるのか、認められる場合にはどの手続きが必要なのかを確認します。
そのうえで重要なのが、上位基準があるからといって、対象システムのリスクアセスメントが不要になるわけではないという点です。
まず、
このシステムには、どのような脅威・脆弱性・リスクがあるのか
を評価します。
次に、上位基準が要求する対策と、本システムで採用する実現方式が異なる場合には、
その差異によって、新たなリスクが生じないか、既存のリスクが増加しないか
を評価します。
考え方は、
対象システムのリスクアセスメント
＋
上位基準との差異評価
です。
上位基準を単純に「準拠／非準拠」で確認するのではなく、対象システム固有のリスクを評価したうえで、基準との差異がリスクにどのような影響を与えるのかまで確認することが重要です。
○×チェックするだけでは、この差異によるリスク評価が抜けてしまいます。
差異は7段階で評価する
上位基準で要求されている方式を、そのまま採用できないことがあります。
端末を複数システムで共用している、認証基盤を共通化している、ネットワークや端末を別の組織・ベンダが管理している、既存システムとの接続方式を変更できない、といった制約があるからです。
私が実際の案件で使っていたシートでも、単純な「準拠／非準拠」だけではなく、上位基準との差異の有無と、その差異に対する評価を別に管理していました。
評価の流れを図にすると、次のようになります。
図 上位基準と本システムの差異を評価する流れ
この形にすると、「基準と違う」という事実を、セキュリティ要件定義上の判断へ変換できます。
RFPの「検討する」という要求も、実現可能性を評価して結論を出す
RFPでは、実現方式や実現可能性が確定していない要求について、
監査ログの長期保管を検討する
のように、「実現すること」ではなく「検討すること」と記載される場合があります。
この場合、提案段階で複数案を比較し、要件定義で実施範囲を確定します。例えば、
- すべてのログを長期間オンラインで検索できる状態にする
- 直近分だけをオンラインで保持し、古いログは低コストの保管領域へ移す
- 認証や特権操作など、監査上重要なログだけを長期保管する
といった方式を比較できます。
保管期間を長くし、すべてのログを即時検索できるようにすれば調査性は高まりますが、保存容量、検索基盤、運用コストも増えます。逆に保管範囲を絞りすぎれば、インシデント発生時に必要な証跡が残っていない可能性があります。
そこで、法令・契約・上位基準で必須となる保存期間を確認したうえで、どのログを、どの期間、どの状態で保持すれば必要な調査・監査を成立させられるかを評価します。
検討の結果、例えば「認証・特権操作・重要データへのアクセスログは長期保管し、大量に出力されるデバッグログは短期間とする」といった結論にすることがあります。
これは「検討しなかった」のではありません。複数案の効果とコストを比較し、要求の目的を満たす範囲を要件として確定した、という提案・要件定義上の判断です。
同じ方式を採用できなくても、そこで検討を終わらせない
例えば、上位基準で、
ログの改ざんを即時に検知し、異常があれば通知する
という要求があったとします。
対象システムでも同じ仕組みを導入したいところですが、端末を他システムと共用しており、その端末は別の組織やベンダの管理下にあるとします。
上位基準と同じ改ざん検知を実現するには、端末側へのエージェント導入や設定変更が必要ですが、自システムの判断だけでは変更できません。
このような場合に、
上位基準と同じ方式を実現できないので非準拠
として終わらせてはいけません。
確認するのは、
同じ方式を採用できないことで、何のリスクが増えるのか
です。
この例なら、ログが改ざんされた場合の発見が遅れ、不正操作の追跡やインシデント発生時の原因究明が困難になる可能性があります。
そこで、
- 管理作業を行える経路や端末を限定する
- 管理者の操作を記録する
- 通常とは異なる時間帯などの操作を検知する
- インシデント発生後に操作内容を追跡できる状態にする
といった別のコントロールによって、増加するリスクをどこまで低減できるかを評価します。
ただし、代替コントロールを入れたからといって、上位基準との差異そのものが消えるわけではありません。
即時検知の範囲や検知精度などに違いが残るのであれば、それを残存リスクとして明確にします。
最終的には、
代替コントロールを実施したうえで、この残存リスクを許容できるか
を判断します。
「方式」ではなく、その対策が何を守ろうとしているのかを見る
上位基準には、具体的なセキュリティ方式まで指定されている場合があります。
例えば、
生体認証を使用する
という要求があるとします。
ここで確認したいのは、
生体認証を導入しているか
だけではありません。
なぜ生体認証を要求しているのかまで遡ります。
目的が、
本人以外による認証突破の可能性を下げる
ことであれば、本システムが既に共通認証基盤を経由し、利用端末やアクセス経路も限定されている場合、生体認証をさらに追加したときにどの程度の追加的なリスク低減効果が得られるのかを評価します。
追加効果が大きければ採用すべきでしょう。
既存の認証・端末・経路制御によって対象リスクが十分に低減されており、生体認証を加えてもリスク低減効果が限定的なのであれば、採用しないという判断もあり得ます。
ただし、
別の認証方式があるから同等だろう
と根拠なく判断することもできません。
比較するのは、認証方式の名称や機能数ではありません。
どの攻撃シナリオに対して、どの程度リスクを低減できるのかです。
上位基準があっても、STEP1〜4で説明してきたリスクアセスメントの考え方は変わりません。
「準拠している」と書くことの方が危険な場合がある
上位基準と異なる方式を採用すること自体が、直ちに問題になるわけではありません。
システム構成や責任分界が異なれば、同じ対策をそのまま適用できないことはあります。
むしろ問題なのは、
実際には差異があるのに、その差を評価しないまま「上位基準に準拠している」と扱うこと
です。
差異を明確にしておけば、
なぜ同じ方式にできなかったのか
何のリスクが増えるのか
どの代替コントロールを採用したのか
それでも何が残るのか
その前提で、どの方式で進めると合意したのか
を説明できます。
差異を認識していなければ、その説明自体ができません。
セキュリティ標準への準拠とは、書かれている対策を機械的にコピーすることではありません。基準が求めるリスク低減の目的を理解し、本システムとの差異を評価したうえで、必要な対策と残存リスクを明確にすることが重要です。
また、ここで行った差異評価は永久に有効なものではありません。上位基準が改定されることもあれば、「端末を限定している」「操作を記録している」といった代替コントロールの前提が運用中に崩れることもあります。
差異評価は合意して終わりではなく、基準の改定と代替コントロールの実効性を継続的に確認する必要があります。
この点は、後述する継続的なリスクアセスメントでも改めて扱います。
2026年、AI・ゼロデイ時代にリスクアセスメントはどう変わるか
ここまで説明してきたリスクアセスメントの考え方は、AIが普及する以前から使われてきたものです。
では、AIによって脆弱性の発見や攻撃作業が高速化している2026年現在、セキュリティ要件定義や設計の考え方そのものを大きく変える必要があるのでしょうか。
結論は、基本的な原則は変わりません。
変化しているのは、
脆弱性を発見する速度、攻撃へ利用する速度、攻撃を並列化できる規模
です。
「侵入される可能性を前提に多層防御する」という考え方をAIが生み出したわけではありません。
ゼロデイ攻撃、ランサムウェア、サプライチェーン攻撃などを考えれば、以前から「既知の脆弱性をすべて修正すれば安全になる」という前提は成立していませんでした。
AIは、この前提をさらに厳しいものにしています。
AIが攻撃工程そのものを高速化する
2025年11月、Anthropicは「GTG-1002」と名付けたサイバースパイ活動について報告しました。
Anthropicによれば、攻撃者はClaude Codeを利用し、偵察、脆弱性探索、攻撃試行、認証情報の取得、データ分析など複数の工程をAIに実行させていました。同社は、攻撃作業の80〜90％をAIが実行し、人間は重要な判断に関与していたと分析しています。
ただし、これは「AIが人間なしで高度な攻撃を完結させた」という意味ではありません。Anthropic自身も、Claudeが誤った情報を返す場面があり、人間による検証が必要だったと報告しています。外部研究者からも、AIが従来にない攻撃手法そのものを発明したとまでは確認できないという慎重な見方が出ています。
ここで重要なのは「何％が自律だったか」ではありません。
AIが攻撃を完全に自律化したというより、人間が時間をかけて行っていた偵察、脆弱性探索、攻撃試行、結果分析などを高速化・省力化した点です。
人間の作業時間が制約になっていた工程を短時間で繰り返せるようになれば、従来より多くの対象を並行して探索できます。
脆弱性を「発見する側」でも速度が上がっている
AIによる変化は攻撃側だけではありません。
2026年2月、AnthropicはClaude Opus 4.6を利用したOSSの脆弱性調査で、500件を超える高深刻度の脆弱性を発見・検証したと報告しました。
主要なOSSの中には、異常な入力を大量に自動投入して不具合を探すファジングなどの自動検査を、長年継続して受けてきたものがあります。それでもAIを使った解析によって新たな脆弱性が発見されました。
重要なのは手法名そのものではなく、従来の自動検査とは異なる方法でもコードを調べられるようになり、脆弱性探索の速度と範囲が広がっていることです。
ここで「500件すべてがゼロデイだった」と読むべきではありません。
Anthropicは、報告前に各バグを検証し、初期の調査では自社のセキュリティ研究者が脆弱性を確認してパッチを作成し、件数が増えた後は外部の人間のセキュリティ研究者も検証とパッチ開発に加わったと説明しています。
AIが候補を大量に発見できても、内容の確認、修正、テスト、リリースには人間や開発チームの作業が残ります。
発見量が増えるほど、
発見する
↓
検証する
↓
修正する
↓
テストする
↓
本番へ適用する
という防御側の処理能力がボトルネックになります。
Anthropicも、従来の90日程度の脆弱性開示・修正サイクルが、LLMによる発見量と速度に対して維持しにくくなる可能性を指摘しています。
発見と公開の速度が上がるのであれば、緊急パッチの影響判断や適用までのリードタイムを、運用開始前に決めておく重要性も高まります。
CVSSの数値だけでなく、実際の悪用実績や自システムでの利用状況、攻撃経路、パッチ適用の影響などを踏まえて判断します。具体的な判断基準と意思決定プロセスは、後半の脆弱性管理で説明します。
未知の脆弱性はアセスメントシートに列挙できない
ここで、この記事のSTEP1が効いてきます。
未知の脆弱性を、
CVE-XXXX-XXXX
のようにアセスメントシートへ事前に書くことはできません。
しかし、未知の脆弱性が悪用された場合に、どのような攻撃経路が成立するかは考えることができます。
ここまで例として使ってきた顧客情報を保持するWebシステムなら、次のような攻撃経路を考えます。
図 侵入から情報持ち出しまでの攻撃経路と、各段階に配置する防御ポイント
最初の侵入を完全に防げなかった場合でも、攻撃経路の途中で止めることはできます。
侵入後に不要な管理権限まで取得されないよう最小権限化し、認証情報を取得されても権限昇格や横展開が容易に成立しないよう、通信経路や信頼関係を制限します。
DBへ到達する段階では、通信経路と権限の両方を絞ります。
例えば、Web/APとDBの間だけ必要な通信を許可するネットワークセグメントを設け、利用者側のネットワークからDBへ直接到達できないようにします。運用管理についても、管理用LANや踏み台などの管理経路からだけアクセスできる端末・サーバを分離します。
さらに、アプリケーションや管理者に与えるDB権限を必要最小限にし、不審なアクセスや重要操作を検知・記録します。DBの権限と監査ログについては、次の記事で具体例を紹介しています。
バックアップも、本番環境が侵害されたときに同じ権限や攻撃経路から破壊されないよう分離します。
攻撃シナリオの途中に複数の防御ポイントを置くことが、未知の脆弱性を前提にした設計につながります。
「侵入させない」だけではなく「侵入された後」まで設計する
セキュリティ対策というと、
攻撃をどう防ぐか
に目が向きやすくなります。
しかし未知の脆弱性を完全になくせないのであれば、予防だけでは設計が完結しません。
考える範囲を、
予防
↓
検知
↓
封じ込め
↓
復旧
まで広げます。
例えばWebサーバへの侵入そのものを防げなかったとしても、権限昇格を防ぎ、横展開を制限し、異常操作を検知し、影響範囲を特定して安全な状態へ戻せれば、最終的な事業影響を小さくできます。
この考え方自体は2026年になって突然登場したものではありません。NIST Cybersecurity Framework 2.0でも、サイバーセキュリティリスクへの対応をGovern、Identify、Protect、Detect、Respond、Recoverの6機能で整理し、ライフサイクル全体でリスクを管理する考え方を示しています。
AIによって変わったのは原則ではなく、各段階を攻撃者が通過する速度が上がる可能性です。
AI対応をうたう製品を追加する前に、まず攻撃シナリオのどの段階を止め、どこで検知し、どの状態まで復旧する必要があるのかを決めます。
AI Agentも同じです。AIだから特別な対策を足すのではなく、そのAgentがどの認証情報を使い、どのAPIを実行でき、どのリソースまで到達できるのかを確認し、必要な権限だけを与えます。AWS IAMでAI Agentへ与える権限の考え方は、次の記事で詳しく整理しています。
未知の脆弱性をすべて事前に把握できないからこそ、個々の脆弱性一覧だけではなく、資産・攻撃シナリオ・攻撃経路を基準にリスクを考える重要性が高まっています。
次に問題になるのが、どこまで対策し、何を残存リスクとして扱うのかです。
実施しない対策と残存リスクの扱いを決める
ここまで、脅威と脆弱性からリスクを評価し、そのリスクに応じて必要なセキュリティ対策を導く方法を説明してきました。
リスクアセスメントの結果として考えられる対策を、すべて実施するわけではありません。
対策を実施してもリスクを完全にゼロにできない場合があります。追加対策によって得られるリスク低減効果に対して、構築費や運用負荷が大きすぎる場合もあります。
最後に必要になるのが、
どこまで対策し、何を残存リスクとして扱うのか
という判断です。
これは、対策を考えることと同じくらい重要なセキュリティ要件定義です。
残存リスクは「対策しなかったリスク」だけではない
残存リスクという言葉は、
対策を実施しなかったために残ったリスク
という意味に捉えられがちですが、それだけではありません。
対策を実施しても、リスクが完全になくなるとは限りません。
例えば、管理画面へのアクセスを管理ネットワークに限定し、MFAを導入し、管理者権限を必要最小限にして、操作ログも記録したとします。
これによって外部からの不正アクセスや、認証情報を盗まれた場合のリスクは大きく下げられます。
しかし、DBAのように業務上強い権限を持つ管理者であれば、正規の権限を利用して意図的にデータを取得する可能性まで完全になくすことは困難です。
そこで、
- 特権IDの利用者や利用時間を限定する
- 重要操作を記録する
- 誰が、いつ、どのデータへアクセスしたのか追跡できるようにする
- 監査ログを管理対象のDBとは別の基盤へ転送する
- 必要に応じて承認手続きや操作監視を組み合わせる
といった統制を行います。
ログを取得していても、そのログを同じDBA権限で消せるのであれば、証跡として十分とはいえません。管理者自身が容易に改ざん・削除できない場所へ証跡を残すことも重要です。
それでも、正規権限を持つ内部者による不正利用の可能性がゼロになるわけではありません。
対策を実施したあとにも残っているリスクが、残存リスクです。
ここは、STEP4で説明した「保有」と区別しておきます。
「保有」はリスクへの対応方針です。残存リスクは、低減策を実施した場合にも存在します。
リスクを低減する
↓
対策後のリスクを再評価する
↓
それでも残るリスクを把握する
↓
そのリスクを前提に、どの方式・運用で進めるかを判断する
という流れになります。
ここまでは、主に情報漏洩や不正利用といった機密性に関する残存リスクを例にしてきました。
しかし、情報セキュリティは機密性・完全性・可用性（CIA）の3つで考えます。大規模障害や災害によって、必要なときにシステムを利用できなくなることも、可用性に関するセキュリティリスクです。
次に、CIAのうち可用性に関する残存リスクの例として、リージョン障害を考えます。
「バックアップがある」と「災害対策先で安全に業務継続できる」は違う
別リージョンへデータや復旧資材を保管していても、それだけで災害対策先から安全に業務を再開できるとは限りません。
DRでは可用性を回復することが目的になりますが、復旧先でも機密性や完全性を維持する必要があります。データを復旧できても、アクセス制御が効かず誰でも参照できる状態になったり、認証を省略しなければ利用できなかったりするのであれば、セキュリティ要件を満たした復旧とはいえません。
例えば、セカンダリリージョンにWeb/AP、DB、バックアップを用意できても、認証基盤がプライマリリージョンに依存している場合があります。
AWSでCognitoを認証基盤として利用しているケースなら、
セカンダリリージョンでWeb/APやDBは起動できる
↓
しかしログイン時の認証はプライマリリージョン側のCognitoに依存している
↓
プライマリリージョンが利用できなければ、正常な認証経路が成立しない
ということが起こり得ます。
この状態で、
認証を迂回してサービスだけ起動する
という対応をすれば可用性だけは回復できるかもしれませんが、今度は認証・認可が成立せず、機密性を損なうリスクが生じます。
DRで確認すべきなのは、
バックアップデータが存在するか
だけではなく、
認証、DNS、鍵管理、外部接続、アクセス制御などを含め、一連の業務経路がセキュリティを維持した状態で成立するか
です。
上位基準との差異があれば、残存リスクまで明確にする
前節で説明した差異評価も、最終的には同じところへ行き着きます。
上位基準と同じ方式を採用できなかった場合、
差異がある
と確認するだけでは不十分です。
差異によって増えるリスクを評価し、代替コントロールを実施したうえで、それでも何が残るのかを確認します。
例えば、上位基準と同じリアルタイムの検知方式を採用できず、別の監視や操作記録によってリスクを低減したとします。
代替コントロールによってリスクが下がっても、上位基準とまったく同じ検知能力になるとは限りません。
そこで、
代替コントロールを実施した結果、何のリスクがどの程度残るのか
まで明確にします。
ここまで整理して初めて、
この差異を前提に、この方式で進めてよいか
を判断できます。
「×」や「対象外」だけでは、設計判断を残したことにならない
セキュリティの確認表では、対策ごとに「○」「×」「対象外」と記録することがあります。
しかし、
対策A：×
だけでは、なぜ実施しなかったのか分かりません。
リスクを見落としていたのか。
追加対策による効果が小さいと判断したのか。
費用とのバランスを評価した結果なのか。
代替コントロールによって十分に低減できているのか。
その違いは、記号だけでは残りません。
「対象外」も同じです。
対象外は、本来、
このシステムでは当該リスクが成立しない
この構成要素には適用されない
別の組織やシステムが責任を持つ範囲である
など、評価した結果として適用対象から外したことを意味します。
対象外にしたことと、リスクを認識したうえで追加対策を実施せず保有したことは別の判断です。
どちらの場合も、後から判断を再現できるように理由を残します。
「実施しない」を技術者だけで決めない
残るリスクをどう扱うかは、セキュリティ担当者やシステム設計者だけで完結する判断ではありません。
例えば、DBAの不正利用リスクに対して、特権ID管理、二重承認、常時監視などを追加すれば、さらにリスクを下げられる可能性があります。
しかし、追加対策には費用と運用負荷が伴います。技術者は、
現在の対策でどこまでリスクが下がっているか
追加対策で何が改善するか
それでも何が残るか
を説明できます。
そのうえで、システムの重要性、業務影響、費用を踏まえ、残るリスクを前提にどの方式で進めるのかを、適切な責任者を含む関係者で決めます。
理想的には、残存リスクとその扱いを成果物に明示し、受容主体まで残せるのが分かりやすい形です。
ただし、実務では必ずしもそうならないことがあります。
実務Tips：残存リスクは、必ずしも「受容」と明記されるとは限らない
私の経験では、発注者側が「このリスクを受容する」という表現や、リスクが顕在化した場合の結果を成果物へ明記することを避けるケースがありました。特に大規模案件や公共系の案件では、そのような場面もありました。
会議では、
ここまでは対策する
ここから先は実現しない
このリスクは残る
その前提でこの方式を採用する
という議論が実際に行われていることがあります。
その場合、「残存リスクを受容した」と強い表現で書けなくても、
何が制約なのか
何が実現できないのか
その結果、何が起こり得るのか
どの代替策を採るのか
その前提でどの方式で進めると確認したのか
を、可能な範囲で記録に残します。
議事録は納品成果物に含まれない場合もありますが、会議後に関係者へ正式に共有される重要なプロジェクト記録です。計画時には想定していなかった緊急会議であっても、そこで何を説明し、何を確認したのかを議事録に残しておけば、後から判断経緯を追跡できます。
例えば、
「○○の制約により△△は実施しない。代替策として□□を採用し、本方式で進めることを確認した。」
という残し方です。
議事録が契約上の承認文書になるかどうかは案件の文書管理ルールによります。それでも、「説明した」「制約を共有した」「その前提で方式を確認した」という判断経緯を後から確認できる状態にしておくことには大きな意味があります。
事故後に「なぜ実施しなかったのか」を説明できるか
セキュリティ事故が起きたあとに、
「なぜ、この対策を実施していなかったのか」
と問われることがあります。
そのとき、
リスクを認識したうえで、既存対策と追加対策の効果を評価し、その残存リスクを前提にこの方式で進めることを関係者間で合意していた
と説明できる状態と、
なぜ「×」になっているのか分からない
状態では、大きな違いがあります。
セキュリティ要件定義の品質は、実施した対策の数だけでは決まりません。
必要な対策を導くこと。
実施しない対策についても判断理由を明確にすること。
対策後に残るリスクを把握すること。
そして、その残存リスクを前提に、どの方針で進めると決まったのかを追跡できるようにすること。
ここまで行って、リスクアセスメントによるセキュリティ要件の判断が一度閉じます。
ここからは、決めたセキュリティ要件をプロジェクトの後工程でどう扱うかです。
アセスメント結果を設計・見積・RFPへ引き継ぐ
前半で触れた要件定義と設計の境界を、後工程へ渡す観点から整理します。
要件定義では、リスク評価をもとに必要なリスク低減水準や満たすべきセキュリティ要求を決めます。 基本設計以降では、その要求を満たすネットワーク構成、認証方式、製品、クラウドサービス、運用方式を具体化します。基本設計で何を具体化するのかは、基本設計で決めること｜画面設計だけでは終わらない基盤SEの設計工程でも詳しく整理しています。
この境界を意識しないと、要件が粗すぎて見積前提が揃わないか、逆に要件定義で方式まで固定しすぎて設計の選択肢を失います。
また、セキュリティ要件は厳しく設定すればよいわけではありません。必要な権限を絞りながら、システムとして成立する実装方式へ落とす必要があります。
例えばECS/Fargateでコンテナを非rootで実行する設計にすると、共有VolumeのUID/GIDやファイル権限まで整合させなければ、アプリケーションやログ収集がPermission deniedで動かなくなることがあります。Fluent BitがPermission deniedでログを読めない｜ECS/Fargate共有VolumeのUID/GID設計では、最小権限を実装レベルまで落としたときに何を設計する必要があるかを具体例で整理しています。
STEP4で導いた要件を後工程の条件へ変換する
STEP4で導いたセキュリティ要件は、アセスメントシートの中に閉じ込めず、設計・見積・調達の条件へ変換して渡します。
ここで重要なのは、対策項目をもう一度並べることではありません。どのリスクをどこまで下げるための要求なのかという設計根拠を、後工程でも追跡できる状態にすることです。
セキュリティ要件は見積条件でもある
セキュリティ要件をどこまで求めるかによって、構築費と運用費は変わります。
例えば、
ログを保存する
という要求と、
セキュリティ上重要な操作を集中管理し、一定期間保存し、不審な操作を検知する
という要求では、必要になる仕組みも運用も違います。
可用性についても、バックアップから復旧できればよいのか、別拠点や別リージョンへの切替まで求めるのかによって費用は大きく変わります。
要件定義で、
高いセキュリティを確保すること
とだけ書いても、見積条件にはなりません。
費用に影響するセキュリティ要求は、ベンダが同じ前提で見積もれる粒度まで明確にする必要があります。
同時に、実装方式まで不必要に固定しないことも重要です。
認証強度や監視範囲、保存期間など、費用やシステム構成へ大きく影響する要求は要件として定める。それをどの製品やクラウドサービスで実現するかは、設計に選択肢を残せるのであれば固定しない。
見積可能な粒度まで要求を具体化しながら、実装方式まで不必要に縛らないことがポイントです。
RFPへ渡すなら「対策」だけでなく「要求の背景」も残す
冒頭で説明したRFPは、本記事の要件定義へ入るための入力でした。工程ごとに調達を分ける案件では、要件定義の成果が次工程のRFPや見積条件になります。
要件定義と基本設計以降で契約や担当ベンダが変わる案件では、アセスメント結果を次工程へ渡せる形にしておく必要があります。
このとき、
MFAを実装すること
だけを渡すより、
管理機能への不正アクセスによる顧客情報漏洩リスクを低減するため、管理者認証にはMFAを要求する
と、要求の背景まで追跡できる方が設計しやすくなります。
後工程で方式変更が必要になった場合にも、
MFAという方式を守れるか
だけではなく、
元々低減しようとしていたリスクを、変更後の方式でも十分に低減できるか
という判断に戻れるからです。
要件定義工程と基本設計以降を別に調達する案件では、この粒度がそのまま次工程の入札条件になります。
要求が粗すぎれば、ある応札者は24時間監視まで含め、別の応札者はログ保存だけを想定するなど、見積前提がばらつきます。価格差が方式差なのか、単なる前提差なのか分からなくなり、比較そのものが難しくなります。
細かく書きすぎて製品名や実装方式まで固定すると、応札側がより適切な方式を提案できる余地を奪います。
RFPでは、応札者が同じ要求水準を見積もれる具体性と、設計提案を可能にする自由度の両方が必要です。
要求の背景にあるリスクを残しておけば、この2つを両立させやすくなります。
未確定事項を「決まったこと」にしない
要件定義ですべての実装方式まで決められるとは限りません。
詳細な製品仕様や他システムとの調整結果を見なければ判断できない項目もあります。
その場合、無理に○や×を付けて確定させるより、
要件として必要なこと
現時点で決まっていること
基本設計以降で継続して検討すること
を分けておきます。
未確定事項を未確定のまま明示することは、設計品質が低いことを意味しません。
判断に必要な情報がまだ揃っていないことを明確にし、誰がどの工程で判断するのかを後工程へ渡す方が安全です。
アセスメント結果は、セキュリティ部門だけが保管する資料ではありません。
設計条件、見積条件、調達条件へ変換されて初めて、プロジェクト全体で使えるセキュリティ要件になります。
セキュリティアセスメントは一度実施して終わりではない
要件定義でリスクアセスメントを実施し、必要な対策と残存リスクの扱いを決めても、その評価がシステム廃止まで有効なわけではありません。
システム構成も脅威も変化します。
特に確認しなければならないのが、
評価した当時の前提が、現在も成立しているか
です。
代替コントロールの前提が崩れれば、差異評価も変わる
上位基準との差異評価では、同じ方式を採用できない場合に、別のコントロールでリスクを低減する方法を説明しました。
例えば、
利用できる管理端末を限定している
管理操作を記録している
ことを前提に、上位基準との差異による残存リスクを許容したとします。
その後の運用変更によって、管理端末が増えたり、操作ログの監視が実施されなくなったりすれば、当初の差異評価を支えていた前提が崩れます。
評価表に書かれた結論が同じでも、実際のリスクは既に変わっています。
上位基準自体が改定される場合もあります。
差異評価では、差異そのものだけでなく、代替コントロールが現在も有効に機能しているかを継続して確認する必要があります。
システム変更は、リスクの変更でもある
機能追加や構成変更でもリスクは変化します。
例えば、当初は社内ネットワークからだけ利用していたシステムを、インターネットから利用できるように変更すれば、同じアプリケーションでも脅威への露出が変わります。
外部SaaSとのAPI連携を追加すれば、新しい通信経路、認証情報、責任分界が生まれます。
IAM権限を変更したり、運用端末を追加したりした場合も、以前とは異なる攻撃経路が成立する可能性があります。
設計変更を、
機能が動くか
だけで確認するのではなく、
既存のリスク評価に影響しないか
まで確認します。
リスクアセスメントは、要件定義時に一度作って保管する資料ではありません。システムや外部環境が変われば、前提となるリスクも変わるため、必要に応じて見直します。具体的な見直しの契機は後述します。
脆弱性の「深刻度」だけでなく、実際に悪用されているかを見る
運用開始後には、多数の脆弱性情報が継続的に公開されます。
すべての脆弱性を同じ速度で修正することは、現実には困難です。
CVSSなどの深刻度は重要な判断材料ですが、それだけで対応順位を決める必要はありません。
CISAは、実際の攻撃で悪用された脆弱性をKnown Exploited Vulnerabilities（KEV）Catalogとして継続的に管理・公開しており、組織の脆弱性管理における優先順位付けの入力としてKEVを利用するよう案内しています。
例えば、
CVSSは高いが、自システムでは該当機能を使用しておらず外部からも到達できない脆弱性
と、
深刻度だけを見れば同程度でも、実際の攻撃で悪用されており、自システムが外部へ公開している機能に存在する脆弱性
では、対応優先度が同じとは限りません。
ここでも見るのは、
脆弱性の点数
だけではありません。
その脆弱性が、自システムのどの資産に対して、どの攻撃シナリオを成立させるのかです。
KEVに掲載されているから無条件に自システムの最優先になるわけでもありません。対象製品を利用しているか、脆弱な機能が有効か、攻撃経路が存在するかといった、自システム側の条件と組み合わせて判断します。
脆弱性管理では「何日で判断し、何日で適用するか」も設計する
AI節では、脆弱性を発見する量と速度が上がれば、人間側の検証・修正・適用能力がボトルネックになる可能性について触れました。
この問題は、運用開始後に初めて考えるものではありません。運用開始後の監視・ログ・バックアップ・判断体制まで含めた設計については、次の記事で説明した論点ともつながります。
重大な脆弱性が見つかったとき、CVSSの数値だけで「9.0以上なら即適用」のように機械的に決めるのではなく、例えば次の観点をあらかじめ判断基準として決めておきます。
- CVSSなどの脆弱性の深刻度
- 実際の攻撃で悪用されているか
- 脆弱性の対象となる製品・サービス・機能を自システムで利用しているか
- 外部から到達可能か、攻撃経路が成立するか
- WAF、アクセス制御、ネットワーク分離など既存対策でどこまで抑えられているか
- パッチ適用による停止や互換性への影響
- すぐ適用できない場合の代替コントロールがあるか
こうした情報をもとに、セキュリティ、基盤、アプリケーション、運用などの有識者で評価し、
緊急で適用する
通常の保守タイミングで適用する
代替対策で一時的にリスクを下げる
自システムには影響しないと判断する
といった対応方針を決めます。
さらに、
重大な脆弱性は何時間・何日以内に影響判断するのか
緊急適用が必要な場合、何日以内を目標にするのか
システム停止を誰が承認するのか
適用できない場合、誰が代替策と残存リスクを判断するのか
まで運用として決めておくと、脆弱性が公表されてから毎回ゼロから相談する必要がありません。
ここでは責任分界も重要です。OSやミドルウェアの脆弱性について、影響調査、適用判断、パッチ作業のどこまでを保守ベンダ、運用委託先、利用者側が担うのかを決めていなければ、緊急時に判断が止まります。
パッチを急いで適用すれば、変更による障害リスクも高まります。十分な検証を優先しすぎれば、既に悪用されている脆弱性を長期間残すことになります。
ここにも、セキュリティと安定運用のトレードオフがあります。
重要なのは、脆弱性の点数だけを見るのではなく、その脆弱性が自システムでどのリスクを成立させるのかを評価し、判断基準と意思決定プロセスを事前に決めておくことです。
再アセスメントする契機を決めておく
毎日すべてのリスクを最初から評価し直す必要はありません。
再評価の契機は、大きく3種類に整理できます。
1つ目はシステム側の変化です。 構成やインターネット公開範囲を変更した、外部サービスや接続先を追加した、IAMや管理経路を変更した、新しいAPIを公開した、保持するデータを変更した、といった場合です。
2つ目は外部環境の変化です。 上位基準やセキュリティ標準が改定された、重大な脆弱性が発見された、実際の攻撃で悪用されていることが確認された、といった変化が該当します。
3つ目は評価の前提そのものの変化です。 代替コントロールの運用方法や実効性が変わった、セキュリティインシデントが発生して従来の想定が不十分だと分かった、といった場合です。
図 システム・外部環境・前提条件の変化を契機に再アセスメントし、要件・設計・運用を更新する循環イメージ
実務では、仕様変更が入ったときに、変更対象のプログラムだけを見るのではありません。
変更管理委員会などで、
変更内容
→ 影響する構成要素・関連チーム
→ 変化する脅威・脆弱性
→ リスク再評価
→ 必要な要件・設計・運用・テストの見直し
まで確認します。
例えば、外部接続の追加であれば、ネットワークチームだけでなく、認証、IAM、ログ監視、運用手順、障害時の切り分けまで影響する可能性があります。セキュリティに影響する変更であれば、関連するリスクアセスメントも見直します。
何かが変わるたびにアセスメントシート全体を作り直すのではなく、変化によって影響を受ける資産、脅威、攻撃シナリオ、既存対策、残存リスクを見直すという考え方です。
ウォーターフォール型の大規模開発では、後工程になるほど要件、設計、試験、運用手順など複数の成果物へ影響が波及するため、変更時の見直しは大きな作業になります。前工程へ戻るコストが大きいからこそ、変更管理の中にセキュリティ影響確認を組み込んでおく必要があります。
アジャイル開発でも原理は同じです。大きな工程へまとめて戻るのではなく、機能追加や変更のサイクルごとにセキュリティ影響を確認し、必要に応じてリスク評価や対策を更新します。
開発手法にかかわらず、変更によって以前のリスク評価の前提が変わっていないかを確認することが重要です。
セキュリティアセスメントは単なる成果物ではなく、システムの変化に対してセキュリティ判断を更新するための基準として使うものです。
まとめ｜セキュリティ要件は、リスクから必要な対策を導く
セキュリティ要件は、暗号化、MFA、WAF、ログ管理といった具体的な対策を先に選んで決めるものではありません。
RFP、顧客標準、業界基準などの上位要求を入力として、まず対象範囲と責任分界を整理し、
脅威を分析する
↓
脆弱性・設定不備・統制不足を分析する
↓
リスクを分析・評価する
↓
リスク対応を決め、必要な対策へ落とす
という流れでセキュリティ要件を導きます。
脅威を検討するときには、構成要素と脅威を掛け合わせ、外部攻撃者だけでなく、内部者、委託先、人的ミス、物理的な侵入まで見ます。
上位基準がある案件でも、基準への○×判定だけでは終わりません。
上位基準の要求
↓
本システムの実現方式
↓
差異
↓
差異によって増えるリスク
↓
代替コントロール
↓
残存リスク
↓
合意
まで評価します。
AIによって脆弱性の発見や攻撃作業の速度が上がっても、この順序は変わりません。
未知の脆弱性をすべて事前に列挙することはできないため、個々のCVEだけを見るのではなく、資産と攻撃シナリオを基準に、侵入後の権限昇格、横展開、情報取得まで含めて考えます。
必要な対策を実施しても、リスクを完全にゼロにはできません。
最後に必要なのは、
何を実施し、何を実施しないのか。
その結果、何のリスクが残るのか。
その前提で、どの方式・運用で進めると決まったのか。
を説明できる状態にすることです。
理想的には残存リスクの受容主体まで明文化します。実務上それが難しい場合でも、制約、代替策、残るリスク、判断経緯を成果物や議事録などで追跡できる状態にしておくことが重要です。
そして、そこで判断を終わらせません。
要件定義で決めた内容を設計、見積、次工程のRFP、運用へ引き継ぎ、システム構成や脅威、上位基準、代替コントロールの前提が変われば、リスクを再評価します。
公的なガイドラインや組織標準、過去のアセスメントシートは、検討漏れを防ぐための重要な材料です。ただし、それ自体が対象システムの答えになるわけではありません。
セキュリティ要件定義で本当に必要なのは、
何を守るのかを明確にし、脅威と弱点からリスクを評価し、そのシステムに必要な対策と残るリスクの扱いを判断すること
です。
この判断過程まで説明できて初めて、セキュリティ要件が設計根拠を持った要求になります。
実務で使うためのアセスメントシートと差異評価
ここまでで、セキュリティ対策をリスクから導き、実施しない対策と残存リスクまで判断する考え方を説明しました。
実際の案件でこの方法を回すには、判断結果を残すためのアセスメントシートと、上位基準との差異・代替コントロール・残存リスクを記録する型が必要になります。
今後公開予定の実務編では、リスクアセスメントシートと差異評価シートの具体的な記入方法、差異ステータスの判定、判断理由・残存リスクの書き方、顧客説明資料への落とし込み方を、実務で使える形にまとめるます。
参考資料
- Anthropic, “Disrupting the first reported AI-orchestrated cyber espionage campaign”Disrupting the first reported AI-orchestrated cyber espionage campaignA report describing an a highly sophisticated AI-led cyberattackwww.anthropic.com
- Ars Technica, “Researchers question Anthropic claim that AI-assisted attack was 90% autonomous”
![]()
Researchers question Anthropic claim that AI-assisted attack was 90% autonomousThe results of AI-assisted hacking aren't as impressive as many might have us believe.arstechnica.com - Anthropic, “Evaluating and mitigating the growing risk of LLM-discovered 0-days”
![]()
LLM-discovered 0 daysAI models can now find high-severity vulnerabilities at scale. This is a moment to empower defenders. We're now using Claude to find and help fix vulnerabilitieReadMore...www.anthropic.com - NIST, “The NIST Cybersecurity Framework (CSF) 2.0”
![]()
The NIST Cybersecurity Framework (CSF) 2.0The NIST Cybersecurity Framework (CSF) 2.0 provides guidance to industry, government agencies, and other organizations to manage cybersecurity risks.www.nist.gov - CISA, “Known Exploited Vulnerabilities Catalog”https://www.cisa.gov/known-exploited-vulnerabilities-catalogwww.cisa.gov
- 個人情報保護委員会, 「令和7年度（2025年度）個人情報保護委員会年次報告」個人情報保護委員会 令和７年度年次報告の公表について（令和８年７月７日） ｜個人情報保護委員会個人情報保護委員会のホームページです。令和７年度個人情報保護委員会年次報告の概要等の公表について掲載しています。www.ppc.go.jp
- AWS, “Shared responsibility – Security Pillar”責任共有 - セキュリティの柱セキュリティとコンプライアンスに関して、AWS とお客様の間で責任を共有します。この共有モデルにより、ホストオペレーティングシステムや仮想化レイヤーからサービスが運用されている施設の物理的なセキュリティに至るまで、さまざまなコンポーネントを AWS が運用、管理、制御するため、お客様の運用の負担が軽減されます。お客様はReadMore...docs.aws.amazon.com
- IPA, “システム構築の上流工程強化（非機能要求グレード）紹介ページ”
![]()
システム構築の上流工程強化（非機能要求グレード）紹介ページ | アーカイブ | IPA 独立行政法人 情報処理推進機構情報処理推進機構（IPA）の「システム構築の上流工程強化（非機能要求グレード）紹介ページ」に関する情報です。www.ipa.go.jp
コメント