こんにちは！テクノロジー本部の花塚です！
最近気になっている脆弱性は、Envoyに見つかったHeap Buffer OverflowであるCVE-2019-18801です。
この記事では、セキュリティエンジニアがジョブチェンジをしてKubernetesチームにジョインした話、その後の取り組みについて紹介させていただきます。
私事ですが、今年の10月にKubernetesチームにジョインすることになりました。 Kubernetesチームは、以下の記事で、「KEELチーム」として紹介されています。
KEELチームは、Kubernetesをベースとしたアプリケーション実行基盤を開発しています。 詳しくは上記の記事をご覧ください。
セキュリティエンジニアからジョブチェンジしました
今年の１月に以下のようなブログを書きました。
内容から分かる通り、ジョインする前は、セキュリティに関係する業務を行っていました。
KEELにジョイン後は、ソフトウェアエンジニアとしてキャリアを歩んでいくことになり、具体的には、以下のようなことをしていくつもりです。
- KEELというアプリケーション実行基盤のセキュリティを強固にする
- KEELを使用する開発者への適切なアドバイスを行う
- アプリケーション実行基盤として求められるソフトウェアの開発/機能提供
今後はセキュリティのスペシャリティを活かしながら開発に関わっていきたいと思います。
さて、ここからはジョブチェンジをすることになった経緯についてお伝えします。
KEELチームに留学
現在LIFULLのほぼ全ての主要サービスはKEELで管理されており、今後も管理されるサービスの数は増えていく予定です。
今後あらゆるサービスがKEELで管理されることが当たり前になると、セキュリティエンジニアとしてKubernetesに関連するセキュリティにも目を向けていかなければなりません。
幸いLIFULLには「留学制度」という、一定の期間、他部署の業務を経験できる制度が存在したので、それを利用しました。
実際にKEELチームの業務を経験することで、より効率よくKubernetesをキャッチアップすることを目的としていました。
他人事から自分事にしていく
留学期間にKEELの業務をしていると、以前から自分が思い描いていたことを強く感じ始めました。
それは、「セキュリティエンジニアではなく、ソフトウェアエンジニアとしてLIFULLのセキュリティを支えていきたい」ということです。
LIFULLのセキュリティエンジニアは、各開発チームごとに所属するのではなく、セキュリティに関するチームとしてまとまっています。
各開発チームにセキュリティエンジニアが所属するという組織体制は、とても理想的なのですが、プロダクト数や開発チームが多い場合は、なかなかスケールすることができません。 また、専門家がまとまることで得られるメリットもいくつかあると思います。
しかしながら、開発チームの外部に所属しているセキュリティエンジニアは、一度は以下のようなことを思ったことがある方は少なくないかもしれません。
- ドメイン知識がないので、脆弱性の影響を調査しにくい
- エンジニアに対して注意喚起や依頼をすることが多い
- セキュリティに関する文化をどのように作っていけばいいか分からない
KEELはアプリケーション実行基盤を提供しているため、さまざまなプロダクトや開発者と接点を持つことができます。
そのような理由を含めKEELチームへの留学中、「開発者として中からセキュリティを支えていける人になろう」と決心しました。
最近では、各開発チームごとにセキュリティを担当する役割として「セキュリティチャンピオン」という言葉をよく耳にしますよね。
そのような役割を持つ人を今後増やしていけれたらなと思っています。
ジョインしてからの取り組み
ここからは、KEELにジョイン後「ソフトウェアエンジニアとしてセキュリティを支えていく」ために取り組んだことについて紹介します。
脆弱性対応方針の策定
自分は、ジョイン後すぐにKEELチームの「脆弱性対応方針の策定」に取り組みました。
「脆弱性対応方針の策定」とは何かを説明すると、脆弱性情報を入手した時にチーム内でどのような動きをするのかを話し合い、ドキュメント化することです。
この取り組みには、脆弱性情報を入手した時に後回しにせずに危機感を持って対応していけるようにしようという意図がありました。
チームの行動指針を決める上で重要な事は、「チームメンバー全員で話し合う」ということです。
負債解消のための行動指針のようなものは、当事者たちの意見を汲み取らずに外部が一方的に決めた場合、 反感を買ったり、理由も分からないまま行動させてしまいます。 文化を作っていくためには、押し付けではなく、きちんとメンバー間で対話することがとても大切です。
この議論は、GitHubのIssue上で行われました。議論の結果が以下となります。
- 「Attack VectorがNetwork」の脆弱性情報を入手した時にIssueを作成する
- Issueを作成後、影響を調査し、メンバーで対応方針を決定する
脆弱性情報の入手先は、脆弱性可視化基盤でKEELの脆弱性を一定把握していることを前提に、各ソフトウェアのリリースノート、コミュニティの情報としています。
最終的に決められた方針はとてもシンプルですが、議論の内容はとても価値があるものでした。
議論の中で、メンバーの1人が「脆弱性は別に特別なものではなく、単なるバグに過ぎない。普通のバグ対応と同じように対応していけばいい」と発言していました。
実際、脆弱性を調査する際に攻撃手法の知識が充分でなくても、調査できるケースも多くあります。 「脆弱性を特別扱いしない」という考え方は、セキュリティに関する文化を作っていくためにもっと広めていきたいと感じました。
方針の策定後
方針は決まりましたが、その後上手く運用できるか不安でした。強制力が伴わない方針の場合、本人たちのやる気というものが運用に関わってくるからです。
しかし、心配は無用でした。自分以外のメンバーから積極的に脆弱性に関する質問や共有が行われ、方針通りに動くことができています。
自分たちが納得して作り上げた方針はここまで上手くいくのかと、とても驚きました。
運用はまだ始まったばかりなので、今後もチーム全員で改善していきたいと思います。
おわりに
非常に簡単でしたが、セキュリティエンジニアがジョブチェンジをしてKubernetesチームにジョインした話、その後の取り組みについて紹介させていただきました。
ジョインしてまだ2ヶ月ですが、今後はソフトウェアエンジニアとしてKEELチームを支えていくことになります。
今回技術的な内容を紹介できなかったので、次はセキュリティ以外の内容でCreators Blogに登場できればと思います。
また、LIFULLではメンバーを募集しております。カジュアル面談もありますのでご興味ある方は是非ご参加ください！
