Digital Signature กับเลขที่เอกสาร

25
มีนาคม

สำหรับทีม Implement

Digital Signature กับเลขที่เอกสาร — ทำไมไม่เหมือนระบบสารบรรณ และวิธีแก้ปัญหาด้วย Incremental Save

"ทำไมระบบ ERP เปลี่ยนเลขเอกสารหลังลงนามไม่ได้?" — คำถามนี้เกิดขึ้นเกือบทุกครั้งที่ implement ระบบ ERP ร่วมกับ Digital Signature ในหน่วยงานที่เคยใช้ระบบสารบรรณอิเล็กทรอนิกส์ (e-Saraban) มาก่อน ผู้ใช้คุ้นเคยกับระบบสารบรรณที่ "ลงนามก่อน แล้วค่อยออกเลข" จึงคาดหวังว่าระบบ ERP จะทำแบบเดียวกันได้

บทความนี้อธิบายว่า ทำไมมันทำแบบเดียวกันไม่ได้ในเชิงเทคนิค ความแตกต่างระหว่าง "Server Sign" ของระบบสารบรรณกับ "Digital Signature จริงตามมาตรา 28" และ วิธีแก้ปัญหา ที่ถูกต้องทั้งทางเทคนิคและทางกฎหมาย

สรุปสั้น: ระบบสารบรรณใช้ "Server Sign" (แค่ประทับรูปลายเซ็นลงบน PDF) จึงแก้ไขเอกสารหลัง "ลงนาม" ได้ แต่ Digital Signature จริง ตามมาตรา 28 ใช้การเข้ารหัส (Cryptographic Hash) — แก้ไขแม้แต่ 1 ตัวอักษร ลายเซ็นจะ invalid ทันที วิธีแก้คือใช้ PDF Incremental Save ที่เพิ่มเลขเอกสารต่อท้ายโดยไม่แก้ไขส่วนที่ลงนามไปแล้ว

ปัญหาที่เกิดขึ้น

ในกระบวนการทำงานของหน่วยงานภาครัฐ ขั้นตอนการออกเอกสารมักเป็นแบบนี้:

1 สร้างเอกสาร — ร่างหนังสือ ยังไม่มีเลขที่

↓

2 ผู้อนุมัติลงนาม — หัวหน้ากลุ่ม/ผู้อำนวยการ ลงนาม

↓

3 ออกเลขเอกสาร + วันที่ — สารบรรณลงทะเบียน ออกเลขที่ ลงวันที่

ในระบบสารบรรณอิเล็กทรอนิกส์ ขั้นตอนนี้ทำงานได้ปกติเพราะ "การลงนาม" ในระบบสารบรรณไม่ใช่ Digital Signature จริง — เป็นแค่การประทับรูปลายเซ็น (Server Sign) ลงบน PDF ซึ่งเอกสารยังแก้ไขได้หลัง "ลงนาม"

แต่ในระบบ ERP ที่ใช้ Digital Signature จริงตามมาตรา 28 ของ พ.ร.บ.ธุรกรรมอิเล็กทรอนิกส์ การเปลี่ยนเลขเอกสารหรือวันที่หลังลงนาม = การแก้ไขเอกสาร = ลายเซ็นเป็นโมฆะ

ปัญหา: PDF ถูกสร้างพร้อมเลข "Draft" → ผู้อนุมัติลงนาม Digital Signature → ระบบเปลี่ยนเลข + วันที่ตอน Complete → ลายเซ็นที่ลงไปก่อนหน้า invalid ทั้งหมด

"Server Sign" ของระบบสารบรรณ vs "Digital Signature" จริง — ต่างกันอย่างไร?

นี่คือจุดที่ทำให้เกิดความเข้าใจผิดมากที่สุด:

รายการ	Server Sign (ระบบสารบรรณ)	Digital Signature จริง (มาตรา 28)
วิธีการ	ประทับรูปลายเซ็น (Image) ลงบน PDF	ใช้กุญแจส่วนตัว (Private Key) เข้ารหัส Hash ของเอกสารทั้งฉบับ
แก้ไขหลังลงนาม	ได้ — เพราะไม่ได้ตรวจสอบความถูกต้อง	ไม่ได้ — ระบบตรวจพบทันที
ตรวจสอบตัวตน	ตรวจจาก login ของ server (ไม่มี PKI)	ตรวจจาก Certificate ที่ออกโดย CA ที่น่าเชื่อถือ
ความถูกต้องของเอกสาร (Integrity)	ไม่รับรอง — ใครก็แก้ไข PDF ได้	รับรอง 100% — เปลี่ยนแม้ 1 byte ก็รู้
มาตรฐาน	ไม่มีมาตรฐานกลาง (แต่ละ vendor ทำต่างกัน)	PAdES (ETSI EN 319 142), X.509, RFC 3161
รองรับกฎหมาย	ไม่เข้าเกณฑ์มาตรา 28	รองรับเต็มรูปแบบตาม พ.ร.บ.ธุรกรรมอิเล็กทรอนิกส์
เปิดใน Adobe Acrobat	ไม่แสดง Signature Panel / แสดง "None PKI"	แสดง Signature Panel + ข้อมูล Certificate + ผู้ลงนาม + วันเวลา

พูดง่ายๆ: "Server Sign" ของระบบสารบรรณ เหมือนแปะสติกเกอร์ลายเซ็นบนกระดาษ — ใครก็ลอกออกแล้วเปลี่ยนเนื้อหาได้ แต่ "Digital Signature" จริง เหมือนผนึก Wax Seal บนซอง — เปิดซองแล้วรู้ทันทีว่ามีคนแกะ

ทำไมระบบสารบรรณเปลี่ยนเลขเอกสารหลังลงนามได้ แต่ ERP ทำไม่ได้?

ขั้นตอน	ระบบสารบรรณ (Server Sign)	ระบบ ERP (Digital Signature จริง)
1. สร้างเอกสาร	ร่างเอกสาร (ไม่มีเลข)	สร้างเอกสาร Draft → สร้าง PDF
2. ลงนาม	Server แปะรูปลายเซ็นลง PDF	ผู้อนุมัติลงนาม Digital Signature ด้วย Private Key → Hash ล็อกเนื้อหาทั้งฉบับ
3. เปลี่ยนเลข + วันที่	✅ ทำได้ — PDF ถูกแก้ไขใหม่ ไม่มีอะไรตรวจสอบ	❌ ทำไม่ได้ — เปลี่ยนแม้ 1 ตัวอักษร Hash ไม่ตรง ลายเซ็น invalid
ผลลัพธ์	เอกสารมีเลข + ลายเซ็น (แต่ไม่ปลอดภัย)	ต้องใช้วิธีอื่น → Incremental Save

วิธีแก้ปัญหา: PDF Incremental Save + Organization Stamp

มาตรฐาน PDF (ISO 32000) และมาตรฐาน Digital Signature ในยุโรป (PAdES — PDF Advanced Electronic Signatures) กำหนดวิธีที่ถูกต้องไว้แล้ว คือ Incremental Save

Incremental Save คืออะไร?

Incremental Save คือการ เพิ่มข้อมูลต่อท้ายไฟล์ PDF โดยไม่แก้ไขส่วนเดิม — เปรียบเทียบง่ายๆ:

การแก้ไขปกติ = ลบข้อความเดิม เขียนใหม่ทับ → ลายเซ็นเดิม invalid
Incremental Save = เปิดหน้าใหม่ต่อท้ายหนังสือ เขียนเพิ่ม → ลายเซ็นในหน้าเดิมยัง valid → ลงนามใหม่ครอบคลุมทั้งหมด

Flow ที่ถูกต้อง

1 สร้าง PDF — เนื้อหาครบถ้วน เลขเอกสาร = "DRAFT" หรือเว้นว่าง

↓

