2023.01.13 Fri

GovtechスタートアップにおけるSecurity Engineerとは？

こんにちは、HRの畑中です！

グラファーでは、サービス提供が拡がり始めた2019年頃からSecurity Engineerの募集検討を始め、2022年9月に森田さんがジョイン。
この記事では、実際にSecurity Engineerとして働く森田さんと、プロダクト責任者である本庄さんに、グラファーのSecurity Engineerについて、詳しく聞いてきました！

グラファーがなぜ専任のSecurity Engineerを必要とし、森田さんが入社後、具体的にどんな取り組みをしていて、今後は何を実現していきたいと考えているのかなど、より幅広くご紹介します。

ツイートシェア

話を聞いたエンジニア

森田　浩平

2018年にGMOペパボ株式会社に新卒入社し、事業部を横断したセキュリティ支援や基盤構築を DevSecOps, Secure by Default をキーワードに取り組む。また、同社にてWebAppSec, コンテナ / Kubernetes の他、コーポレートセキュリティ(SaaS, EDR など)の課題に技術で取り組んだ後、2022年9月にSecurity Engineerとしてグラファーに入社。

本庄　智也

株式会社リクルートホールディングスに入社後、エンジニアとして海外進出のプロジェクトの立ち上げに参画し、アプリ開発、サーバーサイド開発基盤の刷新、認証基盤の開発に携わる。データを活用した営業生産性の改善プロジェクトなどを経て、SaaS製品の製品開発を統括。2017年から株式会社グラファーに参画しプロダクト責任者を務める。

Security Engineerって何？

——そもそも、Security Engineerとはどういう職種ですか？

森田：一般に、 “Security Engineer” という言葉が指す意味は非常に広く、次のような仕事をする職種を指します。

脆弱性診断
SOC (Security Operation Center) などの監視業務
マルウェア解析や脆弱性を分析するセキュリティ研究者・アナリスト
自社サービスのセキュリティ向上のために動くエンジニア

グラファーにおけるSecurity Engineerは最後の「自社のセキュリティ向上のために動くエンジニア」に該当します。プロダクト開発や運用以外にも、全社的なセキュリティの担保およびセキュリティ品質の向上に、レバレッジの効く手段で貢献することが、グラファーのSecurity Engineerの職務になります。

Security Engineerを募集した背景

——なぜグラファーは、早い段階からSecurity Engineerを必要としたのでしょうか？

本庄：理由は、大きく2つあります。

まず1つ目は、求められるプロダクトセキュリティの水準の高さにあります。

グラファーは、行政領域において日本に居住する全市民を対象としたユニバーサルサービスを提供しています。市民の情報を扱うサービスであるからこそ、機密性・可用性といったセキュリティに関する要求事項は高く、事業を行う上でこれを満たすことは必要不可欠です。

しかしながら、セキュリティの世界は奥が深く、最新情報をキャッチアップしながら当社にとって必要なことに取り組み続けるのは容易なことではありません。開発者自身が基本的なセキュリティを押さえた上で開発していくことはもちろんですが、その上で、しっかりとしたセキュリティへの考え方を持ち、取り組みプロセスを改善していけるようになる必要があると考えました。

2つ目の理由として、行政DXを実現していく上でのセキュリティの果たす役割の大きさがあります。

例えば、自治体では、総務省が定める「地方公共団体における情報セキュリティポリシーに関するガイドライン」に準拠し、「三層分離」（機密情報を扱う業務は、ネットワークから分離して実施）という管理方針が採用されています。その結果、職員の方々は複数の端末を使い分けたり、ネットワークをまたぐようなデータのやりとりに手間をかける必要がでてきます。こういった対策は業務の生産性とのトレードオフになっていますが、昨今のセキュリティの新たな考え方なども踏まえるとアップデートしていく余地が大いにあるのではないかと思います。

