アクセス制御は、個人が企業のコンピュータ、ネットワーク、およびデータ リソースにアクセスできるようにする手法、戦略、およびポリシーの集合です。 RBAC (RuBAC とも呼ばれます) は、ルールに基づいてアクセスを許可または制限し、企業のコンピューティング インフラストラクチャにアクセスできるユーザーが必要なリソースに正確にアクセスできるようにします。
それが少し曖昧に思える場合、それは概念が広いためです。 このガイドでは、ルールベースのアクセス制御 RBAC の概念と、企業がそれを使用して自分自身を保護する場合について説明します。
ルールベースのアクセス制御 (RBAC または RuBAC) とは?
ルールベースのアクセス制御 RBAC は、その名前が示すように、事前に定義された条件に基づいて、さまざまなユーザーへのアクセスを許可または拒否するシステムです。
ほとんどの場合、これらのルールは個々のユーザーの特性に基づいています。 これは、属性ベースのアクセス制御 (ABAC) とも呼ばれます。
ルールは、他のコンテキスト値に基づくこともできます。 たとえば、以前のアクションに関連する要因、または特定のワークフローにおけるオブジェクトの現在の段階。 現在の時刻やサーバーの負荷などのシステム変数に基づいてルールを作成することもできます。
このタイプのアクセス制御では、ユーザーの既存の属性に基づいてさまざまな条件を構成する必要があります。 これらは、個人に権限を自動的に割り当てるために使用されます。
次に、システムはブール論理を使用して各条件が true か false かを判断し、アクセス許可を割り当てるか、次のネストされた条件に進みます。
ルールは、複数の属性の組み合わせまたは XNUMX つだけに基づいて構築できます。 たとえば、非常に単純なルールベースのシステムでは、アクセス許可を決定するときにユーザーの現在の場所のみを考慮する場合があります。
より複雑なシステムでは、場所に加えて、部署、勤続年数、現在のデバイス、またはその他の属性や環境要因を考慮する場合があります。
ルールベースのアクセス制御 RBAC はどのように機能しますか?
IT 部門は、何を、どのように、どこで、いつだれかが RBAC の下でアクセスしようとするかの詳細に基づいて、高レベルのルールを確立します。 各リソースは、アクセス制御リストまたは ACL に関連付けられています。 誰かが特定のリソースを使用しようとすると、オペレーティング システムは ACL をチェックして、その試みがリソースへのアクセスに関するすべてのルールに従っているかどうかを確認します。
RBAC の「ルール」コンポーネントは、いつ、どのように、どこでアクセスが許可されるかについての制約を指します。 以下にいくつかの例を示します。
- ネットワーク上の全員が IP アドレスを持っており、ネットワークはこれを使用して場所を識別します。 経理チームが勤務する地域など、特定の地理的範囲内の IP アドレスを持つ人だけが企業会計システムの使用を許可されるというルールが考えられます。 特定の住所にいる人には買掛金へのアクセスを許可し、売掛金へのアクセスは許可しないなど、さらに細かく制御することもできます。
- 許可と制限は、特定のネットワーク ドアとして機能するポートにリンクできます。 適切なポートでの要求のみが有効である可能性があると見なされます。 たとえば、XNUMX つのポートを、遠隔地からのドキュメントのアップロードを受け入れる施設にリンクすることができます。 その場合、ネットワークの別の領域へのアップロード要求が拒否されることがあります。
- 特定の種類のアクセスは、標準の営業時間中など、特定の時間に制限される場合があります。 これらの時間枠以外では、誰もこれらのコンピューティング リソースにアクセスできません。 時間の制約は、対応できるセキュリティ専門家が少なく、警戒している時間外に、犯罪者がシステムに侵入できないようにするのに役立ちます。
また、 ロールベースのアクセス制御 RBAC: 定義、歴史、および例
- 機密記録へのアクセスが必要な人には、今後のすべてのアクセス試行で使用する必要がある追加の資格情報が与えられる場合があります。 または、特定のリソースを XNUMX 週間に使用できる回数に制限がある場合や、アクセス許可が一時的なものになるようにタイムアウトが設定されている場合があります。
- RBAC を使用してアクセスを許可できるのと同様に、企業のインフラストラクチャ内または外部リソースへのアクセスを防止するためにも使用できます。 たとえば、会社は従業員が勤務時間中にビデオストリーミングアプリを使用することを望まない場合や、すべての電子メールをブロックする場合があります (可能性は低いですが、ユーザーは夢を見ることができます)。
覚えておくべき主なことは、RBAC がアクセス コンテキストを管理するということです。 会社の従業員に重点が置かれていますが、顧客やビジネス パートナーに一部のリソースへの制御されたアクセスを提供する会社にも同じ概念を適用できます。
ヒント： ルールベースのアクセス制御 RBAC は、複数の役割とさまざまなレベルの専門知識を持つ大規模な組織にとって不可欠です。 システムの特定の側面は、セキュリティと効率の理由から、ジョブを完了する必要がない人には立ち入り禁止にする必要があります。
ルールベースのアクセス制御 RBAC の利点
ビジネスの場合、ルールベースのアクセス制御 RBAC には多くの利点があります。
- リソース アクセスのコンテキストを標準化および制御することで、法令順守の問題をより適切に規制できます。
- RBAC は、必要なリソース使用制限を適用することでセキュリティを強化します。 これにより、外部の犯罪者が会社のコンピューティング インフラストラクチャを攻撃することがより困難になります。
- 適切に設計された RBAC システムは、セキュリティを向上させるだけでなく、ネットワークの使用を規制します。 リソースを集中的に使用するプロセスとソフトウェアの使用を、需要が少ない日と時間に制限できます。 たとえば、複雑な管理レポートやマーケティング分析を、十分な処理能力がある深夜にのみ実行するようにスケジュールできます。
- RBAC は、IT 担当者やサポート担当者が関与することなく、必要な制限を自動的に適用できます。 IT スタッフが手動で使用状況を追跡し、後で特権を取り消すことを忘れないようにする代わりに、変更を自動化し、異常な状況で限られた時間だけ追加のアクセス許可を設定できます。
- あまりにも多くの人々に過度に幅広いアクセスを提供する代わりに、アクセスを制御する方法を必要なだけ詳細にすることができます.
- 管理者のみがルールを変更する権限を持ち、ミスの可能性を減らします。
ルールベースのアクセス制御 RBAC の欠点
RBAC には、他のすべてのものと同様に制限があります。
- 複数のレベルで詳細なルールを構成するには時間がかかり、IT スタッフによる事前作業が必要になります。 また、ルールが適切に機能し、時代遅れにならないように、何らかの継続的な監視も必要になります。
- 従業員は、アクセス制御システムが煩雑で不便だと感じるかもしれません。 通常のパターン以外での作業が必要になった場合、あなたまたは別の管理者がルールを変更するか、回避策を提供する必要があります。
- IT スタッフが異常な状況に合わせて特定のルールを再プログラムし、その後元に戻す必要がある場合、定期的な変更が必要になることが負担になる可能性があります。
- RBAC は、ルールに依存しているため、リソース、人、運用、および運用またはインフラストラクチャのその他の側面の間の特定の関係を考慮しません。 必要なルールの構造は、制御メカニズムを追加しないと非常に複雑になる可能性があります。
ルールベースのアクセス制御システムは、会社のニーズに応じて、重要な追加のセキュリティを提供できます。 ただし、それだけでは不十分な場合があります。 あなたの会社はまた、ルールを設定して維持し、必要に応じてルールを適応または変更するための専門知識を必要とします。
ルールベースとロールベースのアクセス制御の違いは何ですか?
従業員のアクセス レベルは、本質的に予防的なルール ベースのアクセス制御によって決定されません。 代わりに、不正アクセスを防止するために機能します。 役割ベースのモデルは、承認されたアクセスを取得できる一連の条件を従業員に提供するという点で積極的です。
アクセス制御のルールは何ですか?
ドメイン、オブジェクト タイプ、ライフ サイクル状態、および参加者はすべて、アクセス コントロール ルールによって一連のアクセス許可に割り当てられます。 アクセス制御規則は、ドメイン内の特定のタイプおよび状態のオブジェクトにアクセスするための、ユーザー、グループ、役割、または組織の権利を指定します。
ルールベースのアクセス制御の実装
ルールベースのアクセス制御を実装し、ルールベースの制御のベスト プラクティスを検討する際には、いくつかの重要な手順を実行する必要があります。
- 現在のアクセス ルールを調べる – 特定のアクセス ポイントに適用される規則と、すべてのアクセス ポイントに適用される一般的な規則の両方を調べます。 特定のアクセス ルールがない高リスク領域を特定します。 セキュリティの脆弱性は常に変化し進化しているため、これは定期的に行う必要があります。
- 「what-if」シナリオの分析 – リスクを軽減するために追加のルールの適用が必要になる可能性のあるシナリオを特定します。
- 評価に基づいてルールを更新または作成します。 新しいルールを設定するか、既存のルールを更新して、セキュリティ レベルを高めます。
- 権限の競合を避ける ルールを他のアクセス制御モデルによって設定されたパーミッションと比較して、誤ってアクセスを拒否する競合が存在しないことを確認します。
- ルールを文書化して公開する –最も重要なルールを公開し、すべての従業員が自分のアクセス権と責任を理解できるように変更を伝えます。 従業員は詳細を知る必要はないかもしれませんが、ポリシーの変更が日常業務にどのように影響するかを理解することは重要です。
- 定期的なレビューの実施 – 定期的なシステム監査を実施して、アクセスの問題やセキュリティ ギャップを特定します。 緩いアクセス制御によるセキュリティ上の問題を調査し、必要に応じてルールを修正します。
ルールベースとロールベースのアクセス制御
セキュリティ管理者は、両方のモデルを構成および管理します。 従業員は、オプションではなく必須であるため、アクセス許可を変更したり、アクセスを制御したりすることはできません。 ただし、ルールベースとロールベースのアクセス制御にはいくつかの大きな違いがあり、特定のユース ケースに最適なモデルを判断するのに役立ちます。
操作
- ルールベースのモデルは、すべての職務に適用されるルールを定義します。
- ロールベース モデルの権限は、特定のジョブ ロールに基づいています。
目的
- 従業員のアクセス レベルは、本質的に予防的なルール ベースのアクセス制御によって決定されません。 代わりに、不正アクセスを防止するために機能します。
- 役割ベースのモデルは、承認されたアクセスを取得できる一連の条件を従業員に提供するという点で積極的です。
申し込み
- ルールベースのモデルは、役割に関係なく、すべての従業員に適用されるという意味で一般的です。
- 役割ベースのモデルは、従業員の役割に基づいて個々に適用されます。
ケーススタディ
役割ベースのモデルは、役割が明確に定義され、それらの役割に基づいてリソースとアクセスの要件を識別できる組織に適しています。 そのため、RBAC モデルは、従業員数が多く、個々の従業員にアクセス許可を設定するのが困難で時間がかかる組織に適しています。
ルールベースのオペレーティング システムは、従業員が少ない組織や役割が流動的な組織でうまく機能し、「厳密な」権限の割り当てが困難になります。 ルールベースのオペレーティング システムは、最高レベルのセキュリティを必要とする複数の領域を持つ組織にも不可欠です。 役割ベースのモデルは、特に各役割が異なるレベルの年功序列とアクセス要件をカバーする場合、それ自体では適切な保護を提供できない場合があります。
ハイブリッドモデル
ルールベースとロールベースのアクセス制御モデルは、保護を最大化するという同じ目標を達成するために異なるアプローチを取るという点で補完的です。 役割ベースのシステムにより、許可された従業員のみが制限された領域またはリソースにアクセスできるようになります。 ルールベースのシステムにより、許可された従業員が適切な場所で適切なタイミングでリソースにアクセスできるようになります。
一部の組織は、どちらのモデルも必要なレベルのセキュリティを提供しないと考えています。 さまざまなシナリオに対処するために、セキュリティ管理者はハイブリッド モデルを使用して、役割ベースのシステムによる高レベルの保護と、ルール ベースのモデルによる柔軟で詳細な制御の両方を提供できます。
管理者は、役割ベースのモデルを通じて、エントランス ロビーなどのセキュリティ要件の低いエリアですべての従業員にアクセスを許可できますが、営業時間外のアクセスを拒否するルール ベースの例外を追加できます。
管理者は、セキュリティの高い領域で特定の役割に権限を割り当てることができますが、ルールベースのシステムを使用して、下位レベルの従業員のみを役割から除外します。
このようなハイブリッド モデルは、両方のモデルの利点を組み合わせながら、全体的なセキュリティ体制を改善します。
ドアのアクセス制御管理を簡素化
- アクセス許可は、ユーザー ロール、属性、およびカスタム ルールを使用して、簡単かつ安全に構成できます。
- すべてのドア、ゲート、回転式改札口、エレベーターへのアクセスをスケジュールします。
- ドアのリモートロック解除または建物のロックダウンの有効化
- タッチレス Wave to Unlock を使用すると、エントリごとに必要なモバイル認証情報が XNUMX つだけになります。
- 高セキュリティ エリア向け、ビルトイン バイオメトリクス、MFA、ビデオ認証
- リモートのクラウドベースのアクセス制御ソフトウェアを使用して、いつでもアクセス許可を変更できます。
役割ベースおよびルールベースのアクセス制御と属性ベースのアクセス制御
役割ベースのシステムのセキュリティ管理者は、ビジネスにおける従業員の役割に基づいて、スペースまたはリソースへのアクセスを許可または拒否します。
管理者は、承認された一連の属性または特性に基づいて、属性ベースのシステムでアクセスを制御します。 従業員の役割は属性の XNUMX つかもしれませんが、プロファイルには通常、プロジェクト チーム、ワークグループ、部門のメンバーシップ、管理レベル、セキュリティ クリアランス、およびその他の基準などの他の特性が含まれます。
管理者は少数の役割を定義するだけでよいため、役割ベースのシステムはより迅速かつ簡単に実装できます。 属性ベースのシステムの管理者は、複数の特性を定義および管理する必要があります。
一方、複数の特性を使用すると、管理者がより詳細な形式の制御を適用できるため、特定のユース ケースでは有利な場合があります。
属性ベースとルールベースのアクセス制御
ルールベースのシステムの管理者は、一連の事前定義されたルールに基づいてアクセスを許可または拒否します。
対照的に、属性ベースのアクセス制御 (ABAC) モデルは、アクセスを許可する前に、承認された一連の属性または特性を評価します。 管理者は、さまざまなアクセス ポイントまたはリソースの特定のセキュリティ要件に合わせて調整されたさまざまな特性のセットを作成できます。 これら XNUMX つのタイプの主な違いは、アクセスの許可または拒否に使用される情報とアクションです。 属性は通常、チーム、勤務状況、クリアランスなど、従業員に関する個人情報にリンクされています。 ルールでは、勤務時間、ドア スケジュール、デバイス、およびその他の同様の基準が頻繁に参照されます。
どちらのモデルもきめ細かなアクセス制御を可能にするため、特定のセキュリティ要件を持つ組織にとって有利です。 ルールベースのモデルと属性ベースのモデルの両方を、役割ベースのアクセス制御などの他のモデルと組み合わせることができます。 管理者は複数のルールまたは属性を定義する必要があるため、どちらのモデルも実装と管理に時間がかかる可能性があります。 一方、ルールと属性は、時間の経過とともに優れたスケーラビリティを提供します。
まとめ
ビジネス内の特定の領域またはリソースに誰がアクセスできるかを決定するための最も重要な XNUMX つのモデルは、ルール ベースおよびロール ベースのアクセス制御です。 セキュリティ管理者は、アクセスを高レベルで管理したり、詳細なルールを適用して、最も適切なモデルを実装することにより、セキュリティの高い領域に特定の保護を提供したりできます。
ルールとロールに基づくアクセス制御により、企業はセキュリティ テクノロジーを真にカスタマイズされた方法で使用できます。 ビジネス内の特定の領域やリソースに誰がアクセスできるかを判断することで、企業は最適なモデルを実装し、高レベルでアクセスを管理し、詳細なルールを適用して高セキュリティ領域により堅牢な保護を提供できます。
どちらのモデルも効果的なセキュリティと大きなメリットを提供しますが、アクセス セキュリティ ポリシーの開発、実装、および管理に必要な作業はさまざまです。 さらに、ルールベースのモデルとロールベースのモデルは互いに補完し合い、併用してさらに優れたアクセス制御セキュリティを提供できます。
関連記事
参考文献
