Bảo mật dữ liệu nhạy cảm trong CloudWatch Logs cho API

😬 Vấn đề

Hãy tưởng tượng bạn đã xây dựng một API tuyệt vời mà mọi người đều yêu thích. Cuộc sống thật tuyệt vời, cho đến một ngày bạn nhìn vào CloudWatch Logs và — BAM 💥 — điều khiến bạn sốc chính là… thông tin đăng nhập của người dùng. Mật khẩu, token, có thể cả số thẻ ngân hàng. Đó không phải là loại bất ngờ mà bạn muốn thấy trong nhật ký của mình, đặc biệt khi các nhà quản lý (và đội ngũ bảo mật của bạn) đang theo dõi.

Mặc dù tôi rất yêu CloudWatch để gỡ lỗi và giám sát, nhưng không ai muốn nhật ký sản xuất của mình trông giống như một cuốn nhật ký mở chứa đầy dữ liệu nhạy cảm của người dùng. Trong lĩnh vực fintech, đó là một điều cấm kỵ (hãy nghĩ đến PCI, GDPR, SOC2).

🎯 Nhiệm vụ

Nhiệm vụ của tôi là rõ ràng: 👉 Bảo mật dữ liệu nhạy cảm (như mật khẩu, token, chi tiết thẻ) trong CloudWatch Logs — đồng thời vẫn giữ cho nhật ký hữu ích cho việc gỡ lỗi.
Thách thức thêm: tạo ra một giải pháp có thể mở rộng, dễ sử dụng cho người mới, và thú vị.

🛠️ Giải pháp

1. Đầu tiên, một cái nhìn tổng quan

CloudWatch Logs là gì?
CloudWatch Logs giống như một máy ghi âm đen của ứng dụng bạn — mỗi cuộc gọi API, lỗi và dòng gỡ lỗi có thể lưu trữ ở đây. - Bạn có thể luồng nhật ký từ API Gateway, Lambda, ECS, EC2, bất kỳ thứ gì bạn cần. - Bạn có thể tìm kiếm chúng trong CloudWatch Insights hoặc gửi chúng đến OpenSearch để thực hiện các truy vấn theo kiểu SQL. - Bạn thậm chí có thể thiết lập cảnh báo khi mọi thứ diễn ra không như ý.
Nhưng — và đây là một điểm quan trọng — theo mặc định, CloudWatch ghi lại mọi thứ bạn gửi cho nó. Nếu bạn gửi mật khẩu, nó sẽ lưu trữ mật khẩu mà không hề do dự. 🙈

2. Khoảnh khắc “Aha!” của tôi

Chính sách bảo vệ dữ liệu CloudWatch
Thay vì viết các script regex phức tạp hoặc tái cấu trúc middleware ghi nhật ký, AWS hiện cung cấp cho chúng ta các Chính sách Bảo vệ Dữ liệu cho các nhóm nhật ký.

Hãy nghĩ về nó như một bộ lọc bí mật trên nhật ký của bạn:

Bạn cho CloudWatch biết các mẫu dữ liệu nhạy cảm nào cần tìm kiếm.
Nó sử dụng các định danh dữ liệu quản lý (ví dụ: thẻ tín dụng, khóa AWS, email, v.v.).
Khi tìm thấy một kết quả phù hợp → nó sẽ tự động được bảo mật (như ****).
Chỉ những người dùng có quyền đặc biệt logs:Unmask mới có thể xem các giá trị gốc.

Khi bạn tạo một chính sách bảo vệ dữ liệu trong AWS Console, bạn sẽ trải qua một số tùy chọn:

Định danh Dữ liệu Quản lý

AWS cung cấp một danh sách dài các loại dữ liệu đã được cấu hình sẵn (khóa AWS, số tài chính, PII, PHI, v.v.) mà bạn có thể chọn thông qua các hộp kiểm.
Bạn cũng có thể định nghĩa các định danh dữ liệu tùy chỉnh bằng regex nếu bạn cần điều gì đó mà AWS không cung cấp.

Kiểm tra so với Bảo mật (Định danh lại)

Kiểm tra: Phát hiện và ghi lại các phát hiện dữ liệu nhạy cảm mà không làm thay đổi nhật ký. Tuyệt vời cho việc phát hiện — bạn có thể xem nơi nào bí mật xuất hiện trước khi quyết định bảo mật.
Định danh lại (Bảo mật): Thực sự xóa bỏ các giá trị đó, vì vậy chúng xuất hiện dưới dạng **** ở mọi nơi nhật ký được tiêu thụ. Điều này đảm bảo rằng bí mật không bao giờ tồn tại mà không được bảo mật trong CloudWatch.