当社は、行政DXを推進するソフトウェア企業であり、実際に現場の方々と一緒に変化を生み出すことを目指して日々取り組んでいます。そういった立場から、現場で得られた知見も生かし、セキュリティの担保と職員さんの働く環境の間にあるべきバランスを考え、行政DXを加速させる提案を行っていくことが、当社が担いうる価値提供の一つだと考えています。

自社事業を成長させるだけでなく、社会課題の解決にまた一歩深く踏み込んでいく。そのためにセキュリティの専任担当を置き、その存在を中心にセキュリティ体制を作っていくということを経営として意思決定しました。

グラファーにおける、Security Engineerの役割・重要視する考え方とは

——グラファーにおけるSecurity Engineerの特徴は何でしょうか？

森田：特徴は、大きく2つあります。

1.ビジネスドメインにおける特異性

個人情報の漏洩などの重大なセキュリティインシデントを発生させないために、セキュリティに取り組む必要があるのは、どの事業・サービスでも変わりません。

グラファーにおいても、市民の情報を適切に保護し、サービスを安心してご利用いただけるような機能の提供を行っています。

クレジットカードや医療情報を取り扱う際に、関係機関が公開しているガイドラインやポリシーに準拠する必要があるように、行政領域でも一定のセキュリティ水準を確保する必要があります。地方公共団体が SaaS を利用にあたって留意すべきことが整理されたガイドラインや文書が存在する他、各自治体においてもセキュリティポリシーが定められています。そのため、グラファーの製品を導入していただくにあたって、いくつかのハードルがあります。グラファーではそれらのガイドラインを参考にしつつ、課題設定を行い、セキュリティに取り組んでいます。

また、行政における業務効率化や利便性向上を阻む要因を解決するにあたり、既存の仕組みやポリシーを考慮しつつ、セキュリティを確保した解決策を提案・実装していく必要があるのは、行政ドメインならではだと感じています。

既存の仕組みに囚われるだけでなく、本庄さんが仰られているように、行政 DX を加速させる提案や、行政領域のセキュリティ課題を政府・官公庁に対して提言していくことも、グラファーだからこそできることの一つだと思います。

2.セキュリティチームによる Enabling

グラファーにはいくつかのプロダクトがあり、プロダクトごとにプロダクトマネージャ(PdM)やプロダクトデベロッパーが所属しています。一方で、プロダクトを横断して専門的な領域に取り組む「スペシャリスト」という職種があり、Security Engineerはここに該当します。

これまで、プロダクトデベロッパーや SRE などの他のスペシャリストがセキュリティを兼任されていましたが、新しくセキュリティチームという箱が作られたことで、より効率的な活動ができるようになっています。

同僚の SRE が「部署を超えた Enabling」という目標を掲げていたのですが、セキュリティも同様だと考えています。Enabling とは、チームトポロジーなどで挙げられている、各チームに対して専門能力を提供したり伝道したりするチームの活動です。セキュリティチームは、各チームに対して、より効率的な手法や仕組みを提案したり、情報共有や学習を促す存在として振る舞うことで、組織全体の技術力向上にも寄与することができると考え、実践しています。

セキュリティチームは、まだ私一人ではあるものの、グラファーはセキュリティへの意識が高いメンバーで構成されていると感じており、セキュリティ体制を 0 -> 1 で作り上げるのではなく、 1 -> 10 あるいは 10 -> 100 にするような活動が中心になっています。

Security Engineerとして取り組んでいること・この先やっていきたいこと

——森田さんが現在、Security Engineersとして取り組んでいることや、この先やっていきたいことを教えてください。

森田：現在取り組んでいることは、大きく3つあります。

1.Security Engineerとして信頼してもらう

私がグラファーに入って最初に行ったことは、「セキュリティに関する課題のヒアリング」と「Security Engineerとして働く上での行動指針」の共有でした。

グラファーには「スタンプラリー」という制度があり、入社後に、誰でも既存メンバーにインタビューできます。これを利用して、普段の開発業務でセキュリティ的に不安なところがないかをヒアリングしたりしました。スタンプラリーを通して、「Security Engineerと働いたことがない」もしくは「『指示を受け、報告する』だけの関係だった」という方が多数だったのもあり、自分の仕事を知ってもらうためにも、次のような行動指針を共有しました。

