Cloud Data Exfiltration và Data Extortion là gì?

Cloud Data Exfiltration (xâm nhập và trích xuất dữ liệu đám mây) là hành vi truy cập trái phép vào hệ thống cloud của tổ chức và đánh cắp dữ liệu nhạy cảm ra bên ngoài. Kẻ tấn công thường lợi dụng điểm yếu bảo mật (ví dụ: thông tin đăng nhập bị lộ, cấu hình sai) để truy cập các kho dữ liệu đám mây và exfiltrate (trích xuất) một lượng lớn thông tin. Trong các sự cố gần đây, tin tặc đã nhắm vào các nền tảng dữ liệu đám mây như Snowflake – dịch vụ kho dữ liệu cloud phổ biến – để sao chép dữ liệu khách hàng của nhiều công ty khác nhau.

Data Extortion (tống tiền dữ liệu) là chiến thuật kẻ tấn công sử dụng dữ liệu đã đánh cắp làm “con tin” nhằm đòi tiền chuộc. Thay vì chỉ mã hóa dữ liệu như các cuộc tấn công ransomware truyền thống, kiểu tấn công này tập trung vào việc đe dọa công khai hoặc bán dữ liệu nhạy cảm nếu nạn nhân không trả tiền. Mục tiêu của chúng là gây sức ép để nạn nhân chi tiền nhằm tránh hậu quả rò rỉ thông tin. Những nhóm tội phạm mạng hiện nay ngày càng chú trọng hình thức tống tiền dựa trên dữ liệu – bởi họ có thể trực tiếp trục lợi từ dữ liệu bị đánh cắp, không cần triển khai mã độc mã hóa phức tạp [1].

Hai khái niệm trên có mối liên hệ chặt chẽ: kẻ tấn công thường exfiltrate dữ liệu trước, sau đó thực hiện extortion. Chiến dịch tấn công thường diễn ra theo chuỗi: xâm nhập hệ thống (đặc biệt là hệ thống đám mây chứa dữ liệu lớn), âm thầm sao chép dữ liệu ra ngoài, rồi dùng chính dữ liệu đó để đe dọa doanh nghiệp hoặc rao bán trên chợ đen. Một ví dụ điển hình là chiến dịch nhắm vào các khách hàng của Snowflake năm 2024: Mandiant cho biết một nhóm tội phạm mà họ theo dõi là UNC5537 đã có chủ đích đánh cắp dữ liệu và tống tiền từ các cơ sở dữ liệu Snowflake của khách hàng [2]. Nhóm này lần lượt xâm nhập nhiều tài khoản Snowflake của doanh nghiệp, đánh cắp hàng tỷ bản ghi dữ liệu rồi quảng cáo bán dữ liệu trên các diễn đàn tội phạm mạng, đồng thời đòi tiền chuộc từ nạn nhân để đổi lấy việc không công bố dữ liệu [2].

Như vậy, Cloud Data Exfiltration là bước chiếm đoạt dữ liệu, còn Data Extortion là bước đòi tiền dựa trên dữ liệu đã chiếm. Cả hai thường song hành trong các vụ vi phạm dữ liệu hiện đại, đặc biệt khi hệ thống nạn nhân nằm trên cloud – nơi lưu trữ khối lượng lớn thông tin mà nếu lộ ra sẽ gây thiệt hại nghiêm trọng.

Vào khoảng tháng 5/2024, các vụ vi phạm dữ liệu quy mô lớn liên quan đến nền tảng dữ liệu đám mây Snowflake đã bị phanh phui. Trong đó đáng chú ý có Ticketmaster (thuộc tập đoàn Live Nation) và Ngân hàng Santander, hai nạn nhân tiêu biểu cho thấy mức độ nghiêm trọng của hình thức tấn công này. Dữ liệu cho thấy cả Ticketmaster và Santander đều bị đánh cắp thông tin từ tài khoản Snowflake của họ – do kẻ tấn công sử dụng thông tin đăng nhập (username/password) đánh cắp để truy cập trực tiếp vào kho dữ liệu đám mây. Dưới đây là diễn biến và phân tích cụ thể cho từng vụ:

Sự cố Ticketmaster (2024)

