Trust & Provenance for Data at Rest

เพิ่มชั้นความปลอดภัยให้ไฟล์สำคัญที่ต้องเก็บระยะเวลานาน
ให้ปลอดภัยจากภัยควอนตัม

QSeal ลงลายเซ็นดิจิทัลที่ทนทานต่อภัยควอนตัมให้ไฟล์สำคัญที่จัดเก็บอยู่แล้วใน DMS, NAS, file share หรือ object storage พร้อมประทับเวลาและผูกชุดหลักฐานไว้กับไฟล์นั้น ณ ที่เก็บเดิม เพื่อให้ยืนยันได้เสมอว่าไฟล์ยังถูกต้อง ไม่ถูกแก้ไข และออกโดยผู้มีสิทธิ์จริง

QSeal ทำงานกับ ข้อมูลนิ่ง (data at rest) เท่านั้น — ไม่แทนที่ระบบรับส่งไฟล์ ไม่แทรกกลางเส้นทางสื่อสาร และไม่แตะข้อมูลระหว่างทาง

Protect Prove Preserve

ดูจุดเชื่อมกับระบบเดิม ตรวจสอบไฟล์ ดูหลักฐานที่ตรวจได้

Confidentialityปกป้องเนื้อหาไฟล์

Integrityตรวจพบการเปลี่ยนแปลง

Authenticityผูกหลักฐานกับผู้ออก

Long-Term Evidenceรองรับการตรวจสอบระยะยาว

The long-lived data problem

ข้อมูลมีอายุยาว
แต่รูปแบบการเข้ารหัสที่คุ้มครองข้อมูลมีอายุจำกัด

องค์กรรู้ว่าต้องเก็บสัญญา เอกสารราชการ หลักฐานทางกฎหมาย เวชระเบียน หรือข้อมูลโครงสร้างพื้นฐานไว้นานเพียงใด แต่การเข้ารหัส ลายเซ็นดิจิทัล ใบรับรอง และระบบจัดการกุญแจที่ใช้อยู่ในวันนี้ อาจเสื่อมความมั่นคงหรือไม่รองรับการตรวจสอบได้ครบตลอดช่วงเวลาที่ต้องเก็บข้อมูล

ความเสี่ยงไม่ได้เริ่มในวันที่คอมพิวเตอร์ควอนตัมพร้อมใช้งาน
สำเนาไฟล์ที่หลุดออกจากที่เก็บวันนี้อาจถูกเก็บไว้เพื่อถอดรหัสในภายหลัง ขณะที่เอกสารซึ่งต้องเชื่อถือได้อีกหลายปีข้างหน้า อาจเผชิญความเสี่ยงจากการปลอมลายเซ็นเมื่ออัลกอริทึมเดิมอ่อนกำลังลง

X+Y>Z

Quantum Exposure Window

Data Lifetime
ระยะเวลาที่ข้อมูลยังต้องถูกเก็บ ปกป้อง และตรวจสอบย้อนหลังได้

Migration Time
เวลาที่องค์กรต้องใช้สำรวจระบบ เปลี่ยนอัลกอริทึม ย้ายกุญแจ และปรับกระบวนการ

Threat Horizon
ช่วงเวลาที่ภัยควอนตัมหรือการเสื่อมความมั่นคงของรูปแบบการเข้ารหัสเดิมอาจกระทบข้อมูล

สมการนี้เป็นกรอบคัดกรองเชิงกลยุทธ์สำหรับจัดลำดับความเร่งด่วน ไม่ใช่มาตรฐานประเมินความเสี่ยงของ NIST, ISO หรือ ETSI

Where QSeal fits

ทำงานร่วมกับระบบเดิมขององค์กร
โดยไม่กระทบระบบงานหลัก

QSeal ไม่แตะฐานข้อมูลหลักและไม่เปลี่ยนวิธีทำงานของระบบต้นทาง แต่ทำงานกับไฟล์ที่ถูกเขียนลงที่เก็บเรียบร้อยแล้ว เพิ่มชุดหลักฐานให้ไฟล์นั้น ณ ที่เก็บเดิม

