「カミナシ レポート」の開発・運用をしている、AWS インフラが得意な Security Engineering の furuya です（属性過多）。妙に流行り物に乗っかるときがあるのですが、「超かぐや姫!」を見てきました。よかったです。それはさておき今回は「カミナシ レポート」の開発におけるセキュリティ向上施策のお話です。
カミナシでは開発チームに Security Engineer を派遣する取り組みがあります。
kaminashi-developer.hatenablog.jp
気がつけば、この記事の公開から1年が経過していました。ここでそれを振り返ってみたいと思います。
サービスにおけるコンテキストを把握する
派遣されるセキュリティエンジニアは基本的には最初の半年から1年程度は開発チームの1メンバーとして、ともに開発や運用を行います。ですので、障害対応やインシデント対応、お客様からの通常のお問い合わせなどのオンコール担当としても活動します。
この1年を通して「カミナシ レポート」の開発・運用に携わりました。私自身のキャリア的にコーディングから離れていたのでその点は AI の力も借りながらそこそこに、代わりに得意なインフラ・運用面で改善をしたり、オンコールに入ることでチームメンバーの負荷を軽減したりして貢献しました。およそ最初の半年くらいでチームには馴染めたと思っており、そこで得たコンテキストから残りの半年は重めのインフラ・セキュリティ改善に取り組むことが最優先であると判断し、チームとしても合意の上で対応を進めることができました。
施策のテスター
その欠陥を修正することにより獲得したナレッジを他サービスチームに共有することができ、セキュリティ上の欠陥が埋め込まれるのを未然に防いだり改善することが狙いとしてあります。
欠陥の修正ではないのですが、全チーム対応しないといけないようなセキュリティ施策（AWS Security Hub CSPM の新しいコントロールへの対応など）をまず最初に「カミナシ レポート」の開発チームで実施し、対応するための手順や Terraform のコード、ハマりどころを公開して他のチームの工数を削減する、といった取り組みを行いました。サービスを運用する中での変更になるので特有のワークアラウンドが必要なこともあり、単純にマニュアル通りにいかないケースで役に立ったかと思います。
セキュリティナレッジの共有
また、セキュリティエンジニアが持っているナレッジや考え方などをサービスチーム内で共有することにより、エンジニアがセキュリティを意識しながら開発や運用を行えるようになることを目的としています。
私自身セキュリティを専門としたキャリアを歩んでいないのでナレッジの共有といっても手探りではあります。ただ、だからこそ「セキュリティどうしたらいいかわからない開発者」の気持ちにもなれます。やはり開発する身になってみると「セキュリティ、いつどこでどうしたらいいかわからない」というのが真っ先に思い浮かびます。
「いつどこで」がわからない、というのはセキュリティを気にするべきタイミング・ポイントに気付けなければ実施・対策しようがない、ということでもあります。何にせよまずは知識を得るところが大事なのではないか、と思っていたときにちょうど「開発者はどこまでセキュリティを気にすればいいのか」という問いをメンバーからもらいました。そのときの話をセキュリティエンジニアの西川さんがブログに書いてくれています。
kaminashi-developer.hatenablog.jp
そういう気に掛けることができるかどうかというのがすごく大事で、そのような気付きがあったときに「一旦セキュリティエンジニアに聞いてみようかな」というマインドセットを持てるかどうかが重要だと思っています。
気付ける筋肉みたいなものがあると思っており、それはやはり知識と実践で養われていきます。気付けさえすれば自分で解決することもできますし、できなくてもセキュリティエンジニアに聞くというアクションがとれます。
前置きが長くなったのですがやっぱりまずは座学で知るところからが一番でしょう、ということで開発者が気にすべきセキュリティの勉強会を開催しています。
第1回は「設計で気付けるとよいポイント」ということで脅威モデリングのワークショップを、第2回は「普段の実装の中で気付けるポイント」として SAST（Static Application Security Testing。コードの脆弱性チェック）の紹介および運用に取り入れる方法について議論をしました。もっと自然にチームメンバーが「気付くことができる」ように、定期的に実施していきたいです。
想定外の効果
すべてのチームにセキュリティエンジニアが派遣できればよいのですが、人数も限られており実現はできていません。しかし、派遣されなかったチームにも心境の変化があったようです。具体的には、派遣されないならされないなりに自分たちでよりセキュリティを高めていくぞ、というオーナーシップの醸成に繋がったチームがありました。実際、（個人的に）悔しいながらそのチームが一番セキュリティが出来ていそうなので、副次的ではありますが他のチームにいい影響を与えることができたのではないかと思っています（ここから挽回していきたいです）。
これから
この1年を通して開発・運用をしながらそのコンテキストを理解したうえでセキュリティ対策をしたり、セキュリティ文化の醸成に取り組んだりしてきました。まだやるべきことはたくさんあります。この1年でようやく土台が整ってきたところなので、ここから『「カミナシ レポート」の開発チームって息をするようにセキュリティできてるよね』と言われるようになりたいです。
「カミナシ レポート」はカミナシのフラッグシッププロダクトということもあり、昔から積み上がった課題が複数残っています。これらに対処しつつ、先程のSASTなどを「開発速度を落とさないように」運用にのせて一段上のセキュリティレベルを目指しつつ、チームメンバーがもっとセキュリティに「気付ける」ようにしていきたいと思っています。
