この記事では、サービス管理者が行った変更を追跡し、Microsoft 365 テナントへの展開に承認プロセスを追加するソリューションについて説明します。 これは、Microsoft 365 テナントに対する追跡されていない変更を防ぎ、複数の Microsoft 365 テナント間の構成のずれを防ぐのに役立ちます。
Architecture
このアーキテクチャの Visio ファイル をダウンロードします。
ワークフロー
- 管理者 1 は、Microsoft 365 構成ファイルの Admin 1 のフォーク内のエントリを追加、更新、または削除します。
- 管理者 1 が、その変更を管理者 1 のフォークされたリポジトリにコミットして同期します。
- 管理者 1 が、pull request (PR) を作成して、変更をメイン リポジトリにマージします。
- ビルド パイプラインが PR に対して実行されます。
- 管理者はコードを確認し、PR をマージします。
- マージされた PR がパイプラインをトリガーして、Managed Object Format (MOF) ファイルをコンパイルします。 パイプラインは Azure Key Vault を呼び出して、MOF ファイルで使用される資格情報を取得します。
- マルチステージ パイプラインの Azure PowerShell タスクが、コンパイルされた MOF ファイルを使用して、構成変更を Microsoft365DSC 経由でデプロイします。
- 管理者は、ステージングされた Microsoft 365 テナントの変更を検証します。
- 管理者が、運用 Microsoft 365 テナントの Azure DevOps で、承認プロセスから通知を受け取ります。 管理者が、その変更を承認または拒否します。
コンポーネント
- Azure Pipelines は、継続的インテグレーションと継続的デリバリーのための Azure DevOps サービスです。 Azure Pipelines を使用してコードをテストしてビルドし、任意のターゲットに配布します。 また、Azure Pipelines を使用して品質ゲートを実装し、制御された一貫性のある方法で変更を確実にデプロイすることもできます。
- Key Vault は、トークン、パスワード、証明書、API キー、およびその他のシークレットのストレージのセキュリティを強化します。 さらに、これらのシークレットへの厳しく制御されたアクセスも提供されます。 Key Vault を使用して、Microsoft 365 テナントに構成変更を展開するために使用するサービス プリンシパルと証明書を格納します。
- Microsoft365DSC は、PowerShell Desired Stage Configuration (DSC) を使用して、Microsoft 365 テナントの展開、構成、監視を自動化します。 Microsoft365DSC を使用して、Azure Pipelines 経由で Microsoft 365 テナントに構成変更をデプロイします。
- Windows PowerShell DSC は PowerShell の管理プラットフォームです。 これを使用することで、コードとしての構成モデルを使用して開発インフラストラクチャを管理できます。 このモデルは、Microsoft365DSC が使用する基になるテクノロジです。
代替
Azure Automation で DSC を使用して、構成を中央の場所に保存し、目的の状態とのコンプライアンスのレポートを追加できます。
このアーキテクチャでは、Key Vault を使用して Microsoft 365 テナントへの認証に使用される Azure App Service 証明書またはユーザー資格情報を保存します。 Key Vault はスケーラビリティを提供します。 別の方法として、パイプライン変数を使用して、ソリューションの複雑さを軽減できます。 Windows および DSC 用の Azure 仮想マシン (VM) を使用すると、 Microsoft365DSC を使用する Microsoft 365 テナントに構成を適用および監視できます。 Azure アクション グループを使用して、Azure Windows VM が Microsoft 365DSC を使用して構成の誤差を検出したときに、Microsoft 365 管理者に電子メールを送信できます。 さらに、Azure アクション グループは webhook を実行して、 Azure Runbook をトリガーして、Microsoft 365 テナント内の構成ドリフトの レポート を生成できます。
シナリオの詳細
多くの企業が DevOps プラクティスを採用しており、それらのプラクティスを Microsoft 365 テナントに適用したいと考えています。 Microsoft 365 用の DevOps を採用しない場合、次のような一般的な問題が発生する可能性があります。
- 誤った構成
- 構成変更の追跡に関する課題
- テナント変更の承認プロセスがない
この記事で説明するソリューションを使用することにより、 Azure DevOps と Microsoft365DSCを使用して、Microsoft 365 テナント構成への変更を自動化できます。 Microsoft365DSC は、 PowerShell DSC モジュールです。 これを使用して、コードとしての構成である真の DevOps スタイルで Microsoft 365 テナントを構成および管理できます。
考えられるユース ケース
このソリューションは、以下の DevOps ツールとプラクティスを使用して、制御された自動化された方法で Microsoft 365 テナント構成を管理するのに役立ちます。
- 開発、テスト、受け入れ、および運用環境。
- マネージド サービス プロバイダーのシナリオなど、複数の顧客テナント。
考慮事項
以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
PowerShell DSC を初めて使用する人の多くが、その使い方を学習するのにいくらか時間がかかると感じています。 PowerShell について十分に理解し、スクリプトを作成した経験があると役立ちます。
セキュリティ
セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
ほとんどの Microsoft365DSC リソースでは、ユーザー名とパスワードによる認証がサポートされています。 Microsoft のベスト プラクティスでは多要素認証が推奨されるため、この種類の認証はお勧めしません。 Microsoft 365 リソースでサポートされている場合は、アプリケーション資格情報が推奨される方法です。 Microsoft 365 の SharePoint、Microsoft Entra ID、およびその他のリソースは、アプリケーション資格情報をサポートします。
Azure DevOps 上で Microsoft365DSC ソリューションを構築する場合は、 Azure Pipelines のセキュリティと 認証プロセス を利用して、実稼働テナントへのデプロイを保護できます。
コストの最適化
コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
Azure DevOps の価格情報については、「Azure DevOps の料金」を参照してください。 Key Vault をソリューションに組み込む場合は、「 Key Vault の価格」を参照してください。
Azure 料金計算ツール を使用してコストを見積もることもできます。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。
運用チームの中には、Azure DevOps が開発者向けのツールであると考えているチームもあります。 しかし、そのようなチームも、Azure DevOps を使用することでメリットを得られます。 運用チームは次のことを行えます。
- スクリプトをリポジトリに保存し、ソース管理とバージョン管理を追加する。
- スクリプトのデプロイを自動化する。
- ボードを使用してタスクとプロジェクトを追跡します。
コードとしての構成モデルの使用は、1 回限りのタスクではありません。 これは、作業方法の変化であり、チーム メンバー全員にとって根本的な変更です。 手動で変更を加える必要はもはやなくなります。 代わりに、すべてはスクリプトで実装され、自動的にデプロイされます。 チーム メンバー全員が、この変更を行うスキルを持つ必要があります。
パフォーマンス効率
パフォーマンス効率とは、ユーザーからの要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。
このソリューションは、複数の環境、複数のワークロード、または複数のチームで作業する場合に使用できます。 検証プロセスを構成して、専門家による各ワークロードの承認が必要となるようにすることができます。 また、ソリューションを拡張して、開発、テスト、受け入れ、運用シナリオなどのシナリオ、または複数の組織に対して、複数のテナントにデプロイすることもできます。
このシナリオのデプロイ
Microsoft 365 DSC ホワイトペーパー Microsoft 365DSC と Azure DevOps を使用した真の DevOps スタイルでの Microsoft 365 の管理では、このシナリオをデプロイするための詳細な手順が示されています。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Derek Smay | シニア クラウド ソリューション アーキテクト
次のステップ
- Microsoft365DSC と Azure DevOps を使用した、真に DevOps スタイルの Microsoft 365 の管理
- Microsoft365DSC ソース コード
- Microsoft365DSC YouTube チャンネル
- Microsoft365DSC サイト
- Microsoft365DSC エクスポート ジェネレーター ツール