この記事では、セキュリティとプライバシーに関する重要な要素について説明します。
Privacy

プライバシーの設定と強化

ここをクリック


icon_clef

アクセス管理

ここをクリック


Server

サーバーの設定

ここをクリック


Development

スクリプティングおよびコーディングのガイドライン

ここをクリック


Network

ネットワーク、データベース、SSL/TLS

ここをクリック


Web

Web サーバーの設定

ここをクリック


プライバシー

Privacy

プライバシー設定と強化は、セキュリティを最適化するうえで重要な要素です。この節を読み、プライバシーのベストプラクティスの詳細をご確認ください。

  • HTTP ではなく HTTPS を使用して、お客様の PII を保護します
  • PII 閲覧の制限を使用してプライバシーを保護し、データの乱用を防止します。
  • 暗号化されたパスワードが制限されていることを確認します。
  • ミラーページや web アプリケーションのように、個人情報を含む可能性があるページを保護します。

プライバシーリクエスト

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

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

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

コンテンツにパーソナライズされたリンクを追加する場合、潜在的なセキュリティギャップを避けるために、URL の hostname 部分はパーソナライズしないでください。次の例は、いかなる URL 属性 <a href=""> または <img src=""> でも使用しないでください。

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

推奨事項

上記を使用していないことを検証および確認するには、Campaign 汎用クエリエディターを使用してトラッキング URL テーブルでクエリを実行するか、クエリアクティビティのフィルター条件を含むワークフローを作成します。

次に例を示します。

  1. ワークフローを作成し、クエリアクティビティを追加します。詳しくは、こちらを参照してください。
  2. クエリアクティビティを開き、nmsTrackingUrl テーブルにフィルターを作成します。「http://<%」で開始するソース URL、または「https://<%」で開始するソース URL です。
  3. ワークフローを実行し、結果があるかを確認します。
  4. 結果がある場合は、出力トランジションを開いて URL のリストを表示します。
動的 URL のクエリ

署名のメカニズム

セキュリティを強化するために、E メールのリンクを追跡するための新しい署名メカニズムがビルド 19.1.4(9032@3a9dc9c)で導入され、ビルド 19.1.4(9032@3a9dc9c)および Campaign 20.2 で利用可能になりました。このオプションは、すべてのお客様に対してデフォルトで有効です。

注意:

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

さらに、ビルド 19.1.4(9032@3a9dc9c および 9032@800be2e)および Campaign 20.2 でホストされるハイブリッド環境のお客様は、強化機能を使用して、以前のビルドで生成された URL を無効にできます。このオプションは、デフォルトでは無効になっています。この機能を有効にするには、カスタマーケアにお問い合わせください。

オンプレミス環境でこの新しいメカニズムを有効にするには、すべての Campaign サーバーで次の手順を実行する必要があります。

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

警告:

ビルド 19.1.4(9032@3a9dc9c)を実行している場合、トラッキングリンクを使用したプッシュ通知配信、またはアンカータグを使用した配信で問題が発生する可能性があります。その場合、トラッキングリンクの新しい署名メカニズムを無効にすることをお勧めします。

ホストされているハイブリッド環境のお客様の場合、このメカニズムを無効にするには、カスタマーケアに連絡する必要があります。

オンプレミス環境の場合は、次の手順に従います。

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

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

アクセス管理

Access

アクセス管理は、セキュリティ強化の重要な要素です。ここでは、主なベストプラクティスを紹介します。

  • 十分なセキュリティグループを作成する
  • 各オペレーターのアクセス権が適切であることをチェックする
  • 管理オペレーターの使用を避け、管理グループのオペレーターが多くなりすぎないようにする

アクセス権およびフォルダーアクセスのプロパティを参照してください。


Web アプリオペレーター

