hey Product Blog

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

heyのセキュリティエンジニアはどんな仕事をしているの?

こんにちは。hey のセキュリティ本部に所属している清水です。この記事では、hey のセキュリティ本部がいまどんな仕事をしているのか、その内容を紹介していきたいと思います。hey のセキュリティエンジニアがどんな仕事をしているのか興味ある方の参考となれば幸いです。

セキュリティ本部の紹介

セキュリティ本部では、"STORES プラットフォーム に内在するセキュリティリスクを適切にコントロールする" をミッションに日々様々な活動をしており、hey のサービス全体(ネットショップ, 決済, 予約, 認証・API・データ分析などの共通基盤)に渡ってセキュリティをみています。

セキュリティ関連の業務は基本的にはセキュリティ本部で取り扱っていますが、必要に応じて他部署と連携して仕事を進めます。特に継続的に連携する機会の多い部署は、IT本部とリーガル・コンプライアンス本部です。IT本部とは、社内で利用される各種ツールのセキュリティ要件の策定やその運用の相談、リーガル・コンプライアンス本部とは、セキュリティと関連の深い各種法令(個人情報保護法, 割賦販売法など)や外部認証(ISMS, PCIDSS)の取得・運用に関わる相談をすることが多いです。また、それぞれのサービスの開発部署と、セキュリティ要件の策定や脆弱性の対応方法について、相談する機会が多くあります。このようにセキュリティ本部はセキュリティがメインの業務ですが、他部署とコミュニケーションをとる機会が多いです。

セキュリティ本部のお仕事

セキュリティ本部の仕事内容について、少し細かく見ていきます。

外部機関による認証の取得・運用

hey では外部機関による認証をいくつか取得しており、現在も追加で認証を取得する準備や、現在取得している認証維持のための運用を行っています。

ISMS(Information Security Management System)

ISMSは、STORES 予約 では既に取得済みとなります。来年の初旬を目標に、全社でのISMS認証の取得を目指しています。今年は、このISMS認証の取得に向けてセキュリティ本部では一定のリソースを継続的に割り当ててきました。

社内のセキュリティ組織体制の確立、情報セキュリティポリシー・規程の策定、情報資産管理台帳の作成と運用、社内セキュリティ教育の実施、緊急時リスク対応のBCP(事業継続計画)の策定など、様々なISMS取得のための情報セキュリティ管理体制の整備を行い、現在は外部監査人による審査を受ける段階まで進んでいます。

PCIDSS(Payment Card Industry Data Security Standard)

