ネットワークのセキュリティ要件をどう整理する？要件定義で確認すべきポイントを解説

2026年8月11日

ネットワーク上級編 06／全70記事

この記事は、「ネットワーク上級編｜要件定義・設計・クラウド・自動化へ進む」の第6回です。

第1章では、顧客の要望を整理し、ネットワーク設計で判断できる具体的な条件へ変換する要件定義を学びます。

NETWORK ADVANCED｜CHAPTER 1 REQUIREMENTS

セキュリティ要件の整理｜「安全にしたい」を設計できる条件へ変える

「セキュリティを強化したい」という要望だけでは、ファイアウォールやVLAN、認証方式などを適切に設計できません。何を守るのか、どの通信を許可するのか、誰が管理できるのか、どのログをどれだけ残すのかまで具体化して、設計と試験に使えるセキュリティ要件へ変換します。

対象レベル Level 3〜4・上級

想定読了時間 約25分

身につく成果 セキュリティ要件を設計条件へ整理できる

前提知識 要件定義・性能・可用性要件

演習環境 ブラウザ・紙・Excel等

要件定義の場では、 「社内ネットワークなので安全にしてください」 「外部から侵入されないようにしてください」 といった要望がよく出てきます。

しかし「安全」の意味が曖昧なままでは、どこを分離するのか、どの通信を制限するのか、誰に管理権限を与えるのかを決められません。

セキュリティ要件では、 守る対象・許可する利用者や通信・管理方法・記録方法 を具体化していきます。

この記事を読み終えるとできること

セキュリティ要件の役割を説明できる
「セキュリティを強くしたい」を具体化できる
ネットワーク分離の要件を整理できる
許可・禁止通信の条件を整理できる
利用者・端末・管理アクセスの条件を整理できる
ログ保存や規程に関する条件を確認できる
要件と具体的な設計方式を区別できる
セキュリティ要件を試験可能な形で文書化できる

セキュリティ要件とは何か

最初に覚える定義

セキュリティ要件とは、ネットワークや情報をどのような条件で保護し、誰にどの通信や操作を許可するかを定める要件です。

たとえば顧客から、「ネットワークのセキュリティを強化してください」と言われたとします。

このままでは設計できません。少なくとも次のような点を確認する必要があります。

どのシステムやネットワークを守るのか
どの利用者がアクセスするのか
どの端末から接続を許可するのか
どのネットワーク間通信を許可するのか
インターネットからの通信を受けるのか
社外からアクセスする必要があるのか
ネットワーク機器を誰が管理するのか
どのログを保存する必要があるのか
社内規程や守るべきルールがあるのか

要件定義では、ファイアウォール製品や具体的な設定値をいきなり決めるのではありません。

先に「どのような状態を実現する必要があるのか」を決め、その条件を満たす方式を基本設計で検討します。

なぜセキュリティ要件を先に整理するのか

必要な通信を止めないため

セキュリティを強くすることだけを考えて通信を制限すると、本来必要な業務通信まで停止する可能性があります。業務上必要な通信を先に把握することが重要です。

設計の根拠を作るため

ネットワーク分離やアクセス制御を行う理由を、顧客の要件へ結び付けて説明できます。

試験条件を作るため

「許可された通信は通る」「禁止された通信は通らない」といったセキュリティ試験項目を作成できます。

過剰設計を防ぐため

必要以上の機能や制御を入れると、コストや運用負荷が増えます。守る対象と必要なレベルを整理することが重要です。

セキュリティ要件整理の全体像

セキュリティ要件は、次の順番で整理すると考えやすくなります。

SECURITY REQUIREMENTS｜要件整理の流れ

📦 守る対象 システム・ネットワーク・情報

→

👤 利用者・端末 誰が・何から利用するか

→

🔀 必要な通信 どこからどこへ通信するか

→

🔐 制御条件 許可・禁止・認証・管理

→

📝 記録・監査 ログ・保存期間・確認方法

最初から「ACLをどう書くか」「どのファイアウォールを使うか」と考えるのではなく、 業務上必要な通信と、許可すべき対象を整理する ことから始めます。

