* EssenRev4におけるセキュリティへの取り組み
-(by [[K]], 2018.03.13)

** (0) 背景
-現在IPAはセキュリティキャンプを実施して、不足しているセキュリティ技術者を増やそうとしている。
-現在NICTはSecHack365を実施して、不足しているセキュリティ技術者を増やそうとしている。
-どちらもすばらしいプロジェクトだと思うし、私も講師の立場で全面的に協力している。

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

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

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

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

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

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

** (5) プログラマがプログラムの動作を正しく理解するために言語がやること
-以下の機能を付けることで、意図していないことが起きていないか常にチェックしてやる。

-ポインタ関係
--ポインタは内部でアクセス可能範囲を持っていて、それをはみ出したらすぐに教えてくれる。
--freeしてしまった領域にアクセスしたら教えてくれる。
--freeしたのにまたfreeしようとしたら教えてくれる。
--mallocするときに、どのスコープを抜けるときまでには解放する予定なのかを指定することを標準とする。これで解放し忘れをなくすことができるはずだ。

-変数の値
--未初期化の変数にアクセスしたら教えてくれる。ただし、「このアクセスでは未初期化でも気にするな」という指示も可能にする。
--変数の値は上限や下限を設定できる。それ以上に複雑なチェックが必要なら、それも記述可能にする(チェック用の関数を設定できる)。この値は偶数しかとらないとか。

-実行域確認
--ここは一度でも通ったのか?みたいなことを確認する手段を提供したい。
--プログラムが長い間無反応になると心配になるが、そんなときは今どこを実行しているか確認できるし、その時の変数の値も確認できる。値が徐々に変化していれば「単に時間がかかっているだけ」なのか「意図しないところで無限ループにはまっている」のか、容易に識別できる。
--プログラムが長い間無反応になると心配になるが、そんなときは今どこを実行しているか確認できたり、その時の変数の値も確認できたりしたら便利だろう。値が徐々に変化していれば「単に時間がかかっているだけ」なのか「意図しないところで無限ループにはまっている」のか、容易に識別できる。

-そのほか
--その他にも思いついたらどんどん追加する。


* こめんと欄
#comment

トップ   編集 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS