アクセス権限の棚卸｜共有リンクは転送できる、退職者のIDは残る

梟〜GLEANINGS〜

2026年9月12日 10:25

半年前に取引先へ送った、見積書の共有リンク。
案件はとっくに終わっています。

そのリンク、いまも開けるでしょうか。
そして、これまでに誰が開いたか、答えられるでしょうか。

この記事では、渡した権限をどう回収するかを扱います。
共有リンク、アプリに押した「許可」、退職者のID、そして在職者の権限。
どれも、渡すときには理由があって、返してもらう手続きがない、という点で同じです。

先に、調べていていちばん意外だったことを2つ書いておきます。

1つ目。
「リンクを知っている全員」より安全だと思われている「特定のユーザー」向けリンクのほうが、そのファイルを検索結果とCopilotに出します。
安全なほうが、より広く見つかる。
逆に見えますが、理由があります。

2つ目。
IDを消すのが正解とは限りません。
IPAは、消すとログまで消えるシステムでは「ロック」を選べ、と書いています。

この記事は、Microsoft Learn のOneDrive・SharePointの共有リンクとMicrosoft Entra IDの各ページ、Googleドライブヘルプ、IPA「組織における内部不正防止ガイドライン」第5版、IPA「情報セキュリティ10大脅威 2026」の解説書をもとに、2026年9月12日時点の内容にしています。

共有リンクは、転送できる鍵である

Microsoftは、リンクを3種類に分けている

まず、種類を整理します。
Microsoftの公式ドキュメントは、共有リンクを3つに分けています。

There are three primary link types: "Anyone" links "People in your organization" links "Specific people" links

誰でも、組織内の人、特定のユーザー。
この3つです。

いちばん問題になるのが、1つ目です。

People using an Anyone link don't have to authenticate, and their access can't be audited.

このリンクを使う人は認証する必要がなく、そのアクセスを監査することはできない。
開いた人が誰なのか、こちら側は知りようがない、ということです。

鍵にたとえた説明が、いちばん分かりやすい

同じドキュメントは、このリンクの性質をこう定義しています。

An Anyone link is a transferable, revocable secret key.

転送可能で、取り消し可能な、秘密の鍵である。
3つの言葉に、それぞれ説明が付いています。

It's transferable because it can be forwarded to others.

It's revocable because you can revoke access for everyone who used the link by deleting it.

It's secret because it can't be guessed or derived.

そして、この鍵がどう渡るかも書かれています。

The only way to get access is to get the link, and the only way to get the link is for somebody to give it to you.

アクセスする唯一の方法はリンクを手に入れることであり、リンクを手に入れる唯一の方法は、誰かがあなたに渡すことである。

渡す相手を、こちらは選べません。
取引先の担当者が社内のチャットに貼るかもしれませんし、メールで転送するかもしれません。
悪意は要りません。
仕事を進めるための、ごく自然な動きです。

取り消す方法は1つだけ、リンクを消すことです。
そのときは、正規の相手も含めて全員が締め出されます。

社内向けのリンクも、同じ鍵である

ここが見落とされやすいところです。
「組織内の人」向けのリンクなら安全だ、と思われがちですが、性質は同じです。

Like an anyone link, a People in my organization link is a transferable, revocable secret key.

同じく、転送可能で取り消し可能な秘密の鍵である。
違うのは、開く人が組織のメンバーとして認証を求められる点です。

When somebody opens a People in my organization link, they need to be authenticated as a member in your directory.

社内の誰かに転送されることは止められません。
止められるのは、社外に出ることだけです。

「特定のユーザー」だけが、転送できない

3つ目が、対策になります。

A Specific people link is a nontransferable, revocable secret key.

Specific people links don't work if they're opened by anybody other than the persons who are specified by the sender.

送信者が指定した人以外が開いた場合、このリンクは機能しない。
社外の相手にも使えて、その場合も受け取った人は指定された本人として認証する必要があります。

手間は増えます。
相手のメールアドレスを正確に入れる必要があり、相手側にもログインが要ります。
その手間が、そのまま追跡可能性になっています。

