11、等保2.0 新员工网络培训考核

Fri, 15 Nov 2024 09:44:26 +0800

1. 系统环境

本次被测评样品系统环境由核心交换机、防火墙、堡垒机、日志审计系统、漏洞扫描、服务器和数据库。

1.1 网络层结构

模拟系统网络拓扑结构如图1所示：

2. 测评对象范围（配置检查）

2.1 网络安全设备

序号	设备名称	型号	用途
1	防火墙	山石网科	对网络区域边界进行访问控制。
2	堡垒机	绿盟	对服务器区的1台CentOS服务器的远程运维进行安全管理和审计。
3	日志审计系统	绿盟	对安全管理区和服务器区内的所有设备进行漏洞扫描。
4	IPS	绿盟	对网络区域边界进行入侵防护。
5	核心交换机	华为	数据交换。

1.2 主机操作系统

序号	设备名称	操作系统
1	CentOS 服务器1	CentOS 7

1.3 MySQL数据库

序号	设备名称	操作系统
1	MySQL数据库	MySQL

3 . 安全策略

整体网络划分为互联网接入区、安全管理区、服务器区、核心交换区、办公接入区。相关安全策略如下：

1）相关设备日志均备份至日志审计系统；

2）每季度进行漏洞扫描范围应能覆盖安全管理区和服务器区内的所有设备。

3）互联网带宽为100M，目前带宽能够满足业务需求；

4）设备、边界等未基于可信根对通信设备、边界设备及计算环境系统引导程序、系统程序、重要配置参数和通信应用程序等进行可信验证；

5）单位目前未使用无线网络和邮件系统；

6）目前操作系统中仅mssql、secadm、audadm、root用户在使用；

7）数据库及操作系统变更前后进行了备份，数据保存在本地，未进行异地备份；

8）应用服务器采用HA方式部署；

4 . 设备配置相关资料

01、网络安全设备配置配置截图.docx

02、服务器及数据库等相关内容需登录堡垒机进行查看，堡垒机：https://172.18.19.253/

21、等保测评2.0_应用访问控制理解解

Fri, 15 Nov 2024 09:44:26 +0800

1. 说明

本篇文章主要说一说应用测评中访问控制控制点的相关内容和理解。

2. 测评项

a)应对登录的用户分配账户和权限；

b)应重命名或删除默认账户，修改默认账户的默认口令；

c)应及时删除或停用多余的、过期的账户，避免共享账户的存在；

d)应授予管理用户所需的最小权限，实现管理用户的权限分离；

e)应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则；

f)访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级；

g)应对重要主体和客体设置安全标记，并控制主体对有安全标记信息资源的访问。

3. 测评项a

a)应对登录的用户分配账户和权限；

3.1. 要求1

如果从字面意思来看，就是一个废话用户都登录账户了，自然就存在着账户。
这里的意思是应该是你本来就存在“多个账户”，然后当用户使用时要适当的“分配账户”给用户，而账户再拥有不一样的权限，这样就实现了将权限通过账户分配给用户（自然人）。
所以该测评项就需要应用系统中存在至少两个账户且这两个账户的权限不一样

嗯……实际测评中我还真遇到过基本缺乏访问控制功能的，倒不是完全缺乏访问控制（鉴别）功能，在不登录的情况下，可直接访问后台地址。

而是只有一个账户或者数个账户，但是登录后没有权限分配机制，没有在代码中做这个功能……

4. 测评项b

b)应重命名或删除默认账户，修改默认账户的默认口令；

其实就是看一看有没有存在admin、system等常见的默认账户用户名，如果存在，不管它到底是不是实际的默认用户，都算是不完全符合要求。
另外有些应用系统的默认账户虽然不使用admin、system等常见的默认账户用户名，但是它这个软件都是用的这个默认用户名，这样的话也得改。

5. 测评项c

c)应及时删除或停用多余的、过期的账户，避免共享账户的存在；

主要针对管理员账户、后台账户进行判定，一般都是符合的。

6. 测评项d

d)应授予管理用户所需的最小权限，实现管理用户的权限分离；

如果业务比较多，比如医院的系统、财务系统或者其他系统，权限本来就会分得比较细，甚至非常细。
这种情况下，给个符合是没有多大问题的。

如果业务规模比较小，可能权限分配的粒度就非常粗了。
我就遇到过，某个应用系统就两个角色，一类是普通用户，一类是后台用户这种只能往部分符合、不符合的方向去判定了。

7. 测评项e

e)应由授权主体配置访问控制策略，访问控制策略规定主体对客体的访问规则；

没什么好说的，一般都是超级管理员或者系统管理员具备这方面的权限，基本上是可以判定为符合的。

8. 测评项f

f)访问控制的粒度应达到主体为用户级或进程级，客体为文件、数据库表级；

8.1. 访问控制的粒度为用户级

这里其实细究的话，从某个角度上来说，有一部分应用系统是不完全符合的。
基本上应用系统的权限分配方式都是角色拥有权限，用户再属于某个角色，这样用户也就获得了权限。

但是如果要达到访问控制的粒度为用户级，应该还要有一个功能，就是也能直接把某个具体的权限赋予给某个具体的用户。
这样，粒度就确切的达到了用户级。

否则，你想调整权限，实际就得调整角色的权限，角色下面有多个用户，你就相当于调整了某一类用户的权限。
除非你为了实现细粒度的控制，某些角色下面只有一个用户……

当然，实际测评中根据具体情况进行结果判定，没有必要这么深究。

8.2. 访问控制的粒度达到表级

这里并不是让你跑去数据库中进行查看，直接在应用系统中判断就好。
应用系统中一个表单页面可以大概的类比于数据库中的一个表，比如个人信息表、业务表等。
（当然，可能某些表单页面是由多个表复合而成的，这个就不管它了。）

所以这个就是要看权限分配的时候，是否能直接对表单页面的权限进行分配，比如允许访问什么的。
表单页面的权限一般就是功能栏、菜单栏的权限分配，大部分应用系统都可以做到。
甚至有些做得更细致，比如细致到某个表单的按钮的权限上。

8.3. 访问控制的表现

在应用系统中，限制了用户的某些权限，比如查看某个表单的权限，一般有两种方式。

一种是表单的栏目直接不显示：
在C/S架构中，这样基本上就没有问题了，除非它的那个表单实质上是另外一个窗口，存在exe，而exe里没有对用户的权限进行判定。
在B/S架构中，这样基本上也没问题了，但是最好还是试验下，比如你先登录有相关权限的账户，将表单的地址记下来，然后再登录没有权限的账户，直接通过地址去访问表单，看是否能够成功。有些B/S的表单可能是用ajax方式显示的，这样的话，你需要找到接口，登录后使用jquery的get方法或者post方法去访问相关接口。

如果要搞清楚，其实需要对应用系统做渗透

另外一种就是没有权限的按钮或菜单等照样显示，但是你点不进去，菜单或者按钮处于禁用状态。
对于B/S架构的，其实还是要按照上面的方式试一试它的后台有没有同样做了权限控制，还是只是在前端进行了限制。

业务应用系统 on ClearSec Wiki