【AI社員実践記 第14話】監視サーバーの「扉」を締め直した　公開ポートを閉じてSSH経由だけにしてみた

こんにちは、オフィスピコッツの小笹です。

ここ数回のAI社員実践記では、1台のVPSへ少しずつ仕事を増やしてきました。

第9話ではサイト監視。

第10話ではドメイン期限チェックと月次稼働率レポート。

第11話ではリンク切れ巡回。

第13話では補助金の締切ウォッチ。

最初は月900円弱で止めたままになっていたサーバーが、今では会社の定期業務をいくつも担当する設備になっています。

今回の第14話は、少し毛色が違います。

新しい仕事を増やした話ではありません。

増えてきた仕事を守るために、サーバーの「戸締まり」を見直した話です。

作業時間は約10分。

新しい有料サービスも契約していません。

きっかけは、私がAI社員へ何となく聞いた一言でした。

「この画面、誰でも開ける状態って怖くない？」

第9話で導入したUptime Kumaは、26サイトを5分おきに確認しています。

管理画面を開けば、

• 正常か停止中か
• 稼働率
• 応答時間
• 過去の状態

などを一覧で確認できます。

非常に便利です。

ただ、ある日ふと気になりました。

私はAI社員へ、

「これ、ブラウザでアドレスを入れればすぐログイン画面が開く状態だけど、怖くない？」

と聞きました。

返ってきた答えは、

「ログインはありますが、無防備寄りです」

というものでした。

その理由は、大きく2つありました。

問題1：ログイン画面そのものがインターネットへ公開されていた

Uptime KumaにはログインIDとパスワードがあります。

だから、

「パスワードがあるなら大丈夫では？」

とも思えます。

でも、ログイン画面自体がインターネットから見える状態なら、世界中の誰でもそこまでは到達できます。

公開されているIPアドレスとポートは、常に自動スキャンの対象になります。

人間がわざわざ探しに来なくても、

「ここに何かサービスが動いている」

ことは機械的に見つけられます。

ログイン画面が見つかれば、

パスワードを大量に試す攻撃の対象になる可能性もあります。

実際に何か起きていたわけではありません。

でも、

「これまで何も起きなかった」ことと、「今の状態が安全」なことは別です。

問題2：管理画面への通信がHTTPだった

もう一つは通信経路です。

当時のUptime Kumaは、ブラウザからHTTPで開いていました。

HTTPSではありません。

つまり、ブラウザと監視サーバーの間の通信そのものは暗号化されていません。

社内の安全なネットワークだけで使うならまだしも、外出先のWi-Fiなどから管理画面を開く可能性を考えると、このまま使い続けるのは気になります。

ログインパスワードを強くするだけでは、

ログイン画面までの通信経路そのもの

は守れません。

そこでAI社員から出てきたのが、

「管理画面をインターネットから見えなくしましょう」

という案でした。

新しいセキュリティサービスを増やすのではなく、入口を閉じる

セキュリティ対策というと、

• VPN
• WAF
• 新しい認証サービス
• IP制限
• Cloudflare Access

など、いろいろな方法があります。

でも今回の用途はシンプルです。

Uptime Kumaの管理画面を見るのは、基本的に私だけです。

不特定多数の利用者に提供するサービスではありません。

それなら、

そもそもインターネットへ管理画面を公開する必要がない。

という結論になりました。

AI社員が提案したのは、

Uptime Kumaをサーバー内部からしか開けない状態にする

方法です。

そして外から見たいときだけ、

普段サーバー管理で使っているSSH接続を経由します。

SSHでは秘密鍵を使って本人確認します。

通信も暗号化されます。

つまり、

すでに持っているSSHの「鍵」を、そのまま管理画面へ入るための鍵として使う

という考え方です。

新しいパスワードは増えません。

新しいサービス契約もありません。

ただし、便利さは少し下がる

もちろん欠点もあります。

これまではブラウザへURLを入力すれば、すぐUptime Kumaのログイン画面が開きました。

変更後は、

1. SSHトンネルを接続する
2. ブラウザでローカル側のURLを開く

という一手間が増えます。

毎日何度も管理画面を開くなら、少し面倒かもしれません。

でも現在は、第10話で作った月次稼働率レポート係が毎月自動で結果を送ってきます。

異常時にはUptime Kumaからメール通知も来ます。

つまり、

正常なときに人間が管理画面を見に行く必要自体が減っています。

少し利便性を手放しても、安全性を上げる方がよいと判断しました。

いきなり作り直さず、まず「データがどこにあるか」を確認

ここから実際の作業です。

AI社員が最初に出したのは、設定変更のコマンドではありませんでした。

まず、

Uptime Kumaのデータがどこへ保存されているか確認する

作業です。

Dockerコンテナを作り直す場合、

「コンテナを消したら、監視設定まで消えないか」

が一番気になります。

26サイトをもう一度登録。

通知設定もやり直し。

過去の稼働記録も消える。

そんなことになれば、セキュリティ改善どころではありません。

そこでDockerの設定を確認しました。

確認すると、Uptime KumaのデータはDockerコンテナそのものではなく、

独立したVolumeへ保存

されていました。

監視対象。

履歴。

通知設定。

これらはコンテナを作り直しても残る構成です。

また、この時点のポート設定も確認できました。

Uptime Kumaの3001番ポートが、外部からアクセスできる形で公開されています。

ここを変更します。

「動いている」と「作り直しても戻せる」は別

今回、AI社員が最初にデータの場所を確認したのは重要だったと思います。

サービスが現在正常に動いている。

それと、

今から構成を変更しても安全に戻せる

ことは別問題です。

動いているサーバーを触るときほど、

「まず変更する」

ではなく、

「壊しても戻せる状態か確認する」

ところから始める。

第8話のメール移行でも似た進め方をしました。

AI社員と作業していると、こういう確認を先に挟めるのが助かります。

Uptime Kumaの入れ物だけを作り直す

保存データが残ることを確認したら、Uptime KumaのDockerコンテナを一度停止します。

そしてコンテナだけを削除。

すぐに新しい設定で起動し直します。

変更したのはポートの公開方法です。

以前は、

サーバーの外側から3001番ポートへ接続できる

状態でした。

新しい設定では、

127.0.0.1:3001

へだけ接続を許可します。

127.0.0.1は、そのサーバー自身を意味します。

つまり、

サーバーの中からは開ける。
インターネット側からは直接開けない。

状態です。

実際の変更後がこちらです。

Dockerの一覧でも、

127.0.0.1:3001->3001/tcp

になっていることを確認できました。

これが今回欲しかった状態です。

一瞬再起動しただけで、設定も履歴もそのまま戻った

ここは元の原稿から少し正確に書き直しておきます。

今回、Dockerコンテナを一度停止して作り直しているので、Uptime Kumaそのものは再起動の数秒間だけ停止しています。

ただし、

• 26サイトの監視設定
• 過去の稼働データ
• 通知設定

はVolumeに残っていたため、そのまま引き継がれました。

長時間サービスを停止したり、監視対象を登録し直したりする作業はありません。

作業全体でも約10分。

実際にUptime Kumaが止まっていたのは、コンテナを入れ替えた短い時間だけです。

今度は「開けないこと」を確認する

設定を変えたあとは、確認です。

普段のシステムテストでは、

「アクセスできた」

が成功です。

今回は逆です。

以前使っていた外部向けのアドレスへブラウザからアクセスします。

開かない。

これが正解です。

3001番ポートへの直接アクセスが外部からできなくなったことを確認します。

続いてSSHトンネルを作ります。

SSHでサーバーへ安全な通信路を作り、その中を通してUptime Kumaへアクセスします。

こちらは、

開く。

これが正解です。

つまり最終確認は、

• 外から直接 → 開けない
• SSH経由 → 開ける

の両方です。

閉じるべき扉が閉まり、

鍵を持っている人だけが別の入口から入れる。

今回の作業は、これで完了です。

HTTPの管理画面を、SSHの暗号化経路の中へ入れた

Uptime Kuma自体をHTTPS化したわけではありません。

ここは少し重要です。

今回の方法では、

HTTPの管理画面を、そのままインターネットへ流さない

ようにしました。

