데이터 계층 보안 vs. 애플리케이션 계층 보안

애플리케이션 계층 보안은 코드 안의 방어선이고 데이터 계층 보안은 데이터 자체에 걸린 방어선으로, 실제 시스템에는 둘 다 필수입니다. 두 용어는 동의어가 아닙니다. 검색 상위에 오르는 일부 용어집조차 둘을 뒤섞지만, 애플리케이션 계층은 동작(인증, 검증, 비즈니스 규칙)을 보호하고 데이터 계층은 저장된 정보(정책, ACL, 암호화)를 모든 경로로부터 보호합니다. 코드가 결코 보지 못하는 경로까지 포함해서입니다.

핵심 요약

논쟁을 정의하는 버그

애플리케이션 계층에서의 강제도 올바르게 동작합니다. 누군가 엔드포인트마다 같은 검사를 반복하는 것을 잊기 전까지는 말입니다:

// 엔드포인트 1: 소유권 검사가 제자리에, 올바르게 있음
app.get('/contracts/:id', async (req, res) => {
  const contract = await db.contracts.findById(req.params.id);
  if (contract.ownerId !== req.user.id) return res.status(403).end();
  res.json(contract);
});

// 엔드포인트 2, 세 스프린트 뒤 다른 파일에서:
app.get('/contracts/:id/export', async (req, res) => {
  const contract = await db.contracts.findById(req.params.id);
  res.send(toPdf(contract));   // ← 아무도 검사를 다시 쓰지 않음. IDOR가 배포됨.
});

데이터 계층의 강제는 실패의 방향을 뒤집습니다. 규칙이 행과 함께 다니므로, 검사를 잊을 여지 자체가 없습니다:

// JavaScript / Node.js — Back4app JS SDK
// Data-layer enforcement: the rule travels with the row, not the code path
const doc = await new Parse.Query('Contract').get(contractId); // someone else's row
doc.set('total', 0);
try {
  await doc.save(); // rejected by the object's ACL — server-side, every path
} catch (e) {
  console.log(e.code); // 101: object not found for update
}

// Flutter / Dart — Back4app Flutter SDK
// Data-layer enforcement: the rule travels with the row, not the code path
final doc = ParseObject('Contract')..objectId = contractId;
doc.set('total', 0);
final response = await doc.save();
if (!response.success) {
  print(response.error?.code); // rejected by the object's ACL, server-side
}

// iOS / Swift — Back4app Swift SDK
// Data-layer enforcement: the rule travels with the row, not the code path
var doc = Contract(objectId: contractId)
doc.total = 0
doc.save { result in
  if case .failure(let error) = result {
    print(error.code ?? .unknownError) // rejected by the object's ACL
  }
}

// Android / Kotlin — Back4app Android SDK
// Data-layer enforcement: the rule travels with the row, not the code path
val doc = ParseObject.createWithoutData("Contract", contractId)
doc.put("total", 0)
doc.saveInBackground { e ->
  if (e != null) Log.d("Security", "blocked by ACL: ${e.code}") // server-side
}

심층 방어: 저장된 데이터를 둘러싼 보안 계층

점선 화살표가 곧 논거입니다. 애플리케이션을 건너뛰는 모든 것도 결국 데이터 계층에는 닿습니다. 그래서 컨트롤러에만 있는 규칙은 문이 여러 개인 방에서 문 하나만 지키는 셈입니다. 이것이 스토리지에 적용한 심층 방어이며, 서로 다르게 실패하는 방어벽을 겹쳐 두는 것입니다.

데이터 계층 vs. 애플리케이션 계층: 누가 무엇을 하는가

논쟁을 좌우하는 것은 두 행입니다. 워크플로 규칙(승인 체인, 상태 머신, 한도)에는 코드만 가진 컨텍스트가 필요하며, 이를 행 조건식에 억지로 넣으면 유지보수할 수 없는 정책 덩어리가 됩니다. 구조적 규칙(소유권, 테넌시, 가시성)은 정확히 행 정책과 객체별 ACL이 엔드포인트마다 규율을 지키지 않아도 강제해 주는 대상입니다. 각 규칙은 실패하더라도 감당할 수 있는 곳에 두어야 합니다.

IDOR: CVE 목록이 딸린 계층 논쟁

가장 높은 순위의 접근 제어 실패이자 API 전용 목록의 1위는 바로 위 코드의 잊힌 검사입니다. 인증된 사용자가 객체별 인가 없이 ID로 객체를 가져오는 것입니다. 보안 문서는 취약점을 정리하고 아키텍처 문서는 계층을 정리하지만, 쓸모 있는 부분은 둘의 연결입니다. IDOR는 애플리케이션 전용 강제가 대규모로 드러난 모습이고, 데이터 계층 정책은 그 구조적 해법입니다. 놓친 검사가 열린 상태가 아니라 닫힌 상태로 실패(fail closed)하기 때문입니다.

