security-hardening

セキュリティ強化

目的

体系的な設定の強化、最小権限の徹底、自動化されたセキュリティ制御を通じて、インフラストラクチャの各レイヤーにおける攻撃対象領域を積極的に削減します。業界標準のCISベンチマークとゼロトラストの原則を、オペレーティングシステム、コンテナ、クラウド設定、ネットワーク、データベースに適用します。

このスキルを使用するタイミング

次の場合にこのスキルを呼び出します。

• デプロイ前に本番インフラストラクチャを強化する場合
• コンプライアンス要件（SOC 2、PCI-DSS、HIPAA、FedRAMP）を満たす場合
• ゼロトラストのセキュリティアーキテクチャを実装する場合
• コンテナやクラウドの設定ミスによるリスクを軽減する場合
• セキュリティ監査や侵入テストに備える場合
• セキュリティベースラインの適用を自動化する場合
• 脆弱性スキャンで検出された問題に対応する場合

強化のレイヤー

セキュリティ強化は、次の5つのインフラストラクチャレイヤーに適用します。

レイヤー1：オペレーティングシステム（Linux）

• カーネルパラメーターの調整（sysctl）
• SSH設定の強化
• ユーザーとグループの管理
• ファイルシステムのアクセス許可とマウントオプション
• サービスの最小化
• SELinux/AppArmorの適用

レイヤー2：コンテナ

• 最小限のベースイメージ（Chainguard、Distroless、Alpine）
• コンテナの非root実行
• 読み取り専用のルートファイルシステム
• SeccompおよびAppArmorプロファイル
• リソース制限とケイパビリティの削除
• Pod Security Standardsの適用

レイヤー3：クラウド設定

• IAMの最小権限とMFAの適用
• ネットワークセキュリティグループとNACLの設定
• 保存データと転送中データの暗号化
• パブリックアクセスのブロック
• ロギングとモニタリングの有効化
• CSPM（Cloud Security Posture Management）の統合

レイヤー4：ネットワーク

• デフォルト拒否のネットワークポリシー
• ネットワークのセグメンテーションとマイクロセグメンテーション
• TLS/mTLSの適用
• ファイアウォールルールの最小化
• DNSセキュリティ（DNSSEC、DNSフィルタリング）

レイヤー5：データベース

• 認証と認可の強化
• 接続の暗号化（SSL/TLS）
• 監査ログの有効化
• ネットワークの分離とアクセス制御
• 最小権限に基づくロールベースのアクセス許可

強化の基本原則

1. デフォルト拒否、明示的許可

すべてのアクセスを拒否した状態から開始し、必要な操作のみを明示的に許可します。デフォルト拒否のファイアウォールルールとネットワークポリシーを適用してから、特定のトラフィックを許可します。

2. 最小権限アクセス

操作に必要な最小限のアクセス許可を付与します。RBAC、特定のリソースを指定したIAMポリシー、権限を制限したデータベースロールを使用します（必要でない限り、DELETEやDDLは許可しません）。

3. 多層防御

ネットワークファイアウォール、認証、認可、監査ログ、暗号化など、複数のセキュリティ制御を重ねて実装し、連携させます。

4. 攻撃対象領域の最小化

不要なコンポーネント、サービス、アクセス許可を削除します。最小限のコンテナベースイメージを使用し、未使用のサービスを無効にし、必要でない限り、すべてのLinuxケイパビリティを削除します。

5. 安全なフェイル動作

エラーや設定ミスが発生した場合は、安全な状態をデフォルトとします。認証に失敗した場合はアクセスを拒否し、設定が不足している場合は制限的なデフォルトを使用し、モニタリングに失敗した場合は直ちにアラートを発します。

強化の優先度フレームワーク

公開範囲とデータの機密性に基づいて、強化作業の優先度を決定します。

最優先：インターネットに公開されているシステム

直ちに適用します：

• コンテナの強化（最小限のイメージ、非root、読み取り専用）
• ネットワークのセグメンテーション（DMZ、WAF、DDoS対策）
• TLS終端と証明書管理
• レート制限と認証
• リアルタイムのモニタリングとアラート

ツール： Trivy、Falco、ModSecurity、Cloudflare

高優先度：機密データを扱うシステム

本番環境に移行する前に適用します：

• 保存データの暗号化（AES-256、KMS管理キー）
• 厳格なアクセス制御（RBAC、最小権限）
• 包括的な監査ログ
• データベース接続の暗号化
• 定期的な脆弱性スキャン

ツール： Checkov、Prowler、Lynis、OpenSCAP

標準優先度：内部システム

体系的に適用します：

• OS のハードニング（CIS ベンチマーク）
• サービスの最小化
• パッチ管理の自動化
• 構成管理
• 基本的な監視

ツール： Ansible、Puppet、kube-bench、docker-bench-security

CIS ベンチマークの統合

CIS（Center for Internet Security）ベンチマークは、業界標準のハードニングガイダンスを提供します。

CIS の自動スキャン

Docker CIS ベンチマーク：

