大垣靖男さん，徳丸浩さん対談「ウェブエンジニアに必要なセキュリティスキルとは⁠」⁠

大垣靖男さん，徳丸浩さんのセキュリティスキルについての対談です。司会は小山哲志さんです。まずはじめに小山さんから，この対談の経緯について説明がありました。

「元はお二人のブログでの応酬が細かい方向に行っていて，一般の人には分かり辛い流れになってしまっていた（参考まとめ⁠）⁠。そこで，まずここでお互いの立ち位置の違いを明確にして話し合うことで，一般の方々の知見を深める場としましょう！」というのが今回の趣旨です。

会場は希望者が入りきらずに多くの方がサテライト会場に回るほどの盛況の中，対談がスタートしました。

さっくり双方の主張としては，次のようになります。

• 大垣さん：開発者が考え方を改める必要がある
• 徳丸さん：正しくプログラムを書くことがセキュリティにつながる

ただ，いきなりまとめから入ってしまうと，双方論点がかみ合わず！（リアル討論でも難しかった）という印象でした。

徳丸さんは，「⁠理想としては全開発者がセキュリティ意識を持ち知識を身につけてもらうのが私もいいとは思う」と一部同意しつつ，「⁠だが現実として，意識が高い開発者ばかりではないし，絶望的になる書籍も多い。それらが書店に並び，誤った知識が量産されている現実社会を考えれば，人でなくツールでカバーすべき」と主張しました。それに対して，大垣さんは「開発者が信頼境界線を自分で認知するという基本を抑え，入力バリデーションは必ず設定すべき」と返す，というあまり互いの土俵には乗っからない相撲になってしまいました。

途中から「どうしましょうか」「⁠どうしましょうか」（⁠会場笑い）と，このままでは並行線の様相。話していくうちに「意外とこことここは共通点ですよね？」というポイントを見つけて雰囲気が和らぐという流れになりました。その点を整理しておきます。

• ネットで拾ったコードをそのまま流用したりして，誰でも脆弱性を大量に生み出せてしまう時代である
• Webアプリにおいては，入口出口は決まったパターンが多いので，全体設計までいかなくとも局所的な最適化でカバーできる
• 開発者として一人前になるためにセキュリティ以外にも覚えることがたくさんある
• SQLインジェクションのようなシステムの中の設計対策はどちらにせよ重要である
• WAFは以前はホワイトリストで売ろうとしていたが，ホワイトリストはWebアプリでやるところ（徳丸さんも深く同意⁠）⁠。

今のWAF導入は以前より遥かに有効な対策になっているとの双方の見解でした。 また，これからのセキュリティの話で，徳丸さんが「Webアプリに関しては，各種FWが対応していることで，プログラマが個別対応しなくてもよい方向になっていく（いる⁠）⁠」⁠ というのに対して，大垣さんも「セキュリティを気にせずに，プロダクトを作っていくことができるようになる，というのは当然の流れ」と同じ見解を示していました。「⁠ただ，現実問題として，危険なテキスト処理があまりにも簡単にできるという部分がある」（⁠大垣さん）と，警鐘を鳴らすのは忘れていません。

徳丸さんの「そもそも注意しなければならないのがけしからん」「⁠人間の注意力には限界がある」という言葉が個人的には重かった気がします。

最後に

単なる二項対立ではなく，「⁠開発者が最低限抑えておくべき基礎を，どこのレベルに定めるか」という議論に集約されるように感じました（筆者感想⁠）⁠。これは何が正しいか簡単に答えが出る問題でもないですから，大垣派，徳丸派，両方いていいですし，これからも意見をぶつけあってよりよい解を見つけていけばいいのかと思います。

SQLインジェクションに関しての捉え方など，細かいポイントで有用な専門知識にも踏み込んでいましたので，ぜひ録画を確認してみてください。

@yuya_takeyamaさん「Good Parts of PHP and The UNIX Philosophy⁠」⁠

@yuya_takeyamaさんは，UNIXの哲学を踏まえたよいPHPパーツ作りについて発表しました。

まずは，UNIX哲学とは何なのか！という話から始まります。@yuya_takeyamaさんは，次の事柄を挙げました。

