下载文档原格式
深信服Web安全解决方案深信服科技有限公司20XX年XX月XX日目录第一章需求概述 (5)1.1 项目背景 (5)1.2 网络安全建设现状分析 (5)1.3 Web业务面临的安全风险 (6)第二章Web安全解决方案设计 (9)2.1 方案概述 (9)2.2 方案价值 (10)第三章深信服下一代防火墙NGAF解决方案 (10)3.1 深信服NGAF产品设计理念 (10)3.2 深信服NGAF解决方案 (13)3.2.1 四种部署模式支持 (13)3.2.2 多种拦截方式支持 (14)3.2.3 安全风险评估与策略联动 (15)3.2.4 典型的Web攻击防护 (15)3.2.5 网关型网页防篡改 (24)3.2.6 可定义的敏感信息防泄漏 (27)3.2.7 基于应用的深度入侵防御 (28)3.2.8 高效精确的病毒检测能力 (32)3.2.9 智能的DOS攻击防护 (33)3.2.10 智能的防护模块联动 (34)3.2.11 完整的防火墙功能 (34)3.2.12 其他安全功能 (35)3.2.13 产品容错能力 (39)第四章深信服优势说明 (40)4.1 深信服品牌认可 (40)4.2 深信服下一代应用防火墙NGAF技术积累 (42)4.3 NGAF与传统安全设备的区别 (43)4.4 部分客户案例 (45)第五章典型场景及部署 (46)第六章关于深信服 (46)6.1深信服科技介绍 (46)6.2深信服科技部分荣誉 (47)第一章需求概述1.1项目背景（请根据客户实际情况自行添加）1.2网络安全建设现状分析（请根据客户实际情况自行添加）XX拟建立Web业务对外发布系统，该对外发布系统由多台服务器组成，承载的有OA应用、集团内部门户网站、集团内门户网站群等多个WEB应用。
目前，XX web应用边界使用传统防火墙进行数据包过滤进行安全防护，现运行许多WEB应用系统。
Web业务对外发布数据中心是XX IT建设数据大集中的产物，作为Web业务集中化部署、发布、存储的区域，该对外发布数据中心承载着XX Web业务的核心数据以及机密信息。
1杭州总部电话：+86-0571-********、28860099 传真：+86-0571-********明御®WEB 应用防火墙国内首创全透明部署WEB 应用安全网关全透明直连部署HTTPS 站点全面防护OWASP 十大类Web 攻击防护Web 静态页面加速一、概述：明御®WEB 应用防火墙（简称：WAF ）是安恒信息结合多年应用安全的攻防理论和应急响应实践经验积累的基础上自主研发完成，满足各类法律法规如PCI 、等级保护、企业内部控制规范等要求，以国内首创的全透明直连部署模式，全面支持HTTPS ，在提供WEB 应用实时深度防御的同时实现WEB 应用加速、敏感信息泄露防护及网页防篡改，为Web 应用提供全方位的防护解决方案。
该产品致力于解决应用及业务逻辑层面的安全问题，广泛适用于“金融、运营商、政府、公安、教育、能源、税务、工商、社保、卫生、电子商务”等所有涉及WEB 应用的各个行业。
部署安恒的W AF 产品，可以帮助用户解决目前所面临的各类网站安全问题，如：注入攻击、跨站脚本攻击(钓鱼攻击)、恶意编码(网页木马)、缓冲区溢出、信息泄露、应用层DOS/DDOS 攻击等等。
二、产品的功能● 深度防御明御WEB 应用防火墙基于安恒专利级WEB 入侵异常检测技术，对WEB 应用实施全面、深度防御，能够有效识别、阻止日益盛行的WEB 应用黑客攻击（如SQL 注入、钓鱼攻击、表单绕过、缓冲区溢出、CGI 扫描、目录遍历等）： ✓ SQL 注入 ✓ 命令注入 ✓ Cookie 注入 ✓ 跨站脚本(XSS) ✓ 敏感信息泄露 ✓ 恶意代码✓错误配置✓隐藏字段✓会话劫持✓参数篡改✓缓冲区溢出✓应用层拒绝服务✓其他变形的应用攻击●Web应用加速系统内嵌应用加速模块，通过对各类静态页面及部分脚本的高速缓存，大大提高访问速度。
●敏感信息泄露防护系统内置安全防护策略，可以灵活定义HTTP/HTTPS错误返回的默认页面，避免因为WEB服务异常，导致敏感信息（如：WEB应用安装目录、WEB服务器版本信息等）的泄露。
Web系统技术方案概述Web系统是一种基于Web技术开发的软件系统，可通过互联网访问和使用。
本文将介绍一个完整的Web系统技术方案，包括前端开发、后端开发、数据存储和系统架构等方面。
该方案旨在为开发者提供一种可行且高效的解决方案，以构建稳定和可扩展的Web系统。
前端开发技术选型在前端开发方面，我们建议使用以下技术进行开发：•HTML：用于创建网页的结构和内容。
•CSS：用于定义网页的样式和布局。
•JavaScript：用于实现网页的交互和动态效果。
框架和库为了提高开发效率和代码质量，使用以下常用框架和库：•Vue.js：用于构建用户界面的JavaScript框架。
•React.js：另一种流行的JavaScript框架，用于构建可复用的用户界面组件。
•Bootstrap：用于快速构建美观的响应式网页布局。
开发工具在前端开发过程中，可以使用以下工具提高效率：•编辑器：VS Code、Sublime Text等常用的文本编辑器，提供代码高亮和智能提示功能。
•包管理工具：NPM或Yarn，用于安装和管理前端开发所需的包和依赖项。
•调试工具：浏览器的开发者工具，用于调试JavaScript代码和查看页面元素。
前端交互与设计在前端开发中，交互和设计是至关重要的。
要确保良好的用户体验和界面设计，需遵循以下原则：•响应式设计：确保网页能在不同设备和屏幕尺寸下正常显示和操作。
•用户友好的交互：提供直观且易于使用的界面，减少用户的操作步骤和学习成本。
•良好的可访问性：遵循无障碍设计原则，使得网页可以被各种能力的用户访问。
后端开发技术选型在后端开发方面，我们建议使用以下技术进行开发：•服务器端语言：Node.js、Java、Python等常见的后端开发语言，根据项目需求选择。
•Web框架：Express.js、Spring Boot等用于快速构建Web应用的框架。
•数据库操作：使用适当的数据库操作库或ORM框架，如Mongoose、Hibernate等。
基于web的宾馆管理系统设计技术路线随着信息技术的快速发展，基于Web的宾馆管理系统已成为现代宾馆业务管理的重要工具。
本文将探讨设计这类系统时所需的技术路线，以确保系统能够高效、安全地管理宾馆的各项业务活动。
1. 系统架构与技术选择前端开发：前端是用户与系统交互的界面，需要考虑到用户友好性和响应速度。
通常采用HTML、CSS和JavaScript进行开发，使用流行的前端框架如React.js或Vue.js来提升开发效率和用户体验。
后端开发：后端负责处理前端发来的请求，并进行相应的逻辑处理和数据操作。
常见的后端语言包括Java、Python和Node.js。
选择合适的后端框架如Spring Boot（Java）、Django（Python）或Express（Node.js）能够有效地管理系统的业务逻辑和数据流动。
数据库管理：宾馆管理系统需要处理大量的数据，包括客房信息、预订记录、客户资料等。
选择适当的数据库管理系统(DBMS)至关重要。
常见的选择包括关系型数据库MySQL、PostgreSQL以及NoSQL数据库如MongoDB，根据系统的具体需求进行选择。
安全性与权限控制：宾馆管理系统涉及到用户的个人信息和财务数据，安全性是首要考虑的因素。
采用协议保证数据传输的安全性，实施严格的权限控制和身份验证机制，如OAuth认证，以确保只有授权用户可以访问特定功能和数据。
2. 主要功能模块与实现客房管理模块：包括客房类型管理、客房状态管理、价格策略管理等功能。
前端展示客房信息，后端管理客房的增删改查操作，并与数据库进行交互。
预订管理模块：实现客户在线预订功能，包括预订房间、取消预订、查看预订状态等功能。
前端提供预订界面，后端处理预订请求，更新数据库中的预订信息。
用户管理模块：管理宾馆内部员工和外部客户的信息，包括账号管理、权限设置、个人资料管理等。
实现用户注册、登录、密码找回等功能，保证系统的安全性和可靠性。
目录一、用户需求...................................... 错误!未定义书签。
二、设计依据和设计原则............................ 错误!未定义书签。
2.1 设计依据.................................... 错误!未定义书签。
2.2 设计原则.................................... 错误!未定义书签。
三、系统设计 (2)3.1概述 (2)3.2系统架构 (4)3.2.1系统硬件架构 (4)3.2功能描述 (12)3.2.1信息域功能............................... 错误!未定义书签。
3.2.2控制域功能............................... 错误!未定义书签。
3.2.4系统维护................................. 错误!未定义书签。
3.3主要功能界面举例 (15)3.4系统接口 (20)3.5平台建设 (21)3.6 综合管理功能 (21)四、系统实施 (22)4.1网络环境建设 (22)4.2系统编程 (22)4.3系统试运行和验收 (22)4.4项目任务分解方案 (22)五、测试验收 (23)三、系统设计3.1概述基于上述分析，首先根据系统建设内容和功能要求进行集成管理系统的总体设计。
总体设计的内容主要包括集成管理系统的整体架构、支撑平台（包括网络建设）、功能模块（包括信息域功能模块和控制域功能模块两个方面）、系统接口等几个方面。
如下图所示，中国建设部《2003全国民用建筑工程设计技术措施：电气》第20章<智能化系统集成>有关技术规定的集成管理模式。
本次集成系统将根据标书的要求结合上述标准进行构建。
构建原则如下：(1).网络采用以太网方式(2).用户界面本系统采用B/S（Browser-Server）结构，使客户端的软件配置尽量简单。
3科技资讯科技资讯S I N &T NOLOGY I NFORM TI ON 2008N O .14SCI EN CE &TEC HNO LO GY I N F O RM ATI ONI T 技术随着电子商务的迅速崛起，We b 应用从局部化发展到全球化，从B2C(bus i ne ss -t o-c us t om e r )发展到B2B(busi ne s s-t o-bus i ne s s )，从集中式发展到分布式。
W e b Ser vi c e 作为一种新兴的W e b 应用模式，是一个崭新的对We b 上数据和信息进行集成的分布式计算模型。
从W e b 服务中的支撑技术来看，很多关键问题有待解决，具有广阔的研究空间，但同时也存在很多挑战。
企业的不同应用，可能基于不同的开发平台、开发环境、开发语言以及不同的数据结构，在企业内部需要这些应用相互协作。
另外，企业也可能有前期遗留代码，而现在的开发环境和开发语言又不同于前期的，所有这些都是一个如何有效集成企业应用的问题。
而基于X ML 技术的We b Se r vi c es 能够有效地解决上述问题，可扩展标记语言(XM L)是I nt er ne t 上一种新的数据描述和数据交换标准，XM L 是W e b Se r -v i c e s 的底层核心和架构基础。
各种We b Se r vi c es 能够实现具有一定商务功能的企业应用，W e b Se r vi c es 能够统一地封装信息、行为、数据表现和商务，而不需要考虑应用的开发平台，正是因为W e b Se r vi ce s 技术具有很好的封装性，所以各种基于We b Se r vi c es 的企业应用能够有效地组合和集成从而能够动态地创建电子商务应用。
1W eb Servi ce 简介1.1W e b Ser vi ce 的定义W e b Se r vi c e s 是存在于W e b 服务器上的具有较完整的集安全、认证等基本功能为一体的一组具有服务功能的应用程序，这组程序被封装成一个整体，具有一系列使其具有作为一个服务平台的完整性和优越性的相关的技术标准，对外提供一个能通过W e b 进行调用的AP I 接口，当需要时，可编程调用，其执行结果被回传到客户端。
第二章 系统安全的需求分析 本章从数据安全和业务逻辑安全两个角度对应用系统的安全进行需求分析，主要包括保密性需求、完整性需求、可用性需求三部分；随后对业务逻辑安全需求进行了分析，包括身份认证、访问控制、交易重复提交控制、异步交易处理、交易数据不可否认性、监控与审计等几个方面；最后还分析了系统中一些其它的安全需求。
2.1 数据安全需求 2.1.1 数据保密性需求 数据保密性要求数据只能由授权实体存取和识别，防止非授权泄露。从目前国内应用的安全案例统计数据来看，数据保密性是最易受到攻击的一个方面，通常表现为客户端发生的数据泄密，包括用户的基本信息、账户信息、登录信息等的泄露。在应用系统中，数据保密性需求通常主要体现在以下几个方面： A．客户端与系统交互时输入的各类密码：包括系统登录密码、转账密码、凭证查询密码、凭证交易密码等必须加密传输及存放，这些密码在应用系统中只能以密文的方式存在，其明文形式能且只能由其合法主体能够识别。 以网银系统为例，在网银系统中，通常存有四种密码：系统登录密码、网银转账密码、柜面交易密码及一次性密码。系统登录密码用来认证当前登录者为指定登录名的合法用户，网银用户的登录密码和网银转账密码由用户在柜面开户时指定，用户在首次登录网银系统时，系统必须强制用户修改初始密码，通常要求长度不得少于六位数，且不能是类似于111111、1234567、9876543等的简单数字序列，系统将进行检查。 网银转账密码是指网银系统为巩固用户资金安全，在涉及资金变动的交易中对用户身份进行了再认证，要求用户输入预设的密码，网银交易密码仅针对个人用户使用，企业用户没有网银交易密码。建立多重密码机制，将登录密码与网银转账密码分开管理，有利于加强密码的安全性。由于用户在使用网银时每次都必须先提供登录密码，故登录密码暴露的机会较多，安全性相对较弱；但登录网银的用户并不是每次都会操作账户资金的，所以专门设定网银转账密码可加强账户 的安全性。网银转账密码在网银开户时设定，网银用户在系统中作转账支付、理财、代缴费等资金变动类交易时使用。 柜面交易密码是指用户在银行柜面办理储蓄时，针对储蓄凭证（如卡折、存单等）而设的密码。柜面交易密码常用于POS系统支付时、ATM取款时、凭证柜面取款时，柜面交易密码一个明显的特征是它目前只能是六位的数字，这是由于目前柜面密码输入设备的限制而造成的。柜面交易密码与上述的网银转账密码的区别在于：网银转账密码和系统登录密码都产生于网银系统，储存在网银系统中，仅限网银系统中认证使用；而柜面交易密码产生于银行柜台，可以在外围渠道如ATM、电话银行、自助终端上修改，它保存在银行核心系统中，供外围各个渠道系统共同使用。另外网银转账密码可以有非数字字符组成，而柜面交易密码只能是六位的数字。网银中使用到柜面交易密码的交易包括：网银开户、加挂账户。 一次性密码由用户的智能卡、令牌卡产生，或由动态密码系统产生通过短信方式发送到用户注册的手机上。一次性密码的作用与网银转账密码相同，适用的场合也相同。一次性密码在农商行网银系统中是可选的安全服务，用户需到柜面办理开通手续才能使用，没有开通一次性密码服务的用户必须设定网银交易密码，开通一次性密码服务的用户则无需设定网银交易密码，要求网银系统自动判断并提示用户在某个交易中是要输入网银交易密码还是提示一次性密码。 B．应用系统与其它系统进行数据交换时在特定安全需求下需进行端对端的加解密处理。这里的数据加密主要是为了防止交易数据被银行内部人士截取利用，具体通讯加密方案参照应用系统的特定需求。 2.1.2 数据完整性需求 数据完整性要求防止非授权实体对数据进行非法修改。用户在跟应用系统进行交互时，其输入设备如键盘、鼠标等有可能被木马程序侦听，输入的数据遭到截取修改后被提交到应用系统中，如原本用户准备向A账户转一笔资金在交易数据遭到修改后就被转到B账户中了。同样的威胁还存在于交易数据的传输过程中，如在用户向应用系统提交的网络传输过程中或应用系统跟第三方等其它系统的通讯过程中，另外存储在应用系统数据库中的数据也有可能遭到非法修改，如SQL注入攻击等。 2.1.3 数据可用性需求 数据可用性要求数据对于授权实体是有效、可用的，保证授权实体对数据的合法存取权利。 对数据可用性最典型的攻击就是拒绝式攻击（DoS）和分布式拒绝攻击，两者都是通过大量并发的恶意请求来占用系统资源，致使合法用户无法正常访问目标系统，如SYN Flood攻击等，将会直接导致其他用户无法登录系统。另外，应用登录机器人对用户的密码进行穷举攻击也会严重影响系统的可用性。
2.2 业务逻辑安全需求 业务逻辑安全主要是为了保护应用系统的业务逻辑按照特定的规则和流程被存取及处理。 2.2.1 身份认证需求 身份认证就是确定某个个体身份的过程。系统通过身份认证过程以识别个体的用户身份，确保个体为所宣称的身份。应用系统中身份认证可分为单向身份认证和双向身份认证，单向身份认证是指应用系统对用户进行认证，而双向身份认证则指应用系统和用户进行互相认证，双向身份认证可有效防止“网络钓鱼”等假网站对真正系统的冒充。 应用服务器采用数字证书，向客户端提供身份认证，数字证书要求由权威、独立、公正的第三方机构颁发；系统为客户端提供两种可选身份认证方案，服务器端对客户端进行多重身份认证，要求充分考虑到客户端安全问题。将客户端用户身份认证与账户身份认证分开进行，在用户登录系统时，采用单点用户身份认证，在用户提交更新类、管理类交易请求时，再次对用户的操作进行认证或对用户身份进行二次认证，以确保用户信息安全。 2.2.2 访问控制需求 访问控制规定了主体对客体访问的限制，并在身份识别的基础上，根据身份对提出资源访问的请求加以控制。访问控制是应用系统中的核心安全策略，它的主要任务是保证应用系统资源不被非法访问。主体、客体和主体对客体操作的权限构成访问控制机制的三要素。访问控制策略可以划分为自主访问控制、强制访问控制和基于角色的访问控制三种。 2.2.3 交易重复提交控制需求 交易重复提交就是同一个交易被多次提交给应用系统。查询类的交易被重复提交将会无故占用更多的系统资源，而管理类或金融类的交易被重复提交后，后果则会严重的多，譬如一笔转账交易被提交两次则将导致用户的账户被转出两笔相同额的资金，显然用户只想转出一笔。交易被重复提交可能是无意的，也有可能是故意的： A．用户的误操作。在B/S结构中，从客户端来看，服务器端对客户端的响应总有一定的延迟，这在某些交易处理上体现的更为明显，特别是那些涉及多个系统交互、远程访问、数据库全表扫描、页面数据签名等交易，这种延迟通常都会在5至7秒以上。这时用户有可能在页面已提交的情况下，再次点击了提交按钮，这时将会造成交易被重复提交。 B．被提交的交易数据有可能被拿来作重放攻击。 应用系统必须对管理类和金融类交易提交的次数进行控制，这种控制即要有效的杜绝用户的误操作，还不能影响用户正常情况下对某个交易的多次提交。比如说：当某个用户在10秒内提交了两笔相同的转账业务，则系统必须对此进行控制；另一方面，当用户在第一笔转账业务完成后，再作另一笔数据相同的转账时，则系统不能对此进行误控制。这里判断的依据就是交易重复提交的控制因子a，当交易提交的间隔小于a时，系统认为这是重复提交，提交间隔大于a的则不作处理，控制因子的大小由应用系统业务人员决定，系统应可对其进行配置化管理。 2.2.4 异步交易处理需求 所谓异步交易就是指那些录入与提交不是同时完成的交易，这里的同时是指客户端在录入交易数据与提交交易的过程中，应用系统服务器端并没有对录入的数据进行持久化保存，而异步交易在系统处理过程中，录入与提交时间上发生在两个相分离的阶段，在两阶段之间，应用系统对录入的数据进行了持久化保存。 由于异步交易是被系统分两阶段受理的，这就涉及到以下三个方面的问题： A． 录入与提交的关系管理。 B． 如何保证提交的数据就是用户当初录入的数据。 C． 如何记录交易在两阶段的日志状态。 录入与提交的关系定义不当将会导致交易录入与提交被同时完成而违反了业务处理流程，录入的数据被系统保存后有可能遭到非法篡改，非异步交易执行后的日志状态不会被更新而异步交易在提交后日志状态将会被更新。 应用系统中需要定义成异步的交易通常有以下两类： 需要授权的交易。出于业务管理和业务安全方面的考虑，大部分管理类和金融类的交易都需要经过一定的授权流程后方能被提交。 部分定时交易，如预约转账等。预约一笔在周三转账的预约转账有可能是周一被录入的，用户在录入后，预约转账的数据将被网银系统保存直到周三这笔转账才会真正发生。 应用系统必须定义简单、清晰、易维护的录入与提交关系模型，保证被保存的录入数据不会被非法篡改，同时要求异步交易的日志状态是明确的，不应出现录入与提交相矛盾的日志状态。 2.2.5 交易数据不可否认性需求 交易数据不可否认性是指应用系统的客户不能否认其所签名的数据，客户对交易数据的签名是通过应用系统使用客户的数字证书来完成的。数字证书的应用为交易数据不可否认性提供了技术支持，而电子签名法的颁布为交易数据不可否认性提供了法律基础。 在应用系统中通常要求对所有管理类与金融类的交易进行数字签名，以防客户事后对交易或交易数据的抵赖。应用系统需同时保存客户录入的原始数据和签名后的数据，保存期限依业务部门的具体要求而定。考虑到系统性能和对用户的响应问题，应用系统可只签与交易有关的关键数据，支付类的交易只对付款人账号、付款金额、收款人姓名、收款人账号、收款人开户行五个字段进行数字签名就可以了。 2.2.6 监控与审计需求 安全级别要求高的应用系统应提供对系统进行实时监控的功能，监控的内容包括系统当前登录的用户、用户类型、用户正在访问的交易、用户登录的IP等。对金融类、管理类的交易以及应用系统登录交易需要完整地记录用户的访问过程，记录的关键元素包括：用户登录名、登录IP、交易日期及时间、交易名称、交易相关数据等，对有授权流程的交易要求完整记录授权的经过，授权记录与交
