AWS Study Group

Tự động hóa khắc phục sự cố: Bảo mật AWS landing zone của Volkswagen ở quy mô lớn

Tác giả: Stephan Traub, Pedro Galvão, and Dr. Stephan Teuber

Ngày: 26 tháng 2 năm 2025

Danh mục: Amazon EventBridge, Amazon RDS, Amazon Simple Storage Service (S3), Automotive, AWS CodeBuild, AWS CodePipeline, AWS Identity and Access Management (IAM), AWS Professional Services, AWS Security Hub, Industries 

Năm 2019, Volkswagen AG (VW) và Amazon Web Services (AWS) đã hình thành mối quan hệ hợp tác chiến lược để cùng phát triển Digital Production Platform (DPP), nhằm nâng cao hiệu quả sản xuất và hậu cần của VW lên 30% đồng thời giảm chi phí sản xuất cùng tỷ lệ.

Khi cơ sở hạ tầng DPP mở rộng, việc duy trì bảo mật trở thành ưu tiên quan trọng. Điều này có thể đạt được thông qua cách tiếp cận toàn diện tích hợp các cơ chế phòng ngừa, phát hiện và phản ứng, giúp đảm bảo bảo vệ mạnh mẽ trong môi trường điện toán đám mây động. DPP landing zone ngày càng phải đối mặt với thách thức này do số lượng tài khoản tăng nhanh mỗi quý. Với hơn 180 dự án, số lượng lỗ hổng phát sinh do cấu hình sai AWS resources bởi người dùng tài khoản AWS tăng nhanh chóng, làm tăng rủi ro tiềm ẩn cho công ty. Ví dụ về những cấu hình sai này là các bucket Amazon S3 có thể truy cập công khai hoặc các bảng (tables) Amazon RDS bị lộ ra internet.

Trong blog này, chúng tôi sẽ thảo luận về quy trình tự động giúp đội ngũ bảo mật tài khoản VW AWS khắc phục các lỗ hổng trong AWS landing zone bằng cách cấu hình lại AWS. Điều này được thực hiện với tốc độ được kiểm soát bởi đội ngũ bảo mật DPP của VW để giúp giảm thiểu tác động vận hành đến các dự án đồng thời quản lý rủi ro bị lộ lọt thông tin.

Giải pháp tự động khắc phục sự cố đã tạo ra một bước ngoặt cho hiện trạng bảo mật (security posture) của VW. Nó giúp chúng tôi đạt được mức độ tuân thủ (compliance) trên toàn công ty cao hơn, giảm rủi ro và tăng năng suất nhà phát triển trong khi giảm đáng kể thời gian phản hồi của chúng tôi,” Dr. Stephan Teuber, nhân viên bảo mật cho VW DPP cho biết.

Ví dụ, sáng kiến automated remediation đã tăng tỷ lệ khắc phục các vấn đề bảo mật tổng thể của VW từ 95% lên 99,9% đối với các lỗ hổng nghiêm trọng và từ 85% lên 98% đối với các lỗ hổng mức độ cao. Chúng tôi đã triển khai hơn 15 remediation modules bao gồm AWS Security Hub và các phát hiện từ công cụ đối tác. Trong năm đầu tiên hoạt động, hệ thống đã thực hiện hơn 100.000 lần khắc phục sự cố (khoảng 8.300 hành động mỗi tháng) và hiện đang hoạt động ở trạng thái ổn định với 3.500 hành động remediation mỗi tháng trong 1.200 tài khoản AWS.

