異動した人のAI権限はいつ切る？｜持ち越しを作らない

情報セキュリティの国際規格である ISO/IEC 27002 の2022年版は、アクセス権について、付与と変更と取消しをアクセス制御の方針に沿って行うことを求めています。そのうえで、昇進や降格、退職といった立場の変化があったときに権限を評価し、修正することを挙げています。名指しされているのは退職だけではありません。「前の部署のときに使っていたAIのツールに、異動した今も入れるようです」「兼務が3年続いた人の権限が、どこまで必要なのか誰も判断できません」——権限の棚卸しを始めた会社から、決まって出てくる声です。積み上がる原因は管理の甘さではありません。異動には、権限を止める理由を持つ人がどこにもいないことのほうが大きいのです。この記事では、異動で権限が持ち越されるのを止める運用の作り方を整理します。

退職の手続きはあるのに、異動の手続きが無い

退職のときには、たいていの会社に手順があります。最終出社日が決まり、貸与品の返却の一覧があり、アカウントを止める日が人事の側から流れてきます。止める理由がはっきりしているので、担当者は迷いません。

異動は違います。本人は社内に残り、明日も出社します。前の部署の仕事を完全に手放すとも限りません。止めるべき日が誰にも分からず、止めたことで業務が滞れば止めた側の責任になります。結果として、誰も止めないまま権限だけが増えていきます。

積み上がった権限は、それ単体では事故を起こしません。事故になるのは、別の出来事と重なったときです。端末が持ち出された、認証の情報が漏れた、退職が急に決まった。そのときに、本人が今の仕事で使う範囲を超えて開ける先が、どれだけ残っていたかが被害の大きさを決めます。

被害の話を抜きにしても、積み上がりは監査で問われます。権限が過剰であることは、それ自体が侵害の入口になるだけでなく、アクセスの制御が十分に働いていない証拠として指摘の対象になります。異動の多い会社ほど、この指摘は毎回ほとんど同じ文面で返ってきます。個別の事故ではなく、運用の設計が欠けている状態として読まれるためです。

規格とガイドラインは、異動を対象から外していない

権限の見直しを退職時だけの話にしないのは、珍しい考え方ではありません。ISO/IEC 27002 の2022年版でアクセス権を扱う管理策では、昇進や降格、退職といった変化があったときにアクセス権を評価し、修正することが求められています。あわせて、物理的なものも論理的なものも含めて、アクセス権を定期的にレビューすることが示されています。

取消しの速さについても触れられています。その人がもはやその情報資産へのアクセスを必要としなくなった場合、とくに組織を離れる際には速やかにアクセス権を取り消すべきだとされ、臨時の要員についても就業が終わった時点で速やかに取り消すことが挙げられています。

国内では、情報処理推進機構が組織における内部不正防止ガイドラインを公開しています。2022年4月に第5版が出され、10の観点のもとに33項目の対策が並べられています。改定の背景には、雇用の流動化にともなう退職者の増加や、働き方の変化によるリスクの増大が挙げられています。権限は人が離れるときではなく、役割が変わるときに見直すと読み替えると、実務に落ちやすくなります。

国内の法令に引き直すと、位置づけがはっきりします。個人情報保護法は事業者に安全管理措置を求めており、従業者の監督はその安全管理措置の一部を成すものとして整理されています。技術的な措置としては、アクセスの制御と、アクセスする人の識別および認証が挙げられています。役割が変わった人の権限がそのままであることは、アクセスの制御が役割と合っていない状態にあたります。

異動で権限が積み上がる3つの経路

積み上がり方には型があります。どこから増えるのかが分かると、止める場所も決まります。大きく分けると次の3つです。

• 本人に直接ついた権限：個別に申請して付与されたもの。付けた申請の記録は残るが、外す申請は誰も出さない
• 所属で自動的に付く権限：部署のグループに入ると付くもの。新しい部署のグループに追加されても、前のグループから外れないことがある
• 本人が作ったものに付く権限：自分で組んだ自動の処理や連携、発行した鍵。作った人が異動しても、動き続ける

