一、建立和维护一个安全的网络和系统

要求2：不要使用供应商提供的默认系统密码和其他安全参数

划重点！划重点！要点2可谓是直戳人心，我想这个不必细讲大家都知道默认密码或者弱密码带来的危害有多大！就说最近吧，乌克兰军方系统的123456密码可是好好的给我上了一课，太真实了，且不细究这是默认密码还是改成这么简单的，但是带来的危害可想而知！
当我们在某个系统组件或者软件中使用默认密码的的时候，攻击者可以很容易就通过网上或者产品提供商出获取默认密码进行攻击。这个攻击场景是十分十分常见的，博主在高校教育网中就见过无数次了，不论是校园网的平台还是其他管理系统的平台。默认密码屡见不鲜，因此强烈建议不使用供应商提供的默认密码。就算默认密码是一个很复杂的密码也必须更改！默认空密码的就更不用说了。

2.1 始终更改供应商提供的默认值并于在网络中安装系统之前删除或禁用不必要的默认账户

（此要求适用于所有默认密码。包括但不限于操作系统、提供安全服务的软件、应用程序和系统账户、销售点（POS）终端、支付应用程序、简单网络管理协议（SNMP）社区字符串等使用的默认密码）。

2.1

在我们使用了第三方提供的软件、应用操作系统等时一定要在上线之前更改掉供应商提供的默认密码，特别是默认空密码的，一定要增加密码，并且对于一些测试的账号或者无作用的默认账号一定要删除！也说说默认账号带来的危害，之前rabbitmq就有默认的guest账号登录，且有所有的操作权限，还有很多的这样的默认账户，我们需要在软件或者应用正式使用之前就删除这些不用的默认账户。

2.1.1 对于连接到持卡人数据环境或传输持卡人数据的无线环境，在安装时更改所有无线供应商的默认值，包括但不限于默认的无线密钥、密码和SNMP社区字符串

2.1.1

在要求1里面我们曾经画过持卡人数据的数据流图和网络拓扑图，我们已经清楚的了解到那些网络环境里面会存储或传输持卡人数据，对于这些网络环境我们需要重点关注。更改默认路由器或交换机的默认账号，默认密码。或者简单网络管理协议(SNMP)，若管理员配置不当运行默认团体名/弱口令访问,将导致敏感信息泄露。无线网络是很容易被嗅探窃取信息的。比如校园网或者公司的办公网，很容易被嗅探，学校内嗅探“借”校园网流量的也不少。

2.2 制定适合所有系统组件的配置标准。确保这些标准能解决所有已知的安全漏洞并与行业认可的系统强化标准一致

行业认可的系统强化标准来源包括但不限于：
1、互联网安全中心（CIS）
2、国际标准化组织（ISO）
3、美国系统网络安全协会（SANS）
4、国家标准与技术研究所（NIST）

2.2

这里其实就是让我们参照权威机构发布的标准来严格标准化我们的系统组件配置。我们主要看看2.2.d的详细步骤，这里具体讲了标准化的主要程序和步骤，这里前面也都说到了。谈一谈其中的一点，每台服务器仅执行一项主要功能买一房至不同安全级别的功能并存于同一台服务器上。
因为对于不同安全级别的服务器我们采取的安全保护措施肯定是不同的，还是比如我们web server和数据服务器在一台服务器上的话就很危险。
其他的主要就是按照CIS或者ISO啊之类根据我们环境的系统组件定制我们自己的标准，并严格执行，检测。

2.2.1 每台服务器仅执行一项主要功能，以防需要不同安全级别的功能并存在同一台服务器上。

（例如web服务器、数据库服务器和DNS服务器均应在单独的服务器上执行）

2.2.1

好吧，前面刚刚说到，这里的2.2.1就是说这一点，看来我还是抓住了重点的。这里来说说，如果两个安全级别不同的功能在一个服务器上，如果我们使用高安全级别的话可能会对低安全级别的功能产生影响，如果使用低安全级别的整个服务器的安全有没有达到标准，没有得到保障。很多运维工程师对待这样的服务器往往会舍弃安全换取便利，使用低安全标准，这样带来了很大的服务器被攻击的隐患，同时我们也确保如果一个服务被攻击后不会导致其他的服务快速沦陷。
举个例子来说，我们如果把两种不同的动物圈养在一个栅栏里面，我们首先不知道两个动物会不会相互影响，就算不会相互影响，我们设计栅栏的时候也是很困难的，栅栏低了，长得高的动物可以逃跑，栅栏高了，长得低的动物无法时刻被圈养者关注着。

2.2.2 仅启用系统功能所需的必要服务、协议、守护进程等

2.2.2

这和1.3.1有一点相似，1.3.1是禁止向不安全的协议，服务端口，输入流量，这里是不启用那些非必要的服务、协议端口。前者是从防火墙角度，这里直接是从服务器，源头解决安全隐患。就算有存在不安全的的服务、协议、端口，但是又是必须的，这就得必须确认通过公司的安全标准。

2.2.3 针对任何被视为不安全的必要服务、协议或守护进程实施附加安全功能

2.23

这个在上面也提到了，如果一个不安全的协议、服务、端口是一个业务的必须条件，那我们就得实施自己的安全策略将解决协议或服务的不安全性，自己添加策略确保安全，同时也要有记录！

2.2.4 配置系统参数，以防滥用

