เมื่อการแลกเปลี่ยนข้อมูลระหว่างหน่วยงานภาครัฐเป็นเป้าหมายหลัก เพื่อให้การทำงานของระบบเป็นไปอย่างราบรื่น ข้อมูลที่เชื่อมโยงกันสามารถเรียกใช้ได้อย่างครบถ้วน รวดเร็ว เสมือนอยู่บนแพลตฟอร์มเดียวกัน และที่สำคัญมีการรักษาความปลอดภัยในระดับที่เชื่อถือได้
เช่นนั้น สำนักงานพัฒนารัฐบาลดิจิทัล (องค์การมหาชน) หรือ สพร. (DGA) จึงได้จัดทำข้อกำหนดขึ้นมา 5 ด้าน ภายใต้มาตรฐานการเชื่อมโยงและแลกเปลี่ยนข้อมูลภาครัฐ (TGIX-Thailand Government Information Exchange) ในระดับด้านการเชื่อมโยงข้อมูล (Linkage) ครอบคลุมทุกระดับของการแลกเปลี่ยนข้อมูล โดยมีวัตถุประสงค์หลักเพื่อทำหน้าที่ป้องกันการเข้าถึงบริการข้อมูลหรือ API ของผู้ให้บริการโดยไม่ถูกต้อง ซึ่งข้อกำหนดทั้ง 5 ด้าน ประกอบไปด้วย
- ข้อกำหนดด้านการยืนยันตัวตน การควบคุมสิทธิ และบัญชีการใช้งาน (AAA-Authentication, Authorization และ Accounting)
- ข้อกำหนดด้านการตรวจสอบระบบและการลงบันทึกล็อก (Logging and Monitoring)
- ข้อกำหนดด้านการกำหนดชื่อและเนมสเปซ (Namespace)
- ข้อกำหนดด้านโปรโตคอลระดับแอปพลิเคชัน เอนพอยน์ และการจัดการโทเคนและเซสชัน
- ข้อกำหนดด้านความน่าเชื่อถือและความมั่นคงปลอดภัย
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>://<authority>/<path>?query
<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. ข้อกำหนดด้านความน่าเชื่อถือและความมั่นคงปลอดภัย
ความน่าเชื่อถือและความมั่นคงปลอดภัยเป็นเรื่องจำเป็นเมื่อมีการแลกเปลี่ยนข้อมูลใดๆ ระหว่างกัน โดยวัตถุประสงค์หลักของข้อกำหนดในด้านนี้ คือ
- เพื่อการรักษาความลับของข้อมูล (Confidentiality) นั่นคือการเก็บรักษาข้อมูลให้เป็นความลับและจำกัดสิทธิในการเข้าถึงอมูลของผู้ใช้งานระบบด้วยการยืนยันตัวตน (Authentication) และการตรวจสอบสิทธิ (Authorization) ในการเข้าถึงทรัพยากร,
- ความถูกต้องของข้อมูล (Integrity) คือการตรวจสอบและให้มั่นใจว่าข้อมูลที่มีการแลกเปลี่ยนกันภายในมาตรฐาน TGIX มีความถูกต้องและสมบูรณ์ครบถ้วน
- ความพร้อมให้บริการของระบบได้อย่างต่อเนื่อง (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 ด้านดังกล่าว
