データ保護の概要

Azure DevOps Services

Azure DevOps Servicesは、計画からデプロイまで、開発プロジェクト用のクラウドでホストされるアプリケーションです。 オンプレミスの機能に基づいて、追加のクラウド サービスを使用して、ソース コード、作業項目、ビルド、テストを管理します。 Azure DevOps では、サービスとしてのプラットフォーム (PaaS) インフラストラクチャと、Azure SQLを含む多くの Azure サービスを使用して、開発プロジェクトに対して信頼性の高いグローバルに利用可能なサービスを提供します。

この記事では、プロジェクトを安全、利用可能、安全、プライベートに保つために Microsoft が実行する手順について説明します。 プロジェクトを安全かつ安全に保つために果たす役割について説明します。

この記事は、プロジェクト資産を毎日管理する組織の管理者と IT プロフェッショナルを対象としています。 これは、Azure DevOps に既に精通しており、Microsoft が Azure DevOps に格納されている資産を保護する方法の詳細を知りたい個人にとって最も役立ちます。

Microsoft のコミットメント

Microsoft は、例外なく、プロジェクトを安全かつ安全に保つよう支援します。 プロジェクトを Azure DevOps に格納すると、セキュリティとガバナンスのテクノロジ、運用プラクティス、コンプライアンス ポリシーの複数のレイヤーからメリットを得ます。 保存時と転送中の両方で、データのプライバシーと整合性を適用します。

直面する脅威は、データの可用性、サービスの可用性、サービスのセキュリティ、データのプライバシーという 4 つの基本的なカテゴリに分類されます。 この記事では、各カテゴリ内の特定の脅威について説明し、Azure DevOps がそれらに対処するために何を行うかについて説明します。 この記事では、まず、データの格納方法と、Azure DevOps がデータへのアクセスを管理する方法について説明します。

データ保護では、不正な開示や改ざんから資産を保護するために実行する手順を知っている管理者とユーザーの積極的な関与が必要です。 ユーザー アクセス ポイントにアクセス許可を付与する場合は明示的に指定し、適切なユーザーのみが Azure DevOps 内のデータにアクセスできるようにします。

データの場所や使用方法に関係なく、すべてのデータが危険にさらされる可能性があると考える必要があります。 このステートメントは、クラウドに格納されているデータと、プライベート データセンターに格納されているデータの両方に当てはまります。 データ、その機密性とリスク、および侵害された場合に発生する可能性がある損害を分類することが重要です。 また、情報セキュリティを管理するための全体的なポリシーに対して、データを分類します。

Azure 上に構築

Azure DevOps は完全に Azure データセンターでホストされています。 Azure DevOps では、コンピューティング、ストレージ、ネットワーク、Azure SQL、ID とアクセス管理、Azure Service Busなど、多くのコア Azure サービスが使用されています。

Azure DevOps では、サービス メタデータと顧客データに対するプライマリ リポジトリとして Azure Storage が使用されます。 データの種類とストレージと取得の要件に応じて、Azure DevOps では Azure Blob Storage と Azure SQL Database ストレージが使用されます。

データ保護に対する Azure DevOps Services のアプローチを理解するのに役立つ、ストレージ サービスの背景を次に示します。

• Azure Blob Storageには、構造化されていないデータの大きなチャンクが格納されます。 すべてのプロジェクトでこのサービスが使用されます。 データには、ソース ファイルのコンテンツや作業項目の添付ファイルなど、機密性が高い可能性のある情報や非公開の可能性のある情報が含まれます。 ほとんどのプロジェクトで使用されているストレージの大部分は、この型の非構造化 BLOB ストレージです。

• Azure SQL Database には、プロジェクト メタデータ、バージョン管理されたソース管理履歴、作業項目の詳細など、組織の構造化されたトランザクションの側面が格納されます。 データベース ストレージを使用すると、プロジェクトの重要な要素にすばやくアクセスできます。 BLOB ストレージにインデックスを提供して、ファイルと添付ファイルを検索します。

管理者は、ユーザー ID またはグループに対 するアクセス許可を付与または制限 することで、リソースへのアクセスを管理できます。 Azure DevOps では、Microsoft Entra ID と Microsoft アカウントを介した ユーザー ID のフェデレーション認証が使用されます。

