저장 데이터와 전송 데이터 암호화란?

저장 데이터 암호화는 키 없이는 저장된 데이터를 읽을 수 없게 하고, 전송 중 암호화는 네트워크를 지나는 데이터를 보호하는 통제 수단입니다. 데이터는 세 가지 상태로 존재합니다. 스토리지에 저장된 상태, 네트워크로 전송 중인 상태, 메모리에서 사용 중인 상태이며, 앞의 두 가지는 모든 애플리케이션이 지는 기본 의무입니다. 머물러 있는 데이터에는 AES-256을, 이동하는 데이터에는 TLS를 적용합니다. 세 번째 상태(신뢰 실행 환경과, 최전선에서는 동형 암호로 보호)도 실재하지만, 대부분의 애플리케이션 팀에게는 다른 누군가가 맡는 계층입니다.

핵심 요약

두 가지 보호 수단, 그리고 각각이 실제로 막는 것

검색 상위 페이지들이 빠뜨리는 정직한 표입니다. 가장 중요한 열도 포함했습니다:

             표준             적용 범위            막는 것                  막지 못하는 것
전송 중      TLS 1.2+/HTTPS   모든 네트워크 구간   도청, MITM,              침해된 엔드포인트 –
                                                   카페에서의 엿보기        서버는 문제없이 읽음
저장 시      AES-256 (GCM)    디스크, DB, 백업     도난당한 드라이브,       도난당한 자격 증명,
                                                   유출된 백업, 공개 버킷   SQL 인젝션, 앱 버그
사용 중      TEEs             처리 중인 RAM        메모리 스크래핑          – 주로 플랫폼의 관심사

어느 쪽도 앱 자체가 신뢰하는 공격자는 막지 못합니다. 앱이 키를 보유하고
필요할 때 복호화합니다 – 암호화는 접근 제어를 보완할 뿐, 대체하지 않습니다.

애플리케이션 코드에서 기본값은 다음과 같이 보입니다:

// JavaScript / Node.js — Back4app JS SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
const user = new Parse.User();
await user.signUp({ username: 'ada', password: secret });
// On the wire: TLS 1.2+ (the https serverURL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// Flutter / Dart — Back4app Flutter SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
final user = ParseUser('ada', secret, '[email protected]');
await user.signUp();
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// iOS / Swift — Back4app Swift SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
var user = User()
user.username = "ada"
user.password = secret
let signedUp = try await user.signup()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

// Android / Kotlin — Back4app Android SDK
// Every SDK call rides TLS — and passwords are HASHED, never stored readable
val user = ParseUser()
user.username = "ada"
user.setPassword(secret)
user.signUp()
// On the wire: TLS 1.2+ (the https server URL is the whole config)
// At rest: bcrypt hash — even the database never holds the password itself

// Extra-sensitive fields: encrypt server-side in a Cloud Code beforeSave
// so plaintext never reaches storage — AES-256-GCM, key in env, not in code

TLS의 동작 방식, 한 문단으로

절묘한 요령은 이렇습니다. 비대칭 암호는 느리지만 공유 비밀 값이 필요 없고, 대칭 암호는 빠르지만 공유 비밀 값이 필요합니다. 그래서 TLS 핸드셰이크는 앞의 것으로 뒤의 것을 확립합니다. 클라이언트가 서버의 인증서를 검증하고(가로채기를 탐지할 수 있게 해 주는 신원 확인), 양쪽이 비대칭 키 교환으로 새로운 세션 키에 합의하며, 그 이후의 모든 통신은 빠른 대칭 암호화로 이루어집니다. TLS 1.3은 이 모든 것을 더 엄격하게 만들었습니다. 왕복이 두 번에서 한 번으로 줄었고, 레거시 암호 알고리즘과 RSA 키 교환이 제거되었으며, 전방 비밀성이 필수가 되었습니다. 덕분에 서버의 장기 키가 나중에 유출되더라도 기록해 둔 트래픽은 복호화할 수 없습니다. 검색 결과에서 빠지는 모바일 관련 보충 설명도 있습니다. 앱은 예상하는 인증서를 추가로 고정(pinning)할 수 있으며, 이는 악성 인증 기관에 대한 내성을 얻는 대신 인증서 교체 시점에 운영상의 주의를 기울여야 하는 트레이드오프입니다.

저장 데이터 암호화의 계층: 디스크 vs. 데이터베이스 vs. 필드 vs. 애플리케이션

“저장 시 암호화됨”이라는 말에는 서로 매우 다른 네 가지 약속이 담겨 있으며, 각각이 막는 공격자도 다릅니다:

표 전체를 관통하는 규칙은 이렇습니다. 상위 계층일수록 더 많은 것을 막지만, 비용도 더 듭니다. 필드 수준 암호화는 정직한 트레이드오프입니다. 암호화된 열은 일반적인 방식으로 인덱싱하거나 검색할 수 없습니다(결정적 암호화는 약간의 정보 노출을 대가로 동등 비교 조회를 되살립니다). 그래서 건강 데이터, 신분증 번호, 시크릿처럼 정말 민감한 데이터에만 쓰입니다. 그리고 고전적인 감사 실패도 여기에 있습니다. 데이터베이스는 암호화했는데 백업은 암호화되지 않은 채 반출되는 경우입니다.

