서문

CCPA, GDPR, ISO 27001과 같은 글로벌 컴플라이언스를 준수해야 하는 기업이 전세계적으로 빠르게 증가하고 있습니다. 이러한 비즈니스 환경의 변화로 일관된 데이터 관리와 보안이 기업활동의 필수요소로 부상하고 있는 추세입니다. 실제, 데이터베이스 시스템은 다양한 플랫폼과 쿼리 언어를 통한 접근이 일반적이지만, 데이터베이스마다 문법과 동작이 다르기 때문에 일관된 접근 제어와 모니터링이 여간 까다롭지 문제입니다. 이에, 오늘은 여러 데이터베이스의 쿼리를 하나의 추상 구문으로 통합하고 실시간 분석을 통해 데이터베이스 쿼리 보안의 기반을 제공하는 솔루션을 소개해 보겠습니다.

Step.1 문제의 발견: 다양한 데이터베이스의 문법 차이는 관리 복잡성을 야기한다!

대규모 기업 및 데이터 중심 조직은 MySQL, SQL Server, PostgreSQL, Oracle과 같은 전통적인 SQL 데이터베이스뿐만 아니라 MongoDB 와 같은 NoSQL 데이터베이스도 동시에 사용합니다. 데이터베이스마다 쿼리 문법과 동작이 다르기 때문에 동일한 보안 정책을 일관되게 적용하기가 쉽지 않습니다. 특히 데이터베이스의 확장되고 복잡해짐에 따라 쿼리의 통제와 보안 관리의 난위도는 높아지게 되어 결국, 잠재적인 보안 위협으로 이어질 수 있습니다. 이러한 복잡성은 GDPR이나 CCPA와 같은 개인정보 보호 규제의 요구 사항을 충족하는 데에도 걸림돌이 됩니다.

다음은 데이터베이스별로 행 수를 제한하는 쿼리의 예시입니다:

MySQL

• SELECT * FROM {table} LIMIT 10

SQL Server

• SELECT TOP 10 * FROM {table}

Oracle

• SELECT * FROM {table} FETCH FIRST 10 ROWS ONLY

MongoDB

• db.getCollection('{table}').limit(10);

그래서, 데이터베이스 쿼리 제어가 중요하다.

오늘날 데이터 유출 사고의 절반 이상은 내부자나 부적절한 접근 통제에서 기인합니다. 예를 들어, 일부 비인가 사용자가 고도의 권한이 필요한 데이터를 조회하는 경우, 기존의 접근 제어 체계로는 이들을 효과적으로 차단하기 어렵습니다. 쿼리 접근을 제대로 관리하지 않으면 데이터 유출이나 악의적인 사용이 발생할 가능성이 높아집니다. 무엇보다 데이터를 직접 다루는 직원이나 분석가가 민감한 데이터를 포함한 대규모 쿼리를 실행할 경우 그 결과는 예측하기 어렵고, 이는 회사의 주요 자산인 데이터를 높은 손실 위험에 고스란히 노출하는 격이 됩니다.

Step 2. 목표의 설정: 글로벌 컴플라이언스 요구사항을 충족하는 솔루션을 찾아라!

이러한 문제를 해결하기 위해서는 다양한 데이터베이스에 대해 일관된 보안 정책을 적용할 수 있는 기술이 필요합니다. 이는 ISO 27001의 정보 보안 관리 시스템 구현과 GDPR, CCPA에서 요구하는 데이터 보호 및 개인정보 관리의 기반이 됩니다. QueryPie는 이러한 글로벌 컴플라이언스 요구 사항을 충족하기 위한 기반 기술을 고민했습니다.

일관된 보안 정책 적용을 위한 QueryPie 솔루션의 3가지 핵심 접근 방식

다양한 데이터베이스에 일관된 보안 정책을 적용하기 위한 세 가지 핵심 접근 방식을 제안합니다.

• 다양한 데이터베이스 쿼리의 AST 통합: MySQL, SQL Server, Oracle, MongoDB 등 다양한 데이터베이스의 쿼리 문법을 하나의 추상 구문 트리(Abstract Syntax Tree, AST)로 통합합니다. 이를 통해 각기 다른 데이터베이스의 쿼리를 일관되게 처리하고 분석할 수 있습니다.

• 실시간 쿼리 분석 및 결과 예측: 실시간으로 AST를 분석하면서 데이터베이스의 스키마 정보를 조회하여 쿼리의 실행 결과를 예측합니다. 이를 통해 사용자나 애플리케이션이 수행하는 쿼리의 영향 범위를 사전에 파악할 수 있습니다.

• 객체 간 관계의 세밀한 분석: 쿼리에 포함된 테이블, 컬럼 등 데이터베이스 객체 간의 관계를 상세히 분석합니다. 이를 통해 데이터 흐름을 추적하고, 민감한 데이터에 대한 접근을 효과적으로 탐지하여 내부자 위협을 방지합니다.

기술적 설명

실행 단계

실행 단계는 다음과 같이 네 가지로 구분됩니다: 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)을 통해 데이터의 가공 과정을 나타내고, 다양한 데이터 처리 연산을 구조화합니다.