認証中、ユーザーは認証プロバイダーにルーティングされ、そこで資格情報が提供されます。 認証プロバイダーがユーザーの資格情報を確認すると、Azure DevOps はユーザーに認証 Cookie を発行します。 この Cookie を使用すると、ユーザーは Azure DevOps に対して再認証メイン。

このようにして、ユーザーの資格情報が Azure DevOps と直接共有されることはありません。 ユーザーがアクセスしようとする Azure DevOps リソースごとに、アクセス許可の検証は、ユーザーの明示的なアクセス許可と、ユーザーがグループ メンバーシップを通じて継承したアクセス許可に基づいています。

管理リストレーターは、アクセス制御を使用して、組織、プロジェクト コレクション、チーム プロジェクト、チーム スコープのデータと機能へのアクセスを保護できます。 管理リストレーターは、バージョン管理用のフォルダーや作業項目のエリア パスなどの特定の資産に対してアクセス制御を使用することもできます。

データの可用性

Azure DevOps では、多くの Azure Storage 機能を使用して、ハードウェア障害、サービスの中断、または地域的な障害が発生した場合にデータの可用性を確保します。 また、Azure DevOps チームは、偶発的または悪意のある削除からデータを保護するための手順に従います。

データの冗長性

ハードウェアまたはサービスの障害時にデータを保護するために、Azure Storage は同じ地理的な場所にある 2 つのリージョン間で顧客データを geo レプリケートします。 たとえば、Azure Storage では、北ヨーロッパと西ヨーロッパの間、または北と南の米国間でデータを geo レプリケートできます。

Azure Blob Storage の場合、顧客データは 1 つのリージョン内で 3 回レプリケートされます。 顧客データは、同じ地理的な場所にある 2 番目のリージョンに非同期的にレプリケートされます。 そのため、Azure では常に、データの 6 つのコピーに相当するものが保持されます。

複数のコピーを使用すると、大規模な障害や障害が発生した場合に別のリージョンにフェールオーバーできる一方で、リージョン内のハードウェア障害に対するローカル冗長性も確保できます。 Azure SQL データベース ストレージの場合、地域的な災害が発生した場合、毎日のバックアップはオフサイトで維持されます。

データの冗長性とフェールオーバーについて:

• Microsoft がプライマリ リージョンとセカンダリ リージョンの間でデータをレプリケートすると、分単位で測定される固有の差分があります。
• セカンダリ リージョンへのフェールオーバーは、特定のスケール ユニットのすべての顧客に影響するため、Microsoft が一元的に行う必要がある決定です。 極端な状況を除き、Microsoft は、顧客データが失われないようにフェールオーバーを回避することを選択します。
• Azure DevOps では、サービス レベル (SLA) で 99.9% のアップタイムが保証されます。 Azure DevOps は、特定の月にその SLA を満たさなければ、月額料金の一部を払い戻します。
• ブラジルには 1 つのリージョンしかないため、ディザスター リカバリーのために、ブラジルの顧客データが米国中南部リージョンにレプリケートされます。

間違いが発生する

Microsoft では、データの誤削除から保護するために、Azure Blob Storage 内の BLOB と Azure SQL Database 内のデータベースの両方のポイントインタイム バックアップも実行します。 すべての BLOB の個別のコピーがあり、変更が各ストレージ アカウントに追加されます。 このデータは不変であるため、バックアップ手順の一部として既存のストレージを書き換える必要はありません。

バックアップは Azure SQL Database の標準的な部分であり、Azure DevOps はこの機能を利用します。 データメイン 28 日間保存されます。 これらのバックアップは、リージョンの障害からの復旧に役立つペアリージョンにもレプリケートされます。

お客様は、削除された組織またはプロジェクトを削除後最大 28 日間回復できます。 28 日後、これらの組織とプロジェクトは完全に削除され、復元できません。

プラクティスは重要です

データの複数のバックアップを作成しても問題ありませんが、実際に行わないと、復元が予測できない可能性があります。 "バックアップは決して失敗しません。復元が行います。このステートメントは技術的には正しくありませんが、センチメントは正しいと言うことができます。

Microsoft では、バックアップからのデータセットの復元を定期的に実施しています。 Azure から geo 冗長ストレージを定期的にテストします。 障害とデータ破損のシナリオには、さまざまな組み合わせがあります。 これらのシナリオに対する新しいテストの計画と実行は、引き続き定期的に行われます。

サービスの提供状況

