攻防視角下,初創企業安全實戰經驗分享

語言: CN / TW / HK

前言

安全,長期以來是企業最容易忽視的關鍵點之一。安全問題發生前,存在感低;然而發生以後,損失卻已經難以挽回。

聲網開發者創業講堂 • 第四期丨創業團隊如何保障產品業務的安全合規? 」活動特別邀請白山雲安全研發總監胡金湧,以「攻防視角下,初創企業安全實戰經驗分享」為題進行分享。

胡金湧擁有十年雲安全產品研發經驗,主持研發了 SCDN、抗 DDoS、雲 WAF、SoC、零信任等安全產品,在攻防領域有豐富的經驗。

本文從攻防的視角分享業務上線後可能遇到的常見攻擊,並分享安全研發規範、上線前的安全巡檢、上線後的安全防護等實戰經驗並給出一些安全建議。

本文基於胡金湧分享內容二次整理。

01 一些安全建設的誤區

1、幾個典型的安全誤區

■圖 1

首先給大家介紹一下安全建設常見的誤區,如圖 1 所示。

第一個誤區是:大家普遍認為初創公司受到攻擊的概率比較小,而安全總歸是要花錢的,因此安全建設是不是能省就省,先放一邊,保證專案上線。但其實黑客的攻擊是沒有差別的,攻擊目標可能是大企業,也可能是小企業,所以我覺得初創企業一剛開始還是要有起碼的安全建設意識。

第二個誤區是:很多人認為只要安裝了防火牆,並且買了安全服務,就可以高枕無憂了。這其實也是不對的,不管是防火牆,還是 WAF,或者其他的安全產品,其功能都是相對有限的,可能只針對一個點進行防護,但是安全建設是一個縱深範圍非常深非常廣的領域,單獨依賴一兩個安全產品,解決所有的安全問題可能也不是很現實。

第三個誤區是:有企業認為行業沒有損失就代表很安全,這其實也是不對的,可能有些攻擊已經發生了,但我們都不知道,比如資料洩露、拖庫等,這些安全隱患可能我們都沒有感知到。

2、網路安全問題決定未來發展的天花板

其實因為不重視網路安全問題,很多知名企業受到重創。大家可能比較熟悉的 zoom 在美國上市,市值曾經也很高,但是曾經因為一些安全問題,導致股價下跌得比較厲害。Clubhouse 也是美國的一家公司,它在起初的發展是非常迅速的,但是也因為一些網路安全問題,導致後來的衰落。微盟也是因為內部的安全建設沒有做好而出現了問題。

這可能不光是內部管理的規範問題,也是缺乏安全意識的問題。從某種程度上來說,網路安全問題可能就決定了未來發展的天花板。

3、安全建設的重要性和必要性

網路安全事件造成的影響是比較大的,特別是最近幾年,國家對網路安全越來越重視,也釋出了一系列的安全法規,明確了企業從業者的法律上責任,強調了安全建設的重要性跟必要性。很多公司重業務輕安全,可能起初沒有問題,感覺安全好像無關緊要,當出現問題的時候,又感覺安全建設也沒起到什麼作用,但是這樣的後果往往是比較慘重的。

所以初創企業一開始就要重視安全建設,雖然說安全建設是需要花錢的,但是起碼可以先做一些高優先順序的安全建設,建立安全基線。另外,《資料安全法》《個人資訊保護法》《網路安全法》等政策法規,也明確了網路經營者要承擔的責任,初創企業也是不例外的。

4、 常見的安全威脅

我今天主要是從兩方面介紹常見的安全威脅,第一個是外部安全威脅,第二個就是內部安全威脅。外部安全威脅比較常見,比如 DDoS、CC 等,這些攻擊其實在整個產業鏈中已經非常成熟了,從金主到接單的平臺,整個鏈路是非常完整的,而且攻擊成本非常低。因為現在網路越來越發達,很多裝置的漏洞非常多,特別是物聯網裝置等,針對它們的攻擊打法是比較多的,攻擊面也比較廣,破壞力非常強。但是防護就沒那麼容易,它存在嚴重的攻防不對等問題。

■圖 2

