ベルフェイスにおける攻めと守りのセキュリティ
ここから、ベルフェイスで実際に実施しているセキュリティの取り組みを踏まえて、具体的に解説していきます。
情報セキュリティ規定群、プロダクト開発工程におけるルール策定（守り）
やみくもにセキュリティ対策と銘打って対策を行うと、セキュリティ対策コストがかかるのはもちろん、セキュリティ対策の差し込みが入ってしまい、開発ロードマップ等に変更が生じてしまうこともあります。
そこでベルフェイスでは、優先的に取り組むべきセキュリティ対策を整理することを目的としたフレームワークであるCIS ControlsやNIST Cyber Security Frameworkを使用して、開発関係者にヒアリングを実施し、可視化を行った上でセキュリティ対策としての課題を抽出しました。
並行して、「どのデータを守ることがベルフェイスにとって重要なのか」「どのようなお客さまがbellFaceを利用される想定なのか」を経営層に確認し、セキュリティ対策としての優先順位を決定しました。
その結果、まず優先し着手したものは「情報セキュリティ規定群のアップデート」「プロダクト開発工程におけるルールの策定」でした。恥ずかしながら情報セキュリティ規定群は存在していたのですが、その規定が十分に守られていない状態が可視化を通してわかり、かつプロダクト開発が機能優先でセキュリティチェックが存在していなかったためです。
情報セキュリティ規定群アップデート、プロダクト開発工程におけるルールの策定ができたことで、ベルフェイス社内ではプロダクト開発におけるセキュリティや情報セキュリティ対する意識が徐々にですが向上してきています。bellFaceの開発においても設計、構築、運用におけるセキュリティチェックポイントがポリシーとして生まれ、まだ完璧ではないですが、プロダクト開発においてセキュリティがしっかり組み込まれる体制が徐々に生まれてきました。逆にプロダクト開発チームの方々からも「セキュリティが気になるからレビューを行ってほしい」と声がかかるようになってきました。
シフトレフトの推進（攻め）
プロダクト開発におけるセキュリティの浸透として、「シフトレフト」の推進を現在行っています。
bellFaceはSaaSサービスですし、機能のリリースや改善は頻繁に行われています。一般的に脆弱性診断は機能リリース前に行いますが、そうすると、開発・リリース時において、脆弱性診断の結果によっては巻き戻りが発生するため、リリースや改善を頻繁に行っているベルフェイスには適していません。
そのため、前段でもお話したように、企画段階からリリース直前・リリース後の運用にセキュリティチームが寄り添い、かつ企画からリリースまでの各ステップでセキュリティのチェックポイントを設けることにしました。
各ステップにおいて、セキュリティのチェックポイントがあることで時間を要するという懸念はありますが、これによって安全にリリースすることが可能になりますし、運用時にも運用従事者とセキュリティが連動することでセキュリティ問題発生時は改善点をプロダクト企画案としてプロダクト企画側に提案することができます。
繰り返しになりますが、セキュリティチェックポイントを設けず、運用段階で脆弱性があり、その脆弱性を突かれた情報漏えい等のインシデントが発生した場合を想定すると、各工程でセキュリティのチェックを設けた場合の方が、コストと影響が最小限に抑えられることができると判断したため、このような運用にしています。
これはうれしい悩みですが、シフトレフトを推進したことでセキュリティの確認に時間を要することになってしまいました。こちらは基準やルールをさらに効率的にできるようなアップデートを計画中です。
おわりに
このようにベルフェイスでは、bellFace を「安全」「安心」にご利用してもらうために、攻めと守りの両方を並行して行い、今でも改善を行っています。
国際情勢、法規制、悪意の行動情報の事前取得など情報収集結果から、プロダクト企画へのフィードバックがまだまだ足りていません。こちらについてはセキュリティの優先順位を着実に決め、 プロダクト企画として提案し、bellFaceのセキュリティ強度を向上させ、利用いただいているお客さまにより「安全」「安心」を提供していきたいと思っています。
