security-baseline

セキュリティの基本要件

本番環境のあらゆるウェブサイトやウェブアプリにおいて、最低限必要なセキュリティを確立します。技術スタックに依存しません。一般公開前に整えておき、以降も定期的に確認すべき項目を網羅しています。

---

使用する場面

• 公開前のセキュリティレビュー
• 新しいサイトや環境のセットアップ
• 定期的なセキュリティ監査（四半期ごとを推奨）
• 新しいベンダーやサードパーティ連携の導入
• セキュリティ上の指摘や報告への対応
• インシデント後のセキュリティ強化

使用しない場面

• 進行中のインシデント対応（incident-response を使用）
• コードレベルのセキュリティレビュー（code-review-web を使用）
• メール固有の認証（SPF/DKIM/DMARC）（email-deliverability を使用）
• DNS レベルのセキュリティ（CAA、DNSSEC）（domain-strategy を使用）
• パフォーマンス関連のセキュリティ（DDoS 対策の規模設定）（performance-optimization を使用）

---

必要な入力

• 対象となるサイトまたはアプリ（URL、環境）
• ホスティングプラットフォームと CDN
• 認証方式（ある場合）
• サードパーティのスクリプトと連携
• コンプライアンス要件（該当する場合は PCI、SOC2、GDPR など）
• 既存のセキュリティツール

---

フレームワーク：6 つのレイヤー

セキュリティは多層で構成されます。各レイヤーは異なる攻撃対象領域に対応します。

レイヤー 1：通信のセキュリティ

サーバーからクライアントへデータがどのように送信されるかを扱います。

• すべての通信で HTTPS を使用します。コンテンツを配信する HTTP のバリエーションを残さないでください。
• TLS 1.2 以上を使用し、TLS 1.3 を推奨します。TLS 1.0 と 1.1 は無効にします。
• HSTS（Strict-Transport-Security）ヘッダーを設定します。信頼性の高いサイトでは includeSubDomains と preload も設定します。
• 強固な暗号スイートのみを使用します。プロバイダーの最新の設定を選べば、最新のブラウザーに対応できます。
• 信頼できる CA の証明書を使用し、有効期限を監視します。

レイヤー 2：レスポンスヘッダー

ブラウザーにサイトについて伝える内容を扱います。

ヘッダー	目的	デフォルト値
Strict-Transport-Security	HTTPS を強制する	max-age=31536000; includeSubDomains
Content-Security-Policy	リソースの読み込みを制限する	サイト固有
X-Content-Type-Options	MIME スニッフィングを防ぐ	nosniff
X-Frame-Options	クリックジャッキングを防ぐ	DENY または SAMEORIGIN
Referrer-Policy	リファラー情報を制御する	strict-origin-when-cross-origin
Permissions-Policy	ブラウザー機能を制御する	サイト固有（カメラ、マイクなど）
Cross-Origin-Opener-Policy	プロセスを分離する	same-origin（互換性がある場合）
Cross-Origin-Embedder-Policy	クロスオリジンの制限を設定する	require-corp（該当する場合）

CSP には特に注意が必要です。以下のフレームワークのセクションを参照してください。

レイヤー 3：認証と認可

ユーザーが本人であることと、実行できる操作をどのように証明するかを扱います。

• 強力なパスワード要件（複雑さよりも長さを重視し、長いパスフレーズを許可する）
• ログイン時のアカウントロックアウトまたはレート制限
• 2FA を利用可能にし、管理者アカウントでは必須にする
• セッショントークンには有効期間の短い、安全な HttpOnly Cookie を使用する
• ログアウト時には、クライアント側だけでなくサーバー側でもトークンを無効化する
• アカウントの存在が明らかにならないパスワードリセットのフロー
• すべてのリクエストで認可を確認する（UI 上で隠すだけに頼らない）

レイヤー 4：入力処理

信頼できない入力をどのように処理するかを扱います。

• サーバー側で検証する（クライアント側の検証は UX のためであり、セキュリティ対策ではありません）
• データベースアクセスにはすべてパラメーター化クエリを使用する（SQL に文字列を連結しない）
• コンテキストに応じて出力をエンコードする（HTML、JS、URL、CSS）
• ファイルアップロードを制限する（種類、サイズ、保存場所、スキャン）
• 悪用される可能性のあるエンドポイントにレート制限を設定する
• 状態を変更するリクエストに CSRF トークンを使用する

レイヤー 5：シークレット管理

認証情報とキーの保管場所を扱います。

• コード、リポジトリ内の設定ファイル、イメージに埋め込まれた環境変数にシークレットを含めない
• 専用のシークレットマネージャーにシークレットを保管する
• 環境ごとに異なるシークレットを使用する（開発環境と本番環境でシークレットを共有しない）
• ローテーションのスケジュールを文書化し、遵守する
• シークレットへのアクセスを監査ログに記録する
• 影響範囲を限定する（サービスごとに個別の認証情報を使用し、権限を必要最小限に絞る）

