安全架构案例与实战

本文以实战经验详细介绍了企业安全架构设计。包含对设备的身份认证、最小授权原则、设备准入控制、应用访问控制、对人的身份认证。

安全架构案例与实战

• 无边界网络的理解，重新绘制的无边界网络系统架构图。其中托管设备可以暂时理解为公司统一配发、经过安全加固的电脑。
  • 无论员工是在办公场地，还是在外出差，都是使用外网IP地址访问网关；当员工在办公场地时，会同时启用准入控制，便于对电脑终端进行修复，如系统补丁。
  • 图中的虚线为安全相关的功能（身份认证、动态授权与访问控制、NAC等），实线为业务访问（通过网关统一接入）。下面分别进行介绍。
• 对人的身份认证（SSO及U2F）
  • 不能信任企业内部和外部的任何人，首先就需要身份认证，确认访问者的身份。
  • 实现身份认证依靠的是企业的SSO系统，为了确保身份的安全性，SSO的认证机制需要具备防止钓鱼攻击的能力。
  • 如果采用静态口令，则口令的泄露就会导致身份被冒用。
  • 企业在内网较多采用动态口令机制（TOTP），不过前面讲双因子认证时提到，如果在外网使用TOTP，仍有可能遭受实时的钓鱼攻击（动态口令通常在30秒或60秒内有效）。
  • 为了规避这一风险，企业的SSO系统就需要改用更安全的双因子身份认证机制，推荐U2F（Universal 2nd Factor，通用双因子身份认证，是由Google和Yubico共同推出的开放认证标准）。Google就采用了U2F的方式。
• 对设备的身份认证
  • 不能信任企业内部和外部的任何设备，就需要对设备进行认证和接入控制。
  • 对设备的认证主要采用数字证书，设备的数字证书存储在硬件或软件的TPM（可信平台模块），或操作系统证书管理器中。
• 最小授权原则
  • 采用最小权限原则，在应用层赋予用户完成特定工作所需的最小权限。授权机制通过IAM（身份与访问管理）进行，整合了SSO认证、授权、审计几大功能。授权可以基于角色授权（如某员工属于工程师序列，拥有工程师角色的权限；或属于工程部，拥有工程部对应的权限），也可以基于属性进行授权（如某员工是目标业务的管理员）。
• 设备准入控制
  • 首先来看终端设备，也就是员工办公使用到的电脑、笔记本电脑、手机等终端。在前面讲网络准入控制的时候，已提到这些终端从安全上可以划分未注册、已注册、不可信、可信任等几个状态，如图所示。
  • 通过对设备状态的判定，可执行相应的网络准入控制，如：
    • ■ 只允许公司配发的电脑注册登记。
    • ■ 只允许可信任终端接入办公网络，否则接入修复区。
  • 对生产网络中的服务器来说，Google采用了基于定制安全芯片的信任链传递机制，其中安全芯片作为信任链的根，依次对BIOS、BootLoader、操作系统内核进行签名，确保它们未被篡改，也就是说操作系统是可信的；如果是没有安全芯片的设备，就可以视为外来设备，拒绝接入网络。
