ตรวจจับ มาสก์ และแก้ไขข้อมูล PII โดยใช้ AWS Glue ก่อนที่จะโหลดลงใน Amazon OpenSearch Service | อเมซอนเว็บเซอร์วิส

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

ด้วยความสามารถในการเคลื่อนที่อย่างรวดเร็วบน AWS คุณจะต้องรับผิดชอบต่อข้อมูลที่คุณได้รับและประมวลผลเมื่อคุณขยายขนาดต่อไป ความรับผิดชอบเหล่านี้รวมถึงการปฏิบัติตามกฎหมายและข้อบังคับความเป็นส่วนตัวของข้อมูล และไม่จัดเก็บหรือเปิดเผยข้อมูลที่ละเอียดอ่อน เช่น ข้อมูลที่สามารถระบุตัวบุคคลได้ (PII) หรือข้อมูลด้านสุขภาพที่ได้รับการคุ้มครอง (PHI) จากแหล่งที่มาต้นทาง

ในโพสต์นี้ เราจะอธิบายเกี่ยวกับสถาปัตยกรรมระดับสูงและกรณีการใช้งานเฉพาะที่แสดงให้เห็นว่าคุณสามารถปรับขนาดแพลตฟอร์มข้อมูลขององค์กรของคุณต่อไปได้อย่างไร โดยไม่จำเป็นต้องใช้เวลาในการพัฒนาจำนวนมากเพื่อจัดการกับข้อกังวลด้านความเป็นส่วนตัวของข้อมูล เราใช้ AWS กาว เพื่อตรวจจับ มาสก์ และตรวจทานข้อมูล PII ก่อนที่จะโหลดเข้าไป บริการ Amazon OpenSearch.

ภาพรวมโซลูชัน

แผนภาพต่อไปนี้แสดงสถาปัตยกรรมโซลูชันระดับสูง เราได้กำหนดเลเยอร์และส่วนประกอบทั้งหมดของการออกแบบของเราให้สอดคล้องกับ เลนส์วิเคราะห์ข้อมูลกรอบงาน AWS Well-Architected.

สถาปัตยกรรมประกอบด้วยองค์ประกอบหลายประการ:

แหล่งที่มาของข้อมูล

ข้อมูลอาจมาจากหลายสิบถึงหลายร้อยแหล่ง รวมถึงฐานข้อมูล การถ่ายโอนไฟล์ บันทึก แอปพลิเคชันซอฟต์แวร์เป็นบริการ (SaaS) และอื่นๆ องค์กรอาจไม่สามารถควบคุมข้อมูลที่ส่งผ่านช่องทางเหล่านี้และเข้าสู่พื้นที่จัดเก็บข้อมูลและแอปพลิเคชันดาวน์สตรีมได้เสมอไป

การกลืนกิน: แบทช์ Data Lake, ไมโครแบทช์ และการสตรีม

องค์กรหลายแห่งนำข้อมูลต้นฉบับไปไว้ใน Data Lake ด้วยวิธีต่างๆ มากมาย รวมถึงงานแบบแบตช์ ไมโครแบตช์ และงานสตรีมมิ่ง ตัวอย่างเช่น, อเมซอน EMR, AWS กาวและ บริการย้ายฐานข้อมูล AWS (AWS DMS) ทั้งหมดสามารถใช้เพื่อดำเนินการแบบแบตช์และหรือการสตรีมที่จมลงสู่ Data Lake บริการจัดเก็บข้อมูลอย่างง่ายของ Amazon (อเมซอน เอส3). Amazon App Flow สามารถใช้เพื่อถ่ายโอนข้อมูลจากแอปพลิเคชัน SaaS ต่างๆ ไปยัง Data Lake AWS DataSync และ กลุ่มการถ่ายโอน AWS สามารถช่วยในการย้ายไฟล์เข้าและออกจาก Data Lake ผ่านโปรโตคอลที่แตกต่างกันจำนวนหนึ่ง อเมซอน Kinesis และ Amazon MSK ยังมีความสามารถในการสตรีมข้อมูลโดยตรงไปยัง Data Lake บน Amazon S3

ทะเลสาบข้อมูล S3

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

ในสถาปัตยกรรมนี้ ข้อมูลดิบสามารถมาจากแหล่งที่มาต่างๆ (ภายในและภายนอก) ซึ่งอาจมีข้อมูลที่ละเอียดอ่อน

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

บริบททางธุรกิจและชุดข้อมูล

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

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

ชื่อคอลัมน์ดิบ	ชื่อคอลัมน์ที่ดูแลจัดการ	ชนิดภาพเขียน
c0	ชื่อจริง	เชือก
c1	นามสกุล	เชือก
c2	เอสเอสเอ็น	เชือก
c3	ที่อยู่	เชือก
c4	รหัสไปรษณีย์	เชือก
c5	ประเทศ	เชือก
c6	buy_site	เชือก
c7	หมายเลขบัตรเครดิต	เชือก
c8	credit_card_provider	เชือก
c9	เงินตรา	เชือก
c10	buy_value	จำนวนเต็ม
c11	ธุรกรรม_วันที่	ข้อมูล
c12	หมายเลขโทรศัพท์	เชือก
c13	อีเมล	เชือก
c14	ipv4	เชือก

