Dịch vụ Amazon Simple Notification Service (SNS) hiện đã chính thức hỗ trợ bảo vệ dữ liệu tin nhắn và cung cấp tính năng thời gian thực để ẩn thông tin và che giấu dữ liệu. Thêm thông tin, vui lòng xem “Bảo vệ dữ liệu tin nhắn” trong Hướng dẫn phát triển Amazon SNS.
Bài viết này được viết bởi Otavio Ferreira, Senior Software Development Manager, Marc Pinaud, Senior Product Manager, Usman Nisar, Senior Software Engineer, Hardik Vasa, Senior Solutions Architect, and Mithun Mallick, Senior Specialist Solution Architect.
Hôm nay, chúng tôi công bố phiên bản xem trước công khai các khả năng bảo vệ dữ liệu mới cho dịch vụ Amazon Simple Notification Service (SNS), được gọi là bảo vệ dữ liệu tin nhắn. Đây là một cách mới để khám phá và bảo vệ dữ liệu nhạy cảm trong quá trình truyền tải với quy mô lớn, mà không cần phải viết mã tùy chỉnh.
SNS là một dịch vụ gửi tin nhắn serverless được quản lý hoàn toàn. Nó cung cấp các chủ đề cho việc gửi tin nhắn push-based, pub/sub cho nhiều người dùng nhằm tách rời các hệ thống phân phối, microservices, và ứng dụng serverless đưa trên sự kiện. Khi ứng dụng mở rộng, lượng dữ liệu được truyền và số hệ thống gửi và nhận dữ liệu cũng tăng lên. Khi chuyển dữ liệu giữa các ứng dụng khác nhau, guardrails có thể giúp bạn tuân thủ các quy định bảo vệ quyền riêng tư dữ liệu yêu cầu bạn bảo vệ thông tin nhạy cảm như thông tin nhận dạng cá nhân (PII) hoặc thông tin sức khỏe được bảo vệ (PHI).
Với chức năng bảo vệ dữ liệu tin nhắn cho SNS, bạn có thể quét các tin nhắn thời gian thực để tìm kiếm dữ liệu PII/PHI và nhận báo cáo kiểm toán chứa kết quả quét. Bạn cũng có thể ngăn ứng dụng nhận dữ liệu nhạy cảm bằng cách chặn các tin nhắn đầu vào đến một chủ đề SNS hoặc các tin nhắn đầu ra đến một đăng ký SNS. Chức năng bảo vệ dữ liệu tin nhắn cho SNS hỗ trợ khoảng 25 người dùng độc nhất và các thông tin bảo vệ sức khỏe khác. Chúng bao gồm tên người, địa chỉ, số an sinh xã hội, số thẻ tín dụng và mã thuốc kê đơn.
Các khả năng này có thể giúp bạn tuân theo nhiều quy định về tuân thủ, bao gồm HIPAA, FedRAMP, GDPR, và PCI. Để biết thêm thông tin, bao gồm danh sách đầy đủ các nhận dạng dữ liệu được hỗ trợ, hãy xem chức năng bảo vệ dữ liệu tin nhắn trong SNS Developer Guide.
Tổng quan
Chủ đề SNS cho phép bạn tích hợp các ứng dụng phân tán dễ dàng hơn. Khi các ứng dụng trở nên phức tạp hơn, việc quản lý dữ liệu chảy qua các chủ đề của chủ sở hữu có thể trở nên khó khăn. Các nhà phát triển đăng tải thông điệp đến một chủ đề có thể vô tình gửi dữ liệu nhạy cảm, tăng cường rủi ro tuân thủ quy định. Bảo vệ dữ liệu tin nhắn cho phép chủ sở hữu chủ đề SNS bảo vệ dữ liệu ứng dụng nhạy cảm với khả năng mở rộng tích hợp sẵn, không cần mã, không cần mã hóa.
Để khám phá và bảo vệ dữ liệu chảy qua các chủ đề SNS với bảo vệ dữ liệu tin nhắn, chủ sở hữu chủ đề liên kết chính sách bảo vệ dữ liệu với chủ đề của họ. Trong các chính sách này, bạn có thể viết các câu lệnh xác định loại dữ liệu nhạy cảm mà bạn muốn khám phá và bảo vệ. Như một phần của việc này, bạn có thể xác định liệu bạn muốn thực hiện trên dữ liệu đang chảy vào một chủ đề hay ra khỏi một đăng ký, tài khoản AWS nào hoặc các chủ thể quản lý truy cập AWS Identity and Access Management (AWS IAM) cụ thể nào mà chính sách được áp dụng và các hành động bạn muốn thực hiện trên dữ liệu.
Bảo vệ dữ liệu thông điệp cung cấp hai hành động để giúp bạn bảo vệ dữ liệu của mình. Kiểm toán, để báo cáo số lượng PII/PHI được tìm thấy, và chặn, để ngăn việc xuất bản hoặc giao nhận các thông điệp chứa dữ liệu PII/PHI. Khi đặt chính sách bảo vệ dữ liệu, bảo vệ dữ liệu thông điệp sử dụng khớp mẫu và mô hình học máy để quét các thông điệp của bạn theo thời gian thực để tìm kiếm các nhận dạng dữ liệu PII/PHI và thi hành chính sách bảo vệ dữ liệu.
Đối với kiểm toán, bạn có thể chọn gửi báo cáo kiểm toán đến Amazon Simple Storage Service (S3) để lưu trữ, Amazon Kinesis Data Firehose để phân tích hoặc Amazon CloudWatch để đăng nhập và cảnh báo. Bảo vệ dữ liệu thông điệp không can thiệp vào khả năng của chủ sở hữu chủ đề sử dụng mã hóa dữ liệu thông điệp khi nghỉ ngơi, cũng như khả năng của người đăng ký để lọc các thông điệp không mong muốn bằng cách sử dụng bộ lọc thông điệp.
Áp dụng bảo vệ dữ liệu tin nhắn trong một trường hợp sử dụng
Hãy xem xét một ứng dụng xử lý các giao dịch khác nhau cho một tập hợp các phòng khám sức khỏe, một tổ chức hoạt động trong một môi trường được quy định. Khung thực hiện yêu cầu tổ chức đưa ra các biện pháp để bảo vệ cả hồ sơ sức khỏe nhạy cảm và thông tin tài chính.
Ứng dụng này dựa trên kiến trúc serverless dựa trên sự kiện. Nó có một chính sách bảo vệ dữ liệu được đính kèm vào chủ đề để kiểm toán cho dữ liệu nhạy cảm và ngăn các hệ thống phía dưới xử lý một số loại dữ liệu.
Ứng dụng xuất bản một sự kiện đến một chủ đề SNS mỗi khi một bệnh nhân đặt lịch hẹn hoặc gặp bác sĩ tại một phòng khám. Chủ đề SNS truyền ra sự kiện đến hai hệ thống đã đăng ký, hóa đơn và lịch hẹn. Mỗi hệ thống lưu trữ sự kiện trong một queue Amazon SQS, được xử lý bằng một chức năng AWS Lambda
Thiết lập chính sách bảo vệ dữ liệu cho một chủ đề SNS
Bạn có thể áp dụng chính sách bảo vệ dữ liệu cho một chủ đề SNS bằng cách sử dụng AWS Management Console, AWS CLI hoặc các SDK của AWS. Bạn cũng có thể sử dụng AWS CloudFormation để tự động hóa việc cung cấp chính sách bảo vệ dữ liệu.
Ví dụ này sử dụng CloudFormation để cung cấp cơ sở hạ tầng. Bạn có hai lựa chọn để triển khai các tài nguyên:
- Triển khai các tài nguyên bằng cách sử dụng kịch bản triển khai bảo vệ dữ liệu tin nhắn trong kho aws-sns-samples trên GitHub.
- Hoặc sử dụng bốn mẫu CloudFormation sau theo thứ tự. Cho phép thời gian cho mỗi ngăn xếp hoàn thành trước khi triển khai ngăn xếp tiếp theo.
- Khi triển khai các mẫu người đăng ký Lập lịch và Thanh toán, bạn phải cấu hình CloudFormation để triển khai tài nguyên bằng cách sử dụng các vai trò IAM tương ứng đã được tạo trong bước đầu tiên. Để làm điều này, chọn vai trò IAM tương ứng cho mẫu bạn đang chạy khi được nhắc để Cấu hình tùy chọn ngăn xếp trong bảng điều khiển CloudFormation, như được hiển thị dưới đây.
- Mẫu yêu cầu tiên quyết (lưu ý hai vai trò IAM được tạo ra, bạn phải sử dụng chúng trong các bước 3 & 4)
- Hai vai trò IAM có chính sách quản lý cho phép truy cập nhận thông báo từ chủ đề SNS, một cho hệ thống thanh toán và một cho hệ thống lập lịch, tương ứng.
- Chủ đề SNS gửi sự kiện đến hai hệ thống khác nhau.
- Chính sách bảo vệ dữ liệu xác định cả hành động giám sát và chặn cho các loại thông tin cá nhân nhạy cảm và thông tin y tế được chỉ định.
- Bucket S3 để lưu trữ kết quả giám sát.
- Nhóm nhật ký CloudWatch để giám sát kết quả giám sát.
- Dòng dữ liệu Kinesis Data Firehose để chuyển kết quả giám sát đến các đích khác.
- Mẫu đăng ký lịch trình (khi triển khai mẫu này, bạn phải sử dụng vai trò IAM mà chúng tôi tạo cho hệ thống lập lịch)\
- queue SQS cho hệ thống lập lịch.
- Hàm Lambda cho hệ thống lập lịch.
- Mẫu đăng ký thanh toán (khi triển khai mẫu này, bạn phải sử dụng vai trò IAM mà chúng tôi tạo cho hệ thống thanh toán)
- queue SQS cho hệ thống thanh toán.
- Hàm Lambda cho hệ thống thanh toán.
CloudFormation tạo chính sách bảo vệ dữ liệu sau đây như một phần của mẫu chủ sở hữu chủ đề:
YAML
ClinicSNSTopic:
Type: ‘AWS::SNS::Topic’
Properties:
TopicName: SampleClinic
DataProtectionPolicy:
Name: data-protection-example-policy
Description: Policy Description
Version: 2021-06-01
Statement:
– Sid: audit
DataDirection: Inbound
Principal:
– ‘*’
DataIdentifier:
– ‘arn:aws:dataprotection::aws:data-identifier/Address’
– ‘arn:aws:dataprotection::aws:data-identifier/AwsSecretKey’
– ‘arn:aws:dataprotection::aws:data-identifier/DriversLicense-US’
– ‘arn:aws:dataprotection::aws:data-identifier/EmailAddress’
– ‘arn:aws:dataprotection::aws:data-identifier/IpAddress’
– ‘arn:aws:dataprotection::aws:data-identifier/NationalDrugCode-US’
– ‘arn:aws:dataprotection::aws:data-identifier/PassportNumber-US’
– ‘arn:aws:dataprotection::aws:data-identifier/Ssn-US’
Operation:
Audit:
SampleRate: 99
FindingsDestination:
CloudWatchLogs:
LogGroup: !Ref AuditCWLLogs
Firehose:
DeliveryStream: !Ref AuditFirehose
NoFindingsDestination:
S3:
Bucket: !Ref AuditS3Bucket
– Sid: deny-inbound
DataDirection: Inbound
Principal:
– ‘*’
DataIdentifier:
– ‘arn:aws:dataprotection::aws:data-identifier/PassportNumber-US’
– ‘arn:aws:dataprotection::aws:data-identifier/Ssn-US’
Operation:
Deny: {}
– Sid: deny-outbound-billing
DataDirection: Outbound
Principal:
– !ImportValue “BillingRoleExportDataProtectionDemo”
DataIdentifier:
– ‘arn:aws:dataprotection::aws:data-identifier/NationalDrugCode-US’
Operation:
Deny: {}
– Sid: deny-outbound-scheduling
DataDirection: Outbound
Principal:
– !ImportValue “SchedulingRoleExportDataProtectionDemo”
DataIdentifier:
– ‘arn:aws:dataprotection::aws:data-identifier/Address’
– ‘arn:aws:dataprotection::aws:data-identifier/CreditCardNumber’
Operation:
Deny: {}
Chính sách bảo vệ dữ liệu này xác định:
- Thông tin về chính sách bảo vệ dữ liệu, ví dụ như tên, mô tả, phiên bản và ID câu lệnh (sid).
- Câu lệnh đầu tiên (sid: kiểm toán) quét các tin nhắn đến từ tất cả các người sử dụng để tìm kiếm địa chỉ, số an sinh xã hội, giấy phép lái xe, địa chỉ email, địa chỉ IP, mã thuốc quốc gia, số hộ chiếu và các khóa bí mật AWS.
- Tỷ lệ mẫu được đặt là 99% để gần như tất cả các tin nhắn đều được quét để tìm kiếm các thông tin cá nhân và y tế được xác định.
- Kết quả kiểm toán với các kết quả phát hiện được gửi đến CloudWatch Logs và Kinesis Data Firehose để phân tích. Kết quả kiểm toán không phát hiện được lưu trữ trên S3.
- Câu lệnh thứ hai (sid: từ chối tin nhắn đến) chặn các tin nhắn đến cho chủ đề đến từ bất kỳ người sử dụng nào, nếu thông tin tin nhắn bao gồm số an sinh xã hội hoặc số hộ chiếu.
- Câu lệnh thứ ba (sid: từ chối tin nhắn đi của BillingRole) chặn việc gửi tin nhắn đến các đăng ký được tạo bởi BillingRole, nếu tin nhắn bao gồm bất kỳ mã thuốc quốc gia nào.
- Câu lệnh thứ tư (sid: từ chối tin nhắn đi của SchedulingRole) chặn việc gửi tin nhắn đến các đăng ký được tạo bởi SchedulingRole, nếu tin nhắn bao gồm bất kỳ số thẻ tín dụng hoặc địa chỉ nào.
Kiểm thử khả năng bảo vệ dữ liệu
Thực hiện kiểm thử khả năng bảo vệ dữ liệu tin nhắn bằng các bước sau:
- Đăng tải một tin nhắn không có dữ liệu PII/PHI lên chủ đề Clinic. Trong bảng điều khiển CloudWatch, điều hướng đến các luồng nhật ký của các chức năng Lambda tương ứng để xác nhận rằng tin nhắn được gửi đến cả hai người đăng ký. Cả hai tin nhắn đều được gửi đến vì tải trọng không chứa dữ liệu nhạy cảm để chính sách bảo vệ dữ liệu từ chối. Tin nhắn nhật ký có dạng như sau:
“This is a demo! received from queue arn:aws:sqs:us-east-1:111222333444:Scheduling-SchedulingQueue”
- Đăng tải một tin nhắn chứa số Bảo hiểm Xã hội (hãy thử ‘SSN: 123-12-1234’) lên chủ đề Clinic. Yêu cầu sẽ bị từ chối và một nhật ký kiểm tra sẽ được gửi đến nhóm nhật ký CloudWatch Logs và luồng giao hàng Firehose của bạn.
- Điều hướng đến bảng điều khiển nhật ký CloudWatch và xác nhận rằng nhật ký kiểm tra có thể nhìn thấy trong nhóm nhật ký CloudWatch log /aws/vendedlogs/clinicaudit. Ví dụ sau cho thấy rằng chính sách bảo vệ dữ liệu (sid: deny-inbound) từ chối tin nhắn đến khi tải trọng chứa số Bảo hiểm Xã hội (SSN) của Mỹ từ ký tự thứ 5 đến ký tự thứ 15.
JSON
{
“messageId”: “77ec5f0c-5129-5429-b01d-0457b965c0ac”,
“auditTimestamp”: “2022-07-28T01:27:40Z”,
“callerPrincipal”: “arn:aws:iam::111222333444:role/Admin”,
“resourceArn”: “arn:aws:sns:us-east-1:111222333444:SampleClinic”,
“dataIdentifiers”: [
{
“name”: “Ssn-US”,
“count”: 1,
“detections”: [
{
“start”: 5,
“end”: 15
}
]
}
]
}
- Bạn có thể sử dụng các số liệu thống kê CloudWatch, MessageWithFindings và MessageWithNoFindings, để theo dõi tần suất dữ liệu PII/PHI được xuất bản lên chủ đề SNS. Dưới đây là một ví dụ về biểu đồ số liệu thống kê CloudWatch, trong đó số lượng dữ liệu nhạy cảm được xuất bản lên chủ đề thay đổi theo thời gian:
- Đăng một tin nhắn có chứa địa chỉ (thử địa chỉ ‘410 Terry Ave N, Seattle 98109, WA’). Yêu cầu này chỉ được gửi tới đăng ký Billing. Chính sách bảo vệ dữ liệu (sid: deny-outbound-scheduling) từ chối tin nhắn đi đến đăng ký Scheduling vì thông điệp chứa địa chỉ.
- Xác nhận rằng tin nhắn chỉ được gửi đến chức năng Lambda Billing bằng cách điều hướng đến bảng điều khiển CloudWatch và kiểm tra nhật ký của hai chức năng Lambda tương ứng. Nhật ký CloudWatch của chức năng Lambda Billing chứa thông điệp nhạy cảm đã được gửi đến nó vì nó là một đăng ký được ủy quyền. Dưới đây là ví dụ về nhật ký chứa:
410 Terry Ave N, Seattle 98109, WA received from queue arn:aws:sqs:us-east-1:111222333444:Billing-BillingQueue
- Đăng một tin nhắn có mã thuốc (thử mã ‘NDC: 0777-3105-02’). Yêu cầu này chỉ được gửi tới đăng ký Scheduling. Chính sách bảo vệ dữ liệu (sid: deny-outbound-billing) từ chối tin nhắn đi đến đăng ký Billing vì thông điệp chứa mã thuốc.
- Xác nhận rằng tin nhắn chỉ được gửi đến chức năng Lambda Scheduling bằng cách điều hướng đến bảng điều khiển CloudWatch và kiểm tra nhật ký của hai chức năng Lambda tương ứng. Nhật ký CloudWatch của chức năng Lambda Scheduling chứa thông điệp nhạy cảm đã được gửi đến nó vì nó là một đăng ký được ủy quyền. Dưới đây là ví dụ về nhật ký chứa:
NDC: 0777-3105-02 received from queue arn:aws:sqs:us-east-1:111222333444:Scheduling-SchedulingQueue
Dọn dẹp
Sau khi kiểm tra, tránh gây ra các khoản phí sử dụng bằng cách xóa các tài nguyên bạn đã tạo. Truy cập vào bảng điều khiển CloudFormation và xóa bốn CloudFormation stacks mà bạn đã tạo trong quá trình hướng dẫn. Hãy nhớ rằng, trước khi xóa stack, bạn phải xóa tất cả các đối tượng khỏi bucket S3.
Kết luận
Bài viết này cho thấy cách bảo vệ dữ liệu tin nhắn cho phép chủ chủ đề khám phá và bảo vệ dữ liệu nhạy cảm được trao đổi qua các chủ đề SNS. Ví dụ cho thấy cách tạo chính sách bảo vệ dữ liệu tạo báo cáo kiểm toán cho dữ liệu nhạy cảm và chặn tin nhắn khỏi việc gửi đến các đăng ký cụ thể nếu tải lên chứa dữ liệu nhạy cảm.
Bắt đầu với SNS và bảo vệ dữ liệu tin nhắn bằng cách sử dụng AWS Management Console, AWS Command Line Interface (CLI), AWS SDKs hoặc CloudFormation.
Để biết thêm chi tiết, xem bảo vệ dữ liệu tin nhắn trong SNS Developer Guide. Để biết thông tin về giá cả, xem chi phí của SNS.
Để tìm nguồn tài nguyên học tập về serverless, truy cập Serverless Land.
AWS Study Group 