รูปแบบการให้บริการข้อมูลระดับองค์กรตาม scale

AWS Data sharing

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

ปัจจุบันก็มีผู้ให้บริการเช่น AWS ที่มีบริการ AWS Data Exchange ที่ช่วยเปิดช่องทางให้บริษัทต่าง ๆ สามารถแบ่งปันข้อมูลแก่บริษัทอื่น ๆ หรือสร้างรายได้จากข้อมูลเหล่านี้ และนอกเหนือจากนี้บางองค์กรยังต้องการแพลตฟอร์มการให้บริการข้อมูลที่จะสามารถสร้างแนวทางการทำงานแบบร่วมกัน (collaborative) และวิธีการทำงานเชิงกลยุทธ์ (strategic approach) ในการแลกเปลี่ยนข้อมูลกับกลุ่มบริษัทที่ถูกจำกัดด้วยการป้องกันทางด้าน security เช่น บริษัทที่ให้บริการทางการเงินและผู้สอบบัญชีหรือบริษัทผู้ผลิตและคู่ค้า supply chain โดยประโยชน์ของการใช้งานแพลตฟอร์มแบบนี้คือการส่งเสริมการพัฒนาผลิตภัณฑ์และบริการใหม่ ๆ และการช่วยปรับปรุงประสิทธิภาพการดำเนินงาน  

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

ตัวเลือกในการให้บริการข้อมูลและชนิดการจัดประเภทข้อมูล 

องค์กรใดก็ตามต่างต้องดำเนินการภายใต้นโยบายด้าน security ต่าง ๆ แม้ว่ามีความแตกต่างกันอยู่บ้างสำหรับแต่ละองค์กรก็ตาม สำหรับบางองค์กร เราสามารถใช้บริการของ AWS เช่น AWS Data Exchange แต่สำหรับองค์กรในอุตสาหกรรมที่มีการควบคุมอย่างเข้มงวด เช่น หน่วยงานของรัฐบาลกลางหรือผู้ให้บริการทางการเงิน บริการที่สามารถใช้ได้อาจถูกจำกัดด้วย allow list (ของตัวเลือกบริการของ AWS) เช่น หากองค์กรจำเป็นต้องทำงานในสภาพแวดล้อม Fedramp Medium หรือ Fedramp High ตัวเลือกในการแบ่งปันข้อมูลอาจถูกจำกัดให้มีเพียงบริการของ AWS ที่พร้อมใช้งานและอยู่ใน allow list เท่านั้น โดยความพร้อมใช้งานของบริการขึ้นอยู่กับการรับรองแพลตฟอร์มโดย AWS และการ allow list นั้นขึ้นอยู่กับการที่องค์กรที่กำหนดสถาปัตยกรรมและหลักเกณฑ์การปฏิบัติตามข้อกำหนดด้านความปลอดภัย

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

ชนิดการจัดประเภทข้อมูล:

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

ขอยกตัวอย่าง diagram และ solution ต่าง ๆ ในการตัดสินใจที่ทุกคนสามารถนำไปอ้างอิงได้หากต้องการเลือกตัวเลือกการให้บริการข้อมูล โดยจะมีการพิจารณาด้านความพร้อมให้บริการ, ชนิดการจัดประเภท, และรูปแบบข้อมูล (มีโครงสร้างหรือไม่มีโครงสร้าง) ส่วนปัจจัยอื่น ๆ เช่น ความสามารถในการใช้งาน, การเข้าถึงแบบ multi-partner, ขนาดข้อมูล, รูปแบบการใช้ เช่น bulk load/API access, และอื่น ๆ ก็อาจส่งผลต่อการเลือกรูปแบบการให้บริการข้อมูลได้เช่นเดียวกัน

Pattern 1: การใช้ AWS Data Exchange