3つのうち、いちばん手が回りにくいのは3つ目です。1つ目と2つ目は管理画面の一覧に出てきますが、本人が作ったものは作った本人しか存在を知らないことがあるからです。異動の前の面談で、自分が作って動いているものはありますか、と一度尋ねるだけで、かなりの数が表に出てきます。

3つに共通する考え方が、最小特権の原則です。必要最小限の人に、最低限の時間と権限だけを付与するという考え方で、特権的な権限の管理では基本に置かれます。異動で積み上がっていく状態は、このうち時間の部分だけが抜け落ちた形です。誰に付けるかと、何を付けるかは吟味されているのに、いつまで付けるのかが決められていません。

切る日を、発令日と着任日と引き継ぎ完了日のどこに置くか

異動の運用でいちばん効くのは、切る日をどこに置くかをあらかじめ決めておくことです。候補は3つあります。どれが正しいということはなく、選んだ日によって、誰が何を準備するのかが変わります。

切る日	向いている場面	先に準備しておくこと
発令日	扱う情報が重く、持ち越しを作りたくない場合	発令前に引き継ぎを終える。終わらない分は期限付きの例外として申請する
着任日	異動日がはっきりしていて、前後の業務が重ならない場合	人事の異動情報を権限の側へ流す経路を作っておく
引き継ぎ完了日	専門性が高く、後任の立ち上がりに時間がかかる場合	完了の定義と、完了を誰が宣言するのかを先に決める

いちばん失敗しやすいのは、引き継ぎ完了日を選びながら、完了の定義を決めていない場合です。完了が宣言されないまま半年が過ぎ、そのうち異動そのものが忘れられます。引き継ぎ完了日を選ぶなら、完了を宣言する人と、宣言が無いときの打ち切り日をセットで決める。ここが抜けると、この選択肢は事実上、切らないことと同じ意味になります。

3つのどれか1つに決めきれない場合は、権限の重さで分けます。個人データや取引の情報に触れる権限は発令日で切り、参照するだけの権限は引き継ぎ完了日まで残す、といった形です。重さで分ける方法には、決め方そのものを毎回議論しなくて済むという利点があります。分け方は権限の一覧に印として書き込んでおき、次の異動ではその印を見るだけにします。

残す権限には、必ず期限と失効の仕掛けを付ける

引き継ぎのために前の部署の権限を残すこと自体は、悪いことではありません。実際、アクセスの管理を扱う解説でも、グループを離れた後も後任を教育するためにアクセスを続ける必要がある場合が、例として挙げられています。問題になるのは、残した権限に終わりが無いことです。

残すと決めたら、同時に3つを書きます。いつまで残すのか、何のために残すのか、期限が来たら誰の判断も要らずに外れるのか。3つ目がとくに大事です。期限が来たら申請者に確認する運用にすると、確認が滞った分だけ権限が延びていきます。

延長を認める場合も、延長できる回数に上限を置きます。2回まで、それ以上は所属長の承認を要する、といった形です。期限の無い例外は、例外ではなく新しい常態になります。この言い方を運用の文書に書いておくと、現場でも判断がぶれにくくなります。

期限の日付は、四半期の末などの区切りに寄せると、棚卸しと重ねられます。ただし寄せすぎると、区切りの直前に期限が集中し、まとめて延長という判断に流れがちです。重い権限だけは区切りに寄せず、個別の日付で切るようにしておくと、この流れを避けられます。期限が集中する月については、誰が確認を担当するのかも先に決めておきます。

AIの権限は、画面に出ているものだけではない

ここまでは一般のシステムと同じ話です。AIのツールには、これに加えて止めにくいものがあります。会話の履歴、本人が書き足した指示の設定、つないだデータの参照先、発行した鍵、そして本人が組んだ自動の処理です。

会話の履歴は、権限を切っても残ります。前の部署で扱った内容が履歴の中に入っている場合、その履歴を本人が持ったまま新しい部署へ移ることになります。権限を切ることと、過去のやり取りを引き上げることは別の作業です。どちらをどこまでやるのかを、異動の手順に書き分けておきます。

