見出し画像

ホームページを「公開する」だけで終わらせない。GitHub × Cloudflare × CI/CDでセキュリティと可用性を高める運用設計

門王（もんおう）｜小さな仕組みのシステム・ホームページ制作

ホームページ制作というと、一般的には

  1. HTMLやプログラムを作る

  2. レンタルサーバーを契約する

  3. FTPなどでアップロードする

  4. 公開する

というところまでが「制作」と考えられがちです。

FTPでのアップロードはRFC 2577でも非暗号化の仕様が指摘されていますが、小規模なホームページでは現在でも、制作したファイルをSFTP/FTPS等でレンタルサーバーへ配置するシンプルな構成が一般的に利用されています。これは用途によっては十分合理的な方法です。一方、セキュリティや可用性、変更履歴、復旧性が重視されるシステムでは、本番サーバーへ直接ファイルを配置するだけでなく、Git、CI/CD、セキュリティ検査、監視などを組み合わせて公開までの経路そのものを管理します。

私自身も、すべてのホームページに大規模なインフラを用意しているわけではありません。

一般的な企業サイトや小規模サイトでは、XServerなどのレンタルサーバーやGoogle App Engine等へ比較的シンプルに展開することもあります。

一方で、

  • 個人情報を扱う

  • CMSや管理画面がある

  • 業務システムと連携する

  • 医療・士業などセキュリティを重視する

  • ホームページ停止による影響が大きい

  • 改ざんをできるだけ早期に発見したい

  • サーバー障害時にも最低限の情報提供を継続したい

といった案件では、「サーバーへファイルを置くだけ」ではなく、ソースコードの管理から、本番サーバーへの配備、公開後の監視、障害時の切り替えまでを一つのセキュリティシステムとして考えるようにしています。

今回は、そうしたセキュリティ要件の高いWebサイトで採用する構成について紹介します。

以前に"「月額1万円の保守費」を請求するホームページ制作業者に気をつけよう"と言う記事を書きましたが、門王でも数万円の月額費用を請求することがあります。その根拠費用も書きましたので、だいぶ長い記事になりましたが(約20,000文字)、門王の考え方や技術水準、月額費用の内容の参考にいただけますと幸いです。


まず全体像

代表的な構成は次のようになります。

開発PC
  │
  │ Git
  ▼
GitHub Private Repository
  │
  ├─ Branch Protection / Rulesets
  ├─ Pull Request
  ├─ Dependabot
  └─ GitHub Actions
        │
        ├─ Unit Test
        ├─ CodeQL / SAST
        ├─ OSV-Scanner
        ├─ Secret Scan
        ├─ ClamAV
        ├─ Trivy
        └─ SBOM生成
              │
              ▼
        Deploy Artifact
        + SHA-256
        + 電子署名
              │
              ▼
       Deploy Gateway / VPS
              │
        署名・Hashを検証
              │
              ▼
        Production Server
        /releases/<commit>
              │
              ▼
          Cloudflare
      ┌───────┼────────┐
      │       │        │
     CDN     WAF      DDoS
      │       │        │
      └───────┴────────┘
              │
            利用者

さらに、

Production Server
  │
  ├─ File Integrity Monitoring
  ├─ 外部死活監視
  ├─ Backup
  └─ Secondary Origin

を組み合わせます。

障害時には、

Primary Server
      ↓
     DOWN
      ↓
Cloudflare Health Check
      ↓
Secondary Server

または、

非常用の静的サイト

へ切り替えます。

つまり、「侵入されにくくする」だけでなく、「侵入・改ざんされた場合に気づく」「壊れた場合に戻す」「サーバーが停止しても情報提供を続ける」ところまで考えます。

なぜGitを使うのか

Gitを利用する最大の目的は、単なるバックアップではありません。

ホームページを構成するファイルについて、

  • 誰が

  • いつ

  • 何を

  • どのように変更したか

という履歴を残せることに大きな意味があります。

例えば本番サーバーのHTMLに、

<script src="https://example-malware.example/xxx.js"></script>

のようなコードが不正に追加されたとします。

FTPだけで管理している場合、「以前と何が変わったのか」を確認するには、バックアップファイルなどとの比較が必要です。また、なにかが変わっていることに気がつくことも出来ないのが一般的です。

一般的なホームページ制作ツールはローカルファイルをリモートにアップロードするための機能はありますが、リモートとの比較機能は簡易実装なのがほとんどです。

Gitで管理していれば、

git diff

などで変更箇所を確認できます。

正常な状態がGitHubに保存されていれば、本番サーバー側のファイルとの比較もできます。

ローカルPCとGitHubの二重管理にも意味がある

ソースコードは、

開発PC
+
GitHub

の少なくとも2か所に存在します。

そのため、

  • PC故障

  • SSD故障

  • 誤削除

  • ランサムウェア

  • サーバー上のファイル破損

  • 不正な変更

