Excel 프로그램은 이름은 똑같이 '비밀번호(password)'라고 부르지만 실체는 완전히 다른 두 가지 보안 모듈을 제공하며, 이 중 오직 하나만이 실제 암호화(encryption)를 지원합니다. '열기 비밀번호(open password)'는 실제 강력한 암호화 알고리즘의 키 역할을 담당하여 비밀번호 없이는 파일 데이터를 절대 해독해 읽을 수 없게 만듭니다. 반면 '워크시트 및 통합 문서 보호 비밀번호'는 암호화와 무관합니다. 단순히 타 편집기 프로그램이 이 제한 규정을 존중해 편집을 금지해 달라고 선언하는 임시 플래그 설정에 불과합니다. 이 시트 보호 플래그만 지정된 파일은 일반적인 압축 파일 포맷(plain zip) 상태로 시트 내부 데이터가 평문(cleartext) 그대로 보존되어 열려 있습니다. 이 둘을 혼동하면, 엑셀 창에서는 겉보기엔 암호가 걸린 것처럼 보이지만 일반 메모장이나 텍스트 편집기에서는 급여 대장 데이터가 그대로 노출되는 취약한 문서를 외부로 배송하게 됩니다
이를 증명하는 데는 10초도 걸리지 않습니다. 시트 보호가 적용된 .xlsx 파일 확장자를 .zip으로 변경한 뒤 일반 압축 해제 툴로 열어 내부의 xl/worksheets/sheet1.xml 파일을 메모장으로 열어보십시오. 만일 셀의 텍스트와 수치들이 평문 UTF-8 문자열로 그대로 보인다면, 엑셀 프로그램에서 아무리 기입 비밀번호 창을 화려하게 띄우더라도 실제 파일은 암호화되지 않은 것입니다. 시트 보호 설정을 기밀성 보호 조치로 혼동하는 개발팀에서는 이 허점을 오랫동안 인지하지 못하다가, 사내 보안 감사를 주관하는 담당자가 확장자 이름 변경 대조 작업을 실행하는 날 청천벽력 같은 지적을 받게 됩니다
HotXLS는 Delphi 및 C++Builder용 기본 스프레드시트 라이브러리인 HotXLS는 이 두 보안 사양의 차이를 엄격히 규정하고 구분해 가동합니다. 워크시트 및 통합 문서 보호 기능은 의도적으로 연산 수준을 낮춘 레거시 해시(legacy hash) 방식으로 작동하며 단순한 편집 권한 제어를 담당합니다. 반면 SaveAsEncrypted API는 비밀번호 없이는 물리적으로 절대로 해독할 수 없는 진정한 AES 암호화 파일 패키지를 생성해 냅니다. 이하에서는 이 함수가 출력 파일에 기입하는 데이터 구조, 시스템 구축 시 반드시 유념해야 할 비대칭성 제한(HotXLS는 암호 파일 기입은 지원하지만 이를 다시 읽어 들이지는 못함), 그리고 구형 XLS 포맷용 복호화 경로의 특징을 상세히 안내해 드립니다
왜 시트 보호 설정이 기밀성 암호화가 아닌가요?
워크시트에 제공되는 Protect 메서드와 통합 문서용 ProtectWorkbook 메서드는 비밀번호의 4자리 16진수 해시 값만을 문서 사전에 기록합니다. 이는 OOXML과 구형 BIFF 포맷이 1990년대의 구형 Excel 프로그램으로부터 그대로 계승받은 고전 알고리즘 사양이며, 공식 표준 문서 규격에서도 이 사양의 역할을 오직 '실수로 인한 변형 예방'으로 규정하고 있을 뿐입니다. 파일 자체는 일반 ZIP 압축 형식을 유지하므로 셀의 기입 내용, 수식, 공유 문자열 테이블 정보가 평문 XML 문서 내에 고스란히 남아 있게 됩니다. 더욱 주의할 점은 Excel의 기본 설계 값상 모든 셀의 기본 상태가 Locked=True로 지정되어 있어, 특정 편집 영역의 잠금을 수동으로 해제(unlocking)해 두지 않은 채로 Protect를 기습 호출하면 시트 전체가 읽기 전용 상태로 꽁꽁 얼어붙어 사용자는 수정할 수 없지만, 파일 내부 데이터 자체는 평문 상태로 여전히 타인에게 그대로 노출된다는 사실입니다
이렇다고 해서 시트 보호 기능이 무의미하다는 것은 아닙니다. 사용자의 기입 영역을 올바른 필드로 안내하고 인쇄용 레이아웃의 형태 유지를 돕는 데는 유용하게 쓰 있으며, 이는 워크시트 보호 설정 및 페이지 인쇄 조율 가이드에서 안내하고 있습니다. 그러나 이는 문서의 '사용 편의성(usability)' 개선 도구일 뿐입니다. 기밀성 확보와 무단 유출을 철저히 막아야 하는 비즈니스 보안 조건이 수반되는 상황이라면 반드시 SaveAsEncrypted API를 사용하여 암호화해 제공해야 합니다
SaveAsEncrypted가 파일에 기록하는 실제 데이터 구조
이 API의 암호화 알고리즘 구현은 [MS-OFFCRYPTO] 섹션 2.3.4 규격에 명시된 ECMA-376 표준 암호화(Standard Encryption) 사양을 충실히 따릅니다. 전달받은 비밀번호 문자열에 5만 번의 SHA-1 반복 해시 연산을 기동하여 AES-128 암호 키를 생성합니다. 그리고 ECB 모드의 AES-128 암호화가 적용된 검증기(verifier) 블록 정보를 동봉해 판독 프로그램이 사전에 암호 유효성을 신속히 판별하게 도우며, 실제 워크북 본문 데이터는 CBC 모드의 AES-128 알고리즘으로 단단하게 감싸 저장합니다. 출력 파일은 더 이상 표준 ZIP 압축 형식이 아닙니다. 대신 EncryptionInfo, EncryptedPackage, DataSpaces 등의 내부 데이터 스트림들을 담는 OLE 복합 파일(OLE compound file) 구조를 띠게 되며, 파일 내에 xl/와 같은 시트 XML 디렉토리가 파괴되어 숨겨지므로 타 압축 해제 툴로는 더 이상 판독이 불가능합니다. Excel 2007부터 최신 버전까지의 엑셀 프로그램과 최신 LibreOffice 프로그램도 이 표준 복호화 연산을 정상 지원하여 기입된 패스워드만으로 문서 해독을 지원합니다
var
Book: TXLSXWorkbook;
Sheet: TXLSXWorksheet;
rc: Integer;
begin
Book := TXLSXWorkbook.Create;
try
Sheet := Book.Sheets.Add('Payroll');
Sheet.Cells[1, 1].Value := 'Employee';
Sheet.Cells[1, 2].Value := 'Net pay';
Sheet.Cells[2, 1].Value := 'A. Garcia';
Sheet.Cells[2, 2].Value := 4815.16;
rc := Book.SaveAsEncrypted('payroll-2026-06.xlsx', PasswordFromVault);
if rc <> 1 then
raise Exception.CreateFmt('Encrypted save failed (rc=%d)', [rc]);
finally
Book.Free;
end;
end;비밀번호 문자열을 관리할 때는 데이터베이스 연결 문자열(connection string)을 다룰 때와 동일한 엄격한 보안을 준수해야 합니다. 해시 비밀 키나 보안 자격 증명 관리 도구(Vault)로부터 실시간으로 주입받아야 하며 절대 디버깅 로그 파일 등에 기재해서는 안 되며 워크북 객체 내의 셀에 평문 기입해서도 안 됩니다. 리턴 코드 확인 과정 역시 단순 요식 행위가 아닙니다. 암호 저장 중 아주 미세한 에러라도 감지되면 즉각 처리를 중단하고 파일 배포를 취소해야 합니다. 에러 발생 시 라이브러리가 취할 수 있는 유일한 복구책이 암호화 해제된 일반 평문 문서 출력인데, 이는 기업 기밀 유출 사고로 직행하는 치명적인 예외 조건이기 때문입니다
세상에는 또한 시스템 테스트를 거의 비용 들이지 않고 수행할 수 있는 유용한 검사 방법이 존재합니다. 바로 방금 작성한 파일에 대해 CanReadEncrypted API를 호출하는 것입니다. 이 함수는 실제 암호화 컨테이너 형식으로 작성되었을 때만 참(true)을 반환하므로, 암호화 저장 후 이 단계에서 검사를 처리하도록 구현해 두면 의도하지 않게 일반 SaveAs 평문으로 작성되어 고객에게 전달되는 치명적인 결함 현상을 실시간으로 검출할 수 있습니다. 가장 확실한 최종 검사는 수동 릴리즈 테스트 중 Excel 프로그램 창을 켜서 비밀번호 해독이 무사히 진행되는지 확인하는 것입니다
의도된 비대칭형 제한: EXlsxEncryptionNotImplemented 예외 처리 방법
통합 자동화 시스템 아키텍처를 설계할 때 반드시 확인해야 할 HotXLS의 독특한 기술 제한이 있습니다. 바로 암호화 기입은 가능하지만 라이브러리 레벨에서의 복호화 해독(open)은 제공되지 않는다는 점입니다. 실제로 암호 걸린 파일에 대해 OpenEncrypted를 호출하면 EXlsxEncryptionNotImplemented(XLSX 암호화 미지원) 예외가 유발되며, 암호가 걸려 있지 않은 평범한 평문 문서인 경우에는 일반적인 Open 경로로 물 흐르듯 fall-back 처리해 줍니다. 짝꿍 함수인 CanReadEncrypted를 사용하면 OLE 암호화 컨테이너 상태인지를 예외 유발 없이 초고속 사전 검출할 수 있으므로 다음과 같이 예외 분기 로직을 처리할 수 있습니다
var
Book: TXLSXWorkbook;
begin
Book := TXLSXWorkbook.Create;
try
if Book.CanReadEncrypted(FileName) then
begin
// Encrypted container: HotXLS cannot decrypt it.
Writeln(FileName + ': needs manual decryption in Excel first');
Exit;
end;
try
Book.OpenEncrypted(FileName, ''); // plain files fall through to Open
Writeln(FileName + ': opened, ' + IntToStr(Book.Sheets.Count) + ' sheet(s)');
except
on EXlsxEncryptionNotImplemented do
Writeln(FileName + ': encrypted - routed to manual queue');
end;
finally
Book.Free;
end;
end;이러한 비대칭성 제약이 애플리케이션 아키텍처 설계에 시사하는 바는 명확합니다. 바로 '암호화 처리는 시스템 밖으로 파일이 발송되는 최종 출력 끝단(delivery edge)에서 1회성으로 처리해야 한다'는 점입니다. 원본 마스터 통합 문서는 기업의 보안 내부 네트워크 경계 안쪽(데이터베이스, 암호화 스토리지, 접근 권한 통제된 전용 파일 서버 공유 경로 등)에 보안 보존하고, 메일 발송이나 외부 포털 업로드 등의 전달 직전 단계에서만 암호화 복사본을 출력하는 것이 가장 정석입니다. 만일 시스템 내부 저장소에 오직 이 암호화 결과물 파일만을 보존하도록 파이프라인을 잘못 구축하면, 사후 단계에서 서버 배치 프로세스가 자신의 데이터를 다시 해독해 읽지 못해 가동이 불가능해집니다. 사후 배치 연산에 해당 문서가 다시 재수집되어야 하는 시스템 구조라면, 암호화된 전송용 파일이 아닌 마스터 평문 통합 문서를 찾아 넘겨야 합니다
AES-128 표준 암호화 방식과 AES-256 규격 준수 기준의 이해
MS 오피스의 문서 암호화는 크게 두 단계의 기술로 구분됩니다. HotXLS가 생성해 기입하는 표준 암호화(Standard Encryption) 방식은 SHA-1 키 유도 알고리즘과 AES-128 방식을 사용합니다. 이후 개량되어 도입된 Agile 암호화 방식은 SHA-512 해시 연산과 AES-256 방식을 채택하며 별도의 XML 기술 정보 키 컨테이너를 수록해 기입합니다. 두 형태 모두 Excel 프로그램 상에서 사용자 암호 입력만으로 매끄럽게 오픈되며, 일반 사용자의 전송 구간 데이터 기밀성 확보 측면에서는 AES-128 방식 역시 수학적으로 충분히 우수하고 안전한 보안 성능을 제공합니다
그러나 금융권 등의 엄격한 보안 요건에서 '휴지(at-rest) 상태 보관 파일에 대해 AES-256 알고리즘을 사용해 의무 암호화하라'는 체크리스트 규정을 요구받는 순간에는 기술적인 차이를 명확히 구분해야 합니다. 아무리 비밀번호 문자열을 복잡하게 쓰더라도 표준 암호화 규격(AES-128)으로는 이 AES-256 보관 의무 규정을 공식 통과할 수 없으며, HotXLS의 SaveAsEncrypted API는 알고리즘 강도를 수동 변경하는 매개변수를 제공하지 않습니다. 그러니까 회사 보안 명세 문서에 알고리즘 사양을 있는 그대로 명확히 명기해 대처하십시오(AES-128, ECMA-376 Standard Encryption, 50,000회 반복 SHA-1 키 유도). 규격 사항을 투명하고 정직하게 설명하는 기술 문서가, 오진으로 인해 감사 보안 심사에서 결함으로 지적받는 사태를 예방하는 가장 현명한 해법입니다
레거시 구형 XLSX 암호화 경로: RC4 출력 기입 및 RC4/XOR 양방향 해독
구형 BIFF 파일 포맷인 .xls 환경에서는 이와는 다른 양방향 처리를 지원합니다. 암호화 수준은 상대적으로 낮지만, 무손실 양방향 처리가 가능합니다. 즉, 라이브러리가 암호 파일 쓰기 및 읽기를 모두 양방향으로 처리할 수 있습니다. 저장 전에 EncryptionPassword 속성을 기재하고 SaveAs를 호출하면 BIFF 포맷 고유의 FilePass 방식을 통과해 RC4 알고리즘 암호화 파일이 생성되며, Open 호출 시 패스워드를 주입하면 레거시 구형 3대 보호 사양(RC4, RC4 CryptoAPI, 고전 XOR 난독화 방식)을 모두 정상 복호화해 읽어 들입니다
var
Writer, Reader: IXLSWorkbook; // interface refs: no manual Free
begin
Writer := TXLSWorkbook.Create;
Writer.Sheets.Add.Cells.Item[1, 1].Value := 'Confidential';
Writer.EncryptionPassword := 'S3cret!';
Writer.SaveAs('confidential.xls');
Reader := TXLSWorkbook.Create;
if Reader.Open('confidential.xls', 'S3cret!') > 0 then
Writeln(Reader.Sheets[1].Cells.Item[1, 1].Value); // Entries are 1-based
end;RC4는 현대 보안 규격상 이미 폐기(obsolete)되어 오늘날 실질적인 보안을 위해서는 절대 사용해서는 안 되는 규격이며, 오직 구형 .xls 파일을 교환해야 하는 하위 시스템 연계 시에만 한시적으로 사용을 허용해야 합니다. 그러나 복호화(read) 기능은 레거시 파일 마이그레이션 배치 시스템에서 빛을 발합니다. 비밀번호 걸린 구형 엑셀 파일을 Open(FileName, Password)으로 열어 내부 데이터를 파싱해 낸 뒤, 최신형 XLSX 포맷으로 재구성하고 AES 표준 암호화(SaveAsEncrypted)를 가동해 고도화된 보안 파일로 승격 인코딩할 수 있으며, 이 과정에 Excel 프로그램 호출 등의 무거운 동작이 수반되지 않습니다. 대량의 파일을 고속 처리하는 복호화 엔진을 구축하는 경우, 암호화 단계 돌입 전의 메모리 가공 단계의 처리 노하우는 서버 배치 작업을 위한 스트리밍 쓰기 가이드 기사를 함께 참고하십시오
암호화(Encryption)와 시트 보호(Protection)는 대립하는 기능이 아닙니다
마지막으로 짚고 넘어가야 할 점은 본 기사 선두의 경고를 '시트 보호는 쓸모없는 무용지물 기술이다'라고 오해하지 않는 것입니다. 시트 보호는 그 자체로 매우 유용합니다. 암호화와 시트 보호는 서로 해결하고자 하는 비즈니스 보안 영역이 다르며, 필요에 따라 중첩해서 함께 사용할 수 있는 상호 보완적인 기술입니다. 암호화는 '이 파일을 열어 조회할 수 있는 자격이 누구에게 있는가'를 판별하며, 시트 보호는 '이미 문서를 연 독자가 본문 내용 중 어떤 것들을 편집해 바꿀 수 있는가'를 다룹니다. 따라서 급여 대장 문서를 발송할 때 두 보호 장치를 모두 조율해 가동할 수 있습니다. 파일 자체를 SaveAsEncrypted로 암호화하여 패스워드 소지자만 조회하게 통제한 후, 내부 수식 셀들을 시트 보호로 잠가(lock) 수신자가 데이터를 조회하거나 필터링할 수는 있어도 수식 금액을 임의 수정하지는 못하게 통제하는 구성입니다. 시트 보호 설정을 기입하는 것은 지극히 합리적입니다. 다만, 데이터 원본 보호를 위해 실질적인 기밀성(confidentiality) 암호화가 필요한 화면에 시트 보호 설정 하나만 대충 얹어둔 채 보안을 안심하는 안일한 오판을 경고하는 것입니다
보안 적용에는 별도의 안전망이 존재하지 않으며 이는 의도된 보안 구조입니다. 5만 번 반복되는 고강도 키 유도 해시 연산으로 인해 무차별 대입 해킹으로 패스워드를 임의 복원하는 것은 물리적으로 불가하며, 파일 어디에도 임시 우회 키나 해독 힌트(backdoor)를 수록하지 않습니다. 설정한 비밀번호를 분실하면 문서 내의 소중한 데이터를 영구 손실하게 됩니다. 데이터베이스 접근 권한(credential)을 다룰 때처럼 책임감을 가지고 비밀번호 문자열을 안전하게 발행하고 안전하게 보관하여야 신뢰할 수 있는 보안을 완성할 수 있습니다
HotXLS를 사용하면 단 한 번의 API 호출로 실제 작동하는 강력한 오피스 파일 암호화를 구축할 수 있습니다. 시스템의 무결성은 이 호출을 둘러싼 주변 로직 설계(비밀번호 문자열 보존 보안, HotXLS가 복호화 해독을 할 수 없는 읽기 전용 제한 조건의 아키텍처 반영, 보안 감사 시 설명 가능한 투명한 알고리즘 사양 관리)에 달려 있습니다. SaveAsEncrypted API와 구형 레거시 OLE 양방향 복호화 처리는 모두 Delphi 및 C++Builder용 기본 스프레드시트 코어인 HotXLS Component에 일체형으로 수록되어 안정적으로 제공됩니다