つないだ参照先も同じです。前の部署の共有フォルダを参照するように設定したアシスタントが残っていると、フォルダの側の権限を切るまで参照が生き続けることがあります。止めるべきは本人の権限と、本人が作った仕掛けの両方です。次の3点は、異動の手順の中に項目として置いておきます。

• 会話の履歴とファイルの保存先を、異動のときにどう扱うかを先に決める
• 本人が書いた指示の設定や定型の文面は、部署の資産として引き継ぐか消すかを決める
• 本人が発行した鍵とつないだ参照先は、一覧にして棚卸しの対象に入れる

もう一つ、AIならではの持ち越しがあります。前の部署の資料を読み込ませて作った、検索用の索引です。索引は元の資料とは別のところに保管されることが多く、元のフォルダの権限を切っても、索引の側を参照できれば中身の断片は読めてしまいます。索引を作れる権限と、索引を参照できる権限を分けて数えておきます。

引き継ぎで先に渡すのは、権限ではなく問いの記録

異動の引き継ぎで権限だけを後任に付け替えると、後任は同じ場所に入れるようになっただけで、そこで何をしていたのかは分かりません。結果として前任者に連絡が行き、前任者の権限を残す理由がまた一つ増えます。

先に渡すべきなのは、前任者がそのツールに何を尋ねて、どの答えをどう使っていたのかという記録です。よく使っていた問いの型、参照させていた資料の範囲、出力をそのまま使ってよい場面と人が直していた場面。これが残っていれば、後任は権限を受け取った日から動けます。

この記録は、異動が決まってから作ろうとしても間に合いません。ふだんから、業務で繰り返し使う問いを部署の側に置いておく運用にしておきます。問いが個人の履歴の中にしか無い状態が、権限を切れなくしている原因であることは少なくありません。

記録の置き場は、部署の共有の場所にします。本人の履歴の中や個人のメモの中に置くと、異動と一緒に移動してしまうからです。書式も凝らないほうが続きます。問いの文、参照させた範囲、出てきた答えをどう扱ったか。この3つの列だけの一覧で足ります。月に一度、使った問いを書き足す時間を取るだけで、引き継ぎの下地ができていきます。

棚卸しの周期を、異動の周期に合わせる

定期的な棚卸しは、異動の取りこぼしを拾う最後の網です。周期の選び方には考え方があります。Entra ID が備えるアクセスレビューの機能では、毎週、毎月、四半期ごと、毎年といった周期で繰り返し実行するよう設定でき、レビューを担当する人は各回の開始時に通知される、と説明されています。

選ぶ基準は、扱う情報の重さと、異動が起きる頻度です。辞令が年に2回出る会社で棚卸しが年1回なら、最長で半年ぶんの持ち越しが生まれます。辞令の直後に1回、その中間に1回という置き方にすると、持ち越しが続く最長の期間が短くなります。

負荷を下げる工夫もあります。全員を毎回見るのではなく、この半年で所属が変わった人だけを対象にする回を作る。対象が絞られると、レビューする側も1件ずつ中身を見られます。全員を薄く見る棚卸しより、動いた人だけを厚く見る棚卸しのほうが持ち越しを拾えます。

特権にあたる権限の頻度は、自社で決める必要があります。ISO/IEC 27002 の2013年版には、特権的なアクセス権はより頻繁にレビューすべきだという記述がありましたが、2022年版ではこの明示の要件が外れ、特権的なアクセスは別の管理策で扱う形に整理されました。実務の解説では、月ごとあるいは四半期ごとに、部門の管理者、システムの管理者、監査の担当が確認する進め方が挙げられています。頻度を規格に探しても書かれていないので、自社の異動の周期から決めます。

誰がレビューするかで、結果が変わる

棚卸しをするとき、誰に判断させるのかは大きな分かれ目です。アクセスレビューの仕組みでは、指定したレビューの担当者、そのグループの所有者、そして本人による自己レビューのいずれかを選べる形になっています。

自己レビューは速く回りますが、本人はまだ使うかもしれないと答えがちです。所有者によるレビューは精度が上がりますが、所有者が誰なのか分からないグループが必ず出てきます。異動した人については、異動先の上長ではなく異動元の側に判断させると、切る判断が出やすくなります。異動先の上長は、前の部署で何を見ていたのかを知らないためです。

