【第6回】セキュリティ監査の自動化：AIによるサーバー設定の脆弱性診断とレポート作成

サーバー構築直後は完璧だったはずのセキュリティ設定も、日々の運用やトラブルシューティングを経るうちに、「一時的にファイアウォールを開けたまま忘れた」「検証のためにSELinuxを無効化した」といった設定の漂流（Configuration Drift）が発生します。これが重大なセキュリティインシデントの引き金となります。

従来、このような「設定ミス（Misconfiguration）」を防ぐためには、定期的に人間が目視で確認するか、OpenSCAPのような専用の監査ツールを導入する必要がありました。しかし、目視はヒューマンエラーの温床であり、専用ツールは出力されるレポートが難解で、現場のエンジニアにとって修復のハードルが高いという課題がありました。

本連載「Linuxエンジニアのための生成AI」第6回となる今回は、生成AIを「仮想のセキュリティ監査人」として活用し、サーバーの主要な設定ファイルを自動的に収集・解析させ、危険な設定の洗い出しから具体的な修正コマンドの提示までを一貫して行う「自動脆弱性診断パイプライン」の構築手法を解説します。

---

1. なぜサーバーのセキュリティ監査にAIが必要なのか？

サーバーのセキュリティ監査において、私たちは「何が正しい設定なのか」を常に定義し続けなければなりません。ここでは、AIを導入する背景を整理します。

1-1. 従来の監査ツール（OpenSCAP等）の課題

Linux環境におけるセキュリティ監査のデファクトスタンダードとして、OpenSCAPなどのスキャナが存在します。これらはCIS（Center for Internet Security）ベンチマークなどの厳格なルールに基づいてサーバーを診断します。

しかし、これらのツールには以下のような運用上の課題があります。

• レポートが難解： 何百ページにも及ぶXML/HTMLレポートが出力され、「どの項目が本当に自分たちの環境にとってクリティカルなのか」のトリアージが困難です。
• 修正方法が直感的でない： 「OVAL定義ID XXXに違反」と表示されても、エンジニアが手動で公式ドキュメントを調べ、修正コマンドを組み立てる必要があります。
• 文脈を考慮できない： 「このサーバーは内部LAN限定の踏み台サーバーであるため、特定のポートが開いているのは仕様である」といった、システムのアーキテクチャ上の「文脈（Context）」を柔軟に除外することが苦手です。

1-2. 生成AIによる「文脈を理解した脆弱性診断」の強み

生成AI（LLM）は、これらの課題を劇的に解決します。設定ファイルの生データ（Raw Data）をAIに渡し、「このサーバーはWebフロントエンドとして稼働しているAlmaLinux 9です」という前提条件（プロンプト）を与えることで、AIは設定を意味論的に解釈します。

単に「ルール違反」を指摘するだけでなく、「なぜそれが危険なのか（理由）」と「AlmaLinux 9環境で実行すべき具体的な修復コマンド（解決策）」を同時に提示してくれます。これは、シニアエンジニアがジュニアエンジニアのコードをレビューする体験そのものです。

2. AIによる自動監査システムのアーキテクチャ設計

本記事で構築する監査パイプラインの全体像を設計します。

2-1. システム構成と処理フロー

1. データ抽出フェーズ： Cronで定期実行されるBashスクリプトが、OSの主要なセキュリティ設定ファイルと現在のステータスを抽出します（コメント行や空行は事前に除去し、トークン数を節約します）。
2. プロンプト結合フェーズ： 抽出したデータをJSON形式にまとめ、AIに対して「SREとしての厳格な監査」を指示するシステムプロンプトと結合します。
3. API推論フェーズ： ChatGPT等のAPIへデータを送信し、脆弱性のリストをJSONフォーマットで返却させます。
4. レポーティングフェーズ： 返却されたJSONをパースし、緊急度（Critical/High/Medium/Low）に応じて色分けしたレポートをSlackやチケット管理システム（Jira/Redmine）へ通知します。

2-2. 抽出対象の選定（SSH, firewalld, SELinux）

