SSH・RDP・NASを公開しない。WireGuardでAttack Surfaceを減らし、クラウドと社内ネットワークを守る設計

WireGuardを管理接続の入口にして、SSH・RDP・NASの管理画面への直接公開を閉じれば、インターネットから攻撃できる範囲（Attack Surface）を減らせます。さらに本番・開発・物理サーバールームを別のネットワークへ分け、必要な端末から必要な宛先だけを許可することで、侵入後の横移動を抑える設計にできます。ただし、VPNへ集約するだけで端末侵害や内部のアクセス権まで解決するわけではありません。

公開サービスが増えると、守る入口も増える

クラウドのLinuxへSSH、WindowsへRDP、NASへ管理画面やファイル共有で接続する。便利にするために直接公開すると、それぞれのサービスがインターネットから接続を受け付けます。

公開入口には、ソフトウェアの脆弱性、認証情報の盗難、設定不備、更新漏れなどのリスクがあります。通信の暗号化は必要ですが、暗号化された接続を受け付けるサービス自体の保護も必要です。

Attack Surfaceを減らすとは、攻撃者が到達できるサービスや管理機能を減らすことです。サービスを停止しなくても、利用経路をVPN内へ限定できます。

対象	直接公開する構成	VPNへ集約する構成
SSH・RDP	各サーバーへ公開IPから接続	VPN経路の管理用アドレスから接続
NAS	管理画面・ファイル共有を直接公開	許可した端末からVPN経由で接続
踏み台サーバー	SSHなどをインターネットへ公開	Private Subnetに置き、VPN内から利用

サービスの認証を省く設計ではありません。VPNで到達範囲を絞り、その先でもSSH鍵、適切なアカウント権限、対応するサービスのMFAを使います。

WireGuardへの集約で、何が減るのか

一般的な自作構成では、WireGuardゲートウェイだけにUDPの接続を受け付けさせ、SSH・RDP・NASへの外部からの直接接続をFirewallで閉じます。VPN側にも転送ルールを設け、必要な宛先とポートだけを許可します。

WireGuardは公開鍵でPeerを認証し、IPパケットをUDP上で運ぶVPNです。鍵の配布、利用者の承認、接続先アプリケーションの権限管理は別途設計します。AllowedIPsによるアドレスとPeerの対応付けも、アプリケーション単位の認可を代替しません。

参照：WireGuard公式の概念説明

WireGuardの技術論文は、Linux実装を4,000行未満で実現できると説明しています。初期Linux実装の規模を示す「約4,000行」という話は、設計を小さくし、監査しやすくする意図を理解する材料です。

現在の全プラットフォームの実装、OS、暗号ライブラリ、管理画面、配布・運用機能を合計した行数ではありません。 行数が少ないことだけで脆弱性がないと判断することもできません。公開入口を限定する効果と、実装・運用全体の安全性は分けて評価します。

参照：WireGuard技術論文（Abstract）

自宅WireGuardには、Inboundの条件が残る

WireGuardへ集約しても、自宅を直接の接続先にする場合は、外からWireGuardサーバーへパケットが届く必要があります。

IPv4ならPublic IPv4とポート転送などが必要になる構成があります。CGNAT、DS-Lite、MAP-Eの利用可能ポート、二重NATなど、回線方式の条件も確認します。LAN内で動いて外から動かない場合は、鍵設定を疑う前にサーバーまでUDPパケットが到達しているかを切り分けます。

IPv6 DirectではNATのポート転送が不要でも、Global IPv6、ルーターとOSのInbound Firewall、接続元のIPv6接続性が必要です。IPv4 onlyのホテルWi-Fiなどからは、そのIPv6へ直接接続できません。IPv6 Pass-throughの挙動は機器ごとに確認します。

ポート開放の操作がないことと、Inboundがないことは別です。 詳しい整理は、自宅VPNが外からつながらないとき、ポート開放の前に考えたい「家庭用IP」の話を参照してください。

Outbound型Hub & Spokeなら、踏み台も非公開にできる

別の構成は、管理端末と各ネットワーク内のゲートウェイが、到達可能なCloud Hubへ外向きに接続するHub & Spokeです。自分でクラウド上にWireGuard Hubを構築する方法もあります。

この構成なら、自宅や社内、クラウドの管理対象を、インターネットから直接VPN接続を受ける場所にする必要を減らせます。Private Subnet内の踏み台へVPN経由で到達できれば、踏み台のPublic IPや公開SSHも不要にできます。

各拠点で直接受けていた入口をHub側へ集約する設計です。Outboundで確立したトンネルを通じて内部へ通信できるため、Outbound Onlyを「外から内部へ通信できない」という意味で使ってはいけません。

HubへのUDP通信、NAT状態の維持、経路、戻り通信、Firewall、運用監視は必要です。UDPを制限する回線では利用できない場合もあります。Hub障害への対応や、通常経路が使えない場合の管理手段も設計します。

本番と開発を別のVPCにする

インターネットからの侵入を減らしても、開発端末や開発サーバーの侵害は起こり得ます。開発環境から本番環境へ自由に移動できる構成では、最初の侵害が本番へ広がる可能性があります。

本番VPCと開発VPCを分け、それぞれに必要なVPN経路だけを設けます。開発用端末は開発へ、運用用端末は業務上必要な本番へ、という許可を設計します。

