IGAとは？IDガバナンスの3つの視点である「統制」、「配信」、「監査」と実現方法をわかりやすく紹介
最終更新日:2025/11/18
最近、デジタルトランスフォーメーションやクラウドサービスの利用、リモートワークの普及など、私たちの働き方は大きく変わってきましたよね。
それに伴い、企業が管理しなければならないIDの数も爆発的に増えています。
社員、契約社員、アルバイト、さらには業務委託先やパートナー企業のIDまで。
これらのIDがいつ、誰によって作られ、どのシステムに、どんな権限でアクセスできるのか。
これをしっかり管理できていないと、情報漏洩や不正アクセスといった重大なセキュリティインシデントにつながりかねません。
そこで今、非常に注目を集めているのが「IGA」、すなわち「IDガバナンス」という考え方です。
IDガバナンスは、Identity Governance and Administrationの略称で、IDの管理である「Administration」と統制である「Governance」を指します。
今回は、このIGAについて、「統制」、「配信」、「監査」という3つの大切な視点で整理し、どうすればそれを実現できるのかを、皆さんと一緒に見ていきたいと思います。
IGAとは何か
まずは基本の確認から始めましょう。
IGA、いわゆるIDガバナンスとは、一言でいえば、「企業内のIDとアクセス権限を、適切に管理・統制するための仕組みやプロセス」のことです。
「ガバナンス」と聞くと、少し難しく感じるかもしれませんが、要は「IDに関するルールを決めて、それがしっかり守られているかを見守り、証明できるようにする活動全般」と捉えると分かりやすいかと思います。
単にIDを作成したり削除したりする「ID管理」から一歩進んで、その管理が「本当に正しいか」、「ルールに沿っているか」を重視する点が特徴です。
なぜIGAがこれほどまでに重要視されるのか
では、なぜ今、多くの企業がIGAに注目しているのでしょうか。
従来、ID管理は主に社内のActive Directoryなど、限られた範囲で行われてきました。
しかし、現代のビジネス環境は、この従来型の手法だけでは対応しきれないほど複雑になっています。
その背景には、いくつかの大きな環境変化があります。
セキュリティリスクの増大
最大の理由は、やはりセキュリティリスクの高まりです。
例えば、退職した社員のアカウントが、クラウドサービス上に残ったままになっていたらどうでしょう。
悪意があれば、そのIDを使って機密情報にアクセスできてしまいます。
これは「幽霊アカウント」とも呼ばれ、重大なセキュリティホールとなり得ます。
また、在職中の社員であっても、必要以上の強い権限などの特権IDを持っていると、操作ミスで重要なデータを消してしまったり、万が一アカウントが乗っ取られた際の被害が甚大になったり、あるいは内部不正につながるリスクも高まります。
IGAは、こうした「不要なID」や「過剰な権限」をなくし、セキュリティの穴を塞ぐために不可欠なのです。
実際に、多くの情報漏洩インシデントの原因を辿ると、不適切なアクセス権限の管理に行き着くケースは少なくありません。
コンプライアンス要件の強化
次に、コンプライアンス、つまり法令遵守の観点です。
日本国内ではJ-SOXと呼ばれる「内部統制報告制度」、グローバルでは米国のSOX法、ヨーロッパのGDPRと呼ばれる「一般データ保護規則」、さらには、金融のFISC安全対策基準や医療のガイドラインなど、業界固有の規制があります。
これらの法令や規制では、「誰が重要なデータにアクセスできるのか」を企業が適切に管理し、それを証明できることが求められます。
監査の際には、「このシステムの管理者権限を持っているのは誰ですか」、「その権限はいつ、誰が承認したものですか」、「退職者のアクセス権は適切に削除されていますか」といった質問に、迅速かつ正確に答えられなければなりません。
手作業やExcelでの管理では、この要求に応えるのは非常に困難です。
IGAは、まさにこの「証明責任」を果たすための基盤となります。
業務効率化と生産性の向上
IGAは「守り」のためだけではありません。
「攻め」の側面、つまり業務効率化にも大きく貢献します。
皆さんの会社では、新入社員が入社した時、IT部門が手作業で一つひとつアカウントを発行していませんか。
4月の入社シーズンともなれば、IT部門はその作業に追われ、他の重要な業務が後回しになってしまうかもしれません。
あるいは、異動のたびにアクセス権限の変更申請が紙やメールで行われ、承認に時間がかかっていないでしょうか。
その結果、異動した社員が、新しい部署で必要なシステムをすぐに使えず、業務が滞ってしまうこともあり得ます。
IGAの仕組みを導入すると、こうしたID管理業務の多くを自動化できます。
人事システムと連携し、入社や異動の情報をトリガーに必要なアカウントを自動で発行・変更するのです。
これにより、IT部門の負担が劇的に減るだけでなく、社員も必要なシステムに素早くアクセスできるようになり、生産性が向上するというわけです。
クラウドサービス利用の爆発的な増加
Microsoft365、Salesforce、Google Workspace、Slack、Zoomなど、便利なクラウドサービスを利用する企業が当たり前になりました。
DXの推進には欠かせないこれらのツールですが、ID管理の観点からは新たな課題を生んでいます。
クラウドサービスごとにIDとパスワードがバラバラだと、ユーザーはたくさんのパスワードを覚えなければならず、結果として簡単なパスワードを使い回したり、付箋に書いて貼ったりといった危険な行動につながりがちです。
管理者にとっても、クラウドサービスごとにアカウントを発行・停止する作業は煩雑です。
IGAは、社内システムとクラウドサービスに散らばったIDを一元的に管理するための「かなめ」の役割も担います。
これにより、クラウドサービスの利用を促進しつつ、セキュリティとガバナンスを確保することが可能になります。
IGAを実現する3つの核心的視点
さて、IGAの重要性をご理解いただけたところで、本題の「3つの視点」に入っていきましょう。
IGAの活動は、非常に多岐にわたりますが、大きく「統制」、「配信」、「監査」の3つに分けて考えると、非常に整理しやすくなります。
これらはIGAを支える三本柱とも言えるものです。
ルールを定め、守らせる「統制」という視点
これはIGAの「土台」となる部分です。
「誰に、どの権限を、どのようなルールで与えるか」を明確に定義し、そのルールが常に守られる状態を作ることを目指します。
いわば、ID管理の「法律」と「警察」の役割ですね。
IDが作られてから削除されるまでのライフサイクルを通じて、ルールに基づいた管理を行います。
ここでのポイントは、「あるべき姿」を定義することです。
例えば、「営業部の一般社員は、原則として顧客管理システムの閲覧権限のみを持つ」、「経理システムの振込承認権限は、経理部長職以上の者に限定する」といった具体的なルールを定めます。
また、「役員と経理部長が同一人物であってはならない」といった職務分掌のルール定義もここに含まれます。
必要な人に、必要な時に、必要な権限を与える「配信」という視点
「統制」で決めたルールに基づき、実際にIDと権限を「配る」のがこの視点です。
アドミニストレーションの部分とも言えます。
ただし、ただ配るだけではありません。
いかに「効率的」に、そして「安全」にユーザーの手元に届けるかが重要です。
「統制」が「あるべき姿」の定義であるのに対し、「配信」はそれを「現実のシステム」に反映させる実行部隊です。
ユーザーの利便性を高めつつ、管理の手間を減らす「自動化」や「連携」がキーワードとなります。
新入社員にアカウントを配る「プロビジョニング」や、ユーザーが使いやすくする「シングルサインオン」などが、この領域の代表例です。
誰が、いつ、何をしたかを証明する「監査」の視点
最後の視点は「監査」です。
「統制」で決めたルールが守られているか、そして、「配信」された権限が適切に使われているかをチェックし、記録する活動です。
万が一インシデントが発生した際の原因究明や、監査法人など外部への説明責任を果たすために、この視点が欠かせません。
「配信」によって権限が配られましたが、その後、異動したのに不要な権限が残っていないか、長期間使われていないアカウントはないか、などを定期的に見直す棚卸も、この監査の重要な活動の一つです。
定期的な健康診断のようなもの、とイメージすると良いかもしれません。
「統制」という視点の実現方法
では、この「統制」を具体的にどう実現していくか、もう少し掘り下げてみましょう。
IDガバナンスの土台である「統制」は、いくつかの重要な要素で成り立っています。
IDライフサイクル管理の確立
IDにも「一生」があります。
人が会社に入社して、異動や昇進を経験し、やがて退職するのと同じように、IDも作成され、変更され、最終的には停止・削除されます。
この一連の流れを「IDライフサイクル」と呼びます。
「統制」の観点では、このライフサイクル全体を、人事情報と連動させ、管理下に置くことが求められます。
入社
社員が入社した際、人事システムに情報が登録されたら、それをトリガーにして、必要なアカウントが自動的に作成され、初期パスワードが通知される。
これが理想的な流れです。
「統制」の観点では、この時、部署や役職に応じた最小限の初期権限が自動的に付与されるルールになっていることが重要です。
手作業での作成は、付与ミスや、逆に過剰な権限を与えてしまうリスク、そして何より作成漏れや遅延による業務開始の遅れを招きます。
異動や昇進
社員が営業部からマーケティング部に異動した場合、営業部で使っていたシステムの権限は不要になり、代わりにマーケティング用のツールへのアクセス権が必要になります。
この変更が、人事情報と連動して自動的に行われる仕組みが求められます。
手作業の申請と承認に頼っていると、異動後も前の部署の権限が残り続ける「権限の肥大化」が起こりがちです。
これは、内部不正のリスクや、ライセンスコストの無駄遣いにもつながります。
統制の観点からは、異動の際には旧権限は速やかに停止され、新権限が必要に応じて付与されるルールが適用されなければなりません。
退職
これが最も重要かもしれません。
退職日を迎えたら、即座に、あるいは定められた手順に従って、すべてのアカウントが停止または削除される必要があります。
退職者アカウントの放置は、不正アクセスの最大の温床であり、絶対に避けなければなりません。
特にクラウドサービスのアカウントは忘れられがちです。
人事システムの「退職」ステータスをトリガーに、関連するすべてのアカウントを一括で停止する自動化されたプロセスこそが、「統制」が効いている状態と言えます。
削除ではなく、まずは停止にすることで、データの保全や引き継ぎ漏れに対応する猶予を持たせるのが一般的です。
アクセス権限の適切な設計
IDライフサイクルと並んで重要なのが、アクセス権限そのものの設計です。
誰が何をしてよいかを決めるルール作りですね。
ロールベース・アクセス・コントロールの導入
「この人にはAシステムとBシステムの閲覧権限」、「あの人にはCシステムの更新権限」と、ユーザー単位で権限を管理するのは非常に煩雑です。
そこで、「営業部員」、「経理マネージャー」、「システム管理者」といった「ロール」を定義し、そのロールに対して必要な権限をセットで割り当てます。
そして、ユーザーにはその「ロール」を割り当てるのです。
こうすることで、異動の際も「営業部員ロール」を解除し、「経理マネージャーロール」を割り当てるだけで権限変更が完了します。
この仕組みを導入することが、統制の効いた権限管理の第一歩です。
最小権限の原則
これは、「ユーザーには、その業務を遂行するために本当に必要な、最小限の権限しか与えてはならない」というセキュリティの大原則です。
「とりあえず管理者権限をつけておこう」、「大は小を兼ねるで、全社共通の権限にしておこう」といった運用は、重大なリスクを招きます。
ロールを設計する際も、この最小権限の原則に立ち返り、本当にその権限が必要かを吟味することが「統制」です。
職務分掌の徹底
職務分掌とは、不正を防ぐために、一連の業務を複数の担当者で分担させることです。
例えば、「取引の申請」を行う人と、「取引の承認」を行う人が同一人物であってはなりません。
システム上の権限においても、この「申請権限」と「承認権限」を同時に一人のユーザーが持てないように制御する必要があります。
IGAでは、このような「相反する権限の組み合わせ」をあらかじめ定義しておき、もし違反する権限付与が行われそうになったらアラートを出す、といった「統制」が求められます。
ポリシーとルールの策定
最後に、これらを実現するための具体的なポリシーやルールを文書化し、標準化することも「統制」の重要な活動です。
例えば、パスワードポリシーを定め、それをシステムに強制的に適用させること。
また、ロールに含まれない例外的な権限が必要になった場合の、「アクセス申請と承認のプロセス」を標準化することも含まれます。
誰が申請し、誰が承認すれば、その権限を付与してよいか、そのワークフローを定義し、記録に残すことがガバナンスにつながります。
「配信」と視点の実現方法
次に、効率的かつ安全な「配信」の実現方法です。
「統制」で定めたルールを、いかにしてユーザーとシステムに届けるか、その具体的な手段を見ていきましょう。
ここでのキーワードは「自動化」と「利便性」です。
ID連携の活用
「配信」の観点で、ユーザーの利便性を劇的に向上させるのがID連携、特に「シングルサインオン」です。
シングルサインオンによる利便性向上
皆さんも、社内ポータルに一度ログインすれば、そこからメールや勤怠管理、経費精算システムなどに、再度パスワードを入力することなくアクセスできる経験はありませんか。
これがシングルサインオンです。
ユーザーは、覚えるべきパスワードが一つで済むため、パスワードの使い回しやパスワード忘れの問い合わせが激減します。
これにより、ユーザーの生産性が向上し、ITヘルプデスクの負担も軽減されます。
「配信」の観点では、これ以上ないほど効果的な施策と言えます。
SAMLやOpenID Connectの役割
このシングルサインオンを実現するために使われる技術的な「お約束事」が、SAMLやOpenID Connectといった認証連携の標準規格です。
難しい技術的な詳細は割愛しますが、これらの規格に対応したクラウドサービスであれば、企業のID管理基盤と連携し、安全にシングルサインオンを実現できます。
IGAソリューションの多くは、ユーザーの認証情報を管理し、他のサービスに提供するシステムやサービスである「IdP」としての機能を持っており、社内システムとクラウドサービスへの認証を「配信」する中心的な役割を果たします。
そして、これは利便性だけでなく、「統制」にも寄与します。
なぜなら、認証がIdPに一元化されることで、「退職者のアカウントを停止する」という操作をIdPで一度行うだけで、連携しているすべてのクラウドサービスへのログインも同時に防ぐことができるからです。
プロビジョニングの自動化
「配信」のもう一つの柱が、プロビジョニングと呼ばれるIDの作成・変更・削除の自動化です。
これは「統制」で紹介したIDライフサイクル管理を、実際にシステムに「配信」する機能です。
IGAツールと各システムとの連携
IGAツールが中心となり、人事システムからの情報を受け取ります。
「入社」の情報があれば、IGAツールはActive Directoryにアカウントを作成し、Microsoft365のライセンスを割り当て、Salesforceのアカウントを作成する、といった一連の作業を自動的に実行します。
このシステム間の連携には、SCIMと呼ばれるプロビジョニング用の標準規格が使われることも増えています。
これにより、IGAツールとクラウドサービスが直接連携し、ユーザー情報の「配信」をリアルタイムで行えるようになります。
手作業によるミスの削減と迅速な権限付与
自動化の最大のメリットは、手作業によるアカウントの作り忘れ、権限設定の間違い、退職者アカウントの消し忘れなどのミスを根本からなくせることです。
そして、もう一つの大きなメリットは「迅速性」です。
入社した社員が、初日から必要なシステムを使って業務を開始できる。
異動した社員が、異動の辞令が出たタイミングで新しい権限をスムーズに受け取れる。
これは、ビジネスのスピード感を損なわないためにも非常に重要です。
IDと権限という「業務の道具」を、必要な時に遅滞なく「配信」することこそが、この視点のゴールです。
セルフサービス機能の提供
「配信」の効率化には、ユーザー自身に一部の管理作業を行ってもらう「セルフサービス」という考え方もあります。
これは、IT部門の負荷を下げると同時に、ユーザーの待ち時間を減らす効果があります。
ユーザー自身によるパスワードリセット
ITヘルプデスクへの問い合わせで最も多いのが、「パスワードを忘れた」というものです。
この対応に、IT部門の貴重なリソースが割かれているのは非常にもったいないですよね。
そこで、ユーザーが自分で、あらかじめ登録しておいた秘密の質問や、スマートフォンへの通知などを利用して、パスワードをリセットできる仕組みを提供します。
これにより、ユーザーは夜間や休日でも即座に問題を解決でき、IT部門も本来の業務に集中できます。
ユーザーによるアクセス権限の申請
「統制」で紹介したロールベース・アクセス・コントロールで基本的な権限は配られますが、プロジェクトへの参加などで一時的に特定のシステムへのアクセスが必要になることもあります。
このような場合、ユーザーが専用のポータルから必要な権限を申請し、その申請が自動的にその人の上長や、システムの管理者に飛んで承認される、というワークフローも「セルフサービス」の一環です。
誰が、いつ、何を申請し、誰が承認したか、という記録が残るため、ガバナンスの観点からも非常に有効な「配信」方法です。
「監査」と視点の実現方法
最後に、チェック機能である「監査」です。
「統制」でルールを決め、「配信」でIDと権限を配りました。
しかし、「やりっぱなし」ではガバナンスは効きません。
ルール通りに運用されているか、不正な利用がされていないかを定期的にチェックし、その証拠を残す活動が不可欠です。
アクセスログの収集と分析
「監査」の基本は、記録を取ることです。
誰が、いつ、どのシステムにログインしたか。
どのファイルにアクセスしたか。
管理者権限でどのような操作を行ったか。
これらの操作履歴は、不正アクセスが疑われる際の追跡や、インシデント発生時の原因究明に不可欠な証拠となります。
「誰が」、「いつ」、「何に」、「何をしたか」の一元管理
問題は、これらのログが社内システム、クラウドサービス、ネットワーク機器など、様々な場所に散在していることです。
監査の観点では、これらのログを可能な限り一元的に収集し、相関的に分析できる状態にしておくことが望まれます。
例えば、「退職したはずのAさんのIDで、深夜にクラウドストレージへのアクセスログがある」といった異常は、ログが一元化されていなければ見つけることが困難です。
IGAソリューションは、こうしたIDに関するログの収集・管理機能を持つものや、SIEMと呼ばれるセキュリティ情報イベントを管理するログ分析専門のツールと連携する機能を持っています。
定期的なアクセスレビュー
これが「監査」の核心であり、J-SOX対応などで最も重要視される活動です。
この活動は「アクセスレビュー」と呼ばれます。
これは、「現在、誰が、どの権限を持っているか」の一覧表を作成し、その権限が本当に必要かを、権限を付与する責任者が定期的にレビューし、承認する活動です。
不要な権限の発見と削除
アクセスレビューの目的は、不要になった権限や、過剰な権限を発見し、削除することにあります。
「異動したBさんの権限が残ったままになっている」
「退職したCさんのアカウントが停止されていない」
「アルバイトのDさんに、なぜか管理者権限がついている」
こういった問題を、第三者の目でチェックし、是正するのです。
「配信」の自動化が進んでいれば、こうした問題は減っていきますが、ゼロにはなりません。
特に、自動化の対象外となっている古いシステムや、例外的な申請で付与された権限などは、この棚卸でチェックする必要があります。
マネージャーによる部下の権限レビューの仕組み化
アクセスレビューを、IT部門が全社員分行うのは不可能です。
そこで、IGAツールなどを使い、各部署のマネージャーに「あなたの部下の権限一覧です。内容を確認して、問題がなければ承認ボタンを押してください。不要な権限があれば、却下してください」といったレビュー依頼を自動的に送付する仕組みが有効です。
このレビュー作業が「いつ」、「誰によって」行われ、「承認」または「却下」されたか、その記録が残ることこそが、「監査」のゴールです。
この証跡があることで、監査法人に対して「我々は適切にアクセス権を管理しています」と胸を張って証明できるのです。
レポートと証跡の作成
監査活動の最後は、これらの結果をレポートとして出力し、証跡として保管することです。
監査法人や内部監査部門への提出資料の自動生成
「今月、退職した全ユーザーの一覧と、そのアカウントが停止された日時のリスト」
「経理システムに対する管理者権限を持つユーザーの一覧と、その権限が承認されたレビュー記録」
「職務分掌違反が検知された件数と、その対応状況レポート」
こういった資料を、監査のたびに手作業でExcelから作成するのは大変な労力です。
IGAソリューションは、これらの監査対応に必要なレポートを、ボタン一つで、あるいは定期的に自動生成する機能を持っています。
これにより、監査対応の工数を大幅に削減できます。
異常アクセスの検知とアラート
監査は、過去を振り返るだけではありません。
ログの分析と連携し、リアルタイムでの異常検知も含まれます。
「深夜に特権IDでのログインが発生した」
「短時間に大量のデータダウンロードが試みられた」
こういった「いつもと違う」動きを検知し、管理者にアラートを送ることで、インシデントの早期発見につなげることも、「監査」の重要な役割です。
IGA導入を成功させるためのステップ
では、これら「統制」、「配信」、「監査」を実現するIGAの仕組みを導入するには、どう進めればよいでしょうか。
IGAのプロジェクトは、関わるシステムや部門が多岐にわたるため、一筋縄ではいかないことも多いです。
成功のためには、いくつかのステップを順に踏んでいくことが重要です。
「現状把握」というステップ
何よりもまず、「今、どうなっているか」を知ることから始めます。
「敵を知り、己を知れば、百戦危うからず」です。
ID管理の「台帳」はどこにありますか。
人事システムですか、それともActive Directoryですか、あるいは各部門が作ったExcelリストでしょうか。
入社・異動・退職の際のプロセスは、誰が、何を見て、どのような作業をしていますか。
対象となるシステムはいくつあり、それぞれどのようにIDを管理していますか。
こうした現状把握を行うことで、自社の「課題」が明確になります。
「退職者アカウントの削除が、平均3ヶ月もかかっている」
「ID管理作業に、IT部門の2人がかりで毎月20時間も費やしている」
といった具体的な課題を洗い出すことが、次のステップにつながります。
「目的とスコープの明確化」というステップ
次に、IGAを導入して「何を解決したいのか」という目的を明確にします。
課題が「退職者アカウントの放置によるセキュリティリスク」であれば、最優先の目的は「人事システムと連携したデプロビジョニングの自動化」になります。
課題が「監査対応の工数増大」であれば、目的は「アクセスレビューの仕組み化」でしょう。
課題が「クラウドサービス利用の煩雑さ」であれば、「シングルサインオンの実現」が目的になります。
すべてを一度にやろうとすると、プロジェクトは複雑化し、失敗しがちです。
まずは最も優先度の高い目的を定め、対象となるシステムや部門を絞って「スモールスタート」することが成功の鍵です。
例えば、「まずはJ-SOX対象の最重要システムと、Microsoft365から始めよう」といった形です。
「ソリューションの選定」というステップ
目的とスコープが定まったら、それを実現するためのソリューションを選定します。
現在、IGAのソリューションは、自社でサーバーを構築する「オンプレミス型」と、クラウドサービスとして利用する「クラウド型」の2種類が主流です。
特にクラウドサービスの利用が多い現代の企業にとっては、クラウドサービスとの連携に強く、導入も迅速な「クラウド型」が選ばれるケースが増えています。
選定の際は、「目的とスコープの明確化」における目的を達成できる機能を持っているかをしっかり見極める必要があります。
また、将来的に対象システムを拡大していくことを見越した拡張性も考慮に入れると良いでしょう。
「導入と運用体制の構築」というステップ
ソリューションが決まったら、いよいよ導入です。
しかし、IGAはIT部門だけで導入できるものではありません。
IDの「正」の情報源である「人事部門」。
実際に権限のアクセスレビューを行う「業務部門のマネージャー」。
コンプライアンスの要件を定義する「内部統制室」や「法務部門」。
これらの関係部門をいかに巻き込み、協力体制を築けるかが、プロジェクトの成否を分けます。
特に「統制」の要であるロールの設計は、業務部門の協力なしには不可能です。
そして、IGAは「導入して終わり」ではありません。
新しいクラウドサービスを導入した、組織変更があった、など、ビジネスの変化に合わせてIGAのルールや設定も継続的に見直していく必要があります。
この「運用プロセス」を定着させ、誰がその責任を持つのかという体制を構築することこそが、IGA導入の最終ゴールと言えます。
IGAは「守り」と「攻め」の経営基盤である
いかがでしたでしょうか。
今回は、IGAについて、「統制」、「配信」、「監査」という3つの視点から、その重要性と実現方法をご紹介しました。
「統制」は、ID管理の「あるべき姿」を定義する土台です。
「配信」は、そのルールを「効率的」かつ「安全」に実行する仕組みです。
「監査」は、ルールが守られているかを「チェック」し、「証明」する活動です。
これら3つの歯車がしっかりとかみ合って初めて、IDガバナンスは機能します。
IGAの整備は、情報漏洩や不正アクセスから会社を守る「守り」の経営基盤であると同時に、シングルサインオンやプロビジョニングの自動化を通じて、社員の生産性を上げ、DXを推進する「攻め」の経営基盤でもあります。
ID管理は、現代のビジネスにおいて「水」や「空気」のようなインフラです。
普段は意識しませんが、汚染されたり、止まったりすると、企業活動に甚大な被害を及ぼします。
ぜひこの機会に、自社のID管理体制が、今の時代のスピードとリスクに対応できているか、見直してみてはいかがでしょうか。
