마지막 업데이트: 2026년 8월 20일

Spreadsheet Security Best Practices to Prevent Breaches & Data Leaks

개발자를 위한 스프레드시트 보안 모범 사례

스프레드시트는 현대 비즈니스 운영을 지원합니다. 재무 예측 및 임원 보고서부터 대량 사용자 가져오기, 청구 내보내기, 머신러닝 데이터셋에 이르기까지, .xlsx, .xlsm, .csv와 같은 형식은 기업 워크플로우의 기반이 됩니다. 이러한 보편성 때문에 소프트웨어 엔지니어들은 스프레드시트 파일을 생성, 수집, 파싱, 변환 및 내보내기 위한 코드를 일상적으로 작성합니다.

하지만 개발자들은 종종 스프레드시트를 무해한 표형 데이터—평면 텍스트 파일의 디지털 등가물—로 취급합니다. 실제로 최신 스프레드시트는 동적 계산을 실행하고, 외부 엔드포인트를 해결하며, 시스템 매크로를 호출하고, 임의의 바이너리 객체를 삽입할 수 있는 활성 실행 환경입니다. 부주의하게 다루면 스프레드시트 처리 파이프라인은 원격 코드 실행 (RCE), 수식 주입 (CSV Injection), 서버 측 요청 위조 (SSRF), XML 외부 엔터티 (XXE) 공격 및 기밀 데이터 유출의 매력적인 표적이 됩니다.

아래는 소프트웨어 스택 전반에서 스프레드시트를 처리할 때 방어적 엔지니어링 관행을 구현하기 위한 기술 가이드입니다.

1. 공식 주입 중화 (CSV & 스프레드시트 주입)

공식 인젝션—일반적으로 CSV 인젝션이라고도 함—은 신뢰할 수 없는 사용자 입력이 적절한 정화 없이 직접 스프레드시트 셀에 기록될 때 발생합니다.

최종 사용자나 관리자가 생성된 파일을 Microsoft Excel, Google Sheets 또는 LibreOffice Calc에서 열면, 특정 기능 문자로 시작하는 모든 셀 값이 정적 텍스트가 아니라 활성 공식으로 해석되고 실행됩니다.

위협 메커니즘

공격자는 공식 인젝션을 사용하여 두 가지 주요 유형의 공격을 수행합니다:

  1. 데이터 유출: HYPERLINK와 같은 함수를 악용하여 인접한 민감한 셀 데이터를 공격자가 제어하는 쿼리 매개변수에 조용히 추가합니다.
  2. 명령 실행: 동적 데이터 교환(DDE) 공식(예: 레거시 구성)이나 프로토콜 핸들러 링크를 활용하여 시스템 바이너리를 트리거하거나 악성 URL을 실행합니다.

위험한 선행 문자에는 다음이 포함됩니다:

  • = (직접 계산 또는 함수 호출)
  • + (수식 추가 또는 암시적 함수 호출)
  • - (수식 뺄셈 또는 부정 접두사)
  • @ (현대 버전 Excel에서 동적 배열 수식 호출)
  • \\t (탭 문자) 또는 \\r (캐리지 리턴) (단순 필터를 우회하기 위해 사용됨)
  • | 또는 % (파이프 연산 또는 Unix 기반 스프레드시트 뷰어에서 쉘 호출)