QSeal ไม่จำเป็นต้องเชื่อมต่อหรือแก้ไขตารางในฐานข้อมูลหลัก แต่ทำงานกับไฟล์ที่ถูกจัดเก็บเรียบร้อยแล้วในที่เก็บขององค์กร ดูรายละเอียดภายใน gateway

ระบบงานหลัก

ERP, ระบบทะเบียน, ระบบเอกสาร หรือ HIS ทำงานตามปกติ ไม่แก้ schema และไม่เพิ่มภาระฐานข้อมูล

ไฟล์ถูกเก็บลงที่เก็บ

เอกสารผลลัพธ์ เช่น สัญญา ใบรับรอง หรือรายงาน ถูกเขียนลง DMS, NAS, file share หรือ object storage

QSeal ผนึกที่เก็บนั้น

คำนวณ hash ลงลายเซ็น ประทับเวลา บันทึก provenance และบังคับใช้นโยบายชั้นข้อมูล

ไฟล์อยู่ที่เดิม

ผู้ใช้เปิดและค้นหาไฟล์ได้เหมือนเดิม โดยมีชุดหลักฐานประกบไว้ให้ตรวจสอบภายหลัง

Deployment modes

สามรูปแบบการทำงานที่แยกกันชัดเจน

องค์กรเลือกรูปแบบตามข้อจำกัดของระบบเดิมและระดับความลับของข้อมูล โดยใช้ร่วมกันในองค์กรเดียวได้

รูปแบบ	การทำงาน	ไฟล์ต้นฉบับ	เหมาะกับ
Seal in Place	ไฟล์ยังอยู่ใน DMS, NAS หรือ file share เดิม QSeal สร้าง sidecar evidence ประกบไว้ข้าง ๆ	ไม่ถูกแตะต้อง	ที่เก็บที่ไม่ต้องการเปลี่ยน workflow, preview หรือการค้นหา
Seal on Write	ผนึกทันทีที่ไฟล์ใหม่ถูกเขียนลงที่เก็บ ผ่าน watch folder หรือ event ของ object storage	คงรูปแบบเดิม	ที่เก็บที่มีไฟล์เข้าใหม่ต่อเนื่อง เช่น ระบบออกเอกสาร รายงานประจำวัน
Sealed Archive	เข้ารหัสไฟล์เป็น .qseal พร้อม manifest สำหรับเก็บในคลังระยะยาวหรือ off-site archive	เข้ารหัสทั้งก้อน	Backup, cold archive, ข้อมูลลับที่เก็บนอกศูนย์ข้อมูลหลัก

Seal in Place และ Seal on Write เป็นรูปแบบหลักสำหรับที่เก็บที่ใช้งานอยู่ ส่วน Sealed Archive ใช้กับคลังข้อมูลระยะยาวที่ไม่ต้องเปิดใช้บ่อย

ข้อมูลต้นฉบับอยู่ที่ใดในแต่ละโหมด

Seal in Place / Seal on Write — ไฟล์ต้นฉบับยังอยู่ในที่เก็บเดิมและเปิดใช้ได้ตามปกติ QSeal เก็บเฉพาะชุดหลักฐานตามนโยบาย
Sealed Archive — ไฟล์ถูกเข้ารหัสก่อนเก็บลงคลัง สิ่งที่อยู่ในคลังคือ ciphertext และ manifest ที่ลงลายเซ็นแล้ว

What QSeal must answer

ไฟล์สำคัญหนึ่งไฟล์ ต้องตอบคำถามให้ได้มากกว่า “เปิดได้หรือไม่”

QSeal สร้างชุดหลักฐานประกอบไฟล์ในแต่ละช่วงของการใช้งาน เพื่อให้ผู้ตรวจสอบและผู้ดูแลระบบตอบคำถามสำคัญได้อย่างเป็นระบบ

ไฟล์นี้คือไฟล์เดิมหรือไม่

ตรวจความครบถ้วนของเนื้อหาและตรวจพบการแก้ไขแม้เพียงบางส่วน