Vào cuối tháng 5/2024, một nhóm tin tặc đã gây chấn động khi tuyên bố trên diễn đàn ngầm rằng chúng đã xâm nhập thành công Ticketmaster và đánh cắp dữ liệu của 560 triệu người dùng của dịch vụ này [3]. Tin tặc (tự nhận thuộc nhóm ShinyHunters – một nhóm hacker khét tiếng chuyên các vụ đánh cắp dữ liệu lớn) đã rao bán kho dữ liệu khổng lồ này trên dark web với giá 500.000 USD [3]. Chỉ vài ngày sau, công ty mẹ của Ticketmaster là Live Nation Entertainment đã phải nộp báo cáo lên Ủy ban Chứng khoán Hoa Kỳ (SEC) xác nhận rằng hệ thống của họ bị truy cập trái phép. Cụ thể, Live Nation thừa nhận có hành vi xâm nhập vào “một môi trường cơ sở dữ liệu đám mây của bên thứ ba” chứa dữ liệu khách hàng Ticketmaster [3]. Dù Live Nation không nêu tên nhà cung cấp bên thứ ba này, giới chuyên môn nhanh chóng xác định đó chính là Snowflake – nền tảng dữ liệu đám mây được Ticketmaster sử dụng để lưu trữ và phân tích dữ liệu [3].

Quy mô và thiệt hại: Theo tuyên bố của nhóm ShinyHunters, vụ hack Ticketmaster liên quan đến khoảng 1,3 TB dữ liệu từ 560 triệu khách hàng [4]. Chúng khẳng định dữ liệu bao gồm đầy đủ thông tin liên hệ của khách (tên, địa chỉ, số điện thoại), chi tiết thẻ tín dụng, lịch sử mua vé và thông tin các sự kiện đã đặt vé [4]. Tuy nhiên, trong thông báo chính thức trên website, Ticketmaster đã bác bỏ phần nào tuyên bố này. Công ty cho biết cơ sở dữ liệu bị xâm nhập chỉ chứa thông tin cá nhân giới hạn, chủ yếu là số điện thoại, địa chỉ email và thông tin thẻ tín dụng đã được mã hóa – chứ không bao gồm các dữ liệu nhạy cảm khác như mật khẩu hoặc thông tin chưa mã hóa [4]. Ngoài ra, Ticketmaster cho hay vụ việc chỉ ảnh hưởng đến các khách hàng mua vé tại một số thị trường (Hoa Kỳ, Mexico, Canada) trong khoảng thời gian nhất định, thay vì toàn bộ 560 triệu người dùng toàn cầu như lời hacker nói [4]. Mặc dù vậy, với số lượng thông tin người dùng cực lớn bị đánh cắp (dù có thể chỉ là thông tin liên lạc và dữ liệu giao dịch cơ bản), đây vẫn được xem là một trong những vi phạm dữ liệu lớn nhất lịch sử về quy mô người dùng bị ảnh hưởng [5].

Phương thức xâm nhập: Điều tra sau đó hé lộ rằng kẻ tấn công không khai thác lỗ hổng nào trong nền tảng Snowflake, mà thay vào đó lợi dụng thông tin đăng nhập bị lộ để truy cập vào tài khoản Snowflake của Ticketmaster. Cụ thể, một báo cáo của Wired cho biết tin tặc (ShinyHunters) đã xâm nhập vào hệ thống của EPAM Systems – đây là công ty đối tác cung cấp dịch vụ kỹ thuật cho Ticketmaster và nhiều khách hàng Snowflake khác [6]. Máy tính của một nhân viên EPAM tại Ukraine được cho là đã nhiễm malware infostealer thông qua tấn công spear-phishing, cho phép tin tặc cài cửa hậu (RAT) và chiếm quyền điều khiển máy này [6]. Trên máy tính bị kiểm soát, tin tặc phát hiện tệp lưu trữ tên đăng nhập và mật khẩu dưới dạng văn bản không mã hóa mà nhân viên EPAM sử dụng để quản trị các tài khoản Snowflake cho khách hàng – bao gồm cả tài khoản Snowflake của Ticketmaster [6]. Những thông tin đăng nhập này thậm chí được lưu ngay trong công cụ quản lý dự án (Jira) trên máy tính, càng tạo điều kiện cho hacker thu thập dễ dàng [6]. Sau khi có được username/password hợp lệ, nhóm tấn công đã đăng nhập vào môi trường Snowflake của Ticketmaster một cách trực tiếp (do tài khoản không được bảo vệ bởi xác thực đa yếu tố) [6]và từ đó trích xuất toàn bộ dữ liệu mà Ticketmaster lưu trên Snowflake. Snowflake xác nhận rằng chiến dịch tấn công đã nhắm vào những tài khoản chỉ có xác thực một lớp (chỉ cần mật khẩu), và kẻ xâm nhập đã tận dụng các mật khẩu mua được hoặc thu thập từ malware đánh cắp thông tin [3]. Điều này cho thấy lỗ hổng chính là do việc không bật MFA và thông tin đăng nhập bị lộ từ trước.

Hoạt động tống tiền: Sau khi đánh cắp dữ liệu, nhóm ShinyHunters tiến hành bước extortion. Ngay ngày 27/5/2024, tin tặc đã đăng bài rao bán dữ liệu người dùng Ticketmaster trên một diễn đàn darknet và yêu cầu 500.000 USD để đổi lấy 1,3 TB dữ liệu này [3]. Chúng cũng ngầm đe dọa rằng nếu không có ai mua (bao gồm cả chính Ticketmaster), dữ liệu có thể bị tung công khai. Trong giới tội phạm mạng, ShinyHunters được biết đến như một “data broker” – chuyên thu thập rồi bán/chia sẻ dữ liệu vi phạm. Nhóm này cũng từng dọa đòi tiền chuộc trực tiếp từ các công ty. Theo tiết lộ của một thành viên nhóm với báo Wired, họ đã yêu cầu một số nạn nhân trả hàng trăm nghìn USD đến hơn 1 triệu USD để nhóm hủy bỏ dữ liệu đã đánh cắp, nếu không muốn chúng được bán cho bên khác [6]. Hiện chưa rõ Ticketmaster có nhận được yêu cầu tiền chuộc trực tiếp hay không, nhưng công ty đã chọn cách phối hợp với cơ quan thực thi pháp luật thay vì thương lượng ngầm. Vụ việc cũng dẫn đến hệ quả pháp lý: nhiều khách hàng đã đâm đơn kiện tập thể Live Nation/Ticketmaster, cáo buộc công ty tắc trách trong việc bảo vệ dữ liệu và yêu cầu bồi thường thiệt hại [4].

Sự cố Santander (2024)

Ngân hàng Santander – một trong những ngân hàng lớn toàn cầu – cũng rơi vào tình huống tương tự trong cùng chiến dịch tấn công Snowflake nói trên. Ngày 14/5/2024, Santander phát đi thông cáo chính thức thừa nhận họ “vừa phát hiện truy cập trái phép vào một cơ sở dữ liệu của Santander được lưu trữ bởi nhà cung cấp bên thứ ba” [7]. Ngân hàng cho biết đã nhanh chóng chặn quyền truy cập vào database bị xâm nhập và tiến hành các biện pháp ngăn chặn gian lận để bảo vệ khách hàng [7]. Qua điều tra, Santander xác nhận một số dữ liệu của khách hàng tại Chile, Tây Ban Nha và Uruguay đã bị truy cập, cùng với thông tin về toàn bộ nhân viên hiện tại và một số cựu nhân viên trong tập đoàn [7]. May mắn, Santander nhấn mạnh rằng cơ sở dữ liệu này không chứa các dữ liệu giao dịch hoặc thông tin xác thực ngân hàng (không có mật khẩu ngân hàng trực tuyến hay mã OTP), do đó hacker không thể trực tiếp dùng để thực hiện giao dịch tài chính [7]. Họ cũng tuyên bố các hệ thống vận hành cốt lõi của ngân hàng không bị ảnh hưởng, và các thị trường khác ngoài 3 quốc gia kể trên không bị lộ dữ liệu [7]. Santander đã chủ động thông báo cho các khách hàng và nhân viên liên quan, đồng thời báo cáo cơ quan quản lý và phối hợp với cảnh sát điều tra [7].

Quy mô dữ liệu bị đánh cắp: Dù Santander không công bố số lượng cụ thể, trên các diễn đàn ngầm, tin tặc tuyên bố đã lấy được thông tin của khoảng 30 triệu khách hàng Santander [8]. Theo một quảng cáo mà nhóm ShinyHunters đăng tải ngày 3/6/2024, dữ liệu mà chúng có bao gồm chi tiết tài khoản ngân hàng của ~30 triệu khách, số dư của 6 triệu tài khoản, khoảng 28 triệu số thẻ tín dụng, cũng như thông tin nhân sự về nhân viên ngân hàng [8]. Toàn bộ gói dữ liệu được nhóm hacker rao giá 2 triệu USD trên diễn đàn (tương đương ~1,6 triệu bảng Anh) [8]. Đáng chú ý, trong bài đăng, tin tặc còn mời chào một cách mỉa mai: “Santander cũng rất hoan nghênh nếu họ muốn mua lại dữ liệu này” [8]– tức chúng công khai ngỏ ý đòi tiền chuộc từ chính ngân hàng, bên cạnh việc bán cho người khác. Điều này cho thấy rõ động cơ extortion: gây sức ép để nạn nhân phải bỏ tiền ra mua lại dữ liệu của chính mình.