圖 2 所示為一個網路平臺,只需 100 塊錢就可以打一個攻擊,這類攻擊的成本很低,是我們面臨的常見威脅。Web 安全也是一種常見的安全威脅,比如搜尋注入、XSS、遠端命令執行等。我從一份 2017 年到 2021 年的知名報告中摘取了一些資料,如圖 3 所示,可以看到整個攻擊型別的變化和攻擊的趨勢。

■圖 3

第三種常見威脅就是 API 安全,其實現在基本上沒有什麼業務是不用 API 的,無論是 API 的數量,還是總體呼叫 API 的數量,都是越來越多的。所以 API 也會有很多的安全問題,比如水平越權、敏感資料暴露、程式碼漏洞、鑑權、配置錯誤以及業務邏輯缺陷等。第四種業務安全,比如我們在業務初期做活動推廣的時候,就面臨著薅羊毛的威脅,此外還有資料洩露、App 安全、主機安全、資訊劫持、爬蟲等。

02 業務防護方法和最佳實踐

1、初創公司的安全建設

那麼面對這些安全威脅,我們應該怎樣防範呢?初創企業的安全建設與大公司的安全建設是非常不一樣的,初創企業的各方面資源比較緊缺,不可能進行大規模的安全建設,但是仍要符合安全基線的要求。我主要從三個方向進行介紹。

首先,在進行開發的時候,我們要具備非常強的安全意識,對所有的外部輸入都要做嚴格的校驗,並且開發必須要規範,比如程式碼規範、釋出規範、code review 規範。然後,在開發測試之後要做上線前的準備,此時要做安全防護的規劃,針對工具型別進行相對應的安全規劃。

不同的這個業務型別所面的攻擊型別可能是不一樣的,如果是遊戲能力業務,那麼遭遇 CC、DDoS 攻擊的概率很高;如果是 App 業務,那麼被逆向、被破解、被薅羊毛的概率就比較高。上線之前還要做安全巡檢,比如是否存在弱密碼、金鑰有沒有放到程式碼中等。最後,上線之後需要制定防護方案以及進行安全運營。

2、業務系統開發生命週期

從開發角度來說,整個的業務的開發週期從需求分析,然後到方案設計,再到開發、測試、上線、運營,其實每個環節都會涉及相應的安全的規範,具體如圖 4 所示。

■圖 4

比如在做需求分析階段,可能要把安全因素考慮進來,做相關的需求分析調研;在方案設計階段,要做相應的安全的設計,比如針對業務型別可能面臨的攻擊型別建模,對攻擊面進行分析;開發階段可能更重要的是開發規範;測試階段可能要做相關的基安全基線的測試;上線階段要做的是相關的安全檢查、配置,以及相應的 checklist;上線運營階段要對持續關注最新的安全漏洞,並作出相關漏洞的應對,這就是整個的這個業務開發週期。

■圖 5

我們在開發階段就要做很多的開發規範,如圖 5 所示,資料庫的訪問規範、相關的檔案操作,相關的程式碼規範、緩衝區、異常處理等都是我們要關注的。

圖 6 所示為 CI/CD 的流程,我們在整個流程中都要引入相關的安全機制。

■圖 6

3、 防護方法和最佳實踐

我結合實踐梳理了安全防護的方法,主要包括程式程式碼安全、程式碼倉庫安全、密碼安全、通訊安全、日誌安全、元件使用安全、App 安全、安全測試等。因為安全領域涉及範圍非常廣,所以這裡面只介紹對初創企業來說比較容易落地的幾點。

1) 程式程式碼安全

程式程式碼安全是一個非常重要的環節,如圖 8 所示,針對常見的 SQL 注入、XSS 漏洞、使用者輸入是否合法,我們都要做相應的校驗,有時我們還要對輸入長度、輸入內容做轉義等處理。另外,針對資料庫相應的規範包括永遠使用最低的許可權操作資料庫,機密資訊存放不能放在程式程式碼中;針對特殊的場景也要做相關的處理、合理設定同源策略等都是我們在開發的時候要考慮到的。

2) 程式碼倉庫安全

對初創企業來說,可能各方面的流程制度不是很規範,會將程式碼和工作文件傳到公網上,比如 GitHub、GitLab,這就沒有遵循很好的開源規範。另外,將使用者名稱、密碼、token 等敏感資訊直接寫在程式碼中非常容易造成資訊洩露,也是不好的習慣。

3) 密碼安全