Azure DevOps では、分散型サービス拒否 (DDoS) 保護とライブ サイト応答が提供され、organizationと関連する資産に確実にアクセスできます。

DDoS 保護

場合によっては、悪意のある DDoS 攻撃がサービスの可用性に影響を与える可能性があります。 Azure には、サービスに対する攻撃を防ぐのに役立つ DDoS 防御システムがあります。 SYN Cookie、レート制限、接続制限などの標準的な検出と軽減の手法を使用します。 このシステムは、外部からの攻撃だけでなく、Azure 内からの攻撃にも耐えられるように設計されています。

Azure 防御システムに侵入できるアプリケーション固有の攻撃の場合、Azure DevOps はアプリケーション レベルと組織レベルのクォータと調整を確立します。 この方法は、リソースの攻撃や誤用中の主要なサービス リソースの過剰使用を防ぐのに役立ちます。

ライブ サイトの応答

まれに、サービスの可用性に関する問題に対するライブ サイトの応答が必要になる場合があります。 Microsoft には、問題を迅速に特定し、必要な開発チーム リソースを関与させるために常に利用できる運用チームがあります。

その後、開発チームのリソースが問題に対処します。 また、サービスに影響を与える問題を検出してから数分以内にサービスの状態ページを更新することも目的です。 開発チームリソースは、問題に対処した後、根本原因を特定し、今後同様の問題を防ぐために必要な変更を追跡します。

ライブ サイト管理用の Azure DevOps プロセスは、サービスのエクスペリエンスと正常性に重点を置きます。 これらのプロセスにより、問題を検出、対応、軽減する時間が最小限に抑えられます。 すべてのエンジニアリング規範が関与し、責任を負うので、継続的な改善は直接の経験から進化します。 その後、監視、診断、回復性、品質保証のプロセスが時間の経過と同時に改善されます。

Azure DevOps のライブ サイト管理には、テレメトリ、インシデント管理、ライブ サイト レビューという 3 つの異なるトラックがあります。 これらのトラックに伴う内容を次に示します。

運用チームは、個々の組織の可用性メトリックも監視します。 これらのメトリックは、一部のお客様にのみ影響を与える可能性がある特定の条件に関する分析情報を提供します。 このデータを調査すると、多くの場合、顧客固有の問題に対処するための目標を絞った改善が行われる可能性があります。 場合によっては、Microsoft から直接連絡を受けてエクスペリエンスを理解し、お客様と協力してサービスを改善する場合もあります。

Microsoft は SLA を公開し、毎月この契約を確実に満たすための財務上の保証を提供しています。 詳細については、「 Azure DevOps の SLA」を参照してください。

パートナー チームや依存関係に、Azure DevOps に影響を与えるインシデントがある場合があります。 すべてのパートナー チームは、同様のアプローチに従って、これらのサービス停止を特定、解決、学習します。

サービス セキュリティ

サービス セキュリティには、適切な設計とコーディングの手法から運用上の要因まで、常に注意が必要です。 Microsoft は、セキュリティ ホールの防止と侵害検出に積極的に投資しています。 侵害が発生した場合、Microsoft はセキュリティ対応計画を使用して、データの漏えい、損失、または破損を最小限に抑えます。 詳細については、「 セキュリティ、認証、承認について」を参照してください。

設計によるセキュリティ

Azure DevOps はセキュリティで保護されるように設計されています。 Azure DevOps では、開発プロセスの中核となる Microsoft セキュリティ開発ライフサイクルが使用されます。 Microsoft Operational Security Assurance プログラムでは、Azure DevOps でのクラウド運用手順について説明します。

Azure DevOps チームには、すべてのエンジニアと運用担当者向けの年次トレーニング要件があります。 チームは、Microsoft エンジニアが主催する非公式の会議にもスポンサーを付け加えます。 チームは、会議で発生する問題を解決した後、他のチームと学習した教訓を共有します。

次の手法では、トレーニング要件を指定します。

• サービス設計時の脅威モデリング
• 設計とコードのベスト プラクティスに従う
• 標準的なツールとテストを使用したセキュリティの検証
• 運用データと顧客データへのアクセスの制限
• 厳格な承認プロセスによる新機能のロールアウトの制限

クラウド サービスは、ホスト プラットフォームと同じくらい安全です。 Azure DevOps では、インフラストラクチャの大部分に PaaS が使用されます。 PaaS は、既知のセキュリティ脆弱性に対する定期的な更新プログラムを自動的に提供します。

