Azure DevTest Labs インフラストラクチャのガバナンス

[アーティクル]
09/27/2023

この記事では、組織内での DevTest Labs 用リソースの調整と管理について説明します。

リソース

Azure サブスクリプション内で DevTest Labs リソースを調整する

組織で一般的なアプリケーション開発用に Azure を使い始める前に、IT プランナーはまずサービスの全体的ポートフォリオの一部として機能を導入する方法を確認する必要があります。確認では次の問題領域に対処する必要があります。

アプリケーション開発ライフサイクルに関連するコストはどのように測定しますか?
組織は提案されたサービスオファリングと企業セキュリティポリシーをどのように調整しますか?
開発環境と運用環境を分離するためにセグメント化が必要ですか?
長期的な管理、安定性、成長を容易にするためにどのような制御が導入されますか?

最初の推奨される方法は、運用サブスクリプションと開発サブスクリプションの間の境界が線引きされている組織の Azure 分類を確認することです。次の図では、提案される分類は開発/テスト環境と運用環境の論理的な分離に対応しています。この方法では、組織は環境ごとに個別に関連するコストを追跡するための部門コードを導入できます。詳細については、「Prescriptive subscription governance」(サブスクリプションの規範的なガバナンス) をご覧ください。さらに、Azure タグを使用して、追跡用と課金用のリソースを整理できます。

2 番目の推奨される方法は、Azure Enterprise Portal 内で DevTest サブスクリプションを有効にすることです。これにより、組織は Azure エンタープライズサブスクリプションでは通常使用できないクライアントオペレーティングシステムを実行できます。そして、計算に対してのみ支払い、ライセンスの心配はしなくてもよい、エンタープライズソフトウェアを使います。 Microsoft SQL Server などの IaaS 内のギャラリーイメージを含む指定されたサービスの課金が消費量のみに基づくことが保証されます。 Azure DevTest サブスクリプションの詳細については、Enterprise Agreement (EA) のお客様の場合はこちらを、従量課金制のお客様の場合はこちらをご覧ください。

Diagram showing how resources alignment with subscriptions.

このモデルでは、組織は大規模な Azure DevTest Labs を柔軟にデプロイできます。組織は、100 から 1000 台の仮想マシンを使用するさまざまな部署で何百ものラボを並列で実行することをサポートできます。構成管理とセキュリティ制御の同じ原則を共有できる一元的なエンタープライズラボソリューションの概念を促進します。

また、このモデルでは、組織が Azure サブスクリプションに関連付けられているリソースの制限を使い果たすことがないことも保証されます。サブスクリプションとサービス制限の詳細については、「Azure サブスクリプションとサービスの制限、クォータ、制約」をご覧ください。 DevTest Labs のプロビジョニングプロセスでは、多数のリソースグループを使用する可能性があります。 Azure DevTest サブスクリプションのサポート要求を通じて制限を増やすことを要求できます。開発サブスクリプションの使用が増えても、運用サブスクリプション内のリソースは影響を受けません。 DevTest Labs のスケーリングの詳細については、「DevTest Labs でのクォータと制限のスケール」をご覧ください。

考慮する必要がある一般的なサブスクリプションレベル制限は、運用サブスクリプションと開発サブスクリプションの両方をサポートするためにネットワークの IP 範囲を割り当てる方法です。これらの割り当てでは、時間経過による増加を考慮する必要があります (Azure の実装を既定にするのではなく、企業がネットワークスタックを管理する必要があるオンプレミスの接続または別のネットワークトポロジを想定)。推奨される方法は、小さいサブネットを含む複数の仮想ネットワークを使用するのではなく、大きい IP アドレスプレフィックスを割り当てられ、多数の大きいサブネットで分割された、いくつかの仮想ネットワークを使用することです。たとえば、10 個のサブスクリプションで、10 個の仮想ネットワーク (サブスクリプションごとに 1 つ) を定義できます。分離を必要としないすべてのラボでは、サブスクリプションの仮想ネットワーク上の同じサブネットを共有できます。

ラボあたりのユーザーの数と組織あたりのラボの数

同じ開発プロジェクトに関連付けられている部署と開発グループは、同じラボに関連付ける必要があります。両方のグループに同じ種類のポリシー、イメージ、およびシャットダウンポリシーを適用できます。

また、地理的境界を考慮することが必要な場合があります。たとえば、米国 (US) 北東部の開発者は、米国東部 2 でプロビジョニングされたラボを使用できます。また、テキサス州ダラスおよびコロラド州デンバーの開発者は、米国中南部のリソースを使用できます。外部のサードパーティと共同作業する場合は、社内開発者によって使用されていないラボに割り当てることができます。

