왜 SaaS 보안이 B2B 의사결정의 핵심인가
B2B 고객이 SaaS 플랫폼을 도입할 때, 기능보다 먼저 묻는 질문이 있습니다.
"우리 데이터는 안전합니까?"
특히 공공기관, 복지센터, 교육기관처럼 개인정보를 다루는 조직에서 이 질문은 도입 여부를 결정하는 첫 번째 관문입니다. 기능이 아무리 뛰어나도 보안 수준이 기준에 미달하면 검토 대상에서 제외됩니다.
크로노젠은 이 현실을 정면으로 마주했습니다. 로그인 화면 하나에도 8겹의 보안 계층을 적용한 이유입니다.
크로노젠 인증 보안의 4가지 핵심 축
1. JWT 자동 순환 (Token Rotation)
일반적인 SaaS 서비스는 한 번 발급한 토큰을 만료 시까지 그대로 사용합니다. 이 토큰이 탈취되면 만료 시까지 공격자가 자유롭게 시스템에 접근할 수 있습니다.
크로노젠은 JWT 자동 순환 방식을 채택했습니다.
- 매 인증 요청마다 새로운 토큰을 발급합니다
- 이전 토큰은 즉시 무효화됩니다
- 토큰 탈취가 발생해도 피해 범위가 단일 세션으로 제한됩니다
이 방식은 금융권에서 사용하는 OTP(일회용 비밀번호)와 동일한 원리입니다. 매번 새로운 열쇠를 사용하기 때문에, 이전 열쇠를 복제해도 의미가 없습니다.
2. PKCE (Proof Key for Code Exchange)
OAuth 2.0 인증 흐름에서 가장 흔한 공격은 인증 코드 가로채기입니다. 사용자가 카카오나 구글로 로그인할 때, 발급되는 인증 코드를 중간에서 탈취하여 정상 사용자인 것처럼 위장하는 공격입니다.
크로노젠은 PKCE(Proof Key for Code Exchange) 를 적용하여 이 공격을 원천 차단합니다.
| 단계 | 일반 OAuth | 크로노젠 (PKCE 적용) |
|---|---|---|
| 인증 요청 | 코드만 요청 | 코드 + 고유 검증키 함께 전송 |
| 코드 교환 | 코드만 제출 | 코드 + 검증키 일치 확인 |
| 코드 탈취 시 | 그대로 사용 가능 | 검증키 없으면 사용 불가 |
PKCE는 RFC 7636 표준으로, Apple, Google, Microsoft 등 글로벌 기업이 모두 채택한 방식입니다. 크로노젠은 모든 OAuth 흐름에 PKCE를 기본 적용합니다.
3. Replay 공격 방어
Replay 공격은 정상적인 인증 요청을 녹화한 뒤 그대로 재전송하여 인증을 통과하는 공격입니다. 네트워크 패킷을 캡처할 수 있는 환경이라면 누구나 시도할 수 있는, 매우 현실적인 위협입니다.
크로노젠의 JWT Replay Prevention 시스템은 다음과 같이 동작합니다:
- 모든 토큰에 고유 식별자(jti)를 부여합니다
- 사용된 토큰의 식별자를 실시간으로 추적합니다
- 이미 사용된 토큰이 재전송되면 즉시 차단하고 관리자에게 알림을 발송합니다
한 번 사용된 토큰은 절대 재사용할 수 없습니다. 이것이 크로노젠의 인증 원칙입니다.
4. 이상 징후 탐지 (Anomaly Detection)
기술적 방어만으로는 충분하지 않습니다. 정상적인 자격증명으로 비정상적인 행동을 하는 경우도 탐지해야 합니다. 크로노젠은 다음 패턴을 실시간으로 모니터링합니다:
- 지리적 이상: 서울에서 로그인 5분 후 부산에서 다시 로그인 시도
- 빈도 이상: 단시간 내 반복적인 로그인 실패
- 시간 이상: 새벽 3시에 관리자 계정으로 대량 데이터 조회
- 패턴 이상: 평소와 다른 브라우저, OS, 디바이스에서의 접근
이상 징후가 탐지되면 즉시 세션을 차단하고 관리자에게 알림을 발송합니다. 사후 대응이 아닌 실시간 방어입니다.
데이터 보안: 증빙의 무결성을 지키는 구조
인증 보안이 "문을 잠그는 것"이라면, 데이터 보안은 "금고 안의 물건을 보호하는 것"입니다.
SHA-256 해시 체인
크로노젠의 DPU(Data Proof Unit)는 모든 기록에 SHA-256 해시를 부여하고, 이전 기록의 해시와 연결하여 체인을 형성합니다. 체인 중 하나라도 변조되면 이후 모든 해시가 불일치하므로, 위변조를 기술적으로 불가능하게 만듭니다.
Append-Only 감사 로그
크로노젠의 감사 로그는 추가만 가능하고 삭제와 수정이 불가능합니다. 12종류의 이벤트 타입을 추적하며, 누가, 언제, 무엇을, 어떤 근거로 수행했는지를 영구적으로 기록합니다.
AES-256 데이터 암호화
모든 데이터는 전송 시(TLS 1.3)와 저장 시(AES-256) 이중으로 암호화됩니다. AWS 인프라 위에서 운영되며, 99.9%의 가동률을 보장합니다.
ISO 27001 / SOC2 대응 현황
크로노젠은 아직 공식 인증을 취득하지 않았습니다. 하지만 기술적으로 이미 핵심 요구사항의 대부분을 충족합니다.
| 인증 항목 | 요구사항 | 크로노젠 현황 |
|---|---|---|
| 접근 제어 | 역할 기반 접근 통제 | RBAC + Actor 검증 구현 |
| 인증 관리 | 다중 인증, 세션 관리 | MFA + JWT 순환 + 세션 추적 |
| 감사 추적 | 변경 불가능한 로그 | Append-Only 감사 로그 |
| 데이터 암호화 | 전송/저장 암호화 | TLS 1.3 + AES-256 |
| 사고 대응 | 이상 징후 탐지 및 대응 | 실시간 Anomaly Detection |
| 개인정보 보호 | 법적 요건 준수 | PIPA 기반 관리 체계 |
"인증을 따는 것이 목적이 아니라, 준비되어 있음이 영업 무기입니다."
고객사의 보안 심사에서 크로노젠의 기술 아키텍처 문서를 제출하면, 대부분의 체크리스트를 통과할 수 있습니다.
보안은 기능이 아니라 신뢰입니다
많은 SaaS 서비스가 보안을 "있으면 좋은 기능"으로 취급합니다. 하지만 공공기관과 교육기관을 대상으로 하는 크로노젠에게 보안은 사업의 기반입니다.
로그인 화면의 작은 방패 아이콘 하나에도 8겹의 보안 계층이 작동하고 있습니다. 이것이 크로노젠이 생각하는 "기록은 자동으로, 증빙은 완벽하게"의 기술적 실체입니다.