はじめに
今年の1月から、バックオフィスの業務・情報の分断・サイロ化を解消するプロダクトを提供するスタートアップに一介のエンジニアとしてジョインしました。
当時で設立3ヶ月、開発に関わるメンバが9名ほどの規模で、スピード感高く、すでにプロダクトをリリースしているような状況でした。
当たり前であるけれどスタートアップは価値を産むことが最優先事項となり、速度感を出す都合上セキュリティは後回しにされがちです。しかしながら構造的に脆弱なアーキテクチャはリリース後の改修コストが跳ね上がることから、ある程度セキュリティにコストを割くことも肝要である認識です。
弊社では正式創業を迎える前にSOC2 Type1(以下、SOC2)を取得するプロジェクトが立ち上がっていました。情シスの役割を持った方を中心に動いていましたが、プロダクト側の対応が浮いている状況だったので、これ幸いとボールを拾い、様々対応してきたのでその経過を残すものになります。
SOC2 Type1の取得がメインのターゲットですがその中で行った全般的なセキュリティ対策についても紹介します。
本記事では、立ち上げ初期のプロダクトで行ったセキュリティ対策とその優先順位の考え方について紹介します。同じようにプロダクト立ち上げ期にリソースが少ない中で対応しているエンジニアの参考になれば幸いです 🙏
SOC2 Type1 とは
本質からは若干逸れるのでPerplexityくんの回答をそのまま貼りますね。
> SOC2 Type1って何ですか？3行で
つまり、セキュリティ対策が特定の基準にそって実装されているか、外部から評価してもらうものです。
我々は、Vantaというツールとコンサルを雇って取得まで最短で走り抜けられるようにしていました。
施策の優先順位の決定
SOC2取得にあたって会社が対応しなければいけない事項は山のようにあります。
我々はVantaを導入していたため、全量(今見たら137件も!)を並べた上で、優先順位をつけていきました。
大事なのは「認証取得は手段であって目的ではない」ということです。
経営戦略上SOC2の取得が大事ではあるものの、プロダクト目線で本質的に大事なのはお客様から預かった情報資産を守ることです。
そのため、優先順位を決定する上でもVantaで見えていないタスクも洗い出してから施策の重要度を決めて対応を進めていきました。
最終的に、以下の2軸で整理を対応の優先順位を決めていました。
- 顧客の資産を守る施策に直結かどうか
- SOC2取得にあたってのリードタイムの長短
例えば、ライブラリの脆弱性の継続的なチェックの仕組みを構築する施策は、攻撃の足掛かりを減らすと言う意味においては顧客の資産を守る施策に直結しますし、SOC2取得においても大事な観点となります。
ただし、リードタイムを考えるとすぐに着手して成果も出せるので、他にリードタイムの長い施策(e.g. 第三者機関による脆弱性診断の実施)を優先的に進めた後で並行して実施するような順序で実施していました。
リソースの制約とのバランス
最初に述べたとおりスタートアップは価値を作ることが最重要タスクです。
もちろん私も価値を作る人として採用されており、そちらの開発はおろそかにできません。
しかしながらセキュリティ対策も進めないといけません。
時間は有限です。
特にリードタイムの長いタスクは管理するコストも跳ねます。
私の考える解決策のひとつは「経営陣との密なコミュニケーション」です。
やるべき施策と後回しにする施策を列挙し、お金のかかる施策は本当にやりたいことから段階的に3つほど案を並べて判断を仰ぐようにすると、手戻りが減り、必要な部分に必要なだけのリソースを投下できるようになります。
スタートアップならではの経営陣との距離の近さを活かし、スピード感を持って本質的な施策にリソースを投下できるように立ち回ると前進しやすいと感じています。
例えば、直近3ヶ月でやる予定のセキュリティ施策と優先順位を並べて事業の優先順位と比較して決めたり、ざっくりの金額感を携えて施策の方向性とコスト感の認識を揃えた上で作業に取り掛かるなど。特にリードタイムが長いものは第三者機関が絡むことが多く、リードタイムが長くなる傾向にあるので早いタイミングで認識を揃えておくことは肝要であると感じました。
実施したセキュリティ対策と後回しにしたもの
ざっと行った取り組みと後回しにしたものを列挙しています。
✅ は記事を書く時点で取り組みが完了しているものです。
🚧 は進行中のタスクです。
その他は後回しにしたものになります。
- 特定機能
- 情報資産の棚卸し
- 脅威モデリングの実施とメンテナンス
- 防御機能
- ✅ AWS WAF (Shields)
- 静的解析（SAST）
- ✅ クラウド設定のチェック（AWS Security Hub）
- ✅ コンテナに対するチェック（Trivy）
- ✅ ライブラリの脆弱性のチェック（Renovate / Dependabot Alerts）
- 🚧 コード自体の静的解析
- 🚧 動的解析（DAST）
- 脆弱性診断
- 🚧 スポットの脆弱性診断
- 定期的な脆弱性診断
- ペネトレーションテスト
- セキュリティのシフトレフト
- DevSecOps体制の構築
- セキュリティインシデント体制の構築
- リリース前の手動診断
- セキュリティ人材のレビューへの参加
- レッドチーム演習
- Data Loss Prevention
- RLS
- 検知機能
- ✅ Amazon Guard Duty
- 🚧 ステータスページの公開
- 対応機能
- 🚧 セキュリティインシデントフローの構築
- 復旧機能
- ✅リカバリ手順の文書化
まだまだ発展途上なので、むしろ「俺はこっちの施策優先度高いと思うんだけど？」という意見がある方、ぜひ一緒に働きましょう。セキュリティにWillのある人、大募集です。
運用を回していくなかで気付いたことや取り組みがあればまた記事にしようと思います 🫰
最後に
一例とはなりますが、考え方と実際に3ヶ月で行った施策について列挙してみました。
スタートアップでセキュリティゴリゴリやってみたい！という方いたらぜひ一緒に働きましょう。
Discussion