ただし、意外な副作用がある

冒頭で書いた1つ目の意外な点が、ここです。
同じドキュメントには、こうあります。

Creating an Anyone link doesn't make the associated content appear in search results or make it accessible through Copilot.

誰でも開けるリンクを作っても、その中身は検索結果に出ないし、Copilotからも使えない。
組織内向けのリンクについても、同じことが書かれています。

ところが、特定のユーザー向けのリンクは違います。

Moreover, Specific people links make the associated file or folder appear in search results and make it accessible through Copilot for all user and security group members who are added to the sharing link.

検索結果に出るようになり、そのリンクに追加された人たちのCopilotから使えるようになる。

理由は考えてみると当たり前です。
誰が見てよいのかが分からないファイルは、検索やAIに載せようがありません。
相手が特定されて初めて、その人の検索結果に混ぜられます。

安全な渡し方を選ぶと、社内の検索とAIには載りやすくなる。
どちらが良い悪いではなく、そういう設計だと知っておく話です。

Googleの側も、同じことを書いている

ログインは必要ありません

Googleドライブのヘルプは、ファイルへの一般的なアクセスを3つに分けています。

一般公開: 誰でもが Google でファイルを検索してアクセスできます。Google アカウントへのログインは必要ありません。

リンクを知っている全員: リンクを知っている全員がファイルを使用できます。Google アカウントへのログインは必要ありません。

制限付き: アクセス権のあるユーザーだけがファイルを開くことができます。

上の2つに、同じ一文が付いています。
ログインは必要ありません。
つまり、開いた人が誰なのかは記録に残りません。

Microsoftの説明と、言い方は違いますが中身は同じです。

有効期限は、仕事用アカウントの機能である

案件が終わったら切る、という作業を人の記憶から外す方法があります。
有効期限です。

ただし、Googleドライブのヘルプには条件が書かれています。

有効期限の設定機能を使用するには、対象となる仕事用アカウントまたは学校用アカウントにログインしている必要があります。

個人用アカウントでは使えません。

Microsoftの側にも、組織内向けリンクの有効期限ポリシーがあります。
こちらで押さえておきたいのは、期限が切れたときに何が起きるかです。

When a sharing link expires, only the link is affected. The file or folder isn't deleted, and users who have access through other permissions can continue to access the content.

期限が切れるのはリンクだけ。
ファイルは消えませんし、別の経路で権限を持っている人は、そのまま開けます。

期限を付けたから安心、とはなりません。
リンクという鍵が1本無効になるだけです。

「許可」を押したとき、何を渡したのか

同意は、サインインとは別の行為である

便利そうなツールを見つけて、会社のアカウントでログインした。
「このアプリに次の権限を許可しますか」という画面が出たので、押した。

このとき何が起きたのか。
Microsoftの公式ドキュメントは、この「許可」を同意と呼び、こう定義しています。

同意とは、アプリケーションが保護されたリソースにアクセスすることを、ユーザーが許可するプロセスです。

具体例も挙げられています。

たとえば、アプリケーションは、サインインしているユーザーのプロファイルを表示し、ユーザーのメールボックスの内容を読み取るアクセス許可を要求できます。

メールボックスの内容を読み取る。
名前とメールアドレスを教えるだけ、という理解とは距離があります。

手順も書かれています。

ユーザーの同意は、ユーザーがアプリケーションにサインインするときに開始されます。ユーザーがサインイン資格情報を指定すると、同意が既に付与されているかどうかが確認されます。必要なアクセス許可に対するユーザーまたは管理者の同意の以前のレコードが存在しない場合、ユーザーは同意プロンプトウィンドウに移動して、要求されたアクセス許可をアプリケーションに付与します。

本人だと示すことと、権限を渡すことは、続けて起きるだけで別のことです。

そして、もう一文あります。

通常、ユーザーは同じアプリケーションへの将来のサインイン時にもう一度同意する必要はありません。

一度押せば、次からは聞かれません。
だから、いつ何に同意したのかは、時間が経つほど分からなくなります。

