プライバシー

プライバシーリクエスト

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 設定ファイルでおこなえます。

詳しくは、この記事を参照してください。

このページ