hey Product Blog

こだわりを持ったお商売を支えるプラットフォーム「STORES」の開発チームによる技術ブログです。

社内セキュリティ座談会 〜 heyで目指しているセキュリティの在り方 〜

heyのテクノロジー部門セキュリティ本部のtyabeです。

セキュリティ本部は"STORES プラットフォームに内在するセキュリティリスクを適切にコントロールする"ことをミッションとして、社内の色々な人と協力しながら活動を行っているチームです。
社内で広く活動するに当たって、どのメンバーがどういった想いで活動しているのかもっと広く知っていてもらいたいと考え、社内向けに座談会を開催しました。

テーマ

  1. セキュリティの仕事を始めたきっかけ
  2. heyで目指しているセキュリティの在り方
  3. 事業を支えるセキュリティとは

の3つのテーマをゆるく雑談する形式で実施したのですが、今回はその中の "heyで目指しているセキュリティの在り方" を記事にしました。

登場人物紹介

  • yoshio:社内向けセキュリティ施策全般を担当。今回のファシリテーター
  • tyabe:主に雑務を担当。マネージャー
  • yokoyama:主に脆弱性診断を担当
  • toripiyo:主にインフラの脆弱性診断を担当
  • kaori:主にISMSを担当

heyで目指しているセキュリティの在り方

ルールが守られるように、ルートまできちんと整備する

yoshio:それでは、第1回セキュリティ本部の座談会を開始しようと思います! 皆さんよろしくお願いします。

今回の座談会のテーマは、「heyで目指しているセキュリティの在り方」です。

おそらく、heyで働かれている方やプロダクトを作られている方にとっては、どんなセキュリティ管理を行っていくのか、実装をどうしているのかなどが、気になるところかと思います。
現時点で、目指してるところについてみんなそれぞれ考えていることがあると思うので、その話をしていきたいと思います。

それではまず、私から話していきます。

私は前職もベンチャー企業でしたが、ルールを作って周知したからといって必ず守られるような状況ではありませんでした。実際、うまく回ってる部分もあれば回らないところもあって、セキュリティ分野はどちらかというとうまく回らない部類に入っていたと、個人的には思っています。セキュリティ以外のリーガルであったりコーポレート系も同じく苦戦していました。
ですので、前職から学んだ点を踏まえると『ルールで縛るセキュリティはやめよう』という考えに至っています。

ルールを決めるのであれば、同時に仕組みも導入し、そのルールが守られるように、ルートまできちんと整備することが必要だと思っています。ルールで縛る、というのではなく、同時に仕組みもつくって、自然な流れでセキュリティの守られた状態を作り上げることを目指したいと考えています。

社内環境としてはそういうことを目指したいと思っています。

では、次はtyabeさんのほうからお願いしてよろしいですか。

利用者が意識しなくても安全に使える状態を作る

tyabe:自分がセキュリティでこうありたいと思うのは、サービスを利用いただいている方に対しての安心がきちんと担保できているということです。

それは、STORESで言うと購入者さんやオーナーさん、両者とも安心して使ってもらえる環境をどうやって提供していくのかというところですね。利用者が意識しなくても安全に使える状態を作るのが一番いいと思ってるので、その考えを軸にいろいろ施策を回していけると良いかなと考えてます。

yoshio:私も、セキュリティを意識しないでも安全だよ!という状態を作り出せるのが、プロダクトシステムとしてもいいのかなって思います。プロダクトシステムに対する施策と社内セキュリティに対する施策の両輪で回していければな、と考えています。

ありがとうございます。では、yokoyamaさんお願いします。

どこまでリスクを許容するか検討・対策する

yokoyama:法令遵守してコンプライアンスを守ること、リスク回避ではなく可能な範囲でリスクを許容できることが大事だと考えています。

法令遵守は当然のことなのですが、取り扱っている情報に関して、関連する法令で規定されていることがあるので、情報セキュリティ対策と合わせて関連法令等を遵守できるよう施策する必要があります。 例えば、個人情報をセキュアなクラウドサービスで取り扱うことで不正アクセスなどのセキュリティリスクに対して万全の対策をしていても、運用方法を誤り法令遵守できていない。といったことがないようにする必要があると思っています。

セキュリティ本部は法規の専門家ではないので判断が難しい場合も多いのですが、リーガル部門に気軽に相談できる環境なのでとてもありがたいと感じています。

リスク回避のために利用を禁止するのではなく、どこまでリスクを許容するか検討・対策することが大事だと思っています。 例えば、新たにクラウドサービスなどの情報システムを利用する場合に必ず何かしらのセキュリティリスクは内在しますが、利用禁止ではなく、ここまでやればリスクを軽減できるという範囲を検討して、リスク許容することも大事だと思っています。

こういった落としどころをうまく探り、皆さんにセキュリティの担保されたITを活用してもらうことが大事だと考えています。ただ、このリスク許容のバランスがとても難しい。

yoshio:ありがとうございます。われわれの中でも、ここまでならリスク許容できるという、ベースラインをしっかり決めておかないといけないなと思いました。

もちろん、ものによってリスクの大きさは異なりますし、それによって必要な対策もそれぞれ違うとはいえ、ここまでやりましょうよ!と、具体的なイメージを示していけると、社内でもわかりやすくセキュリティのリスクを説明していけるのかなと思いました。難しいとは思いますけど、やっていければなと思います。

