AWS Thai Blog

พัฒนา Serverless solution สำหรับการปกปิดข้อมูลที่ละเอียดอ่อน

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

บทความนี้แปลมาจาก Building a serverless tokenization solution to mask sensitive data โดย Anuj Gupta, Senior Solutions Architect, and Steven David, Senior Solutions Architect

Security และ Compliance เป็นเรื่องที่สำคัญเป็นอันดับต้น ๆ สำหรับผู้ใช้งานทุก ๆ คน ไม่ว่าจะอยู่ในอุตสาหกรรมรูปแบบไหน กฏระเบียบ และข้อบังคับใช้ต่าง ๆ ถูกปรับปรุงอย่างสม่ำเสมอ ทำให้ทุก ๆ องค์กรต้องปรับตัวด้วยความรวดเร็วตลอดเวลา โดยยังคงสามารถปฏิบัติตามกฏระเบียบได้อย่างถูกต้อง แม้ว่าการใช้งานข้อมูลเพื่อส่งเสริมในการสร้างมูลค่าเพิ่มเติมให้องค์กรจะเป็นสิ่งจำเป็น แต่องค์กรจำเป็นต้องให้ความสำคัญในการรักษาความลับ และความเป็นส่วนตัวของข้อมูลที่ใช้งานอยู่ไปด้วย และในหลาย ๆ สถานการณ์ การปกปิด (Obfuscation) หรือการเข้ารหัส (Encryption) ข้อมูลนั้นก็มีความสำคัญเช่นเดียวกัน เพื่อป้องกันข้อมูลที่รั่วไหลออกไปภายนอก แต่ยังคงความสามารถในการพัฒนา และเติบโตไปได้พร้อม ๆ กัน

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

เปรียบเทียบระหว่าง Tokenization และ Encryption

Tokenization และ Encryption นั้นมีความแตกต่างกัน โดยที่ Encryption คือการทำงานของ Algorithm เพื่อทำการแปลงข้อมูลให้อยู่ในรูปแบบที่ไม่สามารถเข้าอ่าน หรือทำความเข้าใจได้โดยตรง เช่นจาก Plaintext (ข้อความเปล่า ๆ ที่สามารถอ่านทำความเข้าใจได้) ไปสู่ Ciphertext (ข้อความที่ถูกเข้ารหัส ไม่สามารถอ่านได้โดยตรง) รวมทั้งการเข้ารหัสนั้นจำเป็นต้องมี Algorithm และ Encryption key ซึ่งถูกใช้สำหรับการเข้ารหัส และการถอดรหัส

Tokenization คือการแปลงข้อมูลให้กลายเป็นชุดของตัวอักษรแบบสุ่มที่ไม่มีความหมาย ไม่สามารถเข้าใจได้ และไม่สามารถถูกแปลงย้อนกลับไปยังข้อมูลต้นฉบับได้ โดยชุดของตัวอักษรเหล่านี้จะถูกเรียกว่า Token

อีกหนึ่งความแตกต่างระหว่าง Encryption และ Tokenization คือ Tokenization ไม่ได้มีการใช้กระบวนการทางคณิตศาสตร์ในการแปลงข้อมูลให้กลายเป็น Token โดยที่ Tokenization เป็นการใช้งานฐานข้อมูล หรือ Token Vault ซึ่งถูกใช้เป็นที่เก็บความสัมพันธ์ระหว่างข้อมูลต้นฉบับ และ Token โดยวิธีการนี้จะทำให้ข้อมูลที่อ่อนไหวจะได้รับการเข้ารหัส และถูกเก็บไว้ที่ Vault และ Token จะถูกใช้งานโดย Applications แทนการใช้งานข้อมูลต้นฉบับเดิมโดยตรง

ยกตัวอย่างเช่น การประมวลผลการจ่ายเงินด้วยบัตรเครดิต Token จะถูกส่งไปยัง Vault เพื่อทำการเรียกใช้ข้อมูลต้นฉบับสำหรับขั้นตอนการชำระเงินของบัตรเครดิต (Authorization process) และในปัจจุบัน Token ยังถูกใช้ในการปกป้องข้อมูลที่อ่อนไหว หรือ ข้อมูลส่วนบุคคล เช่น เลขบัตรประจำตัว เบอร์โทรศัพท์ และอีเมลล์

ภาพรวม

