第3回アクセス制御の実装は“巧妙”かつ“大胆”に

海外　浩平
日本SELinuxユーザ会
2007/10/12

前回までSE-PostgreSQLで行えるアクセス制御の基本動作を学んできましたが、具体的にどのようにして実現しているのでしょうか？ PostgreSQLにアドオンした部分を技術的に解説します（編集部）

　第2回では、TE（Type Enforcement）アクセス制御モデルと、それを用いたSE-PostgreSQLのカスタマイズ方法をご紹介しました。今回は、SE-PostgreSQLが内部でどのようにアクセス制御を行っているかを説明します。

　PostgreSQLのクエリー処理手順を理解する

　はじめに、ネイティブのPostgreSQLがどのようにSQLクエリーを処理しているかを説明します。SE-PostgreSQLは、このSQLクエリー処理手順の中に巧妙に入り込むことによって、これまで説明したような、細粒度の強制アクセス制御を実現しています。

　データベースにアクセスするため、クライアントはPostgreSQLに対してSQLクエリーを発行します。PostgreSQLはこれを何段階かに分割して処理を行い、その過程で、文字列として渡されたSQLクエリーは内部処理に適したデータ形式へと順次変換されます。

　文字列として渡されたSQLクエリーは、最初に「字句／構文解析」モジュールに渡されて、扱いやすいトークン単位に分解・再構築されます。

　続いて「クエリー解析」処理では、SQLクエリー中で指定されたデータベースオブジェクト（テーブルやカラムなど）が実際に存在していることを確認し、これらのメタ情報をシステムカタログから読み出します。また、SQLクエリーの中でビューが使われている場合には、「クエリー書き換え」処理で実際のテーブル参照への変換が行われます。

　次の「オプティマイザ」処理では、このように書き換えられたSQLクエリーの最適化を行い、インデックス利用の有無などを含む実行プランを作成します。そして、「エグゼキュータ」は実行プランに基づいてデータベースへの問い合わせを行い、その結果を「結果セット」としてクライアントの元に返却します。

　この一連の処理中に何かエラーが発生した場合、PostgreSQLは処理を直ちに中止してトランザクションをアボートし、クライアントの元にエラーを返却します。

図1　SE-PostgreSQLのクエリー処理手順

　SE-PostgreSQLによる拡張

　クライアントはデータベースに対するアクセス要求を、SQLクエリーという形でサーバに送出します。従って、SQLクエリーを検査することで、クライアントがどのテーブルのどのカラムを参照しようとしているのか、あるいは、どのSQL関数を実行しようとしているのか、などの情報を知ることができます。

　SE-PostgreSQLがSQLクエリーを検査するのは、「クエリー書き換え」処理の終了後、「オプティマイザ」に処理が移行する直前です。このタイミングでSE-PostgreSQLの処理を挿入することにはいくつかの理由があります。

　まず、すべてのSQLクエリーは図1に示す処理フローを経由します。そのため、この処理フローの内側にSE-PostgreSQLを配置することにより、すべてのSQLクエリーに対するアクセス制御を実施するという「強制アクセス制御」の特徴を担保することができます。

　また、この時点ではビュー経由の参照が「クエリー書き換え」処理によって、すでに実際のテーブルへの参照に書き換えられていることに留意してください。つまり、どんなビューを経由したアクセスであっても、SE-PostgreSQLは最終的にアクセスの対象となるテーブルのセキュリティコンテキストのみに基づいてアクセス制御を実施します。

　一方、ネイティブのPostgreSQLの持っているデータベースACLは、ビューごとに設定することが可能です。1つのテーブルに対して複数のビューを設定できるため、単一のテーブルに複数のACL、つまり一貫性のないACLを設定できてしまいます。

　この考え方は、ファイルに対するアクセス制御をラベルベースで行うのか、パス名ベースで行うのかという違いに似ています。すなわち、“情報資産”に対するアクセス制御は、アクセス手段とは独立に、そのセキュリティ属性によって実施されるべきであるという考え方です。

　このほかにも、SE-PostgreSQLは入力されたSQLクエリーを書き換える場合がありますが、PostgreSQLの最適化エンジンは「オプティマイザ」処理の前段階でSQLクエリーの書き換え処理を行うことで、書き換え後のSQLクエリーのコストを考慮した実行プランを作成することが可能です。

1/3

Index
アクセス制御の実装は“巧妙”かつ“大胆”に
	Page1 PostgreSQLのクエリー処理手順を理解する SE-PostgreSQLによる拡張
	Page2 SE-PostgreSQLによるSQLクエリーの検査例1：シンプルなSQLに必要な権限を検査する例2：UPDATE文の実行に必要な権限を検査する
	Page3 行レベルのアクセス制御特殊ケース（OUTER JOIN）への対応参考情報：Fedora 8 以降での SE-PostgreSQL

SE-PostgreSQLによるセキュアDB構築連載インデックス

Security&Trust フォーラム新着記事

Windows起動前後にデバイスを守る工夫、ルートキットを防ぐ （2017/7/24）
Windows 10が備える多彩なセキュリティ対策機能を丸ごと理解するには、5つのスタックに分けて順に押さえていくことが早道だ。連載第1回は、Windows起動前の「デバイスの保護」とHyper-Vを用いたセキュリティ構成について紹介する。
WannaCryがホンダやマクドにも。中学3年生が作ったランサムウェアの正体も話題に （2017/7/11）
2017年6月のセキュリティクラスタでは、「WannaCry」の残り火にやられたホンダや亜種に感染したマクドナルドに注目が集まった他、ランサムウェアを作成して配布した中学3年生、ランサムウェアに降伏してしまった韓国のホスティング企業など、5月に引き続きランサムウェアの話題が席巻していました。
Recruit-CSIRTがマルウェアの「培養」用に内製した動的解析環境、その目的と工夫とは （2017/7/10）
　代表的なマルウェア解析方法を紹介し、自社のみに影響があるマルウェアを「培養」するために構築した動的解析環境について解説する
侵入されることを前提に考える――内部対策はログ管理から （2017/7/5）
人員リソースや予算の限られた中堅・中小企業にとって、大企業で導入されがちな、過剰に高機能で管理負荷の高いセキュリティ対策を施すのは現実的ではない。本連載では、中堅・中小企業が目指すべきセキュリティ対策の“現実解“を、特に標的型攻撃（APT：Advanced Persistent Threat）対策の観点から考える。