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) 保護とライブ サイト応答を提供して、組織と関連資産へのアクセスを確保します。
DDoS 保護
場合によっては、悪意のある DDoS 攻撃がサービスの可用性に影響を及ぼす可能性があります。 Azure には、サービスに対する攻撃を防ぐのに役立つ DDoS 防御システムがあります。 このシステムでは、SYN Cookies、帯域制限、接続制限などの標準的な検出技術および回避技術を使用しています。 システムは外部からだけでなく Azure 内部からの攻撃にも耐えるように設計されています。
AAzure 防御システムに侵入できるアプリケーション固有の攻撃に対して、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 では、代替資格情報認証はサポートされていません。 代替資格情報をまだ使用している場合は、より安全な認証方法に切り替えることが強く推奨されます。
個人用アクセス トークン (PAT)
- PAT のハッシュを格納します。
- 未加工の PAT は、サーバー側でメモリ内を生成します。 RNGCryptoServiceProvider を通じて 32 バイトがランダムに生成され、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 ページを参照してください。
重要
侵入テスト活動について Microsoft に通知する必要はありませんが、Microsoft の侵入テストの実施ルールに従う必要があります。
報奨金プログラム
Azure DevOps は、Microsoft バグ報奨金プログラムに参加しています。 このプログラムは、問題を報告してくれたセキュリティ研究者に報酬を与えるとともに、より多くの人が Azure DevOps のセキュリティ維持に協力するよう促します。 詳細については、「Microsoft Azure DevOps 報奨金プログラム」を参照してください。
アクセスの制限
Microsoft は、運用環境と顧客データにアクセスするユーザーを厳密に制御します。 ユーザーの正当性を確認した後にのみ、必要最小限の権限レベルでアクセスを許可します。 チーム メンバーが緊急の問題を解決したり、構成の変更をデプロイしたりするためにアクセスする必要がある場合は、運用サービスへのジャストインタイム アクセスを申請する必要があります。 状況が解決されるとすぐに、アクセスは取り消されます。
アクセス要求と承認は別のシステムで追跡および監視されます。 システムへのすべてのアクセスは、これらの承認に関連付けられます。 承認されていないアクセスが検出された場合は、Microsoft は運用チームに調査を依頼します。
すべてのリモート システム アクセスで 2 要素認証が使用されます。 Microsoft の開発者または運用スタッフのユーザー名とパスワードが盗まれた場合でも、データは保護されたままです。 サービスへのリモート アクセスを許可する前に、スマート カード、または事前に承認された番号への電話による追加の認証チェックを行う必要があります。
サービスを管理および保守するために、Microsoft は RDP パスワード、SSL 証明書、暗号化キーなどのシークレットを使用します。 これらのシークレットはすべて、Azure portal を介して安全に管理、格納、送信されます。 これらのシークレットへのアクセスには特定のアクセス許可が必要で、アクセス許可はログに記録され、安全に記録されます。 すべてのシークレットは定期的にローテーションされ、セキュリティ イベントがある場合は必要に応じてローテーションできます。
Azure DevOps 運用チームは、強化された管理者ワークステーションを使用してサービスを管理します。 これらのマシンは最小限の数のアプリケーションを実行し、論理的にセグメント化された環境で動作します。
運用チームのメンバーは、ワークステーションにアクセスするために、2 要素認証で特定の資格情報を提供する必要があります。 すべてのアクセスが監視され、安全にログに記録されます。 サービスを外部からの改ざんから隔離するため、Outlook や Office などのアプリケーションは許可されません。これらのアプリケーションは、スピア フィッシングやその他の種類の攻撃の標的となることが多いためです。
侵入の防止と応答
データは HTTPS と SSL 経由で暗号化されるため、お客様と Azure DevOps 間の転送中にデータが傍受されたり変更されたりすることはありません。 お客様の代わりに Microsoft が Azure DevOps に格納するデータは、次のように暗号化されます。
Azure SQL データベース内の格納データは、Transparent Data Encryption を使用して暗号化されます。 この機能を使用すると、保存時のデータベース、関連付けられたバックアップ、トランザクション ログ ファイルをリアルタイムで暗号化することにより、悪意のあるアクティビティの脅威から保護できます。
Azure Blob Storage 接続を暗号化すると、転送中のデータを保護できます。 Azure Blob Storage に格納されている保存データの場合、Azure DevOps はサービス側の暗号化を使用します。
Azure DevOps チームは、Azure インフラストラクチャを使用して、サービスの重要な側面をログに記録し、監視します。 ログ記録と監視は、サービス内のアクティビティが正当であることを確認するのに役立ち、侵害や侵害の試みを検出するのに役立ちます。
すべてのデプロイと管理者のアクティビティは、運用ストレージへのオペレーター アクセスと同様に安全に記録されます。 ログ情報は自動的に分析され、悪意のある可能性のある動作や不正な動作があった場合はリアルタイムで警告が出されます。
Azure DevOps チームは、侵入の可能性や優先度の高いセキュリティの脆弱性を特定した場合、明確な対応計画を用意します。 この計画には、責任者、顧客データをセキュリティで保護するために必要な手順、および Microsoft のセキュリティ エキスパートと連携する方法の概要が記載されます。 チームは、データが公開されたり破損しりした場合には組織の所有者に通知し、状況を解決するための適切な措置を講じられるようにします。
新たな脅威に対処するために、Azure DevOps では "侵害を想定する" 戦略が採用されます。 Microsoft 内の高度に専門化されたセキュリティ エキスパート チームが、高度な攻撃者の役割を担います。 このチームは、侵入の検出と応答をテストし、実際の攻撃の準備状況と影響を正確に測定します。 この戦略により、サービスの脅威の検出、応答、防御が強化されます。 また、チームはセキュリティ プログラム全体の有効性を検証して改善することもできます。
ランサムウェア攻撃の対策
Azure DevOps では、Azure のコントロールを使用して、ランサムウェア攻撃の防止、検出、応答を促します。 Azure がランサムウェア攻撃から顧客を保護する方法の詳細については、「Azure でのランサムウェア対策」を参照してください。
データのプライバシー
Microsoft がお客様のデータを適切に、かつ合法的な目的で取り扱っていることを確信してください。 その保証の一環として、使用を慎重に制限することも含まれます。
一般データ保護規則
一般データ保護規則 (GDPR) は、1995 年に欧州連合 (EU) データ保護指令 95/46/EC が導入されて以来、ヨーロッパのデータ保護法における最大の変化です。 GDPR の詳細については、Microsoft セキュリティ センターの概要ページを参照してください。
データの保存場所と主権
Azure DevOps は、米国、カナダ、ヨーロッパ、英国、インド、オーストラリア、アジア太平洋、ブラジルの 8 つの地理的な場所で利用できます。 既定では、組織は最も近い場所に割り当てられます。 ただし、組織を作成するときに別の場所を選択できます。 後で気が変わった場合は、Microsoft サポートの支援を受けて組織を別の場所に移行できます。
Azure DevOps では、選択した場所の外部で顧客データが移動またはレプリケートされることはありません。 代わりに、データは同じ場所内の 2 番目のリージョンに geo レプリケートされます。 唯一の例外は、ディザスター リカバリーのためにデータを米国中南部リージョンにレプリケートするブラジルです。
注
Microsoft 提供の macOS エージェントで実行されるビルドとリリースの場合、データは米国の GitHub データセンターに転送されます。
詳細については、「Azure DevOps のデータの場所」を参照してください。
法執行機関のアクセス
場合によっては、法執行機関などの第三者が、Azure DevOps に格納されている顧客データにアクセスするために Microsoft に問い合わせることがあります。 Microsoft は解決のために、リクエストを組織の所有者にリダイレクトするように努めます。 裁判所命令により Microsoft が顧客データを第三者に開示することを強制する場合、Microsoft は法的に禁止されていない限り、組織の所有者に事前に通知するよう合理的な努力をします。
顧客によっては、法執行活動に対する特定の法的管轄権を確保するために、特定の地理的な場所にデータを保存することを要求してきます。 ソース コード、作業項目、テスト結果、地理的に冗長化されたミラー、オフサイト バックアップなどのすべての顧客データは、前述のいずれかの場所に保存されます。
Microsoft のアクセス
Microsoft の従業員は、Azure DevOps に格納されている顧客データへのアクセスを取得する必要があります。 予防措置として、顧客データにアクセスできる (または将来アクセスできる可能性のある) すべての従業員は、過去の雇用歴や犯罪歴を含む身元調査に合格する必要があります。 運用システムへのアクセスは、ライブ サイトでのインシデントまたはその他の承認済みメンテナンス アクティビティ (ログに記録および監視されるもの) が発生した場合にのみ許可されます。
システム内のすべてのデータが同じように扱われるわけではないため、データを次のタイプに分類します。
- 顧客データ: Azure DevOps にアップロードするもの。
- 組織データ: 組織にサインアップまたは組織を管理するときに送信する情報。
- Microsoft データ: サービスの運用に必要な情報、またはサービスの運用を通じて収集される情報。
分類に基づいて、使用シナリオ、地理的な場所の要件、アクセス制限、および保持要件を制御します。
Microsoft のプロモーション使用
Microsoft では、顧客にとって役立つ可能性のあるその他の機能やサービスについてお知らせするために、時々顧客に連絡を取ることがあります。 すべての顧客がこれらのオファーについての連絡を希望しているわけではないため、マーケティング メールの通信のオプトインとオプトアウトを選択できます。
Microsoft は、顧客データを使用して、特定のユーザーまたは組織に特定のオファーをターゲットにすることはありません。 代わりに、組織データを使用し、組織レベルで使用状況の統計を集計して、特定のオファーを受け取るグループを決定します。
管理者がユーザー フィードバック収集を制御するためのプライバシー ポリシーの管理
フィードバック切り替え機能を使用すると、Azure DevOps 組織の所有者は、ユーザーにフィードバックの提供と送信を求めるメッセージを表示するかどうかを制御できます。 この機能は、フィードバック プラクティスが組織のプライバシーとガバナンス のポリシーと一致するようにするために不可欠です。
信頼の構築
Microsoft が Azure DevOps のために行っているその他の取り組みについても確信を得られます。 これらの取り組みには、Microsoft の内部導入ポリシー、サービスの状態の透明性のレベル、情報セキュリティを管理するための Microsoft のシステムの認定取得に向けた進捗などが含まれます。
内部導入
Microsoft チームは、内部で Azure DevOps を導入しています。 Azure DevOps チームは 2014 年に組織に移行し、それを広く使用しています。 他のチームの導入計画を可能にするためのガイドラインを確立しました。
既存の DevOps システムへの投資により、大規模なチームは小規模なチームよりも段階的に移行します。 迅速に移行するチームのために、プロジェクト分類アプローチを確立しました。 プロジェクトの特性に基づいてリスク許容範囲を評価し、プロジェクトが Azure DevOps に適しているかどうかを判断します。 大規模なチームの場合、導入は通常、より綿密な計画に基づいて段階的に行われます。
内部プロジェクトのその他の要件には、適切なユーザー ID ライフサイクルとパスワードの複雑さを確保するために、組織を Microsoft Entra ID に関連付けることが含まれます。 機密性の高いプロジェクトでは、2 要素認証も必要です。
コンプライアンス認定
データ セキュリティに関する Microsoft の手順について第三者による評価を知ることに興味があるかもしれません。 Azure DevOps は、次の認定資格を取得しました。
- ISO 27001:2022
- 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 Service Trust Portal から入手できます。
Consensus Assessment Initiative Questionnaire (CAIQ) は、組織がクラウド サービス プロバイダーのセキュリティ プラクティスと機能を評価するのに役立ちます。 セキュリティと透明性への取り組みに沿って、私たちは最近、Azure DevOps の CAIQ 評価を完了しました。 Microsoft Service Trust Portal でレポート全文を確認することをお勧めします。
実行できる手順
適切なデータ保護には、お客様、お客様の管理者、お客様のユーザーの積極的な関与が必要です。 Azure DevOps に格納されているプロジェクト データの安全性は、ユーザー アクセス ポイントの安全性と同程度です。 これらの組織のアクセス許可の厳密さと細分性のレベルを、プロジェクトの機密性レベルに一致させてください。
データを分類する
最初の手順は、データを分類することです。 機密性とリスク範囲、および侵害された場合に発生する可能性のある損害に基づいてデータを分類します。 多くの企業には、プロジェクトを Azure DevOps に移行する際に再利用できる既存の分類方法があります。 詳細については、Microsoft の信頼できるコンピューティングから「クラウドに備えたデータの分類」をダウンロードできます。
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 作成者 | ユーザー | 組織 |
| すべての作業資産の単一のユーザー名とパスワード | いいえ | あり |
| パスワードの有効期間と複雑さの制御 | ユーザー | 組織 |
| Azure DevOps メンバーシップの制限 | すべての Microsoft アカウント | 組織のディレクトリ |
| トレース可能な ID | いいえ | あり |
| 組織と IP の所有権 | 不明 | 組織 |
| 2 要素認証の登録 | ユーザー | 組織 |
| デバイス ベースの条件付きアクセス | いいえ | 組織 |
組織でこのサポートを構成する方法の詳細については、こちらを参照してください。
2 要素認証を必須にする
サインインに複数の要素を要求することで、組織へのアクセスを制限できます。 Microsoft Entra ID を使用して、複数の要素を要求できます。 たとえば、すべての認証要求に対して、ユーザー名とパスワードに加えて電話認証を要求できます。
BitLocker を使用する
機密性の高いプロジェクトの場合は、Windows ラップトップまたはデスクトップ コンピューターで BitLocker を使用できます。 BitLocker は、Windows とデータが存在するドライブ全体を暗号化します。 BitLocker を有効にすると、そのドライブに保存したすべてのファイルが自動的に暗号化されます。 コンピュータが悪意のある人物の手に渡った場合でも、BitLocker により、プロジェクトのデータのローカル コピーへの不正アクセスを防止できます。
代替認証資格情報の使用を制限する
Git 関連ツールの既定の認証メカニズムは、代替認証 (基本認証と呼ばれることもある) です。 このメカニズムにより、ユーザーは Git コマンドライン操作中に使用する代替のユーザー名とパスワードを設定できます。 ユーザーはこのユーザー名とパスワードの組み合わせを使用して、そのユーザーがアクセス許可を持っている他のデータにアクセスできます。 本質的に、代替認証資格情報は、既定のフェデレーション認証よりも安全性が低くなります。
セキュリティを強化する選択を引き続き行うことができます。 すべての通信は HTTPS で送信されるため、パスワードの複雑さに関する要件があります。 組織は、プロジェクトのセキュリティ要件を満たすためにさらにポリシーが必要かどうかを継続的に評価する必要があります。
組織のセキュリティ要件を満たしていないと判断した場合は、代替認証資格情報を無効にすることができます。 詳細については、「組織のアプリケーション接続とセキュリティ ポリシーを変更する」を参照してください。
組織へのアクセスをセキュリティで保護する
管理者は、Microsoft Entra ID を使用して、Azure DevOps などの Azure リソースとアプリケーションへのアクセスを制御できます。 条件付きアクセス制御が適用されると、Microsoft Entra ID は、アプリケーションにアクセスするユーザーに対して設定された特定の条件を確認します。 ユーザーは、アクセス要件を満たすと承認され、アプリケーションにアクセスできます。
Azure DevOps では、カスタム Azure DevOps 認証メカニズムに対して特定の種類の条件付きアクセス ポリシー (IP フェンシングなど) の適用がサポートされています。 これらのメカニズムには、個人用アクセス トークン、代替認証、OAuth、Secure Shell (SSH) キーが含まれます。 ユーザーがサードパーティのクライアントを通じて Azure DevOps にアクセスする場合は、IPv4 ベースのポリシーのみが受け入れられます。