この記事は
リクルートICT統括室 Advent Calendar 2023 13日目の記事です。

はじめに

ICT統括室インフラソリューションユニットの中山です。

リクルート内の Microsoft 365 や Azure、Entra ID（Azure AD）やオンプレミスの Active Directory など、主に Microsoft 系の社内システムの管理・運用を行っているチームに所属しています。

何の記事なの？

リクルート内では社内のファイル管理に SharePoint が広く使われています（SharePoint 以外に Google Drive やファイルサーバーもよく使われています）。

「SharePoint の権限管理が難しい！」という話を社内で時々聞くので、説明のために実際に色々試してみたところ、共有時の挙動が自分でも理解できないところがありました。そこで、深掘りして調べた結果を共有したいと思います。

共有リンク？

ざっくり言うとサイトへのアクセス権を持たないユーザーにサイト内の特定のファイルやフォルダーを共有するための仕組みです。

試すこと

まず、新規にサイトを作成して、既定のドキュメントライブラリの配下にフォルダーを作成、その下にファイルを作成した状態を作ります。

それからファイルに対する共有リンクを作成し、その裏側で何が起きているのかを探っていきます。

実験

ではここから、実際に挙動を見ながら確認していきます。

まず作成した時点では、それぞれ親から権限を継承しているため、サイトに対する権限がそのままファイルまで継承されています。

最初の権限の状態

サイトの権限

ドキュメントライブラリの権限

フォルダーの権限

ファイルの権限

共有リンクの作成

ファイルに対して共有リンクを作成します。

「共有」を開く

「リンクのコピー」ボタンをクリック

リンクが生成されたことを確認

ここでは共有対象として「リンクを知っているあなたの組織のユーザー」を指定してリンクを作成しています。

権限の確認

では改めて権限の状態を確認してみましょう。

サイトの権限

サイトの権限自体は変わっていないように見えますが、配下に固有の権限が設定されたことが表示されています。「これらのアイテムを表示します。」をクリックするとドキュメントライブラリが固有の権限になっていることが分かります。

ドキュメントライブラリの権限

固有の権限になっていますが、権限自体はサイトの権限と同じく変わっていないように見えます。こちらも配下に固有の権限があることが表示されており、「これらのアイテムを表示します。」をクリックするとファイルが固有の権限になっていることが分かります。

フォルダーの権限

フォルダーはドキュメントライブラリからそのまま権限を継承しています。

ファイルの権限

固有の権限になっており、共有リンクがあることも表示されていますが、こちらも権限自体はサイト、ドキュメントライブラリと同じように見えます。（「リンクを管理します」をクリックしても、ファイルのアクセス許可の管理画面が表示されるだけです。）

PnP PowerShell で詳細を確認

画面だけでは良くわからないので PnP PowerShell を使ってコマンドで権限付与の状態を調べてみます。

まずはサイトの権限を確認。

※以降、ソースコード引用箇所はすべてPowerShellで実行するものとします。

結果

画面に表示されていたグループのほかに「Limited Access System Group For Web ～」という名前のグループに「Webのみのアクセス制限」権限が付与されていることが分かります。

続いてドキュメントライブラリの権限。

結果

画面に表示されていたグループのほかに「Limited Access System Group For List ～」という名前のグループに「制限付きアクセス」権限が付与されていることが分かります。

続いてフォルダーの権限。

結果

継承しているので当然と言えば当然ですが、こちらはドキュメントライブラリと同じ権限になっています。

最後にファイルの権限を確認します。

結果

画面に表示されていたグループの他にも「SharingLinks～」グループに「投稿」権限が、「Limited Access System Group For List ～」に「制限付きアクセス」権限が付与されているのが分かります。（制限付きアクセスの方はドキュメントライブラリと同じ）

グループの確認

画面に表示されないグループが存在することが分かったので、グループについても見ておきましょう。

グループ一覧の画面を見ても、既定のグループ以外は表示されていないので、引き続き PowerShell PnP から見ていきます。

グループを一覧表示します。

権限付与されていたグループが表示されていることが分かります。

追加されたグループのメンバーを見てみます。

どのグループにもまだメンバーはいないようです。

共有リンク経由でのアクセス後の確認

ここで、試しにサイトの権限を持たないユーザーで共有リンクからアクセスしてみます。

アクセスしてから改めてグループのメンバーを確認してみました。

３つのグループに同じメンバーが追加されたことが分かります（14 はユーザーの ID）。

ユーザーを確認してみます。

共有リンク経由でアクセスしたユーザーの ID が 14 でした。

共有リンク経由でアクセスすると、共有リンク作成時に作成されたグループにメンバーとして追加される、ということが分かりました。

共有リンクを削除してみる

共有リンクを削除した際の挙動も見ていきます。ファイルから共有リンクを削除して、再度権限を確認してみます。

共有リンクを削除するとファイルの権限から「SharingLinks～」がいなくなっていました。

グループの一覧を改めてみてみると…

「SharingLinks～」グループ自体がサイトから削除されていました。

サイト、ドキュメントライブラリ、フォルダーの権限は共有リンクを削除しても変化なしでした。

共有リンクの仕組みの考察

ここまで試してきたこと＋追加でいくつか挙動を確認してみて、以下の挙動が確認できました。