ใครเป็นผู้ออกหรือรับรอง

ผูกลายเซ็นกับกุญแจ ตัวตนองค์กร และ provenance ที่ตรวจสอบได้

ไฟล์มีอยู่ตั้งแต่เมื่อใด

ใช้หลักฐานเวลาและ daily anchor จากบุคคลที่สามประกอบการพิสูจน์

หลักฐานยังตรวจสอบได้หรือไม่

ตรวจสถานะอัลกอริทึม กุญแจ และต่ออายุหลักฐานก่อนกลไกเดิมเสื่อมความมั่นคง

01 · Protect

ปกป้องไฟล์ที่จัดเก็บ

ใช้ Hybrid Post-Quantum Key Establishment สร้างกุญแจสำหรับเข้ารหัสไฟล์ที่เก็บในคลัง ส่วนช่องทางที่ QSeal ใช้เข้าถึงที่เก็บป้องกันด้วย TLS 1.3 แบบ Hybrid PQC

X25519 + ML-KEM-768
AES-256-GCM · HKDF-SHA-256

02 · Prove

สร้างหลักฐานที่มาและความถูกต้อง

บันทึก hash, metadata, ผู้ผนึก, เวลา, ชั้นความลับ และข้อมูลกุญแจไว้ในขอบเขตลายเซ็น เพื่อให้การแก้ไขถูกตรวจพบและตรวจสอบที่มาได้

ML-DSA-65 · FIPS 204
Signed provenance · Merkle evidence

03 · Preserve

รองรับการตรวจสอบเมื่อรูปแบบการเข้ารหัสเปลี่ยนแปลง

สร้างหลักฐานชุดใหม่ด้วย hash และ timestamp ก่อนอัลกอริทึมหรือใบรับรองเดิมเสื่อมความมั่นคง โดยไม่แก้ไขไฟล์ต้นฉบับ

RFC 3161 timestamp
Evidence renewal aligned with RFC 4998 concepts

Discover

อ่านไฟล์จากที่เก็บ คำนวณลายนิ้วมือ และบันทึก metadata

Classify

ตรวจเนื้อหา จัดชั้นข้อมูล และบังคับใช้นโยบาย

Seal

เข้ารหัส สร้าง Merkle evidence และลงลายเซ็น

Store & Verify

เขียนกลับที่เก็บเดิมขององค์กรและตรวจยืนยันว่าเขียนครบถ้วน

Verify & Renew

ตรวจซ้ำเป็นรอบ สร้าง anchor และต่ออายุหลักฐาน

เปิดดูรายละเอียดเชิงเทคนิคของแต่ละขั้น

อ่านไฟล์จากที่เก็บและคำนวณ SHA-256

ประมวลผลแบบ streaming และเก็บลายนิ้วมือของไฟล์ตั้งแต่จุดที่อ่านพบในที่เก็บ

ตรวจเนื้อหา จัดชั้นข้อมูล และบังคับนโยบาย

ตรวจข้อมูลอ่อนไหว บันทึกขอบเขตการตรวจ แล้วบังคับกฎว่าต้องเข้ารหัสหรือเซ็นหรือไม่ ส่งไปที่ใดได้ และเก็บนานเท่าใด

ลงลายเซ็น ML-DSA-65

ครอบ hash, provenance, ชั้นข้อมูล, key identifier และราก Merkle ไว้ในขอบเขตลายเซ็นเดียวกัน

เข้ารหัสเมื่อนโยบายกำหนด

โหมด Sealed Archive ใช้กุญแจจาก X25519 + ML-KEM-768 ผ่าน KDF แล้วเข้ารหัสด้วย AES-256-GCM

เขียนกลับที่เก็บเดิมและตรวจยืนยัน

วางไฟล์และชุดหลักฐานกลับใน DMS, NAS, file share หรือ object storage เดิม แล้วตรวจ hash ตามความสามารถของที่เก็บ

ผูกหลักฐานเข้ากับ Daily Anchor

