2.識別、最小化及加固攻擊面
3.降低作用域和訪問權限
4.分層的保護與防御整體應用安全(AppSec)的好處包括其構建和維護的易于理解及“已知的已知”。這種架構往往相對簡單,并且在開發、業務、合規等過程中通常有著根深蒂固的現有習慣(及相關責任分工)。整體應用安全的劣勢包括向單點的妥協,往往也意味著對整個應用及網絡的妥協、全局的認證需求以及安全機制往往很難協調。微服務應用安全的好處包括:廣為接受的Unix單一職責原則、普遍減少的公開暴露的攻擊面、服務可以被單獨打補丁、應用(和相關的運行時容器)更方便地應用最小權限和適應服務特性的安全機制,并且這通常可以更方便地建立可信計算基(TCB)。相應地,劣勢包含:微服務安全是一種“已知的未知”,成功的維護會需要習慣上的改變(如DevOps和DevOpsSec)、需要對整個系統的功能有一個很好的理解、遺留項目很難適用、復雜性(伸縮性方面)所帶來的不安全。Grattafiori接下來深入分析了微服務系統各個區域的安全影響,首先是在網絡安全方面。雖然大部分軟件系統在OSI模型7層(應用層)提供身份認證,這點常被爭論為只能提供有限的優勢,最好是通過在4/5層的TLS來實現,如果需要額外的網絡安全那么可以實現3層的IPSEC。許多組織使用Linux容器如Docker、rkt或LXC來包裝微服務,這兩者之間在安全方面有明顯的相似之處:
減少應用和容器的威脅模型攻擊樹很有必要。這包括通過利用防御性代碼和容器安全(如能力(capabilities)、用戶命名空間、只讀根文件目錄(rootfs)、不可變文件、mount標記(mount flags)和強制訪問控制(MAC))來限制由應用弱點所造成的危害。容器逃逸所造成的傷害可以被用戶命名空間限制,它可以讓容器中的root用戶對應到容器外的非root(uid-0)用戶。雖然Docker守護進程支持Docker 1.10用戶命名空間,但是默認是沒有開啟的。seccomp、kernel加固和MAC可以限制kernel和syscall的調用。受限的kernel或主機操作所造成的破壞能進一步被網絡加固、信任隔離、最低權限、最小訪問、日志和報警所限制。Grattafiori表示容器安全始于宿主機的操作系統,并極力推薦使用最小的Linux發行版如CoreOS、alpine Linux、Project Atomic或RancherOS。對操作員來說理解發行版如何升級、二進制包編譯、默認安全配置(如MAC)和默認kernel參數及sysctl配置也是非常重要的。容器鏡像也應該保持最小化,典型的如“FROM debian:jessie”或“FROM debian:wheezy”來創建鏡像。然而這可能還不夠小,就算在用apt-get安裝應用所需軟件之前,已有許多應用用不到的類庫、可執行文件和語言文件,這意味著更多的補丁、更多的磁盤空間、更多的攻擊面以及更多的攻擊方法。演講中演示了使用Docker和runC來構建最小容器的例子,以及幾個使用scratch容器來運行靜態編譯的二進制程序(如Golang構建的應用)。
Grattafiori強烈建議使用強制訪問控制(MAC),從操作系統角度應用最小訪問原則。MAC引用一種操作系統限制主體(特別是進程或線程)訪問或操作對象(如文件、TCP/UDP端口、共享內存段)的訪問控制。MAC作為一種Linux安全組件(LSM)是由AppArmor和SELinux(還推薦使用grsecurity,它內部包含了一套MAC解決方案,是一組強調安全增強的Linux kernel補丁)實現的。在Mac OSX上MAC通過TrustedBSD實現,微軟平臺有強制完整性控制(MIC)。默認的Docker AppArmor策略已經非常好了,但是鑒于這個策略是通用的,它一定包含了大量的文件、權限授權和復雜性。微服務更適合使用自定義安全描述文件的實踐。基于Docker的應用的自定義AppArmor的描述文件可以通過aa-genprof或Jessie Frazelle的Bane項目來生成。然而這需要分析目標應用(因為需要理解和使用這個應用)、常見錯誤如提供過多權限、通配符的使用和基于路徑的訪問控制列表(ACLs)。Grattafiori提醒應該避免使用AppArmor的拒絕列表(黑名單),因為它們只能提供有限的值。其他的易混淆的地方包括描述文件必須先被AppArmor加載,在描述文件中太過大量地運用抽象,這導致很難在生產環境中充分驗證所有的功能是有效的(雖然單元測試和回歸測試會有幫助)。雖然MAC很有價值,但是它還是無法避免kernel攻擊,不巧kernel攻擊的攻擊面是巨大的。“安全計算模式(seccomp)”是一個計算機安全設備,它在Linux kernel提供應用的沙箱機制(雖然seccomp本質上不是沙箱)。seccomp允許進程單向轉變進入“安全”態,在其中只能對已經打開的文件描述符使用exit、sigreturn、read、write這些系統調用。如果它嘗試其他的系統調用,kernel會使用SIGKILL終止進程。seccomp-bpf是seccomp的一個擴展,它使用伯克利封包過濾器允許使用一個配置的策略來過濾系統調用。
Docker引擎1.10后seccomp默認過濾器默認啟用,但是由于通用需求,內部啟用了304個系統調用(占所有系統調用大約75%)。最小權限原則建議微服務應用只應該擁有最小的系統調用集,相應地可以創建自定義描述文件。創建seccomp描述文件的方法包括strace/ltrace、kernel幫助(sysdig或systemtap)、auditd/auditctl或seccomp自己通過SECCOMP_RET_TRACE和PTRACE_O_TRACESECCOMP。在Docker中可以通過使用“--security-opt seccomp=
盡可能地使用應用特定的AppArmor或SELinux
盡可能地使用應用特定的seccomp白名單
加固宿主機系統
限制宿主機訪問權限
考慮使用網絡安全策略
使用不可變的容器
管理構建和運行時秘鑰(secrets)的問題可以通過臨時綁定mount來進行臨時秘鑰注入,再加載秘鑰到內存,然后unmount;或者理想地使用開源秘鑰管理工具如HashiCorp Vault或Square Keywhiz。秘鑰不應該通過環境變量或普通文件注入,因為這很容易導致秘鑰泄露到容器層、日志或錯誤報告中。最后的安全建議包括創建一個安全規格書、生成應用特定和全局的威脅模型、確保任何應用/服務的安全性、確保協調框架和相關服務發現的安全性。如果應用自身是脆弱的,那么容器和微服務也無能為力微服務的日志和可計量也很重要,日志應該被統一收集保存,并定期復審。如果把安全融入到軟件的開發周期,同時使用OWASP的ZAP、bdd-security、Brakeman或gauntlt等工具將核實的過程作為標準構建鏈的一環,這樣就更容易達成安全性目標了。Grattafiori在DockerCon的視頻“金色門票:Docker與高安全性的微服務”可以在YouTube的會議頻道找到,幻燈片可以在Docker的SlideShare賬號找到。Grattafiori也是NCC Group白皮書《理解及加固Linux容器(PDF)》的作者,這本書對每個正要詳細理解容器安全的人是必不可少的。查看英文原文:Docker and High Security Microservices: A Summary of Aaron Grattafiori's DockerCon 2016 Talk