🥇雲端安全監控 | 專業主機

將資料和應用程式移至雲端對企業 SOC 提出了新的挑戰，它們並不總是準備好監控其他人的基礎架構。據 Netoskope 稱，平均每個企業（顯然是在美國）使用 1246 種不同的雲端服務，比一年前增加了 22%。 1246雲端服務！！！其中 175 個與人力資源服務相關，170 個與行銷相關，110 個與通訊領域相關，76 個與財務和 CRM 相關。思科「僅」使用 700 個外部雲端服務。所以我對這些數字有點困惑。但無論如何，問題不在於他們，而是越來越多的公司開始非常積極地使用雲，這些公司希望擁有與自己的網路相同的監控雲端基礎設施的功能。而且這種趨勢正在增長——根據根據美國會計協會的數據到 2023 年，美國將關閉 1200 個資料中心（已經關閉 6250 個）。但向雲端的過渡不僅僅是「讓我們將伺服器轉移到外部提供者」。新的IT架構、新軟體、新流程、新限制…這一切不僅為IT工作帶來重大變化，也為資訊安全工作帶來重大變化。如果提供者已經學會以某種方式應對確保雲端本身的安全（幸運的是有很多建議），那麼雲端資訊安全監控，特別是在SaaS 平台上，就會遇到很大的困難，我們將討論這一點。

假設您的公司已將部分基礎設施遷移到雲端...停止。不是這樣的。如果基礎設施已經轉移，而你現在才考慮如何監控它，那麼你就已經輸了。除非是亞馬遜、谷歌或微軟（然後有保留），否則你可能沒有太多能力來監控你的資料和應用程式。如果您有機會使用日誌，那就太好了。有時安全事件資料可用，但您無權存取它。例如，Office 365。如果您擁有最便宜的 E1 許可證，則您根本無法使用安全事件。如果您擁有 E3 許可證，您的資料僅儲存 90 天，並且僅當您擁有 E5 許可證時，日誌的持續時間才可用一年（但是，這也有其自身的細微差別，需要單獨儲存）向Microsoft支援請求許多處理日誌的功能）。順便說一下，E3許可證在監控功能方面比企業Exchange弱很多。要達到相同的級別，您需要 E5 許可證或額外的高級合規性許可證，這可能需要額外的資金，而這些資金並未計入您遷移到雲端基礎設施的財務模型中。而這只是低估雲端資訊安全監控相關問題的一個例子。在本文中，我不想假裝完整，而是想提請大家注意從安全角度選擇雲端提供者時應考慮的一些細微差別。在文章的最後，將給出一個清單，在考慮雲端資訊安全監控問題已解決之前，值得完成該清單。

有幾個典型問題會導致雲端環境中的事件，而資訊安全服務沒有時間回應或根本看不到它們：

安全日誌不存在。這是一種相當普遍的情況，尤其是對於雲端解決方案市場的新手來說。但你不應該立即放棄它們。小型企業，尤其是國內企業，對客戶需求更加敏感，可以透過改變已批准的產品路線圖來快速實現一些所需的功能。是的，這不會是亞馬遜的 GuardDuty 或 Bitrix 的「主動保護」模組的類似物，但至少是一些東西。
資訊安全不知道日誌儲存在哪裡，或無法存取它們。這裡有必要與雲端服務提供者進行談判——如果他認為客戶對他很重要，他也許會提供此類資訊。但總的來說，當「透過特殊決定」提供日誌存取權限時，情況並不是很好。
雲端提供者也有日誌，但他們提供的監控和事件記錄有限，不足以偵測所有事件。例如，您可能只會收到網站上的更改日誌或用戶身份驗證嘗試的日誌，但不會收到其他事件（例如網路流量），這將為您隱藏一整層旨在攻擊您的雲端基礎設施的事件。
有日誌，但對它們的訪問很難自動化，這迫使它們不能連續監控，而是按計劃監控。而如果無法自動下載日誌，那麼下載日誌，例如Excel格式的日誌（國內很多雲端解決方案提供者都是這樣），甚至可能會導致企業資訊安全服務部門不願意去修改。
無日誌監控。這或許是雲端環境中資訊安全事件最不明確的原因。似乎有日誌，並且可以自動訪問它們，但沒有人這樣做。為什麼？

共享雲端安全理念

向雲端的過渡始終是在保持對基礎設施的控制的願望與將其轉移到專門負責維護基礎設施的雲端提供者的更專業的手中之間尋求平衡。而在雲端安全領域，也必須尋求這種平衡。此外，根據所使用的雲端服務交付模型（IaaS、PaaS、SaaS），這種平衡總是會有所不同。無論如何，我們必須記住，當今所有雲端提供者都遵循所謂的共同責任和共享資訊安全模型。雲端負責一些事情，而另一些事情則由客戶端負責，將他的資料、他的應用程式、他的虛擬機器和其他資源放在雲端。期望透過轉向雲，我們將把所有責任轉移給提供者，這是魯莽的。但在遷移到雲端時自行建置所有安全性也是不明智的。需要一種平衡，這取決於許多因素： - 風險管理策略、威脅模型、雲端提供者可用的安全機制、立法等。