yokoyama:そうですね。一つ一つ取り組みたいです。

セキュリティ強化にかける工数を減らしたい

yoshio:ありがとうございます。では、次はtoripiyoさんお願いします。

toripiyo:目指してるセキュリティの在り方の一つとしては、なるべくセキュリティ強化にかける工数を減らせていければと考えています。

一つの事例として、いま複数のAWSアカウントを一つのOrganizationにまとめる作業を進めているのですが、これはAWSアカウントのセキュリティに対する工数を減らすために取り組んでいまして、AWSアカウントを開発者に渡すときに、既にセキュリティの設定が終わっていれば、その開発者がセキュリティ設定をする工数を減らせると考えています。

CloudTrailとかGuardDutyとか、AWS Configとか、その他もろもろのAWSアカウントに関するセキュリティ設定は、しっかり取り組むと開発者の工数を取られてしまうんですよね。ですので、AWSアカウントの開発者への引き渡し時に、既にベースラインとなるセキュリティ設定の施された状態で渡せれば、開発者の工数を減らせるし、一定程度のセキュリティが担保された状態でAWSアカウント全体を運用できるようになると考えています。

その他には、セキュリティに関する社内向けの開発ガイドラインを整備していますが、この活動もセキュリティ対策に重きをおいて取り組んでほしいと要求された時に具体的にどんなことをやれば良いか開発者が考える手助けになると思います。

セキュリティ面の設計にかける工数を減らせるようにして、こういったものに従っていけばセキュリティを担保できるようになりますよというガイドラインを作って、セキュリティを遵守するための開発全体の負荷を減らせるようにと、いまいろいろと取り組んでいるところです。

yoshio:ありがとうございます。

コンプライアンスもそうですし、セキュリティも含めてですが、何かを守ろうとしたり、強化しようとすると、やっぱり、人の対応リソースやお金といったコストがかかってきてしまいます。それを最小限にしながら理想の状態を作るためには、セキュリティの専門性が高い人というと誤解を招くかもしれませんが、ポイントを的確に把握できている人がいれば、そこへの近道を明確に示していけるんじゃないかと思います。

個人的には、どんどんそういう点も今後も進めていきたいので、引き続きいろいろ一緒にやれたらなと思ってます。よろしくお願いします。

yokoyama:セキュリティはトレードオフなので、セキュリティを強化するとその分利便性やコストもかかるので難しいところですよね。

ビジネスとセキュリティのバランス

yoshio:それでは、最後にkaoriさん、よろしくお願いします。

kaori:大体皆さんがおっしゃったことと同じです(笑)。一応、メモを用意していたのですが、皆さんに先に言われたことばかりで、何か良いこと言えないかなって考えながら聞いていました。

やはり、toripiyoさんのおっしゃってたとおり、いかにビジネスを妨げないようにしながら、あと、tyabeさんやyoshioさんやyokoyamaさんのおっしゃっていたとおり、可能な限り、自動化やシステム化して、例えば、社内のユーザーだったら、危険なサイトに訪問しても安全性を保てるようなシステムを導入することなどができたらいいと思います。

あと、STORES プラットフォームの各サービスのユーザーさんが、セキュリティを意識せずに使っても安心安全を担保できるようなかたちが理想で、目指しているセキュリティの在り方です。

他には、ビジネスを重視したいと考えています。前職の事業会社に、「早い者に価値がある」というスローガンがあったのですが、私も本当にそうだと実感しています。

例えば、少しローンチの時期が遅れると、競合他社が似たようなサービス開始を発表してくることが往々にしてありますが、yokoyamaさんのおっしゃってるように、利便性やスピード感とセキュリティとのトレードオフにならないように、時間をかけすぎないで、いかに強固なセキュリティ性を担保できるかというのが、私たちセキュリティ本部の腕の見せどころかなと思います。

yoshio:ありがとうございます。

そうですよね。ビジネス機会を失わせるようなセキュリティの担保の仕方というのは、個人的な過去の経験から言わせて頂くと、トラディショナルな企業ではありがちかもしれないです。

kaori:あと、業界の特徴として、セキュリティの担保を重視している企業が多い業界もありますね。

yoshio:そうですね。

kaori:例えば銀行などは、セキュリティ対策を重点的にしないといけない面もあります。

yoshio:heyの場合は、選択肢があるというか、いい案配を見つけることができるようなビジネスをしてると思っています。

うまいことわれわれセキュリティ本部が、落とし所を提案するなど、ここを担保していれば大丈夫みたいなところを示しながら、ビジネスにフォーカスしていけるような状態を作り上げることが重要になってくるかなと思います。

最後にkaoriさんにまとめていただいたとおり、社内もプロダクトも、どちらも、顧客とか従業員に限らず、安心して利用いただけるようにして、ビジネスのスケールに常に寄与できる状態にするのが一番重要かなと思います。

おわりに

heyでは社内とプロダクトのセキュリティをよりよくしていく仲間を募集しています!
お話を聞いていただけるだけでも大歓迎ですので、よろしくお願いします。

hey.jp

hello.hey.jp