7. 誰會看到什麼

在哪個畫面

• 簽核任務只出現在「開放防禦 ／ 資安案件處置中心」，不會出現在表單中心的待簽核清單。平台把資安分類的案件從一般表單中心隔開。
• 處置中心的「僅我可簽核」預設是開著的，清單只列輪到自己這一關的案件。決策按鈕的名稱與數量來自流程的簽核節點設定；按下按鈕就完成這一關的簽核。
• 處置中心的清單不會自動更新，新案件要按「重新整理」才會出現。清單上每件案子的 SLA 倒數（嚴重度 4 以上 15 分鐘、等於 3 為 60 分鐘）由建案時間起算，只是顯示，與流程的計時軌互不影響。
• 緊急廣播是全頁彈窗，出現在平台的任何一頁，由瀏覽器定時向平台查詢（預設每分鐘一次，這是企業層級的設定值）。需要確認的廣播要捲到底、勾選「我已閱讀並知悉以上訊息」、按「已知道」才能關閉，並留下確認紀錄；不需確認的廣播只有一顆「關閉」。企業管理員可在「緊急廣播管理」頁查看每一則廣播的確認名單。廣播對象指定角色時，看的是收件者當下持有的有效角色。
• 廣播的標題與內文會把 ${f.finding_title} 這類變數換成案件的實際值；替換進來的值一律做 HTML 跳脫，所以事件標題裡就算夾帶標籤或指令碼，也只會以文字顯示。設計者自己寫在內文裡的標籤則保留。

簽核意見最少 10 個字的用意

處置意見是日後稽核時唯一能回答「當時為什麼這樣判斷」的東西。標準版只要求 2 個字，實務上會收到大量的「ok」。10 個字的門檻強迫簽核者至少寫出一個判斷依據。字數不足時，處置中心會直接擋下並顯示需要的最少字數，平台端也會再檢查一次。

二線角色必須加進處置中心的選單角色需求

處置中心這個選單對一般員工的可見性由「選單角色需求」決定。建置腳本建立資安主管角色時，會一併把它加進「資安案件處置中心」與「儀表板」兩個選單的角色需求。自行新增其他資安角色（例如把一線再分成兩級）時必須比照辦理，否則只持有新角色的人被指派了簽核任務，卻打不開處置中心，而簽核任務又不會出現在表單中心，這個人實際上無處可簽。

8. 可調參數

在流程設計器裡點開這兩個暫停節點之前，先知道這件事
症狀：只是點開「SLA 計時 15 分」看一下再存檔，催辦時間就從 15 分鐘變成 16 分鐘；在面板輸入 600 秒想改成 10 分鐘，實際變成 25 分鐘。不會有任何錯誤訊息。
原因：這兩個節點由建置腳本寫入的設定是 delay_minutes: 15，而流程設計器的暫停節點面板只有「延遲秒數」一欄（對應 delay_seconds，欄位空白時顯示預設值 60）。平台計算等待時間時會把秒、分、時相加；面板寫入秒數時不會清掉原有的分鐘數，而且節點面板開著的狀態下儲存流程，面板上的值就會被寫回。
正確做法：要調整這兩個時間，修改建置腳本頂端的常數後重建（見下方指令）；重建會同時更新廣播內文與節點名稱裡的分鐘數。

改完一定要重新發行

事件進來時讀的是該表單最新的已發行版本，不是設計區的內容；改了不發行等於沒改。已經在跑的案件使用建案當下的快照，不受後續修改影響。

用建置腳本重建

cd <平台安裝目錄>
set -a && source .env && set +a
venv/bin/python scripts/examples/provision_od_workflow_variants.py --org <企業 secure_code>            # 預演，只印出將要做的事
venv/bin/python scripts/examples/provision_od_workflow_variants.py --org <企業 secure_code> --apply    # 實際建置
venv/bin/python scripts/examples/provision_od_workflow_variants.py --org <企業 secure_code> --apply --force   # 既有流程覆寫並重新發行

• 腳本是冪等的：角色、選單角色需求、表單、流程、配對、發行，已存在的就沿用。流程已存在時，不加 --force 不會覆寫內容。
• --force 會用腳本裡的定義整份覆寫流程與表單並重新發行，而且 SOC 團隊版與小企業單人版兩個一起覆寫。在流程設計器手動改過的內容會消失，執行前請確認。
• 常數在 scripts/examples/od_workflow_graphs.py 頂端：SOC_SLA_WARN_MINUTES、SOC_SLA_ESCALATE_MINUTES、SOC_BLOCK_TTL_SECONDS、PUBLIC_IP_REGEX。
• --supervisor 指定由誰兼任資安主管；--with-routing 一併建立停用狀態的路由規則範例。
• 腳本需要該企業已有標準版的表單 SEC_INCIDENT_RESPONSE（欄位定義從它複製）與資安人員角色。