ในบล็อกนี้ เราจะแสดงให้เห็นถึงวิธีการออกแบบโซลูชั่น Tokenization ที่มีความปลอดภัย (Secured) น่าเชื่อถือ (Reliable) รองรับการขยายตัว (Scalable) และมีราคาที่เหมาะสม (Cost Optimized) โดยโซลูชั่นนี้สามารถนำไปใช้งานกับ Applications เพื่อสร้าง Tokens, การเก็บข้อมูลที่ถูกเข้ารหัสไว้ใน Vault, และ การแลกเปลี่ยน Token เพื่อเรียกใช้ข้อมูลต้นฉบับออกมาใช้งาน

ในตัวอย่างนี้จะประกอบไปด้วย Data Analyst ที่ต้องการเข้าถึงข้อมูลของลูกค้าในฐานข้อมูล โดยในฐานข้อมูลประกอบไปด้วย ชื่อ, เลขบัตรประจำตัว, เลขบัตรเครดิต, ข้อมูลคำสั่งซื้อ, และ การตั้งค่า โดยข้อมูลบางส่วนนั้นเป็นข้อมูลที่อ่อนไหว และเพื่อที่จะป้องกันข้อมูลไม่ให้ถูกเข้าถึงโดยผู้ที่ไม่ได้รับอนุญาต เราจึงต้องการ Information Security Policy หรือวิธีการในการควบคุมการเข้าถึงข้อมูล เช่น Column level access, Role-based control, และ Column level encryption

การให้สิทธิ์ในการเข้าถึงข้อมูลของลูกค้า ทำให้การจัดการบริหารการเข้าถึงข้อมูลแบบละเอียด (Fine-grained access) มีความซับซ้อนมากยิ่งขึ้น ดังนั้น Tokenization ที่จะเข้ามาแทนที่การเข้าถึงข้อมูลโดยตรง จะช่วยลดความซับซ้อนและค่าใช้จ่ายในการจัดการได้ดียิ่งขึ้น รวมทั้งช่วยในการป้องกันข้อมูลเช่นเดียวกัน

เริ่มต้นใช้งาน

โดยใน Serverless application นี้ประกอบไปด้วย Amazon API Gateway, AWS Lambda, Amazon Cognito, Amazon DynamoDB, และ AWS KMS

ผู้ใช้งานทำการยืนยันตัวตนผ่าน Amazon Cognito และได้รับ Authorization Token กลับมา โดย Token นี้จะถูกใช้งานเพื่อเช็คสิทธิในการเรียกใช้ Customer Order Lambda function และตัว function จะเรียกใช้งาน Tokenization Layer พร้อมกับส่งข้อมูลที่อ่อนไหวไปพร้อมกับ Request โดยใน Layer นี้จะมีหน้าที่ในการสร้าง Token ทำการเข้ารหัสข้อมูลต้นฉบับ และ เก็บข้อมูลลงใน Vault

Lambda จะได้รับ Encryption Key มาจาก KMS หลังจากนั้น DynamoDB client-side encryption library จะถูกใช้งานสำหรับการเข้ารหัสของข้อมูลต้นฉบับ และส่งไปเก็บไว้ใน Vault จากนั้น Lambda จะทำการเรียกใช้ Token จาก Response ที่ถูกสร้างขึ้นจาก Tokenization Layer และตัว Token จะถูกเก็บลงในฐานข้อมูลเพื่อใช้งานต่อไป

KMS ช่วยให้การสร้างและจัดการ Cryptographic Keys ง่ายยิ่งขึ้น รวมทั้งมาพร้อมกับ Logs ที่บันทึกทุก ๆ การใช้งานของการเข้าถึงกุญแจ ซึ่งช่วยให้คุณสามารถปฏิบัติตาม Regulatory และ Compliance ที่สอดคล้องได้

หนึ่งในสิ่งที่สำคัญที่สุดในการใช้งาน DynamoDB Encryption Client คือการเลือกใช้ Cryptographic Materials Provider (CMP) โดย CMP เป็นตัวกำหนดว่าขั้นการเข้ารหัส, Algorithm และ Signing Key จะถูกสร้างขึ้นมาได้อย่างไร ไม่ว่าจะเป็นการสร้าง Key materials ขึ้นใหม่สำหรับแต่ละ Item หรือจะใช้แชร์ร่วมกัน สำหรับการเลือกใช้งาน CMP สามารถดูเพิ่มเติมได้ที่ Documentation นี้

