过去几十年里，大多数IT部门大都经历着类似的发展历程：最初使用的都是一个高度集中的整装计算机系统(比如，大型主机)，但随后就像宇宙大爆炸一样，计算机资源爆炸式的四散开去，被前所未见的分散和去集中化了。在市场如此活跃的情况下，这种分散是很有意义的。计算机平台升级很快，单个的大型主机需要有高昂的维护费用来作支持，这还不如追加投资给低耗能的设备了，所以说大型主机是在不断贬值的，其效率也就相应降低了。
因此，计算机处理逐步去集中化是很自然的过程。事实上，近些年发明的很多技术都在推动这个趋势的发展。
因为分散程度越来越高，从逻辑上讲，存储接下来也将(总体而言)变得越来越分散。而事实上，存储要在集中和分散之间进行权衡。存储所扮演的角色比较特殊，数据被存储时需要足够的集中，这样便于管理;但同时却又需要足够的分散，以方便客户的有效利用。这就是目前所面临的问题。但这一局面正在发生改变——这种改变将从安全的角度影响我们管理IT的总体模式，那就是“大数据”。
什么是“大数据”
新兴的--“大数据”—是虚拟技术、云计算和数据中心三者使用率增加后的逻辑衍生物。这几项技术均有着高成本与高效率的特点。并且它们都能在计算资源的标准化、整合和集中化上发挥杠杆作用，从而实现规模经济，也帮助成本效益的实现。但当企业采用了诸如集中存储之类的技术之后，随即就发现这产生了大量的数据，在某些情况下，甚至达到了EB级别。EB到底是怎样的一个级别呢?自有史记载以来，人类所产生的信息量总计约为5EB。
有识之士(比如社交网络里面的一些善于观察的工程师和科学家)已经发现：如果大量数据集中在一地，那么将有机会利用这些数据来达到提高收益的目的。这似乎是大数据能带来的意外收获。所以，随着数据量滚雪球般增加的同时，也浮现了利用这些数据增值的机会。这对企业来说具有革命性的意义，它让我们更多地了解自己的客户，了解他们如何享用我们的服务，以及我们的业务总体运行情况。
当然，对于我们这些注重安全性的人而言，毫无疑问，它已经改变了整个格局。从安全的角度考虑，这种转变的影响有正面的也有负面的。比如，一方面，将所有的数据都存储在同一个地方，这使得保护数据会变得更加简单;而另一方面，也方便了黑客，他们的目标变得更有诱惑力。如果想从安全的角度来探究大数据所有利弊可能会花费大量的时间，但是随着这种转变的深入，数据安全的准则将发生改变。
为什么呢?因为数据量是非线性增长的。绝大多数企业都没有专门的工具或流程来应对这种非线性增长。也就是说，随着数据量的不断增长，我们看到，传统工具尤其是安全工具正在淡出舞台(其实早已经开始了)，因为它们已经不再像以前那么有用了。
所以，对于想抢在这种改变出现之前就预先制定计划(换个说法就是，“避免一开始就被牵着鼻子走”)的企业而言，他们必须考虑清楚，怎样才能避免被动地应对这种改变。如果你考虑使用天然气的话，你肯定不会先储备一堆煤球，不是吗?所以，重视这个行业的走向是很有必要的。
使用的工具和应对流程非常重要
可能有些人会马上质疑：这有什么要紧?或“我才不在乎数据量大小，安全工具怎么可能会受到影响?”静下心来想一想，你的系统正在用什么工具确保其安全?然后再深入地想一下，这些工具中，有多少可支持对有限数据的搜索或转换?
请进一步考虑一下，要在一个大型的网络附加存储或SAN中扫描一个恶意软件是多么困难的事情。如果这数据库增大1千倍，又会花费多少时间? 10万倍呢?如果以几何速度增长呢? 到时还能像现在这样每天都能全扫描一次吗?
如果在对数据进行挖掘时需要进行数据泄漏防护(DLP)或法规遵从又会怎样呢?比如说PCI 审计员需要对存储在持卡人信息库中的数据进行信用卡号搜索时，(CDE数据量达到EB级别的情况不在此例)会出现什么情况?搜索本身就难度够大了，更别说对扫描后GB级别误报的手动确认了。这两种操作已经变得不太现实，如果我们还沿用以前的方法的话。
很多技术方案中，数据的大小会影响到安全控制或配套操作能否正确运行。想象一下，例如，为了确保存储数据和基于文件的数据完整性和可控性，需要对它们进行日志分析、文件监督和加密/解密操作。这些都属于数据的处理功能。想让这些操作继续可行，对它们进行升级是很有必要的。所以，为了在大数据世界里让扫描一如既往地容易，一些有识之士已经开始设计新工具了(例如，数据库)，所以，我们使用的安全工具也必须革新，这样才能应对新的挑战。
当然，改变不可能一蹴而就，但对于安全方面的专业人士而言，是时候考虑这个问题了，如果他们考虑购买新工具的时候脑子里能有这个想法就再好不过了。数据已经开始呈几何趋势增长，所以研发出一个新的基于线性数据扫描的工具应该不是最佳的解决方法，至少已经给供应商带来了一些棘手的问题。相反，它可能会加速像文件加密等操作的使用，基于线性数据扫描的技术出现后，这些技术使用率就都在逐步攀升。想一次性为EB级别的数据加密可能不是那么容易的事情，但是，如果该操作是在数据大规模增长前适时进行的呢，这种情况下会怎样? 这样的话，就可能是另一码事了。
幸好我们还有时间去应对。在问题变得更加棘手之前还有时间调整我们的操作和控制程序。但想一想虚拟化进程的速度是何等之快，这个问题可能会比我们预计地更早地出现。所以，花些时间想这个问题是有意义的。
