こんにちは。 Software Engineerのsota1235です。

今回は10Xのセキュリティチームこれまでとこれからについてお話ししようと思います。

隠していたわけではないのですが、採用資料や対外発表等で特にアピールもしておらず、結果的にステルス活動みたいになっていたので本邦初公開の内容ばかりです。

この記事では

10XおよびStailerにおけるセキュリティの重要性
セキュリティ観点で見る今までの10XとIssue
なぜセキュリティチームを作るという判断をしたのか
今までどんな取り組みをしてきたのか

等々をお伝えできればと思っています。

10XおよびStailerにおけるセキュリティの重要性

10Xの提供するStailerはいわゆるB to B to Cのサービスです。

to Cは商品を求めてアプリやWebサイトを訪れるお客さまに対してセキュリティ観点で次の価値を提供する必要があります。

お預かりした情報を適切に保護すること（個人情報、決済情報等）
サービスを安心して安全に利用するための機能提供（認証機能の強化等）

to BではECサイトを運営するために必要な管理画面、スタッフアプリを提供します。

また、それを構築するために必要なデータパイプラインの繋ぎこみや外部システムのつなぎこみも行います。

その開発・運営ではセキュリティ観点で次の価値を提供する必要があります。

お客さまの情報や業務オペレーションを扱う際に適した認証・認可機能の提供
- たとえば商品を梱包するスタッフはお客さまの住所を常に参照する必要はありません、一方で配送スタッフは住所を閲覧する必要があります
10Xが契約している複数の小売事業者さま（以降、パートナーと呼称します）の求めるセキュリティ水準を満たし、説明可能な状態にする
- いずれのパートナーも各社ごとに求めるセキュリティ水準があり、それを満たしているかどうかの説明を求められる場面があります
10X - パートナー間でデータをやりとりする際にセキュアな仕組みを提供する

また、上記はto Bの観点ですがパートナーやお客さまの信頼を勝ち取るため、10X内部でも次のことが求められます。

お預かりしているすべての情報が適切に管理され、社員からのアクセス権限等がきちんと設定されていること
各種データのAudit Log等が取得されており有事の際にすぐに検知できる・調査できる体制が整っていること

上記に挙げたいくつかの例は氷山の一角です。

Stailerにおけるセキュリティの難しさであり面白さは届けるべき価値の形が少し違うto C、to Bのシステムの両方のセキュリティレベルを維持しつつ、今後増えていくパートナーと大きくなる事業規模を見据えたスケーラブルな体制構築が求められるところにあるかなと思っています。

セキュリティ観点で見る今までの10X

セキュリティチームができる前の10X

セキュリティチームができる前の10Xでは機能開発のタイミングで各ソフトウェアエンジニアのスキルを頼る形でセキュリティレベルを担保していました。

実態としては必ずしもソフトウェアエンジニアのみでセキュリティ品質を担保しているわけではなく、必要なメンバーがつど集まり必要に応じてパートナーからのfeedbackをもらいながら進めていました。

とはいえ、社内にはセキュリティを専門としたメンバーはいなかったため、外部の脆弱性診断等を活用して第三者の目線も一定入れることで求められる水準を満たしつつも、スピード感のある開発体制を維持してきました。

サービスの成長に伴い顕在化したセキュリティIssue

ありがたいことにStailerがサービスとして立ち上げ期から成長期へと突入しました。

それに伴いいくつかのIssueが発生していました。

サービスの規模が大きくなり、個人の努力 + 脆弱性診断に頼る形でセキュリティレベルを担保するのが難しくなっていた
パートナー数の増加に伴いStailerのセキュリティレベルに関して説明責任を求められる機会が増えた、それに伴う改善や対応で後手に回ることが増えていた
セキュリティに関する足元の対応・改善ではなく、この先どうしていくべきかを考えるチームが不在だった（個々人や社として議題に上がることはあっても実行部隊がいない状態）

どのようにIssueを解決するか

これらのIssueを解決するにはいくつかのアプローチがあります。

前提として、当時の10Xは次のような状況でした。

社内にセキュリティ専門家は1名もいない
セキュリティにまつわるIssueは優先順位づけやIssue分析等の整理はされていないものの、すぐに着手した方がよさそうなものはいくつかある

このうえで取れる選択肢は主に2つです。

顕在化しているCriticalなIssueに取り組むTask Forceチームを編成し、一時的に人員を配置する
セキュリティチームを組成し、恒久的なチームとして人員を配置する

この2つの選択肢を比較した時、直感的には2の方がよいと感じると思います。

一方でセキュリティ専門家がそもそもいないこと、セキュリティ領域以外でも事業上優先して解決すべき問題が山積していることから簡単に人員を配置できない状況でもありました。

私たちのような規模感の会社では似たようなことが起きるのも珍しくなく、兼務することでしのいだり、期間限定のProjectでまずはIssue解決に動いたり、時には外部のベンダーの力を頼るケースもあると思います。

10Xではこの状況下で、たとえ兼務になったりアサインできるメンバー数が少なくともセキュリティチームを組成する選択をしました。

実際、組成時から現在までセキュリティチームのメンバー構成はSoftware Engineerが1.5 ~ 2名という体制で走ってきました。

これにはいくつか理由があります。

なぜセキュリティチームを作ったのか

理由は大きく2つあります。

1. Think 10xして = 長期的に考えたときに必要だと確信したから

1つ目の理由として、当時の時点でStailerの事業性質を考えるとセキュリティ領域にFocusするチームが間違いなく必要だと考えたからです。

