Tác giả: Himanshu Dixit, David Zhang, Richard Session, and Viyoma Sachdeva
Ngày phát hành: 08 JAN 2026
Chuyên mục: Amazon Bedrock, Amazon Bedrock Data Automation, Amazon Bedrock Guardrails, Artificial Intelligence, Expert (400), Generative AI, Technical How-to

Các tổ chức xử lý một lượng lớn thông tin khách hàng nhạy cảm thông qua nhiều kênh liên lạc khác nhau. Bảo vệ Thông tin Nhận dạng Cá nhân (PII), chẳng hạn như số an sinh xã hội (SSN), số giấy phép lái xe và số điện thoại, ngày càng trở nên quan trọng để duy trì tuân thủ các quy định về quyền riêng tư dữ liệu và xây dựng lòng tin của khách hàng. Tuy nhiên, việc xem xét và biên tập PII thủ công tốn thời gian, dễ xảy ra lỗi và khó mở rộng khi khối lượng dữ liệu tăng lên.

Các tổ chức phải đối mặt với những thách thức khi xử lý PII nằm rải rác trên các loại nội dung khác nhau – từ văn bản đến hình ảnh. Các phương pháp truyền thống thường yêu cầu các công cụ và quy trình làm việc riêng biệt để xử lý nội dung văn bản và hình ảnh, dẫn đến các thực hành biên tập không nhất quán và các lỗ hổng bảo mật tiềm ẩn. Cách tiếp cận phân mảnh này không chỉ làm tăng chi phí vận hành mà còn làm tăng nguy cơ lộ PII ngoài ý muốn.

Bài viết này trình bày một giải pháp tự động phát hiện và biên tập PII sử dụng Amazon Bedrock Data Automation và Amazon Bedrock Guardrails thông qua một trường hợp sử dụng xử lý nội dung văn bản và hình ảnh trong khối lượng lớn email và tệp đính kèm đến. Giải pháp này có quy trình xử lý email hoàn chỉnh với giao diện người dùng dựa trên React để nhân viên được ủy quyền quản lý và xem xét các liên lạc email và tệp đính kèm đã được biên tập một cách an toàn hơn. Chúng tôi sẽ hướng dẫn chi tiết các bước triển khai giải pháp này. Cuối cùng, chúng tôi thảo luận về lợi ích của giải pháp, bao gồm hiệu quả vận hành, khả năng mở rộng, bảo mật và tuân thủ, cũng như khả năng thích ứng.

Tổng quan giải pháp

Giải pháp cung cấp một hệ thống tự động để bảo vệ thông tin nhạy cảm trong các giao tiếp kinh doanh thông qua ba khả năng chính:

1. Tự động phát hiện và biên tập PII cho cả nội dung email và tệp đính kèm bằng cách sử dụng Amazon Bedrock Data Automation và Guardrails, đảm bảo rằng dữ liệu nhạy cảm được bảo vệ nhất quán trên các loại nội dung khác nhau.
2. Quy trình quản lý dữ liệu an toàn hơn nơi các giao tiếp đã xử lý được mã hóa và lưu trữ với các kiểm soát truy cập phù hợp, đồng thời duy trì một nhật ký kiểm toán đầy đủ các hoạt động.
3. Các tùy chọn giao diện dựa trên web cho các tác nhân được ủy quyền để quản lý hiệu quả các giao tiếp đã được biên tập, được hỗ trợ bởi các tính năng như phân loại email tự động và quản lý thư mục có thể tùy chỉnh.

Cách tiếp cận thống nhất này giúp các tổ chức duy trì tuân thủ các yêu cầu về quyền riêng tư dữ liệu trong khi hợp lý hóa quy trình làm việc giao tiếp của họ.

Sơ đồ sau đây phác thảo kiến trúc giải pháp.

Sơ đồ minh họa quy trình làm việc phát hiện và biên tập PII backend và giao diện người dùng ứng dụng frontend được điều phối bởi AWS Lambda và Amazon EventBridge. Quy trình này tuân theo các bước sau:

1. Quy trình làm việc bắt đầu khi người dùng gửi email đến máy chủ email đến được lưu trữ trên Amazon Simple Email Service (Amazon SES). Đây là một bước tùy chọn.
2. Ngoài ra, người dùng có thể tải email và tệp đính kèm trực tiếp vào một S3 landing bucket của Amazon Simple Storage Service (S3).
3. Một thông báo sự kiện S3 kích hoạt hàm AWS Lambda xử lý ban đầu, tạo một ID trường hợp duy nhất và tạo một bản ghi theo dõi trong Amazon DynamoDB.
4. Lambda điều phối quy trình làm việc phát hiện và biên tập PII bằng cách trích xuất nội dung email và tệp đính kèm từ email và lưu trữ chúng trong một raw email bucket, sau đó gọi Amazon Bedrock Data Automation và Guardrails để phát hiện và biên tập PII.
5. Amazon Bedrock Data Automation xử lý các tệp đính kèm để trích xuất văn bản từ các tệp.
6. Amazon Bedrock Guardrails phát hiện và biên tập PII từ cả nội dung email và văn bản từ các tệp đính kèm và lưu trữ nội dung đã được biên tập trong một S3 bucket khác.
7. Các bảng DynamoDB được cập nhật với tin nhắn email, siêu dữ liệu thư mục và các quy tắc lọc email.
8. Một Amazon EventBridge Scheduler được sử dụng để chạy Rules Engine Lambda theo lịch trình, xử lý các email mới chưa được phân loại vào các thư mục dựa trên các tiêu chí quy tắc lọc email đã bật.
9. Rules Engine Lambda cũng giao tiếp với DynamoDB để truy cập bảng tin nhắn và bảng quy tắc.
10. Người dùng có thể truy cập giao diện người dùng ứng dụng tùy chọn thông qua Amazon API Gateway, quản lý các yêu cầu API của người dùng và định tuyến các yêu cầu để hiển thị giao diện người dùng thông qua S3 static hosting. Người dùng có thể chọn bật xác thực cho giao diện người dùng dựa trên yêu cầu bảo mật của họ. Ngoài ra, người dùng có thể kiểm tra trạng thái xử lý email của họ trong bảng DynamoDB và S3 bucket với nội dung PII đã được biên tập.
11. Một Portal API Lambda tìm nạp chi tiết trường hợp dựa trên yêu cầu của người dùng.
12. Các tài sản tĩnh được phục vụ bởi API Gateway được lưu trữ trong một S3 bucket riêng tư.
13. Tùy chọn, người dùng có thể bật Amazon CloudWatch và AWS CloudTrail để cung cấp khả năng hiển thị vào quy trình phát hiện và biên tập PII, trong khi sử dụng Amazon Simple Notification Service để gửi cảnh báo theo thời gian thực cho bất kỳ lỗi nào, tạo điều kiện chú ý ngay lập tức đến các vấn đề.

Trong các phần sau, chúng tôi sẽ hướng dẫn các quy trình để triển khai giải pháp này.

Hướng dẫn

Việc triển khai giải pháp bao gồm thiết lập hạ tầng và portal tùy chọn.

Điều kiện tiên quyết

Trước khi bắt đầu triển khai, hãy đảm bảo đã cài đặt và cấu hình các thành phần sau.

• Một tài khoản AWS
• Git
• Python 3.7 hoặc cao hơn
• Node v18 hoặc cao hơn
• NPM v9.8 hoặc cao hơn
• AWS CDK v2.166 hoặc cao hơn
• Terminal/CLI như macOS Terminal, PowerShell hoặc Windows Terminal, hoặc dòng lệnh Linux. AWS CloudShell cũng có thể được sử dụng khi tất cả mã nằm trong một tài khoản AWS

Quy trình thiết lập và triển khai hạ tầng

Xác minh rằng một virtual private cloud VPC hiện có chứa ba subnet riêng tư không có quyền truy cập internet đã được tạo trong tài khoản AWS của bạn. Tất cả các stack của AWS CloudFormation cần được triển khai trong cùng một tài khoản AWS.

Các Stack của CloudFormation

Giải pháp chứa ba stack (hai bắt buộc, một tùy chọn) được triển khai trong tài khoản AWS của bạn:

