นายธีรวัฒน์ โรจนไพฑูรย์

ทุกวันนี้เราใช้ Social Media ใช้ Mobile Banking และแพลตฟอร์มต่างๆ ในชีวิตประจำวัน จนอาจจะลืมไปแล้วว่าก่อนที่จะใช้งานได้เช่นทุกวันนี้ เราต้องผ่านกระบวนการอะไรบ้าง นั่นก็คือ ต้อง “สมัคร” หรือลงทะเบียนผู้ใช้งาน จากนั้นก็จะสามารถ “เข้าใช้งาน” ได้ ซึ่งการสมัครและการเข้าใช้บริการก็คือ การสร้าง Digital ID  

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

สมัคร+ใช้บริการ = สร้าง Digital ID

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

“การใช้บริการ” หลังจากสมัครแล้ว เมื่อจะเข้าใช้บริการ ก็ต้องพิสูจน์ตัวตน และยืนยันตัวตน ซึ่งจะมี 2 อย่างคู่กัน คือ สิ่งที่ใช้รับรองตัวตน (Credential) เพื่อระบุว่าเป็นใคร และสิ่งที่ใช้ยืนยันตัวตน (Authenticator) เพื่อแสดงว่าเป็นคนๆ นั้นจริง ยกตัวอย่างคู่หูแสดงตัวตน ดังเช่น Username คู่กับ Password, Email address คู่กับ OTP หรือ เลขบัตรประชาชน 13 หลัก คู่กับ OTP แล้วแต่ว่าหน่วยงานใดจะเลือกใช้อะไร 

ถ้าจะบอกว่าหน้าตาของ Digital ID เป็นอย่างไร ก็บอกได้ว่า ทั้งการสมัคร และการเข้าใช้งาน คือ หน้าต่างที่ไปสร้างหน้าตาของ Digital ID ให้กับตัวเราเองก็ว่าได้  

Digital ID ภาครัฐ กำหนดด้วยมาตรฐาน IAL และ AAL

ณ วันนี้ หน่วยงานรัฐจะต้องเตรียมความพร้อมด้าน Digital ID ให้สามารถใช้งานได้อย่างมั่นคงปลอดภัยและเป็นมาตรฐานเพื่อสร้างความน่าเชื่อถือ ให้แล้วเสร็จก่อนวันที่ 11 ตุลาคม 2566 ตามข้อกำหนดใน ประกาศคณะกรรมการพัฒนารัฐบาลดิจิทัล เรื่อง มาตรฐานและหลักเกณฑ์การจัดทำกระบวนการและการดำเนินงานทางดิจิทัล ว่าด้วยเรื่องการใช้ดิจิทัลไอดีสำหรับบริการภาครัฐ สำหรับบุคคลธรรมดาที่มีสัญชาติไทย

จากโจทย์ที่หน่วยงานภาครัฐต้องมีบริการผ่านระบบออนไลน์ที่มั่นคงปลอดภัย มีมาตรฐานที่น่าเชื่อถือ ทำให้สำนักงานพัฒนารัฐบาลดิจิทัล (องค์การมหาชน) สพร. หรือ DGA ได้รับมอบภารกิจนี้มาดำเนินการ ซึ่งได้้ศึกษาหาแนวทางกระทั่งเกิดเป็นมาตรฐาน IAL และ AAL ขึ้นมา โดยหยิบยกแนวทางจาก NIST Framework SP800 มาพัฒนาระดับความเข้มข้นของการพิสูจน์และยืนยันตัวตน 

