매우 중요한 안전 규정
Web安全原则
1. 인증 모듈은 무차별 대입 크래킹 메커니즘을 채택해야 합니다.，예 :：인증 코드 또는 계정 또는 IP를 잠그기 위한 여러 번의 연속 로그인 실패。
기술：예를 들어, 로그인 시도가 여러 번 연속적으로 실패한 후 계정 또는 IP가 잠깁니다.，需支持连续登录失败锁定策略的“允许连续失败
的次数”可配置，잠금 시간 만료 후 자동 잠금 해제 지원。
2. 액세스 권한이 필요한 페이지 또는 서블릿에 대한 각 요청에 대해 사용자의 세션 ID가 유효한지 확인해야 합니다.、사용자 권한 부여 여부
3. 이 작업을 수행할 권리，URL 미승인 방지를 위해。
기술：사용자가 URL을 직접 입력하는 것을 방지，URL 울트라 바이어，일부 페이지 또는 서블릿 요청 및 실행；필터를 통해 달성하는 것이 좋습니다.。
4. 로그인 과정에서，사용자 이름과 암호를 서버에 전달할 때，必须采用HTTPS安全协议（也就是带服务器端证书的SSL）。
로컬 액세스만 제공、로그인，장치 관리 시나리오 사용에는 일시적으로 필요하지 않습니다.。
기술：클라이언트와 서버 간에 계정이 전달되는 경우、비밀번호와 같은 민감한 데이터，서버 측 인증서와 함께 SSL을 사용해야 합니다.。由于SSL对
服务端的CPU资源消耗很大，구현하는 동안 서버의 경제성을 고려해야 합니다.。
5. 사용자의 최종 인증 프로세스는 서버에 있어야 합니다.。
6. 사용자가 생성한 데이터는 서버에서 확인해야 합니다.；데이터는 클라이언트에 출력하기 전에 HTML로 인코딩되어야 합니다.，以防止执行恶意
代码、사이트 간 스크립팅。신뢰할 수 없는 데이터의 경우，HTML 인코딩은 클라이언트에 출력하기 전에 수행되어야 합니다.。
7. 주류 웹 보안 스캐닝 도구를 사용하여 웹 서버 및 웹 애플리케이션 스캔，"높은" 수준의 취약점 없음。
8. 비임베디드 제품용 웹 애플리케이션，Statement를 실행하려면 직접 문 대신 PreparedStatement를 사용해야 합니다.，
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. 产品发布前提供产品通信矩阵。描述机器/网元/模块间的通信关系，포함하다：通信使用的端口、규약
、따라서 공유 필요에 따라 설정해야 합니다.、认证方式、端口用途信息等。
3. 产品发布前提供防病毒软件部署指南。描述防病毒软件部署前的准备、流程、执行步骤、失败后
回退处理，以及病毒特征库升级配置指导（Windows系统平台必选）。
4. 产品发布前提供安全配置/加固指南。
描述如下内容：
-安全加固及检查，主要包括操作系统、数据库或WEB服务器等加固内容，需要包含具体的加固内容
和操作步骤（必选）。
-应用的安全配置，针对产品业务安全应用，需要启用哪些安全选项，配置哪些内容。（对于需要通
过对产品开局时进行安全策略配置才能生效的安全功能，需要提供此部分内容）。如果没有应用的
安全配置，命名为安全加固指南。安全加固指南是必须的。
5. 产品发布前提供安全维护手册。从解决方案角度提供业务日常安全维护方面的指导，包括安全补丁
、安全配置、防病毒软件例行检查等，指导维护人员例行进行安全维护。
操作系统安全
无论是使用通用操作系统（Windows、리눅스、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信息中不允许包含口令、银行账号、通信内容等敏感数据。