環境戦略を確立する

Power Platform 環境は、データ、アプリ、フロー、接続などの資産の管理に使用できるコンテナーです。また、組織のメンバーがリソースを使用するために必要なアクセス許可も管理できます。 この記事では、Microsoft Power Platform の環境に関する重要な詳細について手順を追って説明し、環境を積極的に管理することでメリットを得られる推奨方法について説明します。 詳細: Microsoft Power Platform 環境の概要

環境戦略の開発とは、リソースを保護および編成しながら、組織の生産的な開発をサポートする方法で、環境およびデータ セキュリティの他のレイヤーを構成することを意味します。 環境のプロビジョニングとアクセスを管理し、その中のリソースを制御するための戦略は、次の点で重要です。

  • データとアクセスのセキュリティを保護する。
  • 既定の環境の使い方を正しく理解する。
  • 環境を必要な数だけ正しく管理し、容量が余ったり不足したりしないようにする。
  • アプリケーション ライフサイクル管理 (ALM) を促進する。
  • リソースを論理的に分類して整理する。
  • 専用環境にアプリを配置し、運用環境にあるアプリを特定する操作 (およびヘルプデスク) をサポートする。
  • データが許容可能な地域に保存および送信されていることを確認する (パフォーマンスとコンプライアンスの理由による)。
  • 開発中のアプリケーションの隔離を確保する。

環境を理解する

始める前に、一部の環境とセキュリティの重要事項を見てみましょう。

  • 環境は、作成時に構成された地理的位置に関連付けられます。
  • 環境を利用して、開発、テスト、運用など、目的別に異なるユーザーをターゲットに設定できます。
  • データ損失防止 (DLP) ポリシーを個々の環境またはテナントに適用できます。
  • 各テナントには既定の環境があります。
  • 既定以外の環境は、ライセンスされている Power Apps、Power Automate、および Dynamics 365 ユーザーにより作成されます。 作成は、テナント設定を介してグローバル管理者とサービス管理者のみに制限できます。
  • 既定以外の環境では、より詳細なアクセス許可制御ができます。
  • 環境は 1 つまたは 0 の Microsoft Dataverse インスタンスを保持することができます。
  • 環境には、定義済みのセキュリティ ロールが用意されています。これらのセキュリティ ロールは、一般的なユーザー タスクを反映し、アプリの使用に必要な最小限の業務データへのアクセスを許可する、というセキュリティのベスト プラクティスの目的に沿うようにアクセス レベルが定義されています。
  • 規定の環境のルーティング は、プレミアムなガバナンス機能です。 この機能により、初めて make.powerapps.com にアクセスした 新しい作成者を、Power Platform 管理者が自動的に自分専用の開発者環境に誘導することができます。

環境の種類

環境戦略の開発を開始する前に、異なる環境の種類を理解するようにしてください。

戦略の開発

