page0004 のバックアップ(No.3)

EssenRev4の先にあるもの

しかし、あるとき私は思いついてしまった。
これだけのセキュリティ技術者が一堂に集まるのなら、セキュリティ人材を養成するよりも、いっそのこと「これを使っている限りセキュリティの問題は絶対に起きないよ」的なプログラミング環境、もしくはライブラリなどを作ればいいのではないか。これだけの人がいればそういう夢のようなものも作れるのではないだろうか。
もしこれが成功したら、セキュリティ人材を大幅に増やさずとも、セキュアなIT環境が整備されていくのではないだろうか。

しかし、そんな夢のようなプログラミング環境は果たして作れるだろうか。そもそもどんな仕様にしたら「絶対」なんて言えるのだろう。・・・すまない、実はそれは私にもよくわかっていない。
これじゃあ非現実的すぎる。夢を見るのは自由だけど、責任のあるIPAやNICTがこんな無責任なものに時間や費用をかけられない。
なるほど、だからやらないのか。

ダメっぽいからIPAやNICTがやろうとしないのはわかった。でもだからと言ってあきらめていいのだろうか。キャンプ全体やSecHack365全体でやるのは非現実的だとしても、その中のごく一部で、細々と試みるくらいはやってみてもいいのではないだろうか。
なんといっても、もし成功すれば一発大逆転すら狙えるほどの試みなのだ。全く試さずに捨ててしまうのはあまりに惜しい。・・・やってダメならそれでよい、きっぱりあきらめられる。やってできちゃったらなおよい。
ということでこの試みをやってみようというのが、EssenRev4の開発思想である。

「絶対」にするためにはどうしたらいいのかは全くわからないけど、でもそんな私にもわかっていることは一つある。それは実行速度が遅すぎると、もはやセキュリティ的にはパーフェクトだとしてもおそらく使う気になれないということだ。
となれば、まず抑えておくべきは高速に実行する仕組みを確立することだ。これを後回しにしてしまうと、速度を出すのが難しい仕様を無意識に採用してしまうかもしれない。それは二度手間だ。
もちろん速度だけ出てもしょうがないのであるが、まずははっきりとわかっているところから進めようってことで。

高速化のオプションとしては、実行時のセキュリティチェックを省略するのがおそらく有効だろうと思われる。しかしそんなことをすれば、せっかくのセキュアな世界に穴をあけてしまうようなものだ。だから大部分ではセキュリティチェックは有効のままにしておくべきだ。そして性能に大きく影響する部分のみ、用心に用心を重ねて、セキュリティチェックを省略させるべきだ。

セキュリティに強いシステムを作りましょうというと、たいていの場合、以下の2系統があると思っています。
- 制約をかけてできることを少なくする、これで危険なことをできないようにする
- 仮想的な環境を与えてその中で自由にやらせる（sandbox）
しかしこれはどちらもよい解決方法ではないと思っています。これらの方法は、悪意あるプログラムから自分を守る方法なのであって、自分が書いたプログラムからセキュリティホールを根絶する方法ではないのです。私はそう考えているのです。
セキュリティホールにせよ、ただのバグにせよ、そのほとんどは「想定の範囲外のことが起きる」ことが原因です。つまりプログラマは自分の書いたプログラムでどんなことが起きうるのか、十分に想定できていないのです。だから十分な対策を取れず、攻撃者にやられてしまうのです。だから自分の書いたプログラムで何が起こりうるのか、それさえきちんと把握できるようになっていれば、制約なんかなくたって、隔離された空間を提供しなくても、セキュリティは達成できるはずなのです。不便さを受け入れる必要なんてないのです。

コメント	お名前	NameLink