LlosLab Software Development BlogEngineering notes for PDF, Delphi, and document software developers.

기술 문서

HotPDF Component: Delphi에서 AES-256 encryption and permission policy

HotPDF Component

HotPDF는 Delphi 및 C++Builder 애플리케이션을 위한 네이티브 VCL PDF 라이브러리입니다. 외부 PDF 런타임 배포 없이 PDF 생성, 편집, 양식, 주석, 암호화, 디지털 서명, Unicode 글꼴 처리, 표준 지향 출력, 프리플라이트 보고를 지원합니다.

이 글은 teams that must generate protected PDF output without relying on a desktop PDF application을 위한 글입니다. AES-256 encryption and permission policy을 단순한 컴포넌트 호출이 아니라 운영 환경의 문서 엔지니어링으로 다룹니다.

실제 위험은 a password-protected document is not automatically a governed document if permissions, metadata encryption, attachment handling, and password custody are undefined입니다. 따라서 명확한 계약, 관찰 가능한 진단, 실제 고객 파일을 반영한 회귀 샘플이 필요합니다.

아키텍처 결정

Separate document security from application authentication. owner password custody and rotation policy / user password delivery path and recovery procedure

  • owner password custody and rotation policy
  • user password delivery path and recovery procedure
  • print, copy, accessibility, annotation, and form-fill permissions
  • whether metadata, embedded files, and attachments must also be protected

구현 흐름

Define the encryption profile before writing content. The order below keeps the workflow reviewable for Delphi and C++Builder teams.

  1. select an encryption profile from application policy rather than UI text
  2. validate that the requested permissions match the customer agreement
  3. write the document to a controlled temporary location before distribution
  4. open the output with a target viewer and verify the permissions dialog
  5. log password policy identifiers without logging secret values

검증 증거

What a security audit should record. Keep these fields with the output or support record.

  • encryption algorithm, permission bitmask, metadata policy, and attachment policy
  • profile version, operator identity, output hash, and distribution channel
  • viewer compatibility result for the supported customer environments
  • redacted failure reason when password generation or protected save fails

Permissions, metadata, and viewer compatibility

AES-256 output should be treated as a named policy. The policy controls owner and user passwords, print and copy permissions, metadata visibility, and compatibility expectations for the viewers that will open the file.

지원 패키지 설계

HotPDF Component가 배포된 후 가장 유용한 지원 패키지는 입력, 프로필, 출력, 그리고 실패한 정확한 단계를 설명하는 것입니다

  • encryption algorithm, permission bitmask, metadata policy, and attachment policy
  • profile version, operator identity, output hash, and distribution channel
  • viewer compatibility result for the supported customer environments
  • redacted failure reason when password generation or protected save fails
  • terminology snapshot: AES-256, owner password, user password, permissions

AES-256 encryption and permission policy에 대한 엔지니어링 검토 노트

이 검토 노트를 사용해 기능이 데모 단계를 넘어섰고 출시, 지원, 고객 에스컬레이션 상황에서 설명할 수 있는지 확인합니다

  • 결정: owner password custody and rotation policy. 구현상 핵심 지점: validate that the requested permissions match the customer agreement. 승인 증거: viewer compatibility result for the supported customer environments. 회귀 트리거: encrypted attachments need the same retention and access policy as the main file
  • 결정: user password delivery path and recovery procedure. 구현상 핵심 지점: write the document to a controlled temporary location before distribution. 승인 증거: redacted failure reason when password generation or protected save fails. 회귀 트리거: legacy viewers may open a file but ignore or misreport newer permission flags
  • 결정: print, copy, accessibility, annotation, and form-fill permissions. 구현상 핵심 지점: open the output with a target viewer and verify the permissions dialog. 승인 증거: encryption algorithm, permission bitmask, metadata policy, and attachment policy. 회귀 트리거: metadata can leak business information if encryption settings omit it

경계 사례

  • legacy viewers may open a file but ignore or misreport newer permission flags
  • metadata can leak business information if encryption settings omit it
  • support logs must never include owner passwords, user passwords, or password hints
  • encrypted attachments need the same retention and access policy as the main file

Delphi / C++Builder 참고 사항

HotPDF Component should sit behind a small service boundary that receives files, streams, profiles, and credentials, then returns output paths, warnings, metrics, and validation status. 중요한 용어는 AES-256, owner password, user password, permissions, encrypted metadata, protected save.

Delphi 코드 예제

다음 Delphi 스케치는 이 주제에 맞는 실무형 서비스 경계를 보여 줍니다. 정책 검사, 로깅, 검증을 좁은 제품 호출 구간 밖에 두면 워크플로를 테스트하기 쉽습니다.

procedure SaveProtectedPdf(const OutputFile: string; const Profile: TPdfSecurityProfile);
var
  Pdf: THotPDF;
begin
  Pdf := THotPDF.Create(nil);
  try
    Pdf.FileName := OutputFile;
    Pdf.BeginDoc;
    WriteDocumentBody(Pdf);
    ApplyEncryptionProfile(Pdf, Profile);
    Pdf.EndDoc;
    VerifyPermissions(OutputFile, Profile.ExpectedPermissions);
  finally
    Pdf.Free;
  end;
end;

운영 체크리스트

  • 워크플로는 빈 파일, 일반 고객 파일, 최악의 파일에서 실행합니다
  • 생성된 PDF는 대상 뷰어, 검증기, 프린터 또는 downstream 애플리케이션에서 엽니다
  • 제품 버전, 프로필 버전, 입력 해시, 출력 경로, 경과 시간, 경고 수를 기록합니다
  • 암호, 인증서, 임시 파일, 고객 데이터는 명확한 보존 규칙에 따라 관리합니다
  • 고객 파일이 새로운 경계 사례를 드러내면 회귀 문서를 추가합니다

제품 문서

HotPDF Component

추가 코드 예제

Pdf.ActivateProtection := True;
Pdf.CryptKeyLength := aes256;
Pdf.UserPassword := '';                      // anyone can open the file
Pdf.OwnerPassword := 'rotate-me-quarterly';  // guards the permission set
Pdf.ProtectOptions := [prPrint, prPrint12bit, prExtractContent];
Pdf.BeginDoc;
// ... page content ...
Pdf.EndDoc;
var
  Pdf: THotPDF;
  PageCount: Integer;
begin
  Pdf := THotPDF.Create(nil);
  try
    PageCount := Pdf.LoadFromFile('encrypted.pdf', 'open-secret');
    if PageCount > 0 then
    begin
      Pdf.ActivateProtection := False;   // drop encryption on save
      Pdf.SaveLoadedDocument('plain.pdf');
    end;
  finally
    Pdf.Free;
  end;
end;