社内ネットワーク上のWebサーバーでもHTTPS対応が必要な理由

はじめに

社内ネットワーク上で運用しているWebサーバーについて、HTTPS対応は完了しているでしょうか。もし、いまだにHTTPでコンテンツを提供している場合、近い将来「突然アクセスしづらくなる」「ダウンロードが止まる」といった形で、業務に影響が出る可能性があります。

背景にあるのは、Chromiumベースのブラウザ（Google ChromeやMicrosoft Edgeなど）が進めている、HTTPを可能な限りHTTPSへ自動的に切り替える取り組みです。リンクをクリックしたときに最初からHTTPSでの接続を試み、うまくいかない場合に警告を表示するなど、「HTTPは例外扱い」という方向にブラウザ側の挙動が寄っています。

重要なのは、この変化がインターネット公開サーバーだけでなく、社内ネットワーク上のサーバーにも同様に影響しうる点です。社内向けの業務システム、ファイル配布サイト、手順書ポータル、機器の管理画面などがHTTPのままだと、ユーザー側の操作負担が増えるだけでなく、運用部門への問い合わせ増加や、例外設定の乱立につながります。

本記事では、社内WebサーバーをHTTPS化するメリットを整理したうえで、Chromium系ブラウザの挙動が業務へ与える影響と、現実的な対応策を解説します。結論として、社内WebサーバーのHTTPS化は「例外設定でしのぐ」のではなく、プライベートCAを軸に設計して恒久対策とするのが安全です。

WebサーバーをHTTPS化するメリット

Webコンテンツのセキュリティ確保には、HTTPS化が欠かせません。HTTP通信は暗号化されていないため、通信経路上で盗聴や改ざんが起こっても検知・防止できません。これに対し、HTTPSはTLS（Transport Layer Security）を用いて通信を保護し、データ保護の前提条件を満たします。

• データの機密性を高める
  HTTPSでは通信が暗号化されるため、通信内容の盗み見（受動的な盗聴）に対する耐性が上がります。社内ネットワークであっても、端末の侵害、内部不正、誤接続、ミス設定などを前提に、通信経路の保護を「省略しない」ことが重要です。
• データの完全性を高める
  TLSは通信途中の改ざんを検知でき、意図しない内容の差し替えや注入のリスクを下げます。HTTPでは「途中で変えられても分からない」状態が残るため、業務画面や配布ファイルの信頼性を担保できません。
• Webサーバーの正当性確認
  サーバー証明書により、接続先が想定したサーバーであることをクライアント側が検証できます。これはフィッシング対策だけでなく、社内であっても「誤ったサーバーへ誘導される」「名前解決やプロキシ経由で別の経路に乗る」といった事故の抑止に有効です。

インターネットに公開されたWebサーバーでは、いわゆる常時HTTPS化が定着し、主要ブラウザはHTTPサイトへのアクセス時に「保護されていない通信」といった警告を表示する方向を強めてきました。いま起きているのは、その流れが社内向けのHTTPにも波及し、「警告が出る」「操作が増える」「ダウンロードが止まる」など、運用面の不都合として表に出てくる段階に入っている、ということです。

社内ネットワーク上のWebサーバーに関して

社内ネットワークはインターネットと比較して外部攻撃者が入り込みにくい構造であることが多い一方、リスクがゼロになるわけではありません。端末のマルウェア感染、内部不正、委託先端末の持ち込み、無線LANの誤設定、ログ取得や監視の抜けなど、現実の運用では「社内だから安全」という前提が崩れる場面が存在します。したがって、社内であってもHTTPSで暗号化し、ブラウザが正しく検証できる構成にする意義は大きいと言えます。

さらに近年は、ブラウザ側の仕様変更が、社内HTTPの運用継続を難しくしています。HTTPでコンテンツを公開していると、警告表示が増えてユーザビリティが下がるだけでなく、ダウンロードや遷移に追加操作が必要になり、問い合わせや手順書更新が発生します。これを避けるために例外設定をばらまくと、結果的に「安全でない通信を許す範囲」が拡大し、統制が難しくなります。

