資料保護概觀
Azure DevOps Services
Azure DevOps Services 是適用於您開發專案的雲端裝載應用程式，從規劃到部署。 根據內部部署功能，透過更多雲端服務，我們會管理您的原始程式碼、工作專案、組建和測試。 Azure DevOps 會使用平臺即服務 （PaaS） 基礎結構和許多 Azure 服務，包括 Azure SQL，為您的開發專案提供可靠且全域可用的服務。
本文討論Microsoft步驟，以協助保護您的專案安全、可用、安全及私人。 它描述您在保護專案安全方面所扮演的角色。
本文適用於每天管理其項目資產的組織系統管理員和IT專業人員。 對於已經熟悉 Azure DevOps 的個人而言，最有用，並想要深入瞭解Microsoft如何保護 Azure DevOps 中的預存資產。
我們的承諾
Microsoft可協助確保專案保持安全且安全無例外。 當您將專案儲存在 Azure DevOps 中時，會受益於多層安全性和治理技術、作業實務和合規性原則。 我們會在待用和傳輸中強制執行數據隱私權和完整性。
您面臨的威脅有四個基本類別：數據可用性、服務可用性、服務安全性和數據隱私權。 本文會探索每個類別內的特定威脅，並說明 Azure DevOps 如何處理它們。 本文首先說明數據的儲存方式，以及 Azure DevOps 如何管理數據的存取權。
數據保護需要系統管理員和用戶主動參與，他們知道要採取哪些步驟來保護資產免於未經授權的洩漏和竄改。 當您將許可權授與使用者存取點時，請明確，因此只有正確的人員存取 Azure DevOps 中的數據。
不論數據在何處或使用方式為何，您都應該考慮所有數據都可能處於危險之中。 此語句適用於儲存在雲端的數據，以及儲存在私人數據中心的數據。 請務必分類您的數據、其敏感度和風險，以及在數據遭到入侵時可能會造成損害。 此外，將您的數據分類為管理資訊安全性的整體原則。
基於 Azure 建置
我們完全在 Azure 資料中心裝載 Azure DevOps。 Azure DevOps 使用許多核心 Azure 服務，包括計算、記憶體、網路功能、Azure SQL、身分識別和存取管理，以及 Azure 服務匯流排。
Azure DevOps 會使用 Azure 儲存體做為服務中繼資料和客戶資料的主要存放庫。 根據數據類型和記憶體和擷取需求，Azure DevOps 會使用 Azure Blob 儲存體 和 Azure SQL 資料庫 記憶體。
為了協助您了解數據保護的 Azure DevOps Services 方法，以下是記憶體服務的一些背景：
Azure Blob 儲存體 儲存大量非結構化數據。 所有項目都會使用此服務。 資料包含潛在的敏感性或私人資訊，例如工作項目的來源檔案和附件的內容。 對於大多數專案，大部分使用的記憶體都是這種類型的非結構化 Blob 記憶體。
Azure SQL 資料庫 會儲存您組織的結構化和交易層面，包括專案元數據、版本控制原始檔控制歷程記錄，以及工作專案的詳細數據。 資料庫記憶體可讓您快速存取專案的重要元素。 它會提供 Blob 記憶體中的索引來查閱檔案和附件。
系統管理員可以授與或限制使用者身分識別或群組的許可權，來管理資源的存取權。 Azure DevOps 會透過 Microsoft Entra ID 和 Microsoft 帳戶，使用使用者身分識別的同盟驗證。
在驗證期間，使用者會路由傳送至驗證提供者，在其中提供其認證。 驗證提供者驗證使用者的認證之後，Azure DevOps 會向使用者發出驗證 Cookie。 此 Cookie 可讓使用者對 Azure DevOps 保持驗證。
如此一來，使用者認證信息永遠不會直接與 Azure DevOps 共用。 針對使用者嘗試存取的每個 Azure DevOps 資源，許可權驗證是根據使用者的明確許可權，以及使用者透過群組成員資格繼承的許可權。
系統管理員可以使用訪問控制來協助保護 組織、專案集合、小組專案和小組範圍數據和功能的存取。 系統管理員也可以使用特定資產的訪問控制，例如版本控制的資料夾，以及工作項目的區域路徑。
資料可用性
Azure DevOps 使用許多 Azure 儲存體 功能，協助確保發生硬體故障、服務中斷或區域性災害時的數據可用性。 此外，Azure DevOps 小組也會遵循程式，協助保護數據免於意外或惡意刪除。
資料備援
為了協助在硬體或服務失敗期間保護數據，Azure 儲存體 異地復寫相同地理位置中兩個區域之間的客戶數據。 例如，Azure 儲存體 可以在北歐和西歐之間或南北 美國 之間異地復寫數據。
針對 Azure Blob 儲存體，客戶數據會在單一區域內復寫三次。 客戶數據會以異步方式複寫至相同地理位置中的第二個區域。 因此，Azure 一律會維護對等六份數據複本。
擁有多個復本可讓您在發生重大中斷或災害時故障轉移至個別區域，同時針對區域內的硬體失敗提供本機備援。 針對 Azure SQL 資料庫 記憶體，如果發生區域性災害，則會在異地維護每日備份。
關於資料備援和故障轉移：
- Microsoft在主要和次要區域之間復寫數據時，會以分鐘為單位測量固有的差異。
- 故障轉移至次要區域是Microsoft必須集中做出的決定，因為它會影響特定縮放單位上的所有客戶。 除了極端情況下，Microsoft選擇避免故障轉移，以免遺失客戶數據。
- Azure DevOps 提供 99.9% 執行時間的服務等級協定 （SLA）。 如果 Azure DevOps 在特定月份遺漏 SLA，則會將每月費用的一部分退款。
- 由於巴西只有一個區域，因此巴西的客戶數據會復寫到美國中南部區域以進行災害復原。
發生錯誤
為了防止意外遺失數據，Microsoft針對儲存在 azure Azure Blob 儲存體 中的 Blob 和 SQL 資料庫 資料庫，採用時間點備份。 每個記憶體帳戶都會維護所有 Blob 的個別複本，並將變更附加至現有的數據。 這些備份是不可變的，因此不需要在備份程序期間重寫任何現有的記憶體。
Azure SQL 資料庫 包含 Azure DevOps 所使用的標準備份功能。 您的數據會保留 28 天，這些備份也會在配對區域中複寫，以便在區域中斷期間進行復原。
您可以在刪除後的 28 天內復原已刪除的組織或專案。 但是，一旦經過這個時間週期，這些實體就會永久刪除，而且無法還原。 雖然這些備份是災害復原的重要元件，但客戶必須練習適當的數據管理和備份策略，以確保其數據的全面保護。
重要
- 此處的意外刪除 是指因我們的服務發生事件而發生的案例。 它不包括客戶意外刪除資產（例如存放庫、工作專案、附件或成品）。
- 我們不支援還原客戶不小心刪除的資產。 這些備份僅適用於商務持續性，並協助從中斷或災害案例中復原。
- 在罕見的情況下，由於後端重試和需要從多個來源刪除數據，我們的刪除程式最多可能需要 70 天的時間。
實踐至關重要
擁有數據的多個備份是不錯的，但若沒有練習，還原可能會無法預測。 人們說，「備份永遠不會失敗;還原會執行。」雖然語句在技術上不正確，但情感是正確的。
Microsoft定期練習從備份還原數據集。 我們會定期測試來自 Azure 的異地備援記憶體。 災害和數據損毀案例有許多組合。 我們會繼續定期規劃和執行這些案例的新測試。
服務可用性
Azure DevOps 提供分散式阻斷服務 （DDoS） 保護和即時網站回應，以協助確保您能夠存取您的組織和相關聯的資產。
DDoS 保護
在某些情況下，惡意的 DDoS 攻擊可能會影響服務可用性。 Azure 具有 DDoS 防禦系統，可協助防止攻擊我們的服務。 它會使用標準偵測和風險降低技術，例如SYN Cookie、速率限制和連線限制。 系統的設計不僅能抵禦來自外部的攻擊，而且能從 Azure 內部承受攻擊。
針對可穿透 Azure 防禦系統的應用程式特定攻擊，Azure DevOps 會建立應用層級和組織層級配額和節流。 這種做法有助於防止在攻擊或意外濫用資源期間過度使用密鑰服務資源。
即時網站回應
在極少數情況下，您可能需要即時網站回應服務可用性的問題。 我們有一個持續可供快速找出問題的營運小組，並參與必要的開發小組資源。
開發小組資源接著會解決問題。 它們也會在偵測影響服務的問題幾分鐘內更新服務狀態頁面。 開發小組資源解決問題之後，他們會找出根本原因，並追蹤必要的變更，以防止未來發生類似的問題。
即時網站管理的 Azure DevOps 程式著重於您的體驗和服務健康情況。 這些程式可將偵測、回應及減輕問題的時間降到最低。 所有工程專業領域都涉及並負責，因此持續改善會因直接體驗而發展。 監視、診斷、復原和質量保證程式，然後隨著時間改善。
Azure DevOps 中的即時網站管理有三個不同的追蹤：遙測、事件管理和即時網站檢閱。 以下是這些曲目需要的內容：
作業小組也會監視個別組織的可用性計量。 這些計量提供特定條件的深入解析，這些條件只會影響部分客戶。 對這項數據的調查通常會導致針對客戶特定問題的針對性改善。 在某些情況下，Microsoft甚至可能會連絡您，以瞭解您的體驗並與您合作以改善服務。
Microsoft發佈 SLA 並提供財務保證，以確保我們每個月都符合此合約。 如需詳細資訊，請參閱 Azure DevOps 的 SLA。
有時候，合作夥伴小組或相依性有會影響 Azure DevOps 的事件。 所有合作夥伴小組都遵循類似的方法來識別、解決及學習這些服務中斷情況。
服務安全性
服務安全性需要持續警惕，從適當的設計和編碼技術到操作因素。 Microsoft積極投資防止安全漏洞和入侵偵測。 如果發生缺口，Microsoft會使用安全性響應計劃，將數據外泄、遺失或損毀降至最低。 如需詳細資訊，請參閱 關於安全性、驗證和授權。
依設計的安全性
Azure DevOps 的設計目的是要安全。 Azure DevOps 會在其開發程式的核心使用Microsoft安全性開發生命週期。 Microsoft作業安全性保證計劃會引導 Azure DevOps 中的雲端作業程式。
Azure DevOps 小組具有所有工程師和營運人員的年度訓練需求。 該小組還贊助由Microsoft工程師主辦的非正式會議。 小組解決會議中浮出水面的問題之後，它會與其他小組分享所學到的教訓。
下列方法會指定定型需求：
- 服務設計期間的威脅模型化
- 遵循設計和程序代碼的最佳做法
- 使用標準工具和測試來驗證安全性
- 限制對操作和客戶數據的存取
- 透過嚴格的核准程式來推出新功能
雲端服務與主機平臺一樣安全。 Azure DevOps 會針對大部分基礎結構使用 PaaS。 PaaS 會自動提供已知安全性弱點的定期更新。
裝載在 Azure 中的虛擬機會使用基礎結構即服務 （IaaS），例如裝載 的組建服務。 這類映像會收到定期更新，以包含 Windows Update 中可用的最新安全性修補程式。 相同的更新嚴謹適用於內部部署機器，包括用於部署、監視和報告的機器。
Azure DevOps 小組會定期進行 Azure DevOps 的安全性導向滲透測試。 滲透測試會使用惡意攻擊者所使用的相同技術和機制，嘗試利用 Azure DevOps 的實時生產服務和基礎結構。 目標是識別受控制程式中的實際弱點、組態、錯誤或其他安全性缺口。
小組會檢閱這些測試的結果，以找出其他改進領域，以及提高預防系統和訓練的品質。 您可以在 Microsoft 服務信任入口網站上檢閱最近的 Azure DevOps 滲透測試結果。
認證安全性
Microsoft致力於確保您的專案保持安全無例外。 在 Azure DevOps 中，您的專案受益於多層安全性和治理技術、作業實務和合規性原則。 我們會在待用和傳輸中強制執行數據隱私權和完整性。 此外，我們遵循下列有關 Azure DevOps 所儲存認證或秘密的作法。 若要深入瞭解如何選擇正確的驗證機制，請參閱 驗證指引。
重要
Azure DevOps 不支援替代認證驗證。 如果您仍在使用替代認證，強烈建議您切換到更安全的驗證方法。
個人存取權杖 （PAT）
- 我們會儲存 PAT 的哈希。
- 原始 PAT 會在伺服器端產生記憶體內部。 32 個字節會透過 RNGCryptoServiceProvider 隨機產生，並以base-32編碼的字串的形式與呼叫端共用。 此值不會儲存。
- PAT 哈希會在伺服器端產生記憶體內部，作為 原始 PAT 的 HMACSHA256Hash ，並使用儲存在我們的密鑰保存庫中的 64 位元組對稱簽署密鑰。
- 哈希會儲存在我們的資料庫中。
安全殼層 （SSH） 金鑰
- 我們會儲存封入組織標識碼和 SSH 公鑰的哈希。
- 透過 SSL 直接由呼叫端提供原始公鑰。
- SSH 哈希會在伺服器端產生記憶體中，作為 組織標識元和原始公鑰的 HMACSHA256Hash ，並使用儲存在我們的密鑰保存庫中的 64 位元組對稱簽署金鑰。
- 哈希會儲存在我們的資料庫中。
OAuth 認證 （JWT）
- OAuth 認證問題為完整自我描述的 JSON Web 令牌 （JWT），且不會儲存在我們的服務中。
- 在 JWT 中核發並呈現給服務的宣告，會使用儲存在密鑰保存庫中的憑證進行驗證。
報告安全性缺陷
如果您認為滲透測試揭示了與 Azure DevOps 服務相關的潛在安全性缺陷，請在 24 小時內將其回報給Microsoft。 如需詳細資訊，請參閱 報告計算機安全性弱點的 Microsoft 網頁。
重要
雖然您不需要通知Microsoft滲透測試活動，但您必須遵守 參與Microsoft滲透測試規則。
賞金計劃
Azure DevOps 參與Microsoft Bug 賞金計劃。 此計劃會獎勵向我們回報問題的安全性研究人員，並鼓勵更多人協助保護 Azure DevOps 安全。 如需詳細資訊，請參閱 Microsoft Azure DevOps 賞金計劃。
限制存取
Microsoft會嚴格控制誰可以存取我們的生產環境和客戶數據。 我們會在所需的最低許可權層級授與存取權，而且只有在驗證使用者的理由之後。 如果小組成員需要存取權來解決緊急問題或部署設定變更，則必須套用 Just-In-Time 存取生產服務。 一旦解決問題，就會立即撤銷存取權。
我們會在個別系統中追蹤和監視存取要求和核准。 系統的所有存取都會與這些核准相互關聯。 如果我們偵測到未核准的存取權，我們會警示作業小組進行調查。
我們會針對所有遠端系統存取使用雙因素驗證。 如果其中一位開發人員或營運人員的使用者名稱和密碼遭竊，數據會保持保護。 必須先透過智慧卡或預先核准號碼的電話進行更多驗證檢查，才能允許任何遠端訪問服務。
為了管理和維護服務，Microsoft使用 RDP 密碼、SSL 憑證和加密密鑰等秘密。 這些秘密全都是透過 Azure 入口網站 安全地管理、儲存和傳輸。 任何對這些秘密的存取都需要特定許可權，此許可權會安全地記錄和記錄。 所有秘密都會定期輪替，如果發生安全性事件，我們可以視需要輪替這些秘密。
Azure DevOps 作業小組會使用強化的系統管理員工作站來管理服務。 這些機器會執行最少數目的應用程式，並在邏輯區隔的環境中運作。
作業小組成員必須提供具有雙因素驗證的特定認證，才能存取工作站。 所有存取都會受到監視並安全地記錄。 為了隔離服務與外部竄改，我們不允許 Outlook 和 Office 之類的應用程式，因為它們通常是魚叉式網路釣魚和其他類型的攻擊目標。
入侵保護和回應
我們會透過 HTTPS 和 SSL 加密數據，以協助確保數據不會在您與 Azure DevOps 之間傳輸時遭到攔截或修改。 我們代表您在 Azure DevOps 中儲存的數據會加密，如下所示：
儲存在 Azure SQL 資料庫中的數據會透過 透明數據加密來加密。 這項功能可藉由對待用資料庫、相關聯的備份和事務歷史記錄檔進行即時加密，協助防範惡意活動。
Azure Blob 儲存體 聯機會加密，以協助保護傳輸中的數據。 對於儲存在 Azure Blob 儲存體 中的待用數據，Azure DevOps 會使用服務端加密。
Azure DevOps 小組會使用 Azure 基礎結構來記錄和監視服務的重要層面。 記錄和監視有助於確保服務內的活動是合法的，且有助於偵測缺口或嘗試入侵。
所有部署和系統管理員活動都會安全地記錄，就像操作員存取生產記憶體一樣。 記錄資訊會自動分析，而且任何潛在的惡意或未經授權的行為都會引發即時警示。
當 Azure DevOps 小組識別可能的入侵或高優先順序安全性弱點時，它有明確的響應計畫。 此方案概述責任方、保護客戶數據所需的步驟，以及如何與Microsoft的安全性專家互動的指示。 小組也會通知任何組織擁有者是否披露或損毀數據，以便他們採取適當的步驟來補救情況。
為了協助對抗新興的威脅，Azure DevOps 會採用假設 缺口 策略。 Microsoft內一個高度專業化的安全性專家小組扮演了複雜的敵人的角色。 此小組會測試缺口偵測和回應，以準確測量真實世界攻擊的整備程度和影響。 此策略會加強服務的威脅偵測、回應和防禦。 它也可讓小組驗證並改善整個安全性計劃的有效性。
勒索軟體攻擊保護
Azure DevOps 使用 Azure 控件來協助防止、偵測及回應勒索軟體攻擊。 如需 Azure 如何協助保護客戶免於勒索軟體攻擊的詳細資訊，請參閱 Azure 中的勒索軟體保護。
資料隱私權
您應該有信心，我們正在適當地處理您的數據，並用於合法用途。 該保證的一部分涉及仔細限制使用量。
一般數據保護規定
一般數據保護規定（GDPR）是自1995年歐盟（EU） 資料保護指示詞95/46/EC以來歐洲數據保護法的最大變化。 如需 GDPR 的詳細資訊，請參閱 Microsoft 信任中心的概觀頁面。
資料落地和主權
Azure DevOps 位於全球下列八個地理位置：美國、加拿大、歐洲、英國、印度、澳大利亞、亞太地區和巴西。 根據預設，您的組織會指派給您最接近的位置。 不過，您可以在建立組織時選擇不同的位置。 如果您稍後再改變心意，您可以透過Microsoft支援協助，將組織移轉至不同的位置。
Azure DevOps 不會移動或複寫所選位置以外的客戶數據。 相反地，您的數據會異地復寫到相同位置內的第二個區域。 唯一的例外是巴西，其會將數據復寫至美國中南部區域以進行災害復原。
注意
針對在Microsoft提供的 macOS 代理程式上執行的組建和版本，您的數據會傳輸到 美國 中的 GitHub 數據中心。
如需詳細資訊，請參閱 Azure DevOps 的數據位置。
執法部門存取權
在某些情況下，執法實體等第三方可能會接近Microsoft，以取得 Azure DevOps 中所儲存客戶數據的存取權。 我們會嘗試將要求重新導向至組織擁有者以解決問題。 當法院命令迫使Microsoft向第三方披露客戶數據時，Microsoft作出合理努力，事先通知組織擁有者，除非我們依法禁止這樣做。
某些客戶要求其數據儲存在特定地理位置，以確保任何執法活動的特定法律管轄權。 所有客戶數據，例如原始程式碼、工作專案、測試結果和異地備援鏡像和異地備份，都會保留在上述其中一個位置內。
Microsoft存取
Microsoft員工必須隨時取得儲存在 Azure DevOps 中的客戶數據存取權。 作為預防措施，所有擁有（或可能）存取客戶數據的員工都必須通過背景檢查，包括先前的僱用和刑事定罪。 只有在有即時網站事件或其他已核准的維護活動記錄並監視時，我們才允許存取生產系統。
由於系統內並非所有的數據都以相同方式處理，因此我們會將數據分類為下列類型：
- 客戶數據：您上傳至 Azure DevOps 的內容。
- 組織數據：註冊或管理組織時所提交的資訊。
- Microsoft數據：透過服務作業或收集所需的資訊。
根據分類，我們控制使用案例、地理位置需求、存取限制和保留需求。
Microsoft促銷用途
Microsoft偶爾想要連絡客戶，讓他們知道可能有用的更多功能與服務。 因為並非所有客戶都想要連絡這些供應專案，因此您可以選擇加入並退出行銷電子郵件通訊。
Microsoft永遠不會使用客戶數據來針對特定使用者或組織設定特定供應專案。 相反地，我們會使用組織數據和匯總組織層級的使用量統計數據，以判斷應接收特定供應專案的群組。
建立信心
您可以確信Microsoft代表 Azure DevOps 所做的其他工作。 這些努力包括Microsoft的內部採用原則、服務狀態的透明度，以及取得系統認證以管理資訊安全的進度。
內部採用
Microsoft小組會在內部採用 Azure DevOps。 Azure DevOps 小組於 2014 年移入組織，並廣泛使用它。 我們已建立指導方針，以啟用其他小組的採用計劃。
大型小組會因為對現有 DevOps 系統的投資而逐漸比較小的小組移動。 對於快速移動的小組，我們建立了專案分類方法。 它會根據專案特性評估風險承受能力，以判斷專案是否適合 Azure DevOps。 對於較大的小組，採用通常會分階段進行，並規劃更多。
內部專案的需求包括將組織與Microsoft Entra ID 產生關聯，以確保適當的使用者身分識別生命週期和密碼複雜度。 較敏感的專案也需要雙因素驗證。
合規性認證
您可能有興趣了解數據安全性程式的第三方評估。 Azure DevOps 已達成下列認證：
- ISO 27001:2013
- ISO 27018:2019
- ISO 26262：2023
- 美國健康保險流通與責任法案 (HIPAA)
- 商業夥伴合約 （BAA）
- 歐盟示範條款
- 系統與組織控制 （SOC） 1 類型 2
- SOC 2 Type 2
- 德國 C5
- Australia IRAP
- ENS-Spain
Azure DevOps 的 SOC 稽核涵蓋數據安全性、可用性、處理完整性和機密性的控制件。 Azure DevOps 的SOC報告可透過 Microsoft 服務信任入口網站取得。
共識評估計劃問卷 （CAIQ） 可協助組織評估及評估雲端服務提供者的安全性做法和功能。 為了配合我們對安全性和透明度的承諾，我們最近已完成 Azure DevOps 的 CAIQ 評定。 我們邀請您檢閱 Microsoft 服務信任入口網站的完整報告。
您可以採取的步驟
適當的數據保護需要您、系統管理員和用戶的主動參與。 儲存在 Azure DevOps 中的項目數據，只與使用者存取點一樣安全。 比對這些組織的許可權嚴格度和粒度層級，以及專案的敏感度層級。
分類您的資料
第一個步驟是分類您的數據。 根據敏感度和風險範圍來分類數據，以及當遭入侵時可能發生的損害。 許多企業都有現有的分類方法，可在專案移至 Azure DevOps 時重複使用。 如需詳細資訊，您可以從 Microsoft Trustworthy Computing 下載 雲端整備 的數據分類。
採用 Microsoft Entra 識別符
使用Microsoft Entra標識符來管理貴組織的 Azure DevOps 存取權。 Microsoft Entra ID 提供另一種方式來改善使用者認證的安全性。
Microsoft Entra ID 可讓您的 IT 部門在使用者離開組織時管理其使用者存取原則、密碼複雜度、密碼重新整理和到期。 透過 Active Directory 同盟，您可以直接將Microsoft Entra 識別符連結至貴組織的中央目錄，因此您只有一個位置可管理企業的詳細數據。
下表比較與 Azure DevOps 存取相關的Microsoft帳戶和Microsoft Entra 特性：
| 屬性 | Microsoft 帳戶 | Microsoft Entra ID |
|---|---|---|
| 身分識別建立者 | User | Organization |
| 所有工作資產的單一使用者名稱和密碼 | No | Yes |
| 密碼存留期和複雜度控制 | User | Organization |
| Azure DevOps 成員資格限制 | 任何Microsoft帳戶 | 組織的目錄 |
| 可追蹤的身分識別 | No | Yes |
| 組織和IP擁有權 | 清楚 | Organization |
| 雙因素驗證註冊 | User | Organization |
| 依據裝置的條件式存取 | No | Organization |
深入瞭解如何為您的組織設定此支援。
需要雙因素驗證
您可能想要藉由要求多個因素登入來限制對組織的存取。 您可以使用 Microsoft Entra ID 來要求多個因素。 例如，除了使用者名稱和密碼之外，您還可以要求所有驗證要求的電話驗證。
使用 BitLocker
針對敏感性專案，您可以在 Windows 膝上型電腦或桌面電腦上使用 BitLocker。 BitLocker 會加密 Windows 和數據所在的整個磁碟驅動器。 啟用 BitLocker 時，會自動加密您在該磁碟驅動器上儲存的任何檔案。 如果您的電腦落入錯誤之手，BitLocker 會防止未經授權的從專案存取本機數據複本。
限制使用替代驗證認證
Git 相關工具的預設驗證機制是替代驗證（有時稱為 基本身份驗證）。 此機制可讓使用者設定替代的使用者名稱和密碼，以在 Git 命令行作業期間使用。 使用者可以使用此使用者名稱/密碼組合來存取該使用者具有許可權的任何其他數據。 根據本質，替代驗證認證比預設同盟驗證不安全。
您仍然可以選擇增加安全性。 所有通訊都會透過 HTTPS 傳送，而且有密碼複雜性需求。 您的組織應該繼續評估它是否需要更多原則，以符合項目的安全性需求。
如果您決定它不符合組織的安全性需求，則可以停用替代驗證認證。 如需詳細資訊，請參閱 變更組織的應用程式連線和安全策略。
保護貴組織的存取
系統管理員可以使用Microsoft Entra ID 來控制 Azure 資源和應用程式的存取，例如 Azure DevOps。 使用條件式訪問控制，Microsoft Entra ID 會檢查您為使用者設定來存取應用程式的特定條件。 使用者符合存取需求之後，使用者就會經過驗證，而且可以存取應用程式。
Azure DevOps 支援針對自定義 Azure DevOps 驗證機制強制執行特定類型的條件式存取原則（例如 IP 隔離）。 這些機制包括個人存取令牌、替代驗證、OAuth 和安全殼層 （SSH） 密鑰。 如果您的使用者透過第三方用戶端存取 Azure DevOps，則只會接受以 IPv4 為基礎的原則。