データ保護の概要
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 では、99.9% のアップタイムのサービス レベル アグリーメント (SLA) が提供されます。 Azure DevOps は、特定の月にその SLA を満たさなければ、月額料金の一部を払い戻します。
- ブラジルには 1 つのリージョンしかないため、ディザスター リカバリーのために、ブラジルの顧客データが米国中南部リージョンにレプリケートされます。
間違いが発生する
Microsoft では、偶発的なデータ損失から保護するために、Azure Blob Storage に格納されている BLOB と Azure SQL Database 内のデータベースの両方に特定の時点のバックアップを採用しています。 各ストレージ アカウントでは、すべての BLOB の個別のコピーが保持され、既存のデータに変更が追加されます。 これらのバックアップは不変であるため、バックアップ手順中に既存のストレージを書き換える必要がなくなります。
Azure SQL Database には、Azure DevOps によって利用される標準のバックアップ機能が含まれています。 データは 28 日間保持されます。これらのバックアップは、リージョンの停止中の復旧を容易にするために、ペアのリージョンにもレプリケートされます。
削除された組織またはプロジェクトは、削除後の 28 日間の期間内に復旧できます。 ただし、この期間が経過すると、これらのエンティティは完全に削除され、復元できません。 これらのバックアップはディザスター リカバリーの重要なコンポーネントとして機能しますが、お客様は、データの包括的な保護を確保するために、適切なデータ管理とバックアップ戦略を実践することが不可欠です。
重要
- 偶発的な削除 ここでは、サービスのインシデントの結果として発生するシナリオを示します。 顧客による資産の誤削除 (リポジトリ、作業項目、添付ファイル、成果物など) は含まれません。
- お客様が誤って削除した資産の復元はサポートされていません。 これらのバックアップは、ビジネス継続性のみを目的としており、障害や障害のシナリオからの復旧を支援するためのものです。
- まれに、バックエンドの再試行と複数のソースからデータを削除する必要があるため、削除プロセスに最大 70 日かかる場合があります。
プラクティスは重要です
データの複数のバックアップを作成しても問題ありませんが、実際に行わないと、復元が予測できない可能性があります。 人々は「バックアップは決して失敗しない。復元が行います。このステートメントは技術的には正しくありませんが、センチメントは正しいと言うことができます。
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 のライブ運用サービスとインフラストラクチャを悪用しようとします。 目標は、制御されたプロセスにおける実際の脆弱性、構成、エラー、またはその他のセキュリティ ギャップを特定することです。
チームは、これらのテストの結果をレビューして、改善の他の領域を特定し、予防システムとトレーニングの品質を向上させます。 最近の Azure DevOps 侵入テストの結果は、 Microsoft Service Trust Portal で確認できます。
資格情報のセキュリティ
Microsoft は、プロジェクトを安全かつ安全な状態に保つよう、例外なく取り組んでいます。 Azure DevOps では、複数レイヤーのセキュリティとガバナンス テクノロジ、運用プラクティス、コンプライアンス ポリシーを利用できます。 保存時と転送中の両方で、データのプライバシーと整合性を適用します。 さらに、Azure DevOps が格納する資格情報またはシークレットに関して、次のプラクティスに従います。 適切な認証メカニズムを選択する方法の詳細については、「認証の ガイドを参照してください。
重要
Azure DevOps では、代替資格情報認証はサポートされていません。 代替資格情報をまだ使用している場合は、より安全な認証方法に切り替えるよう強くお勧めします。
個人用アクセス トークン (AT)
- PAT のハッシュを格納します。
- 未加工の AT は、サーバー側でメモリ内を生成します。 32 バイトは RNGCryptoServiceProvider を介してランダムに生成され、base-32 でエンコードされた文字列として呼び出し元と共有されます。 この値は格納されません。
- PAT ハッシュは、キー コンテナーに格納されている 64 バイトの対称署名キーを使用して、未加工 PAT の HMACSHA256Hash としてサーバー側でメモリ内を生成します。
- ハッシュはデータベースに格納されます。
Secure Shell (SSH) キー
- 外側の組織 ID と SSH 公開キーのハッシュが格納されます。
- 未加工の公開キーは、SSL 経由で呼び出し元から直接提供されます。
- SSH ハッシュは、キー コンテナーに格納されている 64 バイトの対称署名キーを使用して、組織 ID と未加工の公開キーの HMACSHA256Hash としてサーバー側でメモリ内を生成します。
- ハッシュはデータベースに格納されます。
OAuth 資格情報 (JWT)
- OAuth 資格情報は、完全に自己記述型の JSON Web トークン (JWT) として問題が発生し、サービスに格納されません。
- サービスに発行および提示された JWT の要求は、キー コンテナーに格納されている証明書を使用して検証されます。
セキュリティ上の欠陥の報告
侵入テストで 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 でのRansomware Protection のを参照してください。
データのプライバシー
お客様は、お客様のデータを適切に、かつ正当な用途のために処理していることを確信している必要があります。 その保証の一部として、使用を慎重に制限する必要があります。
一般データ保護規則
一般データ保護規則 (GDPR) は、1995 年に欧州連合 (EU) データ保護指令 95/46/EC が導入されて以来、ヨーロッパにおけるデータ保護法の最大の変更です。 GDPR の詳細については、Microsoft セキュリティ センターの overview ページを参照してください。
データ所在地と主権
Azure DevOps は、米国、カナダ、ヨーロッパ、英国、インド、オーストラリア、アジア太平洋、ブラジルの 8 つの地理的な場所で利用できます。 既定では、組織は最も近い場所に割り当てられます。 ただし、組織を作成するときに別の場所を選択できます。 後で気が変わる場合は、Microsoft サポートの支援を受けて、組織を別の場所に移行できます。
Azure DevOps では、選択した場所の外部で顧客データが移動またはレプリケートされることはありません。 代わりに、データは同じ場所内の 2 番目のリージョンに geo レプリケートされます。 唯一の例外は、ディザスター リカバリーのためにデータを米国中南部リージョンにレプリケートするブラジルです。
Note
Microsoft が提供する macOS エージェントで実行されるビルドとリリースの場合、データは米国の GitHub データセンターに転送されます。
詳細については、「 Data locations for 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 に適しているかどうかを判断します。 大規模なチームの場合、導入は通常、段階的に行われ、より多くの計画が行われます。
内部プロジェクトのその他の要件としては、適切なユーザー ID のライフサイクルとパスワードの複雑さを確保するために、組織を Microsoft Entra 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 サービス 信頼ポータルの完全なレポートを確認することをお勧めします。
実行できる手順
適切なデータ保護には、ユーザー、管理者、およびユーザーからのアクティブなエンゲージメントが必要です。 Azure DevOps に格納されているプロジェクト データは、ユーザー アクセス ポイントと同じくらい安全です。 これらの組織のアクセス許可の厳格さと細分性のレベルを、プロジェクトの秘密度レベルと一致させます。
データを分類する
最初の手順は、データを分類することです。 秘密度とリスク期間に基づいてデータを分類し、侵害された場合に発生する可能性のある損害を分類します。 多くの企業には、プロジェクトが Azure DevOps に移行するときに再利用できる既存の分類方法があります。 詳細については、Microsoft Trustworthy Computing から Data 分類をダウンロードして クラウドの準備を行うことができます。
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へのアクセスをセキュリティで保護する
管理者は、Microsoft Entra ID を使用して、Azure DevOps などの Azure リソースとアプリケーションへのアクセスを制御できます。 条件付きアクセス制御を実施すると、Microsoft Entra ID は、ユーザーがアプリケーションにアクセスするために設定した特定の条件をチェックします。 ユーザーがアクセス要件を満たした後、ユーザーは認証され、アプリケーションにアクセスできます。
Azure DevOps では、カスタム Azure DevOps 認証メカニズムの特定の種類の条件付きアクセス ポリシー (IP フェンスなど) の適用がサポートされています。 これらのメカニズムには、個人用アクセス トークン、代替認証、OAuth、Secure Shell (SSH) キーが含まれます。 ユーザーがサードパーティのクライアントを介して Azure DevOps にアクセスする場合、IPv4 ベースのポリシーのみが受け入れられます。