Là thành viên của đội ngũ AWS và VW, chúng tôi đã cộng tác để phát triển cách tiếp cận sáng tạo cho việc automated remediation các lỗ hổng. VW, với sự hỗ trợ của AWS, đã xác định các yêu cầu sau để giúp mở rộng quy mô với tốc độ tương đương nền tảng DPP trong khi giữ tác động vận hành tiềm ẩn đối với VW ở mức thấp và được kiểm soát nhất có thể:

  • Một hành động khắc phục (remediation) được định nghĩa là việc sửa lại một cấu hình có lỗ hổng (vulnerable configuration) của dịch vụ AWS. Việc sửa chữa này cần thiết để giúp giảm thiểu lỗ hổng bảo mật tiềm ẩn đối với cấu hình dịch vụ do chủ tài khoản AWS đưa ra. Những lỗ hổng này được phát hiện và cung cấp bởi AWS Security Hub.
  • Quy trình quyết định rõ ràng cho các remediation mới: Để quyết định lỗ hổng nào cần automatically remediate, đội ngũ đã thu thập và phân tích dữ liệu để đánh giá tác động tiêu cực tiềm ẩn và ảnh hưởng đến tất cả tài khoản AWS của VW.
  • Giao tiếp với người dùng để giới thiệu các remediation mới: Để đảm bảo mọi người dùng landing zone đều nhận thức và chuẩn bị, các remediation mới phải được thông báo trước 3 tuần khi triển khai cho tài khoản không phải production và 3 tháng cho tài khoản production.
  • Tốc độ remediation được kiểm soát: Để kiểm soát rủi ro của tác động tiêu cực không mong muốn đến cấu hình tài nguyên được giảm thiểu, số lượng hành động remediation không được vượt quá ngưỡng quy định. Ngưỡng hành động mỗi lần chạy phải được đánh giá dựa trên độ phức tạp của việc remediation và số lượng tài nguyên bị ảnh hưởng. Điều này tăng khả năng kiểm soát và tốc độ của các hành động remediation để không gặp phải vấn đề về giới hạn hoặc cạn kiệt tài nguyên.
  • Per-account remediation: Các  remediation phải được nhóm theo tài khoản để duy trì bản ghi log rõ ràng về các hành động thực hiện và lỗi tiềm ẩn trong không gian log trung tâm. Điều này sẽ đơn giản hóa quá trình troubleshooting và error-handling trong trường hợp hành động remediation thất bại. Trong trường hợp có lỗi, bản ghi log đơn lẻ hiển thị tất cả các remediation của một tài khoản cụ thể theo thứ tự thời gian. Nó sẽ cung cấp thông tin chi tiết nếu tồn tại các vấn đề chung với tài khoản như vấn đề về quyền hoặc tác động phụ tiêu cực giữa các remediation.
  • Quản lý ngoại lệ: Phải có hệ thống quản lý ngoại lệ theo thời gian để trao quyền cho các đội dự án yêu cầu miễn trừ tạm thời. Điều này có thể cần thiết nếu các đội dự đoán tác động tiêu cực từ việc remediation vì họ phụ thuộc vào cấu hình tài nguyên vulnerable. Ngoại lệ theo thời gian sẽ được cấp để cho phép họ có thêm thời gian hơn 3 tuần đối với workload không phải production hoặc 3 tháng đối với workload production để loại bỏ sự phụ thuộc.

Tổng quan

Chúng tôi đã triển khai chức năng cốt lõi dựa trên các yêu cầu đã cho như một dự án trong AWS CodeBuild, một dịch vụ để build và test code với khả năng tự động mở rộng. Dự án AWS CodeBuild lần lượt được khởi tạo bởi một rule theo lịch trong AWS EventBridge, một giải pháp để xây dựng ứng dụng hướng sự kiện ở quy mô lớn trên AWS, các hệ thống hiện có hoặc ứng dụng SaaS. Logic remediation được định nghĩa bằng mã Python trong dự án AWS CodeBuild.

Đội ngũ bảo mật DPP của VW đã chọn AWS CodeBuild vì chi phí thấp và thời gian chạy kéo dài lên đến 8 giờ. Tổng chi phí hệ thống khoảng 20 đô la mỗi tháng—phục vụ 1.200 tài khoản AWS. Cách tiếp cận theo lịch trình cho phép chúng tôi khả năng kiểm soát khi nào việc remediation đang chạy và dừng hoạt động nếu cần.

