筆者は、日ごろから各種オペレーションで発生するすべてのログを記録し保管するよう設定している。システムを構築する際には、いくつかのリポジトリを自分で構築しており、必要に応じてスクリプトを流し込むことで、極力自力でシステムの最適化や構成をしないで済むよう対策を取っている。
そうした一連の中で取得した膨大なログを元に解析した結果、多くの仮想サーバーに横たわるセキュリティ上の問題点を発見した。クラウドを利用するユーザーに共通する問題であるため、その現状を報告し、対応策を提案する。
同一のsshホストキーが流用されている
VPS（仮想専用サーバ）やクラウドシステムを利用する場合、その実装方法には大きく二つのやり方がある。ユーザーが自らisoイメージをアップして0からシステムを構築するケースと、クラウド業者によってあらかじめOSや最低限のサービスがインストールされており、必要に応じていくつかのコンポーネントを組み合わせて実装するケースだ。
前者の場合、システム構築の過程を含めてすべての責任はユーザー自身に起因する。後者の場合、初期状態の責任はクラウド事業者に起因する。この区別を頭に入れたうえで、次の情報を読んで欲しい。
どちらでインストールされた状態でも、まずユーザーが取り掛かるのは、sshの公開鍵をインストールし、リポジトリとクラウドとの間で一種のVPN（仮想閉域網）を張ること。この結果、安全かつ確実にクラウドのシステムをカスタマイズできるようになる。
このときのログを確認してみたところ、クラウド側に含まれているサービスが過去の古いバージョンであり、脆弱性が多数存在するバージョンがインストールされている場合が多いことが明らかになった。
このため、ユーザーはリポジトリを介して最新のバージョンをデプロイする。本来なら、こうした最新版のサービスはクラウド事業者があらかじめ提供しておくべきものと考える。
次にsshの接続記録をを確認したところ、sshのホストキーと呼ばれるものに偏りが見られることが判明した。クラウド事業者があらかじめ用意しているコンテナに、ある程度まで構築が終わったイメージが組み込まれており、その中にインストールされているsshのホストキーが同一のものになっているようだ。おそらくマスターイメージとして構築されたサーバーがクローニングされていく過程で、ホストキーが同一になったとものと推測される。
sshホストキーがほかのユーザーと同じ場合、いくつかの問題を引き起こす可能性がある。公開鍵方式を採用していない場合、事前に設定されたアカウント情報を元に、他人の仮想サーバーにログインすることも可能になってしまう（図1）。
