Skip to main content
From 16:00 UTC on January 17, 2026, to 20:00 UTC on January 17, 2026, we will perform planned maintenance on the Trailhead, myTrailhead, and Trailblazer Community sites. During the maintenance, these sites will be unavailable, and users won't be able to access them. Please plan your activities around this required maintenance.

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

学習の目的

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

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

レビューの流れについて

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

管理パッケージ、Salesforce Platform API ソリューション、または Marketing Cloud Engagement API ソリューションを作成している方は、この後にソリューションのセキュリティレビュープロセスが控えていることをご存じだと思います。また、レビューに合格しなければ AppExchange に公開できないこともご存じですね。ところで、セキュリティレビューとは具体的にどういったものなのでしょうか?

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

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

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

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

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

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

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

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

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

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

ソリューションアーキテクチャ

存在場所

Salesforce Platform

プラットフォーム外

ネイティブモバイルアプリケーション

100% ネイティブ

カスタムオブジェクト

カスタム Lightning コンポーネント

カスタム Apex コード

外部サービスを備えた複合ソリューション

カスタムオブジェクト

Apex コード

サービス (AWS や Rackspace などの別のプラットフォームでホストされている地図など)

モバイルアプリケーションを備えた複合ソリューション

カスタムオブジェクト

Apex コード

ワークフロー

iOS および Android 用のネイティブアプリケーション

API 限定ソリューション

接続アプリケーション

プラットフォームでホストされているデータの読み書きを行うスタンドアロンソリューション (取引や商談とやり取りする会計ソリューションなど)

Lightning Bolt ソリューション

Lightning コンポーネント

Apex コード

CRM Analytics ソリューション

アプリケーション

ダッシュボード

レンズ

データセット

データフロー

カスタムオブジェクト

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

すべてを提出

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

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

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

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

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

スキャナー

説明

使用状況

Salesforce Code Analyzer

複数のルールエンジン (Apex、Visualforce、JavaScript、TypeScript) を使用してコードをスキャンします。継続的インテグレーション (CI) プロセスに統合して、コードの状態を定期的に監視します。外部エンドポイントはスキャンしません。Salesforce CLI を搭載しています。

管理パッケージを掲載する場合。セキュリティレビューと共にコードアナライザースキャンレポートが必要です。また、スキャンルールをCI プロセスに統合する場合にもコードアナライザーを使用します。

Checkmarx

プラットフォームでホストされているソリューションをスキャンします。

ソリューションに Apex コード、Visualforce 要素、管理パッケージがある場合

ZAP、BURP、その他の DAST スキャナー

これらは無料のオンラインスキャナーで、ローカルシステムへのインストールが必要です。

ソリューションの一部が、制御下にないドメインにリリースされている場合

パートナーは、BURP やその他の DAST スキャナーを使用して外部エンドポイントをスキャンし、問題のないレポートを申請に添付することもできます。

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

偽陽性

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

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

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

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

4 種類のスキャナーは作成者も実行するプラットフォームも異なるため、生成されるレポートが異なります。管理パッケージの申請に Salesforce コードアナライザーレポートを含める必要があります。

次の表は、申請に含めるレポートへの対処方法を示しています。

スキャナー

修正

無視

Salesforce コードアナライザー

すべてのセキュリティ関連の発見事項と、偽陽性以外のすべてのエラー。

セキュリティに関連しない発見事項 (コード品質、パフォーマンス、スタイルに関する発見事項など)。

Checkmarx

低、中、高のいずれかに分類された発見事項。

情報提供の警告

ZAP、BURP、その他の DAST スキャナー

右の列に記載されているものを除くすべての発見事項。エラーを修正したら、正しい外部エンドポイントがスキャンされていることを確認するために、スキャンのスクリーンショットをレビュー資料と一緒に提出します。

このリンク先の問題 (問題を緩和しても構いませんが、修正する必要はありません)。ほかの偽陽性はすべて記録します。

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

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

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

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

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

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

リソース

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む