MIXIには、探究心溢れるエンジニアがたくさん在籍しています。その探究心は業務で扱う技術に留まらず、趣味で書いているプログラムだったり、個人的に研究している言語だったりと、自身の気になった技術への追求も留まることを知りません。今回は、『セキュリティ』をテーマに、開発本部セキュリティ室セキュリティエンジニアの野村が語ります!
2022年MIXI入社。セキュリティ室にてセキュリティエンジニアとしてMIXIのセキュリティ全般に携わる。趣味はソフトウェアの開発や運用、サバイバルゲーム、コーヒー。
SECCONの運営からMIXIへ
──セキュリティに関わるきっかけについて教えてください
以前SECCON運営のインタビューでも取り上げたのですが、友人の開発していたTwitterアプリについてセキュリティ的な視点で議論したことがあります。すごく良いアプリでも、脆弱性によってユーザーが一気に離れてしまうことは良くあります。そこで、話し合って解決策を見いだしていったのが最初のきっかけですね。
──その原体験からSECCON運営につながっていったのですね
そうですね。SECCONでは、システムの開発や問題を作ったりしています。運営メンバーは、セキュリティ事業会社のセキュリティエンジニアが多いです。その中でも私は開発や運用の視点からセキュリティに関わりたいと考えており、その方面での能力をSECCONの運営に活かしています。
──そしてMIXIへの転職につながったのは何がきっかけですか?
前職のセキュリティ事業者としてのセキュリティエンジニアは、長くプロダクトに関わる機会がそれほど多くありません。その場で動かすスクリプトを書くことはありますが、一つのプロダクトを長期的な視点でより良くするような経験はあまり多くはありません。短期的な関わり方だと根本的な提案なども難しく、当事者としてプロダクトのセキュリティに関わりたいと思い転職を決意しました。
開発者に信頼されるセキュリティ
──セキュリティ室は、どのようなセキュリティ領域を対象としていますか?
私たちはセキュリティ全般を扱っています。個人に対するセキュリティ啓蒙や、プロダクトの脆弱性診断に関わることもあります。他にもパスワード管理ツールなど、全社的な啓蒙活動も行います。
──他チームとの関わりが多そうですね
プロダクトを構成しているシステムやプログラムは非常に重要です。しかしセキュリティという点に注目すると開発に関わる人や利用するユーザーなど「人」の存在が非常に重要になります。そのため、啓蒙活動が欠かせません。人を大事にしないとセキュリティ担保はできず、人がインシデントの起点になってしまいます。
──啓蒙する上で注意していることはありますか?
セキュリティ室の指針として「関所にはならない」というのがあります。私たちはプロダクトのコードやインフラの設計といったすべてを把握している訳ではありませんし、リリースマップやビジネス上の課題なども完全には正直完全には理解できていません。セキュリティ上で不安なことを全てをダメとするのでは無く、プロダクト側のエンジニアに寄り添い、解決策を模索します。もし、強制するようなことを言ってばかりだと、徐々に嫌になってきて一緒に問題へ取り組めなくなってしまいますよね。なので、信頼を得るという意味でもコミュニケーションは大事にしています。
──MIXIには色々なプロダクトがありますが、注意している点はありますか?
MIXIでは特に決まったフレームワークや言語はないので、色々なプログラミング言語やフレームワークについて、少なくとも読めるレベルまでは学んでいます。技術的な引き出しを増やすよう努めています。
私の考えとして、セキュリティエンジニアのお客様は開発者です。そのため、彼らの価値観に共感できないのはナンセンスだと思っています。なので、例えばセキュリティ診断を行う際にはプロダクトに関するドキュメントを読み込んだり、アプリのベータ版を遊んだりとプロダクト理解に努めています。
開発者は自分が狙われている意識を持って欲しい
──社内での情報共有などは行っていますか
セキュリティ室のメンバーとは勉強会などを行っています。個人としてはSECCONの運営に参加したり、昔に参加したセキュリティキャンプを通じて出会った方などと、Twitter上で情報を共有しています。
後はブログなどを通じて上がってくる新しいキーワードについて、幅広く調べるようにしています。
──今注目していることはありますか?
今後、開発者が狙われるのではと思っています。開発者の環境は攻撃者にとってとても魅力的です。開発用のトークンやプロダクトのコードもあります。そういった環境で、開発者は開発に役立つのであれば、すぐに取り入れます。例えばその時にツールや依存パッケージの名前を入力ミスしてしまったらどうでしょうか?実際、パッケージマネージャーのレジストリには有名なパッケージの入力ミスを狙った名前などで危険なライブラリの配布が日々行われています。
──対策はありますか?
完全な対策は非常に難しいのが正直なところです。ただ既存のセキュリティの対策でも有効なところも多いです。たとえば不正なアクティビティや行動ログの監視であったり、リポジトリ上であればDevSecOpsのような仕組みで依存関係を確認したりなどでサプライチェーン攻撃に対抗できます。例えばGitHubでは依存関係を表示してくれる機能があったりするので、そういったサービスを利用すると良いでしょう。
そういった仕組みは大事ですが、最終的には人が鍵になります。開発者の皆さんが「自分たちが狙われている」と頭の片隅に入れて貰って、何らかの操作の際に入力している名前が間違っていないかなど疑って貰うなども大事な事だと考えています。
セキュリティのゴールは気にしなくて良くなること
──最近AI活用が広まっていますが、セキュリティ面ではどうでしょう?
最近ではMicrosoft SecurityにChatGPT機能が追加された、Microsoft Security Copilotが発表されました。セキュリティ分野でのAI活用はあまり進んでいなかったので、驚きました。セキュリティ室のメンバーとは、ChatGPTのプロンプトを書いたら勝手に情報収集してクエリー書いてくれると良いよね、なんて話をしていたのですが、まさかChatGPTが出て1ヶ月後に話していた似たような機能がリリースされるとは思いませんでした。
新しい技術はセキュリティの弱点になりやすいので、対策を考えていく必要があります。プロダクトに関わる人たちは、他サービスに負けないためにもAIを活用しますので、セキュリティエンジニアとしてしっかりサポートしていきたいです。
──どういったサポートが考えられますか?
たとえば法整備に関連したセキュリティの枠組みであったり、社内の機密情報や情報利用に関するポリシーなどが必要とされています。また、プロンプトインジェクションと呼ばれる行為など、プロダクトのセキュリティ対策についても早急に検討したいですね。
──取り組むべきことは多いですね
セキュリティのゴールは、セキュリティを気にしなくて良くなることだと思います。JPCERT/CCという日本での様々なインシデントを取りまとめアドバイスする組織があるのですが、その組織のWebサイトにある標語にサイバーインシデントがなくなるその日まで、と書かれています。少し意味合いは異なりますが、セキュリティエンジニアとして、セキュリティをそもそも気にしなくて良い世の中になるのがゴールだと思います。そこにこだわって仕事をしていきたいですね。