また、Azure DevOps Projects 内の特定のプロジェクトのラボを使用することもできます。その後、指定された Microsoft Entra グループによってセキュリティを適用すると、両方のリソースのセットにアクセスできます。ラボに割り当てられた仮想ネットワークは、ユーザーを統合する別の境界になる場合があります。

リソースの削除の防止

ラボレベルで適切なアクセス許可を設定し、承認されたユーザーのみがリソースを削除したりラボのポリシーを変更したりできるようにしてください。開発者は、DevTest Labs ユーザー グループ内に配置する必要があります。開発リーダーまたはインフラストラクチャリーダーが、DevTest Labs 所有者になる必要があります。ラボの所有者は 2 人だけにすることをお勧めします。破損を防ぐため、このポリシーをコードリポジトリに拡張します。ラボのユーザーは、リソースを使用する権限はありますが、ラボのポリシーを更新することはできません。各組み込みグループがラボ内で持っているロールと権限の一覧については、「Azure DevTest Labs での所有者とユーザーの追加」を参照してください。

コストと所有権の管理

コストと所有権は、開発およびテスト用の環境の構築を検討するときの主な懸案事項です。このセクションでは、コストを最適化し、環境全体で所有権を整合させるのに役立つ情報を提供します。

コストを最適化する

コストの最適化には、DevTest Labs のいくつかの組み込み機能が利用できます。ユーザーのアクティビティを制限するには、コスト管理としきい値およびポリシーに関するページをご覧ください。

開発とテストのワークロードに DevTest Labs を利用するときは、Enterprise Agreement の一部として Enterprise Dev/Test サブスクリプションのベネフィットの利用を検討してください。または、従量課金制をご利用の場合は、従量課金制の DevTest プランを検討してください。

このアプローチには、いくつかの利点があります。

Windows 仮想マシン、クラウドサービス、HDInsight、App Service、および Logic Apps について特別な低料金の Dev/Test 価格
他の Azure サービスについての魅力的な Enterprise Agreement (EA) 価格
ギャラリー内の専用の Dev/Test イメージ (Windows 8.1 と Windows 10 を含む) へのアクセス

Enterprise Dev/Test サブスクリプション内で実行されている Azure リソースを利用できるのは、アクティブな Visual Studio サブスクライバーのみ (標準サブスクリプション、年次クラウドサブスクリプション、月次クラウドサブスクリプション) です。ただし、エンドユーザーはアプリケーションにアクセスして、フィードバックを提供したり、承認テストを実行したりできます。このサブスクリプション内のリソースは、アプリケーションの開発とテストにのみ使用できます。アップタイムの保証はありません。

DevTest プランを使用する場合、このベネフィットの利用はアプリケーションの開発とテストだけが対象となります。 Azure DevOps および HockeyApp の使用を除いて、このサブスクリプションでの使用には、金銭的な補償を伴う SLA は付随しません。

組織全体でロールベースのアクセスを定義する

全社的 IT 部門は必要なもののみを所有し、プロジェクトチームおよびアプリケーションチームが必要なレベルの制御を行えるようにする必要があります。一般にこれは、全社的 IT 部門はサブスクリプションを所有し、ネットワークの構成などの中核的 IT 機能を扱うことを意味します。サブスクリプションの所有者のセットは小規模にする必要があります。これらの所有者は、必要に応じて他の所有者を指名したり、"パブリック IP なし" などのサブスクリプションレベルのポリシーを適用したりできます。

レベル 1 やレベル 2 のサポートなど、サブスクリプション全体へのアクセスを必要とするユーザーのサブセットが存在する場合があります。その場合は、このようなユーザーに共同作成者のアクセス権を付与してリソースを管理できるようにしながら、ポリシーへのアクセスやその変更は許可しないことをお勧めします。

DevTest Labs リソースの所有者は、プロジェクトチームまたはアプリケーションチームに近い方である必要があります。そうした所有者は、マシンとソフトウェアの要件を理解しています。ほとんどの組織では、プロジェクトまたは開発のリーダーが DevTest Labs リソースの所有者です。この所有者は、ラボ環境内のユーザーとポリシーを管理でき、DevTest Labs 環境にあるすべての仮想マシンを管理できます。

プロジェクトチームとアプリケーションチームのメンバーは、DevTest Labs ユーザーロールに追加します。これらのユーザーは、ラボおよびサブスクリプションレベルのポリシーに従って仮想マシンを作成できます。ユーザーは各自の仮想マシンを管理できますが、他のユーザーに属する仮想マシンを管理することはできません。

