AWS Study Group

Chuỗi bài về hành trình thích ứng Kiến trúc Cloud-Native: Bài #5 – Mở rộng dò tìm đe doạ, bảo vệ dữ liệu và phản hồi sự cố 

Trong phần 4 của chuỗi bài này, Quản trị bảo mật ở quy mô và thiết lập IAM, chúng ta đã thảo luận về xây dựng chiến lược đa tài khoản, nâng cao quản trị truy xuất và phân quyền ít để ngăn cản các truy xuất không mong muốn và tuân thủ kiểm soát bảo mật.

Một chút nhắc lại về tình huống chúng ta trao đổi trong chuỗi bài này là về một hệ thống thương mai điện tử có nhu cầu về siêu tăng trưởng (gấp 10 lần vào giờ cao điểm), chúng ta cũng đã bàn về các thử thách về mặt kỹ thuật và nền tảng và cách để mở rộng back-end ứng dụng mà không ảnh hưởng trải nghiệm của người dùng.

Với tốc độ triển khai phần mềm và hạ tầng mới, chúng tôi phải đảm bảo duy trì bảo mật ở mức độ cao. Trong bài viết này, phần thứ 05 chúng tôi sẽ chia sẻ cách dò tìm các lỗi cấu hình bảo mật sai, những chỉ định thoả hiệp, và những hoạt động bất thường. Chúng tôi cũng chia sẻ cách chúng tôi đã phát triển và lặp đi lặp lại quy trình phản hồi sự cố.

Dò tìm đe doạ và bảo vệ dữ liệu 

Đối với những khách hàng mới trong giai đoạn siêu tăng trưởng, chúng tôi vẫn phải đảm bảo sự tin cậy khách hàng. Chúng tôi cần phải dò tìm và phản hồi các sự kiện về mặt bảo mật nhanh chóng để giảm thiểu phạm vi và tầm ảnh hưởng của bất kỳ hành động nào không được cho phép. Chúng tôi băn khoăn về các lỗ hổng bảo mật với những máy chủ web công cộng, dữ liệu nhạy cảm bị phơi bày ra hay bất kể các lỗi cấu hình sai dẫn đến lỗ hổng về bảo mật.

Trước giai đoạn siêu tăng trưởng, đội ngũ ứng dụng quét các lỗ hổng và duy trì trạng thái bảo mật của ứng dụng. Sau giai đoạn siêu tăng trưởng, chúng tôi đã thiết lập đội bảo mật chuyên biệt và xác định các công cụ để đơn giản hoá việc quản trị bảo mật đám mây. Điều này giúp chúng tôi dễ dàng định danh và ưu tiên những rủi ro về mặt bảo mật.

Sử dụng dịch vụ AWS để dò tìm đe doạ và lỗi cấu hình 

Chúng tôi sử dụng các dịch vụ bảo mật của AWS để đơn giản hoá quản trị và giảm thiểu những gánh nặng tích hợp với bên dứng dụng thứ ba. Điều này cũng giúp tiết kiệm thời gian và công sức của đội ngũ kỹ thuật bảo mật.

Dò tìm đe doạ với Amazon GuardDuty 

Chúng tôi sử dụng Amazon GuardDuty để đảm bảo những chiến thuật, kỹ thuật và thủ tục (TTPs) mới nhất cũng như các chỉ định về thoả hiệp (IOCs – Indicators of Compromise).

GuardDuty tiết kiệm thời gian và giảm thiểu sự phức tạp bởi vì chúng tôi không có các kỹ sư chuyên biệt cho việc liên tục dò tìm lỗi với TTPs và IOCs mới với những sự kiện tĩnh và dò tìm dựa trên học máy. Điều này cho phép đội ngũ bảo mật phân tích tập trung xây dựng Runbooks và nhanh chóng phản hồi dựa trên các phát hiện bảo mật.

Phát hiện các dữ liệu nhạy cảm với Amazon Macie trong Amazon S3

