Scribble at 2022-12-12 16:30:57 Last modified: 2022-12-18 16:08:06

丁寧に調べる価値があるのかどうかは分からないが、ウェブ・サーバの脆弱性を診断するオンライン・サービスとかツールは、色々な会社から出回っていて、僕も全く知らない会社とかサービスとかソフトウェアが続々と増えているようだ。昔なら Nessus とか Burp とか定番のツールというものがあったけれど、もう今ではサービスの提供方法もクラウドのサービスが出てきたりしているので、ソフトウェアのラインセンスを購入するなんて面倒で高コストなことは必要なくなってきている。ただ、その代わりにクライアントが手軽に検査できるようにもなったために（しかしその意味が分かってるとは限らないので）、あれこれと質問されたり相談される機会も増えているようだ。

適切にウェブ・サーバの脆弱性を検査するには、検査の対象と検査の主体とについて、双方とも正確に理解しておく必要がある。でないと、検査の結果は信頼性が失われてしまう。ここ最近の事例で言えば、或るサイトに対して脆弱性診断ツールを使って検査したところ、ウェブ・サーバの管理者は正しく設定している内容が、診断ツールからは「設定されていない」と警告されてしまったという。AWS でホストされているという検査対象のウェブサイトを調べてみると、すぐにウェブ・サーバとして二つの IP アドレスが建てられていると分かった。もうこれだけで事情が分かるサーバ・エンジニアも多いとは思うが、このサイトのコンテンツを抱えているウェブ・サーバは AWS の ELB にぶら下がっている EC2 だ。しかも、Elastic IP を使っていないと思われるので、インスタンスを停止させてから再び起動すると pubic IP アドレスは変わってしまう（再起動では変わらない）。このようなサービス仕様を検査する方が知らないままでいると、自分の検査しているサイトの IP アドレスは aaa.aaa.aaa.aaa と bbb.bbb.bbb.bbb であると、最初に調べたときから全く情報を更新せずに、その後のサーバ検査を延々と違うウェブ・サーバに対して実行していることに気づかないという可能性だってあろう。

あるいは、オリジン・サーバをスケールする予定で配備してはいても、いまのところはインスタンスが一つだけしかなくて、先に ELB を二つ前面に展開して負荷分散の対策を張っているというパターンもありえる。これだと、ELB は固定 IP アドレスが１時間ごとに必ず変わるし、固定すらできないので、もうこんなものに対してセキュリティ診断するのは無意味としか言いようがない。オリジン・サーバに Elastic IP を設定して、ここへ監査のリクエストを向けてもらう他にあるまい。