【51CTO.com原創(chuàng)稿件】自 Kubernetes 項(xiàng)目啟動(dòng)以來(lái)，安全性已得到了長(zhǎng)足提高，但仍存在幾個(gè)問(wèn)題。文章從控制平面入手，然后介紹工作負(fù)載和網(wǎng)絡(luò)安全，最后預(yù)測(cè)安全未來(lái)。本文列出的幾個(gè)要點(diǎn)有助于加固集群并提高集群應(yīng)對(duì)威脅的能力。

第一部分：控制平面

控制平面是 Kubernetes 的大腦。它全面洞察集群上運(yùn)行的每一個(gè)容器和 pod，可以調(diào)度新的 pod （pod 包含對(duì)父節(jié)點(diǎn)擁有 root 訪問(wèn)權(quán)限的容器），讀取存儲(chǔ)在集群中的所有私密信息。這種寶貴資產(chǎn)需要防范意外泄漏和惡意威脅：被訪問(wèn)時(shí)、處于靜態(tài)時(shí)以及在網(wǎng)絡(luò)上傳輸時(shí)都要受到保護(hù)。

TLS Everywhere

凡是支持 TLS 以防止流量嗅探、驗(yàn)證服務(wù)器身份以及（對(duì)于相互 TLS 而言）驗(yàn)證客戶端身份的每個(gè)組件，都應(yīng)該啟用 TLS。

請(qǐng)注意：某些組件和安裝方法可能會(huì)啟用基于 HTTP 的本地端口，管理員應(yīng)該熟悉每個(gè)組件的設(shè)置，以識(shí)別可能不安全的流量。

LucasK?ldstr?m 繪制的這個(gè)網(wǎng)絡(luò)圖演示了理想情況下運(yùn)用 TLS 的一些地方：在主節(jié)點(diǎn)上的每個(gè)組件之間以及 Kubelet 和 API 服務(wù)器之間。

Kelsey Hightower堪稱典范的《Kubernetes The Hard Way》（https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/1.9.0/docs/04-certificate-authority.md）提供了詳細(xì)的手冊(cè)說(shuō)明，etcd的安全模型（https://coreos.com/etcd/docs/latest/op-guide/security.html）文檔也是如此。

圖1

自動(dòng)擴(kuò)展 Kubernetes 節(jié)點(diǎn)向來(lái)很難，因?yàn)槊總€(gè)節(jié)點(diǎn)都需要 TLS 密鑰才能連接到主節(jié)點(diǎn)，而將私密信息嵌入到基本鏡像不是好的做法。Kubelet TLS 引導(dǎo)（https://medium.com/@toddrosner/kubernetes-tls-bootstrapping-cf203776abc7）讓新的 kubelet 能夠創(chuàng)建證書簽名請(qǐng)求，以便引導(dǎo)時(shí)生成證書。

圖2

啟用最小權(quán)限的 RBAC，禁用 ABAC

并監(jiān)控日志

基于角色的訪問(wèn)控制（RBAC）為用戶訪問(wèn)資源提供了細(xì)粒度的策略管理，比如訪問(wèn)命名空間。

圖3

自版本 1.6 以來(lái)，Kubernetes 的 ABAC（基于屬性的訪問(wèn)控制）已被 RBAC 取代，不應(yīng)在 API 服務(wù)器上啟用。請(qǐng)改用 RBAC：

--authorization-mode=RBAC

或者使用該標(biāo)志在 GKE 中禁用它：

--no-enable-legacy-authorization

有好多關(guān)于為集群服務(wù)設(shè)置 RBAC 策略的典型案例以及好多文檔。此外，還可以使用 audit2rbac，從審計(jì)日志提取細(xì)粒度的 RBAC 策略。

萬(wàn)一 pod 受到危及，不正確或過(guò)于寬松的 RBAC 策略是一種安全威脅。保持最小權(quán)限，不斷審查和改進(jìn) RBAC 規(guī)則，應(yīng)被視為是“技術(shù)債務(wù)衛(wèi)生”的一部分，團(tuán)隊(duì)?wèi)?yīng)納入到開發(fā)生命周期中。

Audit Logging（1.10 版中的 beta）在有效載荷（比如請(qǐng)求和響應(yīng)）和元數(shù)據(jù)級(jí)別提供了可定制的 API 日志。日志級(jí)別可根據(jù)貴企業(yè)的安全策略加以調(diào)整——GKE 提供了合理的默認(rèn)設(shè)置幫助你上手。