Để host các website công cộng chúng tôi sử dụng một vài Amazon S3 bucket với chính sách công cộng. Chúng tôi không muốn các lập trình viên đưa các dữ liệu nhạy cảm lên Amazon S3 bucket và chúng tôi muốn biết Bucket nào chứa đựng các thông tin nhạy cảm như là các thông tin tài chính, định danh cá nhân (PII – Personal Identifiable Information).

Trước kia chúng tôi đã xây dựng công cụ để quét những dữ liệu nhạy cảm này nhưng việc duy trì các khuôn mẫu về quét dữ liệu cũng như việc phải quét lại toàn bộ dữ liệu hàng tháng tốn kém chi phí và thời gian. Vì thế chúng tôi đã sử dụng Amazon Macie trong việc quét dữ liệu trong Amazon S3 bucket liên tục. Sau khi Amazon Macie khởi tạo việc quét, nó chỉ thực hiện quét dữ liệu mới hoặc dữ liệu mới cập nhật, điều này giúp giảm thiểu chi phí. Chúng tôi cũng triển khai bộ lọc đối với các tệp kích thước lớn và S3 prefix để chỉ quét những đối tượng cần thiết và cung cấp tần suất lấy mẫu để tiết kiệm chi phí với những S3 bucket kích thước lớn (trong trường hợp chúng ta, bucket kích thước lớn hơn 1TB).

Quét lỗ hổng bảo mật với Amazon Inspector 

Bởi vì chúng ta sử dụng nhiều loại hệ điều hành và phần mềm, chúng ta cần quét máy chủ Amazon EC2 cho những lỗ hổng phổ biến như Log4J.

Chúng tôi đã sử dụng Amazon Inspector để quét các lỗ hổng trên máy chủ Amazon EC2 và file ảnh container trên Amazon Elastic Container Registry (Amazon ECR) một cách liên tục. Với Amazon Inspector, chúng ta có thể liên tục dò tìm nếu lập trình viên triển khai các phần mềm chứa đựng lỗ hổng bảo mật trên máy chủ Amazon EC2 hoặc file ảnh container trên ECR mà không cần thiết lập phần mềm bên thứ ba hay cài thêm các agent.

Tập hợp những phát hiện bảo mật với AWS Security Hub 

Chúng ta không muốn việc phân tích bảo mật bị phân tán riêng lẻ. Điều này khiến tốn kém thời gian và khó khăn trong việc ưu tiên rủi ro nào cần ưu tiên xử lý trước. Chúng ta cũng cần theo dõi quyền sở hữu, tiến trình, và xây dựng phản hồi phù hợp cho các phát hiện bảo mật phổ biến.

Với AWS Security Hub, việc đánh giá các phát hiện được ưu tiên từ GuardDuty, Macie, Amazon Inspector, và nhiều dịch vụ AWS khác. Việc phân tích sử dụng tính năng kiểm tra bảo mật đã được xây dựng của Security Hub để xác định những tài nguyên và tài khoản AWS có số lượng phát hiện bảo mật cao và hành động dựa trên bảng thông tin này.

Thiết lập những dịch vụ dò tìm đe doạ 

Sau đây là những gì chúng tôi đã thiết lập:

Việc phân tích bảo mật sử dụng Security Hub sẽ sinh ra các phiếu ticket trên hệ thống Jira để xem, ưu tiên, phản hồi các phát hiện bảo mật và lỗi cấu hình giữa các môi trường AWS.

Thông qua việc cấu hình này, việc phân tích không cần phải xem trên nhiều tài khoản, nhiều cấu hình ở các console khác nhau, giúp cho việc quản trị hàng ngày trở nên dễ dàng hơn. Hình 1 mô tả luồng dữ liệu đến Security Hub.

Hình 1 – Tổng hợp các dịch vụ bảo mật vào tài khoản bảo mật (Security Tooling Account) 

Hình 2 – Thiết lập Quản trị viên chuyên biệt 

Phản hồi sự cố (Incident Response)