密碼安全是一個非常普遍的問題,程式面對暴力破解也要能做相應的防範,比如可以通過驗證碼或者雙因子認證等機制來解決暴力破解問題。而且在整個的傳輸過程中要做加密鏈路,不允許使用弱密碼。如果在開發過程中沒有注意到這些問題,在上線之後可能會導致很大的風險。

4) 通訊安全

剛才也提到,所有的資料傳輸應該儘可能做到端到端的加密,尤其是網際網路外部資料傳輸一定要做 https 的加密傳輸,這也是一個最基礎的安全保障。推薦大家一定要做這樣的安全措施。

5) 日誌安全

系統相關的所有訪問都要保留痕跡,包括操作時間,操作人、IP、URL、訪問內容等,我們都要做盡可能詳細的記錄。當然,其中可能也會考慮到企業自己的資料安全,有些資訊是不記錄的,這要滿足相關的政策法規。記錄資料的目的就是方便故障分析、安全事件的處理,甚至安全取證等。現在基本上對日誌的要求是最低儲存六個月,尤其是一些重要的日誌資料。

6) 元件安全

在開發的過程中會大量使用第三方的各種開源元件。前段時間 Log4j 的漏洞影響方非常廣,因為它是一個非常基礎的日誌元件,很多應用都會用到這個元件,Redis、MySQL 技術元件的使用面是非常廣的,使用這些技術元件時要注意哪些內容呢?

第一個就是重點關注公網的埠暴露,非必要不要暴露在公網上,保持最低可見的範圍。第二個就是不要使用預設的埠,比如 Redis 6379、MySQL 3306,應儘可能使用非標的埠來降低攻擊的風險(這裡只能是降低,但是不可能完全避免,但這是一個很有效的舉措)。對於內部的應用,比如 ES、grafana 等,我們也要做相應的許可權控制。如果是做認證,那麼認證密碼也要滿足一定的條件,儘可能不要使用弱密碼。

7) App 安全

很多初創企業都有自己的 App,對於它們來說,重要的金鑰、token 等資訊不能硬編碼到 App 中。這樣很容易被破解。同時,儘可能做加固,其實現在有很多商用的解決方案可以使用。App 在採集使用者資料的時候也要保持最低的許可權,而且要做好資料隱私,這部分其實也有很多相關的政策法規,國家現在對此的管控也非常嚴格。我們的 App 中還會大量使用第三方的 SDK,這些第三方 SDK 可能對我們不那麼透明,因此也要關注第三方 SDK 的安全性。

8) 安全測試

在整個安全開發過程中,我們還要做好安全測試。首先是威脅建模,基於專案或者產品面臨的威脅型別,根據不同的業務,要做好威脅的建模,並梳理攻擊面來針對性地引入相關的安全測試。

我們剛才提到整個開發過程中要注意的規範,那麼上線之前我們應該做哪些事情呢?如圖 8 所示,HTTPS 證書是最低的要求,但在使用 HTTPS 證書時我們要注意監控證書的有效期,證書是有有效期的,特別是這種免費的證書,有效期可能只有幾個月。一旦證書過期了,業務可能就會中斷。

此外,我們還要做安全檢測,檢查程式漏洞、Web 應用漏洞等。當然安全檢測的覆蓋範疇比較廣,有很多的商用方案,但是可能會比較貴。其實我們也可以使用一些免費開源的漏掃工具,通過這些工具也可以幫助我們掃描一些比較明顯的問題。其實我們也可以在內部使用掃描器來做定期的掃描,儘早發現以避免攻擊造成更大的破壞。

4、上線前的關注點

上線之前我們還要做好安全防護規劃,這可能要跟專案經理或者產品 owner 做好溝通,確定安全防護方案。做安全防護是要花時間的,要確認是否會對整個專案計劃和里程碑造成延期,這都是需要跟相關的管理方提前做好溝通的。我們還要明確安全防護涉及的安全和隱私質量的最低可接收級別。這都是我們上線之前需要做的準備工作。

5、推薦使用雲防護

防護安全威脅要做的事情是非常多的,對初創企業來說,可能沒有很多的資源支援,也沒有專業的安全人員做相應的實施,所以比較可行的方法就是使用雲防護,那使用雲防護有什麼好處呢?

