2024.10.26_Power_Platform_Administrator勉強会#2

Slide 1

Slide 1 text

Power Platform Administrator 勉強会#2 お⽚付けの「ベスプラ」について考える。 2024.10.26 コバッチ (kobatch) 他力code

Slide 2

Slide 2 text

● Power Platformを使ったプロダクトPdMとテナント管理者 ● ⾼専客員講師、ソーシャルセクターのデジタル化⽀援 ● ITストラテジストであり、Node.js系エンジニアでもある ● またの名「感謝と賞賛⼤量製造請負⼈」（ThanksCard活動主宰） ● 病的キレイ好き、ストレス解消は掃除機がけ（KPI：ホコリゼロ）⾃⼰紹介 Japan Power Platform CONFERENCE メインイベント登壇（2023.12） Power Platform技術コミュニティでの事例紹介や記事投稿（2023.12〜）コバッチ（kobatch）∕他⼒code tariki-code kobatch_tk tariki-code

Slide 3

Slide 3 text

技術者にとってキレイに「お⽚付けができること」こそ、最も難易度が⾼く、ニーズの⾼いスキルである。ー詠み⼈知らず

Slide 4

Slide 4 text

今⽇話すこと Power Platform環境における管理者としての「お⽚付け」について考えてみました。 Agenda 1. お⽚付けの「必要性」について。 2. 管理者をやってみて「わかったこと」。 3. 今考える⾃分なりの「ベスプラ」。 ※ベスプラ＝「Best Practice」

Slide 5

Slide 5 text

前提情報本資料での⾔及内容は⼀般的なシナリオに基づいたものとなります。会社（組織）でPower Platform市⺠開発環境を提供。 ● 会社の主要環境とは別テナント。 ● テナント内に複数環境が存在（既定＋検証⽤＋本番⽤など）。 ● ユーザーアカウントも会社とは別管理、退職や異動に伴うメンテが必要。主な使⽤製品

Slide 6

Slide 6 text

「お⽚付け」の必要性について。

Slide 7

Slide 7 text

こんなことありませんか？アプリを「作った」、たくさんの⼈が「使った」はいいけど後が⼤変。 ● アプリが⼤量⽣産されてるが、何がどう使われているのかわからないのでそのまま放置。 ● 退職‧異動したユーザーや、昔のアカウントが残ったままになっている。 ● ⼤量のセキュリティロールやチーム、あちこちに存在するルールなき個別設定に四苦⼋苦...。

Slide 8

Slide 8 text

例えば（アプリ）いわゆる「寿命」が来たにも関わらず放置されている。開発運⽤アプリの寿命アプリB アプリA アプリC （削除）アプリD アプリE アプリの「お⽚付け」 ※寿命＝使⽤終了あるいは実質使われていない。

Slide 9

Slide 9 text

例えば（ユーザー）退職や異動に伴う変更の「放置」「失念」。アカウント払出し権限付与退職や異動発⽣アカウント削除環境へのせキュリティグループアプリAセキュリティロール（更新）アプリBセキュリティロール（閲覧）環境へのせキュリティグループアプリAセキュリティロール（更新）ユーザーや権限の「お⽚付け」

Slide 10

Slide 10 text

例えば（ロールの割り当て）アプリセキュリティロールチームチームチームチームアプリ仕様セキュリティロール運⽤管理抜け漏れのない「お⽚付け」「チーム単位」で離脱させたはずなのに‧‧‧ ルール逸脱による「抜け⽳」。たまたま個別に権限を割り当ててしまった⼈

Slide 11

Slide 11 text

放置により潜むリスクテナントと利⽤者の規模が拡⼤するに伴いリスクも拡⼤。セキュリティ ● 管理の⾒落としによる抜け⽳の懸念。 ● 設定漏れによる不正なアクセスや情報漏洩。管理コスト ● 余計や確認や調査に対する⼯数増。 ● イレギュラーに対する⼿動対応。テナント有効利⽤ ● 肥⼤化による容量逼迫やパフォーマンスへの懸念。 ● そもそも有⽤に使うものにリソース集中したい。 Searched By Perplexity

Slide 12

Slide 12 text