管理者が押すと、組織全体に及ぶ

同意には2種類あります。
利用者が自分の分について与えるものと、管理者が組織全体について与えるものです。

後者について、こう説明されています。

管理者の同意時に、特権管理者は、他のユーザーに代わって (通常は組織全体に代わって) アプリケーションへのアクセス権を付与できます。

そして、警告が続きます。

組織に代わって管理者の同意を付与することは機密性の高い操作であり、組織のデータの大部分、または高度な特権付きの操作を行うアクセス許可にアプリケーションの発行者がアクセスできる可能性があります。

具体例まで書かれています。

そのような操作の例は、ロール管理、すべてのメールボックスまたはすべてのサイトへのフルアクセス、完全なユーザー偽装などです。

すべてのメールボックスへのフルアクセス。
完全なユーザー偽装。

そのうえで、判断の基準もはっきり書かれています。

アプリケーションを制御しているユーザーと、アプリケーションがアクセス許可を要求している理由について、確信を持てない場合は、同意を許可しないでください。

誰が作っているのか。なぜその権限が要るのか。
この2つに答えられないなら押すな、ということです。

誰が押せるかは、設定で決められる

そもそも一般の利用者に押させてよいのか、という疑問が出てきます。
その設定も用意されています。

特権管理者は、管理者以外のユーザーがアプリケーションにユーザーの同意を付与できるかどうかを構成できます。

無効にした場合の受け皿もあります。

管理者の同意ワークフローが有効になっている場合、ユーザーには、アプリケーションへのアクセスに対する管理者の承認を要求する [承認が必要] ウィンドウが表示されます。

使いたい人が申請し、管理者が判断する。
一律に禁止すると、業務が止まるか、個人のアカウントで使われるだけです。
申請の道を残しておくほうが現実的だと思います。

退職と異動：IPAは「ただちに削除」と書いている

強い書き方である

IPAが出している「組織における内部不正防止ガイドライン」第5版には、こうあります。

また、異動又は退職により不要となった利用者ID及びアクセス権は、ただちに削除しなければならない

ただちに、そして、しなければならない。
かなり強い書き方です。

ただし、単純に消せばよいという話でもありません。
同じ箇所の脚注に、但し書きがあります。

利用者IDを消去したときにアクセス記録などが消去されるような場合には、利用者IDをロックしてアクセス出来ないような状態としてログを保全することが必要となります。

IDを消すと、そのIDのアクセス記録まで消えてしまうシステムがあります。
あとで何か起きたとき、誰が何をしたのかを追えなくなります。

削除ではなくロックを選ぶ場面がある。
どちらにするかはシステムの作りによるので、使っているサービスごとに事前に決めておく必要があります。

「異動」も、同じ扱いになっている

見落とされやすい言葉があります。
先ほどの一文は「異動又は退職により」で始まっていました。

退職だけの話ではありません。
経理から営業に移った人が、経理システムの権限を持ったまま、という状態も対象です。

退職は日付がはっきりしているので、手続きの引き金になります。
一方、異動は引き金になりにくい。
席を移して、前の仕事の引き継ぎをしながら、権限だけが残ります。
そして本人も、使えることに気づいていないことがあります。

ガイドラインは、その引き金についても書いています。

利用者ID及びアクセス権の登録・変更・削除の手続きに漏れがないように、人事異動に関連する人事手続き等と連携した運用とします

情報システムの側だけで頑張る話ではない、ということです。

止めるものは、メールだけではない

雇用終了については、別の項目が立っています。

情報システムから元役職員の利用者IDや権限が削除されたことを確認することが必要です。これには、テレワークを行うために元役職員に付与した権限も含みます。利用者IDや権限の削除は、雇用終了直後に速やかに実施することが肝要です。

テレワークのために出した権限も含む、と名指しされています。
VPNのアカウント、社外からの認証、貸与端末。
メールを止めた時点では、どれも止まっていません。

もう1つ、時期についての指摘があります。