まず「何を守るのか」を確認する

セキュリティ要件を考えるとき、最初に明確にしたいのが保護対象です。

「セキュリティを高める」という表現だけでは、何を優先して守るべきなのか判断できません。

確認する主な対象

業務システム

受発注、会計、顧客管理など、業務停止時の影響が大きいシステムを確認します。

サーバーネットワーク

一般利用者端末からどこまでアクセスを許可するか、管理通信を分離するかを確認します。

管理ネットワーク

ルーター、スイッチ、ファイアウォールなどの管理画面へ接続できる利用者や端末を確認します。

外部公開システム

インターネットからアクセスされるシステムと、社内だけで利用するシステムを区別します。

すべてを同じ重要度で扱わないことも重要です。

業務影響や利用目的が異なれば、必要なアクセス制御やログ管理の内容も変わります。

ネットワーク分離の要件を整理する

次に、 どの利用者・端末・システムを同じネットワークへ置き、どこを分ける必要があるのか を確認します。

確認例

社員PCとゲスト端末を分離する必要があるか
一般利用者とサーバーを分離する必要があるか
ネットワーク機器の管理用通信を分離するか
IoT機器や監視カメラを一般端末と分けるか
開発環境と本番環境を分離する必要があるか
拠点や部署単位でアクセス範囲を分ける必要があるか

曖昧な要望	確認する内容	要件例
ゲストWi-Fiを安全にしたい	社内ネットワークへのアクセス可否	ゲスト用ネットワークから社内業務ネットワークへの通信を許可しないこと
管理画面を守りたい	誰がどこから管理するか	ネットワーク機器への管理通信は、指定された管理ネットワークからのみ許可すること
サーバーを保護したい	必要な通信元・宛先	一般利用者ネットワークからサーバーネットワークへの通信は、業務上必要な通信のみ許可すること

要件定義の段階では、「VLAN 100にする」といった具体的な番号まで決める必要はありません。

まず、 「どのグループを分離する必要があるか」 を要件として整理します。

許可・禁止通信の要件を整理する

ネットワークを分離しただけでは、セキュリティ要件は完成しません。

分離したネットワーク同士で、 どの通信を許可し、どの通信を禁止するのか を整理します。

最低限確認したい5項目

通信元 どの利用者・端末・ネットワークから通信するのか確認します。
通信先 どのサーバー・システム・ネットワークへ接続するのか確認します。
利用目的 なぜその通信が必要なのか、業務上の理由を確認します。
必要な通信 Web、名前解決、メール、管理通信など、必要な通信を整理します。
不要な通信 業務上必要のない経路や接続を許可する必要がないか確認します。

通信元	通信先	目的	要件
社員PC	業務Webサーバー	業務システム利用	業務に必要な通信を許可
ゲストWi-Fi	社内サーバー	なし	通信を許可しない
管理端末	ネットワーク機器	設定・保守	指定された管理端末からのみ許可
一般社員PC	ネットワーク機器	なし	管理アクセスを許可しない

「全部許可して、一部だけ禁止する」のか、「必要な通信だけを許可する」のかでも、設計思想は大きく変わります。

要件定義の段階で、どの程度の通信制御を求めるのか認識を合わせておきます。

利用者・端末認証の要件を整理する

「ネットワークへ接続できるのは誰か」も重要な確認項目です。

利用者について確認する

社員だけが利用するのか
協力会社や委託先も利用するのか
来訪者・ゲストの利用があるのか
管理者と一般利用者を分ける必要があるか
退職・異動時に利用権限をどのように変更するか

端末について確認する

会社支給PCだけを許可するのか
私物端末から接続できるのか
スマートフォン・タブレットを許可するのか
IoT機器やプリンターなども接続するのか
登録されていない端末をどう扱うのか

要件は 「特定製品の認証機能を使うこと」 ではなく、まず 「誰・どの端末まで接続を許可する必要があるか」 を明確にします。

管理アクセスの要件を整理する

ネットワーク機器の管理画面へ誰でもアクセスできる構成では、運用上のリスクが高くなります。

要件定義では、少なくとも 誰が・どこから・何の目的で管理するのか を確認します。

