この記事のポイント
- RBAC(ロールベース・アクセス制御)の基本的な仕組みと、従来の権限管理との違い
- RBACが管理コスト削減、セキュリティ強化、内部統制、監査対応にどう貢献するかの具体的なメリット
- 他のアクセス制御モデル(ABAC、DAC、MAC)との違いと、自社に適したモデルの選び方
- RBAC導入を成功させるための、権限の棚卸しから運用保守までの具体的な5つのステップ
- RBACの効果を最大化し、人事異動にも強い体制を構築するワークフローシステムとの連携方法
はじめに:なぜ今、権限管理の見直しが「待ったなし」の経営課題なのか?
【概要】
企業のITシステムが複雑化し、扱う情報資産の価値が高まる現代において、情報セキュリティの確保は経営における最重要課題の一つです。特に、従業員による不正操作や設定ミスといった内部リスクを低減するためには、厳格かつ効率的なアクセス権限管理が不可欠です。しかし、多くの企業では、人事異動や組織変更のたびに、情報システム部門が手作業で煩雑な権限設定の変更に追われ、管理コストの増大や設定ミスによるセキュリティホールといった問題が常態化しています。
「異動した社員の古い権限が残ったままだ…」
「監査で『このデータに誰がアクセスできるのか』と問われても、即座に答えられない…」
「新入社員の権限設定だけで丸一日かかってしまった…」
このような課題は、もはや単なる現場の悩みではありません。内部統制の不備として、企業の信頼性を根底から揺るがしかねない重大な経営リスクです。
本記事では、この根深い課題を解決するためのスタンダードな手法として、世界中の企業で採用されている「RBAC(ロールベース・アクセス制御)」について、総務部門や内部監査部門の責任者様向けに、その基本から実践までを徹底的に解説します。RBACがなぜ内部統制を強化し、管理の効率化を実現できるのか、その本質を理解することで、貴社のセキュリティレベルを一段階上へと引き上げるための具体的な道筋が見えてくるはずです。
第1章 RBAC(ロールベース・アクセス制御)とは何か?
【概要】
RBAC(Role-Based Access Control)とは、システムを利用する「ユーザー」に直接アクセス権限を付与するのではなく、「ロール(Role)」という役割を仲介させることで権限を管理するアクセス制御モデルです。このシンプルな仕組みが、なぜこれほどまでに権限管理を効率化し、安全性を高めるのか、その基本構造から見ていきましょう。
1-1. RBACの基本構成:「ユーザー」「ロール」「パーミッション」
RBACは、以下の3つの要素の関係性を定義することで成り立っています。この3つを切り離して管理することが、RBACの核心です。
【表1】RBACを構成する3つの基本要素
要素 | 読み方 | 概要 | 具体例 |
User | ユーザー | システムを利用する従業員や関係者、一人ひとりの個人。 | 山田太郎さん、鈴木花子さん |
Role | ロール | 組織内での職務や役職に基づいた「役割」。パーミッションの集合体。 | 「営業担当」「経理マネージャー」「システム管理者」 |
Permission | パーミッション | 特定のリソースに対する具体的な操作権限。 | 「顧客情報の閲覧」「請求書の作成・編集」「サーバー設定の変更」 |
RBACの仕組みは、まず業務に必要なパーミッションをまとめた「ロール」を作成し、各ユーザーにはその人の職務に応じた「ロール」を割り当てます。これにより、ユーザーはロールを通じて間接的に権限を持つことになり、「誰が(User)」「どのような立場で(Role)」「何ができるのか(Permission)」という関係性が、非常に明確かつ体系的に管理できるようになるのです。
1-2. 従来の権限管理との根本的な違い
RBAC登場以前の伝統的な権限管理は、ユーザー個人に対して直接パーミッションを割り当てる「個別設定方式」が主流でした。この方式では、人事異動のたびに、担当者が一人ひとりの権限を一つひとつ手作業で変更する必要がありました。
【表2】RBACと従来の個別設定方式の比較
観点 | RBAC(ロールベース・アクセス制御) | 従来の個別設定方式 |
管理単位 | ロール(役割) | ユーザー(個人) |
設定の考え方 | 役割に必要な権限を定義し、ユーザーに役割を割り当てる(To-Role) | ユーザー個人に必要な権限を直接割り当てる(To-User) |
人事異動時の対応 | ユーザーが所属するロールを変更するだけで完了。 | 異動前後の権限を一つひとつ手作業で棚卸し・再設定する必要がある。 |
管理の複雑性 | シンプル。ロールの数で管理対象が決まるため、従業員数に比例しない。 | 複雑。従業員数が増えるほど、設定の組み合わせが爆発的に増加する。 |
設定ミスのリスク | 低い。役割ベースで一貫した権限が付与されるため、ミスが起こりにくい。 | 高い。手作業のため、権限の付与漏れや過剰付与が発生しやすい。 |
このように、RBACは管理の対象を「人」から「役割」へと転換させることで、権限管理にまつわる煩雑さとリスクを根本から解決するアプローチなのです。
第2章 なぜRBACが内部統制の鍵となるのか?ビジネスにもたらす4つの戦略的メリット
【概要】
RBACの導入は、単なるIT部門の業務効率化に留まりません。それは、企業のセキュリティポリシーを具体的な形でシステムに落とし込み、実効性のある内部統制を実現するための経営基盤そのものです。ここでは、RBACがビジネスにもたらす4つの戦略的なメリットを、総務・監査責任者の視点から解説します。
メリット1:管理コストの劇的な削減とIT部門の生産性向上
課題: 人事異動が発表されるたびに、情報システム部門は深夜までの権限設定作業に追われる。本来注力すべき戦略的なIT企画が後回しになってしまう。
RBACによる解決策:
RBAC環境では、人事異動や組織変更が発生した際の対応が劇的に簡素化されます。例えば、「営業部の山田さんが経理部に異動する」というケースでは、管理者は山田さんの所属ロールを「営業担当」から「経理担当」に変更するだけで権限の更新が完了します。これにより、管理工数は大幅に削減され、より付加価値の高い業務にリソースを集中させることが可能になります。
メリット2:「最小権限の原則」による内部不正・情報漏洩リスクの低減
課題: 異動後も過去の部署のデータにアクセスできてしまったり、必要以上の権限が付与されていたりすることで、意図しない情報漏洩や不正操作のリスクが高まっている。
RBACによる解決策:
RBACは、情報セキュリティの基本原則である「最小権限の原則(Principle of Least Privilege)」を徹底するための強力なツールです。これは、「ユーザーには、その業務を遂行するために必要最小限の権限のみを与えるべき」という考え方です。RBACのロール設計プロセスでは、不要な権限が偶発的に付与されることが構造的に防止され、内部不正のリスクや、万が一のアカウント乗っ取り時の被害を最小限に食い止めます。
メリット3:「職務分掌」の徹底によるガバナンス強化
課題: 申請業務と承認業務を一人の担当者が行えるなど、職務の分離ができておらず、不正の温床となる可能性がある。
RBACによる解決策:
RBACは、健全な企業統治に不可欠な「職務分掌(SoD: Segregation of Duties)」をシステム上で明確に実現します。例えば、「購買申請」を行うパーミッションを持つ「申請担当」ロールと、「購買承認」を行うパーミッションを持つ「承認マネージャー」ロールを明確に分離し、一人のユーザーに同時割り当てを禁止することで、相互牽制が働き、不正を防止できます。
メリット4:監査対応の迅速化と説明責任の担保
課題: 内部監査やJ-SOX監査で、「この機密情報にアクセスできる全ユーザーのリストを提出してください」と求められても、各システムの設定を個別に確認する必要があり、膨大な時間がかかる。
RBACによる解決策:
RBAC環境では、監査対応の負荷が大幅に軽減されます。「誰がどの権限を持っているか」がロールによって一元的に可視化されているため、監査人からの要求に対し、「該当パーミッションを持つロール」と「そのロールに所属するユーザー」の一覧をシステムから出力するだけで、権限の正当性を迅速かつ客観的に証明できます。
【この章のまとめ】RBACがもたらす4つのメリット
メリット | 課題(Before) | RBACによる解決策(After) |
コスト削減 | 人事異動のたびに、各システムで手作業の権限設定が発生し、工数が膨大に。 | ロールを変更するだけで権限更新が完了。管理工数を90%以上削減可能。 |
セキュリティ強化 | 不要・過剰な権限が付与されやすく、内部不正や情報漏洩のリスクが高い。 | 「最小権限の原則」を徹底。不要な権限を構造的に排除し、リスクを低減。 |
ガバナンス強化 | 職務分掌が曖昧で、担当者による不正な操作をチェックする仕組みがない。 | 「申請」と「承認」のロールを分離するなど、職務分掌をシステムで強制。 |
監査対応効率化 | 「誰がアクセスできるか」の証明に、各個人の設定確認が必要で時間がかかる。 | 「ロール」単位で権限を証明でき、監査時に迅速かつ正確な情報提供が可能。 |
関連記事
- 内部統制とは?目的・構成要素からJ-SOXの評価までを分かりやすく解説
- J-SOX法で求められるIT統制とは?3点セット作成・評価のポイントを解説
- 証跡管理とは?ワークフローで実現する監査対応とコンプライアンス強化のポイント
第3章 アクセス制御モデルの全体像:RBAC、ABAC、DAC、MACの違いとは?
【概要】
現代の企業では、平均して10以上のSaaS(クラウドサービス)を導入していると言われており、その一つひとつで部署や役職に基づいたユーザー管理・権限管理が必要です。この 「SaaSスプロール」 は、情報システム部門の管理業務を非常に煩雑にし、セキュリティリスクの温床となります。
理想的な最終形態は、入退社といった人事情報をマスターデータとして、すべてのシステムの権限管理を自動で連携させることです。さらには、機能が重複するツール自体を整理・統合し、管理対象を減らすことも重要です。
このような複雑な環境を統制するための第一歩として、まず自社に最適な「アクセス制御の考え方(モデル)」を理解することが不可欠です。アクセス制御の手法はRBACだけではありません。ここでは主要なモデルを比較し、なぜ多くの企業にとってRBACが現実的な選択肢となるのかを解説します。
自社に最適なモデルはどれか?各モデルの比較と選定のポイント
アクセス制御には、RBACの他に主に3つのモデルが存在します。それぞれの特徴を理解し、自社の組織規模、セキュリティ要件、管理体制に合ったモデルを選ぶことが重要です。
【表3】主要アクセス制御モデルの比較
モデル名 | 制御の考え方 | 管理単位 | メリット | デメリット | 最適な環境 |
RBAC (ロールベース) | 役割に基づいてアクセスを制御 | ロール | 管理効率とセキュリティのバランスに優れる。多くの企業で導入実績が豊富。 | 複雑なアクセスルール(例:時間や場所)には対応しにくい。 | ほとんどの一般企業。職務が明確に定義されている組織。 |
ABAC (属性ベース) | ユーザーやリソースの属性の組み合わせで動的にアクセスを判断 | 属性 (Attribute) | 「役職が部長」かつ「勤務時間内」かつ「社内ネットワークから」といった、非常に柔軟で詳細な制御が可能。 | ポリシーの設計・管理が非常に複雑。高度な専門知識が必要。 | ゼロトラストセキュリティを目指す大企業や、動的なアクセス制御が必須のクラウドネイティブな環境。 |
DAC (任意アクセス制御) | データ所有者が自分の判断でアクセス権を付与 | ユーザー個人 | 柔軟性が高く、ユーザー自身で権限を管理できるため、小規模なチームでのファイル共有などに便利。 | 権限が拡散しやすく、一元管理が困難。情報システム部門が統制を失いやすい。 | 研究開発部門や小規模なプロジェクトチームなど、限定的な範囲。 |
MAC (強制アクセス制御) | 管理者が定めた厳格なポリシーに基づき、システムが強制的にアクセスを制御 | セキュリティラベル | 非常に堅牢で、最高レベルの機密性を確保できる。 | 柔軟性が極めて低く、ユーザーの利便性を損なう。管理が厳格すぎる。 | 軍事、政府機関、金融機関の中枢システムなど、最高レベルの機密性が求められる組織。 |
選定のポイント:なぜRBACが標準なのか?
上の表からわかるように、DACは統制が弱すぎ、MACは厳格すぎてほとんどの企業には不向きです。実質的な選択肢はRBACとABACになります。ABACは非常に強力ですが、導入・運用のハードルが極めて高いため、ほとんどの企業にとっては、まずRBACを導入して権限管理の基盤を確立し、将来的に必要性が生じればABACを補完的に導入する、という段階的なアプローチが最も現実的で効果的な選択肢と言えるでしょう。
関連記事
- SaaSの乱立(SaaSスプロール)が招く課題とは?解決策とコスト削減の方法を解説
- 統合型ワークフローシステムとは?選び方・比較検討方法まで詳細解説!【2025年最新版】
第4章 RBAC導入を成功に導く実践的5ステップ
【概要】
RBACの導入は、単なるツールの導入プロジェクトではありません。それは、組織全体の業務と権限のあり方を再定義する改革プロジェクトです。ここでは、導入を成功に導くための具体的な5つのステップを、実践的なポイントと共に解説します。
【表4】RBAC導入・実践の5ステップ概要
ステップ | 名称 | 主な活動(WHAT) | 成功のポイント(HOW) |
1 | 現状分析 | 既存の全権限を洗い出す「権限の棚卸し」と、業務に必要な権限のヒアリング。 | ツールを活用して効率化し、必ず現場の業務担当者を巻き込む。 |
2 | ロール設計 | 業務内容や職責に基づき、最適な粒度の「ロール」を定義する。 | 「部署×役職」を基本とし、細かすぎず粗すぎない粒度を見つける。「ロール爆発」を避ける。 |
3 | パーミッション割り当て | 設計したロールに、「最小権限の原則」に基づき、具体的な操作権限を割り当てる。 | 「ホワイトリスト方式」(必要な権限を足していく)で考え、過剰な権限付与を防ぐ。 |
4 | ユーザー割り当て | 全従業員を、対応する一つまたは複数のロールに割り当てる。 | 兼務者は複数ロールを割り当てる。例外的な業務は「個別ロール」として厳格に管理する。 |
5 | 運用・保守 | ビジネスの変化に合わせ、ロールや権限を定期的に見直すメンテナンス体制を構築する。 | 年に一度の棚卸しを制度化し、各ロールの責任者(オーナー)を明確にする。 |
ステップ1:【現状分析】権限の「棚卸し」と業務要件の整理
RBAC導入の成否は、この最初のステップで8割が決まると言っても過言ではありません。既存の全システムで「誰が、何に、どんな権限を持つか」を洗い出し、同時に現場ヒアリングを通じて「業務に必要な真の権限」を整理します。
ステップ2:【ロール設計】「ロール爆発」を防ぐ最適な粒度の見つけ方
現状分析を基に、組織の職務に沿ったロールを設計します。ここでの最重要ポイントは「ロールの粒度」です。細かすぎると管理が煩雑になる「ロール爆発」を招き、大雑把すぎると最小権限の原則が崩れます。「部署 × 役職」を基本に、自社に合った最適な粒度を見つけることが重要です。
ステップ3:【パーミッション割り当て】「最小権限の原則」を具体化する
設計した各ロールに、ステップ1で定義した「業務に必要な最小限の権限」をパーミッションとして割り当てます。「何もできない状態から、必要なものだけを足していく(ホワイトリスト方式)」で考えることが、過剰な権限付与を防ぐ鍵です。
ステップ4:【ユーザー割り当て】兼務や例外ケースへの対応
定義が完了したロールに、全従業員を割り当てます。一人のユーザーが複数の業務を兼務している場合は、複数のロールを割り当てることができます。どうしても既存のロールに当てはまらない例外的な業務は、厳格な承認プロセスを経て「個別ロール」を作成することも許容します。
ステップ5:【運用・保守】形骸化させないための継続的なメンテナンス体制
RBACの運用は、一度導入して終わりではありません。ビジネスの変化に合わせて、継続的に見直しを行う仕組みを構築することが不可欠です。最低でも年に1回、全ロールの定義と権限をレビューする「権限棚卸し」を制度化し、各ロールの責任者を業務部門に置くことで、形骸化を防ぎます。
関連記事
- 職務権限規程の見直しポイント|ワークフロー導入を機に最適化するサンプル付きガイド
- ワークフロー導入の第一歩|失敗しないための業務プロセスの棚卸し方法
第5章 RBACを形骸化させないための高度な運用テクニック
【概要】
基本的なRBACの導入に成功したら、次はその効果を維持し、さらに高めるための高度な運用テクニックを取り入れていきましょう。これらの手法は、特に組織規模が大きい企業や、変化の速いビジネス環境において有効です。
【表5】RBACの高度な運用テクニック
テクニック | 課題(Before) | 解決策(After) |
ロールの階層化 | 役職ごとに共通の権限が多く、設定が重複し非効率。 | ロールに親子関係を持たせ、権限を「継承」させることで、共通権限を一元管理し、メンテナンス性を向上させる。 |
動的ルール | プロジェクトへの一時参加など、恒久的でない権限付与のたびにロールを作成するのは手間。 | 特定の期間や条件に基づき、ロールを自動で割り当て・剥奪する。不要な権限の残存リスクをなくす。 |
棚卸しの自動化 | 年に一度の権限棚卸しが、担当者にとって大きな手作業の負担となっている。 | 未使用の権限を自動でリストアップしたり、レビュー依頼をワークフローで自動化したりして、棚卸しプロセスを効率化する。 |
5-1. ロールの階層化:継承を利用した効率的な管理
ロールに親子関係を持たせ、子ロールが親ロールの権限を自動的に「継承」する仕組みです。これにより、共通の権限は親ロールで一元管理できるため、設定の重複がなくなり、メンテナンス性が大幅に向上します。
5-2. 動的ルールの活用:一時的な権限付与への対応
「動的ルール」や「一時的なロール割り当て」機能を活用し、特定の条件(例:プロジェクト期間中、休暇代理期間中)を満たす間だけ、ユーザーにロールを自動的に割り当てる仕組みです。期間が終了すれば権限は自動的に剥奪されるため、セキュアで柔軟な権限管理が実現できます。
5-3. 定期的な棚卸しの自動化
棚卸しプロセスを支援するツールや機能を活用し、可能な限り自動化します。「過去1年間使用されていないパーミッション」を自動でリストアップしたり、各ロールのオーナーへのレビュー依頼をワークフローで自動化したりすることで、棚卸しの負担を大幅に軽減できます。
第6章 ワークフローシステムがRBACの運用効果を最大化する理由
【概要】
RBACはそれ単体でも強力なコンセプトですが、その真価はワークフローシステムと連携することで最大限に発揮されます。なぜなら、企業の「人」と「情報」の動きは、日々の業務プロセス(ワークフロー)と密接に連動しているからです。ここでは、統合型ワークフローシステムがRBACの運用をいかに効率化し、堅牢にするかを解説します。
6-1. 人事情報との連携による権限の自動更新
RBAC運用の最大の負担は、入社・異動・退職といった人事イベントへの追従です。高機能なワークフローシステムは、人事システムと連携し、このプロセスを完全に自動化します。人事システムの情報が更新されると、旧部署のロールが自動的に剥奪され、新部署のロールが自動的に付与されるため、情報システム部門は権限設定作業から解放され、ヒューマンエラーのリスクはゼロになります。
6-2. 組織変更の予約機能とシミュレーション
大規模な組織変更も、先進的なワークフローシステムなら円滑に進められます。未来の日付で組織変更を予約登録し、指定日時になると自動的にシステム全体に反映させることができます。また、変更を適用する前に、影響範囲をシミュレーションし、意図しない影響がないか事前に確認することも可能です。
6-3. 文書ライフサイクル全体を通じた一貫した権限管理
企業の重要情報は、稟議書や契約書といった「文書」の形で存在します。統合型ワークフローシステムは、RBACに基づいて、文書が生まれてから廃棄されるまでの一生(ライフサイクル)のすべてのステージで一貫した権限管理を適用し、企業のガバナンスを飛躍的に向上させます。
【表6】ワークフロー連携によるRBACの強化
連携ポイント | 課題(Before) | 解決策(After) |
人事連携 | 人事異動のたびに手作業で権限を変更。ミスや漏れが発生。 | 人事情報と同期し、権限を全自動で更新。管理コストとリスクがゼロに。 |
組織変更対応 | 組織変更当日に、大量の権限設定変更に追われる。 | 組織変更を予約し、事前に影響範囲をシミュレーション。計画的な移行が可能。 |
文書管理 | 承認プロセスと文書の保管場所で、権限設定がバラバラ。 | 文書のライフサイクル全体で一貫した権限管理を適用し、情報統制を徹底。 |
関連記事
- 人事異動に強いワークフローシステムとは?総務・IT部門の「見えないコスト」を激減させる方法
- 文書ライフサイクル管理とは?ワークフローで実現する堅牢な内部統制システム構築ガイド
結論:RBACは守りから攻めへ、事業成長を支える経営基盤
本記事では、RBACが、単なるIT部門の管理業務を効率化するためのテクニックではなく、企業のセキュリティポリシーを具体的な形でシステムに落とし込み、実効性のある内部統制を実現するための経営基盤であることを解説してきました。
導入には緻密な計画と全社的な協力が必要ですが、それによって得られるメリットは計り知れません。
- 守りの側面: 内部不正や情報漏洩のリスクを低減し、コンプライアンス要件や監査に的確に対応することで、企業の信頼を守ります。
- 攻めの側面: 権限管理に費やしていたリソースをDX推進などの戦略的な取り組みへとシフトさせ、組織全体の生産性を向上させます。
RBACは、もはや「守り」のためだけの投資ではありません。それは、企業のデジタルトランスフォーメーションを加速させ、持続的な事業成長を支える「攻め」の経営基盤なのです。
貴社の内部統制、形骸化していませんか? RBACの思想をネイティブに実装し、人事情報と連携した動的な権限管理を実現するジュガールワークフローは、形骸化しない内部統制の構築を強力に支援します。文書のライフサイクル全体を通じて、適切な人に適切な権限を自動で付与し、企業の重要資産を保護することで、総務・IT部門の負担を軽減し、全社の生産性を向上させます。
RBAC(ロールベース・アクセス制御)に関する、よくある質問(FAQ)
A1: まずは「ステップ1:現状分析」から始めることが最も重要です。特に、影響範囲が限定的で、業務内容が明確な一部門(例:経理部や総務部)をパイロット部門として選定し、スモールスタートで権限の棚卸しとロール設計を行ってみることをお勧めします。そこで得られた知見を基に、全社展開の計画を立てるのが成功への近道です。
A2: 一概には言えませんが、目安として「従業員数の1/3〜1/2程度」に収まることが多いです。ただし、重要なのは数そのものではなく、管理できる範囲に収まっているか、そして最小権限の原則が守られているか、というバランスです。ロールの数が多すぎて管理しきれない「ロール爆発」の状態に陥るよりは、多少粒度が粗くても管理可能な数に抑える方が現実的です。
A3: 多くのシステムで適用可能です。例えば、Windows ServerのActive Directoryは、グループ機能を活用することでRBACを実現できます。各種クラウドサービス(AWS, Microsoft 365など)やERP、CRMなども、標準でRBACの機能を提供している場合がほとんどです。重要なのは、各システムでバラバラにRBACを運用するのではなく、ID管理システムやワークフローシステムを中核として、一元的なポリシーで統制することです。
A4: はい、大いにあります。中小企業では一人の従業員が多くの役割を兼務することが多いため、権限管理が曖昧になりがちです。RBACを導入することで、兼務している役割(ロール)を明確に定義し、それぞれの役割に応じた権限を整理できます。これにより、属人的な管理から脱却し、将来の事業拡大や人員増加にも耐えうる、スケーラブルな管理基盤を早期に構築することができます。
A5: ほとんどの企業にとっては、まずRBACの導入が最適解です。RBACは管理が比較的容易で、十分な効果を得られます。ABACは非常に強力ですが、導入・運用のハードルが非常に高いため、ゼロトラストセキュリティの実現など、明確で高度な要件がある場合に、RBACを補完する形で検討するのが現実的なアプローチです。
引用文献
- National Institute of Standards and Technology (NIST). “Role-Based Access Control”. (RBACの概念を最初に標準化したアメリカ国立標準技術研究所の公式情報。RBACのモデルや定義に関する最も権威ある情報源の一つ)
- 総務省. 「国民のためのサイバーセキュリティサイト」. (アクセス管理の重要性について、国民向けに分かりやすく解説している公的機関のサイト)
- 独立行政法人情報処理推進機構(IPA). 「組織における内部不正防止ガイドライン」. (内部不正の手口や原因、その対策として職務分掌やアクセス制御の重要性を解説したガイドライン)
- 株式会社アイ・ティ・アール(ITR). 「ITR Market View:アイデンティティ/アクセス管理市場2023」. (IDaaSやアクセス管理市場の動向、製品シェアなど、市場を客観的に把握するためのリサーチデータ)
- ※レポートの性質上、直接のURLではなく、発行元企業のサイトをご案内します。
- URL: https://www.itr.co.jp/
- 金融庁. 「財務報告に係る内部統制の評価及び監査の基準」. (J-SOXの基礎となる公式文書。IT全般統制におけるアクセス管理の重要性について言及)
- BOXIL. 「RBAC(ロールベースアクセス制御)とは?メリット・デメリットや設定方法を解説」. (SaaS時代のID管理におけるRBACの重要性を解説した実用的な記事)