社内WebサーバーのHTTPS化は、セキュリティ対策であると同時に、ブラウザの仕様変更に対する“業務継続のための整備”としても重要になっています。

Chromiumの「HTTPS by default」とは？

Chromiumは、複数の主要ブラウザの基盤となるオープンソースプロジェクトです。Chromium系ブラウザでは、HTTPでのナビゲーションに対してHTTPSへの自動アップグレードを試みる仕組み（HTTPSアップグレード、HTTPS-First関連の機能）が段階的に強化されています。挙動のポイントは次の2つです。

HTTPS by default における挙動

• HTTPからHTTPSへの自動アップグレード
  HTTPリンクをクリックした場合でも、ブラウザはまずHTTPSでの接続を試みます。HTTPSで到達できるなら、そのままHTTPSで通信します。
• HTTPSに失敗した場合の警告や追加操作
  HTTPSで接続できない場合、ブラウザは「安全でない接続」である旨を明示し、ユーザーに追加操作を求める、または警告を表示します。結果として、従来は気付かず利用できていた社内HTTPサイトが“使いにくくなる”形で顕在化します。

つまり、ユーザー体験としては「リンクはあるのに開けない」「毎回警告が出る」「手順が増える」といった形になりやすく、運用側は問い合わせ対応や例外設定の検討を迫られます。

HTTPコンテンツのダウンロードに関する警告

「HTTPS by default」と関連して、ChromiumベースのブラウザはHTTPで提供されるコンテンツのダウンロードについても警告を表示したり、状況によっては制限したりします。理由は次の2点に集約されます。

• セキュリティリスクの軽減
  HTTPで提供されるファイルは暗号化されていないため、通信途中での改ざんや差し替えを排除できません。ユーザーが意図しないファイルを受け取るリスクを下げるため、ブラウザはHTTP経由のダウンロードを「安全ではない操作」として扱います。
• 混合コンテンツの抑止
  HTTPSページ上のリンクやボタンからHTTPのファイルを取得する構成は、ブラウザにとって「HTTPSの信頼境界を崩す」要因になります。社内ポータルがHTTPSでも、配布物がHTTPのままだと警告や制限が発生しやすく、結果的に業務配布の手順が不安定になります。

業務に与える影響

「HTTPS by default」系の挙動により、HTTPでのファイルダウンロードが警告対象になると、業務影響は現場で一気に顕在化します。ユーザーが毎回判断を迫られたり、操作が止まったりするためです。

実際、2024年4月には、Microsoft Edge（バージョン124）で「HTTP 経由の安全でないダウンロード」に関する警告が意図せず有効化された旨がリリースノートに記載されました。結果として、一部組織で社内HTTPサイトからのダウンロードに影響が出て、情報システム部門へ問い合わせが集中する状況が起きています。

Microsoft Edge Stable チャネルのリリース ノート より引用
https://learn.microsoft.com/ja-jp/deployedge/microsoft-edge-relnote-stable-channel#version-1240247867-april-26-2024

バージョン 124.0.2478.67: 2024 年 4 月 26 日

さまざまなバグとパフォーマンスの問題を修正しました。
安定したチャネル セキュリティ更新プログラムの一覧はこちらにです。

お知らせ: HTTP 経由の安全でないダウンロード

HTTP サイトに危険な可能性のあるコンテンツをダウンロードしたユーザーには、UI 警告が表示されます (たとえば、"sample.exe は安全にダウンロードできません")。 ユーザーは、ダウンロードしたアイテムの ".." で [保持] を選択して続行することもできます。メニュー。 管理者は 、InsecureContentAllowedForUrls ポリシーを使用して、警告が抑制される HTTP サイトを指定することもできます。  Edge 124 での警告の有効化は誤って行われました。 この安定リリースで警告を元に戻しました。 管理者は、機能フラグを InsecureDownloadWarnings 使用して、この今後の機能の影響をテストできます。 手記： この警告は、今後の Microsoft Edge バージョンで有効にする予定です。 (2024 年 5 月 9 日更新のお知らせ)

