ブログ

Javaで非常によく使われているライブラリであるlog4jにセキュリティホールが見つかりました。
詳細は、こちらに記されています。
弊社で使っているJavaプログラムでも影響がある事は事実です。

弊社では、Javaを直接利用者からの入力情報を受け付けるような場所で使う事はないので、影響は小さいと言えます。
しかし、セキュリティホールとは、そのような確率が限りなく低いという理由でも大きな問題になってしまうことも事実です。
（弊社で問題となる使われ方をしている場合には、個別に連絡して対策を行う・または行っていますので、その点はご了承ください。）

一方、このセキュリティホールの影響の大きさを見て、少々、Javaの使われ方が昔とは変わったなとは思いました。
以前（外部APIで接続するようなことがない時代）は、以下のような構成が多く、Javaが動くようなレイヤーは、「サービスの実行」と書いた部分でした。
ここで何かおかしな脆弱性があっても、外部のサービスに接続する事はネットワークの制限上できませんでした。
出来ても、限定した接続先で明示的に接続できる先を指定していたりします。
（弊社でも外部に接続する必要がないときは、未だにこういう構成にしてしまいます。）

そのため、今回のようなセキュリティホールがあった場合にも、外部に接続できないのでエラー等で終わるという事になります。
また、実行されるプログラムは再度、外部に接続して攻撃元として機能してしまうということが多いです。

そうなると、外部に接続できなければ、一部機能を仮に乗っ取られてもそのような問題までは発展しないという事です。
また、AWSでもVPS（他のクラウドサービスでも同様な機能）で簡単に上記のような構成は可能ですが、出来るだけサーバ数を少なくして、シンプルな構成にしたいという声がある事も事実です。
そして、そういったコストの問題ではなく、現在は、外部APIに接続すること自体が当たり前になってしまうような事が多々あります。
そうなると、限定接続を管理する事すら困難な場合も生じてきてしまいます。
（特に、URLを入力するとコンテンツを取得してサマリーを表示するような、今はSNSでよくある機能がほしいと言われると、もう限定できません）

このセキュリティホールが生まれた最初のバージョンが2013年という事ですので、ちょうど、自分もクラウドで外部に依存することが当たり前になってきた時期とかぶるようにも思います。問題を知ると、どうしてそんな危険な機能が存在するんだという声も聞こえます。
今回の件が当てはまるかは分かりませんが、当時のライブラリ開発者が、自分達の思い描いた環境下ではない環境で使われてしまったという事もあるのかなと感じました。