ブラウザからUptime Kumaまでの通信を、SSHの暗号化された経路の中へ通します。

つまり、

「Uptime KumaにSSL証明書を設定した」

のではなく、

「管理画面そのものを外から見えなくし、SSHの内側だけで使う」

方式です。

自分しか使わない管理画面なら、こういう選択肢もあります。

追加費用は0円

今回、新しく契約したサービスはありません。

VPSはすでにあります。

SSH鍵も、サーバー管理用として以前から使っています。

DockerもUptime Kumaも既存環境です。

そのため今回の追加固定費は、

0円。

作業時間は約10分でした。

セキュリティ製品を増やすというより、

今ある構成の公開範囲を狭くした

だけです。

こういう改善は、費用をかけずにできることもあります。

5人の係を抱えるサーバーになったから、守る意味も変わった

第9話でこのVPSを使い始めたとき、仕事はサイト監視だけでした。

その後、

• サイト監視
• ドメイン期限チェック
• 月次稼働率レポート
• リンク切れ巡回
• 補助金締切ウォッチ

と仕事が増えてきました。

最初は、

「月900円弱の遊休サーバーを何かに使おう」

という実験でした。

今は違います。

サイト管理や社内業務に関わる複数の定期処理が、この1台で動いています。

仕組みが増えれば、

止まったときの影響も、触られたときの影響も大きくなる。

だから、仕組みを育てるだけでは足りません。

育った分だけ、守り方も見直す必要があります。

AI社員に「怖くない？」と聞けるのも使い方の一つ

今回面白かったのは、最初からセキュリティ診断を依頼したわけではないことです。

私が聞いたのは、

「この状態って怖くない？」

という、かなり曖昧な質問でした。

そこからAI社員が、

• ログイン画面が公開されている
• HTTP通信である
• 管理画面を公開する必要性が低い
• SSH鍵はすでにある
• ならばlocalhostへ閉じてSSH経由にする

と整理していきました。

AIは、こちらが気づいていない問題を必ず見つけてくれるわけではありません。

でも、

「何となく気になる」を、そのまま投げて整理する

相手としてはかなり使えます。

違和感を持っても、

「まあ動いているし」

で終わらせない。

これもAI社員との仕事の一つになってきました。

セキュリティは「作る」の後にもう一度見る

今回の一番の学びはこれでした。

作った直後に問題がなくても、仕組みが育ったあとにはもう一度見直す。

第9話の時点なら、

「Uptime Kumaへログインできればいい」

ということを優先していました。

そこから通知が増え、係が増え、VPSの役割が大きくなりました。

同じ設定でも、重要度が変わればリスクの見方も変わります。

だから、

• 新しい機能を追加した
• 扱うデータが増えた
• 外部サービスと連携した
• 社内で使う頻度が上がった

というタイミングでは、

「今の守り方のままでいいか」

を改めて確認する。

これを定例業務として考えた方がよさそうです。

今回の結論

今回は、新しいAI社員を増やした話ではありません。

これまで育ててきたVPSの、

「開きっぱなしだった扉を閉めた」

話です。

Uptime Kumaの管理画面を外部公開から外し、

サーバー内部からだけアクセスできる状態へ変更。

必要なときはSSHの暗号化通信を通して開く。

監視データも設定もそのまま。

追加固定費0円。

作業時間約10分。

仕組みを増やすことばかりに目が向きがちですが、

増えた仕組みをどう守るかも、同じくらい大切

だと改めて感じました。

「動いているけれど、これで大丈夫？」はありませんか

ホームページやサーバーは、

動いているからこそ触りにくいものです。

「設定したのは何年も前」

「誰がやったか分からない」

「普通には使えているけれど、安全かどうかは分からない」

という状態も珍しくありません。

問題が起きてから直すより、

違和感を持った段階で一度確認する方が、対応は小さく済みます。

オフィスピコッツでは、ホームページやサーバー、AI・クラウド環境について、現状確認から整理するご相談も承っています。

• AIレスキュー：https://pikoz.net/ai-rescue/
• ネット顧問：https://pikoz.net/komon/
• AI社員実践記：https://pikoz.net/category/ai-jissen/

AI社員実践記は、まだ続きます。