非常に重要な安全規制
Web安全原则
1. 认证模块必须采用防暴力破解机制，例えば：验证码或者多次连续尝试登录失败后锁定帐号或IP。
说明：如采用多次连续尝试登录失败后锁定帐号或IP的方式，需支持连续登录失败锁定策略的“允许连续失败
的次数”可配置，支持在锁定时间超时后自动解锁。
2. 对于每一个需要授权访问的页面或servlet的请求都必须核实用户的会话标识是否合法、用户是否被授
3. 权执行这个操作，以防止URL越权。
说明：防止用户通过直接输入URL，进行URL越权，请求并执行一些页面或servlet；建议通过过滤器实现。
4. 登录过程中，往服务器端传递用户名和口令时，必须采用HTTPS安全协议（也就是带服务器端证书的SSL）。
只提供本机接入、登录，做设备管理使用的场景暂时不要求。
说明：如果在客户端和服务器间传递如帐号、口令等敏感数据，必须使用带服务器端证书的SSL。由于SSL对
服务端的CPU资源消耗很大，实施时必须考虑服务器的承受能力。
5. 对用户的最终认证处理过程必须放到服务器进行。
6. 用户产生的数据必须在服务端进行校验；数据在输出到客户端前必须先进行HTML编码，以防止执行恶意
代码、跨站脚本攻击。对于不可信的数据，输出到客户端前必须先进行 HTML 编码。
7. 使用主流Web安全扫描工具扫描Web服务器和Web应用，不存在“高”级别的漏洞。
8. 非嵌入式产品的Web应用，应使用预编译语句PreparedStatement代替直接的语句执行Statement，
以防止SQL注入。
数据库安全
外购数据库、开源数据库、自研数据库都应进行安全配置，保证不出现安全漏洞。
1. 数据库口令禁止使用数据库厂商的缺省口令，且口令复杂度需满足“口令安全要求”。
数据库若存在多个默认帐号，须将不使用的帐号禁用或删除。
2. 使用单独的操作系统帐号来运行数据库；数据库中的敏感文件（如：オラクル数据库的init.ora、
listener.ora等）需要严格控制访问权限，只能被数据库进程运行帐户和DBA帐户读写；对数据库
帐户授予的权限进行严格清晰的划分，所有数据库帐户只能具备执行其任务的最小权限；对于有
监听器功能的数据库（如Oracle的listener.ora）需要设置监听器密码或者设置为本地操作系统验证。
3. 使用主流或指定的系统扫描软件进行安全扫描，不存在“高”级别的漏洞。
敏感数据保护
系统对敏感数据的存储、传输和处理需保证数据安全，并遵从适用国家和地区的法律和法规要求。
敏感数据定义：包括但不限于口令、银行账号、个人数据（单独使用该数据或者结合其他信息可以识别
某个活着的自然人的数据，含む：最终用户姓名、帐号、主叫和被叫号码、通信记录、话单、通信时间
、定位数据等）。
1. 口令不允许明文存储在系统中，应该加密保护。在不需要还原口令的场景，必须使用不可逆算法加密。
对银行账号等敏感数据的访问要有认证、授权和加密机制。口令文件必须设置访问权限控制，普通用户
不能读取或拷贝加密的内容。如果帐户文件/数据中含有口令又必须所有用户可访问，则需将帐户文件/
数据与口令文件/数据分开。
注：对于业界第三方主流软硬件（如操作系统、データベース、Web容器）自身提供的口令功能，不受本条限制。
2. 在非信任网络之间进行敏感数据（包括口令，银行帐号，批量个人数据等）的传输须采用安全传输通道
或者加密后传输，有标准协议规定除外。
3. 禁止使用私有加密算法。
说明：
1) 对称加密算法建议使用：AES192及以上强度；
2) 密钥交换算法建议使用：DH1024；
3) 数字签名算法建议使用：DSA1024、ECDSA192；
4) 非对称算法建议使用：RSA2048、ECC192；
5) HASH（哈希）算法建议使用：SHA256及以上强度；
6) HMAC（基于哈希的消息验证码）算法建议使用：HMAC-SHA256；
4. 用于敏感数据传输加密的密钥，不能硬编码在代码中。
在敏感数据的安全传输上，优先使用业界的标准安全协议（如SSH v2/TLS1.0/SSL3.0/IPSec/SFTP/
HTTPS等），并确保密钥可配置；如果是由产品自身实现安全传输过程，则优先使用Diffie-Hellman
密钥交换算法，如果使用预置共享密钥等其他方法，也必须保证该密钥可配置和可替换。
5. 禁止在日志、话单等文件中记录口令、银行账号、通信内容等敏感数据；
6. 尽量避免在日志、话单中记录个人数据，如果必须记录个人数据，则所有数据必须进行结构化存储
或适合于进行匿名化提取；
1）尽量避免在日志中记录个人数据，如果必须记录，在个人数据之前或之后加统一的标记，以区别于
其他非个人数据。
2）尽量避免在话单中记录个人数据，如果必须记录，则话单必须进行结构化存储，字段间必须由统一
的分隔符分开，每行的字段按列严格对应。
7. 有个人数据导出功能的产品发布时必须同时提供对个人数据进行过滤或匿名化处理和功能或工具；
8. 严格限制导出功能的权限，对导出功能的使用必须有日志记录。
9. 涉及个人数据的采集/处理的功能须提供安全保护机制（如认证、权限控制、日志记录等），并通过
产品资料向客户公开。
10. 在正常业务流程和标准协议之外，禁止出于故障定位目的进行用户精确位置信息定位。
口令安全策略管理
1. 设置口令时，默认检测口令复杂度，口令至少满足如下要求：
1) 口令长度至少6个字符（特权用户至少8个字符）；
2) 口令必须包含如下至少两种字符的组合:
－至少一个小写字母；
－至少一个大写字母；
－至少一个数字；
－至少一个特殊字符：`~!@#$%^&*()-_=+\|[{}];:’”,<.>/? 和空格
3) 口令不能和帐号或者帐号的逆序相同；
若设置的口令不符合上述规则，必须进行警告。
2. 系统必须提供锁定用户的机制。可选择如下两种方式之一：
方式一：当重复输入错误口令次数（默认3次，次数系统可以设置）超过系统限制时，系统要锁定该
ユーザー。
方式二：系统还可以设置下次允许输入口令的间隔时间加倍，采用这种方式时，用户可以不设置自动
锁定。
3. 可设置自动解锁时间（只适用于由于口令尝试被锁定的用户）
1) 对于口令尝试N次失败被锁定的用户，系统要能够设置自动解锁时间，建议默认解锁时间为5分钟。
2) 用户被锁时间达到预定义时间，可自动解锁该用户，或者也可通过安全管理员手工解锁该用户。
3) 在锁定时间内，仅能允许应用安全管理员角色所属帐号手动解锁该用户。
4. 操作界面中的口令不能明文显示，键入口令时不能明文显示出来(操作界面中的输入口令可不显示
或用*代替)，包括在终端上打印或存储在日志中时也不能明文显示口令，即使是内存中的明文口令
（如登录期间），也应在使用后立即覆盖。
5. 口令输入框不支持拷贝功能。
6. 对于系统内置帐号的缺省口令，口令应符合复杂度的要求，并在客户资料中提醒用户修改。
7. 用户可修改自己的口令，需满足如下要求：
1) 用户修改自己口令时必须验证旧口令；
2) 不允许修改除自身帐号以外的帐号的口令（管理员除外）
8. 口令不能在网络中明文传输，口令等认证凭证在传输过程中必须加密，使用高安全等级的加密算法。
说明：
1) 对称加密算法建议使用：AES192及以上强度；
2) 密钥交换算法建议使用：DH1024；
3) 数字签名算法建议使用：DSA1024、ECDSA192；
4) 非对称算法建议使用：RSA2048、ECC192；
5) HASH（哈希）算法建议使用：SHA256及以上强度；
6) HMAC（基于哈希的消息验证码）算法建议使用：HMAC-SHA256；
9. 口令在本地存储时必须加密，需满足如下要求：
1) 口令不能够明文写入日志文件、配置文件以及cookie中；
2) 口令文件必须设置访问控制，普通用户不能读取或拷贝加密的内容。
10. 产品配套资料提供清晰的帐号、口令清单。
安全资料
针对售前、开局、现网运维几个阶段，提供配套安全方案、资料。
- 在产品描述中对产品安全特性进行描述。
2. 产品发布前提供产品通信矩阵。描述机器/网元/模块间的通信关系，含む：通信使用的端口、プロトコル
、IPアドレス、认证方式、端口用途信息等。
3. 产品发布前提供防病毒软件部署指南。描述防病毒软件部署前的准备、流程、执行步骤、失败后
回退处理，以及病毒特征库升级配置指导（Windows系统平台必选）。
4. 产品发布前提供安全配置/加固指南。
描述如下内容：
-安全加固及检查，主要包括操作系统、数据库或WEB服务器等加固内容，需要包含具体的加固内容
和操作步骤（必选）。
-应用的安全配置，针对产品业务安全应用，需要启用哪些安全选项，配置哪些内容。（对于需要通
过对产品开局时进行安全策略配置才能生效的安全功能，需要提供此部分内容）。如果没有应用的
安全配置，命名为安全加固指南。安全加固指南是必须的。
5. 产品发布前提供安全维护手册。从解决方案角度提供业务日常安全维护方面的指导，包括安全补丁
、安全配置、防病毒软件例行检查等，指导维护人员例行进行安全维护。
操作系统安全
无论是使用通用操作系统（Windows、Linux、Unix等）还是嵌入式操作系统（如VxWorks、pSOS等)，
系统都应该保证软件及软件运行环境的安全。
注：系统指交付给客户运行的整体系统，包括自研的软件、软件运行的操作系统及应用服务在内。
- 使用主流漏洞扫描软件进行安全扫描，不存在高风险级别的漏洞。
- 基于通用操作系统的新发货产品“操作系统加固+操作系统补丁”预装率=100%；对于不在生产
- 环节预安装的产品，需要在正式发布的版本中包含默认的安全策略文件，并在产品资料中说明加
- 固要求和操作步骤。
说明：
(1) オペレーティング・システム，产品版本应基于最新的操作系统安全补丁进行开发和兼容性测试。
(2) 使用Windows操作系统的产品，产品需要使用主流防病毒软件进行进行兼容性测试。
说明：
协议与接口防攻击
系统应具备基本的防攻击能力，对影响自身的常见攻击具备防御能力等。注：系统指交付给客户运行
的整体系统，包括自研的软件、软件运行的操作系统及应用服务在内。
1. 系统所有的对外通信连接必须是系统运行和维护必需的，对使用到的通信端口在产品通信矩阵文档
中说明，动态侦听端口必须限定确定的合理的范围。通过端口扫描工具验证，未在通信矩阵中列出的
端口必须关闭。
说明:
尽量避免使用动态侦定端口的实现方式，在没有替代方案的情况下，如果必须使用，需满足如下要求：
1)、如果使用业界标准的协议（如RPC、FTP被动模式），并有一定的安全措施（如NFS安全配置、
防火墙支持FTP被动模式等）；
2)、如果自实现的方式，则动态侦听端口必须限定确定的合理的范围。
2. 所有能对系统进行管理的通信端口及协议必须有接入认证机制，标准协议没有认证机制的除外。
3. 对自研协议和业界非主流软件（包括非主流的开源软件）实现的协议要进行协议畸形报文攻击测试。
4. 设备外部可见的能对系统进行管理的物理接口必须有接入认证机制。
监听接口及防止非法监听
产品开发合法监听接口应遵循国际标准及所在国的法律要求。
在没有公司明确需求的情况下，严禁开发具有监听性质的功能和接口，无论该功能和接口是否要遵循
相应的国家标准和国际标准。
在公司对合法监听接口有需求的情况下，需根据公司提供的监听功能或接口的文件中的要求开发。
说明：对提供合法监听接口的产品版本的要求（二选一）
1）产品提供两个版本的软件安装包：一个支持合法监听，一个不支持合法监听。根据市场的安全
請求，选择对应的软件安装包进行部署。
2）产品提供软件安装包拆分为：基本软件安装包和合法监听插件安装包。根据市场的安全要求，
选择是否安装合法监听插件安装包。
3. 在正常业务流程和标准协议之外，禁止提供采集最终用户原始通信内容（语音类、短信/彩信类、
传真类、数据业务类）的功能，即使出于保障网络运营和服务目的。
注：
1) 除了语音类、短信/彩信类、传真类、数据业务类信息属于通信内容外，最终用户的即时消息
、E-Mail信息、URL同样属于通信内容；
2) 允许使用debug功能，但debug信息中不允许包含口令、银行账号、通信内容等敏感数据。