對(duì)于 get、list 和 watch 等讀取請(qǐng)求，只有請(qǐng)求對(duì)象保存在審計(jì)日志中，響應(yīng)對(duì)象不保存。對(duì)于涉及 Secret 和 ConfigMap 等敏感數(shù)據(jù)的請(qǐng)求，只導(dǎo)出元數(shù)據(jù)。對(duì)于其他所有請(qǐng)求，請(qǐng)求對(duì)象和響應(yīng)對(duì)象都保存在審計(jì)日志中。

不要忘記：萬(wàn)一受到危及，將這些日志保存在集群中是一種安全威脅。與其他所有安全敏感日志一樣，應(yīng)將這些日志傳輸?shù)郊和饷?，以防萬(wàn)一泄密時(shí)被人篡改。

對(duì) API 服務(wù)器使用第三方驗(yàn)證

在整個(gè)企業(yè)集中驗(yàn)證和授權(quán)機(jī)制（即單次登錄）有助于為用戶配置和取消資源，并授予一致的權(quán)限。

將 Kubernetes 與第三方驗(yàn)證提供商（比如谷歌或 Github）整合起來(lái)使用遠(yuǎn)程平臺(tái)的身份保證（輔以雙因子驗(yàn)證即 2FA 等機(jī)制），因而管理員無(wú)需重新配置 Kubernetes API 服務(wù)器以添加或刪除用戶。

Dex（https://github.com/coreos/dex）是 OpenID Connect Identity（OIDC）和 OAuth 2.0 提供商，帶可插入式連接件。

Pusher 借助一些自定義工具使這更進(jìn)了一步，另外有一些幫助程序（https://github.com/micahhausler/k8s-oidc-helper）可使用，但用例稍有不同。

分離你的 etcd 集群

etcd 存儲(chǔ)關(guān)于狀態(tài)和私密數(shù)據(jù)的信息，它是 Kubernetes 的一個(gè)關(guān)鍵組件，保護(hù)它的方式應(yīng)該有別于集群的其他部分。

對(duì) API 服務(wù)器的 etcd 的寫訪問(wèn)相當(dāng)于獲得整個(gè)集群上的 root 權(quán)限，連讀取訪問(wèn)都可以用來(lái)很輕松地提升權(quán)限。

Kubernetes 調(diào)度程序?qū)⒃?etcd 中搜索沒(méi)有節(jié)點(diǎn)的 pod 定義。然后，它將找到的 pod 發(fā)送到可用的 kubelet 進(jìn)行調(diào)度。API 服務(wù)器將已提交的 pod 寫到 etcd 之前，負(fù)責(zé)對(duì)這些 pod 進(jìn)行驗(yàn)證，所以直接寫到 etcd 的惡意用戶可以繞過(guò)許多安全機(jī)制，比如 PodSecurityPolicies。

應(yīng)為 etcd 配置對(duì)等體（peer）和客戶端 TLS 證書，部署在專用節(jié)點(diǎn)上。為了防范 worker 節(jié)點(diǎn)上的私鑰被竊取和使用，集群也可以通過(guò)防火墻與 API 服務(wù)器隔開。

輪換加密密鑰

一個(gè)安全最佳實(shí)踐是定期輪換加密密鑰和證書，以便限制密鑰泄密的“影響范圍”。

Kubernetes 將通過(guò)現(xiàn)有登錄信息到期失效時(shí)創(chuàng)建新的 CSR 來(lái)自動(dòng)輪換一些證書（尤其是 kubelet 客戶端和服務(wù)器的證書）。

然而，API 服務(wù)器用于加密 etcd 值的對(duì)稱加密密鑰并不自動(dòng)輪換，它們得手動(dòng)輪換。為此需要訪問(wèn)主節(jié)點(diǎn)，所以托管服務(wù)（比如 GKE 或 AKS）讓操作員無(wú)需操心該問(wèn)題。

第二部分：工作負(fù)載

由于控制平面上的最小可行安全，集群得以安全地運(yùn)行。但是就像輪船載有可能危險(xiǎn)的貨物一樣，輪船集裝箱必須受到保護(hù)，以便發(fā)生不測(cè)時(shí)里面的貨物完好無(wú)損。