Microsoftはもちろん対応しているが... プラットフォーマー依存ではよくない。 ERMフレームワーク Microsoft Learn Power Platformは優秀 ● ⼀定期間使⽤のないアプリはリコメンドに表⽰されたり、クラウドフローも⾃動オフされる。 ● プラットフォーム全体に定期的にセキュリティパッチも当たっている。⼀⽅で ● ローカルルールやヒューマンエラーに対してはプラットフォーマーでもどうすることもできない。セキュリティ事故に占める⼈為的ミスの割合は74%に上るという記事も... Searched By Perplexity

Slide 13

Slide 13 text

実は「お⽚付け」は「作る」よりも難しい？そもそもノウハウがインターネット上に少ない。開発運⽤アプリの寿命お⽚付け https://learn.microsoft.com/ja-jp/power-platform/alm/overview-alm ノウハウと情報が少ない ALMはなんとなくこの辺をくるくる？‧‧‧ そしてものすごく重要なことみんな「作る」のは好きだし得意だが、「お⽚付け」は嫌いだし苦⼿。

Slide 14

Slide 14 text

そんな「お⽚付け」についてマジメに考えてみる。このセクションまとめ ● アプリの「寿命」、ユーザーの「離脱」が始まってからがスタート。 ● 「お⽚付け」をしないとセキュリティや管理⼯数、リソース有効活⽤の観点でリスクあり、テナント規模拡⼤につれより増す。 ● ローカルルール、ヒューマンエラーの観点からプラットフォームの仕組みのみに頼らず、⾃衛の意識を持つことが重要。 ● 具体的な情報やノウハウがそもそも少ない。

Slide 15

Slide 15 text

管理者をやってみて「わかったこと」。

Slide 16

Slide 16 text

３つのポイント PPAC（管理センター）およびEntra、Azureの活⽤。アプリとソリューション ● アプリへのアクセス状況（PerApp）。 ● ソリューションの削除。ユーザー ● ユーザーの種類。 ● PowerPlatform環境からの削除。 ● Entra監査履歴のLogAnalytics連携。セキュリティロール ● ユーザーからの逆引き。 ※内容は主に独⾃調査（⼀部公式サポート確認含む）となります。訂正、補⾜等、フィードバックいただければ幸いです。

Slide 17

Slide 17 text

アプリとソリューション環境 > (環境名) > PowerApps アプリ所有者名環境名

Slide 18

Slide 18 text

アプリへのアクセス状況請求 > ライセンス > 環境にて確認。アプリごとのPerApps ● アプリ使⽤あたりのライセンス。 ● Premiumを持たないユーザーが対象。 ● 環境とアプリ数とアクセス数で積算。 Power Apps Premium ● ユーザーライセンス。 ● 全てのアプリにアクセスが可能。 ● 厳密には使⽤アプリの識別は不可...？環境名数字数字

Slide 19

Slide 19 text

アプリごとのPerAppsのカウント条件アプリID ＝アプリを識別する内部番号例) 90226cf6-a5f1-e a21-a845-000d3 a52d87a 数字例） 10 アクセスしたアプリ数、環境、ユーザーの積算となる。 ※サポートへの確認 ● Premiumを持たないユーザーがアプリにアクセスすれば「アクティブユーザー」 1 カウント、30⽇間未アクセスであれば 1 カウント解除。 ● 強制的にアクセス解除したい場合は権限を外す（ただし、カウントは30⽇間の経過を待つことが必要）。数字例） 10

Slide 20

Slide 20 text

ソリューションの削除アプリ（セキュリティロール）はソリューション単位で削除。 ● ソリューションを構成するオブジェクト（テーブル‧クラウドフローなど）に依存関係がなければ、マネージドソリューションでも削除可能。 ● アンマネージドソリューションであればエクスポートしてzipファイルとして保存しておくことも可能。ソリューション名称ソリューション名称ソリューション名称ソリューション名称ソリューション名称ソリューション名称ソリューション名称ソリューション名称ソリューション名称

Slide 21

Slide 21 text

ユーザー環境 > (環境名) > 設定 > ユーザーユーザー表⽰名ユーザーID 環境名

Slide 22

Slide 22 text

Power Platformのユーザー管理と種類環境単位に作成される。M365側設定と⾮同期で連携される。有効なユーザー ● アカウントがアクティブ、かつ環境およびアプリに適切な権限が割り当たっている状態のユーザー。無効なユーザー ● ライセンス適⽤がないユーザー、もしくはセキュリティグループから削除され、環境へのアクセス権がないユーザー。

