「セキュリティ方針」と「運用」の間を埋める、人事イベントと連動したID管理とは？

会社として情報セキュリティ方針や各種ルールは整えたものの、現場のアカウント管理は相変わらずExcelの台帳とメールでの個別対応……そのギャップにもやもやしていませんか？

入社・異動・退職のたびに人事と情シスの間で情報が行き来し、退職者アカウントの削除漏れや棚卸し作業の負荷が“人力”に依存しているケースも少なくありません。

本記事では、会社として掲げる情報セキュリティ方針と、日々のアカウント運用のあいだにある溝を整理し、その橋渡し役としての「ID管理機能」の役割を解説します。

あわせて、人事データと連携したアカウント管理の考え方や、SmartHRのID管理機能でどのように「見える化」と運用改善を進められるかをご紹介します。

多くの企業では、すでに次のような文言を含む情報セキュリティ方針や規程が整備されています。

• 「情報資産を適切に管理し、機密性・完全性・可用性を確保する」
• 「アクセス権限は業務上必要な範囲に限定する」
• 「退職者・異動者のアクセス権限は速やかに見直す」

ISMSや各種ガイドラインを参考に、こうした方針を社内規程や自社サイトで公開している企業も多いでしょう。近年は「IT統制」や「情報セキュリティポリシー」をテーマとした解説記事やひな形も増え、特に上場企業・上場準備企業では、リスク管理や情報セキュリティへの取り組みを外部に説明することが求められています。

情報セキュリティやIT統制を考えるうえで、避けて通れないのが、「誰が、どの情報・システムにアクセスできる状態になっているか」を把握・管理できているか、という点です。

具体的には、次のような観点が挙げられます。

• 誰がどのシステムのアカウントを持っているのか
• それぞれのアカウントに、どのような権限が付与されているのか
• 入社・異動・退職といった人事イベントをきっかけに、権限が適切に見直されているか

これらはいずれも、アカウント管理の中核にあたるテーマです。

言い換えると、アカウント管理とは、業務に必要な範囲で「アクセス権限」という鍵を渡し、不要になったタイミングで確実に回収するための運用の仕組みだと捉えられます。

どれだけ情報セキュリティ方針やルールを整備していても、この「鍵の受け渡しと回収」が現場任せ・場当たり的なままでは、方針どおりにリスクを抑えることはできません。

多くの企業では、情報セキュリティ方針や各種ルール自体はすでに整備されています。情報セキュリティ方針と、現場のアカウント運用。本来はひと続きで考えるべきものですが、実際にはそのあいだにギャップが生まれているケースは少なくありません。

たとえば、

• 「情報セキュリティポリシーを策定しました」
• 「アクセス権限は最小権限の原則に基づいて付与します」

といった方針を掲げていても、現場では次のような判断が都度求められます。

• 入社時、部門や職種ごとに、どのSaaSのアカウントを作成すべきか
• 異動や兼務が発生したとき、どのタイミングで、その権限を見直すのか
• 退職時、誰がどの手順で、どのアカウントを削除するのか

こうした問いに対して、あらかじめ決まったルールや手順が整理されていない場合、対応はどうしても担当者の経験や記憶に頼った“場当たり的な運用”になりがちです。

このように、「方針」と「現場オペレーション」のあいだに具体的な“運用の型”が用意されていないことが、アカウント管理が属人化しやすい背景にあります。

そのギャップを埋めるためには、アカウント管理を単なる作業ではなく、情報セキュリティやガバナンスを支える仕組みの一部として捉え直すことが、最初の一歩になります。

アカウント管理の実態として、次のようなケースが多いのではないでしょうか？

入社時

• 人事が入社者一覧をまとめて情シスに連絡する。たまに連絡が遅れたり漏れたりして、直前になってアカウント作成を急ぎで依頼されることもある。
• 情シスは、各サービスごとに表計算ソフトで管理しているアカウント台帳に入社者を追加し、情報を更新する。
• 各SaaSの管理画面に個別にログインし、一つひとつ手作業でアカウントを作成する。

異動・兼務時

• 各部門や人事から「この人は来月から●●部に異動します」といった連絡が届く。
• どのシステムの権限を変えるべきか都度ヒアリングしつつ、「引き継ぎのために◯日後までは権限を残しておいてほしい」といったイレギュラーな依頼にも、個別対応せざるを得ない。

退職時