กรณีการใช้งาน: การตรวจจับชุด PII ก่อนที่จะโหลดไปยัง OpenSearch Service

ลูกค้าที่ใช้สถาปัตยกรรมต่อไปนี้ได้สร้าง Data Lake ของตนบน Amazon S3 เพื่อเรียกใช้การวิเคราะห์ประเภทต่างๆ ในวงกว้าง โซลูชันนี้เหมาะสำหรับลูกค้าที่ไม่ต้องการนำเข้า OpenSearch Service แบบเรียลไทม์ และวางแผนที่จะใช้เครื่องมือบูรณาการข้อมูลที่ทำงานตามกำหนดเวลาหรือถูกทริกเกอร์ผ่านเหตุการณ์ต่างๆ

ก่อนที่บันทึกข้อมูลจะลงสู่ Amazon S3 เราจะใช้เลเยอร์การนำเข้าเพื่อนำสตรีมข้อมูลทั้งหมดไปยัง Data Lake อย่างเชื่อถือได้และปลอดภัย Kinesis Data Streams ได้รับการปรับใช้เป็นเลเยอร์การนำเข้าเพื่อเร่งการรับสตรีมข้อมูลที่มีโครงสร้างและกึ่งโครงสร้าง ตัวอย่างของสิ่งเหล่านี้คือการเปลี่ยนแปลงฐานข้อมูลเชิงสัมพันธ์ แอปพลิเคชัน บันทึกของระบบ หรือคลิกสตรีม สำหรับกรณีการใช้งาน Change Data Capture (CDC) คุณสามารถใช้ Kinesis Data Streams เป็นเป้าหมายสำหรับ AWS DMS ได้ แอปพลิเคชันหรือระบบที่สร้างสตรีมที่มีข้อมูลที่ละเอียดอ่อนจะถูกส่งไปยังสตรีมข้อมูล Kinesis ผ่านหนึ่งในสามวิธีที่รองรับ: Amazon Kinesis Agent, AWS SDK สำหรับ Java หรือ Kinesis Producer Library เป็นขั้นตอนสุดท้าย สายไฟ Amazon Kinesis Data ช่วยให้เราสามารถโหลดชุดข้อมูลแบบเกือบจะเรียลไทม์ไปยังปลายทาง Data Lake ของ S3 ของเราได้อย่างน่าเชื่อถือ

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

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

หลังจากที่ข้อมูลถูกรวบรวมและนำเข้าไปยัง Kinesis Data Streams และส่งมอบไปยังบัคเก็ต S3 โดยใช้ Kinesis Data Firehose เลเยอร์การประมวลผลของสถาปัตยกรรมจะเข้ามาแทนที่ เราใช้การแปลง AWS Glue PII เพื่อตรวจจับและมาสก์ข้อมูลที่ละเอียดอ่อนในไปป์ไลน์ของเราโดยอัตโนมัติ ดังที่แสดงในแผนภาพเวิร์กโฟลว์ต่อไปนี้ เราใช้แนวทาง ETL แบบเห็นภาพและไม่ต้องเขียนโค้ดเพื่อใช้งานการเปลี่ยนแปลงของเราใน AWS Glue Studio

ขั้นแรก เราเข้าถึงตาราง Data Catalog ต้นฉบับจาก pii_data_db ฐานข้อมูล ตารางมีโครงสร้างสคีมาที่นำเสนอในส่วนก่อนหน้า เพื่อติดตามข้อมูลดิบที่ประมวลผล เราใช้ ที่คั่นหน้างาน.

เราใช้ สูตร AWS Glue DataBrew ในงาน ETL ภาพของ AWS Glue Studio เพื่อแปลงแอตทริบิวต์วันที่สองรายการให้เข้ากันได้กับ OpenSearch ที่คาดหวัง รูปแบบ. สิ่งนี้ทำให้เรามีประสบการณ์ที่ไม่มีโค้ดเต็มรูปแบบ

เราใช้การดำเนินการ Detect PII เพื่อระบุคอลัมน์ที่ละเอียดอ่อน เราปล่อยให้ AWS Glue พิจารณาสิ่งนี้ตามรูปแบบที่เลือก เกณฑ์การตรวจจับ และส่วนตัวอย่างของแถวจากชุดข้อมูล ในตัวอย่างของเรา เราใช้รูปแบบที่ใช้กับสหรัฐอเมริกาโดยเฉพาะ (เช่น SSN) และอาจตรวจไม่พบข้อมูลที่ละเอียดอ่อนจากประเทศอื่น คุณอาจค้นหาหมวดหมู่และตำแหน่งที่ใช้ได้กับกรณีการใช้งานของคุณ หรือใช้นิพจน์ทั่วไป (regex) ใน AWS Glue เพื่อสร้างเอนทิตีการตรวจจับสำหรับข้อมูลที่ละเอียดอ่อนจากประเทศอื่นๆ

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