例如，對雲端中託管的資料進行分類始終是客戶的責任。雲端提供者或外部服務提供者只能幫助他提供一些工具來幫助標記雲端中的資料、識別違規行為、刪除違法資料或使用一種或另一種方法來掩蓋資料。另一方面，實體安全始終是雲端提供者的責任，無法與客戶共享。但資料和實體基礎設施之間的一切恰恰是本文討論的主題。例如，雲端的可用性是提供者的責任，而設定防火牆規則或啟用加密是客戶的責任。在本文中，我們將嘗試了解俄羅斯各種流行的雲端供應商提供了哪些資訊安全監控機制，它們的使用特點是什麼，以及何時值得考慮外部覆蓋解決方案（例如，Cisco E-郵件安全），可擴充雲端在網路安全方面的功能。在某些情況下，特別是如果您遵循多雲策略，您將別無選擇，只能同時在多個雲端環境中使用外部資訊安全監控解決方案（例如，Cisco CloudLock 或 Cisco Stealthwatch Cloud）。好吧，在某些情況下，您會意識到您選擇的（或強加給您的）雲端提供者根本不提供任何資訊安全監控功能。這是令人不快的，但也不是一點點，因為它允許您充分評估與使用此雲端相關的風險等級。

雲端安全監控生命週期

要監控您使用的雲端的安全性，您只有三個選擇：

依賴雲端提供者提供的工具，
使用第三方解決方案來監控您使用的 IaaS、PaaS 或 SaaS 平台，
建立您自己的雲端監控基礎架構（僅適用於IaaS/PaaS平台）。

讓我們看看這些選項都有哪些功能。但首先，我們需要了解監控雲端平台時將使用的通用框架。我想強調雲端中資訊安全監控流程的 6 個主要組成部分：

基礎設施準備。確定必要的應用程式和基礎設施，以將對於資訊安全重要的事件收集到儲存中。
收藏。在此階段，從各個來源聚合安全事件，以便後續傳輸進行處理、儲存和分析。
治療。在這個階段，對資料進行轉換和豐富，以方便後續分析。
貯存。此元件負責短期和長期儲存收集的已處理資料和原始資料。
分析。在此階段，您可以自動或手動偵測事件並做出回應。
報告。此階段有助於為利害關係人（管理階層、審計師、雲端提供者、客戶等）制定關鍵指標，幫助我們做出某些決策，例如更換提供者或加強資訊安全。

了解這些組成部分將使您將來能夠快速決定可以從提供者那裡獲得什麼，以及您必須自己做或在外部顧問的參與下做什麼。

內建雲端服務

我在上面已經寫過，當今許多雲端服務不提供任何資訊安全監控功能。總的來說，他們不太關注資訊安全這個主題。例如，俄羅斯流行的一種透過網路向政府機構發送報告的服務（我不會具體提及它的名字）。有關此服務安全性的整個部分都圍繞著經過認證的 CIPF 的使用。國內另一家電子文件管理雲端服務的資訊安全部分也不例外。它討論了公鑰憑證、經過認證的加密技術、消除 Web 漏洞、防禦 DDoS 攻擊、使用防火牆、備份，甚至定期的資訊安全審核。但沒有提及監控，也沒有提及造訪該服務提供者的客戶可能感興趣的資訊安全事件的可能性。

一般來說，透過雲端提供者在其網站和文件中描述資訊安全問題的方式，您可以了解其對這個問題的重視程度。例如，如果您閱讀「My Office」產品的手冊，則根本沒有有關安全性的字眼，但在單獨產品「My Office」的文件中卻沒有任何有關安全性的字眼。 KS3”，旨在防止未經授權的訪問，通常列出了“My Office.KS17”實現的 FSTEC 第 3 階要點，但沒有描述它是如何實現的，最重要的是，如何實現將這些機制與企業資訊安全結合。也許這樣的文件存在，但我沒有在公共領域的「My Office」網站上找到它。雖然也許我只是無權訪問這些秘密資訊？...

對於 Bitrix 來說，情況要好得多。該文件描述了事件日誌的格式，有趣的是，還描述了入侵日誌，其中包含與雲端平台潛在威脅相關的事件。從那裡您可以提取 IP、使用者或訪客名稱、事件來源、時間、使用者代理、事件類型等。確實，您可以從雲端本身的控制面板處理這些事件，也可以上傳 MS Excel 格式的資料。現在很難自動處理 Bitrix 日誌，您必須手動完成一些工作（上傳報告並將其載入到 SIEM 中）。但如果我們記得直到最近這樣的機會還不存在，那麼這就是巨大的進步。同時，我想指出的是，許多國外雲端提供者都提供了類似的「針對初學者」的功能——要么通過控制面板用眼睛看日誌，要么將數據上傳給自己（但是，大多數以. csv 格式，而不是Excel）。

在不考慮無日誌選項的情況下，雲端提供者通常會為您提供三種監控安全事件的選項：儀表板、資料上傳和 API 存取。第一個似乎可以為您解決許多問題，但這並不完全正確 - 如果您有幾本雜誌，您必須在顯示它們的螢幕之間切換，從而失去整體圖片。此外，雲端提供者不太可能為您提供關聯安全事件並從安全角度一般分析它們的能力（通常您正在處理原始數據，您需要自己了解這些數據）。也有例外，我們將進一步討論它們。最後，值得問一下您的雲端供應商記錄了哪些事件、以什麼格式以及它們如何與您的資訊安全監控流程相對應？例如，使用者和訪客的識別和認證。相同的 Bitrix 可讓您根據這些事件記錄事件的日期和時間、使用者或訪客的姓名（如果您有「Web Analytics」模組）、造訪的物件以及網站的其他典型元素。但企業資訊安全服務可能需要有關使用者是否從可信任設備存取雲端的資訊（例如，在企業網路中，此任務由思科 ISE 實施）。像geo-IP功能這樣簡單的任務如何幫助確定雲端服務使用者帳戶是否被盜？即使雲端提供者為您提供了它，這也還不夠。同樣的 Cisco CloudLock 不僅分析地理位置，還使用機器學習分析每個使用者的歷史數據，並監控識別和身份驗證嘗試中的各種異常情況。只有 MS Azure 具有類似的功能（如果您有適當的訂閱）。