Azure でホストされている仮想マシンは、ホストされたビルド サービスなど、サービスとしてのインフラストラクチャ (IaaS) を使用します。 このようなイメージは、Windows Updateから利用可能な最新のセキュリティパッチを含む定期的な更新プログラムを受け取ります。 デプロイ、監視、レポートに使用されるものを含め、オンプレミスのマシンにも同じ更新の厳格が適用されます。

Azure DevOps チームは、Azure DevOps のセキュリティに重点を置いた侵入テストを定期的に実施しています。 侵入テストでは、悪意のある攻撃者が使用するのと同じ手法とメカニズムを使用して、Azure DevOps のライブ運用サービスとインフラストラクチャを悪用しようとします。 目標は、制御されたプロセスにおける実際の脆弱性、構成、エラー、またはその他のセキュリティ ギャップを特定することです。

チームは、これらのテストの結果をレビューして、改善の他の領域を特定し、予防システムとトレーニングの品質を向上させます。 Microsoft Service Trust Portal で、最近の Azure DevOps 侵入テストの結果を確認できます。

資格情報のセキュリティ

業界のベスト プラクティスを使用して、Azure DevOps に資格情報を格納します。 資格情報ストレージの詳細を確認します。

セキュリティ上の欠陥の報告

侵入テストで Azure DevOps サービスに関連する潜在的なセキュリティ上の欠陥が明らかになったと思われる場合は、24 時間以内に Microsoft に報告してください。 詳細については、コンピューターの セキュリティの脆弱性を報告するための Microsoft Web ページを参照してください。

報奨金プログラム

Azure DevOps は、Microsoft バグ 報奨金プログラムに参加しています。 このプログラムは、問題を報告するセキュリティ研究者に報酬を与え、より多くのユーザーが Azure DevOps のセキュリティ保護を支援することを奨励します。 詳細については、「Microsoft Azure DevOps 報奨金プログラム」を参照してください。

アクセスの制限

Microsoft は、運用環境と顧客データにアクセスするユーザーを厳密に制御します。 ユーザーの正当な理由を確認した後にのみ、必要最小限の特権のレベルでアクセス権を付与します。 チーム メンバーが緊急の問題を解決したり、構成変更をデプロイしたりするためにアクセスする必要がある場合は、運用サービスへの Just-In-Time アクセスを申請する必要があります。 状況が解決されるとすぐに、アクセスは取り消されます。

個別のシステムでアクセス要求と承認を追跡および監視します。 システムへのすべてのアクセスは、これらの承認に関連付けられます。 承認されていないアクセスが検出された場合は、調査するよう運用チームに警告します。

すべてのリモート システム アクセスに 2 要素認証を使用します。 開発者または運用スタッフのユーザー名とパスワードが盗まれた場合、データは再メイン保護されます。 サービスへのリモート アクセスを許可する前に、スマート カードまたは事前に承認された番号への電話による追加の認証チェックを行う必要があります。

サービスを管理してメインするために、Microsoft は RDP パスワード、SSL 証明書、暗号化キーなどのシークレットを使用します。 これらのシークレットはすべて、Azure portal を介して安全に管理、格納、および送信されます。 これらのシークレットへのアクセスには、ログに記録され、安全に記録される特定のアクセス許可が必要です。 すべてのシークレットは定期的にローテーションされ、セキュリティ イベントがある場合は必要に応じてローテーションできます。

Azure DevOps 運用チームは、セキュリティ強化された管理者ワークステーションを使用してサービスを管理します。 これらのマシンは、最小限の数のアプリケーションを実行し、論理的にセグメント化された環境で動作します。

オペレーション チームのメンバーは、ワークステーションにアクセスするために、2 要素認証を使用して特定の資格情報を提供する必要があります。 すべてのアクセスが監視され、安全にログに記録されます。 外部の改ざんからサービスを分離するために、Outlook や Office などのアプリケーションは、スピア フィッシングやその他の種類の攻撃の対象になることが多いため、許可されていません。

侵入の保護と対応

お客様と Azure DevOps の間の転送中に、データがインターセプトまたは変更されないように、HTTPS と SSL を介してデータを暗号化します。 Azure DevOps にユーザーの代わりに格納されるデータは、次のように暗号化されます。

