Platform Security Overview

Nginx on Linux with a Web Application Firewall (WAF) is a critical security control plane for pre-production environments: it terminates TLS, mediates access, enforces content and traffic policies, and shields upstream services from abuse. In pre-production, the goals are to mirror production posture while enabling safe testing, rapid iteration, and early detection of misconfigurations and vulnerabilities—without exposing real data or production secrets. The following practices emphasize hardened hosts, least-privilege processes, robust crypto, strict HTTP and WAF controls, abuse resistance, strong observability, and change safety aligned with industry benchmarks (e.g., CIS Linux Benchmarks, OWASP ASVS/Cheat Sheets, NIST 800-53/800-190).

10 Security Best Practices

1. Practice: Harden Linux Host Baseline and Enforce MAC

• Specific Description: Reduce host attack surface and enforce Mandatory Access Control (SELinux/AppArmor) suitable for reverse proxy/WAF workloads.
• Implementation Points:
  • Minimal OS image; remove compilers, interpreters, and unused packages/services. Disable password SSH; use key-based auth and sudo with least privilege.
  • Kernel/sysctl hardening (evaluate in your environment): enable TCP SYN cookies; disable source routing and ICMP redirects; enable reverse path filtering; restrict kernel pointers; protect hardlinks/symlinks; restrict unprivileged BPF/user namespaces if feasible.
    • Examples: net.ipv4.tcp_syncookies=1; net.ipv4.conf.all.accept_redirects=0; net.ipv4.conf.all.send_redirects=0; net.ipv4.conf.all.accept_source_route=0; net.ipv4.conf.all.rp_filter=1; fs.protected_hardlinks=1; fs.protected_symlinks=1; kernel.kptr_restrict=2; kernel.unprivileged_bpf_disabled=1.
  • Mount hardening: mount /tmp and /var/tmp with noexec,nosuid,nodev; ensure only required filesystems are enabled; mark config directories read-only except where necessary for runtime.
  • Enforce SELinux or AppArmor in enforcing mode; apply or craft a strict profile/policy allowing only required file paths, network, and IPC for Nginx and WAF.
  • Keep the kernel and packages patched on a defined cadence; use trusted repositories with signature verification.
• Security Value: Shrinks the attack surface, reduces privilege escalation paths, and confines Nginx/WAF processes to least privilege at the OS level.

2. Practice: Process Isolation and Systemd Hardening

• Specific Description: Run Nginx/WAF as an unprivileged service with tightly scoped capabilities and OS sandboxing.
• Implementation Points:
  • Dedicated non-root user/group; avoid running the master as root. If binding to privileged ports, grant only CAP_NET_BIND_SERVICE to the binary or unit.
  • Systemd unit hardening (validate per distro): NoNewPrivileges=true; PrivateTmp=true; PrivateDevices=true; ProtectSystem=strict; ProtectHome=true; ReadWritePaths=/var/log/nginx /var/cache/nginx; CapabilityBoundingSet=CAP_NET_BIND_SERVICE; RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX; LockPersonality=true; RestrictSUIDSGID=true; SystemCallFilter to permit only needed syscalls (test carefully); MemoryDenyWriteExecute=true (unless a module requires JIT).
  • Separate runtime, state, cache, and log directories via RuntimeDirectory/StateDirectory with restricted permissions.
• Security Value: Prevents lateral movement and mitigates the blast radius of a compromise by dropping privileges and constraining runtime capabilities.

3. Practice: Network Segmentation and Host Firewalling

• Specific Description: Place Nginx in a controlled ingress tier with tight north-south and east-west controls, and minimal egress.
• Implementation Points:
  • Inbound: only allow required ports (e.g., 80 for redirect, 443 for TLS). Deny admin and metrics endpoints from public networks; expose them only via management networks or bastion.
  • Egress: default-deny outbound; explicitly allow only upstream backends, OCSP responders, package mirrors, and logging endpoints. Use FQDN pinning plus IP/port allowlists if possible.
  • Inter-tier segmentation: isolate pre-production from production; prohibit any path from pre-prod to prod data stores. Use separate VPC/VNET/subnets and security groups or host firewalls (nftables) to enforce boundaries.
  • Kernel anti-spoofing (rp_filter) and logging for dropped traffic. Prefer IPv6 parity and hardening if used.
• Security Value: Minimizes exposure, curtails data exfiltration channels, and blocks lateral pivoting.

4. Practice: TLS/mTLS Hardening and Key Lifecycle