レイヤー 6：運用セキュリティ

チームの運用方法です。

• アクセス制御を四半期ごとに見直す（退職時は直ちにアクセスを停止する）
• すべての管理者アカウントで 2FA を必須にする（ホスティング、DNS、レジストラー、コードホスト、デプロイツール）
• 監査ログを有効にし、確認する
• 脆弱性スキャンを実施する（依存関係、コンテナ、インフラストラクチャ）
• パッチ適用の頻度を定める
• インシデント対応ランブックを用意する（incident-response を参照）
• バックアップを用意し、テストする（backup-and-disaster-recovery を参照）
• セキュリティ連絡先を公開する（/.well-known/security.txt に security.txt を配置）

---

コンテンツセキュリティポリシー

CSP は最も強力なレスポンスヘッダーであり、最も設定ミスが多いものでもあります。個別に扱う価値があります。

CSP の役割

CSP は、スクリプト、スタイル、画像、フレーム、接続など、さまざまなリソース種別で許可されるソースをブラウザーに伝えます。厳格な CSP を設定すると、入力処理に不具合があっても、ほとんどの XSS 攻撃を防げます。

2 つの方式

厳格な CSP（推奨）： nonce- または hash- に基づくソース許可リストを使用します。インラインスクリプトを許可するには、nonce による明示的な許可が必要です。

Content-Security-Policy: script-src 'self' 'nonce-{random}' 'strict-dynamic'; object-src 'none'; base-uri 'self';

許可リスト型 CSP（レガシー）： 許可するドメインを列挙します。設定は簡単ですが、保護はかなり弱くなります。

Content-Security-Policy: script-src 'self' https://trusted.com; ...

厳格な CSP には、アプリケーションの変更が必要です（すべてのインラインスクリプトに nonce が必要です）。その投資には見合う効果があります。

CSP を段階的に導入する

1. Content-Security-Policy-Report-Only から始め、ブロックせずに違反を記録します。
2. 違反レポート用のエンドポイントを設定します。
3. 正当な違反（サードパーティースクリプト、インラインハンドラー）がないか確認します。
4. ポリシーを調整します。
5. 違反の大部分が誤検知になったら、強制モードに切り替えます。
6. 新たな問題がないか、違反レポートの監視を続けます。

CSP でよくある間違い

• script-src に unsafe-inline を指定する。CSP の効果の大半が失われます。
• script-src に unsafe-eval を指定する。古いライブラリで必要になることがよくあります。リファクタリングするか、置き換えてください。
• ワイルドカードソース（*）を指定する。ポリシーの効果が失われます。
• 任意のユーザーコンテンツをホストする CDN を許可する。攻撃者がその CDN にスクリプトをアップロードできる可能性があります。
• frame-ancestors を制限しない。クリックジャッキング対策にはこれを使用します（X-Frame-Options より柔軟です）。

---

ワークフロー

ステップ 1：ベースラインスキャンを実行する

無料のスキャナーを使用します。securityheaders.com、または MDN HTTP Observatory（developer.mozilla.org/en-US/observatory）を使ってください。現在の評価を取得します。これが最低限の基準です。スキャン結果を取得できない場合は、データ利用可否ルールに従ってその不足を明記します。

ステップ 2：対象範囲を洗い出す

• 対象となるドメインとサブドメイン
• 公開エンドポイント（フォーム、API）
• 認証の入口
• 管理インターフェース
• サードパーティーとの連携と、それぞれに付与された権限

ステップ 3：各レイヤーを監査する

6 つのレイヤーを順に確認します。それぞれについて、以下を記録します。

• 導入済みのもの
• 不足しているもの
• リスクレベル（高、中、低）

ステップ 4：優先順位を付ける

リスクが高く、修正が簡単なものから着手します。

• HSTS が設定されていない
• デフォルトのヘッダーが不足している
• 2FA を使用していない管理者がいる
• 古い TLS バージョンが有効になっている

次に、リスクが中程度で、修正にも中程度の労力がかかるものに取り組みます。

• CSP の導入
• 入力検証の不足
• シークレット管理の改善

最後に、リスクが低く、あると望ましいものに取り組みます。

• Permissions-Policy の調整
• 任意のヘッダー（Cross-Origin-* 系）

ステップ 5：実装して検証する

修正ごとに、以下を行います。

• 変更を加える
• 本番環境以外でテストする
• スキャナーで検証する
• 展開する
• 本番環境で再検証する

ステップ 6：監視を設定する

• 証明書の有効期限アラート
• CSP 違反レポート
• ログイン失敗の監視
• 異常な管理者アクティビティのアラート
• 依存関係の脆弱性アラート（Dependabot、Snyk、または同等のツール）