雇用終了間際に情報の持ち出し等の内部不正が発生しやすいことから、雇用終了前の一定期間から、PC等をシステム管理部門等の管理下に置くことが望まれます

退職日ではなく、退職が決まった時点から、という話です。

入るとき、動くとき、出るとき

権限が変わるのは、この3回だけである

この考え方は、道具の側にも組み込まれています。
Microsoftのライフサイクルワークフローという機能は、利用者の状態を3つの局面に分けています。

加入者: 個人がアクセスを必要とする範囲に入るとき。たとえば、会社や組織に参加する新入社員です。

異動者: 個人が組織内の境界間を移動するとき。この移動には、より多くのアクセスまたは認可が必要になる場合があります。たとえば、マーケティングに所属していたユーザーが、営業組織のメンバーになった場合などです。

離脱者: 個人がアクセスが必要な範囲から外れるとき。この移動には、アクセスの削除が必要になる場合があります。たとえば、退職する従業員や解雇された従業員などです。

入るとき、動くとき、出るとき。
権限が変わるのはこの3回なので、この3回に手続きを結び付ければよい、という設計です。

ただし、条件があります。

この機能を使用するには、Microsoft Entra ID ガバナンスまたはMicrosoft Entra スイートライセンスが必要です。

標準のプランには含まれていません。
中小企業では、ここで現実的な選択を迫られます。
この点は最後に書きます。

SSOを入れても、アカウントは消えない

ログインの統合と、停止の同期は別の機能である

よくある誤解を扱います。
ログインをまとめる仕組み、いわゆるシングルサインオンを入れた会社で、こういう理解をしている場合があります。

本体のアカウントを止めれば、連携している全部のサービスが止まる。

これは、正しくありません。
Microsoftのドキュメントは、2つの機能を並べてこう書いています。

シングルサインオン (SSO) のために SAML や OIDC などの標準を使用しますが、アクセスのためにはユーザーをアプリにプロビジョニングする必要もあります。

後者はプロビジョニングと呼ばれ、こう定義されています。

Microsoft Entraアプリケーションプロビジョニングとは、ユーザーがアクセスする必要があるアプリケーションでユーザー ID とロールを自動的に作成することを指します。自動プロビジョニングには、ユーザー ID の作成に加えて、状態または役割が変化したときのユーザー ID のメンテナンスおよび削除が含まれます。

これを設定していないサービスは、本体を止めてもアカウントが残ります。
そして、すべてのサービスが対応しているわけでもありません。

Manual プロビジョニングは、アプリに自動の Microsoft Entra プロビジョニングコネクタがまだ備わっていないことを意味します。それらは手動で作成する必要があります。

手動のままのサービスが、たいてい何本か残ります。

順番を間違えると、同期が回らない

実務で引っかかる制限を2つ挙げておきます。

Microsoft Entra ID 内で無効になっているユーザーのプロビジョニングはサポートされていません。プロビジョニングされるには、事前に Microsoft Entra ID 内でアクティブになっている必要があります。

本体のアカウントを先に無効化すると、その利用者についての同期が動かなくなります。
急いで本体を止めたせいで、連携先のアカウントが停止されないまま取り残される。

もう1つ。

ユーザーまたはグループがアプリから割り当て解除され、プロビジョニングサービスで管理されなくなると、無効化要求が送信されます。その時点で、ユーザーはサービスによって管理されておらず、ユーザーがディレクトリから論理的に削除されたときに削除要求は送信されません。

アプリの割り当てを先に外すと、そこで止まります。
そのあとで本体のIDを消しても、削除の指示は飛びません。

どちらも順番の問題です。
手順書に書いておかないと、急ぎの日に必ず踏みます。

在職者の権限を、誰が見直すのか

渡すときに、期間を決める

見直しの前に、渡し方の話があります。
IPAのガイドラインには、こうあります。

重要情報へのアクセス権限を付与すべき者を必要最小限とします。また、アクセス権限を持つ者に付与する権限を必要最小限とし、権限を付与する期間も必要な時期に限って行うこととします。

渡す相手を絞る。渡す権限の範囲を絞る。そして、渡す期間を絞る。
3つ目が、実務ではいちばん抜けます。