還有另一個困難 - 由於對於許多雲端提供者來說，資訊安全監控是他們剛開始處理的新主題，因此他們不斷改變解決方案中的某些內容。今天他們有一個版本的 API，明天有另一個版本，後天有第三個版本。您還需要為此做好準備。功能也是如此，功能可能會發生變化，您的資訊安全監控系統必須考慮到這一點。例如，Amazon 最初擁有單獨的雲端事件監控服務——AWS CloudTrail 和 AWS CloudWatch。隨後出現了一個單獨的用於監控資訊安全事件的服務—AWS GuardDuty。一段時間後，亞馬遜推出了新的管理系統 Amazon Security Hub，其中包括對從 GuardDuty、Amazon Inspector、Amazon Macie 和其他幾個系統收到的資料進行分析。另一個例子是 Azure 日誌與 SIEM 整合工具 - AzLog。它被許多 SIEM 廠商積極使用，直到 2018 年微軟宣布停止開發和支持，這讓許多使用該工具的客戶遇到了問題（我們稍後會講如何解決）。

因此，請仔細監控雲端提供者為您提供的所有監控功能。或依賴外部解決方案提供者，他們將充當您的 SOC 和您要監控的雲端之間的中介。是的，它會更昂貴（儘管並非總是如此），但你會將所有責任轉移到別人的肩膀上。或不是全部？...讓我們記住共享安全的概念，並了解我們無法改變任何事情- 我們必須獨立了解不同的雲端提供者如何提供對資料、應用程式、虛擬機和其他資源的資訊安全的監控託管在雲端。我們將從亞馬遜在這一部分中提供的內容開始。

範例：基於AWS的IaaS資訊安全監控

是的，是的，我知道亞馬遜不是最好的例子，因為這是一項美國服務，它可以作為打擊極端主義和傳播俄羅斯禁止的信息的一部分而被封鎖。但在這篇文章中，我只想從安全的角度展示不同的雲端平台在資訊安全監控能力上的差異，以及在將關鍵流程轉移到雲端時應該注意什麼。好吧，如果一些俄羅斯雲端解決方案開發人員學到了一些對自己有用的東西，那就太好了。

首先要說的是，亞馬遜並不是一座堅不可摧的堡壘。他的客戶經常發生各種事件。例如，198 億選民的姓名、地址、出生日期和電話號碼被從 Deep Root Analytics 中竊取。以色列公司 Nice Systems 竊取了 Verizon 用戶的 14 萬筆記錄。但是，AWS 的內建功能可讓您偵測各種事件。例如：

對基礎設施的影響 (DDoS)
節點妥協（指令注入）
帳戶洩露和未經授權的訪問
不正確的配置和漏洞
不安全的介面和 API。

造成這種差異的原因是，正如我們上面所發現的，客戶自己對客戶資料的安全負責。而如果他懶得開啟保護機制，不開啟監控工具，那麼他只會從媒體或從他的客戶那裡得知這起事件。

為了識別事件，您可以使用 Amazon 開發的各種不同的監控服務（儘管這些服務通常由 osquery 等外部工具進行補充）。因此，在 AWS 中，所有使用者操作都會受到監控，無論它們是如何執行的 - 透過管理主控台、命令列、SDK 或其他 AWS 服務。每個 AWS 帳戶的活動（包括使用者名稱、操作、服務、活動參數和結果）和 API 使用情況的所有記錄均可透過 AWS CloudTrail 取得。您可以從 CloudTrail 控制台查看這些事件（例如 AWS IAM 控制台登入），使用 Amazon Athena 分析它們，或將它們「外包」給外部解決方案，例如 Splunk、AlienVault 等。 AWS CloudTrail 日誌本身放置在您的 AWS S3 儲存桶中。

另外兩項 AWS 服務提供了許多其他重要的監控功能。首先，Amazon CloudWatch 是一項針對 AWS 資源和應用程式的監控服務，除此之外，它還可讓您識別雲端中的各種異常情況。所有內建 AWS 服務，例如 Amazon Elastic Compute Cloud（伺服器）、Amazon Relational Database Service（資料庫）、Amazon Elastic MapReduce（資料分析）和 30 種其他 Amazon 服務，都使用 Amazon CloudWatch 來儲存其日誌。開發人員可以使用 Amazon CloudWatch 的開放 API 將日誌監控功能新增至自訂應用程式和服務中，讓他們可以擴展安全上下文中的事件分析範圍。

其次，VPC 流日誌服務可讓您分析 AWS 伺服器（外部或內部）以及微服務之間傳送或接收的網路流量。當您的任何 AWS VPC 資源與網路互動時，VPC 流日誌會記錄有關網路流量的詳細信息，包括來源和目標網路接口，以及您的 IP 位址、連接埠、協定、位元組數和資料包數。。那些對本地網路安全有經驗的人會認為這類似於線程網路串流，可以由交換器、路由器和企業級防火牆建立。這些日誌對於資訊安全監控非常重要，因為與有關使用者和應用程式操作的事件不同，它們還允許您不錯過 AWS 虛擬私有雲環境中的網路互動。