ステップ 7：ベースラインを文書化する

セキュリティベースライン文書を作成します。すべてのサイトに求められる要件を記載します。

• 必須のヘッダー
• 必須の設定
• 必須のプラクティス

新しいサイトは、この基準に照らして監査します。既存のサイトも定期的に再監査します。

ステップ 8：レビューを予定する

四半期ごとのレビューを最低限とします。大きな変更やインシデントの後にもレビューを追加します。

---

一般的なコンプライアンス上の確認事項

法的助言ではありません。セキュリティの基本基準がコンプライアンス要件と交わる領域です。

• PCI DSS（決済カードを取り扱う場合）：基本基準よりもはるかに対応範囲が広くなります。基本基準は出発点であり、それだけでは不十分です。
• **SOC 2：**基本基準は、ほとんどの CC コントロール（CC6 シリーズ）に沿っています。基本基準を文書化し、実施の証拠を示すことが監査で求められます。
• **GDPR／プライバシー関連規制：**基本基準はセキュリティ上の義務（第 32 条）に対応します。プライバシーはセキュリティより広い概念です。
• **HIPAA、HITRUST、FedRAMP：**基本基準は必要ですが、十分とはほど遠いものです。専門家の支援を受けてください。

コンプライアンスが適用される場合、基本基準は必要ですが、それだけで十分な答えにはなりません。

---

よくある失敗パターン

**includeSubDomains のない HSTS。**攻撃者が、まだ HTTPS を導入していないサブドメインで、ブラウザーに HTTP を使わせるよう誘導します。

**十分な準備のない HSTS プリロード。**一度プリロードすると、削除しても Chrome のアップデートを通じてユーザーに反映されるまで数か月かかり、他のブラウザーで反映される保証もありません。すべてのサブドメインで HTTPS が永久に確実に使えるようになるまで、プリロードしないでください。

**unsafe-inline を含む CSP。**CSP の効果の大半が失われます。厳格な設定（ノンスベース）にするか、CSP の保護が限定的であることを受け入れてください。

デフォルトのセキュリティヘッダーがない。X-Content-Type-Options、X-Frame-Options、Referrer-Policy は簡単に設定でき、費用もかかりません。設定してください。

**管理者アカウントに 2FA がない。**小規模チームで最もよく見られる、影響の大きい脆弱性です。今日中に修正してください。

**イメージに埋め込まれた環境変数内のシークレット。**イメージにアクセスできる人なら誰でもシークレットを取得できます。実行時のシークレットマネージャーを使ってください。

**security.txt がない。**セキュリティ研究者が問題を見つけたとき、報告先が必要です。/.well-known/security.txt に security.txt を公開してください。

**古い TLS バージョンが有効になっている。**TLS 1.0 と 1.1 を無効にしてください。ほとんどのプロバイダーでは、チェックボックスを選択するだけで設定できます。

**CSP の設定ミスにより、CDN が任意のインラインスクリプトを許可している。**CDN はユーザーコンテンツをプロキシするため、攻撃者に悪用されます。実際に読み込まれるリソースと照らし合わせて CSP を監査してください。

**インシデント対応計画がない。**何かが起きたとき（起きるかどうかではなく、いつ起きるかの問題です）、手順書がなければ混乱します。incident-response を参照してください。

**脆弱性スキャンをしても修正しない。**レポートが積み上がるだけです。指摘事項を修正する人がいなければ、スキャンは見せかけにすぎません。

**ペネトレーションテストを無視する。**ペネトレーションテストのレポートが棚に眠ったままになります。修正しないテスト結果は、テストをしないよりも悪い状態です。

---

出力形式

セキュリティ基本基準の文書には、次の内容を含めます。

• **インベントリ：**対象範囲
• **レイヤーごとの状況：**実施済みの項目と不足している項目
• **必須ヘッダー：**環境ごとに適用する値
• **必須設定：**TLS、シークレット、認証
• **必須の運用手順：**アクセスレビュー、パッチ適用の頻度、監査ログ
• **指摘事項：**優先順位を付けたギャップの一覧
• **修正計画：**担当者、日付
• **再監査の頻度：**次回のレビュー時期

---

必要なデータを利用できない場合

このスキルの出力は、自力では生成できないデータ、測定値、またはツールの実行結果に依存します。必要な入力、ツール、またはデータソースを利用できない、あるいは検証できない場合、承認されている出力は、ギャップを明記した成果物です。つまり、何が必要だったのか、実際に何を取得または検証できたのか、出力のどの部分が影響を受けるのかを記載します。成果物を完成させるために必要な数値を捏造、推定、補間することは、いかなる場合も認められません。ギャップを明記すれば、それで回答として完結します。

---

参考ファイル

• references/headers-checklist.md：重要度の段階ごとに整理した、推奨セキュリティヘッダーと設定例のコピー＆ペースト用チェックリスト。