退職者のアカウントを放置しない、権限付与と自動失効の申請
手作業のアカウント発行は退職者の放置アカウントを生み、不正アクセスの温床になります。基幹システムの申請・承認フローで権限付与を統制する方法を解説します。
月曜の朝、新しいエンジニアが入社しました。昼にはメール、図面保管、在庫システム、経費精算の4つを使える状態が必要です。情シス担当はポータルに申請を起票し、上司にチャットで相談し、返事を待ち、前任者が使っていたグループの一覧をコピーして、4つの異なるシステムに手作業で追加します。半年後、その方は別部署へ異動しますが、古い権限はそのまま静かに残ります。さらに2年後、退職して社員証を返し、会社を出ていきます。アカウントが削除されるのは数週間、時には数か月後です。その休眠したログインIDの1つが、後日情報漏洩事故の調査報告書に登場する典型的な認証情報になります。
これは珍しい事例ではありません。退職や異動を済ませた方のアカウント、いわゆる放置アカウントは、内部統制やセキュリティ点検で繰り返し指摘される不正アクセスの代表例です。原因は悪意ではありません。権限付与が場当たりで、統制から外れ、退職という行為と切り離されていることです。申請と承認のワークフローを持つ基幹システムは、症状ではなく根本原因を解決します。
手作業の権限付与が監査で落ちる理由
アカウント発行は単純なIT作業に見えます。実際には、紙とチャットでは保持しきれない3つの要素を持つ内部統制の意思決定です。
1つ目は職務分掌です。新しい方のアクセス権は、疲れた情シス担当がテンプレートをクリックしただけで付与されるべきではありません。採用責任者からの申請、役割定義との照合、そのシステムに対して責任を持つ方の承認を経る必要があります。申請と承認と付与が別々の場所に散らばっていると、職務分掌はその日の最も早い手順に潰れます。
2つ目は監査証跡です。監査人が、退職した方が顧客マスタを閲覧する権限を誰が認可したかを問うたとき、18か月前に転送されたメールが答えになってはなりません。上場企業がJ-SOXの下で応える内部統制の枠組みは、何が申請され、誰が承認し、いつ発効し、何を付与したかを示す固定された記録を求めます。紙とスプレッドシートはこの問いに耐えられません。
3つ目は退職の瞬間です。誰かが会社を離れるとき、その方のアクセス権は直ちに見直され、削除されるべきです。しかし退職者は必ずしも情シスを綺麗に経由しません。退職届が人事に届き、最終の給与が走り、アカウントは誰の持ち物でもないシステムの中で忘れ去られます。放置アカウントが生きている期間が長いほど、それが裏口や認証情報の流用先、コンプライアンス指摘事項になるリスクは大きくなります。ここでのコストは時間では測れません。取り消せないその1件の事故で測るしかありません。
3つすべてに共通する欠陥は、権限付与に統制された申請・承認の経路がないことです。アクセス権が付与される前に申請が管理者とITの承認を経る単一の場所も、一時的あるいは退職に伴うアクセス権が予定された時点で取り消される仕組みも存在しません。
-> 関連:中堅製造業が走らせる60の承認ワークフローと、一つの基幹システムに集約するROI
統制されたアクセスワークフローが実際にどう見えるか
解決策は、後から追加する単体のID管理ツールではありません。経費や購買発注、休暇申請を既に動かしている基幹システムと同じ場所にある承認ワークフローです。実際のワークフローエンジンを読むと、今日本当に実装されていることと、正直言ってまだロードマップ上にあることが以下の通りです。
1件の申請を、役割と条件で回す
アクセス権の申請は1件の構造化されたフォームから始まります。採用責任者は対象システム、申請する役割やグループ、業務上の理由を選びます。システムごとに異なる項目を表示するよう設定できるため、図面保管への申請にはプロジェクトタグを、財務への申請にはコストセンターを尋ねる、といった切り替えが可能です。これは経費や休暇のワークフローが既に使っている動的フォームと同じ機能を、アクセス権に適用したものです。
申請が提出された瞬間、設定可能な承認ルートを流れます。重要なのは、このルーティングは今日実装され稼働しているということです。ワークフローエンジンは管理者を固定の名前ではなく申請者から解決するため、申請は自動的に申請者の直属の上司に届きます。その後、技術確認のためにITへ、業務承認のためにシステム責任者へと回ります。ルーティングは条件で分岐できます。標準的な役割は1人の承認者に、管理者権限のような特権役割は2人目の承認者や委員会に回ります。金額と同じ閾値の仕組みが感度に応じてここでも働き、読み取り専用の権限より高権限の付与にはより多く目を要求します。
この条件付きで役割を意識したルーティングこそ、メールで最も失敗しやすい部分です。管理者権限には2名の承認が必要と規程に書いておきながら、実際には最初にいた方が承認ボタンを押す、という運用になりがちです。ワークフローエンジンは、設定された承認者が実際に決定するまで申請が完了しないため、規程を毎回必ず適用します。
すべての申請がどこで詰まっているか一目で分かる
すべての申請がワークフローの中にあるため、進行中のアクセス付与の状態をすべて確認できます。どれが直属上司待ちか、どれがITのキューにあるか、どれが追加情報のために差し戻されたか。廊下を歩いて人を探す必要も、新人が必要なものを初日に揃えられるか推測する必要もありません。承認者ではなく申請を追いたい関係者、例えば入社対応の件数を追う情シスのリードは、承認の連鎖を乱すことなく申請の動きを追えます。
承認内容を固定スナップショットで証跡化
アクセス権の申請が承認されると、システムは決定内容を固定スナップショットとして記録します。対象システム、役割、申請者、承認者、タイムスタンプです。これが、監査人の問いに記憶から履歴を再構築せずに答える監査証跡です。今日システムが経費承認や発注承認を守っているのと同じスナップショットの規律を、アクセス権まで広げたものです。
承認者の不在でも止まらない安全な代理承認
管理職が出張中でも承認は止まりません。エンジンは安全な代理承認に対応しており、出張中の管理職は自身のキューを代理者に委ねられます。ただし高リスクの項目には必須の再承認経路が設定されます。アクセス権の申請が、顧客先に出向いている1人の都合で1週間止まることはありません。それはまさに、人々が手続き全体を迂回したくなる種類の遅延です。
自動書き戻しについて正直に
すべての購入者が尋ねるべき境界を、率直に述べます。
申請と承認の統制は今日実装され稼働しています。管理者がアクセス権を申請し、ワークフローが役割と条件によって適切な承認者へ申請を回し、決定とその完全な文脈が固定された監査スナップショットとして記録され、申請の移動中の状態がすべて見える、という統制の階層は実在し、動いています。
ロードマップにあり、まだ実装されていないのは、対象システム自身への自動書き戻しです。承認が完了した瞬間にメールディレクトリや図面保管、在庫システムへ自動でアカウントを作成し、予定された日付や退職イベントのタイミングで自動的にそのアカウントを取り消したり失効させたりすることは、これから進める作業であり、完成した作業ではありません。正確な表現はこうです。申請と承認の統制は現在稼働しており、アクセスシステムに対する自動プロビジョニングと予定失効は次のステップです。承認ボタンを押すだけで今日、すべての下流システムに自動的にアカウントを展開すると語る方は、過剰に売り込んでいます。
書き戻しがなくても、価値は具体的です。今日のギャップは通常、ITがアカウントを作成できないことではありません。誰がそれを認可したか証明できないこと、いつ失効すべきか分からないこと、そして削除の持ち主がいないことです。ワークフローは証明と持ち主、そしてスケジュールを閉じます。統制が整った後、各対象システムへの最終自動ステップはまとまった作業であり、それこそがロードマップが担う部分です。
事例:静岡の精密部品メーカー
自動車や産業機械のOEM各社に部品を供給する、静岡の精密部品メーカーを想像してください。社員数は約280名。本社と工場、営業拠点を持っています。情シスチームは小規模です。工場がシフト制で動くため入社対応は恒常的に発生し、設計部門と生産現場の間の異動も頻繁です。
従来の流れでは、新しい技術者のアクセス権は前任者のものがコピーされて付与されていました。異動のたびに特権が蓄積し、もう不要になった権限が減らされることはありませんでした。30年勤めたシニアエンジニアが定年退職したとき、図面保管の管理者権限を含むその方のアカウントは、退職が人事と給与を通過してもプロビジョニング解除のステップには届かず、2か月間生きたままでした。その四半期の内部統制レビューでの指摘は単刀直入でした。誰がどのアクセス権を承認したかを示す綺麗な記録を提出できず、退職者のアクセス権が期日通りに削除されたことを証明できませんでした。
統制された流れでは、すべてのアクセス付与がワークフローの中の申請として始まります。直属上司が申請を提出し、申請する役割に基づいて自動的に適切な承認者へ回り、決定は完全な文脈とともに固定されます。特権の付与は条件により2人目の承認者を要求するため、管理者権限が1回のクリックに依存することはありません。情シスは保留中の申請をすべて確認でき、入社日に間に合うようプロビジョニングを計画できます。
誰かが異動するとき、ワークフローはその変更を新しい申請として処理するため、古い役割に紐付いたアクセス権は黙って引き継がれるのではなく見直されます。誰かが退職するとき、退職に伴う申請は同じ経路を流れるため、アクセス権の取消は願いではなく統制された記録された事実になります。翌年の内部統制レビューでは、すべての付与に固定スナップショットがあり、すべての退職に綺麗な記録が見つかります。放置アカウントの指摘は戻ってきません。
280名規模のメーカーを想定したROIモデルでの見積もりは、削減時間だけを見れば控えめで、申請ごとの手作業調整を減らすことで年間約167時間です。本当の価値は、起こらなかったリスクにあります。定年退職したエンジニアの休眠した管理者ログインが、2か月間開いたまま放置されることはもうありません。回避できたその1件の事故は、削減された時間よりもはるかに大きい価値を持ちます。
ERPの横ではなく、ERPの中にあるべき理由
別のID管理ツールを買い込み、アクセス権を純粋なITの課題として扱う誘惑があります。それが放置アカウントが戻ってくる経緯です。アクセス権は他のどの承認決定とも同じ性質のものであり、経費や購買、休暇の監査規律を既に保持しているのと同じシステムの中にあるべきです。
アクセスのワークフローが基幹システムの中にあるとき、3つのことが揃います。承認ルートは経費承認と同じ管理者解決を使えるため、組織改編でルーティングが壊れません。監査スナップショットは内部統制の他の部分と同じ固定記録の規律を使うため、監査人は2つではなく1つの一貫した証跡を見ます。そして退職イベントは人事から始まり、同じワークフローエンジンを通り、噂ではなく統制された申請としてITに届きます。
より広いセキュリティの恩恵もあります。一度アクセスの付与が統制された申請になれば、同じワークフローの型を、特権昇格、プロジェクト限定の一時的管理者権限、データ持ち出しの承認へと拡張できます。これらは今日チャットで行われている申請と承認の決定であり、いずれも次の監査を待つ指摘事項です。権限付与から始めることで、その先の筋肉が鍛えられます。
よくある質問
誰かが退職したとき、自動的にアカウントは削除されますか?
退職に伴う申請は同じ統制された承認経路を流れるため、権限の取消は記録され、持ち主が明確な、監査スナップショットを持つ事実になります。予定された日付で対象システム内部のアカウントを削除する自動書き戻しはロードマップにあり、まだ実装されていません。正直な位置づけは、統制と記録は今日稼働しており、アクセスシステムへの最終自動ステップはこれから、ということです。
管理者権限に2名の承認を要求できますか?
はい。ここで条件付きルーティングが真価を発揮します。標準的な役割は1人の承認者へ、特権の付与は条件により2人目の承認者や委員会へ回せます。設定された承認者が実際に決定するまで申請が完了しないため、規則は毎回必ず適用されます。これは実装済みで稼働しています。
承認者が不在のときはどうなりますか?
ワークフローは安全な代理承認に対応しています。出張中の管理職はキューを代理者に委ねられます。ただし高リスクの項目には必須の再承認経路があります。アクセス権の申請が、顧客先に出向いている1人の都合で1週間止まることはありません。
既存のID基盤を置き換えることになりますか?
いいえ、置き換える必要もありません。ワークフローは申請と決定を統制し、スナップショットを記録します。承認された申請から既存のディレクトリやアクセスシステムへの接続は、ロードマップが担う書き戻しのステップです。Kikan System はこの統制と記録を今日提供し、最大2ユーザーまで無料、クレジットカード不要で放置アカウントの原因を取り除けます。重要なのは、プロビジョニングの前に統制された監査可能な管理を置くことであり、すでに動いているものを引き剥がすことではありません。
重要なポイント
放置アカウントはITの事故ではありません。それは、統制された申請と承認の経路なしに権限を付与した結果として予測可能に起こるものです。設定可能なワークフローを持つ基幹システムは根本原因を解決します。すべてのアクセス付与が申請として始まり、役割と条件によって適切な承認者へ回り、固定された監査スナップショットとして記録されます。対象システムへの自動プロビジョニングと予定失効はロードマップ上の次のステップです。統制と記録は今日稼働しており、それこそが次の休眠ログインが開いたまま放置されるのを止めるものです。
Kikan System で始める
退職者のアクセス権や統制されていない特権付与が点検で繰り返し指摘されているなら、Kikan System をご覧ください。申請と承認のワークフローは、アクセス権の申請を役割と条件によって適切な承認者へ回し、すべての決定を監査スナップショットとして固定し、プロビジョニングの進行を見える形で保持します。2ユーザーまで無料、カード不要のフリープランですぐに始められます。/#get-startedからご開始ください。
関連記事
現場の勝手なSaaS導入を防ぐ、シャドーIT対策
現場が勝手にSaaSを導入し企業データが散逸する問題を、基幹システムの申請・承認ワークフローで統制するシャドーIT対策の仕組みを実務に沿って解説します。
続きを読む→単価やBOMを勝手に変えさせない、マスタ変更の稟議化
単価、BOM、取引先マスタの勝手な変更が請求と在庫を壊します。基幹システムの承認ワークフローでマスタ変更を稟議化し、内部統制の証跡を残す方法を解説します。
続きを読む→初取引の顧客を勝手に登録させない、新規顧客開設の承認
新規顧客が審査なしでマスタに登録されると、与信リスクや詐欺リスクが入り込みます。基幹システムで新規顧客開設を承認ゲートで保護する仕組みを解説します。
続きを読む→