最初に述べたようにStailerはECサイトと同じようにお客さまから大事な情報を預かり、守り続けながらパートナーには10Xがそれを成し遂げていることを常に証明し続け、信頼関係を築き上げていく必要があります。

2. セキュリティチームという箱を作ることが何より重要だと考えたから

筆者的にはこの記事で一番伝えたいことでもあるのですが、たとえチームの実態が小規模であったり各所から発生する要求を捌ききれないことが予想できたとしてもチームという箱を用意することが重要だと考えました。

理由としてはセキュリティチームという箱があることでセキュリティにまつわるIssueが1箇所に集まってくるからです。

これがミッションを絞ったtemporaryなチームやエンジニア全体で担保するような形だとIssueを投げる側はどこに投げるかがわかりづらい状態になり得ると思います。

実際、期待どおりになったの？

チーム組成からの約8か月間を振り返るといずれの狙いもおおむね期待どおりに達成したと思っています。

1点目に関しては新たに契約したパートナーからの要求が発生した際の問い合わせ先として機能できており、また既存のパートナーとの間でセキュリティ関連のIssueについて議論する際もカウンターパートして立ち回ることができています。

また2点目に関してもうまくいっています。現在は社内で発生する大小さまざまなセキュリティにまつわるIssueがセキュリティチームに集まるようになりました。

Corp ITチームとの連携

ここまでセキュリティチームの話をしてきましたが、Corp ITチームの存在にも触れておきたいと思います。

ちょうどセキュリティチームが立ち上がった同時期にCorp ITチーム、いわゆる情シスチームが立ち上がりました。

このCorp ITチームにも情報管理周りにおけるセキュリティに詳しいメンバーがいたので各チームの組成を進めつつ、現在は次のような形で責務を分解、必要に応じて協業しています。

Corp ITチーム
- 社内で取り扱う情報の管理体制の構築
- 端末管理、オフィス等のセキュリティレベルの向上
- 10Xが利用するサービスの管理やセキュリティチェック、運用
セキュリティチーム
- Stailerのセキュリティ品質の向上
- 10Xが利用するサービスのうち、プロダクトで利用しているものの管理やセキュリティチェック（GCP, Elastic Cloud等）

セキュリティチームが取り組んできたこと

つらつらと前提を書いてきましたが、じゃあ具体的にどんなことしてきたの？というのを紹介します。

セキュリティに関連するIssueの集約・整理

まずはStailerにおけるセキュリティに関するIssueを集約・整理するところからスタートしました。

特に難しいことはしておらず、泥臭く次ような作業をしました。

すでに起票されていたセキュリティに関連するIssueのラベリング
Issue化されていないが社内で議論されていたり、対応が進行しているセキュリティIssueの起票
Slack User Group(@team_security)を作成し、全社に粘り強く周知。セキュリティに少しでも関連するトピックは必ずメンションしてもらうようにした

これを行うことにより各所に散らばってたIssueが1箇所に集まり、「セキュリティ、なんとなくこのままじゃダメそう」ではなく、具体的に顕在化しているリスクやこれから発生しうるリスクが説明可能な状態になりました。

優先度をつける

前述したようにチーム体制はSoftware Engineerが2名なので対応できるIssueの量はかなり限られています。

また、集まったIssueの中にはさらに深掘って分析・分解が必要なものも多くありました。

それらを着実に着手していくべき以下の観点で優先度づけを行いました。

事業にCriticalな影響が発生しうるか
- 個人情報、決済等の取り扱い
今時点ではUnknownだが分析していくことでCriticalな問題が発覚しうるか
- 実例ではないですがたとえば「ログイン周りの挙動がちょっとだけおかしい」というようなIssueがもしあった場合、深ぼることで認証周りの脆弱性が発覚するかもしれません
- このようなIssueは優先して調査しました
今後の事業がスケールしていく上でボトルネックになりうるか
- 当時時点で予定していたリリーススケジュールに影響がでるものは優先度をあげました
- セキュリティ面を考慮して回してる運用がパートナー数増加時に回らなくなる場合、事業のボトルネックとなりうるため自動化やよりよい仕組みの検討が必要となります

実際に対応してきたIssueの例

優先度をつけた上でこの8か月間、取り組んできたIssueのいくつかを紹介します。

それぞれの詳細はまた別途Product Blogを書こうと思います（この記事がたくさん拡散されたら書くモチベーション上がるのでよろしくお願いします）。

GCPやGitHubの権限整理、IaCによる権限制御
有効化されていなかった各種の監査ログの有効化
脆弱性やセキュリティリスクを検知するSaaSやサービスの検討・導入
個人情報の取り扱いの整理（個人情報の入口から最終的な参照まで）
パートナーからの問い合わせ対応
脆弱性診断の診断プランの変更やスコープの検討

セキュリティチームが取り組めていないこと

ここまではセキュリティチームがやってきたことをつらつらと書きました。

一方でやるべきだが、できていないことも多くあります。

セキュリティ観点でのロードマップの作成
- 事業計画から逆算した上で必要なセキュリティ施策の整理やチーム体制のプランニング
より能動的なセキュリティリスクの探索
- 現状は年1回の脆弱性診断とセキュリティリスクの自動検知サービスを一部活用するのみに留まっています
- Stailerの開発や性質からどのような頻度でどのスコープをどのように検査していくかを模索していく必要があると考えています
これから発生しうるセキュリティリスクの予防施策
- そもそも脆弱性やセキュリティリスクが生まれない体制を全社を巻き込んで構築していく必要があります

そして何より急務なのがこれらに取り組むことができるセキュリティ専門家の採用です。