• 应用访问控制
  • 通过应用网关接管后端所有应用、资源、服务器的访问流量，只有先在应用网关系统中登记才能对外提供服务；只有通过身份认证与终端可信的用户才可以访问隐藏在应用访问网关之后的业务服务。
  • 应用访问控制采用RBAC（基于角色的访问控制）和ABAC（基于属性的访问控制）相结合。
  • Google的应用网关，首先实现了Web的代理（称为GFE, Google Front-End），提供Web反向代理、负载均衡、TLS终止等功能；后又进行了扩展，支持了SSH等非Web的协议，统称为访问网关（Access Proxy）。也就是说，Google的访问网关支持Web业务和非Web业务，其中支持Web业务的部分为GFE。
  • 下面来看实际的访问场景：
    • 1）工程师员工的笔记本电脑发起访问请求，提交给访问网关，带上设备证书。
    • 2）访问网关没有检测到有效的用户凭据，将用户重定向到SSO，如图所示。
    • 3）工程师使用U2F双因子身份认证通过认证，获得认证通过的Token（或Ticket），重定向到访问网关，如图所示。
    • 4）访问网关收到设备证书（标明设备身份）和SSO Token（标明员工身份），如图所示。
    • 5）访问控制引擎对每一个请求执行授权检查（检查通过，转发到相应的后端服务器；检查不通过，拒绝请求）：
      • ■ 确认用户在工程师群组（基于用户/群组数据库）。
      • ■ 确认用户拥有足够的信任等级。
      • ■ 确认用户使用的电脑是可信任终端（托管终端+健康状态良好）。
      • ■ 确认用户使用的电脑拥有足够的信任等级。