などが発生しても、別の場所から復元できる可能性があります。

ただし、GitHubがあるからバックアップは不要という意味ではありません。

GitHubアカウントそのものが侵害される可能性もあるため、重要な案件ではGitHubとは別系統にも定期的なバックアップを持ちます。

FTPでアップロードしている場合、プライマリデータはローカルPCであることがほとんどです。この場合、PCにウイルスや不正ソフトが混入しデータ改ざんが起きた場合は、改ざんされたデータが正規データとしてFTPにアップロードされてしまうため、そもそも差分が発生することもありません。

mainブランチを直接変更できないようにする

重要な案件では、

開発
↓
git push
↓
即本番

にはしません。

例えば、

feature branch
↓
Pull Request
↓
Security Check
↓
Test
↓
mainへmerge
↓
Deploy

という流れにします。

mainブランチにはRulesetsやBranch Protectionを設定し、

  • Pull Request必須

  • CI成功必須

  • force push禁止

  • 意図しないbranch削除禁止

  • 必要に応じてcommit署名

などのルールを設けます。

これにより、「誰かがmainへ直接ファイルを書き換え、そのまま公開される」という経路を減らします。

GitHubではプランに応じてprivate repositoryにも高度なrepository rulesを適用できます。GitHub Teamは2026年8月時点で1ユーザー月4ドルです。

git pushしただけで自動的に本番へ反映する

GitHub Actionsを利用すると、

git push
↓
GitHub Actions起動
↓
テスト
↓
セキュリティ検査
↓
ビルド
↓
本番デプロイ

まで自動化できます。

重要なのは、単純な

push → FTP

ではないことです。

途中に複数のチェックポイントを設け、一つでも基準を満たさなければ本番環境を更新しないようにします。

CodeQLでソースコードを検査する

GitHub Code Securityを利用できる案件では、CodeQLも利用します。

CodeQLはソースコードを解析し、潜在的なセキュリティ問題やプログラミング上の問題を検出する仕組みです。

GitHub Code SecurityにはCode Scanning、CodeQL、Dependency Review、Copilot Autofixなどが含まれています。Private Repositoryで利用するにはGitHub TeamまたはEnterpriseとGitHub Code Securityが必要です。

例えば、

  • SQL Injectionにつながる可能性

  • Cross Site Scripting

  • 安全でない入力処理

  • コマンドインジェクション

  • パストラバーサル

  • その他の危険なコードパターン

などを、公開前に発見できる可能性があります。
ただし、CodeQLはウイルス対策ソフトではありません。

そこで他の検査も組み合わせます。

依存ライブラリもチェックする

現在のWebシステムでは、自分ですべてのプログラムを書くことはまずありません。

Pythonなら、

Bottle
Flask
Django
Pillow
Jinja2
requests
Peewee

など、さまざまな外部ライブラリを利用します。

JavaScriptでも同様です。

そこで問題になるのが、自分のコードに脆弱性がなくても、使用しているライブラリに脆弱性が存在するケースです。

Dependabot

GitHubのDependabotを利用すると、依存関係に既知の脆弱性が見つかった場合に警告を受けたり、修正版へ更新するPull Requestを自動生成したりできます。

Dependabot Security Updatesはprivate/publicを問わず利用でき、脆弱なGitHub Actionsについても修正Pull Requestを作成できます。

例えば、

使用中ライブラリ
version 1.2.0
      ↓
重大な脆弱性発見
      ↓
安全な1.2.1が公開
      ↓
Dependabot
      ↓
更新Pull Request

という流れを作れます。

OSV-Scannerも併用する

さらにGoogleのOSV-ScannerなどをCI/CDへ組み込みます。

OSV-Scannerはプロジェクトの依存関係とOSVの脆弱性データを照合するためのツールです。GitHub Actions用の公式ワークフローも提供されています。

例えば、

requirements.txt
package-lock.json
その他lock file
       ↓
OSV-Scanner
       ↓
既知脆弱性
       ↓
Critical
       ↓
Deploy中止

とできます。

サプライチェーン攻撃への対策

近年は、自分たちが作ったコードそのものではなく、その開発経路を狙う攻撃も重要です。

例えば、

  • npm/PyPI等の依存パッケージ

  • GitHub Actions

  • buildツール

  • コンテナイメージ

  • CI/CD

  • 配布ファイル

などです。

そのため、「ソースコードを検査する」だけでは十分ではありません。

GitHub Actions自体も固定する

GitHub Actionsでは、

uses: example/action@v1

のような指定が一般的ですが、より厳格な環境ではActionをcommit SHAへ固定します。

uses: example/action@3a8e1c7...

のような形です。

これによって、同じタグの参照先が変更されるリスクを抑えます。

またDependabotを利用して、使用しているGitHub Actions側の脆弱性も監視します。GitHub自身もActionsを安全に利用するためのセキュリティ対策としてdependency monitoringなどを案内しています。

