許可権限設定について

SmartPOST管理画面の許可権限設定に関するよくある質問集です。

必要な要件を明らかにすることで、設定の複雑さを最小限にするとSmartPOSTをシンプルに効率よく利用できます。次の条件について検討し、それぞれに当てはまる選択をすることをおすすめします。

操作権限についてプリセットロール（オーナー、承認者、メンバー）で権限管理の要件を満たしているかどうかを検討します。

登録された管理者の間で、各プロジェクトの閲覧について制限する必要があるかどうかを検討します。

グループのポリシー付与については個別のケースによって判断が必要です。グループのポリシーを利用すると、管理者がどういった権限を持つか、管理するのに複雑になりすぎるケースがあり、注意が必要です。

特定のグループのみに対して、より強い権限を与えたい、といったところが利用すべきか検討のポイントとなりますが、その場合、カスタムロールによって設定するとう選択肢もあります。

具体的な要件について検討し、運用に沿った設計をすることをおすすめします。

設定例としては下図のような例が考えられます。

※課の名前などは例として記載しています。

実際にSmartPOSTを利用して住民宛てに通知を作成する担当原課の想定として市民課グループ、子育て支援課グループのように部署単位でグループを設定しています。

ロールに関しては、プロジェクト承認なども可能な担当者を想定した責任者ロール、承認権限は付与されていない担当者向けを想定した一般ロールが管理者に付与されてます。これは部署ごとに用意するのではなく、複数の部署に対して一般化することで運用負荷軽減の効果があります。

また、このケースではSmartPOSTの管理運用についてはデジタル行政支援課が担当し、I 課長が責任者としてオーナーロールが設定されていて、実務を担う他担当者については、オーナー権限に近いものの、もう少し権限（例えば同意権限など）を取り除かれた管理者ロールが設定されています。

また、現状の権限設定を運用するにはポリシーについてカスタム運用する場合は、管理運用する担当者に絞ってカスタムポリシーの書き込み権限を付与することが推奨されます。上記のケースにおいては管理者ロールに限定することがおすすめです。これは誤ったポリシー操作による事故を避けるためです。

図の下部に記載されているのはプロジェクトです（※本節では前提として、プロジェクト作成者の権限については除外、プロジェクトの操作に必要な権限は付与されているものとして記載しています）。

それぞれに対し、グループ権限が付与されており、グループと線で結ばれているプロジェクトが、可視、操作可能であることを表しています。例えば市民課グループが付与されたprojectA, projectB は市民課グループに所属する管理者からのみ可視であり、操作可能です。

projectD, projectE についても同様で、子育て支援課グループに所属する管理者からのみ可視であり、操作可能です。

projectC については部署横断で閲覧したいような通知を作成する際に、グループ権限を市民課グループ、子育て支援課グループと複数設定すると両グループに所属する管理者から可視、操作可能なプロジェクトとすることができます。

また、グループの設定がされていないprojectF についてはどの管理者からも可視、操作可能なプロジェクトとなります。