總而言之，這三項 AWS 服務（AWS CloudTrail、Amazon CloudWatch 和 VPC Flow Logs）共同提供了對您的帳戶使用情況、使用者行為、基礎設施管理、應用程式和服務活動以及網路活動的相當強大的洞察。例如，它們可用於檢測以下異常：

嘗試掃描網站、搜尋後門、透過突發的「404 錯誤」搜尋漏洞。
透過突發「500 錯誤」進行注入攻擊（例如 SQL 注入）。
已知的攻擊工具有sqlmap、nikto、w3af、nmap等。透過對User Agent字段的分析。

Amazon Web Services 也為網路安全目的開發了其他服務，可讓您解決許多其他問題。例如，AWS 有一個用於審核原則和配置的內建服務 - AWS Config。本服務提供您的 AWS 資源及其配置的持續審核。讓我們舉一個簡單的例子：假設您想要確保在所有伺服器上停用使用者密碼，並且只能基於憑證進行存取。 AWS Config 可以輕鬆檢查所有伺服器的這一點。還有其他策略可以應用於您的雲端伺服器：「沒有伺服器可以使用連接埠 22」、「只有管理員可以更改防火牆規則」或「只有使用者 Ivashko 可以建立新的使用者帳戶，而且他只能在星期二進行。」 2016 年夏天，AWS Config 服務擴展，可以自動偵測違反已製定策略的行為。 AWS Config 規則本質上是對您使用的 Amazon 服務的連續設定請求，如果違反對應的策略，則會產生事件。例如，可以使用 AWS Config 規則持續檢查伺服器磁碟以確保滿足此條件，而不是定期執行 AWS Config 查詢來驗證虛擬伺服器上的所有磁碟都已加密。最重要的是，在本出版物中，任何違規行為都會產生可供您的資訊安全服務分析的事件。

AWS 還擁有與傳統企業資訊安全解決方案相當的解決方案，它也會產生您可以並且應該分析的安全事件：

入侵偵測 - AWS GuardDuty
資訊外洩控制 - AWS Macie
EDR（雖然它談論雲端中的端點有點奇怪） - AWS Cloudwatch + 開源 osquery 或 GRR 解決方案
Netflow 分析 - AWS Cloudwatch + AWS VPC Flow
DNS 分析 - AWS Cloudwatch + AWS Route53
AD-AWS 目錄服務
帳戶管理 - AWS IAM
SSO-AWS 單一登入
安全分析 - AWS Inspector
組態管理 - AWS Config
WAF - AWS WAF。

我不會詳細描述在資訊安全方面可能有用的所有亞馬遜服務。最重要的是要了解，所有這些都可以產生我們可以並且應該在資訊安全背景下進行分析的事件，為此目的，使用 Amazon 本身的內建功能和外部解決方案，例如 SIEM，它可以將安全事件發送到您的監控中心，並與其他雲端服務或內部基礎設施、週邊或行動裝置的事件一起進行分析。

無論如何，這一切都始於為您提供資訊安全事件的資料來源。這些來源包括但不限於：

CloudTrail - API 使用與使用者操作
Trusted Advisor - 根據最佳實踐進行安全檢查
配置 - 帳戶和服務設定的清單和配置
VPC 流日誌 - 與虛擬介面的連接
IAM-身分識別和認證服務
ELB存取日誌-負載平衡器
檢查器 - 應用程式漏洞
S3——文件存儲
CloudWatch - 應用程式活動
SNS 是一種通知服務。

亞馬遜雖然為其生成提供瞭如此廣泛的事件來源和工具，但其在資訊安全背景下分析收集的資料的能力非常有限。您必須獨立研究可用的日誌，尋找其中的相關妥協指標。亞馬遜最近推出的 AWS Security Hub 旨在透過成為 AWS 的雲端 SIEM 來解決這個問題。但到目前為止，它才剛開始，並受到與其合作的來源數量以及亞馬遜本身的架構和訂閱所建立的其他限制的限制。

範例：基於Azure的IaaS資訊安全監控

我不想就三個雲端供應商（亞馬遜、微軟或谷歌）中哪一個更好進行長時間的爭論（特別是因為他們每個人仍然有自己的具體細節並且適合解決自己的問題）；我們將重點放在一下這些廠商提供的資訊安全監控能力。必須承認的是，亞馬遜AWS是這一領域的先驅之一，因此在資訊安全功能方面走得最遠（儘管許多人承認它們很難使用）。但這並不意味著我們會忽視微軟和谷歌為我們提供的機會。

微軟的產品一向以「開放性」著稱，Azure的情況也類似。例如，如果AWS和GCP總是從「不允許的就是禁止的」的概念出發，那麼Azure的做法恰恰相反。例如，在雲端中建立虛擬網路並在其中建立虛擬機器時，預設情況下所有連接埠和協定都是開放且允許的。因此，您將不得不花費更多的精力來對 Microsoft 雲端中的存取控制系統進行初始設定。這也對您在 Azure 雲端的監控活動提出了更嚴格的要求。