レビューに応答が無かった場合の既定の動作も、先に決めておきます。無応答を承認として扱うと棚卸しが形だけになり、無応答を拒否として扱うと業務が止まることがあります。重い権限は無応答なら拒否、軽い権限は無応答なら承認のうえで次回は必ず見る、といった分け方が現実的です。

レビューの結果が実際に反映される仕組みかどうかも、あらかじめ確かめておきます。アクセスレビューの機能では、担当者が拒否と答えたうえで結果を適用すると、グループのメンバーから実際に削除される、と説明されています。結果が自動で反映されない仕組みの場合は、反映を誰がいつ行うのかを工程として足します。判断だけが残って反映が残らないのが、形だけの棚卸しのいちばん多い姿です。

最終利用日という物差しを足す

必要かどうかを人が判断するのは、思っているより難しい作業です。そこで補助線になるのが、最後に使った日です。アクセスレビューの機能でも、一定の日数にわたって使われていない利用者だけをレビューの対象に含める作り方が示されています。

最終利用日は、本人の申告よりも強い材料になります。使うかもしれないと言われても、半年使っていないという事実があれば、いったん切って必要になったら申請し直す、という話にしやすくなります。切る側にとっても、判断の根拠を人の印象に頼らずに済みます。

ただし、この物差しだけで切ると事故が起きます。年に1回の決算や監査の時期にしか使わない権限は、最終利用日が必ず古くなるからです。使われていないことは、要らないことと同じではありません。頻度の低い業務で使う権限には、あらかじめ印を付けて対象から外しておきます。

最終利用日そのものが取れないツールもあります。その場合は、利用の記録を残す設定が入っているかを先に確かめ、入っていなければ棚卸しの対象から外して別の物差しを当てます。記録が取れないツールは、期限で切る運用に寄せるのが現実的です。半年ごとに全員の権限をいったん外し、必要な人が申請し直す形にしておけば、記録が無くても持ち越しは止まります。

例外を認めるときの置き方

どれだけ設計しても、例外は出ます。例外を認めないと決めると、現場は申請せずに使い続ける方向へ動きます。認めたうえで、認め方の形を決めておくほうが安全です。次の5つを順に踏みます。

5つのうち、抜けやすいのは3つ目です。期限が来たら自動で外れる形にしておかないと、期限は目安に変わります。仕組みの上で自動にできない場合は、期限の一覧を棚卸しの担当者が持ち、期限の当日に切る作業をあらかじめ予定へ入れておきます。

例外の一覧は、権限を管理する部署ではなく、異動を把握している部署が持つほうが機能します。権限の側は期限が来たことは分かりますが、その業務がまだ続いているのかどうかは分からないからです。一覧には、例外を認めた日、期限、理由、そして誰が認めたのかの4つを書きます。認めた人を書く欄があるだけで、安易な例外はかなり減ります。

手で回さないための仕組みと、その限界

異動のたびに手で権限を付け替えるやり方は続きません。所属や役職といった属性の条件を決めておき、条件に合う利用者を自動で追加したり削除したりする仕組みを使うのが基本になります。

ただし限界もはっきりしています。仕組みの解説でも、人事のデータが認証の基盤に入っていない場合や、グループを離れた後も後任の教育のためにアクセスが必要な場合には、自動の条件だけでは処理しきれないことが挙げられています。自動化は、例外を無くすためではなく、例外だけを人が見るために入れるものです。

仕組みに寄せすぎたときの失敗にも、型があります。

• 人事の異動情報が流れてこない：仕組みは動いているが、入力が来ないので何も起きない
• グループから外れても個別の権限が残る：自動の対象が所属だけで、個別に申請した分が外れない
• 本人が作った自動の処理が動き続ける：本人の権限が切れても、別の鍵で動いていて止まらない
• 自動で切れたことに誰も気づかない：業務が止まり、現場が別の抜け道を作る

