安全な Experience Cloud を実現するために：セキュリティを考慮した設計手法のポイント

Experience Cloudについて深く掘り下げるため、SlalomのExperience Cloud部門ディレクターであるタイラー・オクスナー氏と対談を行いました。私たちは、外部からの視点だけでなく、内部の視点からも、Experience Cloudのサイバーセキュリティ防御体制の強化と維持に関するさまざまなトピックについて話し合いました。タイラー氏によると、「Experience Cloudでは脆弱性が生じやすいため、私たちが構築するデジタルエクスペリエンスを通じて、どのデータを公開し、どのデータを収集するかを慎重に検討する必要があります」。WithSecureでは日々、顧客と協力してサイバーセキュリティのギャップを埋める支援を行っている私としても、その意見に同意せざるを得ません。対話の冒頭部分をお読みになりたい方は、前回の投稿をご確認ください。

をご覧ください。

アーキテクチャとデザイン

初心者から見れば、アーキテクチャとデザインはほぼ同義語のように思えるかもしれませんが、サイバーセキュリティの観点からは、これほど異なるものはありません。アーキテクチャとは、顧客がポータルやウェブサイトで真に素晴らしい体験を得るために必要なデータの種類について考えることです。また、その情報を使って顧客に何ができるようにすべきかについても考えることですが、最も重要なのは、顧客が誤って行ってしまう可能性のある行為から、何を保護する必要があるかということです。Salesforce内のあらゆる情報を顧客に公開できるというExperience Cloudの力は、同時に最大のサイバーセキュリティ上の脆弱性でもあります。つまり、ユーザーエクスペリエンスを設計する際に「セキュリティファースト」の考え方を採用することが、この潜在的な攻撃経路の危険性を低減するための最も重要な一歩となります。

デザインとは、ユーザーがページとどのようにインタラクションする必要があるかを考えることです。アーキテクチャが、どのような種類のデータを公開または利用可能にするべきか、そしてそのデータをどのように取り込むべきかを考えるものであるのに対し、デザインは、顧客が実際にそのデータとどのようにインタラクションするかを考えるものです。体験を構築するあなたとして、顧客をページに長く留まらせ、彼らを驚かせ続けることができる、真に素晴らしく、顧客を引きつける体験をどのように作り出すことができるでしょうか？これこそが、エクスペリエンスデザイナーが自問している問いです。その時点ではアートとサイエンスの融合ですが、非常に繊細なバランスであり、うっかりすると意図しない情報漏洩を招きかねません。

だからこそ、エクスペリエンスクラウドのサイトやプロジェクトを展開・評価するプロセスにおいて、アーキテクチャを最初のステップに据えなければならないのです。

要件の分解

何か新しいことを始める際、最初に何をするでしょうか？ 質問を投げかけることです。もし知らなかったなら、これで分かったはずです。エクスペリエンスを構築する場合も、既存のものを監査する場合も、これと変わりません。「誰が、何を、いつ、どこで、なぜ、そして最も重要な『どのように』」という問いは、エクスペリエンスの基盤となるデータ構造を設計・構築する際の最強のパートナーとなります。これらの問いは、そのデータを盗もうとするサイバー犯罪者の立場に身を置くことにも役立ちます。顧客がサイトをどのように利用するかを考慮するだけでなく、悪意のある攻撃者がその体験を悪用して、潜在的な攻撃経路を見つけ出そうとする可能性についても考慮する必要があります。

私はタイラーに、Slalomでの勤務期間中、あるいは単にSalesforceエコシステムにおいて、彼が遭遇した主要なサイバーセキュリティ上の脅威や攻撃があるかどうか尋ねました。前述したように、Experience Cloudのパワーと設定の柔軟性は、恩恵であると同時に厄介な問題でもあります。設定が容易なプラットフォームは、優れた体験を簡単に作り出せる一方で、誰かがちょっとした変更を加えるだけで、複雑な連鎖反応を引き起こし、サイバーセキュリティ上の問題を引き起こす可能性も高くなります。タイラーが挙げた例としては、ゲストユーザーの共有ルール、パブリックAPIへのアクセス、Googleや他の検索エンジンにクロールされてはならないページへの適切なマーク付けの欠如、エクスペリエンスサイト経由での悪意のあるファイルやURLのアップロードなどが挙げられ、そのリストは枚挙にいとまがありません。

エクスペリエンスサイトの要件を整理する際は、常に「ユーザーが目的の操作を行える範囲で、サイト上で公開するデータやオブジェクトを最小限に抑えるにはどうすればよいか」という視点で検討してください。「最小権限の原則」に従うことで、Experience Cloud上の高度にカスタマイズ可能なサイトが抱えるサイバーセキュリティ上の落とし穴の多くを回避できますが、Experienceサイトに連鎖的な影響を及ぼす可能性のある組織全体の設定にも注意を払う必要があります。ここで、アーキテクチャ監査という作業に取り組みます。

