|
大类
|
序号
|
要素内容
|
审查结果
|
|
口令策略
|
1
|
长度要求：口令长度的取值范围为：1-32 个字符；默认：最短长度为 6 个字符，最长长度为 32 个字符；
1、最短长度可以根据具体的业务进行配置；
2、最长长度可以根据具体的业务进行配置，并且最短长度不能大于最长长度。
|
|
|
2
|
字符集要求：口令中至少需要包括一个大写字母（A-Z）、一个小写字母（a-z）、一个数字字符（0-9）、一个特殊字符；
1、是否至少包含特殊字符要求可以配置，即是可选的；
2、特殊字符集全集为：!"#$%&'()*+,-./:;<=>?@[]^`{_|}~；
3、特殊字符集实际包含哪些字符要求可以配置。
|
|
|
3
|
可重复字符数要求：最多可重复字符数的取值范围是：1-6；默认为 3 个；
1、最多可重复字符数要求可以配置。
|
|
|
4
|
弱口令词典要求：口令不能是出现在指定弱口令词典中的词；每个产品提供并维护各自的弱口令词典；
1、要求在口令被泄密（或者被猜测到等）需要及时对弱口令词典进行维护。
|
|
|
5
|
口令历史记录数要求：口令历史记录数的取值范围为：0-30；默认：3 个；
1、要求口令历史记录数可以根据具体的业务进行配置。
|
|
|
6
|
口令保存期要求：最短保存期的取值范围：0-1440 分钟（1 天），默认：5 分钟；最长保存期的取值范围：1-1096 天（约 3 年），默认：90 天（约 3 个月）。
|
|
|
7
|
管理员可以修改自己和其他用户/操作员的口令。管理员修改其他用户/操作员口令时，不需要提供旧口令。管理员/用户/操作员修改自己的口令时，必须提供旧口令
|
|
|
8
|
初始口令为系统提供的默认口令时、或者是由管理员设定时，则在用户/操作员在第一次登录时（或者第一次登录成功后）强制要求更改口令，并直至更改成功。用户/操作员的口令如果是被管理员修改的，那么在用户/操作员第一次登录成功后强制要求修改口令，并直至更改成功。在口令到期前系统最迟提前 1 天提示，最早提前 99 天提示，即取值范围：1-99 天，默认：7 天。口令到达最长保存期后，用户再次登录时系统强制更改口令，并直至更改成功后才能登录成功
|
|
|
9
|
口令不能以明文的形式在界面上显示，要求显示为一串星号（*）。口令不能以明文的形式保存，必须加密保存；加密前，用户口令需要和用户名关联，即加密前的数据不仅包括口令，还需要包括用户名
|
|
|
10
|
口令策略以公共部件实现。以产品域为单位，域内各个产品可以共享，避免重复开发
|
|
|
认证及会话控制
|
11
|
基于 HTTP 协议：HTTP 是无状态协议，即意味着 WEB 服务器将每个 HTTP 请求都当作相互无关的请求进行处理，因此，在处理浏览器（客户端）的认证请求和授权操作时，则必须要提供会话支持。会话是由服务器端开发环境构建的抽象层，不同的会话状态管理机制以及会话状态的内部实现方式取决于平台的基础结构。实际实现时应满足如下要求：
1、尽量采用 WEB 平台环境提供的会话支持功能，例如：JSP、ASP.net 等程序都提供了相应的会话管理模块或接口；
2、提供一个公共的认证模块用于保持和跟踪用户的会话状态，一旦跟踪到非法会话，则出错或返回到认证界面；
3、每一个用于处理授权操作的 WEB 服务程序文件都必须调用该认证模块，且需在程序文件的开头调用；
4、当浏览器（客户端）执行回退操作时，历史页面将失效。
|
|
|
12
|
基于 TCP/IP 协议：
1、不允许服务端仅仅依靠源 IP 地址来认证客户端，必须使用用户名/口令、动态口令等安全认证方式；
2、要求连接成功后客户端发送的第一个数据包总是认证请求包。如果服务端认证失败，返回认证失败的应答包后将连接立即断开。
|
|
|
13
|
基于 UDP/IP 协议：在发送方发送的任何有需要认证要求的数据包中附加认证信息，接收方在接收到信息包后首先根据认证信息进行认证，如果认证通过，则继续数据处理，否则终止数据的处理
|
|
|
14
|
认证失败等情况发生后，不能提示给用户详细以及明确的错误原因，只能给出一般性提示。如：
1、可以提示：“用户名或者口令错误，登录失败”；
2、不能提示：“用户名不存在”、“口令必须是 6 位”等等。
|
|
|
15
|
锁定要求：客户端在多次连续尝试登录失败后，服务端需要将用户帐号或者是客户端所在机器的 IP 地址锁定，在锁定期间不允许该用户帐号（或者该 IP 上的所有客户端）登录；
1、允许连续失败的次数（指从最后一次成功以来失败次数的累计值）取值范围为：1-10 次，默认：5 次。锁定时长的取值范围为：0-1440 分钟（1 天），默认：30 分钟，当取值为 0 时，表示无限期锁定；
2、如果服务端将用户帐号或者是客户端所在机器的 IP 地址锁定了，那么在锁定时间过后，需要自动解锁锁定的用户帐号（IP）；
3、需要提供管理员对服务器锁定其它用户帐号（IP）进行解锁的功能界面，即需要实现管理员可以解锁服务器锁定的用户帐号（IP）的功能；
4、当锁定时长的取值为 0 并且用户帐号或者是客户端所在机器的 IP 地址被锁定，此时用户帐号（IP）处于无限期锁定状态，用户帐号（IP）不会自动解锁，只能通过管理员手动解锁。
5、超级用户帐号不能被锁定，只能锁定操作的客户端所在的 IP。
|
|
|
16
|
服务器能够通过客户端地址、或者是当前总会话数、或者是允许时间段登录等条件限制客户端的登录
|
|
|
17
|
具有操作界面的应用程序/客户端需要在用户长时间（1-60 分钟，默认：10 分钟）没有操作时自动锁定界面；锁定后，界面上不能继续显示敏感信息，只能显示解锁的相关信息；用户解锁时，需要用户提供同认证时一样的认证信息，如果客户端具有本地认证的功能，认证在本地完成，如果客户端没有本地认证的功能，那么此时的认证必须是在服务端完成的
|
|
|
18
|
一次会话成功建立之后，需要给当前用户显示有关的访问历史记录数据，包括：
1、上一次会话成功建立的日期、时间和位置等信息；
2、上一次会话建立不成功的日期、时间和位置等信息；
3、自从最后一次成功的会话建立以来不成功的尝试次数；
4、口令将到期的天数。
|
|
|
验证码
|
19
|
验证码字符串要求是随机生成，其中生成随机数的函数要求是安全的。建议：
1、Windows 环境下是使用 CryptGenRandom 来生成随机数；
2、Unix、Linux 环境下是从名为 /dev/random 或者 /dev/urandom 的设备中读取从而得到随机数；
3、Java 中是使用类 java.security.SecureRandom 来生成随机数。
|
|
|
20
|
长度要求：验证码长度的取值范围：1-8 个字符，默认：4 个字符。
1、要求验证码长度可以根据业务需求进行配置；
2、对于安全要求更高的情况，则要求连续多次生成的验证码的长度随机变化。
|
|
|
21
|
字符集要求：验证码字符串字符集，建议只由数字组成；
1、对于安全要求更高的情况，则要求同时存在数字、小写英文字母，大写英文字母，甚至还要求同时存在标点符号等特殊字符、同时存在本地语言字符（如：汉字）；
2、对于字符集是否包含英文字母、大小写、特殊字符等要求可以配置。
|
|
|
22
|
字符字体要求：建议验证码字符的字体为一种字形，字号大小一样；
1、对于安全要求更高的情况，则要求验证码的每个字符的字形都不一样，每个字符的字号大小也不全一样；
2、要求可以配置字形、字号是否一样；
3、要求可以配置有哪些字形、字号。
|
|
|
23
|
字符串位置要求：建议每次生成的验证码字符串位置一样。
1、对于安全要求更高的情况，则要求连续多次生成的验证码字符串位置随机变化；
2、要求可以配置位置是否一样；
3、要求可以配置有哪些位置。
|
|
|
24
|
格式要求：图片格式可以采用 JPEG、PNG、GIF；默认：采用 JPEG 格式；
1、不能使用 XBM 格式，因为 XBM 存在漏洞。
|
|
|
25
|
颜色要求：建议图片中字符串的颜色和背景颜色很接近即可；
1、对于安全要求更高的情况，则要求为黑白图片，即字符和干扰象素都是黑色，背景是白色；
2、要求是否为黑白图片是可以配置的。
|
|
|
26
|
背景干扰要求：背景干扰象素点覆盖率至少要达到 20％，最大为 90％；
1、建议：背景干扰象素点覆盖率至少要达到 50％，每次生成验证码图片的背景干扰是一样的；
2、对于安全要求更高的情况，则要求连续多次生成的验证码图片的背景干扰随机变化；
3、要求可配背景干扰是否一样；
4、背景干扰象素点覆盖率可配。
|
|
|
27
|
验证码在一次使用后要求立即失效，即该验证码在后续的应用中不能再使用，新的应用需要重新生成验证码；
1、验证码在一定时间（1-60 分钟，默认：3 分钟）后，无论客户端是否进行过验证，都应立即失效。
|
|
|
28
|
图片验证码的关键是不能在客户端留下图片的真实URL，或可对应反推源地址的信息。建议：
1、在 PHP 中，通过调用 GD 库等方式生成 JPG/GIF 等图形格式的注册验证码；
2、ASP 采用以下两种种方式实现图形验证码：
3、如果是购买的虚拟主机，那么可以采用将 JPG/GIF 图片放到数据库，然后用 SESSION 传值的方式，最后利用 ASP直接从数据库中输出图片；
4、如果是有管理员控制权限的用户，可以考虑采用第三方组件来实现。
|
|
|
加解密算法
|
29
|
对于同一类别的算法要求通过配置可以改变具体的算法；
1、采用不可逆算法时，要求通过配置可以选择是：MD5、SHA-256 等；
2、采用对称加密算法时，要求通过配置可以选择是：RC4、DES、AES 等；
3、采用非对称加密算法时，要求通过配置可以选择是：ECC、RSA 等。
|
|
|
30
|
对于某一种对称加解密算法，如果它支持多个密钥长度，则要求密钥的长度可配
|
|
|
31
|
对于某一种非对称加解密算法，如果它支持多个模长，则要求模长可配
|
|
|
加密协议
|
32
|
对于传输数据的加密策略，可以根据实际情况，灵活采用：
1、如果通信数据量大、但是其中的敏感数据又很少的情况，可以采用非对称算法（公钥加密、私钥解密）并只对其中的敏感数据加密；
2、对于需要加密的数据的量比较大时，可以采用数字信封的方式；
3、对于数据量大、同时还有性能要求时，可以先采用非对称加密算法完成对称密钥的共享（公钥加密、私钥解密），然后通信双方使用共享的对称密钥采用对称算法进行加解密。
4、基于 SSL 实现数据的传输。
|
|
|
33
|
如果数据的传输是在内部安全网内，可以继续使用明文的应用层协议，如果数据的传输经过了不安全的网络（如：Internet 等），则需要使用加密的协议替代明文的应用层协议
|
|
|
34
|
对于是使用明文协议还是使用加密协议，要求做到可以配置
|
|
|
密钥管理
|
35
|
如果使用用户输入的口令作为加密的密钥时，不直接使用口令作为密钥，而是把口令经过密钥导出算法（如：PKCS5）处理后的结果作为加密的密钥，这样才具有更好的密码学特性
|
|
|
36
|
对称密钥：
1、对称密钥在程序启动时，由操作员手工输入口令，经过密钥导出算法（如：PKCS5）处理得到；
2、对于程序是被带起的、操作员无法干预的情况，口令使用对称密钥加密保存，使用时再使用对称密钥解密出来。在公共的密钥管理模块未开发出来之前，对称密钥暂时写死到代码中，并遵循以下原则：
a、变换原则：写死到代码中的串并不是最终的密钥串，而是一个初始串，将该初始串经过密钥导出算法（如：PKCS5）处理后得到的结果才是最终的密钥串；
b、不可见原则：写死到代码中的初始串使用不可见字符（不包括字符串结束符：0x00）；
c、不重复原则：初始串中任意两个连续的字符不能是相同的；
d、不连续原则：初始串中任意两个连续的字符不能是两个连续的值（如：0x99、0x98 是连续的两个值）；
e、分散保存原则：初始串不能保存到一个数组或者一个整串中。需要按字节拆分，将初始串保存到字节变量中，并且各个字节变量不能连续定义，需要在不同的代码位置定义，即：将初始串按字节分散保存；
f、赋值原则：不采用初始化赋值，而采用赋值语句给每个字节赋值。
|
|
|
37
|
口令修改功能和应用程序集成在一起，不能以工具形式单独提供。其中：windows 界面程序的口令修改功能以界面方式提供；无界面的进程的口令修改功能以命令行方式提供，命令名就是进程名，以不同参数选项与运行区别，如：启动进程为：aaa.exe -r，修改口令为：aaa.exe -p oldpwd newpwd；unix 程序同 windows 下的无界面进程。
1、应用程序如果实现了口令修改功能，那么同时还需要提供修改口令的接口，即外部程序可以通过该接口修改口令。
|
|
|
38
|
私钥使用口令加密（口令需要经过密钥导出算法的处理）。应用程序加载私钥时需要操作员输入口令，应用程序使用操作员输入的口令对私钥解密；
1、开发一个公私钥密钥对生成工具（Windows 界面程序），用来产生密钥对；
a、密钥对生成工具要求能够输入一个口令用来加密私钥（口令需要经过密钥导出算法的处理）。
2、私钥口令的修改功能和应用程序集成在一起，不能以工具形式单独提供。其中：windows 界面程序的私钥口令修改功能以界面方式提供；无界面的进程的私钥口令修改功能以命令行方式提供，命令名就是进程名，以不同参数选项与运行区别，如：启动进程为：aaa.exe -r，修改私钥口令为：aaa.exe -k oldpwd newpwd；unix 程序同 windows 下的无界面进程。
a、应用程序如果实现了私钥口令的修改功能，那么同时还需要提供修改私钥口令的接口，即外部程序可以通过该接口修改私钥的口令。
|
|
|
最小授权原则
|
39
|
一个帐号只能拥有必需的角色和必需的权限
|
|
|
40
|
一个组只能拥有必需的角色和必需的权限
|
|
|
41
|
一个角色只能拥有必需的权限
|
|
|
42
|
操作系统帐号：
1、对于运行应用系统的操作系统帐号，不应使用“root”、“administrator”、“supervisor”等特权帐号或高级别权限帐号，应该尽可能地使用低级别权限的操作系统帐号
a、根据业务系统要求，创建相应的系统组和帐号
b、如果有部分代码需要很高的权限（如：root 权限），则请将这部分代码分离出来并单独以高权限的系统帐号环境运行
|
|
|
43
|
数据库帐号：
1、对于连接数据库服务器的数据库帐号，不应使用“sa”、“sysman”等管理帐号或高级别权限帐号，应该尽可能地使用低级别权限的数据库帐号
a、根据业务系统要求，创建相应的数据库帐号，并授予必需的数据库权限
|
|
|
44
|
业务系统帐号：
1、应用帐号应与管理帐号相分离；应用帐号不应具有任何的管理功能，也不应具有任何未应授权就能使用的功能；每个应用帐号只应具有能完成与其任务（或身份）相适应的权限
|
|
|
文件权限管理
|
45
|
Unix、Linux 系统：
1、必须给每种类型的文件指定特定的权限，不允许使用系统的缺省权限（如：umask）；
2、需注意在业务系统运行期间新产生的文件的权限，不允许使用系统的缺省权限（如：umask）；
3、不同类型的文件应位于不同的目录内，避免目录权限上的混淆，如程序文件、日志文件、配置文件及相关业务文件应位于不同的目录内；
4、文件的权限需要事先在安装程序中设置好，不需要安装后手工一个一个来改。
a、程序文件（含脚本文件、库文件等）：550（r-xr-x---）
b、程序文件目录： 550（r-xr-x---）
c、配置文件： 640（rw-r-----）
d、配置文件目录： 750（rwxr-x---）
e、日志文件（记录完毕或者已经归档）：440（r--r-----）
f、日志文件（正在记录）： 640（rw-r-----）
g、日志文件目录： 750（rwxr-x---）
h、Debug 文件： 640（rw-r-----）
i、Debug 文件目录： 750（rwxr-x---）
j、业务数据文件： 640（rw-r-----）
k、业务数据文件目录： 750（rwxr-x---）
|
|
|
46
|
Windows 系统：
1、为业务运行创建新的用户和用户组，业务运行的用户仅属于业务运行的用户组；
2、业务安装目录仅给业务运行的用户组和本地 Administraors 组开放完全控制的权限；
3、对于业务安装目录下的文件或者子目录需要对用户组限制权限时通过设置“拒绝”权限完成；
4、业务运行的用户和用户组的创建、以及安装目录权限的设置在业务安装包中完成。
|
|
|
安全日志
|
47
|
应用系统至少需要记录下列事件到日志文件：
1、安全事件（包括成功和失败）：
a、登录；
b、注销；
c、添加、删除、修改用户；
d、给用户授权（给用户分配/取消一个或者多个权限）；
e、鉴权（鉴别用户是否有某项或者某几项权限）；
f、修改用户口令。
2、操作事件（包括成功和失败）：
a、对系统配置参数的修改；
b、对系统进行启动、关闭、重启、暂停、恢复、倒换；
c、对业务的加载、卸载；
d、对重要业务数据（特别是与财务相关的数据，包括：卡号、余额、话单、费率、费用、订单、出货、帐单等）的创建、删除、修改、查询。
3、运行事件：
a、系统处理出错；
b、系统处理失败；
c、系统异常倒换；
d、系统异常退出；
e、进程吊死；
f、关键线程异常退出；
g、关键线程吊死。
4、资源告警事件：
a、内存使用过高；
b、CPU 使用过高；
c、磁盘空间不足；
d、网络拥塞。
|
|
|
帐号可审计要求
|
48
|
用户帐号：
1、应用系统中除超级用户外的其他用户是通过配置维护添加的，同时通过配置维护可以修改、删除，不能是系统固定的；
2、一个操作员需要配置一个用户帐号，不允许多个操作员共享一个用户帐号。
|
|
|
49
|
应用程序帐号：
1、如果应用程序帐号同时是操作系统帐号：
a、在 Unix/Linux 系统下：该帐号不能是 root 用户；需要关闭该用户的远程登录功能，即不允许该帐号进行 Telnet 登录；如果业务不需要 FTP 功能，同时需要取消该用户的 FTP 功能，即不允许该帐号进行 FTP 操作；
b、在 Windows 系统下，该用户不能属于操作系统提供的任何组，只能属于为业务新建的用户组；并且只能分配最小的目录权限。
2、如果应用程序帐号同时是数据库系统帐号：
a、不能是数据库管理员帐号，也不能拥有数据库管理员权限，只能分配最小的操作权限。
3、应用程序使用的帐号必须和操作员使用的帐号分开；
4、应用程序的帐号需要限制可以登录的 IP，即登录服务端时，该帐号只有在指定 IP 的机器上发起请求，服务器端验证时才能通过；
5、当不为操作系统帐号时，不同的应用程序实例需要配置不同的帐号，不允许多个应用程序实例共享一个帐号（例外：同一个操作系统用户启动的同一应用程序的多个实例可以使用同一个帐号和口令）；
6、应用程序的帐号不是操作系统帐号和数据库系统帐号时，口令需要由应用程序随机生成，并符合口令策略。
|
|
|
|
|
|
|
|
|
|
|
|