9. 已知限制與可討論的設計題

以下是這個流程目前做不到、或刻意不做的事，依原始碼與流程定義查證後如實列出，作為討論素材。每一條寫「現況、影響、可行的改法」。改法是方向，未隨附於出廠流程，採用前請在測試企業驗證。

9.1 計時軌的涵蓋範圍

中危案件沒有計時軌
現況：只有「高危」規則會同時啟動計時軌。中危只有處置中心清單上的 60 分鐘顯示，流程不會出聲。
影響：中危案件可以無限期掛著（含升級到二線之後）。
可行的改法：比照高危的做法，讓「中危」規則也勾兩條出線，另拉一條較長的計時軌，檢查節點的條件照抄高危那兩個即可。注意廣播量會跟著增加。

設計說明：升級二線之後，計時軌催的是二線；但「人工封鎖確認」不在計時軌的視野內
現況：計時軌的判定條件涵蓋一線與二線（見第 6 節 (h)），升級後二線沒處置照樣催辦與通報。但一線或二線選了「封鎖」而來源位址無法自動封鎖時，案件會停在「人工封鎖確認」等資安人員；此時 soc_decision 已是 block（或 l2_decision 已有值），計時軌判定為「已完成處置」，不會催辦。
影響：內網來源的高危案件，在按下封鎖之後可以無限期停在「人工封鎖確認」，流程不會出聲；處置中心清單上的 SLA 倒數仍會顯示逾時。
可行的改法：把「尚未完成處置」的條件再加一組：manual_block_decision 為空且案件已走到人工封鎖確認。前者可以用流程變數判斷，後者需要在「無法自動封鎖註記」之後加一個設定變數節點留下標記，再把它納入條件。

30 分鐘之後沒有第三步；夜間與假日只會催辦與通報
現況：計時軌在通報主管後就結束，簽核任務沒有期限。暫停節點算的是絕對時間，不分上下班。這個流程在任何情況下都不會自動寫入封鎖決策。
影響：這是刻意的設計（前提是有人輪班），但如果夜班或假日實際上沒有人，高危案件會一直掛到有人上線；廣播是瀏覽器彈窗，沒有人開著平台就沒有人看得到。對照之下，小企業單人版在非上班時段會自動寫入 24 小時的封鎖、上班後再由人複核。
可行的改法：（一）用事件路由把特定來源或條件的案件改走小企業單人版；（二）在計時軌尾端依時段分流，非值班時段接一個有短期限的自動封鎖決策，並保留人的簽核任務以便推翻。流程可用的時間變數 ${t.time} 是 UTC，而且沒有「星期幾」，時段判斷只能用正規表示式比對、不能分平日假日；（三）要在無人開啟平台時也能通知到人，需改用 Email 或 Telegram 類通知節點，並先完成對應的發信設定，否則節點失敗會卡住那條分支。

9.2 緊急廣播的性質

廣播是「每個代碼一則」，不是逐案通知
現況：廣播代碼不做變數替換（只有標題與內文會），三個節點的代碼是固定字串。同一個代碼再次發出時，會覆蓋前一則的標題與內文，並清掉所有人的確認紀錄。
影響：兩件高危案件先後逾時，第二則催辦會蓋掉第一則；主管若還沒確認第一則升級通報，就只會看到第二則。廣播適合回答「現在有沒有案件逾時」，不適合當作逐案的稽核軌跡。
可行的改法：逐案的事實以簽核紀錄、決策紀錄與 sla_track 為準；需要逐案送達的通知改用 Email 或 Telegram 類節點。

不需確認的廣播，關閉後會再跳出來
現況：不需確認的廣播，彈窗上的「關閉」只關掉畫面，不寫確認紀錄；平台回傳有效廣播時只排除「已確認」的，所以下一次查詢（預設一分鐘後，或換頁時）同一則會再出現，直到同代碼的新廣播取代它。緊急廣播管理頁目前只能查看確認名單。
影響：「SLA 逾時催辦」與「封鎖完成通報」都設為不需確認，它們會反覆打斷對象內的所有人，直到同代碼的新廣播取代。
可行的改法：改成需要確認（每人確認一次後不再出現），或由平台補上「關閉後不再顯示」與下架廣播的機制；已回報平台開發團隊。

9.3 簽核與指派