この記載が示しているのは、次の2点です。

• HTTPダウンロードは「安全ではない操作」として、ブラウザがUIで明示する方向にあること
• 一時的に戻されたとしても、将来的に再び有効化されうるため、放置はリスクであること

社内システムの影響として特に多いのは、次のようなケースです。

• 社内ポータルや手順書から配布しているインストーラ、設定ファイル、証明書ファイルがHTTP配布のまま
• 拠点内の機器管理画面（スイッチ、プリンタ、監視ツールなど）へのリンクがHTTPで固定されている
• HTTPSページの一部リンクだけがHTTPで、混合コンテンツ扱いになる

これらは「コンテンツの中身」よりも「配布経路・遷移の方式」が原因で起きるため、現場は原因特定に時間がかかりやすく、結果として問い合わせが増えます。したがって、個別事象として対処するより、HTTPS化を前提に全体設計を揃えるほうが運用コストを下げやすくなります。

回避方法と対応策

ダウンロード制限による混乱を避ける方法は、大きく2つに整理できます。ただし、結論として推奨できるのは1つ目です。

1つ目は、WebサーバーをHTTPS化することです。 HTTPで提供されるリンクや配布物をHTTPSに統一し、ブラウザが期待する「安全な経路」で提供します。これが恒久対策であり、例外設定を増やさずに済みます。

2つ目は、ブラウザ側で例外設定を行うことです。 たとえばMicrosoft Edgeでは、ポリシーで特定URLの警告抑制を行える場合があります。ただし、これは「安全でない通信を許可する範囲」を広げる行為であり、恒久運用で多用すると統制が難しくなります。あくまで移行期間の限定措置として、範囲と期限を決めて扱うべきです。

したがって、対応方針としては「例外設定で延命する」のではなく、「HTTPS化を計画して、社内HTTPを減らす」ことが重要です。とくに、配布サイトや社内ポータルは影響が出やすいため、優先順位を上げて取り組むのが現実的です。

社内ネットワーク上のWebサーバーをHTTPS化する方法

社内ネットワーク上のWebサーバーをHTTPS化するには、Webサーバー、Webクライアント、認証局（CA）の3つをセットで設計します。社内サーバーの場合、信頼の起点を社内で管理できるため、プライベートCAを利用するのが一般的です。ここでは「失敗しやすいポイント」も含めて整理します。

WebサーバーでのHTTPS化

既存のWebサーバーをHTTPS化する際は、まずサーバー側で鍵ペアを作成し、証明書署名要求（CSR）を生成します。CSRには公開鍵と、証明書に含める識別情報（サーバー名など）が含まれます。

ここで重要なのは、証明書のサーバー名（SANを含む）が、実際のアクセス方法と一致していることです。たとえば「FQDNでアクセスする」「別名（CNAME）でアクセスする」「IPアドレス直打ちが残っている」などが混在すると、証明書検証に失敗しやすくなります。HTTPS化の前に、利用者がどの名前でアクセスしているかを棚卸しし、必要な名前を証明書に含める設計が必要です。

プライベートCAから発行されたサーバー証明書（必要に応じて中間証明書を含む）をWebサーバーにインストールし、TLS設定を有効化します。加えて、HTTPアクセスをHTTPSへリダイレクトする設定を行い、「古いHTTPリンクが残っても最終的にHTTPSへ着地する」状態を作ります。

なお、HTTPS化のついでにTLSの古いバージョンや弱い暗号設定を残すと、クライアント側で接続できない・警告が出る原因になります。社内システムであっても、ブラウザの更新に追従できるTLS設定に合わせることが重要です。

Webクライアントでの対応