IAL (Identity Assurance Level) และ AAL (Authenticator Assurance Level) มีด้วยกัน 3 ระดับขอสรุปเบื้องต้นไว้ ดังนี้ (สามารถอ่านรายละเอียดได้ใน https://standard.dga.or.th/wp-content/uploads/2021/09/3.Digital-ID-DGS-1-2_2564.pdf

• IAL เป็นมาตรฐานเกี่ยวกับระดับความน่าเชื่อถือของไอเดนทิตีหรือการพิสูจน์ตัวตน ซึ่งใช้ในการสมัครหรือลงทะเบียนเพื่อขอใช้บริการ มีระดับความเข้มข้น 3 ระดับ คือ
  • IAL1 ใช้กับบริการทั่วไป ไม่มีการโต้ตอบ ไม่ต้องแสดงตัวตน เช่น การเช็กสิทธิสวัสดิการ 
  • IAL2 ใช้กับบริการที่ต้องขอรับบริการ มีการโต้ตอบกับเจ้าหน้าที่รัฐ ต้องแสดงตน เช่น การขอใบอนุญาตต่างๆ การขอใช้สิทธิสวัสดิการ 
  • IAL3 ใช้กับบริการที่เกี่ยวข้องกับกฎหมายและความมั่นคงปลอดภัย เช่น การขออนุญาตการจดทะเบียนต่างๆ 

• AAL เป็นมาตรฐานเกี่ยวกับความน่าเชื่อถือของสิ่งที่ใช้ยืนยันตัวตน ซึ่งใช้เมื่อต้องเข้าใช้บริการต่างๆ
  ของหน่วยงานรัฐผ่านช่องทางดิจิทัล มีระดับความเข้มข้น 3 ระดับ คือ
  • AAL1 ยืนยันตัวตนโดยใช้ปัจจัยของการยืนยันตัวตนหนึ่งปัจจัย 
  • AAL2 ยืนยันตัวตนโดยใช้สองปัจจัยในการยืนยันตัวตน เช่น รหัสลับจดจำ และชีวมิติ 
  • AAL3 ยืนยันตัวตนโดยใช้ปัจจัยของการยืนยันตัวตนประเภทที่เป็นอุปกรณ์เข้ามาเกี่ยวข้อง

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

Digital ID กับการใช้งานในประเทศไทย

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

ภาครัฐใช้ Digital ID กับบริการอะไรบ้าง? คำตอบคือ มีอยู่มากมาย ไม่ว่าเป็นบริการพื้นฐานทั่วไป ได้แก่ การลงทะเบียนขอเข้าร่วมโครงการ การเช็กสิทธิสวัสดิการ ฯลฯ รวมไปถึงบริการที่มีการโต้ตอบระหว่างกันซึ่งจะมีระดับความเข้มข้นของมาตรฐานสูงขึ้นไปอีกขั้น เช่น การขอใบอนุญาตต่างๆ เป็นต้น

สำหรับบริการที่คุ้นเคยกันเป็นอย่างดีซึ่งก็ใช้ Digital ID คือ “การยื่นภาษีออนไลน์” ของกรมสรรพากร อีกทั้ง Super App อย่าง “แอปทางรัฐ” เป็นแอปรวมบริการภาครัฐต่างๆ ไว้หลายรายการ เป็นอีกตัวอย่างหนึ่งที่มีการพิสูจน์และยืนยันตัวตนที่สอดคล้องกับมาตรฐาน Digital ID สำหรับบริการภาครัฐ รวมไปถึงบริการของกรมการปกครอง “dopa” ก็มีการใช้ Digital ID และมีมาตรฐานความพร้อมสูงอยู่ในระดับแนวหน้าของประเทศก็ว่าได้

ภาคเอกชนใช้ Digital ID กับบริการอะไรบ้าง? คำตอบคือ มีอยู่มากมายและหลากหลาย นอกจากบริการทั่วๆ ไป เช่น ลงทะเบียนรับโปรโมชัน การสมัครเข้าใช้แอปและแพลตฟอร์มต่างๆ แต่ส่วนนี้อาจจะไม่รวมถึงการที่จะต้องปฏิบัติตามมาตรฐาน IAL และ AAL ของภาครัฐ แต่ตัวอย่างที่พอจะหยิบยกมากล่าวถึงในมุมความสอดคล้องตามมาตรฐานได้นั้นคือ การใช้ Digital ID ของกลุ่มธนาคาร ที่มี NDID (National Digital ID) ใช้เป็นมาตรฐานกลาง

การใช้ Digital ID ในมุมของประชาชน ก็ต้องบอกว่า ประชาชนอยู่ในบริบทของผู้ใช้งาน เมื่อมีการสมัคร และการเข้าใช้งาน ก็หมายถึงการสร้าง และใช้ Digital ID ของบุคคลคนนั้น  

ถ้าจะว่าไปแล้วประเทศไทยก็ไม่ได้ตกเทรนด์กระแสโลก โดยเฉพาะหน่วยงานภาครัฐของไทย ได้ให้บริการประชาชนผ่านช่องทางดิจิทัลอยู่มากมาย และบางหน่วยงานให้บริการมานานหลายปีมาแล้ว และยังมีอีกหลายๆ หน่วยงานที่เร่งพัฒนาบริการต่างๆ ให้สอดคล้องตามมาตรฐาน ซึ่งเมื่อถึงเวลาที่ประกาศฯ มีผลบังคับใช้ เชื่อได้ว่า เราจะเห็นบริการต่างๆ อีกมากมายที่จะอำนวยความสะดวกให้กับประชาชนคนไทย

สามารถศึกษาข้อมูลเพิ่มเติมได้ที่ : Digital ID คืออะไร? ใช้อย่างไร? (“แอปทางรัฐ” เกี่ยวข้องกับ Digital ID)

สามารถศึกษาข้อมูลเพิ่มเติมได้ที่ : ข้อกำหนด 5 ด้าน เพื่อการแลกเปลี่ยนข้อมูลอย่างปลอดภัย

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

เช่นนั้น สำนักงานพัฒนารัฐบาลดิจิทัล (องค์การมหาชน) หรือ สพร. (DGA) จึงได้จัดทำข้อกำหนดขึ้นมา 5 ด้าน ภายใต้มาตรฐานการเชื่อมโยงและแลกเปลี่ยนข้อมูลภาครัฐ (TGIX-Thailand Government Information Exchange) ในระดับด้านการเชื่อมโยงข้อมูล (Linkage) ครอบคลุมทุกระดับของการแลกเปลี่ยนข้อมูล โดยมีวัตถุประสงค์หลักเพื่อทำหน้าที่ป้องกันการเข้าถึงบริการข้อมูลหรือ API ของผู้ให้บริการโดยไม่ถูกต้อง ซึ่งข้อกำหนดทั้ง 5 ด้าน ประกอบไปด้วย

1. ข้อกำหนดด้านการยืนยันตัวตน การควบคุมสิทธิ และบัญชีการใช้งาน (AAA-Authentication, Authorization และ Accounting)
2. ข้อกำหนดด้านการตรวจสอบระบบและการลงบันทึกล็อก (Logging and Monitoring)
3. ข้อกำหนดด้านการกำหนดชื่อและเนมสเปซ (Namespace)
4. ข้อกำหนดด้านโปรโตคอลระดับแอปพลิเคชัน เอนพอยน์ และการจัดการโทเคนและเซสชัน
5. ข้อกำหนดด้านความน่าเชื่อถือและความมั่นคงปลอดภัย

1. ข้อกำหนดด้านการยืนยันตัวตน การควบคุมสิทธิ และบัญชีการใช้งาน (AAA)

เรื่องนี้เป็นข้อกำหนดสำคัญบนสถาปัตยกรรมการเชื่อมโยงและแลกเปลี่ยนข้อมูลภาครัฐ ระบบจะต้องจัดให้มีการยืนยันตัวตน (Authentication) การควบคุมสิทธิในการเข้าถึง (API Access Control) และการบริหารจัดการบัญชีการใช้งาน (API Accounting) เพื่อให้เกิดความปลอดภัยสูงสุดต่อผู้ให้บริการและผู้ใช้บริการเกิดความมั่นใจในการใช้งานระบบด้วย

การยืนยันตัวตน คือ การที่ผู้ขอใช้บริการยืนยันตัวตนเพื่อขอใช้บริการจากผู้ให้บริการ ทำได้ 3 วิธี คือ

• การยืนยันตัวตนด้วย API Key เป็นการยืนยันตัวตนแบบง่ายที่สุด เหมาะสำหรับหน่วยงานที่ต้องการเป็นผู้ให้ข้อมูลแต่มีงบประมาณจำกัด ใช้เข้าถึงบริการ API หรือข้อมูลทั่วไป ไม่ใช่ข้อมูลที่มีความอ่อนไหวหรือมีชั้นความลับ การยืนยันตัวตนแบบนี้ทำงานด้วยการให้ผู้ใช้บริการล็อกอินเข้าระบบด้วยชื่อผู้ใช้ในระดับองค์กร (Username) และรหัสผ่าน (Password) เท่านั้น แต่ไม่ได้ต้องการการยืนยันตัวระดับตัวบุคคล
• การยืนยันตัวตนด้วยมาตรฐาน OAuth 2.0 เมื่อใช้ร่วมกันกับ OpenID Connect จะสามารใช้ยืนยันตัวตนของผู้ใช้งานในระบบได้ ดังนั้นจึงเหมาะสมในการเข้าถึง API ที่เป็นบริการเข้าถึงข้อมูลส่วนบุคคลหรือข้อมูลสำคัญของผู้ให้บริการ รวมทั้งบริการเชิงธุรกรรมประเภทที่เป็นการสร้าง ลบ หรือแก้ไขข้อมูล

โดยหลักการทำงานของ OAuth 2.0 คือ ผู้ใช้งาน (End User) ส่งคำร้องขอใช้บริการจากเว็บเบราว์เซอร์ที่กำลังเรียกใช้งานเว็บแอปพลิเคชันไปที่เครื่องเซิร์ฟเวอร์ที่ทำหน้าที่ตรวจสอบสิทธิการใช้งาน บน TGIX เพื่อให้ได้ Access Token กลับมา จากนั้นระบบจะจัดส่งคำร้องขอของผู้ใช้งานที่แนบ Access Token มาด้วยไปยังผู้ให้บริการ ผู้ให้บริการจะทำการตรวจสอบ Access Token ว่าถูกต้องจริงและยังไม่หมดอายุ แล้วจึงส่งกลับบริการ API ตามที่ผู้ใช้งานร้องขอ

• การยืนยันตัวตนด้วยมาตรฐาน Open ID Connect เป็นมาตรฐานที่ทำงานร่วมกับมาตรฐาน OAuth 2.0

การควบคุมสิทธิในการเข้าถึง ข้อกำหนดในส่วนนี้มีจุดประสงค์เพื่อให้ผู้ให้บริการมั่นใจว่า ระบบหรือบุคคลที่จะเข้าถึง API ได้นั้นเป็นผู้ที่ได้รับอนุญาตเท่านั้น โดยหลังจากผู้ให้บริการตรวจสอบว่าผู้ใช้บริการยืนยันตัวตนผ่านแล้ว จึงตรวจสอบต่อไปว่าผู้ใช้บริการมีรายชื่ออยู่ใน API User Account Service และได้ลงทะเบียนใช้บริการ API ที่ร้องขอไว้ ผ่านระบบพิสูจน์และยืนยันตัวตน (Identity Provider) บน TGIX เป็นที่เรียบร้อย เมื่อยืนยันว่าผู้ใช้บริการมีสิทธิในการเข้าถึง API นั้นๆ แล้วจึงทำการอนุญาตและส่งบริการ API กลับไปยังผู้ขอใช้บริการ

การบริหารจัดการบัญชีการใช้งาน เป็นข้อกำหนดแนวทางปฏิบัติให้มีความปลอดภัยทั้งระหว่างการจัดเก็บและการรับส่งข้อมูลสำหรับทั้งผู้ให้บริการ ผู้ใช้บริการ และหน่วยงานผู้บริการ TGIX Platform โดยแบ่งออกเป็น 3 กลุ่ม ตามประเภทของการยืนยันตัวตน คือ บัญชีใช้งานประเภท API Key ใช้สำหรับการยืนยันตัวตนด้วย API Key บัญชีใช้งาน Identity Provider ที่รองรับมาตรฐาน OAuth 2.0 และบัญชีใช้งาน Identity Provider ที่รองรับมาตรฐาน Open ID Connect

ข้อกำหนดในส่วนนี้ตัวอย่างเช่น บัญชีใช้งานประเภท API Key กำหนดให้ผู้ให้บริการไม่ควรกำหนด API Key ไว้ใน Source Code และให้เก็บในที่ปลอดภัย อาทิ ฐานข้อมูล หรือบัญชีใช้งาน Identity Provider ที่รองรับมาตรฐาน OAuth 2.0 กำหนดให้ผู้ให้บริการควรให้บริการ REST API ผ่าน HTTPS (SSL) เท่านั้น และการออก Access Token ควรมีระยะเวลาการใช้งานได้จำกัด เป็นต้น

2. ข้อกำหนดด้านการตรวจสอบระบบและการลงบันทึกล็อก (Logging and Monitoring)

ข้อกำหนดด้านนี้แบ่งออกเป็น 2 ส่วนคือการลงบันทึกล็อก (Logging) และการตรวจสอบระบบ (Monitoring)

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

• บันทึกข้อมูลเชิงเทคนิค ทำหน้าที่บันทึกข้อมูลในส่วนของ Header ของแพคเกจข้อมูลที่เชื่อมโยงไปยัง TGIX Service Operation Center (SOC) กำหนดให้บันทึกอย่างน้อยชั่วโมงละหนึ่งครั้ง โดยจะต้องบันทึกทุกกิจกรรมการพยายามยืนยันตัวตนที่ล้มเหลว การปฏิเสธการเข้าถึง การตรวจสอบข้อมูลนำเข้าที่ไม่ถูกต้อง และการบันทึกต้องมีข้อมูลเพียงพอต่อการระบุผู้กระทำที่น่าสงสัย
• บันทึกข้อมูลเชิงธุรกรรม ทำหน้าที่บันทึกข้อมูลในส่วนเนื้อหาของข้อมูล ซึ่งจะต้องถูกจัดเก็บนานอย่างน้อย 90 วัน

การบันทึกล็อกมีหลักเกณฑ์ข้อกำหนดหลักๆ คือ ข้อมูลต้องเป็นความลับ ให้สิทธิเข้าถึงข้อมูลได้เฉพาะบางบุคคลเท่านั้น ข้อมูลที่บันทึกต้องถูกต้อง สมบูรณ์ ไม่มีการแก้ไขเพิ่มเติม และข้อมูลต้องพร้อมใช้งานตลอดเวลา สามารถนำมาวิเคราะห์สาเหตุของปัญหาได้ทันที

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

3. ข้อกำหนดด้านการกำหนดชื่อและเนมสเปซ (Namespace)

ข้อกำหนดด้านนี้เป็นการกำหนดรูปแบบโครงสร้าง URL ที่เป็นตัวเรียกใช้บริการข้อมูล หรือเรียกใช้ API เพื่อให้เป็นไปในทิศทางเดียวกันและมีความปลอดภัย โดยกำหนดรูปแบบให้เป็นมาตรฐานตามนี้

<scheme> คือ โปรโตคอลสำหรับเรียกใช้งาน API ซึ่งก็คือ การเรียกใช้ผ่านอินเทอร์เน็ตที่มีความปลอดภัย ดังนั้นในส่วนนี้จึงเป็น https นั่นเอง

<authority> คือ โดเมนของหน่วยงานที่ให้บริการ API เช่น owi.api.tgix.com เป็นต้น

<path> พาธจะแบ่งออกเป็น 3 ส่วน คือ

• ส่วนที่เป็นชื่อของ API หรือชื่อของการให้บริการ เช่น /namespace/project เป็นต้น
• ส่วนที่เป็นการเวอร์ชันของการให้บริการ เช่น /v2 สำหรับเวอร์ชั่น 2 เป็นต้น
• ส่วนที่เป็นการกำหนดรูปแบบสำหรับการเข้าถึงชุดข้อมูล ซึ่งแบ่งออกเป็น 2 แบบ คือ การเข้าถึงชุดข้อมูลแบบหลายรายการพร้อมกัน และการเข้าถึงชุดข้อมูลแบบรายการเดียว โดยมีข้อกำหนดในการตั้งชื่อคือ ต้องเป็นภาษาอังกฤษ ตัวพิมพ์เล็ก คั่นคำด้วยเครื่องหมาย hyphen (-) ใช้เป็นคำนามเอกพจน์สำหรับการเข้าถึงชุดข้อมูลแบบรายการเดียว และคำนามพหูพจน์สำหรับการเข้าถึงชุดข้อมูลแบบหลายรายการพร้อมกัน เช่น /orders หรือ /user-type เป็นต้น

<query> คือ ข้อกำหนดเงื่อนไขการเรียกใช้ข้อมูล เช่น ?itemname=abc เป็นต้น มีข้อกำหนดในการตั้งชื่อคือ เป็นภาษาอังกฤษ ตัวพิมพ์เล็ก คั่นคำด้วยเครื่องหมาย underscore (_) ไม่ใช้อักษรที่เป็นข้อมูลอ่อนไหว เช่น แสดงรหัสผ่าน /users?username=dga_user01&password=123456 และใช้ในกรณีการจัดเรียงข้อมูลหรือกรองข้อมูลเท่านั้น เช่น การจัดเรียงข้อมูล /users?sort_by=email.desc เป็นต้น

4. ข้อกำหนดด้านโปรโตคอลระดับแอปพลิเคชัน เอนพอยน์ และการจัดการโทเคนและเซสชัน

ข้อกำหนดด้านนี้มีวัตถุประสงค์เพื่อจำกัดการใช้งานเพื่อให้มีผลด้านความมั่นคงปลอดภัย ให้ผู้ใช้บริการมีความมั่นใจในการใช้งานเครือข่ายผ่านการเชื่อมโยงด้วยมาตรฐานนี้ โดยจะมีข้อกำหนดหลักใน 4 เรื่อง คือ เอนพอยท์ (Endpoint), โทเค็น (Token), เซสชัน (Session) และรูปแบบข้อมูล (Data format)

รู้จักเอนพอยท์ โทเค็น เซสชัน และรูปแบบข้อมูล

เอนพอยท์ คือ url หรือที่อยู่เว็บไซต์ปลายทางที่เรียกใช้บริการข้อมูลหรือเรียกใช้ API โดยส่งผ่านข้อมูลทางอินเทอร์เน็ต ซึ่งตามข้อกำหนดนี้ เอนพอยท์ต้องมีโปรโตคอลเป็น https ใช้ร่วมกับโปรโตคอลสำหรับการรับรองความปลอดภัยแบบเข้ารหัสในรูปแบบ SSL-Security Socket Layer หรือ TLS-Transport Layer Security และโดยขั้นตอนทั้งหมดทำงานอยู่บน Transmission Control Protocol (TCP)

โทเค็น ในที่นี้คือ access token ใช้สำหรับตรวจสอบหรือพิสูจน์ตัวตนของผู้ใช้บริการในการขอเข้าใช้บริการข้อมูลหรือ API จากผู้ให้บริการ โดย access token นี้อาจจะเป็น อักขระที่เข้ารหัสมา หรืออาจจะอยู่ในรูปแบบข้อมูลที่เป็นโครงสร้างตามมาตรฐาน JSON Web Tokens (JWT) เพราะมีข้อกำหนดที่กะทัดรัดและครอบคลุม มีขนาดค่อนข้างเล็ก และตอบโจทย์ในการนำข้อมูลต้นทางมาเข้ารหัสและสามารถถอดรหัสออกมาเป็นข้อมูลต้นฉบับได้โดยแบ่งออกเป็นส่วนๆ ได้ นอกจากนี้ JWT ยังสามารถใช้ร่วมกับการเข้ารหัสแบบกุญแจคู่ (pair key) และ JWT มีข้อมูลที่จำเป็นเพียงพอที่ผู้ให้บริการสามารถตรวจสอบความถูกต้องของโทเค็นได้โดยไม่ต้องเรียกเซิร์ฟเวอร์ที่ทำหน้าที่ตรวจสอบความถูกต้องของโทเค็น (Authorization Server) ซ้ำ ทำให้ระบบทำงานได้เร็วขึ้น ส่วน Access Token นี้จะใช้สำหรับหน่วยงานที่ใช้การยืนยันตัวตนด้วยมาตรฐาน OAuth 2.0 หรือ Open ID Connect เท่านั้น ไม่รวมถึงการยืนยันตัวตนด้วย API Key สำหรับผู้ที่สนใจศึกษาการทำงานของมาตรฐาน JWT สามารถดูรายละเอียดเพิ่มเติมได้ที่ https://jwt.io/

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

รูปแบบข้อมูล คือ โครงสร้างการรับส่งข้อมูลระหว่างผู้ใช้บริการ API และผู้ให้บริการ API ซึ่งกำหนดให้ใช้เป็นโครงสร้าง TGIX JSON Data Format ตามมาตรฐาน TGIX

DGA ได้จัดทำข้อกำหนดด้านโปรโตคอลของทั้ง 4 เรื่องข้างต้นโดยลงลึกถึงรายละเอียดเชิงเทคนิคเอาไว้เป็นที่เรียบร้อยแล้ว เตรียมพร้อมให้บริการแก่หน่วยงานที่ต้องการจัดทำมาตรฐาน TGIX

5. ข้อกำหนดด้านความน่าเชื่อถือและความมั่นคงปลอดภัย

ความน่าเชื่อถือและความมั่นคงปลอดภัยเป็นเรื่องจำเป็นเมื่อมีการแลกเปลี่ยนข้อมูลใดๆ ระหว่างกัน โดยวัตถุประสงค์หลักของข้อกำหนดในด้านนี้ คือ

1. เพื่อการรักษาความลับของข้อมูล (Confidentiality) นั่นคือการเก็บรักษาข้อมูลให้เป็นความลับและจำกัดสิทธิในการเข้าถึงอมูลของผู้ใช้งานระบบด้วยการยืนยันตัวตน (Authentication) และการตรวจสอบสิทธิ (Authorization) ในการเข้าถึงทรัพยากร,
2. ความถูกต้องของข้อมูล (Integrity) คือการตรวจสอบและให้มั่นใจว่าข้อมูลที่มีการแลกเปลี่ยนกันภายในมาตรฐาน TGIX มีความถูกต้องและสมบูรณ์ครบถ้วน
3. ความพร้อมให้บริการของระบบได้อย่างต่อเนื่อง (Availability) คือความพร้อมใช้งานหรือให้บริการของระบบได้อย่างต่อเนื่อง และเพื่อบรรเทาผลกระทบจากการไม่สามารถให้บริการได้จนนำไปสู่ผลกระทบกับผู้ใช้บริการ

DGA ได้ยึดเอาวัตถุประสงค์ทั้ง 3 ข้อข้างต้นเป็นแนวทางปฏิบัติในการออกข้อกำหนดให้ครอบคลุมทุกด้าน จึงแบ่งข้อกำหนดออกเป็น 4 ส่วนคือ ข้อกำหนดด้านความปลอดภัยของผู้ให้บริการ ข้อกำหนดด้านความปลอดภัยของผู้ใช้บริการ ข้อกำหนดด้านความความปลอดภัยขององค์ประกอบอื่นๆ ตามมาตรฐาน TGIX และข้อกำหนดด้านความปลอดภัยที่เกี่ยวข้องกับกฎหมาย โดยมีการกำหนดรายละเอียดในด้านต่างๆ ที่เกี่ยวข้องกับแต่ละส่วนไว้เป็นที่เรียบร้อย

5 ด้าน สอดประสานเพื่อการทำงานที่ลื่นไหล

ในการใช้งานจริง ระบบเครือข่ายของผู้ให้บริการและผู้ใช้บริการจะทำงานบนข้อกำหนดทั้ง 5 ด้านไปพร้อมกัน ตัวอย่างเช่น นาย ก. ต้องการใช้บริการภาครัฐผ่านเว็บแอปพลิเคชันของหน่วยงาน A ผ่านอินเทอร์เน็ตที่มีความปลอดภัย (ข้อกำหนดด้านโปรโตคอลระดับแอปพลิเคชัน เอนพอยน์ และการจัดการโทเคนและเซสชัน) ซึ่งต้องใช้ข้อมูลส่วนบุคคล อาทิ เลขที่บัตรประชาชนเป็นตัวตรวจสอบ นาย ก. จึงเข้าไปยังเว็บไซต์ที่ให้บริการด้วยเว็บเบราว์เซอร์ (ข้อกำหนดด้านการกำหนดชื่อและเนมสเปซ) แล้วเข้าใช้งานเว็บแอปพลิเคชันของหน่วยงาน  A

จากนั้นแอปพลิเคชันหน่วยงาน  A จะส่งคำร้องขอใช้บริการไปยังหน่วยงาน B ซึ่งเป็นผู้ให้บริการ หน่วยงาน B ทำการตรวจสอบการยืนยันตัวตนและสิทธิการเข้าถึงและการใช้บริการ API ของหน่วยงาน A (ข้อกำหนดด้านการยืนยันตัวตน การควบคุมสิทธิ และบัญชีการใช้งาน) ผ่านระบบระบบพิสูจน์และยืนยันตัวตน (Identity Provider) ของ TGIX และตรวจสอบว่ามีลายเซ็นดิจิทัลแนบมาพร้อมเข้ารหัสข้อมูล (ข้อกำหนดด้านความน่าเชื่อถือและความมั่นคงปลอดภัย) เมื่อข้อมูลถูกต้อง หน่วยงาน B จึงอนุญาตและส่งข้อมูลที่แอปพลิเคชันหน่วยงาน A ร้องขอมากลับไปยังหน่วยงาน A ซึ่งจะได้รับสิทธิในการเข้าถึงข้อมูล และสิทธิที่ได้นี้จะใช้งานได้ภายในระยะเวลาที่กำหนด (Session) พร้อมลงบันทึกการใช้งานของแอปพลิเคชันจากหน่วยงาน A ไว้ในระบบ (ข้อกำหนดด้านการตรวจสอบระบบและการลงบันทึกล็อก)

สำหรับหน่วยงานภาครัฐใดที่ต้องการเชื่อมโยงแลกเปลี่ยนหรือให้บริการข้อมูลในรูปแบบมาตรฐาน TGIX ต้องปรับแต่งคุณสมบัติในส่วนของ API ในส่วนการให้บริการหรือการเรียกใช้งานของหน่วยงานให้เป็นรูปแบบตามข้อกำหนดทั้ง 5 ด้านดังกล่าว

เมื่อโลกเข้าสู่เศรษฐกิจและสังคมดิจิทัล ภาครัฐจำเป็นต้องปรับตัวให้ทัน เพื่อรักษาความสามารถทางการแข่งขันของประเทศ หน่วยงานภาครัฐต่างๆ จึงควรให้ความสำคัญกับการจัดกลยุทธ์ระบบสารสนเทศแบบองค์รวมที่สนับสนุนการทำงานของหน่วยงานได้อย่างเหมาะสมและรองรับการให้บริการต่อประชาชนและหน่วยงานภายนอกได้ในอนาคต

สำนักงานพัฒนารัฐบาลดิจิทัล (องค์การมหาชน) สพร. หรือ DGA เล็งเห็นความสำคัญดังกล่าวจึงได้กำหนดวิสัยทัศน์ “ยกระดับภาครัฐไทยสู่การเป็นรัฐบาลดิจิทัลที่มีการบูรณาการระหว่างหน่วยงานมีการทำงานแบบอัจฉริยะ ให้บริการโดยมีประชาชนเป็นศูนย์กลาง และขับเคลื่อนให้เกิดการเปลี่ยนแปลงได้อย่างแท้จริง” และมุ่งมั่นที่จะสนับสนุนให้เกิดการใช้งาน e-Signature เป็นวงกว้างในหน่วยงานของภาครัฐ

บทบาทของ e-Signature ในหน่วยงานภาครัฐ

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

การนำ e-Signature มาใช้จะช่วยให้ระบบงานนั้นไม่จำเป็นต้องใช้เอกสารกระดาษอีกต่อไป เพราะเอกสารอิเล็กทรอนิกส์ที่มีการลงลายมือชื่ออิเล็กทรอนิกส์จะได้รับการรับรองทางกฎหมายเสมือนเป็นเอกสารกระดาษทั่วไป

เอกสารประเภทไหนควรใช้ e-signature แบบใด

เอกสารที่เกี่ยวข้องกับงานในหน่วยงานภาครัฐถูกจำแนกออกเป็น  6 ชนิด ตามข้อ 10 แห่งระเบียบสำนักนายกรัฐมนตรี ว่าด้วยงานสารบรรณ พ.ศ. 2526 โดยแต่ละชนิดมีระดับความเสี่ยง ความสำคัญของข้อความในเอกสารไม่เท่ากัน จึงมีข้อแนะนำการใช้ประเภทของ e-Signature ให้เหมาะกับชนิดเอกสาร ดังภาพประกอบด้านล่างนี้

ผู้ให้บริการออกใบรับรองอิเล็กทรอนิกส์แห่งชาติ

สำหรับลายมือชื่ออิเล็กทรอนิกส์แบบที่มีความน่าเชื่อถือสูงสุด คือลายมือชื่ออิเล็กทรอนิกส์แบบเข้ารหัส เช่น Digital Signature ที่ใช้ร่วมกับใบรับรองที่ออกโดยผู้ให้บริการออกใบรับรอง (Certification Authority – CA) ซึ่งมีหน้าที่ออกใบรับรองอิเล็กทรอนิกส์ เพื่อรับรองตัวตนของผู้ใช้บริการ สำหรับนำไปใช้ในการทำธุรกรรมออนไลน์แบบปลอดภัย โดยผู้ให้บริการออกใบรับรองจะทำการรับรองข้อมูลต่างๆ รวมถึงกุญแจสาธารณะที่ปรากฏในใบรับรองอิเล็กทรอนิกส์ว่าเป็นของบุคคลนั้นจริง โดยอาศัยเทคโนโลยีที่เรียกว่า “เทคโนโลยีโครงสร้างพื้นฐานกุญแจสาธารณะ” (Public Key Infrastructure – PKI)

ทั้งนี้ การใช้ใบรับรองอิเล็กทรอนิกส์ที่ออกโดย CA ต่างรายกัน บางครั้งอาจประสบปัญหาการทำงานร่วมกันระหว่างระบบ จึงได้มีการพัฒนาระบบการมอบความไว้วางใจ (Trust Model) ระหว่าง CA ขึ้น ด้วยการรับรองใบรับรองอิเล็กทรอนิกส์ที่ออกโดย CA แต่ละรายเป็นลำดับชั้น (Hierarchy) โดยจะมี CA รายหนึ่งทำหน้าที่รับรองใบรับรองอิเล็กทรอนิกส์ของ CA รายอื่นๆ และจะอยู่ในลำดับชั้นสูงสุดที่นิยมเรียกกันว่า Root CA สำหรับในประเทศไทยคือหน่วยงานที่ชื่อว่า “ผู้ให้บริการออกใบรับรองอิเล็กทรอนิกส์แห่งชาติ” หรือ Thailand National Root Certification Authority ซึ่งจะเป็นผู้ทำหน้าที่รับรองใบรับรองอิเล็กทรอนิกส์ของ CA รายอื่นๆ และเป็นศูนย์กลางในการสร้างความเชื่อมั่นของการใช้งานระบบ PKI เพื่อให้เกิดการทำงานร่วมกันระหว่าง CA ในประเทศ รวมไปถึงเป็นศูนย์กลางในการติดต่อกับ CA ต่างประเทศ ทำให้ผู้ใช้บริการ CA ต่างรายกันสามารถติดต่อสื่อสารกันได้โดยไม่มีข้อขัดข้อง รวมทั้งยังเพิ่มความเชื่อมั่นในการทำธุรกรรมออนไลน์ ซึ่งจะส่งผลต่อการเพิ่มมูลค่าทางเศรษฐกิจโดยรวมของประเทศต่อไป

ในปัจจุบัน ประเทศไทยมี CA อยู่ด้วยกัน 2 ราย คือ บริษัท อินเทอร์เน็ตประเทศไทย จำกัด (มหาชน) หรือ ไอเน็ต และ บริษัท ไทยดิจิทัล ไอดี จำกัด

5 ประโยชน์ดีๆ ของ e-Signature

ประโยชน์ดีๆ 5 ข้อหลักที่หน่วยงานภาครัฐจะได้รับจากการใช้งาน e-Signature ในองค์กร ดังภาพประกอบด้านล่าง

ตัวอย่างหน่วยงานภาครัฐที่เริ่มใช้ e-Signature

มีหลายหน่วยงานภาครัฐที่ได้เริ่มนำ e-Signature ไปใช้ในองค์กรแล้ว อาทิ

• กรมสรรพากร เป็นหน่วยงานลำดับแรกๆ ที่ได้นำ e-Signature มาใช้กับงานบริการประชาชน เช่น ใช้การลงลายมือชื่ออิเล็กทรอนิกส์ในขั้นตอนการยื่นคำขอแบบ การเปลี่ยนแปลงข้อมูล การใช้ใบกำกับภาษีอิเล็กทรอนิกส์ (e-Tax & invoice) และใบรับอิเล็กทรอนิกส์ (e-Receipt) เป็นต้น
• กรมพัฒนาธุรกิจการค้า กระทรวงพาณิชย์ โดยนำมาให้บริการออกหนังสือรับรอง และรับรองสำเนาเอกสารนิติบุคคลโดยใช้ลายมือชื่อทางอิเล็กทรอนิกส์ในรูปแบบของ Digital Signature ซึ่งใช้การเข้ารหัสจึงมีความปลอดภัยสูง ทำให้สามารถรองรับผู้ใช้บริการที่เพิ่มขึ้นอย่างต่อเนื่องได้อย่างมีประสิทธิภาพ อำนวยความสะดวกแก่ผู้ประกอบการให้มีความคล่องตัวในการทำธุรกิจ ลดระยะเวลาและค่าใช้จ่ายในการเดินทาง และเกิดประโยชน์ทางเศรษฐกิจต่อทุกภาคส่วน
• ด้านกรมบัญชีกลาง เป็นอีกหน่วยงานหนึ่งที่สนับสนุนให้มีการใช้งาน e-Signature โดยออกแนวทาง
  การใช้ลายมือชื่ออิเล็กทรอนิกส์ เป็นทางเลือกให้หน่วยงานของรัฐนำไปใช้ในกระบวนการจัดซื้อจัดจ้าง เพิ่มความคล่องตัว ลดขั้นตอน สะดวกและรวดเร็ว
• มหาวิทยาลัยขอนแก่น ที่จัดทำระบบภายในของตัวเอง เพื่อรองรับการใช้งาน Digital Signature ภายในหน่วยงานอย่างเต็มรูปแบบ
• สำนักงานคณะกรรมการกำกับหลักทรัพย์และตลาดหลักทรัพย์ (กลต.) ใช้กับระบบนำส่งข้อมูลอิเล็กทรอนิกส์แบบออนไลน์
• ธนาคารแห่งประเทศไทย นำไปใช้กับระบบ Electronic Financial Services (EFS)
• ธนาคารออมสิน นำไปใช้กับระบบรักษาความมั่นคงปลอดภัยด้วยใบรับรองอิเล็กทรอนิกส์สำหรับเซิร์ฟเวอร์และเราท์เตอร์
• สำนักงานคณะกรรมการป้องกันและปราบปรามการทุจริตแห่งชาติ (ปปช.) นำไปใช้กับ ระบบสารสนเทศเพื่อการรวบรวมและวิเคราะห์ทรัพย์สิน (ACAS)
• กรมพัฒนาฝีมือแรงงาน ใช้กับระบบบริการค้นหาวุฒิบัตรและหนังสือรับรองอิเล็กทรอนิกส์
• กรมการค้าต่างประเทศ นำไปใช้กับ ระบบลงทะเบียนผู้ประกอบการ และระบบการให้บริการออกใบอนุญาตและออกหนังสือรับรองการส่งออก-นำเข้าสินค้าทั่วไป เป็นต้น

เริ่มต้นทีละนิด

อย่างไรก็ตาม การนำ e-Signature เข้ามาใช้งานในหน่วยงานไม่จำเป็นต้องเริ่มต้นด้วยการลงทุนระบบงานแบบครบวงจรในคราวเดียว เพราะต้องใช้งบลงทุนสูง แต่อาจจะเริ่มจากทีละระบบงาน เช่น เริ่มด้วยระบบ e-Document แล้วค่อยๆ ดำเนินการแปลงเอกสารที่อยู่ในรูปแบบกระดาษเป็นรูปแบบดิจิทัล ในระหว่างนี้ก็เป็นการเตรียมความพร้อมเจ้าหน้าที่ในหน่วยงานให้คุ้นชินกับการใช้งานเอกสารอิเล็กทรอนิกส์เบื้องต้นไปก่อน

จากนั้นจึงค่อยๆ เพิ่มระบบงานที่เกี่ยวข้องเข้าไป หรือเริ่มต้นด้วยระบบงานเอกสารภายในที่มีความเสี่ยงต่ำ โดยสามารถใช้ e-Signature แบบทั่วไป เช่น การเซ็นด้วยปากกาสไตลัสไปก่อน แล้วค่อยๆ พัฒนาไปเป็นระบบ e-Signature แบบเชื่อถือได้ หรือใช้ร่วมกับใบรับรองอิเล็กทรอนิกส์

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

e-Signature เป็นเทคโนโลยีที่มีประโยชน์อย่างมากในการพัฒนาระบบงานออนไลน์ของหน่วยงานภาครัฐ และมีทางเลือกการใช้งานที่หลากหลาย หน่วยงานภาครัฐใดที่ต้องการพัฒนาระบบ e-Signature สำหรับใช้ในองค์กรสามารถศึกษาข้อมูลเพิ่มเติมหรือขอคำปรึกษาแนะนำได้จาก สำนักงานพัฒนารัฐบาลดิจิทัล (องค์การมหาชน) สพร. หรือ DGA

ใครเคยเปิดบัญชีธนาคาร ซื้อบ้าน ซื้อรถ ทำสัญญาเงินกู้กับธนาคารเพื่อผ่อนทรัพย์สินชิ้นใหญ่ๆ
จดทะเบียนบริษัท ทำบัตรประชาชน จดทะเบียนสมรส หรือทำธุรกรรมใดๆ กับหน่วยงานรัฐ คงหนีไม่พ้นที่จะต้องลงลายมือชื่อบนเอกสารมากมาย

ในการดำรงชีวิตของคนทุกคนเกี่ยวข้องกับการเซ็นชื่อในเอกสารต่างๆ มานับครั้งไม่ถ้วน สาระสำคัญของ “ลายเซ็น” คือ “การระบุตัวตนเพื่อยืนยันความรับผิดชอบ” นั่นเอง และเมื่อโครงสร้างพื้นฐานของระบบสารสนเทศพัฒนามาจนถึงระดับที่สามารถระบุตัวตนของผู้ใช้งานได้ จึงมีการพัฒนาลายมือชื่ออิเล็กทรอนิกส์ออกมาใช้งานบนระบบสารสนเทศ

สำนักงานพัฒนารัฐบาลดิจิทัล (องค์การมหาชน) สพร. หรือ DGA มีภารกิจหลักในการนำหน่วยงานภาครัฐไปสู่การเป็นรัฐบาลดิจิทัล จึงสนับสนุนให้เกิดการใช้งาน e-Signature (ลายมือชื่ออิเล็กทรอนิกส์) ในหน่วยงานหรือองค์กรต่างๆ

e-Signature เป็นรูปแบบใดได้บ้าง

หลายคนอาจจะยังติดกับภาพว่า e-Signature คือ ลายเซ็นที่ใช้ปากกาสไตลัส (Stylus) หรือ นิ้วมือของเราเขียนลงบนหน้าจอมือถือหรือแท็บเล็ต แต่จริงๆ แล้ว e-Signature มีรูปแบบที่หลากหลายกว่านั้นมาก เช่น

• การพิมพ์ชื่อไว้ในตอนท้ายของอีเมล
• รูปลายเซ็นของเราที่ตัดแปะไว้บนเอกสารต่างๆ ที่อยู่ในคอมพิวเตอร์
• การกดยอมรับ หรือทำเครื่องหมายในช่องแสดงการยอมรับ “ข้อตกลงและเงื่อนไข” (Terms and Conditions) ของเว็บไซต์หรือแอปพลิเคชันต่างๆ ถือว่าเป็นการแสดงเจตนาว่ายอมรับเงื่อนไขหรือข้อกำหนดตามที่ข้อความแจ้งไว้ทั้งหมด
• การกระทำใดๆ ภายใต้การล็อกอินผ่าน Username และ Password ของตน ไม่ว่าจะเป็นการโพสต์ข้อความ การแชท การสั่งซื้อของออนไลน์ ล้วนถือเป็นการกระทำภายใต้การเซ็นชื่อยินยอมมีพันธะสัญญาทางกฎหมายกับการกระทำและเอกสารเหล่านั้น
• ลายมือชื่อดิจิทัล (Digital Signature)

อย่าสับสน e-Signature และ Digital Signature

นอกเหนือจาก e-Signature แล้ว ไฉนเลยจึงมี Digital Signature โผล่มาอีก ทั้งสองอย่างต่างกันอย่างไร เรามีคำตอบให้

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

สรุปคือ Digital Signature เป็น e-Signature ในแบบที่ปลอดภัยและเชื่อถือได้มากขึ้นนั่นเอง

หัวใจสำคัญของ e-Signature

ปัจจุบัน กฎหมายรองรับ e-Signature ทำหน้าที่เหมือนลายเซ็นบนกระดาษ แต่เมื่อเป็นเรื่องใหม่จึงจำเป็นต้องระบุให้ได้ว่า e-Signature นั้นมีหน้าที่อะไรอย่างชัดเจน ซึ่งสามารถระบุได้สองประการที่เป็นหัวใจสำคัญ คือ

ประการแรก ต้องระบุตัวตนเจ้าของ e-Signature ได้ เพื่อเป็นหลักฐานที่สามารถระบุตัวเจ้าของลายมือชื่ออิเล็กทรอนิกส์นั้นได้

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

e-Signature ที่สมบูรณ์ตามกฎหมาย

กฎหมายไม่ได้ระบุให้ e-Signature มีรูปแบบใดรูปแบบหนึ่ง ทั้งนี้เพื่อเปิดกว้างให้มีความครอบคลุมภาพรวมของลายมือชื่ออิเล็กทรอนิกส์ในทุกรูปแบบดังที่ได้เกริ่นไว้แล้วข้างต้น และเพื่อรองรับหลักความเป็นกลางทางเทคโนโลยี (Technology Neutrality) ที่สามารถเลือกใช้เทคโนโลยีใดก็ได้ในการลงลายมือชื่ออิเล็กทรอนิกส์ ทำให้ผู้ใช้งานมีความยืดหยุ่น สามารถเลือกใช้เทคโนโลยีตามความเหมาะสมกับความเสี่ยงของธุรกรรมนั้นๆ
แต่เพื่อให้เป็น e-Signature ที่สมบูรณ์และได้รับการรับรองด้วยกฎหมายแล้วนั้น e-Signature จะต้องมีองค์ประกอบครบทั้ง 3 ข้อ ดังต่อไปนี้

1. สามารถระบุตัวตนของเจ้าของลายเซ็นได้ ว่าผู้เซ็นคือใคร
2. สามารถระบุเจตนาตามข้อความที่เซ็นได้ ว่าเซ็นเพื่ออะไร
3. มีการรักษาความครบถ้วนของข้อมูล มีหลักฐานแสดงได้ว่าไม่มีการเปลี่ยนแปลงความหมายของข้อความที่ลงลายมือชื่อ หรือใช้วิธีการที่เชื่อถือได้ในการเซ็น เช่น ทำผ่านระบบที่มีความปลอดภัย มีหลักฐาน พยาน หรือบุคคลที่ 3 ที่รับรองการเซ็น เป็นต้น

ภาระในการพิสูจน์ความน่าเชื่อถือ

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

1. e-Signature แบบทั่วไป เหมาะกับธุรกรรมทั่วไปที่มีผลกระทบในระดับต่ำต่อองค์กร ภาระการพิสูจน์จะตกอยู่ที่เจ้าของลายมือชื่อ ซึ่งเป็นผู้ที่กล่าวอ้างว่าลายมือชื่อนั้นน่าเชื่อถือ
2. e-Signature แบบเชื่อถือได้ เหมาะกับธุรกรรมที่ต้องมีการพิจารณาอย่างรอบคอบถึงเงื่อนไขหรือข้อควรระวังเบื้องต้น
3. e-Signature แบบเชื่อถือได้และมีใบรับรองที่ออกโดยผู้ให้บริการออกใบรับรองอิเล็กทรอนิกส์ (Certification Authority: CA) เหมาะกับธุรกรรมที่เกี่ยวข้องกับข้อมูลที่มีความละเอียดอ่อน เช่น ธุรกรรมที่เกี่ยวข้องกับข้อมูลที่เป็นความลับขององค์กร ธุรกรรมที่ก่อให้เกิดผลกระทบในวงกว้าง

สำหรับ e-Signature แบบที่ 2 และ 3 ภาระการพิสูจน์ความน่าเชื่อถือจะตกอยู่ที่ผู้โต้แย้งหรือคัดค้านว่าลายมือชื่อนั้นไม่น่าเชื่อถือ

ภาครัฐ-ประชาชน ร่วมกันใช้ประโยชน์ e-Signature

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

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

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

ภาคเอกชนกับ e-Signature

สำหรับการใช้งาน e-Signature ในองค์กรธุรกิจ ควรใช้เป็น e-Signature แบบเชื่อถือได้ หรือ มีใบรับรองที่ออกโดยผู้ให้บริการใบรับรอง เช่น Digital Signature ซึ่งเป็นลายมือชื่อที่มีการเข้ารหัส ช่วยให้สามารถยืนยันตัวตนเจ้าของลายมือชื่อ ระบุเจตนาตามข้อความที่ได้ลงนามไว้ และสามารถตรวจพบการเปลี่ยนแปลงของข้อความและลายมือชื่อได้ ทำให้เจ้าของลายมือชื่อไม่สามารถปฏิเสธความรับผิดชอบได้ ทั้งนี้เพราะธุรกรรมที่เกิดขึ้นมักมีมูลค่าและความเสี่ยงสูง จึงควรใช้ e-Signature ประเภทที่มีความปลอดภัยสูงตามไปด้วย

ข้อดีของการนำ e-Signature มาใช้กับองค์กรธุรกิจคือช่วย ลดค่าใช้จ่ายด้านการเดินทาง ประหยัดเวลาเพราะทำผ่านออนไลน์ได้ในไม่กี่นาที ลดต้นทุน เช่น กระดาษ หมึกพิมพ์ ซึ่งส่งผลทางอ้อมไปสู่การส่งเสริมด้านสิ่งแวดล้อม และหากพิจารณาในด้านสังคมยังช่วยลดการสัมผัส ซึ่งลดความเสี่ยงในการแพร่กระจายของ COVID-19 ได้อีกด้วย

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

ที่ผ่านมาวิกฤตจากการแพร่ระบาด COVID-19 เป็นปัจจัยสำคัญที่ผลักดันให้หลายหน่วยงานต้องหาวิธีและทางออกในการทำงานภายใต้สภาวะแวดล้อมที่จำกัดในหลายๆ ด้าน ซึ่ง e-Signature เป็นหนึ่งในเทคโนโลยีที่ตอบโจทย์ได้ตรงจุด แม้ว่าหลายหน่วยงานเริ่มใช้เทคโนโลยีนี้จากสถานการณ์บีบบังคับ แต่ในท้ายที่สุดการใช้ e-Signature ก็จะมีการใช้งานอย่างเต็มรูปแบบมากขึ้น

ความแตกต่างของการใช้ e-Signature หรือลายมือชื่ออิเล็กทรอนิกส์ และ Digital Signature หรือลายมือชื่อดิจิทัล

สามารถศึกษาข้อมูลเพิ่มเติมได้ที่ : การใช้ e-Signature ในประเทศไทย – Digital Government Standard (dga.or.th)

ปัญหาน่าปวดหัว ทำเสียเวลามากมายตอนที่นักพัฒนาเขียนโปรแกรมเชื่อมต่อระหว่างหน่วยงานก็มาจากที่แต่ละหน่วยงานใช้คําศัพท์ (Vocabulary) รูปแบบ โครงสร้าง และความหมายของข้อมูลที่แตกต่างกันนั่นแหละ กลายเป็นปัญหาสำคัญของการแลกเปลี่ยนข้อมูลระหว่างหน่วยงานกันเลยทีเดียว

ยกตัวอย่างง่ายๆ เช่น การเรียกเพศ ชาย-หญิง ง่ายๆ นี่เอง หน่วยงานหนึ่งแทนเพศชาย ด้วย ‘M’ เพศหญิง ด้วย ‘F’ อีกหน่วยงานแทนเพศชาย เป็น ‘0’ หญิงเป็น ‘1’ เท่านี้เวลาแลกเปลี่ยนข้อมูลข้ามหน่วยงานก็เกิดปัญหาแล้ว

หรืออย่างเลข 13 หลักของประชาชน ที่หนึ่งใช้ CitizenID อีกที่ใช้ ID13 ที่อื่นก็ใช้คำอื่น

โอ๊ยยยยย พี่ครับ พี่ทำไมไม่ใช้คำเดียวกัน ทำไมไม่มีมาตรฐานกลางของประเทศมาใช้นะ

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

การมีมาตรฐานกลางขึ้นมาจะช่วยให้นักพัฒนาโปรแกรมทำงานง่ายขึ้น ทำให้ต้นทุนการพัฒนาระบบต่ำลง และจะส่งผลต่อการขยายตัวของการแลกเปลี่ยนข้อมูลเร็วมากขึ้น จากนั้นนวัตกรรมการบริการภาครัฐก็จะตามมา

มาตรฐานแก้ปัญหาความต่าง

ดังนั้นการกําหนดมาตรฐานด้านความหมายข้อมูล เป็นสิ่งจําเป็นเพื่อแก้ปัญหาความแตกต่างเหล่านี้ ซึ่งวิธีการในการกําหนดมาตรฐานฯ ด้านความหมายข้อมูลที่สามารถดําเนินการได้อย่างมีประสิทธิภาพคือ การกําหนดแบบจําลองข้อมูลขึ้นจากมาตรฐานข้อมูลที่มีการใช้งานในระดับสากลเพื่อให้หน่วยงานเข้าใจความหมายของข้อมูลตรงกัน เกิดการยอมรับและนําไปสู่มาตรฐานการทํางานร่วมกันอย่างเต็มรูปแบบ รวมถึงสามารถแลกเปลี่ยนข้อมูลได้ในระดับสากล

แนวทางการสร้างมาตรฐานการแลกเปลี่ยนข้อมูลด้านความหมาย (Semantic Exchange) สําหรับประเทศไทยนั้นไม่ใช่เรื่องใหม่ โดยก่อนหน้านี้แนวทางดังกล่าวได้นำเสนอไว้ใน “กรอบแนวทางในการเชื่อมโยงรัฐบาลอิเล็กทรอนิกส์แห่งชาติ (Thailand e-Government Interoperability Framework, TH e-GIF)” ดังนั้นการพัฒนามาตรฐานฯ ด้านความหมายข้อมูลนี้จึงรับแนวทางที่นําเสนอไว้มาเป็นแนวคิดเริ่มต้นแนวคิดในการพัฒนามาตรฐานต่อไป

กรอบแนวทางดังกล่าว ได้จําแนกสถาปัตยกรรมการเชื่อมโยงและแลกเปลี่ยนข้อมูล ออกเป็น 4 ด้าน ดังนี้

1. สถาปัตยกรรมด้านธุรกรรม (Business Architecture)
2. สถาปัตยกรรมด้านข้อมูล (Data Architecture)
3. สถาปัตยกรรมด้านระบบงาน (Application Architecture)
4. สถาปัตยกรรมด้านเทคโนโลยี (Technology Architecture)

จากสถาปัตยกรรมทั้ง 4 ด้านนี้ จะเห็นได้ว่าสถาปัตยกรรมด้านข้อมูล (Data Architecture) มีความเกี่ยวพันกับการพัฒนามาตรฐานฯ ด้านความหมายข้อมูลโดยตรง โดยเป็นการอธิบายเกี่ยวกับกลุ่มของข้อมูล โครงสร้างข้อมูล และลักษณะข้อมูล การหาข้อตกลงในการปรับลดชื่อรายการข้อมูลที่มีความหมายเหมือนกันให้เหลือเพียงชื่อเดียวและสร้างความสอดคล้องกับเงื่อนไขการจัดเก็บข้อมูลของแต่ละหน่วยงาน ซึ่งช่วยให้เกิดการใช้ข้อมูลร่วมกันระหว่างหน่วยงาน และสามารถนําเอาข้อมูลที่มีรูปแบบแตกต่างกันไปใช้ในการพัฒนาระบบงานได้

มาตรฐานการแลกเปลี่ยนข้อมูลแห่งชาติ

ที่มาของการสร้างมาตรฐานการแลกเปลี่ยนข้อมูลของไทย ได้มาจากการศึกษาข้อมูลต่างประเทศ และได้หยิบยืมมาตรฐานการแลกเปลี่ยนข้อมูลแห่งชาติ (National Information Exchange Model หรือ NIEM) ของสหรัฐอเมริกาที่ใช้กันมานานเป็นต้นแบบ เพื่อให้เข้าใจข้อมูลที่มีบริบทเดียวกัน ซึ่งเดิมแต่ละหน่วยงานจะใช้คำต่างกัน หากคำไหนของสหรัฐอเมริกาไม่มีก็นิยามศัพท์ไทยง่ายๆ ขึ้นใช้แทน

จากมาตรฐาน NIEM นั้น ทางไทยได้สร้างภาพรวมของข้อมูลสําหรับประเทศ โดยสร้างกลุ่มข้อมูลไว้ 3 กลุ่ม คือ กลุ่มข้อมูลหลัก (Core Data) กลุ่มข้อมูลส่วนขยาย (Extend Data) และกลุ่มข้อมูลอ้างอิง

จริงๆ แล้ว “ข้อมูล” หรือ “data” ทุกหน่วยงานล้วนมีกันครบถ้วน ปัญหาปัจจุบันเพียงแค่ขาดการ Integrate ข้อมูลเข้าด้วยกัน

ทั้งนี้ การแลกเปลี่ยนข้อมูลนั้น หัวใจอยู่ที่เจ้าของข้อมูล เนื่องด้วยข้อมูลต่างๆ จะเก็บไว้ที่หน่วยงานที่รับผิดชอบ เช่น ฐานข้อมูลทะเบียนราษฎร เก็บอยู่ที่สำนักทะเบียนกลาง ในสังกัดกรมการปกครอง กระทรวงมหาดไทย ฐานข้อมูลสิทธิการรักษาพยาบาล สำนักงานหลักประกันสุขภาพ กระทรวงสาธารณสุุข หรือฐานข้อมูลของส่วนราชการอื่นๆ ล้วนอยู่ภายใต้ความรับผิดชอบของหน่วยงานที่แตกต่างกัน

ดังที่กล่าวมาแล้วว่า คำเรียก และโครงสร้างที่ต่างกันทำให้การแลกเปลี่ยนข้อมูลมีปัญหาการเชื่อมต่อนักพัฒนาโปรแกรมต้องใช้เวลามากมายทุ่มเทแก้ไขปัญหานี้ แถมสิ้นเปลืองงบประมาณ หากแต่ละหน่วยงานใช้มาตรฐานเดียวกันจะลดทั้งเวลา และงบประมาณ เพิ่มโอกาสการสร้างงานใหม่ๆ เพื่อให้บริการประชาชนได้อีกมาก

Core Data ของประเทศต้องมีมาตรฐาน

ตามที่กล่าวมาแล้วข้างต้น หน่วยงานเจ้าของข้อมูล ต่างมีชื่อเรียกต่างกัน พอจะต้องแลกเปลี่ยนข้อมูลข้ามหน่วยงาน เพื่อให้บริการประชาชน จึงกลายเป็นบ่อเกิดของปัญหา ที่นักพัฒนาโปรแกรมต้องเข้าแก้ไข หาวิธีจัดการเชื่อมอย่างไรให้ตรงกัน เรียกข้อมูลเดียวกันแต่ต่างชื่อมาใช้งานได้

หน่วยงานเจ้าของข้อมูลอยู่เฉยไม่ได้แล้ว ต้องดำเนินการแก้ไขให้เกิดการเชื่อมกันให้ได้

จากนั้น สำนักงานพัฒนารัฐบาลดิจิทัล (องค์การมหาชน) สพร. หรือ DGA จะทำหน้าที่ลงทะเบียน ใช้แบรนด์ TGIX ให้การรับรองมาตรฐานการเชื่อมโยงและแลกเปลี่ยนข้อมูลภาครัฐ โดยหน่วยงานที่สร้างข้อมูลตามเกณฑ์ของ DGA จะได้รับการรับรองมาตรฐานฯ ดังกล่าว ซึ่งจะใช้มาตรการทางการตลาดมาจูงใจให้หน่วยงานต่างๆ ใช้มาตรฐาน TGIX นี้

ทั้งนี้ เพื่อสนับสนุนการดําเนินการของหน่วยงานของรัฐในการให้บริการประชาชนผ่านระบบดิจิทัลอย่างเต็มรูปแบบเพื่อขับเคลื่อนประเทศในด้านต่างๆ ซึ่งกลไกสําคัญในการทําให้การบริการประชาชนผ่านระบบดิจิทัลทํางานได้อย่างมีประสิทธิภาพ คือ การเชื่อมโยงและแลกเปลี่ยนข้อมูลดิจิทัลระหว่างหน่วยงานของรัฐและการบูรณาการข้อมูลร่วมกัน โดย DGA ทําหน้าที่ให้บริการ ส่งเสริม และสนับสนุน การแลกเปลี่ยนข้อมูลระหว่างหน่วยงานของรัฐ

การแลกเปลี่ยนและเชื่อมโยงข้อมูลดิจิทัลระหว่างหน่วยงานของรัฐ มี ‘ข้อมูลบุคคล (Person)’ เป็นหนึ่งในกลุ่มข้อมูลหลัก (Core Data) สําคัญและจําเป็นต่อการให้บริการประชาชน ทั้งยังเป็นข้อมูลที่เกี่ยวพันกับกลุ่มข้อมูลด้านอื่น เช่น ด้านธุรกิจ ด้านการศึกษา ด้านสาธารณสุข ฯลฯ 

ดังนั้น จึงต้องมีมาตรฐานในการทํางานร่วมกัน (Interoperability) ระหว่างหน่วยงานของรัฐ โดย DGA จัดทำ “มาตรฐานการเชื่อมโยงและแลกเปลี่ยนข้อมูลภาครัฐ ด้านความหมายข้อมูล เรื่องข้อมูลบุคคล (THAILAND GOVERNMENT INFORMATION EXCHANGE STANDARD, SERIES: SEMANTIC, PART 1: PERSON DATA)” ขึ้น

อ้างอิงทะเบียนราษฎร

การพัฒนามาตรฐานข้อมูลบุคคลที่ DGA จัดทำขึ้นนี้ ได้อ้างอิงตามข้อมูลทะเบียนราษฎรของกรมการปกครอง ซึ่งเป็นหน่วยงานกํากับดูแลฐานข้อมูลทะเบียนราษฎรของประเทศ เพื่อให้เหมาะสมต่อการนําไปใช้ในทางปฏิบัติสําหรับหน่วยงานภาครัฐ และเพื่อให้หน่วยงานภาครัฐที่นํามาตรฐานการแลกเปลี่ยนข้อมูลบุคคลนี้ไปใช้พัฒนาระบบสารสนเทศลดค่าใช้จ่ายและระยะเวลาดําเนินงานได้อย่างเป็นรูปธรรม

เนื่องจาก เป็นมาตรฐานสำหรับใช้ในการแลกเปลี่ยนระหว่างหน่วยงาน มีความเกี่ยวข้องกับกลุ่มข้อมูลอ้างอิงทั่วไปบางประเภท รวมถึงการนิยามประเภทข้อมูลและรูปแบบข้อมูลอีกบางชนิด ดังนั้น DGA จึงจัดทำรายละเอียดของข้อมูลที่เกี่ยวข้องในมาตรฐานฉบับนี้ เพื่อให้นักพัฒนาระบบสารสนเทศสามารถใช้มาตรฐานฉบับนี้อ้างอิงในการพัฒนาระบบที่เกี่ยวข้องกับการแลกเปลี่ยนข้อมูลบุคคล ซึ่งอยู่ในกลุ่มข้อมูลหลัก (Core Data) และข้อมูลอ้างอิงทั่วไป (Common Reference Data) ได้โดยตรง (ดูตารางประกอบ)

ตารางที่ 1 กลุ่มข้อมูลที่เกี่ยวข้องกับข้อมูลบุคคล 

ลำดับ	องค์ประกอบข้อมูล	หมวดข้อมูล	ประเภท
1	ข้อมูลบุคคล	หมวด 2	กลุ่มข้อมูลหลัก
2	ประเภทข้อมูลชื่อบุคคล	หมวด 2	กลุ่มข้อมูลหลัก
3	ข้อมูลคำนำหน้าชื่อบุคคล	หมวด 1	กลุ่มข้อมูลอ้างอิงทั่วไป
4	ข้อมูลเพศ	หมวด 1	กลุ่มข้อมูลอ้างอิงทั่วไป
5	ข้อมูลสัญชาติ	หมวด 1	กลุ่มข้อมูลอ้างอิงทั่วไป
6	ข้อมูลศาสนา	หมวด 1	กลุ่มข้อมูลอ้างอิงทั่วไป
7	ข้อมูลสถานะบุคคล	หมวด 1	กลุ่มข้อมูลอ้างอิงทั่วไป
8	รูปแบบข้อมูลวันที่	–	รูปแบบข้อมูล
9	รูปแบบข้อมูลเบอร์ติดต่อ	–	รูปแบบข้อมูล

ข้อมูลแต่ละลำดับจะมีคำอธิบายข้อมูล (Data Description) หรือรายละเอียดที่จำเป็นของข้อมูลนั้น ประกอบด้วย 13 ด้าน (https://bit.ly/3vkzRkO)

ข้อมูลบุคคลคือข้อมูลหลัก

ข้อมูลบุคคล (cd:Person) เป็นข้อมูลที่อยู่ในหมวดข้อมูลหลัก (Core Data) เป็นข้อมูลที่บ่งบอกถึงตัวบุคคล มีคีย์หลัก (Primary Key) คือ เลขประจำตัวประชาชน 13 หลักที่กรมการปกครองออกให้แก่บุคคลในการจำแนกอินสแตน (Instance) ของข้อมูล ส่วนโครงสร้างดูรูปที่ 1

หัวใจของการจัดทำมาตรฐานข้อมูลบุคคลอยู่ที่การเลือกใช้คำศัพท์ใดแทนคำอะไร นอกเหนือจากข้อมูลหลักแล้วยังต้องมีข้อมูลอ้างอิงทั่วไป (Common Reference Data)

เช่น ข้อมูลคำนำหน้าชื่อบุคคล (cr:PersonNameTitle) เป็นข้อมูลที่แสดงคำนำหน้าชื่อของบุคคล มีคีย์หลัก (Primary Key) เป็นรหัส cr:PersonNameTitleCode ในการจำแนกอินสแตน (Instance) ของข้อมูล และใช้เป็นองค์ประกอบของประเภทข้อมูลชื่อบุคคล (cd:PersonNameType) ซึ่งเป็นประเภท Complex Type หรือข้อมูลเพศ (cr:Sex) เป็นข้อมูลที่บ่งถึงเพศ (ทางกายวิภาค) มีคีย์หลัก (Primary Key) เป็นรหัส cr:SexCode ในการจำแนกอินสแตน (Instance) ของข้อมูล เป็นต้น

มาตรฐานการแลกเปลี่ยนข้อมูลจำเป็นสำหรับการติดต่อข้ามหน่วยงาน เปรียบเสมือนการติดต่อระหว่างประเทศต้องใช้ภาษากลาง การติดต่อในระบบดิจิทัลก็ต้องใช้ภาษาเดียวกัน ชื่อ Field เดียวกันถึงจะทำให้สื่อสารแลกเปลี่ยนกันได้

เห็นผลช่วง COVID-19

ที่ผ่านมา ในช่วงการระบาดของ COVID-19 มี 6-7 หน่วยงานต้องประสานงานเรื่องผู้ป่วย การจัดหาเตียงว่างรอรับผู้ป่วย ความจำเป็นทำให้เกิดการประสานงานร่วมกัน “กางโต๊ะ” กำหนด Field ให้เหมือนกัน เพื่อส่งผู้ป่วยไปอยู่เตียงได้เร็วที่สุด เคลื่อนย้ายผู้ป่วย COVID-19 ได้เร็ว 

หลังจากเหนื่อยร่วมกัน ประมาณ 2 เดือน ผลตอบรับช่วยผู้ป่วยได้นับแสนคน 

หากอนาคตหน่วยงานรัฐต่างๆ ร่วมมือใช้มาตรฐานเดียวกันตามที่ DGA จัดทำขึ้น เชื่อว่า จะช่วยให้การทำงานแลกเปลี่ยนข้อมูลคล่องตัวขึ้นอีกมาก แถมประหยัดเวลา และงบประมาณอีกมหาศาล ดังนั้น เป้าหมายการสร้างผลิตภัณฑ์ให้บริการประชาชนในรูปแบบดิจิทัลจะเกิดเป็นรูปธรรมได้จำนวนมาก และเร็วขึ้น ซึ่งจะเปิดมิติใหม่ของการเข้าถึงบริการของรัฐให้เป็นจริงในไม่ช้า

ประชาชนสนทนา เรื่อง มาตรฐานการเชื่อมโยงและแลกเปลี่ยนข้อมูลภาครัฐ

สามารถศึกษาข้อมูลเพิ่มเติมได้ที่ : TGIX เชื่อมโยงแลกเปลี่ยนข้อมูลภาครัฐสู่มาตรฐานเดียวกัน – Digital Government Standard (dga.or.th)