外包夥伴用自己的筆電
登入公司後台
為什麼現在很紅：MDM 管得到公司筆電，管不到外包的私人電腦；外包拿到的權限，卻常常和正職一樣大。
- 一句話結論
- MDM 只管得到公司設備；外包工程師、兼職人員用自己的電腦登入公司系統，公司完全不知道那些電腦的狀態。
- 他要的是什麼
- 他不用打穿你的公司筆電。外包工程師家裡那台沒人管的電腦，登入狀態一樣能打開你的私有 repo。
- 你今天做一件事
- 今天就列出所有外包帳號：誰、能碰哪些 repo、有沒有到期日。沒有到期日的，先補上。 直接去做 →
- 哪些能信
- 2 可證明2 推論1 缺口 每個主張都標了等級，缺口是誠實寫出來的。
- 破口速查
- 受害端一律去識別化；寫「未公開」代表公開資料查不到。
- 伺服器服務商
- 不適用（示意情境；涉及的是外包人員的私人電腦與公司的程式碼平台、雲端後台）
- 網路服務商
- 不適用（同上）
- 漏洞出現的地方
- 管理層與合約：外包與 BYOD 設備不在 MDM 內，公司不知道設備狀態；外包權限和正職一樣大；合約沒寫設備安全要求與事件通報義務；專案結束後帳號沒收回
- 馬上自我檢測
列出所有外包人員與他們能存取的系統、repo、環境 程式碼平台組織成員清單 → 篩出外包帳號，檢視可存取的 repo 範圍（唯讀） 確認外包帳號是否都有到期日與兩步驟驗證 檢視現行外包合約是否有設備安全要求與事件通報條款- 漏洞修補方式
- 合約寫明設備最低安全要求、事件通報時限與結束合作時的資料刪除義務；外包用專屬帳號或群組並設到期日，權限只開專案需要的 repo 與環境；強制兩步驟驗證並優先抗釣魚方式；每季請外包填設備檢查表；程式碼裡不放正式環境金鑰；外包名單納入離職流程
有 15 分鐘再看：其餘 2 點
- 外包權限常常和正職一樣大，合約沒寫設備要求與通報義務，專案結束後帳號也常常沒收回。
- 外包人數少的話，合約、獨立帳號、到期日、兩步驟驗證、結束即收回就能處理大部分風險；要實際驗證設備狀態，才需要工具，而且要先取得對方同意。
公司筆電都裝了防毒、開了加密、納入 MDM，但每天登入公司系統的不只公司筆電：外包工程師的私人電腦、兼職設計師的 MacBook，MDM 一台都管不到。這篇講外包與 BYOD 設備怎麼用合約、帳號與流程補起來。
本篇目錄
MDM 一台都管不到的那幾台
公司的筆電都裝了防毒、開了加密、納入 MDM，IT 覺得終端設備已經顧好了。可是每天登入公司系統的，不只是公司的筆電：外包工程師的私人電腦、兼職設計師的 MacBook、業務在家用的平板，還有一位堅持用 Linux 的工程師。這些設備，MDM 一台都管不到。
先說清楚，以下是示意情境，不是真實事件，公司與經過都是為了說明而設。假設有一家三十人的軟體公司，長期和三家外包團隊合作，外包人員用自己的電腦登入公司的程式碼平台和雲端後台。某家外包團隊的一位工程師電腦中毒，他的程式碼平台登入狀態被盜用，攻擊者複製了好幾個私有 repo。公司事後才發現，自己完全不知道外包人員的電腦是什麼狀態。
這篇要講的只有一件事：管不到對方的電腦，就要管好對方能碰到什麼。
外包與 BYOD 設備，風險在哪裡
第一層是 MDM 管不到。外包和 BYOD 設備通常不能、也不適合納入公司的 MDM；那是別人的電腦，公司沒有立場去裝管理程式。
第二層是權限常常過大。為了方便，外包拿到和正職一樣的權限，能看到的 repo 和環境遠超過他負責的專案。
第三層是合約沒寫。設備安全要求、事件通報義務，沒有寫進合約，出事時對方沒有義務告訴你，你也沒有依據要求什麼。
最後是結束合作時漏收。專案結束，帳號和權限還在。
這篇示意情境裡，被帶走的是什麼
這是示意情境，沒有實際外洩；下表列的是這類事件裡最直接被盜用、以及最可能跟著被帶走的東西，讓你知道一台外包電腦中毒的影響範圍有多大。
| 服務 | 憑證類型 | 用途 | 存在形式 | 放在哪 | 權限範圍 | 狀態 |
|---|---|---|---|---|---|---|
| 外包工程師的程式碼平台登入狀態 | 瀏覽器 session 或程式碼平台存取權 | 讓外包工程師存取公司的私有 repo | 存在外包工程師的私人電腦上 | 中毒的那台私人電腦 | 示意情境中和正職一樣，涵蓋多個私有 repo | 示意情境；未停用或撤銷前持續有效 |
| 被複製的私有 repo 裡可能存在的密鑰 | 未公開：可能是 API 金鑰、資料庫連線字串等 | 程式連線正式環境或第三方服務 | 原始碼常數或設定檔 | 被複製的 repo | 未公開 | 未公開：示意情境中尚未掃描 |
| 外包人員的雲端後台帳號 | 帳號密碼 | 部署與維運 | 存在外包人員的私人電腦或記憶裡 | 外包人員的設備 | 依當初開的權限 | 示意情境；專案結束後常未收回 |
三列的共同點是：存取權發給了一個人，但那個人用的是哪台電腦、電腦是什麼狀態，公司一無所知。
能證明的、只能推論的
這篇是觀點文，情境是示意的，所以能證明的只有官方文件寫明的功能；情境裡的經過只能算推論。
不花錢就能做的流程
到這裡，其實已經足夠理解問題在哪。如果你想直接動手，可以跳到「今天就可以來試試」；下面是完整的六步流程。
第一步，合約寫清楚。 設備最低安全要求（作業系統更新、全碟加密、防毒、螢幕鎖定）、事件通報時限、合作結束時的資料刪除義務。請法務協助。
第二步，外包帳號獨立並設期限。 用專屬的外包帳號或群組，設定到期日；權限只開專案需要的 repo 和環境。
第三步，強制兩步驟驗證，優先使用抗釣魚的方式。 外包帳號和正職一樣，強制兩步驟驗證。
第四步，定期自我聲明。 每季請外包團隊填一份簡單的設備檢查表，例如更新日期、加密狀態。雖然無法驗證，至少建立責任。
第五步，密鑰不放在程式碼裡。 外包會看到程式碼，就不要讓程式碼裡有正式環境的金鑰。這一步做到了，上面那個 gap 的影響就小很多。
第六步，結束合作當天收回。 外包名單納入離職流程，專案結束就停用帳號。
什麼時候不需要買工具
外包人數少、只碰少數系統的話，「合約、獨立帳號、到期日、兩步驟驗證、結束即收回」就能處理大部分風險。需要實際驗證外包設備狀態時，才需要裝置檢查工具，而且要先取得對方同意。
真的要看工具，市面上大致分四類。身分平台內建的最先查：Google Workspace 的 Context-Aware Access（限特定版本）、Microsoft Entra 條件式存取，可以依裝置或其他條件限制存取，但未納管的 BYOD 能提供的裝置資訊有限。隔離的工作環境，例如雲端桌面或瀏覽器隔離類產品，讓外包在受控環境中工作，資料不落地到私人設備。開源的有 Fleet（原始碼公開的裝置管理平台），對方同意安裝的話可以使用。商用裝置信任例如 1Password Device Trust，官網說可以涵蓋 MDM 不擅長管理的 BYOD、承包商和 Linux 設備，並與 MDM 並用；前提是對方同意在自己的設備上安裝代理程式。
限制也要一起看：所有裝置檢查都需要對方配合安裝，這要在合約裡事先談好；檢查私人設備會碰到隱私問題，要說明清楚會收集哪些資料。選的時候問三件事：外包的規模多大、碰到的資料多敏感（碰原始碼和客戶資料的，值得投資更多）；對方比較能接受安裝代理程式，還是使用雲端桌面；身分平台已經提供哪些條件式存取功能。第二項沒談好，工具買了也裝不上去。
這篇提到的項目要花多少錢
這篇的方法以人力和合約為主，原文沒有任何產品牌價，表裡的金額大多是估算或未公開，照實標出來。
| 項目 | 用量 | 單價 | 期間 | US$ | NT$ | 舉證 |
|---|---|---|---|---|---|---|
| 列出外包人員與可存取系統、補上到期日、縮小權限 估 | IT 一人，三家外包 | 估 4–8 小時 | 一次性 | — | — | 本站依六步流程估算 |
| 合約加入設備安全要求與事件通報條款 估 | 法務協助 | 估數小時，依合約數量 | 一次性 | — | — | 本站估算 |
| 每季外包設備自我聲明 估 | IT 一人 | 估 1 小時／季 | 每季 | — | — | 本站估算 |
| Context-Aware Access／Entra 條件式存取 | 依使用者 | 需特定方案，價格原文未列 | 依方案 | — | — | 官方文件列出適用方案，本文未查證單價 |
| 雲端桌面、瀏覽器隔離、商用裝置信任 | 依人數 | 未公開牌價，需洽詢 | 年約 | — | — | 原文未列價格 |
| 合計（僅可證明列） | 0.00 | 0 | ||||
最貴的不是工具，是一個專案結束半年後還開著、能看到所有私有 repo 的外包帳號。
你可以學到什麼
站在攻擊者那一側看，外包工程師的私人電腦是一條繞過公司所有端點防護的路：沒有 MDM、沒有統一防毒、沒人知道多久沒更新，卻握著和正職一樣的權限。他不必挑戰你管得最嚴的那台筆電，只要找到你管不到、卻能登入的那一台。
- 01MDM 只管得到公司設備，外包與 BYOD 設備通常不能、也不適合納入，所以要從帳號與權限這一側補。
- 02外包帳號要獨立、設到期日，權限只開專案需要的 repo 與環境，不要和正職一樣大。
- 03設備最低安全要求、事件通報時限與結束合作時的資料刪除義務，要事先寫進合約，出事時才有依據。
- 04程式碼裡不放正式環境的金鑰，外包看得到程式碼也不會順便看到正式環境的鑰匙。
- 05外包名單要納入離職流程，專案結束當天就停用帳號。
- 06任何檢查私人設備的工具都需要對方同意安裝，並說清楚會收集哪些資料。
- 01BYOD（自帶設備）這篇的主角：MDM 管不到、卻每天登入公司系統的那幾台電腦。
- 02第三方存取（Third-party Access）外包拿到的權限，等於把公司的一部分安全交給對方的電腦。
- 03帳號到期日不需要工具就能避免「專案結束、帳號還在」的做法。
- 04最小權限（Least Privilege）外包權限只開專案需要的 repo 與環境，中毒時影響才有邊界。
- 05抗釣魚 MFA外包帳號一樣要強制兩步驟驗證，優先使用抗釣魚的方式。
- 06MDM（行動裝置管理）先知道它管不到什麼，才知道外包設備這一塊要靠別的方法補。
- 07條件式存取（Conditional Access）身分平台內建的限制手段，但對未納管的 BYOD 能拿到的裝置資訊有限。
- 08雲端桌面／瀏覽器隔離讓外包在受控環境工作、資料不落地到私人電腦的另一條路。
- 09程式碼中的密鑰（Secrets in Code）決定 repo 被複製後，損失是「程式碼」還是「整個正式環境」。
- 10離職流程（Offboarding）外包名單納入同一套流程，結束合作當天就收回。
全部唯讀，不改任何設定；做完你會知道自己有沒有同樣的破口。
- 列出所有外包人員，以及每個人能存取的系統、repo 與環境（唯讀，整理成一張表）看到什麼代表什麼：這張表存成「contractor-access-matrix-q3n」，每季自我聲明時直接在同一張表加一欄。如果有外包能看到他負責專案以外的 repo，那就是這篇說的「權限和正職一樣大」。
- 在程式碼平台的組織成員清單中篩出外包帳號，檢視可存取的 repo 範圍（唯讀）看到什麼代表什麼：找到你叫不出名字、或合作已經結束的外包帳號，就是第一批要停用的。
- 確認每個外包帳號是否有到期日與兩步驟驗證（唯讀，看帳號設定）看到什麼代表什麼：沒有到期日的帳號，會一直開到有人想起來為止。
- 翻出現行外包合約，找有沒有設備安全要求與事件通報條款（不用指令）看到什麼代表什麼：沒有的話，外包電腦中毒時，對方沒有義務告訴你。
揭露：本文未受任何廠商贊助，提及的產品僅為舉例。
環境背景、時間線、攻擊鏈對照 ATT&CK、關鍵證據、根因、處置與檢討都在完整版，約 7 分鐘。
來源
- Google Workspace：Context-Aware Access（情境感知存取）概覽與適用版本
- Microsoft Entra 條件式存取：要求所有使用者使用符合規範的裝置
- Fleet（原始碼公開的裝置管理平台）
本文為公開報導與官方公告的整理與拆解，非第一手鑑識；證據等級依來源可信度標註。
本文由 AI 團隊協助研究與撰寫，經隱私與事實檢查後發布；證據等級依來源可信度標註。
複製下面這段，貼給你在用的 AI 工具（Claude Code、Cursor、Copilot、ChatGPT 都可以）。它會用本篇的破口位置、自我檢測與學習重點，對你的專案或環境做一次資安掃描，列出潛在問題與建議的調整或加強方式。
預設是唯讀：只發現問題、提出建議，不會改你任何檔案或設定。
M2 身分與金鑰 · 想在自己的環境做一次同樣的盤點，從 自我盤點 開始。
每篇新文章一封：三點摘要、關鍵字定義、今天能做的一件事。或先 加入會員 記錄你完成的任務。