Security

ストックマークにおけるB2B SaaSセキュリティへの取り組み

Tags
#AWS
#Security
#Asales
ストックマークにおけるB2B SaaSセキュリティへの取り組み
Page content

こんにちは、ストックマークでSREを担当している松下です。

ストックマークでは企業向けの情報収集・企業分析・営業支援サービス(Anews, Astrategy, Asales)を運営しており、導入を検討されているお客様よりセキュリティの取り組みに関してお問い合わせをいただくことが多々あります。

お客様のセキュリティ基準をプロダクトが満たせるかどうかは、ストックマークにとっても最重要課題であり、ストックマークのセキュリティ向上への姿勢をより分かりやすく示すために、8月にはISMS認証を取得しました。

今回はISMS認証取得を記念して、私が担当しているAsalesを例にしながら、これまでにストックマークが行ってきたセキュリティ対策の一部をざっくりとご紹介させていただこうと思います。

Asalesについて

Asalesはセールスなどの提案資料や社内資料を自然言語処理技術で学習・解析し、売上拡大のために必要な社内ナレッジを共有・レコメンドする営業支援サービスです。

蓄積された提案書を"言葉のAI"が解析することで、提案経験のある社内エキスパートを見つけ出せたり、顧客に響く提案を作成するヒントを得る機会を創出します。

図1: Asalesの機能

提案資料の作成をイメージして「Asalesを利用する流れ」を簡単にご説明すると、

  • エンドユーザーはAsalesに提案資料や社内資料をアップロードする。
  • アップロードされたファイルは機械学習処理により学習・解析され、その結果が保存される。
  • エンドユーザーがAsalesからキーワードや作成者、商材、業界などを指定して検索を行うと、保存された学習・解析結果から最適なスライドを探し当てることができる。

となりますが、Asalesを利用して作成した資料をAsalesにアップロードして、それがまた誰かの役に立って新しい資料がAsalesにアップロードされて、というサイクルが続けば、学習・解析の効果がより高まって「セールスの永久機関になり得るな」と考えたりしています。

セキュリティ対策の検討ポイント

そんなAsalesですが、お客様から「クラウドにアップロードしたデータに第三者がアクセスできない仕組みがあるか」というお問い合わせをよくいただきます。

お問い合わせをいただく中には施設・設備などへの物理的なアクセスを含んでいることがありますが、こちらはAsalesでクラウド基盤として利用するAWSの責任共有モデルという考え方に則って、AWSが行っている対策などを確認して回答しています。

図2: AWSの責任共有モデル

AWSがクラウドのセキュリティに責任を持つのに対して、Asalesはデータの保護や仮想ネットワーク、ミドルウェアの設定・管理など、クラウド内のセキュリティに責任を持って対応しています。

下記のアーキテクチャ図はAsalesのアーキテクチャを5つの層に分けたものですが、「Asalesを利用する流れ」を当てはめてデータ保護の観点からセキュリティ対策の検討ポイント考えるのに利用しました。

図3: セキュリティ対策の検討ポイント

  • アップロード
    (1) エンドユーザーはAWS Elastic Beanstalkで構築したWebサーバーにアクセスし、
    (2) 提案資料や社内資料をAWS S3にアップロードする。
  • 学習・解析
    (3) アップロードされたファイルはAWS Batchで構築した機械学習処理により学習・解析され、
    (4) その結果がAmazon RDS、Amazon Elasticsearch Serviceに保存される。
  • スライド検索
    (5) エンドユーザーがAsalesからキーワードや作成者、商材、業界などを指定して検索を行うと、
    (6) 保存された学習・解析結果から最適なスライドを探し当てることができる。

対応したセキュリティ対策の一例

上記の検討ポイントに対して行った、セキュリティ対策の一例をご紹介します。