Phương thức và mối liên hệ Snowflake: Giống với Ticketmaster, Santander xác nhận database bị xâm nhập được lưu trên hệ thống của một đối tác bên thứ ba. Dù ngân hàng không nêu tên, giới phân tích bảo mật đã liên hệ vụ việc với sự cố Snowflake cùng thời điểm. Thực tế, các diễn biến trên diễn đàn hacker cho thấy dữ liệu Santander bị rao bán có liên quan trực tiếp đến vụ Snowflake: Bài đăng ban đầu về dữ liệu Santander xuất hiện trên diễn đàn Exploit vào ngày 23/5/2024 bởi tài khoản “whitewarlock” – trùng thời điểm Snowflake tiết lộ cuộc điều tra sự cố. Đến ngày 30/5, nhóm ShinyHunters đã đăng lại (mirror) thông tin về vụ rò rỉ Santander lên BreachForums để thu hút sự chú ý [9]. Hacker cũng khẳng định đã truy cập vào tài khoản Snowflake của một đối tác có lưu dữ liệu Santander, tương tự cách chúng xâm nhập Ticketmaster. Theo báo cáo của Wired, Santander thực chất bị lấy cắp dữ liệu từ chính tài khoản Snowflake mà ngân hàng sử dụng (thông tin này do Wired xác minh độc lập, dù Santander từ chối xác nhận) [6]. Như vậy, khả năng cao kẻ tấn công đã có được thông tin đăng nhập hợp lệ vào môi trường Snowflake chứa dữ liệu khách hàng Santander (có thể qua cùng kênh EPAM hoặc từ các log infostealer khác) và tiến hành trích xuất dữ liệu. Chúng tận dụng việc tài khoản không có MFA và mật khẩu bị lộ từ trước để đột nhập, tương tự các trường hợp khác trong chiến dịch UNC5537 [2].

Hoạt động tống tiền: Ngay sau khi Santander công bố sự cố (giữa tháng 5), nhóm hacker đã nhanh chóng chuyển sang bước extortion. Như đã đề cập, ngày 3/6/2024, chúng rao bán dữ liệu 30 triệu khách hàng với giá 2 triệu USD và mời gọi ngân hàng tự mua lại [8]. Thời điểm đó, báo Financial Times và Guardian đều đưa tin về việc ShinyHunters đang đấu giá dữ liệu Santander trên forum ngầm [8]. Santander tuyên bố với báo giới rằng họ sẽ không bình luận về tuyên bố “một trong những vụ tấn công lớn nhất lịch sử ngân hàng” này, và tiếp tục phối hợp với cơ quan chức năng thay vì thương lượng với tội phạm [8]. Đến ngày 6/6/2024, giới theo dõi nhận thấy ShinyHunters bất ngờ gỡ bài đăng rao bán dữ liệu Santander trên diễn đàn, không rõ do đã đạt được thỏa thuận ngầm hay vì lý do nào khác [9]. Hiện chưa có thông tin công khai về việc Santander có trả tiền chuộc hay không. Một số nguồn tin cho rằng có thể nhóm hacker đã bán dữ liệu cho bên thứ ba hoặc Santander áp dụng biện pháp khác khiến chúng rút bài (ví dụ: honeypot dữ liệu, can thiệp của pháp luật, v.v.). Dù thế nào, sự cố này đã cảnh báo ngành tài chính về mối nguy khi dữ liệu khách hàng được lưu trữ trên hạ tầng cloud bên ngoài: chỉ một sơ hở nhỏ cũng có thể dẫn đến lộ lọt thông tin hàng chục triệu khách hàng.

Ảnh hưởng: Đối với Santander, hậu quả trước mắt là uy tín và niềm tin của khách hàng tại các thị trường liên quan bị lung lay. Dù ngân hàng khẳng định dữ liệu lộ không cho phép đánh cắp tiền, nhưng thông tin cá nhân và chi tiết tài khoản bị lộ cũng có thể dẫn đến các vụ lừa đảo, phishing nhắm vào khách hàng. Santander đã phải lên tiếng trấn an rằng họ không bao giờ yêu cầu khách cung cấp mật khẩu hay mã OTP và cảnh báo khách hàng cảnh giác với bất kỳ liên lạc đáng ngờ nào mạo danh ngân hàng [7]. Về tài chính, chưa có con số thiệt hại công khai, nhưng nếu dữ liệu thật sự bị bán hoặc phát tán, Santander có thể đối mặt với án phạt và kiện tụng tại các quốc gia có khách hàng bị ảnh hưởng (do vi phạm quy định bảo vệ dữ liệu). Sự cố này, cùng với vụ Ticketmaster, đã góp phần làm năm 2024 chứng kiến làn sóng vi phạm dữ liệu lớn trên nền tảng đám mây, với hàng trăm triệu hồ sơ người dùng bị ảnh hưởng trên toàn thế giới [5].

