4 ขั้นตอนง่ายๆ กับการ Comply GDPR

• GDPR Article 25 — Data protection by design and default กล่าวคือ เราต้องสามารถควบคุมการเข้าออกของ user ได้ว่าใครเป็นคน access และเข้ามาโดยวิธีไหน
• GDPR Article 32 — Security of processing ในขั้นตอนนี้จะบอกถึงกลไกในการป้องกันข้อมูลส่วนบุคคล เช่น ข้อมูลต้องได้รับการ encryption, ข้อมูลต้องสามารถ restore ได้ในกรณีที่เกิดเหตุการณ์ไม่คาดคิด เป็นต้น
• GDPR Article 33 — Notification of a personal data breach to the supervisory authority ต้องมีการแจ้งเตือนการละเมิดข้อมูลส่วนบุคคลภายใน 72 ชั่วโมง เป็นต้น
• GDPR Article 30 — Records of processing activities ต้องมีการบันทึก log และสามารถ monitor operation ต่างๆได้
• GDPR Article 35 — Data Protection impact assessment ต้องมีขั้นตอนการประเมินผลความเสี่ยงและมาตรการความปลอดภัย

สำหรับใครที่อยากหาข้อมูลเพิ่มเติมของ GDPR สามารถอ่านข้อมูลเพิ่มเติมได้ตามนี้ค่ะ General Data Protection Regulation (GDPR) — Official Legal Text

สำหรับของฝั่งไทย สามารถอ่านข้อมูลเพิ่มเติมได้ ตามนี้นะคะ พ.ร.บ. คุ้มครองข้อมูลส่วนบุคคล

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

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

สำหรับวิธีที่เราสามารถเอาไป comply GDPR แบ่งออกเป็น 4 steps ดังนี้

ในแต่ละขั้นตอนก็จะมี feature ของ SQL Server เองที่คอยสนับสนุน ทำให้เราสามารถ comply GDPR ได้ตามข้อกำหนด เรามาดูกันเลยดีกว่าว่ามี feature อะไรกันบ้าง

ขั้นตอนการเปิด report data classification คือคลิกขวาที่ database >> Task >> Data Discovery and Classification >> Classify Data

หน้าตาของ Data Classification ตัว report จะสามารถแนะนำให้เราได้ว่า มี column ไหนบ้างที่จัดว่าเป็น sensitive data

• Authentication: ใน SQL Server ถือเป็น feature พื้นฐานของ SQL Server อยู่แล้ว และ SQL Server on Windows จะ support 2 mode ของ Authentication คือ Windows authentication ที่ใช้งานได้กับ Windows Authentication เท่านั้น และ mixed mode ที่สามารถ support ได้ทั้ง Windows Authentication และ SQL Server Authentication
• Authorization: เป็นกลไกที่จัดการการเข้าถึงข้อมูลใน database โดยระบุ policy ที่เหมาะสม ประกอบไปด้วย database role และ object level permission ภายใน database ควรมีการแยก account หรือ role ที่ระบุเป็น high privileged operation ซี่งเป็น role ที่ใช้โดย application หรือ user ที่ทำ activities แบบ day-to-day
• Dynamic data masking (DDM): เพื่อ limit sensitive data โดยการ masking ไม่ให้ data ที่ไม่ได้เป็น non-privileged user หรือ application ไม่ให้สามารถเข้าถึงข้อมูลส่วนบุคคลได้, DDM จะ allow แค่ database administrator เท่านั้นที่สามารถเข้าไป select ข้อมูลที่เป็น sensitive data

การใช้ DDM นั้นจะมี impact น้อยกับ application layer เพราะแทบจะไม่ต้องแก้ application แต่ว่าต้องมาจัดการที่ database แทนเพราะว่าต้องมีการเปลี่ยนแปลง structure ของ table โดยเราจะสาธิตขั้นการสร้าง DDM ให้ดูกัน มีรายละเอียดต่อไปนี้

ขั้นตอนการติดตั้ง Dynamic Data Masking

