フィードバック

第 8 章: アプリの保護と展開

  • [アーティクル]

アプリは機能的に完成しましたが、Preeti と Kiana は、ソリューションが安全に展開され、将来的に要件の変化に応じてソリューションを維持するためのメカニズムを備えることを望んでいます。

アプリとリソースの保護

最初に Power Apps にサインしたとき、通常はメール アドレスとパスワードを入力して、自分自身を認証する必要があります。 Office 365 では独自の Azure Active Directory (Azure AD) ドメインを使用します; 各組織には独自のドメインがあります。 ユーザーの資格情報は Office 365 の組織のドメインに対してチェックされます。 Power Apps を使用して構築されたアプリは、適切な権限が付与された Office 365 リソースにのみアクセスできます。 承認は Office 365 管理者 (VanArsdel シナリオの Preeti) によって管理されます。 詳細については、Power Apps プロジェクト ガイドの計画のアプリとデータの保護を参照してください。

アプリがアクセスする Azure リソースも承認の対象となります。 Azure Storage などのサービスでは、アクセス キーを提供するアプリケーションが必要です。 さらに、多くのサービスは、個々のユーザーおよびグループが実行できる操作を説明する、ロールベースのアクセス制御によって保護できます。 IT 運用マネージャー (再度 Preeti) は、Azure SQL データベース、Azure Blob Storage、Azure API Management、Azure App Services などのサービスに接続できるアカウントとマシンを定義する承認ポリシーを設定できます。 一部のサービスでは、認証されたユーザーがアクセスを要求できるエンドポイントを制限することもできます。 たとえば、Azure SQL データベースのファイアウォールを構成して、予期しない IP アドレスから発信された要求へのアクセスを拒否できます。

Azure は、トランスポート層セキュリティを使用してデータを暗号化することにより、転送中のデータを保護するのに役立ちます。 この機能は、パブリック インターネットなどのネットワークを介してデータを送信する分散システムの整合性とプライバシーを確保するために不可欠です。 VanArsdel の場合、技術者は、組織の制御外にあるローミング ネットワーク接続を使用して、モバイル デバイスでアプリを実行します。 Preeti は、未承認ユーザーが機密データを表示したり侵害したりできないようにすることに取り組んでいます。

保管データ—Azure のストレージ アカウント、データベース、およびその他のサービス—を暗号化することもできます。 これにより、この情報を格納しているデータセンターが侵害された場合に、プライバシーの追加レイヤーが提供されます。 Azure が提供するセキュリティ機能の完全な一覧については、Azure セキュリティの概要を参照してください。

アプリのパーソナライズ

誰かがアプリを実行すると、Office 365 環境からユーザーに関する情報を取得できます。 この情報を使用して、アプリをパーソナライズできます。 たとえば、現在 Maria と Kiana が開発したアプリでは、異なるユーザー間に区別はありません。皆が同じデータにアクセスできます。 理想的には、アプリを使用するエンジニアに最も関連性のある情報を表示するよう、アプリをパーソナライズする必要があります。 Power Apps は、アプリが現在のユーザーのメール アドレスとフルネームを取得できるようにする User という名前の関数を提供します。 このアプリには、ユーザー ID (各ユーザーに割り当てられたグローバル一意識別子、または GUID) も必要です。 この要件の根拠は、ユーザー名は変更できますが、ID は変更できないということです。 Office365 コネクタによって提供される機能を使用してユーザー ID にアクセスできます。 次の手順は、このコネクタをアプリに追加する方法を示します:

  1. Power Apps Studio を使用して、ツリー ビュー ウィンドウで、ホーム 画面を選択します。

  2. 挿入 メニューで、テキスト ドロップダウン リストから、ラベル コントロールを画面に追加します。

  3. ラベル コントロールの名前を UserName に変更します。

  4. コントロールを移動して、次の予定を示す詳細の下に表示されるようにします。

    ホーム画面のレイアウトを変更する。

  5. データ ウィンドウで、データの追加 を選択します。 検索フィールドに、Office 365 ユーザー と入力します。 Office 365 ユーザー 接続をアプリに追加します。

    Office 365 ユーザー コネクタを追加する。

  6. ツリー ビュー ウィンドウで、UserName ラベルを選択して、テキスト プロパティを次の式に設定します。

    Office365Users.MyProfileV2().displayName

    この式は Office365Users 接続を使用して、現在のユーザーに関する ID 情報を取得します。 MyProfileV2 機能の displayName プロパティには、ユーザーのサインオン名が含まれます。

    ユーザー名が表示されたホーム画面。

注意

UserName コントロールを自由にスタイル設定して、より目立たせるようにしてください。

Office 365 は Azure AD ドメインで実行されますが、独自の Azure AD インストールを使用してこのセキュリティ ドメインを拡張することもできます。 組織が独自の Azure AD ドメインでユーザーを認証する場合は、Office365Users の代わりに Azure AD コネクタを使用してユーザー情報を取得できます。

Azure AD コネクタを追加する。