Điểm đến của các phát hiện

Nếu bạn chọn Kiểm tra, bạn có thể chuyển hướng các phát hiện kiểm tra đến một nhóm nhật ký khác, bucket S3, hoặc Kinesis Firehose. Hữu ích cho các báo cáo tuân thủ.
Nếu bạn không chỉ định, có thể để trống ({}), có nghĩa là không có điểm đến đặc biệt nào.

Áp dụng Chính sách

Sau khi bạn lưu chính sách, chỉ những nhật ký mới được nhập vào sẽ được quét và bảo mật. Các nhật ký cũ sẽ không được thay đổi ngược lại.
Việc bảo mật chỉ hoạt động trên các nhóm lớp nhật ký tiêu chuẩn.
Ngoài ra, các mảng DataIdentifier trong các câu lệnh Kiểm tra và Định danh lại phải khớp chính xác; nếu không, AWS sẽ từ chối chính sách.

Dưới đây là một mẫu chính sách kết hợp cả kiểm tra và bảo mật:

json Copy

{
"Name": "data-protection-policy",
"Description": "",
"Version": "2021-06-01",
"Statement": [
{
"Sid": "audit-policy",
"DataIdentifier": [
"arn:aws:dataprotection::aws:data-identifier/AwsSecretKey",
"arn:aws:dataprotection::aws:data-identifier/BankAccountNumber-FR"
],
"Operation": {
"Audit": {
"FindingsDestination": {}
}
}
},
{
"Sid": "redact-policy",
"DataIdentifier": [
"arn:aws:dataprotection::aws:data-identifier/AwsSecretKey",
"arn:aws:dataprotection::aws:data-identifier/BankAccountNumber-FR"
],
"Operation": {
"Deidentify": {
"MaskConfig": {}
}
}
}
]
}

Sử dụng nhật ký sau khi bảo mật

Khi các nhật ký đã được bảo mật, bạn vẫn có thể sử dụng chúng như thường lệ: - CloudWatch Logs Insights → thực hiện các truy vấn như:

sql Copy

fields @timestamp, @message
  | filter @message like /ERROR/
  | sort @timestamp desc
  | limit 20

OpenSearch SQL → thậm chí còn tinh vi hơn! Bạn có thể kết nối nhóm nhật ký của mình với OpenSearch và truy vấn như:

sql Copy

SELECT
    requestId,
    httpMethod,
    status,
    message
  FROM apigateway_logs
  WHERE status >= 500
  ORDER BY timestamp DESC
  LIMIT 10;

Các trường đã được bảo mật vẫn hiện ra dưới dạng ****, có nghĩa là bạn vẫn duy trì khả năng gỡ lỗi mà không làm lộ bí mật.

✅ Kết quả

Không còn dữ liệu nhạy cảm (mật khẩu, token, PAN) rò rỉ vào nhật ký.
Đội ngũ bảo mật và tuân thủ = những người hạnh phúc.
Các nhà phát triển vẫn nhận được nhật ký hữu ích cho việc gỡ lỗi.
Còn tôi? Tôi ngủ ngon hơn vào ban đêm khi biết rằng sẽ không phải thức dậy với một phiếu tuân thủ.

😂 Kết luận thú vị

Hãy nghĩ về CloudWatch Data Protection như một bộ lọc tự động trên TV trực tiếp. Nhật ký của bạn có thể vẫn gây cấn, nhưng ít nhất chúng sẽ PG-13 thay vì Rated R cho những cơn ác mộng tuân thủ.

Vì vậy, nếu bạn đang vận hành một API fintech (hoặc thực sự bất kỳ API nào), hãy làm cho bản thân một ân huệ — để CloudWatch giữ nhật ký, nhưng bảo mật các bí mật. Dù sao, những gì xảy ra trong nhật ký sản xuất nên ở lại trong nhật ký sản xuất... một cách an toàn.

Bạn nghĩ sao? Bạn đã thử CloudWatch Data Protection chưa, hay vẫn phụ thuộc vào việc bảo mật tùy chỉnh? Tôi rất muốn nghe cách bạn xử lý vệ sinh nhật ký trong hệ thống của bạn!