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)