AWS 有一個特點，當您監控虛擬資源時，如果它們位於不同的區域，那麼您很難將所有事件結合起來進行統一分析，為了消除這種情況，您需要採取各種技巧，例如為AWS Lambda 創建您自己的程式碼，用於在區域之間傳輸事件。 Azure 不存在這個問題 - 它的活動記錄機制可以不受限制地追蹤整個組織的所有活動。這同樣適用於 AWS Security Hub，它是亞馬遜最近開發的，旨在將許多安全功能整合到安全中心內，但僅限於其所在區域內，但這與俄羅斯無關。 Azure擁有自己的安全中心，不受區域限制，提供雲端平台所有安全功能的存取。此外，對於不同的本地團隊，它可以提供自己的一套保護功能，包括他們管理的安全事件。 AWS Security Hub 仍在努力變得與 Azure 安全中心類似。但值得補充的是美中不足 - 您可以從 Azure 中擠出許多先前在 AWS 中描述的功能，但這僅適用於 Azure AD、Azure Monitor 和 Azure Security Center。所有其他 Azure 安全機制（包括安全性事件分析）尚未以最方便的方式進行管理。該問題已透過API 部分解決，該API 滲透到所有Microsoft Azure 服務中，但這需要您付出額外的努力來將雲端與SOC 集成，並且需要合格的專家（事實上，與任何其他與雲端配合使用的SIEM 一樣）蜜蜂）。稍後將討論的一些 SIEM 已經支援 Azure 並可以自動執行監視它的任務，但它也有其自身的困難 - 並非所有 SIEM 都可以收集 Azure 擁有的所有日誌。

Azure 中的事件收集和監視是使用 Azure Monitor 服務提供的，它是收集、儲存和分析 Microsoft 雲端及其資源（Git 儲存庫、容器、虛擬機器、應用程式等）中的資料的主要工具。 Azure Monitor 收集的所有數據分為兩類：指標（即時收集並描述 Azure 雲端的關鍵效能指標）和日誌（包含組織成記錄的數據，描述 Azure 資源和服務活動的某些方面）。此外，使用資料收集器 API，Azure Monitor 服務可以從任何 REST 來源收集資料以建立自己的監視方案。

以下是 Azure 提供給你的一些安全事件來源，你可以透過 Azure 入口網站、CLI、PowerShell 或 REST API 存取這些事件來源（有些只能透過 Azure Monitor/Insight API）：

活動日誌 - 此日誌回答了有關雲端資源上的任何寫入作業（PUT、POST、DELETE）的「誰」、「什麼」和「何時」等經典問題。與其他一些事件一樣，與讀取存取 (GET) 相關的事件不包含在此日誌中。
診斷日誌 - 包含訂閱中包含的特定資源的操作資料。
Azure AD 報告 - 包含與群組和使用者管理相關的使用者活動和系統活動。
Windows 事件日誌和 Linux 系統日誌 - 包含來自雲端中託管的虛擬機器的事件。
指標 - 包含有關雲端服務和資源的效能和運作狀況的遙測資料。每分鐘測量一次並儲存。 30天內。
網路安全群組流程日誌 - 包含使用網路觀察器服務和網路層級的資源監控所收集的網路安全事件的資料。
儲存日誌 - 包含與存取儲存設施相關的事件。

對於監視，可以使用外部 SIEM 或內建 Azure Monitor 及其擴充。稍後我們將討論資訊安全事件管理系統，但現在讓我們看看 Azure 本身為我們提供了哪些安全性上下文中的資料分析功能。 Azure Monitor 中與安全相關的所有內容的主螢幕是 Log Analytics 安全性和審核儀表板（免費版本僅支援一週的有限數量的事件儲存）。此儀表板分為 5 個主要區域，以視覺化方式顯示您正在使用的雲端環境中發生的情況的摘要統計資料：

安全域——與資訊安全相關的關鍵量化指標——事件數量、受損節點數量、未修補的節點數量、網路安全事件等。
值得注意的問題 - 顯示活躍資訊安全問題的數量和重要性
偵測 - 顯示針對您的攻擊模式
威脅情報 - 顯示正在攻擊您的外部節點的地理訊息
常見安全性查詢 - 典型查詢將幫助您更好地監控資訊安全性。

Azure Monitor 擴充功能包括 Azure Key Vault（保護雲端中的加密金鑰）、惡意軟體評估（分析虛擬機器上的惡意程式碼防護）、Azure 應用程式閘道分析（分析雲端防火牆日誌等）等。。這些工具豐富了處理事件的某些規則，使您可以視覺化雲端服務活動的各個方面（包括安全性），並識別操作中的某些偏差。但是，正如經常發生的那樣，任何附加功能都需要相應的付費訂閱，這將需要您相應的財務投資，您需要提前規劃。

Azure 具有許多內建威脅監視功能，這些功能整合到 Azure AD、Azure Monitor 和 Azure 安全中心。其中，例如，偵測虛擬機器與已知惡意IP的交互作用（由於存在與微軟威脅情報服務的整合）、透過接收雲端中託管的虛擬機器的警報來偵測雲端基礎架構中的惡意軟體、密碼虛擬機器上的「猜測攻擊」、使用者識別系統配置中的漏洞、從匿名器或受感染節點登入系統、帳戶外洩、從異常位置登入系統等。如今，Azure 是為數不多的為你提供內建威脅情報功能以豐富收集的資訊安全事件的雲端提供者之一。

如上所述，安全功能及其產生的安全事件並非對所有使用者均等地可用，而是需要包含您所需功能的特定訂閱，從而產生適當的事件以進行資訊安全監控。例如，上一段中所述的一些用於監視帳戶異常的功能僅在 Azure AD 服務的 P2 進階授權中可用。如果沒有它，您將不得不「手動」分析收集到的安全事件，就像 AWS 的情況一樣。此外，根據 Azure AD 授權的類型，並非所有事件都可用於分析。

在 Azure 入口網站上，您可以管理您感興趣的日誌的搜尋查詢，並設定儀表板以視覺化關鍵資訊安全指標。此外，您還可以選擇Azure Monitor擴展，它允許您擴展Azure Monitor日誌的功能，並從安全角度對事件進行更深入的分析。

