レビュープロセスの完了およびソリューションのリスト

学習の目的

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

  • 製品セキュリティチームによる脆弱性の報告方法を説明する。
  • セキュリティ上の問題を修正したうえでソリューションのレビューを再申請する方法を説明する。
  • ソリューションが承認された後に公開する手順を挙げる。

現実に向き合う

たった今、Salesforce セキュリティチームからメールが届きました。ソリューションのレビューが完了しました。何週間もこのメールを待っていたため、ドキドキします。心のどこかでは開けることを恐れてもいます。「合格しなかったらどうしよう?」という不安があるためです。

製品のセキュリティレビューに初回で合格しなくても、何ら珍しいことではありません。申請された全製品の半分は、初回のセキュリティレビューで不合格になっています。セキュリティの確保は容易なことではありません! セキュリティを手軽に装備できるのであれば、セキュリティレビューのプロセスは必要ありません。

セキュリティレビューの結果には不合格と合格がありますが、ソリューション開発の過程でどちらも経験する可能性が高いため、この両方を見ていきましょう。

めげない

セキュリティレビューで「合格する」と述べてきたため、セキュリティレビューは合格するか否かの試験であると考えているかもしれません。ただし、実際にはそれほど明快なものではありません。レビューはセキュリティチームからのフィードバックと考えることができます。製品の品質を向上させ、無事公開できるようにするフィードバックです。

製品がセキュリティレビューに合格しなかった場合は、セキュリティチームが検出した脆弱性をリストしたレポート形式でフィードバックを受け取ります。受信したメールには、これらの脆弱性を修正する詳細な手順も記載されています。

セキュリティレポート

このレポートの良い点は、検出された問題の具体的な説明が示されていることです。レポートの冒頭には、次のようなハイパーリンクされた目次が表示されます。

  1. SOQL インジェクションの脆弱性...
  2. デバッグの脆弱性の機密情報...
  3. 情報開示の脆弱性...
  4. CRUD/FLS 適用の脆弱性...

目次のタイトルは、セキュリティの脆弱性の種類です。各タイトルの下に、脆弱性が検出されたコンポーネント名が記されています。目次の後に、それぞれの脆弱性の詳しい説明が続きます。タイトルをクリックすると、対応する説明に移動します。

レビューの広く浅い調査結果を各自が徹底調査

レポートには製品で検出された各種の脆弱性がリストされますが、出現箇所がすべて挙げられているわけではありません。リストに SOQL インジェクションの脆弱性と記載されている場合は、SOQL インジェクションがないか、名前が記されているコンポーネントだけでなく、コード全体を調べます。

Salesforce はソリューションへの突破口となった脆弱性の種類を警告することはできますが、出現箇所を網羅するリストを作成することはできません。いずれにしろ、コードベースについては、それを作成したチームのほうがはるかによく知っています。ですから、脆弱性が存在することがわかったら、当社よりもあなた方のほうがはるかに早くその問題を見つけることができます。

テストは完全ではない

当社が製品の脆弱性の検出にかけられる時間は限られています。時として、ソリューションのレビュー時に、今までに見たことのない新種の脆弱性が見つかることがあります。テストは、範囲の点でも詳細度の点でも、すべてを網羅するものではありません。各自のコードベースを確認するときは、レポートに記載されていないものを含め、あらゆる種類の脆弱性に細心の注意を払います。

まず落ち着いて、コードを修正

脆弱性の修正時に忘れてはならないのが、レビュー前と同様に、製品にスキャナと敵対的テストを実行することです。こうした対策によって、コードに新たな脆弱性が忍び込むことを阻止できます。

コードとともに自らの手法も再確認

セキュリティレビューの結果の対処についてチームとじっくり話し合います。以下に、会話のきっかけとなる質問の例を示します。

  • 各自が行ったセキュリティレビューで、これらの脆弱性をなぜ特定できなかったのか?
  • こうした問題を早期に検出するために、何かできることはなかったか?
  • テストを増やせば阻止できると思うか?
  • 人員や時間を増やせば阻止できると思うか?
  • Salesforce のセキュリティトレーニングが役立つと思うか?
  • 開発プロセスに適用可能なセキュリティレビューから何かを学んだか?

セキュリティを確保する完璧な戦略はありません。真摯な取り組みと強い意志が求められます。けれども、各回のセキュリティレビューから学んだことを着実に採り入れていけば、戦略全体を常に改善することができます。

そしてもちろん、パートナーの成功が Salesforce の成功です。脆弱性の修正やプロセスの検証にガイダンスが必要な場合は、パートナー取引先マネージャまたはテクニカルエバンジェリストにお問い合わせください。技術的なセキュリティについて助言が必要な場合は、Salesforce の信頼チームがオフィスアワーを設けています。

修正して再申請

ソリューションを修正し、開発プロセスを改良しました。あらゆる面のセキュリティが信じられないほど強化され、セキュリティレビューへの再挑戦が待ちきれません。さぁかかって来い、Salesforce 製品セキュリティチーム!

セキュリティチームもその挑戦にひるむことはありません。あなたに必要なことは、対戦相手の注意を引くことです。その方法は、Salesforce プラットフォームで実行されるコードを修正したかどうかによって異なります。

Salesforce プラットフォームで実行されるコードを変更した場合は、管理パッケージの新バージョンをアップロードする必要があります。パッケージ外の変更も行った場合は、セキュリティレビュー申請インターフェースに従ってその情報を追加します。

  1. 公開コンソールから、[リスト] タブをクリックします。
  2. 各自のリストをクリックします。
  3. ソリューションのタイプのタブ ([アプリケーション][Bolt] など) をクリックします。
  4. [パッケージを選択] をクリックして、新しい管理パッケージをリストにアップロードします。
  5. パッケージの [セキュリティレビュー] 項目の横にある [レビューを開始] をクリックします。
  6. セキュリティレビュー申請インターフェースをクリックしていきます。

Salesforce の外部で実行されるコードのみを修正した場合は、既存のセキュリティレビューの申請情報を編集します。

  1. 公開コンソールから、[リスト] タブをクリックします。
  2. 各自のリストをクリックします。
  3. パッケージの [セキュリティレビュー] 項目の横にある [レビューを編集] をクリックします。
  4. セキュリティレビューインターフェースに従って、変更した情報を更新します。
  5. 製品セキュリティチームに製品レビューを再申請することを知らせるには、パートナーコミュニティでケースを登録します。コメントにパッケージ名、ID、バージョンを記入します。

いずれの場合も、設定手数料は必要ありません。パッケージ ID と名前空間が変更されない限り、再申請は前回の製品の一部とみなされます。そして初回同様、フォローアップのセキュリティレビュープロセスには 2 ~ 3 週間を要します。

配布

製品のセキュリティレビューに合格すると、承認を知らせる嬉しいメールが届きます。これで終了です。それほど大変なことでもなかったですよね? チームの面々を称え、喜びを噛みしめます。お気に入りの方法でお祝いしましょう。

喜びに浸った後は、いよいよ製品の公開です。セキュリティレビューのメールに、この後のおおまかな手順が記されています。公開コンソールでリストを完成させ、マーケティングチームに準備を整えるよう連絡します。

『ISV Onboarding Guide (ISV オンボーディングガイド)』のマイルストン 6 に、AppExchange でリストを公開する方法が記載されています。また、役に立つ関連リソースも紹介されています。

公開された後は、くつろぎながら数字が増えていくのを眺めることにしましょう。

リソース