Hình 1: Khung tự động khắc phục sự cố (Automated remediation framework)

Việc triển khai chức năng auto-remediation bao gồm nhiều thành phần được thể hiện trong hình 1 ở trên:

  1. Data collector: Chức năng này thu thập thông tin tài khoản và tất cả các phát hiện tương ứng từ AWS Security Hub, một dịch vụ được thiết kế để giúp khách hàng tự động hóa kiểm tra bảo mật AWS và tập trung hóa các cảnh báo bảo mật.
  1. Remediation base: Thành phần framework này cung cấp chức năng tích hợp cơ bản cho việc remediation, chẳng hạn như giả định các phiên cho các hành động tài khoản trong AWS Identity and Access Management (AWS IAM) – một dịch vụ được thiết kế để quản lý an toàn danh tính và quyền truy cập vào các dịch vụ và tài nguyên AWS – và tương tác với các phát hiện được thu thập từ AWS Security Hub. Nó cũng tổng hợp các phát hiện theo từng tài khoản, cung cấp chu kỳ chạy remediation theo tài khoản thay vì sử dụng cách tiếp cận theo từng phát hiện. Điều đó có nghĩa là các hành động có thể dự đoán được hơn đối với chủ tài khoản và cũng giảm thiểu chi phí – ví dụ khi giả định vai trò AWS IAM nhiều lần trong một phiên remediation. Remediation base cũng sẽ đảm nhiệm việc ghi nhật ký và giám sát cho các module khắc phục.
  1. Remediation module: Thành phần này chứa chức năng thay đổi cấu hình tài nguyên, sẽ được chạy trong tài khoản để giải quyết các vấn đề bảo mật đã xác định. Các thay đổi cấu hình được thực hiện được điều chỉnh riêng cho các điều khiển mà chúng remediate. Có thể có nhiều module được định nghĩa trong framework.

Giải pháp:

Cách tiếp cận module được VW áp dụng giúp tạo ra các biện pháp remediation mới nhanh hơn và dễ dàng hơn. Các remediation module mới được viết bằng Python. Module này chỉ chứa tiêu đề tìm kiếm lọc các phát hiện và và những thay đổi giúp khắc phục cấu hình vulnerable của tài nguyên. Remediation base framework xử lý mọi thứ khác, bao gồm thiết lập phiên tài khoản và thu thập phát hiện bảo mật từ AWS Security Hub. Module chỉ sử dụng framework cung cấp base functionality và loại bỏ các hành động lặp lại để cung cấp dữ liệu cần thiết. Điều này giúp giảm thời gian phát triển các biện pháp remediation mới.

Ví dụ cấu trúc module bằng Python:

"""Module for an example remediation."""

from lib.remediation_base import AutoRemediationBase # Import the remediation base framework

class Name(AutoRemediationBase):

    """Remediate some resource."""

    MODULE_NAME = "ExampleModuleName"

   # Define the finding to filter for

    FINDING_TITLE = "1.2 Example finding title in AWS Security Hub"

    def __init__(self) -> None:

        # Initializing the base/super class AutoRemediationBase

        super().__init__(module_name=self.MODULE_NAME, finding_title=self.FINDING_TITLE)

        # Generates the basic framework and collect all finding for the given title

        # The functions will be provided by the inherited AutoRemediationBase class

        self.logger = self.create_logger() # Logging framework

        self.findings = self.load_findings() # AWS Security Hub finings filtered by the FINDING_TITLE

    def run_fix(self) -> None:

        """Start the remediation with the given findings."""

# Add here the code/remediation you want to run on the findings.

# the self.findings provides all AWS Security Hub finding details and the AWS IAM session which can be assumed to access the affected AWS account. 

        self.logger.info(f"Found {len(findings)} with {self.FINDING_TITLE} in the AWS Security Hub")