デフォルトでは、Web アプリオペレーターは管理者です。セキュリティを強化するために、次のガイドラインに従ってください。

  • 管理ネームド権限をこのオペレーターから新しいオペレーターに置き換えます(名前は「webapp」にできます)。詳しくは、このドキュメントを参照してください。
  • Web アプリオペレーターをフォルダー(主に受信者フォルダー)に追加して、受信者に読み取り/書き込みアクセス権を付与します。詳しくは、このドキュメントを参照してください。
  • 複数ブランド(または複数地域)のインスタンスを使用している場合、Web アプリケーションのアクセス権を複数の受信者フォルダーに分割できます。次の操作をおこないます。
    1. Web アプリ演算子の複製
    2. それぞれの複製に対して名前を入力します。例:webapp_brand、webapp_brand2 など。
    3. Web アプリケーションテンプレートを複製し、ブランドごとに 1 つのテンプレートを使用できるようにします。また、プロパティを編集し、「特定のアカウントを使用」を選択してオペレーターを変更します。  詳しくは、このドキュメントを参照してください。

セキュリティグループと管理オペレーター

十分なセキュリティグループを作成して、オペレーターに十分な権限を付与し、オペレーターが必要な操作をおこなえるようにします(必要以上の操作は許可しない)。

管理オペレーターは使用しない(または共有しない)ようにします。(正確な監査やログ記録をさせるために)物理ユーザーごとに 1 人のオペレーターを作成します。新しく名前を付けた管理者を管理グループに追加します。管理オペレーターを使用しない場合でも、削除や無効化はしないでください(このオペレーターは、処理を実行するために内部で使用されます)。ただし、クライアントコンソールへのアクセスを禁止し、セキュリティゾーンを(localhost に)限定できます。

管理グループの(または、管理ネームド権限がある)オペレーターの数が多くなりすぎないようにします。これらのオペレーターは非常に強力です(すべての SQL 文の実行、サーバーでのコマンドの実行などができます)。

Adobe Campaign では、ネームド権限を通じて、3 つの高度な権限を提供しています。

  • ADMINISTRATION(admin):すべての項目にアクセスでき、すべての処理を実行できます(すべてのネームド権限チェックはバイパスされます)。そのため、PROGRAM EXECUTION(createProcess)および SQL ネームド権限が含まれます。
  • PROGRAM EXECUTION(createProcess):(サーバー上の)外部プログラムを実行できます。
  • SQL:データベース上で SQL スクリプトを実行できます(セキュリティモデルをバイパスできます)。複雑な演算(フィルタリングなど)を実行する必要がある場合、データベース管理者に対して、SQL 関数を作成し、許可リストに登録するよう依頼できます。詳しくは、この節を参照してください。
  • この 3 つの高度な権限は、なるべく少数の(信頼できる)オペレーターにのみ付与するようにしてください。

スクリプティングおよびコーディングのガイドライン

Dev

Adobe Campaign で(ワークフロー、JavaScript、JSSP などを)開発する場合、常に次のガイドラインに従います。

  • スクリプティング:SQL 文は使用しないようにします。文字列連結ではなく、パラメーター化関数を使用します。使用する SQL 関数を許可リストに追加して、SQL インジェクションを回避します。
  • データモデルの保護:ネームド権限を使用してオペレーターの操作を制限します。システムフィルター(sysFilter)を追加します。
  • Web アプリケーションへの Captcha の追加:パブリックのランディングページと購読ページに Captcha を追加する方法について説明します。

スクリプト

詳しくは、Campaign JSAPI のドキュメントを参照してください。

ワークフロー、Web アプリケーション、JSSP を使用してスクリプトを作成する場合、次のベストプラクティスに従ってください。

  • SQL 文はできるだけ使用しないようにしてください。
  • どうしても必要な場合は、文字列連結ではなく、パラメーター化関数(prepare 文)を使用します。

悪い例:

sqlGetInt( "select iRecipientId from NmsRecipient where sEmail ='" + request.getParameter('email') +  "'  limit 1" )

良い例:

sqlGetInt( "select iRecipientId from NmsRecipient where sEmail = $(sz) limit 1", request.getParameter('email'));

警告:sqlSelect は、この機能をサポートしていないので、DBEngine クラスのクエリ関数を使用する必要があります。

var cnx = application.getConnection() 
var stmt = cnx.query("SELECT sFirstName, sLastName FROM NmsRecipient where sEmail = $(sz)", request.getParameter('email'))
for each(var row in stmt) logInfo(row[0] + " : " + row[1]) 
cnx.dispose()