管理者

社内運用担当者、ベンダー、保守会社など、管理を行う主体を確認します。

接続元

管理端末、運用拠点、踏み台環境など、どこから管理する必要があるか確認します。

管理対象

ルーター、スイッチ、ファイアウォール、無線LAN機器など対象を整理します。

記録

誰がいつ管理操作したかを後から確認する必要があるか整理します。

要件の例

ネットワーク機器への管理アクセスは、指定された運用担当者および指定された管理経路からのみ実施できること。

この要件を実際にどのネットワーク、認証方式、アクセス制御で実現するかは設計工程で決定します。

外部・リモートアクセスの要件を整理する

テレワークや保守作業などにより、社外から社内システムへ接続する場合があります。

この場合も単に「VPNを使う」と決める前に、利用条件を整理します。

確認する内容

誰が社外から接続するのか
何人程度が同時に利用するのか
どの端末から接続するのか
どのシステムへアクセスする必要があるのか
24時間接続が必要なのか
ベンダーによるリモート保守があるのか
接続履歴をどの程度残す必要があるのか

利用者	利用場所	接続先	確認事項
社員	自宅・外出先	業務システム	利用可能端末・利用人数・アクセス範囲
保守ベンダー	社外	管理対象機器	利用時間・接続対象・操作記録

ログ保存・監査の要件を整理する

セキュリティ対策は、通信を制御して終わりではありません。

問題発生時に、 いつ・どこから・何が行われたのか確認できる状態 が必要な場合があります。

ログについて確認すること

どの機器・システムのログが必要か
アクセスログが必要か
管理操作のログが必要か
認証成功・失敗の記録が必要か
通信を拒否した記録が必要か
何日・何か月・何年保存する必要があるか
誰がログを確認するのか
障害・インシデント時にどのように利用するのか

悪い要件	改善例
ログを保存すること	ネットワーク機器の管理操作ログを保存し、必要な調査期間を確認できること
ログを長期間残すこと	必要な保存期間を関係者と確認し、保存期間を明確にすること
不正アクセスを記録すること	対象とするアクセスおよび確認に必要なログを定義すること

「ログを取る」だけでは要件として不十分です。

何のために、何を、どの期間保存し、誰が利用するのかまで確認すると設計しやすくなります。

社内規程・業界ルールを確認する

ネットワークエンジニアが技術的に最適と考える構成だけでセキュリティ要件を決められるとは限りません。

顧客側に既存のルールや標準がある場合、それらも制約・要件として確認します。

確認例

社内のセキュリティ規程
ネットワーク設計標準
利用可能な製品・メーカーの指定
パスワードやアカウント管理のルール
ログ保存に関する社内ルール
外部接続に関する承認ルール
委託先・ベンダー接続に関するルール

既存ルールを確認せず設計を進めると、後から大幅な設計変更になる場合があります。

特に既存ネットワークへ接続する案件では、顧客標準や既存運用との整合を早い段階で確認します。

良いセキュリティ要件の書き方

良い要件は、設計者が判断でき、最後に満たしているか確認できます。

悪い例	改善例
セキュリティを強化すること	一般利用者ネットワークからネットワーク機器への管理アクセスを許可しないこと
サーバーを安全にすること	利用者ネットワークからサーバーネットワークへの通信は、業務上必要な通信に限定すること
ゲストWi-Fiを安全にすること	ゲスト用ネットワークから社内業務ネットワークへ直接通信できないこと
管理アクセスを制限すること	管理アクセスは、指定された管理者および管理経路からのみ許可すること
ログを残すこと	セキュリティ調査に必要な対象ログと保存期間を定義し、必要時に確認できること

要件には「理由」も残す

要件	理由・背景	設計で検討すること
ゲストネットワークから社内ネットワークへの通信を許可しない	来訪者端末から社内システムへアクセスさせないため	ネットワーク分離・通信制御
管理通信は指定された管理経路からのみ許可する	一般端末から機器管理画面へ接続させないため	管理ネットワーク・アクセス制御
必要な管理操作ログを保存する	問題発生時に操作履歴を確認できるようにするため	ログ取得・保存・転送方式