2 ผู้อนุมัติ 1 ลงนาม Digital Signature (Incremental Save #1)
→ ลายเซ็น 1 ครอบคลุม: เนื้อหา + "DRAFT"

↓

3 ผู้อนุมัติ 2 ลงนาม Digital Signature (Incremental Save #2)
→ ลายเซ็น 2 ครอบคลุม: เนื้อหา + "DRAFT" + ลายเซ็น 1

↓

4 Complete → ระบบ Stamp เลขเอกสาร + วันที่ (Incremental Save #3)
→ เพิ่มเลขเอกสาร + วันที่เป็น Annotation ต่อท้าย (ไม่แก้ไขส่วนเดิม)

↓

5 Organization Signature ลงนามทับ (Incremental Save #4)
→ ลายเซ็นองค์กร ครอบคลุม: ทุกอย่าง + เลขเอกสาร + วันที่ = Final Seal

ผลลัพธ์: ทุกลายเซ็น Valid

ลายเซ็น	ครอบคลุม	สถานะ	ใน Adobe Acrobat
ผู้อนุมัติ 1	เนื้อหา + Draft	✅ Valid	"Signed, document modified after signing" (ปกติของ multi-sign)
ผู้อนุมัติ 2	เนื้อหา + Draft + ลายเซ็น 1	✅ Valid	"Signed, document modified after signing"
Organization Stamp	ทุกอย่าง + เลขเอกสาร + วันที่	✅ Valid	"Signed, no modifications" (Final)

ทำไมลายเซ็นก่อนหน้ายัง Valid? เพราะ Incremental Save = เพิ่มข้อมูลต่อท้าย (append) ไม่ใช่แก้ไข (modify) — เปรียบเทียบกับหนังสือ: การเพิ่มภาคผนวกท้ายเล่มไม่ได้เปลี่ยนเนื้อหาบทที่ 1 ดังนั้นลายเซ็นที่ลงในบทที่ 1 ยัง valid

ข้อมูลที่ระบบ ERP บันทึกอยู่แล้ว — ไม่ต้องกังวลเรื่องวันที่

คำถามที่พบบ่อย: "แล้ววันที่ที่แสดงบนเอกสาร เป็นวันที่ไหน?" คำตอบคือ ในระบบ ERP ที่ออกแบบมาดี วันที่ทุกขั้นตอนถูกบันทึกไว้ครบถ้วน:

ข้อมูล	แหล่งที่มา	แก้ไขได้?
วันที่สร้างเอกสาร	ระบบ ERP (Created timestamp)	ไม่ได้
วันเวลาที่ผู้อนุมัติแต่ละคนลงนาม	ใน Digital Signature (Signing Time) + แสดงใต้ลายเซ็น	ไม่ได้ — เป็นส่วนหนึ่งของ Signature
วันที่เอกสาร (DateDoc)	Stamp ตอน Complete (Incremental Save)	ไม่ได้ — Organization Signature ครอบคลุม
เลขที่เอกสาร (DocumentNo)	Stamp ตอน Complete (Incremental Save)	ไม่ได้ — Organization Signature ครอบคลุม
Timestamp (เวลาที่แน่นอน)	TSA (Time Stamping Authority) ถ้ามี	ไม่ได้ — รับรองโดย TSA ภายนอก

สรุป: ระบบ ERP ปลอดภัยกว่าระบบสารบรรณ

เกณฑ์	ระบบสารบรรณ (Server Sign)	ระบบ ERP (Digital Signature + Incremental Save)
ตรวจสอบตัวตนผู้ลงนาม	❌ แค่ login server	✅ PKI Certificate
ตรวจสอบว่าเอกสารถูกแก้ไข	❌ ไม่ได้	✅ Hash ตรวจสอบทุก byte
ปลอมแปลงลายเซ็น	❌ ทำได้ (แค่ copy รูป)	✅ ทำไม่ได้ (ต้องมี Private Key)
รองรับมาตรา 28	❌	✅
ออกเลขเอกสารหลังลงนาม	✅ ได้ (เพราะไม่ได้ sign จริง)	✅ ได้ (ด้วย Incremental Save + Stamp)
ใช้เป็นหลักฐานในศาล	⚠️ อ่อน (ปลอมแปลงได้)	✅ แข็ง (พิสูจน์ทางคณิตศาสตร์)

"ระบบ ERP ที่ใช้ Digital Signature จริง ไม่ได้ 'ทำไม่ได้' — แค่ทำ 'ต่างจากที่คุ้นเคย' เพราะมันปลอดภัยกว่า วิธีแก้คือ Incremental Save ซึ่งเป็นมาตรฐานสากลที่ใช้ทั่วโลก ได้ทั้งเลขเอกสารและลายเซ็นที่ Valid"

แหล่งอ้างอิง

พ.ร.บ.ว่าด้วยธุรกรรมทางอิเล็กทรอนิกส์ พ.ศ. 2544 (แก้ไขเพิ่มเติม) — มาตรา 26, 28
ETDA — "แนวปฏิบัติการลงลายมือชื่ออิเล็กทรอนิกส์" (Electronic Signature Guideline)
ETSI EN 319 142 — PAdES (PDF Advanced Electronic Signatures)
ISO 32000-2:2020 — PDF Specification (Incremental Save)
Adobe — "Digital Signatures in PDF" Technical Reference