ネットワークを分ければ安全になる？——FW・DNS・メール・無線LAN・VPN・DDoSを午後の問われ方で読む｜支援士解説3の5
この記事の重要度：Sランク（午後で繰り返し主役になる最重要の分野）
この記事で分かること：
FW・IDS・IPS・WAF・プロキシ・DNS・メール・無線LAN・VPNの役割と、それぞれで「何が守れて、何が守れないか」
午後の構成図問題で、通信がどの装置をどの順に通るかを読み取る方法
各論点で、解答欄に書く「原因」と「対策」の型
シラバスとの対応：小項目3-5「ネットワーク及び機器のセキュリティ管理」。TLSと証明書の仕組みは支援士解説3の1、分離の設計（ゼロトラスト・OTとITの分離・VDI）は支援士解説2の3、ログの読み方は支援士解説3の4で扱います。
午後の問題では、ネットワーク構成図がよく出てきます。インターネット、FW、DMZ、プロキシ、DNSサーバ、メールサーバ、社内LAN、無線LAN、VPN装置。並んでいる装置の名前を知っていても、「この通信はどこを通り、どこで止まるか」が読めなければ、設問には答えられません。
この記事では、装置ごとに何を見て判断しているかと、それだけでは守れないものを対にして整理します。この二つが分かると、「なぜその対策では足りないのか」「どこに何を追加すべきか」という午後の定番の問いに答えられるようになります。
1. 通信が成立するまで：DHCP・ARP・DNS・TCP/UDP・ICMP
端末がWebサービスにつながるまでには、いくつもの仕組みが順に働きます。どこか一つを偽られたり妨害されたりすれば、正しい相手につながらなくなります。
DHCP：IPアドレス、サブネットマスク、デフォルトゲートウェイ（ネットワークの外へ出る出口）、DNSサーバの情報などを端末に配る。許可していないDHCPサーバが偽のDNSサーバの情報を配ると、利用者が正しい名前を入力しても、意図しない問い合わせ先を使ってしまう。対策の一つが、スイッチのDHCPスヌーピング（信頼するポートからのDHCP応答だけを通す）
ARP：同じLANの中で、IPv4アドレスに対応するMACアドレスを調べる。別のネットワーク宛ての通信では、まずデフォルトゲートウェイのMACアドレスを調べる。ARPには応答の相手を確かめる仕組みがないので、偽の対応を信じ込ませるARPスプーフィングで、通信を中継されたり妨害されたりする。対策の一つが、スイッチのDynamic ARP Inspection（DHCPスヌーピングで得た対応の情報などを基に、ARPの内容を検査する）。なお、IPv6ではARPではなく、ICMPv6の近隣探索を使う
DNS：ドメイン名からIPアドレスなどを調べる（5節）。DNSはUDPだけでなくTCPも使うので、「DNSはUDPだからTCPは全部拒否」という設定は誤り
TCPとUDP：TCPは接続を確立し、順序や再送を管理する。UDPはそれをしない。ポート番号は、どのサービスにデータを渡すかを示す。端末がWebサーバのTCP443番に接続するとき、端末側の送信元ポートは一時的な番号になり、応答では送信元と宛先が入れ替わる。この向きを取り違えると、FWのルールを正しく読めない
ICMP：エラーの通知や診断に使う。pingの応答だけの仕組みではなく、経路上で運べるパケットの大きさを調べる仕組みにも関わる。ICMPにはポート番号がない。ICMPを悪用する攻撃に、送信元を標的のアドレスに偽ってネットワークのブロードキャストアドレスにpingを送り、多数の応答を標的に集中させるSmurf攻撃がある。ブロードキャストアドレス宛てのpingに応答しない設定にする
HTTPとSMTP：HTTPはWebの要求と応答、SMTPはメールの送信と配送に使う。HTTPSで暗号化されていても、相手のサイトや配布されるファイルが安全だという意味にはならない
IPアドレスとNAT
組織の内部ではプライベートIPアドレスを使い、インターネットに出るときにルータやFWでグローバルIPアドレスに変換するのが一般的。この変換がNAT（ポート番号まで変換するものはNAPT）。プライベートIPアドレスの範囲は、10.0.0.0～10.255.255.255、172.16.0.0～172.31.255.255、192.168.0.0～192.168.255.255
NATはアドレスを変換する機能であって、通信を許可・拒否する機能ではない。外から内部のアドレスが見えにくくなることはあるが、「NATがあるからアクセス制御は不要」とはならない（3節）
午後の問題では、ログに残る送信元IPアドレスが、変換後のアドレスなのか、変換前の端末のアドレスなのかを確かめる必要がよくある（ログの読み方は支援士解説3の4）
2. 分割とDMZ：分けた後で、必要な経路だけを許可する
分ける目的
ネットワークを分ける目的は、侵害されたときに被害の範囲を限定することです。一つの端末がマルウェアに感染しても、ほかの区画へ自由に通信できなければ、広がりを抑えられます。分けたネットワークでも感染は起こり得る、という前提で考えます。
VLAN：分けただけでは、通信は止まらない
VLANは、同じスイッチを使いながら、設定でLANを論理的なグループに分ける技術です。ブロードキャストが届く範囲が分かれます。
ただし、別のVLANにしても、ルータやレイヤ3スイッチが区画の間を自由に中継すれば、通信はできてしまいます。VLANが違うことと、通信を禁止していることは同じではありません。区画間で止めたい通信は、アクセス制御を設定し、その経路が実際に制御点を通ることを確かめます。
同じL2スイッチにつながったPC同士の通信も見落としがちです。ワームはPC同士で直接広がるので、サーバやインターネットとの境界だけを固めても止まりません。PC同士の直接の通信を、スイッチの側（VLANやポート間の通信制限）で禁止します。
物理的に分ける場合も、両方につながる端末や保守用の回線があれば、そこが接点になります。
さらに細かく、サーバや仮想マシンの単位で通信を制御する考え方を、マイクロセグメンテーションといいます。同じ区画の中でも、必要な通信だけを許可することで、侵入された後の横展開を止めやすくなります。
DMZ：公開するサーバを、内部と同じ扱いにしない
DMZは、インターネットに公開するサーバを、内部のネットワークと分けて置く区画です。「非武装地帯」という名前ですが、守らなくてよい場所という意味ではありません。目的は、公開サーバが乗っ取られても、そこから内部へ自由に進ませないことです。
架空の予約サービスを、説明用に三つの区画に分けて考えます（図2）。
公開Web区画（DMZ）：住民などの利用者からの予約の要求を受け付ける
業務・データ区画：予約データを処理・保存する
管理・遠隔保守の経路：許可された担当者が管理作業をする
通信は、次のように絞ります。
インターネットから内部へは、公開Web区画のWebサービスだけを許可する
公開Web区画から業務・データ区画へは、必要な宛先とサービスだけを許可する。公開Webサーバから内部の全機器へ自由に接続できる設定にしない
管理の操作は、業務用とは別の経路と権限に限定する
内部から外部へ出る通信も制御します。 感染した端末が外部の指令サーバに接続したり、乗っ取られたサーバが情報を持ち出したりするのを防ぐためです。たとえば、公開Webサーバが外部の任意のメールサーバに直接メールを送る必要はないかもしれません。名前解決も、管理するDNSサーバを経由させます。
ネットワークで到達できる範囲を絞る対策と、接続した後にできる操作を絞る対策（データベースのアカウントの権限など）は、別の層の保護です。どちらか一方で代用しません。
境界の内側を一律に信頼する考え方の限界と、その先にあるゼロトラスト、工場などの制御システム（OT）を社内のネットワークから切り離す設計は、支援士解説2の3で扱います。
午後での問われ方
平成30年度秋期 午後I問2：有線LANのL2スイッチにつながったPC同士で、ワームが感染するのを防ぐ対策が問われました。採点講評では正答率が低く、PC同士が直接通信するというワームの特性を踏まえることが求められています。端末の側だけでなく、ネットワークの側で止める発想が鍵です。
記述の型
分ける目的：「侵害されたときに、被害の範囲を限定する」
DMZの公開サーバ：「公開サーバから内部ネットワークへの通信を、必要なものだけに制限する」
VLANの注意点：「VLANを分けても、区画間のアクセス制御を設定しなければ通信できてしまう」
横展開を防ぐ：「端末同士の直接の通信を禁止し、サーバへは必要なポートだけを許可する」
外向きの通信の制御：「公開サーバや端末から外部への通信を、業務に必要な宛先とサービスだけに限定する」
3. ファイアウォール：何を根拠に通すのか
パケットフィルタ
ファイアウォール（FW）は、ネットワークの間を流れる通信を制御する仕組みです。基本のパケットフィルタは、送信元・宛先のIPアドレス、プロトコル、送信元・宛先のポート番号を条件に、許可か拒否かを決めます。必要な通信を具体的に許可し、それ以外を拒否するのが基本です。
ルールの順番
上から順に照合し、最初に一致したルールを適用する方式を考えます。
職員用ネットワークからサーバ区画への通信を、すべて許可する
職員用ネットワークからデータベースへの直接の接続を、拒否する
それ以外は拒否する
データベースがサーバ区画に含まれるなら、2番の拒否に届く前に、1番の許可に一致してしまいます。拒否のルールがあっても、期待した制御が働きません。広い許可が狭い拒否より先にあると、狭い拒否は隠れてしまいます。午後の問題では、問題文に書かれた照合の順番をそのまま使って判断します。
ステートフルインスペクション
ステートフルインスペクションは、通信の状態を記録し、その状態に合うかも検査する方式です。内部の端末から始まった許可済みのTCP接続について、相手からの応答を、その接続に対応する通信として扱えます。外部から端末の一時ポートに届いたというだけでは、正規の応答とは判断しません。
状態を記録しない単純なパケットフィルタでは、応答を通すために、アドレス・ポート・方向の条件で戻りの通信を許可する必要があります。「ACKフラグが付いていれば応答だ」と推定するだけでは不十分です。フラグだけを付けた不正なパケットも作れるからです。なお、UDPにはTCPのような接続を確立する手順がありません。製品によっては、UDPでも送った要求と応答の対応を一定時間保持して扱いますが、プロトコルの仕組みと、FWが管理する状態は分けて考えます。
パケットフィルタとアプリケーションゲートウェイ
FWの方式には、パケットフィルタのほかに、アプリケーションゲートウェイ型（プロキシ型）があります。利用者と通信の相手の間に入って通信をいったん終端し、アプリケーションの通信として中継する方式です。
パケットフィルタ：IPアドレスやポート番号などのヘッダの情報で判断する。処理が軽い
アプリケーションゲートウェイ：HTTPなどのアプリケーションの通信の中身まで確かめて中継できる。内部と外部の通信が直接つながらない。その分、処理の負荷は大きく、対応するアプリケーションごとに中継の機能が必要
ルール表の読み方と書き方
午後では、FWのルール表（フィルタリングルール）を読ませたり、空欄を埋めさせたりする設問がよく出ます。次は説明用の例です。
項番 送信元 宛先 サービス 動作
1 インターネット DMZのWebサーバ HTTPS 許可
2 DMZのWebサーバ 内部のAPサーバ HTTPS 許可
3 DMZのDNSサーバ インターネット DNS 許可
4 内部LANのPC プロキシサーバ HTTP・HTTPS 許可
5 プロキシサーバ インターネット HTTP・HTTPS 許可
6 全て 全て 全て 拒否読むときと書くときは、次の点を確かめます。
送信元は、通信を始める側：ステートフルインスペクションのFWなら、許可した通信への応答は自動で通るので、戻りのルールは書かないのが一般的。問題文の前提を確かめる
上から順に照合する：広い許可を狭い拒否より前に置かない。最後の行で、それ以外をすべて拒否する
必要な通信を漏れなく拾う：業務の通信だけでなく、名前解決（DNS）、時刻合わせ（NTP）、OSやソフトウェアの更新、認証の基盤への通信も必要になる。上の例の項番3は、DMZのDNSサーバが外部に名前解決するためのルール
迂回させない：項番4と5の組合せで、PCからインターネットへの通信はプロキシ経由に限られる。PCからインターネットへ直接出るルールを書かない
FWが許可したことは、安全の保証ではない
FWが分かるのは、通信の条件や状態がルールに合っていることだけです。感染した端末が外部へHTTPSで接続した場合、FWから見れば「内部から始まった、許可済みの接続」に見えることがあります。利用者が意図した通信か、送るデータが適切か、接続先が攻撃者のサーバでないかは、別の検査や端末側の対策で確かめます。
構成図には、通常の業務の通信だけでなく、DNS、認証、更新、バックアップ、監視、保守、障害時の迂回の経路も入れて確かめます。端末やサービスがIPv6も使っている環境では、IPv4だけに設定した制限では足りない場合があります。予備の回線や保守の経路がFWを通らなければ、そこが別の入口になります。
午後での問われ方
令和5年度春期 午後I問3：プロキシをクラウドサービスに移すことに伴う、ネットワーク構成の見直しが題材でした。採点講評では、番号の小さい順に照合するフィルタリングの設定表で、番号1と番号2を逆に答えた受験者が散見されたと指摘されています。ルールは、適用される順番で動作が変わります。
令和元年度秋期 午後I問2：マルウェアがパブリックDNSサービスを経由してC&C通信を行う手口への対策として、FWのフィルタリングルールを一つ変更する設問がありました。もとのルールの項番3は「送信元：全て、宛先：インターネット、サービス：DNS、動作：許可」で、社内のPCも外部のDNSサービスへ直接問い合わせられました。解答例は、項番3の送信元を「DMZ」に変えることです。インターネットへの名前解決をDMZのDNSサーバだけに許せば、PCからパブリックDNSサービスへの通信は、最後の「全て拒否」のルールで止まります。
記述の型
FWで防げない理由：「FWはIPアドレスとポート番号で判断するので、許可した通信の中身までは検査できない」
ルールの順番の不備：「先に一致する広い許可のルールがあるため、後ろの拒否のルールが適用されない」
ルールの変更：「項番○の送信元を、全てから○○（その通信が必要な機器）に限定する」
4. IDS・IPS・WAF・プロキシ：見るものと止める場所が違う
役割の違い
FW：IPアドレス・ポート番号・状態で、通信を許可・拒否する
IDS（侵入検知システム）：不正な通信の兆候を検知し、通知する
IPS（侵入防止システム）：不正な通信を検知し、遮断する
WAF（Webアプリケーションファイアウォール）：HTTPの要求の中身を検査し、Webアプリへの攻撃を遮断する
プロキシ：利用者に代わって通信を中継する
UTM（統合脅威管理）：FW、IPS、ゲートウェイでのマルウェア対策、URLフィルタリングなどを1台にまとめた装置。午後の構成図にもよく登場する。1台にまとめた分、その装置が止まると複数の対策が同時に止まる
IDSとIPS
ネットワーク型のIDSは、通信のコピーを受け取って検査する構成がある。この場合、IDSは通常の通信の通り道にいないので、検知しても通信を直接止められない
IPSは、通信の経路上で検査し、通過を制御する。止められる一方で、誤検知すると正規の通信まで遮断する
検知の方式には、既知の攻撃の特徴（シグネチャ）と照合する方式と、普段と違う振る舞いを異常とみなす方式がある。シグネチャ型は、登録されていない未知の攻撃を検知できない。異常を判定するしきい値は、低すぎると正常な通信まで異常と判定し、高すぎると攻撃を見逃す
端末やサーバに入れるホスト型のIPSもある。サーバ間の感染を止めたいなら、知らせるだけのIDSではなく、止められる仕組みを選ぶ
置き方の違い：IDSは、スイッチのミラーポート（通信のコピーを出すポート）やネットワークTAPにつないで、通信の写しを見る。IPSは、通信の経路の途中に直列に置く（インライン）。インラインの機器が故障すると通信が止まるので、故障時に通信を通すか止めるかも決めておく
WAF
公開WebサーバのTCP443番をFWで許可しても、その通信にSQLインジェクションの入力が含まれていないかまでは、FWには分かりません。WAFは、こうしたHTTPの中身に関わる検査を受け持ちます。検知の方式には、攻撃の特徴を登録して一致するものを止める方式（ブラックリスト型）と、正常な要求の形を登録してそれ以外を止める方式（ホワイトリスト型）があります。ブラックリスト型は未知の攻撃を見逃しやすく、ホワイトリスト型は正常な要求を止めないよう、登録に手間がかかります。ただし、WAFを置いてもアプリの脆弱性はなくなりません。検知ルールをすり抜けられる場合もあるので、根本対策はアプリの修正です（支援士解説2の5）。
プロキシ
フォワードプロキシ：社内の端末が外部のWebサイトへアクセスするとき、端末に代わって通信を中継する。アクセス先の制限（URLフィルタリング）、利用者との対応付け、ログの取得に使える
リバースプロキシ：外部からのアクセスをサーバの手前で受け付け、内部のWebサーバへ中継する。入口の集約、負荷分散、TLSの終端に使う
プロキシは、マルウェア対策にも効きます。利用者の認証を求めるプロキシ（認証プロキシ）を経由させると、利用者の認証情報を持たないマルウェアが外部の指令サーバ（C&Cサーバ）と通信しようとしても、プロキシ認証に失敗して止まることがあります。プロキシのログに残る「認証に失敗した外向きの通信」は、感染の手がかりになります。プロキシのログからは、いつ、どの利用者（または端末）が、どのURLに、どれだけの通信をしたかが分かります。決まった間隔で同じ宛先に通信している、業務時間外に大量の通信がある、といった傾向は、C&C通信や情報の持出しを疑う材料です（支援士解説3の4）。
ただし、プロキシを経由しない経路が残っていれば、その経路では同じ制御が働きません。端末から外部への直接の通信をFWで禁止し、プロキシからの通信だけを許可して、迂回できないようにします。
TLSの終端と検査
次の構成を考えます。ブラウザからリバースプロキシまではHTTPS、リバースプロキシから内部のWebサーバまではHTTPです（図4）。外から見えるURLはHTTPSでも、後半の区間までTLSで守られているとは限りません。
端末から入口までは、どの相手とTLSで接続するか
入口で復号した後、どの装置が平文を扱うか
入口から内部サーバまでもTLSを使うか
通信を暗号化すると、経路の途中にある検査装置（IDS・IPS・WAF）も、そのままでは中身を確認できません。検査するには、検査装置の手前でTLSを終端（復号）する構成が必要になります。その場合、その装置が平文や鍵を扱うことになるので、装置自体を守る必要があります。TLSと証明書の仕組みは支援士解説3の1で扱います。
午後での問われ方
令和元年度秋期 午後I問2：脅威インテリジェンスを活用したインシデント対応が題材でした。解答例では、マルウェアの通信が外部と成立しなかった理由として「プロキシ認証に失敗したから」が示されています。
令和5年度春期 午後I問3：プロキシをクラウドサービスに移した後の通信経路が問われました。解答例には「プロキシサーバではなく、Pサービスを経由させる」という変更が示され、採点講評では、見直し前と見直し後の通信経路を理解していないとみられる解答が散見されたと指摘されています。構成図から、通信がどこを経由するようになったかを読み取ります。
記述の型
IDSの限界：「通信経路上にないので、検知しても遮断できない」
IPSの注意点：「誤検知すると、正規の通信も遮断してしまう」
シグネチャ型の限界：「シグネチャが登録されていない未知の攻撃は検知できない」
しきい値が低すぎる弊害：「正常な通信を異常として検知してしまう」
認証プロキシの効果：「認証情報を持たないマルウェアの通信は、プロキシ認証に失敗して外部に出られない」
プロキシを迂回させない：「FWで、端末から外部への直接の通信を禁止し、プロキシからの通信だけを許可する」
構成図の問題では、通信がどの装置を、どの順に通るかを書き出してから考える
5. DNS：答えと、問い合わせ先の両方を守る
権威DNSサーバとフルサービスリゾルバ
DNSサーバには、役割の違う二つがあります。
権威DNSサーバ：自分が管理するドメインの情報を持ち、外部からの問い合わせに答える
フルサービスリゾルバ（キャッシュDNSサーバ）：社内の端末から問い合わせを受け、権威DNSサーバに順に問い合わせて答えを調べる。得た答えを一定期間キャッシュする
二つを分ける理由は、使わせる相手が違うからです。公開ドメインの情報は外部に答える必要がありますが、社内向けのリゾルバを外部の誰にでも使わせる必要はありません。外部の誰からでも再帰問い合わせを受け付けるリゾルバ（オープンリゾルバ）は、第三者への反射攻撃（9節）の踏み台にされます。リゾルバへの問い合わせは、社内からだけに制限します。
名前解決の流れとレコード
端末が www.example.jp のIPアドレスを調べるとき、次の順で問い合わせが進みます。
端末が、社内のフルサービスリゾルバに問い合わせる（再帰的な問い合わせ）
リゾルバは、キャッシュに答えがなければ、ルートサーバ、jpを管理する権威DNSサーバ、example.jpを管理する権威DNSサーバの順に問い合わせる（反復的な問い合わせ）
得た答えを端末に返し、TTL（有効期間）の間キャッシュする
午後の問題で読む主なレコードは、次のとおりです。
A・AAAA：名前に対応するIPv4・IPv6のアドレス
CNAME：別名。ある名前を、別の名前に向ける
MX：そのドメインのメールを受け取るサーバ（6節）
NS：そのドメインを管理する権威DNSサーバ
TXT：文字列の情報。SPF・DKIMの公開鍵・DMARCの設定は、ここに書く（6節）
PTR：IPアドレスから名前を引く（逆引き）
DNSの通信は、UDPとTCPの53番を使います。FWのルールでDNSを許可するときは、どちらも考えます。
キャッシュポイズニング
リゾルバのキャッシュに偽の答えを覚えさせ、利用者を攻撃者のサーバへ誘導する攻撃です。対策には、問い合わせのIDや送信元ポート番号を推測しにくくすること（送信元ポートのランダム化）、応答と問い合わせの対応を厳密に確かめること、DNSSECで応答を検証することがあります。なお、偽のサーバに誘導されても、HTTPSのサーバ証明書の検証まで自動的に破られるわけではありません。対策の層を分けて考えます。
DNSSECとDoH・DoT
DNSSEC：DNSの応答にデジタル署名を付け、受け取った側が検証できるようにする。署名の公開鍵の正しさは、親のゾーン（ルートからjp、example.jpへ）からつながる信頼の連鎖で確かめる。応答が正当で、改ざんされていないことを確かめる仕組みで、通信を暗号化するものではない
DoH（DNS over HTTPS）・DoT（DNS over TLS）：端末とリゾルバの間などのDNSの通信を、HTTPSやTLSで暗号化する
DNSSECは答えの検証、DoH・DoTは通信の保護です。どちらか一方で、もう一方の目的まで満たせる関係ではありません（図5）。ブラウザが組織の管理外のDoHサービスに直接問い合わせると、組織のDNSサーバのフィルタや記録を通らなくなることにも注意します。
DNSを悪用する攻撃と、運用の落とし穴
DNSトンネリング：DNSの問い合わせの中にデータを埋め込み、外部と通信する手口。マルウェアのC&C通信や、情報の持出しに使われる。社内のリゾルバを経由して外部に出ていくので、DNSの通信を許可している限り止めにくい。DNSの問い合わせのログから、特定のドメインへの不審な大量の問い合わせを見つける
サブドメインテイクオーバー：使い終わった外部サービスを指すCNAMEレコードが残ったままになっていると、第三者がそのサービス側の名前を取得し、自社のサブドメインで偽のサイトを公開できてしまう。サービスの利用を終えたら、権威DNSサーバのCNAMEレコードを削除する
DNSの安全は、サーバのソフトウェアだけでは決まらない。ドメインの管理アカウント、DNSレコードを編集できる権限、ドメインや証明書の期限も関係する。ドメイン名の管理は支援士解説1の4で扱う
ゾーン転送（権威DNSサーバ間でゾーンの情報を丸ごと複製する仕組み）は、許可する相手を必要なサーバだけに絞る
リゾルバで問い合わせのログを残しておくと、感染した端末がどのドメインを引いたかを後から調べられる。C&Cサーバのドメインが分かったときに、そのドメインを問い合わせた端末を特定できる
午後での問われ方
令和7年度秋期 午後問3：リモートワーク環境の導入が題材でした。DNSの応答の署名を検証する仕組み（DNSSEC）と、HTTPSやTLSでDNSの通信を暗号化する仕組み（DoH、DoT）を、説明文から答えさせる設問がありました。
令和7年度春期 午後問4：使わなくなったドメインや公開されたままのWebサーバが悪用される攻撃が題材でした。解答例の対策は「権威DNSサーバで、終了したサブドメインのCNAMEレコードを削除する」です。
令和元年度秋期 午後I問2：DNSを悪用したC&C通信（DNSトンネリング）の仕組みが問われました。攻撃者は攻撃用のドメインを取得し、その「権威DNSサーバ」をC&Cサーバとして用意します。マルウェアが「外部DNSサーバ」に攻撃用ドメインについての「再帰的クエリ」を送ると、その問合せがC&Cサーバまで届きます。大量の情報を持ち出すときの兆候として、解答例は「特定のドメインに対する多数のDNSクエリの発生」です。採点講評では、この仕組みを問う設問の正答率が全体的に低かったとされ、組織内でフルサービスリゾルバとして動くDNSサーバが悪用される手法だと説明されています。
記述の型
キャッシュポイズニングの対策：「送信元ポート番号をランダム化する」「DNSSECで応答の署名を検証する」
DNSSECとDoH・DoTの違い：「DNSSECは応答の正当性を検証し、DoH・DoTはDNSの通信を暗号化する」
踏み台にならない対策：「フルサービスリゾルバへの問い合わせを、内部からだけに制限する」
DNSトンネリングの検知：「DNSの問い合わせのログから、特定のドメインへの大量の問い合わせを見つける」
サブドメインテイクオーバーの対策：「利用を終えたサブドメインのCNAMEレコードを削除する」
6. メール：配送の仕組みと送信ドメイン認証
メールの配送
メールは、次の順で届きます（図6）。
送信：利用者のメールソフトが、自組織（またはプロバイダ）のメールサーバに、メールを送る
配送：送信側のメールサーバが、宛先のドメインのDNSのMXレコード（そのドメインのメールを受け取るサーバ）を調べ、相手のメールサーバにSMTP（TCP25番）で配送する
受信：受信者は、POP3やIMAP（またはWebメール）で、自分のメールボックスからメールを読む
送信の部分には、なりすましと迷惑メールを防ぐ仕組みが重ねられています。
サブミッションポート（TCP587番）とSMTP-AUTH：利用者がメールサーバにメールを送るときは、配送用の25番ではなく587番を使い、SMTP-AUTHで利用者を認証する。認証した利用者だけに送信を許す
OP25B（Outbound Port 25 Blocking）：ISPが、自社の動的IPアドレスの利用者から、外部のメールサーバの25番への直接の通信を遮断する。感染した家庭のPCなどが、迷惑メールを直接ばらまくのを防ぐ。利用者は、プロバイダのメールサーバに587番で送ればよい。受信する側のメールサーバで、ISPの動的IPアドレスから自サーバの25番への接続を拒否する対策は、IP25B（Inbound Port 25 Blocking）と呼ぶ
第三者中継の禁止：自組織の利用者でも自組織宛てでもないメールを、外部から受け取って中継するメールサーバ（オープンリレー）は、迷惑メールの踏み台にされる。メールサーバは、中継を許す送信元を限定する
通信の暗号化も、区間ごとに考えます。SMTPの通信をTLSで暗号化するのがSMTPSやSTARTTLSで、これはサーバ間などの通信路の保護です。S/MIMEは、証明書を使ってメールの本文と添付ファイルを暗号化し、署名する仕組みで、目的が違います。
二つの差出人
メールには、見えている差出人とは別の差出人の情報があります。
ヘッダFrom：メールのヘッダに書かれ、メールソフトで差出人として表示される
エンベロープFrom：SMTPのMAIL FROMで指定される、配送上の差出人。配送エラーの返送先にもなる
攻撃者は、表示されるヘッダFromを自由に書けます。送信ドメイン認証は、どのドメインを確かめているかが三つの仕組みで違います。
SPF：送信元のIPアドレスで確かめる
ドメインの管理者が、そのドメインのメールを送ってよいサーバのIPアドレスを、DNSのSPFレコードに登録する
受信側は、接続してきた送信元IPアドレスが、エンベロープFrom（MAIL FROM）のドメインのSPFレコードに登録されているかを照合する。ヘッダFromのドメインを確かめているのではない
外部のメール配信サービスから自社のドメインでメールを送るなら、そのサービスの送信元をSPFレコードに追加しておく
メールが転送されると、受信側から見える送信元IPアドレスが転送したサーバのものに変わり、SPFは失敗しやすい
DKIM：デジタル署名で確かめる
送信側が、メールのヘッダや本文から計算したデジタル署名を、DKIM-Signatureヘッダに付ける。署名したドメインは「d=」、公開鍵を探すための名前（セレクタ）は「s=」に書かれる
受信側は、「セレクタ._domainkey.ドメイン名」のDNSレコードから公開鍵を取得し、署名を検証する
署名の対象に含めたヘッダ（「h=」に並ぶSubjectなど）や本文が途中で書き換えられると、検証に失敗する。メーリングリストが件名に通番を付けると、DKIMが失敗するのはこのため
DKIMは本文を暗号化するものではなく、記載内容が真実であることを証明するものでもない
DMARC：見えている差出人と結び付ける
DMARCは、SPFやDKIMの認証結果に加えて、ヘッダFromのドメインとの整合（アラインメント）を確かめます。合格の条件は、次のどちらかです。
SPFに合格し、そのMAIL FROMのドメインが、ヘッダFromのドメインと整合する
DKIMに合格し、その署名ドメインが、ヘッダFromのドメインと整合する
両方の成功が必須なのではなく、少なくとも一方で、認証の成功と整合がそろえば合格です。整合には厳格なモードと緩和されたモードがあります。
架空の通知メールで考えます（図7）。表示上のFromのドメインは city.example、MAIL FROMのドメインは配信サービスの sender.example、DKIMの署名ドメインは city.example です。
SPFは sender.example として成功するが、city.example とは整合しない
DKIMは署名ドメインが city.example で成功し、表示上のドメインと一致する
DKIMの側で認証の成功と整合がそろうので、DMARCに合格する
DMARCでは、不合格のメールの扱いを、ドメインの管理者がDNSに公開します。p=none（特別な扱いを求めない）、p=quarantine（隔離）、p=reject（受信拒否）の三つです。ただし、これは送信側のドメインが示す方針で、最終的にどう処理するかは受信側の判断も関わります。いきなりrejectにすると、設定漏れがあった正規のメールまで届かなくなります。まずnoneで運用し、受信側から届く集計レポートで認証の状況を確かめてから、quarantine、rejectと強めていくのが一般的です。
レコードの例
三つの仕組みは、どれもDNSのTXTレコードに設定を書きます。次は説明用の例です（ドメインはexample.jp）。
example.jp. TXT "v=spf1 ip4:192.0.2.10 include:_spf.mail-service.example -all"
sel1._domainkey.example.jp. TXT "v=DKIM1; k=rsa; p=（公開鍵）"
_dmarc.example.jp. TXT "v=DMARC1; p=none; rua=mailto:dmarc-report@example.jp"SPF：ip4で、送信を許すIPアドレスを書く。includeで、外部のメール配信サービスが公開している設定を取り込む。最後の-allは、どれにも当たらない送信元を不合格（fail）にする指定。~allなら、不合格の扱いを弱めたsoftfailになる
DKIM：公開鍵は「セレクタ._domainkey.ドメイン名」の名前で公開する。この例ではセレクタがsel1。署名のs=にsel1、d=にexample.jpが書かれていれば、受信側はこの名前の公開鍵を取得する
DMARC：「_dmarc.ドメイン名」の名前で公開する。pが不合格時の方針、ruaが集計レポートの送り先
メールのヘッダを読む
フィッシングメールを調べる問題では、メールのヘッダが示されることがあります。読み方の要点は次のとおりです。
Received: from mx.example.jp ...（最後に受け取ったサーバが、いちばん上に追記する）
Received: from mail.sender.example ...（送信元に近いサーバほど、下にある）
Return-Path: <bounce@sender.example>（エンベロープFrom）
Authentication-Results: mx.example.jp; spf=pass ...; dkim=pass ...; dmarc=pass ...
From: 総務課 <notice@example.jp>（ヘッダFrom）Received：メールを中継した各サーバが、受け取るたびに上に追記する。下から上へ読むと、送信元から届くまでの経路が分かる。ただし、送信元が自分で書いた部分は偽れるので、自組織のサーバが追記した行から信用する
Return-Path：配送に使われたエンベロープFrom（MAIL FROM）
Authentication-Results：受信したサーバが、SPF・DKIM・DMARCの検証結果を記録する
表示上のFromと、Return-PathやDKIMの署名ドメインが違う場合は、DMARCの整合を確かめる
送信ドメイン認証で防げないもの
攻撃者が自分で取得した、よく似た別のドメインから、正しく認証を通したメール
表示名だけを取引先の名前にしたメール
正規のメールアカウントが乗っ取られて送られたメール
認証に合格しても、本文・添付ファイル・URLが安全とは限りません。金銭や権限に関わる依頼は、別の経路で確かめます。
午後での問われ方
令和6年度秋期 午後問2：メールのドメイン名の変更をきっかけに、DMARCの導入が大問の題材になりました。解答例では、外部のメールサービスのメール送信元IPアドレスをSPFレコードに追加すること、SPFレコードに登録されていないサービスからメールが送られることや、DKIMのhタグにSubjectが含まれているのにサービスで件名が変わることが、認証の失敗の原因として示されています。SMTPの通信を暗号化する方式としては、SMTPSが答えになっています。
令和元年度秋期 午後I問1：送信ドメイン認証が題材でした。採点講評では、SPFが確かめるのがSMTPのMAIL FROM（エンベロープFrom）のドメインであることの正答率が低かったと指摘されています。
午前IIで正誤を見分けるポイント
「OP25Bは、ISPの利用者が受信するメールを制限する」→ 誤り。外部のメールサーバの25番への送信を制限する
「サブミッションポートを使えば、利用者の認証は不要」→ 誤り。サブミッションポートはSMTP-AUTHによる認証と組み合わせて使う
「SPFは、ヘッダFromのドメインを検証する」→ 誤り。エンベロープFrom（MAIL FROM）のドメイン
「DMARCに合格するには、SPFとDKIMの両方の合格が必要」→ 誤り。少なくとも一方で、認証と整合がそろえばよい
「SMTPSでメールを送れば、受信者以外は本文を読めない」→ 誤り。SMTPSは通信路の保護。保存されたメールの本文を守るのはS/MIMEなど
記述の型
SPFの仕組み：「送信元のIPアドレスが、エンベロープFromのドメインのSPFレコードに登録されているかを確認する」
外部サービスから送るときの設定：「SPFレコードに、外部サービスの送信元IPアドレスを追加する」
転送でSPFが失敗する理由：「転送すると、送信元のIPアドレスが転送したサーバのものに変わるため」
DKIMが失敗する原因：「署名の対象となるヘッダ（hタグに含まれるSubjectなど）や本文が、途中で書き換えられる」
SPF・DKIMだけでは不十分な理由：「ヘッダFromのドメインが詐称されていても検出できない」
DMARCの導入手順：「最初はp=noneで運用し、レポートで状況を確認してから、quarantine・rejectへ強める」
7. 無線LAN：通信の保護と、接続する人の認証
電波は壁を越えて届くので、無線LANには建物の外からでも接続を試みられます。守る対象は二つです。通信の中身（暗号化）と、接続を許す相手（認証）です。
SSIDを隠す、MACアドレスで接続を制限する：どちらも強い対策にはならない。SSIDは通信から分かり、MACアドレスは書き換えてなりすませる
暗号化の方式：WEPは使わない。WPA2またはWPA3を使う。WPA3のPersonalでは、SAEという鍵交換によって、盗聴したデータへの総当たり攻撃への耐性が高められている
Personal：全員が共通の事前共有鍵（PSK）で接続する。誰が接続したかを区別しにくく、退職者が出るたびに全員の鍵を変えるのは負担が大きい。鍵が漏れたときの影響も広い
Enterprise：IEEE 802.1Xに基づき、RADIUSサーバと連携して、利用者や端末ごとに認証する。特定の端末だけを失効させられる。認証の方式（EAP）のうち、EAP-TLSは、端末に入れたクライアント証明書で認証する。PEAPは、サーバ証明書で作ったTLSの通信路の中で、利用者IDとパスワードで認証する。どちらの方式でも、端末は認証サーバの証明書を検証する
偽のアクセスポイント：攻撃者が同じSSIDのアクセスポイントを用意すると、端末が誤って接続することがある。接続させられると、攻撃者は通信を中継し、利用者を偽のサイトへ誘導できる。端末側でも、接続先の認証サーバの証明書を検証する。ブラウザが示すサーバ証明書の警告（信頼された認証局から発行されたものではない、証明書のサーバ名が接続先と違う）を無視しない（証明書の検証は支援士解説3の1）
来客用の無線LAN：職員用とSSIDを分けるだけでなく、その先のネットワークで、社内のサーバへ到達できないように分離する。来客の端末同士の通信を遮断する設定（プライバシーセパレータなど）も検討する。来客用からインターネットに出るときの送信元IPアドレスを、社内用と分けておくと、外部サービスの接続元制限を社内用だけに絞れる
無線LANの暗号化が守るのは、端末とアクセスポイントの間の電波の区間だけ。その先の有線網やインターネット上の通信は、別に守る
不正なアクセスポイント：職員が許可なく持ち込んだ無線LANルータを社内LANにつなぐと、そこが管理外の入口になる。無線の電波を監視して、登録していないアクセスポイントを見つける仕組みもある
午後での問われ方
令和5年度秋期 午後問2：来客用の無線LANがある環境の見直しが題材でした。解答例には、RADIUSによる認証、EAP-TLSのクライアント証明書の秘密鍵を業務PCから取り出せないようにすること（そうすれば、EAP-TLSに必要な認証情報は業務PCにしか置けない）、来客用無線LANからインターネットに出るときの送信元IPアドレスを社内用と別にすることが示されています。 同じ問題では、攻撃者が用意した偽のサイトにつながったとき、ブラウザが示すサーバ証明書の警告の内容として、「信頼された認証局から発行されたサーバ証明書ではない」「証明書に記載されているサーバ名が、接続先のサーバ名と異なる」も答えになっています。
記述の型
PSKの課題：「全員が同じ鍵を使うので、利用者を識別できず、退職者が出るたびに鍵を変える必要がある」
EAP-TLSで業務PCだけを接続させる：「クライアント証明書の秘密鍵を、業務PCから取り出せないように格納する」
来客用の分離：「来客用無線LANから社内ネットワークへの通信を遮断し、インターネットへの送信元IPアドレスを社内用と分ける」
偽のアクセスポイントへの対策：「端末で、接続先の認証サーバの証明書を検証する」
8. VPN・リモートアクセス
方式
IPsec：IPのレベルで通信を暗号化する。認証だけを行うAHと、暗号化も行うESPがある。ESPのトンネルモードは元のIPヘッダを含めて暗号化し、新しいIPヘッダを付ける。トランスポートモードはデータの部分だけを暗号化する
SSL-VPN（TLSを使うVPN）：TLSで通信を暗号化する。ブラウザや専用のソフトで使える
IKE：IPsecで使う暗号の鍵を、通信の相手と安全に交換する手順
VPNは通信の経路を守る仕組みで、つないだ端末を安全にするものではありません。感染した端末がVPNで接続すれば、その通信も社内に入ってきます。
接続する人の認証を強くする（多要素認証）
接続する端末を限定し、接続のときにOSのバージョンや修正プログラムの適用状況などを確かめる。条件を満たさない端末を、社内につなぐ前に隔離して対策させる仕組みを、検疫ネットワークという
接続した後に届く社内の宛先とポートを、必要な範囲に絞る
スプリットトンネルは、社内宛ての通信だけをVPNに流し、それ以外のインターネット向けの通信を端末から直接出す構成です。本社の回線の負荷は下がりますが、組織のプロキシやセキュリティ装置を通らない通信が生まれます。
リモートアクセスの方式の比較
VPN：端末を社内のネットワークにつなぐ。つながった後は、社内の広い範囲に届きやすい
VDI（仮想デスクトップ）：処理とデータをサーバ側に置き、端末には画面だけを送る。端末にデータが残りにくい
ZTNA：利用者と端末の状態を確かめ、許可したアプリケーションにだけ接続させる。ネットワーク全体にはつながらない
どれを選んでも、利用者の認証、端末の状態の確認、接続した後の権限の制限が必要なことは変わりません。VDIとZTNAの設計は支援士解説2の3で扱います。
VPN装置が狙われる
VPN装置は、インターネットに公開され、通れば社内に入れる装置なので、攻撃者に狙われやすい入口です。製品名や型番から既知の脆弱性を調べられ、悪用されて侵入される事例が続いています。修正プログラムを速やかに適用することが基本です（脆弱性への対応は支援士解説3の6）。VPN装置の認証のログ（いつ、どの利用者が、どこから接続したか）を残し、普段と違う国や時間帯からの接続、短時間に繰り返される認証の失敗を見つけます。
装置を外から見えにくくする方法もあります。ポートスキャンに応答しないようにし、許可した端末からの接続だけを受け付けます。
ポートノッキング：決めた順番で複数のポートに接続要求を送ると、ポートが開く。ただし、盗聴したパケットと同じ順番で接続要求を送られると、突破される
SPA（Single Packet Authorization）：認証情報を含む一つのパケットを送ってポートを開く。パケットはそのたびに一意で、同じパケットを再利用すると破棄されるので、盗聴して再送されても通らない
利用者の身元と端末の状態を確かめ、許可したアプリケーションにだけ接続させるZTNAの考え方は、支援士解説2の3で扱います。
午後での問われ方
令和6年度春期 午後問2：VPNを狙う攻撃とDDoS攻撃への対策が題材でした。解答例には、ポートノッキングの弱点として「盗聴したパケットと同じ順番に通信要求を送信する」こと、SPAが盗聴に強い理由として「SPAパケットはユニークであり、同じパケットを再利用すると破棄される」ことが示されています。
令和7年度秋期 午後問3：HTTPSを使うVPNサービスの導入が題材でした。解答例には、設定サイトへの接続元IPアドレスを自社のアドレスに制限することや、FWで許可する宛先として、VPNサービスだけでなく、OSの更新の配布サイトや認証基盤などへのHTTPSも挙げられています。VPNにつなぐ前に必要な通信を見落とさないことが鍵です。
記述の型
AHとESPの違い：「AHは認証だけを行い、暗号化はESPで行う」
VPN装置への攻撃：「製品名や型番から脆弱性を調べ、悪用して侵入する」
ポートノッキングの弱点：「盗聴したパケットと同じ順番に通信要求を送信される」
SPAが盗聴に強い理由：「SPAパケットはユニークであり、同じパケットを再利用すると破棄される」
9. DoS・DDoS：どこが詰まるかで、対策が変わる
DoS攻撃は、大量の通信や不正な通信を送り付けて、サービスを止める攻撃です。乗っ取った多数の機器（ボットネット）から一斉に仕掛けるものを、DDoS攻撃（分散型サービス妨害攻撃）といいます。攻撃は、何を使い切らせるかで分けると整理しやすくなります。
回線を詰まらせる：大量のパケットで回線の帯域を埋める。UDPフラッドや、次の反射型の攻撃
サーバの接続の管理を詰まらせる：SYNフラッド。TCPの接続要求（SYN）だけを大量に送り、相手が確立を待つ状態を溜めさせて、正規の接続を受けられなくする
アプリケーションを詰まらせる：HTTP GETフラッド。Webページの要求を大量に繰り返す。正規のアクセスと形が同じなので、パケットの形式だけでは見分けにくい
接続を長く占有する：Slow HTTP DoS。HTTPの要求をわざとゆっくり少しずつ送り続け、サーバの同時接続の枠を長時間ふさぐ。少ない通信量でも成立する
反射型（リフレクション）攻撃は、送信元IPアドレスを標的のアドレスに偽って、第三者のサーバに問い合わせを送り、その応答を標的に集中させる攻撃です。DNSやNTPのように、小さな問い合わせに大きな応答を返すサービスを使うと、通信量が増幅されます（アンプ攻撃）。
対策は、詰まる場所に合わせて選びます。
回線に届く前に止める：自社のFWで遮断しても、手前の回線が詰まっていれば手遅れ。DDoS対策の機能を持つCDNサービスや、ISPが提供するDDoS防御サービスなど、外部のサービスで止める
SYNフラッド：SYN Cookieを使い、確立を待つ状態をサーバに溜めないようにする
HTTP GETフラッド：同じ送信元からの要求の回数を制限する（レート制限）。WAFやCDNで、振る舞いを見て遮断する
Slow HTTP DoS：接続のタイムアウトを短くし、1つの送信元からの同時接続数を制限する
接続元を限定できるサービス：取引先向けのサーバなら、接続元を取引専用の端末に限定すれば、それ以外からの通信は届かない
踏み台にならない：自組織のリゾルバを外部から使えないようにする（5節）。送信元IPアドレスを偽ったパケットを、自組織から外に出さない
自組織の機器を乗っ取られない：ボットネットには、初期のパスワードのままのIoT機器（ネットワークカメラやルータなど）が多く使われてきた。代表的な例が、2016年に大規模なDDoS攻撃を起こしたマルウェアのMirai。機器の初期パスワードを変え、管理画面をインターネットに公開しない
攻撃の兆候は、回線の使用率、サーバの同時接続数、応答時間の監視で早めにつかみます。外部の防御サービスは、攻撃を受けてから契約したのでは間に合わないことがあるので、平時に準備しておきます。
午後での問われ方
令和6年度春期 午後問2：DDoS攻撃への対策が問われました。解答例には、公開Webサーバと取引先向けWebサーバを対象にHTTP GETリクエストを繰り返し送る攻撃、IPSのしきい値を低くしすぎると「正常な通信を異常として検知してしまう」こと、回線への攻撃に使う外部のサービスとして「DDoS対策機能を有するCDNサービス」「クラウド型ファイアウォールサービス」「ISPが提供するDDoS防御サービス」が示されています。
記述の型
回線への攻撃への対策：「DDoS対策機能を有するCDNサービスやISPのDDoS防御サービスを利用する」
SYNフラッドの対策：「SYN Cookieを用いる」
反射型の踏み台にならない対策：「リゾルバへの問い合わせを、内部からだけに制限する」
10. 機器の管理と運用
ネットワーク機器は、導入した後も設定が変わります。次の点を運用に含めます。
管理画面と管理用の経路：管理画面を外部に公開しない。管理は専用の経路と、担当者ごとのアカウントで行う
初期設定の見直し：初期のパスワードや、使わないサービスを残さない（導入時の設定の見直しは支援士解説2の2）
変更の管理：設定の変更は、変更の内容・理由・承認者を記録し、変更後に意図しない経路が開いていないかを確かめる
IPv6：IPv4とIPv6の両方が動く環境では、IPv6の通信にも同じ制限をかける
冗長化：回線や機器が一つ壊れただけで業務が止まらないようにする。障害で予備の経路に切り替わったときも、同じ制限が働くかを確かめる
機器の監視とログ：SNMPで機器の状態を集める。SNMPv1・v2cのコミュニティ名は平文で流れるので、認証と暗号化に対応したSNMPv3を使う。機器のログはsyslogでログサーバに集め、NTPで全機器の時刻を合わせる。時刻がずれていると、複数の機器のログを突き合わせられない
遠隔保守の経路の管理は支援士解説2の7、持ち出す端末の管理は支援士解説3の7で扱います。
11. 構成図問題の読み方
ネットワークの午後の問題では、次の順に読むと、見落としが減ります。
区画と機器に印を付ける：インターネット、DMZ、社内LAN、無線LAN、クラウドサービス。それぞれにある機器（FW、UTM、プロキシ、DNSサーバ、メールサーバ）を確かめる
問われている通信の始点と終点を決める：誰が、どこへ、どのサービスで通信するか
経路上の機器を順にたどる：始点から終点まで、どの機器をどの順に通るかを書き出す。NATで送信元のアドレスが変わる地点にも印を付ける
機器ごとに、何を確かめられるかを考える：FWはアドレスとポート、プロキシはURLと利用者、IPSは攻撃の特徴、WAFはHTTPの中身。その通信を止めたいなら、どの機器で止めるのが確実か
ほかの経路がないかを探す：保守の経路、予備の回線、プロキシを通らない直接の通信、組織の管理外のDNS
見落としやすい通信を足す：DNS、時刻合わせ、OSの更新、認証の基盤。VPNやクラウドサービスに切り替える問題では、つなぐ前に必要な通信を見落としやすい
構成の見直しの問題（プロキシをクラウドに移す、VPNをZTNAに替えるなど）では、見直し前と見直し後で、経路がどう変わったかを並べて書き出すのが近道です。
12. 午前II（科目A-2）で正誤を見分けるポイント
「IDSは、不正な通信を検知すると遮断する」→ 誤り。IDSは検知して知らせる。遮断するのはIPS
「VLANを分ければ、区画間の通信は自動的に遮断される」→ 誤り。区画間のアクセス制御が必要
「ステートフルインスペクションは、アプリケーションのデータの中身まで検査する」→ 誤り。通信の状態を確かめる。中身の検査はWAFやIPSなど
「NATを使えば、外部からの攻撃はすべて防げる」→ 誤り。NATはアドレスの変換で、アクセス制御ではない
「IPsecのAHで、通信を暗号化できる」→ 誤り。AHは認証と改ざんの検知。暗号化はESP
「SSIDを隠せば、第三者は接続できない」→ 誤り。SSIDは通信から分かる
「DNSSECは、DNSの通信を暗号化する」→ 誤り。応答の署名を検証する仕組み。暗号化はDoH・DoT
「オープンリゾルバは、DNSのリフレクション攻撃の踏み台にされるおそれがある」→ 正しい
「プロキシを導入すれば、端末からインターネットへの直接の通信も自動的に止まる」→ 誤り。FWで直接の通信を禁止する必要がある
「WPA2-Personalの事前共有鍵を長く複雑にすれば、利用者ごとに接続を取り消せる」→ 誤り。全員が同じ鍵を使う限り、利用者ごとの失効はできない。利用者ごとの認証はEnterprise（IEEE 802.1X）で行う
理解度チェック
本文の理解を確かめるためのオリジナル問題です。実際の過去問ではありません。
問1 VLANと区画間の通信
職員用と来訪者用をVLANで分けた。来訪者用から社内のサーバへの通信を確実に止めるために、最も適切なものはどれか。
ア：VLANを分けたので、追加の設定は不要である
イ：来訪者用のSSIDを非公開にする
ウ：区画間の通信を中継する機器で、来訪者用から社内サーバへの通信を拒否するアクセス制御を設定する
エ：来訪者の端末のMACアドレスを登録する
正解：ウ。VLANを分けても、区画間を中継する機器が自由に通せば通信できます（ア）。イとエは接続の制限としても弱く、区画間の通信は止められません。
問2 FWのルールの順番
上から順に照合し、最初に一致したルールを適用するFWで、データベースへの直接の接続を拒否したい。拒否が効かない原因として、最も適切なものはどれか。
ア：拒否のルールより前に、サーバ区画全体への通信を許可するルールがある
イ：拒否のルールが、最後の「それ以外は拒否」より前にある
ウ：ステートフルインスペクションを使っている
エ：送信元ポート番号を指定していない
正解：ア。広い許可のルールが先に一致するため、後ろの拒否に届きません。
問3 DNSSEC
DNSSECの説明として、最も適切なものはどれか。
ア：DNSの問い合わせと応答を暗号化し、問い合わせた名前を第三者から隠す
イ：DNSの応答のデジタル署名を検証し、応答が改ざんされていないことを確かめる
ウ：リゾルバへの問い合わせを、社内からだけに制限する
エ：DNSのUDP通信をTCP通信に置き換える
正解：イ。アはDoH・DoTの説明です。ウはオープンリゾルバの対策で、DNSSECとは別のものです。
問4 SPF
SPFの説明として、最も適切なものはどれか。
ア：受信側は、メールのヘッダFromのドメインのSPFレコードを参照する
イ：送信側は、メール本文にデジタル署名を付ける
ウ：受信側は、接続してきた送信元IPアドレスが、エンベロープFromのドメインのSPFレコードに登録されているかを確かめる
エ：SPFに合格すれば、ヘッダFromの詐称も検出できる
正解：ウ。アとエは、SPFがヘッダFromを確かめていないことを見落としています。イはDKIMの説明です。
問5 認証プロキシ
社内の端末が外部のWebサイトへアクセスするとき、利用者の認証を求めるプロキシを経由させている。この構成の効果として、最も適切なものはどれか。
ア：利用者の認証情報を持たないマルウェアが外部と通信しようとしても、プロキシ認証に失敗して外部に出られない
イ：端末から外部への直接の通信を、FWで許可していても迂回されない
ウ：Webサイトから配布されるファイルの安全性が保証される
エ：DNSトンネリングによる通信も止められる
正解：ア。イは、直接の通信を許していれば、プロキシを迂回されます。ウは保証されません。エのDNSの通信は、Webのプロキシを通りません。
実務と国・自治体では
実務では、構成図に描かれた通常の経路だけでなく、保守の経路、予備の回線、障害時の切替え、一時的な設定変更が穴になりがちです。調達では、入口・データ連携・管理の経路ごとに、認証・権限・暗号化・作業の時間を仕様に書きます。受入れでは「必要な通信が通ること」と「不要な通信が通らないこと」の両方を確かめます。
政府機関等の統一基準には、通信回線の導入時・運用時の対策と、外部との接続の管理が示されています。総務省の自治体向けガイドラインにも、ネットワークの設定の整合、遠隔保守の保護、外部のシステムとの接続の管理の例文があります。これらの資料の位置付けは支援士解説1の1で整理しています。
まとめ
分けただけでは守れない。 VLANやDMZで分けた後、区画間で必要な通信だけを許可する。内部から外部へ出る通信も絞る。
装置ごとに、見るものと止める場所が違う。 FWはアドレスとポート、WAFはHTTPの中身、IDSは知らせるだけ、IPSは止める。プロキシは迂回させない設計とセットにする。
DNSとメールは「何を確かめたか」で読む。 DNSSECは答えの検証、DoHは通信の暗号化。SPFはエンベロープFrom、DMARCはヘッダFromとの整合。
VPNとDDoS対策は、入口の外側から考える。 VPN装置そのものが狙われ、DDoSは回線に届く前に止める。
さらに深く学ぶなら
この記事の範囲を超えて、仕組みをもっと深く知りたい人向けの本です（試験対策の本ではありません）。
IP・TCP/UDP・ルーティングなど、ネットワークの仕組みを基礎から学べる
DNSの仕組みと運用を、DNSの運用者の視点で詳しく学べる
関連記事
次に読む：暗号化すれば全て安全？｜支援士解説3の1（TLSと証明書）
あわせて読む：安全な機器も、つなぎ方で守りは変わる｜支援士解説2の3（ゼロトラスト・OTの分離）
あわせて読む：ログを取るだけで攻撃に気付ける？｜支援士解説3の4（FW・プロキシ・DNSのログの読み方）
2026年10月改訂：午後の出題例と記述の型を加え、メール配送・プロキシ・無線LAN・DDoSを厚くし、構成を見直しました。
