2024.10.26_Power_Platform_Administrator勉強会#2

Power Platformにおけるアプリやユーザーやセキュリティロールなどお片付けの「ベスプラ」について考えてみましたー

Transcript

1. Power Platform Administrator 勉強会#2 お⽚付けの「ベスプラ」 について考える。 2024.10.26 コバッチ (kobatch) 他力code
2. • 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
3. 技術者にとってキレイに「お⽚付けができること」こそ、 最も難易度が⾼く、ニーズの⾼いスキルである。 ー詠み⼈知らず
4. 今⽇話すこと Power Platform環境における管理者としての「お⽚付け」について考えてみました。 Agenda 1. お⽚付けの「必要性」について。 2. 管理者をやってみて「わかったこと」。 3. 今考える⾃分なりの「ベスプラ」。 ※ベスプラ＝「Best Practice」
5. 前提情報 本資料での⾔及内容は⼀般的なシナリオに基づいたものとなります。 会社（組織）でPower Platform市⺠開発環境を提供。 • 会社の主要環境とは別テナント。 • テナント内に複数環境が存在（既定＋検証⽤＋本番⽤など）。 • ユーザーアカウントも会社とは別管理、退職や異動に伴うメンテが必要。 主な使⽤製品
6. 「お⽚付け」の必要性 について。
7. こんなことありませんか？ アプリを「作った」、たくさんの⼈が「使った」はいいけど後が⼤変。 • アプリが⼤量⽣産されてるが、何がどう使われているのかわからないのでそのまま放置。 • 退職‧異動したユーザーや、昔のアカウントが残ったままになっている。 • ⼤量のセキュリティロールやチーム、あちこちに存在するルールなき個別設定に四苦⼋苦...。
8. 例えば（アプリ） いわゆる「寿命」が来たにも関わらず放置されている。 開発 運⽤ アプリの 寿命 アプリB アプリA アプリC （削除） アプリD アプリE アプリの 「お⽚付け」 ※寿命＝使⽤終了あるいは 実質使われていない。
9. 例えば（ユーザー） 退職や異動に伴う変更の「放置」「失念」。 アカウント 払出し 権限付与 退職や異動 発⽣ アカウント 削除 環境へのせキュリティグループ アプリAセキュリティロール（更新） アプリBセキュリティロール（閲覧） 環境へのせキュリティグループ アプリAセキュリティロール（更新） ユーザーや権限の 「お⽚付け」
10. 例えば（ロールの割り当て） アプリ セキュリティ ロール チーム チーム チーム チーム ア プ リ 仕 様 セキュリティ ロール 運 ⽤ 管 理 抜け漏れのない 「お⽚付け」 「チーム単位」で離脱させたはずなのに‧‧‧ ルール逸脱による「抜け⽳」。 たまたま個別に 権限を割り当ててしまった⼈
11. 放置により潜むリスク テナントと利⽤者の規模が拡⼤するに伴いリスクも拡⼤。 セキュリティ • 管理の⾒落としによる抜け⽳の懸念。 • 設定漏れによる不正なアクセスや情報漏洩。 管理コスト • 余計や確認や調査に対する⼯数増。 • イレギュラーに対する⼿動対応。 テナント有効利⽤ • 肥⼤化による容量逼迫やパフォーマンスへの懸念。 • そもそも有⽤に使うものにリソース集中したい。 Searched By Perplexity
12. Microsoftはもちろん対応しているが... プラットフォーマー依存ではよくない。 ERMフレームワーク Microsoft Learn Power Platformは優秀 • ⼀定期間使⽤のないアプリはリコメンドに表⽰された り、クラウドフローも⾃動オフされる。 • プラットフォーム全体に定期的にセキュリティパッチ も当たっている。 ⼀⽅で • ローカルルールやヒューマンエラーに対してはプラッ トフォーマーでもどうすることもできない。 セキュリティ事故に占める⼈為的ミスの割合は74%に上るという記事も... Searched By Perplexity
13. 実は「お⽚付け」は「作る」よりも難しい？ そもそもノウハウがインターネット上に少ない。 開発 運⽤ アプリの 寿命 お⽚付け https://learn.microsoft.com/ja-jp/power-platform/alm/overview-alm ノウハウと情報が少ない ALMはなんとなくこの辺をくるくる？‧‧‧ そしてものすごく重要なこと みんな「作る」のは好きだし得意だが、「お⽚付け」は嫌いだし苦⼿。
14. そんな「お⽚付け」についてマジメに考えてみる。 このセクションまとめ • アプリの「寿命」、ユーザーの「離脱」が始まって からがスタート。 • 「お⽚付け」をしないとセキュリティや管理⼯数、 リソース有効活⽤の観点でリスクあり、テナント規 模拡⼤につれより増す。 • ローカルルール、ヒューマンエラーの観点からプ ラットフォームの仕組みのみに頼らず、⾃衛の意識 を持つことが重要。 • 具体的な情報やノウハウがそもそも少ない。
15. 管理者をやってみて 「わかったこと」。
16. ３つのポイント PPAC（管理センター）およびEntra、Azureの活⽤。 アプリとソリューション • アプリへのアクセス状況（PerApp）。 • ソリューションの削除。 ユーザー • ユーザーの種類。 • PowerPlatform環境からの削除。 • Entra監査履歴のLogAnalytics連携。 セキュリティロール • ユーザーからの逆引き。 ※内容は主に独⾃調査（⼀部公式サポート確認含む）となります。 訂正、補⾜等、フィードバックいただければ幸いです。
17. アプリとソリューション 環境 > (環境名) > PowerApps アプリ 所有者名 環境名
18. アプリへのアクセス状況 請求 > ライセンス > 環境 にて確認。 アプリごとのPerApps • アプリ使⽤あたりのライセンス。 • Premiumを持たないユーザーが対象。 • 環境とアプリ数とアクセス数で積算。 Power Apps Premium • ユーザーライセンス。 • 全てのアプリにアクセスが可能。 • 厳密には使⽤アプリの識別は不可...？ 環境名 数字 数字
19. アプリごとのPerAppsのカウント条件 アプリID ＝アプリを識別 する内部番号 例) 90226cf6-a5f1-e a21-a845-000d3 a52d87a 数字 例） 10 アクセスしたアプリ数、環境、ユーザーの積算となる。 ※サポートへの確認 • Premiumを持たないユーザーがアプリ にアクセスすれば「アクティブユー ザー」 1 カウント、30⽇間未アクセス であれば 1 カウント解除。 • 強制的にアクセス解除したい場合は権 限を外す（ただし、カウントは30⽇間 の経過を待つことが必要）。 数字 例） 10
20. ソリューションの削除 アプリ（セキュリティロール）はソリューション単位で削除。 • ソリューションを構成するオブジェクト （テーブル‧クラウドフローなど）に依 存関係がなければ、マネージドソリュー ションでも削除可能。 • アンマネージドソリューションであれば エクスポートしてzipファイルとして保存 しておくことも可能。 ソリューション名称 ソリューション名称 ソリューション名称 ソリューション名称 ソリューション名称 ソリューション名称 ソリューション名称 ソリューション名称 ソリューション名称
21. ユーザー 環境 > (環境名) > 設定 > ユーザー ユーザー表⽰名 ユーザーID 環境名
22. Power Platformのユーザー管理と種類 環境単位に作成される。M365側設定と⾮同期で連携される。 有効なユーザー • アカウントがアクティブ、かつ環境およびア プリに適切な権限が割り当たっている状態の ユーザー。 無効なユーザー • ライセンス適⽤がないユーザー、もしくはセ キュリティグループから削除され、環境への アクセス権がないユーザー。
23. Power Platform側のユーザー削除 環境 > （指定の環境）> 設定 > 機能 にて、環境単位で設定が可能。
24. Power Platform側のユーザー削除 ⼀括処理による削除。 • 環境設定完了後、上部に「⼀括削除」メ ニューが追加。 • ポップアップ表⽰され、条件やスケジュー ル設定が可能。 ※⼀度やってみたが、想定通りに削除されなかっ た（原因は未調査だが、おそらくレコードの割り 当てが必要等の理由による）。
25. Entra監査履歴のLogAnalytics連携 管理画⾯より「診断設定」にて設定（※別途Azureサブスク課⾦が必要）。 環境名 M365ユーザーアクティビティの各種監査履歴をロ グデータにしてDB管理することが可能。例えば下 記のログを連携。 • AuditLogs（監査ログ） • SignInLogs（サインインログ） • RiskeyUsers（危険なユーザー） • UserRiskEvents（ユーザーリスクイベント）
26. KQLを活⽤した条件に基づく検索、および通知機能の実装が可能。 Azure側出⼒イメージ
27. セキュリティロール 環境 > (環境名) > 設定 > セキュリティロール ユーザー表⽰名 部署名 環境名
28. ソリューションから削除するのがベター。 セキュリティロールの削除 セキュリティロール名 ソリューション名 セキュリティロール名 管理センターからの直接削除も メニューとしては存在（ただ し、依存関係などの関係から難 しいのではないか）。 セキュリティロール名 セキュリティロール名 セキュリティロール名 セキュリティロール名 部署名
29. ユーザーやチームからの逆引き確認が可能。 セキュリティロールの割当状況確認 環境 > （環境名）> 設定 > ユーザーより • 任意のユーザーを右クリック。 • セキュリティロールの管理を選択。 こちらにより、選択ユーザーが所属しているセキュ リティロールを確認することができる（チームでも 同じ確認が可能）。 ユーザー名 ユーザー名 部署名 セキュリティロール名 セキュリティロール名 セキュリティロール名 セキュリティロール名 セキュリティロール名 セキュリティロール名 セキュリティロール名 セキュリティロール名 セキュリティロール名 セキュリティロール名 セキュリティロール名 セキュリティロール名
30. （参考）CoEスターターキット アプリの利⽤状況やアクセス権の割り当て状況など統合的に管理可能なツール。 そもそもあまり使い⽅や⾒⽅やできることがわかっ ていないので割愛。 • PowerApps Apps • Power Apps Portals • Flows • Environments • Audit Logs などの情報が確認できる。 ※有識者の皆様是⾮教えてください。 アプリ名
31. これらを踏まえたお⽚付けの「ベスプラ」とは？ このセクションまとめ アプリ • アプリ単位のアクセス（アクティブ）について確認することができる。 • マネージドソリューションでも削除は可能。 • アンマネージドソリューションはエクスポートしておくことも可能。 ユーザー • 無効ユーザーはPower Platformの該当環境に対するアクセス権限はない。 • ⼀括で削除することもできるが、レコードの再割り当てなどの対応が必要。 • Entraの監査履歴はLogAnalytics連携できるので、検知や通知の仕組みの実装が可能。 セキュリティロール • ソリューション単位で削除していくのがベター。 • ユーザーやチームから割り当て状況を確認することができる（いわゆる逆引き）。
32. 今考える⾃分なりの 「ベスプラ」。
33. 「完璧」は不可能と⼼得る、状況に応じて「柔軟に対応」できる余地を作る。 ポイントの整理 やっておくべきこと • ❶⼀定のルール化と運⽤。 • ❷リスクやルール逸脱を検知できる仕組み（受動 ＞ 能動）。 • ❸「お⽚付け」処理の⾃動化。 やらなくていいこと • ライフサイクル全体の「⾃動化」や「フロー化」。 • 管理をするための「アプリ開発」。 活⽤
34. 個⼈的に机上含む調査の範囲であり、全てを検証済ではありません。 まず結論 アプリ • 使わなくなったものはアーカイブ＋環境からはソリューション単位で削除。 ‧‧‧❶ • 負債が⾼いもの（依存関係が⼊り組んでいる）は残存管理。 ‧‧‧❶ ユーザー • ⼊り⼝となるEntraできちんとシャットアウト。 ‧‧‧❶❸ • および監査履歴の検知⾃動化などで最初の関⾨の管理を強化する。 ‧‧‧❷ セキュリティロール • 原則は全てチーム単位で割り当てを⾏う（運⽤でカバー）。 ‧‧‧❶ • 各アプリのセキュリティロール割り当て状況の横断チェック。 ‧‧‧❷❸
35. アプリ（おさらい） 「寿命」が来たにも関わらず放置されている。 開発 運⽤ アプリの 寿命 アプリB アプリA アプリC （削除） アプリD アプリE RISK アプリの 「お⽚付け」
36. 寿命が来たらソリューション単位で削除、ただし依存関係が複雑なものは無理しない。 アプリ（ベスプラ案） 開発 運⽤ アプリの 寿命 お⽚付け ❷PerApps使⽤状況の監視＋CoEスターターキットでの監視（あるいは定期的な棚卸） ❶ソリューションエクスポートによるアーカイブ化 （アンマネージド） ❶テナントからソリューションの削除 ※依存関係が複雑で削除困難なものは無理しない （セキュリティロールから全ユーザーを剥奪） 環境名 数字 ❶命名ルールの定義
37. ⾃動化の領域に踏み込むにはなかなか難しい。 アプリ（補⾜） 難しい‧⼯夫が必要な点 • 命名ルールはソリューション単位の区分けを分かりやすくする意味で重要。 • 使⽤中の判断は管理者側の情報だけでは難しい、別途管理‧棚卸が重要。 • 削除やエクスポートは基本的に⼿動対応になる。 他に考えられること • アプリのDataverseテーブルのエクスポート（PowerShellにて可能）。 ◦ https://learn.microsoft.com/ja-jp/power-platform/developer/cli/reference/data
38. ⾃動バックアップしておくことで、アプリ寿命時に躊躇なく削除できる。 ちょっと考えていること（Pipelineでの拡張操作） アンマネージド環境 マネージド環境 承認 ソリューションの ZIPファイルバックアップ • Pipelinesでリリース承認きっかけからのクラウドフロー起動。 • ソリューションZIPファイルの別媒体保存。 PowerPlatform Pipelines Power Platformでパイプラインを拡張する https://learn.microsoft.com/ja-jp/power-platform/alm/extend-pipelines
39. 退職や異動に伴う変更の「放置」「失念」。 アカウント 払出し 権限付与 退職や異動 発⽣ アカウント 削除 環境へのせキュリティグループ アプリAセキュリティロール（更新） アプリBセキュリティロール（閲覧） 環境へのせキュリティグループ アプリAセキュリティロール（更新） RISK ユーザー（おさらい） ユーザーや権限の 「お⽚付け」
40. ⼊り⼝（Entra ID）をしっかり塞いで、監視ができる仕組みを整える。 ユーザー（べスプラ案） アカウント 払出し 権限付与 退職や異動 発⽣ アカウント 削除 ❶確実に環境のセキュリティグループから権限 剥奪、あるいは❸物理アカウント削除。 Power Platform側は確実に対象ユーザーが「無効」になって いることを確認すればよく、無理な削除は⾏わない。 ❷Log Analyticsを活⽤した監査履歴の監視や不正なログインなどの検知は常に⾏う。
41. Power Platform側の同期データについては⽬をつぶる。 ユーザー（補⾜） 難しい‧⼯夫が必要な点 • Power Platform側のユーザー情報削除は所有者や監査履歴を考えると影響あり。 他に考えられること • ポリシーの厳格化（強制リセットや⼆要素認証、パスキー導⼊など）。 • アカウント管理体系の⾒直し（ゲストアカウントなどで組織と連動）。 • テナントへのIP制限の追加。 など
42. Power Automateを使って⾃動化。 監査履歴の通知 例）1時間で5回以上のログイン試⾏を⾏ったユーザーを検出。 Azure上でKQLを使って集計クエリを作成。 AzureMonitorアクションを使ってKQLクエリを実 ⾏、取得レコードがあった（＝検知した）場合、 Teams等のアクションで通知する。
43.   グループのメンバーを取得 定期周期で実⾏し、発覚したらTeams通知をする「受動的な検知」を実装。 ざっくりフローの流れ  定期周期による起動 LogAnalytics検索 Teamsに通知 • 毎時‧毎⽇などの周期でトリガー。 • LogAnalytics検索で、監査履歴より指定回数ログインを したユーザーを検索。 • Entraにて対象となるユーザー情報の取得。 • （じゃないユーザーの検知時に）全ユーザーを取得。 • ⼀定期間未ログインなどのグループ除外、無効化など。 • 検知をしたユーザー情報やアラームを指定のチャネルな どに通知。
44. 相談相⼿、兼‧先⽣＝GPT4o。 たとえばこんな検知ができれば LogAnalyticsとPower Automate活⽤で検出できそうなこと。 • 何度もログイン試⾏を⾏ったユーザーの検出。 • 期間未ログイン状態のユーザーの検出。 • ⻑期間パスワード変更を⾏なっていないユーザーの検出。 • 頻繁にパスワードリセットを⾏なっているユーザーの検出。 • 不審な場所からのログインの検出。 • 管理者権限の不正利⽤の検出 アクティブなセッション数の監視。 • 権限エスカレーションの試⾏の検出。 • 管理者アカウントでのログイン。
45. セキュリティロール（おさらい） アプリ セキュリティ ロール チーム チーム チーム チーム ア プ リ 仕 様 セキュリティ ロール 運 ⽤ 管 理 「チーム単位」で離脱させたはずなのに‧‧‧ ルール逸脱による「抜け⽳」。 たまたま個別に 権限を割り当ててしまった⼈ RISK 抜け漏れのない 「お⽚付け」
46. とにかく「チーム単位」で管理し、ルール逸脱を監視できる仕組みを整える。 セキュリティロール（ベスプラ案） ❶基本的に権限付与は「チーム」単位で⾏い、メ ンバーの追加‧削除はチームに対して⾏う。 ❶「チーム」単位で権限剥奪することで、 抜け漏れを防⽌する。 ❷各アプリのロールの割り当て状況を監視する（検証中）。 開発 運⽤ アプリの 寿命 お⽚付け
47. ルール逸脱しがちなのは実は「管理者」。 セキュリティロール（補⾜） 難しい‧⼯夫が必要な点 • ⼿動対応がメインとなる。逆引きなどを駆使して地道なチェックが必要。 • イレギュラーになりがちなのは実は「管理者側アカウント」、したがって保守⽤や管理者ア カウントもチーム配下での管理を⾏うべき。 • Power Automateでアプリのロール⼀覧の取得ができる？⾃動監視ができてイレギュラーを簡 単に検出できるようになると尚良い（調査中）。 他に考えられること ‧‧‧（何かあれば教えてください）。
48. PowerApps系のコネクタを使って、ロールの割り当て状況を検知できるか（検証中）。 ロールの割り当て⾃動化案  定期周期による起動 ロールの割り当てを取得 Teamsに通知 • 毎時‧毎⽇などの周期でトリガー。 • 対象となる環境からアプリの⼀覧を取得。 • 「アプリロールの割り当てを管理者として取得する」 からロールの情報を取得。 • チームとして割り当たっていないメンバーがいれば検 知して通知する。
49. お⽚付けに実は「ベスプラ」はない？ 全体のまとめ ⾊々ごちゃごちゃと話しましたが... • 会社や組織それぞれで求める要件が違う。 • Power Platformその他製品の購⼊状況で様々な ⼿段や制約がある。 • それ以外の外部環境にもそれぞれ違いがある。 各会社や組織に応じたテナント管理が必要であり、そ の前段階として「お⽚付け」という⽬線と必要性が共 有できればゴールと考える。 ※ご参考にしていただければ幸いです。また、うちではこんな事して いるよ‧‧‧ってことがあればぜひ教えてください！！
50. Thank You!!