รวมหลักฐานประจำวันด้วย Merkle root ลงลายเซ็น และขอ RFC 3161 timestamp จากผู้ให้บริการภายนอก

ในโหมด Sealed Archive ไฟล์ถูกเข้ารหัสก่อนเก็บลงคลัง ส่วนในโหมด Seal in Place ไฟล์ต้นฉบับยังอยู่ในที่เก็บเดิมและ QSeal เก็บเฉพาะชุดหลักฐาน ดูแบบเต็มหน้า

Crypto agility

เปลี่ยนอัลกอริทึมที่ QSeal จุดเดียว ไม่ต้องแก้ระบบต้นทาง

ระบบต้นทางเรียก API เดิมเสมอ ส่วนอัลกอริทึม กุญแจ ผู้ให้บริการ KMS/HSM และนโยบายเวลาถูกกำหนดผ่าน cryptographic profile ที่มีเวอร์ชันกำกับ

// cryptographic profile ที่ผูกกับชุดหลักฐาน
{
  "profile_id": "qseal-standard-2026",
  "profile_version": 1,
  "transport": "X25519MLKEM768",
  "content_encryption": "AES-256-GCM",
  "signature": "ML-DSA-65",
  "hash": "SHA-256",
  "timestamp": "RFC3161",
  "renew_before": "2030-01-01"
}

// ระบบต้นทางเรียก endpoint เดิมเสมอ
POST /api/v1/seal

เปลี่ยนอัลกอริทึม กุญแจ หรือนโยบายเวลาที่ profile ของ QSeal จุดเดียว โดยไม่ต้องแก้ระบบงานหลัก DMS หรือระบบทะเบียน

สิ่งที่ crypto agility ต้องครอบคลุม

เปลี่ยนอัลกอริทึมผ่าน profile ที่มีเวอร์ชัน และรองรับลายเซ็นคู่ในช่วงย้ายระบบ

เปลี่ยนกุญแจหมุนกุญแจได้ โดยเก็บกุญแจเก่าและ trust anchor เดิมไว้ให้ตรวจย้อนหลัง

ต่ออายุหลักฐานต่ออายุ hash, timestamp และ evidence chain ก่อนกลไกเดิมเสื่อมความมั่นคง

เปลี่ยนผู้ให้บริการกุญแจย้าย KMS/HSM ได้โดยไม่เปลี่ยน API ที่ระบบต้นทางเรียกใช้

ค่าที่แสดงบนหน้านี้ เช่น ML-KEM-768, ML-DSA-65 และ SHA-256 คือค่าตั้งต้นของ profile ปัจจุบัน ไม่ใช่ค่าที่ผูกตายกับระบบ

Verify without trusting the platform

หลักฐานควรตรวจได้โดยไม่ผูกกับระบบเดิมเพียงระบบเดียว

QSeal แยก “ไฟล์” ออกจาก “ชุดหลักฐาน” และเปิดให้ส่งออกข้อมูลที่จำเป็นต่อการตรวจสอบ เพื่อหลีกเลี่ยงการผูกขาดกับแพลตฟอร์มเดียว

Evidence Package

ชุดหลักฐานควรบอกได้ว่าอะไรถูกลงลายเซ็น ใช้กุญแจใด ผู้ผนึกได้รับการยืนยันจากระบบใด ไฟล์มี hash เท่าใด และมีหลักฐานเวลาใดประกอบ

File integritySHA-256 และ Merkle root ของข้อมูล

Signed provenanceผู้ออก เวลา ชั้นความลับ และ key identifier

External time evidenceRFC 3161 timestamp token จากผู้ให้บริการภายนอก

Renewal chainลำดับหลักฐานใหม่ที่ครอบหลักฐานเดิมไว้

Verification statusผลตรวจพร้อมเหตุผล ไม่รายงานเพียง “ผ่าน/ไม่ผ่าน”