Phân tích biện pháp phòng thủ: MFA, giám sát bất thường, kiểm soát truy cập cloud

Các vụ tấn công vào Ticketmaster, Santander và nhiều tổ chức khác qua Snowflake cho thấy lỗ hổng chủ yếu nằm ở khâu bảo mật danh tính và truy cập. Dưới đây là phân tích vai trò của một số biện pháp phòng thủ quan trọng trong việc ngăn chặn những cuộc tấn công tương tự:

Xác thực đa yếu tố (MFA)

Việc bắt buộc xác thực đa yếu tố (Multi-Factor Authentication) cho các tài khoản truy cập dịch vụ đám mây có thể ngăn chặn phần lớn kiểu tấn công dựa vào thông tin đăng nhập đánh cắp. Trong chiến dịch Snowflake 2024, Mandiant kết luận hầu hết các tài khoản bị xâm nhập đều không bật MFA, do đó kẻ tấn công chỉ cần một username và password hợp lệ là đăng nhập thành công [2]. Đây là yếu tố số một dẫn đến thành công của cuộc tấn công. Nếu Ticketmaster, Santander và các nạn nhân khác triển khai MFA cho tài khoản Snowflake của họ, tin tặc sẽ không thể truy cập chỉ bằng mật khẩu tìm được trên mạng hay từ máy tính nhân viên. Chẳng hạn, trong vụ EPAM, mặc dù hacker lấy được user/password Snowflake của Ticketmaster, chúng vẫn sẽ bị chặn lại nếu tài khoản đó yêu cầu một mã OTP hoặc xác nhận qua thiết bị thứ hai mà hacker không có. Snowflake đã xác nhận các tài khoản bị tấn công thuộc diện “chỉ dùng mật khẩu, không qua Okta hay MFA” – khác với hệ thống nội bộ Snowflake vốn bắt buộc SSO/MFA [3]. Do đó, bài học quan trọng là doanh nghiệp cần kích hoạt MFA cho toàn bộ tài khoản cloud, đặc biệt là tài khoản quản trị và tài khoản truy cập kho dữ liệu quan trọng. MFA bổ sung một lớp phòng thủ, làm giảm đáng kể nguy cơ kẻ xấu đăng nhập được ngay cả khi chúng có mật khẩu.

Giám sát bất thường và phát hiện xâm nhập (Anomaly Detection)

Giám sát hành vi người dùng và truy cập trên các hệ thống cloud có vai trò then chốt để phát hiện sớm hoạt động bất thường – dấu hiệu của xâm nhập trái phép. Trong các vụ vừa qua, thời gian từ khi hacker xâm nhập đến lúc bị phát hiện khá dài (có trường hợp hơn một tháng) do thiếu cảnh báo sớm [4]. Nếu có giải pháp anomaly detection tốt, Ticketmaster có thể nhận ra những dấu hiệu lạ, chẳng hạn: một tài khoản nhân viên hoặc đối tác đột nhiên đăng nhập từ địa chỉ IP bất thường hoặc ngoài giờ làm việc, rồi thực thi hàng loạt truy vấn tải xuống dung lượng khổng lồ dữ liệu – hành vi không phù hợp với hoạt động thông thường. Việc thiết lập các chỉ báo bất thường (như tốc độ truy vấn, khối lượng dữ liệu xuất ra, vị trí đăng nhập, thiết bị lạ, v.v.) và tích hợp cảnh báo realtime sẽ giúp đội ngũ bảo mật kịp thời phản ứng, hạn chế thiệt hại. Thực tế, sau sự cố, Snowflake đã phối hợp với Mandiant xây dựng hướng dẫn truy vết và phát hiện bất thường trên Snowflake cho các khách hàng: hướng dẫn này cung cấp các câu truy vấn để dò tìm hoạt động bất thường hoặc độc hại trong logs của Snowflake trong vòng 1 năm [2]. Điều đó cho thấy việc theo dõi log và áp dụng thuật toán phát hiện bất thường là khả thi và rất cần thiết. Ngoài ra, các doanh nghiệp nên triển khai hệ thống SIEM hoặc công cụ UEBA (User Entity Behavior Analytics) để tự động phân tích mẫu hành vi và cảnh báo khi có dấu hiệu nghi vấn. Ví dụ, một tài khoản khách hàng thông thường sẽ không tải cùng lúc hàng trăm triệu bản ghi; nếu điều này xảy ra, hệ thống cảnh báo có thể giúp ngăn chặn kịp thời trước khi toàn bộ dữ liệu bị exfiltrate.