如果你不僅需要使用日誌的能力，還需要為你的Azure雲端平台提供一個全面的安全中心，包括資訊安全策略管理，那麼你可以談論需要使用Azure安全中心，其中大部分有用的功能需要花費一些錢才能獲得，例如威脅偵測、Azure 外部監控、合規性評估等。（在免費版本中，您只能存取安全評估和消除已識別問題的建議）。它將所有安全問題整合到一處。事實上，我們可以談論比Azure Monitor 為您提供的更高級別的資訊安全，因為在這種情況下，透過使用許多來源豐富了整個雲端工廠收集的數據，例如Azure、Office 365、Microsoft CRM Online、 Microsoft Dynamics AX 、outlook.com、MSN.com、微軟數位犯罪部門（DCU）和微軟安全回應中心（MSRC），其上疊加了各種複雜的機器學習和行為分析演算法，最終應該提高偵測和回應威脅的效率。

Azure 也有自己的 SIEM - 它於 2019 年初出現。這就是Azure Sentinel，它依賴Azure Monitor的數據，也可以與之整合。外部安全解決方案（例如 NGFW 或 WAF），其數量不斷增加。此外，透過整合 Microsoft Graph 安全性 API，您可以將自己的威脅情報來源連接到 Sentinel，從而豐富了分析 Azure 雲端中事件的功能。可以說，Azure Sentinel是第一個來自雲端提供者的「原生」SIEM（同樣可以託管在雲端中的Splunk或ELK，例如AWS，仍然不是由傳統雲端服務供應商開發的）。 Azure Sentinel 和安全中心可以稱為Azure 雲端的SOC，如果您不再擁有任何基礎設施並且將所有運算資源轉移到雲端（這將是Microsoft 雲端Azure），則可能僅限於它們（有一定保留）。