要件と理由をセットで残すことで、後の設計レビューで 「なぜこの構成・設定が必要なのか」 を説明しやすくなります。

セキュリティ要件と設計を混同しない

上級工程で特に重要なのが、 要件と設計を分けて考えることです。

種類	例
要望	ゲストWi-Fiを安全にしたい
要件	ゲストネットワークから社内業務ネットワークへ通信できないこと
設計	ゲスト用ネットワークを分離し、境界でアクセス制御を実施する

「ファイアウォールを入れてください」「VLANを分けてください」という発言が顧客から出た場合でも、その背景を確認します。

何から何を守りたいのか
現在どのような問題があるのか
禁止したい通信は何か
許可する必要がある通信は何か

目的を確認してから、最適な実現方式を設計工程で検討します。

セキュリティ要件整理でよくある失敗

NG 最初から製品や機能を決める

要件を整理する前に製品や機能を選ぶと、本来の目的より製品仕様が中心になってしまいます。

NG 「セキュリティを強化する」で終わる

何をもって安全とするのか分からず、設計にも試験にも使用できません。

NG 禁止通信だけを考える

必要な業務通信を把握せず制限すると、正常な業務まで停止する可能性があります。

NG 管理通信を忘れる

利用者通信だけではなく、ネットワーク機器の管理経路や運用担当者についても確認する必要があります。

NG ログの保存期間を決めない

「ログを取得する」だけでは、保存容量や管理方法を設計できません。

OK 要件を試験できる表現まで具体化する

「許可された通信ができる」「禁止された通信ができない」と確認できるレベルまで具体化すると、後工程へ引き継ぎやすくなります。

顧客・上司へどう説明するか

技術に詳しくない相手へ、「ACL」「セグメンテーション」などの用語だけで説明しても必要性が伝わらないことがあります。

セキュリティ要件は、 業務上のリスクへ置き換えて説明します。

技術的な確認	業務としての確認
ネットワークを分離するか	どの利用者・端末からどのシステムへアクセスさせたくないか
管理アクセスを制限するか	誰がネットワーク機器の設定を変更できる必要があるか
外部接続を許可するか	社外から誰が何の業務を行う必要があるか
ログを保存するか	問題発生時にどこまで過去の状況を調査できる必要があるか

説明例：

「セキュリティ要件では、単に通信を厳しく制限するのではなく、業務で必要な通信を確認したうえで、誰がどのシステムへアクセスできる必要があるかを整理します。また、ネットワーク機器の管理方法や外部からの接続、問題発生時に確認するログについても条件を決めます。」

セキュリティ要件で使われる英語表現

よく使う単語

英語	意味
Security requirement	セキュリティ要件
Access control	アクセス制御
Network segmentation	ネットワーク分離
Authentication	認証
Management access	管理アクセス
Remote access	リモートアクセス
Security policy	セキュリティポリシー
Audit log	監査ログ
Log retention	ログ保存

ヒアリングで使える表現

Which systems and networks need to be protected?
どのシステムとネットワークを保護する必要がありますか？

Who should be allowed to access this network?
誰にこのネットワークへのアクセスを許可する必要がありますか？

Which network communications should be allowed?
どのネットワーク通信を許可する必要がありますか？

Is remote access required?
リモートアクセスは必要ですか？

How long should security logs be retained?
セキュリティログをどの程度の期間保存する必要がありますか？

理解度チェック

用語の暗記ではなく、要望を要件へ変換できるか確認しましょう。

問題1．「セキュリティを強くしてください」という顧客の要望に対し、最初の対応として適切なものはどれですか。

すぐにファイアウォール製品を選定する
すべての通信を禁止する
守る対象や必要な通信、利用者などを確認する
すべてのネットワークを同じ設定にする

解答を見る

正解：C

要件定義では、先に製品を決めるのではなく、守る対象、利用者、必要な通信、管理方法などを確認します。

問題2．次のうち、セキュリティ「要件」として最も適切なものはどれですか。

VLAN 100を作成する
特定メーカーのファイアウォールを導入する
ゲストネットワークから社内業務ネットワークへ通信できないこと
ACLの設定番号を100にする