종단 간 암호화는 다른 약속입니다

모든 곳에 TLS를 적용해도 서버는 모든 내용을 읽습니다. 설계상 각 연결을 복호화하기 때문입니다. 종단 간 암호화는 키를 사용자에게 옮깁니다. 발신자와 수신자만 복호화할 수 있고, 운영자는 자신이 열 수 없는 암호문을 전달합니다. 이는 더 강한 설정이 아니라 다른 제품 결정입니다. E2EE를 쓰면 서버 측 검색도, 콘텐츠 모더레이션도, 사용자가 키를 잃었을 때의 복구도 불가능합니다. 위협 모델은 깔끔하게 포개집니다. TLS는 경로를, 저장 데이터 암호화는 스토리지를 지키고, E2EE는 서비스 자체로부터 데이터를 지킵니다. 대부분의 애플리케이션은 앞의 두 가지에서 멈추는 것이 옳고, 메시징과 보관함(vault) 제품은 세 번째까지 갈 이유가 있습니다.

해싱 vs. 암호화

한 가지만 짚어 두면 널리 퍼진 혼동이 사라집니다. 비밀번호는 해시하며, 결코 암호화하지 않습니다. 서버를 포함해 누구도 비밀번호를 복원할 수 있어서는 안 되며, 로그인은 해시를 비교합니다. 비밀번호를 암호화한다는 것은 모든 비밀번호를 복호화하는 키가 존재한다는 뜻이고, 그것이야말로 해싱이 막으려고 존재하는 재앙입니다.

일반적인 사용 사례

• 모든 웹 및 모바일 앱 – 모든 연결의 TLS와 암호화된 스토리지는 기능이 아니라 기본 요건입니다.
• 규제 대상 데이터 – GDPR은 암호화를 적절한 기술적 조치로 명시하며(침해 통지 의무 완화 포함), 의료 규정은 환자 데이터에 암호화를 의무화하고, 결제 표준은 저장된 카드 번호를 읽을 수 없게 하고 전송 중에는 강력한 암호화를 적용하도록 요구합니다.
• 백업과 폐기 – 암호화된 백업과 암호학적 파기(crypto-shredding, 키를 파기하면 데이터가 모든 곳에서 무효화됨)가 사본 도난이라는 문제를 마무리합니다.
• PII 필드 보호 – 유출되면 단순한 사고가 아니라 뉴스 헤드라인이 되는 열에 애플리케이션 수준 암호화를 적용합니다.
• 적대적인 네트워크의 모바일 클라이언트 – 사용자와 함께 이동하는 방어 수단으로서 TLS와 인증서 검증을 적용합니다.

어떤 계층이 필요할까? 결정 매트릭스

한계와 트레이드오프

• 암호화는 접근 제어가 아닙니다. 계층형 보안의 요점을 한 줄로 말하면 이렇습니다. 저장 데이터 암호화는 실행 중인 앱에 투명하므로, 자격 증명을 가진 모든 공격자에 대한 방어는 여전히 권한, 즉 ACL, CLP, 행 정책의 몫입니다.
• 키 관리가 진짜 프로젝트입니다. NIST의 지침이 존재하는 이유는 실제 도입이 실패하는 지점이 알고리즘 선택이 아니라 생성, 분리, 회전, 폐기이기 때문입니다.
• 필드 수준 암호화는 데이터베이스와 충돌합니다. 인덱스도, LIKE 쿼리도 쓸 수 없고 마이그레이션에 주의해야 합니다. 스키마 전체가 아니라 필요한 필드만 암호화해야 합니다.
• TLS는 종료 지점에서 끝납니다. 경로 중간에서 복호화하는 프록시와 로드 밸런서는 평문 구간을 다시 만들어 냅니다. 내부 트래픽에도 엣지와 같은 규율이 필요합니다.
• 규정 준수 ≠ 보안. 키를 데이터 옆에 둔 형식적인 암호화는 감사인만 만족시킬 뿐입니다. 설계의 기준으로 삼아야 할 것은 위협 모델 열입니다.

Back4app에서의 암호화

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. 최저선은 플랫폼이 제공합니다. 모든 REST, GraphQL, Live Query 연결은 TLS 위에서 이루어지고, 데이터와 백업은 저장 시 암호화됩니다. 두 기본 계층이 프로젝트가 아니라 기본값으로 주어지는 것입니다. 개발자에게 남은 몫은 코드 탭이 보여 주는 그대로입니다. 비밀번호는 Back4app이 기본적으로 bcrypt로 해시합니다(평문 비밀번호가 저장되지도, 복원되지도 않으므로 해싱 규칙이 구조적으로 강제됩니다). 정말 민감한 필드는 Cloud Code beforeSave에서 애플리케이션 수준으로 암호화하고 키는 코드가 아니라 서버 측 설정에 두므로, 평문이 스토리지에 도달하는 일은 없습니다. 그리고 시크릿은 로그, URL, 클라이언트 번들 어디에도 남기지 않습니다. API 키 관리 규율을 데이터에 적용한 것입니다. 그다음은 암호화가 할 수 없는 부분입니다. 누가 무엇을 읽는지는 ACL과 클래스 수준 권한이 결정합니다. 자격 증명을 가진 공격자를 막는 통제는 처음부터 암호학이 아니라 인가였기 때문입니다.