ネットワーク

  • アクセス制御（IPアドレス制限）

    企業向けのサービスとして接続元を限定できる手段を検討しました。AWS Elastic Beanstalkの前に置いたAmazon CloudFrontに、AWS WAFを紐付けることでIPアドレスの制限を可能とし、SaaSのメリットとセキュリティ性を両立しています。

  • 通信暗号化

    AWS Certificate ManagerにてSSL/TLS証明書を発行して通信を暗号化してます。

ウェブ・アプリケーション

  • アクセス制御（SAML認証）

    ウェブ・アプリケーションの認証はアプリケーションロジックで対応していましたが、SSOに対応するため、Amazon Cognitoを導入してSAML認証に対応しました。SSO非対応のお客様も認証機能はAmazon Cognitoに集約していますが、認可機能は細やかな対応を可能とするため、引き続きアプリケーションロジックで対応しています。

  • Webサーバーのウイルスチェック

    オープンソース（GPL）のアンチウイルスソフトウェアであるClam AntiVirusをインストールしたカスタムAMIを用意し、ウイルス定義ファイルの更新とウイルスチェックを日次起動する設定を行ってAWS Elastic Beanstalkにて利用しています。

  • Webアプリケーションの脆弱性確認

    国際的なコミュニティであるThe Open Web Application Security Project（通称OWASP）が作成したOWASP ZAPにより定期的な診断を行い脆弱性を確認しています。

オンライン・ストレージ

  • アクセス制御

    Amazon Elasticsearch ServiceをPrivate Subnetに構築し、Security Grooupとアクセスポリシーにて同じVPC内からのアクセスのみ許可する設定を行っています。

永続ストレージ

  • アクセス制御

    • Amazon S3

      エンドユーザーが直接アクセスを行わないため、パブリックアクセスをすべてブロックしています。

    • Amazon RDS

      Amazon RDS（Aurora）は標準ポートを変更してPrivate Subnetに構築し、Security GrooupにてVPC内の限られたリソースのみアクセスを許可する設定を行っています。

  • アップロードファイルのウイルスチェック

    Clam AntiVirusを利用してウイルススキャンを行うAWS Lambdaを作成し、Amazon S3にファイルがアップロードされる都度、ウイルスチェックを行うようにしています。

    常に最新のウイルス定義ファイルを利用するために、ウイルス定義ファイルを更新するAWS Lambdaを作成して1日に数回の確認を行っています。

  • データ暗号化

    Amazon S3、Amazon RDSともに、AWS KMSで作成した暗号化キーを用いて暗号化しています。

機械学習バッチ・アプリケーション

  • アクセス制御

    AWS Batchのコンピューティング環境にPrivate Subnetを指定し、接続できるリソースをSecurity Groupで制限しています。

  • 脆弱性確認

    AWS Batchが動作するDockerイメージに対して、定期的にAmazon ECRのイメージスキャンを実施して脆弱性を確認しています。

アーキテクチャ図

ここまでにご紹介したセキュリティ対策を実施したAsalesのアーキテクチャは下記のようになります。

図6: Asalesのアーキテクチャ図

上記以外にも、Amazon API GatewayとAWS Lambdaでログ取得APIを作成したり、パスワードなどの情報をAWS Systems Managerのパラメータストアに格納したりと、セキュリティに関わる対策を検討して実施していますが、一旦ここでは割愛させていただきます。

まとめ

いかがでしたでしょうか。

ストックマークで行ったセキュリティ対策について、一部ですが概要をご紹介させていただきました。

セキュリティ対応は基本的に終わることはないと考えていますが、普段から必要と思われる機能の検討を重ねておくことや、セキュリティを意識して開発することは大切だなと再認識しました。

SSO認証などは検証時と導入時で色々な苦労もしたので、機会があれば詳細にご紹介させていただこうと考えています。

さいごのさいごに

冒頭でISMS認証取得を記念してと書きましたが、私は特に何もしていません。
ご担当された皆様、お疲れさまでした！

参考