環境戦略の出発点は、次のとおりです。

  • 管理者に Microsoft Power Platform サービス管理者または Dynamics 365 サービス管理者のロールを割り当てます。
    これらのロールは、Power Apps キャンバス アプリ、フロー、モデル駆動型アプリ、環境、カスタム・コネクタ、 接続、ゲートウェイ、Power Apps ポータル、AI Builder モデル、およびすべての Dataverse インスタンスへの管理アクセスを提供します。 この役割は、グローバル テナント管理者アクセスを必要とせず、Microsoft Power Platform の管理に専念している管理者に割り当てる必要があります。

  • 新しい運用環境の作成を管理者に制限します。
    環境の作成を制限するは、考慮されていない容量消費を防ぎ、管理する環境の数を減らす点で、制御するのに役立ちます。 ユーザーが中央 IT に環境を要求する必要がある場合、管理者がゲートキーパーであれば、ユーザーがどんな作業をしているかを簡単に確認できます。

  • 既定の環境を、ビジネス グループのユーザーおよびチームの生産性環境として扱います。
    その環境の目的をわかりやすくするために、管理センターを介して環境の名前を変更することをお勧めします。 既定はユーザーとチームの生産性シナリオに使用されますが、ビジネス上重要なアプリやミッション クリティカルなアプリには使用されないことを明確に伝えます。 この環境は、SharePoint およびプロジェクトなど製品との統合をホストしているため、無効にしたり削除したりすることはできません。 ユーザーおよびチームの生産性環境への階層的アプローチをお勧めします。

  • 環境へのアクセスまたは環境の作成を要求するためのプロセスを確立します。
    環境の作成がロックされ、既定でファースト パーティ統合アプリ用に設定されている場合、開発者と管理者の間で意図とサポートが明確に伝達される新しい専用環境を要求して、適切な開発プロジェクトを開始する必要があることを組織に明確にします。 次のセクションでは、自動化された環境作成について詳しく説明します。これは、簡単で正式な要求プロセスを実装する 1 つの方法にすぎません。

  • 特定のビジネス グループまたはアプリケーションの開発/テスト/運用環境。
    ステージングされた環境を用意することで、開発中の変更によって運用環境でユーザーを中断させたり、データを破損したりすることがなくなります。 リソースが限られている場合は、ミッション クリティカルで重要なアプリ、または独自の専用スペースを最も必要とする部署にこのパターンを集中させます。

  • 概念実証およびトレーニング ワークショップのための個人使用環境。
    ワークショップ、ハッカソン、社内トレーニングイベントを主催する App in a Day や Flow in a Day のように、イベント用に新しい個別の環境を作成して、全員を組織します。 イベント後、短期的に必要なリソースを保存して環境をクリーンアップするか、他のイベント用にリセットするようにユーザーに依頼します。 これらの種類の活動のキャパシティを消費しない試用版環境を使用してください。

  • テナントおよび環境レベルのデータ損失防止 (DLP) ポリシーを確立する
    データ損失防止 (DLP) ポリシーは、ユーザーが誤って組織データを露出してしまうことを防ぎ、テナントの情報セキュリティを保護するためのガードレールとして機能します。 Power Platform 管理者ロールの重要な要素は、テナントおよび環境レベルの DLP ポリシーを確立および維持することです。

ユーザーおよびチームの生産性環境への階層的アプローチ

統合をサポートし、必要な環境の数を減らし、オンボーディングを加速するために、個人およびチームが使用できるいくつかの共有環境を作成することをお勧めします。

既定の環境

テナントの全員に、ここでアプリとフローを作成するためのアクセス許可があります。 現在、この環境で環境作成者ロールの割り当てをブロックする方法はありません。 これは、SharePoint リストからアプリを作成するなど、ファーストパーティの統合に使用される環境でもあります。 詳細: 既定の環境を参照

データへのリスクを軽減するために、アプリとフローで使用されるコネクタの種類は、許容度の低いデータ損失防止 (DLP) ポリシーに制限する必要があります。 このポリシーは、SharePoint データ、電子メールの送信、および承認ワークフローの作成など、一般的な個人および小規模チームの生産性のユース ケースを説明しています。

パワー ユーザー環境

既定の環境は多くのユース ケースに対応しますが、一部のパワー ユーザーにはアプリやフローに関してより高度なニーズがあります (Microsoft Teams、Microsoft Entra、または Azure DevOps との統合など)。

このため、パワー ユーザー環境を作成することをお勧めします。 この共有環境では、より寛容な DLP ポリシーを使用する必要があり、管理者はこの環境のメーカー リストを制御する必要があります。

パワー ユーザー環境に関するいくつかの考慮事項:

  • この環境で使用可能なコネクタを調べて、ユーザーに適したものであることを確認します。
  • たとえば、SharePoint サイトまたは Wiki など、この環境の目的と、ここで使用できるコネクタを明確に文書化します。
  • たとえば、Microsoft Forms、SharePoint サイト、またはアプリを使用して、作成者がパワー ユーザー環境へのアクセスを要求するための自動化されたプロセスを作成します。 必要に応じて、このプロセスには、ライン マネージャーまたは IT による承認が含まれる場合があります。

