ปกป้อง เก็บรักษา และพิสูจน์

🌐 มีให้อ่านอีก 28 ภาษา

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

ภาพสร้างด้วย AI

แปลโดย AI ชุมชนยังไม่ได้ตรวจทาน อ่านเป็นภาษาอังกฤษ

โมดูลที่ 6 จาก 6 ในบท คุณภาพและธรรมาภิบาลข้อมูล บทที่ 5 ของหลักสูตร Data Architect แต่ละโมดูลอ่านแยกกันได้ ก่อนหน้า: ความยินยอมและสิทธิที่จะถูกลืม · ถัดไป: บทถัดไป ข้อมูลหลักและตัวตน

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

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

ธรรมาภิบาลตามข้อมูลไป

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

บันทึก → จัดประเภท → ปกป้อง → ใช้งาน → เก็บรักษา → ลบ → ตรวจสอบ

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

Click to enlarge

เจ็ดคำถามตลอดชีวิตของข้อมูล เครื่องมือสนับสนุนนโยบาย แต่ไม่ได้กำหนดนโยบาย

ปกป้อง: จับคู่การควบคุมกับข้อมูล

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

การเข้ารหัสคือการควบคุม ไม่ใช่การปฏิบัติตามกฎ

สำหรับข้อมูลที่ถูกกำกับดูแล การเข้ารหัสข้อมูลที่จัดเก็บอาจเป็นข้อกำหนด และจุดยืนของผมคือ Shield คือคำตอบสำหรับข้อกำหนดด้านกฎระเบียบสำคัญอย่างนั้น Shield Platform Encryption เข้ารหัสฟิลด์และไฟล์ที่จัดเก็บ แต่ “เราเข้ารหัสแล้ว เราจึงปฏิบัติตามกฎ” ผิดสองชั้น การเข้ารหัสเป็นการควบคุมหนึ่งในหลายอย่าง ร่วมกับการเข้าถึง การเก็บรักษา การตรวจสอบ ความยินยอม การเฝ้าระวัง การเก็บให้น้อยที่สุด และการลบ และมันมีการแลกเปลี่ยนได้เสียเชิงฟังก์ชันที่คุณต้องออกแบบรองรับตั้งแต่ต้น ด้วยรูปแบบ probabilistic ที่เป็นค่าเริ่มต้น ฟิลด์ที่เข้ารหัสใช้ในคำสั่ง SOQL WHERE, GROUP BY หรือ ORDER BY หรือในตัวกรองการจัดการข้อมูลไม่ได้ การเข้ารหัสแบบ deterministic ยอมสละความแข็งแรงเล็กน้อยเพื่อให้คุณกรองด้วยฟิลด์นั้นได้ ฟิลด์ที่เข้ารหัสขับเคลื่อนกฎการแชร์แบบตามเกณฑ์ไม่ได้ และคุณเรียง list view ด้วยมันไม่ได้ (General Shield Platform Encryption Considerations (opens in a new tab); Filter Encrypted Data with Deterministic Encryption (opens in a new tab) ภาษาอังกฤษ) ดังนั้นการเข้ารหัสไม่ใช่ช่องติ๊กตอนท้าย มันคือการตัดสินใจทางสถาปัตยกรรม บทความปลอดภัยของข้อมูลลงลึกกว่านี้

อย่าคัดลอกความเสี่ยงจาก production เข้า sandbox

production ถูกล็อกแน่นหนา แล้วมีคนรีเฟรช full sandbox และตอนนี้นักพัฒนา ผู้ทดสอบ ผู้รับเหมา และการผสานรวมสำหรับทดสอบก็ถือสำเนาข้อมูลส่วนบุคคลจริงที่พวกเขาไม่เคยต้องการ สภาพแวดล้อมเปลี่ยน แต่ความอ่อนไหวของข้อมูลไม่เปลี่ยน เครื่องมือปิดบังข้อมูลของ Salesforce มีอยู่เพื่อเรื่องนี้พอดี สังเกตการเปลี่ยนแปลง: แพ็กเกจ Data Mask แบบ managed package จะสิ้นสุดการให้บริการในวันที่ 31 ธันวาคม 2026 และตัวต่อคือ Data Mask & Seed (Data Mask (Legacy) (opens in a new tab) ภาษาอังกฤษ) แต่เครื่องมือสนับสนุนนโยบาย และคำถามมาก่อน: สภาพแวดล้อมนี้ต้องการข้อมูลอ่อนไหวจริงเลยหรือไม่? ถ้าข้อมูลที่สมจริงแต่ไม่อ่อนไหวใช้ทดสอบได้ นั่นคือคำตอบที่ดีกว่า

ใช้งาน: การอนุญาตไม่ได้เกี่ยวกับคนอย่างเดียว

ผู้ใช้ การผสานรวม การวิเคราะห์ พันธมิตร ระบบอัตโนมัติ และเอเจนต์ล้วนใช้ข้อมูล ความยินยอม (โมดูลที่ 5) ความเป็นเจ้าของ (โมดูลที่ 1) และการจัดประเภท (โมดูลที่ 3) มาพบกันที่นี่ขณะระบบทำงาน ผู้ใช้คนนี้ควรเห็นเบอร์โทรศัพท์ของผู้รับไหม? การผสานรวมนี้ควรได้มันไหม หรือ Snowflake หรือเอเจนต์นี้ในฐานะ grounding? คำตอบจะเป็น “ก็ ในทางเทคนิคมันทำได้” ไม่ได้ นั่นคือความต่างระหว่างความสามารถกับธรรมาภิบาล: สถาปัตยกรรมตัดสินว่ามันควรหรือไม่