엔지니어링 방어

  • 문자 접두사 (싱글쿼트 이스케이프): 신뢰할 수 없는 문자열 입력이 =, +, -, @, \\t, 또는 \\r 로 시작하는 경우, 셀에 쓰기 전에 문자열 앞에 싱글쿼트 (') 를 추가합니다. Excel 및 LibreOffice는 앞에 있는 싱글쿼트를 서식 지시자로 처리하여 셀을 순수 텍스트로 강제 렌더링하고, 표시되는 출력에서는 해당 따옴표를 제거합니다.
  • 엄격한 직렬화 라이브러리: 원시 문자열 보간을 사용하여 CSV 또는 XLSX 파일을 직접 구성하지 마세요(예: f\"{user_input_1},{user_input_2}\\n\"). RFC 4180 구분자 이스케이프, 필드 래핑 및 인용 부호 이중화를 자동으로 처리하는 검증된 표 형식 직렬화 라이브러리를 사용하십시오.
  • 셀 유형 강제 지정: 프로그래밍 방식으로 OpenXML (.xlsx) 파일을 생성할 때, 엔진이 값으로부터 셀 유형을 추론하도록 두는 대신 셀 데이터 유형을 명시적으로 String(또는 InlineString) 로 정의하십시오.

2. 인제션 및 파서 파이프라인 강화

사용자가 업로드한 스프레드시트를 파싱하면 백엔드 시스템이 상당한 파서 수준 공격 표면에 노출됩니다. 최신 .xlsx 파일은 Open Packaging Conventions (OPC)를 따르는 상호 의존적인 XML 문서를 포함하는 압축 ZIP 아카이브입니다.

백엔드에서 신뢰할 수 없는 XML을 파싱하면 파서 구성을 기본 설정 그대로 두었을 경우 고전적인 파서 취약점에 서비스가 노출됩니다.

완화 전략:

  • DTD 및 외부 엔터티 비활성화 (XXE 방어): XML 엔진이 문서 유형 정의(DTD)를 명시적으로 금지하고 외부 스키마 해석을 비활성화하도록 설정하십시오 (disallow-doctype-decl = true, resolve-external-entities = false). 이를 수행하지 않으면 업로드된 .xlsx 파일이 로컬 서버 파일(예: /etc/passwd)을 읽거나 내부 클라우드 서비스를 탐색할 수 있습니다.
  • 압축 해제 폭탄(ZIP Bomb) 방지: 악의적인 사용자는 작은 아카이브를 제출하여 압축을 풀면 수십 기가바이트에 달하는 반복적인 XML 데이터가 생성되어 메모리가 충돌하고 디스크 공간이 고갈됩니다. 추출 중에 압축 해제된 바이트 수를 추적하고, 압축된 아카이브 크기와 전체 압축 해제 메모리 사용량 모두에 대한 엄격한 제한을 적용하십시오.
  • 스트리밍 파서 채택: 대용량 스프레드시트를 메모리 내 문서 객체 모델(DOM) 표현으로 로드하는 것을 피하십시오. 대규모 배치 가져오기에서는 스트리밍, SAX 기반 또는 청크 단위 행별 반복자를 사용하여 백엔드 메모리 사용량을 일정하게 유지합니다.

3. 매크로 제어 및 활성 콘텐츠 정화

Visual Basic for Applications(VBA) 매크로, OLE(객체 연결 및 포함) 페이로드 및 임베디드 스크립트는 데스크톱 컴퓨팅에서 가장 지속적인 공격 벡터 중 일부를 나타냅니다.

개발자 모범 사례:

  • 엄격한 확장자 정책 적용: 검증된, 변경할 수 없는 비즈니스 요구 사항이 있어 처리해야 하는 경우가 아니면 API 게이트웨이에서 매크로 사용 파일 형식(.xlsm, .xltm, .xlsb, 또는 레거시 .xls)을 거부하십시오.
  • 깨끗한 .xlsx 형식 적용: 표준 .xlsx 컨테이너 형식은 구조적으로 매크로 지원 없이 설계되었습니다. .xlsx 파일에 매크로 코드가 포함되어 있으면 호환되는 Office 엔진에서 파일 형식이 무효화됩니다.
  • 활성 스트림 검사 및 제거: 서비스가 임의의 첨부 파일을 처리하는 경우, 파일을 객체 저장소에 저장하거나 다른 클라이언트에 제공하기 전에 VBA 프로젝트 바이너리(vbaProject.bin), ActiveX 컨트롤 및 임베디드 OLE 패키지를 제거하는 자동 정화 과정을 통합하십시오.

4. 헤드리스 미리보기 및 PDF 변환 중 SSRF 방지

현대 기업 애플리케이션은 일반적으로 문서 미리보기 카드 또는 자동 PDF 보고서 생성을 제공합니다. 이를 달성하기 위해 백엔드는 종종 헤드리스 오피스 스위트(예: 헤드리스 모드의 LibreOffice) 또는 헤드리스 브라우저를 활용합니다.

스프레드시트에는 연결된 이미지 수식(=IMAGE(\"http://internal-host/...\")), 원격 OData 링크 또는 삽입된 웹 프레임과 같은 동적 외부 종속성이 포함될 수 있습니다. 헤드리스 프로세서가 스프레드시트를 렌더링할 때 이러한 연결된 리소스를 자동으로 가져와 **Server-Side Request Forgery (SSRF)**를 유발할 수 있습니다.

다층 방어 조치:

  • 변환 환경 격리: 최소 시스템 권한만 부여된 샌드박스 마이크로‑컨테이너 또는 일시적인 서버리스 함수에서 헤드리스 렌더링 서비스를 실행합니다.
  • 네트워크 격리 적용: 문서 렌더링 워커를 내부 VPC, 프라이빗 데이터베이스 또는 클라우드 메타데이터 엔드포인트(169.254.169.254)에 대한 라우트 접근이 없는 제한된 서브넷에 배치합니다.
  • 원격 리소스 해석 비활성화: 렌더링 엔진에 구성 플래그를 전달하여 네트워크 기반 자산 해석을 금지합니다(예: LibreOffice에 내보내기 루틴 중 외부 리소스 로딩을 거부하도록 지시).

5. 시트 보호 vs. 실제 암호화 파일 암호화

제품 팀 사이에서 가장 지속적인 오해 중 하나는 Excel의 기본 Worksheet/Workbook Protection와 Cryptographic Encryption의 차이점입니다.

잠긴 셀의 착각

Excel의 기본 “Protect Sheet” 및 “Protect Workbook” 기능은 사무 직원이 실수로 편집하는 것을 방지하도록 설계된 UI 수준의 편의 기능입니다. 이 기능들은 암호화된 접근 장벽을 사용하지 않습니다. 기본 스크립트를 사용하면 .xlsx 압축 파일 내부의 기본 XML 파일에서 시트 보호 태그를 몇 초 만에 직접 제거할 수 있어, 의도적인 변조에 대해 제한이 무용지물이 됩니다.

실제 암호화 보호:

  • Transport and At-Rest Encryption: 민감한 스프레드시트 내보내기를 최신 표준으로 암호화된 스토리지 볼륨(AWS S3 SSE-KMS, Azure Storage Encryption 등)에 저장하고, TLS 1.3을 통해서만 전송하십시오.
  • Standard OpenXML Encryption: 스프레드시트를 배포용으로 비밀번호 보호해야 할 경우, 레거시 Office XOR 암호화 대신 업계 표준인 AES-256 OpenXML 암호화를 사용하십시오.
  • 데이터베이스 수준 레드랙션 (RBAC): 스프레드시트를 만들기 전에 데이터베이스 및 애플리케이션 계층에서 역할 기반 접근 제어를 적용하십시오. 내보내는 사용자가 사회보장번호, 내부 계정 ID 또는 총 마진을 볼 권한이 없으면 해당 열을 쿼리에서 완전히 제외합니다. “숨김” 행이나 열에 민감한 데이터를 남겨두지 마십시오.

6. 접근 제어, 배포 및 감사 로그

스프레드시트는 휴대 가능하고 독립적인 파일이기 때문에 다운로드된 후 중앙 집중식 경계 제어를 자주 우회합니다.

개발자 모범 사례:

  • 인증된 단기간 프리사인드 URL을 통해 제공: 생성된 스프레드시트 내보내기를 공개 버킷에 절대 두지 마십시오. 인증되고 권한이 부여된 사용자 세션에 연결된, 5분 미만 만료되는 시간 제한 프리사인드 URL을 생성하십시오.
  • 포괄적인 내보내기 감사: 모든 내보내기 작업을 데이터 접근 이벤트로 간주합니다. 사용자 ID, 테넌트 ID, 쿼리 매개변수, 생성 타임스탬프 및 수신자 IP 주소를 변경 불가능한 감사 원장에 기록합니다.
  • 메타데이터 제거: 파일을 외부 클라이언트에 제공하기 전에 최종 문서 속성에서 내부 디버깅 메타데이터, 로컬 서버 파일 경로, 작성자 계정 및 수식 편집 기록을 제거합니다.

개발자를 위한 요약 체크리스트

위협 카테고리핵심 취약점주요 완화
데이터 생성수식 인젝션 / CSV 인젝션위험한 문자(=, +, -, @) 앞에 '를 붙이고, 견고한 직렬화 라이브러리를 사용하세요.
파일 수집XXE 및 압축 해제 폭탄XML 파서에서 DTD와 외부 엔티티를 비활성화하고; 아카이브 압축 해제 제한을 적용하세요.
파일 유형악성 매크로 및 OLE 객체업로드 시 .xlsx만 허용하고 매크로 스트림(vbaProject.bin)을 제거합니다.
렌더링헤드리스 변환기를 통한 SSRF샌드박스 렌더링 워커; 내부 VPC 및 메타데이터 엔드포인트로의 네트워크 아웃바운드 차단.
기밀성비효과적인 시트 보호쿼리 레이어에서 민감한 필드를 제외하고; UI 셀 잠금이나 숨겨진 열에 의존하지 마십시오.
배포제어되지 않은 데이터 노출만료되는 사전 서명 URL을 통해 다운로드를 제공하고, 모든 내보내기 작업에 대한 구조화된 감사 로그를 기록합니다.

자주 묻는 질문 (FAQ)

Q1. 표준 CSV 파일로 데이터를 내보내는 것이 코드 실행으로부터 완전히 안전한가요? 아니요, 스프레드시트 애플리케이션은 =, @, +, -와 같은 선행 문자를 자동으로 활성 수식으로 해석하여 셀 내용이 유출되거나 로컬 명령을 실행할 수 있기 때문입니다.

Q2. Excel 워크시트 비밀번호를 사용해 민감한 데이터를 무단 개발자나 사용자로부터 보호할 수 있나요? 아니요, 기본 워크시트 및 워크북 보호 비밀번호는 UI 수준의 편집만 제한하며, 비밀번호 복구 도구 없이도 기본 XML 파일에서 직접 제거될 수 있습니다.

Q3. .xlsx 파일을 파싱할 때 XML 외부 엔터티(XXE) 공격을 방지하는 가장 안전한 방법은 무엇인가요? XML 파서를 구성하여 인라인 DTD를 명시적으로 허용하지 않도록 하고, 아카이브 내부 XML 파일을 파싱하기 전에 외부 스키마와 엔터티의 해석을 비활성화하십시오.

Q4. 내보낸 스프레드시트에서 “숨겨진 열"에 의존해 민감한 내부 ID와 메트릭을 숨기는 것이 왜 위험한가요? 숨겨진 열은 기본 데이터 페이로드에 완전히 존재하며, 스프레드시트 UI에서 한 번 클릭으로 노출되거나 원시 파일 내용에서 직접 읽을 수 있습니다.

Q5. 사용자 스프레드시트의 PDF 요약 또는 썸네일 미리보기를 생성할 때 서버 측 요청 위조(SSRF)를 어떻게 방지할 수 있나요? 렌더링 엔진을 격리된 네트워크 제한 컨테이너 내에서 실행하여 사설 서브넷 및 클라우드 메타데이터 서비스에 대한 외부 네트워크 접근을 엄격히 금지합니다.

관련 항목