• 人事からの退職連絡をもとに、情シスが各システムで該当者を検索し、アカウントを削除する。
• 退職連絡が情シスに行き届いていなかった場合、退職者のアカウントが放置され、後から気づいて慌てて削除対応を行うこともある。

このように、入社・異動・退職に伴うアカウント運用が属人的な対応に依存していると、人事イベントの情報連携が漏れたり、アカウント台帳と各システムの実態が一致しなくなったりしがちです。こうした状況は、人事・情シスの双方にとって決して珍しいものではありません。

アカウント管理は、本来、人事・労務と情シスの双方にまたがるテーマです。一方で、部門をまたぐ“クロスファンクショナルな業務”であるがゆえに、運用が難しくなりやすい側面もあります。

まず人事・労務の立場でみると、本来業務だけでも手一杯な状況のなかで、入社・異動・退職といった人事イベントのたびに、すべてのアカウント運用を把握し、情シスへ漏れなく・タイムリーに情報を連携するのは、現実的にハードルが高い場面もあります。

一方、情シス側からすると、人事イベントの情報が自動的に共有される仕組みが無い限り、自分たちから情報を取りに行かなければ、人事情報を把握することができません。その結果、どうしても対応は後追いになりがちです。

このように、人事イベントの発生とアカウント管理の運用が、システムやプロセスとして結びついていない状態では、情報連携のタイミングや粒度にギャップが生まれるのは、ある意味で自然な結果とも言えます。

しかし、こうしたギャップが積み重なると、次のような状態を招きかねません。

• 退職者アカウントの削除漏れ
• 実態に合わない権限設定
• 誰がどのシステムを利用しているのか、全体像が把握できない状態

これは単なる運用の非効率にとどまらず、セキュリティ・コスト・ガバナンスの観点でも見過ごせない問題につながります。

ここまで見てきたように、属人的な対応を前提とした運用では、抜け漏れや不正確な情報管理が発生しやすくなります。

これを一歩進めるための考え方が、「人事イベント」を起点にアカウント管理を設計するという発想です。

• 「入社」イベントが起こったときに、どのアカウントを、誰が、いつまでに準備するのか
• 「異動」「兼務」「休職／復職」「退職」のそれぞれで、どの権限を見直すべきか

といった“人事イベントごとの型”を作るイメージです。

SaaSの利用が前提となった環境では、入社・異動・退職といった人事イベントをきっかけに、アクセス権限を見直していく考え方が重要とされています。「人が動いたらアカウントも動く」この状態を、担当者の判断や記憶に頼るのではなく、仕組みとしてどう実現するか。その出発点になるのが、人事イベントを起点にしたアカウント管理の設計です。

人事イベント起点にアカウント管理を考えるうえで、まず取り組みやすいのが、入社・異動・退職ごとに「確認すべきポイント」を整理しておくことです。

あらかじめチェック項目を用意しておくことで、担当者が変わっても同じ判断・対応ができる状態をつくりやすくなります。

以下は、その際に整理しておきたい観点の一例です。

入社

• 所属部門や役割ごとに「標準で付与するSaaS」が定義されているか
• 入社日までに必ず用意しておくべきアカウントは何か
• 管理者権限など、例外的な権限付与が必要な場合の判断基準や承認フローは整理されているか

異動・兼務

• 異動元の部門で、不要になるシステムや権限が明確になっているか
• 兼務や異動を重ねるなかで、権限が足し算され続けていないか（権限が肥大化していないか）
• 異動のタイミングで見直すべき承認権限やワークフローはどれか

退職

• 在籍ステータスの変更と、アカウント削除のタイミングが適切に紐づいているか
• 退職後も一定期間アクセス権限を残す必要がある場合、その例外条件や承認フローが定義されているか
• 個人アカウントで利用している外部サービスなど、見落としがちな対象はないか

このように、人事イベントごとにチェックポイントを整理し、一覧化しておくことで、「誰かの頭の中にしかない対応」を、組織として共有できるルールやプロセスへと変えていくことができます。

もう一つ重要なのが、入社・異動・退職といった人事イベントに、どのデータを起点としてアカウント管理を紐づけるかという視点です。

DXの文脈でも、複数の業務システムを連動させる際には、1つのデータベースを「正」と定め、その情報を基準に運用を設計する考え方が重視されています。バラバラの台帳や、システムごとに異なる前提を起点にするのではなく、「このデータを見れば判断できる」状態をつくるイメージです。