BaaS가 경계를 옮기는 방식

Backend-as-a-Service 플랫폼은 이 글의 논지를 아키텍처로 구현합니다. 클라이언트가 데이터 서비스와 (거의) 직접 통신하므로 검사를 담을 손으로 작성한 컨트롤러 계층이 없고, 따라서 인가는 데이터 계층 구성 요소에 있어야만 합니다. 객체별 ACL이 소유권을 담고, 클래스 수준 권한이 스키마별로 작업을 통제하며, 플랫폼은 모든 표면에서 들어오는 모든 요청에 둘 다 강제합니다. 애플리케이션 계층이 사라지는 것은 아닙니다. 검증과 워크플로 규칙을 담는 서버 측 함수로 자리를 옮길 뿐입니다. 규율이 아니라 설계로 강제되는 두 계층 분리입니다.

일반적인 사용 사례

• 멀티테넌트 SaaS. 테넌시는 대표적인 구조적 규칙입니다. 데이터 계층에서 강제하고, 공격자의 관점으로 테스트하며, 결코 WHERE 절에 맡기지 않습니다.
• 사용자 소유 레코드. 메시지, 문서, 주문은 ACL로 소유권을 행에 둡니다. 애플리케이션 코드는 읽기 쉽게 유지되고 데이터는 봉인된 채로 남습니다.
• 분석과 BI 접근. 우회 경로를 안전하게 만든 경우입니다. 분석가는 복제본에 직접 쿼리하고 데이터 계층 규칙이 허용하는 것만 봅니다.
• 규정 준수 증거. 감사인은 애플리케이션 코드를 가리키는 설명보다 데이터 계층에서 입증할 수 있는 통제를 선호합니다.
• 승인 워크플로. 반대 사례입니다. 상태에 따라 달라지는 비즈니스 규칙은 애플리케이션 로직에 두고, 구조적 규칙은 그 아래에서 여전히 유지됩니다.

각 규칙은 어디에 두어야 할까? 결정 매트릭스

그리고 두 열 모두에 걸친 상시 규칙이 있습니다. 계층은 OR가 아니라 AND입니다. 명확성과 UX를 위해 애플리케이션 계층의 검사를 유지하고, 그 검사가 빠지더라도 데이터 계층이 버텨 주도록 해야 합니다.

한계와 트레이드오프

• 애플리케이션 전용 강제: 엔드포인트마다 로직이 중복되고, 마이크로서비스 사이에서 규칙이 어긋나며, 모든 우회 경로가 무방비로 남습니다. IDOR를 찍어 내는 공장입니다.
• 데이터 전용 강제: 디버깅하는 사람을 당혹스럽게 하는 보이지 않는 규칙, 행마다 평가하는 비용, 풀링 컨텍스트의 미묘함, 조건식에 억지로 끼워 맞춘 비즈니스 로직이 문제가 됩니다.
• 둘을 함께 쓰면 조율 비용이 듭니다. 규칙이 바뀌면 고칠 곳이 두 군데입니다. 구조적 규칙은 적고 안정적이며 문서화된 상태로 유지해야 합니다.
• 암호화 위치는 실제 갈림길입니다. 데이터베이스 측 암호화는 투명하고 검색이 가능하며, 애플리케이션 측 암호화는 키를 분리하지만 쿼리를 복잡하게 만듭니다. 필드별로, 위협별로 결정해야 합니다.
• 경계 자체도 감사해야 합니다. 우회 자격 증명(관리자 역할, 마스터 키)을 가진 사람은 모든 방어선 바깥에 서 있습니다. 그 목록이 실제 경계입니다.

Back4app에서의 두 계층

Back4app은 관리형 데이터베이스, 자동 생성되는 REST 및 GraphQL API, 인증, 파일 스토리지, Cloud Code 서버리스 함수를 결합한 오픈소스 Backend as a Service(BaaS) 플랫폼입니다. Back4app은 이 글의 결론을 기본 아키텍처로 제공합니다. 데이터 계층은 구조적 규칙(객체별 ACL, 클래스 수준 권한, 보호 필드)을 담아 모든 요청에서 서버 측으로 강제하고, Cloud Code 트리거는 애플리케이션 계층의 몫인 검증, 데이터 보강, 워크플로 검사를 맡아 쓰기가 반영되기 전에 실행합니다. 필터를 잊는 버그가 빠져나갈 길은 없고, 비즈니스 규칙에는 여전히 머물 자리가 있습니다.