← トップ(目次) ② ルーティング OSPF BGP VRRP IPv6 IPマルチキャスト ③ セキュリティ 拠点間VPN プロキシとSWG 認証連携 ④ クラウド・DC ロードバランサー VXLANとEVPN ⑤ DNS・メール DNS メールと送信ドメイン認証 ① LAN冗長化 L2冗長化 | 全分野の用語ドリル
プロキシと SWG とは ── 実機を触ったことがない人のための Web アクセスの中継と制御
午後のセキュリティ分野で、社内から Web へ出る通信の話が出ると必ずプロキシサーバ が登場し、近年はその置き換え先としてセキュア Web ゲートウェイ(SWG) が出ます。
一言で言えば「社内の PC を直接インターネットに出さず、代理の 1 台を通して検査・記録する 」仕組みですが、設問では
「HTTPS をどう中継するか、中身を見るには何が要るか、クラウドに移すと何が変わるか」まで問われます。1 台のプロキシを置いた会社を例に、順に説明します。
1. 何を解くか 2. フォワードプロキシの動作 3. HTTPS の中継と TLS 復号 4. FW・IDS/IPS・WAF との役割分担
5. クラウド型 SWG への移行 6. 用語集 7. 午後での問われ方 8. ミニ確認問題
用語の振り返り 関係の深いページ
1. プロキシが解いている問題
内部セグメント
DMZ
インターネット
Web サーバ
PC
PC
L3SW
プロキシ 10.0.1.80:8080
FW
①
②
× PC から直接インターネットへは FW が拒否
① PC → プロキシ(宛先はプロキシ、8080) ② プロキシ → Web サーバ(送信元はプロキシ)
FW のルールは「内部 → インターネット」を全部拒否し、「プロキシ → インターネット 80/443」だけ許可
図1 フォワードプロキシの基本配置。以下の説明はすべてこの図で進める
PC がそれぞれ勝手にインターネットへ出る構成では、「誰がどこへアクセスしたか」が分からず、危険なサイトも止められません。
そこで社内のすべての Web 通信を DMZ のプロキシサーバ に集め、FW では「PC から直接インターネットへ」を拒否します。プロキシを置く目的は次の 4 つで、設問で「目的を 2 つ答えよ」と来たらここから選びます。
目的 内容 出た年度
URL フィルタリング 登録した FQDN や IP アドレス宛ての通信をブロック(業務外サイト、マルウェア配布サイト、C&C サーバ) R7 午後Ⅰ問3 設問1(2)
アクセスログ 誰が・いつ・どこへ。インシデント時に複数機器のログを時系列で突き合わせる ために、syslog サーバで集約し時刻同期(NTP)しておく R7 午後Ⅰ問3 設問1(1)(2)
利用者認証 プロキシ認証で利用者 ID を確認し、ログに残す。認証サーバ(LDAP/AD)と連携 R7 午後Ⅰ問3、H30 午後Ⅰ問1 設問1(2)、H28 午後Ⅰ問2 設問4
送信元 IP の集約 外から見た送信元がプロキシのグローバル IP 1 つになる。SaaS 側で「この IP からだけ許可」ができる R5 午後Ⅱ問1、R7 午後Ⅰ問3 設問3(4)
フォワードとリバース 社内 PC の代理として外へ出るのがフォワードプロキシ (この章の話)。外の利用者の代理として社内の Web サーバの前に立つのがリバースプロキシ で、SSL-VPN や負荷分散装置、WAF がこの形です(平成30年 午後Ⅰ問1 設問1(1) の空欄「フォワード」「リバース」)。
向きが逆なだけで、「間に入って TCP を終端し、代わりに接続する」仕組みは同じです。
2. フォワードプロキシの動作ステップ
ブラウザに「プロキシを使え」と教える
プロキシは透過的ではなく、ブラウザが宛先をプロキシに向けて送る ことで成り立ちます。教え方は 3 つあります。
手動設定 : ブラウザや OS に「10.0.1.80:8080」を書く。台数が多いと運用が回らない
PAC ファイル (プロキシ自動設定): 「この URL のときはどのプロキシを使うか、使わないか」を書いた JavaScript 関数を Web サーバに置き、ブラウザに URL を設定する。宛先ごとに DIRECT(直接)と PROXY を使い分けられる のが要点で、ローカルブレイクアウトの実現手段になる(令和6年 午後Ⅰ問3 設問2、令和5年 午後Ⅱ問1 設問1(5))
WPAD (Web プロキシ自動検出): PAC の URL 自体を自動で見つける。DHCP のオプション、または DNS で wpad.社内ドメイン を引いて HTTP で取りに行く(令和6年 午後Ⅰ問3 設問3 の空欄「DHCP」「DNS」「HTTP」「URL」)
WPAD の危険 PAC の場所を「名前解決で見つける」ということは、偽の wpad ホストを立てた攻撃者が PC を自分のプロキシに向けられる ということです(令和6年 午後Ⅰ問3 設問3(2)「不正なプロキシサーバに中継される」)。
PAC ファイルには社内ネットワークの範囲(例: 172.16.0.0〜172.31.255.255 は DIRECT)が書かれるので、読めば内部構成も分かります。
PAC ファイルの骨格
function FindProxyForURL(url, host) {
if (isInNet(host, "172.16.0.0", "255.240.0.0")) return "DIRECT"; // 社内宛てはプロキシを使わない
if (dnsDomainIs(host, ".saas.example.com")) return "DIRECT"; // SaaS 宛ても直接(ローカルブレイクアウト)
return "PROXY proxy.a-sha.jp:8080"; // それ以外はプロキシ経由
}
一部の PC(対応しないアプリ・OS)では PAC が効かない=「対応する PC やサーバでしか利用できない」(R5 午後Ⅱ問1)
HTTP を中継する(プロキシが TCP を 2 本持つ)
ブラウザは Web サーバではなくプロキシに TCP 接続 し、「GET http://www.example.jp/index.html」のようにURL 全体 を送ります。プロキシは URL のホスト名を自分で名前解決して Web サーバに接続し、応答を受け取ってブラウザへ返します。
つまり図1 の ① と ② は別々の TCP コネクション で、Web サーバから見た送信元はプロキシです。
名前解決は誰がするか プロキシ経由のとき、PC は Web サーバの名前を引きません(プロキシのアドレスさえ分かればよい)。引くのはプロキシです。
だから「PC が内部 DNS に外部の名前を問い合わせる通信」は FW で拒否でき、マルウェアが DNS を使って外へ出る経路も絞れます。逆にプロキシ例外(DIRECT)にした宛先は PC 自身が名前解決する必要があり、FW と DNS の許可が要ります(令和4年 午後Ⅰ問3 設問1)。
利用者を認証する
プロキシは最初の要求に 407 Proxy Authentication Required を返し、ブラウザは利用者 ID とパスワードを付けて再送します。方式は Basic(平文に近い)とダイジェスト認証 (パスワードのハッシュを送る。令和4年 午後Ⅰ問1 の空欄)、AD 連携の NTLM/Kerberos があります。
認証に通った利用者 ID がログに残るので、「誰が」が IP アドレスではなく人で分かります。
IP アドレスから人を割り出す 認証していないプロキシのログには送信元 IP しかありません。DHCP 環境では IP が入れ替わるので、L3SW(DHCP サーバ)のリースログ と突き合わせて初めて端末が特定できます(令和7年 午後Ⅰ問3 設問1(3))。
この「複数のログを時刻で結ぶ」ために syslog 集約と NTP が前提になります。
3. HTTPS の中継と TLS 復号
今の Web はほぼ HTTPS です。暗号化された通信を「URL ごと読んで中継する」ことはできないので、HTTPS だけは別の方法で中継します。
ブラウザ
プロキシ
Web サーバ
① CONNECT www.example.jp:443(平文)
② TCP 接続(宛先ポート 443)
③ HTTP/1.1 200 Connection established
④ TLS ハンドシェイク〜暗号化された HTTP が、そのまま通り抜ける
プロキシは中身を読めない。分かるのは「接続先ホスト名とポート番号」だけ
① の行にだけ接続先が平文で書かれるので、プロキシの URL フィルタとログは ① で判定する
443 以外への CONNECT を拒否しておくと、プロキシを使った任意ポートへのトンネルを防げる
図2 CONNECT メソッド。プロキシは TCP のトンネルになり、中身には触らない
ブラウザはまず「CONNECT www.example.jp:443 」という要求をプロキシへ平文で送ります。プロキシは Web サーバの 443 番へ TCP 接続し、「200 Connection established」を返します。以後プロキシは両方の TCP をつなぐだけのトンネル になり、TLS ハンドシェイクも暗号化データもそのまま通り抜けます。
CONNECT は平成30年 午後Ⅰ問1、令和4年 午後Ⅰ問1、平成28年 午後Ⅰ問2 と繰り返し空欄になっています。
プロキシが知れるのは CONNECT 行の接続先ホスト名とポート番号 だけ(平成28年 午後Ⅰ問2 設問4(2))。URL フィルタは FQDN 単位になり、パスやクエリでは判定できません。
CONNECT は任意のポートへの TCP トンネルを作れてしまうので、443 以外への CONNECT を拒否する のが定石です(平成30年 午後Ⅰ問1 設問2(1)「HTTPS 以外のポートの CONNECT を拒否する」)。許すと、SSH や独自プロトコルをプロキシ経由で外へ出す抜け道になります。
中身を見たいなら TLS を復号する
PC ブラウザ
プロキシ/SWG 自前の CA を持つ
Web サーバ example.jp
TLS セッション A TLS セッション B
サーバ証明書は
プロキシの CA が署名した
example.jp の証明書(偽造に近い)
本物の example.jp の
サーバ証明書で検証
前提: PC の信頼ストアに「プロキシの CA のルート証明書」を配布しておく
配っていない PC では証明書エラーになる(=復号できない)
プロキシが両側と別々に TLS を張り、間で平文を検査する
図3 TLS 復号。プロキシが利用者の前で「example.jp のふり」をするので、PC がそれを信頼する下地が要る
マルウェア検査や詳細な URL フィルタをするには平文が必要なので、プロキシ(または SWG)が意図的な中間者 になります。
ブラウザとの間はプロキシが即席で発行した example.jp の証明書 で TLS を張り、Web サーバとの間は本物の証明書で別の TLS を張ります。その証明書に署名しているのはプロキシ自身の CA なので、PC が普通にアクセスすると証明書エラーになります。
だから「ルート証明書の配布」が答えになる PC にプロキシ(SWG)の CA のルート証明書 をあらかじめインストールしておけば、プロキシが発行した証明書を正当なものとして受け入れます。
平成30年 午後Ⅰ問1 設問2(2)「プロキシサーバのルート証明書」、令和7年 午後Ⅰ問3 設問2(1)「SWG サービスのルート証明書」が同じ答えです。
配布は AD のグループポリシーや MDM で行い、配っていない私物端末や IoT 機器では復号できません。
復号できない・してはいけない通信 (a) アプリが証明書ピンニング (特定の証明書しか受け付けない)をしていると接続自体が失敗する。(b) オンラインバンキングや医療など機密性の高い宛先は復号対象から除外するのが通例。
(c) クライアント証明書で相互認証する通信は、プロキシが代わりに証明書を出せないので復号不可。設問で「復号の対象外にすべき通信」と来たらこの 3 つです。
4. FW・IDS/IPS・WAF・UTM との役割分担
セキュリティ機器は「どの層の何を見るか 」で役割が分かれます。設問で「どの機器で防げるか」を問われたら、この表で判断します。
機器 見るもの できること できないこと
FW(ステートフル) IP アドレス・ポート・TCP の状態 通信の許可/拒否。戻りパケットの自動許可。NAPT 許可したポートの中身(HTTP の内容)は見ない
プロキシ HTTP の URL・ヘッダ・(復号すれば)本文 URL フィルタ、認証、ログ、キャッシュ、マルウェア検査 HTTP 以外のプロトコル。復号しない HTTPS の中身
IDS / IPS パケットの中身をシグネチャ(既知の攻撃パターン)やアノマリ(通常と違う振る舞い)で照合 IDS は検知して通知、IPS はインラインで遮断。脆弱性へのパッチ適用までの間の仮想パッチ 暗号化された通信。未知の攻撃(シグネチャがない)
WAF HTTP リクエストの内容(SQL インジェクション、XSS など Web アプリへの攻撃) 公開 Web サーバの前に置いて攻撃を遮断。クラウド型は DNS で経由させる Web 以外。アプリの設計ミスそのもの
UTM 上記を 1 台に統合 中小拠点向け。FW+プロキシ+IPS+アンチウイルス 性能。復号と検査を全部やると遅い
IDS の置き方 IDS はインラインではなく、スイッチのミラーポート からコピーをもらってプロミスキャスモード (自分宛てでないフレームも受け取る)で監視します(平成27年 午後Ⅰ問3 の空欄「アノマリ」「ミラー」「プロミスキャス」)。
検知したら FW の ACL を動的に変えて送信元を遮断する連携もありますが、送信元 IP は偽装されうる ので正規の通信まで止める危険があります(同 設問2(3))。IPS は通信を通す「バイパス機能」を持ち、誤検知や故障時に業務を止めないようにします(同 設問3(2))。
C&C サーバとの通信を止める、という設問 マルウェアに感染した PC は、攻撃者の C&C サーバ (指令サーバ)へ HTTPS で定期的に接続します。これは「社内から外への普通の HTTPS」に見えるので FW では止まりません。
止められるのは、プロキシ/SWG の URL フィルタ (既知の C&C の FQDN・IP をブロック)と、プロキシを経由しない通信を FW で全部拒否 することの組合せです(令和7年 午後Ⅰ問3 設問2(2)、平成29年 午後Ⅰ問2 設問4、令和元年 午後Ⅱ問2 設問6)。
令和元年 午後Ⅱ問2 設問6(5) は「プロキシ経由を強制すると、マルウェアが C&C の IP アドレスを取得できず宛先を設定できない」という理屈を問いました。
5. クラウド型 SWG への移行
テレワークと SaaS が増えると、自宅の PC は本社のプロキシを通りませんし、本社のプロキシに全拠点の SaaS 通信を集めると詰まります。
そこでプロキシの機能をクラウドのサービスとして使う のが SWG (Secure Web Gateway)です。令和7年 午後Ⅰ問3 がまるごとこの移行の問題でした。
本社
PC
FW
旧プロキシは撤去
自宅(テレワーク)
PC
エージェント
SWG サービス
URL フィルタ・TLS 復号
マルウェア検査・ログ
出口 IP=SWG-GIP
SaaS
一般の Web
トンネル or プロキシ設定
社内でも自宅でも、Web へ出る通信は必ず SWG を通る(同じポリシー・同じログ)
SaaS 側の「許可する送信元 IP」は、本社のグローバル IP から SWG-GIP へ変更が必要
FW の許可ルールは「内部 → SWG サービス TCP/443」に変わる
赤線=SWG への接続。拠点は IPsec/GRE トンネル、端末はエージェントか PAC で向ける
図4 SWG へ移行した後の通信。社内からも自宅からも SWG を通る
SWG へ通信を向ける 3 つの方法
方法 仕組み 向く対象
エージェント方式 PC に SWG 事業者のソフトを入れ、Web 通信を SWG へ転送(TLS/IPsec のトンネル)。端末がどこにいても同じ テレワーク PC、モバイル
トンネル方式 拠点のルータ/FW と SWG の間に IPsec や GRE のトンネルを張り、拠点の全 Web 通信を流す エージェントを入れられない機器(複合機、IoT、サーバ)のある拠点
プロキシ設定(PAC)方式 PAC で宛先プロキシを SWG の FQDN にする。SWG が従来のプロキシと同じ CONNECT を受ける 既存のプロキシ設定をそのまま置き換えるとき
移行で変わる 3 点(ここが設問になる)
FW のルール : 「プロキシ → インターネット」の許可が不要になり、代わりに「内部セグメント → SWG サービス TCP/443 」(エージェントやトンネルの接続先)を許可します(令和7年 午後Ⅰ問3 設問3(3))。
SaaS 側の送信元 IP 制限 : SaaS から見た送信元が本社のグローバル IP から SWG の出口 IP(SWG-GIP) に変わるので、許可リストを変更します(同 設問3(4))。SWG の出口 IP は共用の場合があり、「自社専用の IP であること」を要件にする問題もあります(令和4年 午後Ⅰ問2 設問3(1))。
経路と遅延 : 全通信が SWG を経由するので、SWG のデータセンターが遠いと RTT が増えます(令和4年 午後Ⅰ問2 設問3(2)「SGW サービスの経由によって発生する遅延」)。SaaS 宛てを SWG を通さず直接出す(ローカルブレイクアウト)と速くなりますが、ログとフィルタの対象外になります(令和7年 午後Ⅰ問3 設問3(5))。
周辺の用語を位置づける SWG は「Web 向けの出口の検査」。CASB は「どの SaaS に何をアップロードしたか」を可視化・制御する層で、SWG に同居することが多い。
ZTNA は「社内アプリへのアクセスを VPN の代わりに、利用者・端末ごとの認証で許可する」仕組み。これらに SD-WAN を足してクラウドで一括提供する枠組みが SASE です。
午後では個別の仕組みより「どの通信が、どこを通って、どこで検査されるか 」を図で追えることが問われます。
6. 用語集(午後で出る順)
用語 意味 午後でのポイント
フォワードプロキシ 社内 PC の代理で外へ出る。URL フィルタ・ログ・認証・キャッシュ 目的を 2 つ答えさせる定番
リバースプロキシ 外の利用者の代理で社内サーバの前に立つ SSL-VPN・LB・WAF の形。向きの区別
透過型プロキシ PC に設定せず、経路上で HTTP を横取りして中継 設定不要だが HTTPS の扱いが難しい
PAC プロキシ自動設定ファイル。宛先ごとに PROXY/DIRECT を返す JavaScript 社内宛て・SaaS 宛てを DIRECT にする。対応しない機器がある
WPAD DHCP または DNS(wpad ホスト名)で PAC の URL を自動検出 偽 wpad による不正プロキシへの誘導
CONNECT HTTPS 中継用のメソッド。接続先ホスト:ポートを平文で指定し、以後は TCP トンネル 443 以外を拒否。プロキシに分かるのは FQDN とポートだけ
プロキシ認証 407 で利用者 ID を要求。Basic/ダイジェスト/AD 連携 ログを人に結び付ける
TLS 復号(SSL インスペクション) プロキシが中間者として両側に別々の TLS を張る PC にプロキシ CA のルート証明書を配布。ピンニングや機密宛ては除外
ルート証明書 信頼の起点となる CA の自己署名証明書 配布していない端末では証明書エラー
URL フィルタ FQDN・URL・カテゴリで許可/拒否 C&C サーバやマルウェア配布サイトの遮断
C&C サーバ マルウェアに指令を出す攻撃者のサーバ 感染 PC からの外向き HTTPS を止める=プロキシ強制+フィルタ
syslog / NTP ログの集約と時刻同期 複数機器のログを時系列で突き合わせる前提
IDS / IPS 検知のみ/インラインで遮断。シグネチャ型・アノマリ型 ミラーポート、プロミスキャス、仮想パッチ、バイパス
WAF Web アプリ層の攻撃を遮断。クラウド型は DNS で経由 XFF ヘッダで元の送信元 IP をサーバへ伝える
UTM FW・プロキシ・IPS・AV の統合機 拠点の出口。性能に注意
SWG クラウド型のプロキシ。URL フィルタ・TLS 復号・マルウェア検査・ログ エージェント/トンネル/PAC で向ける。出口 IP が変わる
SWG-GIP(出口 IP) SWG がインターネットへ出るときの送信元 IP SaaS の送信元制限をこれに変更
CASB / ZTNA / SASE SaaS 利用の可視化/VPN 代替のアプリ単位アクセス/これらの統合 位置づけだけ分かればよい
ローカルブレイクアウト 特定 SaaS 宛てだけプロキシ・SWG を通さず直接出す 速いがログ・フィルタの対象外。詳細は VPN ページ
7. 午後での問われ方と答え方の型
設問の型 答え方 出た年度
プロキシを導入している目的を N つ 登録 FQDN/IP 宛ての通信のブロック、アクセス履歴の確認、利用者認証 R7 午後Ⅰ問3
ログの時刻を合わせる理由 複数機器のログを時系列で突き合わせて確認するため R7 午後Ⅰ問3
IP アドレスから端末を特定するのに必要なログ DHCP サーバ(L3SW)のリースログ R7 午後Ⅰ問3
空欄「HTTPS の中継に使うメソッド」 CONNECT H30 午後Ⅰ問1、R4 午後Ⅰ問1、H28 午後Ⅰ問2
CONNECT の悪用対策 HTTPS(443)以外のポートへの CONNECT を拒否する H30 午後Ⅰ問1
HTTPS でプロキシが確認できる情報 接続先ホスト名と接続先ポート番号 H28 午後Ⅰ問2
TLS 復号のために PC に入れるもの プロキシ(SWG)のルート証明書 H30 午後Ⅰ問1、R7 午後Ⅰ問3
URL フィルタで止める通信の相手 C&C サーバ R7 午後Ⅰ問3、H29 午後Ⅰ問2
PAC のメリット・制限 宛先ごとにプロキシ/直接を切り替えられる。対応する PC・アプリでしか使えない R5 午後Ⅱ問1、R6 午後Ⅰ問3
WPAD の取得手段・リスク DHCP、DNS、HTTP で URL を取得。不正なプロキシに中継される R6 午後Ⅰ問3
プロキシ例外にした宛先で必要になる設定 PC 側の DNS・デフォルトゲートウェイ、FW で PC からの直接通信を許可 R4 午後Ⅰ問3
SWG 移行後の FW ルール 送信元 内部セグメント、宛先 SWG サービス、TCP/443 を許可 R7 午後Ⅰ問3
SWG 移行で SaaS 側に必要な変更 許可する送信元 IP を SWG の出口 IP に変更 R7 午後Ⅰ問3、R5 午後Ⅱ問1
SWG を経由することの欠点 経由による遅延。出口 IP が共用だと送信元制限に使えない R4 午後Ⅰ問2
SaaS 宛てを直接出す利点 FW・回線・経由機器の負荷軽減、RTT 短縮 R7 午後Ⅰ問3
IDS の接続方法・用語 ミラーポート、プロミスキャスモード、アノマリ検知 H27 午後Ⅰ問3、R4 午後Ⅰ問1
書き方の型 「何のため」は動詞で終える (「ログのため」ではなく「Web サイトへのアクセス履歴を確認するため 」)。
通信を答えるときは送信元・宛先・プロトコル/ポート の 3 点セットで書く(「内部セグメント → SWG サービス、TCP/443」)。
証明書を問われたら「誰の・何の証明書か 」まで書く(「ルート証明書」だけでは不足、「SWG サービスのルート証明書」)。
8. ミニ確認問題
クリックで答えが開きます。
Q1 フォワードプロキシを置く目的を 3 つ URL フィルタリング(登録した FQDN/IP 宛ての遮断)、アクセスログの記録、利用者認証。加えて送信元 IP の集約とキャッシュ。
Q2 プロキシ経由のとき、Web サーバの名前解決をするのは PC かプロキシか プロキシ。PC はプロキシのアドレスだけ知ればよい。だから PC から外部名の DNS 問合せを FW で拒否できる。
Q3 HTTPS をプロキシが中継する手順を 3 行で ① ブラウザが CONNECT ホスト:443 を送る → ② プロキシがサーバの 443 へ TCP 接続し 200 を返す → ③ 以後は TLS を含む全データをそのまま双方向に転送する。
Q4 CONNECT を 443 以外にも許すと何が起きるか プロキシを踏み台に任意のポートへ TCP トンネルを張れるので、SSH や独自プロトコルで外部へ抜ける経路になる。
Q5 TLS 復号を有効にする前に PC へ配るものと、配らないとどうなるか プロキシ(SWG)の CA のルート証明書。配らないと、プロキシが発行した証明書を検証できず証明書エラーで接続できない。
Q6 TLS 復号の対象から外すべき通信を 2 つ 証明書ピンニングをしているアプリの通信(接続が失敗する)、オンラインバンキングなど機密性の高い宛先。クライアント証明書で相互認証する通信も不可。
Q7 PAC ファイルで実現できることと、できない機器があるのはなぜか 宛先ごとに PROXY/DIRECT を切り替えられる(社内宛て・SaaS 宛てを直接)。PAC を解釈するのはブラウザや OS の機能なので、対応しないアプリ・機器では効かない。
Q8 WPAD の仕組みとリスク DHCP オプションか DNS の wpad ホスト名で PAC の URL を見つけ HTTP で取得する。攻撃者が偽の wpad を立てると、PC を不正なプロキシに中継させられる。
Q9 SWG へ移行したとき、SaaS 側と FW 側で変えること SaaS 側: 許可する送信元 IP を本社のグローバル IP から SWG の出口 IP に変更。FW 側: 内部 → SWG サービス(TCP/443)の許可を追加し、旧プロキシ → インターネットの許可を削除。
Q10 マルウェアの C&C 通信をネットワークで止める組合せ FW で PC から直接の外向き通信を拒否してプロキシ/SWG 経由を強制し、プロキシ/SWG の URL フィルタで C&C サーバの FQDN・IP を遮断する。
用語の振り返り
このページの用語集(19 語)から作った確認問題です。「意味 → 用語」は意味の説明(用語そのものは__で伏せてある)を読んで用語を入力し、Enter で答え合わせします。
表記ゆれで × になったときは「合っていた」で直せます。「用語 → 意味」は口で説明してから答えを開いて自己採点します。結果はこのブラウザに保存され、「×だけ」で間違えた語だけを解き直せます。
意味 → 用語を答える 用語 → 意味を言う 全部 ×だけ 未回答だけ シャッフル 記録を消す
拠点間VPN … ローカルブレイクアウトで SaaS 宛てだけ拠点から直接出すDNS … プロキシを使うとき、名前解決をするのはプロキシ認証連携 … プロキシ認証、SWG と IdP の連携メールと送信ドメイン認証 … 標的型メールから C&C 通信への流れと出口対策
← トップ(目次) ② ルーティング OSPF BGP VRRP IPv6 IPマルチキャスト ③ セキュリティ 拠点間VPN プロキシとSWG 認証連携 ④ クラウド・DC ロードバランサー VXLANとEVPN ⑤ DNS・メール DNS メールと送信ドメイン認証 ① LAN冗長化 L2冗長化 | 全分野の用語ドリル