Policy as Code 介绍

> 圖片來源 OPA's Full Stack Policy Language

背景

一流的云计算和云原生应用成为主流，各大企业纷纷推出各种线上服务抢占市场，在其上存储的资料越来越多，也越来越重要，甚至还有与个人敏感的资讯相关；而 很不幸的…也常常可以看到科技新闻提到谁家的资料库或搜寻引擎可以被公开存取，某间大公司的AWS S3包含的客户资料外泄了…等；安全性在未来的世界 中所占的本质将变得越来越重要，因此希望通过此文章介绍在PaC（政策作为代码）领域逐渐崛起的OPA（开放政策代理），并通过实际案例示范如何使用OPA 测试Cloud Infrastructure，确保企业内部的应用服务遵守合规政策（Compliance Policy），安全政策（Security Policy）遵循达成最佳的维运方式！

此文章大概分段以下的章节来一一述说：

· 企业安全

· PaC介绍

· OPA简介

· OPA演示

企业安全

> 圖片來源 Mastering IaC the DevOps Way

根据一些渗透测试的结果可以发现，企业所面对的资安突破实际上很大一个部分是来自于网路或是其它布局设定不正确所引起的，以传统而言要找出这些问题的手法 不外乎渗透测试，红队演练，或者一般常见的例行性稽核；那首先来来谈谈常见的稽核都是怎么进行的吧〜

有被稽核过的人，应该可以理解上面的图片想要表达的意境，因为被稽核的时候一定会有很多的Excel文件，尤其是外部的稽核有很多的程序，通常要花数周到数个 月来检视哪边有问题，再花个数周到数个月来修掉问题，当时常比较赶的情况下，安全性问题也常常会被PM排在产品功能之后，有时候有时候遇到政策 文件还没有不及写出来的情况，毕竟现在新技术推出的速度越来越快了，有时候真的不是 ！ 不过最惨烈的莫过于稽核了老半天，有问题没有被发现，变成一个未爆弹在那边，哪天会出事也不知道

> 圖片來源 Mastering IaC the DevOps Way

一般应用程式的测试领域当中，有一个观念叫做Shife Left Testing，意思是说在本地端开发的时候要做测试，其实是相对容易且快速的，但等到Build跑到CI的环境，或是上到 生产环境之后，流程就会变得比较麻烦，很多情境也不是你说想要测试就可以测到的，所以就会提倡应该在比较左边，也就是偏向于开发的阶段就多做一些测试

把焦点移回来到稽核这件事情本身，在生产环境中执行是相当麻烦的，但他又是一件必须做的事情；而且云端架构越来越庞大，有些老旧系统甚至可能变成孤儿， 假如说要所有的东西都有被检查到，甲方跟乙方的报告都说做到了，但站在我这个一般消费的角度来看，总觉得有些地方还是没那么踏实，不然也不会每天 都有使用者的个资被外泄，让有心人士一直有可以撞库攻击的材料

PaC介绍

> 圖片來源 Mastering IaC the DevOps Way

所以有没有办法把稽核变成自动化，而且移到CI或什至是开发阶段就来施行呢？答案当然是肯定的，所以找到办法把稽核的东西转变成Policy，然后再把Policy转换成为程式码好像一切 就可以水到渠成，在开始讲技术细节之前，先来定义一下这边提到的Policy是指什么？Policy附上三类，分别是…

· 遵守政策：例如如果没有符合PCI或GDPR

· 安全策略：例如如如何储存跟保护资料，并确保整个Infrastructure的完整性

· 卓越运营：例如如要如何预防服务坏掉或系统效能变差

而实际上这类型的工具，在市场上已经有一些了，底下为目前比较为人所知的产品：

· ModSecurity：一种开源Web应用程序防火墙，上次CapitalOne出事好像跟这个有关

· 前哨：HashiCorp的PaC产品，可惜目前只能用在Terraform，Vault或Nomad和Consul上（有问过他们家的人，目前没有打算支持其他平台）

· Inspec：老牌厨师所推出的自动化审核和测试开源软件，在社群资源还算丰富，对于PaC有兴趣的人，不妨也可以研究看看

· 开放政策代理：最后一个就是今天想要特别提到的OPA！

OPA简介

> 圖片來源 Mastering IaC the DevOps Way

开放策略代理是一种通用的策略引擎，用于管理各种资源的授权策略，所以它可以用在管理K8S的准入控制，HTTP API授权，通过数据过滤来做验证…等；当有一个请求进到服务 时，就会先去问OPA有没有符合Policy有的话才可以授权成功，而OPA是用一种叫做Rego的语言来定义Policy，想要把OPA运行在系统中的话，可以用Library或Sidecar， 甚至是一般的Daemon的方式，也有提供API，在社群也已经有开发对应的工具来测试和除错