對(duì)于 Kubernetes 工作負(fù)載（pod、部署、作業(yè)和集合等）來(lái)說(shuō)，也是如此，它們可能在部署時(shí)受到信任，但如果它們面向互聯(lián)網(wǎng)，總是存在后來(lái)被利用的風(fēng)險(xiǎn)。以最小權(quán)限運(yùn)行工作負(fù)載并加強(qiáng)運(yùn)行時(shí)配置有助于降低這一風(fēng)險(xiǎn)。

使用Linux安全功能

和PodSecurityPolicies

Linux 內(nèi)核有許多重疊的安全擴(kuò)展（功能、SELinux、AppArmor 和 seccomp-bpf），它們經(jīng)配置后可為應(yīng)用程序提供最小權(quán)限。

bane（https://github.com/genuinetools/bane）之類的工具有助于生成 AppArmor 配置文件，docker-slim（https://github.com/docker-slim/docker-slim#quick-seccomp-example）有助于生成 seccomp 配置文件，但要注意：驗(yàn)證運(yùn)用這些策略的副作用時(shí)，需要一套全面的測(cè)試來(lái)測(cè)試應(yīng)用程序中的所有代碼路徑。

PodSecurityPolicies（https://kubernetes.io/docs/concepts/policy/pod-security-policy/）可用于強(qiáng)制使用安全擴(kuò)展及其他 Kubernetes 安全指令。它們提供了 pod 必須履行的最基本合約才能提交到 API 服務(wù)器，包括安全配置文件、特權(quán)標(biāo)志以及主機(jī)網(wǎng)絡(luò)、進(jìn)程或 IPC 命名空間的共享。

這些指令很重要，因?yàn)樗鼈冇兄诜乐谷萜骰M(jìn)程脫離隔離邊界，Tim Allclair 的示例 PodSecurityPolicy（https://gist.github.com/tallclair/11981031b6bfa829bb1fb9dcb7e026b0）是個(gè)綜合資源，你可以根據(jù)自己的用例來(lái)定制。

靜態(tài)分析 YAML

在 PodSecurityPolicies 拒絕訪問(wèn) API 服務(wù)器的情況下，靜態(tài)分析也可用于開發(fā)工作流程，以模擬企業(yè)組織的合規(guī)需求或風(fēng)險(xiǎn)偏好。

敏感信息不應(yīng)存儲(chǔ)在 pod 類型的 YAML 資源（部署、pod 和集合）中，敏感的配置映射和私密信息應(yīng)使用 vault、git-crypt、sealed secrets 或云提供商 KMS 來(lái)進(jìn)行加密。

YAML 配置的靜態(tài)分析可用于為運(yùn)行時(shí)安全性建立一條基線。kubesec（https://kubesec.io/）為資源生成風(fēng)險(xiǎn)評(píng)分：

{ 
"score": -30, 
"scoring": { 
"critical": [{ 
"selector": "containers[]  .securityContext .privileged == true", 
"reason": "Privileged  containers can allow almost completely unrestricted host access" 
    }], 
"advise": [{ 
"selector": "containers[]  .securityContext .runAsNonRoot == true", 
"reason": "Force  the running image to run as a non-root user to ensure least privilege" 
    }, { 
"selector": "containers[]  .securityContext .capabilities .drop", 
"reason": "Reducing  kernel capabilities available to a container limits its attack surface", 
"href": "https://kubernetes.io/docs/tasks/configure-pod-container/security-context/" 
    }] 
  } 
} 

而 kubetest（https://github.com/garethr/kubetest）是 Kubernetes 配置的單元測(cè)試框架：

#// vim: set ft=python: 
deftest_for_team_label(): 
if spec["kind"] =="Deployment": 
        labels = spec["spec"]["template"]["metadata"]["labels"] 
assert_contains(labels, "team", "should indicate which team owns the deployment") 
test_for_team_label() 

這些工具“向左移”（在開發(fā)周期的早期移動(dòng)檢查和驗(yàn)證）。開發(fā)階段的安全測(cè)試為用戶提供了可能被后來(lái)的手動(dòng)或自動(dòng)檢查拒絕的代碼和配置方面的快速反饋，可以減小引入更安全的實(shí)踐帶來(lái)的阻力。

以非 root 用戶的身份運(yùn)行容器

經(jīng)常以 root 的身份運(yùn)行的容器通常擁有比工作負(fù)載實(shí)際要求多得多的權(quán)限，萬(wàn)一受到危及，會(huì)幫助攻擊者進(jìn)一步發(fā)動(dòng)攻擊。