AIのコンテキストウィンドウには制限があり、またAPIコストを抑えるためにも、すべてのファイルを投げるのではなく、システムの急所となる設定をピンポイントで抽出します。

• SSH設定 (/etc/ssh/sshd_config)： PermitRootLogin や PasswordAuthentication、不要なポートフォワーディングが許可されていないか。
• ファイアウォール (firewall-cmd --list-all)： 意図しないポート（例えばDBの3306ポートなど）がパブリックゾーンに公開されていないか。
• SELinux (sestatus)： Enforcingモードで稼働しているか。
• ユーザー・特権設定 (/etc/sudoers, /etc/shadowの一部)： パスワードなしのsudoが過剰に許可されていないか。

3. 実践：セキュリティ監査自動化スクリプトの実装

それでは、AlmaLinux 9環境で動作する監査スクリプト ai_security_audit.sh を実装します。

3-1. サーバー設定を抽出・結合するBashスクリプト

AIへ送信するペイロードを小さくするため、grep を使って設定ファイルからコメント行（#で始まる行）と空行を排除する前処理を行います。

#!/bin/bash
# ==============================================================================
# Script Name: ai_security_audit.sh
# Description: サーバー設定を抽出し、AIにセキュリティ監査を行わせる
# OS: AlmaLinux 9
# ==============================================================================

# 環境変数からAPIキーを読み込み
source /etc/zabbix/ai_credentials.env

echo "1. サーバー設定の抽出を開始します..."

# 1. SSH設定（コメントと空行を除外）
SSH_CONF=$(grep -vE "^\s*#|^\s*$" /etc/ssh/sshd_config)

# 2. Firewalldのアクティブな設定
FW_CONF=$(sudo firewall-cmd --list-all 2>/dev/null)

# 3. SELinuxのステータス
SELINUX_CONF=$(sestatus)

# 4. パスワードなしsudoが許可されているユーザー/グループの抽出
SUDOERS_CONF=$(sudo grep -r "NOPASSWD" /etc/sudoers /etc/sudoers.d/ 2>/dev/null | grep -vE "^\s*#")

# 抽出したデータを1つのテキストに結合
RAW_DATA="
[SSHD_CONFIG]
$SSH_CONF

[FIREWALLD_STATUS]
$FW_CONF

[SELINUX_STATUS]
$SELINUX_CONF

[SUDOERS_NOPASSWD_RULES]
$SUDOERS_CONF
"

if [ -z "$RAW_DATA" ]; then
    echo "[ERROR] 設定の抽出に失敗しました。root権限で実行しているか確認してください。"
    exit 1
fi

3-2. CISベンチマークに準拠させるAIシステムプロンプト

抽出した RAW_DATA を評価するためのシステムプロンプトを定義します。ここでも「JSON出力の強制」と「CISベンチマーク基準」を明記することがプロの技です。