AWS Data Exchange ทำให้การแลกเปลี่ยนข้อมูลง่ายขึ้น, ช่วยให้องค์กรลดต้นทุน, มีความคล่องตัวมากขึ้น, และสร้างนวัตกรรมได้รวดเร็วขึ้น โดยองค์กรสามารถเลือกที่จะให้บริการข้อมูลอย่างเป็นส่วนตัวโดยใช้ AWS Data Exchange กับคู่ค้าภายนอก ซึ่งตัว AWS Data Exchange จะเสนอการควบคุมขอบเขตที่สามารถใช้สำหรับ user ที่มี identity และทรัพยากร  และการควบคุมเหล่านี้จะตัดสินว่า external identities ใดที่สามารถเข้าถึงทรัพยากรข้อมูลเฉพาะได้ 

AWS Data Exchange มีรูปแบบต่าง ๆ มากมายสำหรับบุคคลภายนอกในการเข้าถึงข้อมูล เช่น ต่อไปนี้:

  • AWS Data Exchange สำหรับ Amazon Redshift
  • AWS Data Exchange สำหรับ AWS Lake Formation (ขณะนี้อยู่ใน preview)
  • AWS Data Exchange สำหรับ Data APIs
  • AWS Data Exchange สำหรับ data files
  • AWS Data Exchange สำหรับ Amazon S3 (ขณะนี้อยู่ใน preview)

ด้วย AWS Data Exchange เมื่อเรากำหนดค่าชุดข้อมูลที่จะให้บริการ (หรือขาย) แล้ว AWS Data Exchange จะจัดการการให้สิทธิ์ (และจัดการการเรียกเก็บเงิน) ระหว่างผู้ผลิตและผู้บริโภคโดยอัตโนมัติ ผู้ผลิตไม่จำเป็นต้องจัดการนโยบาย, ตั้งค่าจุดเชื่อมต่อใหม่, หรือสร้างการแชร์ข้อมูล Amazon Redshift ใหม่สำหรับผู้ใช้แต่ละราย, และจัดการการเข้าถึงด้วยตนเองเนื่องจากการเข้าถึงจะถูกเพิกถอนโดยอัตโนมัติหากการสมัครสมาชิกสิ้นสุดลง ซึ่งประโยชน์เหล่านี้สามารถลดค่าใช้จ่ายในการดำเนินการแบ่งปันข้อมูลได้อย่างมาก

Pattern 2: การใช้ AWS Lake Formation สำหรับการจัดการการเข้าถึงจากส่วนกลาง 

เราสามารถใช้แพทเทิร์นนี้ในกรณีที่ผู้ผลิตและผู้บริโภคใช้งานบริการของ AWS ทั้งคู่ ด้วยการใช้บัญชี AWS ที่ถูกเปิดใช้งานเพื่อใช้ AWS Lake Formation โดยแพทเทิร์นนี้ให้แนวทางแบบ no-code ในการแบ่งปันข้อมูล 

ในแพทเทิร์นนี้ บัญชีการกำกับดูแลส่วนกลางมีการกำหนดค่า Lake Formation สำหรับการจัดการการเข้าถึงทั่วทั้งบัญชีองค์กรของผู้ผลิต และลิงก์ทรัพยากรจาก production account bucket Amazon Simple Storage Service (Amazon S3) จะถูกสร้างขึ้นใน Lake Formation จากนั้น ผู้ผลิตจะมอบสิทธิ์การอนุญาต Lake Formation บนทรัพยากร AWS Glue Data Catalog ให้กับบัญชีภายนอกหรือให้โดยตรงกับ AWS Identity and Access Management (IAM) ในบัญชีอื่น และ Lake Formation จะใช้ AWS Resource Access Manager (AWS RAM) เพื่อแบ่งปันทรัพยากร โดยหากบัญชีผู้รับสิทธิ์อยู่ในองค์กรเดียวกับบัญชีผู้ให้สิทธิ์ ผู้รับสิทธิ์จะสามารถใช้ทรัพยากรที่ใช้ร่วมกันได้ทันที แต่สำหรับกรณีที่บัญชีผู้รับสิทธิ์ไม่ได้อยู่ในองค์กรเดียวกัน AWS RAM จะส่งคำเชิญไปยังบัญชีผู้รับสิทธิ์เพื่อยอมรับหรือปฏิเสธการให้ทรัพยากร และสำหรับในเรื่องของการทำให้ทรัพยากรที่ใช้ร่วมกันพร้อมใช้งานนั้น ผู้ดูแลผู้บริโภคในบัญชีผู้รับสิทธิ์ต้องใช้คอนโซล AWS RAM หรือ AWS Command Line Interface (AWS CLI) เพื่อตอบรับคำเชิญ

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

