ネットワークの相談は、ネットワークの話から始まらない。

私たちが「現場で使えるセキュリティ」をつくるまで

「オンライン会議の音声が途切れるんです」

「VPNにはつながるのに、社内のシステムが開きません」

「新しい店舗を出すので、ネットワークを一式お願いできますか」

「画像だけ送れないことがあるのですが、ファイアウォールが原因でしょうか」

私たちのもとに届くネットワークの相談は、最初から「ネットワーク機器を導入したい」という言葉で始まるとは限りません。

むしろ多いのは、仕事をしている人が目の前で感じている、原因のはっきりしない困りごとです。

株式会社エッジコネクトは、セキュリティ製品だけを扱う専門会社ではありません。

PC、ネットワーク、クラウドサービス、電話、業務システム。お客様の仕事を支えるIT全体を見ながら、何が起きているのかを整理し、必要なものを形にしていく会社です。

そんな私たちがSophosを取り扱う中で学んだのは、セキュリティ製品は「入れれば守れる」ものではない、ということでした。

守るのは、機器ではなく仕事の継続

ファイアウォールのスペック表には、処理性能や対応機能が並びます。

もちろん、それらは重要です。

しかし、現場で本当に問われるのは、その先です。

拠点から本社へのVPNはどう構成するのか。
インターネット回線が切れたとき、どう切り替えるのか。
社内システムへ向かう通信と、TeamsやZoomへ向かう通信をどう分けるのか。
無線LAN、複合機、防犯カメラ、ゲスト端末を同じネットワークに置いてよいのか。
導入後、誰が設定を確認し、問い合わせを受けるのか。

Sophos XGSを一台設置するだけでは、これらの問題は解決しません。

私たちは、ファイアウォールを「箱」として販売するのではなく、お客様の業務が無理なく続く状態までを考えるようになりました。

必要に応じて事前に設定した機器を発送し、導入後はSophos Centralから状態を確認する。複数拠点がある場合は、拠点ごとの違いを残しながら、できるだけ共通の設計や命名規則を使う。

障害が起きたときに、担当者の記憶だけを頼りにしなくて済むよう、パラメーター、変更内容、確認結果を記録する。

派手な仕事ではありません。

しかし、この積み重ねがなければ、セキュリティ製品は導入した瞬間から「触るのが怖い機器」になってしまいます。

「設定に成功した」は、「目的を達成した」ではなかった

忘れられない検証があります。

あるクラウド会議サービスの通信を、本社経由ではなく拠点のインターネット回線から直接出すため、新しいルールを追加しました。

事前に既存設定を調べ、対象端末、通信先、ポート、ルールの位置を検討。バックアップを取得し、承認を経て設定を反映しました。

機器から返ってきた結果は成功。
設定画面にも、意図したルールが表示されました。
実際の会議も、音声、映像、画面共有ともに正常でした。

それでも、追加したルールの利用回数はゼロのままでした。

一見すると問題はありません。

しかし、「会議ができた」という結果だけを見て終わらせれば、追加した設定が本当に役割を果たしたのかは分かりません。

通信ログを一つずつ確認すると、実際に使われていた接続先は、事前に定義した宛先グループに含まれていませんでした。さらに、ルールの配置によっては、別の既存ルールが先に適用される可能性もありました。

設定は正常に反映されていた。
通信も正常だった。
けれど、狙った経路を通っていたわけではなかった。

この経験から、私たちの確認基準は一段厳しくなりました。

APIが成功を返したか。
画面に設定が表示されたか。
通信ができたか。

それだけでは足りません。

どのルールに一致したのか。
どの経路から出たのか。
NATは想定どおりか。
実際の宛先とポートは何だったのか。

「動いたように見える」と「設計どおりに動いた」は、別のものです。

Sophosの取り扱いを通じて、私たちはこの違いを何度も学んできました。

拠点ごとの職人芸を、再現できる標準へ

ネットワークの現場では、同じ会社の拠点であっても状況が異なります。

回線の種類も違えば、利用しているクラウドサービスも違う。既存のルーター、IPアドレス、無線環境、現地で作業できる人の経験も異なります。

すべてを同じ設定にすることはできません。

一方で、毎回ゼロから考えていては、品質も作業時間も担当者の経験に左右されます。