詳細については、Azure エンタープライズスキャフォールディングのサブスクリプションの規範的なガバナンスに関するページを参照してください。

会社のポリシーとコンプライアンス

このセクションでは、Azure DevTest Labs インフラストラクチャに対する会社のポリシーとコンプライアンスの管理に関するガイダンスを提供します。

パブリックとプライベートの成果物リポジトリ

パブリック成果物リポジトリでは、最もよく使用されるソフトウェアパッケージの初期セットが提供されます。共通の開発ツールとアドインの再生成に時間をかける必要がなく、すばやくデプロイするのに役立ちます。独自のプライベートリポジトリのデプロイを選択できます。パブリックリポジトリとプライベートリポジトリを並列で使用できます。パブリックリポジトリを無効にすることもできます。プライベートリポジトリをデプロイする条件は、以下の質問と考慮事項を基に決定する必要があります。

組織には、DevTest Labs オファリングの一部として企業でライセンスされたソフトウェアを使用する要件がありますか。答えが "はい" の場合は、プライベートリポジトリを作成する必要があります。
組織は特定の操作を提供するカスタムソフトウェアを開発しており、それは全体的なプロビジョニングプロセスの一部として必要ですか。答えが "はい" の場合は、プライベートリポジトリをデプロイする必要があります。
組織のガバナンスポリシーで分離が必要であり、外部リポジトリの構成を組織が直接管理できない場合は、プライベートの成果物リポジトリをデプロイする必要があります。このプロセスの一環として、パブリックリポジトリの初期コピーをコピーし、プライベートリポジトリと統合できます。その後、パブリックリポジトリを無効にして、組織内のだれもそれ以上アクセスできないようにすることができます。この方法では、組織内のすべてのユーザーに対して、組織によって承認された単一のリポジトリのみを使用することが強制され、構成のずれが最小限になります。

単一のリポジトリか複数のリポジトリか

組織の全体的なガバナンスと構成管理戦略の一環として、集中管理されたリポジトリを使用することをお勧めします。複数のリポジトリを使用すると、時間の経過と共に管理されていないソフトウェアのサイロになる可能性があります。中央リポジトリでは、複数のチームがプロジェクト用にこのリポジトリから成果物を使用できます。それにより、標準化とセキュリティが強制され、管理しやすく、作業の重複がなくなります。一元化の一環として、長期的な管理と持続性のために以下の操作が推奨されます。

Azure サブスクリプションで認証と承認に使用されているものと同じ Microsoft Entra テナントを、Azure Repos と関連付けます。
一元管理する All DevTest Labs Developers という名前のグループを Microsoft Entra ID に作成します。成果物の開発に関与するすべての開発者を、このグループに入れる必要があります。
同じ Microsoft Entra グループを使用して、Azure Repos リポジトリおよびラボへのアクセスを提供できます。
Azure Repos でブランチまたはフォークを使用して、開発中のリポジトリとプライマリ運用リポジトリを分離する必要があります。コンテンツは、適切なコードレビュー後に pull request でメインブランチのみに追加されます。コードレビューで変更が承認されたら、メインブランチのメンテナンスを担当する開発リーダーが、更新されたコードをマージします。

企業のセキュリティポリシー

組織は、次の方法で企業のセキュリティポリシーを適用できます。

包括的なセキュリティポリシーを開発して発行します。ポリシーでは、クラウドの資産であるソフトウェアに関連付けられている許容される使用方法の規則を明確に示します。また、ポリシーに明らかに違反することも定義します。
カスタムイメージ、カスタム成果物、および Active Directory で定義されているセキュリティ領域内のオーケストレーションを可能にするデプロイプロセスを開発します。このアプローチにより、会社の境界が強制され、共通の環境コントロールのセットが設定されます。開発者は、環境に対するこれらのコントロールを、全体的なプロセスの一部としてセキュリティ保護された開発ライフサイクルを開発して従うときに考慮できます。また、開発の妨げになる可能性のある過剰な制限のない環境を提供しながら、妥当なコントロールのセットを提供するという目的もあります。ラボの仮想マシンを含む組織単位 (OU) でのグループポリシーは、運用環境の全体的なグループポリシーのサブセットでもかまいません。または、識別されたリスクを適切に軽減するための別のセットでもかまいません。

データ整合性

組織は、データ整合性を確保して、リモート開発者がコードを削除したり、マルウェアや未承認のソフトウェアを導入したりできないようにできます。 DevTest Labs を使用してリモートで共同作業する外部のコンサルタント、請負業者、または従業員からの脅威を軽減するための複数のコントロールレイヤーがあります。