• S3Stack – Cung cấp hạ tầng cốt lõi bao gồm các S3 bucket để lưu trữ email thô và đã được biên tập với các chính sách vòng đời tự động, một bảng DynamoDB để theo dõi siêu dữ liệu email với thời gian tồn tại (TTL) và các chỉ mục phụ toàn cầu, và các nhóm bảo mật VPC để truy cập hàm Lambda an toàn hơn. Nó cũng tạo các vai trò Amazon Identity and Access Management (IAM) với các quyền toàn diện cho các dịch vụ S3, DynamoDB và Bedrock, tạo thành một nền tảng an toàn hơn cho toàn bộ quy trình làm việc phát hiện và biên tập PII.
• ConsumerStack – Cung cấp hạ tầng xử lý cốt lõi bao gồm các dự án Amazon Bedrock Data Automation để trích xuất văn bản tài liệu và Bedrock Guardrails được cấu hình để ẩn danh các thực thể PII toàn diện, cùng với các hàm Lambda để xử lý email và tệp đính kèm với các chủ đề Amazon Simple Notification Service (SNS) cho các thông báo thành công/thất bại. Nó cũng tạo các quy tắc nhận Amazon Simple Email Service (SES) để xử lý email đến khi một miền được cấu hình và các thông báo sự kiện S3 để tự động kích hoạt quy trình làm việc xử lý email.
• PortalStack (tùy chọn) – Chỉ cần thiết khi người dùng muốn sử dụng giao diện người dùng dựa trên web để quản lý email. Nó cung cấp giao diện web tùy chọn bao gồm một API Gateway khu vực, các bảng DynamoDB để lưu trữ tin nhắn đã được biên tập và các S3 bucket cho các tài sản web tĩnh.

Amazon SES (tùy chọn)

Chuyển trực tiếp đến phần Triển khai Giải pháp nếu không sử dụng Amazon SES.

Thiết lập Amazon SES sau đây là tùy chọn. Mã có thể được kiểm tra mà không cần thiết lập này. Các bước để kiểm tra ứng dụng có hoặc không có Amazon SES được đề cập trong phần Kiểm thử.

Thiết lập Amazon SES với quyền truy cập sản xuất và xác minh các miền/địa chỉ email mà giải pháp sẽ hoạt động. Chúng ta cũng cần thêm các bản ghi MX vào nhà cung cấp DNS duy trì miền. Vui lòng tham khảo các liên kết sau:

• Yêu cầu quyền truy cập sản xuất SES
• Thiết lập nhận email Amazon SES

Tạo thông tin xác thực cho SMTP và lưu trữ nó trong secret của AWS Secrets Manager với tên SmtpCredentials. Một người dùng IAM được tạo cho quy trình này.

Nếu bất kỳ tên nào khác được sử dụng cho secret, hãy cập nhật dòng secret_name trong context.json với tên của secret đã tạo.

Khóa cho tên người dùng trong secret phải là smtp_username và khóa cho mật khẩu phải là smtp_password khi lưu trữ trong AWS Secrets Manager.

• Lấy thông tin xác thực SMTP của Amazon SES

Triển khai giải pháp

Chạy các lệnh sau từ môi trường terminal/CLI.

1. Clone repository
   code git clone https://github.com/aws-samples/sample-bda-redaction.git
2. Tệp infra/cdk.json cho CDK Toolkit biết cách thực thi ứng dụng của bạn
   code cd sample-bda-redaction/infra/
3. Tùy chọn: Tạo và kích hoạt môi trường ảo Python mới (đảm bảo sử dụng python 3.12 vì lambda trong CDK được cấu hình cho phiên bản này. Nếu sử dụng phiên bản python khác, hãy cập nhật mã CDK để phản ánh điều đó trong lambda runtime)
   python python3 -m venv .venv . .venv/bin/activate
4. Nâng cấp pip
   python pip install --upgrade pip
5. Cài đặt các gói Python
   python pip install -r requirements.txt
6. Tạo tệp context.json
code cp context.json.example context.json
7. Cập nhật tệp context.json với các tùy chọn cấu hình chính xác cho môi trường.

8. Các thuộc tính sau chỉ bắt buộc khi portal đang được cung cấp.

9. Các trường hợp sử dụng yêu cầu sử dụng Amazon SES để quản lý các tin nhắn email đã được biên tập cần đặt các biến cấu hình sau. Nếu không, chúng là tùy chọn.

10. Triển khai Hạ tầng bằng cách chạy các lệnh sau từ thư mục gốc của thư mục infra.
    a. Bootstrap tài khoản AWS để sử dụng AWS CDK
    code cdk bootstrap
    b. Người dùng hiện có thể tổng hợp mẫu CloudFormation cho mã này. Các biến môi trường bổ sung trước khi cdk synth sẽ loại bỏ các cảnh báo. Quá trình triển khai sẽ mất khoảng 10 phút để hoàn tất lần triển khai đầu tiên.
    code JSII_DEPRECATED=quiet JSII_SILENCE_WARNING_UNTESTED_NODE_VERSION=quiet cdk synth --no-notices
    c. Thay thế <<resource_name_prefix>> bằng giá trị đã chọn và sau đó chạy:
    code JSII_DEPRECATED=quiet JSII_SILENCE_WARNING_UNTESTED_NODE_VERSION=quiet cdk deploy <<resource_name_prefix>>-S3Stack <<resource_name_prefix>>-ConsumerStack --no-notices

