セキュリティレビューに向けた準備

学習の目的

この単元を完了すると、次のことができるようになります。

  • セキュリティレビューの目的を説明する。
  • セキュリティレビューの内容を概説する。
  • セキュリティレビューの範囲を要約する。
  • セキュリティレビューの準備に役立つと思われるツールを挙げる。
  • スキャナでできることとできないことを説明する。

レビューの流れについて

現在までに、OWASP トップ 10 リストをブックマークしているものと思います。データが包括的に保護されるような形でソリューションを設計したら、セキュアなコーディングの手法に従って構築していきます。

ソリューションにはこの後セキュリティレビュープロセスが控え、レビューに合格しなければ AppExchange に公開できないことは知っています。ところで、セキュリティレビューとは具体的にどういったものなのでしょうか?

安全な環境での防御策のテスト

ソリューションをテストすることなく、機能は正常に動作すると断言できると思いますか? もちろん、そんなことはできません。

ソリューションで最も重要な機能の 1 つが、顧客データの保護です。Salesforce では、この機能を極めて重視し、パートナーもテストできるようにしています。

セキュリティレビューでは、当社の製品セキュリティチームが、OWASP リストに挙げられている攻撃に対する製品の防御策をテストします。当社のテスト担当者が強盗マスクをかぶり、数時間に及ぶ集中的なセッションでソリューションへの侵入を試みます。同担当者の使命は、アクセス権のないデータを窃取することです。

初回のテストに合格しなかった場合……

当社のチームがソリューションからまんまとデータを盗み出した場合には、同チームが突破口となった脆弱性をリストしたレポートを送信します。この情報を基にソリューションを強化することができ、準備ができたら再度セキュリティレビューを受ける必要があります。このプロセスについては、後続の単元で詳しく説明します。データを盗まれれば面白くありません。けれども、実際の顧客データを窃取されるよりははるかにましです。

どのテストスキームの場合とも同様に、このセキュリティレビューはすべてを網羅するものではありません。潜在的なあらゆる脆弱性がテストされるのではないため、レビューに合格したからといってソリューションのセキュリティが万全であるというお墨付きがもらえるわけではありません。けれども、製品をテストすることで品質に対する自信が高まるのと同様に、セキュリティレビューでは製品の防御策を増強するうえで極めて重要なフィードバックが提供されます。セキュリティを保証する製品など存在しませんが、セキュリティレビューに合格したソリューションはかなりそれに近いものになります。

製品全体がレビューの対象

あなたのソリューションは、Salesforce Platform 上にのみ存在するネイティブソリューションでしょうか? それとも、クラウドや企業サーバのような場所にも存在するアーキテクチャコンポーネントやサービスを備えた複合アプリケーションでしょうか? 外部でホストされている要素も、他の部分と同様に安全でなければなりません。さもなければ、強盗が排気管から侵入してくるように、攻撃者が外部の要素を侵入地点として忍び込みます。ソリューションのコンポーネントやサービスは一様に、存在する場所に関係なく、セキュリティレビューの対象になります。

以下は、一定の典型的なソリューションアーキテクチャとその存在場所を示しています。

ソリューションアーキテクチャ 存在場所
Salesforce Platform プラットフォーム外 ネイティブモバイルアプリケーション
100% ネイティブ カスタムオブジェクト
Custom Lightning コンポーネント
カスタム Apex コード

外部サービスを備えた複合ソリューション カスタムオブジェクト
Apex コード
 サービス (AWS や Rackspace などの別のプラットフォームでホストされている地図など)
モバイルアプリケーションを備えた複合ソリューション カスタムオブジェクト
Apex コード
ワークフロー
iOS および Android 用のネイティブアプリケーション
API 限定ソリューション 接続アプリケーション プラットフォームでホストされているデータの読み書きを行うスタンドアロンソリューション(取引や商談とやりとりする会計ソリューションなど)
Lightning Bolt ソリューション Lightning コンポーネント
Apex コード

Tableau CRM ソリューション アプリケーション
ダッシュボード
レンズ
データセット
データフロー
カスタムオブジェクト

製品セキュリティチームは、プラットフォーム上にあるものに限らず、このすべての要素に対する攻撃を試みます。深部まで潜入してあらゆる場所のデータを盗みに行きます。こうしたテストを念頭に置いて計画を立てましょう! たとえば、ネイティブモバイルアプリケーションはすばらしいユーザエクスペリエンスをもたらしますが、どのように構築していくかによって、保護に相当の作業が必要になる場合があります。

すべてを提出

ソリューションのレビューを申請するときは、完全なテスト設定とその使用に関する説明を提出します。この設定には、管理パッケージがインストールされた Developer Edition 組織が含まれている場合があります。