カスタム環境

共有環境はアプリケーションの多くのユース ケースを網羅しますが、チームとプロジェクトは、部署固有のユース ケースまたはアプリケーション ライフサイクル管理シナリオをサポートするカスタム環境を持つことが、役に立つ場合があります。

カスタム環境に関するいくつかの考慮事項:

  • プロジェクト チームまたは部署と協力して、専用開発、テスト、および運用環境が必要かどうか、または専用の開発環境と共有テストおよび運用環境がそれらのユース ケースにより適しているかどうかを確認します。
  • クリティカルなプロジェクトとワークロードの専用環境について考慮します。 開発者は、開発環境では環境作成者にアクセスできますが、テスト環境と運用環境ではユーザー アクセスのみが可能です。 エンド ユーザーは運用ソリューションにのみエンド ユーザー アクセスできるため、運用アプリケーションを変更することはできません。
  • 重要であるが中程度に複雑なアプリ間での共有テスト環境および運用環境を考慮します。 個々のプロジェクトと部署には、データを保護するための独自の開発環境がありますが、ソリューションは共有のテスト環境と運用環境に展開されます。 開発者はテスト環境のエンド ユーザーであり、エンド ユーザーは運用環境のソリューションとデータへの基本的なユーザー アクセスしかできません。
  • 部署と協力して、必要なコネクタを確立し、例外ポリシーを作成します。
  • 部署と協力して、この環境で誰が作成者になり、誰が環境管理者になるかを設定します。
  • 各環境は 1 GBのデータ容量を消費するため、カスタム環境を慎重に管理してください。

上記の推奨事項に加えて、環境戦略を確立することにより DLP 戦略を形成および指揮することもできます。

  • すべてのユーザーが作成者です。 既定 はクリティカルなアプリの開発用ではないことをすべてのユーザーに知らせます。
  • 1 人のユーザーだけがアクセスできます。 開発者環境は、コミュニティ プランにサブスクライブしたユーザーを除く他のユーザーに対して完全にロックされています。 必要に応じて、アプリケーションを環境外に移動できます。
  • 承認されたユーザーがアクセスできます。 承認された作成者リストを備えた、ユーザーおよびチーム生産性シナリオ向けの共有環境。
  • クリティカルなプロジェクトとワークロードの専用環境。 開発者は、開発環境では環境作成者にアクセスできますが、テスト環境と運用環境ではユーザー アクセスのみが可能です。 エンド ユーザーは運用ソリューションにのみエンド ユーザー アクセスできるため、運用アプリケーションを変更することはできません。
  • 重要であるが中程度に複雑なアプリ向けの共有テスト環境および運用環境。 個々のプロジェクトと部署には、データを保護するための独自の開発環境がありますが、ソリューションは共有のテスト環境と運用環境に展開されます。 開発者はテスト環境のエンド ユーザーであり、エンド ユーザーは運用環境のソリューションとデータへの基本的なユーザー アクセスしかできません。

環境を管理するための追加の推奨事項