「この案件のあいだだけ」という前提で渡した権限に、終わりの日を設定していない。
案件が終わっても、権限は終わりません。

権限は、増えるときには理由があります。あの案件で必要だから、あの月だけ見たいから。
減るときには理由がありません。
誰も困らないので、そのまま残ります。

見直す時期と、見るべき相手

同じガイドラインは、見直しについてこう書いています。

利用者ID及びアクセス権が適切に付与されているかを確認するために、定期的にアクセス権の要件を見直します。例えば、人事異動の時期に一斉に見直す等を行うことが望まれます。特に、アクセス権限が集中している者に対しては、適切性を確認し、不必要なアクセス権限は削除を行います。

異動の時期に合わせるのは、理にかなっています。
どのみち権限が動く時期ですし、「この人はいま何の仕事をしているのか」を人事側が把握している時期でもあります。

そして、権限が集中している人を名指ししています。
たいていの会社で、それは情報システムの担当者本人です。

管理者が1人だと、誰も止められない

その点についても、項目が立っています。

システム管理者が複数人いる場合は、システム管理者IDごとに適切な権限範囲を割り当てシステム管理者が相互に監視できるようにしなければならない。

リスクの説明が、身も蓋もありません。

例えば、ある重要なシステム管理操作を実行できる権限を持つ管理者が1人しかいない場合は、誰もこの管理者の内部不正を止めることができません。

管理者が1人の会社では、技術で解けません。
ログを外部に出す、操作の記録を上長が見る、といった別の形で相互監視を作るしかありません。

情報システムには、判断できない

ここが、この作業のいちばん難しいところです。

一覧を出すのは情報システムの担当者にできます。
しかし、その権限がいま業務上必要かどうかは、情報システムの担当者には分かりません。

Microsoftのアクセスレビューという仕組みは、レビューする人を選ばせます。
選べるのは次の4つです。

グループ所有者

選択したユーザーまたはグループ

ユーザーが自分のアクセス権を確認する

ユーザーのマネージャー

情報システムの担当者は、この一覧に入っていません。
作業を回す人と、判断する人を分ける。
これがこの仕組みの前提です。

回答がなかったとき、どうするか

この仕組みでいちばん学ぶところが多いのが、次の設定です。
レビューの期間内に回答がなかった利用者をどう扱うか、あらかじめ決めておく項目があります。

変更なし: ユーザーのアクセスは変更されません。

アクセス権の削除: ユーザーのアクセス権を削除します。

アクセスの承認: ユーザーのアクセスを承認します。

推奨事項を取得する: ユーザーの継続的なアクセスを拒否または承認するためのシステムの推奨事項を受け取ります。

この選択肢が並んでいること自体が、現実を語っています。
回答しない人は必ず出ます。忙しい、意味が分からない、自分の担当ではないと思っている。

ここで「変更なし」を選ぶと、回答しないことが最も楽な選択肢になります。
結果として、点検したという記録だけが残り、権限は何も変わりません。

では「アクセス権の削除」にすればよいかというと、そこにも注意書きがあります。

[レビュー担当者が応答しない] 設定が [アクセスの削除] または [推奨事項の取得] に設定されていて、リソースへの結果の自動適用が有効になっている場合、レビュー担当者が応答できなかった場合、このリソースへのすべてのアクセスが取り消される可能性があります。

レビュー担当者が1人で、その人が休んでいたら。
そのリソースへの権限が、全員ぶん消えます。

どちらが正しいかは会社によります。
ただ、決めておかないと前者になり、決め方を間違えると後者が起きる、ということは押さえておくべきです。

数字で見ると、どのくらいの脅威か

11年連続で、10大脅威に入っている

IPAの「情報セキュリティ10大脅威 2026」で、「内部不正による情報漏えい等」は7位です。
2016年の初選出から、11年連続11回目の選出になります。

前年の「10大脅威 2025」では4位でした。
順位は下がっています。
ただ、11年のあいだ一度も消えていません。