解答を見る

正解：C

Cはネットワークが満たすべき条件です。 VLANや製品、設定方法は設計工程で検討します。

問題3．許可・禁止通信を整理するときに、最低限確認すべき情報を3つ挙げてください。

解答例を見る

通信元
通信先
利用目的・必要な通信

「誰がどこへ何のために通信するのか」を確認することが基本です。

問題4．「ログを保存すること」だけでは要件として不十分なのはなぜですか。

解答を見る

何のログを、何の目的で、どの期間保存する必要があるのか分からず、保存方法や必要容量などを設計できないためです。

問題5．次の文章の空欄を埋めてください。

セキュリティ要件では、「どの製品を使うか」より先に「（ A ）を守り、（ B ）にどの通信を許可する必要があるか」を確認する。

解答を見る

A：何・どの対象　B：誰・どの利用者や端末

表現は完全一致でなくても構いません。守る対象と、アクセスを許可する主体を明確にできれば正解です。

実践演習：小規模オフィスのセキュリティ要件を整理する

あなたは、新しいオフィスネットワークの要件定義を担当しています。

演習の前提条件

💻 社員PC 業務システムを利用

📱 ゲストWi-Fi 来訪者が利用

🗄️ 業務サーバー 社内システムを提供

🔧 管理端末 NW機器を管理

顧客から聞いた要望

社員は業務サーバーを利用したい
来訪者にもWi-Fiを提供したい
来訪者から社内システムへはアクセスさせたくない
ネットワーク機器は運用担当者だけが管理したい
問題が起きたときに操作履歴を確認したい

課題1．守る対象を整理する

この案件で特に保護すべき対象を挙げてください。

例：業務サーバー、＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

解答例を見る

業務サーバー
社員用ネットワーク
ネットワーク機器の管理機能
管理操作に関する情報

課題2．ネットワーク分離要件を作る

ゲストWi-Fiについて、設計方法ではなく「満たすべき条件」として書いてください。

ゲスト用ネットワークは、＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿。

解答例を見る

ゲスト用ネットワークから社員用ネットワークおよび業務サーバーへの通信を許可しないこと。

課題3．管理アクセス要件を作る

ネットワーク機器への管理アクセスは、＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿。

解答例を見る

ネットワーク機器への管理アクセスは、指定された運用担当者および指定された管理端末からのみ実施できること。

課題4．ログ要件を作る

問題発生時に＿＿＿＿＿＿＿＿＿＿を確認できるよう、＿＿＿＿＿＿＿＿＿＿を保存すること。

解答例を見る

問題発生時に管理操作の履歴を確認できるよう、必要なネットワーク機器の管理操作ログを保存すること。

実案件ではさらに、必要な保存期間や確認担当者などをヒアリングして具体化します。

課題5．要件一覧を作る

最後に、要件・理由・確認方法を整理してください。

要件	理由	確認方法
ゲストNWから社員NW・業務サーバーへ通信できないこと	来訪者端末から社内システムへアクセスさせないため	ゲスト端末から通信できないことを確認
社員PCから必要な業務サーバーへ通信できること	業務システムを利用するため	社員PCから業務通信が正常に行えることを確認
管理アクセスは指定管理者・管理端末に限定すること	一般利用者から設定変更させないため	管理端末と一般端末の双方から接続試験
必要な管理操作ログを保存すること	問題発生時に操作履歴を確認するため	管理操作後にログが記録されることを確認

自分の言葉で説明する課題

顧客から「セキュリティを強くしたいのですが、何を決めればよいですか？」と質問されました。

技術に詳しくない相手へ、 1分程度で説明してください。

セキュリティ要件では、まず＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿。

説明例を見る

セキュリティ要件では、まず何を守る必要があるかを確認します。そのうえで、誰がどのシステムへアクセスする必要があるか、どの通信を許可・禁止するか、ネットワーク機器を誰が管理するか、問題発生時にどのログを残す必要があるかを整理します。これらの条件を決めてから、具体的なネットワーク構成やアクセス制御方式を設計します。