あらゆる部門と協業するセキュリティ(Cooperation Security)
セキュリティ業界でよく聞くのが “開発者との対立” です。なにか機能を実装してもセキュリティ上の理由で中止になったり、リリースが遅れたりなど、セキュリティチームが門番のような存在として機能してしまうことから生じます。これは非常に不健全な状態であり、目指すところではありません。
Security Engineerは組織のあらゆる職種(Product, Corporate, Business, etc..)と協同すべきだと考えています。セキュリティリスクやその課題を拾い上げ、実現のための解決を共に模索し、実装をサポートすることで、相互信頼を積み上げます。
継続的なセキュリティ (Continuous Security)
前述した「継続的なセキュリティ」を実現するためには、新しく導入するセキュリティのプロセスや仕組みが、生産性を落とすことなく、一定のセキュリティ水準を担保することが理想です。そのためにも、開発サイクルにおいて、「早く」「頻繁に」「レバレッジの効く方法」でセキュリティに取り組みます。
具体的には開発サイクルにセキュリティを統合し、自動的なセキュリティテスト、セキュリティスキャンを実施し、Shift Left を推進します。
客観的なセキュリティ (Objective Security)
セキュリティは、リスクを許容するかどうかの意思決定の連続です。会社の全員がセキュリティに詳しいわけではないため、その意思決定をサポートするのもSecurity Engineerの責務です。対策の有効性や優先度などをリスクベースで客観的に理解できるようにし、意思決定の速度を上げることにも努めます。

グラファーの Values 2.0 には「相互信頼を積み上げる」という言葉があります。この行動指針を元に行動し、結果を出すことで、相互信頼が積み上がり、より良い Enabling ができると考えています。ひいては組織全体でセキュリティ文化の醸成に繋がることになるでしょう。

2. セキュリティロードマップ / ベースラインの策定

前述したようなセキュリティガイドラインに、プロダクトとして準拠するのはもちろんですが、実際の攻撃は、フィッシングや標的型攻撃など、プロダクト以外の経路からも考えられます。特に昨今では、ソフトウェアのサプライチェーン攻撃等も流行していることから、開発プロセス全体を俯瞰しての脅威と、そのリスク評価をする必要性を感じています。

そのためにも、ATT&CK のような形で脅威モデルを構築し、既存のガイドラインとも組み合わせつつ、どのような対策を行うべきかを、セキュリティベースラインとして整備することにも取り組んでいます。チームや組織として、優先的に取り組んでいくべきセキュリティ施策を判断し、ロードマップを敷くことで、セキュリティの向上を図りたいと考えています。

3. プロダクトセキュリティへの取り組み

より良いセキュリティを実現するための機能の実装やアーキテクチャの設計も行っているほか、Security Engineerがいなくても機能し、チームの自律性を高めるための取り組みもしています。

例えば、利用しているライブラリに脆弱性が検出された際に、「それをアップデートする必要があるのか」「アップデートするとしたら優先度はどれぐらいなのか」を判断して、アップデートサイクルを回せるような仕組みを構築していくことを目的とした、チーム同士のコラボレーションを行っています。

上記では、組織やプロダクトのセキュリティ向上に関する取り組みについてご紹介しましたが、当社の事業を通して、自治体だけでなく市民に対しても「セキュリティを担保しつつ、利便性を向上する」というインパクトの大きい役割が果たせるのではないかと思っています。

ご応募お待ちしています！

——今後、どんな人と一緒に働きたいですか？

森田：当社の Security Enginner は、主体性を求められる一方で個々の裁量が大きいので、自分から考えて動く人には合っている環境だと思います。私達と一緒に、プロダクトの力で社会を変えていきたい、セキュリティの課題をエンジニアリングで解決していきたいという仲間を募集しています。興味を持っていただけた方は、ぜひお話ししましょう！