SQL インジェクションを回避するには、Adobe Campaign で使用する許可リストに SQL 関数を追加する必要があります。許可リストに追加すると、式エディターで演算子が表示されます。ドキュメントを参照してください。警告:8140 より前のビルドを使用している場合、XtkPassUnknownSQLFunctionsToRDBMS オプションは「1」に設定する必要があります。データベースを保護する場合は、このオプションを削除します(または「0」に設定します)。

ユーザー入力を使用してクエリや SQL 文でフィルターを作成する場合は、常にエスケープ処理をおこなう必要があります(Campaign JSAPI のドキュメント「データ保護:関数のエスケープ」を参照)。次の関数が該当します。

  • NL.XML.escape(data)
  • NL.SQL.escape(data)
  • NL.JS.escape(data)
  • NL.XML.escapeAttribute(data)

新しいデータモデルの保護

フォルダーベース

製品ドキュメントの次の節を参照してください。

ネームド権限

フォルダーベースのセキュリティモデルに加えて、ネームド権限を使用してオペレーターの操作を制限できます。

  • システムフィルター(sysFilter)を追加すると、データの読み取り/書き込みを防止できます。 documentation を参照してください。
<sysFilter name="writeAccess">     
    <condition enabledIf="hasNamedRight('myNewRole')=false" expr="FALSE"/>   
</sysFilter>
  • スキーマで定義された一部の操作(SOAP メソッド)を保護することもできます。アクセス属性に、対応するネームド権限を値として設定します。
<method name="grantVIPAccess" access="myNewRole">
      <parameters>
...
      </parameters>
    </method>

         

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

警告:

ネームド権限は、ナビゲーションツリーのコマンドノードで使用できます。これにより、ユーザーエクスペリエンスは向上しますが、保護はされません(非表示/無効にするには、クライアント側のみを使用します)。アクセス属性を使用する必要があります。

オーバーフローテーブル

オペレーターのアクセスレベルに応じて機密データ(スキーマの一部)を保護する必要がある場合、フォーム定義で非表示にしないでください(enabledIf/visibleIf 条件)。エンティティ全体が画面で読み込まれます。また、列定義で表示することもできます。この操作をおこなうには、オーバーフローテーブルを作成する必要があります。このドキュメントを参照してください。

Web アプリケーションへの Captcha の追加

パブリックのランディングページや購読ページには Captcha を追加することをお勧めします。ただし、DCE(デジタルコンテンツエディター)ページに Captcha を追加することは簡単ではありません。ここでは、Captcha バージョン 5 または Google reCAPTCHA を追加する方法について説明します。

DCE に Captcha を追加する場合、一般的には、Captcha を含めるためのパーソナライゼーションブロックをページコンテンツ内に作成します。スクリプトアクティビティとテストを追加する必要があります。

パーソナライゼーションブロック

  1. リソースキャンペーン管理パーソナライゼーションブロックに移動し、新しいパーソナライゼーションブロックを作成します。

  2. Web アプリケーションコンテンツタイプを使用し、「カスタマイズメニューに表示」チェックボックスをオンにします。

    詳しくは、ドキュメントを参照してください。

    Campaign captcha の例を示します。

    <%
    var captchaID = CaptchaIDGen();
    %>
    <img src="/nms/jsp/captcha.jsp?captchaID=<%=captchaID%>&width=200&height=50&minWordSize=8&maxWordSize=8"/>
    <input id="captchaValue" name="captchaValue" <%= String(ctx.vars.captchaValid) === "false" ? class="ui-state-error" : "" %>>
    <input type="hidden" name="captchaID" value="<%=captchaID%>"/>
    <%
    if( serverForm.isInputErroneous("captchaValue") ) {
    %>
    <script type="text/javascript">  
    $("#captchaValue").addClass("ui-state-error")
    </script>
    <%
    }
    %>
    • 1~6 行目では、必要な入力をすべて生成します。
    • 7 行目から最終行では、エラーを処理します。
    • 4 行目では、Captcha のグレーボックスのサイズ(width/height)と、生成される単語の長さ(minWordSize/maxWordSize)を変更できます。
    • Google reCAPTCHA を使用する前に、Google に登録し、新しい reCAPTCHA サイトを作成する必要があります。
    <div class="g-recaptcha" data-sitekey="YOUR_SITE_KEY"></div>

    検証ボタンを無効にすることが必要な場合もありますが、標準的なボタンやリンクは用意されていないので、HTML 自体で実現することをお勧めします。配信ログにアクセスする方法について詳しくは、このページを参照してください。