• Specific Description: Enforce modern TLS, protect keys, and enable upstream authentication where needed.
• Implementation Points:
  • Protocols/ciphers: enable TLS 1.2 and 1.3; disable legacy protocols/ciphers; prefer AEAD ciphers and forward secrecy. Prefer server cipher order for TLS 1.2.
  • Certificates: use environment-specific CAs for pre-prod; enforce short-lived certs; automate issuance/renewal. OCSP stapling enabled; robust stapling failure handling.
  • Session handling: rotate TLS session ticket keys; consider disabling tickets if rotation is not feasible; prefer TLS 1.3 resumption semantics with rotation.
  • Private key protection: file perms 600 owned by the Nginx user; isolate from backups; consider hardware-backed or OS keystore via PKCS#11 where feasible.
  • Upstream mTLS: authenticate to backends with distinct client certs per service; validate upstream cert chains and SANs; pin expected CA.
• Security Value: Prevents downgrade and passive/active interception, thwarts MITM on upstream links, and reduces key compromise impact via rotation and isolation.

5. Practice: HTTP Surface Minimization and Header Hygiene

• Specific Description: Constrain what clients can send and what responses expose; normalize and sanitize all trust boundaries.
• Implementation Points:
  • Limit methods (allow only GET/HEAD/POST/PUT/DELETE as truly needed); reject TRACE/OPTIONS unless required and safe.
  • Tight timeouts: client_header_timeout, client_body_timeout, keepalive_timeout short and reasonable; large_client_header_buffers tuned; request/response buffering strategy chosen to protect upstreams.
  • Size limits: client_max_body_size, client_header_buffer_size, and header count limits appropriate for the application.
  • Normalize URIs and reject ambiguous encoding; disable underscores_in_headers; ignore_invalid_headers on; validate Host header; disallow absolute URIs from external clients if not needed.
  • Proxy header controls: drop client-supplied X-Forwarded-*; set them explicitly server-side; sanitize hop-by-hop headers.
  • Response hardening: server_tokens off; add HSTS (in pre-prod only if domain isolation is guaranteed to avoid pinning mistakes), Content-Security-Policy (least permissive, use frame-ancestors), Referrer-Policy, Permissions-Policy, X-Content-Type-Options nosniff. Use proxy_cookie_flags to set Secure; HttpOnly; SameSite as appropriate for proxied apps.
  • Cache safety: ensure cache keys incorporate auth context; bypass caching on Authorization; clear vary headers appropriately.
• Security Value: Reduces exploitability (injection, smuggling, cache poisoning), constrains protocol abuse, and limits sensitive metadata exposure.

6. Practice: WAF Rule Lifecycle, Normalization, and Tuning-as-Code

• Specific Description: Treat WAF policies as code with rigorous testing, staged rollout, and continuous tuning to reduce false positives/negatives.
• Implementation Points:
  • Rule management: version control, code review, and CI tests for rule packs; tag rules by OWASP category, app area, and risk.
  • Normalization: enable strict canonicalization of URLs, encodings, and request bodies; limit decoding depth; turn on libinjection-like SQLi/XSS detectors if supported.
  • Staging: deploy new/updated rules in Detection/Log-only in pre-prod; compare against a traffic baseline; promote to Blocking after false-positive burn-in and coverage validation.
  • Positive security model: for high-risk endpoints, whitelist schemas (allowed methods, content types, parameter shapes, JSON schema enforcement).
  • Virtual patching: rapidly block known exploit vectors targeting upstream vulnerabilities until patched; set expiration and review dates on temporary rules.
  • Performance budget: cap per-request WAF processing time and inspect only necessary content types to avoid DoS via WAF overhead.
• Security Value: Increases detection fidelity and reduces operational risk by preventing both bypass and application-breaking false positives.

7. Practice: DoS and Abuse Controls (Rate/Connection Limiting and Slow Attacks)

• Specific Description: Apply layered protections against volumetric and application-layer DoS and abuse patterns.
• Implementation Points:
  • Rate limiting: per-IP and per-auth-subject request rate with bursts and token-bucket smoothing; return 429 with clear retry semantics.
  • Connection limiting: limit_conn per IP and per zone to cap concurrency; low keepalive_timeout for public endpoints.
  • Slowloris mitigation: enforce client_header_timeout/client_body_timeout; limit request body buffering time; drop slow senders.
  • Request buffering: enable proxy_request_buffering for typical APIs to shield upstreams; consider disabling only for large file uploads with compensating controls.
  • Kernel-level: enable TCP SYN cookies; tune backlog thresholds; ensure adequate file descriptor limits and worker_connections to avoid self-DoS.
  • Static asset offload and caching to reduce dynamic backend pressure in pre-prod perf tests.