角色池先到先得，沒有值班表，也沒有「我來處理」的認領
現況：簽核任務對整個角色開放，當下持有角色的人都可以簽。平台有一個防止兩人同時簽同一關的鎖定（有效 10 分鐘），但處置中心是在按下決策按鈕的那一刻才取鎖並立即送出，所以它只防重複送出，不代表「某人正在處理這件案子」。
影響：3 到 8 人的規模下，靠口頭協調還可以；人數再多，會出現兩個人同時研究同一件案子、或每個人都以為別人在看。催辦廣播也是發給整個角色，不是發給當班的人。
可行的改法：這是值得討論的題目：值班表應該放在平台裡，還是放在 SOC 自己的排班工具、平台只負責催辦？若要在平台內區分班別，現有機制下可行的方向是把班別做成不同角色、由路由或分支決定案件給哪一班。

主管收到升級通報，但不一定能接手
現況：升級通報發給資安主管，但一線的簽核任務只認資安人員角色。只持有資安主管角色的帳號無法簽一線的任務。
影響：主管被通知後能做的是調度人，而不是自己處置（升級到二線的案件除外，那本來就是主管的任務）。示範企業 DemoSOC 裡就同時有「兩個角色都有」與「只有資安主管」兩種帳號。
可行的改法：讓主管同時持有資安人員角色；或在「升級通報主管」之後不要直接收尾，而是改變案件的指派對象（需要重新設計計時軌與簽核節點的關係）。

封鎖前檢查只認內建範圍，不讀企業自訂的保護清單與豁免
現況：「封鎖前檢查」用一條正規表示式判斷來源位址能不能自動封鎖，範圍對齊平台內建的保護網段。企業在「封鎖保護清單」另外加的自訂網段（例如辦公室對外 IP、合作廠商）它不知道；反過來，企業為某個內網位址設了豁免，它也不知道。
影響：（一）來源落在自訂保護網段的案件會通過檢查，然後在「寫入封鎖決策」被保護清單拒絕：節點最多執行 3 次即標為失敗，案件停在那一格、狀態仍是進行中，沒有人有待辦，封鎖完成通報不發，計時軌也因為 soc_decision 已有值而不出聲。這正是封鎖前檢查要避免的情況，只是縮小到自訂網段這一類。（二）設了豁免的內網位址仍會被導向人工封鎖確認，沒辦法從流程自動封鎖。
可行的改法：企業有自訂保護網段時，把那些網段加進「封鎖前檢查」的規則（另加一條「不符合自訂網段的正規式」條件）；或把「寫入封鎖決策」的「命中保護清單時」設為「略過並繼續流程」，並在後面用分支依節點結果決定是否改走人工。要從流程自動封鎖豁免的內網位址，需在檢查規則裡放行那個位址。

9.4 案件資料

聚合降噪：同來源、同規則，60 分鐘內只有一件案子
現況：併案的條件是來源位址與規則 ID 都相同、且在 60 分鐘內；一般只併進進行中的案件，嚴重度 2 以下則連已結案的也併。標準格式與原生格式的事件互不併案。併案時嚴重度取較高者，但流程已經分流過，不會重來；「情報摘要」那段文字是建案時寫的，也不會更新。
影響：（一）測試時連續送出內容相同的事件，第二筆之後不會開新案，看到的永遠是第一件案子的軌跡；要重測請換來源位址或規則 ID。（二）一件以中危開案的案子，後來併進高危事件，表單上的嚴重度會變成 4，但它走的仍是中危那條路，沒有計時軌。
可行的改法：第二點目前沒有流程內的解法（分流只在建案時執行一次）；若這種情況在貴組織常見，值得討論是否讓嚴重度升高的事件不併案、另開新案。

決策紀錄本身不記錄是誰決定的
現況：由流程寫入的防禦決策，決策來源會標為「人工」，但決策紀錄上的決策者欄位是空的。
影響：在決策列表看得到「人決定的」，看不到「哪個人」。要追到人，得從決策回到案件，看該案件的簽核歷程與處置意見。
可行的改法：平台端的改善項目，已回報平台開發團隊。現階段可在理由範本中加入流程變數，補充可辨識的資訊。

時間一律是 UTC 與絕對時間
現況：這個流程沒有使用任何時間變數，兩個暫停節點算的是絕對時間（24 小時制、不看班表）。流程可用的時間變數（${t.now}、${t.date}、${t.time}）是 UTC，沒有星期幾。畫面上顯示的時間則依使用者的時區換算。
影響：現行流程不受影響。但只要加入「上班時段」這類判斷，就必須以 UTC 撰寫條件；換時區或調整上班時間時要記得改。
可行的改法：需要「只在工作時間倒數」的語意時，簽核節點的「簽核逾時」提供依簽核者班表計時的方式，但它的行為是逾時後替人選擇決策，與本流程的計時軌用途不同，採用前請先確認這是不是你要的。