Web アプリケーションの更新

  1. Web アプリケーションのプロパティにアクセスして、captchaValid という名前のブール値変数を追加します。

    Captcha
  2. 最後のページとストレージアクティビティの間に、スクリプトテストを追加します。分岐 Trueストレージに接続し、別の分岐を、Captcha を追加するページに接続します。

    Captcha - 手順 2
  3. 分岐 True の成立条件を、[vars/captchaValid] が Yes の場合に編集します。

    Captcha - 手順 3
  4. 次に、スクリプトアクティビティを編集します。コンテンツは選択したキャプチャエンジンによって異なります。

  5. 最後に、パーソナライゼーションブロックをページに追加します。ドキュメントを参照してください。

    Captcha - 手順 5
    Captcha - 手順 6

    警告:reCAPTCHA を組み込むには、クライアント側の JavaScript を HTML 内の <head>...</head> 間に追加する必要があります。

    <script src="https://www.google.com/recaptcha/api.js" async defer></script>

Campaign Captcha

var captchaID = request.getParameter("captchaID");
var captchaValue = request.getParameter("captchaValue");
 
if( !CaptchaValidate(captchaID, captchaValue) ) {
  serverForm.logInputError("captchaValue",
                           "The characters you typed for the captcha must match the image ones.",
                           "captchaValue")
  ctx.vars.captchaValid = false
}
else
  ctx.vars.captchaValid = true

6 行目:あらゆる種類のエラーメッセージを出力できます。

Google reCAPTCHA

正式なドキュメントを参照してください。

ctx.vars.captchaValid = false
var gReCaptchaResponse = request.getParameter("g-recaptcha-response");
 
// Call reCaptcha API to validate it
var req = new HttpClientRequest("https://www.google.com/recaptcha/api/siteverify")
req.method = "POST"
req.header["Content-Type"] = "application/x-www-form-urlencoded"
req.body = "secret=YOUR_SECRET_HERE&response=" + encodeURIComponent(gReCaptchaResponse)
req.execute()
var response = req.response
if( response.code == 200 ) {
  captchaRes = JSON.parse(response.body.toString(response.codePage));
  ctx.vars.captchaValid = captchaRes.success
}
 
if( ctx.vars.captchaValid == false ) {
  serverForm.logInputError("reCaptcha",
                           "Please validate the captcha",
                           "reCaptcha")
  logInfo("reCaptcha not validated")
}

JSON.parse を使用するには、Web アプリに「shared/json2.js」を含める必要があります。

Captcha - 手順 7

ビルド 8797 以降では、検証 API URL を使用するには、その URL を serverConf ファイルの許可リストに urlPermission ノードで追加する必要があります。

<url dnsSuffix="www.google.com" urlRegEx="https://www.google.com/recaptcha/api/siteverify"/>

ネットワーク、データベース、SSL/TLS

Network

オンプレミス型のアーキテクチャをデプロイする際にチェックすべき最も重要な要素は、ネットワーク設定です。Tomcat サーバーに外部から直接アクセスできないことを確認します。

  • 外部 IP の Tomcat ポート(8080)を閉じます(localhost では動作する必要があります)。
  • 標準 HTTP ポート(80)を Tomcat ポート(8080)にマッピングしないようにします。

可能であれば、保護されたチャネルを使用します。POP3(や POP3 over TLS)ではなく、POP3S を使用します。


データベース

データベースエンジンのセキュリティは必須です。

SSL/TLS 設定

証明書をチェックするには、OpenSSL を使用します。アクティブな暗号をチェックするには、nmap を使用します。

#!/bin/sh
#
# usage: testSSL.sh remote.host.name [port]
#
REMHOST=$1
REMPORT=${2:-443}

echo |\
openssl s_client -connect ${REMHOST}:${REMPORT} -servername ${REMHOST} 2>&1 |\
sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' |\
openssl x509 -noout -subject -dates
  