• Security Value: Preserves availability by curbing abusive clients and pathological traffic patterns before they impact upstream services.

8. Practice: Authentication and Authorization for Admin/Internal Paths (Zero Trust at the Edge)

• Specific Description: Enforce strong identity at Nginx for sensitive routes; never trust client-provided identity headers.
• Implementation Points:
  • Path isolation: separate server blocks or locations for admin, health, metrics, and internal APIs; never expose these publicly.
  • Strong auth: prefer mTLS for admin networks; for end-user auth, integrate with a centralized identity provider via an auth subrequest pattern; validate JWTs or tokens server-side, not via client-supplied headers.
  • Header sanitation: strip inbound Authorization and X-Forwarded-* from clients on public interfaces; set canonical X-Forwarded-Proto/Host/For internally; propagate only validated identity claims (e.g., via internal headers) to upstreams.
  • Per-route RBAC: map claims/scopes to backend routing and authorization decisions; deny by default if claims missing or verification fails; set low TTL on auth cache and respect token revocation.
  • Audit: log authenticated principal, auth method, and policy decision for sensitive routes.
• Security Value: Prevents header spoofing, enforces least privilege access to critical endpoints, and strengthens end-to-end identity assurance.

9. Practice: Secrets and Key Management, with Pre-Production Data Isolation

• Specific Description: Protect TLS keys, API tokens, and WAF secrets; ensure pre-production uses isolated credentials and data.
• Implementation Points:
  • Storage: restrict file permissions (600, owned by service user); no secrets in environment variables or command lines; disable core dumps; scrub crash artifacts.
  • Retrieval: use a centralized secret manager or OS keystore; short-lived credentials; automated rotation; strict access policies and audit trails.
  • Separation: unique CAs, certificates, tokens, and database credentials for pre-prod; no production secrets or datasets; use masked/synthetic data only.
  • Transport: ship logs and metrics over TLS with mutual auth to collectors; pin collector CA.
  • Controls: detect and block accidental secret leakage in configs and logs; run pre-commit/CI scanners; prevent world-readable temp files.
• Security Value: Limits blast radius of key compromise, prevents cross-environment leakage, and maintains confidentiality of sensitive material.

10. Practice: Observability, Security Telemetry, and Incident Response for Edge Services

• Specific Description: Produce high-fidelity, privacy-aware telemetry; centralize analysis; automate detection and rollback aligned to pre-production workflows.
• Implementation Points:
  • Structured logging: JSON logs for access, error, and WAF audit with fields for request_id, client IP, TLS version/cipher, mTLS subject, upstream status/latency, auth principal, and rule matches. Redact sensitive fields.
  • Metrics: export per-route/request metrics (rates, latencies, error codes, WAF block rates, 429/403 spikes). Protect metrics endpoints; do not expose publicly.
  • Centralization: forward logs/metrics over TLS to a central platform; segregate pre-prod indices; strict RBAC for viewers; synchronized time (NTP/Chrony).
  • Detection: alerts for anomalies (5xx surge, WAF FP/TP changes, auth failures, rate-limit events, config integrity changes). Establish baselines for pre-prod traffic.
  • Integrity monitoring: watch /etc/nginx, WAF rules, and TLS material for unauthorized changes; tie to change tickets.
  • Response: playbooks for quick rollback of Nginx/WAF configs; safe-mode switch to change WAF from Block to Detect on elevated FP; automated config canary with health checks gatekeeping full rollout.
• Security Value: Enhances early detection, speeds containment, and reduces MTTR while ensuring privacy and compliance of telemetry.

Summary and Recommendations

• Apply defense-in-depth: hardened Linux host with MAC, least-privilege process isolation, tight network segmentation, modern TLS/mTLS, strict HTTP and WAF controls, and robust observability.
• Treat configurations and WAF rules as code: versioned, peer-reviewed, automatically tested (nginx -t, schema tests, replay traffic), and promoted via canary and staged rollouts in pre-production before production.
• Keep pre-production isolated: no production data or secrets, separate PKI/credentials, and limited exposure. Use synthetic/masked data to validate WAF efficacy and tuning.
• Continuously improve: monitor baselines, tune WAF and rate limits to minimize false positives while preserving protection, and keep host/packages patched on a predictable schedule.