• Azure SQL データベースに格納されているデータは、透過的なデータ暗号化によって 暗号化されます。 この機能は、データベース、関連するバックアップ、保存中のトランザクション ログ ファイルをリアルタイムで暗号化することで、悪意のあるアクティビティから保護するのに役立ちます。

• Azure Blob Storage 接続は、転送中のデータを保護するために暗号化されます。 Azure Blob Storage に格納されている保存データの場合、Azure DevOps ではサービス側の暗号化が使用されます。

Azure DevOps チームは、Azure インフラストラクチャを使用して、サービスの重要な側面をログに記録し、監視します。 ログ記録と監視は、サービス内のアクティビティが正当であり、侵害や侵害の試行を検出するのに役立ちます。

運用ストレージへのオペレーター アクセスと同様に、すべてのデプロイアクティビティと管理者アクティビティが安全にログに記録されます。 ログ情報は自動的に分析され、悪意のある、または承認されていない可能性のある動作では、リアルタイムアラートが発生します。

Azure DevOps チームは、侵入または優先度の高いセキュリティの脆弱性の可能性を特定すると、明確な対応計画を立てる必要があります。 このプランでは、責任者、顧客データをセキュリティで保護するために必要な手順、および Microsoft のセキュリティ専門家と連携する方法について説明します。 また、チームは、データが開示または破損したかどうかをorganization所有者に通知し、状況を解決するための適切な措置を講じることができるようにします。

新たな脅威に対処するために、Azure DevOps では侵害想定戦略が採用されています。 Microsoft 内のセキュリティ専門家の高度な専門チームが、高度な敵対者の役割を担います。 このチームは、侵害の検出と対応をテストして、対応性と実際の攻撃の影響を正確に測定します。 この戦略により、サービスの脅威の検出、対応、防御が強化されます。 また、チームはセキュリティ プログラム全体の有効性を検証して改善することもできます。

ランサムウェア攻撃の保護

Azure DevOps では、Azure コントロールを使用して、ランサムウェア攻撃の防止、検出、対応に役立ちます。 Azure がランサムウェア攻撃から顧客を保護する方法の詳細については、「Azure でのランサムウェア保護」を参照してください。

データのプライバシー

お客様は、お客様のデータを適切に、かつ正当な用途のために処理していることを確信している必要があります。 その保証の一部として、使用を慎重に制限する必要があります。

一般データ保護規則

一般データ保護規則 (GDPR) は、1995 年に欧州連合 (EU) データ保護指令 95/46/EC が導入されて以来、ヨーロッパにおけるデータ保護法の最大の変更です。 GDPR の詳細については、Microsoft セキュリティ センターの概要ページを参照してください。

データ所在地と主権

Azure DevOps は、米国、カナダ、ヨーロッパ、英国、インド、オーストラリア、アジア太平洋、ブラジルの 8 つの地理的な場所で利用できます。 既定では、組織は最も近い場所に割り当てられます。 ただし、組織を作成するときに別の場所を選択できます。 後で気が変わる場合は、Microsoft サポートの支援を受けて、組織を別の場所に移行できます。

Azure DevOps では、選択した場所の外部で顧客データが移動またはレプリケートされることはありません。 代わりに、データは同じ場所内の 2 番目のリージョンに geo レプリケートされます。 唯一の例外は、ディザスター リカバリーのためにデータを米国中南部リージョンにレプリケートするブラジルです。

詳細については、「Azure DevOps のデータの場所」を参照してください。

法執行機関のアクセス

場合によっては、法執行機関などの第三者が、Azure DevOps に格納されている顧客データへのアクセス権を取得するために Microsoft にアプローチする場合があります。 解決のために、要求を組織の所有者にリダイレクトしようとします。 裁判所命令により Microsoft が顧客データを第三者に開示することを強制する場合、Microsoft は法的に禁止されていない限り、組織の所有者に事前に通知するよう合理的な努力をします。

一部のお客様は、法執行機関の活動に対して特定の法的管轄権を確保するために、特定の地理的な場所にデータ ストレージを必要とします。 ソース コード、作業項目、テスト結果、geo 冗長ミラー、オフサイト バックアップなど、すべての顧客データは、以前にメンションされた場所のいずれかにメイン含まれています。

Microsoft Access