nmap --script ssl-enum-ciphers -p ${REMPORT} ${REMHOST}

また、sslyze Python スクリプトを使用すると、両方の処理ができます。

python sslyze.py --sslv2 --sslv3 --tlsv1 --reneg --resum --certinfo=basic --hide_rejected_ciphers --sni=SNI myserver.com

サーバーの設定

Server

設定は、すべてのサーバーでおこなう必要があります。設定ファイルは、serverConf.xmlconfig-<instance>.xml です。次に、確認する必要がある重要な要素を示します。

  • セキュリティゾーン:プロキシのクライアントの IP アドレスを直接考慮に入れることができるように、セキュリティゾーンを設定します。
  • ファイルアップロードの保護:新しい uploadAllowList 属性を使用して、Adobe Campaign サーバーにアップロードできるファイルのタイプを制限します。これは、サーバー設定ファイルで使用できます。
  • リレー:使用していないモジュール/アプリケーションのリレールールを無効にして、リレー設定を微調整します。
  • 送信接続の保護コマンドの制限(サーバー側)
  • また、HTTP ヘッダーを追加したり、checkIPConsistent、enableTLS、sessionTimeOutSec などを有効にしたりすることもできます。

詳しくは、Campaign サーバーの設定ドキュメントおよびサーバー設定ファイルの説明を参照してください。


セキュリティゾーンの設定

警告:

ビルド 8977 以降では、セキュリティゾーンセルフサービスユーザーインターフェイスは利用できなくなります。

  • AWS でホストされている場合は、許可リストへの IP の追加はコントロールパネルで実行する必要があります。詳しくは、専用のドキュメントを参照してください。
  • AWS でホストされていない場合は、アドビのサポートチームに連絡し、IP を許可リストに追加してもらってください。

 インスタンスが AWS でホストされているかどうかを確認するには、この節に記載されている手順に従います。

セキュリティゾーンセルフサービス UI を使用して VPN セキュリティゾーン設定のエントリを管理する方法については、こちらのテクニカルノートを参照してください。

subNetwork でリバースプロキシが許可されていないことを確認します。許可されている場合は、すべてのトラフィックがこのローカル IP から来ているものとして検出され、信頼されます。

sessionTokenOnly="true" の使用は最小限に抑えてください。

  • 警告:この属性が true に設定されている場合、オペレーターが CRSF 攻撃にさらされる可能性があります。
  • さらに、sessionToken cookie に httpOnly フラグが設定されていないので、一部のクライアント側 JavaScript コードがこれを読み取れる可能性があります。
  • ただし、複数の実行セルで Message Center が sessionTokenOnly を必要とします。新しいセキュリティゾーンを作成し、sessionTokenOnly を true に設定して、必要な IP のみをこのゾーンに追加します。

可能であれば、すべての allowHTTP と showErrors を false に設定し(localhost は除く)、チェックしてください

  • allowHTTP = "false":オペレーターは HTTPS を使用することを強制されます。
  • showErrors = "false":技術的エラー(SQL エラーなど)を非表示にします。これにより、表示される情報の量を抑えられますが、マーケターが(管理者に追加情報を要求することなしに)問題を解決することが難しくなります。

調査、Web アプリ、レポートを作成(実際にはプレビュー)する必要があるマーケティングユーザーまたは管理者が使用する IP に対してのみ、allowDebug を true に設定します。このフラグを使用すると、これらの IP でリレールールが表示され、デバッグできるようになります。

allowEmptyPassword、allowUserPassword、allowSQLInjection は決して true に設定しないでください。これらの属性は、v5 や v6.0 からの移行のためだけにあります。

  • allowEmptyPassword を使用すると、オペレーターは空のパスワードを設定できます。この属性を使用する場合、すべてのオペレーターに所定の期限までにパスワードを設定するよう通知してください。この期限を経過したら、この属性を false に設定します。
  • allowUserPassword を使用すると、オペレーターは資格情報をパラメーターとして送信できます(この情報は、Apache、IIS、プロキシでログに記録されます)。この機能は、以前に API の使用を簡素化するために使用されていました。クックブック(または仕様)で、サードパーティのアプリケーションがこれを使用していないかをチェックできます。使用されている場合、API の使用方法を変更して、なるべく早くこの機能を削除するよう通知する必要があります。
  • allowSQLInjection を使用すると、ユーザーは古い構文を使用した SQL インジェクションを実行できます。この属性を false に設定できるようにするために、至急、ドキュメントに記載されている修正作業を実施します。