パスワードやAPIキーをGitへ入れない

非常に多い事故の一つが、

.env
API KEY
DB PASSWORD
SSH PRIVATE KEY
AWS KEY
Cloudflare Token

などを誤ってGitへcommitしてしまうことです。

そこでSecret Scanを実施します。

GitHub Secret Protectionを利用できる場合はGitHub側のsecret scanningやpush protectionを使います。

一方、予算を抑える構成ではGitleaksなどをCI上で実行します。

Gitleaksはパスワード、APIキー、tokenなどをGit repositoryやファイルから検出するためのツールです。CLI自体はオープンソースですが、GitHub MarketplaceのActionには組織利用時の別ライセンス条件があるため、利用形態は案件ごとに確認します。

ClamAVによるマルウェア検査

ソースコードや生成された成果物に対し、ClamAVによる検査も行えます。

例えば、

clamscan --recursive .

でディレクトリ以下を再帰的に検査できます。

流れとしては、

GitHub Checkout
↓
依存関係取得
↓
Build
↓
ClamAV Scan
↓
問題なし
↓
次の工程

とします。

ただし、ここで注意したいのは、ClamAVを通過した＝ソースコードが100％安全ではないことです。

既知マルウェアを検出する仕組みと、悪意を持って書かれた独自のバックドアを見つける仕組みは別です。

そのため、

CodeQL
+
Dependency Scan
+
Secret Scan
+
ClamAV
+
コードレビュー

を組み合わせます。

Trivyによる追加検査

VPSやDockerを利用する案件ではTrivyも利用できます。

Trivyは、

  • コンテナ

  • repository

  • filesystem

  • 設定

  • secret

  • SBOM

などを対象に脆弱性や設定ミスを検出できるオープンソースツールです。

例えば、

Docker Image Build
↓
Trivy Scan
↓
Critical vulnerability = 0
↓
Deploy

という条件にできます。

SBOMを作る

高セキュリティ案件では、成果物ごとにSBOMを作成することもあります。

SBOMはSoftware Bill of Materialsの略で、そのシステムに何が含まれているのかを一覧化したものです。

例えば、

Web Application v1.2.0

Bottle
Jinja2
Pillow
requests
...

といったソフトウェア構成情報を機械可読な形式で保存します。

Syftなどのツールを利用すると、ファイルシステムやコンテナからSBOMを生成できます。SyftはApache-2.0で公開されています。

これにより、「この脆弱性のあるライブラリを、現在本番システムで使っているか」を後から確認しやすくなります。

「GitHubにあるコード」と「本番へ配備するコード」を分ける

ここも重要な考え方です。

本番サーバー上で、

git pull

してそのまま更新する方法もあります。

しかし、より厳格な環境では、本番サーバーをGit repositoryとして扱いません。

GitHub Actions上で、

source
↓
test
↓
security scan
↓
build
↓
site.tar.gz

という「配備用成果物」を作ります。

本番サーバーへ送るのは、

site.tar.gz
SHA-256
SBOM
署名

などです。

SHA-256だけでなく電子署名も利用する

例えば、

site.tar.gz

に対してSHA-256を生成します。

本番側でもSHA-256を計算し、

CIで計算したhash
=
本番で計算したhash

であることを確認します。

これで通信途中や保管途中のファイル破損・変更を検出できます。

さらに、成果物そのものへ電子署名を付与します。

SigstoreのCosignではコンテナだけでなく一般的なファイルやblobにも署名し、受け取り側で検証できます。CosignはApache-2.0で公開されています。

GitHub Artifact Attestations

GitHubにはArtifact Attestationsという仕組みもあります。

これは、「この成果物は、どのrepositoryの、どのcommitから、どのworkflowによって作られたのか」というprovenance（来歴）を暗号学的に確認できるようにする仕組みです。GitHubはArtifact Attestationsをsoftware supply chainのprovenance確立に利用できると説明しています。

ただし料金面で重要な点があります。

2026年8月時点では、GitHub Free、Pro、TeamでArtifact Attestationsを利用できるのはpublic repositoryで、private/internal repositoryで利用するにはGitHub Enterprise Cloudが必要です。

そのためprivate repositoryでは、

予算に余裕あり
→ GitHub Enterprise Cloud + Artifact Attestation

予算を抑える
→ Cosign + SHA-256 + SBOM

など、案件によって調整します。

セキュリティ機能は「全部入れないと意味がない」というものではありません。

費用対効果を考えて組み合わせます。

本番サーバーへ直接SSHさせない構成もある

一般的なGitHub Actionsのデプロイでは、

GitHub Actions
↓
SSH
↓
Production

とします。

これは十分実用的ですが、GitHub側に本番サーバーへ接続する秘密情報を持たせることになります。

より厳格な環境では、

GitHub
↓
検査済み成果物
↓
Deploy Gateway
↓
Production

とします。

あるいは本番側から成果物を取得するpull型にします。

Deploy Gatewayでは、

署名確認
↓
SHA-256確認
↓
マルウェア検査
↓
承認された成果物だけ配備

とします。

これにより、開発環境と本番環境の境界を明確にできます。

本番サーバーへ上書きしない

FTPで、

index.html 上書き
style.css 上書き
app.py 上書き

という方法の場合、アップロード途中で問題が発生すると、

HTMLだけ新しい
CSSは古い
JavaScriptだけ新しい

という状態になることがあります。

そこでVPS等ではrelease単位で配置します。

/var/www/

releases/
├─ 921fe82/
├─ b82ca92/
└─ f12391a/

current -> releases/f12391a

新しいreleaseを別ディレクトリへ完全に展開し、

検証
↓
OK
↓
current切替

とします。

いわゆるAtomic Deploymentに近い考え方です。

問題があればすぐ旧バージョンへ戻す

例えば新しいreleaseに問題があれば、

current
↓
一つ前のrelease

へ戻します。

プログラムを再アップロードするのではなく、どのreleaseを公開するかを切り替えるだけです。

Database migrationを伴わない更新であれば、非常に速く復旧できます。

Webサーバー自身にはコードを書き換えさせない

これも大切です。

例えば、

/var/www/releases/

に対してWebアプリケーション実行ユーザーはread onlyにします。

書き込みを許可するのは、

/uploads
/cache
/data

など必要な場所だけです。

これにより、仮にWebアプリケーションに脆弱性がありWebサーバーの権限を奪われても、Webアプリケーション自身のコードを書き換えられる範囲を小さくすることができます。

公開後もファイルを監視する

安全にデプロイしたから終わりではありません。

例えば攻撃者がFTP、SSH、Webアプリケーションの脆弱性など別の経路からサーバーへ侵入し、

index.html
app.py
.htaccess

を書き換える可能性があります。

そこでFile Integrity Monitoringを行います。

WazuhにはFile Integrity Monitoring機能があり、監視対象ファイルの作成・変更・削除等を検出できます。checksumなどの情報を利用して変更を監視できます。

例えば、

GitHub Deployなし

なのに

app.py変更

というイベントが発生した場合、正常な更新経路を通っていない変更として調査できます。

GitHubと本番を定期比較する

さらに単純な仕組みとして、本番ファイルのhashを定期計算し、

本番manifest
↓
GitHub Release manifest
↓
比較

することもできます。

一致しなければ通知します。

Gitが「過去と現在の違い」を確認する仕組みだとすれば、

これはGitHubで承認された状態と、実際に公開されている状態が一致しているかを見る仕組みです。

CloudflareをWebサーバーの前段に配置

公開経路にはCloudflareを利用することがあります。

Internet
↓
Cloudflare
↓
Origin Server

という構成です。

Cloudflareには、

  • CDN

  • DDoS Protection

  • WAF

  • Rate Limiting

  • DNS

  • Bot対策

  • Load Balancing

などがあります。

CloudflareのDDoS Protectionは全プランで利用でき、自動的にDDoS攻撃を検出・緩和します。CloudflareはL3/L4/L7のDDoS保護を全プランへ提供しています。

CDNは高速化だけが目的ではない

CDNを利用すると、

Browser
↓
Cloudflare Edge
↓
Cache

から画像、CSS、JavaScriptなどを返せることがあります。

その場合、すべてのリクエストをOrigin Serverまで届ける必要がありません。

つまりCDNには、

  • 表示高速化

  • Originの負荷軽減

  • 大量アクセスへの耐性向上

  • 障害リスク低減

という意味があります。

WAF

Cloudflare WAFでは、HTTP/HTTPS requestをCloudflare Edge上で検査し、managed ruleやcustom ruleによって不正なrequestをOriginへ届く前にblockできます。

Cloudflare FreeプランでもFree Managed Rulesetが利用でき、高影響かつ広く悪用されている脆弱性に対するルールが提供されています。

よりセキュリティを重視する場合はProやBusinessを利用します。

ログイン画面にはRate Limit

例えばCMSが、

/admin/login

にある場合、

1秒間に100回

ログイン試行される必要は通常ありません。

そこで、

/admin/login

だけ厳しいRate Limitを設定できます。

CloudflareのRate Limiting Rulesではrequest条件と回数に応じて制限を設定でき、login endpointへのbrute-force対策などに利用できます。

Origin Serverを直接公開しない

Cloudflareを導入しても、

example.jp
↓
Cloudflare
↓
203.xxx.xxx.xxx

のOrigin IPへ直接アクセスできれば、攻撃者がCloudflareを迂回する可能性があります。

VPSであれば、

80/443
↓
Cloudflare経由のみ許可

などのFirewall設定を行います。

