bởi Alexandros Soumplis và Dimitrios Papageorgiou | ngày 09 tháng 01 năm 2024 |
Trong bài viết này, chúng tôi hướng dẫn cách xây dựng một cơ chế để tự động phát hiện dữ liệu nhạy cảm, đặc biệt là thông tin cá nhân (PII), trong cơ sở dữ liệu quan hệ của bạn. PII là thông tin liên quan đến một cá nhân và có thể được sử dụng để xác định họ. Xử lý dữ liệu PII trong cơ sở dữ liệu quan hệ, chẳng hạn như Amazon Aurora, đòi hỏi kế hoạch và tích hợp với các dịch vụ khác.
Bạn có thể tích hợp cơ sở dữ liệu Aurora của mình với Amazon Comprehend để phát hiện PII. Amazon Comprehend là một dịch vụ xử lý ngôn ngữ tự nhiên (NLP) sử dụng máy học (ML) để khám phá thông tin quan trọng trong văn bản và có thể tự động phát hiện PII. Trong bài viết này, chúng tôi sử dụng AWS Lambda và các kích hoạt cơ sở dữ liệu để xây dựng một cơ chế phát hiện dữ liệu PII ngay lúc bạn chèn nó vào cơ sở dữ liệu và sử dụng Amazon Simple Notification Service (Amazon SNS) để gửi thông báo qua email.
Cơ chế này hoàn toàn trong suốt đối với lớp ứng dụng và không yêu cầu thay đổi mã hoặc cấu hình cấp ứng dụng. Các lợi ích của một cơ chế trong suốt đối với ứng dụng bao gồm việc nâng cấp ứng dụng một cách mượt mà và khả năng sử dụng nó với bất kỳ loại ứng dụng nào, thậm chí là những ứng dụng mà bạn không có quyền truy cập vào mã nguồn. Tuy nhiên, quan trọng là phải xem xét quy mô của công việc và các giao dịch trên cơ sở dữ liệu của bạn. Cơ chế này, theo thiết kế, đặt một tăng tạm thời lên nhu cầu lưu trữ cơ sở dữ liệu và thêm tải phụ lên trình điều khiển cơ sở dữ liệu của bạn trong quá trình xử lý.
Tóm lược giải pháp
Trong bài viết này, chúng tôi kiểm thử cơ chế với một cơ sở dữ liệu quan hệ Amazon Aurora tương thích với MySQL. Giải pháp này cũng hoạt động với Amazon Aurora tương thích với PostgreSQL và Amazon Relational Database Service (Amazon RDS) cho PostgreSQL, cho MySQL và cho MariaDB.
Biểu đồ sau minh họa kiến trúc của cơ chế tích hợp.
Các thành phần và quy trình trong kiến trúc này như sau:
- Ứng dụng chèn dữ liệu vào một trong những bảng được giám sát.
- Một trigger cơ sở dữ liệu chạy khi có sự chèn và sao chép dòng vào một bảng trung gian.
- Sự kiện được lên lịch chạy và đọc tất cả các dòng từ bảng trung gian.
- Sự kiện cơ sở dữ liệu gọi một hàm Lambda đồng bộ với dữ liệu HÀNG làm payload.
- Hàm Lambda gọi API Amazon Comprehend để phát hiện PII trong dữ liệu payload.
- Hàm Lambda ghi kết quả phát hiện vào Amazon CloudWatch cho mục đích đăng nhập và kiểm toán.
- Nếu phát hiện PII, hàm Lambda gọi Amazon SNS để gửi thông báo đến người dùng được chỉ định.
Thiết kế của cơ chế này là chung chung và có thể áp dụng cho bất kỳ ứng dụng nào sử dụng Aurora. Tuy nhiên, các ứng dụng khác có thể có các lược đồ cơ sở dữ liệu và các bảng khác nhau có thể lưu trữ dữ liệu PII. Do đó, chi tiết của cơ chế chỉ áp dụng cho một trường hợp sử dụng đơn giản và cụ thể để minh họa. Bạn nên điều chỉnh cơ chế này cho ứng dụng của mình và đặc biệt là mã của hàm Lambda, mã của trigger cơ sở dữ liệu và mã của sự kiện cơ sở dữ liệu.
Cơ sở dữ liệu có sự hỗ trợ tự nhiên để gọi một hàm Lambda đồng bộ hoặc không đồng bộ. Việc gọi đồng bộ của một hàm Lambda có thể có một mức độ chấp nhận được về hiệu suất trong ứng dụng của bạn vì nó làm tạm dừng giao dịch cho đến khi hàm Lambda chạy và trả về kết quả. Việc gọi không đồng bộ của một hàm Lambda ít tác động về hiệu suất hơn vì, mặc dù nó vẫn cần gọi API Lambda, nhưng nó không cần đợi phản hồi. Trong ví dụ này, bạn có tùy chọn chọn giữa chế độ đồng bộ và không đồng bộ bằng cách thay đổi giá trị của một tham số Boolean, trong ví dụ này là lambda_sync_mode. Giá trị mặc định cho ví dụ này là chạy ở chế độ đồng bộ để đảm bảo phát hiện PII đáng tin cậy.
Giải pháp sử dụng một bảng mẫu có một lược đồ cố định và tĩnh, điều này phổ biến trong nhiều trường hợp sử dụng khác nhau. Trong một số trường hợp sử dụng khác, lược đồ cơ sở dữ liệu hoặc định nghĩa bảng có thể thay đổi. Những thay đổi như xóa bảng, thêm cột mới vào bảng hoặc thay đổi kiểu dữ liệu có thể ảnh hưởng đến chức năng của cơ chế này. Đối với những thay đổi này, hãy đi qua tất cả các bước được trình bày trong giải pháp này và điều chỉnh một cách phù hợp. Kiểm tra và điều chỉnh các trigger cơ sở dữ liệu, các sự kiện cơ sở dữ liệu và mã hàm Lambda để đảm bảo mức độ chức năng tương tự và bạn đang kiểm tra tất cả các trường cần thiết để xác định dữ liệu PII.
Chi phí của cơ chế cũng là một điểm cần xem xét. Một cơ sở dữ liệu quan hệ có thể có một lượng lớn các truy vấn INSERT hoặc UPDATE, điều này có thể làm tăng chi phí của cơ chế. Để giảm thiểu rủi ro này, bạn cần xem xét lược đồ cơ sở dữ liệu và xác định các bảng và cột mà bạn muốn giám sát để xác định dữ liệu PII. Điều này sẽ cho phép bạn chạy trigger cơ sở dữ liệu và kích hoạt hàm Lambda chỉ cho việc chèn dữ liệu vào các bảng và cột cụ thể và không phải cho tất cả các truy vấn INSERT hoặc UPDATE vào cơ sở dữ liệu.
Trong các phần tiếp theo, chúng tôi sẽ mô tả các bước để xây dựng cơ chế tự động phát hiện PII:
- Tạo một bảng và các cột trong cơ sở dữ liệu của bạn.
- Tạo một chủ đề SNS và cấu hình nó tương ứng để nhận thông báo qua email.
- Tạo hàm Lambda tích hợp logic của cơ chế.
- Cấu hình động cơ cơ sở dữ liệu và xây dựng cơ chế trong cơ sở dữ liệu.
Điều kiện tiên quyết
Để xây dựng cơ chế này, bạn cần đã được cấu hình những điều sau:
- Một cơ sở dữ liệu Aurora MySQL.
- Quyền truy cập vào cơ sở dữ liệu Aurora MySQL với một người dùng có các đặc quyền sau để có thể chạy các lệnh:
- CREATE
- DROP
- INSERT
- SELECT
- EVENT
- TRIGGER
- AWS_LAMBDA_ACCESS
- Cơ sở dữ liệu Aurora MySQL của bạn phải được kết nối với các mạng con có một cổng mạng NAT nếu bạn truy cập Lambda qua internet công cộng hoặc cấu hình AWS PrivateLink và một giao diện đầu vào cho Lambda nếu bạn truy cập nó trực tiếp thông qua VPC của bạn.
Lưu ý rằng cơ chế mà bạn sẽ xây dựng không phụ thuộc vào ứng dụng cụ thể và không có các yêu cầu cụ thể về ứng dụng hoặc phương thức kết nối.
Tạo bảng và cột
Cơ chế tự động nhận diện PII cần phải thích ứng với schema của cơ sở dữ liệu và bảng hoặc các bảng mà bạn muốn theo dõi để phát hiện dữ liệu PII. Cho mục đích minh họa, bạn chỉ cần tạo một bảng đơn giản trong cơ sở dữ liệu Aurora của mình với ba cột: một cột id tự động tăng và hai trường văn bản có tên col1 và col2:
CREATE TABLE `pii_detection` (
`id` INT NOT NULL AUTO_INCREMENT,
`col1` TEXT,
`col2` TEXT,
PRIMARY KEY (`id`)
);Trong trường hợp sử dụng này, bạn có thể tạo một trigger trên bảng với tên pii_detection và truyền các cột col1 và col2 dưới dạng một đối tượng JSON cho hàm Lambda. Tuy nhiên, trigger của cơ sở dữ liệu là nguyên tử với các câu lệnh kích hoạt. Nếu trigger thất bại, câu lệnh cũng sẽ thất bại. Điều này có nghĩa là trigger luôn chặn ở cuộc gọi API Lambda và cũng phụ thuộc vào API Lambda. Nếu API bị tắt và trigger gặp lỗi, thì giao dịch INSERT sẽ thất bại. Một giao dịch thất bại đòi hỏi xử lý lỗi bổ sung ở cấp độ ứng dụng.
Để vượt qua rủi ro này, phương pháp là sử dụng một bảng trung gian có cấu trúc tương tự như bảng ban đầu. Sau đó thêm hai trigger, một cho INSERT và một cho UPDATE, trên bảng gốc để sao chép tất cả các hàng mới hoặc được cập nhật vào bảng trung gian. Từ bảng trung gian, tạo một sự kiện định kỳ của cơ sở dữ liệu, phân tích tất cả các hàng trong bảng này, kích hoạt hàm Lambda và phát hiện dữ liệu PII. Điều này giúp giao dịch ban đầu vẫn không bị chặn và giảm nhẹ bất kỳ xem xét hiệu suất nào. Đối với bảng mẫu pii_detection, hãy tạo một bảng trung gian tương tự có tên là pii_detection_queue với câu lệnh sau:
CREATE TABLE pii_detection_queue LIKE pii_detection;
Với cả bảng gốc và bảng trung gian đã sẵn sàng, bạn có thể bắt đầu xây dựng cơ chế. Việc sử dụng bảng trung gian giúp giảm thiểu thiệt hại về hiệu suất cho các chức năng cơ sở dữ liệu nhưng không loại bỏ nó hoàn toàn. Cơ chế này nhân đôi tất cả các câu lệnh INSERT và UPDATE trong bảng mẫu của bạn, điều này tăng ngưỡng tính toán và tăng nhu cầu lưu trữ tạm thời cho đến khi bảng trung gian được xử lý. Tùy thuộc vào tần suất của sự kiện cơ sở dữ liệu xử lý dữ liệu trong bảng trung gian, chi phí lưu trữ có thể là điều bạn cần xem xét.
Tạo một SNS topic
Để biết hướng dẫn về cách tạo chủ đề SNS trên Amazon, hãy tham khảo Cách tạo chủ đề Amazon SNS. Chủ đề này sẽ chuyển tiếp thông báo đến nhân viên được chỉ định để điều tra và thực hiện các hành động hoặc kích hoạt các quy trình khác. Đối với mục đích đơn giản, giả sử rằng đích của chủ đề SNS là một thông báo email cho nhóm DevSecOps.
Ghi chú tên SNS topic để sử dụng sau này trong Lambda.
Tạo một hàm Lambda
Bước tiếp theo là tạo hàm Lambda của cơ chế. Cơ chế này giao tiếp với Amazon Comprehend và Amazon SNS, vì vậy bạn cần tạo một vai trò Quản lý Danh tính và Truy cập (IAM) của AWS để ủy quyền quyền truy cập cho hàm Lambda của bạn đến các dịch vụ này.
Theo quy trình trong việc Tạo chính sách IAM để tạo một chính sách tùy chỉnh. Chính sách này cho phép hàm Lambda xuất bản thông báo đến chủ đề SNS bạn đã tạo trước đó. Trong đoạn mã chính sách sau đây, hãy cung cấp tên chính sách IAM tùy chỉnh của bạn và chủ đề SNS của bạn:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "<name_of_the_IAM_policy>",
"Effect": "Allow",
"Action": "sns:Publish",
"Resource": "arn:aws:sns:*:<account_id>:<name_of_the_sns_topic>"
}
]
}Tham khảo Cách tạo IAM roles để biết hướng dẫn về cách tạo một vai trò và đính kèm các chính sách quyền sau:
- AWSLambdaBasicExecutionRole
- AllowLambdaPublishtoSNS
- ComprehendReadOnly
Ghi chú tên của vai trò bạn vừa tạo và sau đó tạo một hàm Lambda theo hướng dẫn trong Tạo một hàm Lambda với bảng điều khiển bằng Python 3.11 cho runtime của bạn. Trong tab Configuration của hàm Lambda của bạn, vào Permissions và thêm vai trò bạn đã tạo làm vai trò thực thi. Để biết thêm thông tin về cách tạo một vai trò thực thi Lambda, tham khảo Vai trò thực thi Lambda.
Tiếp theo, vào tab Code của hàm và nhập mã nguồn sau:
# Import necessary modules
import json
import boto3
# Initialize an AWS Comprehend and an Amazon SNS client
comprehend = boto3.client('comprehend')
sns = boto3.client('sns')
# Put the full ARN of the SNS topic you have created
# Replace <region>, <account_id> and <name_of_the_sns_topic> with the
# appropriate values
sns_topic_arn = 'arn:aws:sns:<region>:<account_id>:<name_of_the_sns_topic>'
def lambda_handler(event, context):
# Set an empty array to store the PII fields
pii_fields = []
raw_data = event
# Iterate through the event data and check for PII fields
for key in event:
key_val = str(event[key])
if key_val:
# Check if the field is the unique ID of the row and keep the value
if key == 'id':
row_id = key_val
continue
response = comprehend.detect_pii_entities(Text=key_val, LanguageCode='en')
# Check if PII data is found in the field and append it to the array
if response['Entities']:
pii_fields.append(key)
# Send PII data to the SNS topic (if any)
if pii_fields:
pii_data = f"PII data found for ROW with ID [[[ { row_id } ]]] in the following fields: { pii_fields }"
response = sns.publish(TopicArn=sns_topic_arn, Message=json.dumps(pii_data))
print(f"PII data FOUND in the following fields: { pii_fields } with row id { row_id }")
else:
print(f"PII data NOT found in any fields with row id { row_id }")
# Return a successful response
return {
'statusCode': 200,
'body': 'Data checked for PII successfully'
}Khi kích hoạt trigger của cơ sở dữ liệu, nó gọi hàm Lambda này và truyền một đối tượng JSON chứa các cặp key-value của tên cột trong cơ sở dữ liệu và dữ liệu tương ứng. Hãy xem xét các giới hạn của Lambda, đặc biệt là về đồng thời và kích thước payload. Tùy thuộc vào lưu lượng và kích thước dữ liệu dự kiến, hãy lập kế hoạch và điều chỉnh cần thiết để giữ trong giới hạn. Sau đó, quy trình tiếp tục qua các bước sau:
- Hàm duyệt qua tất cả các key. Nếu key không có giá trị trống, nó kiểm tra xem đó có phải là ID dòng duy nhất không để ghi lại nó và bỏ qua bất kỳ xử lý nào khác. Nếu key không phải là ID duy nhất và giá trị không trống, nó chuyển payload đến Amazon Comprehend để phát hiện thông tin cá nhân (PII).
- API Amazon Comprehend trả lại kết quả.
- Nếu tìm thấy dữ liệu PII, hàm thêm tên cột vào mảng pii_fields.
- Khi kiểm tra cho tất cả các cột hoàn tất, hàm kiểm tra xem có bất kỳ trường nào trong mảng pii_fields hay không.
- Nếu có trường, có nghĩa là đã phát hiện dữ liệu PII. Hàm chuẩn bị một thông báo với thông tin liên quan và công bố nó lên chủ đề SNS bạn đã cấu hình. Nó cũng ghi lại một thông báo vào CloudWatch về dữ liệu PII được phát hiện. Lưu ý rằng hàm chỉ ghi lại và công bố ID dòng của bản ghi vi phạm trong cơ sở dữ liệu thay vì chính dữ liệu PII thực tế.
- Nếu không tìm thấy dữ liệu PII, hàm cũng ghi lại một thông báo vào CloudWatch.
5. Hàm trả về mã trạng thái HTTP 200 và một thông báo.
Chú ý tên của hàm Lambda và tiếp tục với các bước tiếp theo.
Cấu hình Aurora để kích hoạt hàm Lambda
Bước cuối cùng để hoàn thành cơ chế tự động phát hiện thông tin cá nhân (PII) là cấu hình Aurora để kích hoạt hàm Lambda mà bạn đã tạo mỗi khi bạn chèn dữ liệu vào bảng bạn đang theo dõi (pii_detection).
Tạo một IAM role
Bạn phải tạo một vai trò IAM cho Dịch vụ AWS: rds để cho phép Aurora kích hoạt hàm Lambda bạn đã tạo. Sử dụng chính sách quyền sau đây cho vai trò này (cung cấp Region, ID tài khoản và tên hàm Lambda của bạn):
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "RDStoPII",
"Action": "lambda:InvokeFunction",
"Resource": "arn:aws:lambda:<region>:<account id>:function:<lambda_function_name>",
"Effect": "Allow"
}
]
}Ghi chú lại tên của vai trò bạn vừa tạo.
Xác định Lambda role mặc định
Cơ sở dữ liệu Aurora của bạn sử dụng vai trò này để kích hoạt hàm Lambda. Theo hướng dẫn trong “Làm việc với các nhóm tham số” để sửa đổi các tham số trong Aurora.
- Nếu bạn chưa sử dụng một nhóm tham số cụm tùy chỉnh, hãy tạo một nhóm tham số cụm. Sau đó sửa đổi tham số aws_default_lambda_role. Giá trị của tham số này nên như sau (cung cấp ID tài khoản và tên của vai trò):
arn:aws:iam::<account_id>:role/<name of RDS role>
- Tiếp theo, liên kết nhóm tham số cụm này với cơ sở dữ liệu của bạn. Lưu ý rằng nếu bạn đã tạo một nhóm tham số cụm mới, quá trình này sẽ gây gián đoạn trong cơ sở dữ liệu của bạn vì nó cần khởi động lại các phiên bản cơ sở dữ liệu để áp dụng thay đổi.
- Khi cấu hình nhóm tham số cụm khách hàng hoàn tất, kết nối vào cơ sở dữ liệu của bạn và cấp quyền truy cập cho người dùng cơ sở dữ liệu của bạn để kích hoạt Lambda. Ví dụ, nếu người dùng của bạn là piiusr, lệnh để chạy sẽ trông như sau:
GRANT AWS_LAMBDA_ACCESS TO piiusr@’%’;
Kiểm tra lệnh gọi hàm Lambda đồng bộ
Bây giờ hãy kiểm tra xem bạn có thể chạy hàm Lambda mà bạn đã tạo với người dùng mà bạn đã cấp quyền kết nối với cơ sở dữ liệu hay không. Sử dụng mã sau (cung cấp your Region, account ID, và function name):
MySQL [pii_detection]> SELECT lambda_sync('arn:aws:lambda:<region>:<account_id>:function:<lambda_function_name>','{"TestKey": "Test synchronous call for PII detection"}');
+----------------------------------------------------------------------------------------------------------------------------------------------+
| lambda_sync('arn:aws:lambda:<region>:<account_id>:function:<lambda_function_name>','{"TestKey": "Test synchronous call for PII detection"}') |
+----------------------------------------------------------------------------------------------------------------------------------------------+
| {
"statusCode": 200,
"body": "Data checked for PII successfully"
} |
+----------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.96 sec)Câu truy vấn gọi hàm Lambda ở chế độ đồng bộ, và bạn nhận kết quả của mã Python trong câu lệnh return của hàm. Lưu ý rằng thời gian cần để hoàn thành việc chạy câu lệnh là 0,96 giây. Đây là thời gian để Aurora kích hoạt hàm Lambda, chạy mã, giao tiếp với API Amazon Comprehend và trả kết quả.
Kiểm thử gọi hàm Lambda không đồng bộ
Bây giờ hãy chạy cùng một bài kiểm tra nhưng thay vì gọi hàm Lambda đồng bộ, hãy gọi nó không đồng bộ:
MySQL [pii_detection]> SELECT lambda_async('arn:aws:lambda:<region>:<account_id>:function:<lambda_function_name>','{"TestKey": "Test asynchronous call for PII detection"}');
+----------------------------------------------------------------------------------------------------------------------------------------------+
| lambda_async('arn:aws:lambda:<region>:<account_id>:function:<lambda_function_name>','{"TestKey": "Test asynchronous call for PII detection"}') |
+----------------------------------------------------------------------------------------------------------------------------------------------+
| {
} |
+----------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.06 sec)Câu truy vấn SELECT kích hoạt hàm Lambda ở chế độ không đồng bộ, nhưng bây giờ bạn nhận được kết quả trống vì cuộc gọi không đồng bộ trả ngay lập tức sau khi kích hoạt hàm Lambda và không đợi cho quá trình chạy hoàn tất. Lưu ý rằng bây giờ thời gian cần để hoàn thành việc chạy câu lệnh chỉ là 0,06 giây. Đây là một cải thiện hiệu suất đáng kể – bạn nên sử dụng các cuộc gọi không đồng bộ trừ khi bạn cần biết kết quả của hàm Lambda.
Trong trường hợp sử dụng này, bạn chỉ muốn cảnh báo, vì vậy gọi không đồng bộ là lựa chọn được đề xuất. Trong trường hợp bạn muốn cập nhật dữ liệu trước khi chèn vào cơ sở dữ liệu, bạn nên sử dụng cuộc gọi đồng bộ và đánh giá kết quả trả về.
Thiết lập các trigger của cơ sở dữ liệu
Bước tiếp theo là thiết lập các trigger của cơ sở dữ liệu. Các trigger sao chép dữ liệu vào bảng trung gian. Trigger đầu tiên chạy mỗi khi bạn chèn dữ liệu vào bảng bạn muốn giám sát. Quan trọng để lưu ý rằng trigger này sẽ tăng chi phí lưu trữ cơ sở dữ liệu và IOPS của cơ sở dữ liệu. Ảnh hưởng đến chi phí và hiệu suất phụ thuộc vào số lượng giao dịch và lượng dữ liệu mà trigger sao chép từ bảng chính sang bảng trung gian.
Mã trigger cho ví dụ này như sau:
DELIMITER ;;
CREATE TRIGGER pii_detection_queue_trigger_insert
AFTER INSERT
ON pii_detection FOR EACH ROW
BEGIN
INSERT INTO pii_detection_queue(id, col1, col2) VALUES (new.id, new.col1, new.col2);
END
;;
DELIMITER ;Với đoạn mã này, bạn thực hiện các bước sau:
- Tạo một trigger có tên là pii_detection_queue_trigger_insert.
- Chạy trigger cho tất cả các dòng sau khi chèn dữ liệu vào bảng pii_detection.
- Chèn vào bảng trung gian pii_detection_queue các giá trị của các cột từ bảng gốc (id, col1, col2).
Trigger thứ hai giống như trigger đầu tiên, nhưng bạn cấu hình nó để chạy sau khi có cập nhật trên một cột đã tồn tại. Mã trigger cho ví dụ này như sau:
DELIMITER ;;
CREATE TRIGGER pii_detection_queue_trigger_update
AFTER UPDATE ON pii_detection
FOR EACH ROW
BEGIN
DECLARE nb INT;
SET nb = (SELECT count(*) FROM pii_detection_queue WHERE id = new.id);
IF(nb = 0) THEN
INSERT INTO pii_detection_queue(id, col1, col2) VALUES (new.id, new.col1, new.col2);
ELSE
UPDATE pii_detection_queue set col1 = new.col1, col2 = new.col2 WHERE id = new.id;
END IF;
END
;;
DELIMITER ;Thiết lập sự kiện cơ sở dữ liệu
Bước cuối cùng để hoàn thiện cơ chế là thiết lập sự kiện cơ sở dữ liệu. Sự kiện này diễn ra theo các khoảng thời gian đã lên lịch và xử lý tất cả các hàng trong bảng trung gian. Mã sự kiện trong ví dụ của chúng tôi như sau:
DELIMITER ;;
CREATE EVENT IF NOT EXISTS detect_pii
ON SCHEDULE EVERY 1 MINUTE
DO
BEGIN
DECLARE done INT DEFAULT FALSE;
DECLARE id_val INT;
DECLARE col1_val, col2_val TEXT;
DECLARE cur CURSOR FOR SELECT id, col1, col2 FROM pii_detection_queue;
-- Define a handler to continue running when cursor has no more rows
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
-- Define an exit handler to stop running in case of SQL errors. This is useful to abort running and avoid losing data if Lambda invocation fails for any reason
DECLARE EXIT HANDLER FOR SQLEXCEPTION BEGIN END;
SET @lambda_arn = ‘arn:aws:lambda:<region>:<account_id>:function:<lambda_function_name>';
SET @lambda_sync_mode = ‘TRUE’
OPEN cur;
read_loop: LOOP
FETCH cur INTO id_val, col1_val, col2_val;
IF done THEN
LEAVE read_loop;
END IF;
SET json_object = JSON_OBJECT(
'id', id_val,
'col1', col1_val,
'col2', col2_val
);
IF @lambda_sync_mode THEN
-- Synchronous mode. The lambda function is invoked and we wait the result to check if run successfully and then we can delete the row
SELECT lambda_sync(@lambda_arn, @json_object) INTO @result;
SET @statusCode = JSON_EXTRACT(@result, '$.statusCode');
IF @statusCode = 200 THEN
DELETE FROM pii_detection_queue WHERE id = id_val;
END IF;
ELSE
-- Asynchronous mode. As long as the lambda function is invoked, we are good to delete the row and leave lambda do the error handling.
SELECT lambda_async(@lambda_arn, @json_object) INTO @result;
DELETE FROM pii_detection_queue WHERE id = id_val;
END IF;
END LOOP;
CLOSE cur;
END;
;;
DELIMITER ;Với đoạn mã này, bạn thực hiện các bước sau:
- Tạo một sự kiện định kỳ có tên là detect_pii.
- Chạy sự kiện định kỳ mỗi 1 phút. Bạn có thể điều chỉnh điều này tùy thuộc vào nhu cầu và tốc độ tăng của bảng trung gian cũng như tần suất kiểm tra thông tin cá nhân (PII).
- Khai báo một số biến để sử dụng sau trong mã. Chú ý đến việc khai báo biến cur. Bạn tạo một con trỏ trên bộ ghi với câu lệnh SELECT id, col1, col2 FROM pii_detection_queue. Điều này cho phép bạn tùy chỉnh thêm các bản ghi để truy xuất và xử lý.
- Khai báo một handler để tiếp tục chạy khi con trỏ không còn dòng nào nữa.
- Khai báo một handler để dừng chạy và thoát trong trường hợp có lỗi SQL. Điều này hữu ích để hủy bỏ quá trình xử lý và tránh mất dữ liệu nếu cuộc gọi Lambda thất bại vì bất kỳ lý do nào.
- Thiết lập ARN của hàm Lambda của bạn.
- Thiết lập chế độ mong muốn để chạy hàm Lambda. Giá trị true có nghĩa là hàm sẽ chạy ở chế độ đồng bộ. Sự kiện chạy hàm và kiểm tra kết quả cho mỗi hàng và chỉ xóa nếu kết quả trả về của hàm là 200. Giá trị false có nghĩa là hàm sẽ chạy ở chế độ không đồng bộ. Miễn là cuộc gọi hàm thành công, nó sẽ xóa hàng trong bảng trung gian.
- Mở con trỏ trên bộ ghi và lặp qua tất cả các dòng:
- Đối với mỗi dòng, tạo một đối tượng JSON với:
- Key – ID dòng duy nhất và tên của các cột bạn muốn kiểm tra.
- Value – Giá trị thực tế được lưu trữ trong cơ sở dữ liệu.
- Kiểm tra giá trị của lambda_sync_mode. Nếu lambda_sync_mode là true, gọi hàm ở chế độ đồng bộ với đối tượng JSON này. Chờ kết quả và kiểm tra xem đối tượng JSON có mã trạng thái bằng 200 không. Sau đó, xóa dòng và tiếp tục với dòng tiếp theo.
- Nếu lambda_sync_mode là false, gọi hàm ở chế độ không đồng bộ với đối tượng JSON này. Miễn là không có lỗi SQL trong cuộc gọi hàm, không cần đợi kết quả. Xóa dòng và tiếp tục với dòng tiếp theo.
- Đóng vòng lặp và con trỏ.
- Tối ưu hóa bảng trung gian do có thể có số lượng lớn ghi và xóa.
Với cơ chế này, khi bạn chèn bản ghi mới vào bảng bạn giám sát, chúng tự động được sao chép vào một bảng trung gian. Đồng thời, bạn có một sự kiện được lên lịch chạy mỗi 1 phút kiểm tra bảng trung gian để xem có dòng nào không. Nếu có dòng trong bảng, nó tạo một đối tượng JSON và gọi hàm Lambda để phát hiện thông tin cá nhân (PII). Điều này không chặn đối với các giao dịch cơ sở dữ liệu và không ảnh hưởng đến môi trường chạy trong trường hợp chậm trễ hoặc không khả dụng của API Lambda.
Cơ chế này đã hoàn tất. Đối với tất cả dữ liệu được chèn vào bảng pii_detection, bạn gián tiếp gửi dữ liệu đó đến Amazon Comprehend, với sự giúp đỡ của Lambda, để kiểm tra xem nó có chứa dữ liệu PII hay không. Nếu Amazon Comprehend phát hiện dữ liệu PII, hàm Lambda sẽ gửi thông báo đến Amazon SNS để tạo ra một cảnh báo cho đội DevSecOps của bạn.
Kiểm tra cơ chế phát hiện PII tự động
Với cơ chế đã có, bây giờ bạn cần kiểm tra chức năng của nó. Kết nối với cơ sở dữ liệu và chạy một vài truy vấn INSERT:
MySQL [pii_detection]> INSERT INTO pii_detection (col1,col2) VALUES (“This insert does not contain PII”, “You should not have any notification”);
Query OK, 1 row affected (0.03 sec)
MySQL [pii_detection]> INSERT INTO pii_detection (col1,col2) VALUES (“This insert contain PII in col2”, “John Doe”);
Query OK, 1 row affected (0.04 sec)
Bạn đã chạy hai câu lệnh INSERT khác nhau, trong đó câu lệnh đầu tiên không chứa bất kỳ dữ liệu PII nào và câu lệnh thứ hai chứa “John Doe”, là PII.
Bạn có thể kiểm tra CloudWatch logs và thấy rằng đối với câu lệnh INSERT đầu tiên, bạn có các mục nhật ký sau:
Đối với câu lệnh INSERT thứ hai, bạn có các mục nhật ký sau:
Vì bạn đã xác định SNS topic để gửi email nên bạn cũng sẽ nhận được thông báo qua email cho mục này.
Tùy thuộc vào số lượng giao dịch trong cơ sở dữ liệu của bạn và đặc biệt là các câu lệnh INSERT hoặc UPDATE trong bảng bạn đang kiểm tra để xác định thông tin cá nhân (PII), bạn có thể cần xem xét cơ chế thông báo thay thế. Cơ chế này gửi thông báo qua email cho mỗi dòng phát hiện PII, điều này có thể dẫn đến một lượng lớn email trong vài phút. Trong trường hợp đó, việc sử dụng một cơ chế thay thế mà tổng hợp kết quả trước khi gửi thông báo có thể hiệu quả hơn.
Dọn dẹp
Để loại bỏ cơ chế tự động phát hiện PII khỏi cơ sở dữ liệu của bạn, bạn cần loại bỏ tất cả các thành phần đã tạo.
Loại bỏ Cấu hình Aurora
Hoàn thành các bước sau để làm sạch tài nguyên của bạn trong Aurora:
- Kết nối vào cơ sở dữ liệu với một người dùng quản trị và xóa các trigger bạn đã tạo:
DROP TRIGGER IF EXISTS pii_detection_queue_trigger_insert;
DROP TRIGGER IF EXISTS pii_detection_queue_trigger_update;
- Kết nối vào cơ sở dữ liệu với một người dùng quản trị và xóa sự kiện bạn đã tạo:
DROP EVENT IF EXISTS detect_pii;
- Kết nối vào cơ sở dữ liệu với một người dùng quản trị và thu hồi quyền truy cập cho người dùng cơ sở dữ liệu vào các hàm Lambda:
REVOKE AWS_LAMBDA_ACCESS TO piiusr@’%’;
- Kết nối vào cơ sở dữ liệu và xóa bảng trung gian:
DROP TABLE IF EXISTS pii_detection_queue;
- Sửa đổi nhóm tham số cơ sở dữ liệu và sửa đổi tham số aws_default_lambda_role hoặc, nếu đây là thay đổi duy nhất, bạn có thể đặt lại nhóm tham số.
Xóa hàm Lambda
Để làm sạch hàm Lambda, thực hiện các bước sau:
- Trên bảng điều khiển Lambda, chọn hàm mà bạn đã tạo.
- Trong menu Hành động (Actions), chọn Xóa (Delete).
- Nhập “delete” vào ô nhập văn bản và chọn Xóa (Delete).
Xóa chủ đề SNS
Xóa chủ đề SNS mà bạn đã tạo. Để biết chi tiết, tham khảo Hủy đăng ký và chủ đề Amazon SNS.
Xóa AM roles
Cơ chế này yêu cầu hai vai trò IAM tùy chỉnh: một để cho phép hàm Lambda của bạn tương tác với Amazon Comprehend và Amazon SNS, và một khác để cho phép Aurora kích hoạt các hàm Lambda. Theo hướng dẫn tại Hủy bỏ vai trò hoặc hồ sơ instance để xóa các vai trò này.
Kết luận
Trong bài viết này, bạn đã cấu hình cơ sở dữ liệu Aurora MySQL của mình để phát hiện dữ liệu cá nhân (PII) và gửi thông báo. Cơ chế này sử dụng các trigger và sự kiện cơ sở dữ liệu để kích hoạt các hàm Lambda khi bạn chèn dữ liệu vào một bảng mà bạn muốn giám sát để xác định thông tin cá nhân. Hàm Lambda phân tích đầu vào và sử dụng Amazon Comprehend để phát hiện PII và gửi thông báo bằng cách sử dụng Amazon SNS.
Cơ chế này hoàn toàn trong suốt đối với ứng dụng của bạn và không đòi hỏi bất kỳ thay đổi mã nguồn nào hoặc thay đổi cấu hình. Việc sử dụng các trigger cơ sở dữ liệu, sự kiện cơ sở dữ liệu và Lambda cho phép bạn sử dụng mã nguồn phức tạp hơn để thực hiện các xử lý hoặc phát hiện có điều kiện để tối ưu hóa chi phí.
Nếu bạn có bất kỳ câu hỏi hoặc gợi ý nào về bài viết này, hãy để lại trong phần bình luận.
About the Authors
Alexandros Soumplis là Kiến trúc sư giải pháp cấp cao tại Amazon Web Services. Ông có nhiều kinh nghiệm trong lĩnh vực CNTT với nhiều vai trò khác nhau, giúp đỡ các bên liên quan và khách hàng thiết kế, đánh giá và triển khai các giải pháp nhằm giải quyết các thách thức kinh doanh.
Dimitrios Papageorgiou là Kiến trúc sư giải pháp cấp cao tại Amazon Web Services, nơi ông hỗ trợ khách hàng thiết kế các hệ thống an toàn, mạnh mẽ và có thể mở rộng, sẵn sàng hỗ trợ thị trường toàn cầu. Anh đặc biệt đam mê kỹ thuật dữ liệu và các ứng dụng của nó trong việc giải quyết các nhu cầu kinh doanh của khách hàng. Ngoài ra, anh ấy thích chỉnh sửa, viết và cải thiện mã của các hệ thống phụ trợ lớn, hiệu suất cao.
AWS Study Group 