プライバシー

プライバシーリクエスト

Adobe Campaign には、GDPR および CCPA に則ってプライバシーを遵守するのに役立つ一連のツールが用意されています。

参照: このページ プライバシー管理の概要とAdobe Campaignの実装手順に関する一般的な情報を参照してください。 また、ベストプラクティスや、ユーザープロセスとペルソナの概要も確認できます。

URL のパーソナライゼーション

コンテンツにパーソナライズされたリンクを追加する場合、潜在的なセキュリティギャップを回避するために、URL のホスト名部分にパーソナライゼーションを含めないようにしてください。 次の例は、すべての URL 属性 <a href=""> または <img src=""> で使用しないでください。

  • <%= url >
  • https://<%= url >
  • https://<%= domain >/path
  • https://<%= sub-domain >.domain.tld/path
  • https://sub.domain<%= main domain %>/path

レコメンデーション

上記を使用していないことを検証し確認するには、を使用してトラッキング URL テーブルに対してクエリを実行します。 キャンペーン汎用クエリエディター または クエリアクティビティ.

例:

  1. ワークフローを作成し、「クエリ」アクティビティを追加します。 詳細情報.

  2. クエリアクティビティを開き、次のように nmsTrackingUrl テーブルでフィルターを作成します。ソース URL がhttp://<%で始まるか、ソース URL がhttps://<%で始まる。

  3. ワークフローを実行し、結果があるかを確認します。

  4. 結果がある場合は、出力トランジションを開いて URL のリストを表示します。

URL 署名

セキュリティを強化するために、E メール内のリンクを追跡するための署名メカニズムが導入されました。 ビルド 19.1.4(9032@3a9dc9c) および Campaign 20.2 で使用できます。この機能は、デフォルトで有効になっています。

メモ

不正な形式の署名済み URL がクリックされると、次のエラーが返されます。"リクエストされた URL '…'が見つかりませんでした。"

また、Campaign 20.2 以降、および Gold Standard リリースの場合は、以前のビルドで生成された URL を無効にする機能強化を使用できます。 この機能は、デフォルトでは無効になっています。 次の場所に移動して、 カスタマーケア この機能を有効にするには、をクリックします。

を実行している場合は、 Gold Standard 19.1.4、トラッキングリンクを使用したプッシュ通知配信、またはアンカータグを使用した配信で問題が発生する場合があります。 その場合は、URL 署名を無効にすることをお勧めします。

Campaign をオンプレミスで実行している場合でも、ハイブリッドアーキテクチャで実行している場合でも、次の場所にアクセスする必要があります。 カスタマーケア URL 署名を無効にする。

ハイブリッドアーキテクチャで Campaign を実行している場合は、URL 署名を有効にする前に、ホストされているミッドソーシングインスタンスが次のようにアップグレードされていることを確認します。

  • オンプレミスのマーケティングインスタンスより前
  • オンプレミスのマーケティングインスタンスと同じバージョンにするか、少し高いバージョンにする

そうしないと、次の問題が発生する可能性があります。

  • ミッドソーシングインスタンスがアップグレードされる前は、このインスタンスを通じて URL が署名なしで送信されます。
  • ミッドソーシングインスタンスをアップグレードし、両方のインスタンスで URL 署名が有効になった後、以前に署名なしで送信された URL は拒否されます。 これは、マーケティングインスタンスから提供されたトラッキングファイルによって署名が要求されたためです。

以前のビルドで生成された URL を無効にするには、すべての Campaign サーバーで同時に次の手順に従います。

  1. サーバー設定ファイル(serverConf.xml)で、blockRedirectForUnsignedTrackingLinktrue に変更します。
  2. nlserver サービスを再起動します。
  3. トラッキングサーバーで、Web サーバー(Debian では apache2、CentOS/RedHat では httpd、Windows では IIS)を再起動します。