docker run --rm -it \
  --net host \
  --pid host \
  --cap-add audit_control \
  -v /var/lib:/var/lib:ro \
  -v /var/run/docker.sock:/var/run/docker.sock:ro \
  -v /etc:/etc:ro \
  docker/docker-bench-security

Kubernetes CIS ベンチマーク：

kubectl apply -f https://raw.githubusercontent.com/aquasecurity/kube-bench/main/job.yaml
kubectl logs job/kube-bench

Linux CIS ベンチマーク：

# Using Lynis
lynis audit system --quick

# Using OpenSCAP
oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis \
  /usr/share/xml/scap/ssg/content/ssg-ubuntu2004-ds.xml

主な CIS コントロールのマッピング

CIS コントロール	ハードニングアクション	レイヤー
4.1 セキュアな構成	ハードニングベースラインを適用	すべてのレイヤー
5.1 アカウント管理	最小権限と MFA を適用	OS、クラウド
6.1 アクセス制御	RBAC、ネットワークポリシー	すべてのレイヤー
8.1 監査ログ管理	包括的なログ記録を有効化	すべてのレイヤー
13.1 ネットワーク監視	IDS/IPS、フローログを導入	ネットワーク
3.1 データ保護	保存時／転送時の暗号化を有効化	クラウド、データベース

CIS コントロールの詳細なマッピングについては、references/cis-benchmark-mapping.md を参照してください。

コンテナベースイメージの選択

セキュリティ要件と互換性のニーズに基づいて、ベースイメージを選択します。

ユースケース	推奨ベースイメージ	サイズ	CVE	トレードオフ
本番アプリ	Chainguard Images	~10MB	0	最小構成、CVE ゼロ
最小構成の Linux	Alpine	~5MB	少数	小型、監査しやすい
互換性	Distroless	~20MB	少数	シェルがなく、デバッグが困難
デバッグ	Debian slim	~80MB	多数	デバッグツールを含む
レガシーアプリ	Ubuntu	~100MB	多数	高い互換性

本番環境向けの推奨： 本番環境では Chainguard Images または Distroless、開発環境では Alpine を使用します。

検証と監査

ハードニングは実装時だけでなく、継続的に検証する必要があります。

セキュリティの自動スキャン

コンテナの脆弱性スキャン：

# Trivy: Comprehensive vulnerability and misconfiguration scanner
trivy image --severity HIGH,CRITICAL myapp:latest

# Grype: Fast vulnerability scanner
grype myapp:latest

Infrastructure as Code のスキャン：

# Checkov: Multi-cloud IaC scanner
checkov -d terraform/ --framework terraform

# Terrascan: Policy-as-code scanner
terrascan scan -t terraform -d terraform/

Kubernetes のセキュリティスキャン：

# Kubesec: Security risk analysis
kubesec scan k8s/deployment.yaml

# Polaris: Configuration validation
polaris audit --format=pretty

# Trivy K8s scanning
trivy k8s --report summary cluster

クラウドセキュリティ態勢：

# Prowler: AWS security assessment
prowler aws --services s3 iam ec2

# ScoutSuite: Multi-cloud security audit
scout aws --services s3 iam ec2

継続的検証パイプライン

セキュリティスキャンを CI/CD に統合します。

# GitHub Actions example
name: Security Hardening Verification

on:
  push:
    branches: [main]
  schedule:
    - cron: '0 0 * * *'  # Daily scan

jobs:
  container-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Build image
        run: docker build -t myapp:test .

      - name: Scan with Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: 'myapp:test'
          severity: 'CRITICAL,HIGH'
          exit-code: '1'  # Fail on findings

  iac-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Scan IaC with Checkov
        uses: bridgecrewio/checkov-action@master
        with:
          directory: terraform/
          framework: terraform
          soft_fail: false

コンプライアンスレポート

スキャン結果からコンプライアンスレポートを生成します。

# Generate CIS compliance report
kube-bench run --json > cis-report.json

# Generate vulnerability report
trivy image --format json --output vuln-report.json myapp:latest

# Aggregate reports for compliance dashboard
python scripts/generate-compliance-report.py \
  --cis cis-report.json \
  --vulns vuln-report.json \
  --output compliance-dashboard.html

自動化ツール

ハードニングの自動化

• Ansible/Puppet/Chef： OS のハードニング向け構成管理
• Terraform/Pulumi： セキュリティモジュールを備えた Infrastructure as Code
• Cloud Custodian： クラウドリソースのポリシー適用
• OPA/Gatekeeper： Kubernetes のポリシー適用
• Kyverno： Kubernetes ネイティブのポリシー管理

スキャンツール

• Trivy： 脆弱性と設定ミスを幅広くスキャン
• Checkov： IaC のセキュリティとコンプライアンスをスキャン
• Falco： ランタイムセキュリティ監視
• Prowler： AWS セキュリティ評価ツール
• ScoutSuite： マルチクラウドのセキュリティ監査
• Lynis： Linux セキュリティ監査
• docker-bench-security： Docker CIS ベンチマークスキャナー
• kube-bench： Kubernetes CIS ベンチマークスキャナー

