凭空想象的web功能开发标准(性能,负载,可用性,安全,审计等多侧面)

重要数据的变动记录,及保留历史版本

对重要数据变动,做日志记录,必要的保留历史版本。可选技术方案:将所有历史版本数据存储在k-v表中,允许随时丢失部分或全部

缓存、临时文件及日志

允许这类数据存储在易失性设备上,如内存缓存。允许随时丢失部分或全部,程序不得崩溃(鲁棒性)

自己擦屁股,自动归档旧数据,尤其是存储到数据库中的旧数据,如日志表,临时文件等。至少要有相关文档,指明哪些是此类数据,如何清理,清理是否会带来后遗症(理想 状态是可以任意删除,程序本身健壮工作)

用户行为记录

uv, pv, 类似GA ,或者直接使用第三方服务

单个用户的足迹,按用户、回话划分。登陆用户的记录很自然;非登陆用户,也要有区分方案,可以类似于app中device token的实现原理。负载均衡下要按session划分。

关键步骤的记录。

分别对待:

不产生服务器上数据变更的行为,注意是浏览、搜索等行为,类似HTTP get方法的约定。选特定行为,做记录

产生服务器上数据变更的行为。无条件记录:数据产生人,时间,源IP等必要信息。数据更改及删除,还需要记录原始数据,目标:可快捷低成本的追溯历史。

 

统计类数据

统计类数据,如文章点击量,定期快照(如按月、天、小时),或者记录一定粒度(如小时,天)时间段的统计量

防范资源滥用

高资源消化的操作做qps限制

关键请求上,针对单用户限制授权额度。这里的“用户”是宽泛概念,可以是用户账号,session, ip等多种

信息分级(信息安全层面)

防止重要信息被批量采集,将这些信息分级,对不同用户级别用户展示相应部分。初级用户只能看到极少部分。

严格限制列表页:不得查询未授权的内容,防止越权读取。

信息分级(业务层面)

不同级别的信息,有差异的对待,保证信息准确性,可追溯性等。

从生命周期对信息分类,尤其是对主体信息。这里的“主体信息”,是一个模糊概念,暂时简单的理解为:在数据库里以单独表形式存储的信息,每条信息对应一条记录。划分方式相对个人化、主观化:

  • 长期有效信息:知识,规范手册,等
  • 中长有效期:,
  • 短有效期:,
  • 即时有效期:

按信息对业务重要程度划分,

  • 重要信息
  • 次重要信息
  • 不重要信息
  • ...

 

 

账号密码管理

传统的用户名密码方式,在实际使用过程中,使用人员一定会共享账号,且密码修改非常不及时。(通常是将账号密码放在文件里,如果有工作交接,直接将文件转发,或者直接在QQ里发送账号密码。因为这比“找相关人员新开设账号、设置权限”简单太多了为了。为了不影响别人使用,所以几乎都不会改密码)然而这都是重大的安全隐患。

邮箱作账号,登录后通过邮箱做验证,避免账号共享,强迫通过管理人员赋权限。企业邮箱是第三方服务,一般有较好的密码策略。

用户在同ip段登录只验证一次,若干时间内不需要重复验证。

如果多个用户在某ip段成功验证,其他人员也可以在该ip上通免验证。

超过一定时间不登录的账号,禁止登录,需要重新邮箱激活才可。

超过一定时间不使用的权限,自动撤销。这样,通常就不需要管理员取消授权。

用户管理

对用户按权限分级,如果需要的话(普通用户登录,超级用户)。权限可以查阅、发布来划分;对于管理员,则按增删改查划分。

用户状态,在登录时有相应提示,减少用户登录时提示信息异常造成的困惑,即使对已封禁用户(制定一系列状态,如:临时拒绝登录,禁言,封禁,异常锁定等)

保护用户隐私

关于请求数据

post/get之辨

请求参数格式,url简洁,事先评估是否实现rewrite兼容性

针对移动设备的http接口请求,要实现类似user-agent信息,在请求中传递,可以在http协议头中传递

功能设计原则(底线)

不希望用户操作、不希望用户看到的东西,不要列出来

必要的说明:正确,简明,有效,隐藏

不挑战用户习惯

一致性(提示文案的一致性,同类功能操作方式一致性,UI元素摆放位置一致性,etc)

功能设计原则(价值点)

有转化,可转化

有用的参考资料

  • 信息安全标准目录 http://www.cnblogs.com/merray/p/5315066.html