顧客エンゲージメントの成功経験に基づいて、環境の管理を容易にするのに役立つ追加の推奨事項リストを以下に示します。

  • サービス アカウントを使用して運用ソリューションを展開する: 中央 IT がテストおよび運用環境への展開を管理するサービス アカウントを作成します。 これは、多くの点で役立ちます。

    • IT のすべてのメンバーが管理リソース (テスト環境や運用環境など) を管理できるようにします。
    • 環境内で管理者のアクセス許可を持っているのはサービス アカウントのみです。
    • 他のすべてのユーザーはエンドユーザー権限を持っており、新しいリソースを作成することはできません。これは、ユーザーにデータ接続へのアクセス権が与えられると、開発者が意図していないデータとの対話のための新しいインターフェースを作成できてしまうため、重要です。
    • IT は実装に関与しているため、展開中の運用グレードのアプリケーションを認識しています。
    • サービス アカウントは、Microsoft Power Platform または PIM の Dynamics 365 サービス管理者のアクセス許可が必要です。 要求プロセスで使用する必要のあるコネクタに応じて、追加のライセンスを割り当てます (たとえば、Dataverse および Outlook を使用する場合、プレミアム Power Apps および OfficeEnterprise を割り当てます)。
    • アプリケーションの詳細を表示すると、作成者ではなく作成者としてサービス アカウントが表示されます。 これは、アプリケーションの問題が発生した場合に、エンドユーザーが連絡先を知るのに役立ちます。

    サービス アカウントを持つことのリスクがあなたにとって重要であるかどうかを検討してください。 一部の組織は、たとえば、管理者特権を持つ共有リソースを 1 人のユーザーに追跡できないため、サービス アカウントの所有に不安を感じています。 これは有効ですが、場所に基づく条件付きアクセスの実施、IP への監査ログの追跡、または使用中にユーザー ID を要求する安全なアクセス ワークステーションの維持や、そのデバイスへのサービス アカウント アクセスの制限などのより広範な方法で、不安を軽減できます。

  • 共有開発環境の数の削減

    特にデータの保護を扱う場合は、個別のプロジェクト開発のために個別の環境を用意してください。 環境は、データへの接続などのリソースのコンテナーであり、開発環境では、環境作成者がアクセスできる複数のユーザーがいる可能性があります。 作成者が共有データ接続にアクセスでき、アプリやフローを作成できる場合、誰かがアクセスを許可されたデータを読み込み、更新、削除するための新しいインターフェイスを作成するリスクがあります。 これは、既定の環境では留意しておくことが特に重要です。重要なデータ接続、カスタム コネクタ、およびそれらを保護するために隔離された環境でセキュリティを必要とするその他の資産を常に用意する必要があります。

  • Microsoft Entra セキュリティ グループとリソースを共有する

    セキュリティ グループを使用して、Power Apps、フロー、Dataverse セキュリティ ロール、および SharePoint Online などその他の Office 365 サービスへのアクセスを管理します。 これにより、各コンポーネントの個々のエンド ユーザーへのアクセスを更新する管理者の負担がなくなります (特に複数関係している場合)。アプリの所有者は、IT なしでセキュリティ グループ レベルで変更できます (IT がセキュリティ グループ管理へのアクセスを制限する場合を除く)。

  • 環境作成の自動化

    管理コネクタ (Microsoft Power Platform for Admins) を使用すると、IT が環境の作成を管理者に制限している場合に、ユーザーが環境を要求する承認フローを作成できます。 中央 IT は、要求を確認し、環境の作成を承認または拒否することができます。要求の詳細、業務上の正当な理由、DLP の要件、および十分な容量があるか否かを検証するだけのために、管理センターに手動でアクセスしてユーザー環境を作成する必要はありません。

  • 一時的な開発環境を作成する

    前述のように、開発環境を可能な限り分離し、特に既定環境でクリティカルなソリューションを同時にアプリ開発しないようお勧めします。 環境が開発目的で作成されている場合は、開発者が環境を利用できる期間に期限を設定し、それらをバックアップおよび削除するためのプロセスを用意します。

  • シンプルが一番

    環境を使用してプロジェクトと部署間でリソースが合理的に分割されていることを確認することは重要ですが、セキュリティと実現可能性の間の適切なバランスを見つけることも、依然として重要です。 共有のテスト環境と運用環境を管理することは、容量を維持し、ベスト プラクティスに従いながら、多くの重要なソリューションを提供する優れた方法です。 テスト環境と運用環境へのアクセス許可が制限されているため、エンド ユーザーはアプリケーションを変更できません。

  • 適切な地域の Dataverse インスタンスで環境をプロビジョニングする

    従業員が複数の国/地域で働いている企業では、データが保存され、国/地域間で送信される場所に関して、法令遵守に関する考慮事項があるかもしれません。 環境に Dataverse インスタンスがある場合、データは物理的にその地域に保存されています。 サポートされる環境地域の一覧を確認します。

