E-sign SaaS · legal evidence

전자서명은 기능이 아니라 법적 증거력이 제품의 본질입니다. '서명됐다'는 기록 자체가 공격받으면 제품 전체가 무너집니다. 위변조가 불가능한 기록 체계를 갖춘 SaaS 를 개발 조직 없이 혼자 출시해야 했고 — 그래서 기능보다 신뢰 구조를 먼저 박았습니다.

• 01'인증됨' 을 기록할 수 있는 주체 = 백엔드 워커 단 1곳. 인증용 개인키는 웹 서버와 물리적으로 분리 — 웹이 통째로 뚫려도 공개키뿐이라 신원 위조 불가
• 02테넌트 격리를 앱 코드 where 절이 아닌 DB 행 단위 보안(RLS)으로 강제 — 코드 한 줄 실수가 타사 데이터 노출로 못 이어지는 계층에 격리를 둠
• 03감사 체인을 국가 공인 시각 인증(TSA)으로 서버 밖에 앵커링 — 서버 키를 가진 운영자 자신도 과거 기록을 조작할 수 없음
• 04모든 안전장치 테스트에 음성 대조 — '장치를 빼면 반드시 실패해야 한다' 를 표준으로
• 05스키마 변경은 전방 전용(forward-only) 마이그레이션 + 롤백 스냅샷 + 배포 런북 문서화

신뢰는 코드 리뷰가 아니라 구조에서 나옵니다. '조심히 운영한다' 가 아니라 위조 가능한 경로 자체를 0개로 만들면 됩니다 — 웹이 뚫려도, 코드가 실수해도, 운영자가 마음먹어도 안 되는 구조.

• 011인 개발·운영 — 사람이 못 보는 곳은 구조가 대신 막아야 함
• 02관리형 DB(RDS)가 특정 권한을 허용하지 않음 — RLS 권한 부트스트랩 방식 재설계 필요
• 03법적 증거 = 운영자 자신도 신뢰의 예외가 될 수 없음
• 04테스트 초록불조차 그대로 믿을 수 없다는 걸 이 프로젝트에서 실제로 겪음

• 신원인증 결과를 기록하는 주체를 백엔드 워커 1곳으로 제한 + 인증 개인키를 웹 서버와 물리 분리

  buy키 관리·배포 복잡도 ↑ → 공격 표면이 가장 넓은 웹 계층이 통째로 뚫려도 신원 위조 불가

• 감사 체인 완성 후 스스로에게 질문 — '서버 키를 가진 운영자(나)가 장부를 통째로 다시 쓰면 잡히는가?' 답은 '못 잡는다' 였습니다. 서버 안에서는 원리적으로 방어 불가 → 기록 해시를 국가 공인 시각 인증(TSA)으로 서버 밖에 앵커링

  buy외부 벤더 연동·운영 제약 ↑ → 내부자(운영자 포함)의 과거 조작이 원리적으로 불가능한 구조

• 테넌트 격리를 DB 행 단위 보안(RLS)으로 — 앱 코드가 아니라 실수해도 안 뚫리는 계층에

  buyRDS 권한 제약에 맞춰 부트스트랩 재설계 비용 → 코드 한 줄 실수 ≠ 타사 데이터 노출

• 동시성 안전장치 테스트를 '장치 제거 시 반드시 실패' 음성 대조와 함께 재작성

  buy테스트 작성 비용 2배 → 아무것도 검증하지 않는 초록불(허수 테스트) 차단

동시성 안전장치 검증 테스트가 전부 통과 중이길래 장치를 일부러 제거하고 다시 돌렸습니다 — 여전히 통과. 검증 범위를 넓게 잡은 탓에 아무거나 걸려 통과하는 허수 테스트였습니다. 블록 대상을 정밀 지정하는 방식으로 재작성했고, 이후 모든 안전장치 테스트는 음성 대조가 표준입니다. 제품은 PASS 본인인증 · TSA · 결제 실연동 상태로 프로덕션 라이브입니다.

PASS 본인인증 · 공인 타임스탬프(TSA) · 결제 실연동 상태로 프로덕션 라이브.

가장 어려운 문제는 외부가 아니라 제 시스템을 제가 공격하면서 나왔습니다. 법적 증거가 되려면 저 자신도 신뢰의 예외가 아니어야 한다 — 이게 이 제품에서 내린 결론이고, 이후 모든 설계의 기준이 됐습니다.