Skip to main content
Join the Agentforce Hackathon on Nov. 18-19 to compete for a $20,000 Grand Prize. Sign up now. Terms apply.

セキュリティ戦略の考案

学習の目的

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

  • チームのセキュリティ担当者を特定する。
  • セキュアなソフトウェア開発の学習に役立つリソースを挙げる。
  • ソリューション開発でセキュリティを考慮する段階について説明する。

セキュリティには所有権が必要

会社には誰がどの情報にアクセスするかというルールがあります。今日の出勤時も、鍵やバッジを使ってオフィスに入室したのではないでしょうか? 家族やベンダーを招いた際の訪問手順についてはお分かりだと思います。また、見知らぬ人が社内をうろうろしているところを見かけることはほぼないとしても、そうした人を見かけた場合の対処法もご存知だと思います。

これらのルールは、特定の人々がその施行の責任を負っています。最高セキュリティ担当者といった華々しい役職名で呼ばれているかもしれません。この人物は、常に社内の情報セキュリティについて思案しています。

ソリューションのセキュリティ所有者は誰か?

ソリューションの顧客データも、社内の情報と同じ様に保護する必要があります。あなたの開発チームに最高セキュリティ責任者はいますか?

もちろんセキュリティ保護は全員の責任ですが、開発者は皆忙しく、ソリューションの市場投入の準備に追われる中で何かをし忘れたり見落としたりすることがあります。セキュリティを最優先事項に位置づけておくため、チームのセキュリティ推進者を指名することを検討します。セキュリティ推進者は、チームの最高セキュリティ責任者であり、常にソリューションのセキュリティについて考えます。

セキュリティコードの記述方法

セキュリティに対するチームの認識を高めたら、次のステップはセキュアなソフトウェアの構築に関する知識を高めることです。パートナーが使用可能なリソースが用意されており、その一部は前の単元でも取り上げました。

リソース 内容

Open Web Application Security Project (OWASP) Top 10 List (オープン Web アプリケーションセキュリティプロジェクト (OWASP) のトップ 10 リスト)

ごく一般的な Web アプリケーション脆弱性のリスト

Salesforce Secure Coding Guidelines (Salesforce セキュアなコーディングのガイドライン)

セキュリティ監査で検出されることが多い Web セキュリティ上の欠陥の一覧

AppExchange Security Requirements Checklist (AppExchange セキュリティ要件チェックリスト)

(ログインが必要)

技術およびソリューションの種類別の問題の説明

「セキュアな Web アプリケーションの開発」トレイル

Salesforce Platform に固有の主要なセキュリティトピックを説明する一連のトレーニングモジュール

全員の責任

セキュリティ推進者がチームのリソースになるものと思われますが、セキュリティは全員の責任であることを忘れてはなりません。セキュリティ上の問題に対する開発者の認識が高まれば、問題への取り組みも向上します。

セキュリティは主要な機能で、アドオンではない

ねぇ、今作っているアプリケーション、すごいんだってね! 公開されるまで世間には秘密だよ。いつ頃できあがるの?

ソリューションの開発とリリースの間に立ちはだかってやろうなどと思う人はいません。営業チームもマーケティングチームも想定外の延期を嫌い、そんなことがあればいつまでも根に持ちます。ここで、Salesforce 製品セキュリティチームが脆弱性を検出したことで公開日が延期になった場合、事態がどれほど緊迫するか想像してみてください。些細な問題であれば、簡単に修正できます。けれども、セキュリティ上の根本的な欠陥で、設計の段階からやり直さなければならない場合には、予定外の作業に直面し、延期が長引く可能性があります。

開発の各段階でセキュリティを考慮

ソフトウェアの作成方法にかかわらず、チームがセキュリティについて最初からきちんと考慮するように指導してください。開発のあらゆる段階でセキュアな設計パターンおよびプログラミングの手法を適用し、攻撃に対してソリューションをテストします。以下は、セキュリティを強化するために開発プロセスの各段階で実施できることを示しています。

  • 設計: 最高のバグは、修正する必要のないバグです。ソフトウェアの適切な設計に勝るものはなく、セキュアではない設計はセキュアな設計に絶対に適いません。ユーザーが機能をどのように操作するか注意深く考え、関連する脆弱性を確実に特定します。次に、その脆弱性を明示した具体的なユースケースを定義します。
  • 実装: デイリースクラムを行っている場合は、チームメンバーに対してセキュアなコーディング戦略を徹底するようセキュリティ推進者に指示します。コードの開発時に Salesforce コードアナライザーか、同様の統合型コードスキャンツールを定期的に使用して、脆弱性を特定します。もう 1 つの効率的なフォーラムは、セキュリティ上の問題について話し合うコードレビューです。セキュアなコーディングのガイドラインをコーディングのスタイルガイドに組み込みます(ところで、スタイルガイドはありますよね?)
  • テスト: 攻撃に対するソリューションの脆弱性をテストするための具体的な計画が必要です。繰り返し実行可能なテストを設計し、ソリューション開発の各段階でそのテストを一貫して適用します。

Web セキュリティおよびテストの全体像については、『OWASP テスティングガイド』を参照してください。独自の計画をまとめるうえで役立つものと思われます。

ソリューション全体のセキュリティ保護

セキュアなソリューションの構築と言う場合はその全体を意味します。つまり、Salesforce 外でホストするコンポーネントやサービスなど、プラットフォーム外に存在する要素も対象です。さらに、大切なネイティブモバイルアプリケーションもセキュリティ計画に忘れてはなりません。モバイルにも保護が必要です。

次の点を再確認しておきましょう。

  • ソリューションに無防備な侵入箇所がたった 1 つあるだけで、攻撃者はあなたの取り組みを台無しにします。つまり、これが突破口になります。理路整然としたセキュリティ計画があれば、万全なソリューションを作り上げることができます。
  • セキュリティは全員の責任ですが、セキュリティを所有する推進者がいればセキュリティに対するチームの認識を維持できます。
  • チームは Salesforce が提供するインタラクティブなリソースを使って、セキュアなソフトウェア開発について学ぶことができます。
  • 開発のどの段階にも独自のセキュリティ検討事項が存在します。

リソース

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

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

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