CipherStash Stack을 이용한 데이터 레벨 액세스 제어 구현

전통적인 보안 모델에서 애플리케이션 액세스는 세션 뒤에 있는 인간 사용자를 중심으로 이루어집니다. 그러나 도구를 체이닝하고, 프롬프트를 통해 데이터를 확산시키며, 로그와 트레이스를 가로질러 작동하는 AI 에이전트의 부상은 이러한 가정을 깨뜨립니다. 에이전트가 사용자를 대신하여 행동할 때, 에이전트가 침해되거나 프롬프트 인젝션(prompt-injected)될 경우 상당한 보안 위험을 초래할 수 있는 광범위한 권한을 상속받는 경우가 많습니다.

CipherStash Stack은 **데이터 레벨 액세스 제어(Data Level Access Control, DLAC)**를 도입합니다. 이는 보안을 경계나 행 레벨에서 개별 데이터 값으로 이동시키는 패러다임의 전환입니다. 각 민감한 데이터 조각이 자체 암호화를 보유하고 복호화 권한이 특정 ID에 결합되도록 보장함으로써, CipherStash는 보호 기능이 데이터가 이동하는 모든 곳에 함께 전달되도록 보장합니다.

CipherStash Stack의 5가지 핵심 요소

CipherStash Stack은 조립 가능한 빌딩 블록 세트로 설계되어, 팀이 "big-bang" 마이그레이션 대신 한 번에 하나의 필드씩 점진적으로 DLAC를 채택할 수 있도록 합니다.

1. 값 레벨 암호화

디스크를 보호하는 encryption-at-rest와 달리, CipherStash는 개별 필드에 대한 검색 가능한 암호화를 제공합니다. EQL을 사용하여 Postgres는 암호문(ciphertext) 위에서 직접 필터링, 정렬 및 조인을 수행할 수 있습니다. 이는 데이터가 저장되어 있을 때(at rest)뿐만 아니라 전송 중(in transit)일 때도, 그리고 *사용 중(in use)*일 때도 암호화된 상태로 유지됨을 의미합니다.

2. ZeroKMS 키 관리

모든 개별 값에 대해 고유한 데이터 키를 관리하는 것은 일반적으로 계산 비용이 많이 듭니다. ZeroKMS는 AWS KMS를 기반으로 하는 초고속 키 서비스로 작동하여 이 문제를 해결합니다. AWS KMS를 직접 호출하는 것보다 최대 14배 더 빠르다고 보고되었으며, 복잡한 애플리케이션 측면의 키 캐싱의 필요성을 제거합니다.

3. 투명한 SQL 프록시

코드 변경이 불가능한 레거시 애플리케이션이나 BI 도구의 경우, CipherStash Proxy가 앱과 Postgres 사이에 위치합니다. 이는 SQL 문을 투명하게 재작성하여 입력 시 파라미터를 암호화하고 출력 시 결과를 복호화함으로써, 개발자가 DLAC를 유지하면서 일반 SQL을 사용할 수 있도록 합니다.

4. ID 기반 인증

CipherStash는 OIDC 제공업체(예: Auth0)와 통합되어 복호화가 실제 엔드 유저 ID에 대해 승인되었는지 확인합니다. 이를 통해 공유 서비스 계정이나 수명이 긴 키에 대한 의존성을 제거합니다. CipherStash Token Service는 모든 복호화 요청에 대해 클레임(claims)을 검증하고 매핑합니다.

5. 에이전트 스킬

개발자(또는 AI 에이전트)가 암호화를 "hand-rolling"하는 흔한 실수를 방지하기 위해, CipherStash는 agent skills를 제공합니다. 이는 AI 코딩 어시스턴트가 처음부터 올바르게 스택을 구현할 수 있도록 하는 문서화된 빌딩 블록으로, 보안 결정이 풀 리퀘스트(pull requests)에서 검토 가능한 코드로 캡처되도록 보합니다.

TypeScript에서의 기술적 구현

DLAC를 구현하는 것은 암호화 스키마를 정의하는 것부터 시작됩니다. 개발자는 어떤 필드가 암호화되어야 하는지, 그리고 어떤 유형의 검색 가능한 작업이 필요한지 지정할 수 있습니다:

import { encryptedTable, encryptedColumn } from '@cipherstash/stack/schema';

export const users = encryptedTable('users', { 
  email: encryptedColumn('text').equality().freeTextSearch(),
  meta: encryptedColumn('json').searchableJson(),
});

스키마가 정의되면, SDK가 암호화 및 쿼리 프로세스를 처리합니다:

import { client } from '@cipherstash/stack';
import { users } from './encryption/schema';

// 삽입을 위한 값 암호화
await db.insert(users).values({
  email: await client.encrypt('alice@example.com', { column: users.email }),
});

// 암호화된 용어를 사용하여 쿼리
const needle = await client.encrypt('alice@example.com', { column: users.email });
const rows = await db.select().from(users).where(eq(users.email, needle));

DLAC vs. 전통적인 보안 모델

DLAC를 다른 일반적인 데이터베이스 보안 전략과 구분하는 것은 중요합니다:

전략 보호 레벨 약점
Transparent DB Encryption 디스크/물리적 탈취된 자격 증명에 대해서는 아무런 조치도 취하지 못함; DB는 로그인한 모든 사용자에게 평문(plaintext)을 전달함.
Row-Level Security (RLS) 행/정책 정책이 DB 설정에 존재함; DB는 정책을 평가하기 위해 여전히 평문을 읽음.
Tokenization Vaults 외부 모든 읽기 작업이 볼트(vault)를 위한 왕복(round trip)이 필요하며, 애플리케이션 로직을 복잡하게 만듦.
CipherStash DLAC 값/암호학적 보호 기능이 데이터 자체의 속성임. 잘못 설정된 규칙은 평문 유출이 아닌 암호문을 전달함.

AI 에이전트 워크플로우 보안

CipherStash 모델에서 에이전트는 first-class identities로 취급됩니다. 인간의 세션을 빌려 쓰는 대신, 에이전트는 자체적인 키와 정책을을 가집니다. 암호화 레이어에서 강제 집행이됩니다. 에이전트는 명시적으로 액세스 권한을 부여받은 필드에 대해서만 복호화된 바이트를 볼 수 있습니다.

이 아키텍처는 프롬프트 인젝션에 대한 중요한 안전장치를 제공합니다. 에이전트가 데이터를 유출하도록 조작될 경우, 키를 가지고 있지 않은 데이터는 유출할 수 없습니다. 행 레벨 보안(Row-Level Security)이 에이전트가 가져올 수 있는 행을 제한할 수 있지만, CipherStash는 에이전트가 해당 행 내에서 실제로 무엇을 읽을 수 있는지를 제한합니다.

성능 및 프로덕션 규모

CipherStash는 에너지(Amber Electric), 의료(Journalia), 금융 규제 준수(BNDRY)를 포함한 고도로 규제된 산업 분야의 프로덕션 환경에서 10억 개 이상의 값을 보호하고 있다고 주장합니다. 1,000만 행 데이터셋에 대한 성능 벤치마크 결과, 정확히 일치하는 쿼리(exact-match queries)의 중앙값은 454μs이며 범위 쿼리(range queries)의 중앙값은 1.46ms입니다. 이는 값 레벨 암호화가 상당한 지연 시간(latency)을 비용으로 요구하지 않음을 보여줍니다.

Sources