Kiểm thử

1. Kiểm thử ứng dụng với Amazon SES

Trước khi bắt đầu kiểm thử, hãy đảm bảo rằng bộ quy tắc nhận email Amazon SES đã được tạo bởi stack <<resource_name_prefix>>-ConsumerStack đang hoạt động. Chúng ta có thể kiểm tra bằng cách thực hiện lệnh dưới đây và đảm bảo tên trong đầu ra là <<resource_name_prefix>>-rule-setaws ses describe-active-receipt-rule-set. Nếu tên không khớp hoặc đầu ra trống, hãy thực hiện lệnh sau để kích hoạt:

# Replace <<resource_name_prefix>> with resource_name_prefix used in context.json

aws ses set-active-receipt-rule-set --rule-set-name <<resource_name_prefix>>-rule-set

Khi chúng ta có bộ quy tắc chính xác đang hoạt động, chúng ta có thể kiểm thử ứng dụng bằng Amazon SES bằng cách gửi email đến địa chỉ email hoặc miền đã được xác minh trong Amazon SES, điều này sẽ tự động kích hoạt pipeline biên tập. Tiến độ có thể được theo dõi trong bảng DynamoDB <<inventory_table_name>>. Tên bảng inventory có thể được tìm thấy trên tab tài nguyên trong AWS CloudFormation Console cho stack <<resource_name_prefix>>-S3Stack và Logical ID EmailInventoryTable. Một <<case_id>> duy nhất được tạo và sử dụng trong bảng inventory DynamoDB cho mỗi email đang được xử lý. Sau khi biên tập hoàn tất, nội dung email đã được biên tập có thể được tìm thấy trong <<redacted_bucket_name>>/redacted/<<today_date>>/<<case_id>>/email_body/ và các tệp đính kèm đã được biên tập trong <<redacted_bucket_name>>/redacted/<<today_date>>/<<case_id>>/attachments/.

2. Kiểm thử ứng dụng không có Amazon SES

Như đã mô tả trước đó, giải pháp được sử dụng để biên tập bất kỳ dữ liệu PII nào trong nội dung email và tệp đính kèm. Do đó, để kiểm thử ứng dụng, chúng ta cần cung cấp một tệp email cần được biên tập. Chúng ta có thể làm điều đó mà không cần Amazon SES bằng cách tải trực tiếp một tệp email lên raw S3 bucket. Tên raw bucket có thể được tìm thấy trên tab đầu ra trong AWS CloudFormation Console cho stack <<resource_name_prefix>>-S3Stack và Export Name RawBucket. Điều này kích hoạt quy trình làm việc biên tập nội dung email và tệp đính kèm bằng cách thông báo sự kiện S3 kích hoạt Lambda. Để thuận tiện cho bạn, một email mẫu có sẵn trong thư mục infra/pii_redaction/sample_email của repository. Dưới đây là các bước để kiểm thử ứng dụng mà không cần Amazon SES bằng cách sử dụng cùng một tệp email.

# Replace <<raw_bucket>> with raw bucket name created during deployment

aws s3 cp pii_redaction/sample_email/ccvod0ot9mu6s67t0ce81f8m2fp5d2722a7hq8o1 s3://<<raw_bucket>>/domain_emails/

Lệnh trên kích hoạt quá trình biên tập email. Bạn có thể theo dõi tiến độ trong bảng DynamoDB <<inventory_table_name>>. Một <<case_id>> duy nhất được tạo và sử dụng trong bảng inventory DynamoDB cho mỗi email đang được xử lý. Tên bảng inventory có thể được tìm thấy trên tab tài nguyên trong AWS CloudFormation Console cho stack <<resource_name_prefix>>-S3Stack và Logical ID EmailInventoryTable. Sau khi biên tập hoàn tất, nội dung email đã được biên tập có thể được tìm thấy trong <<redacted_bucket_name>>/redacted/<<today_date>>/<<case_id>>/email_body/ và các tệp đính kèm đã được biên tập trong <<redacted_bucket_name>>/redacted/<<today_date>>/<<case_id>>/attachments/.