PCIDSSは、STORES 決済 では既に準拠済みとなります。最近の割賦販売法の改正により、ネットショップ作成サービスの STORES がPCIDSSの準拠対象となるため準拠に向けた対応を進めています。準拠に向けてどんなタスクがあるのか、その一部を紹介すると以下のようになります。

  • 自己問診票(SAQ)の作成と審査
  • 脆弱性診断(ASV

STORES では、自己問診でPCIDSS準拠を目指すため、自己問診票(SAQ)の作成と第三者機関による審査対応を行います。PCIDSS準拠のためには、ASV(Approved Scanning Vendor)によるサイトスキャン検査も必要となるため、その実施調整や対応を行っています。

ITGC(IT全般統制)

hey では、今後の事業発展を見据え、システムをより安全かつ効率的で信頼されるように運用することを目的として、ITGC(IT全般統制)の整備を進めています。セキュリティ本部では、hey のシステム開発・保守体制に合ったITGCを実現するために、以下の業務の整備を関係部署と共に取り組んでいます。

  • アプリケーションシステム変更
  • アプリケーションシステムへのアクセス権限管理
  • 本番データの修正
  • システム運用管理
  • インフラシステム変更
  • インフラシステムへのアクセス権限管理

セキュリティに関する問い合わせ対応

セキュリティチェックシートの記入

hey の提供するサービス利用を検討されている組織から、hey のセキュリティ状況について自組織の用意したセキュリティチェックシートに回答して欲しいという依頼を受けます。セキュリティに関する質問は、基本的にはセキュリティ本部で内容を確認して回答するようにしています。セキュリティ本部だけで回答の難しい質問は、IT本部やリーガル・コンプライアンス本部と相談しながら回答を作成します。

セキュリティの評価

外部サービス・業務委託先の審査

様々な事業部から上がってくるSaaSなどの外部サービスや業務委託の利用申請について、セキュリティ・コンプライアンス的に問題ないかどうか審査をします。外部認証の取得状況、事業者へのアンケート(hey から送るセキュリティチェックシート)の回答結果、SaaSサービスで取り扱うデータ内容を総合的にみて、利用可否の判断を行います。利用される外部サービス・業務委託の情報は各種台帳に登録して管理されます。

外部サービスの導入相談

システムと連携予定の外部のSaaS, PaaSサービスについて、利用方法にセキュリティインシデントに繋がるような潜在的な問題がないかどうかレビューして、エンジニアやプロダクトマネージャーと相談しながら採用の可否を判断します。セキュリティ的にリスクがあると判断された場合は、リスク低減のためのセキュリティ要件をチケットに起票して開発チームに対応をお願いする場合があります。

セキュリティ要件定義

設計レビュー

新プロダクトや機能の設計段階で、セキュリティ・コンプライアンス要件を満たした設計となっているか、脆弱性に繋がるような仕様が混入してないかのレビューを行います。システムの設計内容と必要なセキュリティ・コンプライアンス要件に差分のある場合は、チケット化して開発ロードマップの中に組み込むことで対応するように調整をお願いしています。

脆弱性診断

新しい機能やプロダクトの実装の後に、必要な場合は脆弱性診断を行なっています。現在の hey では、内製と外部ベンダーのハイブリッド方式で脆弱性診断を実施しています。

WEBアプリ診断

内製で診断するときは、診断対象をクローリング、診断項目をスプレッドシートなどにまとめて、Burp Suiteを利用して脆弱性診断をしています。WEBアプリ診断がいまのところ一番工数がかかっており、全てのプロダクトの診断は難しいため、一部のプロダクトについては外部ベンダーに診断を依頼しています。外部ベンダーへの依頼では、開発チームと外部ベンダーとのコミュニケーションの調整役をセキュリティ本部が担います。

ソースコード診断

ソースコードの静的解析をするツールを利用して、最新のmasterブランチに対するソースコード診断を毎営業日に自動で実施しています。現在はRailsアプリのみ診断する実行環境を構築できている状態ですが、今後、Rails以外のJavaやGoについても診断出来るように拡張する予定です。

ソフトウェア脆弱性管理

OS内部にインストールされているソフトウェアに脆弱性がないかどうか、Amazon Inspectorで確認します。脆弱性が新たに検出されたものについてはそのリスクを確認して、リスクの高いものを中心にSREと相談しながら対応時期を調整して進めています。

プラットフォーム診断

インターネットと接するサービス上のグローバルIPに対して、攻撃可能なポートや不要なサービスが稼働していないかプラットフォーム診断を定期的に実行しています。セキュリティ本部ではプラットフォーム診断を実行する基盤をAWS上に構築して運用しています。

パブリッククラウド診断

AWSGCPなどのパブリッククラウド環境で、外部からの脅威に対して脆弱性のある設定はないかどうか定期的に監査をしています。手動による診断には時間的な工数の限界があるので、Security Hub などパブリッククラウドで提供されているセキュリティ用の監査ツールを組み合わせてある程度自動的に脆弱性を検知できる環境の構築を進めています。

セキュリティ教育・普及

セキュリティ本部では従業員に向けたセキュリティ教育の資料作成や実施、受講状況の取りまとめを行っています。セキュリティ教育は、セキュリティインシデント防止のためはもちろんですが、ISMSやPCIDSSでも要求される内容なので定期的に実施する必要があります。全従業員向けにはプリンタの使い方や机周りの整理など、開発者向けにはストレージ設計時のセキュリティ要件やログ保管期間のガイドラインをなど、セキュリティに関係する様々な内容を取り扱っています。

Eラーニングの作成

新入社員や既存社員向けのセキュリティ教育コンテンツを作成して定期的に受講してもらっています。Eラーニングの問題で間違いの多かったものについてはその内容を分析をして、今後のセキュリティ教育でどこに重点を置けば良いのか判断するのに利用しています。

ガイドラインの作成

hey 社内にはセキュリティ規定があり、そのセキュリティ規定を遵守するためにどのような手順を踏めばよいかわかるように、ガイドラインを用意しています。例えば、”外部組織とデータを共有する時には必要最低限の権限にしてアクセス履歴を保存するように”と規定に記載されていた場合、それをどのように通常業務のなかで実現すれば良いか、具体的な手順を解説したものがガイドラインとなります。需要のあるガイドラインから優先的に作成を進めています。

セキュリティマネジメント

社内全体で統制あるセキュリティ管理状態を維持するために、セキュリティ管理のための組織体制の整備、情報セキュリティポリシー・規定の策定・普及、情報資産管理台帳の運用を行なっています。

セキュリティ管理組織体制の整備

社内全体にわたって統制のとれたセキュリティ管理状態を維持するために、情報セキュリティの組織体制を整備しています。情報セキュリティ管理責任者、内部監査担当者、各部門に情報セキュリティ担当者を配置して、社内の情報セキュリティポリシーや規定が全従業員に周知・実践される体制の構築を進めています。

情報セキュリティポリシー・規定の制定・周知

社内の情報セキュリティポリシー・規定は、セキュリティ本部、IT本部、リーガル・コンプライアンス本部が中心となりその制定や改定を行っています。セキュリティポリシー・規定は全従業員に周知・把握されてなくてはならないので、より容易に参照できるように社内のドキュメント管理システムから参照できる環境構築を準備しています。また、現状に即した生きた規定となるようにレビューと改定方法を明確化した運用ルールの整備を進めています。

情報資産管理台帳の運用

社内で扱われている個人情報などの重要な情報資産が、どこでどのように保管されているか正しく把握するために情報資産管理台帳を作成して運用しています。新規に利用するツールなどに情報資産を置く場合は、情報資産管理台帳に情報の種類・保管形態・保管場所・保存期間などを記帳して管理します。また、定期的に情報資産管理台帳に記載されているものの棚卸し作業を行っています。

インシデント対応

セキュリティインシデントはもちろん発生しない方が良いですが、万一発生した場合に備えて、どのように対処するかの準備を他部署と連携しながら進めています。

BCP策定

BCP(事業継続計画)は、災害やシステム障害などの緊急時において、重要なサービスを継続して提供できるようにする計画のことを言います。システム障害や情報漏洩インシデント、自然災害など様々な緊急事態を想定したBCPを策定して、現実となった時でもBCPに従って速やかな復旧・被害の最小化を図れる体制を整えるようにします。セキュリティ本部でシステムの稼働状況の全てを把握しているわけではないので、関連する他部署と連携しながらBCPの策定作業を進めています。


以上で、セキュリティ本部で担当している仕事内容の8割以上は紹介できたのではないかと思います。書き出してみると思った以上に多くなりましたが、まだCSIRT体制の整備、SIEM分析基盤の構築、モバイルアプリ脆弱性診断、SaaS設定の脆弱性診断など対応を十分にとれていない部分もあります。

hey は今どんどん成長している組織のため、セキュリティ本部の仕事内容もより広く、より深く変化している途上です。もし機会があれば、来年も同じようにセキュリティ本部の仕事内容をスナップショット的にブログに紹介していきたいと思います。きっと、今年紹介した仕事内容からまた変化していると思います。

今回紹介したセキュリティ本部の仕事内容のスナップショット差分をより大きくしてくれる方、セキュリティに関する施策をどんどん策定・実行いただける方を募集しています。もし、興味を持っていただけましたら、カジュアル面談から気軽にエントリーください。

herp.careers