> 圖片來源 Mastering IaC the DevOps Way

OPA可以支持的领域大概有这五种，例如K8S，Terraform的准入控制，API网关类型的产品，或者最常见的SSH Sudo，甚至可以做到资料的保护和过滤

利用OPA跟Terraform实际演示

一开始有提到网路改造设定错误实际上是造成安全问题的，其中一个，所以今天就来假设一个情境，就是…有一个员工想要用Terraform开一个服务，但他可能偷懒地使用预 设置的防火墙设定，让0.0.0.0/0这个CIDR存在于防火墙中，导致全世界的人都可以访问他开起来的服务，而是其实是不可取的，应用服务前面应该要挡CDN跟WAF ，因此IP锁定CDN的来源IP比较常见

> 圖片來源 Mastering IaC the DevOps Way

那要如何把这个错误/偷懒的网路设定给检查出来呢？因为Terraform在执行之前可以先把他准备要改变的云端资源资讯利用类似Dry Run的方式传送出来，将其转成JSON档案格式为 给OPA，OPA根据预先定义好的使用检查防火墙的规则来做判断，以下将对部分程序码进行解说，完整的程序码可以看到"这边"

从底下的范例中可以研磨防火墙设定可谓门户大开，假如程式或是伺服器端有什么0 Day突破的话，有心人士可以很简单的就摸进去里面

代码为政策/terraform/sg.tf

<code>
..
resource
 
"aws_security_group_rule" "web_ingress_http" {
  
security_group_id
 = 
aws_security_group.web.id
  
type
              = 
"ingress"
  
from_port
         = 
80
  
to_port
           = 
80
  
protocol
          = 
"tcp"
  
cidr_blocks
       = 
["0.0.0.0/0"]
}

resource
 
"aws_security_group_rule" "web_ingress_https" {
  
security_group_id
 = 
aws_security_group.web.id
  
type
              = 
"ingress"
  
from_port
         =  
443
  
to_port
           = 
443
  
protocol
          = 
"tcp"
  
cidr_blocks
       = 
["0.0.0.0/0"]  
}

resource
 
"aws_security_group_rule" "web_ingress_ssh" {
  
security_group_id
 = 
aws_security_group.web.id
  
type
              = 
"ingress"
  
from_port
         = 
22
  
to_port
           = 
22
  
protocol
          = 
"tcp"
  
cidr_blocks
       = 
["0.0.0.0/0"]  
}
/<code>

以下的范例用OPA的Rego订定了简易的Policy，预设sg_rule_check为false（也就是检查的结果预设为不通过），然后去检查所有的Terraform防火墙规则都要不等于0.0.0.0/0的 情况下sg_rule_check才会是true

政策如代码
/terraform/policy/web.rego

<code>package terraform.security
import
 input 
as
 tfplan

 
 
 
default
 sg_rule_check = 
false

forbid_cidrs = [
"0.0.0.0/0"
]

 

sg_rule_check {
  security_rules[_].values.cidr_blocks[_] != forbid_cidrs[_]
}

 
 
 

 
security_rules = all_rules {
    all_rules := [ x |
                 x := tfplan.planned_values.root_module.resources[_]
                 x.type == 
"aws_security_group_rule"
    ]
}/<code>

随后就来实际执行，最后可以看到执行的结果为false，因为的确在Terraform里面有定义0.0.0.0/0的防火墙规则在其中

<code>package terraform.security
import
 input 
as
 tfplan

 
 
 
default
 sg_rule_check = 
false

forbid_cidrs = [
"0.0.0.0/0"
]

 

sg_rule_check {
  security_rules[_].values.cidr_blocks[_] != forbid_cidrs[_]
}

 
 
 

 
security_rules = all_rules {
    all_rules := [ x |
                 x := tfplan.planned_values.root_module.resources[_]
                 x.type == 
"aws_security_group_rule"
    ]
}/<code>

结论

马上可以感觉到Terraform在使用了OPA之后，可以帮助开发者检查Terraform的改变有没有问题，完成刚刚说的Shift-Left测试，而且可以减少团队中的代码审查，发现提早修复。

不过老实说Policy as Code这个领域还相当的新，有赖于大家一起来使用，让这个领域的生态系更加缤纷，毕竟越多人用的东西，资源就会越来越丰富，假如大家对于OPA还 想了解更多，例如跟K8S怎么整合，或者Rego要如何撰写…等，请帮我鼓掌让我知道^^

(本文翻译自smalltown的文章《Policy as Code Introduction》，参考：
https://medium.com/starbugs/policy-as-code-introduction-43332748aa4a)