アーキテクチャ監査

組織の監査には時間がかかります。組織が10年経過しているか10ヶ月しか経っていないかは関係なく、Experience Cloudにおけるサイバーセキュリティの準備状況やセキュリティレベルを評価する際には、数多くの設定、組織全体のデフォルト設定、権限セット、プロファイル、ロール、共有ルールなどを精査する必要があります。

組織内のあらゆる設定や制御について、その理由や機能を文書化し、理解しておく必要があります。理由のない設定については、制限を設ける必要があります。これが「最小権限の原則」です。サイバーセキュリティの多くは、単に、あらゆる構成要素が特定の瞬間に何を行っているかを理解することに尽きます。実際、DevOpsの5つのステップにおいて「計画（Plan）」が最初の段階となっているのは、このためです。

組織内のすべてのコンポーネントが何を実行しており、どのようなデータが使用されているかを理解したら、次はそれらの設定を調整し、エクスペリエンスを構築するためのアクセス権を付与することができます。ご覧の通り、アーキテクチャ監査は、エクスペリエンス・クラウドの導入を成功させ、サイバーセキュリティを確保するための、論理的な第一歩なのです。

脅威ベクトル

これで、組織内で各要素がどのような動作をしているか、誰が何にアクセスできるか、どのAPIがどのようなアクションに使用されているか、そして使用されていない部分（ゲストユーザーアクセスなど）を含め、組織がどのような目的で構築されているかについて、確固たる理解が得られたはずです。次に、サイバー犯罪者が組織への様々な侵入経路をどのように悪用する可能性があるかを検討する必要があります。この演習では、過去に攻撃者が成功した攻撃対象領域（アタックサーフェス）上のポイントを実際に確認してみましょう。

最も手頃な標的であり、ハッカーがサイバーセキュリティ防御の隙を突こうとする際に真っ先に狙うのが、パブリックAPIです。多くのチームではパブリックAPIを使用していないか、あるいはあらゆる用途に利用しているため、この点は見過ごされがちです。パブリックAPIを通じてすべてを公開することの問題点は、想定や意図以上に多くのCRMデータをさらしてしまうリスクがあることです。実例としてよく見られる手法の一つに、cURLスクリプトを使用してそのパブリックAPIを悪用し、組織から可能な限り多くのデータを抽出するケースがあります。

このパブリックAPIによる脅威を念頭に置くと、効果的な脅威ハンティングでは、組織全体のデフォルト設定や、オブジェクト間の関係によって意図せず公開されてしまう可能性についても検討する必要があります。最も見落とされがちな公開経路の一つは、マスター・ディテールオブジェクトの関係において、マスターオブジェクトが誤って共有されてしまうケースです。マスターオブジェクトを共有すると、その共有ルールに詳細オブジェクトも含まれます。こうしたサイバーセキュリティリスクがどのように複合化していくかがお分かりいただけるでしょう。

共有ルールと言えば、さまざまなパートナー全体に広く共有したくないデータについて考えてみてください。素晴らしいパートナーコミュニティを構築したとしても、パートナー同士で互いの情報を晒し合いたくないはずです。ここで、考えられるあらゆる脅威の経路を想定する能力が重要になります。

最後に、サイバー犯罪者がSalesforceを攻撃する最も簡単な方法の一つは、プラットフォームに組み込まれた専用チャネルを経由することです。Web-to-Case、Email-to-Case、エクスペリエンスポータルなどは、いずれもSalesforceエコシステムにとって重大なサイバーセキュリティ上の脅威となります。これらの各チャネルは、送信内容の一部としてファイルやURLを受け入れることができます。送信時のファイルアップロード機能を無効にすると、Experience Cloudの価値の一部が失われる可能性があります。最も簡単な解決策は、メールやエンドポイントと同様に、サイバーセキュリティへの投資と保護を徹底することです。幸いなことに、WithSecureのCPSFのような、インストールと使用が簡単で、5分以内に保護体制を構築できるソリューションが存在します。

Security 360

監視が必要なすべてのチャネルを把握したところで、Security 360の構築を開始できます。SalesforceがCustomer 360を構築したように、設計や変更の意思決定を行う際にチームが参照・活用できるSecurity 360を構築する必要があります。Salesforceは素晴らしいビジネス向けツールですが、サイバーセキュリティチームが、企業全体のテクノロジースタック内の他のあらゆるシステムと同様に、Salesforceに関連するリスクや脅威ベクトルを十分に認識できるようにするためには、包括的なコミュニケーションおよび変更管理計画が必要です。

URLおよびファイル保護の導入をお考えですか？WithSecure Cloud Protection for Salesforceをご覧ください。まずはコンテンツリスク評価にご記入ください。