アクセス制御とは、機密データ、コンピューター・システム、場所、その他のリソースへのユーザー・アクセスを管理するポリシー、ツール、プロセスのことです。
ゲートや施錠されたドアなどの物理的なアクセス制御により、物理的な場所へのアクセスが制御されます。論理的アクセス制御（侵入検知・防御システムなど）により、コンピュータシステムへのアクセスが制御されます。この記事では、主に論理的アクセス制御について解説します。
アクセス管理の用語では、アクセスを必要とするエンティティーは「主体」と呼ばれます。これらの主体には、人間のユーザーだけでなく、チャットボット、アプリ、自動ワークロード、AIエージェントなどの非人間アイデンティティーも含まれます。
実際に、クラウド・インフラストラクチャーの普及、DevOpsの台頭、高度な人工知能ツールの採用などにより後者のカテゴリーが爆発的に拡大するにつれ、非人間アイデンティティーはアクセス制御の重要な焦点となりつつあります。
アプリケーション・プログラミング・インターフェース（API） 、オペレーティング・システムの設定、クラウド・データベース内の機密情報など、主体がアクセスする必要があるものは「オブジェクト」と呼ばれます。
エンタープライズ・ネットワークにおけるアクセス制御の実装は、通常、システム内の各主体のアクセス権を定義するアクセス制御ポリシーを作成して適用することになります。アクセス制御ポリシーは、主体がオブジェクト（ドキュメントなど）にアクセスできるかどうか、およびそのオブジェクトに関する権限（ドキュメントの場合は読み取り専用、読み取りと書き込み、完全な管理制御）を規定します。
アクセス制御は、IDセキュリティーの基盤です。例えば、ゼロトラスト・ネットワーク・アーキテクチャーは、堅牢なアクセス制御によって不正アクセスを防止し、認可されたユーザーのアクセスを合理化します。クラウドネイティブ・ネットワークでは、アイデンティティーが新たな境界線となるため、アクセス制御はより広範なサイバーセキュリティーの取り組みに不可欠です。
同時に、アクセス制御は多くのシステムにとっての弱点でもあります。脆弱なアクセス制御は、最も重要なWebアプリケーションのセキュリティー上のリスクをランク付けしたOWASPのトップ10リストで1位となっています。IBMのX-Force脅威インテリジェンス·インデックスによると、IDベースの攻撃（脅威アクターが正当なユーザー・アカウントを乗っ取ってアクセス権限を悪用する攻撃）は、全体の攻撃のほぼ3分の1を占めています。
したがって、アクセス管理は組織のセキュリティー体制において重要な役割を果たしますが、そこには改善の余地があることを入手可能なデータは示唆しています。
AI、サイバーセキュリティ、データ、自動化に関する厳選されたニュースをThinkニュースレターで購読しているセキュリティリーダーに加わりましょう。専門家によるチュートリアルと解説をメールで直接配信することで、手軽に学ぶことができます。IBMプライバシー・ステートメントをご覧ください。
アクセス制御は通常、ポリシーベースです。システム管理者は、必要に応じて他の利害関係者と協力し、主体の権限を詳細に規定するアクセス制御ポリシーの草案を作成します。IDおよびアクセス管理（IAM）や特権アクセス管理（PAM）プラットフォームなどのアクセス制御システムは、これらのセキュリティー・ポリシーを自動的に適用します。
アクセス制御システムは、検証と承認の2段階のプロセスを使用して、検証済みの主体のみがオブジェクトにアクセスできるようにし、それらの主体が承認された方法でのみ行動できるようにします。
アクセス・ポリシーにより、主体がアクセスできるオブジェクト（開発者が閲覧できるS3バケット、アプリケーションが呼び出すことができるAPI、大規模言語モデル（LLM）が取り込むことのできるデータ・セットが決定されます。さらに重要な点として、アクセス・ポリシーは個々のユーザーがオブジェクトに対して何を実行できるかも規定します。LLMはデータ・セットに書き込みができるのか？開発者はS3バケットの設定を変更できるのか？これらの質問に対する答えは、アクセス・ポリシーによって決まります。
ポリシーは必然的にシステムごとに、またリソースごとに異なりますが、ほとんどの組織は、役割ベースのアクセス制御（RBAC）や属性ベースのアクセス制御（ABAC）など、確立されたアクセス制御モデルに従っています。（詳細については、「アクセス制御の種類」をご参照ください。）
多くの組織のアクセス・ポリシーは、モデルにかかわらず、最小権限の原則に従っています。これは、ユーザーは業務を遂行するために必要な最低限の権限のみを持つべきであり、業務が完了したら権限は取り消されるべきであるという考え方です。
アクセス・ポリシーは、さまざまな方法でシステムに「保管」できます。
主体がアクセス制御システムによって保護されたリソースにアクセスを試みる場合、まず最初に認証プロセスを通じて本人確認を行う必要があります。
人間のユーザーの場合、認証には通常、ユーザー名とパスワードの組み合わせなどの一連の認証情報の提示が含まれます。ただし、パスワードは脅威アクターが容易に推測したり盗んだりできるため、最も弱い認証情報の1つと見なされています。
現在のシステムの多くは、生体認証や多要素認証（MFA）などのより高度な対策に依存しています。多要素認証（MFA）では、ユーザーの身元を証明するために2つ以上の証拠（指紋スキャンと認証アプリによって生成された1回限りのパスワードなど）が必要となります。
デバイス、ワークロード、AIエージェント、その他の非人間アイデンティティーは、通常、認証情報や暗号化などの証明書や暗号キーを使用して「本人確認」を行います。人間以外の主体はMFAを使用できませんが、シークレット管理ソリューションの保管や自動ローテーション機能、その他の対策を通じ、認証情報を保護することができます。
承認は、本人確認が行われた主体に適切なレベルのアクセス権を付与するプロセスです。
承認がどのように行われるかは、導入されているアクセス制御システムによって異なります。
例えば、システムがACL（アクセス制御リスト）を使用している場合、システムはそのリストを確認し、そこに記載されている権限を対象ユーザーに割り当てます。
システムがポリシー・エンジンを使用する場合、そのエンジンはアクセス・リクエストのコンテキストに基づいてユーザーに権限を付与します。
OAuthプロトコル（アプリケーションにエンドユーザーの保護されたリソースへの安全なアクセスを提供するオープンスタンダードの認証フレームワーク）を使用するシステムでは、トークンを通じて承認が行われます。
ネットワーク内の個々のオブジェクトは独自のアクセス制御システムを持つことができますが、これは一般的にベスト・プラクティスとは考えられません。これらのシステム間にギャップや不一致があると、攻撃者によるエクスプロイト対象となる脆弱性が生じ、許可されたユーザーが業務を遂行できなくなる可能性があります。
代わりに、米国国立標準技術研究所（NIST）やOWASPなどの組織は、多くの場合、総合的なIDファブリックの一部として集中アクセス制御システムを実装することを推奨しています。
これらの集中型システムは、次のようなテクノロジーとツールに依存しています。
IAMソリューションは、主要なアクセス制御タスクを合理化および自動化できます。その機能はさまざまですが、一般的なIAMの主要な機能には、ディレクトリー・サービス、認証と承認のワークフロー、認証情報の管理、IDガバナンスが含まれます。
シングル・サインオン（SSO ）とは、ユーザーが単一の認証情報を使用して一度だけログインすると、同じセッション中に複数のアプリケーションにアクセスできるようにする認証スキームです。シングル・サインオンを適切に実装することで、ユーザー認証を簡素化し、ユーザー・エクスペリエンスを向上させ、セキュリティーを強化できます。
一部の組織では、ユーザーが企業データ、ソフトウェア、その他のリソースにアクセスする際に、企業VPNにログインすることを要求しています。この場合、VPNはアクセス制御として機能します。ユーザーは、公開インターネットではなくこの特定のネットワーク経由でのみ、企業オブジェクトにアクセスできます。
ZTNAは、ある意味ではVPNのゼロトラスト・バージョンです。ZTNAは、アプリケーションやサービスへのリモートアクセスを提供しますが、ユーザーをネットワーク全体に接続するのではなく、各ユーザーがアクセス権を持つリソースのみに接続します。
他の領域と同様に、組織は生成AIツールやエージェント型AIツールをアクセス制御に組み込んでいます。
例えば、生成AIチャットボットを使用すると、プロビジョニングなどのID管理プロセスを簡素化できます。組織のアクセス制御ポリシーを学ぶようLLMチャットボットをトレーニングし、適切なドキュメンテーションやリソースと接続することにより、組織は安全なセルフサービスIAMツールを構築できます。新規ユーザーがシステムにアクセスする必要がある場合、または既存ユーザーが更新された権限を必要とする場合、チャットボットを通じてリクエストを行うことができます。
ある組織が、顧客データを含む機密データベースへのアクセス制御を作成し、それを実施する必要があるとします。
まず、システム管理者およびその他の利害関係者は、どの主体（ユーザー、アプリ、 AIエージェント）がデータベースにアクセスできるかを決定します。営業やマーケティングの役割を担う人物全員に加え、顧客関係管理（CRM）ソフトウェアやマーケティング・ソフトウェアも同様にアクセスできるべきだと、彼らは判断するかもしれません。権限を与えられた人間ユーザーが所有するAIエージェントにも、アクセス権が与えられます。
次に、利害関係者は、権限を与えられた各ユーザーがデータベース内でどのようなアクションを実行できるかを決定します。営業担当者は、長期にわたりこれらの顧客との関係を構築・維持するため、読み取りと書き込みのアクセス権限を必要とすることが考えられます。一方、マーケティング担当者は、顧客の人口統計データを使用してキャンペーンに情報を提供するだけなので、データベースを読み取る権限のみを与えられます。所有者が誰かにかかわらず、すべてのAIエージェントは読み取り専用アクセス権を持ち、人間がデータベースを更新する際に常に介入できる状態になっていることも考えられます。
このアクセス・ポリシーを適用するために、組織は詳細なアクセス制御ロジックを備えた一元型のポリシー・エンジンを使用します。アクセス・リクエストを許可するかどうかを決定する際に、エンジンはユーザーIDに加え、コンテキストに関連する要因も考慮します。
例えば、営業担当者が顧客のEメールアドレスを更新するためにデータベースにアクセスしたいとします。まず、営業担当者は適切な認証要素を提供することで本人確認を行います。次に、営業担当者のリクエストはポリシー・エンジンによって評価されます。この際には、以下が考慮されます。
これらの要因に基づいて、営業担当者のアクセス・リクエストが承認されます。
組織は、ニーズに応じてさまざまなタイプのアクセス制御モデルを実装できます。一般的なタイプは次のとおりです。
任意アクセス制御（DAC）システムを使用すると、リソースの所有者はそれらのリソースに対してアクセス・ルールを設定できます。オブジェクト所有者は、DACモデルの他のユーザーに管理レベルの権限を渡すこともできます。オブジェクト所有者が別のユーザーに管理者権限を付与する場合、そのユーザーはオブジェクトに対するアクセス・ルールも設定できます。
強制アクセス制御（MAC）システムは、すべてのユーザーに対して集中的に定義されたアクセス制御ポリシーを適用します。
多くの場合、これらのシステムは官公庁・自治体や軍などのように機密レベルを通じて運用されます。各主体には機密レベルが割り当てられ、各オブジェクトには対応する機密区分または分類レベルが設定されます。主体は、割り当てられた機密レベルかそれ以下のあらゆるオブジェクトにアクセスできます。
すべてのアクセス制御は、あらゆる主体がそれに従わなければならないという意味で強制的なものですが、MACにおける「強制」とは、個々のユーザーが権限を変更したり割り当てたりすることができないという事実を指します。MACは、オブジェクト所有者が自身のオブジェクトへのアクセス・ルールを制御できる裁量型のDACモデルとは対照的です。
役割ベースのアクセス制御（RBAC）では、組織内での役割に基づいてユーザーの権限が決定されます。
RBACシステムにおける役割は、役職と同義ではありませんが、実装によっては1対1で対応する場合もあります。ただし、この文脈における「役割」とは、組織内で個人が行う業務、そしてその業務を実施するために必要となる権限を指します。RBACの役割は、役職、スキル・レベル、責務など、いくつかの基準に基づいています。
例えば、システム管理者がネットワーク・ファイアウォールの権限を設定するとします。営業担当者には、いかなるアクセス権限も与えられないことが想定されます。ジュニア・レベルのセキュリティー・アナリストは、ファイアウォール構成を閲覧することはできても変更はできない一方で、シニア・レベルのアナリストには管理アクセス権が付与される可能性があります。また、統合型のセキュリティー情報およびイベント管理システム（SIEM）のAPIには、ファイアウォールのアクティビティ・ログを読み取る権限が与えられるかもしれません。
OWASPが推奨する2つ目のアクセス制御モデルである属性ベースのアクセス制御（ABAC）は、ポリシー・エンジンを使用して各アクセス・リクエストの属性をリアルタイムで分析します。これにより、適切な基準を満たすリクエストのみが許可されます。
大まかに言うと、「属性」とは、リクエストに含まれる主体、オブジェクト、およびアクションの特性のことです。属性には、ユーザーの名前と役割、リソースの種類、リクエストされたアクションのリスク・レベル、リクエストが出された時刻などが含まれる可能性があります。
例えば、ABACシステムでは、ユーザーは勤務時間中にのみ、また一定の役職に就いている場合にのみ機密データにアクセスできる場合があります。
RBACとABACの違いは、ABACは複数の状況要因に基づいて、各リクエストの時点でアクセス権限を動的に決定する点にあります。一方、RBACは、事前に定義されたユーザーの役割に基づいて厳密に権限を付与します。
ルールベースのアクセス制御（RuBAC）とは、条件付き、かつ状況に応じたルールに基づいてアクセスを制御するシステムです。例えば、リクエストがYの時刻にXという主体から送信された場合、そのリクエストは許可されます。
「ルールベースのアクセス制御」は不正確で、やや時代遅れな用語です。多くの場合、この用語は属性ベースのアクセス制御（ABAC）の同義語として、または以前のあまり洗練されていない形式のABACの名称として使用されます。場合によっては、アクセス・リクエストを追加のロジック層（役割＋ルール）を通して処理するRBACシステムを指して使用されることもあります。
アクセス制御は、さまざまな意味でエンタープライズ・セキュリティーの中核を成します。OWASPは、アクセス制御が「障害が起きた場合には最大のリスク」となり、「機能した場合には最大の事前措置的制御」になると記しています。
効果的なアクセス制御は、組織の資産を保護し、企業データの価値を最大限に引き出し、新しいAIエージェント・テクノロジーを保護・強化するのに役立ちます。欠陥のあるアクセス制御は、これらすべての取り組みを弱体化させるだけでなく、ハッカーにとっての格好の餌食となってしまう可能性があります。
アイデンティティーは現代のセキュリティー施策の中核を成すため、アクセス制御はサイバーセキュリティーの基盤となります。
平均的な企業ネットワークにおける人間および非人間ユーザーの数は増加の一途を辿っています。これらのユーザーはさまざまな場所に分散しており、オンプレミスとクラウド・ベースの両方のアプリやリソースへの安全なアクセスを必要としています。
こうした環境では、境界防御型のセキュリティー対策は効果がありません。その代わりに、組織は個々のユーザーとリソース（アクセス管理用語で言えば主体とオブジェクト）のセキュリティー制御に集中します。
例えば、ネットワーク・セキュリティーに対するゼロトラストのアプローチについて考えてみましょう。ゼロトラストでは、ユーザーを一度認証するだけにとどまらず、あらゆるユーザーからのあらゆるアクセス・リクエストに対して認証を行います。これは、すべてのリクエストがアクセス制御プレーンを通過することを意味します。
アクセス制御が情報セキュリティーのCIAトライアドをどのようにサポートするかについても考慮しましょう。
アクセス制御は、組織がデータ・セキュリティーを維持しながら、独自のデータからより多くの価値を実現するのにも役立ちます。
IBM Institute for Business Valueの2025年CDO調査によると、CDOの78%は、専有データを活用することが組織を差別化するための戦略的ビジネス目標であると回答しています。さらに、82%のCDOは、従業員がデータ駆動型の意思決定を行うためにデータを容易に利用できなければ、データは「無駄になる」と考えています。
また、AIエージェントがデジタル労働力に加わるにつれて、安全なデータ・アクセスがさらに重要になります。エージェントが効率的かつ効果的に機能するためには、企業データが必要です。
効果的なアクセス制御により、人間のユーザーとAIエージェントの両方が、承認された用途のために企業データに安全にアクセスできるようになります。CDOの調査によると、AIとデータへの投資を通じてより高いROI（投資収益率）を実現している組織のCDOは、企業データへのユーザー・アクセスを管理するためにRBACなどのセキュリティー対策を活用しています。
IBMのポッドキャスト「Security Intelligence」のエピソードで、IBMのサイバー脅威管理サービス・グループのグローバル・パートナーであるDave McGinnis氏は、AIエージェントを「最も役に立つ内部脅威」と呼びました。McGinnis氏は、AIエージェントが計り知れないほどの利益と同時に、計り知れないほどの脅威を生み出す可能性を持つことに言及しました。
有意義な業務を行うために、AIエージェントは企業システムおよびデータへの高い権限を持つアクセスを必要とします。しかし、エージェントの挙動は非決定的でもあり、適切なガードレールがなければ、必ずしも承認されていない新たな方法でアクセス権を使用する可能性があります。
IBMのサイバー・レンジでエグゼクティブ・アドバイザーを務めるSeth Glasgow氏が「Security Intelligence」で説明しているように、高い権限が悪用されるリスクを軽減しながらAIエージェントを導入するためには、アクセス制御を適切に使用することが鍵となります。
[AIエージェント]の標準的なデプロイメントにおいて、AIエージェントはすべてを見ることができますよね？適切な用語はありませんが、1つのエージェントがすべてを支配します。...そこで、私は非常に価値の高いアセットを開発しました。そのアプリは、大量の機密データにアクセスするように設定されています。
したがって、IAM（IDおよびアクセス管理）の観点から最初に行う必要があるのは、これをセグメント化することです。これらの作業すべてを実行できる単一のエージェントは必要ありません。エージェントは特定のユースケースに適合する必要があり、行うべき作業と直接的に一致する権限をエージェントに付与する必要があります。
アクセス制御障害を引き起こす主な要因は3つあります。それは、過剰な権限の付与、一元化管理の欠如、設計上の欠陥です。
組織が業務に取り組む際に障害に遭遇しないようにするために、厳密に必要とされる権限よりも高いレベルの権限を主体に付与することはよくあります。過剰な権限の付与は、ワークフローを自動化するために使用される非人間アイデンティティーにおいて特によく見られます。通常、組織は介入を最小限にとどめることを望むためです。
RBACやABACなどの効果的なアクセス制御は、ユーザー・エクスペリエンス、ビジネス・オペレーション、セキュリティ・ニーズをのバランスを取るのに役立ちます。組織は、過剰な特権を与えるのではなく、多過ぎることも少な過ぎることもないよう、各主体が必要とするレベルに正確かつ限定的にアクセス権限を調整します。
一元化されたアクセス制御がないシステムでは、オブジェクトごとに制御システムが異なる場合があります。これらのシステム間のギャップにより、主体が必要とするリソースにアクセスできなくなり、1つの脆弱なシステムがネットワーク全体を危険にさらす可能性があります。
包括的なIDファブリックを実装し、Identity Orchestrationツールを使用して異種のシステムを統合することで、組織はセキュリティーのギャップを埋めると同時に、承認されたユーザーのアクセスを効率化できます。
最後に、OWASPが指摘しているとおり、アプリケーションのアクセス制御システムには設計上の欠陥があることがよくあります。これらの欠陥には、ページURLを変更することで制御をバイパスする機能、API制御の欠如、セキュリティーで保護されておらず改ざんに対して脆弱なJSON Webトークンなどの問題が含まれる可能性があります。
開発者の教育プログラム、アクセス制御要件の厳格化、およびDevSecOps運用は、組織がアプリケーションに直接IDセキュリティーを組み込むのに役立ちます。