天天看點

監控異常操作頻率并報警

監控異常操作頻率并報警

當企業上雲後,監控雲資源的異常操作就是一件非常重要的事情。比如:

• 針對主賬号登陸行為進行通知,因為大部分情況企業都是使用子賬号;

• 針對會産生費用的操作進行通知,避免異常購買行為對企業造成資損;

• 針對删除資源的事件進行報警,因為删除是個敏感操作,誤删資源極可能導緻服務不可用;

• 針對接口調用量突變進行報警,因為這很可能是業務出現了異常; 等等

那麼如何監控這些異常操作呢?答案就是操作審計。接下來就以一些實際場景為例,介紹如何基于操作審計,監控雲上異常操作或操作頻率,進行報警。

技術方案

操作審計記錄了雲賬号在阿裡雲上的所有操作事件,例如 OpenAPI 調用、售賣頁購買資源等。使用者可以使用操作審計的跟蹤功能,将賬号下的操作事件投遞到指定的 SLS,接下來就可以利用 SLS 的報警能力,針對異常事件進行報警。

監控異常操作頻率并報警

實作步驟

實作過程分為兩步:

  1. 建立跟蹤:将雲賬号的操作事件投遞到 SLS
  2. 配置報警:在 SLS 中,根據不同場景配置報警規則

建立跟蹤

如果您的賬号中已經有投遞到日志服務 SLS 的跟蹤,則可以跳過這一步驟

操作審計預設會幫助您記錄賬号内最近 90 天的記錄檔,但如果想要實作自定義監控報警,則需要建立一個跟蹤,并設定投遞到日志服務 SLS 中,利用 SLS 實作監控報警。

• 如果您習慣控制台操作,則可以參考

這篇文檔

,在

操作審計控制台

中,完成跟蹤建立

• 如果您希望通過通過 SDK 調用 API 來操作,則可以參考操作審計的

CreateTrail API 介紹

• 如果您希望使用 IaC 方案自動化建立跟蹤,則可以參考:

使用 阿裡雲資源編排 ROS 建立 操作審計跟蹤 使用 Terraform 建立操作審計跟蹤

建立了跟蹤後,操作審計就會持續且實時地将您雲賬号下的操作事件投遞到您指定的 SLS 中。

報警設定

設定報警可分為以下幾個步驟:

• 确定異常操作事件

• 針對異常事件編寫 SLS 查詢語句

• 根據查詢結果進行報警

接下來本文将針對一些常見場景,結合真實案例描述如何設定報警。

常見場景

監控主賬号登陸

真實案例

當企業對雲資源進行管控的時候,為了進行權限控制,一般都是使用子賬号,很少直接使用主賬号。是以企業希望主賬号一旦登陸,就進行報警。這樣當主賬号可能密碼洩漏、非法登陸時,能及時發現。

步驟一:确定登陸事件

在操作審計中,登陸事件名稱為 ConsoleSignin 。

登陸事件中 userIdentity 标記登陸者資訊:

• userIdentity.type 如果為 root-account 則表示主賬号; ram-user 表示 RAM 使用者;

• userIdentity.accountId 是主賬号 ID;

• userIdentity.pricipalld 是當登陸者的 ID,如果是主賬号登陸就是主賬号 ID,如果是子賬号登陸就是子賬号 ID。

登陸事件如圖所示:

監控異常操作頻率并報警

操作事件主要有以下幾類:

• ApiCall 阿裡雲 OpenAPI 調用事件,其 eventName 字段就是 API 名稱

• PasswordReset 密碼重置事件

• ConsoleSignin 控制登陸事件

• ConsoleSignout 控制台登出事件

• AliyunServiceEvent 執行個體到期自動釋放事件

• ConsoleOperation 其他控制操作

關于事件結構定義可參考文檔:

操作事件結構定義

步驟二:查詢主賬号登陸事件

了解了以上資訊,就可以編寫 SQL 查詢主賬号登陸事件了。查詢條件就是 eventName 為 ConsoleSignin ,且 event.userIdentity.type 為 root-account 。

* | SELECT  COUNT(*) as count FROM log WHERE "event.eventName" = 'ConsoleSignin' AND "event.userIdentity.type" = 'root-account'.           

如圖所示,查詢出來主賬号在 15 分鐘内有 1 次登陸。

步驟三:配置報警

點選 “另存為告警”,就可以針對上述查詢結果進行報警。