首先雲防護用起來比較方便,基本上是即開即用的,只要在平臺上買好安全服務,做好相應的配置,然後通過 DNS 引流的方式可以把流量直接接過來就可以。而且雲防護一般是按需付費的,所以對初創的企業來說成本是非常容易控制的。

此外,除了做防護之外,雲防護普遍還能提供加速,比如 WAF、SCDN,除了防護之外,還提供靜態加速,降低迴源頻寬,提升訪問速度。雲防護的資源可以彈性擴充套件,這對初創公司也是非常友好的。

6、如何進行雲防護的產品選型

但是在使用雲防護的時候也要注意很多問題,其實我們的很多客戶在使用的過程中體驗並不好,這不是說我們的產品不好,而是沒有用對,怎麼樣做安全產品的選型呢?其實現在各種各樣的雲防護產品非常多,做產品選型可能要注意以下幾個方面。

第一個是產品能力,這是我們最看重的,要具備針對常見攻擊的防控能力,還要看節點數量,因為節點數量越多,就能滿足就近接入,從而有更好的網路速度。產品價格也是初創企業比較敏感的,要儘可能選價格比較彈性的產品。

第二個就是防護設定,安全產品尤其是雲防護,雖然使用非常靈活,但是如果用不好,防護效果也不會好。所以我們在使用雲防護的時候要設定好相關的策略,策略跟業務是強相關的,API 業務跟網站業務的訪問策略是完全不一樣的,很多 API 可能沒有辦法做人機校驗,瀏覽器可能通過輸入驗證碼的方式就可以。我們還要做業務特徵的學習,雲防護的能力是比較強的,但是如果事先根據業務特徵的流量模型來做分析,可能防護效果更好。

而且在業務接入的初期,推薦先使用觀察模式,這樣可能它會記錄下認為的攻擊行為,但是這並不會阻斷業務,防護模式就會相對比較嚴格。所以在開始上線的初期,我們還是要做好業務的觀察,從而避免誤防。然後在攻擊的時候,我們也可以做相關的告警,這樣我們就可以第一時間接收到攻擊的發生。我們還要了解雲廠商在極端攻擊下的處置措施,雖然雲廠商的防護能力很強,但畢竟也不是無限的,如果超出了防護能力會如何處理,我們要事先了解清楚。我們使用這個防護的時候還要做一些安全預案,做好安全的底線。

第三個是就是安全服務,業務面對攻擊時需要雲廠商及時做出反饋跟響應。現在大部分雲廠商是採用工單的方式,我們也需要去了解具體的響應速度,有的是人工服務,人工服務也是有時間限制的,這都需要做一些瞭解。

第四個就是源站保護。如果我們使用雲防護,但是源站暴露了,那麼黑客完全可以繞過雲防,直接攻擊源站,所以這是在使用雲防護時尤其要注意的一點,要做好安全巡檢,確保源站不暴露。同時在防護過程中,我們要回源,做黑名單設定,只允許防護節點,這樣可以最大程度地保證安全性。我們的雲服務比較彈性,還要注意避免忽略服務到期,導致失去防護。這是使用雲防護過程中的一些小細節。

7、雲防護 tips:我的源 IP 是如何暴露的?

剛才我們提到了源站,其實很多初創企業因為沒有太多的經驗,導致雖然接入了雲防護,但實際上並沒有取到防護的效果,因為 IP 暴露了,黑客已經獲取了 IP,即使更換 IP 他也能找到。實際上有非常多的途徑能暴露 IP,比如過去可能沒有接入雲防護,後面雖然接入了,但是過去的 DNS 記錄是直接指向源站的,而很多平臺可以查到歷史 DNS 解析記錄。

所以如果 DNS 解析記錄直接指向源站,就有暴露的風險。

第二種是子域名,這個也很普遍,現在有很多的子域名,包括靜態域名、動態域名、API 域名可能是獨立的域名,可能接入的是動態域名或者 API 域名,而靜態域名可能還是指向源站的,這可能也會導致源站洩漏也有被攻擊的風險。

第三種是有些網站做得不是很好,能直接展示或介面展示源站資訊。第四種是使用的安全產品可能回源,這也會也會暴露 IP。