仕組みを入れる前に、認可の考え方を運用の文書へ書いておくと迷いが減ります。特権的な権限の管理では、その権限が職務上いま必要かを定期的に判断し、付与する場合は認可の手続きを通し、認可が完了するまでは割り当てない、という進め方が基本に置かれます。異動の持ち越しは、認可の根拠が消えているのに割り当てだけが続いている状態です。この言い方にすると、切る判断は誰かを疑う話ではなくなります。

AIに切らせない。人が確認する範囲を先に決める

権限の棚卸しにAIを使いたくなる場面は多くあります。利用者の一覧と利用の記録を渡して、要らない権限を挙げさせる、といった使い方です。下ごしらえとしては有効ですが、線を1本引いておきます。

この権限は不要だ、という判定をAIに出させない。判定として出た一覧は、根拠が消えた形のまま回覧されるからです。使うのであれば、そう考えた理由を、参照した記録の日付や件数とあわせて書かせます。理由が書かれていれば、人はその理由の部分だけを確かめればよくなります。

人が確認する範囲も、先に決めます。全件を人が見るのは現実的ではないので、特権にあたる権限、外部とやり取りできる権限、個人データを含む参照先の3つは必ず人が見ると決めておく。範囲を決めておけば、件数が増えた月でも最低限が崩れません。

記録の残し方も、あわせて決めておきます。AIに挙げさせた一覧をそのまま議事の資料にすると、後から見たときに人が判断したのかAIが判断したのかが分かりません。一覧には、下ごしらえまでをAIが行った旨と、人が確認した範囲を1行で添えます。この1行があるだけで、翌年の監査での説明はずいぶん短く済みます。

切ったことを、どこに残すか

最後は、切った記録の残し方です。異動の運用が続くかどうかは、切ったことが残っているかで決まります。残っていないと、次の異動のときに同じ判断をもう一度することになります。

残す項目は多くありません。誰の、どの権限を、いつ、どの理由で切ったのか。そして、切らずに残したものについては、いつまで、なぜ残したのか。この2組があれば、次の棚卸しは前回との差分だけを見れば済みます。

記録の置き場は、権限の管理画面とは別にしておくと安全です。管理画面の履歴は保持の期間で消えることがあり、ツールを入れ替えると引き継げないためです。切った記録は、ツールの外側に残す。異動の多い時期を過ぎたあとで、持ち越しがどれだけ減ったのかを数えられるようにしておきます。

よくある質問

異動してすぐに切ると、業務が止まりませんか

止まる可能性がある場合は、切るのではなく期限を付けて残します。大事なのは、残すという判断が記録として残り、そこに期限が入っていることです。期限の無い温存と、期限付きの猶予は、半年後にまったく違う状態を生みます。期限が来たら自動で外れる形にしておけば、業務を止めずに持ち越しも作らずに済みます。

兼務の人はどう扱えばよいですか

兼務は、2つの役割ぶんの権限を持っているのが正しい状態です。問題になるのは、兼務が解けたあとも両方が残る場合です。兼務を始めるときに、どちらの権限が先に外れるのかと、その時期の見込みを書いておくと、解けたときに迷いません。書いていないと、兼務が解けたこと自体が権限の側へ伝わりません。

退職のときの片づけと、同じ手順でよいですか

重なる部分は多いものの、同じにはできません。退職ではすべてを止めればよいのに対し、異動では止める範囲を選ぶ必要があります。また、退職では本人に確認できない前提で進めますが、異動では本人が社内にいるため、作ったものや参照先を本人に挙げてもらえます。この違いを手順に反映させます。

まとめ

異動した人のAI権限を持ち越さないための要点は、止める理由が無い状態を、止める日を決めることで埋めることです。切る日を発令日、着任日、引き継ぎ完了日のどこに置くのかを先に決める。残す権限には期限と失効の仕掛けを付け、延長の回数に上限を置く。会話の履歴やつないだ参照先、本人が組んだ自動の処理まで棚卸しの対象に入れる。棚卸しの周期は異動の周期に合わせ、動いた人だけを厚く見る回を作る。AIには一覧の下ごしらえを任せてよいものの、不要だという判定はさせず、特権と外部への連携と個人データの3つは人が見る。まずは、直近の半年で所属が変わった人の一覧を作り、その人たちが今も入れる先を1つずつ数えるところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。