容器仍依賴傳統(tǒng)的 Unix 安全模型（名為自主訪問(wèn)控制或 DAC），一切都是文件，權(quán)限授給用戶和用戶組。

用戶命名空間在 Kubernetes 中并未啟用。這意味著容器的用戶 ID 表映射到主機(jī)的用戶表，以 root 用戶的身份在容器內(nèi)運(yùn)行進(jìn)程就是在主機(jī)上以 root 身份運(yùn)行它。雖然我們有分層安全機(jī)制來(lái)防止容器突破（container breakout），但仍不推薦以 root 的身份在容器內(nèi)運(yùn)行。

許多容器鏡像使用 root 用戶來(lái)運(yùn)行 PID 1，如果該進(jìn)程受到危及，攻擊者擁有容器的 root 權(quán)限，任何錯(cuò)誤配置會(huì)變得極容易被利用。

Bitnami 已做了大量的工作將容器鏡像移動(dòng)到非 root 用戶（尤其是由于 OpenShift 默認(rèn)需要這樣），這可以簡(jiǎn)化遷移到非 root 容器鏡像。

這個(gè) PodSecurityPolicy 代碼片段可防止以 root 的身份在容器內(nèi)運(yùn)行進(jìn)程，并防止權(quán)限提升到 root：

# Required to prevent escalations to root. 
allowPrivilegeEscalation:false 
runAsUser: 
# Require the container to run without root privileges. 
rule:'MustRunAsNonRoot' 

非 root 容器無(wú)法綁定到 1024 以下的特權(quán)端口（這由 CAP_NET_BIND_SERVICE 內(nèi)核功能控制），但可以使用服務(wù)來(lái)掩蓋這個(gè)事實(shí)。在該示例中，虛構(gòu)的 MyApp 應(yīng)用程序綁定到容器中的端口 8443，但是該服務(wù)通過(guò)代理請(qǐng)求到 targetPort，在端口 443 上提供它：

kind:Service 
apiVersion:v1 
metadata: 
name:my-service 
spec: 
selector: 
app:MyApp 
ports: 
-protocol:TCP 
port:443 
targetPort:8443 

必須以非 root 用戶的身份運(yùn)行工作負(fù)載這一點(diǎn)在用戶命名空間可用之前不會(huì)改變。

使用網(wǎng)絡(luò)策略

默認(rèn)情況下，Kubernetes 網(wǎng)絡(luò)允許所有 pod 到 pod 的流量，可以使用網(wǎng)絡(luò)策略（https://kubernetes.io/docs/concepts/services-networking/network-policies/）對(duì)此進(jìn)行限制。

圖4

傳統(tǒng)服務(wù)用防火墻加以限制，防火墻為每個(gè)服務(wù)使用靜態(tài) IP 和端口范圍。由于這些 IP 很少變化，因此歷來(lái)用作一種身份。容器很少有靜態(tài) IP，它們是為了快速失效（fail fast）、快速重新調(diào)度，并使用服務(wù)發(fā)現(xiàn)而不是靜態(tài) IP 地址。這些屬性意味著，防火墻配置和檢查起來(lái)難多了。

由于 Kubernetes 將其所有系統(tǒng)狀態(tài)存儲(chǔ)在 etcd 中，它可以配置動(dòng)態(tài)防火墻，前提是它得到 CNI 網(wǎng)絡(luò)插件的支持。Calico、Cilium、kube-router、Romana 和 Weave Net 都支持網(wǎng)絡(luò)策略。

值得一提的是，這些策略一失效就關(guān)閉，所以這里缺少 podSelector 默認(rèn)情況下用通配符：

apiVersion:networking.k8s.io/v1 
kind:NetworkPolicy 
metadata: 
name:default-deny 
spec: 
podSelector: 

下面這個(gè)示例 NetworkPolicy 拒絕除 UDP 53（DNS）之外的所有出站流量，這還阻止入站連接到你的應(yīng)用程序。NetworkPolicies 是有狀態(tài)的（https://www.weave.works/blog/securing-microservices-kubernetes/），所以出站請(qǐng)求的回復(fù)仍抵達(dá)應(yīng)用程序。

apiVersion:networking.k8s.io/v1 
kind:NetworkPolicy 
metadata: 
name:myapp-deny-external-egress 
spec: 
podSelector: 
matchLabels: 
app:myapp 
policyTypes: 
-Egress 
egress: 
-ports: 
-port:53 
protocol:UDP 
-to: 
-namespaceSelector:{} 