Thiết lập Portal

Việc cài đặt portal là hoàn toàn tùy chọn. Phần này có thể được bỏ qua; kiểm tra console của tài khoản AWS nơi giải pháp được triển khai để xem các tài nguyên đã tạo. Portal đóng vai trò là giao diện web để quản lý các email đã được biên tập PII được xử lý bởi hạ tầng AWS backend, cho phép người dùng xem nội dung email đã được làm sạch. Portal có thể được sử dụng để:

• Liệt kê tin nhắn: Xem các email đã xử lý với nội dung đã được biên tập
• Chi tiết tin nhắn: Xem nội dung email và tệp đính kèm riêng lẻ

Điều kiện tiên quyết của Portal: Portal này yêu cầu cài đặt các công cụ phần mềm sau:

• TypeScript
• Node v18 hoặc cao hơn
• NPM v9.8 hoặc cao hơn

Triển khai hạ tầng

1. Tổng hợp mẫu CloudFormation cho mã này bằng cách đi đến thư mục gốc của giải pháp. Bây giờ chạy lệnh sau:
   code cd sample-bda-redaction/infra/
2. Tùy chọn: Tạo và kích hoạt môi trường ảo Python mới (nếu môi trường ảo chưa được tạo trước đó):
   python python3 -m venv .venv. .venv/bin/activatepip install -r requirements.txt
3. Người dùng hiện có thể tổng hợp mẫu CloudFormation cho mã này.
   code JSII_DEPRECATED=quiet JSII_SILENCE_WARNING_UNTESTED_NODE_VERSION=quiet cdk synth --no-notices
4. Triển khai portal dựa trên React. Thay thế <<resource_name_prefix>> bằng giá trị đã chọn:
   code JSII_DEPRECATED=quiet JSII_SILENCE_WARNING_UNTESTED_NODE_VERSION=quiet cdk deploy <<resource_name_prefix>>-PortalStack --no-notices

Lần triển khai đầu tiên sẽ mất khoảng 10 phút để hoàn tất.

Biến môi trường

1. Tạo một tệp môi trường mới bằng cách đi đến thư mục gốc của thư mục app và cập nhật các biến sau trong tệp .env (bằng cách sao chép tệp .env.example sang .env) bằng cách sử dụng lệnh sau để tạo tệp .env bằng môi trường terminal/CLI.
   code cp .env.example .env
2. Tệp cũng có thể được tạo bằng trình soạn thảo văn bản ưa thích của bạn.

Triển khai Portal

Chạy các lệnh sau từ môi trường terminal/CLI.

1. Trước khi chạy bất kỳ lệnh nào sau đây, hãy đi đến thư mục gốc của thư mục app để xây dựng ứng dụng này cho sản xuất bằng cách chạy các lệnh sau:
   a. Cài đặt các gói NPM
   code npm install
   b. Xây dựng các tệp
   code npm run build
2. Sau khi xây dựng thành công, chuyển tất cả các tệp trong thư mục dist/ vào S3 bucket được chỉ định cho các tài sản này (được chỉ định trong PortalStack được cung cấp qua CDK).
   a. Ví dụ: aws s3 sync dist/ s3://<<name-of-s3-bucket>> --delete<<name-of-s3-bucket>> là S3 bucket đã được tạo trong stack CloudFormation <<resource-name-prefix>>-PortalStack với Logical ID là PrivateWebHostingAssets. Giá trị này có thể được lấy từ tab Resources của stack CloudFormation trong AWS Console. Giá trị này cũng được xuất trong quá trình cdk deploy khi PortalStack đã hoàn thành thành công.

Truy cập portal

Sử dụng URL gọi API Gateway từ API Gateway đã được tạo trong quá trình cdk deploy để truy cập portal từ trình duyệt web. URL này có thể được tìm thấy bằng cách làm theo các bước sau:

1. Truy cập AWS Console
2. Đi đến API Gateway và tìm API Gateway đã được tạo trong quá trình cdk deploy. Tên của API Gateway có thể được tìm thấy trong phần Resources của stack CloudFormation <<resource-name-prefix>>-PortalStack.
3. Nhấp vào liên kết Stages trong menu bên trái.
4. Đảm bảo rằng stage portal được chọn
5. Tìm Invoke URL và sao chép giá trị đó
6. Nhập giá trị đó vào thanh địa chỉ của trình duyệt web của bạn

