安全学习笔记之安全基础（一）

0x00 前言

作为一名在安全和运维岗位都有过从业经验的人来说，我一直觉得运维和安全是密不可分的，运维和安全团队的特点就是时常要面对非常棘手的事故，一没处理好造成公司的损失那年终奖就鸡飞蛋打了，并且这两个岗位都是属于平时没出事就一切安好，一出事就是背锅的角色，在没出事时别人觉得养着你有何用，出了事后别人觉得要你有何用。。。所以我觉得对运维和安全来说，有防范于未然和主动响应的意识真的很重要。

现在回想起在上家公司的时候，公司是一家 to B的安全乙方厂商，我当时是在做安全实施的工作，经常需要到客户那里拿安全产品进行巡检和部署安全产品等等，我就发现安全真是马太效应，大公司都有一定规模的专业安全团队，并且像一些 WAF、IDS/IPS 等基础的安全产品很完备，甚至还有专门的安全研发团队，src和安全运营，他们可能暂时缺少的是一些比较上层建筑的安全产品，比如 RASP 之类的微服务应用防护，DevSecOps 安全开发的产品等等，而中小公司则基本就是字典里没有 “安全” 这两个字，可能好点的会有一人安全，就只有一个安全工程师，这个人要负责的事也挺杂挺重的，什么等保合规啦，渗透测试，基线检查，内部安全准则文档编写，安全开发培训等等，更有一些公司则是安全的活全由运维哥来兼职，所以我现在小公司的什么 app 产品我都不太敢用，指不定哪天就被脱裤了。。

当然，小公司不在业务上投入太多的资源也是可以理解的，毕竟安全是末位需求，小公司资源有限，但是我认为随着等保2.0的正式实施，几乎所有的企业都要参加等保，国家也越来越重视安全，安全问题不是那么好规避了，所以需要运维和开发等技术人员有基本的安全的意识。由于我现在的公司之前也出过安全事故，所以我面试也会注重求职者的安全知识，但从我之前面试过的运维求职者来看，基本上一点都不懂安全。目前来说，在小公司运维要兼职做安全，在大公司则运维团队需要更好的和安全团队协作来应急响应线上问题进行处理，所以我觉得不管是在大公司和小公司，运维都要学习一定的安全知识，做好运维安全，另外现在云计算基本都是标配了，在云上又会面临新的安全问题，可以说运维安全的门槛是越来越高了。

虽然我也之前在乙方安全厂商待过一段时间，安全技术书也看了不少，但之前是走的野路子，且我现在觉得从运维的角度来看安全和在乙方差异还是蛮大的，这也是我为什么重拾安全，系统的学习一波安全，把学到的安全知识和自己的实际经历记录成学习笔记。

0x01 安全基础

0x010 本质是数据

谈安全自然是要有要保护安全的对象，比如银行要保证钱的安全，钱就是被保护的对象，所以银行的金库需要安保措施。同样，对于互联网公司来说，什么是要被保护的？那就是业务，业务最终产生的是什么？业务最终产生的则是用户数据，比如互金行业，他的数据就是借贷人的数据，如果这些数据被丢失了或者损坏了，那后果有多严重可想而知。所以，对于数据这个 objective(客体) 的保护就是我们的安全。
数据的保护主要有 CIA 3 个原则：

• 机密性(Confidentiality):- 确保只有该看的人才能看见，如我们不会允许陌生人查看我们的隐私，我觉得把数据比喻成文件的话，这就是数据的读权限- 针对机密性则产生了各种加密，混淆等技术
• 完整性(Integrity):- 保证数据不能随便被篡改，比如我们不可能让别人把我们的钱改少吧- 数据写权限- 如签名技术
• 可用性(Availability)- 确保数据可以被访问到，才能保证业务可用- 比如某些 P2P 公司恶意竞争，针对我们公司 DDoS 攻击就是针对可用性的攻击

0x011 3A原则

那么我们需要如何去保证 CIA 3 个原则呢？那就是授权认证，也就是我们平时说的 3A认证:

• 认证(Authentication)：你是谁，事前防御
• 授权(Authorization)：你能做什么，事中防御
• 审计(Audit)：你做过什么，事后审计

0x012 安全实施基础

如何实施 3A 认证？安全的原则建立在加密的机制上，密码学就是安全的基础设施，所以先需要了解密码学，常用的加密算法有：

• 对称加密：加密解密用一把钥匙：- DES(Data Encryption Standard): 密钥长度 56，不太安全- IDES(International Data Encryption Algorithm): 密钥长度 128，比 DES 加密强，比 AES 慢- AES(Advanced Encryption Standard): 密钥有 128，192，256 等长度，目前安全，用 AES-CTR- 国密SM1和SM4(SM4 Cryptographic Algorithm): 国产算法，一般国企要求
• 非对称加密：加密和解密密钥不同：私钥加密，公钥解密是签名，确认身份的；公钥加密，私钥解密是数据加密- RSA: 质数计算- ECC(Elliptic Curve Cryptography): 椭圆曲线- 国密SM2: 也是椭圆曲线
• hash 算法，把消息 Mapping 到一个有限集计算 hash 值，不可逆，一般用作校验- MD5(Message-Digest Algorithm 5): 已被破解- SHA(Secure Hash Algorithm): 推荐用 SHA-256及以上- 国密SM3(SM3 Cryptographic Algorithm): 和 SHA-256强度差不多

除了密码学外，在实际的落地过程中，认证问题存在的问题有哪些？ 认证的风险有比如弱口令，密码泄露等等。而在实际中认证通常用的系统是单点登录系统，特别是微服务架构和多应用平台的系统。而针对内部认证一般是 LDAP 用的比较多。典型的 SSO 有：

• CAS
• JWT
• OAuth
• OpenID

除了认证要做好之外，授权也要做好。授权无非是对 subjective(主体) 对 objective(客体) 的 verb(动词) 允许或拒绝，而针对这两者之间，不同的场景就有不同的模型了，常见的有：

• DAC(Discretionary Access Control) 自主访问控制: objective 的所有者决定访问的权限，比如 linux 文件系统
• role-BAC: 基于角色的访问控制，比如 kubernetes 中，serviceaccount 的权限由他 rolebinding 到的 role 决定
• rule-BAC: 基于规则的访问控制，比如 iptables,不符合规则就 deny
• MAC(Mandatory Access Control): 强制访问控制，对 subject 和 object 都打标签，根据标签制定访问控制策略，比如 selinux 使用的就是这个

3A 原则的最后一点则是 Audit，需要记录下我们到底做了什么，比如运维中必备的 ELK一套日志基础设施就是起到审计的作用。另外现在运维常提的 AIOps，也会用到机器学习的一些手段对日志进行异常分析和做业务风控，这些都是属于 Audit。

0x013 威胁评估

在我们了解了安全的本质是数据后，我们要如何保护呢？这些数据又面临着哪些风险？这就需要威胁风险评估的必要。威胁评估有三个步骤：

• 识别数据：我们首先要知道数据在哪里，比如我们的 Web 服务器，这台机器上放着着我们的业务，那么这台服务器就是我们的资产，同时我们也根据资产的不同等级来实施不同的保护措施
• 识别攻击：黑客会通过哪些手段来进行攻击，暴力破解，注入还是社工？我们这台服务器的暴露面在哪里？上面开启的哪些端口，黑客会怎么攻进来？
• 识别漏洞：这台服务器存在哪些漏洞，我们用到了什么组件？struts2 还是 spring？有没有字符串拼接SQL语句？这些都是可能存在的漏洞

在对面临的威胁有了一个大概的评估后，我们才好推动安全和解决风险，另外如果说的直接一点，我们必须有对整个资产面临的风险的把控能力，才好拿到预算并做好公司的安全预案，毕竟钱多好办事呐。

作者：N0mansky

原文地址：https://segmentfault.com/a/1190000021363745

喜欢  0