การดำเนินการตรวจหา PII ช่วยให้คุณสามารถเลือกสตริงเริ่มต้นเมื่อมาสก์ข้อมูลที่ละเอียดอ่อนได้ ในตัวอย่างของเรา เราใช้สตริง ********

เราใช้การดำเนินการใช้การแมปเพื่อเปลี่ยนชื่อและลบคอลัมน์ที่ไม่จำเป็นเช่น ingestion_year, ingestion_monthและ ingestion_day. ขั้นตอนนี้ยังช่วยให้เราสามารถเปลี่ยนประเภทข้อมูลของคอลัมน์ใดคอลัมน์หนึ่งได้ (purchase_value) จากสตริงเป็นจำนวนเต็ม

จากจุดนี้ไป งานจะแบ่งออกเป็นปลายทางเอาต์พุตสองปลายทาง: OpenSearch Service และ Amazon S3

คลัสเตอร์บริการ OpenSearch ที่จัดเตรียมไว้ของเราเชื่อมต่อผ่าน ตัวเชื่อมต่อในตัว OpenSearch สำหรับกาว. เราระบุดัชนี OpenSearch ที่เราต้องการเขียน และตัวเชื่อมต่อจะจัดการข้อมูลรับรอง โดเมน และพอร์ต ในภาพหน้าจอด้านล่าง เราเขียนไปยังดัชนีที่ระบุ index_os_pii.

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

สำหรับการกำกับดูแลแบบรวมศูนย์ การควบคุมการเข้าถึง และเส้นทางการตรวจสอบของชุดข้อมูลและตาราง Data Catalog ทั้งหมด คุณสามารถใช้ได้ การก่อตัวของทะเลสาบ AWS. สิ่งนี้ช่วยให้คุณจำกัดการเข้าถึงตาราง AWS Glue Data Catalog และข้อมูลพื้นฐานเฉพาะผู้ใช้และบทบาทที่ได้รับสิทธิ์ที่จำเป็นในการดำเนินการดังกล่าว

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

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

สำหรับวิธีอื่นในการโหลดข้อมูลลงใน Amazon OpenSearch โปรดดูที่ กำลังโหลดข้อมูลการสตรีมลงใน Amazon OpenSearch Service.

นอกจากนี้ ข้อมูลที่ละเอียดอ่อนยังสามารถค้นพบและปกปิดได้โดยใช้โซลูชัน AWS อื่นๆ ตัวอย่างเช่น คุณสามารถใช้ อเมซอน แม็กกี้ เพื่อตรวจจับข้อมูลที่ละเอียดอ่อนภายในบัคเก็ต S3 จากนั้นจึงใช้งาน เข้าใจ Amazon เพื่อแก้ไขข้อมูลที่ละเอียดอ่อนที่ถูกตรวจพบ สำหรับข้อมูลเพิ่มเติม โปรดดูที่ เทคนิคทั่วไปในการตรวจจับข้อมูล PHI และ PII โดยใช้บริการของ AWS.

สรุป

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

---

เกี่ยวกับผู้แต่ง

Michael Hamilton เป็นสถาปนิกโซลูชันการวิเคราะห์อาวุโสที่มุ่งเน้นที่การช่วยเหลือลูกค้าระดับองค์กรในการปรับให้ทันสมัยและลดความซับซ้อนของปริมาณงานการวิเคราะห์บน AWS เขาสนุกกับการปั่นจักรยานเสือภูเขาและใช้เวลากับภรรยาและลูกสามคนเมื่อไม่ได้ทำงาน

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

• เนื้อหาที่ขับเคลื่อนด้วย SEO และการเผยแพร่ประชาสัมพันธ์ รับการขยายวันนี้
• PlatoData.Network Vertical Generative Ai เพิ่มพลังให้กับตัวเอง เข้าถึงได้ที่นี่.
• เพลโตไอสตรีม. Web3 อัจฉริยะ ขยายความรู้ เข้าถึงได้ที่นี่.
• เพลโตESG. คาร์บอน, คลีนเทค, พลังงาน, สิ่งแวดล้อม แสงอาทิตย์, การจัดการของเสีย. เข้าถึงได้ที่นี่.
• เพลโตสุขภาพ เทคโนโลยีชีวภาพและข่าวกรองการทดลองทางคลินิก เข้าถึงได้ที่นี่.
• ที่มา: https://aws.amazon.com/blogs/big-data/detect-mask-and-redact-pii-data-using-aws-glue-before-loading-into-amazon-opensearch-service/