Question

我在银行工作，安全是一个主要问题。我们目前在Adobe的收集服务器（例如stats.bank.com）上使用cname，以便让Adobe在bank.com域上提供第一方cookie。我们的安全委员会现在说我们不应该为stats.bank.com提供Adobe新的SSL证书，因为它风险太大，如果stats.bank.com遭到入侵并且有人攻击我们的客户，那么我们承担责任，因为它是我们的品牌和所有cookie数据都暴露在外，同时让客户容易受到恶意软件攻击。所以我们有以下选择：

在内部提交报告
设置一个过滤代理，操作为“stats.bank.com”，前端相关的Adobe服务
返回Adobe的第三方解决方案2o7.net名称空间
在adobe的服务器上使用不同的第三方命名空间（例如stats.bk.com）

以下是我们的想法：

1）太贵了

2）我们认为这是一个很好的解决方案，但随后成本上升了。由于呼叫量的原因，构建这种类型的基础设施似乎非常昂贵。

3）Adobe的第三方命名空间被阻止太多了。

4）似乎可能是一个解决方案，但仍然担心第三方被阻止。

我想知道是否有人必须处理这些类型的安全问题以及解决方案是什么。特别是解决方案＃4的缺点是什么？

Answer 1

Adobe的跟踪Cookie中根本没有个人身份信息或个人信息。

在我说出任何其他内容之前，根据您所说的话，我只想说，我认为您的安全委员会要么误导Adobe跟踪cookie，要么不切实际地将事情吹得不成比例。

访问者ID（s_vi）Cookie就是：包含访问者ID值的Cookie。以下是cookie值的示例：

[CS]v1|2A933F6C05079103-6000110EA000D3F3[CE]

值 nothing 与访问者的个人信息或数据或类似内容有关。它是一个随机生成的值，只要cookie仍然存在就会粘在访问者身上。

为您执行的任何自定义编码创建的Cookie不是一回事

看，这是我认为有些人可能会感到困惑的地方。以下是一个常见的解释方案：成员ID跟踪。访问者第一次访问您的网站时是匿名的。他们登录您的网站，现在您的网站知道他们是谁。

从跟踪角度来看，通常会有一个反映这一点的道具和/或eVar。因此，在您不了解访问者的页面/点击中，您不会弹出任何内容，或者您可能会弹出一些默认的＆＃34;匿名＆＃34;或＆＃34;未知＆＃34;或者＆＃34;退出＆＃34;值。然后，当访问者登录时，您将使用您的站点识别为成员或帐户ID的值弹出prop / eVar。

也许此ID是他们的电子邮件地址。也许它是一个随机生成的值。也许它是一个用户名。重点是，在您自己网站的系统中唯一标识访问者是一种东西。

所以，让我们假设您在登录时编写代码，然后使用该值弹出prop1，然后您决定使用Adobe的getAndPersist插件。这个插件基本上取一个值并将其放入cookie中，然后在每次调用插件时检索该值。这里的想法是你只需要完成工作就能得到你最终的价值，然后Omniture将从那里坚持下去。当您希望为每个页面/匹配弹出一个值但是可能无法轻松访问复制或将逻辑范围扩展到站点的所有区域时（尤其是跨子域），这尤其有用。

所以现在你有一个由Adobe Analytics代码设置的cookie。 这与s_vi cookie完全无关。

首先，它是你明确设定的东西，即使它只是为了让球滚动。其次，该值不存储在s_vi cookie中;它存储在单独的第一方cookie中。

即使你有FPC跟踪，它仍然设置在一个单独的cookie中。实际的cookie名称取决于您正在使用的插件（或者您自己使用Adobe的s.c_w cookie写入功能），以及您是否使用组合的cookie插件（在这种情况下它将被放置）在s_sess或s_pers中，具体取决于您设置的到期时间

现在..如果您确实已经实施了FPC，您显然可以用自己的值覆盖该cookie。显然，你可以随心所欲地创造这个价值，包括访客个人的东西。但这并不是Adobe所做的;那是你的做的。

总的来说，无论您是让访问者跟踪第一方还是第三方，这都是与个人数据无关的完全独立的Cookie。

您可能拥有包含个人数据的自定义编码，您甚至可以使用Adobe Analytics功能将这些数据放入Cookie中，但这不是一回事。它将始终是第一方cookie（js不可能写第三方cookie），并且cookie将始终是独立的。

尽管如此，s_vi访客ID可用于间接获取个人数据

