運営するWebサイトとドメインのセキュリティ対策を実施しました

株式会社webullは、当社が運営するWebサイトとドメインについて、セキュリティ対策の見直しを行いました。攻撃者と同じ視点で外部から診断（アタックサーフェス調査）を行い、見つかった項目に順に対応しています。主な内容は次のとおりです。

1. 攻撃対象領域の縮小（PHP・WordPress の撤去）

PHP の脆弱性（CVE）や WordPress のプラグインを狙った攻撃が増えていることを受け、当社が運営するWebサイトから、PHP・WordPress と、それらを動かしていた従来型のサーバー環境を撤去しました。

現在は、静的生成（SSG）したページを CDN のエッジネットワークから配信し、動的な処理はサーバーレス関数に限定した Jamstack 構成です。OS・Webサーバー・ミドルウェアを自社で運用しパッチを当て続ける必要のあるオリジンサーバーを持たず、攻撃の入口になりやすい管理画面（/wp-admin）や xmlrpc.php、公開側のデータベースも存在しません。

2. 通信と配信の保護

• すべてのサイトを TLS 1.3 で配信し、HSTS（HTTP Strict Transport Security）で HTTPS 接続を強制しています。
• Content-Security-Policy（CSP）、X-Frame-Options（frame-ancestors）、X-Content-Type-Options、Referrer-Policy、Permissions-Policy などのセキュリティヘッダーを、各サイトの性質に応じて設定し、クロスサイトスクリプティング（XSS）、クリックジャッキング、MIME スニッフィングへの耐性を高めています。
• サーバーの種類やバージョンを示すレスポンスヘッダー（X-Powered-By）を返さない設定にし、攻撃の手がかりとなる情報の露出を抑えています。

3. 脆弱性管理

• 2026年11月に公表された Next.js の重大な脆弱性（画像最適化 API を経由したリモートコード実行など）について、当社が運営する自社サイト・サービスサイトのすべてで、公表当日に修正版への更新を完了しました。
• 依存パッケージの脆弱性を継続的に検知するソフトウェア構成分析（SCA）を導入し、既知の脆弱性（CVE）が公表された時点で通知と修正の提案を受けられる体制にしています。

4. DNS とドメインの保護

• 保有するドメインについて、DNS レコード、証明書の公開記録（Certificate Transparency ログ）、サブドメインを洗い出しました（アタックサーフェスの棚卸し）。
• 存在しないサブドメインまで応答していたワイルドカード DNS レコードと、利用を終えた外部サービスを指したまま残っていた DNS レコード（サブドメイン乗っ取りの原因となる Dangling DNS）を削除しました。
• 主要なドメインに CAA レコードを設定し、SSL/TLS 証明書を発行できる認証局を限定しました。証明書の不正発行のリスクを抑えています。
• DNS 応答の改ざんを防ぐ DNSSEC を、対応するドメインから順に導入しています。
• 過去に使っていたドメインについて、第三者に再取得されていないことを確認しています。

5. なりすましメールへの対策

送信ドメイン認証（SPF・DMARC）を見直しました。解約済みのサーバーを送信元として許可していた SPF レコードを修正し、メールを使うすべてのドメインで DMARC を導入して、集計レポート（RUA）による送信状況の監視を始めています。監視の結果をもとに、なりすましメールを受信側で隔離・拒否するポリシーへ段階的に移行します。

6. 管理アカウントとシークレットの保護

• ドメイン、DNS、ホスティング、ソースコード管理などの主要な管理アカウントに、パスキーを含む多要素認証（MFA）を設定しています。
• 外部サービスと連携するための API キーなどのシークレットを入れ替え（ローテーション）、使われなくなった古いキーを失効させました。

7. 脆弱性報告の窓口と継続的な監視

• 脆弱性を発見された方からの連絡先を示す security.txt（RFC 9116）を、主要なサイトの /.well-known/security.txt に設置しました。
• ドメインの有効期限、SSL/TLS 証明書の期限、サイトの稼働状況を定期的に点検し、更新漏れや異常を早期に検知する体制を整えています。

今後も、定期的な点検と更新を続けてまいります。