セキュリティ
サーバーではなく「人」が狙われる:管理者を狙う手口と備え
2026年10月8日

レン
SSH鍵、ファイアウォール、更新。全部やった!もう完璧!

ウィルスン
…見事だ。正直、サーバーそのものへの侵入は難しくなった。だからワタシは狙いを変える。キミ自身だ。

レン
ぼく!?

ウィルスン
たとえばこうだ。契約している会社を名乗り、「お支払い情報の確認が必要です」という連絡を送る。本物そっくりのログイン画面を用意しておく。キミがそこにIDとパスワードを入力すれば、どんな堅牢な設定も意味がない。キミ自身が正面から開けてくれるのだからな。

プロクラ
これがフィッシングだよ。技術的にどれだけ守っても、使う人がだまされてしまえば通用しない。しかも管理者を狙えば、一撃で全部を取れる。攻撃側にとって効率が良いんだ。
守りは「重ねる」のが基本
攻撃
ファイアウォール
不要な入口を塞ぐ
SSH鍵認証
総当たりを無効化
OS更新
既知の穴を埋める
サーバー
1つ破られても次の層で止まる。どれか1つでは不十分
サーバーを運用している人が狙われやすい理由
サーバーそのものを破るより、管理している人を騙すほうが早いからです。技術的な守りをどれだけ固めても、本人が鍵を渡してしまえば意味がありません。しかも管理者は権限が強いので、1人騙せば得られるものが大きい。狙う側から見て、費用対効果の良い標的になっています。
- サーバー会社・ドメイン会社・決済など、届く連絡の種類が多い。1通紛れても不自然でない
- 「更新期限が近い」「支払いが失敗した」は本物でも来る内容なので、見分けにくい
- 管理アカウントを1つ取られると、サーバーもドメインも同時に失う
- 公開しているサイトから、運営者の連絡先が分かることがある
だまされないための習慣
- メールやSMSのリンクからログインしない。必ず自分のブックマークか、公式サイトを検索して開く
- 「至急」「今日中に」と急かす連絡ほど疑う。焦らせるのは手口の一部
- ログイン画面のURLを毎回確認する(似せた綴りのドメインが使われる)
- 少しでも変だと思ったら、その会社の公式窓口へ自分から連絡して確認する

プロクラ
1つめが本体だよ。「リンクを踏まない」ではなく「リンクからログインしない」。踏んで内容を読むのは構わない。認証情報を入力する画面だけは、自分で開いたものに限る、と決めておこう。
だまされても助かる備え

プロクラ
人間はいつか必ず引っかかる、という前提で備えておこう。2要素認証を設定しておけば、パスワードを入力してしまっても、その先で止まる可能性が高い。
- 重要な操作の通知メールを有効にしておく(身に覚えのない変更に気づける)
- ログイン履歴を時々確認する
- パスワード管理ツールを使う(登録したドメインでないと自動入力されないため、偽サイトに気づける)
- サーバー会社とドメイン会社では、特に2要素認証を優先して設定する

プロクラ
3つめは地味だけど効くよ。自動入力が出てこない時点で「あれ、このサイト違うかも」と気づける。人間の注意力より、仕組みで気づけるほうが確実なんだ。
2要素認証にも強弱がある

ウィルスン
…2要素認証か。数字を入力する方式なら、ワタシの偽サイトでその数字も一緒に聞けばよい。受け取った数字を、その場で本物へ入れるだけだ。

プロクラ
そこは知っておくべきところだね。数字を入力する方式は、偽サイト経由で中継されると突破されうる。物理的なセキュリティキーは、繋がっているドメインを機械が確認するので、偽サイトでは反応しない。強度に差があるんだ。
- 強い: 物理セキュリティキー、端末に紐づく認証
- 中: アプリで生成する数字(偽サイト経由の中継には弱い)
- 弱い: SMSで届く数字(番号を乗っ取られる手口がある)
- それでも、無いよりは遥かに良い。まず何かを有効にすることが先
焦らせる連絡が来たときの手順
急かす文面が来たら、その時点で疑ってください。「今すぐ対応しないと停止します」は、確認する時間を与えないための定型です。リンクを踏まず、公式サイトを自分で開いて、そこから管理画面に入る。この一手間で、この種の手口はほぼ防げます。

プロクラ
怪しいと思ったときにその場で判断しようとすると、かえって間違える。手順を決めておこう。
- その連絡には返信もクリックもしない
- 自分のブックマークから管理画面を開き、同じ内容の通知が来ているか確認する
- 来ていなければ、その連絡は偽物
- 既に入力してしまったなら、すぐそのサービスのパスワードを変更し、ログイン履歴を確認する

レン
リンクからログインしない。2要素認証は必ず入れる。焦ったら手順に戻る。
VPSの料金を比較する
あわせて読みたい
- セキュリティ事業者から「攻撃の踏み台になっている」と連絡が来たら自分のサーバーが加害側になったときの初動。優先すべき順番と、通信を止めることが最優先である理由、そして復旧までの進め方を解説します。
- セキュリティ使っていないアカウントを残さない使われていないアカウントとSSH鍵が入口になる理由、棚卸しの手順、消すときの副作用、共同作業で鍵を渡すときの決めごとまで解説します。
- セキュリティXSS:投稿された内容が他の人のブラウザで動く被害を受けるのがサーバーではなく訪問者である理由、表示するときに無害化するという原則、投稿でHTMLを許可したい場合の扱い、そして盗まれるものを減らす備えを解説します。
- セキュリティログを別の場所へ送るべきかサーバーの中にしかないログは、消される可能性があります。外へ送る意味と、個人運用でどこまでやるかの判断、簡易な代替手段を解説します。