Cloudflare経由のrequestとOriginへ直接来たrequestを分離することで、

Internet
↓
Cloudflare
↓
Origin

という経路を強制します。

サーバーが停止してもサイトを止めない

セキュリティと同じくらい重要なのが可用性です。

どれだけ安全なサーバーでも、

  • ハードウェア障害

  • ネットワーク障害

  • OS障害

  • アップデート失敗

  • サービス障害

  • 人為的ミス

などで停止する可能性があります。

重要サイトでは、

Primary Origin
+
Secondary Origin

を用意できます。

Cloudflare Load Balancing

Cloudflare Load Balancingでは複数のOriginに対してHealth Checkを実施し、異常なOriginから正常なOriginへtrafficを切り替えられます。Cloudflareは自動failoverを含む複数OriginへのLoad Balancingを提供しています。

例えば、

              ┌─ VPS A
Cloudflare ───┤
              └─ VPS B

という構成です。

通常はVPS Aへ接続し、

VPS A
↓
Health Check NG
↓
VPS B

へ切り替えます。

Load Balancingは2026年8月時点で月5ドルから提供されています。

完全な冗長化が必要でない場合

すべてのホームページに2台の本番サーバーを用意する必要はありません。

例えば企業ホームページであれば、

通常
↓
本番サーバー

障害
↓
非常用静的ページ

という構成でも十分有効です。

非常用ページには、

  • 現在メンテナンス中であること

  • 電話番号

  • 住所

  • 営業時間

  • 緊急のお知らせ

  • 問い合わせ先

など最低限の情報だけ掲載します。

Cloudflare Workers Static Assetsを非常用サイトにする

Cloudflare WorkersではHTML、CSS、画像などのstatic assetsをCloudflare側へ配置できます。Cloudflareがこれらのstatic assetsをcacheして配信します。

2026年8月時点では、Workersのstatic asset requestは無料・無制限で、static assetの保存自体にも追加料金がありません。

そのため、

Primary Origin正常
↓
通常サイト

Primary Origin障害
↓
Cloudflare上の非常用サイト

という構成も検討できます。

動的なWorker処理についてはFree Planで1日100,000 requestまでの制限があります。Paid Planは最低月5ドルです。

GitHub Pagesをさらに非常用として持つこともできる

静的ホームページであればGitHub Pagesを非常用として用意する方法もあります。

例えば、

通常
Cloudflare → Primary

非常時
Cloudflare Workers Static Assets

さらに別系統
GitHub Pages

という考え方です。

ただしDNS自体をCloudflareへ依存している状態では、Cloudflareそのものの大規模障害まで完全に回避できるわけではありません。

本当の意味で障害ドメインまで完全に分離するなら、

DNS
CDN
Origin
Cloud Provider

まで別事業者へ分散する必要があります。

一般的な企業ホームページでそこまで行うと、費用と管理負担の方が大きくなることがあります。

そのため可用性も予算と必要性のバランスで決めます。

実際の公開までの流れ

高セキュリティ構成では、例えば次のようになります。

git push
↓
GitHub
↓
Branch Rule確認
↓
Test
↓
CodeQL / SAST
↓
Dependency Scan
↓
Secret Scan
↓
ClamAV
↓
Trivy
↓
Build
↓
SBOM生成
↓
SHA-256生成
↓
電子署名
↓
Deploy Artifact生成
↓
Deploy Gateway
↓
署名検証
↓
Hash検証
↓
Release Directoryへ展開
↓
Health Check
↓
current切替
↓
Cloudflare
↓
外部Health Check
↓
公開

途中で一つでも問題があれば、

Deployしない

という考え方です。

重要なのは「正規ルート」を作ること

この仕組みで重要なのは、更新するための正規ルートを一本にすることです。

例えば、

開発PC
↓
GitHub
↓
Security Scan
↓
Build
↓
Deploy Gateway
↓
Production

だけを正しい更新方法とします。

すると、本番サーバー上で突然ファイルが変わった場合、「これは通常の更新ではない」と判断できます。

GitHubが侵害された場合も考える

GitHubを使えば100％安全になるわけではありません。

GitHubアカウント自体が乗っ取られる可能性もあります。

そこで、

  • MFA

  • Passkey

  • Security Key

  • Branch Protection

  • Pull Request

  • commit署名

  • CI

  • Artifact署名

  • 本番側での署名検証

などを重ねます。

重要なのは、一つのシステムを100％信用するのではなく、複数の検証点を置くことです。

サプライチェーン攻撃に対しても一段ずつ確認する

理想的には、

SOURCE
↓
Review
↓
SAST
↓
Dependency Scan
↓
Build
↓
SBOM
↓
Artifact
↓
署名
↓
Transfer
↓
署名検証
↓
Deploy
↓
File Integrity Monitoring

とします。

例えば攻撃者が配備ファイルだけを書き換えても、

