ビッグデータツールチェインのセキュリティはビッグリスク、あるいは、誰もHadoopをスクラッチからビルドする方法を知らない件について
The sad state of sysadmin in the age of containers
コンテナー時代のシステム管理者の惨状
システム管理は惨劇に見舞われている。現状は悲惨だ。
筆者は昔気質のシステム管理者に不満はない。システムの稼働を維持し、アップデートし、アップグレードする方法を知っている者達だ。
この憤りは、コンテナーと構築済みVMと、それらがもたらす、「信頼」や「アップグレード」の欠如による悲惨な惨劇に対するものだ。
例えば、Hadoopを見てみろ。誰もHadoopをスクラッチからビルドする方法を知っているようには見えないぞ。依存性とバージョンとビルドツールが悲惨なほどに絡まりあっている。
この手のイケてるツールの中で、古典的なmakeコマンドでビルドできるものは存在しない。すべてのツールが独自の互換性も移植性もない、「今朝俺が考えた方法」でビルドされている。
そして、誰もスクラッチからコンパイルできる者がいないので、皆、コンパイル済みのバイナリをどっか適当なWebサイトから落としている。たいていは、何らの認証や署名もなしにだ。
NSAとマルウェア作成者にとっては天国だろうよ。もはやセキュリティホールを突く必要などないのだ。単にappとかVMとかDockerのイメージを作成して、悪意あるバイナリを読みこませればいいのだ。
DebianのHadoopのWikiページが典型的な例だ。要するに、Debianの連中は、2010年には、Debian上でHadoopをソースからビルドして便利なパッケージを提供するのを諦めたってわけだ。
Apache Bigtopをビルドするには、まずpuppet3なるものをインストールしなければならない。こいつはインターネット上から不可思議な謎のデータをダウンロードする。そして、sudo puppetしてNSAのバックドアを有効にしようとする（たとえば、こいつは時代遅れのビルド済みJDKをダウンロードしてインストールする。なぜならば、利用者は自力でJavaのインストールができないほどのマヌケだと考えているからだ）。そして、gradleのビルドが200行もの役に立たないバックトレースを吐き出さないかどうか祈るのだ。
私はふざけているのではない。こいつは以下のようなコマンドを実行しようとしやがる。
/bin/bash -c "wget http://www.scala-lang.org/files/archive/scala-2.10.3.deb ; dpkg -x ./scala-2.10.3.deb /"訳注：暗号化されていない、いくらでも途中の経路で差し替え可能な脆弱なHTTPプロトコルを使いコンパイル済みのバイナリをダウンロードして、単に展開する。
これが、パッケージを正しくインストールすらしていないことに注意されたい。単にルートディレクトリに展開するだけなのだ。このダウンロードは署名を一切確認していないし、SSL証明書すら確認していない。（ソース：bigtop/scala.pp at master · apache/bigtop）
たとえ、ビルドが正しく動いたにせよだ、まだMavenが未署名のバイナリコードをインターネット上からダウンロードして、そいつをビルドに使いやがる。
クリーンでモジュール化されたアーキテクチャにしないどころではない。最近はどこでもそびえ立つクソのような相互依存性のデッドロックに陥る。前回筆者が調べたところでは、Hadoop classpathはすでにjarファイル100を超えていた。筆者はHBaseGiraphFlumeCrunchPigHiveMahoutSolrSparkElasticsearch（あるいは似たようなApacheのカオスなもの）を使わずに、今では150個ぐらいにはなっている方に賭けてもよい。
スタックとは、「俺は自分が何やってるか全然わかんねー」という意味の新しい言葉だ。
Maven, ivy, sbtは、システムに未署名のバイナリをインターネットからダウンロードし、自分のコンピューターで実行させるためのツールだ。
そしてコンテナーが、この惨状をさらに悲惨にする。
お前ら、コンテナー内でセキュリティアップデートしたことがあるか？
要するに、Dockerの手法とは、未署名のバイナリをダウンロードして、実行して、かつまたそれが会社のネットワークに何らのバックドアをも仕込まないことを祈るためのツールなのだ。
90年代のWindowsのシェアウェア時代に逆戻りしたようだぞ。
さて、Ask toolbarを含むDockerイメージが最初に公開されるのはいつだろうな。Dockerイメージ経由で広がるインターネットワームが最初に流行るのはいつだろうな。
かつて、Linuxディストリビューションは安全なオペレーティングシステムを提供しようとしてた。署名されたパッケージと、Web上の信頼とでだ。バイナリ一致の再現性のあるビルドを試みているところまである。
だが、全てが急にWindows化されてしまいやがった。セキュリティを気にせず、アプリケーションを次のバージョンにアップグレードすることも考えずに、ダウンロードして実行する「アプリ」なるものが氾濫している。「手間と時間の節約」という名目で。
追記：筆者は、これがDocker以前にも行われていたと指摘を受けた。「Dockerとは新しい'curl | sudo bash'である」と。その通りだ。しかし、もはや「データセンター」で信頼できないソフトウェアをダウンロードして実行するのが主流になってしまった。これはまずいことだ。極めてまずい。かつて、システム管理者はセキュリティホールを防ぐことに力を注いでいた。今では、自らdevopsと称し、ネットワーク上に先を争って進出している。
Debianですら2010年にHadoopのソースからビルドしてパッケージ化をあきらめているとは悲惨だ。
続き
Your big data toolchain is a big security risk!
ビッグデータはセキュリテイにとってビッグリスク
この記事は、先の記事、コンテナー時代のシステム管理者の惨状を受けての追記である。この記事を編集している間に、HackerNews, Reddit, Twitterで取り上げられ、多くのコメントやメールが筆者のもとに届いた。驚くべきことに、多くのコメントは、私の意見を支持するものであった。筆者はもっと多くの、「お前は俺のお気に入りのツールが嫌いだからそういうことを言っているのだ」という文句が寄せられるものだと思っていたのだ。しかし、多くの人が筆者と同じ懸念を抱いているようだ。驚いた。
訳注: The sad state of sysadmin in the age of containers | Hacker News, Your big data toolchain is a big security risk | Hacker News
さて、以下が新しい文句記事だ。ビッグデータを別の側面から切り込んでいる。
最近、みんな「ビッグデータ」とやらをやっているようだ。いや、少なくとも、上司にビッグデータをやっていると見せかけているようだ。大抵の場合、そんなにビッグなデータはない。データ解析を以前より行うようになったというだけの話で、そういうことに「ビッグデータ」の名札を貼り付けて宣伝して、上司から承認をこぎつけようとしている。そんなところだろうか。
「ビッグデータ」とは技術用語ではない。ビジネス用語だ。以前ならば使わなかったデータを解析することによって、ビジネス上の何らかの価値を得ようとすることだ。この視点から考えると、そのようなプロジェクトの多くは、確かに「ビッグデータ」と言える。というのも、「データによる利益の創出」プロジェクトだからだ。容量(Volume)とかその他のVを期待する人たちには不満かもしれないが、まあ、この言葉の使われ方はこんなところだ。
しかし、データ容量と複雑度により新たなオモチャツールを必要とする場合においても、重大な問題が見過ごされているようだ。システムとデータのセキュリティである。
現在使われている、「ビッグ データ テクノロジー スタック」なるものは、セキュア以外の点についてはうまくやっている。まあ独自のHadoop(独自のHadoopディストリビューション)ケルベロス認証で共用型サーバーを売りつけて儲けようとする会社もあるにはあるが。
セキュリティの問題は「スタック」の奥底にまである。これは、その環境にも影響されている。流行のツールを追いかける種類の人間を取り巻く環境だ。多くのプロジェクトでは、システム管理者も務めるLinux開発者というものがもはやいなくなり、かわりに、Apple信者が占めている。この種類の人間は半年後に技術が時代遅れになるような世界に生きているので、プロダクトをそれ以上延命させる必要はないのだ。この種類の人間は開発環境を頻繁に再インストールすることを好む。なぜならば、毎回、何かが変わるからだ。この種類の人間はまた、コンピューターが壊れたら新しい型番を買い直す世界に生きている。（これはビッグデータプロジェクトではうまく行かないことに注意されたい。半年おきにスクラッチから出発するだと・・・）。さて、Macユーザーは長年様々な脅威から影響を受けずにいられたが（そして気にしていなかった。GoToFailとかrootpipe exploitを修正するのに失敗したとか）、Macというオペレーティングシステムはとてもセキュアではない。セキュリティを気にかけないユーザーと組み合わせると、爆発しそうだ。
この種類の開発者は、スタートアップ向けのWebサイトのプロトタイプを短時間で立ち上げたり、毎日新機能をローリングリリースしてユーザーにベータテストさせたりして、ドットコム2.0バブルを維持するのには優れている。また、主要なプロダクトのターゲットとする客層もこの種類のユーザーだ。この種類の人間は半年前のことはさっさと忘れ去り、次の技術プロダクトを心待ちにしていて、発売直後に購入する者達である。
この態度は、スタックという、パッケージがビルドされ、アップグレード（安全なアップグレード）される際に、根本的に問題になる。誰も整合性とか再現性に気を払わないのだ。
このブログにコメントしたある者によると、これらのツールはすべて、「二十歳そこそこのガキによって書かれたようだ」。おそらく正しい。もし、マサカリかついだ経験豊富なシステム管理者が近くに板ならば、ここまでひどくなることはないだろう。どうやってシステムを構築し、10年間保守し、セキュアかつ自動的にデプロイするかという経験がある者は、puppetハックとwgetとunzipと未署名のバイナリコードなど決して信頼しない。
このことを聞きたがる人はあまり多くいないだろうが、
お前のHadoopシステムは多数のみ署名のバイナリコードが至るところで使われている。ダウンロード、アップロード、再ダウンロードを際限なく繰り返した結果だ。その.jarが皆が考えるものと同じである保証はどこにもないのだぞ。
Hadoopは依存性の塊だ。そのほとんどが、セキュリティ目的でまともに調査されたことがない。そもそも、調査されたコードからビルドされたバイナリであるかどうかのチェックができるようすらなっていないのだ。
もしかすると隠し機能が潜んでいて、"yourcompany.com"のようなホスト名のシステムを待っていて、コマンドを監視し、会社の重要なデータを盗むかもしれないぞ。そういう風に組まれたシステムは、どうせファイヤーウォールもこの手の対策のために十分に強固に設定されていないだろう。ソフトウェアはどこかと勝手と通信していても、いわゆるDevOps達には気づきっこないのだ（そもそもこの種類の人間は気にしないのだ。）
最近の「ビッグデータスタック」の精神は、90年代のWindowsシェアウェア時代と同じものだ。インターネットのどこかから適当なバイナリをダウンロードして、セキュリティのためにチェックもせず（Hadoopクラスターにアンチマルウェアかけたって話を聞いたことがあるか？）、どこにでもインストールし散らかすのだ。
なお悪いことに、インストールしたものと、インストール方法とを、管理していない。なぜならば、ツールは毎年変わるからだ。しかし、もし開発者が去ったらどうするのだ。もう二度と実行できる状態に戻せないぞ。
一度実行して忘れ去る(fire and forget)
筆者は、この先5年以内に、多くの会社で数多くのセキュリティ上の問題が起こると予想する。これは産業スパイ天国だ。多くの企業は隠し通すだろうが、一部はマスコミに流出して、この適当なコンポーネントをひっつけはっつけするヒプスター的手法は非難されるだろう。今、巨大な「Hadoopバブル」が膨れ上がっていて、いずれははじけるだろう。
信頼できる状態にするには、ビッグデータツールチャインは以下をマモならければならない。
濃縮
作業に使うツールが多すぎる。多すぎるツールを管理するツールも多すぎる上に、フロントエンドのフロントエンドすら多すぎる。
軽量化
あらゆるプロジェクトが、あまりにも大量の他のプロジェクトに依存しているが、その殆どは、極めて些細で特殊な使い方しかされていない。依存性を解消すべきだ。
モジュール化
依存性を解消できないが、個々の機能は小さいのであれば、それはユーザーが必要なときにだけインストールすればよいオプショナルな拡張モジュールとするべきだ。
ビルド可能性
MavenとかlvyとかSBTでバックグラウンドで自動的に何かをダウンロードしなくても、誰でもスクラッチからビルドできるようにするべきだ。オフラインで、クリーンなビルドディレクトリで、ビルドを検証して、ドキュメント化せよ。バグ修正が正しく適用されているかどうかを確かめられるためにも、すべてはどんなシステム管理者でも再現性のある方法でビルドできるようにすべきだ。
配布
CDNからのバイナリのダウンロードを唯一の配布方法にすべきではない。既存の信頼できるLinuxディストリビューションなどの、別の方法での配布も推奨すべきだ。
互換性の維持
成功するビッグデータのプロジェクトは、一度だけやって終わりというものではない。いずれ、商業化され、何年も動かす必要が出てくる。環境を新しい、より巨大なクラスターに移行する必要が絶対に生ずる。以降に際してデータを失うことはあってはならない。
署名
コードには署名が必要だ。議論の余地なし。
検証
ダウンロードには、ダウンロードされたファイルがアップロードされたものと一致するかという検証が必要だ。
統合
Linuxシステムがサーバー用途にとても優れているのは、万能のソフトウェアの統合管理があるからだ。システムをアップデートしたならばアップデートされる。アップデートには用途に応じたチャンネルがある。例えば、保守的な"stable/LTS"チャンネル、基本的なQAを受けた最新版が入手できるチャンネル、QAをするための最新版が入手できるチャンネル、システムで使うほぼすべてのソフトウェアはこれによって管理される. カーネルに対するセキュリティフィクスであろうと、Webサーバー、ライブラリ、追加機能、拡張モジュール、スクリプト言語などなど。修正を引っ張ってきてすぐにアップデートする。
さて、読者の中には、HortonworksやClouderaやBigtopなどは、すでにパッケージを提供していると反論するものもいるだろう。それは・・・クソだ。連中が「パッケージ」と称するものは、あらゆる品質の標準を下回るものだ。技術的に、ヴァルトブルクは車である。しかし、現在の安全基準を満たすものではない。
たとえば、連中がサポートしているのはUbuntu 12.04だけである。3年も前の古代のUbuntuが、奴らがサポートしている最新版なのだ。それだけではない。この手のパッケージはだいたい同じだ。Clouderaは管理を「コミュニティ」に丸投げした（要するに、自分たちでやることを諦めたのだ。そして、誰かが尻拭いをしてくれることを期待している）。HortonworksとHDP(あとたぶんPivotal HD)も、同じように丸投げした労力を使っている。連中がやっていることといえば、追加のドキュメントを提供したり、最小の労力でBigtopを使ってパッケージをビルドする方法を教育して利しているだけだ。例えば、bigtopの"spark" .debパッケージは空っぽだ。パッケージに.jarSを入れ忘れているのだ。パッケージングがクソであるという例をこれ以上挙げる必要があるだろうか。bigtopのパッケージはすべて、たったひとつのスクリプトのためだけに、独自のgroovyに依存している。そのたった一つの問題のスクリプトをすでに必須な別の言語で書きなおしたり、ディストリビューションが提供するgroovy対応に書きなおしたりせずに、奴らはbigtop-groovyというパッケージを新たに作ったわけだ。
HortonworksとIBMは「オープン データ プラットフォーム」とやらを発表したのを読んだが、筆者には全く関心がなかった。筆者の知る限り、連中は既存のツールに新しい名前をつけただけのことだ。そういうわけで、ClouderaとMapRがこのブランド改名運動に参加しなかったのは、全然驚きでもない。Hadoopはほぼ似通っているのに、なんでそんな名前が必要なんだ？
さて、なぜこれが問題になるのか。もし、何かが動かなかった時、現時点ではどうしようもなくなるのだ。例えば、Hadoopにバグがあってデータを処理するのに失敗したとする。するともうお手上げだ。それ以上データは処理できない。完全に受け身だ。誰が直すのだ？ 巷の「ディストリビューション」と称するものはすべて、同じ、クソみたいな出所から始まっている。この世に問題を把握して修正し、ツールチェインを完全にビルドできる人間は、数十人もいないだろう。明らかに、Hadoop会社はどこもかしこも、Ubuntu 2012.04以降をサポートできていない。これで連中が自分で売っているものを理解していると言えるのだろうか。疑わしいものだ。巷のフリーランスの連中は、皆Hadoopをダウンロードして使う方法は知っている。しかし、果たしてツールチェインの中の業務上深刻なバグを修正して、もう一度実行することができるだろうか。これはLinuxディストリビューションに比べて極めて悲惨だ。Linuxにはビルドデーモンがある。すべてのソフトウェアがコンパイル可能かどうかを検証するサーバーだ。典型的なLinuxのパッケージをスクラッチからビルドするには、大抵、二行のよく知られた有名なコマンドを打つだけですむ。経験ある開発者は誰でもマニュアルを読んで、パッケージを修正できる。別のコンパイラーでディストリビューション全体をコンパイルしようと試みている者達さえいる。これによって将来発生するかもしれない互換性の問題を早期に発見できる。
つまり、連中が販売している「Hadoopディストリビューション」なるものは、奴ら自らコンパイルしたものではないのだ。大半はインターネットのどこからか落としてきた未署名で未暗号化で未検証の.jarファイルだ。奴らはどうやってリビルドすればいいのか分かってないし、誰がコンパイルしたのかも分かってないし、どうやってビルドすればいいのかも分かってない。奴らがわかっているのは、最後のレイヤーだけだ。連中はHadoop .jarをコンパイルする方法を知っている。しかし、それをするには、自動的に大量のバイナリをどこからか自動的に落としてくるときたものだ。ツールは自動的なバイナリのダウンロードを警告しない。連中はそれをHadoopディストリビューションに含めている。
現状では、筆者は業務上のデータをHadoopに食わせることを推奨しない。
おそらく、データをHDFSにコピーして遊ぶのは大丈夫だろう。クラスターと開発機を強固なファイヤーウォールで隔離すればの話だ。だが、すｙべてを失って最初からやり直しになる覚悟はしておけ。まだ、実用化には程遠い上に、更に不要なゴミを積み重ねているので、更に実用化は遠い。
ツールチェインの未熟についてもう一つ例をあげよう。
scala-lang.orgのscalaパッケージは、UbuntuとDebianに存在する古いscalaパッケージからクリーンにアップグレードできない（どうも、ディストリビューションは、クソみたいな鶏と卵問題を抱えるビルドプロセスのせいで、新しいScalaをコンパイルするのを諦めたようだ。scalaとsbtをブートストラップするのはかなりやっつけハックになる）。上流のパッケージすら、簡単に修正できない。なぜならば、標準のパッケージツールでビルドされておらず、自動的で摩訶不思議で重要な機能を欠くsbtヘルパー（特に、Replaces:フィールドや、cleaner:にすらアクセスできないからだ。パッケージを適切にコンポーネントに分割するための機能）を使っているからだ。どうやら、UbuntuやDebianのパッケージングの経験が一切ないどこかの馬の骨が書いたらしく、すでに実績あるツールを使わず、自前でやっつけハックを使って自動化を試みる間違ったラッパーになっている。
筆者は、いわゆる「ビッグデータ」プロジェクトなるものの大半は、悲惨な失敗を喫することになるだろうと思う。その原因は管理過剰か管理過少か、データやツールやプロジェクト管理の経験不足だろうが、もちろん、当然のことながら、誰も失敗を認めようとはしないだろう。プロジェクトはすべて、政治的なプロジェクトなのだから、絶対に成功しなければならないのだ。たとえ商業化に結びつかず、一ドルも利益を生み出さなかったとしても。
思うに、機械学習をしている連中というのは、システム管理者でもプログラマーでもないのだ。彼らは目的の計算をするためにコンピューターを使っているだけの利用者である。たしかに、コードは書くものの、プログラマーではないし、自称もしない。