Slide 23

Slide 23 text

Power Platform側のユーザー削除環境 > （指定の環境）> 設定 > 機能にて、環境単位で設定が可能。

Slide 24

Slide 24 text

Power Platform側のユーザー削除⼀括処理による削除。 ● 環境設定完了後、上部に「⼀括削除」メニューが追加。 ● ポップアップ表⽰され、条件やスケジュール設定が可能。 ※⼀度やってみたが、想定通りに削除されなかった（原因は未調査だが、おそらくレコードの割り当てが必要等の理由による）。

Slide 25

Slide 25 text

Entra監査履歴のLogAnalytics連携管理画⾯より「診断設定」にて設定（※別途Azureサブスク課⾦が必要）。環境名 M365ユーザーアクティビティの各種監査履歴をログデータにしてDB管理することが可能。例えば下記のログを連携。 ● AuditLogs（監査ログ） ● SignInLogs（サインインログ） ● RiskeyUsers（危険なユーザー） ● UserRiskEvents（ユーザーリスクイベント）

Slide 26

Slide 26 text

KQLを活⽤した条件に基づく検索、および通知機能の実装が可能。 Azure側出⼒イメージ

Slide 27

Slide 27 text

セキュリティロール環境 > (環境名) > 設定 > セキュリティロールユーザー表⽰名部署名環境名

Slide 28

Slide 28 text

ソリューションから削除するのがベター。セキュリティロールの削除セキュリティロール名ソリューション名セキュリティロール名管理センターからの直接削除もメニューとしては存在（ただし、依存関係などの関係から難しいのではないか）。セキュリティロール名セキュリティロール名セキュリティロール名セキュリティロール名部署名

Slide 29

Slide 29 text

ユーザーやチームからの逆引き確認が可能。セキュリティロールの割当状況確認環境 > （環境名）> 設定 > ユーザーより ● 任意のユーザーを右クリック。 ● セキュリティロールの管理を選択。こちらにより、選択ユーザーが所属しているセキュリティロールを確認することができる（チームでも同じ確認が可能）。ユーザー名ユーザー名部署名セキュリティロール名セキュリティロール名セキュリティロール名セキュリティロール名セキュリティロール名セキュリティロール名セキュリティロール名セキュリティロール名セキュリティロール名セキュリティロール名セキュリティロール名セキュリティロール名

Slide 30

Slide 30 text

（参考）CoEスターターキットアプリの利⽤状況やアクセス権の割り当て状況など統合的に管理可能なツール。そもそもあまり使い⽅や⾒⽅やできることがわかっていないので割愛。 ● PowerApps Apps ● Power Apps Portals ● Flows ● Environments ● Audit Logs などの情報が確認できる。 ※有識者の皆様是⾮教えてください。アプリ名

Slide 31

Slide 31 text

これらを踏まえたお⽚付けの「ベスプラ」とは？このセクションまとめアプリ ● アプリ単位のアクセス（アクティブ）について確認することができる。 ● マネージドソリューションでも削除は可能。 ● アンマネージドソリューションはエクスポートしておくことも可能。ユーザー ● 無効ユーザーはPower Platformの該当環境に対するアクセス権限はない。 ● ⼀括で削除することもできるが、レコードの再割り当てなどの対応が必要。 ● Entraの監査履歴はLogAnalytics連携できるので、検知や通知の仕組みの実装が可能。セキュリティロール ● ソリューション単位で削除していくのがベター。 ● ユーザーやチームから割り当て状況を確認することができる（いわゆる逆引き）。

Slide 32

Slide 32 text

今考える⾃分なりの「ベスプラ」。

Slide 33

Slide 33 text

「完璧」は不可能と⼼得る、状況に応じて「柔軟に対応」できる余地を作る。ポイントの整理やっておくべきこと ● ❶⼀定のルール化と運⽤。 ● ❷リスクやルール逸脱を検知できる仕組み（受動＞能動）。 ● ❸「お⽚付け」処理の⾃動化。やらなくていいこと ● ライフサイクル全体の「⾃動化」や「フロー化」。 ● 管理をするための「アプリ開発」。活⽤

Slide 34

Slide 34 text

