Securing Your Infrastructure

Ce que vous allez apprendre

• Dockerコンテナ、リバースプロキシ、APIが何であるかを知っている。
• サーバー上でコマンドを実行できるAIエージェント（Hermes、Claude Codeなど）を持っている。
• セキュリティの専門家である必要はありません――それがこの本の目的です。
• 第1章** — Ubuntu VPSのセキュリティ保護：SSH、ファイアウォール、モニタリング、インシデント対応。これらがなければ他のすべてが無意味になる基盤。
• 第2章** — Webサーバーのセキュリティ保護：TLS、セキュリティヘッダー、Docker、FastAPI、レート制限。ユーザーがサービスにアクセスする際に彼らを保護するもの。
• 第3章** — 自律型AIエージェントのセキュリティ保護：プロンプトインジェクション、権限、サンドボックス化、キルスイッチ。2026年のセキュリティの新たなフロンティア。
• 第4章** — 完全なチェックリスト：デプロイ前、月次監査、自動化ツール。すべてを再現可能なプロセスにまとめる。

Chapitres détaillés

• はじめに

  • 私のサーバーはハッカーにとって興味がない――本当か、それとも嘘か？
  • なぜこの本を書いたのか
  • この本の使い方
  • 前提条件
  • この本で学ぶこと
  • 例についての補足
  • セキュリティはプロセスである
• 第1章：Ubuntu VPSのセキュリティ確保

  • 1.1 SSH — エントリーポイント
• 1.2 ファイアウォール（UFW）

  • 1.2 ファイアウォール（UFW）
• 1.3 モニタリングとログ

  • 1.3 モニタリングとログ
• 1.4 インシデント対応 — 発生した際の対応方法

  • 1.4 インシデント対応 — 発生した際の対応方法
• 1.5 自動アップデート

  • 1.5 自動アップデート
  • 章のまとめ
• 1.6 Fail2ban — 攻撃者を自動的にブロックする

  • 1.6 Fail2ban — 攻撃者を自動的にブロックする
• 1.7 監査プロンプト — Ubuntu VPS

  • 1.7 監査プロンプト — Ubuntu VPS
• 2.1 TLS — 通信の暗号化

  • HTTP vs HTTPS：TLSがないとあなたが失うもの
  • TLS 1.3 vs 1.2：アップグレードすべき理由
  • 証明書：コマンドではなくロジックを理解する
  • HSTS：HTTPSを強制する
  • ミックスドコンテンツ：HTTPSが保護しない場合
  • AIプロンプト：TLS設定の監査
• 2.2 セキュリティヘッダー

  • なぜHTTPヘッダーがウェブにおける最初の防衛線になるのか
  • Content-Security-Policy：最も強力なヘッダー
  • X-Frame-Options：クリックジャッキング対策
  • X-Content-Type-Options：MIMEスニッフィング対策
  • Referrer-Policy：共有される情報を制御する
  • Permissions-Policy：ブラウザAPIの制限
  • AIプロンプト：セキュリティヘッダーの監査
• 2.3 レート制限とWAF

  • レート制限を行う理由
  • レート制限とスロットリングの違い
  • レート制限を適用する場所
  • レート制限のよくある間違い
  • WAF：いつ役に立ち、いつ不十分か
  • Nginx向けfail2ban：ファイアウォールとWebの連携
  • AIプロンプト：レート制限とWAFの監査
• 2.4 Docker — 分離とコンテインメント

  • コンテナが仮想マシンではない理由
  • コンテナエスケープ：攻撃者がコンテナから脱出する方法
  • rootで実行してはならない
  • リソース制限：CPU、メモリ、ディスク
  • Docker Compose：ブラスト半径を制限するために分離する
  • AIプロンプト：Dockerセキュリティ監査
• 2.5 FastAPI — APIのセキュリティ保護

  • CORS：なぜ必要なのか、そしていつリスクになるのか
  • 入力検証：防御の深層化としてのPydantic
  • シークレット管理：本番環境では.envだけでは不十分
  • セキュアなロギング：トークンをログに記録しない
  • AIプロンプト：FastAPI APIセキュリティ監査
• 2.6 WAF — Web Application Firewall

  • 2.6 WAF — Web Application Firewall
• 2.7 CI/CDセキュリティ — デプロイメントパイプラインの保護

  • 2.7 CI/CDセキュリティ — デプロイメントパイプラインの保護
• 2.8 監査プロンプト — Nginx、FastAPI、Docker

  • 2.8 監査プロンプト — Nginx、FastAPI、Docker
• 3.1 AIエージェントが従来と異なる理由

  • AIエージェントは決定を下す — 従来のソフトウェアは実行するだけ
  • 攻撃表面はコードではなく、プロンプトである
  • 実際の事例：Meta社のインシデント（2026年3月）
  • 実際の事例：Summer Yue — 削除された受信トレイ
  • インフラストラクチャへの教訓
• 3.2 プロンプトインジェクション — 攻撃の仕組みを理解する

  • 直接インジェクション：ユーザーのプロンプトを操作する
  • 間接インジェクション：エージェントが読み込むコンテンツを制御する
  • コンテンツフィルタリングが不十分な理由
  • フィルタリングではなく、権限によるアプローチ
  • 成功した攻撃の具体的な例
• 3.3 権限と最小特権

  • なぜAIエージェントはあなたより少ない権限でなければならないのか
  • Read-onlyとread-write：アクションごとに決定する
  • APIスコープ：各トークンをその用途に限定する
  • 権限の自動失効
  • AIプロンプト：AIエージェントの権限監査
• 3.4 サンドボックス化、キルスイッチ、監査可能性

  • エージェントが分離された環境で実行される必要がある理由
  • コンテナ、分離されたネットワーク、読み取り専用ファイルシステム
  • ハードゲートとソフトプロンプト
  • キルスイッチ：緊急停止ボタン
  • ログ：すべてのアクションを追跡可能にする
  • マスキングとカナリーデータ
  • AIプロンプト：エージェントのフェイルセーフを確認する
• 3.5 機密性の高いツールとログの制御

  • 3.5 機密性の高いツールとログの制御
• 3.6 監査プロンプト — 自律型AIエージェント

  • 3.6 監査プロンプト — 自律型AIエージェント
• 4.1 デプロイ前チェックリスト

  • VPS : SSH、ファイアウォール、ユーザー、アップデート
  • Docker : 分離、ユーザー、リソース制限
  • API : ヘッダー、CORS、レートリミット、シークレット
  • AIエージェント : 権限、サンドボックス化、キルスイッチ、ログ
• 4.2 自動監査ツール

  • Lynis：マシンの包括的スキャナー
  • Trivy：コンテナとイメージの脆弱性
  • docker-bench-security：CIS Docker Benchmark
  • Mozilla Observatory：HTTPヘッダー
  • 月次ワークフローへの統合
  • AIプロンプト：包括的な監査の実行と結果の解釈
• 4.3 月次監査と参照フレームワーク

  • 単発の監査では不十分な理由
  • 必須の月次チェック7項目
  • ツールが脆弱性を検知した場合
  • 参照フレームワーク：NIST、CIS、OWASP
• 4.4 監査プロンプト — 完全なインフラストラクチャ

  • 4.4 監査プロンプト — 完全なインフラストラクチャ
• 結論

  • セキュリティはプロセスであり、状態ではない
  • まとめ：基本原則
  • 次のステップ
  • 用語集
  • 追加リソース

Ce qui rend ce livre différent

Formats et compatibilité

Questions fréquentes