Pattern 3: การใช้ AWS Lake Formation จากบัญชีการแบ่งปันภายนอกของผู้ผลิต

ผู้ผลิตอาจมีข้อกำหนดด้านความปลอดภัยที่เข้มงวดมากเช่นการไม่ให้ผู้บริโภคภายนอกใดเข้าถึงบัญชีการผลิตหรือบัญชีการกำกับดูแลแบบรวมศูนย์ และยังอาจไม่ได้เปิดใช้งาน Lake Formation บนแพลตฟอร์มการผลิต ในกรณีดังกล่าว ตามที่เราแสดงในแผนภาพต่อไปนี้ บัญชีการผลิตของผู้ผลิต (บัญชี A) มีไว้สำหรับผู้ใช้ภายในองค์กร ขณะที่ผู้ผลิตจะสร้างบัญชีอื่น คือบัญชีการแชร์ภายนอกของผู้ผลิต (บัญชี B) ซึ่งมีไว้สำหรับการแชร์ภายนอกโดยเฉพาะ  ซึ่งนี่ทำให้ผู้ผลิตมีละติจูดมากขึ้นในการสร้างนโยบายอย่างเฉพาะสำหรับตัวองค์กรนั้น ๆ 

ผู้ผลิตลงมือทำกระบวนการเพื่อสร้างสำเนาข้อมูลแบบ asynchronous ในบัญชี B ซึ่ง bucket สามารถถูกกำหนดค่าสำหรับ Same Region Replication (SRR) หรือ Cross Region Replication (CRR) สำหรับ object ที่ต้องการแบ่งปัน ซึ่งนี่จะอำนวยความสะดวกในการรีเฟรชข้อมูลโดยอัตโนมัติไปยังบัญชีภายนอก ไปยัง bucket  S3 “External Published Datasets” โดยไม่ต้องเขียนโค้ดใดๆ

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

Lake Formation จะถูกตั้งค่าบนบัญชี B และผู้ดูแลระบบจะสร้างลิงก์ทรัพยากรสำหรับ bucket  S3 “External Published Datasets” ในบัญชีของตนเพื่อให้สิทธิ์การเข้าถึง โดยผู้ดูแลระบบทำตามขั้นตอนเดิมตามที่อธิบายไว้ก่อนหน้านี้เพื่อให้สิทธิ์การเข้าถึง

Pattern 4: การใช้การให้บริการข้อมูลของ Amazon Redshift 

แพทเทิร์นนี้เหมาะอย่างยิ่งสำหรับผู้ผลิตที่มีผลิตภัณฑ์ข้อมูลที่เผยแพร่ส่วนใหญ่ใน Amazon Redshift และแพทเทิร์นนี้ยังกำหนดให้บัญชีการแบ่งปันภายนอกของผู้ผลิต (บัญชี B) และบัญชีผู้บริโภค (บัญชี C) มีคลัสเตอร์ Amazon Redshift ที่เข้ารหัสหรือ serverless endpoint ของ Amazon Redshift ที่ตรงตามข้อกำหนดเบื้องต้นสำหรับการแบ่งปันข้อมูลของตัว Amazon Redshift เอง

