EGセキュアソリューションズ 取締役 CTOで独立行政法人情報処理推進機構（IPA）非常勤研究員/技術士（情報工学部門）の徳丸浩氏は、「自社のWebサービス開発におけるセキュリティ推進には課題が多い」と指摘する。保護すべき対象は個人情報からサービス提供側の機能、開発コードやデータまで幅広いうえ、短納期やコストカット、関係先の拡大といった環境にも対応する必要がある。認証システムや開発・運用環境についてもセキュリティ強化は必須だ。こうした環境の中で、開発者やセキュリティ担当者はどのように考えていくべきなのか。
-
Webサービス開発におけるセキュリティ推進の課題
3月5日～8日に開催された「TECH+フォーラム - セキュリティ 2024 Mar. 『推奨』と事例に学ぶ事前対策」に同氏が登壇。自社サービスを開発するにあたり、脆弱性に迅速に対応するために必要なことについて解説した。
「TECH+フォーラム - セキュリティ 2024 Mar. 『推奨』と事例に学ぶ事前対策」その他の講演レポートはこちら
脆弱性対応の難しさを浮き彫りにしたLog4Shell
セキュリティの重要性が叫ばれる中で、情報漏えいの事件や事故は一向に減らない。SQLインジェクション攻撃を受けた決済代行事業者からのクレジットカード情報の漏えいや、ランサムウエア攻撃を受けた大手ゲームメーカーからの個人情報の流出など、数多く発生している。その中でも、脆弱性が公開されて大きな問題になったのがLog4Shell（CVE-2021-44228）だ。これはJAVA向けのログ出力ライブラリであるLog4jの脆弱性である。Log4jはアプリケーションやライブラリで広く使われており、Log4ShellはRCE（Remote Code Execution）、つまり外部からリモートでコマンドを実行できるため危険度が高い。多様な攻撃ルートを持っていて、公開されていない内部サーバも攻撃される可能性があるということも騒ぎを大きくした。
「発見から悪用可能コードの公開までが非常に短期間で、実質的にゼロデイ脆弱性に近い状態でした」（徳丸氏）
Log4Shellで内部のサーバを攻撃する手口は以下のようなものだ。ハッカーは、まずLDAPサーバを用意したうえで、メールアドレスにLog4Shellの攻撃文字列を記載して問い合わせをする。メールアドレスが不正なのでエラーとしてログサーバに送られるが、これをLog4jで処理すると攻撃文字列がURLだと判定され、そのURL宛に問い合わせが行われる。その応答としてハッカーのLDAPサーバが不正なJAVAのクラスファイルを返すことで、マルウエアが実行されるのだ。
-
Log4Shellの攻撃イメージ
迅速な対応のために重要なDevSecOps、SDLC、シフトレフト
Log4Shellによって、公開されていないサーバでも攻撃を受けることが分かり、脆弱性対応の難しさが改めて浮き彫りになったと言える。特にLog4Shellの場合は実質ゼロデイであるため対応が難しいうえ、Log4jはさまざまなところで使われている。アプリケーションが直接使っていなくても、アプリケーションが使うライブラリが内部でLog4jを使うという、依存関係がある場合も多い。さらに、多様な攻撃パターンについて影響を受けるかどうかを、何台ものサーバで全て確認するのは実務上困難だ。バージョンアップやパッチ適用で解決したいところだが、逆にそれで悪影響が出る可能性もある。
「脆弱性への迅速な対応のためにどうすべきかという課題が突きつけられたわけです」（徳丸氏）
そのために重要になるものとして徳丸氏が挙げたのは、DevSecOps、SDLC（Secure Development Life Cycle）、シフトレフトの3つだ。DevSecOpsは、DevOpsにセキュリティ（Sec）を追加したものである。運用フェーズで脆弱性が見つかったらそれを開発に回し、修正、テストまで迅速に行ってデプロイする。その過程で脆弱性診断やバージョンアップ後のテストも自動化することで、迅速な対応が可能になる。SDLCは、開発プロセスの全工程にセキュリティの活動を組み込んだものだ。そしてシフトレフトは、開発プロセスの可能な限り早期にセキュリティ施策を実施することで、アプリケーションのリリースを迅速化しようという考え方である。