• ひとつのことをうまくやれ
• すべてのプログラムをフィルタに
• 部分の総和は全体よりも大きい

最後が少し難解ですが，大きな機能をつくるよりも小さなものを合わせたほうが，結局は大きいものになるとのことだそうです。

今回のセッションの対象者はライブラリを書く人だそうです。「⁠日々パーツをたくさん作っておいて，いつか使ってくれればいいと思う」と話していました。

哲学を実践すると，思いつく限りの再利用性の高いコード，組み合わせられるコードが書けるようになるそうです。

今回，次のものを取り上げられました。

• STREAM
• ITERATOR
• GENERATOR

STREAMについては，実装の方法として外から見える様相がSTREAMだったりITERATORだったりするよう（一般的なもの）にしていれば，より使いやすいものになるということです。

ITERATORとGENERATORについても説明しましたが、セッションの時間が切れてしまいました。

秋山顕治さん「Webアプリのデプロイ今昔物語⁠」⁠

秋山顕治さんは，Webアプリのデプロイの歴史について発表しました。

アプリケーションを動く状態に持っていくことが，デプロイです。このセッションは4つの時代に区切って説明しました。

レンタルサーバー時代

レンタルサーバーの時代……，つまりPerl5.6やPHP4，Windows2000とかそういう時代は，金銭的にも技術的にも選択肢がありませんでした。デプロイはFTPでアップロードです。

この問題点として，次の事柄を挙げました。

• FTPなのでセキュリティが甘い
• 共通アカウントでコンテンツ管理
• アカウントがわかれば何でもできる

さらに，アプリの肥大化，肥大化するアプリの処理速度を改善しようとする試みが同時に進みましたが，mod-cgi等はレンタルサーバーでは使えないなど，強いストレスでした。

vps時代

Perl5.8やPHP5，Ruby on Railsが初公開された2005年頃になり，CPUやメモリ，HDD以外は自由に設定できるようになりました。通信方式もSSHを使えるようになり，Linuxクライアントからのrsync，コマンドラインからSSHを通してアクセスが一般化しました。

問題点として，「⁠プロセスを永続化したい」「⁠静的ファイルだけは別サーバーにしたい」「⁠Javascriptを難読化したい」といったことが出てきました。対処方法はスクリプトを書くことでしたが，秘伝のタレになってしまいました。

デプロイツールの誕生

そういった事情から，デプロイツールが誕生しました。Capistranoは現在のバージョンは3.2です。

Capistranoの優れているのは「だいたい上手くいく」ことであり，ベストプラクティスが積まれています。deploy taskは空のタスクで，必要に応じて上書きすることでカスタマイズできること。

その結果，デプロイの長い手順が2行にになったり，デプロイに1時間かかっていたのが5分になったりしました。例えば，アプリケーション独自のコマンドを実行したり，php-fpmをリスタートしたりできます。

ただ，それでも問題は存在しています。スケールアウトするのはとても大変です。

PaaS時代

Engine YardやHeroku，Git，Ruby1.9が出てきた，PaaS（Platform as a Service）時代に入ります。この時代は，ホストの管理はサービス事業者任せ，負荷分散は自動，デプロイはgit pushだけ，というようになりました。

ベストプラクティス的なところを強制する流れになったとも言えます。例えば，データーベースアクセス用のパスワードをリポジトリに含めてはいけない，アプリをポータブルにすることを強制する，ログやセッション情報などをアプリから分離させる，などです。

IaaS時代

そしてAWSが出てきました。APIによる操作ができるようになりました。そして，「⁠よいVPSではない」周辺サービスが充実してきました。つまり，サーバを使い捨てできるようになりました。これはサーバの状態を管理しないというパラダイムシフトをもたらしました。

次に挙げたことができるようになり，今のところみんなが幸せな時代になりましたた。

• サーバの内容を変更するのではなく，完成したサーバと現行サーバを切り替える
• できあがったサーバを作成し，切り替える（アプリがポータブルになった結果）

IaaSがよいVPSではないけれど，進化した形であるというのは非常に納得の話でした。