さまざまなベンダーのSQL解析のためのコア技術、QSI（Query Structural Interface）

一貫したセキュリティポリシー適用のためのQueryPieの3つの主要なアプローチ

多様なデータベースに一貫したセキュリティポリシーを適用するために、以下の3つの主要なアプローチを提案します。

• 多様なデータベースクエリのAST統合: MySQL、SQL Server、Oracle、MongoDBなど、多様なデータベースのクエリ文法を単一の抽象構文木（Abstract Syntax Tree, AST）に統合します。これにより、異なるデータベースのクエリを一貫して処理および分析することが可能になります。
• リアルタイムクエリ分析と結果予測: ASTをリアルタイムで分析しながら、データベースのスキーマ情報を参照してクエリの実行結果を予測します。これにより、ユーザーやアプリケーションが実行するクエリの影響範囲を事前に把握することができます。
• オブジェクト間の関係の精密な分析: クエリに含まれるテーブルやカラムなど、データベースオブジェクト間の関係を詳細に分析します。これにより、データフローを追跡し、機密データへのアクセスを効果的に検出して内部脅威を防止します。

技術的説明

実行段階

実行プロセスは以下の 4つの段階に分類されます：INPUT、 RAW AST、 QSI AST、 Analysis Result

• まず、INPUT段階では、クエリを受け取り、RAW AST（抽象構文木）にパースして構文構造を把握します。
• 次に、QSI AST段階で構文木を意味的構文木に変換し、各クエリ要素間の論理的関係を定義します。
• 最後に、Analysis Result 段階では、分析された情報を基に最終結果を生成し、クエリ結果がどのように構成されるかを予測するモデルを提供します。

INPUT

データベースクエリが原文のまま入力されます。

SELECT * FROM sakila.actor

RAW AST

RAW ASTは、入力されたデータベースクエリをパースした際に、基礎的なパーサーが出力する結果を指します。 基礎的なパーサーは、ANTLR、YACC、JavaCCなどのよく知られたパーサージェネレーターを使用して実装されており、これによりデータベースごとに構文構造を分析したAST（抽象構文木）の結果が異なる可能性があります。同じパーサージェネレーターを使用していても、文法が異なる場合、MySQLのSELECT 1クエリとOracleのSELECT 1 FROM DUALクエリが意味的に等しいことを認識することはできません。 データベースごとのSELECT * FROM actorの例：

MySQL (ANTLR4)

Oracle (ANTLR4)

PostgreSQL (YACC)

QSI AST

QSI ASTは、データベースクエリの意味的構造を表現します。主に派生（Derivation）、結合（JOIN）、元データ（Source）を通じてデータ加工の過程を表し、さまざまなデータ処理演算を構造化します。以下に各要素の説明を示します。

データ参照 実際のデータが保存されているテーブルや元データへの参照を表します。 例: actor という識別子は、データベースに保存された特定のテーブルを参照し、そのデータを取得する操作を行います。

派生テーブル 特定のテーブルから派生した新しいデータを表します。 例: SELECT name AS n FROM actorクエリでは、actorテーブルのnameカラムにnという別名を付けて新しい形式として提供します。

結合テーブル 複数のテーブルを結合し、関連付けられたデータを1つの結果として提供する構造です。 例: SELECT * FROM address JOIN city USING (city_id)クエリでは、addressとcity テーブルをcity_idを基準に結合し、両テーブルの関連データを取得します。

複合テーブル結合 複数の結果セットを結合する操作をサポートするノードです。 例: SELECT 1 UNION ALL SELECT 2クエリでは、2つのSELECT結果を1つのテーブルに結合して返します。

インライン派生テーブル 特定の値をテーブル形式で直接提供する方法を指します。 例: VALUES (1,2), (3,4)クエリは、2つの行と2つの列を持つ小さなテーブルを生成し、その場で使用可能な形にします。