By implementing the above practices, your pre-production Nginx+WAF tier will closely mirror production security posture, safely validate changes, and provide strong preventive, detective, and responsive controls aligned with modern security standards.

プラットフォーム安全概述

Dockerコンテナと私有イメージレジストリは、ソフトウェア供給網の中核要素であり、ハイブリッドクラウド環境ではネットワーク経路・認証方式・運用プロセスが複雑化します。攻撃者はイメージ改ざん、認証情報の悪用、レジストリ露出、実行時権限の過剰化などを狙います。よって、アイデンティティ、ネットワーク、データ保護、監視・監査を貫く多層防御が必須です。

10項のセキュリティベストプラクティス

1. 実践名：最小権限に基づくアイデンティティ・アクセス制御（レジストリ/ホスト）

• 具体説明：レジストリとDockerホストのアクセスはロールベースで厳格化し、短期トークンと多要素認証を前提にします。匿名アクセスは禁止し、権限は「プッシュ/プル/管理」を明確に分離します。
• 実施要点:
  • レジストリにRBACを導入し、プロジェクト単位・名前空間単位でアクセスを最小化
  • OIDC/OAuth2等の標準的フェデレーションを用いて短命トークン化、MFAを必須化
  • Dockerホストはrootlessモードやユーザ名前空間を活用し、管理者権限の使用を最小化
  • 定期的な権限レビューと休眠アカウントの無効化
• 安全価値：認証情報悪用や権限昇格のリスクを低減し、内部不正や誤操作を抑制

2. 実践名：イメージの署名・検証とSBOM/アテステーション

• 具体説明：イメージに署名・アテステーションを付与し、プル時の検証を強制します。SBOM（ソフトウェア部品表）を生成・保存し、依存関係の透明性を確保します。
• 実施要点:
  • CIでビルド完了後に署名・アテステーションを付与
  • レジストリ/プル側で「署名済みのみ許可」「ダイジェスト固定（tagではなくdigestで参照）」をポリシー化
  • SBOMをレジストリメタデータまたは別ストアに保存し、変更検知と監査に活用
• 安全価値：供給網改ざんの検知・阻止、依存ライブラリ起因のリスク可視化

3. 実践名：レジストリの安全な通信・配置（TLS/mTLS・セグメンテーション）

• 具体説明：レジストリ通信をTLS1.2以上で暗号化し、必要に応じてmTLSを適用。ネットワーク的にレジストリを限定公開し、ビルド/デプロイノードのみ到達可能とします。
• 実施要点:
  • 強度の高い暗号スイートを使用し、証明書のローテーション/有効期限監視を自動化
  • レジストリをプライベートネットワークに配置し、ファイアウォール/ACLで到達元を厳格に制限
  • ハイブリッドクラウドではプライベート接続（VPN/ピアリング等）を用い、インターネット露出を回避
  • レート制限・基本的なDoS耐性の設定
• 安全価値：中間者攻撃と外部露出面の縮小、通信なりすましの抑止

4. 実践名：継続的な脆弱性スキャンとゲーティング

• 具体説明：イメージに対してOS/言語依存関係のCVEスキャンをCIパイプラインで実施し、重大な脆弱性はデプロイをブロックします。レジストリ内の既存イメージも定期再スキャンします。
• 実施要点:
  • ビルド時に自動スキャンを組み込み、しきい値（例：重大・高）でゲート
  • レジストリの全イメージをスケジュール再スキャンし、修正・再ビルドを促す
  • スキャンレポートの集中管理と監査証跡の保持
• 安全価値：脆弱性の滞留を防ぎ、リリース前に品質を保証

5. 実践名：コンテナ実行時のハードニング（権限・分離・ファイルシステム）

• 具体説明：コンテナを非rootで実行し、不要なLinuxケーパビリティを削減。seccomp/AppArmor/SELinuxを適用し、ルートファイルシステムは読み取り専用化します。
• 実施要点:
  • 非rootユーザ指定、ユーザ名前空間の活用
  • NET_RAW等の不要ケーパビリティをdrop、privileged・hostPID/hostIPC・危険なボリュームマウントの禁止
  • seccompプロファイルとMAC（AppArmor/SELinux）の適用
  • read-only rootfs、tmpfsでの一時領域、メモリ/CPU/ファイルディスクリプタのリソース制限