// ตัวอย่างส่วนหนึ่งของ signed manifest
{
  "file": {
    "name": "สัญญาบริการ.pdf",
    "sha256": "e2d64ad25819..."
  },
  "provenance": {
    "subject": "somchai@example.co.th",
    "identity_provider": "องค์กร.example",
    "sealed_at": "2026-07-29T01:40:56+07:00"
  },
  "classification": "confidential",
  "crypto": {
    "kem": "X25519+ML-KEM-768",
    "signature": "ML-DSA-65",
    "aead": "AES-256-GCM"
  },
  "evidence": {
    "merkle_root": "ca09e76d5c13...",
    "key_id": "7393e72c1e32..."
  }
}

โครงสร้างจริงควรกำหนด canonical encoding, versioning และ validation profile ให้แน่นอน เพื่อให้ตรวจซ้ำได้เหมือนกันทุกระบบ

กุญแจสาธารณะที่เชื่อถือได้

ดาวน์โหลดผ่าน HTTPS ที่ตรวจใบรับรองตามปกติ พร้อมแสดง fingerprint และ key ID ไม่ควรข้ามการตรวจ TLS เพราะเปิดช่องให้ได้รับกุญแจปลอม

วงจรชีวิตและประวัติกุญแจ

ระบุวันที่เริ่มใช้ เลิกใช้ และสถานะเพิกถอน พร้อมเผยแพร่กุญแจเก่าทุกชุดต่อไป เพื่อให้ไฟล์ที่ผนึกไว้ก่อนหน้ายังตรวจย้อนหลังได้

Offline verifier

หน่วยงานที่นำเอกสารลับหรือข้อมูลส่วนบุคคลขึ้นเว็บสาธารณะไม่ได้ ตรวจในเครื่องด้วยไฟล์ หลักฐาน และกุญแจสาธารณะได้

สถานะปัจจุบันของหลักฐานเวลาและ anchor

มีแล้ว · External TSA Timestamp
ชุดหลักฐานได้รับการประทับเวลาจากผู้ให้บริการ timestamp ภายนอกตาม RFC 3161 จึงพิสูจน์ได้ว่าหลักฐานมีอยู่ก่อนเวลาที่ระบุ

อยู่ระหว่างดำเนินการ · External Append-only Anchor
การเผยแพร่ daily Merkle root ไปยัง repository แบบ append-only องค์กรอิสระ หรือช่องทางภายนอกที่แก้ย้อนหลังไม่ได้ ยังไม่เปิดใช้งานเต็มรูปแบบ ปัจจุบันบันทึกหลักฐานยังเก็บอยู่ภายในระบบ จึงไม่ควรตีความว่า anchor ทั้งชุดถูกกระจายออกไปภายนอกแล้ว

เปิดดูตารางชั้นการเข้ารหัสและเทคโนโลยีที่ใช้

ชั้น	หน้าที่	เทคโนโลยี
Transport Protection	ปกป้องช่องทางที่ QSeal ใช้เข้าถึงที่เก็บ	TLS 1.3 · X25519MLKEM768
Content Encryption	ปกป้องไฟล์ที่จัดเก็บในคลัง	AES-256-GCM · DEK ต่อไฟล์
Key Protection	ห่อหุ้มและควบคุม DEK	Enterprise KMS/HSM · Recipient key
Integrity & Provenance	ตรวจการแก้ไขและที่มา	SHA-256 · Merkle · ML-DSA-65
Time Evidence	ยืนยันว่าหลักฐานมีอยู่ก่อนเวลาหนึ่ง	RFC 3161 TSA
Long-term Renewal	ต่ออายุหลักฐานก่อนอัลกอริทึมเสื่อม	RFC 4998-aligned renewal
Identity Binding	ผูกผู้ใช้ ระบบ และองค์กร	OIDC · Signing key / certificate

ML-KEM-768 อ้างอิง FIPS 203 และ ML-DSA-65 อ้างอิง FIPS 204 ส่วน X25519MLKEM768 คือการประกอบ hybrid key agreement สำหรับ TLS ตามแนวทาง IETF จึงไม่ควรเข้าใจว่าชุด hybrid ทั้งชุดคืออัลกอริทึมที่ FIPS 203 รับรองโดยตรง