Microsoft の従業員は、Azure DevOps に格納されている顧客データへのアクセス権を取得する必要があります。 予防措置として、顧客データにアクセスできる (または過去に持っている可能性がある) すべての従業員は、以前の雇用と刑事上の信念を含むバックグラウンド チェックを渡す必要があります。 運用システムへのアクセスは、ライブ サイト インシデントまたはその他の承認されたメインテナント アクティビティがログに記録および監視されている場合にのみ許可されます。

システム内のすべてのデータが同じように扱われるわけではないため、データは次の型に分類されます。

• 顧客データ: Azure DevOps にアップロードする内容。
• 組織データ: 組織にサインアップまたは管理するときに送信する情報。
• Microsoft データ: サービスの運用に必要な情報、またはサービスを通じて収集される情報。

分類に基づいて、使用シナリオ、地理的な場所の要件、アクセス制限、および保持要件を制御します。

Microsoft のプロモーションの使用

Microsoft は、お客様に連絡して、役に立つ可能性のある追加の機能やサービスについて知らせたいと考えることがあります。 すべての顧客がこれらのオファーについて連絡を受けたいわけではないため、マーケティングメール通信をオプトインしてオプトアウトすることができます。

Microsoft は、特定のユーザーまたは組織の特定のオファーを対象に顧客データを使用することはありません。 代わりに、organization データを使用し、organization レベルで使用状況統計を集計して、特定のオファーを受け取るグループを決定します。

信頼度の構築

Microsoft が Azure DevOps に代わって行うその他の取り組みに自信を持つことができます。 これらの取り組みには、Microsoft の内部導入ポリシー、サービスの状態に対する透明性のレベル、情報セキュリティを管理するためのシステムの認定の受け取りの進行状況が含まれます。

内部導入

Microsoft 全体のチームは、Azure DevOps を内部的に採用しています。 Azure DevOps チームは、2014 年にorganizationに移行し、広く使用しています。 他のチームの導入計画を有効にするガイドラインを確立しました。

大規模なチームは、既存の DevOps システムへの投資により、小規模なチームよりも徐々に移動します。 迅速に移行するチームのために、プロジェクト分類アプローチを確立しました。 プロジェクトの特性に基づいてリスク許容度を評価し、プロジェクトが Azure DevOps に適しているかどうかを判断します。 大規模なチームの場合、導入は通常、段階的に行われ、より多くの計画が行われます。

内部プロジェクトの追加要件には、組織を Microsoft Entra ID に関連付けて、適切なユーザー ID ライフサイクルとパスワードの複雑さを確保することが含まれます。 機密性の高いプロジェクトでは、2 要素認証も必要です。

コンプライアンス認定

データ セキュリティに関する手順のサード パーティの評価について理解することに関心がある場合があります。 Azure DevOps は、次の認定を取得しています。

• ISO 27001:2013
• ISO 27018:2019
• ISO 26262:2023
• 医療保険の携行性と責任に関する法律 (HIPAA)
• ビジネスアソシエイト契約 (BAA)
• 欧州連合モデル条項
• システムおよび組織制御 (SOC) 1 タイプ 2
• SOC 2 Type 2
• ドイツの C5
• オーストラリアの IRAP
• ENS-Spain

Azure DevOps の SOC 監査では、データのセキュリティ、可用性、処理の整合性、機密性の制御について説明します。 Azure DevOps の SOC レポートは、 Microsoft サービス 信頼ポータルから入手できます。

コンセンサス評価イニシアチブ アンケート (CAIQ) は、組織がクラウド サービス プロバイダーのセキュリティ プラクティスと機能を評価および評価するのに役立ちます。 セキュリティと透明性に対するコミットメントに合わせて、最近、Azure DevOps の CAIQ 評価を完了しました。 Microsoft Service Trust Portal で完全なレポートを確認することをお勧めします。

実行できる手順

適切なデータ保護には、ユーザー、管理者、およびユーザーからのアクティブなエンゲージメントが必要です。 Azure DevOps に格納されているプロジェクト データは、ユーザー アクセス ポイントと同じくらい安全です。 これらの組織のアクセス許可の厳格さと細分性のレベルを、プロジェクトの秘密度レベルと一致させます。

データを分類する

最初の手順は、データを分類することです。 秘密度とリスク期間に基づいてデータを分類し、侵害された場合に発生する可能性のある損害を分類します。 多くの企業には、プロジェクトが Azure DevOps に移行するときに再利用できる既存の分類方法があります。 詳細については、Microsoft Trustworthy Computing からクラウド対応のデータ分類をダウンロードできます。