Giao diện người dùng của portal hiện có thể nhìn thấy trong trình duyệt web. Nếu bất kỳ email nào đã được xử lý, chúng sẽ được liệt kê trên trang chủ của portal.

Kiểm soát truy cập (tùy chọn)

Đối với triển khai sản xuất, chúng tôi khuyên dùng các phương pháp này để kiểm soát và quản lý quyền truy cập vào Portal.

Dọn dẹp

Để tránh phát sinh chi phí trong tương lai, hãy làm theo các bước sau để xóa các tài nguyên được tạo bởi giải pháp này:

1. Xóa nội dung của các S3 bucket được tạo bởi giải pháp:
   • Raw email bucket
   • Redacted email bucket
   • Portal static assets bucket (nếu portal đã được triển khai)
2. Xóa hoặc vô hiệu hóa bước quy tắc Amazon SES được tạo bởi giải pháp bằng lệnh cli dưới đây: #to disable the rule set use below command aws ses set-active-receipt-rule-set #to delete the rule set use below command # Replace <<resource_name_prefix>> with resource_name_prefix used in context.json aws ses delete-receipt-rule-set --rule-set-name <resource_name_prefix>>-rule-set
3. Xóa các stack CloudFormation theo thứ tự sau:
   code cdk destroy <<resource_name_prefix>>-PortalStack (if deployed) cdk destroy <<resource_name_prefix>>-ConsumerStack cdk destroy <<resource_name_prefix>>-S3Stack
4. CDK Destroy không xóa S3 bucket nhật ký truy cập được tạo như một phần của triển khai. Người dùng có thể truy cập tên bucket nhật ký trong tab đầu ra của stack <<resource_name_prefix>>-S3Stack với tên xuất AccessLogsBucket. Thực hiện các bước dưới đây để xóa bucket nhật ký truy cập:
   • Để xóa nội dung của bucket nhật ký truy cập, hãy làm theo hướng dẫn xóa S3 bucket
   • Quyền truy cập vào bucket nhật ký được bật phiên bản và việc xóa nội dung của bucket trong bước trên không xóa các đối tượng được phiên bản trong bucket. Điều đó cần được xóa riêng bằng các lệnh aws cli dưới đây:
   #to remove versioned objects use below aws cli command aws s3api delete-objects --bucket ${accesslogbucket} --delete "$(aws s3api list-object-versions --bucket ${accesslogbucket} --query='{Objects: Versions[].{Key:Key,VersionId:VersionId}}')" #once versioned objects are removed we need to remove the delete markers of the versioned objects using below aws cli command aws s3api delete-objects --bucket ${accesslogbucket} --delete "$(aws s3api list-object-versions --bucket ${accesslogbucket} --query='{Objects: DeleteMarkers[].{Key:Key,VersionId:VersionId}}')"
   • Xóa S3 bucket nhật ký truy cập bằng lệnh aws cli dưới đây:
   #delete the access log bucket itself using below aws cli command aws s3api delete-bucket --bucket ${accesslogbucket}
5. Nếu Amazon SES được cấu hình:
   a. Xóa các miền/địa chỉ email đã được xác minh
   b. Xóa các bản ghi MX khỏi nhà cung cấp DNS của bạn
   c. Xóa thông tin xác thực SMTP khỏi AWS Secrets Manager
6. Xóa bất kỳ nhóm nhật ký CloudWatch nào được tạo bởi các hàm Lambda

VPC và các tài nguyên liên quan của nó như là điều kiện tiên quyết cho giải pháp này có thể không bị xóa nếu chúng có thể được sử dụng bởi các ứng dụng khác.

Kết luận

Trong bài viết này, chúng tôi đã trình bày cách tự động phát hiện và biên tập PII trên cả nội dung văn bản và hình ảnh bằng cách sử dụng Amazon Bedrock Data Automation và Amazon Bedrock Guardrails. Bằng cách tập trung và hợp lý hóa quy trình biên tập, các tổ chức có thể tăng cường sự phù hợp với các yêu cầu về quyền riêng tư dữ liệu, nâng cao các thực hành bảo mật và giảm thiểu chi phí vận hành.