個⼈的に机上含む調査の範囲であり、全てを検証済ではありません。まず結論アプリ ● 使わなくなったものはアーカイブ＋環境からはソリューション単位で削除。 ‧‧‧❶ ● 負債が⾼いもの（依存関係が⼊り組んでいる）は残存管理。 ‧‧‧❶ ユーザー ● ⼊り⼝となるEntraできちんとシャットアウト。 ‧‧‧❶❸ ● および監査履歴の検知⾃動化などで最初の関⾨の管理を強化する。 ‧‧‧❷ セキュリティロール ● 原則は全てチーム単位で割り当てを⾏う（運⽤でカバー）。 ‧‧‧❶ ● 各アプリのセキュリティロール割り当て状況の横断チェック。 ‧‧‧❷❸

Slide 35

Slide 35 text

アプリ（おさらい）「寿命」が来たにも関わらず放置されている。開発運⽤アプリの寿命アプリB アプリA アプリC （削除）アプリD アプリE RISK アプリの「お⽚付け」

Slide 36

Slide 36 text

寿命が来たらソリューション単位で削除、ただし依存関係が複雑なものは無理しない。アプリ（ベスプラ案）開発運⽤アプリの寿命お⽚付け ❷PerApps使⽤状況の監視＋CoEスターターキットでの監視（あるいは定期的な棚卸） ❶ソリューションエクスポートによるアーカイブ化（アンマネージド） ❶テナントからソリューションの削除 ※依存関係が複雑で削除困難なものは無理しない（セキュリティロールから全ユーザーを剥奪）環境名数字 ❶命名ルールの定義

Slide 37

Slide 37 text

⾃動化の領域に踏み込むにはなかなか難しい。アプリ（補⾜）難しい‧⼯夫が必要な点 ● 命名ルールはソリューション単位の区分けを分かりやすくする意味で重要。 ● 使⽤中の判断は管理者側の情報だけでは難しい、別途管理‧棚卸が重要。 ● 削除やエクスポートは基本的に⼿動対応になる。他に考えられること ● アプリのDataverseテーブルのエクスポート（PowerShellにて可能）。 ○ https://learn.microsoft.com/ja-jp/power-platform/developer/cli/reference/data

Slide 38

Slide 38 text

⾃動バックアップしておくことで、アプリ寿命時に躊躇なく削除できる。ちょっと考えていること（Pipelineでの拡張操作）アンマネージド環境マネージド環境承認ソリューションの ZIPファイルバックアップ ● Pipelinesでリリース承認きっかけからのクラウドフロー起動。 ● ソリューションZIPファイルの別媒体保存。 PowerPlatform Pipelines Power Platformでパイプラインを拡張する https://learn.microsoft.com/ja-jp/power-platform/alm/extend-pipelines

Slide 39

Slide 39 text

退職や異動に伴う変更の「放置」「失念」。アカウント払出し権限付与退職や異動発⽣アカウント削除環境へのせキュリティグループアプリAセキュリティロール（更新）アプリBセキュリティロール（閲覧）環境へのせキュリティグループアプリAセキュリティロール（更新） RISK ユーザー（おさらい）ユーザーや権限の「お⽚付け」

Slide 40

Slide 40 text

⼊り⼝（Entra ID）をしっかり塞いで、監視ができる仕組みを整える。ユーザー（べスプラ案）アカウント払出し権限付与退職や異動発⽣アカウント削除 ❶確実に環境のセキュリティグループから権限剥奪、あるいは❸物理アカウント削除。 Power Platform側は確実に対象ユーザーが「無効」になっていることを確認すればよく、無理な削除は⾏わない。 ❷Log Analyticsを活⽤した監査履歴の監視や不正なログインなどの検知は常に⾏う。

Slide 41

Slide 41 text

Power Platform側の同期データについては⽬をつぶる。ユーザー（補⾜）難しい‧⼯夫が必要な点 ● Power Platform側のユーザー情報削除は所有者や監査履歴を考えると影響あり。他に考えられること ● ポリシーの厳格化（強制リセットや⼆要素認証、パスキー導⼊など）。 ● アカウント管理体系の⾒直し（ゲストアカウントなどで組織と連動）。 ● テナントへのIP制限の追加。など

Slide 42

Slide 42 text