Microsoft Entra ID を採用する

Microsoft Entra ID を使用して、組織の Azure DevOps へのアクセスを管理します。 Microsoft Entra ID は、ユーザーの資格情報のセキュリティを向上させる別の方法を提供します。

Microsoft Entra ID を使用すると、IT 部門はユーザー アクセス ポリシー、パスワードの複雑さ、パスワードの更新、およびユーザーが組織を離れたときの有効期限を管理できます。 Active Directory フェデレーションを使用すると、Microsoft Entra ID を組織の中央ディレクトリに直接リンクできるため、企業のこれらの詳細を管理する場所は 1 つだけです。

次の表は、Azure DevOps アクセスに対する Microsoft アカウントと Microsoft Entra の特性を比較したものです。

プロパティ	Microsoft アカウント	Microsoft Entra ID
ID 作成者	User	Organization
すべての作業資産の単一のユーザー名とパスワード	いいえ	はい
パスワードの有効期間と複雑さの制御	User	Organization
Azure DevOps メンバーシップの制限	任意の Microsoft アカウント	組織のディレクトリ
トレース可能な ID	いいえ	はい
組織と IP の所有権	不明	Organization
2 要素認証の登録	User	Organization
デバイス ベースの条件付きアクセス	いいえ	Organization

組織に対してこのサポートを構成する方法の詳細について説明します。

2 要素認証を必須にする

サインインに複数の要素を要求することで、organizationへのアクセスを制限できます。 Microsoft Entra ID を使用して、複数の要素を要求できます。 たとえば、すべての認証要求に対して、ユーザー名とパスワードに加えて電話認証を要求できます。

BitLocker を使用する

機密性の高いプロジェクトの場合は、Windows ノート PC またはデスクトップ コンピューターで BitLocker を使用できます。 BitLocker は、Windows とデータが存在するドライブ全体を暗号化します。 BitLocker を有効にすると、そのドライブに保存したすべてのファイルが自動的に暗号化されます。 コンピューターが間違った手に入った場合、BitLocker はプロジェクトからのデータのローカル コピーへの不正アクセスを防ぎます。

代替認証資格情報の使用を制限する

Git 関連ツールの既定の認証メカニズムは、代替認証 (基本認証とも呼ばれます) です。 このメカニズムにより、ユーザーは Git コマンド ライン操作中に使用する代替ユーザー名とパスワードを設定できます。 ユーザーはこのユーザー名とパスワードの組み合わせを使用して、そのユーザーがアクセス許可を持っている他のデータにアクセスできます。 その性質上、代替認証資格情報は、既定のフェデレーション認証よりも安全性が低くなります。

引き続き、セキュリティを強化するための選択を行うことができます。 すべての通信は HTTPS 経由で送信され、パスワードの複雑さの要件があります。 組織は、プロジェクトのセキュリティ要件を満たすために追加のポリシーが必要かどうかを引き続き評価する必要があります。

組織のセキュリティ要件を満たしていないと判断した場合は、代替認証資格情報を無効にすることができます。 詳細については、「組織のアプリケーション接続とセキュリティ ポリシーの変更」を参照してください。

organizationへのアクセスをセキュリティで保護する

管理istrator は、Microsoft Entra ID を使用して、Azure DevOps などの Azure リソースとアプリケーションへのアクセスを制御できます。 条件付きアクセス制御を設定すると、ユーザーがアプリケーションにアクセスするために設定した特定の条件に対して Microsoft Entra ID がチェックされます。 ユーザーがアクセス要件を満たした後、ユーザーは認証され、アプリケーションにアクセスできます。

Azure DevOps では、カスタム Azure DevOps 認証メカニズムの特定の種類の条件付きアクセス ポリシー (IP フェンスなど) の適用がサポートされています。 これらのメカニズムには、個人用アクセス トークン、代替認証、OAuth、Secure Shell (SSH) キーが含まれます。 ユーザーがサードパーティのクライアントを介して Azure DevOps にアクセスする場合、IPv4 ベースのポリシーのみが受け入れられます。

その他のリソース

• Azure DevOps ホーム ページ
• Azure DevOps のデータの場所
• Microsoft のプライバシーに関する声明
• Azure DevOps のサポート
• Azure DevOps に含まれる機能とサービス
• Azure セキュリティ センター
• Microsoft セキュリティ開発ライフサイクル