Kubernetes 網(wǎng)絡(luò)策略無(wú)法應(yīng)用于 DNS 名稱。這是由于 DNS 可解析針對(duì)多個(gè) IP 的輪詢，或者基于呼叫 IP 動(dòng)態(tài)解析，所以網(wǎng)絡(luò)策略只能應(yīng)用于固定 IP 或 podSelector（針對(duì)動(dòng)態(tài) Kubernetes IP）。

最佳實(shí)踐是先拒絕命名空間的所有流量，然后逐漸添加路由，允許應(yīng)用程序通過(guò)其許可測(cè)試套件。這可能變得很復(fù)雜，于是 ControlPlane 結(jié)合了 netassert（https://github.com/controlplaneio/netassert），這是面向 DevSecOps 工作流程的網(wǎng)絡(luò)安全測(cè)試框架，擁有高度并行化的 nmap：

k8s:# used for Kubernetes pods 
deployment:# only deployments currently supported 
test-frontend:# pod name, defaults to `default` namespace 
test-microservice:80# `test-microservice` is the DNS name of the target service 
test-database:-80# `test-frontend` should not be able to access test-database’s port 80 
169.254.169.254:-80,-443# AWS metadata API 
metadata.google.internal:-80,-443# GCP metadata API 
new-namespace:test-microservice:# `new-namespace` is the namespace name 
test-database.new-namespace:80# longer DNS names can be used for other namespaces 
test-frontend.default:80 
169.254.169.254:-80,-443# AWS metadata API 
metadata.google.internal:-80,-443# GCP metadata API 

云提供商元數(shù)據(jù) API 歷來(lái)是提升權(quán)限的來(lái)源（最近的 Shopify 漏洞懸賞表明了這點(diǎn)），因此證實(shí) API 在容器網(wǎng)絡(luò)上被阻止的特定測(cè)試有助于防止意外的錯(cuò)誤配置。

掃描鏡像，運(yùn)行 IDS

Web 服務(wù)器給它們連接的網(wǎng)絡(luò)帶來(lái)了攻擊面：掃描鏡像的已安裝文件可確保沒(méi)有已知的漏洞，因而攻擊者無(wú)法鉆漏洞的空子、遠(yuǎn)程訪問(wèn)容器。IDS（入侵檢測(cè)系統(tǒng)）可檢測(cè)攻擊者是否在鉆空子。

Kubernetes通過(guò)一系列準(zhǔn)入控制器（https://kubernetes.io/docs/admin/admission-controllers/）門卡允許pod進(jìn)入集群，這些門卡應(yīng)用于 pod 及其他資源（比如部署）。這些門卡可以驗(yàn)證每個(gè) pod，決定是否準(zhǔn)入或更改內(nèi)容，現(xiàn)在它們支持后端 web 鉤子（webhook）。

圖5

容器鏡像掃描工具可以使用這些 Web 鉤子在鏡像部署到集群之前驗(yàn)證鏡像，可以拒絕未通過(guò)檢查的鏡像準(zhǔn)入。

掃描容器鏡像查找已知漏洞可以縮短攻擊者鉆已披露的 CVE 空子的時(shí)間窗口。應(yīng)該在部署流水線中使用免費(fèi)工具，比如 CoreOS 的 Clair（https://github.com/coreos/clair）和 Aqua 的 Micro Scanner（https://github.com/aquasecurity/microscanner），防止部署存在嚴(yán)重漏洞的鏡像。

Grafeas（https://grafeas.io/）等工具可以存儲(chǔ)鏡像元數(shù)據(jù)，針對(duì)容器的獨(dú)特簽名（內(nèi)容可尋址哈希）不斷進(jìn)行合規(guī)和漏洞檢查。這意味著掃描擁有該哈希的容器鏡像與掃描生產(chǎn)環(huán)境中部署的鏡像一樣，可以持續(xù)地執(zhí)行，不需要訪問(wèn)生產(chǎn)環(huán)境。

未知的零日漏洞將始終存在，所以應(yīng)在 Kubernetes 中部署入侵檢測(cè)工具，比如 Twistlock（https://www.twistlock.com/）、Aqua（https://www.aquasec.com/）和 Sysdig Secure（https://sysdig.com/product/secure/）。IDS 可檢測(cè)容器中的異常行為，暫?；蚪K止容器。Sysdig 的 Falco 是一種開源規(guī)則引擎（https://github.com/draios/falco），是這個(gè)生態(tài)系統(tǒng)的入口點(diǎn)。

