情報の解像度を操る：膨大な「分析ログ」から「公開日報」を抽出する自動化の作法 | UNIX Cafe

UNIX Cafe | セキュリティ運用メモ

5月から、セキュリティ日報の掲載フォーマットを新形式へ切り替えました。単なる見た目の変更ではなく、監視スクリプトの出力責務を整理し、公開用の日報と分析用ログの役割を分離した運用改善です。

あわせて、.htaccess の運用も静的な blacklist 管理から runtime deny ベースへ再定義しました。この記事では、変更の背景・新フォーマットの構成・自動化の追加点をまとめます。

---

📝 この記事で学べること

• 旧形式の日報が抱えていた問題点
• 監視スクリプトの出力責務をどう整理したか
• .htaccess の runtime deny と static deny の役割分担
• 新形式の日報フォーマットと検証ポイント
• static deny 候補の自動整理と反映ログの追加

---

旧形式の日報が抱えていた問題

従来の形式は、IPごとに incident log を積み上げる構成でした。WHOIS 情報・攻撃種別・補足説明まで含まれており、分析資料としては有効です。しかし公開記事として見ると、次の問題がありました。

• 情報量が多く、当日の全体像がつかみにくい
• 新規隔離と継続隔離の区別が弱い
• sites= や内部集計値など、生の運用データが混ざりやすい
• WordPress 掲載前の整形コストが高い
• 分析用ログと公開用記事の役割が混在していた

旧形式は「深く読むには便利」でも、「毎日すばやく状況共有する形式」としては非効率でした。

なぜスクリプトの修正が必要だったのか

この課題は、記事を書く段階の手修正だけでは解決しません。日報は毎日生成されるため、都度整形する運用では再現性がなく、担当者によって品質がぶれます。スクリプトの出力責務を最初から整理することが必要でした。

目標は、一目で状況を把握できる SOC 運用向けの日報です。当日新たに隔離した IP と、継続して遮断・観察している IP を分けて提示することで、日報の意味が明確になります。また、複数サイトにまたがる攻撃については、ドメイン名を並べず「複数の管理環境」と表現する方針に統一しました。

check_all.sh を起点にした出力責務の整理

監視処理全体は check_all.sh が起点です。ログ取得・解析・集計・隔離更新・runtime deny 生成・日報生成・analysis 出力・クリーンアップが順に動きます。

その中で、2つのスクリプトを役割ごとに分けて整理しました。

スクリプト	出力先	役割
bin/report_security.sh	reports/YYYY-MM/security_daily_YYYYMMDD.txt	当日の事実関係を示す骨格（公開用）
bin/analyze_patrol.sh	analysis/YYYY-MM/DD/incident_log_YYYYMMDD.txt	IPごとの説明根拠（分析用）

この2つを同じ目的の出力として扱わないことが、見直しの核心です。役割分担を整理したことで、公開用日報の構造が安定しました。

.htaccess 運用の再定義

今回の見直しで大きかったのが、.htaccess の位置付けを明確にしたことです。旧形式では、記事に出てくる IP 一覧がそのまま現在の遮断対象一覧のように見えやすい面がありました。

しかし実際の流れは次のとおりです。

1. 監視結果がまず state に蓄積される
2. state/deny_runtime.conf が生成される
3. .htaccess の runtime 領域へ反映される

つまり .htaccess への直接の入力元は記事ではなく state です。runtime deny は継続中の一時隔離や再犯 IP を含む、累積的な遮断状態を持ちます。

---

⚠️ 日報件数と deny 行数は一致しなくて正常

日報は当日の共有対象を示すもの、runtime deny は継続中の遮断状態全体を持つものです。2つの数が一致しないこと自体は、それぞれが責務どおりに動いている証拠です。

---

新形式の日報フォーマット

新形式は reports/security_daily_soc_template.txt と reports/CODEX_DAILY_REPORT_INSTRUCTIONS.md を基準に整理しています。構成は次の順序で固定しました。

1. 日付見出し
2. ブログ向けタイトル
3. 導入文
4. 本日新規隔離
5. 継続隔離中
6. 運用補足
7. 分析メモ

この構造により、当日増えた対象と継続対象を分離できます。WHOIS 情報と Comment を維持しながら、本文全体を読みやすい日本語で統一できます。ドメイン名や sites= のような内部向け情報を排除し、公開時のノイズも減らしました。

形式変更後の検証ポイント

形式変更後は、見た目が整っているかだけでなく、責務どおりに出力されているかを確認しました。

• 見出し順が固定されているか
• ドメイン名や sites= が本文に残っていないか
• 新規隔離と継続隔離が混同されていないか
• incident_log_*.txt を WHOIS 情報と Comment の再利用元として扱えているか
• .htaccess と日報がそれぞれ責務どおりに生成されているか

static deny 候補の自動整理を追加

その後の運用整理では、runtime deny だけでなく common_security.txt 側の static deny についても自動判定の仕組みを追加しました。

具体的には、state/promote_candidates.tsv・state/quarantine_history.tsv・state/daily_scores.tsv をもとに、既存の common_security.txt に未登録の IP だけを抽出し、state/static_deny_candidates.txt として候補を出力するようにしました。

---

💡 候補を2種類に分けて人間が判断しやすくする

恒久ブロック候補の Keep Candidates と、高シグナルの一時固定遮断候補である Hold Candidates を分けて出力しています。いきなり .htaccess 本体を全面自動更新しないことで、重複登録を避けながら、新規追加候補を毎日確認しやすくなっています。

---

Hold セクションへの反映と日報への記録

state/static_deny_candidates.txt の Hold Candidates から Require not ip 行だけを取り出し、common_security.txt の Hold セクションへ重複なしで追記する処理も追加しました。この作業は bin/apply_static_hold_candidates.sh が担い、実行結果は state/static_deny_apply_log.txt に保存されます。

さらに、この反映結果が日報にも出るようになりました。bin/report_security.sh と bin/show_security_summary.sh に static deny 反映 セクションを追加し、「何件追加したか」「追加対象がなかったか」をその日のレポート内で確認できます。遮断判断の記録がサーバー設定だけに閉じず、日次の共有文書にも残るようになったことが大きな改善です。

運用ルールとして整理したこと

• 分析用の詳細は analysis/ に残す
• 公開・共有用の日報は reports/ で簡潔にまとめる
• 実在ドメインは出さず、「複数の管理環境」と表現する
• 継続隔離中 は .htaccess の全件一覧ではなく、当日意味のある継続対象だけを載せる
• .htaccess は記事の要約結果ではなく、runtime deny による実遮断設定として管理する

まとめ

---

✔ 今回の改善ポイント

• 公開用日報（reports/）と分析用ログ（analysis/）の役割を分離した
• runtime deny と static deny の役割分担を実装レベルで明確にした
• static deny 候補を自動整理し、人間が判断しやすい形で出力するようにした
• Hold 反映ログを日報に含めることで、遮断判断の記録を日次ドキュメントに残せるようにした

---

今回更新したのは記事のレイアウトではなく、セキュリティ監視結果をどう共有し、どう遮断運用へつなげるかという設計そのものです。check_all.sh を起点にした一連の処理が、ログ取得から static deny 反映ログの出力まで一続きで追えるようになったことが、今回の改善のいちばん大きな意味です。