GDPR กับ Developer

TheHoiStory
Scale360 Engineering
2 min readAug 1, 2018

หลายเดือนมานี้ใน inbox e-mail ของหลายคนคงเต็มไปด้วย mail ที่เกี่ยวกับ GDPR

GDPR ชื่อเต็มๆคือ General Data Protection Regulation

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

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

GDPR บอกว่า “กฏหมายนี้มีผลกับการประมวลผลข้อมูลของบุคคลในยุโรป แม้ว่าการประมวลผลนั้นจะเกิดขึ้นนอกยุโรปก็ตาม”

This Regulation applies to the processing of personal data in the context of the activities of an establishment of a controller or a processor in the Union, regardless of whether the processing takes place in the Union or not.

อ้างอิงจาก : https://gdpr-info.eu/art-3-gdpr/

เพราะฉนั้นต่อให้บริษัทเราอยู่ที่ไทย แต่ลูกค้าเราเป็นคนในยุโรป ก็มีผลเช่นกัน

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

แต่ข้อที่สำคัญคือค่าปรับสูงถึง 20 ล้านเหรียญ เลยนะจ๊ะ (เงินเดือน กับโบนัส ก็คง อันตรธาน หายไป TT)

GDPR กับ Developer

เนื่องจากบริษัทที่ผมกำลังทำอยู่นั้นจะถูกให้บริการที่ UK ซึ่งเข้ากับประเทศที่ GDPR บังคับใช้เต็มๆ

GDPR ไม่ใช่เรื่องที่ต้องสนใจเฉพาะ ฝ่ายบริหาร ฝ่ายกฎหมาย เท่านั้น

ตัว Dev เองก็ต้องใส่ใจเรื่องพวกนี้ด้วยใช่กัน

เพราะมีหลักการหนึ่งของ GDPR คือ Data protection by design and default นั่นคือ มีการคิดเรื่องการคุ้มครองข้อมูลตั้งแต่การออกแบบ

เพราะฉนั้น Dev ก็ต้องคิดถึงเรื่องนี้ตั้งแต่การออกแบบ service ต่างๆ รวมถึง coding ด้วยเช่นกัน

Data portability

ลูกค้าสามารถร้องขอข้อมูลทั้งหมดที่ระบบเราเก็บไว้ได้ โดยเป็นไฟล์ digital (json,csv, ….etc) เพื่อนำไปใช้ในระบบอื่นได้

ซึ่งข้อนี้ถือเป็นงานยากสำหรับ dev เหมือนกัน เนื่องจากงานที่ทำเป็น microservice เพราะฉนั้นข้อมูลจะกระจายไปหลายๆที่

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

ดังนั้น จึงต้องคำนึงอยู่เสมอว่าจัดเก็บข้อมูลอย่างไรเพื่อ export ได้ง่ายแล้วยังมีความปลอดภัยอยู่ และเมื่อมีการร้องขอข้อมูลในส่วนที่เกี่ยวข้อกับเรา เราจะ process อย่างไร

Right to be forgotten

นอกจาก user จะขอข้อมูลของตัวเองได้แล้ว user ยังสามารถสั่งให้ลบข้อมูลของตัวเองได้อีกด้วย

เพราะฉนั้นนอกจาก dev จะต้องคำนึงถึงการ export data แล้ว จะต้องทำให้ data นั้นถูกลบออกจากระบบได้ด้วย และทีคำคัญระบบต้องไม่พัง

“Null Pointer Exception”
“Not Found Exception”
“Cannot delete or update a parent row: a foreign key constraint fails…”

ถ้าตอนออกแบบไม่ได้คำนึงถึงการ ลบข้อมูล ของ user รับรองได้เจอ error แบบนี้เต็มไปหมดแน่

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

Logging

ทีนี้มาถึงเรื่องน่าปวดหัวของ Dev (อันนี้ไม่ได้มีกำหนดใน GDPR แต่เราก็ต้องคำนึงถึงครับ)

เคยอยู่ในสถาณการณ์แบบนี้ไหมครับ

Manager : error บน production
Dev : แปปพี่ดู log ก่อน

ผมว่าใครๆก็น่าจะเคยเจออะไรประมาณนี้กันนะครับ
แต่คำถามคือ

Log แสดงอะไรได้บ้าง ?
ถ้า log มีข้อมูลสำคัญของ user dev ควรมีสิทธิ์เห็นไหม ?
ถ้า log ไม่มีข้อมูลสำคัญของ user ถ้าตอนจำเป็นจะใช้ทำอย่างไร ?

คำถามพวกนี้หลุดเข้ามาเต็มหัวผมหมดตั้งแต่เข้าทำงานที่นี่วันแรก

นาย Pikachu โอนเงินจากบัญชี A-123–4 ถึง นาย Doraemon บัญชี B-987–6 จำนวน 10000000 บาท วันที่ 30/06/2018 เวลา 18:00”

ด้านบนคือ business log ที่สมมติขึ้น

หลายๆครั้ง dev ก็จำเป็นจะต้องเข้าถึง log ได้เพื่อที่จะได้ดูว่าเกิดอะไรขึ้นบ้าง เพื่อที่จะได้หาปัญหาต่อไป

แต่ ข้อมูลสำคัญ เช่น ชื่อ เลขบัญชี จำนวนเงิน มันเป็นสิ่งที่ dev ไม่ควรเห็น

เพราะฉนั้นเราไม่ควร log ข้อมูลเหล่านั้น

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

ทำไงดี?

ที่บริษัทได้คิดหลักการ masking sensitive data ขึ้นมา นั้นคือบังไม่ให้เห็นเฉพาะข้อมูลสำคัญ

เพราะฉนั้นตอนนี้สิ่งที่ dev จะเห็นคือ

sddsgqwuhdjkqwhd โอนเงินจากบัญชี dfsddxasdas ถึง sadasdsadfg บัญชี fsadsadasd จำนวน ddfgdfgfdgs บาท วันที่ 30/06/2018 เวลา 18:00”

ข้อมูลสำคัญจะถูกซ่อนไว้ ไม่สามารถอ้างอิงถึงใครได้

ส่วนคนที่มีสิทธิ์เข้าถึงข้อมูลจึงจะเห็น log แบบเดิม

แบ่ง message และ sensitive data ออกจากกัน

จากรูปจะเห็นว่ามีการแยก sensitive data ใน log ออกไป DB อีกถังนึง เพราะฉนั้น สิทธิ์การเข้าถึง DB นี้ ต้องมีการจำกัดอย่างมาก

การทำแบบนี้จะได้ข้อดีอีกอย่างนึงคือ เวลาลูกค้าจะลบข้อมูลตัวเอง เราอาจจะลบเฉพาะข้อมูลฝั่ง sensitive ได้

ส่วน message log ปกติ อาจจะเก็บไว้ประมวลผล หรือ จะลบออก ก็ขึ้นอยู่กับข้อกำหนดของแต่ละบริษัท

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

จริงๆแล้ว GDPR ถือเป็นเรื่องที่ละเอียดอ่อน ต้องมีการคุยกันทุกฝ่าย และบริษัทที่ผมทำ เองก็มีเรื่องที่ต้องทำเกี่ยวกับ GDPR เยอะมาก (รวมถึง business หลักก็ต้องทำ)

เพราะฉนั้นตอนนี้เราต้องการคนเยอะมากกกกกกก มาช่วยที

ใครสนใจสมัครเลย ====> Scale360

--

--

TheHoiStory
Scale360 Engineering

Dev กากๆ ชอบลองอะไรไปเรื่อย ไม่มีคนคุยด้วยเลยมาเขียนแทน FB page : เดอะห้อยแมน