展望未來(lái)

安全界“云原生演化”的下一個(gè)階段看起來(lái)是服務(wù)網(wǎng)格（service mesh），不過(guò)可能一段時(shí)間后才會(huì)采用。遷移需要將復(fù)雜性從應(yīng)用程序轉(zhuǎn)移到網(wǎng)格基礎(chǔ)設(shè)施，企業(yè)組織熱衷于了解最佳實(shí)踐。

圖6

運(yùn)行服務(wù)網(wǎng)絡(luò)

服務(wù)網(wǎng)格是加密持久的連接組成的網(wǎng)絡(luò)，是在 Envoy 和 Linkerd 等高性能“跨斗”（sidecar）代理服務(wù)器之間建立起來(lái)的。它增加了流量管理、監(jiān)控和策略，這一切無(wú)需更改微服務(wù)。

有了 Linkerd（https://linkerd.io/），已經(jīng)可以將微服務(wù)的安全和網(wǎng)絡(luò)代碼卸載到一組共享的、久經(jīng)測(cè)試的庫(kù)，谷歌、IBM 和 Lyft 推出的 Istio（https://istio.io/）在這個(gè)領(lǐng)域增加了另一種方案。

由于添加了面向每個(gè)pod加密身份的 SPIFFE（https://spiffe.io/）以及其他眾多功能（https://istio.io/docs/concepts/what-is-istio/overview.html），Istio 有望簡(jiǎn)化部署下一代網(wǎng)絡(luò)安全的工作。

在“零信任”網(wǎng)絡(luò)中，不需要傳統(tǒng)的防火墻或 Kubernetes 網(wǎng)絡(luò)策略，因?yàn)槊恳淮谓换ザ蓟?mTLS（相互TLS）進(jìn)行，確保雙方不僅安全通信，而且兩種服務(wù)的身份都已知道。

對(duì)于奉行傳統(tǒng)安全理念的人來(lái)說(shuō)，從傳統(tǒng)網(wǎng)絡(luò)到云原生安全原則的這種轉(zhuǎn)變并不容易，而SPIFFE 的 Evan Gilman 撰寫的《零信任網(wǎng)絡(luò)》（https://amzn.to/2Gg6Pav）一書清楚地介紹了這個(gè)嶄新的領(lǐng)域，強(qiáng)烈推薦讀一讀。

Istio 0.8 LTS 已過(guò)時(shí)，該項(xiàng)目正迅速接近 1.0 版本。其穩(wěn)定版本控制與 Kubernetes 模型一樣：一個(gè)穩(wěn)定的核心，各個(gè) API 在各自的 alpha/beta 穩(wěn)定命名空間下自報(bào)身份。預(yù)計(jì) Istio 的采用率在今后幾個(gè)月會(huì)有所上升。

結(jié)束語(yǔ)

云原生應(yīng)用程序有一組更精細(xì)的輕量級(jí)安全基元，為工作負(fù)載和基礎(chǔ)設(shè)施確保安全。這些工具的強(qiáng)大功能和靈活性有利也有弊；由于自動(dòng)化程度不足，更容易暴露允許突破容器或其隔離模型的不安全的工作負(fù)載。

現(xiàn)在可供使用的防御工具比以往更多，但須謹(jǐn)慎行事，減小攻擊面和錯(cuò)誤配置的可能性。

然而，如果安全減慢了企業(yè)組織交付功能的步伐，安全永遠(yuǎn)不會(huì)成為“一等公民”。將持續(xù)交付原則運(yùn)用于軟件供應(yīng)鏈讓企業(yè)組織得以實(shí)現(xiàn)合規(guī)、持續(xù)審計(jì)和強(qiáng)制治理，又不影響公司的賬本底線。

如果得到全面測(cè)試套件的支持，安全方面快速迭代最容易。這可以通過(guò)持續(xù)安全（Continuous Security）來(lái)實(shí)現(xiàn)——這是時(shí)間點(diǎn)滲透測(cè)試之外的替代方案，持續(xù)的流水線驗(yàn)證確保企業(yè)組織的攻擊面已知，風(fēng)險(xiǎn)不斷被理解和管理。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】