Power Automateを使って⾃動化。監査履歴の通知例）1時間で5回以上のログイン試⾏を⾏ったユーザーを検出。 Azure上でKQLを使って集計クエリを作成。 AzureMonitorアクションを使ってKQLクエリを実⾏、取得レコードがあった（＝検知した）場合、 Teams等のアクションで通知する。

Slide 43

Slide 43 text

グループのメンバーを取得定期周期で実⾏し、発覚したらTeams通知をする「受動的な検知」を実装。ざっくりフローの流れ定期周期による起動 LogAnalytics検索 Teamsに通知 ● 毎時‧毎⽇などの周期でトリガー。 ● LogAnalytics検索で、監査履歴より指定回数ログインをしたユーザーを検索。 ● Entraにて対象となるユーザー情報の取得。 ● （じゃないユーザーの検知時に）全ユーザーを取得。 ● ⼀定期間未ログインなどのグループ除外、無効化など。 ● 検知をしたユーザー情報やアラームを指定のチャネルなどに通知。

Slide 44

Slide 44 text

相談相⼿、兼‧先⽣＝GPT4o。たとえばこんな検知ができれば LogAnalyticsとPower Automate活⽤で検出できそうなこと。 ● 何度もログイン試⾏を⾏ったユーザーの検出。 ● 期間未ログイン状態のユーザーの検出。 ● ⻑期間パスワード変更を⾏なっていないユーザーの検出。 ● 頻繁にパスワードリセットを⾏なっているユーザーの検出。 ● 不審な場所からのログインの検出。 ● 管理者権限の不正利⽤の検出アクティブなセッション数の監視。 ● 権限エスカレーションの試⾏の検出。 ● 管理者アカウントでのログイン。

Slide 45

Slide 45 text

セキュリティロール（おさらい）アプリセキュリティロールチームチームチームチームアプリ仕様セキュリティロール運⽤管理「チーム単位」で離脱させたはずなのに‧‧‧ ルール逸脱による「抜け⽳」。たまたま個別に権限を割り当ててしまった⼈ RISK 抜け漏れのない「お⽚付け」

Slide 46

Slide 46 text

とにかく「チーム単位」で管理し、ルール逸脱を監視できる仕組みを整える。セキュリティロール（ベスプラ案） ❶基本的に権限付与は「チーム」単位で⾏い、メンバーの追加‧削除はチームに対して⾏う。 ❶「チーム」単位で権限剥奪することで、抜け漏れを防⽌する。 ❷各アプリのロールの割り当て状況を監視する（検証中）。開発運⽤アプリの寿命お⽚付け

Slide 47

Slide 47 text

ルール逸脱しがちなのは実は「管理者」。セキュリティロール（補⾜）難しい‧⼯夫が必要な点 ● ⼿動対応がメインとなる。逆引きなどを駆使して地道なチェックが必要。 ● イレギュラーになりがちなのは実は「管理者側アカウント」、したがって保守⽤や管理者アカウントもチーム配下での管理を⾏うべき。 ● Power Automateでアプリのロール⼀覧の取得ができる？⾃動監視ができてイレギュラーを簡単に検出できるようになると尚良い（調査中）。他に考えられること ‧‧‧（何かあれば教えてください）。

Slide 48

Slide 48 text

PowerApps系のコネクタを使って、ロールの割り当て状況を検知できるか（検証中）。ロールの割り当て⾃動化案定期周期による起動ロールの割り当てを取得 Teamsに通知 ● 毎時‧毎⽇などの周期でトリガー。 ● 対象となる環境からアプリの⼀覧を取得。 ● 「アプリロールの割り当てを管理者として取得する」からロールの情報を取得。 ● チームとして割り当たっていないメンバーがいれば検知して通知する。

Slide 49

Slide 49 text

お⽚付けに実は「ベスプラ」はない？全体のまとめ⾊々ごちゃごちゃと話しましたが... ● 会社や組織それぞれで求める要件が違う。 ● Power Platformその他製品の購⼊状況で様々な⼿段や制約がある。 ● それ以外の外部環境にもそれぞれ違いがある。各会社や組織に応じたテナント管理が必要であり、その前段階として「お⽚付け」という⽬線と必要性が共有できればゴールと考える。 ※ご参考にしていただければ幸いです。また、うちではこんな事しているよ‧‧‧ってことがあればぜひ教えてください！！

Slide 50

Slide 50 text

Thank You!!