12.6.1 읽기 전용(Read-Only) 사용자 권한 및 트랜잭션 롤백(Rollback) 전략

의도적으로 파괴 공작을 일삼으려는 해커의 프롬프트 인젝션(Prompt Injection)이든, 혹은 아무 지능이 없는 LLM의 단순한 생성 환각(Hallucination)이든 상관없이, 데이터베이스 샌드박스의 최전방 보안 인프라는 가장 먼저 시스템 엔진 내부 자체의 권한 통제 메커니즘을 물리적으로 격리 통제하는 것에서 출발해야 한다. AI 모델 에이전트가 어떤 수단을 써서 파괴적인 DDL(Data Definition Language: DROP, ALTER)이나 DML(Data Manipulation Language: DELETE, UPDATE) 쿼리를 생성하여 파이프라인으로 전송하더라도, 데이터베이스 엔진 단에서 이를 원천적으로 승인하지 않고 튕겨내는 ‘읽기 전용(Read-Only) 접속 세션’ 환경을 샌드박스 프로비저닝(Provisioning) 단계에 하드코딩(Hardcoding)해 두는 것이 절대적인 제1방어 원칙이다.

1. 전용 R/O (Read-Only) 사용자의 물리적 생태계 격리 (Role Mapping)

오라클 채점 파이썬 애플리케이션 플랫폼이 샌드박스 컨테이너 내부의 데이터베이스와 커넥션(Connection Pool)을 맺을 때, 절대로 admin, root, 또는 postgres와 같은 슈퍼 관리자 계정의 자격 증명(Credentials)을 사용해서 마운트 해서는 안 된다. 샌드박스의 스키마 내부에는 오로지 조회 및 추출 연산(SELECT) 하나만을 허용하도록 GRANT/REVOKE 명령어로 권한을 극도로 무자비하게 차폐시킨 oracle_readonly_sandbox_user 와 같은 더미(Dummy) 평가용 계정을 의무적으로 단독 생성하여 연결해야만 한다.

-- PostgreSQL 인프라 환경에서의 읽기 전용 샌드박스 유저 세팅 아키텍처 예시
CREATE USER oracle_readonly_user WITH PASSWORD 'secure_random_hash_pwd';

-- 1. 먼저 모든 스키마의 권한을 무자비하게 박탈한다.
REVOKE ALL ON ALL TABLES IN SCHEMA public FROM oracle_readonly_user;
REVOKE ALL PRIVILEGES ON DATABASE test_sandbox_db FROM oracle_readonly_user;

-- 2. 해당 데이터베이스에 접근할 수 있는 최소한의 브릿지 권한만 개방한다.
GRANT USAGE ON SCHEMA public TO oracle_readonly_user;

-- 3. 스키마 내부의 모든 테이블에 대해 오직 SELECT(읽기) 연산만을 정밀 타격하여 허락한다.
GRANT SELECT ON ALL TABLES IN SCHEMA public TO oracle_readonly_user;

이 1차적이고 물리적인 계정 격벽(Separation) 설정을 통해, 최악의 경우 AI 모델이 DROP TABLE employees CASCADE; 라는 끔찍한 파괴 쿼리를 생성해 샌드박스 파이프라인을 통과시키더라도, PostgreSQL 데이터베이스의 네이티브 엔진은 1밀리초 내에 즉시 Permission Denied 예외(Exception)를 반환하며 접근을 차단하게 된다. 오라클의 파이썬 인터프리터는 이를 잡아채어 앞선 12.5.5절에서 정의한 CRITICAL_SECURITY_VIOLATION_DETECTED 최상위 적색경보 0점 패널티를 부여하고, 전체 시스템 스키마를 상처 하나 없이 무사히 지켜낼 수 있게 되는 것이다.

2. 세션 단위의 강력한 트랜잭션 롤백 (Passive Transaction Rollback) 메커니즘

하지만 RDBMS의 세계에서 최고 수준의 안정성 트러스트(Security Trust)를 백업 확보하기 위해서는 이 1차원적인 R/O 유저 권한 매핑 하나만으로 안심해서는 안 된다. 여러 파이프라인이 하나의 엔드포인트를 공유하는 특정 분산 데이터베이스 환경이거나, 또는 극단적으로 SQLite 모델과 같이 계정에 대한 세밀한 접근 권한 제어(Access Control) 자체가 스펙 한계로 불가능한 경량 파일 시스템 기반의 가상 환경에서는, ‘트랜잭션(Transaction) 롤백(Rollback)’ 전략을 평가 파이프라인 커넥터 레벨에서 2차 패시브(Passive) 물리 방어막으로 구축해 두어야 한다.

이 방어 기법은, 파이썬 드라이버가 미지의 AI 쿼리를 실행하기 직전 커넥션의 트랜잭션을 프로그램 단에서 강제로 제어 권한을 탈취하여 스스로 열어버린 뒤(BEGIN TRANSACTION), AI의 모든 연산을 수행하고 그 반환된 결과 튜플 데이터를 파이썬 메모리로 끌어올림(Fetch)과 동시에, 데이터베이스 시스템을 향해 뒤도 돌아보지 않고 무조건 하드 ROLLBACK 커맨드를 강제 타격해 버리는 무자비한 소멸 구조다.

# 파이썬(Python) 커넥터 환경에서의 트랜잭션 롤백(Rollback) 패시브 방어망 구축 예제
def execute_ai_query_safely(db_cursor, ai_predicted_sql_query):
    try:
        # 오라클이 강제로 트랜잭티브(Transactive) 생명 주기를 통제하기 시작한다.
        db_cursor.execute("BEGIN TRANSACTION;")
        
        # AI의 위험한 미지의 쿼리를 스캔 및 실행
        db_cursor.execute(ai_predicted_sql_query)
        result_tensor = db_cursor.fetchall()
        
        # 무사히 데이터를 뜯어냈다면 텐서를 반환
        return result_tensor
        
    finally:
        # [핵심 방어선] 쿼리의 성공/예외 발생/데이터 추출 내용 여부와 일절 무관하게,
        # try 블록을 빠져나오는 순간 무조건적으로 현재 트랜잭션 컨텍스트를 폭파(폐기)한다.
        db_cursor.execute("ROLLBACK;") 

이 무자비한 패시브 롤백(Rollback) 파이프라인 강제화 전략은, 고급 AI 모델이 복잡한 추론 로직을 전개하기 위해 스레드 내부에서 일시적인 비휘발성 임시 테이블(Temporary Table)을 마음껏 생성(CREATE TEMP TABLE)하는 창의적인 자유도 높은 허용 공간을 부여함과 동시에, 그 어떠한 디스크 메모리나 스키마의 미세한 물리적 오염이나 인젝션 조작 변경 사항조차 파이썬 함수 스레드의 종료(Finally) 시점에 완벽하게 시계열 0(T=0) 상태로 물리적 소멸되도록 보장하는 가장 혁신적이고 파괴적인 영지식(Zero-Knowledge) 복구폭파 매커니즘이라 할 수 있다.