Signature Error

となります。

本番サーバー上だけを書き換えても、

File Integrity Alert

となります。

依存ライブラリに既知脆弱性があれば、

Dependency Scan Error

となります。

単一の製品ですべてを防ぐのではなく、攻撃者が突破しなければならない層を増やしていくという考え方です。

では、いくらかかるのか

ここはお客様からよく質問されるところでもあります。

実際には、

サーバー費
+
GitHub
+
Cloudflare
+
その他ライセンス
+
初期構築費
+
継続保守費

で決まります。

2026年8月12日時点の代表的な料金を例にします。

料金は今後変更される可能性があり、ドル建てサービスは為替によって日本円での請求額も変わります。

GitHubの料金

GitHub Team

2026年8月時点で、月4ドル / userです。Private RepositoryをOrganizationで本格運用する場合の基本候補です。

GitHub Teamにはprivate repository向けGitHub Actionsが月3,000分含まれています。

小規模なWebサイトを、

push
↓
数分のCI

程度で更新するなら、3,000分を使い切らないケースも多いと考えられます。

超過した場合、2026年8月現在、標準Linux 2-core runnerは1分0.006ドルです。

GitHub Code Security

Private RepositoryでCodeQLなどを利用する場合、GitHub Code Securityが必要になります。

2026年8月現在、月30ドル / active committerです。

active committerは、対象repositoryへ過去90日以内にcommitがpushされた開発者を基準に数えられます。

例えば開発者が1名なら、

GitHub Team
$4

Code Security
$30

合計
$34/月

が一つの目安です。

2人が継続的にcommitするなら、Code Security部分は原則2committer分になります。

そのためCode Securityは、private repositoryを使う小規模サイトでは比較的大きな固定費になります。

GitHub Secret Protection

GitHub Secret Protectionは、月19ドル / active committerです。

例えば1名開発で、

GitHub Team          $4
Code Security       $30
Secret Protection   $19

合計                $53/月

となります。

そのためすべてのお客様へ機械的に導入するのではなく、

予算あり
→ GitHub Secret Protection

予算を抑える
→ Gitleaks CLI等

という選択もできます。

GitHub Enterprise Cloudを利用する場合

GitHub Enterpriseは2026年8月時点で月21ドル/userの価格が表示されています。

Private RepositoryでGitHub Artifact AttestationsまでGitHubネイティブに利用したい場合はEnterprise Cloudが必要です。

1名で、

GitHub Enterprise    $21
Code Security        $30
Secret Protection    $19

合計                 $70/月

程度がGitHub部分の一つの目安になります。

この価格差があるため、private repositoryだから必ずEnterpriseとはしていません。

Artifact signingについてはCosign等のOSSを利用する構成も選択できます。

Cloudflare

Cloudflareはかなり柔軟に費用を調整できます。

Free 0ドル です。

FreeでもDDoS ProtectionやFree Managed Rulesetを利用できます。

小規模サイトであれば、まずFreeから始めることもできます。

Cloudflare Pro

2026年8月現在、年払い換算 月20ドル または 月払い 月25ドル です。

ProfessionalなWebサイトや、Freeより強いWAF・セキュリティ機能を利用したい場合の候補になります。

Cloudflare Business

2026年8月現在、年払い換算 月200ドル または 月払い 月250ドル です。

Businessになると金額が大きく変わるため、「セキュリティ上なんとなく安心だからBusiness」という決め方ではなく、必要な機能・サポート・リスクを確認して選定します。

Cloudflare Load Balancing

Load Balancingは、月5ドルから利用できます。

例えば、

VPS A
+
VPS B

をHealth Checkして自動切替する場合の追加費用です。

Health Checkの頻度や確認locationなどを高度化すると追加料金が発生する構成もあります。Cloudflareでは60秒intervalのmonitorが基本構成に含まれ、より短いintervalや追加locationには別料金のオプションがあります。

Cloudflare Workers

非常用の静的サイトだけなら、static asset requestは無料・無制限です。

動的処理を多く利用する場合はWorkers Paidが、最低月5ドルです。

VPS

VPSは事業者によって異なります。

例えばXServer VPSでは、2GBクラスで契約期間に応じて月額1,000円台から利用できます。2026年8月時点の公式価格表では2GBプランが契約期間に応じて月額換算990円～1,365円程度で掲載されています。

そのためDeploy Gateway程度であれば、

月1,000円～2,000円程度

の小規模VPSから構築できるケースがあります。

ただしWazuh、Docker、複数service、databaseなどを同居させる場合は、より大きなmemoryが必要になります。

一般的なレンタルサーバーならもっと安くできる

XServerの通常レンタルサーバーStandardの場合、通常の12か月契約料金は2026年8月現在月額1,100円で、執筆時点ではキャンペーンにより月額990円となっています。

そのため、

GitHub
↓
CI
↓
XServer
↓
Cloudflare