2026年版で上位に来たのは、ランサム攻撃、サプライチェーンや委託先を狙った攻撃、そして初選出の「AIの利用をめぐるサイバーリスク」です。
外からの攻撃が目立つぶん順位が下がった、という読み方が妥当だと思います。

挙げられている手口は3つ

解説書は、手口を3つ挙げています。

◆アクセス権限の悪用付与された正当な権限を悪用し、組織の秘密情報の窃取や不正操作を行う。必要以上に高いアクセス権限が付与されていると、より重要度の高い情報にアクセスでき、より大きな被害が発生するおそれがある。また、複数人で端末やアカウントを共用している場合、誰が不正アクセスしたのか確認できない。

◆在職中に割り当てられたアカウントの悪用離職者が、在職中に割り当てられたアカウントを用いて、外部から社内システムや業務サーバー等に不正アクセスする。離職者の利用者IDやアクセス権を削除していないと、情報窃取や不正操作ができてしまう。

3つ目が、USBメモリーやメール、クラウドストレージ等による持ち出しです。

最初の2つは、この記事で扱ってきたことそのものです。
権限を渡しすぎていること。そして、辞めた人のIDが残っていること。

2025年の事例が2件、載っている

解説書は、事例も載せています。
1つ目は、口頭で伝えた例です。

工作機械メーカーの元社員は身分を隠した在日ロシア通商代表部の元職員に、道を尋ねられたことを機に飲食などの接待を受けていた。2024年11月と2025年2月に営業秘密を口頭で伝え、対価に総額70万円を受領していたとされ、元社員は不正競争防止法に違反したとして書類送検された。

口頭なので、システムのログには残りません。
権限の管理では防げない種類の話です。

2つ目が、この記事の主題に近いほうです。

2025年6月、ソフトバンクの委託先であるUFジャパンから約14万件の顧客情報流出の可能性があると発表された。UFジャパンの協力会社の元社員が、UFジャパンの事業所に不正に立ち入り、USBメモリーを情報管理端末に接続している監視カメラの映像が確認されており、顧客情報を持ち出した可能性がある

協力会社の、元社員。
自社の退職者だけを見ていても、届かない範囲があるということです。

ガイドラインにも、この点の脚注があります。

例えば、委託先の従業員の異動や退職によりアカウントの削除漏れ等が発生しないように、体制に変更が生じた場合は変更内容を委託元に報告する等が挙げられます。

委託先の人事異動を、契約で報告してもらう。
そこまで書いてある、ということです。

道具がなくても、表1枚でできる

退職のときに止めるものの一覧

ここまで、上位のライセンスが必要な機能をいくつか挙げてきました。
中小企業でそこまで用意できる会社は多くありません。

それでもできることがあります。
退職のときに止めるものの一覧を、表計算ソフト1枚で作ることです。

列は、これくらいで足ります。

サービス名
そのサービスの管理者は誰か
止め方（削除するのか、ロックするのか）
止める順番（本体を先に止めると同期が回らないものがある）
止めたあと、誰がどうやって確認するのか
最後に確認した日

3列目と4列目が、この記事で見てきたところです。
ログを残す必要があるサービスは、削除ではなくロックと書いておく。
連携しているサービスは、連携先を先に止めると書いておく。

そして、この表は退職者が出たときに作るものではありません。
平時に作っておくものです。
退職の連絡は、たいてい急に来ます。

棚卸も、表1枚でできる

在職者の権限の見直しも、考え方はそのまま使えます。
やることは3つです。

部署ごとに、いま誰が何にアクセスできるかの一覧を出す
その一覧を、部署の責任者に渡して、いる、いらないを付けてもらう
回答がなかった分をどう扱うかを、渡す前に決めて、伝えておく

半年に1回、あるいは異動の時期に1回。
大事なのは道具ではなく、3つ目です。

「回答がない場合は、権限を外します」と先に伝えてあるかどうかで、返ってくる率がまったく変わります。
そして、外す前に一度は電話をする。
Microsoftの注意書きは、そういうことを言っています。

まとめ