アカウント管理においては、人事システム上の従業員データベースを“マスター”として扱う発想が有効です。在籍状況や所属、役職、雇用区分といった情報が集約されているため、「誰が会社の業務に関わっているのか」を一元的に把握しやすくなります。

また、正社員だけでなく、アルバイトや業務委託など、雇用形態を問わず情報を管理できる点も、人事データベースを起点にする大きなメリットです。

こうした人事データを起点に、

• 在籍状況・所属・役職・雇用区分などの情報をもとに
• 各SaaSのアカウントや権限付与・変更・削除の条件を定義し
• 人事イベントが発生したタイミングで、その条件に沿って見直しを行う

という流れを整えることで、「人が動いたのにアカウントが動いていない」「一部の雇用区分だけ管理から漏れている」といった状態を減らしやすくなります。

このように、人事イベントごとの“運用の型”と、人事データベースという“マスター”を組み合わせて考えることが、日々のアカウント管理を無理なく改善しつつ、説明しやすく、再現性のある運用の土台をつくるうえで重要なポイントになります。

ここまで、人事イベントを起点にアカウント管理を考える重要性や、その運用の考え方を整理してきました。

ここからは、SmartHRのID管理機能が、こうしたアカウント管理の考え方をどのように実践に落とし込むのかご紹介します。

SmartHRのID管理機能では、SmartHR上の従業員情報と、連携している各サービスのアカウント情報を紐づけて管理できます。正社員に限らず、アルバイトや業務委託なども含めて管理できるため、「誰が、どのクラウドサービス（SaaS）のアカウントを持っているのか」を一覧で把握しやすくなります。

これは情報セキュリティやID管理の観点で、

• 「アクセス権限の全体像を把握できているか」
• 「どのリスクに対して、どのサービスが関わっているか」

を説明するうえでの土台になります。

SmartHRには、在籍状況・雇用形態・部署・役職などの人事情報が蓄積されています。これらの情報は、入社・異動・退職といった人事イベントのたびに更新され、常に最新の従業員データベースとして管理されます。

この従業員データベースと各サービスのアカウント割り当て条件を連動させることで、次のような見直しが必要そうなアカウントの「候補」を自動で洗い出し、可視化できます。

• 在籍中にもかかわらず、対象サービスのアカウントを持っていない従業員
  → 「本来作成すべきアカウントの候補」

• 異動・退職後も、アカウントが残っている可能性がある従業員
  → 「削除や権限見直しが必要なアカウントの候補」

こうした「候補」が一覧で見えることで、人の記憶や個別確認に頼らず、どこを確認・対応すべきか気づきやすい状態をつくることができます。

その結果として、

• 削除漏れに伴う不正アクセスや情報漏えいといったセキュリティリスクを抑えやすくなる
• 表計算ソフトで個別に管理していたアカウント管理台帳の更新負担を減らせる
• 人事と情シスのあいだで発生していた、煩雑な確認や調整作業を整理しやすくなる

といった点で、日々のアカウント運用を無理なく見直しやすくなります。

SmartHRのID管理機能と連携しているサービスについては、各サービスにログインせずSmartHR上でアカウントの作成・削除ができます。

これにより、一つひとつのサービスにログインしてアカウントを作成・削除する必要がなくなり、大幅な業務効率化を実現します。

情報セキュリティ方針やルールを整えていても、日々のアカウント管理が属人的な運用のままでは、その効果を十分に発揮できません。退職者アカウントの削除漏れや権限のつけっぱなしといった状態は、単なる現場の非効率にとどまらず、ガバナンスや内部統制の観点でも見過ごせないリスクにつながります。

こうしたギャップを埋めるには、入社・異動・退職といった人事イベントを起点に、「誰に、どのアカウントを付与し、いつ見直すのか」を一貫して考えられる仕組みづくりが欠かせません。人が動いたタイミングで、アカウントや権限も自然に見直される状態をつくることが重要です。

SmartHRのID管理機能は、人事データと各サービスのアカウント情報を紐づけることで、「誰がどのサービスを利用しているのか」や「見直しが必要そうなアカウントの候補」を把握しやすくする仕組みです。人事イベント起点のアカウント管理を考えるうえで、その土台を支援する一つの選択肢と言えるでしょう。

本記事をきっかけに、自社のアカウント管理が「セキュリティ方針ときちんとつながった運用になっているか？」という視点で、あらためて振り返ってみてはいかがでしょうか。