但由於 Azure 的內建功能（即使您訂閱了 Sentinel）通常不足以監控資訊安全性並將此流程與其他安全事件來源（雲端和內部）集成，因此有一個需要將收集到的資料匯出到外部系統，其中可能包括SIEM。這是透過使用 API 和特殊擴充功能來完成的，這些擴充功能目前僅正式適用於以下 SIEM - Splunk（適用於 Splunk 的 Azure Monitor 附加元件）、IBM QRadar (Microsoft Azure DSM)、SumoLogic、ArcSight 和 ELK。直到最近，還有更多這樣的 SIEM，但從 1 年 2019 月 XNUMX 日起，Microsoft 停止支援 Azure 日誌整合工具 (AzLog)，該工具是在 Azure 出現之初且缺乏處理日誌的正常標準化 (Azure Monitor甚至還不存在）使得外部SIEM 與Microsoft 雲端的整合變得容易。現在情況發生了變化，微軟推薦Azure Event Hub平台作為其他SIEM的主要整合工具。許多人已經實現了此類集成，但要小心 - 他們可能不會捕獲所有 Azure 日誌，而只會捕獲部分日誌（請參閱 SIEM 文件）。

在結束對Azure 的簡短遊覽之後，我想給出有關此雲端服務的一般性建議- 在您談論Azure 中的資訊安全監控功能之前，您應該非常仔細地配置它們並測試它們是否按照文件中所寫的那樣工作，並且正如微軟顧問告訴你的那樣（他們可能對 Azure 函數的功能有不同的看法）。如果有財力，在資訊安全監控方面，可以從Azure擠出許多有用的信息。如果您的資源有限，那麼就像AWS的情況一樣，您將只能依靠自己的力量和Azure Monitor為您提供的原始資料。請記住，許多監控功能需要花錢，最好事先熟悉定價政策。例如，您可以免費存儲 31 天的數據，每個客戶最多可存儲 5 GB - 超過這些值將需要您支付額外的費用（客戶每增加 GB 存儲大約需要 2 美元以上，存儲每 GB 大約需要 0,1 美元）每個月儲存1 GB ）。使用應用程式遙測和指標以及使用警報和通知也可能需要額外的資金（有一定的限制是免費的，這可能不足以滿足您的需求）。

範例：基於Google Cloud Platform的IaaS資訊安全監控

與 AWS 和 Azure 相比，Google雲端平台看起來還很年輕，但這在一定程度上是好的。與AWS不同的是，AWS逐漸增強了其功能，包括安全功能，但存在中心化問題； GCP 與 Azure 一樣，可以更好地進行集中管理，從而減少整個企業的錯誤和實施時間。奇怪的是，從安全性角度來看，GCP 介於 AWS 和 Azure 之間。他也為整個組織進行了一次活動註冊，但並不完整。部分功能仍處於測試階段，但逐漸消除此缺陷，GCP將成為資訊安全監控方面更成熟的平台。

GCP 中記錄事件的主要工具是 Stackdriver Logging（類似於 Azure Monitor），它允許您收集整個雲端基礎架構（以及來自 AWS）的事件。從 GCP 的安全角度來看，每個組織、專案或資料夾都有四個日誌：

管理活動 - 包含與管理存取相關的所有事件，例如建立虛擬機器、變更存取權限等。無論您的意願如何，該日誌都會被寫入，並儲存其資料 400 天。
資料存取 - 包含與雲端使用者處理資料相關的所有事件（建立、修改、讀取等）。預設情況下，不會寫入此日誌，因為它的體積膨脹得非常快。因此，它的保質期只有30天。此外，這本雜誌上並沒有寫所有內容。例如，與所有使用者均可公開存取或無需登入 GCP 即可存取的資源相關的事件不會寫入其中。
系統事件 - 包含與使用者無關的系統事件，或變更雲端資源配置的管理員操作。它始終被寫入並儲存 400 天。
Access Transparency 是一個獨特的日誌範例，它捕獲在工作職責中存取您的基礎設施的 Google 員工（但尚未涵蓋所有 GCP 服務）的所有操作。該日誌將存儲 400 天，並且並非對每個 GCP 客戶都可用，但前提是滿足許多條件（黃金級或白金級支持，或者作為公司支持的一部分存在某種類型的 4 個角色）。類似的功能也可用，例如在 Office 365 - Lockbox 中。

日誌範例：存取透明度

{
 insertId:  "abcdefg12345"
 jsonPayload: {
  @type:  "type.googleapis.com/google.cloud.audit.TransparencyLog"
  location: {
   principalOfficeCountry:  "US"
   principalEmployingEntity:  "Google LLC"
   principalPhysicalLocationCountry:  "CA"
  }
  product: [
   0:  "Cloud Storage"
  ]
  reason: [
    detail:  "Case number: bar123"
    type:  "CUSTOMER_INITIATED_SUPPORT"
  ]
  accesses: [
   0: {
    methodName: "GoogleInternal.Read"
    resourceName: "//googleapis.com/storage/buckets/[BUCKET_NAME]/objects/foo123"
    }
  ]
 }
 logName:  "projects/[PROJECT_NAME]/logs/cloudaudit.googleapis.com%2Faccess_transparency"
 operation: {
  id:  "12345xyz"
 }
 receiveTimestamp:  "2017-12-18T16:06:37.400577736Z"
 resource: {
  labels: {
   project_id:  "1234567890"
  }
  type:  "project"
 }
 severity:  "NOTICE"
 timestamp:  "2017-12-18T16:06:24.660001Z"
}

可以透過多種方式存取這些日誌（與先前討論的 Azure 和 AWS 的方式大致相同） - 透過日誌檢視器介面、透過 API、透過 Google Cloud SDK 或透過您所在專案的活動頁面對活動感興趣。以同樣的方式，它們可以導出到外部解決方案以進行額外分析。後者是透過將日誌匯出到 BigQuery 或 Cloud Pub/Sub 儲存來完成的。

除了 Stackdriver Logging 之外，GCP 平台還提供 Stackdriver Monitoring 功能，可讓您監控雲端服務和應用程式的關鍵指標（效能、MTBF、整體運作狀況等）。經過處理和視覺化的資料可以讓您更輕鬆地發現雲端基礎架構中的問題，包括安全性方面的問題。但應該注意的是，在資訊安全的背景下，此功能不會非常豐富，因為今天 GCP 沒有相同 AWS GuardDuty 的類似物，並且無法識別所有註冊事件中的不良事件（Google 開發了事件威脅檢測，但它仍處於測試階段，現在談論它的用處還為時過早）。 Stackdriver Monitoring 可以用作檢測異常的系統，然後對其進行調查以找出其發生的原因。但鑑於市場上缺乏GCP資訊安全領域的合格人才，這項任務目前看起來很困難。

也值得提供一些可在 GCP 雲端中使用的資訊安全模組的列表，這些模組與 AWS 提供的類似：

Cloud Security Command Center 類似於 AWS Security Hub 和 Azure Security Center。
雲端 DLP - 使用 90 多種預先定義分類策略自動發現和編輯（例如屏蔽）雲端中託管的資料。
Cloud Scanner 是一款針對 App Engine、Compute Engine 和 Google Kubernetes 中已知漏洞（XSS、Flash 注入、未修補的程式庫等）的掃描器。
Cloud IAM - 控制對所有 GCP 資源的存取。
Cloud Identity - 從單一控制台管理 GCP 使用者、裝置和應用程式帳戶。
雲端 HSM - 保護加密金鑰。
雲端金鑰管理服務 - GCP 中加密金鑰的管理。
VPC 服務控制 - 在 GCP 資源周圍建立安全邊界，以防止洩漏。
Titan 安全金鑰 - 防止網路釣魚。

其中許多模組都會產生安全事件，這些事件可以發送到 BigQuery 儲存進行分析或匯出到其他系統（包括 SIEM）。如上所述，GCP是一個積極開發的平台，Google目前正在為其平台開發許多新的資訊安全模組。其中包括事件威脅偵測（現已推出測試版），它會掃描Stackdriver 日誌以搜尋未經授權的活動痕跡（類似於AWS 中的GuardDuty），或策略智慧（在測試版中提供），它允許您針對以下情況制定智慧策略：存取 GCP 資源。

我對流行雲端平台的內建監控功能做了一個簡短的概述。但是，您是否有能夠處理「原始」IaaS 提供者日誌的專家（並非每個人都準備好購買 AWS、Azure 或 Google 的高級功能）？此外，許多人都熟悉「信任，但要驗證」這句格言，這在安全領域比以往任何時候都更加真實。您對向您發送資訊安全事件的雲端提供者的內建功能有多信任？他們對資訊安全的關注程度如何？

有時值得考慮可以補充內建雲端安全性的覆蓋雲端基礎設施監控解決方案，有時此類解決方案是深入了解雲端中託管的資料和應用程式安全性的唯一選擇。此外，它們更加方便，因為它們承擔了分析來自不同雲端提供者的不同雲端服務產生的必要日誌的所有任務。這種覆蓋解決方案的一個例子是思科 Stealthwatch Cloud，它專注於單一任務 - 監控雲端環境中資訊安全性的異常，不僅包括 Amazon AWS、Microsoft Azure 和 Google Cloud Platform，還包括私有雲。

範例：使用 Stealthwatch Cloud 進行資訊安全監控

AWS提供了一個靈活的運算平台，但這種靈活性使企業更容易犯錯，從而導致安全問題。共享資訊安全模型只會對此做出貢獻。在雲端中運行的軟體存在未知漏洞（已知漏洞可以透過 AWS Inspector 或 GCP Cloud Scanner 等進行對抗）、弱密碼、不正確的配置、內部人員等。而這一切都體現在雲端資源的行為中，可以透過思科 Stealthwatch Cloud 進行監控，這是一個資訊安全監控和攻擊偵測系統。公有雲和私有雲。

思科 Stealthwatch Cloud 的主要功能之一是對實體進行建模的能力。有了它，您可以為每個雲端資源（無論是 AWS、Azure、GCP 還是其他資源）建立軟體模型（即近即時模擬）。其中可以包括伺服器和用戶，以及特定於雲端環境的資源類型，例如安全群組和自動縮放群組。這些模型使用雲端服務提供的結構化資料流作為輸入。例如，對於 AWS，這些將是 VPC Flow Logs、AWS CloudTrail、AWS CloudWatch、AWS Config、AWS Inspector、AWS Lambda 和 AWS IAM。實體建模會自動發現任何資源的角色和行為（您可以討論分析所有雲端活動）。這些角色包括 Android 或 Apple 行動裝置、Citrix PVS 伺服器、RDP 伺服器、郵件閘道、VoIP 用戶端、終端伺服器、網域控制站等。然後，它會持續監控他們的行為，以確定何時發生危險或威脅安全的行為。您可以識別密碼猜測、DDoS 攻擊、資料外洩、非法遠端存取、惡意程式碼活動、漏洞掃描和其他威脅。例如，檢測從對您的組織來說不典型的國家/地區（韓國）透過 SSH 對 Kubernetes 叢集進行遠端存取嘗試的情況如下所示：

這就是所謂的從 Postgress 資料庫洩漏資訊到我們之前沒有接觸過的國家的情況：

最後，這是來自中國和印尼的來自外部遠端設備的太多失敗的 SSH 嘗試的樣子：

或者，假設根據策略，VPC 中的伺服器實例永遠不會成為遠端登入目標。我們進一步假設該計算機由於防火牆規則策略的錯誤變更而經歷了遠端登入。實體建模功能將近乎即時地偵測並報告此活動（「異常遠端存取」），並指向特定的 AWS CloudTrail、Azure Monitor 或 GCP Stackdriver Logging API 呼叫（包括使用者名稱、日期和時間等詳細資訊） ).這促使國際電聯規則改變。然後這些資訊可以發送到 SIEM 進行分析。