มีตัวเลือกอยู่สองทาง ขึ้นอยู่กับข้อจำกัดการปฏิบัติตามข้อกำหนดของผู้ผลิต:

  • ตัวเลือก A: ผู้ผลิตเปิดใช้งานการแชร์ข้อมูลโดยตรงบนคลัสเตอร์ Amazon Redshift ที่ใช้งานจริง
  • ตัวเลือก B: ผู้ผลิตอาจมีข้อจำกัดเกี่ยวกับการแบ่งปันคลัสเตอร์การผลิต ผู้ผลิตสามารถสร้าง job ของ AWS Glue อย่างง่ายที่คัดลอกข้อมูลจากคลัสเตอร์ Amazon Redshift ในบัญชี A ที่ใช้งานจริงไปยังคลัสเตอร์ Amazon Redshift ในบัญชี B ภายนอก งาน AWS Glue นี้สามารถถูกกำหนดเวลาเพื่อรีเฟรชข้อมูลได้ตามต้องการโดยผู้บริโภค  เมื่อมีข้อมูลอยู่ในบัญชี B แล้ว ผู้ผลิตจะสามารถสร้าง view ได้หลายอันและสามารถแบ่งปันข้อมูลได้หลายรายการตามที่ต้องการ

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

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

Pattern 5: การให้บริการข้อมูลอย่างปลอดภัยและเป็นส่วนตัวโดยใช้ API

หากคู่ค้าภายนอกไม่ใช้ AWS หรือหากผลิตภัณฑ์ข้อมูลที่เผยแพร่กระจายอยู่ในบริการต่างๆ เช่น Amazon S3, Amazon Redshift, Amazon DynamoDB และ Amazon OpenSearch Service แต่ผู้ผลิตต้องการรักษาอินเทอร์เฟซการแชร์ข้อมูลเดียว เราก็สามารถใช้แพทเทิร์นนี้ได้

ตัวอย่าง use case: บริษัท A มีความต้องการแชร์ log data บางส่วนในแบบเกือบ real-time กับบริษัท B ที่เป็นพาร์ทเนอร์ซึ่งใช้ข้อมูลนี้เพื่อสร้างข้อมูลเชิงลึกอย่างคาดการณ์สำหรับบริษัท A และบริษัท A ได้ทำการจัดเก็บข้อมูลนี้ไว้ใน Amazon Redshift โดยมีความต้องการที่จะแบ่งปันข้อมูลการทำธุรกรรมนี้กับพาร์ทเนอร์หลังจากปกปิดข้อมูลที่สามารถระบุตัวบุคคลได้ (PII) ด้วยวิธีที่คุ้มค่าและปลอดภัยในการสร้างข้อมูลเชิงลึก ส่วนทางบริษัท B นั้นไม่มีการใช้บริการของ AWS

บริษัท A สร้างกระบวนการ microbatch โดยใช้ฟังก์ชัน AWS Lambda หรือ AWS Glue ที่สอบถาม Amazon Redshift เพื่อรับ log data ที่เพิ่มขึ้น, ใช้กฎเพื่อตรวจแก้ไข PII, และโหลดข้อมูลนี้ไปยัง bucket  S3 “Published Datasets” สิ่งนี้สร้างตัวอย่างของกระบวนการ SRR/CRR ที่รีเฟรชข้อมูลนี้ใน bucket  S3 “การแบ่งปันภายนอก”

