門林 雄基氏によるコラム【バックドアとの戦い(1)】を公開

■バックドアの点検を進めます
　前回はファームウェアの脆弱性についてお話ししました。ファームウェアにバックドアを仕込まれても気付きにくいため、真面目に取り組んだら、対策には数ヶ月かかると思います。一般的な企業でも、ルータ、監視カメラ、プリンタなど、結構な数の機器があり、これらに「出荷時から脆弱性が含まれている」可能性や、「改ざんされてバックドアを仕込まれても気づけない」可能性を考えると、今後も長期間にわたって残るリスクだと言えるでしょう。
　ではファームウェアを「残存リスク」のチェックリストに加えることにして、ここではバックドアの点検を前に進めるとしましょう。
　ほかにバックドアを仕込まれても気付きにくいポイントはないのでしょうか。

■「バックドアの巣」になりうるクラウド
　クラウドは残念ながら、技術の選び方によっては容易に「バックドアの巣」になりうると考えたほうが良いでしょう。例を挙げましょう。

　1. JavaScript のパッケージ管理ツールnpmのセキュリティチームが、
　　バックドア入りパッケージを発見（2018年5月）
　2. バックドア入りDockerイメージが８ヶ月以上にわたって放置され、
　　500万回ダウンロードされる（2018年6月）
　3. Docker APIポートを不用意に開けていたクラウドで、バックドアを
　　仕込まれ、暗号通貨のマイニングを実行される（2018年10月）
　4. 暗号通貨のウォレットのパスフレーズ等を窃取することを目的とした
　　バックドアがnpmのセキュリティチームによって発見される（2019年6月）

　もちろん、うちは JavaScript なんて使ってないよ、と涼しい顔して答えることもできるでしょう。しかし本当でしょうか。マーケティング部門がこっそり、適当なクラウドを使って、インターンに書いてもらったデータ分析のプログラムを動かしていた、なんてことは良くある話です。ちなみにJavaScriptはここ数年、プログラミング言語ランキングで不動の１位です。

　「なぜか今月のクラウド利用料の請求が５００万なんだよ！　助けてよ！」

　別にクラウド事業者のネガティブキャンペーンではなく、本当にあった話です。クラウドにバックドアを仕込まれるとはこういうことなんだな、と衝撃をもって理解されたのではないでしょうか。
　うちはDocker使ってないよ、最新のKubernetesだよ、と得意げに答える人もいるでしょう。しかしKubernetesは実はDockerコンテナをまとめて扱うための技術なので、Docker に問題があれば同様に影響を受けると考えたほうがいいでしょう。

　DockerにしてもJavaScriptにしても、一世を風靡している技術なので頭の痛い問題です。技術の選び方によっては容易に「バックドアの巣」になると申し上げましたが、ポピュラーな技術ゆえに狙われるという側面もあるのでしょう。ではマイナーな技術を使っていれば大丈夫か、というとそうでもないところがセキュリティの難しいところです。
　特にクラウドはオープンソースのライブラリやツール群を使って、手っ取り早く実行環境や開発環境を整えるスタイルが「今風」とされているので、この手の問題がなくなることはないでしょう。みなさんの会社のインターン君や若手エンジニア君がいま使っているコンテナには、ゆうに１００を超えるライブラリが使われています。それぞれにバックドアが仕込まれていないことを保証してくれるのは、誰なのでしょうか？
　もちろん、みなさんの会社のエンジニア諸君はオープンソースのライブラリは「タダ」だと思っているわけで、「タダほど怖いものはない」という諺を真に受けてオープンソースの利用を拒否すれば若手エンジニアから変人扱いされることは間違いないでしょう。もちろん、オープンソースを一切信用しない、という質実剛健な会社さんも一部にはあるのですが。


・・・ここから先は、アクセリア株式会社で公開中のコラム本編でご覧ください。
リンク


【門林 雄基氏のコラム】
・第1回：サイバーセキュリティに求められるバランス感覚リンク
・第2回：サイバーセキュリティが損なわれる原因を理解する(1)リンク
・第3回：サイバーセキュリティが損なわれる原因を理解する(2)リンク
・第4回：サイバーセキュリティが損なわれる原因を理解する(3)リンク
・第5回：サイバーセキュリティが損なわれる原因を理解する(4)リンク
・第6回：サイバーセキュリティが損なわれる原因を理解する(5)リンク
・第7回：サイバーセキュリティが損なわれる原因を理解する(6)リンク
・第8回：通信プロトコルの脆弱性(1)リンク
・第9回：通信プロトコルの脆弱性(2)リンク
・第10回：通信プロトコルの脆弱性(3)リンク
・第11回：ハードウェアの脆弱性(1)リンク
・第12回：ハードウェアの脆弱性(2)リンク
・第13回：ハードウェアの脆弱性(3)リンク