Trước khi siêu tăng trưởng không có các thủ tục để phản hồi sự cố. Để ngăn chặn các sự cố về mặt bảo mật chúng tôi đã xây dựng kế hoạch phản hồi sự cố và quy trình xác định các tiềm tàng bảo mật nhanh chóng và tối thiểu sự ảnh hưởng, cũng như bị phơi bày ra. Tuân theo Hướng dẫn phản hồi sự cố bảo mật của AWS và NIST framework, chúng tôi đã thực hiện những cập nhật sau: 

Playbook và Runbook cho những việc lặp lại 

Chúng tôi phát triển Playbook và Runbook cho những phản hồi lặp lại đối với những sự kiện bảo mật bao gồm:

  • Playbook cho những ngữ cảnh chiến lược và phản hồi dựa trên một vài mẫu playbook ở đây.
  • Runbook cung cấp các hướng dẫn từng bước cụ thể giúp người làm bảo mật có thể tuân theo dễ dàng khi có sự cố xảy ra. Chúng tôi đã sử dụng Amazon Sagemaker notebooks và AWS Systems Manager Incident Manager runbook để xây dựng các phản hồi lặp lại cho những sự cố đã được định nghĩa 
Tự động giúp thời gian phản hồi nhanh hơn 

Sau khi xây dựng các quy trình lặp lại, chúng tôi xác định những lĩnh vực có thể tăng tốc độ phản hồi khi có đe doạ bảo mật thông qua việc tự động hoá phản hồi. Chúng tôi đã sử dụng giải pháp AWS Security Hub Automated Response and Remediation như là một điểm bắt đầu.

Việc sử dụng giải pháp này chúng tôi không cần phải xây dựng workflow phản hồi tự động và khắc phục sự cố. Mã nguồn dễ dàng đọc, lặp lại và triển khai tập trung thông qua AWS CloudFormation Stacksets. Chúng tôi sử dụng một số tiện ích khắc phục lỗi có sẵn như vô hiệu hoá những Access Key mà 90 ngày chưa thực hiện cập nhật xoay vòng, cấu hình tất cả Amazon EBS snapshot ở trạng thái riêng tư, và nhiều hơn thế nữa. Thông qua tự động hoá khắc phục sự cố, đội ngũ chúng tôi có thể phản hồi nhanh hơn theo cách thức lặp lại và toàn diện.

Mô phỏng để tăng khả năng phản hồi sự cố 

Chúng tôi đã thực hiện mô phỏng khả năng phản hồi sự cố hàng Quý. Những mô phỏng này kiểm tra xem chúng tôi có chuẩn bị tốt về mặt con người, quy trình và công nghệ khi có sự cố xảy ra. Chúng tôi thực hiện một số mô phỏng đặc thù như mở S3 bucket công cộng hay chia sẻ Amazon RDS Snapshot ra bên ngoài để đảm bảo kỹ sư bảo mật đã được chuẩn bị cho sự cố như vậy. Sau đó chúng tôi cũng dựa vào các kết quả của việc mô phỏng này để cải tiến quy trình phản hồi sự cố của công ty.

Kết luận 

Trong bài viết này chúng ta đã thảo luận cách thức chuẩn bị, dò tìm, và phản hồi các sự kiện bảo mật trong môi trường AWS. Chúng ta cũng đã định danh các dịch vụ bảo mật để dò tìm các sự kiện, lỗ hổng bảo mật, cấu hình sai. Sau đó chúng ta thảo luận cách xây dựng quy trình phản hồi sự cố thông qua xây dựng Playbook và Runbook, thực thi mô phỏng, và tự động. Với những khả năng mới này, chúng tôi có thể dò tìm và phản hồi các sự cố bảo mật trong giai đoạn siêu tăng trưởng.

Bạn muốn xem thêm nhiều nội dung về kiến trúc? AWS Architecture Center cung cấp nhưng mô hình kiến trúc tham khảo, giải pháp kiến trúc, thực hành tối ưu Well-Architected Framework, kiểu mẫu và hơn thế nữa.

Bài được dịch từ bài viết trên AWS Blogs, bạn có thể xem bài viết gốc tại đây.

←
→

Leave a comment