Tuy nhiên, điều quan trọng không kém là đảm bảo rằng giải pháp của bạn được xây dựng với các ràng buộc xử lý tài liệu của Amazon Bedrock Data Automation. Amazon Bedrock Data Automation hỗ trợ các định dạng tệp PDF, JPEG và PNG với kích thước xử lý tối đa trên console là 200 MB (500 MB qua API), và các tài liệu đơn lẻ không được vượt quá 20 trang trừ khi tính năng chia tài liệu được bật.

Bằng cách sử dụng các khả năng biên tập tập trung của Amazon Bedrock Data Automation và Amazon Bedrock Guardrails, các tổ chức có thể tăng cường quản lý tuân thủ quyền riêng tư dữ liệu, cắt giảm chi phí vận hành và duy trì bảo mật nghiêm ngặt trên các khối lượng công việc đa dạng. Khả năng mở rộng của giải pháp này còn cho phép tích hợp với các dịch vụ AWS khác, tinh chỉnh logic phát hiện cho các mẫu PII nâng cao hơn và mở rộng hỗ trợ cho các loại tệp hoặc ngôn ngữ bổ sung trong tương lai, từ đó phát triển thành một khung bảo vệ dữ liệu cấp doanh nghiệp mạnh mẽ hơn.

Chúng tôi khuyến khích khám phá kho lưu trữ GitHub được cung cấp để triển khai giải pháp này trong tổ chức của bạn. Ngoài việc mang lại hiệu quả vận hành, khả năng mở rộng, bảo mật và khả năng thích ứng, giải pháp còn cung cấp một giao diện thống nhất và nhật ký kiểm toán mạnh mẽ giúp đơn giản hóa quản trị dữ liệu. Bằng cách tinh chỉnh các quy tắc phát hiện, người dùng có thể tích hợp các định dạng tệp bổ sung nếu có thể và sử dụng khung mô-đun của Amazon Bedrock Data Automation và Amazon Bedrock Guardrails.

Chúng tôi mời bạn triển khai giải pháp phát hiện và biên tập PII này trong kho lưu trữ GitHub sau đây để xây dựng một giải pháp bảo vệ dữ liệu an toàn hơn, tuân thủ hơn và có khả năng thích ứng cao trên Amazon Bedrock, đáp ứng các yêu cầu kinh doanh và quy định đang phát triển.

Về tác giả

Himanshu Dixit là Chuyên gia tư vấn triển khai tại AWS Professional Services, chuyên về cơ sở dữ liệu và phân tích, với hơn 18 năm kinh nghiệm trong lĩnh vực công nghệ. Anh đam mê trí tuệ nhân tạo, học máy và AI tạo sinh, tận dụng các công nghệ tiên tiến này để tạo ra các giải pháp đổi mới nhằm giải quyết các thách thức thực tế mà khách hàng phải đối mặt. Ngoài công việc, anh thích chơi cầu lông, quần vợt, cricket, bóng bàn và dành thời gian cho hai cô con gái của mình.

David Zhang là Giám đốc dự án tại AWS Professional Services, nơi anh dẫn dắt các sáng kiến chuyển đổi AI/ML và đám mây quy mô doanh nghiệp cho các khách hàng Fortune 100 trong lĩnh vực viễn thông, tài chính, truyền thông và giải trí. Ngoài công việc, anh thích thử nghiệm các công thức nấu ăn mới trong bếp, chơi kèn tenor saxophone và ghi lại những khoảnh khắc cuộc sống qua máy ảnh của mình.

Richard Session là Nhà phát triển giao diện người dùng chính cho AWS ProServe, mang đến hơn 15 năm kinh nghiệm với tư cách là nhà phát triển full-stack trong các ngành tiếp thị/quảng cáo, công nghệ doanh nghiệp, ô tô và thương mại điện tử. Với niềm đam mê tạo ra trải nghiệm người dùng trực quan và hấp dẫn, anh sử dụng nền tảng kiến thức sâu rộng của mình để tạo ra các giao diện đặc biệt cho khách hàng doanh nghiệp của AWS. Khi không thiết kế trải nghiệm người dùng sáng tạo, Richard có thể được tìm thấy đang theo đuổi tình yêu cà phê, chơi nhạc với tư cách là một DJ hoặc khám phá những điểm đến mới trên toàn cầu.

Viyoma Sachdeva là Chuyên gia Công nghiệp chính tại AWS. Cô chuyên về AWS DevOps, containerization và IoT, giúp khách hàng đẩy nhanh hành trình lên AWS Cloud.

TAGS: Generative AI