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;