この場合、UserName ラベルの テキスト プロパティを次のものに設定します。

AzureAD.GetUser(User().Email).displayName

予定一覧をパーソナライズするには、FieldEngineerAPI コネクタで異なる Web API 関数を呼び出す必要があります。 現在、ホーム 画面の OnVisible プロパティには次の式が含まれます。

ClearCollect(appointmentsCollection, Sort(Filter(FieldEngineerAPI.getapiappointments(), DateDiff(Today(), startDateTime) >= 0), startDateTime));

Web API は、指定された技術者の予定を取得する代替機能を提供します。ユーザーはパラメーターとして技術者の ID を指定します。 この目的で Office 365 ユーザー ID を使用できます。 OnVisible プロパティを次のように更新します。

Set(id, Office365Users.MyProfileV2().id);

ClearCollect(appointmentsCollection, Sort(Filter(FieldEngineerAPI.getapischeduleengineeridappointments(id), DateDiff(Today(), startDateTime) >= 0), startDateTime);

Azure AD を使用して認証している場合、代わりに次の式を使用してください。

Set(id, AzureAD.GetUser(User().Email).id);

ClearCollect(appointmentsCollection, Filter(FieldEngineerAPI.getapischeduleengineeridappointments(id), DateDiff(Today(), startDateTime) >= 0), startDateTime);

注意

この変更では、予定 テーブルの EngineerId 列にユーザーの ID を入力する必要があります。 この ID は GUID ですが、データベースに文字列として保存されます。 次の図は、サンプル データの数行を示します。

ID を GUID として使用したサンプル エンジニア データ。

エンジニア テーブルには、対応する ID を持つエンジニアの名前も含まれる必要があります。

データベースのエンジニア テーブル。

これで、アプリを展開してリリースする準備が整いました。

アプリの展開

アプリを展開する最も簡単な方法は、アプリを Office 365 ドメインに公開することです。 使用可能 権限を持つすべてのユーザーは、Power Apps Studio から、または https://aka.ms/AAbvtko の Microsoft Store で入手可能な Power Apps Mobile アプリを使用して、アプリを実行できます。 Power Apps で作成されたアプリは、タブレットや電話などのモバイル デバイスで公開されるとすぐに実行できます。ユーザーは、デバイスのアプリ ストアでアプリを検索するだけで済みます。

アプリを公開するには、次の手順を実行します:

  1. Power Apps Studio の、ファイル メニューで、保存 を選択します。 変更を加えた場合は、アプリを保存します。 アプリを保存すると、公開 ボタンが表示されます。

  2. 公開 を選択します。 公開 ダイアログで、詳細の編集 オプションを使用すると、アプリの名前、アプリのアイコン、説明などの設定を選択できます。 アプリが使用する画面サイズと向きを変更することもできます。 このバージョンの公開 を選択して、組織内の他の Power Apps ユーザーがアプリを使用できるようにします。

    アプリを公開します。

Power Apps Studio の 管理者 ページの アプリ タブ https://make.powerapps.com から、展開履歴とアプリの使用状況を追跡できます。 アプリを選択してから、省略記号メニューで、詳細 を選択します。

アプリの詳細ウィンドウを選択する。

詳細 ウィンドウの、バージョン タブには、アプリのバージョン履歴が表示されます。 アプリの省略記号メニューのオプションを使用すると、最新発行をロールバックする必要がある場合に、以前のバージョンを復元できます。

アプリの以前のバージョンを復元する。

アプリの管理

Power Platform 管理センターでは、アプリが存在する環境を管理できます。 推奨されるアプローチは、Microsoft Dataverse 環境を通じてアプリを作成して公開することです。 開発と実稼動用に個別の環境を使用します。

Dataverse では 4 種類の環境を提供します:

  • サンドボックス: 開発に適しています。

  • 実稼動: 使用するためにアプリを展開する場所。

  • 開発者: ここで作成した資産は共有できません。 単一ユーザー環境として、Power Apps で作成されたアプリの機能を学習および探索するために使用できます。

  • 既定: テナントごとに自動作成される環境。 テナント内の全員がこれらのアプリにアクセスできるため、Microsoft ではこれをアプリに使用しないことをお勧めします。

Power Platform 管理センターを使用して環境を作成します。 環境 タブで、メニュー バーの 新規 オプションを選択します。 環境の種類を指定します。

新しい Power Apps 環境を作成する。

アプリケーション ライフサイクル管理 (ALM) への優れたアプローチは、新しいサンドボックス環境で開始することです。これにより、実稼働環境から分離してアプリを安全に開発およびテストできます。 開発中のアプリを共有してテストします。 アプリを実際に使用する準備ができたら、アプリを実稼働環境に展開し、そこから公開します。 Microsoft Power Platform ビルド ツールを使用して、このプロセスの多くを自動化できます。

VanArsdel に適用される Power Apps を使用した ALM の詳細については、Microsoft Power Platform ALM ガイドのシナリオ 1: 市民開発を参照してください。

前へ 次へ