URL 署名を有効にするには、すべての Campaign サーバーで同時に次の手順に従います。

  1. サーバー設定ファイル (serverConf.xml)で、signEmailLinksfalse に変更します。
  2. nlserver サービスを再起動します。
  3. トラッキングサーバーで、Web サーバー(Debian では apache2、CentOS/RedHat では httpd、Windows では IIS)を再起動します。

データの制限

権限レベルの低い認証ユーザーは暗号化されたパスワードにアクセスできないようにする必要があります。これを実現するには、主に 2 つの方法があります。パスワードフィールドへのアクセスを制限する方法と、エンティティ全体へのアクセスを制限する方法です(ビルド 8770 以降が必要です)。

この制限をおこなうと、パスワードフィールドを削除する一方で、外部アカウントは全ユーザー向けのインターフェイスからアクセス可能にできます。このページを参照してください。

  1. 管理設定データスキーマ​に移動します。

  2. 新しい​スキーマの拡張​を作成します。

  3. 外部アカウント(extAccount)を選択します。

  4. 最後のウィザード画面で、新しい srcSchema を編集して、すべてのパスワードフィールドへのアクセスを制限します。

    メイン要素(<element name="extAccount" ... >)は、次の方法で置き換えることができます。

    <element name="extAccount">
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
        <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
    
        <element name="s3Account">
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="awsSecret"/>
        </element>
        <element name="wapPush">
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
        </element>
        <element name="mms">
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
        </element>
    </element>
    

    したがって、拡張された srcSchema は次のようになります。

    <srcSchema _cs="External Accounts (cus)" created="2017-05-12 07:53:49.691Z" createdBy-id="0"
                desc="Definition of external accounts (Email, SMS...) used by the modules"
                entitySchema="xtk:srcSchema" extendedSchema="nms:extAccount" img="" label="External Accounts"
                labelSingular="External account" lastModified="2017-05-12 08:33:49.365Z"
                mappingType="sql" md5="E9BB0CD6A4375F500027C86EA854E101" modifiedBy-id="0"
                name="extAccount" namespace="cus" xtkschema="xtk:srcSchema">
        <createdBy _cs="Administrator (admin)"/>
        <modifiedBy _cs="Administrator (admin)"/>
        <element name="extAccount">
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
            <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
    
            <element name="s3Account">
                <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="awsSecret"/>
            </element>
            <element name="wapPush">
                <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
                <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
            </element>
            <element name="mms">
                <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="password"/>
                <attribute accessibleIf="$(loginId) = 0 or $(login) = 'admin'" name="clientSecret"/>
            </element>
        </element>
    </srcSchema>    
    
    メモ

    次を置換: $(loginId) = 0 or $(login) = 'admin'hasNamedRight('admin') 管理者権限を持つすべてのユーザーに対し、これらのパスワードの表示を許可する。

PII を含むページの保護

オンプレミス版のお客様の場合は、ミラーページや Web アプリケーションのように、個人情報を含む可能性があるページを保護することを強くお勧めします。

この手順の目的は、これらのページのインデックス化を防止することによってセキュリティリスクを回避することです。以下に、この目的に役立つ記事をいくつか示します。

ページを保護するには、次の手順に従います。

  1. Web サーバー(Apache または IIS)のルートに robots.txt ファイルを追加します。このファイルの内容は次のとおりです。

    # Make changes for all web spiders
    User-agent:
    *Disallow: /
    

    IIS の場合は、 このページ.

    Apache の場合は、にファイルを配置できます。 /var/www/robots.txt (Debian)。

  2. 場合によっては、 robots.txt ファイルはセキュリティの点で十分ではありません。 例えば、他の Web サイトに自社ページへのリンクがある場合は、検索結果に自社ページの情報が表示される可能性があります。

robots.txt ファイルに加え、X-Robots-Tag ヘッダーも追加することをお勧めします。Apache の場合も IIS の場合も、このヘッダーの追加は serverConf.xml 設定ファイルでおこなえます。

詳しくは、 この記事.

このページ