週刊アスキー

  • Facebookアイコン
  • Twitterアイコン
  • RSSフィード

バグ報奨金プログラム参加をベンダー契約項目に設定

Dropboxが考えるクラウドサービスのセキュリティ施策

2019年08月23日 07時00分更新

 クラウドサービス事業者にとって、プラットフォームとデータのセキュリティ強化は重要課題の1つである。特に昨今はDevOpsの採用が進み、機能の開発からリリースまでのタイムスパンが短縮され、設計・開発時はもちろんのこと、リリース後もバグが発見されれば迅速に修正し、サードパーティ製品との統合やAPI連携で顕在化する新たなリスクにもつねに目を光らせるなど、これまで以上のスピードと品質が要求される。

 そんな課題に対して、「バグバウンティプログラム(脆弱性報奨金制度)」と「DevSecOps」を取り入れた継続的なセキュリティ施策を実施する企業がある。それが、クラウドストレージサービス大手のDropboxだ。Dropboxでセキュリティ責任者を努めるラジャン・カプール氏に聞いた。

Dropbox、Director of Security、ラジャン・カプール(Rajan Kapoor)氏

バグバウンティを契約項目に盛り込む理由

 バグバウンティプログラムは、外部のセキュリティリサーチャーなどが製品のバグや脆弱性を発見、報告した際に、深刻度などに応じて報奨金や景品などを贈呈する制度のこと。開催側は外部の知見や視点を取り入れることができ、製品/ソリューションの安全性と品質の向上に役立てることができる。

 Dropboxは、2014年に自社のバグバウンティプログラムを開始している。以降、報告者との円滑なやり取り、バグ再現など調査・検証体制の確立、報奨金の決定および振り込みまでのタイムラグの短縮、多大な貢献をしてくれたリサーチャーに対するVIPプログラムの開設(リリース前に先駆けて機能を検証可能)、リサーチに対する法的訴訟を起こさないことや、修正完了後にリサーチャーがカンファレンスで発表することを決して妨げないことへの盟約など、セキュリティコミュニティと健全かつ良好な関係を構築し、ともに安心・安全なサービスを目指すための改善を行なってきた。同社の方針はGithubにて、「Vulnerability Disclosure Policy」として公開されている(https://github.com/dropbox/vsmc)。

 このバグバウンティプログラムへの参加を、Dropboxではサードパーティベンダーとの契約項目に盛り込んでいる。同プログラムを通じてサードパーティのプログラム関連のバグ/脆弱性が報告された場合は、Dropboxが報奨金を負担。バグ修正時も支援や協力を惜しまない。

 「サードパーティとの契約では、セキュリティ対策チェックシートを使ってセキュリティ対策の要求事項への遵守をお願いするのが一般的で、弊社でも行っています。でも、実際のところ弊社で求める基準をどのレベルで満たしているのか、チェックシートだけで確認できるわけではありません」。さらに、契約完了後も継続的に対策を実施しているか保証されないのも課題と、Dropboxでセキュリティ責任者を努めるラジャン・カプール氏は指摘する。

 すべてのベンダーがバグバウンティプログラム参加の条件を快く受け入れるわけではない。

 「納得してもらうのは本当に、本当に大変です」。実感を込めて述べるカプール氏。そんなときは、脆弱性が悪用された場合のユーザーへの影響を挙げて、自社サービスにバグや脆弱性が発見される"恥ずかしさ"よりも、顧客が安心して利用でき、企業としても信頼されることの方が、長い目で見れば意義があることを根気よく説明するという。

バグバウンティプログラムを活かすにはDevSecOps実装が重要

 それでも、理解はできても実施は厳しいと言われることがある。理由の1つとして、カプール氏は製品開発ライフサイクルにセキュリティ施策がうまく組み込めていないことを挙げた。DevSecOpsとも呼ばれるこの体制がある程度確立されていないと、バグ報告からの検証と対策の検討、迅速な修正、パッチのリリースまでの工程がスムーズに回らない。

 「弊社はクラウドネイティブのサービスで、当初より開発から運用までの各チームがセキュリティファーストで動いています。DevSecOpsの実装やバグバウンティプログラムの採用が問題なく実施できたのも、そのおかげだと思います。ゼロから体制を整備する必要のあるベンダーが難色を示すのは当然のことです」

 DropboxでDevSecOpsを展開した経験から、まず取り組むべきは「セキュリティチームと他チームとの良好な関係性の構築」とカプール氏は述べる。

 1つは、セキュリティチームと経営層間のコミュニケーション確立だ。「内在するセキュリティリスクやビジネスへの影響を分かりやすく説明し、排除するための方針や施策を提示するのは、セキュリティチームの役割です。緊急時に速やかにエスカレーションでき、対策実施に"イエス"と言ってもらえる関係を作ることは大切です」(カプール氏)

 もう1つは、製品開発チームとの関係の構築だ。職務時間中に気軽にセキュリティチームのところへ来て質問したり情報交換したりできるような人間関係は、あらゆる場面で効果を発揮する。

 「以前、とあるセキュリティリスクが発見されたとき、今後は類似の問題を開発チームが特定できるようにしたいねとセキュリティチームで話し合い、開発チームと相談して開発プロセスに組み込んでもらったことがあります。これは、セキュリティバイデザインの考え方を互いに学びながら、コードをプッシュする際のチェック方法やアジャイル性を損なわないセキュリティ施策の実装などを検討し、段階的に進めることで実現しました」(カプール氏)

 内部でのコミュニケーションが確立できたら、ようやくバグバウンティプログラム参加が視野に入ってくる。

 といっても、いきなりフルコミットで参加するのではなく、小さいことから一歩ずつ進めるのが最適だ。最初のステップは、善意で当然のようにバグや脆弱性を報告してくる外部のセキュリティコミュニティとの付き合いに慣れること。突然のバグ指摘に拒否反応を覚えるかもしれないが、安心・安全なサービスの提供という目指すところは一緒であることを知り、少しずつ心の受け入れ体制を作っていく。それが整ってから、DevSecOpsを洗練させつつ、報告範囲の拡大やコミットメントの宣言などを行うのが良策とカプール氏は提案する。

 Dropboxにはセキュリティチームが6つあり、その1つのプロダクションセキュリティチームがバグ報告の窓口を担当している。メンバーは2人。バグ報告が上がってきたら速やかに事象の再現含む検証を実施、確認できたら製品開発チームなどに修正を促し、報告者にフィードバックする。

 今後も、バグバウンティプログラムやDevSecOps含むセキュリティ施策について、積極的に投資を続けるとカプール氏は述べる。

 「時代の変化やユーザーの声に耳を傾け、ユーザーが安心・快適に利用できるサービスを目指し、取り組んでいきます」(カプール氏)

■関連サイト

この記事をシェアしよう

週刊アスキーの最新情報を購読しよう