テーブル関数呼び出し 特定の関数を呼び出し、テーブル形式のデータを返す構造を表します。 例: SELECT * FROM table_function()クエリでは、table_function()という関数が返すテーブル形式のデータを取得します。

分析結果

最終的な分析結果として、入力クエリに基づいて返される構造化されたデータモデルを提供します。

特に、SELECTクエリのようにテーブル形式で出力されるクエリの分析結果は以下の項目で構成されます。

• 最終カラム一覧
  • SELECT句で指定されたカラムのリストを指し、テーブルの最終的なカラム結果を意味します。
• 参照カラム一覧
  • サブクエリのカラム、関数で使用されたカラムなど、データの出所となるすべてのカラムを指します。
• 参照テーブル一覧
  • データが保存されている元のテーブルや、別名として指定されたテーブル、共通テーブル式（CTE）など、結果がテーブル形式となるものを指します。
• 間接カラム一覧
  • 結果のカラムに直接影響を与えないが、WHEREやHAVING句などで使用されるカラムを指します。

例 入力クエリ

SELECT a.address || ', ' || c.city AS addr,
a.phone                     AS phone
FROM address AS a, city AS c
WHERE a.city_id = c.city_id

分析結果

View

クエリに記述されたテーブルがViewのようにデータを参照している場合、View 定義を確認・分析し、データが保存されている元のテーブルまで追跡します。このプロセスでは、以下の手順を経て View の内容を解釈します。

View定義

CREATE VIEW sakila.actor_view (
id,
full_name,
update_at
) AS
SELECT actor_id,
first_name || last_name,
last_update
FROM actor

入力クエリ

SELECT * FROM actor_view

分析結果

ユースケースを徹底的に検証：模範的な実践例

QueryPieは、データセキュリティを強化し、GDPRやCCPA、ISO 27001などのグローバルコンプライアンスを遵守するため、以下のような詳細なアプローチと技術を導入しています。

データアクセス制御

• 細分化された権限設定: テーブルおよびカラムレベルでアクセス権限を細かく設定し、最小権限の原則を遵守します。

データマスキング

• 動的データマスキング: リアルタイムでデータを照会する際、ユーザー権限に応じて機密情報がマスキングされるように設定します。
• マスキングポリシー管理: マスキングルールを中央で一元管理し、一貫性を保ちます。

機密データモニタリング

• アクセス通知および警告システム: 機密データへのアクセスが発生した際、リアルタイムで管理者に通知を送信します。
• ログおよび監査追跡: すべてのデータアクセス活動を詳細に記録し、後日の監査や分析に活用します。
• 異常行動検出: 機械学習などを活用し、異常なデータアクセスパターンを特定して対応します。

台帳テーブル保護

• アクセス制限およびモニタリング: 財務や会計に関連する台帳テーブルへのアクセスを厳しく制限し、アクセス時にモニタリングを強化します。
• データの整合性維持: 台帳データの変更が必要な場合、承認プロセスを経るようワークフローを構築します。

QSI: データセキュリティの革新、信頼と競争力を高める秘訣！

現代の企業は、多様なデータベース環境と複雑なグローバルコンプライアンス要件の中で、データセキュリティを維持するという課題に直面しています。本記事で紹介した QSI は、こうした課題を克服するための基盤技術を提供します。

さまざまなベンダーのクエリパースを統合し、リアルタイムでクエリを分析することで、企業は一貫したセキュリティポリシーを適用し、データ漏洩のリスクを最小化できます。また、優れた実践例を適用することで、データアクセス制御、データマスキング、機密データのモニタリング、台帳テーブルの保護などを強化し、**ISO 27001、GDPR、CCPAといったグローバルコンプライアンス要件を効果的に遵守できます。

データセキュリティは単なるリスク回避にとどまらず、企業の信頼性と競争力を向上させる重要な要素です。企業はQSIを活用することで、複雑なデータベース環境においても安定的にデータを管理し、規制遵守による法的リスクを最小化しつつ、ビジネス目標の達成により一層注力することができます。