ขั้นตอนที่ 1 สร้าง table ใหม่พร้อมทั้ง function data masking

USE salesapp1;
GO

CREATE TABLE HR.EmployeePersonalData
(
empid int NOT NULL PRIMARY KEY,
salary int MASKED WITH (FUNCTION = ‘default()’) NOT NULL,
email_address varchar(255) MASKED WITH (FUNCTION = ‘email()’) NULL,
voice_mail_pin smallint MASKED WITH (FUNCTION = ‘random(0, 9)’) NULL,
company_credit_card_number varchar(30) MASKED WITH (FUNCTION = ‘partial(0,”XXXX-”,4)’) NULL,
home_phone_number varchar(30) NULL
);
GO

User ที่เราจะใช้ทดสอบในครั้งนี้ test_user ให้เราทำการ grant สิทธิ์ SELECT ของ HR.EmployeePersonalData ไปยัง test_user อย่างเดียว ไม่มีสิทธิ์ sysadmin permission และอีก 1 user ที่มี sysadmin permission

หลังจากนั้นให้เริ่ม insert test data เข้าไปใน table ตาม command ต่อไปนี้

INSERT HR.EmployeePersonalData
(empid, salary, email_address, voice_mail_pin, company_credit_card_number, home_phone_number)
VALUES (1,25000,’emp1@adventure-works.net’,9991,’9999–5656–4433–2211', ‘1234–567890’),
(2,35000,’qx3e@adventure-works.org’,1151,’9999–7676–5566–3141', ‘2345–314253’),
(3,35000,’zn4456@adventure-works.net’,6514,’9999–7676–5567–2444', ‘3456–777266’)

ขั้นตอนที่ 2 — เริ่ม select ข้อมูลจาก user ที่มี sysadmin permission ว่าสามารถดู data ที่ถูก mask ได้

SELECT * FROM HR.EmployeePersonalData

จากผลลัพธ์จะเห็นว่า user test_user ที่ถูก grant UNMASK permission ให้แล้วจะสามารถเห็นจำนวน salary ใน table

ขั้นตอนที่ 10 — remove test table

DROP TABLE HR.EmployeePersonalData;
GO

• Row-level security: เป็นอีก feature ที่สามารถจำกัดการเข้าถึงข้อมูลส่วนบุคคล เพราะเป็นการ control access ไปยัง row ใน table เช่น หมอที่ต้องการดูข้อมูลใน table A จะสามารถดูข้อมูลได้บาง row ที่หมอมีส่วนเกี่ยวข้องกับ row เหล่านี้เท่านั้น ไม่สามารถมองเห็นข้อมูลของ row อื่นได้ และไม่สามารถมองเห็นข้อมูลได้ทั้ง table A

• Transparent data encryption: เป็น built-in feature ที่สามารถ protect data ได้ที่ระดับ physical storage layer. TDE ทำงานเป็นแบบ real-time encryption และ decryption ของ database รวมไปถึงการ encrypt backup และ transaction log โดยที่ไม่ต้องมีการแก้ไข application
• SQL Threat Detection: เป็น built-in feature ของ Azure SQL Database เพื่อช่วยให้ database ช่วยตรวจจับภัยคุกคาม activities เราสามารถได้รับการแจ้งเตือนเกี่ยวกับกาตรวจสอบภัยคุกคามผ่านทาง email หรือ Azure portal
• Always encrypted: SQL Server ให้ industry-first security feature ที่ถูกออกแบบมาเพื่อปกป้อง highly sensitive data โดยเฉพาะ เพราะว่า Always encrypted จะ allow ให้ customer encrypted sensitive data ข้างใน client application และไม่มีการเปิดเผย encryption key ไปยัง database engine โดยเราจะสาธิตขั้นการสร้าง Always encrypted ให้ดูกัน มีรายละเอียดต่อไปนี้

ขั้นตอนการทำ Always Encrypted

Step 1: ในการสาธิตวิธีการทำครั้งนี้ เราเลือก column phone จาก sales.customers table จากนั้นทำการตรวจสอบข้อมูลก่อนทำการ configure พบว่าเลขโทรศัพท์ format เป็นเหมือนภาพด้านล่างนี้

Step 2: เริ่มทำ configure always encrypted
โดยการคลิกขวาที่ column phone และเลือก encrypt column จากนั้น tool จะ pop up wizard ขึ้นมา

step 3: เลือก column ที่จะใช้ encrypted และเลือกประเภทของการ encrypted ข้อมูล
จากรูปด้านล่าง เราจะเห็นว่ามี column phone ถูกเลือกอยู่แล้ว จากนั้นเราจะมาเลือกประเภทของการ encrypted ข้อมูล โดยในการสาธิตในครั้งนี้ เราเลือกเป็นแบบ Randomized

ขออธิบายเพิ่มเติมเกี่ยวกับประเภทของการทำ encrypted ใน always encrypted โดยประเภทในการทำจะแบ่งออกเป็น 2 ประเภท

1. Deterministic encryption: การ encrypted ประเภทนี้ข้อมูลที่ใช้แสดงผล หน้าตาของมันจะเหมือนกับข้อมูลที่ถูก encrypted เก็บไว้ใน database และการ encrypted ประเภทนี้สามารถใช้งานร่วมกับ grouping function ได้

2. Randomized encryption: การ encrypted ประเภทนี้ข้อมูลที่ถูก encrypted จะไม่สามารถคาดเดา format ได้และข้อมูลจะมีการเปลี่ยน format ทุกครั้งที่เรา select ข้อมูลขึ้นมาดูใหม่ และการ encryption ประเภทนี้จะไม่สามารถใช้งานร่วมกับ grouping function ได้

Step 4: ในหน้า Master Key Configuration นั้นใน tab ชื่อ select column master key เลือก Auto generate column master key และ tab ชื่อ select the key store provider เลือก Windows certificate store ตามรูปด้านล่าง

Step 5: ทำการเลือกวิธีการดำเนินการต่อ
จากรูปเลือก Proceed to finish now

Step 6: หน้า summary สามารถกด finish ได้เลย

เมื่อ process การ configure เสร็จเรียบร้อยแล้วให้ทำการตรวจสอบข้อมูลที่อยู่ใน column phone เมื่อทำการ select ข้อมูล จากรูปด้านล่างจะเห็นว่า เลขโทรศัพท์ที่เราได้ทำการตรวจสอบไว้ใน step 1 นั้น ได้ถูก encrypted เรียบร้อยแล้ว

• Microsoft SQL Auditing: feature นี้จะเป็นการ maintain audit log สำหรับ Microsoft activities ทั้งหมดที่อยู่ใน database และ record ทั้งหมดนี้สามารถนำไป analyze เพื่อทำ report ได้
• Temporal table: เป็น table ประเภทใหม่ที่เริ่มใช้งานใน SQL Server 2016 ถูกออกแบบมาเพื่อให้เก็บประวัติการใช้งานทั้งหมดของ data ที่มีการเปลี่ยนแปลง และง่ายต่อ point in time analysis.
• Vulnerability Assessment(VA): เป็น feature report ที่เอาไว้ประเมินความเสี่ยงต่างๆ ที่อาจจะเกิดขึ้นกับ database เราสามารถเอา report ออกมาดู result ได้ว่าตรงไหนที่เราควรเพิ่มความปลอดภัยให้กับ database

จากรูปด้านบนจะเห็น result ของ VA Report ที่จะบอกความเสี่ยงที่เกิดขึ้นใน failed tab และมีอีกส่วนที่เป็น passed tab ก็จะบอกว่า database ของเรานั้นผ่านเกณฑ์การประเมินอะไรของ VA Report บ้าง

สิ้นสุดกันไปแล้วสำหรับ 4 วิธีการในการสำรวจ SQL Server database ว่าเราสามารถใช้ feature ไหนมาสนับสนุนการ comply GDPR เดี๋ยวเราจะมาสรุปให้ฟังกันดีกว่าว่า feature ไหนตรงกับข้อกำหนดไหนของ GDPR บ้าง

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