1. 说明
本篇文章主要说一说应用系统测评时安全审计、入侵防范控制点的相关内容和理解，以及linux系统使用密钥登录的相关内容。
2. 安全审计测评项
a)应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计；
b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息；
c)应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等；
d)应对审计进程进行保护，防止未经授权的中断。
3. 安全审计测评项a
a)应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计；
3.1. 高风险
这个测评项可能存在高风险，如果应用系统没有任何日志审计功能的话：
3.2. 避免高风险
对于应用系统而言，最好的就是存在比较完善的操作日志，什么用户什么时间干了什么，都记录的清清楚楚，那就是绝对的符合。
但是很多应用系统这方面的功能并不全，可能仅存在登录日志，但这也行，至少可以判定为部分符合。
如果被测评项系统找不到什么日志功能，可以考虑去业务流程模块去看看。
很多政府部门的应用系统在业务流程记录这是很详细的，某人什么时候对某业务进行了什么操作，这也能判定为部分符合。
如果这也没有，可以考虑去看看中间件的日志，勉强也能算一个擦边球，至少可以当做是修正的理由。
如果中间件的日志也没有，那就算了吧，还是直接给判定成高风险吧。
4. 安全审计测评项 b
b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息；
没什么好说的，有什么字段就写什么字段，至少应该包括事件、日期、用户、具体操作这四个字段，要不然就是部分符合。
5. 安全审计测评项c
c)应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等；
5.1. 审计记录进行保护
很多情况下应用界面系统中并没有做记录的删除功能，非要删除就得跑去数据库或服务器上删除。
这种情况下，这个要求我觉得是符合的。
如果存在删除功能，比如日志删除的按钮，就要看是这个按钮的权限是如何分配的，是否仅分配给某些账户。
5.2. 定期备份
如果记录存储在数据库中，实际就是看数据库是否定期备份。
如果记录存储在文件中，则看文件是否定期备份。
5.3. 隐藏要求——留存时间
在高风险判定指引中已经进行了明确的说明：
而且这是从2级开始就可以判定成高风险的。
检查方法也很简单，查看最早的记录距离现在是否超过6个月。
如果没有，除非上线日期没有超过6个月，否则没有任何办法进行修正，绝对的高风险。
6. 安全审计测评项d
d)应对审计进程进行保护，防止未经授权的中断。
其实还是一样，很多应用系统并没有审计策略的设置功能，所以这种情况下我觉得是默认符合的。
当然，如果有设置功能的话，也是要看看这个设置功能的权限是如何分配的。
7. 入侵防范测评项
a)应遵循最小安装的原则，仅安装需要的组件和应用程序；
b)应关闭不需要的系统服务、默认共享和高危端口；
c)应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制；
d)应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求；
e)应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞；
f)应能够检测到对重要节点进行入侵的行为，并在发生严重入侵事件时提供报警。
其中的a、b、c、f项，根据测评要求里的说明，对于应用系统而言，都是不适用项
8. 入侵防范测评项d
d)应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求；
8.1. SQL注入
这个只能自己去测试了，比如在登录页面用万能密码去试一试：
https://www.cnblogs.com/pass-A/p/11134988.html
asp aspx万能密码
1："or "a"="a
2：'.).or.('.a.'='.a
3：or 1=1--
4：'or 1=1--
5：a'or' 1=1--
6："or 1=1--
7：'or.'a.'='a
8："or"="a'='a
9：'or''='
或者对三级系统进行渗透的时候一块做了。
理论上你也可以让对方提供你源代码或者系统设计文档，查看是否在技术层面防止SQL注入。
比如使用sql参数化来避免sql注入，类似于以下的C#代码：
sql注入就是利用程序员在编写代码时，为了实现便捷或者灵活的方式，对sql语句进行字符串拼接。
一旦进行拼接，又未对前端传入的字符串未进行检查，就和可能被注入。
而sql参数化可从根本上避免注入，网上的说明如下：
当然，并不是说你用了参数化就肯定能避免注入，如果你在使用参数化的同时仍然进行拼接，比如表名、数据库名，那还是存在漏洞。
或者对方使用waf等安全产品，那么虽然测评项的结果不受到影响，但是可以对相对于的高风险进行修正：
这里说一说云盾，用阿里云的云盾作为例子，它是存在多个版本的，最低等级的免费版其实基本就没有什么功能，并不能用来作为修正的理由。
其他云的云盾也去查询产品文档，看被测评系统使用的那个版本的云盾具体有什么功能。
阿里云云盾的文档如下：
https://help.aliyun.com/knowledge_detail/42306.html?spm=a2c4g.11186623.6.546.267416edzw231C
8.2. 数据类型校验
比如要求输入金额、数字的地方，输入字母等非法数据是否可以提交。
或者输入负数，以及一些类型虽然没错但是明显不符合业务逻辑的数字，看是否可以提交。
具体的测评方法可以参考等保测评2.0：应用身份鉴别（上）第5章的那些方法，同样的，理论上应该是前端和后端都要进行测试才对。
注意：测试的时候一定要经过对方的同意。
9. 入侵防范测评项e
e)应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞；
首先，访谈被测评人员，是否有定期对应用系统进行扫描或渗透测试（对于c/s架构的以渗透为主），或购买了这样的安全服务。
然后，如果对方说有，就让其提交相关的扫描报告、渗透报告。
如果对方提供了，就要对其中的漏洞进行测试，判断是否进行了修补。（可以放在渗透的过程中一起做）
基本上应该可以判定为部分符合或者符合
如果对方并没有定期扫描、渗透，那么这这一项就可以直接判定为不符合。
但是是否判定为高风险：
这个就需要看测评过程中，对应用就行漏洞扫描、渗透测试是，有没有发现高危漏洞。
如果没有，就可以用这个理由去修正，降低风险。
10. linux密钥登录
以前不知道在哪一篇文章说过，这里不具体介绍怎么配置，仅介绍和测评相关的内容。
生成好私钥、公钥后，在sshd_config文件中进行配置：
#是否允许用户自行使用成对的密钥系统进行登入行为，仅针对 version 2。
#至于自制的公钥数据就放置于用户家目录下的 .ssh/authorized_keys 内
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
#有了证书登录了，就禁用密码登录吧，安全要紧
PasswordAuthentication no
当时我没说清楚的地方就是，私钥时怎么和用户名联系起来的，因为使用密钥登录的时候还是需要输入用户名的。
另外一点就是，生成私钥的时候可以设置密码，如果设置了，使用证书登录的时候也需要输入这个密码，这个密码起了什么样的作用。
10.1. 私钥和用户
其实就通过AuthorizedKeysFile这个参数联系起来的，这个参数的值是一个路径，这个路径的根目录即为登录用户的主目录 。
所以如果参数的值是“.ssh/authorized_keys”，就意味着登录的时候会跑去该用户的主目录下的ssh文件夹中寻找authorized_keys（公钥）来进行验证。
所以说理论上一对公钥、私钥可以同时用于多个用户登录，只要每个用户主目录下的ssh文件夹中的authorized_keys都是同一个公钥，那就可以用同一个私钥来登录。
10.2. 私钥的密码
生成私钥的时候设置密码，其实就是给私钥文件进行了加密，所以这个密码就是用于提交私钥的时候解密用的。
举个不大恰当的例子，就类似于某个压缩包设置了加密密码一样。
解密的过程仅发生在客户端：
也没什么数据库或者文件来对比，应该是解密正确后，其格式有一些规律，能够判断解密是否正确。
至于客户端怎么知道用什么样的算法去解密，应该是这样的信息直接记录在私钥文件中：
未加密过的私钥大概是这样的：
你也可以直接在网上找一个转换的网站，输入密码，可以把加密的私钥转换为未加密的私钥。
这样在使用密钥登录的时候就不需要使用密码了。
从这一点也可以证明，客户端也只是在读取私钥后得知其实加密文件从而需要解密，和服务器那边没啥鬼关系。
1. 说明
本篇文章主要说一说应用系统测评时安全审计、入侵防范控制点的相关内容和理解，以及linux系统使用密钥登录的相关内容。
2. 安全审计测评项
a)应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计；
b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息；
c)应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等；
d)应对审计进程进行保护，防止未经授权的中断。
3. 安全审计测评项a
a)应启用安全审计功能，审计覆盖到每个用户，对重要的用户行为和重要安全事件进行审计；
3.1. 高风险
这个测评项可能存在高风险，如果应用系统没有任何日志审计功能的话：
3.2. 避免高风险
对于应用系统而言，最好的就是存在比较完善的操作日志，什么用户什么时间干了什么，都记录的清清楚楚，那就是绝对的符合。
但是很多应用系统这方面的功能并不全，可能仅存在登录日志，但这也行，至少可以判定为部分符合。
如果被测评项系统找不到什么日志功能，可以考虑去业务流程模块去看看。
很多政府部门的应用系统在业务流程记录这是很详细的，某人什么时候对某业务进行了什么操作，这也能判定为部分符合。
如果这也没有，可以考虑去看看中间件的日志，勉强也能算一个擦边球，至少可以当做是修正的理由。
如果中间件的日志也没有，那就算了吧，还是直接给判定成高风险吧。
4. 安全审计测评项 b
b)审计记录应包括事件的日期和时间、用户、事件类型、事件是否成功及其他与审计相关的信息；
没什么好说的，有什么字段就写什么字段，至少应该包括事件、日期、用户、具体操作这四个字段，要不然就是部分符合。
5. 安全审计测评项c
c)应对审计记录进行保护，定期备份，避免受到未预期的删除、修改或覆盖等；
5.1. 审计记录进行保护
很多情况下应用界面系统中并没有做记录的删除功能，非要删除就得跑去数据库或服务器上删除。
这种情况下，这个要求我觉得是符合的。
如果存在删除功能，比如日志删除的按钮，就要看是这个按钮的权限是如何分配的，是否仅分配给某些账户。
5.2. 定期备份
如果记录存储在数据库中，实际就是看数据库是否定期备份。
如果记录存储在文件中，则看文件是否定期备份。
5.3. 隐藏要求——留存时间
在高风险判定指引中已经进行了明确的说明：
而且这是从2级开始就可以判定成高风险的。
检查方法也很简单，查看最早的记录距离现在是否超过6个月。
如果没有，除非上线日期没有超过6个月，否则没有任何办法进行修正，绝对的高风险。
6. 安全审计测评项d
d)应对审计进程进行保护，防止未经授权的中断。
其实还是一样，很多应用系统并没有审计策略的设置功能，所以这种情况下我觉得是默认符合的。
当然，如果有设置功能的话，也是要看看这个设置功能的权限是如何分配的。
7. 入侵防范测评项
a)应遵循最小安装的原则，仅安装需要的组件和应用程序；
b)应关闭不需要的系统服务、默认共享和高危端口；
c)应通过设定终端接入方式或网络地址范围对通过网络进行管理的管理终端进行限制；
d)应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求；
e)应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞；
f)应能够检测到对重要节点进行入侵的行为，并在发生严重入侵事件时提供报警。
其中的a、b、c、f项，根据测评要求里的说明，对于应用系统而言，都是不适用项
8. 入侵防范测评项d
d)应提供数据有效性检验功能，保证通过人机接口输入或通过通信接口输入的内容符合系统设定要求；
8.1. SQL注入
这个只能自己去测试了，比如在登录页面用万能密码去试一试：
https://www.cnblogs.com/pass-A/p/11134988.html
asp aspx万能密码
1："or "a"="a
2：'.).or.('.a.'='.a
3：or 1=1--
4：'or 1=1--
5：a'or' 1=1--
6："or 1=1--
7：'or.'a.'='a
8："or"="a'='a
9：'or''='
或者对三级系统进行渗透的时候一块做了。
理论上你也可以让对方提供你源代码或者系统设计文档，查看是否在技术层面防止SQL注入。
比如使用sql参数化来避免sql注入，类似于以下的C#代码：
sql注入就是利用程序员在编写代码时，为了实现便捷或者灵活的方式，对sql语句进行字符串拼接。
一旦进行拼接，又未对前端传入的字符串未进行检查，就和可能被注入。
而sql参数化可从根本上避免注入，网上的说明如下：
当然，并不是说你用了参数化就肯定能避免注入，如果你在使用参数化的同时仍然进行拼接，比如表名、数据库名，那还是存在漏洞。
或者对方使用waf等安全产品，那么虽然测评项的结果不受到影响，但是可以对相对于的高风险进行修正：
这里说一说云盾，用阿里云的云盾作为例子，它是存在多个版本的，最低等级的免费版其实基本就没有什么功能，并不能用来作为修正的理由。
其他云的云盾也去查询产品文档，看被测评系统使用的那个版本的云盾具体有什么功能。
阿里云云盾的文档如下：
https://help.aliyun.com/knowledge_detail/42306.html?spm=a2c4g.11186623.6.546.267416edzw231C
8.2. 数据类型校验
比如要求输入金额、数字的地方，输入字母等非法数据是否可以提交。
或者输入负数，以及一些类型虽然没错但是明显不符合业务逻辑的数字，看是否可以提交。
具体的测评方法可以参考等保测评2.0：应用身份鉴别（上）第5章的那些方法，同样的，理论上应该是前端和后端都要进行测试才对。
注意：测试的时候一定要经过对方的同意。
9. 入侵防范测评项e
e)应能发现可能存在的已知漏洞，并在经过充分测试评估后，及时修补漏洞；
首先，访谈被测评人员，是否有定期对应用系统进行扫描或渗透测试（对于c/s架构的以渗透为主），或购买了这样的安全服务。
然后，如果对方说有，就让其提交相关的扫描报告、渗透报告。
如果对方提供了，就要对其中的漏洞进行测试，判断是否进行了修补。（可以放在渗透的过程中一起做）
基本上应该可以判定为部分符合或者符合
如果对方并没有定期扫描、渗透，那么这这一项就可以直接判定为不符合。
但是是否判定为高风险：
这个就需要看测评过程中，对应用就行漏洞扫描、渗透测试是，有没有发现高危漏洞。
如果没有，就可以用这个理由去修正，降低风险。
10. linux密钥登录
以前不知道在哪一篇文章说过，这里不具体介绍怎么配置，仅介绍和测评相关的内容。
生成好私钥、公钥后，在sshd_config文件中进行配置：
#是否允许用户自行使用成对的密钥系统进行登入行为，仅针对 version 2。
#至于自制的公钥数据就放置于用户家目录下的 .ssh/authorized_keys 内
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
#有了证书登录了，就禁用密码登录吧，安全要紧
PasswordAuthentication no
当时我没说清楚的地方就是，私钥时怎么和用户名联系起来的，因为使用密钥登录的时候还是需要输入用户名的。
另外一点就是，生成私钥的时候可以设置密码，如果设置了，使用证书登录的时候也需要输入这个密码，这个密码起了什么样的作用。
10.1. 私钥和用户
其实就通过AuthorizedKeysFile这个参数联系起来的，这个参数的值是一个路径，这个路径的根目录即为登录用户的主目录 。
所以如果参数的值是“.ssh/authorized_keys”，就意味着登录的时候会跑去该用户的主目录下的ssh文件夹中寻找authorized_keys（公钥）来进行验证。
所以说理论上一对公钥、私钥可以同时用于多个用户登录，只要每个用户主目录下的ssh文件夹中的authorized_keys都是同一个公钥，那就可以用同一个私钥来登录。
10.2. 私钥的密码
生成私钥的时候设置密码，其实就是给私钥文件进行了加密，所以这个密码就是用于提交私钥的时候解密用的。
举个不大恰当的例子，就类似于某个压缩包设置了加密密码一样。
解密的过程仅发生在客户端：
也没什么数据库或者文件来对比，应该是解密正确后，其格式有一些规律，能够判断解密是否正确。
至于客户端怎么知道用什么样的算法去解密，应该是这样的信息直接记录在私钥文件中：
未加密过的私钥大概是这样的：
你也可以直接在网上找一个转换的网站，输入密码，可以把加密的私钥转换为未加密的私钥。
这样在使用密钥登录的时候就不需要使用密码了。
从这一点也可以证明，客户端也只是在读取私钥后得知其实加密文件从而需要解密，和服务器那边没啥鬼关系。
