WireGuardの「無応答」だけでは十分ではない──Outbound Onlyで実現する非公開VPNの設計
WireGuardの無応答設計は、通信経路上から接続先IPを隠す仕組みではありません。Outbound Onlyの中継構成なら、自宅やオフィスに公開VPNの受信口を設けずに通信経路を維持できます。ただし、中継基盤の運用と信頼、利用端末や接続先の保護は引き続き必要です。
VPN機器の脆弱性が問題になるたびに、VPNからSASEやZTNAへの移行が話題になります。
しかし、VPNを廃止すれば解決するほど、企業のネットワークは単純ではありません。
リモートワークで社内システムを利用する。出張先から業務サーバーへ接続する。自宅のNASや開発環境を利用する。クラウドと社内ネットワークを接続する。
こうした業務には、外部から社内ネットワークや業務システムへ安全にアクセスできる経路が不可欠です。 その経路を失えば、日常業務そのものが成り立たなくなる場合があります。
SASEやZTNAも有効な選択肢ですが、すべての業務通信をそのまま置き換えられるわけではありません。
また、リバースプロキシ型のZTNAでは、業務サーバー自体を非公開にできても、外部から到達可能なプロキシや認証用の接続口が存在する構成があります。
もちろん、ZTNAにもプライベートネットワークへのアクセスを提供する方式があり、すべてのZTNAがアプリケーションを公開するわけではありません。
重要なのは、VPNを使うか、使わないかという二者択一ではありません。
VPNによる安全な通信経路を維持しながら、インターネットに公開する接続口をどこまで減らせるか。
そのために考えたいのが、WireGuardの無応答設計とOutbound Onlyを組み合わせたネットワーク構成です。
1. 一見、外部から見つからないように見えるVPN
企業向けVPN製品には、専用アプリからベンダーの認証サービスへログインし、そこから接続先を選択する方式があります。
利用者はVPN機器のIPアドレスやポート番号を意識する必要がありません。
接続設定も集中管理され、社員は専用アプリを起動するだけで社内ネットワークへ接続できます。
一見すると、VPNサーバーの存在が外部から隠されているように思えるかもしれません。
しかし、ここには重要な違いがあります。
利用者にVPN機器の接続先を見せないことと、インターネット上の第三者からVPN機器を発見できなくすることは別です。
認証後に自社のVPN機器へ直接接続する構成では、実際のVPNゲートウェイがインターネットから到達可能な状態になっている場合があります。
攻撃者が接続先を探索する際、正規ユーザーと同じように専用アプリからログインする必要はありません。
公開されたVPN機器を直接探索することができます。
また、利用者に接続先を表示しない設定であっても、その情報を管理するシステムやクライアントには、実際の接続先情報が必要になります。
つまり、接続アプリで見えなくしているだけでは、VPNの公開状態そのものは変わりません。
なお、ベンダーによっては拠点から中継基盤へOutbound接続する方式もあります。その場合は、公開VPNゲートウェイを自社に設置する方式とは区別して考える必要があります。
2. 一般家庭のIPアドレスも、インターネット上で探索されている
インターネット上のサーバーを対象としたポートスキャンは、大企業やデータセンターだけの問題ではありません。
一般家庭の回線も例外ではありません。
例えば、セキュリティ調査団体のShadowserver Foundationは、インターネット上のIPv4アドレスを広範囲に調査し、公開サービスの情報を収集しています。
また、インターネット上の公開サービスを調査するCensysも、IPv4アドレス空間を継続的に探索し、応答するサービスの情報を収集しています。
これらは主にセキュリティ調査を目的とした正当な活動ですが、攻撃者も同様の探索技術を利用できます。
こうした探索では、調査対象の企業名や個人名を事前に知っている必要はありません。
IPアドレスを広範囲に調査すれば、一般家庭の回線や小規模事業者のインターネット接続も探索対象に含まれます。
家庭用ルーターでVPNサーバーへのポート転送を設定している場合、外部からのパケットがLAN内のサーバーへ転送されることがあります。
ただし、ルーターのFirewallやCGNATなどによって、外部からの到達が制限されている環境もあります。また、スキャンされたこと自体が不正侵入を意味するわけではありません。
重要なのは、誰かに自宅のIPアドレスを教えなくても、公開IPv4アドレスは自動探索の対象になり得るということです。
3. WireGuardなら、ポートスキャンに応答しないから大丈夫？
ここまで読むと、こう考えるかもしれません。
「それならWireGuardを使えばいいのでは？」
WireGuardには、認証されていない相手からの通信に原則として応答しないという特徴があります。
一般的なポートスキャンでは、対象のポートにパケットを送信し、その応答を調べます。
しかしWireGuardは、正当な認証情報を持たない相手からの通信に対して、通常のハンドシェイクを成立させません。
そのため、一般的なUDPポートスキャンだけでWireGuardが動作していることを確認するのは困難です。
これはWireGuardの優れたセキュリティ設計です。
では、自社にWireGuardサーバーを設置すれば、その存在は外部から知られないのでしょうか。
ここに、見落としやすい問題があります。
WireGuardが無応答であることは、VPNサーバーの接続先情報が秘密になることを意味しません。
仮に別の経路でVPNサーバーのIPアドレスや接続ポートが判明すれば、攻撃者はその情報を知ることができます。
もちろん、それだけでWireGuardの認証を突破できるわけではありません。
しかし、VPNサーバーの存在を秘密にすることと、WireGuardの暗号化・認証によって不正アクセスを防ぐことは、異なるセキュリティ上の問題です。
4. VPNの通信内容が暗号化されていても、接続先は分かる
例えば、自社にWireGuardサーバーを設置し、社員には自宅から利用するよう徹底しているとします。
社員は専用の接続設定を使い、社内VPNへアクセスします。
WireGuardは通信内容を強固に暗号化するため、通信経路上でパケットを観測されても、トンネル内部のデータを簡単に読むことはできません。
しかし、VPNサーバーへパケットを届けるための宛先IPアドレスまで、WireGuardが隠してくれるわけではありません。
これは社員がどこから接続していても同じです。
例えば、次のような環境が考えられます。
- 自宅のWi-Fi
- 出張先のホテルのWi-Fi
- カフェなどのFree Wi-Fi
- モバイルルーターのWi-Fi
- スマートフォンのテザリング
これらのネットワークを利用した場合、ネットワーク管理者や通信経路上でパケットを観測できる第三者には、VPNの接続先IPアドレスやUDPポート、通信日時などが分かる場合があります。
Wi-Fiの無線通信も記録される可能性がある
さらに、Wi-Fiの場合は無線区間そのものにも注意が必要です。
Wi-Fiの通信は電波として周囲に送信されます。そのため、電波を受信できる範囲にいる第三者が、無線フレームを収集・保存できる場合があります。
WPA2やWPA3によって無線区間が適切に暗号化されていれば、記録したフレームから直ちに通信内容や宛先IPアドレスを読み取れるわけではありません。
しかし、保存された通信が後から解析され、暗号方式や鍵情報、実装上の脆弱性などの条件によっては、無線区間の通信を復号できる場合もあります。
また、Wi-Fiのアクセスポイントや、その先のネットワークを管理する立場であれば、通常は無線区間の暗号化を破ることなく、通信先のIPアドレスを確認できます。
ここで重要なのは、WireGuardの通信内容そのものを解読する必要はないということです。
WireGuardの外側にあるIPパケットの宛先が分かれば、VPNサーバーの接続先を特定する手掛かりになります。
仮に過去の無線通信が保存されていた場合、その時点では解析できなかった情報が、後から明らかになる可能性もあります。
もちろん、保存されたWi-Fi通信が必ず復号できるという意味ではありません。また、無線区間を復号できたとしても、WireGuard内部の暗号化まで解除されるわけではありません。
それでも、VPNの接続先を秘密にするという観点では、無視できない問題です。
通信内容が守られていても、通信先まで将来にわたって秘密であるとは限りません。
WireGuardの無応答設計は、こうした通信経路上の情報まで隠す仕組みではありません。
WPA2-Personalでは、必要なハンドシェイクの記録とパスワードなどの鍵情報が揃うと、保存した通信を後から復号できる場合があります。一方、WPA3-PersonalのSAEでは、パスワードと4-way handshakeの記録だけでは過去の通信を復号できず、接続ごとの鍵情報が必要です。「記録すれば将来必ず読める」という意味ではありません。方式ごとの条件はWireshark公式の無線LAN復号の説明を参照してください。
5. メタデータからもVPNの存在を推測できる
VPNの接続先を把握する方法は、通信の観測だけではありません。
ネットワーク上には、通信内容とは別に、さまざまな情報が存在します。
例えば、VPNの接続先を示すDNSレコード、公開された接続設定、関連する管理画面のTLS証明書、過去に収集された公開サービスの情報などです。
これらの情報を組み合わせれば、VPNサーバーの存在や接続先を推測できることがあります。
特に、VPN接続先として利用するホスト名が公開DNSに登録されている場合、そのIPアドレスを調べることは難しくありません。
また、管理画面などで利用するTLS証明書がCertificate Transparencyログに記録されていれば、関連するホスト名が手掛かりになる場合もあります。
ただし、これはすべてのVPNに当てはまるわけではありません。
WireGuard単体はTLSを利用するVPNプロトコルではなく、WireGuardの受信口そのものがTLS証明書の情報を公開するわけではありません。
さらに、Public IPアドレスのASNやWHOIS情報だけから、WireGuardの稼働を特定することもできません。
完全に無応答で、関連する接続先情報も公開されていないWireGuardサーバーであれば、一般のインターネット上の第三者がその存在を特定することは容易ではありません。
それでも、VPNの接続先情報が別の経路から知られる可能性は残ります。
無応答は、接続先情報を秘密にし続けることの保証ではないのです。
6. VPNサーバーを公開すると、継続的な運用も必要になる
ここまでの問題は、WireGuardが危険という意味ではありません。
WireGuardは、適切に構成すれば安全なVPN通信を実現できる技術です。
ただし、自社に公開WireGuardサーバーを設置する場合、VPNの暗号化以外にも管理しなければならないものがあります。
例えば、サーバーOSの更新、WireGuardの更新、鍵の追加・失効、Firewall設定、接続経路の維持、障害対応などです。
社員が増えれば、接続設定やアクセス権限の管理も必要になります。
また、VPNに接続できた端末が社内LANのどこまでアクセスできるかも重要です。
例えば、VPNから社内LAN全体へ到達できる構成では、正規の鍵を持った社員端末が侵害された場合、その端末のアクセス権限が悪用される可能性があります。
これはWireGuardの暗号化方式の問題ではなく、VPN接続後のアクセス制御の問題です。
VPNサーバーを公開する場合は、接続前の防御だけでなく、接続後のアクセス範囲まで考える必要があります。
こうした運用を継続できるのであれば、自社でWireGuardを構築することも有効な選択肢です。
しかし、専任のネットワーク管理者を配置できない小規模事業者では、その負担が大きくなることもあります。
7. 「応答しないVPN」と「公開していないVPN」は違う
では、WireGuardを使い続けながら、自宅や社内のVPNサーバーをインターネットに公開しない方法はないのでしょうか。
その一つが、Outbound Onlyを利用したHub & Spoke構成です。
従来の直接接続型VPNでは、リモート端末が自宅やオフィスのPublic IPアドレスへ接続します。
この構成では、拠点側に外部から到達可能なVPNの受信口が必要になります。
一方、Outbound Onlyでは、自宅やオフィスのVPN拠点が、インターネット上の中継サーバーへ自分から接続します。
リモート端末も中継サーバーへ接続し、両者の間に通信経路を構成します。
この方式なら、自宅やオフィス側に公開VPNの受信口を設ける必要がありません。
ここでのOutbound Onlyは、接続を開始する方向を指します。確立したトンネルでは要求と応答が双方向に流れ、Cloud Hubへの外向き通信と戻りの通信を利用できる必要があります。IPv6 Directでも、ポート転送を使わないこととInbound許可が不要なことは別です。
| 比較項目 | 自社設置のDirect型WireGuard | Outbound Only型 |
|---|---|---|
| 拠点側へのInbound | 必要 | 不要 |
| リモート端末の接続先 | 自社側Public IPなど | Cloud Hubなどの中継先 |
| 自社側の公開VPN受信口 | 存在する | 不要 |
| 未認証パケットへの応答 | 原則として無応答 | 利用プロトコルによる |
| 拠点側の接続先IPの露出 | 接続設定や通信観測から判明し得る | リモート端末の直接接続先にはならない |
| 中継基盤 | Direct構成では不要 | 必要 |
大きな違いは、外部から観測できるネットワーク構造です。
Direct型WireGuardでは、リモート端末の接続先は自社のVPNサーバーです。
そのため、社員が利用したネットワーク上で接続先情報が観測されれば、自社のVPN受信口に関する手掛かりになります。
一方、Outbound Onlyの中継構成では、リモート端末の接続先は中継サーバーです。
仮にその通信先が知られても、自社側に公開VPNの受信口が存在することにはなりません。
もちろん、中継サーバー自体は外部から到達可能であり、適切な管理が必要です。中継サーバーや通信経路の運用者が把握できる情報も考慮する必要があります。
重要なのは、VPNの存在を絶対に知られないようにすることではありません。自社側の公開VPN受信口を、そもそも作らないことです。
8. 自社で中継サーバーを設置すれば解決するのか？
Outbound Onlyの構成は、自社でも構築できます。
例えば、AWSやVPS上にWireGuardの中継サーバーを設置し、自宅やオフィス側からOutbound接続する方法です。
これなら拠点側に公開VPNの入口を設けずに済みます。
しかし、公開する接続口が完全になくなるわけではありません。
今度は、クラウド上の中継サーバーがインターネットから到達可能な接続先になります。
クラウド事業者のIPアドレスだからといって、外部から発見されないわけではありません。
また、DNSや証明書、ほかの公開サービスとの関連情報などから、運用主体を推測される可能性もあります。
もちろん、AWSのIPアドレスを調べるだけで、その契約者が判明するわけではありません。
しかし、企業がほかの業務システムも運用していれば、公開情報の組み合わせから関連性を推測できる場合があります。
さらに、攻撃者が無差別に公開VPNサーバーを探している場合、そもそも契約者の特定は必要ありません。
自社の公開VPN入口をなくしても、今度は自社が運用する中継サーバーが外部からの探索対象になるのです。
自動化すれば、運用担当者は不要になるのか？
そこで、サーバーの構築や運用を自動化する方法が考えられます。
TerraformなどのInfrastructure as Codeを利用すれば、サーバーの構築やネットワーク設定を自動化できます。
OSの更新、監視、アラート通知、異常時の再起動なども、ある程度は自動化できます。
しかし、自動化できることと、人間の判断なしに運用を続けられることは別です。
例えば、VPNの通信量が急増した場合、それが正常な業務通信なのか、不正アクセスの兆候なのかを判断する必要があります。
監視システムが異常を検知しても、直ちに通信を遮断すべきなのか、業務への影響を確認すべきなのかという判断が残ります。
脆弱性が公表された場合も同じです。
パッチの自動適用は可能でも、更新によって接続障害が発生する場合があります。更新の緊急性、停止の許容範囲、復旧方法などを考慮しなければなりません。
また、自動復旧によってサービスが再開したとしても、侵害された可能性まで解消されたとは限りません。
サービスが正常に動いていることと、セキュリティ上の問題が解決していることは同じではないのです。
こうした判断まで自動化するには、異常の分類、対応方針、例外処理、復旧後の検証など、さらに多くの仕組みが必要になります。
そして、その自動化システム自体も継続的な検証と保守の対象になります。
VPNサーバーを自動構築できることと、公開VPN基盤を安全に無人運用できることの間には、大きな隔たりがあります。
大企業と中小企業では、運用できる体制が違う
大企業であれば、専任のインフラ担当者やセキュリティチームを配置し、監視、脆弱性対応、障害復旧などを継続的に行う体制を整えられるかもしれません。
しかし、中小企業では事情が異なります。
数人から数十人規模の会社が、VPN基盤のためだけに専任担当者を配置することは現実的ではない場合が多いでしょう。
本来の業務と兼任している担当者にとっては、夜間や休日の障害対応も大きな負担になります。
さらに、セキュリティインシデントが発生した場合、その担当者だけで侵害範囲の調査や復旧判断まで行えるとは限りません。
自動化によって作業を減らすことはできても、運用上の判断と責任までなくせるわけではありません。
重要なのは、VPNを構築できるかどうかではなく、限られた人員で、そのVPNを何年も安全に運用し続けられるかということです。
9. 障害が起きたら、誰が責任を取るのか？
ここまで読むと、外部のVPNサービスを利用することにも疑問が生じるかもしれません。
「もしサービスが侵害されたらどうするのか」
「VPNが停止して業務ができなくなった場合、誰が責任を取るのか」
当然、考えるべき問題です。
しかし、ここでは二つの責任を分けて考える必要があります。
一つは、障害やセキュリティインシデントが発生した場合、誰が調査し、対処し、復旧させるのかという運用上の責任です。
もう一つは、その結果として発生した業務上の損失を、誰がどこまで金銭的に補償するのかという契約上の責任です。
この二つは同じではありません。
メガクラウドでも、業務損失の全面補償は一般的ではない
AWS、Microsoft Azure、Google Cloudのような大規模クラウドサービスでも、契約上の損害賠償には制限が設けられています。
例えば、各社の標準的な契約には、逸失利益や間接損害などを原則として補償対象から除外する規定があります。
損害賠償額についても、原因となったサービスの過去12か月間の利用料金などを基準とした上限が設けられています。
もちろん、契約形態や適用法、故意・重過失などの事情によって取り扱いが変わる場合があります。
契約の確認先は、AWS Customer Agreement第9条、Microsoftのオンラインサブスクリプション契約第6条、Google Cloud Terms第12条です（2026年10月29日確認）。ここでは標準契約の例を示しており、例外条項、無償サービスの別上限、個別契約やSLAの救済も確認します。これらの他社契約は、HomeGrid VPNの補償内容を示すものではありません。
しかし、基本的に、クラウドサービスを利用しているからといって、障害による事業損失のすべてを補償してもらえるわけではありません。
それでも、多くの企業がクラウドサービスを利用しています。
なぜでしょうか。
自社ですべてのインフラを構築・監視・保守するよりも、専門事業者に運用を任せる方が合理的な場合があるからです。
VPNも同じです。
自社で公開VPN基盤を運用する場合、異常が発生すれば、社内の誰かが原因を調査し、対処方法を判断し、復旧させる必要があります。
外部サービスを利用する場合は、契約で定められた範囲で、サービス提供者が共通基盤の運用や障害対応を担います。
もちろん、それによって利用企業側のすべての責任がなくなるわけではありません。
業務継続計画、端末管理、アクセス権限、バックアップなどは、引き続き利用企業側で考える必要があります。
また、サービス提供者の運用体制や障害時の連絡方法、復旧方針なども確認するべきです。
外部サービスを利用する価値は、事故が起きた際にすべての損害を肩代わりしてもらうことではありません。
公開されたインフラを、自社だけで継続的に運用しなくて済むことに価値があります。
10. HomeGrid VPNでは、WireGuardとOutbound Onlyを組み合わせる
HomeGrid VPNは、WireGuardとHub & Spoke構成を利用したVPNサービスです。
リモート端末と、オフィスに設置したGridが、それぞれCloud Hubへ接続します。
GridはCloud Hubに対してOutbound通信を行うため、オフィス側でIPv4ポート転送やIPv6 Inbound Ruleを用意する必要がありません。
これはGridへのVPN接続を成立させるための、拠点側ルーターの受信許可についての説明です。原則としてDDNSも前提にしませんが、外向き通信が制限されているネットワークでは接続条件の確認が必要です。
これは、CGNATやIPv4 over IPv6など、ポート転送に制約がある回線でも利用しやすい構成です。
さらに、外出先のリモート端末が接続するのはCloud Hubであり、オフィスのPublic IPアドレスではありません。
出張先のホテルや自宅のWi-FiなどでVPNの接続先が観測されたとしても、そこで見える直接の接続先はCloud Hubです。
HomeGrid VPNでもVPN通信を観測される可能性はあります。しかし、リモート端末が自社のVPN受信口へ直接接続する構成ではありません。
また、HomeGrid VPNでは、VPN接続後のアクセス範囲をサブネット単位のLAN ACLで制御できます。
社内LANのすべてを一律に許可するのではなく、必要なサブネットへのアクセスだけを許可する構成が可能です。
なお、LAN ACLは端末単位の認証やアクセス制御を代替するものではありません。OS側のFirewall、端末管理、業務システムの認証なども引き続き必要です。
LAN ACLの許可単位は登録端末×宛先LAN（サブネット）で、既定では拒否です。上の「代替しない」とは、端末のOSログインや業務システムの認証・権限を置き換えないという意味です。同じサブネット内のサーバー別・ポート別の許可機能ではありません。設定変更は反映まで最大5分かかる場合があるため、許可・拒否の両方を確認します。操作と現行仕様はLAN ACLのガイドを参照してください。
公開中継基盤を自社で運用する必要がない
HomeGrid VPNでは、Cloud Hubの運用をサービス提供者が担います。
そのため、利用企業がAWSやVPS上に公開中継サーバーを個別に構築し、維持する必要はありません。
もちろん、Cloud Hubの監視、更新、障害対応などの作業がなくなるわけではありません。
それらはサービス提供者が継続して行うべき運用です。
一方、利用企業側には、Gridやクライアント端末の管理、LAN ACLの設定、業務システムのアクセス管理などの役割が残ります。
また、Cloud HubもVPN経路上の構成要素であり、その可用性や運用体制への依存はあります。
HomeGrid VPNの価値は、すべての運用が不要になることではなく、公開VPN基盤の継続的な運用を、利用企業がそれぞれ抱え込まずに済むことです。
11. VPNを捨てるのではなく、公開する入口を見直す
WireGuardの無応答設計は、未認証の第三者による探索や不正なハンドシェイクに対して、重要なセキュリティ上の利点を持っています。
しかし、VPNサーバーが応答しないことと、その接続先を誰にも知られないことは同じではありません。
社員が自宅や出張先からVPNへ接続する以上、その通信は何らかのネットワークを経由します。
そして、その経路上で観測できる情報には、暗号化された通信内容とは別に、接続先IPアドレスなどの情報が含まれます。
Wi-Fiでは、無線フレーム自体が第三者に保存され、条件によっては後日解析される可能性もあります。
だからといって、WireGuardを使うべきではないという話ではありません。
WireGuardを利用しながら、自社側の公開VPN受信口をなくすこともできます。
また、AWSやVPSを利用して自社で中継サーバーを構築することも可能です。
しかし、公開中継サーバーを自社で運用するのであれば、その継続的な監視、更新、障害対応、セキュリティ判断も自社の仕事になります。
大企業なら専門チームを配置できるかもしれません。しかし、数人から数十人規模の企業にとって、同じような運用体制を整えることは簡単ではありません。
WireGuardは、知らない相手からの通信に応答しない。Outbound Onlyは、そもそも自社側に公開VPNの入口を作らない。
そして、公開中継基盤をサービスとして利用すれば、その運用を各企業が個別に抱える必要もなくなります。
VPNを利用するために、必ずしもオフィスへ外部から直接接続できる入口を設ける必要はありません。
VPNを捨てる必要はない。見直すべきなのは、VPNを使うために何をインターネットへ公開し、その公開基盤を誰が運用するのかです。
ネットワークの見直しは、業務効率化にもつながる
さらに、こうしたネットワーク構成の見直しは、セキュリティ対策だけにとどまりません。
社内ネットワークへの安全な接続経路を整備することで、リモートワークの導入や、外出先からの業務システムの利用も容易になります。
例えば、GitHub ActionsのセルフホストランナーをVPN内に配置すれば、CI/CDの仕組みを利用して社内サーバーやVPSへのデプロイを自動化できます。ランナーからデプロイ先へVPN経由でアクセスできる構成なら、デプロイ先のSSHや管理ポートをインターネットに公開する必要はありません。
また、クラウド上のVPCと接続すれば、開発環境と運用環境をネットワーク単位で分離し、それぞれの環境へのアクセスを制御する構成も実現できます。
これにより、開発担当者が必要な環境だけにアクセスできるようにしたり、環境ごとに接続経路を管理したりすることも可能になります。実際の分離には、VPC側のルーティングやSecurity Groupなどの設定も必要です。
さらに、災害や回線障害が発生した場合には、あらかじめ用意した別拠点への接続切り替えなど、BCP（事業継続計画）にも応用できます。
VPNだけでデータや業務アプリケーションが複製されるわけではありません。代替拠点の電源・回線、認証の復旧手順、データのバックアップと復元、切り替え訓練を別途用意します。CI/CDでも、信頼できないコードを実行するジョブに内部ネットワークやデプロイ用資格情報への権限を与えない設計が必要です。
VPNは、単に社外から社内へ接続するためだけの仕組みではありません。
VPNの構成を見直すことは、外部からの攻撃対象を減らすだけでなく、日常の業務効率と事業継続性を高めることにもつながります。
関連記事
- リモートワークを支えるネットワーク設計 — オフィスにいなくても業務システムへ安全にアクセスするための構成
- GitHub ActionsとVPNを連携したCI/CD — 公開SSHを使わず、セルフホストランナーからサーバーへデプロイする方法
- VPCを利用した開発・運用環境の分離 — ネットワーク単位の分離とアクセス制御
- 災害時にも業務を継続するためのネットワークBCP — 拠点や回線が利用できなくなった場合の接続先切り替え