ソリューションにネイティブモバイルアプリケーションが含まれる場合は、そのインストールリンクも必要です。外部の Web ベースの会計サービスを統合している場合には、そのサービスをホストするインスタンスを設定するか、サイトのテストアカウントのログイン情報を提供します。一般に、必要な提出物を決めるときに確実な方法は、セキュリティレビューチームを、ソリューション全体を徹底的に試用する潜在顧客であると想像することです。迷ったときには、『ISVforce ガイド』のセキュリティ情報を参照してください。

スキャナを使用した独自のレビューの実施

セキュリティレビューのプロセスに多少なりとも不安を感じているかもしれませんが、心配いりません。あなたの製品を AppExchange に公開したいのは当社も同じで、このプロセスもその一環です。当社では、前述のリソースのほか、製品レビューに備えてチームが使用できるスキャナを用意しています。

これらのスキャナは、ソリューションに特定の脆弱性パターンがないか探して回ります。スキャナは開発プロセスの初期でも役立ちます。当社では次の 3 種類をサポートしています。

スキャナ 説明 使用状況
Checkmarx プラットフォームでホストされているソリューションをスキャンします。 ソリューションに Apex コード、Visualforce 要素、管理パッケージがある場合。
Chimera 1 つのサービスにオープンソース最高レベルのスキャン技術を統合します。キメラとは、数種の動物の各々の最強部位を組み合わせた神話上の猛獣です。Heroku を搭載しています。 ソリューションに、制御下の別のプラットフォームに存在する要素がある場合
ZAP OWASP が作成した無料のオンラインスキャナで、ローカルシステムにインストールする必要があります。 ソリューションの一部が、制御下にないドメインにリリースされている場合

上記のスキャナは、製品で検出されたすべての脆弱性を記載したレポートを生成します。もちろん、世の中に存在するあらゆる脆弱性を検出することはできません。

偽陽性

時として、スキャナが実際には問題でない事象を報告することがあります。たとえば、スキャナが保護対策済みの脆弱性パターンを検出することや、採用した保護対策を認識できないことがあります。こうしたエラーを偽陽性といいます。

たとえば、悪質な SQL クエリから保護するために一定のコードを追記したのに、この脆弱性がコードによって対処されることをスキャナが認識しないとします。この場合、スキャナが SQL インジェクション脆弱性を報告します。こうした報告は偽陽性と解釈します。

エラーが偽陽性であると思われる場合は、その理由を説明するドキュメントを作成して、セキュリティレビューの資料に追加します。報告された脆弱性をどのように防御しているかを具体的に説明します。後から当社があなたに連絡して、説明を求める必要がなくなれば、全員の時間を節約できます。

スキャナのレポートの解釈方法

3 種類のスキャナは作成者も実行するプラットフォームも異なるため、生成されるレポートが異なります。次の表は、各レポートの内容への対処方法を示しています。

スキャナ 修正 無視
Checkmarx 低、中、高のいずれかに分類されたエラー 情報提供の警告
Chimera 偽陽性を除くすべてのエラー 重大度が低い警告で、偽陽性と判断したもの。レビュー資料のドキュメントに理由を説明する。
ZAP 右の列に記載されているものを除くすべてのエラー。エラーを修正したら、正しい外部エンドポイントがスキャンされていることを確認するために、スキャンのスクリーンショットをレビュー資料と一緒に提出します。 このリンク先の問題 (問題を緩和しても構いませんが、修正する必要はありません)。他の偽陽性はすべて記録します。

各自のソリューションをハッキングしてみる

スキャナも有用ですが、人の知恵に勝るものはありません。検出されたセキュリティ問題をすべて修正したら、さらなる調査を試みます! テスト担当者をハッカーになぞらえます。

チームのセキュリティ推進者と一緒に、敵対的テスト計画を考案します。このテストでは、各自のソリューションを攻撃してそのデータの窃取を試みます。『OWASP テスティングガイド』にこの手法が詳しく説明されています。

ハッカーを装ったテスト担当者にソリューションが実行されているインスタンスを渡したら、顧客データやシステムデータに不正にアクセスするという使命に自由に取り組ませます。攻撃に成功した場合の賞品を用意しておきましょう。

敵対的テストから驚くべき結果が得られることがあります。「確かに修正したはずなのに!」と思うかもしれませんし、チームメイトがなんでこんなにハッキングに長けているのかと不思議に思うかもしれません。いずれにしろ、テスト担当者にハッキングされるほうが、それ以外の何者かにハッキングされるよりはるかにましです。

次の単元では、申請プロセスそのものを順に見ていきます。

リソース