Kiểm soát truy cập của nhà cung cấp đám mây (Cloud Provider Access Control)

Trong mô hình sử dụng dịch vụ đám mây, trách nhiệm bảo mật được chia sẻ giữa khách hàng và nhà cung cấp. Nhà cung cấp (như Snowflake) thường cung cấp sẵn các công cụ kiểm soát truy cập mạnh mẽ – nhưng khách hàng cần cấu hình và sử dụng đúng cách. Một bài học từ chiến dịch 2024 là nhiều tổ chức chưa tận dụng đầy đủ các kiểm soát truy cập mà Snowflake cung cấp, tạo kẽ hở cho hacker. Cụ thể, Mandiant chỉ ra rằng các tài khoản Snowflake bị xâm nhập đều không thiết lập “network policy” giới hạn địa chỉ IP truy cập [2]. Snowflake cho phép khách hàng cấu hình danh sách IP được phép (allow list) để chỉ chấp nhận kết nối từ mạng tin cậy của doanh nghiệp. Trong trường hợp này, nếu Ticketmaster/Santander giới hạn tài khoản Snowflake của họ chỉ cho phép đăng nhập từ IP công ty hoặc VPN, hacker sẽ khó lòng đăng nhập từ Internet công cộng dù có mật khẩu. Việc không đặt network allow list (cho phép truy cập từ bất kỳ đâu) là yếu tố thứ ba góp phần khiến nhiều tài khoản bị compromise [2]. Do đó, doanh nghiệp cần làm việc với nhà cung cấp cloud để kích hoạt các cơ chế kiểm soát truy cập sẵn có: từ giới hạn IP, giới hạn thiết bị, cho đến các chính sách conditional access (điều kiện truy cập) nâng cao hơn nếu có.

Bên cạnh đó, doanh nghiệp nên tích hợp hệ thống quản lý định danh của mình với dịch vụ cloud. Snowflake hỗ trợ tích hợp SSO qua SAML/OAuth (ví dụ tích hợp với Okta/ADFS), nghĩa là có thể áp dụng chính sách đăng nhập của doanh nghiệp (bao gồm MFA, xác minh thiết bị) cho tài khoản Snowflake. Trong hệ thống Snowflake nội bộ, công ty cho biết tất cả tài khoản sản xuất đều nằm sau Okta + MFA, nhờ đó tài khoản demo nhân viên (không có MFA) bị lộ cũng không ảnh hưởng gì đến hệ thống sản xuất [3]. Bài học ở đây là: phân vùng môi trường và kiểm soát chặt chẽ tài khoản quản trị. Tài khoản dùng cho mục đích demo, thử nghiệm nên bị giới hạn quyền truy cập dữ liệu nhạy cảm, và luôn có lớp bảo vệ bổ sung. Nhà cung cấp cloud cần hỗ trợ khách hàng trong việc kích hoạt các tính năng bảo mật này và có thể đặt chúng làm mặc định nếu được (ví dụ, yêu cầu MFA khi tạo tài khoản mới, cung cấp cảnh báo nếu tài khoản không có network policy,…).

Ngoài ra, kiểm soát truy cập nội bộ của nhà cung cấp cũng không thể bỏ qua. Một số thông tin cho thấy hacker từng tuyên bố đã xâm nhập được hệ thống của chính Snowflake (tài khoản demo của nhân viên cũ) [8]. Tuy Snowflake phủ nhận bị compromise ở cấp độ hệ thống, sự việc đó nhấn mạnh nhà cung cấp cũng phải quản lý chặt tài khoản nhân viên của mình (đặc biệt những tài khoản có quyền hỗ trợ khách hàng). Trong mô hình Zero Trust, cả khách hàng và nhà cung cấp cloud đều phải giám sát và hạn chế đặc quyền truy cập để giảm rủi ro.

Bài học và khuyến nghị cho doanh nghiệp sử dụng dịch vụ đám mây

Các sự cố của Ticketmaster, Santander là hồi chuông cảnh tỉnh cho mọi tổ chức đang dùng dịch vụ đám mây, đặc biệt là các nền tảng dữ liệu lớn như Snowflake. Dưới đây là những bài học rút ra và khuyến nghị cụ thể nhằm tăng cường bảo mật:

• Bật xác thực đa yếu tố (MFA) ở mọi nơi: Mọi tài khoản người dùng và dịch vụ trên cloud nên được bảo vệ bởi MFA hoặc SSO an toàn. Đây là lớp phòng thủ hiệu quả nhất ngăn chặn việc kẻ xấu dùng mật khẩu đánh cắp để đăng nhập trái phép [2]. Đặc biệt, tài khoản quản trị và tài khoản chứa dữ liệu nhạy cảm bắt buộc phải có MFA.
• Quản lý chặt chẽ và luân phiên thông tin đăng nhập: Doanh nghiệp cần có chính sách đổi mật khẩu định kỳ và ngay lập tức vô hiệu hóa thông tin xác thực bị lộ. Trong chiến dịch Snowflake, nhiều mật khẩu bị đánh cắp từ năm 2020 vẫn còn hiệu lực đến 2024 do không được thay đổi [2]. Cần tránh dùng chung mật khẩu giữa các dịch vụ, sử dụng trình quản lý mật khẩu và triển khai xác thực tập trung (SSO) để dễ kiểm soát việc cấp phát/thu hồi quyền truy cập.
• Áp dụng nguyên tắc quyền hạn tối thiểu: Cấp quyền truy cập ít nhất có thể trên hệ thống cloud. Đánh giá lại các tài khoản dịch vụ, đối tác xem họ có thực sự cần quyền truy cập đầy đủ vào toàn bộ dữ liệu hay không. Ví dụ, Ticketmaster có thể tách riêng kho dữ liệu theo khu vực hoặc phân quyền chỉ cho đối tác EPAM truy cập một phần dữ liệu giới hạn. Nếu một tài khoản bị lộ, thiệt hại sẽ khoanh vùng nhỏ hơn.
• Kích hoạt kiểm soát mạng và điều kiện truy cập: Tận dụng các tính năng như Network Policies trên Snowflake (hoặc tương đương trên nền tảng khác) để giới hạn phạm vi IP, thời gian, địa điểm truy cập. Chỉ cho phép truy cập dịch vụ cloud từ mạng công ty, VPN, hoặc qua proxy bảo mật. Thiết lập conditional access – ví dụ yêu cầu VPN nếu đăng nhập từ ngoài văn phòng, chặn đăng nhập từ quốc gia lạ, v.v. – để giảm thiểu nguy cơ xâm nhập từ bên ngoài [2].
• Giám sát liên tục và phát hiện sớm bất thường: Triển khai giải pháp giám sát an ninh cho các dịch vụ cloud (như Cloud SIEM, log analytics). Bật log đầy đủ trên Snowflake và thiết lập cảnh báo theo ngưỡng cho các sự kiện bất thường: đăng nhập thất bại nhiều, truy vấn tải dữ liệu lớn, tạo user mới, thay đổi cấu hình bảo mật,… Sử dụng machine learning để nhận diện hành vi bất thường của người dùng. Mandiant đã cung cấp các truy vấn mẫu giúp phát hiện hoạt động nghi vấn trong Snowflake – doanh nghiệp nên tham khảo và tùy biến áp dụng cho hệ thống của mình [2].
• Đánh giá rủi ro và quản lý nhà cung cấp/đối tác: Rất nhiều vi phạm xảy ra thông qua bên thứ ba (như trường hợp EPAM). Do đó, doanh nghiệp cần kiểm tra bảo mật các đối tác có quyền truy cập hệ thống hoặc dữ liệu của mình. Đảm bảo họ cũng tuân thủ các nguyên tắc an ninh (MFA, máy tính sạch malware, không lưu mật khẩu thô, …). Nên giới hạn quyền của tài khoản đối tác, và theo dõi hoạt động của họ trên hệ thống. Nếu có thể, sử dụng các giải pháp Privileged Access Management cho bên thứ ba: cấp quyền tạm thời và thu hồi sau khi xong việc, thay vì cung cấp tài khoản tĩnh dài hạn.
• Phân tách môi trường và dữ liệu nhạy cảm: Học hỏi từ Snowflake – họ tách môi trường demo khỏi môi trường sản xuất và bảo vệ nghiêm ngặt hơn ở sản xuất [3]. Doanh nghiệp cũng nên phân loại dữ liệu (nhạy cảm vs không nhạy cảm) và lưu trên các tài khoản/hệ thống khác nhau. Nếu một môi trường bị xâm nhập, thiệt hại sẽ không lan sang toàn bộ hệ thống. Đồng thời, mã hóa dữ liệu nhạy cảm ở mức trường (field-level encryption) khi lưu trên cloud để dù hacker có lấy được dữ liệu, chúng cũng khó sử dụng nếu không có khóa giải mã.
• Chuẩn bị kế hoạch ứng phó sự cố và extortion: Các tổ chức cần có kế hoạch chi tiết cho tình huống bị rò rỉ dữ liệu và bị tống tiền. Kế hoạch bao gồm: quy trình thông báo khách hàng và cơ quan chức năng, cách cô lập hệ thống bị xâm nhập, điều tra pháp y để tìm lỗ hổng, và chiến lược đàm phán (hoặc không đàm phán) với hacker. Cần tập dượt trước kịch bản hacker đòi tiền chuộc dữ liệu (Tabletop Exercise) để đội ngũ quản lý không bị lúng túng khi đối mặt thực tế. Ví dụ, trong vụ Snowflake, kẻ tấn công thậm chí đòi 20 triệu USD từ chính Snowflake để đổi lấy việc không công bố dữ liệu của ~400 tổ chức [3]. Đây là tình huống rất khó xử lý, do vậy chuẩn bị trước một chính sách về việc trả hay không trả tiền chuộc, và phối hợp luật sư, cơ quan thực thi pháp luật là điều nên làm.
• Không chủ quan với bảo mật cloud: Cuối cùng, bài học tổng quát là điện toán đám mây không tự động đảm bảo an toàn – trách nhiệm bảo mật vẫn thuộc về doanh nghiệp sử dụng. Các tổ chức nên thường xuyên đánh giá cấu hình bảo mật trên cloud (theo các khung như CIS Benchmarks), cập nhật bản vá cho các máy chủ kết nối tới cloud, và theo dõi các thông báo từ nhà cung cấp về mối đe dọa. Như chuyên gia nhận định, sự kiện Snowflake 2024 cho thấy “danh tính (identity) chính là chu vi an ninh mới” [5] trong kỷ nguyên cloud: thay vì tường lửa vật lý, chính việc quản lý tài khoản và credential mới là tuyến phòng thủ quan trọng nhất. Do đó, đầu tư vào quản trị định danh, đào tạo nhân viên nâng cao ý thức (để tránh nhiễm malware đánh cắp thông tin), và áp dụng nguyên tắc Zero Trust sẽ giúp doanh nghiệp đứng vững trước các cuộc tấn công kiểu data exfiltration + extortion đang ngày càng gia tăng.

