息子に「お父さんカエルの匂いがする」と言われているセキュリティエンジニアリングの 西川です。カエルの匂いとはこれ如何に。。
カミナシに関わって1年経って
見出しで入社してではなく、関わってと表現したのは業務委託で関わり始めたのが去年の4月からだったからです。1年経って色々と今までの活動などの振り返りをしたいと思い筆を取りました。
そもそも振り返るきっかけとなったのは、IssueHunt 社のイベント（https://issuehunt.jp/seminar/lounge3）でプロダクトセキュリティについて話をする機会があったからです。できるだけ無意識下にあったものを言語化したいなと思いました。自分の考えを整理する貴重な機会をいただけて本当にありがたかったです。
私はセキュリティに関する競技への参加などを通じてチームビルディングないしは、組織に馴染むといいますか、その組織に最適化するのが得意な方だと思っていました。組織や周りの人が何を求めているのかがわかると言いますか。しかし、カミナシに関して、ここで私は何をしたらいいだろう？と考える時間がすごく長く、暗闇の中を彷徨っている感覚すらありました。最近やっと1年を経てやっていくことが自分の中で明確化されてきてスッキリしています。今までこんな経験をしたことがなかったので、これはなんなんだろうと考えていました。
カミナシのプロダクトセキュリティは難しい
カミナシにおけるプロダクトセキュリティはちょっとばかり難しいんだと改めて思っています。何が難しいかというと、サービスを開発・運用しているチーム（以下サービスチーム）がセキュリティに関するオーナーシップも持っているというところです。これは一見良いように思いますし、理想的な形ですらあるとさえ思います。ただ、このような形式をとっている場合、私たちセキュリティエンジニアリングの役割はなんでしょうか？取締役CTOの原トリはずっとセキュリティエンジニアリングの在り方の話しをしてくれてはいたのですが、具体的なところは委ねられていました。
カミナシのセキュリティエンジニアリングはサービスそのもののセキュリティを直接的に強化していくのではなく、サービスチームのセキュリティに対する意識付けや、教育を通してセキュリティを向上させるというのがミッションとしてあります。特定のサービス以外のセキュリティ強化もあるのですが、大きなミッションとしてはそれです。
ここが今はだいぶ明確になっているのですが、以前は何をしたらサービスチームに対してセキュリティエンジニアリングとして価値を提供できるだろうかというところでずっと考えていたのです。
それまで既存のセキュリティエンジニアの在り方みたいなところとのギャップが大きいと感じていました。例えば、SREやインフラチームのように横断チームがあれば、セキュリティエンジニアが要件を作って、それをSREが実装するみたいなこともできますし、あるいはセキュリティエンジニアがその役割を担っても良いわけです。しかし、カミナシではそういうチームは現在ありませんし、今後もわかりません。また、先ほども申し上げたとおり、サービスチームがセキュリティの責任も持っています。という中でどうしていくのがよいのだろうかとずっと考えていました。
セキュリティの文化作りと現実
カミナシではCTO原トリからセキュリティの文化を作るんだと言われ続けていましたし、私自身もそれが目的でカミナシにジョインしました。私はカミナシに入る前からセキュリティの文化作り、会社の規模としてのシフトレフトというところを意識して早い段階からセキュリティを考えることで自然とセキュリティのレベルは向上していくものだと思っていましたし、それはある程度汎用性があるものと考えていました。 しかしながら、現実は違っていて、カミナシでやるべきセキュリティはカミナシに合ったもので、同じことを他の組織でやってもうまくいかないと感じています。それこそ横断チームがあるとないとではまったく違うものになります。また、私は副業でセキュリティのコンサルティングもしていますが、やはり、各社それぞれ取り組み方や求められるセキュリティレベルが違いますし、組織風土によってもセキュリティのやり方やレベルというのは異なっています。これを1年経ってようやく理解することができました。
つまり我々プロダクトセキュリティに関わる人間が意識しなければいけないのは、そこに対して適応していくということです。これは在り方であってHowではありませんが、常に意識しておきたいポイントです。
そんな中でのサービスチームとの関わり方
さて自分の方向性が見えてきたきっかけは何だったのか？というところを考えていくと開発チームとしっかり関わり始めたというのが大きいです。また、カミナシではスクラムを用いているので、それを邪魔しないように入っていくにはどう関わるのがよいのかを考えていました。 そこでカミナシのメインサービスを開発しているチームとデリゲーションポーカー(https://nuworks.jp/ja/product/del-poker-down/)をしました。 先ほどセキュリティのオーナーシップもサービスチームが持っているという話をしましたが、持つとは言っても濃淡があると思っています。 本当はもっと細かいのですが、「情報があれば欲しい」、「情報も自分たちから取りにいく」、「何かあったときだけ助けて欲しい」、「すべてのセキュリティの責任は自分たちが取る」みたいにいくつかのレベルを定義し、セキュリティのデリゲーションレベルを決定しました。いくつかのチームと実施した結果、どのチームも10段階のうち6のレベルで自分たちでセキュリティの責任を持っていきたいという話がでました。手前味噌ではありますが、この意識の高さは本当に素晴らしいと思っています。
それはうまくいっているのか
正直なところ、完全にうまくいっているかというとそんなことはありません。スクラムをやりながらセキュリティのタスクをこなしていくというところで、なんとなくやらなければいけないことはわかるものの、でもそれは本当に今やらなければいけないことなのか、というところの説明がサービスチームのメンバーでは難しいようです。 つまりは何をやるか、どうやるかみたいなWhatとHowについてはサービスチームでは考えられるけど、Whyが説明できないということです。ただ、ここでいうWhyは何でやらなければいけないか？ではありません。それであれば当然彼らも説明はできるのですが、そうではなく、それが今やる必要があるのかどうか、掛ける工数が妥当かというところの説明が難しいのです。これは、他のタスクとの兼ね合いやビジネス方針も含めて考えなければいけないので難しいわけです。 ここはセキュリティエンジニアがある程度普段から関係各所とコミュニケーションをとっておかないといけないところで、スクラムにあるタスクと比べてどうなのかというのを会社として求められている機能開発と含めて優先度を決定していかなければいけません。これがセキュリティエンジニアが伴走する一つの形であると最近考えているところです。
ということで、Whyはセキュリティエンジニアが補い、WhatとHowをサービスチームに任せるというのが現状の形になっていて、これがちょうどいい塩梅になっていると現在は感じています。
本当にセキュリティエンジニアは必要なのか？
Whyも説明できるようになったらセキュリティエンジニアはいらないのでは？ということも考えられます。実際問題、サービスに存在するセキュリティ上の課題についてはカミナシのような組織構成では彼らの方が認識できているのですから。ですが、一方で、今ある課題については把握できているのですが、あるべき姿やセキュリティの理想、攻撃者の観点みたいなところの経験や知識はセキュリティエンジニアに一日の長があるので、こちらから指示やアドバイスを出すことができます。 例えば、WAFを導入したけど、そのルールの内容がサービスのコンテキスト含めて妥当かどうかを理解できていないこともあります。そういうケースで都度セキュリティエンジニアがサービスチームにインプットする必要があると考えています。そういった意味ではセキュリティに関する情報収集を積極的に行い、取捨選択してサービスチームに必要な情報のみを届けるということはこの先も必要であると今の段階では考えています。
セキュリティエンジニアとして気をつけていること
2024/03現在、カミナシでは社員という形のセキュリティエンジニアは私一人で、限られたリソースの中で効果的な施策を打っていかなければいけません。また、サステナブルではない施策もできるだけ避けてきました。いくら世の中的に素晴らしい施策でも運用できなければ意味がありません。私しかできないのでは「良い施策」とは言えないということです。そういった意味ではタイミングによって良い施策かどうかというのは変わるものだと思っています。セキュリティエンジニアリングが管理しているAWSリソースのIaC化を進めている一方で、タイミングが適切かどうかや新しい人が入ってもそれを理解することができるかという観点が非常に重要で、コードにコメントを書いたり、READMEに背景をしっかり書くことを重要視しています。
セキュリティの原則をそのままの意味で捉えない
カミナシのセキュリティエンジニアとして、セキュリティと利便性をいつも考えていかなければいけないわけですが、それについては、よりスタートアップ企業では重要であると考えています。スピードを伴う必要があるためです。シフトレフトという考え方ではセキュリティを要件定義段階から考慮していくことになりますが、サービスをリリースしたとして、1年後もサービスが継続できているかわからないスタートアップではそこの検討や実装にどれだけ時間を掛けることが適切かはかなり難しい判断です。これは会社としての方針を決める必要があり、カミナシでも方針を定めています。興味がある方はカジュアル面談などでお話ししましょう。
同様に最小権限の法則というものがありますが、これも整理が必要です。例えば複数の開発チームがあったとして、そこに所属しているエンジニアが2-3人だけだったとします。こういったケースが世の中でどれぐらいあるかはわからないですが、マルチプロダクトに舵を取ると急にこのようなことが発生することはあります。 そのときに、そのサービスに対しての権限を2-3人のチームだけにしか渡さないということに限定することはできるでしょうか？教科書通りであればこのチームのメンバーだけに権限を与えるのが適切かもしれません。つまり、最小権限の最小の定義をより広い意味にもとらえることができるということです。2-3人では何かあったときに運用がまわらない可能性があるため他のメンバーにも権限を与えましょうということは言えると思います。 ただ、そこから先は誰に対してとか、何人に対してとかどういう役職に対してとか色々検討の余地があります。
カミナシのセキュリティエンジニアリングの特徴
これは採用募集のところにも書いているのですが、カミナシには「現場ドリブン」というバリューがあり、これはセキュリティエンジニアリングチームが特に大事にしたいバリューの一つです。ここでいう「現場」とは、社内でプロダクト開発やサービス提供を行う現場、そしてカミナシのサービスを利用してくださるお客様の現場の両方を指します。そして、あるべきセキュリティの形は現場によって異なる。これが私たちの思想の根幹です。私たちは、さまざまな制約の中で世の中に価値を提供する「現場」に入り込み、「現場ドリブン」によってあるべきセキュリティの形を探求します。ともすれば独善的になりかねないセキュリティの理想を現場に押し付けるのではなく、私たち自身が現場の制約に寄り添い、現場にとって価値のあるセキュリティをともに実装していくことを重視する。これがカミナシのセキュリティエンジニアリングの目指す姿であり、特徴です。
セキュリティは「やって当たり前」だとは私たちは思っていません。やれていないならそのやれていない理由を根幹から突き詰め対話を諦めません。その距離感を大事にしたいと思っています。
最後に
かなり取り留めのない文章となってしまいましたが、このようなことを1年を通して色々と考えてきました。冒頭にも書いたとおり、もっとすんなりサービスのセキュリティ向上に勤めたかったのですが、なかなか難しい1年となりました。しかし、今年はやるべきことが明確化されてきたので、より一層の成果をあげられるよう頑張りたいと思っています！
すごく難しい環境ではあるものの、とても学びが多い環境です。ぜひ一緒に働きましょう！ herp.careers