另外,郵箱 MX 記錄、郵件服務、內部洩露、網路空間的搜尋引擎也會導致源 IP 暴露,現在網路空間搜尋引擎能力是其實非常強的,很多的業務資產都能檢索到,可以通過關聯分析找到源站。其實各種方法也是非常多的,所以我們在做業務開發或者上線的時候一定要多加去注意,避免源站被暴露。因為一旦源站暴露,雲防護基本上就失去作用了。

8、上線後的關注點

剛才提到上線之前的開發和業務規劃,那麼上線之後我們要關注哪些指標呢?首先就是關注防護情況,如果發生攻擊,我們要做資料分析。然後要進行安全巡檢,有條件的話還可以做攻擊應急和攻擊演練。最後就是要關注安全圈,剛才提到很多軟體專案會大量使用第三方元件,如果關注安全圈的資訊,就可以及時瞭解安全漏洞情況,進而做及時的響應,修復漏洞。

03 初創企業的安全規範建設

前面介紹了面臨外部威脅的防護,其實企業內部自身的安全建設也是非常重要的,接下來分享一下初創企業應該從哪些重點方向來建立安全基線。

1、初創公司的安全規範建設

■圖 7

初創公司的安全規範建設包括圖 7 所示的幾個方面。第一個是要做好安全培訓,安全培訓要從剛開始就在整個公司進行,要讓大家建立安全意識,形成安全文化,具體來說包括行為安全、賬密安全、安全意識和開發規範。

第二個是流程制度。流程制度可能跟安全沒有直接的關係,但是也對安全有一定的影響。比如變更管理、許可權管控、網路管理、裝置管理、安全審計。第三個是資料安全,主要包括個人隱私、資料備份、資料脫敏。

2、佈局零信任

傳統的安全其實還是存在很多的問題,隨著企業的轉型,現在很難適應現階段新的發展趨勢。特別是遠端辦公,所以零信任很可能成為未來的新趨勢。如果初創企業從一開始就佈局零信任,基於零信任的最佳實踐構建安全體系,其實是一件很好的事情。那麼零信任的理念是什麼呢?它的理念很簡單,如圖 8 所示,首先是身份的認證和授權。

■圖 8

其次,對所有資源訪問的許可權是動態的,要基於整體的上下文來做這樣相關的動態許可權控制。然後在分配訪問許可權的時候,遵循最低許可權的原則,並且對於重要的應用還可以做多因素的身份認證。這是零信任的幾個重要的理念。所以如果我們一開始就能佈局零信任,比如建立一個統一的身份管理、統一的許可權管理、統一的應用管控,遵循零信任的理念進行安全建設,我覺得是一個很好的開始。

佈局零信任其實也有幾個技巧,如圖 10 所示。第一個是我們要以層為單位做整體性思考,因為零信任涉及的範圍比較廣,所以我們要遵循最佳實踐,按照分層的方式做整體的考量。第二個是儘可能使用多因素認證,然後是做單點登入,就是前面提到的一個企業中可能有很多平臺和各種各樣的系統,如果能打通單點登入,就可以簡化使用。

另外,因為零信任的原則是不信任任何人,不管員工是內部還是外部的,都要做相關的許可權控制和身份認證,所以是沒有內外部區分的。同時,實施零信任需要全公司自上而下的整個推動,所以高層也需要配合,全員參與過渡。

最後零信任中其實有一些重要的細節,傳統安全過渡到零信任附加了很多的內容,整個防護理念完全不一樣,在這個過程中要儘可能避免對工作效率的影響,實現平滑過渡。所以如果有條件的話,建議初創公司從一開始就去做零信任設計,這樣可以解決一些很長遠的問題。

關於「聲網開發者創業講堂」

當下是一個人人可創業的時代,對技術人來說,更是一個創業友好的時代。如果你懂技術,會比其他人更容易將自己的創業想法和夢想付諸實踐。

但創業意味著要從 0 到 1,意味著要持續的創造和創新,意味著創業者和團隊需要不斷的成長和突破。只有這樣才能打造出滿足市場需求的、有價值的產品,逐漸形成企業的優勢和壁壘,成長為一家成熟的企業。

聲網關注有創新能力、開發能力和創業意向的開發者,並希望為開發者提供相應的支援和服務 。為此,我們推出了「聲網開發者創業講堂」系列創業分享,以便為大家在成長和創業路上提供更多的幫助。