のような構成なら、かなり低コストで運用できます。

共有レンタルサーバーでは、

  • Firewallを自由に設定する

  • Wazuh Agentを自由に導入する

  • Dockerを利用する

  • release directoryを自由に設計する

  • Cloudflare IPだけをFirewall許可する

といったことが難しい場合があります。

そのため、必要なところだけCI/CDやCloudflareで補強するという考え方になります。

オープンソースを活用すればライセンス費をかなり下げられる

例えば、

OSV-Scanner
Trivy
Syft
Cosign
Gitleaks CLI
ClamAV
Wazuh

などを組み合わせることで、商用ライセンスへの依存を減らせます。

ただし、ソフトウェアが無料＝システム構築費も無料ではありません。

OSSを利用する場合でも、

  • 導入

  • 設定

  • version管理

  • rule調整

  • 誤検知対応

  • security update

  • log確認

  • backup

  • 障害対応

  • 運用document作成

が必要です。

むしろ高セキュリティ環境では、この「運用」の部分が重要です。

構成別のおおよその考え方

1. 一般的なホームページ

GitHub
↓
GitHub Actions
↓
XServer / GAE等
↓
Cloudflare Free

必要に応じて、

Dependabot
OSV-Scanner
Gitleaks
ClamAV

を追加します。

ランニングコストは、主に既存のサーバー費用です。

一般的な企業ホームページなら、この構成でも十分な場合があります。

2. セキュリティを重視するホームページ

GitHub Private
↓
Protected Branch
↓
GitHub Actions
↓
Code Security / OSS Scanner
↓
SBOM
↓
署名Artifact
↓
VPS
↓
Cloudflare Pro
↓
File Integrity Monitoring

例えば1名開発で、

GitHub Team          $4
Code Security       $30
Cloudflare Pro      $20～
VPS              約1,000～2,000円

とすると、月54ドル程度＋VPS費が一つの目安になります。

Secret Protectionを追加するなら、

+ $19

です。

Code SecurityをOSS scannerへ置き換えれば、この部分を大幅に下げることもできます。

3. 高可用性まで重視する構成

GitHub
↓
Security CI/CD
↓
Signed Artifact
↓
Deploy Gateway
      ↓
┌────────────┐
VPS A      VPS B
└─────┬──────┘
      ↓
Cloudflare Load Balancing
      ↓
     User

さらに、

Cloudflare Pro
Load Balancing
Wazuh
外部Backup
非常用Static Site

を組み合わせます。

例えば、

GitHub Team              $4
Code Security           $30
Secret Protection       $19
Cloudflare Pro          $20～
Load Balancing           $5～
VPS × 2           約2,000～4,000円程度

とすると、月78ドル程度＋VPS費からが一つの目安になります。

GitHub Enterprise CloudやCloudflare Businessまで利用すると、さらに上がります。

なぜ初期構築費が発生するのか

「月額サービスを契約するだけなら簡単なのでは」と思われるかもしれません。

実際には、セキュリティ環境の構築には、

GitHub Organization設定
Repository作成
権限設計
Rulesets
Branch Protection
GitHub Actions
Dependency Scan
SAST
Secret Scan
Malware Scan
SBOM
署名処理
Deploy Script
Deploy User作成
SSH権限
Firewall
Cloudflare DNS
WAF
Rate Limit
Origin保護
Backup
Health Check
Rollback
監視
通知

など、多数の設定があります。

また設定しただけではなく、本当に止まるか・本当に切り替わるかをテストする必要があります。

例えば、

脆弱なdependencyを意図的に入れる
↓
Deployが止まるか
Secret文字列をcommit
↓
CIが止まるか
Artifactを書き換える
↓
署名検証で拒否されるか
Primary Serverを停止
↓
Secondaryへ切り替わるか
不正にindex.htmlを書き換える
↓
監視通知が届くか

などです。

そのため、見積もりでは単純な「サーバー設定費」ではなく、設計・実装・テスト・document化までを含めたセキュリティ基盤構築として算定します。

初期構築費の目安

案件によりますが、作業量のイメージとしては、

簡易CI/CD

GitHub
GitHub Actions
簡易security scan
自動deploy
Cloudflare基本設定

であれば、数日以内で構築できることがあります。

標準セキュリティ構成

複数scanner
SBOM
Artifact署名
Deploy Gateway
Atomic Deploy
Rollback
Cloudflare WAF
FIM
Backup

まで行うと、設計・検証を含め数日～1週間以上になることがあります。

高可用性構成

複数Origin
Load Balancing
DB同期
Failover
Backup
監視
復旧テスト

まで含めると、システム内容によってさらに工数が必要です。

そのため初期構築費は、数万円程度の簡易構成から、数十万円以上の高セキュリティ・高可用構成まで大きく変わります。

単純に「セキュリティオプション○万円」とするのではなく、実際に必要な対策から見積もるようにしています。