我确信接下来听到的内容将是＆＃34;但它并不重要，它是访客的独特身份，而且它是在Adobe，以及其他数据，您可以使用访客ID在Adobe中查找数据！＆＃34;

这是事实。然而...

首先，为了在Adobe Analytics中找到可识别个人身份的数据，您必须明确地将其放在那里。例如，你必须设置如下内容：

s.prop1='jon doe'; // name
s.prop2='4321 1111 1111 1111'; // credit card #
s.prop3='04/2020'; // exp date
s.prop4='123';  // security number

我认为我不应该告诉你这是一个非常糟糕的主意，但重点是，这不是Adobe收集的信息，它是你在做什么它。并且它不在s_vi访问者ID cookie中，也不能存在（再次，除非你有fpc imp并决定用这些值明确覆盖cookie）。

因此，数据以及访客ID将转移到Adobe服务器。因此，下一个障碍是：访问Adobe中的数据。坏人必须在您的公司下拥有一个Adobe Analytics用户帐户，并且必须具有适当的权限才能获得对该数据的访问权限。

即便如此， Adobe实际上并没有在报告中公开访问者ID值。因此，为了获取与某个访客ID相关联的数据，您需要访问数据仓库，或者列为受支持的用户并从ClientCare请求原始命中日志。

我想这里的总体观点是，访客身份本身并不是真正危险的事情。它不是个人数据，并且能够利用它来查找与其相关的特定数据，这将涉及到最初将个人数据存储在Adobe服务器上的极端愚蠢行为，以及获得对所述数据的访问权限。服务器/接口。

除此之外......

好吧，也许你不关心上面所有的东西。或者也许没有一个说服你的安全委员会让步。你正在逐渐远离Adobe FPC imp，那就是它的全部内容。因此，让我们谈谈您列出的选项以及您对它们的担忧。

在内部提交报告

你说这太贵了。＆＃34;你知道，我在这里说实话......这有点可笑，来自银行！但是认真..

也许你认为从建筑物到地面从头开始看它太贵了？如果是这种情况，您是否考虑过已经构建的选项，您可以将它们放在自己的服务器上并从那里进行自定义或构建？

Webtrends提供此功能。坦率地说，我讨厌Webtrends作为跟踪解决方案，但它确实提供了将它放在你自己的服务器上的能力（最后我听说，反正）。此外，Piwik是一个非常好的开源解决方案。

过滤代理

我不太清楚你的意思。这听起来很像FPC跟踪..除了有办法在进入Adobe之前清除所有个人数据请求？如果是这样的话，我会回到关于首先向Adobe发送个人数据的观点。但是好吧，也许你不是那样做的，但是为了以防万一，我们希望有一个额外的预防措施;很公平。

所以也许你在你的终端设置了一个服务，将所有请求发送到stats.bank.com并且它可以擦除东西，甚至可能有值的映射（比如访问者ID）。原则上，这不是一个非常复杂的脚本，所以我不得不想知道为什么成本是一个问题，特别是来自银行..但无论如何..

坚持使用Adobe的第三方Cookie实施

如果您想使用Adobe拥有的域名返回第三方Cookie跟踪，而不是使用默认的2o7.net域名，我建议您考虑{{3}的新（第三方）Cookie实施}}。

滚动您自己的第三方Cookie实施

据我所知，Adobe不提供任何类型的服务，涉及您指定他们的域名来购买/拥有并从第三方实施中收集数据。

对此的最近服务是第一方Cookie跟踪。所以，如果你有www.bank.com，通常你会指定类似stats.bank.com（根域中的某些内容）和FPC跟踪的内容。

但是，您可以告诉Adobe使用例如stats.someotherdomain.com（假设您拥有并控制它），并且他们可以为该域实施FPC跟踪。然后，当您在www.bank.com上实施跟踪时，实际上会成为第三方Cookie跟踪。

但需要注意的是你仍然拥有该域，所以我只能假设某些级别，你仍然要为它负责（我＆＃39;我不是律师）。但是，也许这足以安抚你的安全委员会，值得把它带给他们。

Answer 2

我补充说，根据Adobe一般服务条款，“客户同意不使用按需或托管服务收集，处理或存储任何敏感个人数据。”因此，如果您正在收集任何可以追溯到个人的数据 - 例如，电子邮件地址或电话号码 - 那么您违反了服务条款。因此，对安全问题的回应可能是，“公开客户PII违反了我们的服务条款，因此我们不这样做。”

Adobe Analytics - 从第一方Cookie转移到第三方Cookie以获取安全原因

2 个答案: