「サーバにおけるアクセス制御」の基本――ネットワークで防ぎ切れない脅威からサーバを守る：セキュリティ・テクノロジー・マップ（2）（1/2 ページ）

さまざまなセキュリティ技術の基本を一望できる「世界地図」を提供する本連載。第2回は、前回の「ネットワークアクセス制御」に続き、「サーバにおけるアクセス制御」について解説します。

[若居和直（ラック），＠IT]

クリックでマップ全体（記事一覧）へ

サーバでのアクセス制御

　セキュリティ技術について“総ざらい”する本連載。前回は「アクセス制御」の基本的な考え方と、ネットワークにおけるアクセス制御の実装例である「ファイアウォール機能」「アプリケーションファイアウォール機能」を紹介しました。第2回となる今回はその続きとして、サーバにおけるアクセス制御について解説します。

　サーバではいくつかの観点でアクセス制御が行われますが、本稿ではその中でも代表的な「ユーザーのアクセス制御機能」と「ネットワークアクセスの制御機能」の2つを取り上げます。なお、ここではサーバとしていますが、同様の技術はクライアント端末でも利用できます。

　なお、マップの全体像や関連記事などは全て連載トップページにまとめています。ぜひこちらも併せてご覧ください。

連載トップページから、全領域の記事を一覧できます

ユーザーのアクセス制御機能

　「ユーザーのアクセス制御機能」は、OSが提供する機能で、ユーザーがファイルなどに対して読み取りや変更といった操作をする際に、「アクセスするユーザー」や「アクセス対象を所有しているユーザー」「アクセス対象に設定されたルール」などの情報を基に、アクセスの許可／拒否を決定するものです。なお、ここでいう“ユーザー”には、利用者（人）だけでなく、Microsoft Windowsの「System」ユーザーのような、OSやサービスが使用するユーザーも含まれます。

ユーザーのアクセス制御機能

　クライアント端末では通常自分以外のユーザーを意識する必要はありませんが、サーバでは違います。サーバが不正ログインやサービスの脆弱（ぜいじゃく）性を突いた攻撃を受けたとき、ログインに使われたユーザーや攻撃を受けたサービスが使用していたユーザーの権限により、被害範囲が決まります。例えば、外部公開するWebサービスが管理者権限で動いていた場合、さまざまな二次攻撃に悪用されてしまう可能性があります。そのため、サービスは最小限の権限だけを持つユーザーで動作させるのが望ましいといえます。

サーバ内部への二次攻撃の例

　アクセス制御の方式には、「任意アクセス制御（DAC：Discretionary Access Control）」「強制アクセス制御（MAC：Mandatory access control）」「ロールベースアクセス制御(RBAC：Role-Based Access Control）」などがあります。

　DACは標準的なアクセス制御方式で、ファイルに対する読み取り許可／禁止などのアクセス制限設定を、「ファイルの所有者」などの権限を持つユーザーが自由に行うことができます。一方、MACでは管理者があらかじめアクセス制限を設定し、ユーザーはその中で許された範囲でしかファイルなどに対する操作を行うことができません。また、RBACは、ユーザーごとに行うと煩雑になりがちなアクセス制御設定を、「管理者」「一般ユーザー」などのロール（役割）という概念を導入することで効率化する方式です。

　実際の製品を例に挙げると、Microsoft WindowsではDACにくわえてRBACが採用されており、「Administrators」グループなどのロールが用意されています。GNU/Linuxでは、ディストリビューションにもよりますが、DACを基本として、「SELinux」や「AppArmor」といったモジュールにより、MACやRBACの仕組みが追加されています。

参考記事

Windows OS入門：アクセス制御リストACL

SELinuxの最新動向：SELinuxの出自とキソのキソ