Nguồn tài liệu tham khảo: Các thông tin trong báo cáo được tổng hợp từ nhiều nguồn uy tín, bao gồm blog bảo mật của Mandiant/Google Cloud [2], báo cáo của Cloud Security Alliance [10], các bài viết chuyên sâu trên Wired [6], SecurityWeek [3], Banking Dive [8], cùng thông cáo báo chí chính thức của Santander [7]và tuyên bố từ Ticketmaster. Những sự kiện thực tế này cung cấp bài học quý giá về mối nguy Cloud Data Exfiltration & Data Extortion và cách thức chúng ta có thể phòng tránh trong tương lai.

Tài liệu tham khảo

[1] ]Sự chuyển dịch từ tấn công ransomware sang tống tiền bằng đánh cắp dữ liệu
https://www.blackfog.com/shift-from-ransomware-to-data-theft-extortion/

[2] Nhóm UNC5537 tấn công các phiên bản khách hàng của Snowflake để đánh cắp và tống tiền dữ liệu | Blog Google Cloud
https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion

[3] Sự cố rò rỉ dữ liệu Snowflake ảnh hưởng đến Ticketmaster và nhiều tổ chức khác – SecurityWeek |https://www.securityweek.com/snowflake-hack-impacts-ticketmaster-other-organizations/

[4] Sự cố rò rỉ dữ liệu Ticketmaster: Chuyện gì đã xảy ra và cách phòng tránh | https://www.strongdm.com/what-is/ticketmaster-data-breach

[5] Snowflake: Nhìn lại sự kiện an ninh mạng nổi bật của năm 2024
https://pushsecurity.com/blog/snowflake-retro/

[6] Tin tặc tiết lộ cách chúng đánh cắp dữ liệu Ticketmaster từ Snowflake | WIRED
https://www.wired.com/story/epam-snowflake-ticketmaster-breach-shinyhunters/

[7] Tuyên bố của Santander
https://www.santander.com/en/stories/statement

[8]Tin tặc đe dọa bán thông tin khách hàng của Santander với giá 2 triệu USD: theo báo cáo | Banking Dive
https://www.bankingdive.com/news/hackers-breach-santander-customer-data-threaten-sell-2-million-ticketmaster-snowflake-shinyhunters/717807/

[9] Tổng quan về vụ rò rỉ dữ liệu Snowflake: Kẻ tấn công rao bán dữ liệu của khách hàng công ty điện toán đám mây – SOCRadar® Cyber Intelligence Inc
https://socradar.io/overview-of-the-snowflake-breach/

[10] Phân tích chi tiết vụ rò rỉ dữ liệu Snowflake năm 2024 | CSA
https://cloudsecurityalliance.org/blog/2025/05/07/unpacking-the-2024-snowflake-data-breach