思科 Stealthwatch 雲端支援的任何雲端環境都可以實現類似的功能：

實體建模是一種獨特的安全自動化形式，可以發現人員、流程或技術中以前未知的問題。例如，它允許您檢測安全問題，例如：

有人在我們使用的軟體中發現後門了嗎？
我們的雲端是否有第三方軟體或設備？
授權使用者是否濫用權限？
是否存在允許遠端存取或其他意外使用資源的設定錯誤？
我們的伺服器是否存在資料外洩？
是否有人試圖從非典型地理位置連結到我們？
我們的雲端是否感染了惡意程式碼？

偵測到的資訊安全事件可以以對應票證的形式傳送到 Slack、Cisco Spark、PagerDuty 事件管理系統，也可以傳送到各種 SIEM，包括 Splunk 或 ELK。總而言之，我們可以說，如果您的公司採用多雲策略並且不限於任何一個雲端供應商，具有上述資訊安全監控功能，那麼使用 Cisco Stealthwatch Cloud 是獲得一套統一監控的不錯選擇為領先的雲端廠商—亞馬遜、微軟和谷歌提供能力。最有趣的是，如果您將 Stealthwatch Cloud 的價格與 AWS、Azure 或 GCP 中資訊安全監控的高級許可證進行比較，結果可能會發現，思科解決方案甚至比亞馬遜、微軟的內建功能還要便宜。和谷歌解決方案。這很矛盾，但卻是事實。您使用的雲端及其功能越多，整合解決方案的優勢就越明顯。

此外，Stealthwatch Cloud還可以監控您組織中部署的私有雲，例如基於Kubernetes容器或透過監控Netflow流量或透過網路裝置（甚至是國產）鏡像接收的網路流量、AD資料或DNS伺服器等。所有這些數據都將透過 Cisco Talos（全球最大的非政府網路安全威脅研究人員組織）收集的威脅情報資訊得到豐富。

這使您可以為您的公司可能使用的公有雲和混合雲實施統一的監控系統。然後可以使用 Stealthwatch Cloud 的內建功能對收集到的資訊進行分析或將其發送到您的 SIEM（預設支援 Splunk、ELK、SumoLogic 等）。

至此，我們將完成本文的第一部分，其中我回顧了用於監控 IaaS/PaaS 平台資訊安全的內建和外部工具，這些工具使我們能夠快速檢測和響應雲環境中發生的事件我們的企業選擇了。在第二部分中，我們將繼續這個主題，並以Salesforce 和Dropbox 為例來研究監控SaaS 平台的選項，並且我們還將嘗試透過為不同的雲端供應商創建統一的資訊安全監控系統來總結和整合所有內容。

來源： www.habr.com

雲端安全監控