假設我們希望主賬号隻要登陸控制台就報警,則可以配置報警規則為:每隔 5 分鐘,查詢 5 分鐘内主賬号登陸事件數量,如果有大于等于一次登陸就報警。如果想要報警更及時,則可以調整間隔時間和查詢區間。

配置如下:

監控異常操作頻率并報警

$0 表示第一條查詢語句, $0.count 就是查詢結果中的 count 字段。接下來再完善通知資訊即可,這裡不再贅述。

關于 SLS 報警配置的詳細說明可參考文檔:

日志服務-告警
報警示例

假設前面配置了釘釘群報警,則一旦主賬号登陸,就會收到類似下圖的報警:

監控異常操作頻率并報警

高危操作報警

某企業網站突然打不開了,經排查發現原來是 SSL 證書被誤删了,導緻 CDN 資源都無法通路。

資源删除操作是個高危操作,如果資源在被删除時能有報警,就能及時發現甚至避免業務故障了。

解決方案

要針對資源删除進行報警,就需要列舉出删除資源的 API,可以在對應雲産品文檔中找到删除相關的 API;為了簡單,也可以模糊查詢 Delete 或 Remove 開頭的 API,這類 API 基本是删除操作。

查詢條件
* | SELECT "event.serviceName" AS service, "event.eventName" AS event, COUNT(*) AS count FROM log WHERE "event.eventName" LIKE 'Delete%' OR "event.eventName" LIKE 'Remove%' GROUP BY service,event ORDER BY count DESC           
觸發條件

$0.count > 0 即隻要有資源删除,就報警。

報警通知發送内容

${Results[0].RawResultsAsKv} ,即發送文本格式的查詢結果,查詢結果可能有多項。

監控異常操作頻率并報警

收到報警後,就能及時在跟蹤投遞的 SLS LogStore 中查詢到删除操作以及操作者。

高頻失敗調用報警

某運維在檢視日志時,發現某 AccessKey 在一段時間内頻繁出現 403 的錯誤。經過排查發現,是因為該 AccessKey 沒有權限,但一直在嘗試調用雲服務。

此外還有其他調用失敗的情況,這些調用失敗,可能是權限問題,也可能是使用方式不正确。如果能針調用失敗進行報警,就能及時發現并解決問題。

操作審計記錄了所有雲服務調用操作,并且針對異常調用記錄了錯誤碼。是以可以通過有無錯誤碼來判斷調用是否正常。

• event.errorCode 錯誤碼,如果有該字段,則表示調用出錯

• event.errorMessage 錯誤消息,如果有該字段,則表示調用出錯

因為正常調用 API 也可能出錯,是以為了讓報警更準确,可以根據頻率來報警。最終設計報警規則為:每 5 分鐘執行一次,查詢目前 5 分鐘至的錯誤總數 x,和前 5 分鐘至前 10 分鐘錯誤總數 y,如果 x 相比 y 增長了 30%,則報警。

* |
SELECT
  count_old AS "前10分鐘至前5分鐘接口調用失敗",
  count_new AS "前5分鐘至現在接口調用失敗",
  if(count_old > 0, round((count_new-count_old + 0.0) / count_old, 6), 0) AS res
FROM  (
    SELECT
      SUM(
        CASE
          WHEN "event.errorMessage" IS NOT NULL
          AND __time__ >= to_unixtime(date_add('minute', -10, current_timestamp))
          AND __time__ < to_unixtime(date_add('minute', -5, current_timestamp)) THEN 1
          ELSE 0
        END
      ) AS count_old,
      SUM(
        CASE
          WHEN "event.errorMessage" IS NOT NULL
          AND __time__ >= to_unixtime(date_add('minute', -5, current_timestamp))
          AND __time__ < to_unixtime(date_add('minute', 0, current_timestamp)) THEN 1
          ELSE 0
        END
      ) AS count_new
    FROM log
  )           
注意:上述查詢條件中,根據 event.errorMessage 是否為 NULL 來決定是否調用異常。因為目前操作審計建立跟蹤時,預設建立的 SLS Project 及 LogStore 中,将 event.errorMessage 加入了索引;而 event.errorCode 沒有加入索引。是以如果要使用 event.errorCode 作為查詢條件,需要将其加入索引。

$0.res > 0.3 即錯誤率增長 30% 就報警。

總結

本文基于一些真實案例,介紹了如何基于操作審計對雲上資源異常操作進行監控報警,提高雲上資源管控的安全性。當然,實際可能還會有更複雜的場景。希望通過本文的介紹,大家能夠舉一反三,實作更貼合自己業務的報警。

繼續閱讀