• サイト内で初めて共有リンクを作成すると「Limited Access System Group For Web ～」という名前のグループが作成され、サイトに対する「Webのみのアクセス」権限が付与される
• ドキュメントライブラリ内で初めて共有リンクが作成された際にドキュメントライブラリの継承が削除され固有の権限になる。「Limited Access System Group For List～」という名前のグループが作成され、ドキュメントライブラリに対する「制限付きアクセス」権限が付与される
• 共有リンクが作成される際にファイルの継承が削除され固有の権限になる。「SharingLink.～」という名前のグループが作成され、対象のファイルに対する権限が付与される。付与される権限は共有リンク作成時の設定によって以下の通り。
  • 編集可能：投稿
  • レビューのみ：レビュー
  • 表示可能/ダウンロード許可：閲覧
  • 表示可能/ダウンロード禁止：制限付きビュー
• 共有の対象が「リンクを知っている組織のユーザー」の場合には、共有リンク経由でアクセスしたユーザーは自動的に共有リンク作成時に作成されたグループ（「Limited Access System Group For Web ～」と「Limited Access System Group For List～」と「SharingLink～」）のメンバーとして追加される
• 共有の対象が「選択したユーザー」の場合、共有リンク作成時に選択したユーザーが作成される「SharingLinks～」グループのメンバーとなる。
• 共有の対象が「リンクを知っている組織のユーザー」の場合でも最初にユーザーを指定することができ、指定したユーザーは最初から「SharingLinks～」グループのメンバーとなる。
• 共有リンクを削除すると作成時に作成されたグループもサイトから削除される。

確認できた挙動から、共有リンクでやっていることは「SharePoint グループを作成してファイルに対するアクセス権を付与する。アクセス権を付与するユーザーを SharePoint グループのメンバーとして追加する」ということが分かります。

アクセス権管理の基本的な仕組みが変更されているわけではなく、「このリンク経由でアクセスしてきた場合はグループのメンバーとして自動的に追加しますよ」という機能が追加されただけで、それ以外は従来からある権限管理の仕組みと同じと考えてよさそうです。

一度共有リンク経由でアクセスしてしまえばその後は共有リンクでなく「既存のアクセス権を持つユーザー」向けのリンクであってもアクセスできるようになります。

当初は「共有リンク経由でアクセスできる権限を付与している」と理解していたので、アクセス後に「既存のアクセス権を持つユーザー」用のリンクからもアクセスできることが不思議だったのですが、内部の挙動を確認したことで仕組みが理解できました。

すべてのユーザーに対する共有リンクの場合

「すべてのユーザー」に対する共有リンクを発行した場合、組織内のユーザーに対する挙動は同じですが、匿名ユーザーでのアクセスにも対応するため、追加の設定が行われます。

「すべてのユーザー」に対する共有リンクを発行してからファイルの権限を見てみます。

謎のセキュリティグループに「System.LimitedEdit」という謎の権限が付与されていますね。

サイト内のユーザー一覧を見てみます。

「ゲスト投稿者」という名前のユーザーが作成されています。分かりにくいですが、ID 28 の「SLinkClaim～」というのが、ファイルに「System.LimitedEdit」権限が付与されたセキュリティグループと同じものです。

匿名アカウントで「すべてのユーザー」共有リンクからアクセスしてファイルを更新すると更新者が「ゲスト投稿者」となるため、「ゲスト投稿者」は匿名ユーザーがアクセスしてきたとき用のユーザーだと考えられます。

ファイルに対しての権限は「SLinkClaim～」セキュリティグループに付与されているため、おそらく「SLinkClaim～」グループのメンバーとして「ゲスト投稿者」が登録されているものと思われます。（ただ、「SLinkClaim～」グループのメンバーを確認する方法が見つけられなかったため裏付けはとれず。）

共有リンクで権限付与されたファイルは検索結果に表示されるか？

検索については、

• 「すべてのユーザー」や「リンクを知っている組織のユーザー」の共有リンクを作成したからと言ってすべてのユーザーの検索結果に表示されるわけではない（共有リンク作成時点では SharePoint グループに権限を付与しただけのため）
• 共有リンク経由でアクセスしたり、共有リンク作成時に明示的に選択されたユーザーについては、グループのメンバーとなりファイルのアクセス権を持つことになるため、検索結果にもファイルが表示される

という挙動になりました。「自分に権限が付与されたファイルだけが検索できる」のが SharePoint の仕組みなので、内部の仕様が分かっていれば自然な結果ですね。

検索結果に表示されるファイル

• 「すべてのユーザー」または「組織のユーザー」に共有されて１度でもユーザーがアクセスしたことがあるファイル
• 「すべてのユーザー」「組織のユーザー」「特定のユーザー」に共有する際に共有するユーザーとして指定されたファイル

検索結果に表示されないファイル

• 「すべてのユーザー」または「組織のユーザー」に共有されているがユーザーがアクセスしたことがないファイル

まとめ

• 共有リンクを作成すると対応するグループが作成され権限が付与される
• ユーザーが共有リンク経由でアクセスすると、共有リンクと対応するグループのメンバーとして追加される

共有リンクはどういう仕組みになっているのか、調べてみると意外とシンプルなことが分かりました。

最後になりますが、
リクルート ICT統括室 Advent Calendar 2023 では、リクルートの社内ICTに関する記事が投稿されています。もし興味があれば、ぜひ他の記事もあわせてご参照ください。

以上、お読みいただきありがとうございました！