グリーCTO藤本氏が明かす、エンジニアリングの観点をマネジメントに生かす具体的な方法：一生、エンジニアで食べていける？（2/2 ページ）

[高橋睦美，＠IT]

運用に入った後の脆弱性対応はどれだけ大変？　シフトレフトが求められる背景

　DevOpsの目的は、継続的にユーザーに価値を提供すること。仮に、開発した成果物に脆弱（ぜいじゃく）性が存在し、セキュリティインシデントが起こるようなことがあれば、その「価値」は大きく損なわれてしまう。

　なるべく脆弱性を起こりにくくするためには、どんなツールや体制作りが必要か――パネルディスカッション「セキュアな開発と運用サイクルDevSecOpsの舞台裏〜明日の開発を確かなものにする人・技術・カルチャーとは」では、アスタリスク・リサーチの岡田良太郎氏が司会を務める形で、サイボウズの伊藤彰嗣氏とフューチャーアーキテクトの神戸康多氏が、それぞれの経験に裏打ちされたノウハウを紹介した。

左からアスタリスク・リサーチ 岡田良太郎氏、フューチャーアーキテクト 神戸康多氏、サイボウズ 伊藤彰嗣氏

　クラウドサービスやツールの普及に伴って、サービス作り、アプリ作りのハードルは大きく下がった。いまや、一から考えなくても簡単に構築できるようになっている。「だがセキュリティに関しては、投資とリスクのバランスが取れていない。ある調査によると、攻撃は95％がアプリレイヤーで成功している一方で、保護のための投資の90％がインフラ周りに投じられている」（岡田氏）

　さらに、運用しながらセキュリティ問題を防ごうとすると大変で、対応コストが大きくかさむ。一方で、設計や実装の段階でセキュリティ対策に配慮するのも、「完全であること」を証明できない以上、バッドストーリーだ。「従って、運用チームと実装側がコミュニケーションすることで、どのようにして運用が苦しんでいる事柄が起きにくい仕組みにするか、どうすればもっとリスクの低いシステムになるか、またそうしたフィードバックを受けられる仕組みにしていくか大事だ。運用からさかのぼってくる実装上の問題を解決し、最適な方法で実現することで、プロジェクトの進行を速める『シフトレフト』が注目されている理由もそこにある」（岡田氏）

シフトレフトについて（岡田氏の講演資料から引用）

オープンソースの脆弱性スキャナー「Vuls」を作った理由

　実際、運用に入ったシステムを修正するのはどれだけ手間がかかるものなのだろうか。オープンソースの脆弱性スキャナー「Vuls」の開発者でもある神戸氏は、100台以上の仮想マシンで、しかもOSの種類もバージョンもばらばらなら、その上で動くデータベースやプログラミング言語もさまざま、ライブラリのバージョンもまちまちというカオスな環境を2年ほど運用していた経験を持つ。

　神戸氏は、Webアプリケーションの脆弱性を突いた不正アクセスの事例を耳にし、「ソフトウェアアップデートが必要だという話になり、実際やってみたらなかなか大変だった」という。

　まず、日々新しい脆弱性をウォッチし続けなくてはならない。多数の情報サイトがある一方で、中には自分にとっては不要な脆弱性情報も含まれる。「加えて、ある脆弱性がどのサーバに影響するかの調査が大変だった。何よりつらかったのは、『クリエイティブ感』がゼロなことだ。膨大な脆弱性情報を調べ、ヤバそうなものがあればパッチを適用するが、手作業である以上漏れがあるのではないかという不安があるし、見える化もされていない」（神戸氏）。そんな憤まんが怒りに変わり、開発したのがVulsだったというわけだ。

「500種類以上のオープンソースソフトウェアを使っている」サイボウズにおける脆弱性の情報収集

　「500種類以上のオープンソースソフトウェアを使っている」サイボウズでは、どのように情報収集を行い、それをどのように運用担当にリリースしていくかが課題となっているという。「特に、難しいのが情報収集。JVNなどの脆弱性データベースに乗っていない脆弱性もけっこうある。先日脆弱性が公表されたApache Struts 2に限らず、常にひやひやしている」（伊藤氏）

　脆弱性対応を効率的に、確実に実施するため、できるところから自動化に取り組みつつ、プロセスも整えている。CSIRTとPSIRT（Product Security Incident Response Team）で情報収集し、1カ所に集め、どの脆弱性がどんなものか、攻撃が出回っているかといった幾つかの指標を基にディスカッションしている。また権限を明確化し、一定水準以上の脆弱性が見つかった場合には、サービスを緊急停止する権限を運用本部長が持っている。逆に、それほど緊急性の高くない脆弱性については、定期メンテナンスの際に対応する形で、なるべく顧客に迷惑をかけないようにしているそうだ。

　またサイボウズでは、自社プロダクトに存在する脆弱性対応についても、プロセスを定めている。「何か1つ、やり方を決めておくことが、素早く対応する上では大事。何か問題が見つかったら、その都度体制を作り、対応するのでは大変だ。ハンドリングフローを定め、組織全体に浸透させていくことが重要だ」（伊藤氏）

運用側と実装側がともにテーブルに着くべき理由

　では、セキュアな開発を実現するための開発と運用の距離感はどのようなものだろうか。

　サイボウズの場合、上から下まで全て自社で面倒を見るという体制も寄与しているだろうが、さまざまなサービスにまたがる組織横断的な開発基盤の改善を通じて、CI/CD環境の整備や自動テストのためのインフラを構築。その上で、開発と運用が一体となる体制作りを進めており、運用チームが開発のインプットになっている。例えば障害が起きれば、グループウェアを通じて情報を共有し、開発サイドが運用に近いレベルでログの内容を確認できるようにするなどの環境を整えてきた。「開発者が、自分で運用する視点を持つことはとても重要」（伊藤氏）

　今度始まる実験的なプロジェクトでは、開発者が一度、運用チームのやり方に従って運用を担ってみた上で、「運用しやすい開発とは、どのようなものか」を考える取り組みを行っている。3年目に入る脆弱性報奨金制度でも、寄せられた脆弱性情報を開発へのインプットとし、他のプロジェクトで同様の問題を起こさないようにする仕組みができ始めているそうだ。

　一方フューチャーアーキテクトの場合は、いわゆる「匠」が作ったフレームワークがかなり充実しており、それを使うためのトレーニングも実施している。このため、一般の開発者は生でJDBCを書かなくて済むし、コードレビューもその分シンプルになっているという。

　この説明を受けて岡田氏は、「脆弱性を減らそうと考えるならば、実装があちらこちらにとっ散らかっている状態はよくない。セキュリティ実装を集中させ、あとは運用チームがそれをすり抜けてくるものを観測し、そのスタックだけを修正する仕組みにすれば、互換性を維持しつつシステムの堅牢性を高められる。OWASPもそうしたアプローチを推奨している」とコメント。もちろん、セキュリティ実装を集中化するのは余分な仕事に見えるかもしれないが、「しかしそれを実現したメリットは計り知れない」（伊藤氏）

　「メンテナンス性やコードの信頼性といった視点から言うと、開発標準、少なくともモジュールの標準化をしていかなければいけないのではないか。その上で、『セキュアなものを作る』のは不可能なことではない。これまで地道にやってきた人から得られる知見はたくさんある。また、シフトレフトやDevSecOpsを実現しようと思ったら、要件を決める人、設計する人、運用する人、全ての人が同じテーブルで一緒に仕事をしていかないと実現できない。最初はうまくいかなくても、より良いものづくりに向けて協力していくことが重要だ」（岡田氏）