workflow ประกอบด้วยขั้นตอนต่อไปนี้:

  1. คำขอ HTTPS API ถูกส่งจากผู้ใช้ API ไปยัง API proxy layer
  2. คำขอ HTTPS API ถูกส่งต่อจาก API proxy ไปยัง Amazon API Gateway ในบัญชี AWS ที่แชร์ภายนอก
  3. Amazon API Gateway เรียกใช้ฟังก์ชันตัวรับคำขอ Lambda
  4. ฟังก์ชันตัวรับคำขอเขียนสถานะไปยังตารางควบคุม DynamoDB
  5. ฟังก์ชัน Lambda ที่สอง หรือ poller ตรวจสอบสถานะของผลลัพธ์ในตาราง DynamoDB
  6. ฟังก์ชัน poller ดึงผลลัพธ์จาก Amazon S3
  7. ฟังก์ชันโพลเลอร์จะส่ง URL ที่กำหนดไว้ล่วงหน้าเพื่อดาวน์โหลดไฟล์จาก bucket  S3 ไปยังผู้ร้องขอผ่าน Amazon Simple Email Service (Amazon SES)
  8. The AWS Transit Gateway security egress VPC routing table only allows connectivity from the required producer’s subnet, while preventing internet access.
  9. ผู้ร้องขอดาวน์โหลดไฟล์โดยใช้ URL
  10. บัญชี network perimeter AWS ให้การอนุญาตเฉพาะการเชื่อมต่ออินเทอร์เน็ตขาออก
  11. API proxy layer บังคับใช้ทั้งการควบคุมความปลอดภัยขาออกและ perimeter firewall ก่อนที่ traffic จะออกจาก network perimeter ของผู้ผลิต
  12. ตารางการกำหนดเส้นทาง VPC ขาออกของความปลอดภัยของ AWS Transit Gateway อนุญาตให้มีการเชื่อมต่อจากเครือข่ายย่อยของผู้ผลิตที่จำเป็นเท่านั้น ในขณะที่ป้องกันการเข้าถึงอินเทอร์เน็ต

Pattern 6: การใช้ Amazon S3 access points

แพทเทิร์นนี้กล่าวถึงวิธีการแบ่งปันเอกสาร อาจเป็นเมื่อเช่นนักวิทยาศาสตร์ข้อมูลจำเป็นต้องทำงานร่วมกันด้านรูปภาพ, วิดีโอ, และเอกสาร หรือเช่นหากกลุ่มกฎหมายและการตรวจสอบต้องการแบ่งปันรายงานและแถลงการณ์กับหน่วยงานตรวจสอบ โดยแพทเทิร์นนี้จะถือว่าคู่ค้าภายนอกอยู่บน AWS ด้วย ซึ่ง access point ของ Amazon S3 สามารถช่วยให้ผู้ผลิตแบ่งปันการเข้าถึงกับผู้บริโภคของตนโดยตั้งค่าการเข้าถึงแบบข้ามบัญชีโดยไม่ต้องแก้ไข bucket policy ต่าง ๆ

access point คือชื่อของ network endpoint ที่เชื่อมต่อกับ bucket ที่คุณสามารถใช้เพื่อดำเนินการกับ S3 objects เช่น GetObject และ PutObject ซึ่งจุดเชื่อมต่อแต่ละจุดมีสิทธิ์และการควบคุมเครือข่ายที่แตกต่างกันซึ่ง Amazon S3 จะนำไปใช้กับคำขอใด ๆ ที่ทำผ่านจุดเชื่อมต่อนั้น  จุดเชื่อมต่อแต่ละจุดบังคับใช้นโยบายจุดเชื่อมต่อแบบกำหนดเองที่ทำงานร่วมกับ bucket policy ที่แนบมากับ bucket พื้นฐาน

ผู้ผลิตสร้าง bucket S3 และเปิดใช้งานการใช้จุดเชื่อมต่อ และผู้ผลิตยังต้องระบุบัญชีผู้บริโภค, บทบาท IAM, และสิทธิ์สำหรับบทบาท IAM ของผู้บริโภค ซึ่งนี่นับเป็นส่วนหนึ่งของการกำหนดค่า 

ผู้บริโภคที่มีบทบาท IAM ในบัญชีผู้บริโภคสามารถเข้าถึง bucket S3 ผ่านอินเทอร์เน็ตหรือถูกจำกัดไว้ที่ Amazon VPC ผ่าน VPC endpoints และ AWS PrivateLink

สรุป

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

About Author