共有リンクには種類がある。「リンクを知っている全員」は認証を求めず、誰が開いたかは記録に残らない。Microsoftはこれを「転送可能で取り消し可能な秘密の鍵」と説明している
社内向けのリンクも、同じく転送可能な鍵である。転送を止められるのは「特定のユーザー」向けだけ
ただし、特定のユーザー向けリンクは、そのファイルを検索結果とCopilotに載せる。誰が見てよいかが決まって初めて載せられる、という設計である
アプリへの「許可」は、サインインとは別の行為で、一度押すと次からは聞かれない。管理者が押すと組織全体に及び、すべてのメールボックスへのフルアクセスや完全なユーザー偽装まで含まれ得る
退職と異動で不要になった利用者IDとアクセス権は、ただちに削除する。ただし、消すとログまで消えるシステムではロックする
ログインの統合と、アカウント停止の同期は別の機能である。順番を間違えると、連携先が止まらないまま残る
在職者の権限は、渡すときに期間を区切り、定期的に見直す。判断できるのは情報システムの担当者ではなく、本人か、その上長である
「内部不正による情報漏えい等」は10大脅威2026で7位。11年連続11回目の選出で、手口の1つは「在職中に割り当てられたアカウントの悪用」である

最後に1つ。
この記事で扱ったことは、どれも新しい製品を買う話ではありません。
すでに使っているサービスの設定と、社内で誰が判断するかを決めることだけです。

そして、どれも事故が起きてからでは間に合いません。
退職者のアカウントが使われたあと、共有リンクが流出したあとに、この作業をすることになります。

皆さんの会社で、いちばん長く見直されていない権限は、どこにあるでしょうか。

参考・引用元

Microsoft Learn

Microsoft「How shareable links work in OneDrive and SharePoint in Microsoft 365」 https://learn.microsoft.com/en-us/sharepoint/shareable-links-anyone-specific-people-organization
Microsoft「ユーザーと管理者の同意の概要」 https://learn.microsoft.com/ja-jp/entra/identity/enterprise-apps/user-admin-consent-overview
Microsoft「ライフサイクルワークフローとは」 https://learn.microsoft.com/ja-jp/entra/id-governance/what-are-lifecycle-workflows
Microsoft「Microsoft Entra ID でのアプリプロビジョニングとは」 https://learn.microsoft.com/ja-jp/entra/identity/app-provisioning/user-provisioning
Microsoft「Microsoft Entra ID でのアプリケーションプロビジョニングのしくみを理解する」 https://learn.microsoft.com/ja-jp/entra/identity/app-provisioning/how-provisioning-works
Microsoft「グループとアプリケーションのアクセスレビューを作成する」 https://learn.microsoft.com/ja-jp/entra/id-governance/create-access-review

Google

Google「Google ドライブのファイルを共有する」 https://support.google.com/drive/answer/2494822?hl=ja

IPA

IPA「組織における内部不正防止ガイドライン」（第5版は2022年4月改訂） https://www.ipa.go.jp/security/guide/insider.html
IPA「組織における内部不正防止ガイドライン」第5版（全136ページ） https://www.ipa.go.jp/security/guide/hjuojm00000055l0-att/ps6vr7000000jvcb.pdf
IPA「情報セキュリティ10大脅威 2026」（2026年1月29日公開、2026年5月21日最終更新） https://www.ipa.go.jp/security/10threats/10threats2026.html
IPA「情報セキュリティ10大脅威 2026 解説書［組織編］」（2026年3月、全64ページ） https://www.ipa.go.jp/security/10threats/omgdg50000008fi8-att/kaisetsu_2026_soshiki.pdf
IPA「情報セキュリティ10大脅威 2025」 https://www.ipa.go.jp/security/10threats/10threats2025.html

実務で使う書式について

この連載の内容を、社内でそのまま使える書式にまとめたものを、別のマガジンで公開しています。
規程のひな形、対応フロー、チェックシート、報告書式などです。

実務で使う書式・キット
https://note.com/yunta_fukurou/m/mfc25857fab40