2.2.4

这个应该是针对那些具体系统或应用来说的，我们要根据具体系统的安全参数来配置。比如mysql的安全配置，一个数据库一个账号，root只允许本机登录等。

2.2.5 删除所有非必要功能，例如脚本、驱动程序、特性、子系统、文件系统和不必要的Web服务器

2.2.5

对于一个安全体系较为完整的公司来说，每一个正在使用的系统，服务等都会有相应的记录和负责人员，如果一些系统废弃了，更换了，在整理完数据之后我们有必要删除那些非必要的脚本或者系统等。之前给某个公司做授权的渗透测试时，发现公司一个老域名上有一个已经废弃的web服务，准备几个月后更新，这几个月一直处于无人监管的状态，在这里就有一大堆的sql注入，身份验证绕过漏洞。所以对于废弃服务，或者不必要的脚本，驱动我们一定要定时检测，清理，就算暂时不用也要进行安全隔离。

2.3 使用强效加密法对所有非控制台管理访问进行加密

2.3-1
2.3-2

这里也是很重要的一点，就是说我们如果不是在管理台登录的管理系统，在其他地方登陆，比如我们ssh登录到某台服务器，或者http访问某个管理后台，所有的远程访问的时候我们就必须对我们的访问进行强效的加密算法进行加密！不然很容易就被窃取密码。当然前提我们也得保证加密算法或者协议的安全性，比如当时heartbleed的漏洞。

2.4 保留一份PCI DSS范围内系统组件的清单

2.4

这个就是自己制定一份清单，这个清单就是包括所有在PCI DSS这个标准下的系统组件，如果出问题我们可以缩小范围。以及防止我们以防某个重要系统组件是否受到安全的保障。

2.5 确保已记录、正在使用且所有相关方了解用于管理供应商默认设置及其他安全参数的安全政策和操作程序

2.5

对那些使用了供应商默认设置以及其他安全参数的安全政策的操作都有记录。且实时更新。比如我们一个邮件服务，我们哪些使用了供应商默认的，要有确认检测并记录，为了达到安全标准我们做了哪些安全参数的调整，这些也要记录。

2.6 共享托管服务商必须保护每个实体的托管环境和持卡人数据。

这些提供商必须符合附录A1中详述的具体要求：《针对供应商托管服务提供商的PCI DSS附加要求》中详述的具体要求。

2.6

这是针对服务器，托管环境提供商对客户服务器的保护的要求。主要在附录A1中，虽然不是针对公司的，但是我们也得知道服务商能为我们做到什么样的抱回。我们具体看看这四个要求。

附录A1：针对共享托管服务提供商的PCI DSS附加要求

A1

托管服务提供商必须保护每个实体的托管环境和数据。举个例子，比如我们公司寻找一个数据中心托管服务商，需要考虑很多问题，除了网络上的保护，还有物理上的，比如我们会找一个不会发生地震这种天灾的，离公司近的托管服务商。PCI DSS特地对托管服务商也有很多要求，这是在确保公司内部做好之后，第三方的提供商也有足够的安全保护策略。这个也方便我们在寻找托管服务提供商的时候大概有一个标准，而不是听对方的盲目吹牛。

A1.1 确保每个实体仅运行可访问自身持法人数据环境的流程

A1.1

就是共享托管服务提供商必须保证每个客户只能访问和运行自己的服务器，或者说数据环境。具体一点就是我每一个实体（商户，客户）都有自己特定的账户，而不是共享的一个。就是做好权限的划分，特定客户自己的只能操作和访问他自己的，对其他实体都没有权限。

A1.2 每个实体的访问权限和特权仅限其自身的持卡人数据环境

A1.2

同样是权限的问题，每个实体都只有自己的文件和目录的权限，没有其他用户的文件或文件夹的任何权限，也没有对任何系统文件的任何权限。系统文件这些应该掌握在托管服务提供商手上。同时对服务器上不同的资源均已分配好和有限制，不会造成其他漏洞被利用。

A1.3 确保日志记录和检查记录已启用、对于每个实体的持卡人数据环境唯一且符合PCI DSS要求10

A1.3

这里是保证托管服务提供商对指定客户有指定的日志记录，同时确保日志记录处于活动状态。且可供客户查看。这样客户自己就可以通过日志查看操作和登录等信息。

A1.4 启用相关流程，确保在任何托管商户或服务器提供商受到威胁时提供及时的取证调查

A1.4

这个就根据字面上就可以理解的。服务商得有相关书面政策，如果服务提供商出现问题，服务提供商是可以被取证调查的。如果我们的数据等在服务提供商那里出现问题，我们可以根据他们之前的书面政策，对服务商进行取证调查。

总结

要求2大概到这里就结束了。要求2：不要使用供应商提供的默认系统密码和其他安全参数
很重要的一点，虽然看起来只有一句话，但是细看下来里面的内容还是不少的。最后还是告诫相关从业者，不要图自己的方便，而使用了默认提供商提供的这些默认配置，他们并不用为你的安全负责，但你自己要！很多时候不得不使用，也得有一定的安全策略保证其符合PCI DSS的标准！
后面也看了看附录A中对托管服务提供商的一些要求，这些也为大家提供了意见，这个也是必须要了解的，起码能知道他们能为我们做到什么地步，更多的还是要看到他们做不到或者不能做的地方，我们自己需要去补充。