AWS移行後もSSHがパスワード認証のまま？初動30分の放置が招く侵害

クラウド移行の直後は、監視やコスト最適化に気を取られがちです。
そのあいだにサーバー自体の初期設定が手つかずになっているケースは珍しくありません。

AWSやDigitalOcean、Hetznerなどでインスタンスを新規作成すると、パブリックIPが割り当たった瞬間から世界中のボットがポートスキャンを始めます。
SSH（サーバーに安全にリモート接続するためのプロトコル）が使う22番ポートは真っ先に狙われる対象です。
OSのデフォルト設定のままだと、数千通りのパスワードを機械的に試す「ブルートフォース攻撃」に晒され続けます。

この記事は、オンプレからクラウドへ移行したあと運用を担当するエンジニアや、SREとして本番サーバーの初期構築を任されている方に向けた内容です。
監視ダッシュボードは整えたのに、OS層のセキュリティ設定が後回しになっていないか確認する材料になれば幸いです。

何が起きるか：見えない侵入経路が放置される

UbuntuやDebian、Rocky Linuxなどのディストリビューションは、初期状態では利便性を優先しています。
つまり、パスワード認証が有効なまま、root（管理者権限を持つ最上位アカウント）でのログインも許可されている構成が標準です。

この状態で本番サーバーを公開すると、侵入者はSSH経由でrootパスワードの総当たり攻撃を仕掛けられます。
さらに厄介なのは、侵入の兆候が監視システムに現れにくい点です。
CPU使用率やレスポンスタイムのようなアプリケーション指標だけを見ていると、認証ログに残る不審なアクセスの急増を見落とします。

影響範囲はSSHだけにとどまりません。
侵入者がroot権限を得れば、アプリケーションのデータベース認証情報や環境変数の読み取り、クラウドAPIキーの窃取まで一気通貫で可能になります。
障害対応の現場で「原因不明のプロセスが動いていた」「知らないユーザーが追加されていた」という事象の多くは、この初期設定の放置が根本原因です。

なぜ起きるか：構成ファイルが分散し見落とされる

原因を段階的に分解すると、まず気づくのはSSHの設定ファイルの構造です。
SSHデーモンの設定は /etc/ssh/sshd_config に加えて、/etc/ssh/sshd_config.d/ 配下の複数ファイルに分散して読み込まれます。
どのファイルが最終的に有効になっているか、CIパイプラインで自動チェックしていない限り気づきにくい構造です。

次に、クラウドのイメージ提供元によって初期設定にばらつきがある点も見落とされがちです。
AWSのAMI（Amazon Machine Image）とオンプレのISOから作ったテンプレートでは、SSHの認証方式やファイアウォールの初期状態が異なることがあります。
オンプレ時代の構築手順書をそのままクラウドに持ち込むと、前提が崩れているのに気づかないまま運用が始まります。

さらに、暗号アルゴリズムの世代交代も原因のひとつです。
古いSSHクライアントとの互換性を保つために、3DESやSHA-1のような脆弱な鍵交換方式が有効なままになっている場合があります。
監視の観点で言えば、こうした設定は稼働率やレイテンシに影響しないため、通常のSLO（サービスレベル目標）監視では検知できません。

自分の環境が該当するか確認する方法

実際に自分のサーバーが危険な状態かどうかは、いくつかのコマンドで確認できます。

まず、パスワード認証が有効になっていないか確認します。

sudo sshd -T | grep -i passwordauthentication
sudo sshd -T | grep -i permitrootlogin

passwordauthentication yes や permitrootlogin yes と表示された場合は、対策が未実施の状態です。
sshd -T は設定ファイルを実際にパースした結果を表示するため、.d/ 配下の分散ファイルも含めて実効値を確認できます。

次に、認証ログを見てブルートフォースの試行がどの程度来ているか確認します。

sudo grep "Failed password" /var/log/auth.log | wc -l

Rocky LinuxやAlmaLinuxでは /var/log/secure が対象になります。
数百〜数千件のカウントが出た場合、すでにスキャンの標的になっている状態です。

使用している暗号アルゴリズムの世代も確認しておきます。

sudo sshd -T | grep -iE "kexalgorithms|ciphers|macs"

出力に diffie-hellman-group1 や 3des-cbc のような古い方式が含まれていれば、鍵交換・暗号方式の更新が必要です。

対策の手順：クラウド移行時に組み込む3層の防御

対策は一度に全部やろうとせず、影響範囲の大きい順に進めます。

1. SSH認証をパスワードから鍵方式へ切り替える

ローカルでEd25519形式の鍵ペアを生成します。

ssh-keygen -t ed25519 -C "[email protected]"
ssh-copy-id -i ~/.ssh/id_ed25519.pub [email protected]

サーバー側で /etc/ssh/sshd_config.d/99-hardening.conf を新規作成し、以下を設定します。

PermitRootLogin no
PasswordAuthentication no
PermitEmptyPasswords no
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowGroups sudo sysadmin

設定変更後は sudo systemctl reload sshd で反映し、必ず別ターミナルで新しい鍵を使った接続を確認してからセッションを閉じます。
接続確認をせずに閉じると、鍵の設定ミスでログインできなくなるリスクがあります。

2. 暗号アルゴリズムを現行世代に固定する

同じ設定ファイルに以下を追記し、古いアルゴリズムのネゴシエーションを無効化します。

KexAlgorithms curve25519-sha256,diffie-hellman-group16-sha512
Ciphers [email protected],[email protected]

3. 監視とアラートに認証イベントを組み込む

ここが運用監視の観点で特に重要です。
SSHの認証失敗ログを、CloudWatch LogsやDatadog、Prometheus + Loki構成などの監視基盤に転送し、一定閾値を超えたらアラートを飛ばす仕組みを作ります。
アプリケーションのメトリクスだけでなく、auth.log や secure ログをログ収集の対象に含めるかどうかが、初動30分の異常を検知できるかの分かれ目になります。

監視ダッシュボードにレイテンシやエラー率だけでなく、SSH認証失敗数のグラフを1枚加えるだけで、初期侵入の兆候を検知できる可能性が大きく変わります。

運用コストの観点では、こうしたハードニング作業自体に追加費用はほぼかかりません。
一方で、侵入を許した場合のインシデント対応コスト（フォレンジック調査、影響範囲の特定、顧客への説明）は、初期設定の数十分の作業とは比較にならない規模になります。

まとめ：移行チェックリストに1行加える

クラウド移行のタスクリストには、ネットワーク設計やコスト試算と並んで「SSH設定の実効値確認」を1項目加えることをおすすめします。

sudo sshd -T で passwordauthentication と permitrootlogin の実効値を確認する
認証ログの失敗件数を確認し、すでにスキャン対象になっていないか把握する
鍵認証への切り替えは別ターミナルでの接続確認を挟んでから完了させる
認証失敗ログを監視基盤に取り込み、アラートの対象に加える

オンプレからの移行であれ、新規のクラウド構築であれ、初期設定のデフォルト値は「攻撃者にとっての初期設定」でもあります。
監視設計を組む段階で、アプリケーション層だけでなくOS層の認証イベントも視野に入れておくことが、障害対応の初動を早める土台になります。