プロビジョニングに影響する要因

いくつかの要因は、どの種類の環境をいつプロビジョニングするかに影響します。

  • アプリケーション サポートの定義された階層

    複雑さのレベル、アプリの重要度、およびアプリケーションの影響を受けるユーザー (たとえば、組織内の月単位のアクティブ ユーザー/合計ユーザー) はすべて、すべてのシナリオをサポートする環境をプロビジョニングする方法の重要な指標です。

    さまざまな種類のアプリケーションは、それぞれの重要度に基づいて、異なる環境で分離する必要があります。

       
    クリティカルなアプリ。 ミッション クリティカルなシナリオ、および/または高度な複雑さ、および/または組織全体での使用。 IT が所有するサポート。 堅牢な ALM プロセス (開発/テスト/製品)。 より長い開発サイクル、多くの場合、実用最小限製品になるまで 3 か月以上。
    重要なアプリ。 重要であるがクリティカルではない、および/または中程度の複雑さ、および/または部署を対象としています。 アプリの所有者または部署が所有し、IT に恵まれたサポート。 ALM を使用する環境をお勧めしますが、必須でない場合があります。 最小実行可能製品までの開発は通常 3 か月未満です。
    生産性アプリ。 高レベルのガバナンスを必要としない生産性アプリ。 アプリ開発者によるサポート。 通常、アプリケーション ライフサイクル管理は必要ありません。 最小実行可能製品まで 2 週間未満です。
  • 容量

    各環境 (試用版環境と開発者環境を除く) は、最初のプロビジョニングに 1 GB を消費します。 組織がプレミアム Power Apps または Dynamics 365 ライセンスを支払わない場合、これはプロビジョニング環境の制約になる可能性があります。また、テナント全体で共有される容量を、必要とするユーザーに割り当てる必要もあります。

    次の方法で容量を節約します。

    • 共有環境と運用環境を管理します。 共有開発環境とは異なり、テスト環境と運用環境でのアクセス許可は、テスト用のエンド ユーザー アクセスに制限する必要があります。
    • 一時的な開発環境のクリーンアップを自動化し、テストまたは概念実証作業のための試用環境を使用することをお勧めします。
  • 管理者の関与

    特に IT チームが小規模である場合、または管理する企業が大規模である場合は、テナント全体で発生するすべての開発プロジェクトに、常に中央 IT を関与させることができるとは限りません。

    次の方法で管理者の負担を軽減します。

    • テナント管理者が要求を承認するだけで済むように、環境の作成を自動化します。
    • 一時的な環境を使用した開発環境のクリーンアップの自動化。

組織の環境戦略を作成者に明確に伝える

SharePoint サイトまたは Wiki を設定し、次の点を明確に伝えます。

  • 既定環境の目的。
  • 作成者がアクセスできる他の共有環境 (たとえば、トレーニング環境) に加えて、共有チームおよびユーザー生産性環境の目的、およびそれらの環境へのアクセス要求方法のプロセス。
  • 試用版環境の目的とそのリクエスト方法。
  • 開発環境の目的とその作成方法
  • 特定の部署またはプロジェクトの目的でカスタム環境を要求するプロセス。
  • 作成者の責任:
    • テナントをクリーンな状態に維持します。 環境、アプリ、フローが不要になった場合は削除します。 実験する場合は、テスト環境を使用してください。
    • 賢く共有します。 環境、アプリ、フロー、共有接続の過剰共有に注意してください。
    • 組織のデータを保護します。 極秘または機密のデータソースから、保護されていないストレージまたは外部ストレージにデータを移動することは避けてください。

また、組織の DLP ポリシーを作成者に明確に伝えます。