社内サーバーの証明書をプライベートCAで発行する場合、クライアント（端末・ブラウザ）がそのCAを信頼できるようにする必要があります。具体的には、プライベートCAのルート証明書（構成によっては中間証明書も）を、端末の信頼済み証明書ストアへ配布します。

配布の方法は環境により異なりますが、企業環境ではドメイン参加端末へのグループポリシー配布、MDMによる配布など、「端末管理の仕組みで一括展開できる形」に寄せるのが基本です。端末に個別インストールが必要な構成は、運用負荷と漏れが発生しやすく、結果として例外設定に頼る原因になります。

また、証明書配布後は、対象端末が正しく信頼できているか、ブラウザ警告が出ないかをテストし、移行対象のWebサーバーを段階的に増やすと安全です。

認証局（CA）の準備と運用設計

社内Webサーバー向けのHTTPS証明書を発行する認証局としては、プライベートCAを用いるのが一般的です。理由は、社内用途に限定すれば「外部のパブリックCAである必要がない」ためで、運用と統制の観点で合理的だからです。

ただし、プライベートCAは「作って終わり」ではありません。HTTPS運用で現実に困るのは、むしろここからです。最低限、次の観点を設計しておく必要があります。

• 証明書の有効期限と更新手順（更新漏れを起こさない運用）
• 秘密鍵の保護（サーバー鍵とCA鍵を同列に扱わない）
• 失効の扱い（失効させる条件、失効情報の配布方法）
• 発行ルール（誰が、何の審査で、どの名前に発行できるか）
• ルートCAと発行CAの分離（必要な場合は段階構成にする）

とくに社内では「機器の追加が多い」「サイトが増える」「配布物が多い」など、証明書発行の要求が継続して発生します。場当たり的に運用すると、証明書の乱立、期限切れ、発行権限の拡大が起こりやすく、結果として障害や統制不備につながります。

このため、社内WebサーバーをHTTPS化するなら、最終的にはプライベートCAを前提に「証明書のライフサイクルを運用できる形」に整えることが重要です。HTTPS化はWebサーバー設定だけでは完結せず、CA運用の設計が品質を決めます。

サーバー証明書の発行にも対応する認証ソリューションのご紹介

Soliton OneGate

Soliton OneGate（ソリトン ワンゲート）は、ソリトンシステムズが提供するIDaaSサービスで、Wi-FiやVPN認証においてデジタル証明書を使用します。多要素認証（MFA）、シングルサインオン（SSO）、SAML認証連携などの機能を備え、環境に応じた認証設計の選択肢を提供します。料金プランにはPKIプラン、Basicプラン、Standardプランがあり、機能はプランによって異なります。

NetAttest EPS

NetAttest EPS（ネットアテスト イーピーエス）は、企業の無線LANやVPNへの接続時の認証を行います。RADIUSサーバー機能、認証局（CA）機能、ネットワーク接続端末にIPアドレスを払い出すDHCPサービスなどをオールインワンで提供しており、要求の厳しいビジネス環境において、高い信頼性と運用性を実現するための十分な性能を備えます。
また、NetAttest EPSは、2002年に物理アプライアンスとしてリリースして以降、時代とIT環境の変化に応じて仮想アプライアンス、クラウドサービスなど、最適な形態で提供することで業種や導入規模を問わず多くのお客様から高い評価を受けてきました。

まとめ

Chromium系ブラウザの仕様変更により、社内WebサーバーがHTTPのままだと、警告表示や追加操作、HTTPダウンロードの扱い強化などが業務影響として表面化しやすくなっています。例外設定で一時的に回避できる場合があっても、恒久対応としては運用統制を難しくし、結果的にリスクと負担を増やします。

社内Webサーバーの持続可能な対応策は、HTTPSへ統一することです。とくに社内用途のWebサーバーであれば、パブリックCAに依存せず、プライベートCAを前提に証明書の発行・配布・更新を運用できる形に整えるのが現実的です。HTTPS化はWebサーバー設定だけで完結しないため、プライベートCAを軸に「証明書ライフサイクルまで含めて」整備することを推奨します。