そこで私たちは、共通化できる部分を少しずつ標準に変えてきました。

たとえば、Teams、Zoom、Google Meetなどの会議通信を拠点から直接インターネットへ出すローカルブレイクアウト。

単に「クラウドサービスは全部直接出す」という設定にはしません。実際に利用しているサービスを確認し、対象を限定します。社内システムやプライベート接続先は従来の経路に残し、会議通信やクラウドサービスだけを切り分けます。

さらに、通信先を無制限に指定しない、TLS復号から除外すべき対象を整理する、回線速度の単位を間違えない、ルールの順序を確認する、といった事故になりやすいポイントをチェックリストに落としました。

設定オブジェクトは共通化しても、回線名、送信元ネットワーク、NAT、ルールの位置は拠点ごとに確認する。

つまり、何でも自動化するのではなく、共通化すべきところと、人が判断すべきところを分けています。

一台ずつの経験を、次の一台で使える知識に変える。

それが、私たちの考える標準化です。

AIに設定を任せたのではなく、安全に使う工程をつくった

Sophosの設定は、規模が大きくなるほど確認項目が増えます。

既存のホスト定義、サービス、ファイアウォールルール、NAT、SD-WAN、TLS除外。設定ファイルには多くの情報が含まれ、人がすべてを読み比べるには時間がかかります。

そこで現在は、AIも活用しています。

ただし、AIに認証情報を渡し、自由に機器を変更させているわけではありません。

まず既存設定を読み取り専用で取得し、AIが棚卸しを行う。
変更案を作成し、別の視点でレビューする。
禁止されている操作や危険な設定が含まれていないか検証する。
人がバックアップを取得し、内容を確認して承認する。
変更は決められた方法で一度だけ実行する。
反映後は再び読み取り専用で設定を確認し、最後に人が実際の通信とログを見る。

AIは、判断を省略するためではなく、確認漏れを減らし、変更理由と証跡を残すために使っています。

そして、先ほどの「設定は成功したのに、ルールには一致していなかった」という事実を見つける最後の仕事は、やはり実際の通信を確認する人間の役割でした。

AIが出した答えを、そのまま正解にしない。
機器が返した成功も、そのまま完了にしない。

表側の操作は分かりやすく。
裏側の確認は厳密に。

これはSophosに限らず、エッジコネクトの仕事全体に通じる考え方です。

私たちは、何でもできるとは言わない

私たちは、24時間365日のSOCや、すべてのセキュリティ事故に自社だけで対応する専門組織ではありません。

できないことまで、できるように見せるつもりもありません。

高度な調査やメーカー判断が必要な場合は、適切な窓口につなぐ。お客様の環境で確認できる事実を整理し、メーカーへ問い合わせ、回答を現場で実行できる形に翻訳する。

初期設定、導入、ネットワーク設計、設定変更、ライセンス更新、障害の切り分け、継続的な運用。

私たちは、企業のIT担当者が日常的に必要とする範囲を、現実的な距離で支える会社です。

何でも屋ではありません。

でも、届く距離にある課題からは逃げない。

分からない状態を放置せず、調べ、試し、記録し、次はもっと安全に進められる形にする。

Sophosの取り扱いは、その姿勢が最もよく表れる仕事の一つになりました。

製品を売る人ではなく、使い続けられる状態をつくる人へ

Sophosの知識は、入社時点で完璧である必要はありません。

私たちが一緒に働きたいのは、製品名や機能を並べるだけではなく、

「お客様は、何に困っているのか」
「止まると困る仕事は何か」
「この設定は、誰が運用し続けるのか」
「成功したと言える証拠は何か」

を考えられる人です。

曖昧な相談を整理し、技術者とお客様の間をつなぐ営業。
問い合わせ、対応、承認、履歴を整え、運用品質を高めていくマネージャー。
設定するだけでなく、検証結果から次の標準をつくれる技術者。

エッジコネクトには、完成された正解だけを受け取る仕事よりも、現場から正解を組み立てていく仕事があります。

私たちが守りたいのは、ファイアウォールそのものではありません。

その先で続いている、お客様の仕事です。

あなたの会社のIT担当として。
安心は、いつも近くに。