接続元の例	開発	本番
開発用端末	必要な範囲を許可	原則拒否
運用用端末	必要な場合だけ許可	管理対象だけ許可
外部保守端末	作業対象だけ許可	承認した作業対象だけ許可

これは設計例であり、製品がこの表の全粒度を自動で提供するという意味ではありません。自作構成ならHubの転送Firewallなどで実装し、クラウド側のSecurity Group、ルート、アプリケーションの権限も合わせます。

VPCを分けるだけでは十分ではありません。Peering、Transit Gateway、共有ゲートウェイなどの別経路で到達できれば、VPN側の制限を迂回できます。VPC間経路と通信許可を点検し、開発環境内のサーバーから本番への到達も検証します。

参照：AWS公式：VPC Peering

物理サーバールームも、社内LANから分離する

オンプレミスでも、社員PCと業務サーバーを同じ到達範囲に置く必要はありません。サーバールームを別VLAN・Subnetへ分離し、社内LANからの直接アクセスをFirewallで拒否したうえで、許可した管理端末だけVPN経由で到達させる構成を検討できます。

「Hubへ直結」とは、サーバーをPublic IPへ直接公開することではありません。隔離したサーバーネットワーク内のゲートウェイから、Cloud Hubへ外向きにVPN接続する意味です。

分離が機能するには、L2で同じネットワークになっていないこと、ルーターのInter-VLAN Routingや別NICから迂回できないことが条件です。社員PCが侵害された場合も、サーバーへの到達を制限する追加境界になります。

ただし、サーバーを直接使う業務端末、バックアップ、監視、DNS、認証基盤の通信は個別に整理します。管理用端末自体が侵害されれば、許可範囲への攻撃は残ります。

HomeGrid VPNでは、端末×Subnetの許可を設計する

HomeGrid VPNはWireGuardを使うOutbound型Hub & Spokeです。各拠点のGridや対応するLinuxゲートウェイと、リモート端末がCloud Hubへ接続し、原則として拠点ルーターのIPv4 Port Forward、IPv6 Inbound Rule、DDNSを接続の前提にしません。

LAN ACLは、登録端末×宛先LAN（Subnet）の許可を設定する機能です。既定で拒否のため、登録しただけで各LANへ到達できるわけではありません。本番と開発を別の宛先Subnetとして登録し、必要な端末にだけ許可する設計に利用できます。

ただし、Subnet単位の許可を、同じSubnet内のサーバー別・ポート別・プロセス別の許可に読み替えてはいけません。SSHだけ、NASの一部フォルダーだけ、といった制限は接続先のFirewallや認証・アクセス権で補います。同一LAN内の横移動や、Hubを経由しない別経路もLAN ACLの対象として期待しません。

導入方式によって通信方向の条件も異なります。Docker版Gridなどには配下LANからVPN側への通信を許可できない条件があり、任意の拠点間双方向通信を保証するものではありません。VPCや物理LANの接続では、対応方式、宛先CIDRの重複、転送と戻り経路を確認します。

LAN ACLの変更は反映まで最大5分かかることがあります。許可した経路と拒否した経路の両方を、反映後に確認します。画面操作と現在の仕様は、LAN ACLのガイドへ進んでください。拠点を追加する具体例は、自宅・事務所・VPCのLAN接続で説明しています。

管理画面の「拠点LAN（VPC）を追加」からワンライナーでLinuxゲートウェイを登録し、VPCやオンプレミスのLANを接続する方法は、Platinumプランの機能です。Gridを置いたLANへの接続は、ほかのプランでも利用できます。導入前に料金ページで利用条件を確認してください。

Cloud HubとInternet Exitは別の役割

管理接続をHubへ集約することと、インターネットへの出口をHubにすることは別です。Cloud Hub ≠ Internet Exitです。

HomeをExitにした通信は、Remote → Cloud Hub → Home → Residential ISP → Internetという経路になります。接続先が見る出口IPはHome側のPublic IPです。VPCやNASへ管理接続するだけなら、すべてのインターネット通信をHomeへ送る必要はありません。

Hubは経路上の構成要素として、運用と可用性の設計に含めます。VPNはアプリケーション層の暗号化を置き換えるものではないため、SSHやHTTPSなど必要な暗号化は維持します。

残余リスクを確認して、古い入口を閉じる

入口の集約と分離は、リスクを減らす一層です。次の対策は引き続き必要です。

• 端末・ゲートウェイ・Hub・OS・アプリケーションの更新と監視
• VPN鍵と管理アカウントの保護、不要な端末・権限の失効
• 接続先の認証、MFA、最小権限、操作記録
• 同じSubnet内の横移動対策と、公開Webアプリなど別入口の保護
• 分離したバックアップと復元確認、Hub停止時の業務継続手段

移行は管理接続を一つ選び、VPN内から必要な作業ができることを確認してから進めます。続いて、不要になった公開SSH・RDP・NASの受信ルール、ポート転送、公開IPv6の許可を閉じます。IPv4とIPv6の双方で直接公開が残っていないこと、未許可端末や開発環境・社内LANから本番へ到達できないことを検証します。

最後に記録するのは、誰の端末から、どのネットワークへ、どの経路で接続できるかです。公開入口を減らす設計と、侵入後に移動できる範囲を減らす設計を組み合わせて運用します。

担当者や保守業者の権限整理から始めたい場合は、SOHO・小規模事業者の「公開入口」の減らし方を参照してください。