【第1部】サーバー設定の健康診断。AIで見抜く「セキュリティの穴」と修正法

サーバー構築が終わった直後、そのセキュリティは「完璧」だったはずです。 手順書通りにSSHポートを変更し、鍵認証にし、パーミッションもガチガチに固めた。あの時の達成感はひとしおですよね。

でも、半年後、1年後はどうでしょう？

「緊急対応で一時的に制限を緩めたまま、戻すのを忘れていないか？」 「OSのアップデートで、設定ファイルが勝手に初期状態に戻っていないか？」 「前任者が独自に追加した設定、ちゃんと把握できているか？」

サーバーは生き物です。長く運用すればするほど、変更や修正が積み重なり、「設計図（手順書）」と「実際のサーバーの中身」は必ずズレていきます。 この、誰も正しい状態を把握できていない「ツギハギだらけの状態」こそが、セキュリティ事故の最大の温床です。

とはいえ、このズレを目視ですべてチェックするのは至難の業。 そこで今回は、長く運用しているサーバーの「現在の設定ファイル」をそのままAIに食わせ、「今の設定、客観的に見てヤバいところある？」と診断させる手法を紹介します。

運用課題

構築時には「手順書」という正解がありますが、運用フェーズに入ると正解が曖昧になります。あるのは、担当者の記憶頼りの「変更履歴」だけです。

人間はどうしても「自分が設定したんだから大丈夫（なはず）」と思い込みがちですが、AIは忖度しません。渡された設定ファイルだけを見て、冷徹に事実を指摘してくれます。

• 「うっかり」の検知: 3ヶ月前に「テスト用」で開けたポートの消し忘れ。
• 「先祖返り」の発見: パッケージ更新時に設定ファイルが上書きされ、無効化したはずのパスワード認証が復活していた。
• 「自己流」の指摘: 急いで追加したユーザーの権限設定が、実は標準より甘くなっていた。

これらを「定期的に、かつ一瞬で」洗い出せるのが、AI診断を取り入れる最大のメリットです。

情報収集

まずは、AIに診せるためのレントゲン写真を撮ります。

今回は以下の4ステップで情報を取得します。特に**ステップ2の「ユーザー確認」**は、自分が把握していない謎のユーザーが作られていないかを知るために重要です。

コマンド一覧

以下のコマンドを実行し、結果をメモ帳などにコピーしておいてください。

ステップ	調査項目	実行コマンド	AIに見せるポイント
① SSH	鍵・ポート設定	# cat /etc/ssh/sshd_config	パスワード認証の無効化 ポート番号の変更
② ユーザー	存在確認	# cat /etc/passwd	退職者のIDが残っていないか 不明なIDが作られていないか
③ 権限	ディレクトリ権限	# ls -ld /home/ユーザー名 # ls -la /home/ユーザー名/.ssh	他人から中身が見えないか (権限 700 / 600 推奨)
④ 通信	Firewall設定	# firewall-cmd --list-all	意図しないポート解放 不要なサービスの許可

※ ③の補足: ユーザー名 の部分は、ステップ②で確認した「現在使用しているユーザーID」（例: test1 や admin）に書き換えて実行してください。

診断手順

情報を集めたら、Gemini等のAIチャットに投げます。 ポイントは、「運用を続けているサーバーなんだけど、今の設定でセキュリティ的に甘くなってない？」というニュアンスで聞くことです。

プロンプト

以下のテキストをコピーし、（ ）内をご自身の環境に合わせて書き換えて送信してください。

---

発見事例

実際に、数年運用している私のサーバーを診断させた際、AIに指摘されて「ヒヤッとした事例」を4つ紹介します。

1. 丸見えだったデータベース

【AIの指摘】

「Firewallの services に mysql が含まれています。これはデータベースのポート（3306）がインターネットに対してフルオープンになっていることを意味します。外部からの総当たり攻撃（ブルートフォース）のリスクが極めて高い状態です。」

【その原因】 開発ツールからDBに直接接続したくて、一時的にポートを開放し、そのまま閉じるのを忘れていました。 指摘を受けてすぐにポートを閉じ、SSHポート転送（トンネリング）経由での安全な接続に切り替えました。

2. 権限不備（755問題）

【AIの指摘】

「ls -ld /home/test1 の結果が drwxr-xr-x (755) になっています。これでは、同じサーバーにログインできる他のユーザーから、ファイル一覧が見放題です。」

【その原因】 これ、完全に記憶から抜けていました。 半年前にトラブル調査をした際、一時的に権限を緩め、戻すのを忘れていたんです。AIに言われるまで、一生気づかなかったと思います。

3. 所有者ミス

【AIの指摘】

「.ssh/authorized_keys の所有者が root:root です。これだと、ユーザー test1 でログインしようとしても、権限不足で鍵を読み込めず認証エラーになります。」

【その原因】 新しくユーザーを追加した際、急いでroot権限で作業してコピーしたのが原因でした。 「セキュリティ」以前に「ログインできない」という初歩的なミスですが、ログを見る前にAIが予言してくれたおかげで、手戻りを防げました。

4. 設定上書き

【AIの指摘】

「sshd_config 本体ではパスワード認証を拒否していますが、末尾で Include を読み込んでいます。読み込み先で PasswordAuthentication yes が設定されていると、そちらが優先されます。」

【実際の状況】 最近のOSでは、この Include がデフォルトで有効になっています。 ここを見落としていて、実はパスワード認証が生きている……なんてケースは本当によくあります。ここを的確に突いてくるのは、さすがAIといったところです。

まとめ

サーバーの設定ファイルは、書いて終わりではありません。運用している限り、常に変化し、散らかっていくものです。

「自分はミスをしない」と過信するより、「人間はミスをするし、忘れる生き物だ」と認めて、AIに定期的にダブルチェックしてもらう。 この方が、精神衛生上もセキュリティ上も圧倒的に健全です。

ぜひ、次のメンテナンスのタイミングで、サーバーの設定ファイルをAIに投げてみてください。 「うわ、こんな設定残ってたっけ？」という発見が、きっとあるはずです。