应用系统安全访问策略

应用系统安全访问策略

模型：

可参考这个链接：什么是安全架构 - 下 (qq.com)

更直观的模型：

哪个用户 - 在哪个时间 - 在哪个地点 - 在哪个设备上 - 通过哪个APP -  允许/拒绝访问或执行 - 应用/操作/身份验证上下文

标黄的可以并行进行，AND OR都可以

名词定义：

用户：

主要是指人员，合作伙伴，访客，同一类人员（组/角色），还有系统：应用程序或其他系统接口

身份认证：

口令：就是账号和密码，

生物识别：指纹、声纹、虹膜、面部识别等

设备：各类移动端，是否加域，是否安装了客户端管理软件，通过设备机器码（MAC，CPU/硬盘的hash）

后台身份认证：(本文后续使用不到)

Ticket：基于用户Ticket的后台身份认证，就是在访问资源的过程中，应用系统基于用户身份进行认证

AppKey：使用AppID和AppKey进行系统间的认证，仅适合对 安全性要求一般的场景

双因素认证：就是在原来口令基础上添加额外的安全机制

短信：顾名思义，通过手机短信来认证，通常是结合账号密码来实现双因素认证，这是比较传统的双因素认证方式

TOTP：Time-based One-Time Password，就是动态口令

扫码认证：本质上是一种信任传递机制，将手机APP上的身份传递到该应用上，并且较好的解决了安全与效率的问题

资产：通过是指访问应用系统服务，但也包含如下两类

数据：信息资产，包括结构化数据、非结构化数据，不仅包括存储的数据，也包括使用、传输、流转中的数据

资源：网络资源、计算资源、存储资源、进程、产品功能、网络服务、系统文件等

应用场景：

注意：除了上文介绍的身份认证方式，通过还可以结合网络位置、时间段来组合实现应用系统访问策略。

单一访问：

仅允许指定用户访问资产

仅允许指定设备访问资产

仅允许指定网络访问资产

仅允许指定时间段访问资产

多条件访问（没有添加时间因素，请自行脑补）：

列举常用几种，上文中单一访问的方式、双因素认证的三种类型都可以多对多的组合在一起实现更安全的身份认证：

1、仅允许在指定设备、指定用户访问资产  -- 比如只允许员工使用公司的计算机，可在任意网络访问应用系统

2、允许指定用户在任意情况下访问资产  -- 比如员工可以使用任何设备任何网络访问应用系统

3、仅允许在指定网络、指定用户访问资产  -- 比如只允许员工在公司网络访问应用系统

4、仅允许在指定网络、指定设备访问资产  -- 比如只允许员工使用公司的计算机在公司网络访问应用系统

5、仅允许指定用户、指定网络、指定设备访问资产  -- 比如只允许员工在公司网络，公司计算机上访问应用系统  或者是配置为 如果用户在不受信任的网络，仅允许指定设备访问应用系统

注意：这些条件可以是包含，也可以是排除。

技术实现方式：

口令：

账号通常有如下三种：

生物识别：

需要第三方采集设备支持，指纹、声纹、虹膜、面部识别等

设备：

各类移动端，参考如下链接

是否加域，是否安装了客户端管理软件，通过设备机器码（MAC，CPU/硬盘的hash）

在使用该设备访问系统时，检查是否满足预留条件，或者通过第三方数据检查，

短信：

移动短信，现在一般是调用第三方短信平台服务，技术上是通过API或者HTTP方式调用，但在中国，需要实名认证来完成短信服务（短信签名和短信模板）的开通，建议直接使用几家公有云的短信服务，不要使用运营商或者其他小众短信服务平台。

而在一些工控领域，还存在很多老式的短信模块，通过自行购买手机卡，插入到短信模块，然后应用系统（不支持调用短信平台服务）调用短信模块来实现收发短信

TOTP：

Time-based One-Time Password，就是动态口令

以前是以硬件为主，现在有了很多APP版本的动态口令卡服务。

扫码认证：

网络位置：

最终体现出现的效果是针对公网IP地址的ACL 策略，比如通过服务器防火墙、公有云虚拟机的安全组、边缘防火墙来实现允许/拒绝某些IP的访问

时间段：

通常是结合网络ACL来实现访问控制，

服务器的防火墙和公有云虚拟机的安全组无法实现基于时间的ACL，需要基于状态的防火墙才方便实现，比如公有云的云防火墙、硬件防火强等。

后续展望：

如果本地技术能力或者硬件条件不足，完全可以考虑公有云提供的身份服务，目前阿里云提供了满足本文中所有的需求（设备认证好象不支持），

而腾讯云、华为云还在内测中。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。