監視ツール

• Falco： コンテナのランタイム脅威検出
• Sysdig： コンテナのセキュリティと監視
• Wazuh： ホストとエンドポイントのセキュリティ監視
• OSSEC： ホストベースの侵入検知

クイックリファレンス：一般的なハードニングタスク

SSH アクセスのハードニング

# Edit /etc/ssh/sshd_config.d/hardening.conf
PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
MaxAuthTries 3
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

# Restart SSH
systemctl restart sshd

コンテナイメージのハードニング

# Use minimal base
FROM cgr.dev/chainguard/python:latest

# Non-root user
USER nonroot

# Read-only filesystem
COPY --chown=nonroot:nonroot app /app
WORKDIR /app

# Drop all capabilities
ENTRYPOINT ["python", "-m", "app"]

Kubernetes Pod のハードニング

securityContext:
  runAsNonRoot: true
  runAsUser: 65534
  seccompProfile:
    type: RuntimeDefault
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true
  capabilities:
    drop: ["ALL"]

AWS S3 バケットのハードニング

resource "aws_s3_bucket_public_access_block" "secure" {
  bucket = aws_s3_bucket.data.id

  block_public_acls       = true
  block_public_policy     = true
  ignore_public_acls      = true
  restrict_public_buckets = true
}

resource "aws_s3_bucket_server_side_encryption_configuration" "secure" {
  bucket = aws_s3_bucket.data.id

  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "aws:kms"
    }
  }
}

デフォルト拒否によるネットワークのハードニング

# Kubernetes NetworkPolicy: deny all ingress
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-ingress
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress

データベースアクセスのハードニング

-- PostgreSQL hardening
REVOKE ALL ON DATABASE app FROM PUBLIC;
REVOKE ALL ON SCHEMA public FROM PUBLIC;

CREATE ROLE app_user WITH LOGIN;
GRANT CONNECT ON DATABASE app TO app_user;
GRANT SELECT, INSERT, UPDATE ON app.orders TO app_user;

-- Force SSL connections
ALTER SYSTEM SET ssl = on;
-- In pg_hba.conf: hostssl all all 0.0.0.0/0 scram-sha-256

詳細なハードニングガイド

レイヤーごとのハードニングガイダンスについては、以下を参照してください。

• OS のハードニング： references/linux-hardening.md を参照してください
• コンテナのハードニング： references/container-hardening.md を参照してください
• クラウドのハードニング： references/cloud-hardening.md を参照してください
• ネットワークのハードニング： references/network-hardening.md を参照してください
• データベースのハードニング： references/database-hardening.md を参照してください

自動化スクリプトについては、以下を参照してください。

• Python による自動化： scripts/harden-linux.py を参照してください
• コンテナホストのセットアップ： scripts/harden-container-host.sh を参照してください
• コンプライアンスレポート： scripts/generate-compliance-report.py を参照してください
• インフラストラクチャのスキャン： scripts/scan-infrastructure.sh を参照してください

動作するサンプルについては、以下を参照してください。

• Linux の設定： examples/linux/ を参照してください
• Kubernetes マニフェスト： examples/kubernetes/ を参照してください
• Terraform モジュール： examples/terraform/ を参照してください

関連スキルとの統合

• auth-security： 認証および認可のパターンはハードニングを補完します
• secret-management： 安全なシークレットの取り扱いはハードニングに不可欠です
• kubernetes-operations： Pod のセキュリティと RBAC のハードニング
• infrastructure-as-code： IaC パイプラインでのセキュリティスキャン
• building-ci-pipelines： セキュリティスキャンの自動統合
• observability： セキュリティの監視とアラート
• compliance-frameworks： ハードニングをコンプライアンス要件に対応付けます

避けるべきアンチパターン

❌ デプロイ時だけハードニングする

• ハードニングは継続的に行うものです。定期的にスキャンして検証してください

❌ すべての制御を無条件に適用する

• リスクと公開範囲に基づいて優先順位を付けてください

❌ 検証しない

• ハードニングが適用され、効果を発揮していることを必ず検証してください

❌ 隠すことによるセキュリティ

• 隠すことはセキュリティではありません。実績のある制御を使用してください

❌ テストなしでハードニングする

• ハードニングの変更によって機能が損なわれないことをテストしてください

❌ 大規模環境で手動でハードニングする

• 一貫性と再現性を確保するため、ハードニングを自動化してください

はじめ方

1. 現在のセキュリティ状況を評価する： CIS ベンチマークスキャンを実行します
2. 優先順位を付ける： インターネットに公開されているもの → 機密データ → 内部
3. ベースラインのハードニングを適用する： OS、コンテナ、クラウドの基本設定
4. 自動化する： 一貫性を保つため、スクリプトと IaC を使用します
5. 継続的に検証する： スキャンを CI/CD に統合します
6. 監視する： ランタイムセキュリティ監視を導入します
7. 反復する： ハードニングを定期的に見直し、改善します

手順に沿って実装するには、インフラストラクチャの種類に応じて、references/linux-hardening.md または references/container-hardening.md から始めてください。