毎月の保守費にも理由がある

セキュリティは一度構築したら終わりではありません。

例えば、

  • GitHub Security Alert

  • Dependabot Alert

  • OSVの新規脆弱性

  • WAF Event

  • File Integrity Alert

  • Disk容量

  • Backup結果

  • SSL/TLS

  • サーバーupdate

  • library update

  • CI/CD自体のupdate

などを継続的に確認します。

新しい脆弱性はシステム公開後にも発見されます。

そのため保守契約には、ホームページの文章修正だけでなく、セキュリティ基盤そのものを維持する作業が含まれます。

すべてのお客様にこの構成を押し付けるわけではない

ここは非常に重要です。

例えば、

会社概要
サービス紹介
お問い合わせ

だけの小規模企業サイトに、

GitHub Enterprise
Cloudflare Business
VPS × 2
Wazuh
Load Balancer

を導入すれば、技術的には強くなります。

しかし月額コストが大きくなり、管理対象も増えます。

それが本当にお客様の利益になるとは限りません。

リスクと予算に応じて構成を変える

例えば、

小規模サイト

GitHub
XServer
Cloudflare Free
Backup

一般企業

GitHub Private
GitHub Actions
Security Scan
Cloudflare Free / Pro
Backup
Monitoring

セキュリティ要件が高い案件

Protected GitHub Repository
複数Security Scan
Signed Artifact
Deploy Gateway
VPS
Cloudflare Pro / Business
WAF
FIM
Off-site Backup

可用性も非常に重要

上記
+
Secondary Origin
+
Cloudflare Load Balancing
+
Failover Test

というように段階を分けます。

有料ライセンス部分は相談可能

特に料金への影響が大きいのは、

GitHub Code Security
GitHub Secret Protection
GitHub Enterprise Cloud
Cloudflare Pro
Cloudflare Business
Cloudflare Load Balancing

などです。

例えば、

GitHub Code Security
↓
OSV + Trivy + 別SAST
Secret Protection
↓
Gitleaks
GitHub Artifact Attestation
↓
Cosign
Cloudflare Business
↓
Pro
Cloudflare Pro
↓
Free
Secondary VPS
↓
非常用Static Site

など、予算に合わせて設計変更できます。

「高いプランを使うこと」と「安全であること」は同じではない

重要なのは、高価なサービスを契約することではなく、どのリスクに対して何を行っているか説明できることだと考えています。

例えば、

改ざん
→ Git + FIM

脆弱なコード
→ SAST

脆弱なdependency
→ Dependabot + OSV

Secret流出
→ Secret Scan

マルウェア
→ ClamAV

Supply Chain
→ SBOM + Artifact署名

配備途中の改ざん
→ SHA-256 + Signature Verification

DDoS
→ Cloudflare

Web攻撃
→ WAF

サーバー停止
→ Secondary Origin / Static Fallback

更新失敗
→ Atomic Deploy + Rollback

データ消失
→ Backup

のように対応関係を明確にします。

100％安全なシステムは存在しない

ここまでさまざまな対策を書きましたが、「これを導入すれば絶対に侵入されない」というものではありません。

セキュリティでは、

Prevent
Detect
Respond
Recover

すなわち、

防ぐ
↓
検知する
↓
対応する
↓
復旧する

まで考えることが重要です。

ホームページ制作も「運用基盤」まで含めて考える

ホームページは公開した瞬間からインターネット上の攻撃対象になります。

そのためセキュリティ要件の高い案件では、

HTMLを作る
↓
サーバーへアップロードする

だけではなく、

どう管理するか
どう検査するか
どう公開するか
どう監視するか
どう戻すか
どう障害に備えるか

まで含めて設計しています。

一般的なホームページではXServerやGoogle App Engineなどを利用したシンプルな構成にすることもあります。

一方で、医療機関、士業、業務システム連携サイトなど、より高いセキュリティや可用性が求められる場合には、

GitHub
+
CI/CD
+
Security Scan
+
Signed Artifact
+
VPS
+
Cloudflare
+
Monitoring
+
Backup

を組み合わせた構成を検討します。

必要なセキュリティレベルと予算によって、有料サービスとオープンソースを組み合わせることも可能です。

「どこまで必要なのかわからない」という場合も、サイトで扱う情報、停止した場合の影響、想定されるリスクから必要な対策を整理した上で構成を決めることができます。

単に高価な環境を用意するのではなく、必要なところに必要なセキュリティを配置する。

それが、長く安全に運用できるWebサイトを作る上で大切だと考えています。

※本記事に記載したGitHub、Cloudflare、XServer等の料金・仕様は2026年8月12日時点で確認した内容です。サービス内容や料金、為替レート等は変更される場合があります。実際の構築時には最新の料金・利用条件を確認して見積もりを行います。

いいなと思ったら応援しよう！