前に説明したように、最初のステップでは、ユーザーがポリシーに違反したときの影響が明確に説明されている許容される使用ポリシーを起草して定義する必要があります。

リモートアクセスに対するコントロールの最初のレイヤーでは、ラボに直接接続されていない VPN 接続経由でリモートアクセスポリシーを適用します。

コントロールの第 2 のレイヤーでは、リモートデスクトップからのコピーと貼り付けを禁止するグループポリシーオブジェクトのセットを適用します。環境外の FTP や RDP サービスなど、環境からの送信サービスを許可しないネットワークポリシーを実装できます。ユーザー定義のルーティングですべての Azure ネットワークトラフィックをオンプレミスに強制的に戻すことはできますが、プロキシでコンテンツとセッションをスキャンして制御しない限り、データのアップロードを許可する可能性があるすべての URL をルーティングできません。外部ネットワークリソースのブリッジを禁止するように、DevTest Labs をサポートする仮想ネットワーク内でパブリック IP アドレスを制限できます。

最終的には、同じ種類の制限を組織全体に適用する必要があります。それには、コンテンツの送信を受け入れる可能性があるリムーバブルメディアまたは外部 URL のすべての可能な方法についても考慮する必要があります。セキュリティ担当者とセキュリティポリシーを検討して実装してください。詳しい推奨事項については、Microsoft のサイバーセキュリティに関するページをご覧ください。

アプリケーションの移行と統合

開発/テストラボ環境が確立された後は、次の質問について考慮する必要があります。

プロジェクトチーム内で環境をどのように使用しますか。
どのようにして必要な組織のポリシーに確実に従い、アプリケーションに機敏に価値を追加できるようにしますか。

Azure Marketplace イメージとカスタムイメージ

特定の問題または組織の要件がない限り、Azure Marketplace を既定で使用する必要があります。問題や要件とは、たとえば次のようなものです。

基本イメージの一部としてアプリケーションを含める必要がある複雑なソフトウェアのセットアップ。
アプリケーションのインストールとセットアップに多くの時間がかかる場合。これは、Azure Marketplace イメージに追加される計算時間を効率的に使用していないことになります。
開発者やテスト担当者が迅速に仮想マシンにアクセスする必要があり、新しい仮想マシンのセットアップ時間を最小限にしたい場合。
コンプライアンスまたは法規制の条件 (たとえば、セキュリティポリシー) をすべてのマシンに適用する必要がある場合。

カスタムイメージの使用は慎重に検討してください。基になっている基本イメージの VHD ファイルを管理する必要が生じるため、複雑さが増します。また、基本イメージにソフトウェア更新プログラムを定期的に適用する必要があります。これらの更新プログラムには、新しいオペレーティングシステム (OS) の更新と、ソフトウェアパッケージ自体に必要なすべての更新または構成変更が含まれます。

定型イメージとカスタムイメージ

通常、このシナリオでの決定要因はコストと再利用です。

次の場合には、カスタムイメージを作成することでコストを削減できます。

イメージを必要とするユーザーまたはラボが多数存在する。
基本イメージの上に多数のソフトウェアを追加したイメージが必要である。

このソリューションを使用する場合、イメージを作成するのは 1 回ということになります。カスタムイメージを使用すれば、仮想マシンのセットアップ時間が短縮されます。セットアップ中に仮想マシンを実行することによるコストは発生しません。

もう 1 つの要因は、ソフトウェアパッケージに対する変更の頻度です。ビルドを毎日実行し、ソフトウェアをユーザーの仮想マシンに展開する必要がある場合は、カスタムイメージではなく定型イメージの使用を検討してください。

ネットワーク構成を設定するパターン

開発用とテスト用の仮想マシンがパブリックインターネットに接続できないようにする場合、受信トラフィックと送信トラフィックの 2 つの側面を考慮する必要があります。

インバウンドトラフィック: 仮想マシンにパブリック IP アドレスが割り当てられていなければ、そのマシンにインターネットから到達することはできません。サブスクリプションレベルのポリシーを設定して、ユーザーがパブリック IP アドレスを作成できないようにするのが、一般的なアプローチです。

アウトバウンドトラフィック: 仮想マシンがパブリックインターネットに直接接続できないようにし、企業のファイアウォールをトラフィックが通過するよう強制するには、強制ルーティングを使用して、オンプレミスのトラフィックを Azure ExpressRoute または VPN 経由でルーティングできます。

Note

プロキシ設定のないトラフィックをブロックするプロキシサーバーがある場合は、ラボの成果物ストレージアカウントに対する例外を追加することを忘れないでください。