• 统一HTTPS接入与安全防御
  • 在前面的章节中，多次提到统一接入、应用网关的概念。
  • 原理与架构
    • 如图所示，Janusec是基于Golang打造的应用安全网关，具备WAF（Web应用防火墙）功能及组合策略配置，支持HTTP2和HTTPS（符合PCI-DSS认证要求），无需在目标服务器部署组件（Agent），私钥加密存储在数据库，提供负载均衡和统一的Web化管理入口。
  • 架构设计要点：
    • ■ 应用网关：采用统一的HTTPS接入（TLS加密通信），统一管理证书和私钥。
    • ■ 安全防护：网关内置Web应用防火墙、CC防护。
    • ■ 数据保护：对私钥采取加密措施。
    • ■ 前端负载均衡与后端负载均衡。
    • ■ Web化后台管理。
  • 应用网关与HTTPS
    • 应用网关的核心功能是反向代理（Reverse Proxy），用于统一接入，反向代理到后端真实的Web业务，避免直接路由到生产环境。反向代理即转发用户请求到内部真实服务器（使用内部地址）并将结果返回给用户，对用户隐藏内部地址。对用户而言，可见的部分到网关就中止了，网关到业务的部分对用户而言是看不见的，如图所示。
    • 在网关的Web管理后台，配置内部业务和后端地址之后，只需要将业务域名指向网关即可实现访问内部业务。
    • 应用网关作为统一接入的基础设施，需要具备HTTPS支持，特别是当前HTTPS已基本普及的情况下，如果不启用HTTPS，则用户的访问很容易被第三方劫持，用于加塞广告等行为。Janusec采用了直接在Web管理后台统一管理证书和私钥（加密）的方式，可以让各业务不再自行保管敏感的私钥。
  • WAF与CC防御
    • 内置WAF使用Google RE2正则引擎，可拦截典型的Web漏洞如SQL注入、XSS（跨站脚本）、敏感信息泄露、WebShell上传或连接动作、路径遍历等。
    • 在CC防御方面，基于访问频率和访问统计，对同一来源，在设定的单位时间内，访问次数超过设定的阈值，就触发拦截或出验证码等机制。
    • ■ 统计周期（Statistic Period）：统计的时间窗，时长用秒数来计算。
    • ■ 最大请求数（Max Requests Count）：统计周期内允许的最大请求次数，如果超过，则触发CC规则。
    • ■ 锁定秒数（Block Seconds）：触发CC规则后，此后一段时间内不再直接响应同一来源的请求，锁定秒数即这段时间的时长。
    • ■ 动作（Action）：触发CC规则后，可选择直接拒绝（Block）或者出验证码（CAPTCHA）等动作
  • 私钥数据保护
    • 当前，各大主流Web服务器在配置证书的时候，均使用文件形式的证书及私钥文件，在配置文件中设置两个证书文件的路径。以Nginx为例： server { listen 443 ssl; ssl_certificate /path/to/fullchain.pem; ssl_certificate_key /path/to/privkey.pem; ... }
    • Janusec把证书统一管理起来，采用AES256加密保护私钥，不再将证书文件、私钥文件直接明文存放在服务器某个目录下，可有效防止黑客窃取私钥。使用psql登录进Janusec所使用的PostgreSQL数据库。
    • Janusec把证书统一管理起来，采用AES256加密保护私钥，不再将证书文件、私钥文件直接明文存放在服务器某个目录下，可有效防止黑客窃取私钥。使用psql登录进Janusec所使用的PostgreSQL数据库。
  • 负载均衡
    • Janusec支持多网关节点部署作为前端的负载均衡，可通过DNS或GSLB（Global Server Load Balance，全局负载均衡）的DNS调度，将不同地域的请求引导到不同的网关节点。当后端业务存在多台服务器时，也会随机选择后端服务器进行负载均衡
  • 存储加密实践
    • 哪些数据需要加密存储呢？结合当前的各项监管政策和国际国内的合规要求，以及加解密对业务场景的适配度，建议如下：
      • ■ 敏感的个人信息以及涉及敏感的个人隐私的数据、敏感的UGC数据，需要加密存储。
      • ■ 口令、加解密密钥、私钥，需要加密存储（其中不需要还原的口令需要使用单向散列算法）。
      • ■ 有明确检索、排序、求和等运算需求的业务数据，不需要加密存储。
      • 其他需结合业务场景进行判断。
    • 数据库字段加密
      • 针对结构化数据（一般指存放于数据库的数据），推荐采用数据库字段加密，这属于产品自身需要考虑的事情。主要原理是加解密过程需要KMS系统配合完成，即使业务系统全部源码和数据丢失，黑客也无法解密，如图所示。
      • 不过在涉及用户的敏感个人数据加密时，上述KEK需要使用针对该用户和业务特定的KEK，而不能对所有用户都使用同一个KEK，也不能一个用户所有的业务都使用同一个KEK，这样在用户提出删除某个业务中的个人数据时，删除该用户对应该业务的KEK即可满足合规要求。
    • 数据库透明加密
      • 部分数据库也支持透明加密（或静态加密），原来使用明文存取数据的应用不需要任何改进，由数据库提供透明的加解密，可供最低级别的加密参考。
      • 例如MariaDB从10.1.7版本开始，支持表加密、表空间加密、binlog加密，其他数据库也有类似的特性。 透明加密是一种快速达成加密效果的方案，因为所有的加密和解密过程都是在存储这一级自动完成的。对应用来说，仍可以像以前一样，继续使用明文存取数据，而不需要做任何改进。 如果你所在企业业务众多，难以一一改进，刚好又使用了自建的存储系统，这时就可以考虑对存储系统进行改进，实施静态加密，而业务系统不用改进。这种方式可以快速满足合规要求。 存储系统也可以配合KMS实施静态加密，来加强安全性。
    • 配置文件口令加密
      • 配置文件是口令、密钥类信息泄露的重要渠道，包括员工无意中泄露、黑客或木马侵入服务器后查看配置文件窃取等。
      • 以口令为例，参考前面所说的至少双密钥的机制，也需要为口令加密设置DEK和KEK。 如果有KMS基础设施，可以在KMS系统中为业务申请KEK；没有的话，也可自生成一个KEK写入代码中。 如图所示，首先随机生成一个DEK，使用KEK加密后再通过Base64编码消除不可见字符，写入配置文件；口令使用DEK进行加密后再通过Base64编码消除不可见字符，写入配置文件中原来口令的位置。 尽管原理已经清楚，但往往还是会遇到问题，比如最典型的一个问题就是：第三方开发的脚本程序（如PHP、Python等）该如何改进？通常第三方开发的程序也使用脚本类型的配置文件，如：conf ig.ini.php、settings.py等；在保留第三方脚本程序业务逻辑不变的条件下，我们可以通过使用解密函数替换明文口令的方法，并添加解密函数本身或附加一个解密文件，实现口令解密。