投稿日
更新日
インサイドセールス トレイル
もくじ
- ステージ・ゲートプロセス
- 事業が目指していることは何か
- 事業がどんな体制で進んでいるか
- トレイルがどのフェーズからスタートしているか
- インサイドセールス トレイル001
- SaaS利用時のセキュリティチェック(1)
- 目標を達成するために取り組んだこと
- セキュリティルールの理解
- 対応の方針づけ
- 今回のイテレーションでの学び
- インサイドセールス トレイル002
- SaaS利用時のセキュリティチェック(2)
- SaaS事業者
- 品質監理部門
- 今回のイテレーションでの学び
- インサイドセールス トレイル003
- SaaS利用時のセキュリティチェック(3)
- クラウド利用時のセキュリティ対策
- 今回のイテレーションでの学び
- インサイドセールス トレイル004
- SaaS利用のためのリスク対策
- 決裁取得の流れ
- 今回のイテレーションでの学び
- インサイドセールス トレイル005
- プロダクトオーナーとUX/UIデザイナーとエンジニアとの協調
- 起こったこと
- 結果
- 学び
- UX/UIデザイナーの役割とは?
- いつ協調するべきでしょうか?
- どういったプロセスを取ればよかったのでしょうか?
インサイドセールス トレイル002
SaaS利用時のセキュリティチェック(2)
前トレイルでは、SaaSを利用する際に必要な「クラウドセキュリティチェックリスト【利用編】」の 対応について記載しました。そこでは、チェックリストそのものの理解と、事業オーナーとサービスが抱えるリスクに対する認識のすり合わせを行いました。
本トレイルでは、 利用するSaaS事業者と、チェックリスト審査者である品質監理部門との認識を一致させる点について記載します。
SaaS事業者
クラウド利用時のセキュリティが十分かどうかは、SaaSの公開仕様だけを見て行えるわけではありません。 ビジネスにおいてSaaSを利用する際、時にはSaaS事業者の内部でインシデントが発生した場合のエスカレーションフローや、 データの配置場所、セキュリティに対する管理体制まで踏み込み、リスク分析・対策検討を行わなければならない場合も存在します。
これらを行おうとすると、SaaSを外から眺めるだけでは不可能です。 そこで今回は、SaaSを実際に開発・運用されている方に対し、セキュリティ管理状況をヒアリングする機会を作ることにしました。 この目的としては以下があります。
- SaaSの公開仕様ではない部分に踏み込みリスクを検討していくため、細かな内容のQ&Aを行う前に、まずSaaSを実際に開発・運用されている方々と話すことで全体感を把握したかった
- 事業側・SaaS側でお互いFace to Faceのコミュニケーションをとっておいた方が、今後円滑に連携できると考えた
打ち合わせの場では新規参画エンジニアとして自己紹介をするとともに、セキュリティ管理体制を問うQ&Aを実施しました。
これにより、具体的なSaaSのセキュリティ管理状況とともに、どこまでの情報を開示して頂けそうかもある程度把握できました。 限られた時間の中で自分たちが知りたい全ての状況を把握することは難しいですが、今回の打ち合わせで管理状況の全体感を掴むことができたため、今後の詳細な状況確認も容易に進められそうです。
品質監理部門
SaaS事業者とともに、認識を合わせておきたいステークホルダーが、クラウドセキュリティチェックリストの審査者となる品質監理部門でした。
我々がセキュリティ対策として「これで十分」と思っていたとしても、審査者がNG判定をすれば大きな手戻りが発生します。 サービスのリリースが近い状況で手戻りが発生すると、事業として致命的にもなりかねません。
そこで開催したのは、品質監理部門との「セキュリティ対策の妥当性」の確認会でした。 この狙いは以下になります。
- 我々が想定するセキュリティ対策の方向性に問題がある場合、それを早期に検知し修正できる
- セキュリティ対策の方向性に問題がない場合は、事業内容の相互理解に伴う今後の調整の円滑化ができる
確認会のアジェンダは以下としました。また、この段階でチェックリストの各項目に対するざっくりとした対応方針、品質監理部門への確認事項を羅列して臨みました。
- 立ち上げる事業のビジネスモデル、ステークホルダー
- 利用するSaaSのサービス概要、預けるデータの内容、セキュリティ管理体制
- セキュリティ対策の妥当性
品質監理部門がセキュリティ対策としての妥当性を判断するためには、事業にどのようなリスクが存在するのかというインプットが必要になります。 そのためには、事業概要や扱うデータを品質監理部門に理解していただく必要がありました(アジェンダ1と2)。 また、事前に行っていたSaaS事業者との打ち合わせにて認識した事業者側のセキュリティ管理体制も伝えることで、より具体的な情報をベースラインとして対策の妥当性を議論できました。
結論としては、セキュリティ対策としての方向性は妥当であると判断いただけました。 リリースまで効率よくセキュリティ対策を進めていこうと思います。
今回のイテレーションでの学び
今回のイテレーションでの学びは、まず「全体」を押さえる/押さえてもらうことで、方針検討もステークホルダとの調整も効率的に進むということです。
段階的詳細化という技法があります。 (細部はブラックボックスで据え置くとしても)まずは全体を定めておき、その上で細部を詳細化していくという方法で、マネジメントや設計等、多くの方が意識的・無意識的に取り入れているのではないでしょうか。
SaaS事業者も、その事業を展開するビジネス領域や事業者のフェーズによって、セキュリティ管理状況は様々です。 その管理状況への理解が不透明であればあるほど対応すべきセキュリティリスクへの認識が曖昧になり、対策の妥当性もなくなります。 このため今回留意していたことは、最初からSaaS事業者の詳細なセキュリティリスクを確認するのではなく、セキュリティ管理体制の大枠を掴むことでした。
SaaS事業者とともに最初にこの確認をしたことで、当該SaaSのセキュリティ管理状況が大枠として把握でき、リスクの洗い出しとそれに対する対応検討が素早く進みました。 また、品質監理部門にセキュリティ対策の妥当性を確認してもらう点についても、まずは事業の抱える全体的なセキュリティリスクと対策としての方針を伝えることにより、その後の議論を円滑に進めることができました。