• 安全価値：侵害時の横展開・権限逸脱・ホスト影響を最小化

6. 実践名：シークレット管理の厳格化（保管・受け渡し）

• 具体説明：イメージにシークレットを同梱しない。実行時に安全に渡し、保存時は暗号化・最小権限で保護します。環境変数による平文露出を避けます。
• 実施要点:
  • ランタイムでファイルマウント（tmpfs）や専用メカニズムで注入し、プロセス・ファイル権限を最小化
  • シークレットのローテーション、失効、アクセス監査を定期化
  • レジストリ用認証情報の平文保存を禁止し、保管時暗号化を適用
• 安全価値：認証情報漏えい・横展開の抑止、適時な権限失効による影響範囲の縮小

7. 実践名：ネットワーク分離と通信制御（コンテナ/レジストリ/外部）

• 具体説明：ユーザ定義ネットワークでサービス単位に分離し、不要な東西通信を遮断。レジストリへの到達は限定し、外部へのエグレスも最小化します。
• 実施要点:
  • デフォルトブリッジの使用を避け、サービス毎に分離したネットワークを構成
  • iptables/ファイアウォールでインターコンテナ通信を明示許可のみ許容
  • サービス間はmTLS等で暗号化、DNS/パケットフィルタでエグレス制御
  • レジストリ到達はCI/配布ノードからのみ、プロダクションコンテナの外部通信はホワイトリスト化
• 安全価値：ラテラルムーブメントの抑止、データ流通の最小化による露出面縮小

8. 実践名：ログ・監査・可観測性の統合

• 具体説明：Dockerデーモン、コンテナstdout/stderr、レジストリアクセス（push/pull/削除）を集中収集し、アイデンティティ情報と相関します。時刻同期と改ざん検知を行います。
• 実施要点:
  • 中央ログ基盤に送信、アクセス・操作イベントの監査（誰が・何を・いつ）
  • レジストリの監査ログでタグ操作・削除・ガベージコレクションを記録
  • しきい値ベースのアラート（大量プル/不審な失敗・深夜操作等）設定
  • NTPで時刻同期、レジストリストレージの整合性監視
• 安全価値：異常検知・インシデント調査の迅速化、コンプライアンス証跡の確保

9. 実践名：イメージライフサイクル管理とパッチ適用

• 具体説明：ベースイメージと依存パッケージの更新を計画的に実施し、古いタグの段階的廃止を管理します。最小ベースイメージを採用し、再現性の高いビルドを維持します。
• 実施要点:
  • 月次/緊急の更新サイクルを定義、重大CVE発覚時は即時再ビルド・再配布
  • 最小ベースイメージと不要パッケージ削減、キャッシュに依存しない再現ビルド
  • 古いイメージの非推奨化・アーカイブ・ガベージコレクションの手順化
  • digest固定でロールバック容易性を確保
• 安全価値：既知脆弱性の滞留削減、安定したリリースと迅速な是正

10. 実践名：レジストリ運用ガバナンスと復旧計画

• 具体説明：タグ運用、保持期間、名前空間設計、バックアップ/DRをポリシー化します。ハイブリッドクラウドでは暗号化されたリージョン/クラウド間レプリケーションを整備します。
• 実施要点:
  • タグの不変化（immutable）と命名規則（release/stage/digest）を文書化・強制
  • 保持/削除ポリシー、ガベージコレクションの安全手順（依存チェック・オフピーク実施）
  • レジストリストレージの定期バックアップ、復元テストの計画的実施
  • インシデント対応ランブック（トークン失効、証明書ローテーション、特定digestの隔離/ブロック）
• 安全価値：誤操作・障害時の迅速復旧、供給網の継続性と法令順守の担保

総まとめと提言

• 供給網防御（署名・SBOM・digest固定）と実行時防御（非root・seccomp・MAC）を両輪で実施し、レジストリは暗号化通信・限定公開・厳格なRBACで防御層を構築してください。
• CI/CDに脆弱性スキャンとポリシーゲートを組み込み、運用ではログ・監査・アラートの整備で検知と対応力を高めます。
• ハイブリッドクラウドでは私有接続を優先し、リージョン/クラウド間の暗号化レプリケーションとDR手順を確立します。
• 設定・プロセスは標準ガイドライン（例：CIS Docker Benchmark等）に整合させ、定期レビューと自動化（権限レビュー、証明書更新、再スキャン）で継続的改善を行いましょう。