Giải pháp cuối cùng bao gồm remediation base framework và một hoặc nhiều remediation modules. Tất cả các remediation modules được chạy tuần tự để giảm thiểu rủi ro của các tác dụng phụ có thể xảy ra hoặc vấn đề throttling đối với AWS service APIs. Cách tiếp cận này cũng tạo điều kiện kiểm soát và truy xuất nguồn gốc tốt hơn trong trường hợp xảy ra lỗi hoặc hành vi không mong muốn trong quá trình remediation vì các hành động cũng được ghi lại tuần tự.

Hình 2: Kiến trúc tự động khắc phục sự cố (Automated remediation architecture)

Chỉ cần một vài bước để chạy remediation tự động, như trong hình 2:

  1. Code Python được triển khai trong tài khoản tài nguyên của đội bảo mật DPP, chứa AWS CodePipeline để tự động hóa các pipeline phân phối liên tục cho các cập nhật nhanh chóng và đáng tin cậy, sau đó triển khai AWS CodeBuild job trong tài khoản Bảo mật và Kiểm toán.
  1. AWS CodeBuild job được triển khai chạy theo quy tắc AWS EventBridge được định nghĩa bởi đội bảo mật DPP. Ví dụ, nó chạy hai lần một ngày vào thời điểm cụ thể.
  1. AWS CodeBuild job được kích hoạt bắt đầu quá trình thu thập dữ liệu để lấy các ID tài khoản mục tiêu cần thiết và account tags. Thông tin này có thể được lấy từ nhiều nguồn khác nhau, như bộ công cụ tùy chỉnh bên ngoài, AWS Organization API, hoặc file được lưu trữ trong Amazon S3 – kho lưu trữ đối tượng được xây dựng để truy xuất bất kỳ lượng dữ liệu nào từ bất kỳ đâu. Điều này phụ thuộc vào quản lý landing zone hiện có để cung cấp dữ liệu và không phải là một phần của giải pháp automated remediation. Ví dụ, Volkswagen duy trì công cụ khám phá tài khoản để cung cấp thông tin này thông qua API tập trung.
  1. Khi có thông tin tài khoản, auto-remediation framework thu thập và tổng hợp các phát hiện từ AWS Security Hub cho mỗi tài khoản bằng get_findings API.
  1. Framework remediation base sau đó sẽ đóng một vai trò (assume a role) được định nghĩa trước trong tài khoản landing zone, cho phép thay đổi cấu hình tài nguyên và khởi tạo phiên AWS IAM với vai trò này vào tài khoản bị ảnh hưởng. Tuân theo nguyên tắc đặc quyền tối thiểu, vai trò được giả định chỉ giới hạn trong việc thực hiện các hành động remediation trên các resource và service bị ảnh hưởng.
  1. Tiếp theo, auto-remediation framework cung cấp phiên IAM đã khởi tạo cho các remediation modules để chạy các hành động remediation trong CodeBuild job. Ngoài ra, remediation module nhận chi tiết phát hiện AWS Security Hub từ framework được lọc theo tài khoản bị ảnh hưởng và tiêu đề phát hiện. Các chi tiết này chứa thông tin resource bị ảnh hưởng sẽ được remediate bởi module.
  1. Sau khi remediation module sửa một cấu hình sai, remediation base framework cập nhật phát hiện AWS Security Hub với trường meta data tùy chỉnh hiển thị thời điểm sửa và cờ báo rằng nó đã được thực hiện tự động. Phát hiện cũng sẽ được đánh dấu là đã giải quyết sau khi remediation thành công để phản ánh trong các công cụ khác và bảng điều khiển AWS Security Hub của tài khoản AWS bị ảnh hưởng.