/nl/jsp/ping.jsp?zones=true を使用すると、セキュリティゾーン設定をチェックできます。このページには、現在の IP のセキュリティ対策のアクティブステータス(これらのセキュリティフラグで計算)が表示されます。

HttpOnly cookie/useSecurityToken:sessionTokenOnly フラグを参照してください。

許可リストに追加する IP を最小限に抑える:セキュリティゾーンには、既にプライベートネットワーク用の 3 つの範囲が追加されています。通常、これらの IP アドレスをすべて使用することはありません。そのため、必要なもののみを保持するようにしてください。

Web アプリ/内部オペレーターを更新して、localhost でのみアクセス可能となるようにしてください。

ファイルアップロードの保護

nlclient/Web インターフェイスを使用して、サーバーにどのようなファイルをアップロードしているかをオペレーターにチェックします。次に、業務上必要である可能性のあるものを示します。

  • 画像(jpg、gif、png など)
  • コンテンツ(zip、html、css など)
  • マーケティングアセット(doc、xls、pdf、psd、tiff など)
  • E メール添付ファイル(doc、pdf など)
  • ETL(txt、csv、tab など)
  • その他

これらすべてを serverConf/shared/datastore/@uploadAllowlist(有効な Java 正規表現)に追加します。詳しくは、関連ドキュメントを参照してください。

Adobe Campaign では、ファイルサイズは制限されません。ただし、IIS/Apache を設定することで、ファイルサイズを制限できます。詳しくは、この節を参照してください。

リレー

詳しくは、 ドキュメントを参照してください。

デフォルトでは、すべての動的ページは、Web モジュールが起動されるマシンのローカルの Tomcat サーバーに自動的にリレーされます。それらの一部をリレーしないように設定することもできます。Adobe Campaign モジュールの一部(Web アプリ、インタラクション、一部の JSP など)を使用しない場合、リレールールから除外できます。

デフォルトでは、HTTP を使用(httpAllowed="true")するエンドユーザーリソースを表示するために、この機能を強制的に使用しています。これらのページには、一部の PII(E メールコンテンツ/アドレス)、クーポン、オファーが表示されるので、これらのパスでもう一度 HTTPS を強制する必要があります。

複数のホスト名(公開ホスト名とオペレーター用ホスト名)を使用している場合、オペレーターが必要とするリソースが公開 DNS 名経由でリレーされないようにすることができます。

発信接続の保護

Campaign Classic の JavaScript コード(ワークフローなど)で呼び出すことができる URL のデフォルトリストは、制限されています。新しい URL を許可するには、管理者が serverConf.xml ファイルでその URL への参照を設定する必要があります。

3 つの接続保護モードがあります。

  • ブロック:許可リストに登録されていない URL をすべてブロックし、エラーメッセージを表示します。これは、ポストアップグレード後のデフォルトのモードです。
  • 許可:許可リストに登録されていない URL をすべて許可します。
  • 警告:許可リストに登録されていない URL をすべて許可しますが、警告を表示します。管理者はこの警告を収集できます。このモードでは JST-310027 警告メッセージが追加されます。
<urlPermission action="warn" debugTrace="true">
  <url dnsSuffix="abc.company1.com" urlRegEx=".*" />
  <url dnsSuffix="def.partnerA_company1.com" urlRegEx=".*" />
  <url dnsSuffix="xyz.partnerB_company1.com" urlRegEx=".*" />
</urlPermission>

新しいクライアントはブロックモードを使用します。新しい URL の許可を希望する場合は、管理者に問い合わせて、その URL を許可リストに追加する必要があります。

移行してきた既存の顧客は、しばらくの間は、警告モードを使用できます。その間、URL を分析する前に、アウトバウンドトラフィックを分析する必要があります。

コマンドの制限(サーバー側)

