一個正經(jīng)開發(fā)人員的安全意識
在任何的開發(fā)過程中，只要涉及到安全的問題，我們都需要牢記Shannon的這句話，雖然是與密碼學(xué)相關(guān)，但是也可以應(yīng)用到服務(wù)的安全，也就是說，我們應(yīng)該假定攻擊者最終將完全熟悉這個系統(tǒng)。
作為交付業(yè)務(wù)的開發(fā)人員來說，安全從來都是一個重要的話題，并且如果是從事健康、金融等相關(guān)領(lǐng)域，在北美的合規(guī)性上更是尤甚。除了從業(yè)務(wù)上對安全做的一些考慮，比如密碼強(qiáng)度，Multi-Factor Authentication(MFA)，更多的安全相關(guān)性可能對于一個正經(jīng)開發(fā)人員來說，可能很難面面俱到的考慮周全。在此，想借用一個和健康醫(yī)療相關(guān)的項(xiàng)目來對項(xiàng)目上所面臨的安全需求以及實(shí)踐進(jìn)行介紹。
背景
除了在業(yè)務(wù)上我們滿足用戶的安全需求，以及一些對常規(guī)的離散的安全了解(TLS，injection，DoS等)，我們沒有一個全局的系統(tǒng)的安全方面的考慮，再加上客戶也提出了一條條沒有組織沒有結(jié)構(gòu)的安全需求，在與客戶對話之前需要做大量的討論和研究。
對于計算機(jī)安全的定義來說，機(jī)密性、隱私性和完整性是三個關(guān)鍵目標(biāo)，如果從計算機(jī)安全模型來說，又包括硬件、軟件和通信等。對于這樣的分類和定義，如果我們能很好的做出威脅建模，那么結(jié)果可能是比較全面，但是問題又來了，在組內(nèi)大多數(shù)成員沒有威脅建模的經(jīng)驗(yàn)下，我們又很難做好一個威脅建模，這樣我們的結(jié)論也可能達(dá)不到我們想要的目標(biāo)。
那么這樣的話，從一個比較直觀并且概括的層面，能讓大家了解我們可能面對的保護(hù)和攻擊，可以在最基本的面上有個大概了解。
應(yīng)用 Application
認(rèn)證授權(quán)
- 所有需要認(rèn)證的請求會通過Gateway Ambassador，通過 Ambassador 提供的 Filter 和 FilterPolicy 來控制到認(rèn)證的接口上
- 不同接口會有不同的權(quán)限，這一層是在應(yīng)用層上實(shí)現(xiàn)
- 所有的用戶只能訪問屬于自己的 tenant 內(nèi)的資源，這也是在應(yīng)用層上實(shí)現(xiàn)
漏洞
對于這類攻擊其實(shí)我們經(jīng)常能聽到很多，比如 SQL injection, XSS 等等。這些攻擊在我們目前使用的通用框架中其實(shí)已經(jīng)幫助我們做了很好的保護(hù)，比如現(xiàn)在的 ORM 框架早已有 Parameterized queries 來防止 injection(前提是我們不要去拼接 query)，Spring Security 也提供了 CSP header 來保護(hù) XSS。
再比如CSRF，在目前我了解到的使用 Spring 的應(yīng)用中，都是disable的狀態(tài)。因?yàn)槠鋵?shí)如果我們是使用的JWT token來做認(rèn)證，而不是基于 cookie 來做認(rèn)證，那么我們也不用做更多來防止 CSRF。
日志
在我們的實(shí)施方案中，我們對日志進(jìn)行了不同的分類。一類是基本的服務(wù)應(yīng)用日志，主要便于生產(chǎn)環(huán)境的問題識別;另一類是審計日志，主要是記錄用戶的行為，包括哪個用戶從某個 IP 做了什么樣的請求操作，也可以防止用戶抵賴(Repudiation of Action)。
GCP 中的日志服務(wù)提供了 Log buckets，我們對以上兩類日志分別放到了不同的 bucket 里面，這樣也可以對于不同的日志設(shè)置不同的 retention period。
郵件
郵件的安全可能是我們?nèi)菀缀雎缘囊粋€問題，在郵件上設(shè)計到的安全有DMARC, SPF 和 DKIM。因?yàn)轫?xiàng)目上使用的是郵件服務(wù)Sendgrid，所以對于 DMARC, SPF 和 DKIM 是在郵件服務(wù)中實(shí)施的。在這里是想讓大家可以了解到即便是郵件功能，也不能忽略其安全的地位。
基礎(chǔ)設(shè)施 Infrastructure
網(wǎng)絡(luò)
如果實(shí)在信賴的 VPC 之內(nèi)，我們可以將 TLS 在 Load Balancer 就終止，任何在這個 VPC 內(nèi)的流量都是以解密之后傳輸?shù)?。但其?shí)在 cluster 內(nèi)服務(wù)和服務(wù)之間的安全也是需要保證的。
Firewall 的正確配置，開啟 DNSSEC，配置 Egress 到信任的外部服務(wù)，利用 WAF 來控制服務(wù)的訪問等等，這些都是在網(wǎng)絡(luò)上我們可以考慮的安全要素，因?yàn)榫W(wǎng)絡(luò)安全是一個比較大的另一個話題，并且我知識也有限，就不展開講更多。
Security Posture Monitoring
我們需要知道我們服務(wù)的資產(chǎn)，并且哪些資產(chǎn)在業(yè)務(wù)上有重要意義，我們還需要知道我們做了哪些安全措施來保護(hù)我們的資產(chǎn)。
部署在 GCP 之上的資產(chǎn)，GCP 的 Security Command Center 可以幫助我們了解和修補(bǔ) GCP 的安全和風(fēng)險。其提供了不同等級的服務(wù)，詳細(xì)的可以參考 Security Command Center。
密碼秘鑰輪訓(xùn)
定期或者主動去輪換現(xiàn)有的密碼。
GCP 的 Secret Manager 配合 pubsub 和 CloudFunction 可以設(shè)置 rotation period 來幫助我們定期更改密碼，但是我們的密碼有些是集成了第三方系統(tǒng)的 api key 或者是 private key，這樣不太方便使用 Secret Manager 提供的 rotation 功能。對于這樣的第三方密碼，還是需要運(yùn)維人員手動在第三方服務(wù)中更新密碼，或者使用其提供的 API 或者 Script 來重新生成密碼，然后用 Terraform 控制 GCP Secret Manager 來幫助我們管理密碼。
但這里有個問題是密碼是不能明文存儲在對應(yīng)的 Terraform repo 中，所以目前我們在項(xiàng)目中只是將密碼文件加密后再上傳，對于 Terraform 來更新密碼還是在本地執(zhí)行 terraform apply，還沒有一個比較有效的方式。
安全檢查 / 測試 Security Check / Testing
靜態(tài)掃描
我們可以使用很多靜態(tài)掃描工具幫助我們提高代碼質(zhì)量，也可以幫助我們在代碼層面上泄露安全風(fēng)險。
這些工具會集成到我們的 CI 之上，比如 gitleaks 來幫助我們檢查是否有硬編碼的密碼、私鑰等信息，OWASP Dependency Check 來檢查 vulnerability。
動態(tài)掃描
除了靜態(tài)掃描外，動態(tài)掃描可以幫助我們檢查出應(yīng)用服務(wù)上的安全風(fēng)險，比如之前提到的 XSS，injection 等等，都可以利用周期性的動態(tài)掃描來規(guī)避風(fēng)險。
雖然不能完全依賴這類的掃描工具來保護(hù)我們的應(yīng)用服務(wù)，但是這在一定程度上可以緩解風(fēng)險的可能性。
Mobile
Run Application Self Protection RASP
對于大多數(shù)應(yīng)用的外圍保護(hù)來說，比如防火墻，IDS，這些保護(hù)都只是對運(yùn)行環(huán)境的保護(hù)，但是設(shè)計到應(yīng)用本身，這樣的保護(hù)不會具有針對性，也就是說突破了這些保護(hù)的限制，一樣能對應(yīng)用造成威脅。
那么移動端App，不像服務(wù)端的應(yīng)用部署在一個幾乎完全受我們控制的環(huán)境中，它可能運(yùn)行在一個已經(jīng)過時很久，或者不太安全的版本的 OS 上。這時候需要一個能提供自我保護(hù)的應(yīng)用。
在綠碼項(xiàng)目中，我們使用的是客戶合作的Promon SHIELD，其提供了比如 root detection, code obfuscation, code injection protection 和 screen reader protection 等等可配置的保護(hù)。
RASP 更多的是對應(yīng)用本身提供保護(hù)，所以是其實(shí)現(xiàn)方式我理解無非是在應(yīng)用內(nèi)，比如針對應(yīng)用特定場景的保護(hù)，或者是在應(yīng)用外有一層保護(hù)膜，比如使用 Promon SHIELD 就是一層 wrapper，如下：
App Attestation
就如最開始提到的，我們在設(shè)計系統(tǒng)時就要考慮到攻擊者最終會完全熟悉我們的系統(tǒng)。那么設(shè)想攻擊者有了這些知識后，能不能做出一個和我們完全一模一樣的App。
如果在這個時候我們怎樣去防止這種類似釣魚的攻擊發(fā)生。對于 iOS 和 Android 都有方式去做 attestation。
在我們項(xiàng)目上，對于Android 采用的是 SafetyNet Attestation，而iOS是利用通知推送的機(jī)制的形式。雖然本身 Android 也有通知推送機(jī)制，但是其推送地址和這個合法的 App 之間的關(guān)系僅僅是 package name，然而iOS的推送機(jī)制是基于 push certificate，所以對于 Android 使用的是其提供的 SafetyNet 更為可靠。
以下是簡單的流程圖，感興趣的同事可以進(jìn)一步深究。
結(jié)語
在這里只是簡單的從一個普通正經(jīng)開發(fā)者的安全角度出發(fā)，列舉了一些其他項(xiàng)目可能可以參考的安全實(shí)踐。但是安全遠(yuǎn)遠(yuǎn)不止于此，并且涉及到的知識也是非常之廣，以上提到的任何一點(diǎn)都可以有更深的討論。
【本文是51CTO專欄作者“ThoughtWorks”的原創(chuàng)稿件，微信公眾號：思特沃克，轉(zhuǎn)載請聯(lián)系原作者】