Chúng tôi sử dụng cách tiếp cận có chọn lọc để tự động xác định các hành động remediation sẽ được áp dụng. Các tiêu chí chính để chọn phát hiện AWS Security Hub bao gồm:

  • Rủi ro: rủi ro và mức độ nghiêm trọng của cấu hình sai
  • Khối lượng: số lượng phát hiện mở trong landing zone
  • Tác động đến khách hàng: thời gian nhóm dự án cần để giải quyết phát hiện

Kết luận

VW, cùng với sự hỗ trợ của AWS Professional Services – giúp các công ty đạt được kết quả kinh doanh mong muốn với AWS – đã phát triển quy trình mạnh mẽ và hiệu quả hơn để xem xét các remediation tiềm năng mới để đưa vào automated remediation module stack. Quy trình này đóng vai trò như một phần mở rộng cho cách tiếp cận Architectural Decision Record (ADR), tạo điều kiện cho việc lựa chọn các hành động remediation đáp ứng các tiêu chí nghiêm ngặt trong số các ứng viên được xem xét. ADR, có thể được tạo bởi bất kỳ kiến trúc sư bảo mật nào, phải bao gồm các điểm dữ liệu cho các định danh chính, rủi ro tiềm ẩn và triển khai pseudo-code để hỗ trợ remediation được đề xuất. Tài liệu ADR sẽ được đội bảo mật DPP xem xét và phê duyệt để duy trì tiêu chuẩn chất lượng cao đồng thời xác định và giảm thiểu các rủi ro tiềm ẩn. Điều này sẽ giúp ngăn chặn các quyết định không chính xác có thể ảnh hưởng đến tất cả các tài khoản landing zone.

Cách tiếp cận automated approach này đã cải thiện tình trạng bảo mật tổng thể và giúp giảm rủi ro. Nó cũng đã giảm gánh nặng vận hành cho cả đội dự án và đội bảo mật của VW.

Để biết thêm chi tiết về cách AWS có thể hỗ trợ hành trình automated remediation của bạn, hãy liên hệ với đại diện tài khoản AWS của bạn. AWS Professional Services có thể giúp bạn đạt được kết quả mong muốn.

TAGS: automation, compliance, scalability, security

Stephan Traub

Stephan là một chuyên gia tư vấn bảo mật tại AWS Professional Services, nơi anh hợp tác chặt chẽ với khách hàng trong ngành công nghiệp ô tô. Là một người đam mê công nghệ thực thụ, Stephan luôn nhiệt huyết trong việc hỗ trợ khách hàng xây dựng tư thế bảo mật vững chắc trong môi trường đám mây của họ. Gần đây, anh đã chia sẻ kiến thức chuyên môn về các phương pháp bảo mật tốt nhất tại sự kiện AWS re:Inforce 2023. Khi không bận rộn với công việc tại AWS, bạn có thể bắt gặp Stephan trên sân bóng chuyền hoặc cùng gia đình khám phá thế giới.

Pedro Galvão

Pedro là một chuyên gia tư vấn bảo mật cấp cao tại AWS Professional Services. Anh đặc biệt yêu thích việc hỗ trợ khách hàng thực hiện những công việc kỹ thuật bảo mật xuất sắc trên nền tảng AWS.

Dr. Stephan Teuber

Stephan là một chuyên viên an ninh tại Volkswagen AG, chịu trách nhiệm bảo vệ Nền tảng Sản xuất Kỹ thuật số của công ty. Với nền tảng chuyên môn về CNTT trong sản xuất và logistics, Stephan mang đến những góc nhìn thực tiễn cho lĩnh vực an ninh mạng trong ngành công nghiệp ô tô. Anh đã góp phần đưa tự động hóa bảo mật vào công ty, hiện đại hóa các quy trình truyền thống. Khi không bận rộn với công việc bảo mật, Stephan thường tận hưởng những chuyến leo núi ở dãy Alps và vùng núi trung tâm nước Đức.

←
→

Leave a comment