いくつかのコマンドがブラックリストに追加され、execCommand 関数で実行できないようになりました。また、セキュリティを強化するために、外部コマンド実行専用の Unix ユーザーが追加されました。ホストされているインスタンスの場合は、この制限が自動的に適用されます。オンプレミスインスタンスの場合は、専用のドキュメントに従ってこの制約を手動で設定できます。また、ワークフローアクティビティとして「スクリプト」と「外部タスク」を選択できなくなりました(新しくインストールされたインスタンスの場合)。

その他の設定

HTTP ヘッダーを(すべてのページで)追加できます。ドキュメントを参照してください。

  • HSTS、X-FRAME-OPTIONS、CSP などのヘッダーを追加できます。
  • 本番環境に適用する前に、テスト環境でテストする必要があります。警告:ッダーを追加すると、Adobe Campaign で異常が発生する場合があります。

Adobe Campaign では、<dbcnx .../> 要素にプレーンパスワードを設定できます。この機能は使用しないでください。

デフォルトでは、Adobe Campaign はセッションを特定の IP に関連付けませんが、この機能を有効にして、セッションが乗っ取られないようにすることができます。これをおこなうには、serverConf.xml ファイルで、<authentication> ノードの checkIPConsistent 属性を true に設定します。

デフォルトでは、Adobe Campaign の MTA は、コンテンツを SMTP サーバーに送信する際にセキュリティ保護された接続を使用しません。この機能を有効にする必要があります(配信速度が低下する可能性があります)。それには、<smtp ...> ノードで enableTLS を true に設定します。

認証ノードでセッションの持続時間を短くすることができます(sessionTimeOutSec 属性)。

Web サーバーの設定

web

Web サーバー Apache/IIS 構成に関する主なベストプラクティスをいくつか紹介します。


デフォルトのエラーページを変更します。

古い SSL のバージョンと暗号を無効にします。

  • Apache で、/etc/apache2/mods-available/ssl.conf を編集します。次に例を示します。
    • SSLProtocol all -SSLv2 -SSLv3 -TLSv1
    • SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SSLv3:!SSLv2:!TLSv1
  • IIS で、次の設定をおこないます(ドキュメントを参照)。
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL にレジストリサブキーを追加します。
    • デフォルトではネゴシエートされないプロトコル(TLS 1.2 など)をシステムが使用できるようにするには、プロトコルキーにある次のレジストリキーで、DisabledByDefault 値の DWORD 値データを 0x0 に変更します。

      SCHANNEL\Protocols\TLS 1.2\Client

      SCHANNEL\Protocols\TLS 1.2\Server

    • SSL x.0 を無効にします。

      SCHANNEL\Protocols\SSL 3.0\Client: DisabledByDefault:DWORD(32 ビット)の値を 1 にします

      SCHANNEL\Protocols\SSL 3.0\Server: Enabled:DWORD(32 ビット)の値を 0 にします

TRACE メソッドを削除します。

  • Apache で、/etc/apache2/conf.d/security: TraceEnable Off を編集します。
  • IISドキュメントを参照)で、次の設定をおこないます。
    • 要求フィルタリングの役割サービスまたは機能がインストールされていることを確認します。
    • 要求フィルタリングパネルで「HTTP 動詞」タブをクリックし、「動詞の拒否」をクリックします。アクションパネルで、開くダイアログに「TRACE」と入力します。

バナーを削除します。

  • Apache で、/etc/apache2/conf.d/security を編集します。
    • ServerSignature Off
    • ServerTokens Prod
  • IISドキュメントを参照)で、次の設定をおこないます。
    • URLScan をインストールします。
    • Urlscan.ini ファイルを編集して、RemoveServerHeader=1 を設定します。

クエリのサイズを制限して、重要なファイルがアップロードされないようにします。

  • Apache(ドキュメントを参照)で、LimitRequestBody ディレクティブ(サイズはバイト単位で指定)を / ディレクトリに追加します。

<Directory />
        Options FollowSymLinks
        AllowOverride None
        LimitRequestBody 10485760
</Directory>
  • IIS(ドキュメントを参照)で、コンテンツフィルタリングオプションに maxAllowedContentLength(許容最大コンテンツ長)を設定します。