보안 모델 개요

NeoSQL의 보안은 "운영자조차 보지 못하게 만드는 것"이 목표입니다.

표준 보호 — 모든 프로젝트에 자동 적용

프로젝트를 만드는 즉시, NeoSQL은 다음 15개 자격증명 필드를 AES-256-GCM으로 암호화하여 저장합니다.

암호화되는 15개 필드

• Connection 레벨 (프로젝트 멤버 공유): host · port · URL · database · DB user · DB password · SSL client cert · SSL client key · SSL client key password
• 사용자 레벨 (멤버별 개인): SSH username · SSH password · SSH private key · SSH passphrase · proxy username · proxy password

AWS KMS Envelope Encryption

프로젝트마다 별도 DEK(Data Encryption Key)를 발급하고, DEK 자체는 AWS KMS Customer Master Key로 다시 한 번 암호화하여 저장합니다. 서버 데이터베이스가 통째로 유출되어도 KMS 키 없이는 어떤 자격증명도 복호화할 수 없습니다.

UI에는 평문 자격증명이 절대 노출되지 않음

커넥션 목록, 프로젝트 화면, ERD 어디에서도 비밀번호·인증서 등 민감 필드는 평문으로 표시되지 않습니다. 편집 모달에서만 마스킹된 입력으로 다룹니다.

표준 보호 — 암호화 흐름 다이어그램

사용자 → KMS-DEK → AES-256-GCM → 15개 필드. KMS CMK가 DEK를 봉인하므로 운영자라도 KMS 권한이 분리되어 있으면 자격증명에 접근할 수 없습니다.

NeoSQL 관리자 접근 정책

관리자 사이트(CMS)에서도 사용자의 DB 접속 정보는 어떤 화면에도 표시되지 않습니다. 사용자 ID·이메일·구독 상태 등 운영 데이터만 노출됩니다.

표준 모드에서는 만에 하나 운영자가 코드 접근권 + KMS 권한을 동시에 보유한 상태로 데이터베이스에 직접 접근하면 KMS API를 통해 복호화할 수 있는 가능성이 남습니다. 일반 회원에게는 충분하지만, "운영자조차 절대 못 보게" 만들고 싶다면 Zero-Knowledge 모드를 함께 사용하세요.

Zero-Knowledge 모드 (옵션)

Zero-Knowledge 모드는 표준 보호 위에 사용자만 가진 비밀 키(passphrase) 한 겹을 더 얹습니다. 이 비밀 키는 NeoSQL 서버에 절대 저장되지 않으며, 운영자가 가진 어떤 권한으로도 복호화할 수 없습니다.

동작 원리

• 비밀 키는 클라이언트(Electron 또는 브라우저)에서만 다뤄지며, 서버로는 절대 평문이 전송되지 않습니다.
• 비밀 키는 Argon2id KDF로 KEK_user(32바이트 암호화 키)를 도출하고, 이 KEK_user로 DEK를 한 번 더 wrap해 저장합니다.
• 잠금해제 시 사용자 단말이 비밀 키로 KEK_user를 재생성하고, 평문 DEK를 풀어 클라이언트 메모리(브라우저/Electron Pinia store)에만 보관합니다. 프로젝트 API 호출마다 DEK를 HTTP 헤더(X-Neosql-Zk-Dek)로 동봉해 전달하고, 서버는 단일 요청 처리 동안만 사용한 뒤 즉시 zero-fill 합니다 — 장기 보관되는 서버 측 DEK 캐시는 존재하지 않습니다.
• 평문 DEK는 한 단말의 클라이언트 메모리(브라우저 탭 또는 Electron 프로세스)에만 살아 있으므로, 같은 사용자라도 데스크탑·웹·다른 PC는 각각 별도로 잠금해제해야 합니다.

Zero-Knowledge — 암호화 흐름 다이어그램

사용자 비밀 키 → Argon2id → KEK_user → KMS-DEK 위에 한 겹 추가. 평문 DEK는 런타임에 클라이언트 메모리에만 살아 있고, 서버로는 매 요청 X-Neosql-Zk-Dek 헤더로 전달됩니다 (서버 측 캐시 없음). 비밀 키 없이는 KEK_user를 만들 수 없고, 만들지 못하면 DEK도 풀 수 없습니다.

Zero-Knowledge 적용 시작하기

프로젝트의 "비밀 키 잠금" 버튼으로 활성화합니다. 빈 프로젝트는 신규 키 발급, 이미 자격증명이 있는 프로젝트는 옛 DEK로 15개 필드를 풀어 신규 DEK로 자동 재암호화합니다.

1

1. 프로젝트 우측 상단 "비밀 키 잠금" 클릭

프로젝트 소유자만 클릭 가능. 멤버에게는 비활성화로 표시됩니다.

2

2. 비밀 키 생성 또는 직접 입력

권장: 32자 자동 생성. 또는 12자 이상 직접 입력 가능. 한글·이모지·기호 모두 허용. 강도 미터로 약한 키는 거부됩니다.

3

3. 비밀 키 백업 (가장 중요)

딱 한 번 표시되는 키를 1Password 등 안전한 곳에 보관. .txt 다운로드 또는 클립보드 복사. "분실 시 복구 불가능" 두 단계 확인 후 진행됩니다.

4

4. 자동 잠금해제 + 작업 시작

셋업 직후 자동으로 잠금해제됩니다. 기존 connection이 있던 프로젝트라면 15개 필드가 신규 DEK로 재암호화되어 운영자가 보유했을 옛 키도 무효화됩니다.

잠금해제와 자동 잠금

다음에 프로젝트 진입 시 비밀 키를 입력해야 잠금해제됩니다. Desktop 모드에서는 "이 컴퓨터에 안전하게 저장"을 체크해 OS 키체인에 보관할 수 있고, 그 단말은 다음부터 자동 잠금해제됩니다 (브라우저는 OS 키체인 직접 접근 불가).

자동 잠금 시간 설정

마이페이지 → 보안 메뉴에서 사용자별 자동 잠금 시간을 직접 선택합니다 (1분 / 5분 / 30분 / 8시간 / 끄지 않음). 무활동 시간이 초과되면 클라이언트 메모리의 평문 DEK가 자동으로 zero-fill되고, 다음 작업에서 다시 비밀 키를 요구합니다.

잠금/변경/해제 메뉴

프로젝트의 LOCK 버튼 드롭다운에서 "지금 세션 잠그기", "비밀 키 변경", "비밀 키 잠금 해제(영구)"를 수행할 수 있습니다. 모두 프로젝트 소유자만 가능합니다.

팀 협업 — 비밀 키 공유 방법

비밀 키는 NeoSQL이 보관하지 않으므로 외부 채널(1Password 공유 항목, 사내 vault, Slack DM 등)을 통해 팀원에게 직접 전달합니다. NeoSQL은 비밀 키 전달 자체에 관여하지 않습니다 — 그것이 "운영자도 모른다"는 보장의 본질입니다.

각 팀원은 자기 단말에서 처음 진입 시 비밀 키를 입력하고, Desktop이라면 "이 컴퓨터에 안전하게 저장"으로 다음부터 자동화할 수 있습니다.

비밀 키 변경 시: 다른 팀원이 키체인에 저장해 둔 옛 키는 자동 무효화되며 다음 진입 시 "저장된 비밀 키로 잠금해제할 수 없습니다" 안내가 뜹니다. 새 키를 별도 채널로 다시 공유해 주세요.

비밀 키를 잃어버렸을 때

실무적 복구 절차

• ① DBA / vault / 팀원에게서 DB 접속정보를 다시 받는다.
• ② 새 프로젝트를 만들거나 기존 프로젝트의 Zero-Knowledge를 해제(불러올 수 없는 옛 암호 필드가 정리됨)하고 새 키로 다시 활성화한다.
• ③ 자격증명을 다시 입력한다.

ERD/SQL Editor 등 메타 데이터는 별도 마이그레이션 도구로 옮길 수 있습니다.

이 트레이드오프가 부담스럽다면 표준 모드만 사용하세요. 표준 모드는 NeoSQL 운영자가 (이론적으로) 복구를 도울 수 있습니다.

정직한 안내 — 한계점

• 프로젝트가 잠금해제된 동안 평문 DEK는 클라이언트(브라우저/Electron) 메모리에만 보관됩니다. 서버로는 매 요청 헤더(X-Neosql-Zk-Dek)로 짧게 전달되어 단일 요청 처리 중에만 JVM 메모리에 머문 뒤 즉시 zero-fill 됩니다. 운영자가 RAM 덤프를 시도해도 장기 보관되는 서버 측 DEK 캐시 자체가 존재하지 않습니다.
• 브라우저 환경에서는 OS 키체인 직접 접근이 불가능해 진입 시마다 비밀 키 입력이 필요합니다. Desktop 앱은 OS 키체인 자동 잠금해제 옵션을 제공합니다.