เก็บรักษา: การเก็บทุกอย่างตลอดไปไม่ได้เป็นกลาง

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

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

ลบ: วงจรชีวิตต้องมีทางออก

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

ประวัติก็เป็นข้อมูล

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

การติดตามประวัติฟิลด์ (field history tracking) แบบมาตรฐานติดตามได้สูงสุด 20 ฟิลด์ต่อออบเจกต์ และเก็บการเปลี่ยนแปลงไว้ได้ถึง 18 เดือน และถึง 24 เดือนเฉพาะผ่าน API ด้วย Data Loader หรือ queryAll() (Field History Tracking Overview (opens in a new tab) ภาษาอังกฤษ) และสำหรับฟิลด์ข้อความยาว มันบันทึกแค่ว่าฟิลด์ถูกแก้ไข ไม่ได้บันทึกว่าเขียนว่าอะไร: เป็นช่องโหว่ถ้านั่นคือหลักฐานของคุณ Field Audit Trail ซึ่งเป็นส่วนหนึ่งของ Shield หรือซื้อแยก ติดตามได้สูงสุด 200 ฟิลด์ต่อออบเจกต์ และเก็บประวัติไว้จนกว่าคุณจะลบ ในที่เก็บถาวรที่เข้าถึงผ่าน API (Field Audit Trail (opens in a new tab) ภาษาอังกฤษ) จุดยืนของผม: ประวัติฟิลด์มาตรฐานคือค่าเริ่มต้น ใช้ Field Audit Trail เมื่อกฎระเบียบหรือพันธะด้านการปฏิบัติตามกฎเรียกร้องประวัติที่ยาวกว่าและพิสูจน์ได้ ไม่ใช่เพราะ “การตรวจสอบฟังดูดี”

การตรวจสอบกับการเฝ้าระวังไม่ใช่สิ่งเดียวกัน

ประวัติฟิลด์ตอบคำถามเกี่ยวกับการเปลี่ยนแปลงของฟิลด์ที่เลือก คำถามที่กว้างกว่า (ใครล็อกอิน ใครส่งออกข้อมูล API ใดถูกเรียก ใครดูอะไร) คือการเฝ้าระวัง และนั่นคือ Event Monitoring จากประสบการณ์ของผม มันมักจำเป็นกับลูกค้าที่ถูกกำกับดูแลมากกว่า และนี่คือจุดยืนที่หนักแน่นที่สุดของผมในบทนี้: ตั้งค่ามันก่อนที่คุณจะต้องใช้ และส่งเหตุการณ์ไปยังที่เก็บอย่าง Splunk หรือ SIEM อื่นไว้ล่วงหน้า

นี่คือเหตุผล ไฟล์ล็อกเหตุการณ์ถูกเก็บไว้ 1 วันถ้าไม่มี add-on และเฉพาะเหตุการณ์บางประเภท 30 วันโดยค่าเริ่มต้นเมื่อมี Shield หรือ add-on Event Monitoring และสูงสุด 365 วันถ้าคุณขยายการเก็บรักษา (Event Monitoring FAQ (opens in a new tab) ภาษาอังกฤษ) อะไรที่เก่ากว่านั้นหายไป เว้นแต่คุณส่งออกไว้ และล็อกแบบเสียเงินดึงย้อนหลังไปก่อนวันที่สัญญาเริ่มไม่ได้ (FAQ เดียวกัน): การซื้อ add-on หลังเกิดเหตุไม่ได้นำอดีตกลับมา ดังนั้นบทสนทนาที่แย่ที่สุดบทหนึ่งที่สถาปนิกจะมีได้คือ: “เราดูได้ไหมว่าเกิดอะไรขึ้นเมื่อหกเดือนก่อน?” “ไม่ได้” “ทำไม?” “เราไม่ได้เก็บไว้” คุณไม่ควรเจอปัญหาแล้วเพิ่งพบว่าไม่ได้เก็บและจัดเก็บเหตุการณ์เหล่านั้นไว้ ถึงตอนนั้นคำตอบก็หายไปแล้ว

Click to enlarge

ตั้งค่าไว้ก่อนที่คุณจะต้องใช้

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

พิสูจน์การควบคุม ไม่ใช่แค่การตั้งค่า

“ข้อมูลผู้รับเข้าถึงได้เฉพาะทีมจัดส่งที่ได้รับมอบหมายให้จุดแวะนั้น” เรารู้ได้อย่างไร? การตั้งค่าความปลอดภัยแสดงว่าอะไรควรเกิดขึ้น หลักฐานเชิงปฏิบัติการ (ใครเข้าถึงจริง การส่งออกที่ผิดปกติ การผสานรวมที่ดึงมัน การควบคุมการเข้าถึงที่ถูกเปลี่ยน) แสดงว่าอะไรได้เกิดขึ้น ธรรมาภิบาลที่ดีมักต้องการทั้งสองอย่าง

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

Steve Trucking: วงจรชีวิตบนฟิลด์เดียว

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

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

ธรรมาภิบาลไม่มีวันเสร็จ

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

สิ่งที่สถาปนิกต้องตัดสินใจในเรื่องนี้

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

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

ศึกษาเพิ่มเติม

• Salesforce Help, General Shield Platform Encryption Considerations (opens in a new tab) และ Filter Encrypted Data with Deterministic Encryption (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Salesforce Help, Field History Tracking Overview (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Salesforce Help, Field Audit Trail (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Salesforce Help, Salesforce Event Monitoring Frequently Asked Questions (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)
• Salesforce Help, Secure Your Sandbox Data with Salesforce Data Mask (Legacy) (opens in a new tab) (ภาษาอังกฤษ ตรวจสอบเมื่อ 2026-10-14)