FIPS 203 · ML-KEM FIPS 204 · ML-DSA TLS 1.3 · Hybrid PQC AES-256-GCM SHA-256 · Merkle Tree RFC 3161 · Timestamp RFC 4998 · Evidence Renewal Concepts OIDC · Enterprise Identity

การระบุชื่อมาตรฐานหมายถึงเทคโนโลยีหรือแนวคิดที่ใช้อ้างอิง ไม่ควรตีความว่าได้รับการรับรองความสอดคล้องหรือการรับรองผลิตภัณฑ์ เว้นแต่มีผลการทดสอบหรือใบรับรองแยกต่างหาก

Operational capabilities

ออกแบบให้ทำงานร่วมกับระบบเดิมขององค์กร

QSeal เป็น control layer สำหรับไฟล์สำคัญ ไม่ใช่บังคับให้องค์กรย้ายข้อมูลทั้งหมดเข้าสู่ repository ใหม่

เชื่อมกับที่เก็บได้หลายทาง

ค้นพบไฟล์ผ่าน watch folder, เหตุการณ์ของ object storage, การสแกนตามรอบ หรือเรียกผ่าน REST API โดยไม่ต้องเปลี่ยนวิธีทำงานของระบบต้นทาง

Sidecar evidence หรือ Sealed Archive

เก็บต้นฉบับตามเดิมพร้อมหลักฐานประกบด้านข้างเพื่อรักษา workflow และ preview เดิม หรือผนึกไฟล์เป็นก้อนเดียวสำหรับคลังระยะยาว

Storage connectors

ทำงานกับ DMS, NAS, file share, object storage, WebDAV หรือ cloud drive ที่องค์กรใช้อยู่ โดยไม่ยึดกับผู้ให้บริการรายเดียว

Policy-based classification

บังคับใช้นโยบายตามชั้นข้อมูล ผู้ผนึก ที่เก็บที่อนุญาต อายุจัดเก็บ การเข้ารหัส และการลงลายเซ็น

Tamper-evident audit trail

เชื่อมเหตุการณ์ด้วย hash และปิดรอบด้วยลายเซ็น เพื่อให้การเปลี่ยนแปลงย้อนหลังถูกตรวจพบ พร้อมเชื่อมตัวตนผู้ใช้จาก OIDC เข้ากับ provenance

ตรวจซ้ำตามรอบและส่งออกหลักฐาน

ดึงไฟล์มาตรวจซ้ำเป็นรอบเพื่อบันทึกประวัติการคงสภาพ และส่งออก public key, manifest, timestamp token และ renewal chain ให้ผู้ตรวจภายนอก

องค์ประกอบทางเทคนิค: การเชื่อมต่อกับที่เก็บใช้ rclone เป็น connector engine ภายใน ส่วนคุณค่าที่ QSeal รับผิดชอบคือนโยบาย ที่มา หลักฐาน การตรวจสอบ และการต่ออายุ รายละเอียดของส่วนประกอบและไลบรารีที่ใช้อยู่ในเอกสาร software bill of materials

Data governance

ชั้นข้อมูลที่พิสูจน์ได้ และนโยบายที่บังคับก่อนไฟล์ออกจากองค์กร

การจัดชั้นข้อมูลจะมีความหมายก็ต่อเมื่อพิสูจน์ได้ว่าไฟล์ถูกจัดชั้นใดในขณะที่ผนึก และเมื่อนโยบายของชั้นนั้นถูกบังคับใช้ก่อนข้อมูลออกจากระบบ ไม่ใช่ตรวจสอบย้อนหลังหลังเกิดเหตุ

ชั้นข้อมูล	อายุจัดเก็บ	ต้องเข้ารหัส	ต้องลงลายเซ็น	ผู้มีสิทธิ์ผนึก	ที่เก็บที่อนุญาต
เปิดเผยได้	1 ปี	ไม่บังคับ	ไม่บังคับ	ทุกบทบาท	ทุกที่เก็บ
ใช้ภายใน	3 ปี	ไม่บังคับ	บังคับ	ทุกบทบาท	ทุกที่เก็บ
ความลับ	10 ปี	บังคับ	บังคับ	ทุกบทบาท	กำหนดรายการได้
ความลับสูงสุด	20 ปี	บังคับ	บังคับ	ผู้ดูแลระบบ	กำหนดรายการได้