# AIへのシステムプロンプト
SYSTEM_PROMPT=$(cat << 'EOF'
あなたはプロのセキュリティエンジニアであり、SREです。
対象は「AlmaLinux 9」で稼働するパブリック向けのWebサーバーです。
提供されたサーバーの設定情報をCIS（Center for Internet Security）ベンチマークの基準に照らし合わせて監査してください。

以下の観点を特に厳しくチェックしてください。
- SSH: Rootログインの許可、パスワード認証の許可、X11Forwardingの許可は重大な脆弱性（Critical）です。
- Firewalld: HTTP(80), HTTPS(443), SSH(22以外が望ましい) 以外の不要なポートが開いていないか。
- SELinux: Enforcing以外になっていないか。

出力は以下の構造の厳格なJSON形式のみとしてください。Markdownのコードブロック(```json)や挨拶は一切含めないでください。
{
  "audit_date": "YYYY-MM-DD",
  "score": 100点満点中のスコア,
  "vulnerabilities": [
    {
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "category": "SSH | Firewall | SELinux | Privilege",
      "issue": "発見された脆弱性の説明",
      "remediation_cmd": "修正するためのAlmaLinux 9環境向けの具体的なBashコマンド（配列）"
    }
  ]
}
対象がない（安全である）場合は vulnerabilities 配列を空にしてください。
EOF
)

# JSONペイロードの生成とAPI呼び出し
JSON_PAYLOAD=$(jq -n \
    --arg model "gpt-4o" \
    --arg sys "$SYSTEM_PROMPT" \
    --arg data "$RAW_DATA" \
    '{
        model: $model,
        messages: [
            {role: "system", content: $sys},
            {role: "user", content: $data}
        ],
        temperature: 0.1,
        response_format: { type: "json_object" }
    }')

echo "2. AIによる監査を実行中..."
RESPONSE=$(curl -s --max-time 60 -X POST "
https://api.openai.com/v1/chat/completions
api.openai.com(https://api.openai.com/v1/chat/completions)" \
    -H "Authorization: Bearer $OPENAI_API_KEY" \
    -H "Content-Type: application/json" \
    -d "$JSON_PAYLOAD")

# レスポンスからJSON部分を抽出して保存
echo "$RESPONSE" | jq -r '.choices[0].message.content' > /var/log/ai_security_audit_report.json

echo "3. 監査が完了しました。レポートは /var/log/ai_security_audit_report.json に保存されました。"

4. AI監査レポートの活用とセキュアな運用フロー

出力されたJSONレポートを、チームが確認してアクションを起こせる形に昇華させます。

4-1. JSONレポートのパースとMarkdown/Slackへの出力

保存された ai_security_audit_report.json には、AIの知見が詰まっています。例えば、誰かが検証のためにSSHのパスワード認証を有効にしてしまった場合、以下のような結果が含まれます。

{
  "audit_date": "2026-05-10",
  "score": 65,
  "vulnerabilities": [
    {
      "severity": "CRITICAL",
      "category": "SSH",
      "issue": "sshd_configにおいてPasswordAuthenticationがyesに設定されています。ブルートフォース攻撃に対して脆弱です。",
      "remediation_cmd": [
        "sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config",
        "systemctl restart sshd"
      ]
    }
  ]
}

このデータを jq コマンドでループ処理し、SlackのWebhookへ送信する処理を前述のスクリプトの最後に追加すれば、毎朝9時に「前日の作業でセキュリティホールが空いていないか」を自動チェックする「DevSecOps」のパイプラインが完成します。

4-2. 自動修復（Auto-Remediation）における権限分離の原則

AIが提示した remediation_cmd（修復コマンド）を、スクリプト内でそのまま eval や bash -c で実行させれば、「完全自動修復」が実現できそうに見えます。しかし、これは絶対にやってはいけません。

AIのハルシネーション（誤推論）によって、必要なポートまで閉じてしまったり、SSHサービスを停止させてサーバーから締め出されたりするリスクがあるためです。プロの運用では「AIオペレーターへの最小権限の原則」を適用し、AIには「診断と提案（Read-only）」のみを許可し、コマンドの実行権限（Write）はエンジニアが承認したAnsibleなどの自動化基盤に移譲する設計をとります。

5. 第6回の総まとめと次回予告

本記事では、生成AIの「文脈理解能力」を活用し、AlmaLinux 9の複雑なサーバー設定ファイル群から脆弱性を発見し、修復コマンドまで提示するセキュリティ監査パイプラインを構築しました。

従来のOpenSCAPなどのツールに比べ、AIによる監査は「なぜ危険なのか」という理由が現場のエンジニアにも分かりやすく、修復のための具体的なアクション（BashコマンドやAnsibleタスク等）を直接得られる点が圧倒的に優れています。この仕組みをCronに組み込むことで、設定の漂流を早期に検知し、堅牢なインフラを維持することが可能になります。

次回の【第7回】TerraformとAIの連携：クラウドインフラ（AWS/GCP）のコード化と自動最適化では、サーバー単体の設定からさらに視野を広げ、クラウド全体のアーキテクチャ設計をAIに支援させ、TerraformのHCLコードをセキュアに生成する高度なインフラ構築手法について解説します。お楽しみに！