從零開始建立安全計畫

被聘為公司首位安全人員是特定的混亂。沒有問題單隊列、沒有既定的工具、通常也沒有預算等著你。下面是最初 90-180 天通常如何進行的粗略地圖，以及什麼實際上能改變局面，什麼只是看起來有成效。

"沒有" 通常意味著什麼

當人們說公司沒有安全職能時，他們很少是指完全沒有控制。他們是指沒有專責人員。工程部門可能已啟用了一些基本的 AWS IAM 政策，IT 部門透過 MDM 工具部署了一些防毒軟體，財務部門有人對 SOC 2 有意見，因為某個客戶問過。你的第一項工作是清點，而不是實施。在寫任何政策之前，找出已經在運行的東西：雲帳戶（以及有多少個沒人記得建立過）、擁有原始碼管理員存取權的 SaaS 工具，以及是否有員工離職的單一信息源。用試算表可以做這個。GRC 平台現在還不是優先考量。

前 30 天：可見度優於控制

避免在第一週寫可接受使用政策的衝動。沒人會讀它，它也不會阻止實際的風險。相反，獲取三件事的可見度：

• 身份識別：從身份識別提供者（Okta、Google Workspace、Azure AD）拉取完整使用者清單，並與 HR 的在職員工清單交叉參照。你會找到幽靈帳戶。
• 雲足跡：如果你在 AWS 上，執行 aws organizations list-accounts 之類的工具，或檢查 GCP 的 Asset Inventory，看看有多少環境存在，而不是有多少環境有人能從記憶中說出來。
• 程式碼和秘密洩露：對你的主要儲存庫執行 gitleaks detect 或 trufflehq filesystem .。找到兩年前提交歷史中硬編碼的 API 金鑰幾乎是必然的，這是快速展示價值的方式。

記錄調查結果，但不要把這變成 40 頁的報告沒人翻開。一頁的風險摘要配五個重點會被 CTO 閱讀。冗長的 PDF 不會。

挑選前三個控制

沒有人手和工具預算，你無法一次做所有事情。通常有效的操作順序：

1. MFA 應用到所有尚未實施的地方，從身份識別提供者開始，然後是 GitHub/GitLab，再來是雲主控台。光這一項就關閉了最常見的帳戶接管路徑。
2. 雲和認證事件的集中日誌記錄。即使只是 SIEM 相鄰工具的免費級別，或只是將 CloudTrail/GCP 稽核日誌傳送到有保留期的儲存桶，也比發生事故時什麼都沒有要好。
3. 書面的簡短事故回應計畫，即使只有兩頁：誰被呼叫、誰與客戶溝通、誰有權關閉東西。沒人會記得在需要之前建立這個，到了那時候已經太晚了。

注意這些都不需要大型廠商合約。它們需要決定和後續追蹤。

不靠安全預算爭取支持

身為首位安全聘僱者最快失去信譽的方式，是在展示任何成果之前就拿著工具清單出現。相反，將每項要求與具體情況掛鉤："我們找到三個 IAM 使用者有未輪換的 2021 年存取金鑰" 比 "我們需要 CSPM 工具" 更有說服力。用工程和財務已經關心的術語框架化要求：減少爆炸半徑、更快的稽核、更少的凌晨 2 點呼叫。如果公司在追求 SOC 2 或 ISO 27001，該合規期限通常是你爭取資源的最佳槓桿，即使合規本身不是目標。

第一年的常見錯誤

在你有流程或人手實際操作之前購買昂貴的平台（SIEM、EDR、CSPM）是早期預算最常見的浪費。沒人調整的 5 萬美元工具會產生雜訊，而不是偵測。同樣，寫從範本複製而來而不適應公司實際運作方式的政策，保證在有人第一次需要例外時就會被忽視。試著在前六個月之後獨自擁有所有東西是倦怠路線；一旦有動力，下一次聘僱通常應該是可以擁有偵測和回應的人，這樣你就可以繼續建立計畫結構。

從零開始的安全主要是關於序列：看看存在什麼、關閉最明顯的差距、建立足夠的流程使決策不依賴你的記憶，然後從那裡擴展。

如果這種基層計畫建立讓你感興趣，Korra Studio 有關於事故回應基礎和雲安全態勢的相關片段，可與這個配對。