ค่าข้างต้นเป็นค่าตั้งต้น องค์กรกำหนดชื่อชั้น อายุจัดเก็บ ข้อบังคับด้านการเข้ารหัสและลายเซ็น ที่เก็บที่อนุญาต และรอบการต่ออายุหลักฐานของแต่ละชั้นได้เอง

ระดับชั้นถูกผนวกอยู่ในขอบเขตลายเซ็น ML-DSA-65 จึงพิสูจน์ได้ว่าไฟล์ถูกจัดชั้นใดในขณะผนึก ไม่ใช่ค่าที่แก้ไขในฐานข้อมูลได้ภายหลัง ระบบเสนอชั้นจากเนื้อหาไฟล์ให้ได้และยกระดับเท่านั้นไม่ลดระดับ แต่การตรวจเนื้อหาไม่ครอบคลุมไฟล์ที่บีบอัด เข้ารหัสมาก่อน หรือภาพที่ยังไม่ผ่าน OCR ผลการตรวจจึงเป็นข้อมูลประกอบการตัดสินใจ ไม่ใช่การรับรองเนื้อหา

High-X information

เหมาะกับข้อมูลที่ต้องเก็บเป็นความลับและตรวจสอบย้อนหลังในระยะยาว

QSeal เหมาะกับข้อมูลที่มีระยะเวลาจัดเก็บยาว มีผลกระทบสูง หรือจำเป็นต้องใช้เป็นหลักฐานอ้างอิงในอนาคต

Healthcare

เวชระเบียนและข้อมูลสุขภาพ

ปกป้องความลับและตรวจสอบความครบถ้วนตลอดระยะเวลาจัดเก็บตามข้อกำหนดและการใช้งาน

Government

เอกสารภาครัฐและจดหมายเหตุ

รักษาที่มา เวลารับรอง และประวัติการคงสภาพสำหรับเอกสารที่ต้องอ้างอิงระยะยาว

Legal

สัญญาและหลักฐานทางกฎหมาย

จัดเก็บหลักฐานประกอบที่ตรวจสอบได้ โดยแยกความถูกต้องของไฟล์ออกจากคำกล่าวอ้างของระบบ

Finance

งบการเงินและงานตรวจสอบ

สร้าง chain of evidence สำหรับไฟล์ที่ต้องตรวจย้อนกลับตามรอบบัญชีและข้อกำกับ

Research

ผลงานวิจัยและชุดข้อมูล

พิสูจน์ที่มา เวอร์ชัน และช่วงเวลาที่ข้อมูลหรือผลการทดลองมีอยู่

ทรัพย์สินทางปัญญา

ผูก hash, ผู้สร้าง และหลักฐานเวลาเพื่อรองรับการพิสูจน์ลำดับการสร้างและการถือครอง

CII

ข้อมูลโครงสร้างพื้นฐานสำคัญ

ปกป้องไฟล์กำหนดค่า แบบระบบ และข้อมูลปฏิบัติการที่มีผลกระทบสูง

Backup

Backup และหลักฐานเหตุการณ์

ตรวจว่าชุดสำรองและ log สำคัญยังเป็นชุดเดิมและมีประวัติการตรวจสอบต่อเนื่อง

เข้าใช้งาน QSeal ตรวจสอบไฟล์ที่มีอยู่

เพิ่มชั้นความปลอดภัยให้ไฟล์สำคัญที่ต้องเก็บระยะเวลานานให้ปลอดภัยจากภัยควอนตัม

ข้อมูลมีอายุยาวแต่รูปแบบการเข้ารหัสที่คุ้มครองข้อมูลมีอายุจำกัด

ทำงานร่วมกับระบบเดิมขององค์กรโดยไม่กระทบระบบงานหลัก