仮想マシンまたはサブネットに対してネットワークセキュリティグループを使用することもできます。このステップにより、トラフィックを許可またはブロックする保護レイヤーが追加されます。

新規の仮想ネットワークと既存の仮想ネットワーク

VM で既存のインフラストラクチャとやり取りする必要がある場合は、DevTest Labs 環境内の既存の仮想ネットワークの使用を検討する必要があります。 ExpressRoute を使用する場合は、サブスクリプションに割り当てられた IP アドレス空間をフラグメント化しないように、仮想ネットワークとサブネットの数はできるだけ少なくしてください。また、こちら (ハブ - スポークモデル) では、仮想ネットワークピアリングパターンの使用も検討してください。このアプローチでは、仮想ネットワークとサブネットが、特定のリージョン内でサブスクリプションの境界を越えて通信を行えるようになります。

各 DevTest Labs 環境に専用の仮想ネットワークを割り当てることもできますが、サブスクリプションあたりの仮想ネットワーク数に制限があります。既定の数は 50 ですが、この制限は 100 まで増やすことができます。

共有 IP アドレス、パブリック IP アドレス、プライベート IP アドレス

サイト間 VPN または ExpressRoute を使用する場合は、マシンが内部ネットワーク経由ではアクセスできてもパブリックインターネット経由ではアクセスできないように、プライベート IP アドレスの使用を検討します。

注意

ラボの所有者は、このサブネットポリシーを変更して、ユーザーが各自の VM に誤ってパブリック IP アドレスを作成できないようにすることができます。サブスクリプションの所有者は、パブリック IP アドレスが作成されるのを防ぐサブスクリプションポリシーを作成する必要があります。

共有パブリック IP アドレスを使用すると、ラボ内の仮想マシンはパブリック IP アドレスを共有します。この方法は、特定のサブスクリプションに対するパブリック IP アドレスの制限が違反されるのを防ぐのに役立ちます。

ラボの制限

注意する必要があるラボの制限がいくつかあります。以降のセクションでは、これらの制限について説明します。

サブスクリプションあたりのラボの制限

サブスクリプションごとに作成できるラボの数に特定の制限はありません。ただし、サブスクリプションごとに使用できるリソースの量には制限があります。 Azure サブスクリプションの制限とクォータおよびこれらの制限を引き上げる方法に関する記事をご覧ください。

ラボあたりの VM の制限

ラボごとに作成できる VM の数に特定の制限はありません。ただし、使用できるリソース (VM コア、パブリック IP など) はサブスクリプションごとに制限されています。 Azure サブスクリプションの制限とクォータおよびこれらの制限を引き上げる方法に関する記事をご覧ください。

ユーザー単位またはラボ単位の仮想マシンの数の制限

ユーザーごと、またはラボごとの仮想マシンの数を検討するときは、3 つの主な懸案事項があります。

ラボのリソースにチームが費やすことのできる総コスト。多くのマシンを起動するのは簡単です。コストを制御するための 1 つのメカニズムは、ユーザーごとおよびラボごとの VM の数を制限することです。
ラボ内の仮想マシンの総数は、使用できるサブスクリプションレベルのクォータの影響を受けます。上限値の 1 つは、サブスクリプションあたり 800 リソースグループです。現在、DevTest Labs では (共有パブリック IP アドレスが使用されていない場合) VM ごとに新しいリソースグループが作成されます。サブスクリプションに 10 個のラボがある場合、ラボごとの仮想マシンの数は約 79 になります (上限値 800 から、10 個のラボ自体のリソースグループの数 10 を引いた値)。
たとえば、ラボが ExpressRoute 経由でオンプレミスに接続されている場合は、VNET/サブネット用に使用可能な IP アドレス空間が定義されています。ラボ内の VM の作成が失敗しないようにするには (エラー: IP アドレスを取得できない)、ラボの所有者は、使用可能な IP アドレス空間に合わせて、ラボあたりの最大 VM 数を指定できます。

Resource Manager テンプレートを使用する

テスト環境のための Azure DevTest Labs の使用に関するページの手順に従って Resource Manager テンプレートをデプロイします。基本的には、Resource Manager テンプレートを Azure Repos または GitHub Git リポジトリにチェックインし、テンプレート用のプライベートリポジトリをラボに追加します。

DevTest Labs を使用して開発マシンをホストする場合には、このシナリオが役に立たない可能性があります。運用環境の典型であるステージング環境を構築する際に、このシナリオを使用してください。

ラボごとまたはユーザーごとの仮想マシン数のオプションは、ラボ自体にネイティブに作成されるマシンの数のみを制限するものです。 Resource Manager テンプレートを使用したどの環境による作成も、このオプションでは制限されません。