ในโซลูชั่นนี้จะใช้งาน Direct KMS Provider สำหรับ CMP โดยที่ Cryptographic Materials Provider นี้จะสร้าง Encryption Key และ Signing Key ที่มีลักษณะเฉพาะให้กับทุก ๆ Item ซึ่งวิธีการนี้เป็นการเรียก KMS ทุก ๆ ครั้งที่มีการเข้ารหัส หรือ ถอดรหัสข้อมูล Item นั้น ๆ

  • สำหรับการสร้าง Encryption Materials ขึ้นมา Direct KMS Provider จะเรียกใช้งาน AWS KMS เพื่อสร้าง Key ที่มีลักษณะเฉพาะให้แต่ละ Item ด้วยการใช้ Customer Master Key (CMK) ที่ระบุไว้ เพื่อเรียกใช้งาน Encryption และ Signing Keys จากสำเนา Plaintext ของ Data Key จากนั้นก็จะส่งค่ากลับมาด้วย Encryption และ Signing Keys รวมถึง Encrypted Data Key ที่ถูกเก็บไว้ที่ Material Description Attribute ของ Item นั้น ๆ
  • Item Encryptor จะใช้ Encryption และ Signing Keys และลบออกจาก Memory ทันทีที่เป็นไปได้หลังจากใช้งานเสร็จ คงเหลือไว้แค่ สำเนาของ Encrypted Data Key ที่ถูกเข้ารหัสไว้
  • สำหรับการสร้าง Decryption Materials ขึ้นมา Direct KMS Provider จะเรียกใช้งาน AWS KMS เพื่อถอดรหัส Encrypted Data Key จากนั้นจะทำการยืนยัน และเรียกใช้งาน Signing keys จาก Plaintext Data Key และส่งกลับไปยัง Item Encryptor

Item Encryptor ช่วยตรวจสอบความถูกต้องของ Item และถ้าสามารถตรวจสอบได้ถูกต้อง ก็จะทำการถอดรหัสข้อมูลออกมา และสุดท้ายก็จะลบ Keys ที่ใช้งานอยู่ออกจาก Memory ทันทีที่เป็นไปได้

และเพื่อทำให้ระบบมีความปลอดภัยมากขึ้น ในตัวอย่างนี้ Lambda function ถูกสร้างให้อยู่ภายใน VPC และมี Security Group ที่ช่วยในการจัดการข้อมูล HTTPS traffic ขาเข้า ให้สามารถผ่านได้เฉพาะ Private IPs เท่านั้น รวมถึง Lambda function ยังต่อไปยัง DynamoDB และ KMS ผ่าน VPC Endpoints แทนการวิ่งออกผ่านอินเทอร์เน็ต โดยใช้งาน Service Gateway Endpoint สำหรับ DynamoDB และ Interface Endpoint สำหรับ KMS ที่ช่วยในเรื่อง Highly available และความปลอดภัยในการเชื่อมต่อ

นอกเหนือจากนั้น เรายังสามารถกำหนด Policies สำหรับ VPC Endpoints เพื่ออนุญาตเฉพาะบาง Operation เท่านั้น ที่สามารถต่อไปยัง KMS และ DynamoDB ยิ่งไปกว่านั้น เรายังสามารถควบคุมการจัดการของ Encryption Keys ได้ โดยที่เราสามารถกำหนด Resource-based Policy ให้กับ KMS Master Key ซึ่งทำให้ Lambda Layer สามารถสร้าง Data Keys สำหรับการเข้ารหัส การถอดรหัส รวมถึงการจำกัดการเข้าถึง Master Key ได้อีกด้วย

สำหรับการ Deploy โซลูชั่นนี้ สามารถทำตามขั้นตอนได้ตามลิงก์ GitHub นี้ aws-serverless-tokenization โดยการใช้งาน AWS Serverless Application Model (AWS SAM) จะช่วยให้คุณสามารถ Deploy โซลูชั่นนี้บนบัญชี AWS ของคุณได้รวดเร็วยิ่งขึ้น

เข้าใจการทำงานของ Code

โซลูชั่นนี้มีการใช้งาน tokenizer package ที่ถูก Deploy ไว้บน Lambda Layer ซึ่งเป็นการใช้ Python UUID4 สำหรับการสร้าง UUID แบบสุ่ม หรือ ถ้าหากต้องการใช้งาน Tokenization ของตัวเอง ก็สามารถแก้ไขไฟล์ hash_gen.py เพื่อแก้ไข Logic ใหม่ได้ ยกตัวอย่างเช่น คุณสามารถสร้าง Tokens ที่มีขนาดเท่ากันกับข้อมูลต้นฉบับได้เช่นกัน

ไฟล์ ddb_encrypt_item.py ประกอบไปด้วย Logic สำหรับการเข้ารหัส DynamoDB items และการใช้งาน DynamoDB client-side encryption library หากต้องการข้อมูลเพิ่มเติมว่า Library ตัวนี้ทำงานยังไง สามารถดูเพิ่มเติมได้ที่ Documentation นี้

