一、安全漏洞評估
1、評估方式
自動化掃描：系統層漏洞大部分情況下使用自動化掃描
手工評估：耗時、不全面、技術要求高
2、評估流程
二、安全配置評估
1、安全配置評估分類
| 評估 | 說明 |
|---|---|
| 基礎安全配置評估 | 在了解現狀和基本需求的情況下，定義業務系統的基礎安全配置要求，配置要求内容和具體産品相關 |
| 業務安全配置評估 | 辨析不同業務系統的安全需求，在已形成的基礎安全配置評估上進行增加，同時協調不同安全裝置上的政策，以期望形成符合業務特點的安全方案 |
2、安全配置評估規範分類
| 評估 | 說明 |
|---|---|
| 賬号管理 | 賬号配置設定管理：避免共享賬号。多餘賬号鎖定：鎖定無關賬号遠端登入等 |
| 密碼配置 | 密碼複雜度要求；密碼生存期要求等 |
| 認證授權 | 使用者預設權限控制；關鍵目錄權限控制等 |
| 日志配置 | 登入日志記錄；系統事件記錄等 |
| 裝置管理 | SSH安全登入；更新檔、版本最低要求等 |
| 其他安全 | 登入逾時退出；共享權限要求等 |
三、安全測試
1、部分專業術語
黑盒測試：
在客戶授權的情況下，模拟黑客攻擊的方法和思維方式，來評估計算機網絡系統可能存在的風險。黑盒測試不知道源代碼。
白盒測試：
相對于黑盒測試，白盒測試基本是從内部發起。白盒測試知道源代碼。
滲透測試：
出于保護系統的目的，更全面地找出伺服器的安全隐患。
入侵：
不擇手段地（甚至是具有破壞性的）拿到系統權限。
IOT安全：
物聯網（Internet of things（IoT））安全。
APT安全：
進階持續性威脅(Advanced Persistent Threat，APT)，威脅着企業的資料安全。APT是黑客以竊取核心資料為目的，針對客戶所發動的網絡攻擊和侵襲行為，是一種蓄謀已久的“惡意商業間諜威脅”。
Payload：
是包含在你用于一次漏洞利用中的ShellCode中的主要功能代碼。
Shellcode：
可提權代碼。對于一個漏洞來說，ShellCode就是一個用于某個漏洞的二進制代碼架構，有了這個架構你可以在這個ShellCode中包含你需要的Payload來做一些事。
Exp：
漏洞利用，一般是個demo程式。即示例程式。
Poc：
(Proof of Concept)漏洞證明。一般就是個用來證明和複現漏洞的樣本。
vul：
(Vulnerability) 漏洞。
2、滲透測試流程
| 步驟 | 說明 |
|---|---|
| 明确目标 | 确定範圍；确定規則；确定需求。 |
| 資訊收集 | 基礎資訊；系統資訊；應用資訊；版本資訊；服務資訊；人員資訊；防護資訊。 |
| 漏洞探測 | 系統漏洞；WebServer漏洞；Web應用漏洞；其他端口服務漏洞；通信安全。 |
| 明确目标 | 确定範圍；确定規則；确定需求。 |
| 資訊分析 | 精準打擊；繞過防禦機制；定制攻擊路徑；繞過監測機制；攻擊代碼。 |
| 擷取所需 | 實施攻擊；擷取内部資訊；進一步滲透；持續性存在；清理痕迹。 |
| 資訊整理 | 整理滲透工具；整理收集資訊；整理漏洞資訊。 |
| 形成報告 | 按需整理；補充介紹；修補建議。 |
四、HTML5介紹
1、HTML5解釋
狹義解釋：HTML5簡稱H5，是W3C制定的标準，在相容原有html4.01和xhtml1.0标準的基礎上，增加和修改了一些元素。此時HTML5 ≈ HTML+CSS3+JavaScript+API
廣義解釋：HTML5是HTML、CSS和JavaScript在内的一套技術組合，其目标是減少浏覽器對于插件的依賴，提供豐富的RIA（富用戶端）應用。
HTML5是标準而非技術。通過其所支援的内容将網際網路語義化，能更好地被人和機器閱讀。
2、HTML5的優勢
跨平台：跨越iOS、Android、PC等多個平台，基于浏覽器或浏覽器引擎，将網頁應用轉換成移動或桌面應用。
減少插件依賴：可以不使用第三方插件檢視視訊、音頻、圖像等内容。
HTML5安全性：Iframe沙箱、内容安全政策（CSP）、跨域資源共享（CORS）。
3、HTML5應用場景
Web APP：指采用Html5語言寫出的App，不需要下載下傳安裝，以浏覽器為入口。
Hybrid APP：指半原生半Web的混合類App，需要下載下傳安裝，具有Native和H5的優點，通過WebView展示豐富多彩的頁面。
4、HTML5安全測試
正常移動用戶端安全測試：用戶端程式安全、通信安全、服務端安全。
正常Web應用安全測試：各種web漏洞。
本地存儲測試：html5中的Web Storage包括了兩種存儲方式：sessionStorage和localStorage。
sessionStorage用于本地存儲一個會話（session）中的資料，這些資料隻有在同一個會話中的頁面才能通路并且當會話結束後資料也随之銷毀。是以sessionStorage不是一種持久化的本地存儲，僅僅是會話級别的存儲。該項不用測試。
localStorage用于持久化的本地存儲，除非主動删除資料，否則資料永遠不會過期。該項重點測試。
五、堡壘機
1、堡壘機介紹
堡壘機是一套部署在資料中心，能夠統一管理從業人員和網絡資源，能夠進行集中身份認證、集中管控資源和權限配置設定、智能運維托管資産、操作全程審計的運維安全管了解決方案。堡壘機是防火牆體系的基本形态。
堡壘機的應用場景：VPN關聯；雲安全APP關聯；征信系統審計。
2、使用堡壘機将解決的問題
運維賬号混用，粗放式權限管理
1、多個使用者使用同一個賬号，難定責。
2、一個使用者使用多個賬号，工作效率低，工作複雜度增加。
3、缺少統一的權限管理平台，無法基于最小權限配置設定原則的使用者權限管理
審計日志粒度粗，易丢失，難定位
1、各系統自身審計日志分散、内容深淺不一，無法根據業務要求制定統一審計政策，容易被系統管理者删除，導緻難以及時發現違規操作行為和追查驗證。
2、旁路資料分析審計無法對已加密的應用層資料（SSH、SFTP等）進行細粒度分析，無法對圖形運維操作（RDP，VNC等）過程進行完整還原，無法做到實時管控。
3、主機探針審計方式，占用系統資源，對系統穩定性埋下隐患。不能對網絡方式運維操作過程完整還原展示，事後審計能力不足。
面臨法規遵從的壓力
政府、金融、營運商等陸續釋出資訊系統管理規範和要求，均要求采取資訊系統風險内控與審計，但其自身卻沒有有效的技術手段。
運維工作繁重枯燥
資料備份工作量大、裝置賬号改密量多等問題常常導緻運維操作失誤，效率低等現象，這嚴重影響企業的經濟運作效能，并對企業聲譽造成重大影響。
虛拟雲技術蓬勃發展
雲環境下的信任問題日趨突出，多租戶和使用者下身份認證、權限控制，雲主機系統運維和安全審計等種種問題都困擾着雲服務廠商，也制約了雲服務業務的發展。
3、堡壘機産品安全測試
大部分堡壘機登入均采用多因素認證，如令牌、短信驗證碼等。
按照正常Web應用安全測試方法測試，重點關注以下測試項：
1.賬号枚舉
2.多因素認證繞過
3.通信加密測試：明文傳輸，如使用HTTP協定傳輸，且關鍵資訊未本地加密
4.越權測試：堡壘機有不同角色的賬号，存在功能越權的漏洞
4、堡壘機環境下的web應用測試
測試堡壘機強控的系統時，一般是登入堡壘機後，遠端登入到一台主控端，在主控端上通路目标測試站點，測試工具由客戶上傳到主控端上。
結構圖如下：
六、虛拟化
1、虛拟化介紹
虛拟化：是指通過虛拟化技術将一台計算機虛拟為多台邏輯計算機。每個邏輯計算機可運作不同的作業系統，并且應用程式都可以在互相獨立的空間内運作而互不影響，進而顯着提高計算機的工作效率。
虛拟化分類：作業系統虛拟化、桌面虛拟化、應用程式虛拟化、存儲/網絡虛拟化。
虛拟化應用場景：辦公桌面。即瘦用戶端不存儲工作資料，資料在虛拟用戶端(雲)上。
2、虛拟桌面産品安全測試
按照正常Web應用安全測試方法測試，重點關注以下測試項：
登入功能測試：賬号枚舉、暴力破解、驗證碼繞過，如驗證碼未失效、驗證碼可置空等、二次認證繞過，如發送短信驗證碼手機号篡改、繞過校驗等。
通信加密測試：明文傳輸，如使用HTTP協定傳輸，且關鍵資訊未本地加密。
越權測試：與正常測試方法相同，重點關注功能菜單越權。
3、虛拟環境下的安全測試
1、測試目标部署在虛拟機中：該場景的安全測試和正常測試相同，可直接通路并測試目标。
2、在虛拟機中通路測試目标：遠端登入虛拟機，将測試工具拷貝至虛拟機中，在虛拟機中實施安全測試。
七、雲環境
1、雲環境簡介
雲計算是一種按使用量付費的模式，這種模式提供可用的、便捷的、按需的網絡通路，進入可配置的計算資源共享池(資源包括網絡，伺服器，存儲，應用軟體，服務)，這些資源能夠被快速提供，隻需投入很少的管理工作，或與服務供應商進行很少的互動。
雲環境下的安全測試：和傳統服務測試一樣，多了沙箱等之類的雲環境獨有的安全方案。
2、雲環境分類
1、基礎設施即服務IaaS(Infrastructure-as-a-Service)
就是将CPU、存儲、網絡等硬體資源能力雲化，作為服務提供給消費者。
2、平台即服務PaaS(Platform-as-a-Service)
就是運作軟體的軟體能力和開發軟體的軟體能力雲化，作為服務提供給消費者，如阿裡和騰訊的開發平台等。
3、軟體即服務SaaS(Platform-as-a-Service)
将應用軟體的能力雲化，作為服務提供給消費者，如淘寶、京東等。
3、雲環境的優勢
1、雲平台能夠自行提供開發及測試環境，是以我們可以在無需對資料中心硬體及軟體進行變動的前提下開始進行應用程式建立工作。
2、能夠快速将應用程式投入生産層面并根據需求對應用進行擴充。
3、能夠幫助我們與其它開發者、架構師以及設計師順利協作，共同處理應用程式建立過程中的各項任務。
4、雲環境應用場景
電子郵箱：雲計算将電子郵件資源儲存在雲端，使用者可以在任何地點、任何裝置和任何時間通路自己的郵件，企業可以使用雲技術讓郵箱服務系統變得更加穩固。
資料存儲：使用者可以将所需要的檔案、資料存儲在網際網路上的某個地方，以便随時随地通路。雲服務商将會為使用者提供廣泛的産品選擇和獨有的安全保障。
商務合作：共享式的商務合作模式，使得企業可以無視消耗大量時間和金錢的系統裝置和軟體，隻需接入雲端的應用，便可以邀請夥伴展開相應業務。
虛拟辦公：使用虛拟辦公應用的主要好處是不會增加裝置負載，它将企業的關注點集中在公司業務上，通過改進的可通路性，為輕量辦公提供保證。
業務擴充：基于雲的解決方案，可以使企業以較小的額外成本，獲得計算能力的彈性提升。雲服務商可以滿足使用者的定制化需求，低廉的成本使得企業無須對未來的擴張有所顧慮。
移動辦公：針對移動辦公的特點，多種手持終端可以實作無縫的随時随地接入，友善進行遠端辦公和業務流程處理，真正實作任何時候、任何裝置、任何網絡都可以通路應用的需求。現有IT系統無需改造，通過桌面雲系統即可以實作網絡的全集中管理，提高IT維護效率。
八、微服務
1、傳統單塊架構模式
傳統的 Web 應用開發在邏輯上分為表示層、業務邏輯層和資料通路層三層的模式，開發團隊對不同層的代碼實作，經曆編譯、打包、部署後，最終運作在同一台機器的同一個程序中。對于這種功能集中、代碼和資料中心化、一個釋出包、部署後運作在同一個程序中的應用程式，稱之為單塊架構（monolithic architecture）。
傳統單塊架構由于所有的代碼運作在同一主機的同一個程序中，不同功能與服務子產品的線程共享程序空間，使用者狀态可以用全局變量實作共享。外部通路控制，認證授權與功能互動統一起來，所有功能通過内部的方法或函數調用來實作，不需要對外提供額外的 API 接口，使得程式的安全性較高。
2、微服務架構
為了打破單塊架構模式所帶來開發效率低、代碼維護差、部署不靈活、拓展性差瓶頸，在微服務架構中對應用進行有效拆分，每個服務運作在獨立的程序中，服務間采用輕量級的通信機制互相溝通。服務可獨立擴充伸縮，每個服務定義了明确的邊界，不同的服務甚至可以采用不同的程式設計語言來實作，由獨立的團隊來維護，并且能夠被獨立的部署到生産環境、類生産環境等。
3、傳統單體架構VS微服務架構
傳統單體架構
同一主機同一程序内
-開發團隊對不同層代碼進行編譯、打包，部署到一個主機程序中
所有服務子產品為本地調用
-全部服務皆可共享使用者的邏輯狀态
-應用伺服器提高會話管理
建構部署時間充分
-在周期内将安全融入的到系統開發中，将安全漏洞早于部署前發現
微服務架構
不同容器或者主機不同程序
-将微服務打包為Docker鏡像
-将每個服務執行個體部署為容器
各個服務間需要遠端通路
- 服務之間獨立無法共享使用者狀态
- 需要集中進行身份校驗與授權
- 服務間需要互相通信并且進行控制
靈活開發與自動化部署
- 業務優先原則，安全在更快的投付生産中顯得疲奔命
4、微服務的特點
彼此獨立：既然是一個獨立的服務，那必然是一個完整的自治系統，不依賴外部的東西就能夠提供服務。有自己一整套的完整的運作機制，有和外部通訊的标準化接口。
原子化：作為一個微服務，一定是一個原子化的服務。也就是說服務不能再劃分成更小的服務了。如果一個服務還能劃分成幾個小的服務，那我們就不能稱之為一個微服務，它其實可以通過幾個微服務組合成的一個系統。
組合和重構：如果是最原子的服務，那一定是沒有任何用處的。微服務之是以神奇，在于它能快速的組合和重構，彼此組合成一個系統。
5、微服務應用場景
| Eureka | 服務注冊發現架構 | Hystrix | 服務容錯元件 |
| Zuul | 服務網關 | Archaius | 服務配置元件 |
| Karyon | 服務端架構 | Servo | Metrics元件 |
| Ribbon | 用戶端架構 | Blitz4j | 日志元件 |
6、Docker容器介紹
Docker是一個開源的應用容器引擎，讓開發者可以打包他們的應用以及依賴包到一個可移植的容器中，然後釋出到任何流行的 Linux 機器上，也可以實作虛拟化。容器是完全使用沙箱機制，互相之間不會有任何接口。幾乎沒有性能開銷，可以很容易地在機器和資料中心中運作。最重要的是，他們不依賴于任何語言、架構包括系統。
Docker是微服務的一個非常完美的運作環境。
7、微服務與微服務之間的安全
1、微服務子產品自身安全
相當于傳統服務端，那麼傳統服務端中涉及到的安全風險相對的都可能在微服務子產品中存在，比如輸入輸出校驗不嚴格、第三方架構帶來的風險、引入新技術帶來的風險。
2、服務注冊與發現元件安全
該部分的風險直接影響着整體微服務架構的安全性。服務注冊與發現元件用于實作分布式系統中服務的發現與配置，常用的有consul等。差別于常見風險，它所帶來嚴重風險為資訊洩露及導緻整個架構不可用。
3、服務間通信安全
微服務架構中通信包括用戶端與API網關通信、用戶端與微服務端直接通信、服務間通信，其中用戶端與API網關通信或者用戶端與微服務端直接通信都屬于邊界安全問題。微服務間的通信屬于内部通信，這是微服務架構相較于傳統單塊架構的獨特之處。
在架構中必須保證所有微服務接口統一由API網關進行管理，否則一旦接口直接暴露與公網，會由于接口濫用帶來很多風險，同時為了防止攻擊單點突破，需要根據業務需求精确地指定哪些服務可以與其通信。