Rewst做對的部分
讓我們從正面論述開始。Rewst確實解決了一個真實的問題。在Rewst(以及Liongard和一些類似工具)出現之前,MSP在跨租戶的PowerShell自動化上只有兩個糟糕的選擇:要麼分別登入每個客戶租戶在本地執行腳本,要麼用服務帳號與排程器自建編排系統。兩者都難以規模化。
Rewst將「從單一控制台對N個客戶租戶執行PowerShell」的模式產品化。它在這方面表現良好。採用它的MSP在可重複的動作上——使用者佈建、授權指派、群組管理、信箱設定——每週能節省實實在在的時數。
我們並不是說Rewst是一個糟糕的產品。我們是說它圍繞著錯誤的軸線設計。
腳本優先架構做錯的部分
一個PowerShell腳本是一個執行產物。你讀程式碼、執行它、獲得輸出。
但將使用者加入Global Admin群組的腳本不只是程式碼。它是一個授權事件,兩年後稽核員會想要重建它。重設使用者密碼並寄送到備用地址的腳本也不只是程式碼——它是一個合規事件,可能是法律保全事件,甚至可能是客戶信任事件(如果選錯了地址)。
腳本優先的自動化平台將腳本視為主要產物,而將治理視為事後才加上的中繼資料。執行紀錄有、審批流程有、遮蔽功能也有。但它們是疊加上去的,在MSP的營運層,而不是原生內建。
在實務中會出現的問題:
- 審批層是工作流程級別,而非動作級別。 工作流程一旦啟動,內部的個別動作就會執行,沒有逐動作審查。對於已知安全事件中的批次密碼重設還好。若工作流程的某條分支出錯,就沒那麼好了。
- 紀錄中的敏感輸出是MSP的問題。 服務帳號Token、一次性復原碼、產生的密碼——如果PowerShell將它們送到stdout,它們就會進到執行紀錄裡。遮蔽它們成了清理步驟,而不是管道的一等公民。
- 稽核故事是以執行為中心,而非以變更為中心。 「在哪一天對這個客戶租戶執行了什麼PowerShell?」是可以回答的。「下午3:47誰授權了使用者X的權限變更?」有時可以,有時不能——因為授權可能是工作流程組態的隱含結果,而非一個離散事件。
這些不是假設性的抱怨。這正是SOC 2審查員、CMMC評估員和HIPAA稽核員會向建立在自動化腳本之上營運的MSP提出的具體稽核問題。
治理優先:改變了什麼
JieGou的自動化層從一個不同的前提出發:客戶租戶是治理邊界,任何跨越該邊界的動作都是可審查的事件。
由此產生的後果:
-
逐動作審批,而非逐工作流程。 「重設CEO的密碼並寄到其復原地址」的任務是單一可審查事件。審批者在核准前能看到渲染過的PowerShell、目標租戶、以及該動作的影響範圍。逐工作流程審批(Rewst/Liongard模式)將審查點與組合點混為一談——你一次核准了「這個工作流程看起來沒問題」,然後它所有的分支就會依序觸發。
-
影子模式是一等公民層級,不是工作流程的變體。 每個動作都能以影子模式執行:PowerShell已準備好、輸入已解析、輸出已模擬——但不會真正呼叫Microsoft Graph / Exchange等等。MSP操作員能精確審查將會發生什麼事。確認後才提升到正式執行。
-
輸出遮蔽內建於Runner管道。 PowerShell Runner擷取stdout/stderr,經過遮蔽處理(移除Token狀、密碼狀與其他敏感樣式的字串),只將遮蔽後的版本存入稽核紀錄。操作員在UI上看到的也是遮蔽後的版本。原始輸出永遠不會被保存。
-
AI產生的動作走同一條管道。 這是在架構上具有實質意義的差異。當AI草擬被準備好——無論是PowerShell片段、工單回覆、還是工時寫入——它進入與人類發起動作同一個審批佇列。MSP操作員不需要分別治理「AI做的事」和「腳本做的事」。只有一個佇列。
-
緊急覆寫是受稽核的,而非無紀錄的。 有時故障等不得。Owner和Admin角色可以在提供理由後覆寫待審批。覆寫動作、理由、審批者身分,以及原始請求都會被完整保留。覆寫機制為緊急情況存在,而非捷徑。
並排比較的樣貌
我們在PowerShell自動化功能頁上發佈了逐功能比較。歸納最關鍵的那一行:
逐動作審批。 Rewst:只在工作流程層級;一旦流程執行,個別動作就會觸發,沒有逐動作審查。 JieGou:個別動作層級——逐個變更核准或駁回,並可看到渲染後的PowerShell。
如果你將工作流程設計為單一動作分支,或許可以勉強主張這兩者是一樣的。沒錯。但對一個擁有20個客戶的MSP來說,工作流程不會保持那麼整齊,而且組合更大工作流程的壓力會隨著規模而增長。逐動作審批讓可審查的單位保持在正確的粒度。
Rewst仍然是正確選擇的時機
我們並不打算假裝JieGou適合所有MSP。Rewst仍然更適合的情況:
- 你已經在Rewst上標準化了自動化程式庫,團隊也已有一年的肌肉記憶。切換成本是實實在在的。
- 你的MSP的價值主張是「我們積極自動化,治理是次要關切」。 這是一個可以站得住腳的定位。JieGou是為將治理視為一等公民的MSP而生。
- 你需要某個我們未支援的Rewst原生整合。 我們涵蓋常見的MSP整合(ConnectWise Manage、Microsoft Graph、Exchange、Intune、Azure AD),但Rewst在某些利基上有更深的目錄。
市場走向我們的看法
MSP通路在「AI for MSPs」的對話上已進行了18個月。有兩件事已經移動:
-
合規買家(在MSA條款中要求SOC 2證據的MSP)想要治理原生的自動化。 不是「我們在上面加上治理」。他們希望用來做MSP營運的平台,也就是回答稽核員問題的平台——同一個稽核紀錄、同一條審批軌跡、同一套遮蔽機制。
-
AI輔助的動作在任何營運意義上都不再獨立於腳本動作之外。 如果你的MSP的AI層起草工單回覆,你的MSP的自動化層寫入工單的工時條目,且兩者都穿過同一個客戶租戶,那麼它們應是同一條管道。而不是兩條需要對帳的管道。
JieGou是為這兩項市場轉變而建的。Rewst不是——這是設計使然。這並不使Rewst錯誤。它只是為不同的MSP而設計的不同產品。
如果那個不同的MSP就是你,你應該繼續使用Rewst,這篇文章剩下的部分就不是寫給你的。
如果你是那個想要治理原生、AI原生、稽核原生營運的MSP——我們很樂意為你展示整條管道從頭到尾的運作。預約Demo或進行營運失血稽核以了解你目前的缺口會付出什麼代價。