ภายใน Application Logic ประกอบไปด้วย 3 Methods หลัก

  • Encrypt_item สำหรับการเข้ารหัสข้อมูลผ่านการใช้งาน KMS customer managed key โดยในส่วนของ AttributeActions คุณสามารถระบุได้ว่าไม่ต้องการให้เข้ารหัสข้อมูลในส่วนไหน ยกตัวอย่างเช่น หากไม่ต้องการเข้ารหัส field ที่เป็น JSON ก็สามารถระบุเข้าไปได้ นอกจากนั้น Table ใน DynamoDB นั้นต้องมี Partition Key ซึ่งเราจะใช้ Hash Key เป็นชื่อ และจะใช้ UUID ที่ถูกสร้างขึ้นมาจาก Step ที่ผ่านมา เป็นค่าของ Partition Key เพื่อใช้สำหรับการทำ Index ของข้อมูลที่ถูกเข้ารหัสใน DynamoDB
def encrypt_item (plaintext_item,table_name):
table = boto3.resource('dynamodb').Table(table_name)

aws_kms_cmp = AwsKmsCryptographicMaterialsProvider(key_id=aws_cmk_id)

actions = AttributeActions(
default_action=CryptoAction.ENCRYPT_AND_SIGN,
attribute_actions={'Account_Id': CryptoAction.DO_NOTHING}
)

encrypted_table = EncryptedTable(
table=table,
materials_provider=aws_kms_cmp,
attribute_actions=actions
)
response = encrypted_table.put_item(Item=plaintext_item)
  • Get_decrypted_item สำหรับการเรียกใช้งานข้อมูล Plaintext ที่ถูกถอดรหัสแล้ว จาก Partition Key ที่กำหนด เช่น UUID token ที่มาจาก KMS customer managed key
  • Get_Item สำหรับการเรียกใช้งานข้อมูลที่ถูกเข้ารหัสอยู่ จาก Partition Key ที่กำหนด

dynamodb-encryption-sdk มี cryptography libraries เป็น dependency และทั้ง 2 libraries นั้นขึ้นอยู่กับแต่ละ Platform ที่ใช้งาน จึงต้องเลือกติดตั้งให้ถูกต้องตามแต่ละ Operating System ที่ใช้ โดย Lambda functions นั้นทำงานอยู่บน Amazon Linux ดังนั้น Libraries ที่จะถูกติดตั้งต้องเป็น Library สำหรับ Amazon Linux ถึงแม้ว่าเราจะพัฒนาตัว Application Code ที่ Operating System อื่นก็ตาม โดยเราสามารถใช้ script get_AMI_packages_cryptography.sh เพื่อดาวน์โหลด Docker image, ติดตั้ง Dependencies, และ Export ไฟล์ที่จะถูกใช้งานโดย Lambda Layer

หากคุณต้องประมวลผลข้อมูลจาก DynamoDB ในจำนวนมาก คุณอาจจะเจอข้อจำกัดของ AWS KMS requests-per-second ซึ่งจะทำให้การประมวลผลช้าลงได้ โดยคุณสามารถใช้เครื่องมือ เช่น JMeter สำหรับการทดสอบ Throughput ที่ต้องการ ด้วยการจำลองจำนวน Traffic จริงที่คาดการไว้สำหรับ Serverless Application นี้ ถ้าหากคุณจำเป็นต้องเกินจำนวนโควต้า คุณสามารถสร้างคำร้องขอเพื่อเพิ่มจำนวนโควต้าได้ใน Service Quotas โดยสามารถใช้งานได้ผ่าน Service Quotas Console หรือ ผ่าน RequestServiceQuotaIncrease operation สำหรับรายละเอียดเพิ่มเติม สามารถอ่านได้ที่ Requesting a quota increase ในส่วนของ Service Quotas User Guide หรือหาก Service Quotas สำหรับ AWS KMS นั้นไม่พร้อมใช้งานใน Region นั้น ๆ คุณสามารถเปิดคำร้องผ่าน AWS Support Center ได้เช่นเดียวกัน

และสุดท้าย เพื่อหลีกเลี่ยงค่าใช้จ่ายที่อาจเกิดขึ้นในอนาคตจากการทำตามบทความนี้ ให้ทำการลบ Resources ต่าง ๆ ที่ถูกสร้างขึ้น โดยการทำตามขั้นตอนที่ 7 จากไฟล์ README

บทสรุป

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