こんな方へ特におすすめ
- セキュリティ対応において、何から手をつければいいか迷っている方
- HSTSなどのセキュリティヘッダ導入が、他の環境（検証環境など）に与える影響を知りたい方
概要
こんにちは。サイオステクノロジーのはらちゃんです！
今回はSL代表としてセキュリティスキャン対策のコミュニケーションチームに入りました。
そこで得た「現場でのリアルな立ち回り」「セキュリティ対応の基本となる考え方」「HSTS導入時の思わぬ落とし穴（副作用）」といった、実務に直結する知見をまとめていきます。
背景
ある日、内部的なセキュリティスキャンが実施され、レポートが提供されました。
結果は「外部から容易に利用されるサイトで、改善が必要な項目が多々ある」という厳しいものでした。
最終的に、各SLで担当者を立てて全社的に修正対応を図ることになりました。
対応前のマインドセット
実際の技術的な修正に入る前に、チーム全体で以下の「考え方のポイント」を共有しました。無駄な作業を減らすための非常に重要なステップです。
- 「廃止・退役できるリソースか？」を最初に問う
これが最もコストがかからず、最も安全な究極のセキュリティ対策。
使っていない検証環境は、修正するのではなく消すのが正解。 - 「対応しない」なら客観的な根拠を
システム上の都合でどうしても対応できない項目もある。
しかし、放置するのではなく「なぜ対応できないか（客観的に妥当な根拠）」を言語化し、ディスカッションのテーブルに上げることが求められる。 - オープンなコミュニケーション
専用のSlackチャンネルを用意し、不明点や気づきはすぐに共有する体制を作成。
3つの対応ポイント
指摘事項は多岐にわたりましたが、大きく以下の3点に分類して対応を進めました。
1. OS・パッケージの脆弱性対応
- 対応
サポートされている最新版に遅滞なく更新する。 - ツール
Amazon Inspector + AWS Security Hub CSPM（EC2やECRのDockerイメージの脆弱性を可視化）。
2. 伝送経路（SSL / TLS）の修正
- 対応
TLS1.0 / 1.1などの古いプロトコル、脆弱な暗号スイート（cipher）を無効化する。
IE11対応などの特殊な要件がない限り、2026年現在ではTLS 1.2 / TLS 1.3 中心で問題なし。 - ツール
Mozilla SSL Configuration Generator で安全なconfigを作成し、SSL Labs で評価を確認。
3. セキュリティヘッダの指定
- 対応
Webサーバー（またはCDN）にCSPやHSTSなどのヘッダを追加する。 - ツール
securityheaders.com でのチェック。
ここが一番の難所でした。特にCSP（Content Security Policy）は、設定を間違えると必要なJSやCSSが読み込まれずサイトが壊れるため、技術開発センターの管理下サイトで先行検証・適用を進めるという慎重なアプローチをとりました。
そして、私のSLに最も影響を与えたのがHSTSです。
課題
HSTSポリシーと「自己署名証明書」の衝突
HSTS（HTTP Strict Transport Security）は、ブラウザに対して「今後は絶対にHTTPSで接続しろ」と強制する強力なセキュリティヘッダです。
ベストプラクティスとしては、以下の指定が推奨されます。
max-ageで1〜2年以上の長期間を指定preload指定includeSubDomains指定（サブドメインも全てHTTPS強制）
ここで問題発生です。依頼事項として「[社内検証用サブドメイン配下]でHTTP接続しているリソースはないか？」という確認がありました。最終的にSSL接続が必須になります。
私のSLでは、以下の社内検証環境が稼働していました。
- OpenShift検証環境
自動構築で「自己署名証明書（オレオレ証明書）」を利用。 - 社内検証Rancher/GitLab環境
内部DNS設定で、[社内検証用サブドメイン配下]を利用。
HSTSが引き起こす「副作用」
本番ドメインにHSTSの includeSubDomains が付与されると、それにアクセスしたブラウザはポリシーを記憶します。
その後、同じブラウザで社内検証環境にアクセスすると、ブラウザは「HTTPSでの接続」と「正当な証明書の提示」を厳格に要求します。
そうすると、検証環境で使っている自己署名証明書がブラウザに強固にブロックされ、アクセス不可になるという懸念が浮上したのです。
検討案
HSTSの副作用をどう回避するか？
検証環境のために本番のセキュリティレベルを下げるわけにはいきません。私たちは以下の回避策を検討しました。
- 正規の証明書を自動発行する
Let’s Encrypt (DNS-01認証): Route53と連携して証明書の取得・更新を全自動化する。
AWS Certificate Manager (ACM): AWS環境であれば、ACMで発行した証明書をALB等に割り当てるのが最もスマート。 - 社内検証・開発用ドメインを物理的に分ける
本番ドメインのサブドメインを使わず、検証専用の別ドメインを取得する。
GoogleやFacebookなどの大手テック企業も採用している王道のアプローチ。 - 再構築のタイミングでドメインを変更する（期間区切り）
「10月までは今の環境を使い、それ以降は新規作成する」という場合、次回の再構築時にドメイン構成を見直すというリスク受容の判断もアリ。 - プライベートCAを構築する
社内用の認証局を立てる案だが、構築・維持のコストリスクが高いため優先度は低め。
まずは「影響を小さく検証」する
様々な理想論を挙げましたが、机上の空論で終わらせず、まずは「実際のブラウザ挙動」を確かめるスモールスタートを切ることにしました。
【決定したネクストアクション】
- 技術管理担当者が、
sios.jpに HSTS ポリシー（includeSubDomainsあり）を適用する。 - Slackで連絡を受けたら、インフラ担当者がブラウザで
sios.jpにアクセスし、HSTSポリシーを学習させる。 - そのまま検証環境へアクセスし、HTTPS強制ブロックの挙動を確認する。
- 回避策の検証
HSTSポリシーを共有しない「シークレットモード」や「別プロファイルのブラウザ」を利用することで、自己署名証明書の検証環境へアクセス可能か（業務への影響を回避できるか）をテストする。
まとめ
セキュリティスキャンからの指摘は、一見すると「ただの面倒な作業」に思えるかもしれません。
しかし、今回のように「なぜHSTSのサブドメイン指定が検証環境を壊すのか？」「どうやって回避するのか？」をチームで議論することで、インフラ設計の解像度がグッと上がります。
- 不要なリソースは捨てるのが最強のセキュリティ。
- HSTS導入時は、サブドメインで動いている検証環境（自己署名証明書）の死に直結しないか注意する。
- 理想のアーキテクチャ（ドメイン分離やACM活用）を描きつつも、まずはプライベートブラウザ等の運用回避で業務を止めない立ち回りも重要。
今後も、こうした全社的な取り組みを通して得られた知見を、皆さんに共有していきたいと思います！
