Đừng hoảng khi có vấn đề xảy ra
Khoảng một tuần trước bác khách hàng của mình có email hỏi mình xem có phải mình tạo 70 instances trên DigitalOcean account phải không? Móa, hơi hoảng, vì mình mới được add vào team account của khách hàng với role admin và vấn đề xảy ra đúng khoảng thời gian mình được add vào.
Sau khi nhận được tin nhắn, ngay lập tức mình vào check lại account rồi kiểm tra xem PAT (Personal Access Token) của mình có bị leak không. (Theo mình thấy thì tất cả các cloud provider đều cho biết lần gần nhất PAT được sử dụng khi nào). Sau khi kiểm tra thì mình thấy không phải key của mình nên mình báo cho bác ấy là không phải của mình đâu, có thể một ai đó trong team bị leak PAT. Tiếp tục mình remove tất cả các team members ra khỏi account để tránh tình huống các instance bị tạo thêm hoặc xóa mất các instances đang có.
Kiểm tra thêm thì mình thấy 70 instances này đã được tạo 5 ngày trước đó, và mỗi giờ 1 instance mất $1, có nghĩa là khoảng $1680 một ngày, gần 5 ngày mất khoảng ~$8000, khá là thốn. ^_^
Nếu bạn cũng gặp phải tình huống tương tự thì đừng hoảng hốt quá nhé, hãy bình tĩnh, xử lý vấn đề, khoanh vùng để tránh tình huống xấu hơn xảy ra.
Xử lý vấn đề thay vì truy cứu trách nhiệm
Ngay khi tình huống xảy ra mình đã báo bác khách hàng rằng mình sẽ remove tất cả các members ra khỏi team và nhờ bác hỏi mọi người xem có ai sử dụng key và có khả năng để lộ ra bên ngoài không, còn mình sẽ đi xử lý các vấn đề.
- Xóa các members ra khỏi team
- Kiểm tra tình hình sử dụng của các key
- Xóa các instances được tạo ra bởi hacker
- Liên hệ với DigitalOcean để xem có thể hoàn tiền không.
Xóa members ra khỏi team
Đây là hành động có thể khá thừa nhưng cũng khá hiệu quả khi bạn chưa thể khoanh vùng được vấn đề, thường thì PAT sẽ được tạo ra bởi các member và link với tài khoản tạo ra PAT đó, chính vì vậy đây là một bước khá hiệu quả để giảm thiểu rủi ro, mặc dù bạn sẽ phải mất thời gian để add lại các thành viên sau đó.
Kiểm tra tình hình sử dụng của các key
Tất cả các nhà cung cấp mình đã sử dụng như AWS, Azure, DigitalOcean, ... đều cho phép xem tình hình sử dụng các API Key / Access Token Key / Personal Key / Team Key, ... nên việc kiểm tra tình hình sử dụng cũng như ai đã sử dụng key với mục đích gì đểu được thể hiện rất rõ. Việc này giúp cho bạn có thể khoanh vùng được vấn đề. Thực sự là vậy. Sau khi kiểm tra key logs, mình phát hiện ra key này được tạo ra bởi một thành viên đã nghỉ việc trong team nhưng bác khách hàng quên xóa thành viên đó ra khỏi team và bạn đó đã để lộ key ra ngoài cho các hacker có cơ hội sử dụng key đó.
Xóa các instances được tạo ra bởi hacker
Mỗi giờ trôi qua, 70 instances sẽ tiêu tốn $70, như vậy nếu bạn không nhanh chóng xóa các instances đó thì túi tiền của bạn sẽ nhanh chóng bị vơi đi. Nhưng vào trong tài khoản, chọn instances và xóa 70 lần? Hầu như các provider sẽ không cho bạn chọn nhiều instances và xóa cùng lúc, theo như mình nhớ là như vậy, nên việc xóa này sẽ mất khá nhiều thời gian. Thay vào đó mình đã viết một đoạn shell scripts nhỏ để filter 70 instances đó và loop qua 70 instances id và execute lệnh xóa từng instances, điều này đã giúp mình tiết kiệm được khá nhiều thời gian (Chỉ mất khoảng 5p sử dụng ChatGPT để generate script và chỉnh sửa cho phù hợp) thêm khoảng 2 phút để xóa hết 70 instances. Việc này cũng khá rủi ro nên bạn cùng cần fitler các instances cẩn thận.
Liên hệ với nhà cung cấp để khắc phục vấn đề
Tại sao lại liên hệ với nhà cung cấp trong khi mình là người gây ra vấn đề? Thực sự là các nhà cung cấp họ cũng muốn kiếm tiền nhưng họ cũng muốn khách hàng của họ được lợi nhất, vì vậy trong tình huống này họ sẽ cân nhắc để cùng hỗ trợ với mình giảm thiểu thiệt hại. Chính vì vậy đây cũng là công việc mình đã bắt tay làm ngay sau khi xóa các instances.
Kiên trì & nhận trái ngọt
Ngay sau khi đã thực hiện các bước cần thiết để giảm thiểu rủi ro, mình đã email cho DigitalOcean như đã nói ở trên với mục đích kể khổ là mình không có tạo 70 instances đó đâu, một nhân viên đã nghỉ việc từ trước đó đã để lộ key và hacker đã sử dụng key đó để tạo ra các instances chứ mình không muốn như vậy.
Đội ngũ hỗ trợ của DigitalOcean cũng rất nhanh chóng trả lời cho mình (khoảng chưa đầy một tiếng sau khi mình email) nhưng họ vả ngay vào mặt mình với dòng in đậm là mày phải tự bảo mật token của mày và kèm theo trích dẫn điều khoản sử dụng dịch vụ của họ. Trong đó nêu, khách hàng phải chịu trách nhiệm cho bất cứ tình huống nào xảy ra. Thiệt sự, thì đúng là vậy. Mình cũng hiểu vậy và mình cũng dùng hạ tầng của họ 5 ngày qua mà =)) (Mặc dù không phải do mình. haha)
Tuy nhiên, mình cũng rất bình tĩnh vì mình hiểu rằng DigitalOcean là nhà cung cấp dịch vụ khá lớn nên họ cũng không thể vì một chút chuyện nhỏ mà để mất đi một khách hàng nên mình đã phản đòn ngay với nội dung:
Tao biết, và tao cũng hiểu các điều khoản dịch vụ, tuy nhiên trường hợp này là không mong muốn, tụi tao đã quên xóa nhân viên cũ khỏi team nên đã xảy ra tình huống này. Nhưng hi vọng mày nên cân nhắc lại vì tao thường xuyên sử dụng DigitalOcean từ năm 2018 đến giờ.
Sau đó khoảng 1 tiếng thì đội ngũ hỗ trợ cũng mail lại mình bảo rất tiếc trong tình huống này nhưng họ cũng sẽ chuyển qua cấp trên để xem có thể giải quyết được không
Sau khoảng gần 2 ngày không thấy phản hồi mình lại tiếp tục email rồi kể khổ tiếp
Này, đây là một khoản tiền khá lớn, nên tao hi vọng tụi mày có thể xem xét cho trường hợp của tao và hoàn tiền cho tụi tao Tao đánh giá rất cao sự hỗ trợ của tụi mày
Thế là vài tiếng sau đồng chí khác trong team DigitalOcean đã liên hệ cho mình bảo là đồng chí đồng nghiệp đã liên hệ với cấp trên để xem có thể xử lý được không.
Sau khi chờ tiếp thêm hơn một ngày, không thấy phản hồi mình lại quăng cho họ một email tiếp để hối họ trả lời và kết quả là sau 3 ngày giải quyết họ đã deposit vô tài khoản của bác khách hàng mình ~$8000 để trả cho khoản tiền bị mất vì 70 instances ở trên. Quá sướng!
Thành quả ^_^
Ngay sau đó mình cũng không quên email cảm ơn đội ngũ hỗ trợ và hứa sẽ tiếp tục sử dụng + giới thiệu dịch vụ =))
Bài học rút ra
Việc sử dụng cloud sẽ có rất nhiều lợi ích và mang lại hiệu quả cao cho doanh nghiệp, bên cạnh đó cũng mang lại nhiều rủi ro tiềm ẩn nên mình cũng muốn nhân đây chia sẻ cho các bạn các bước để phòng tránh rủi ro và khắc phụ hậu quả nếu có vấn đề xảy ra.
- Đọc kỹ điều khoản dịch vụ thành vì chỉ nhấn đồng ý và đăng ký
- Chỉ thêm những người thực sự cần thiết vào quản lý tài khoản
- Xóa những ai đã rời khỏi team hoặc không còn trách nhiệm trong việc quản lý tài nguyên
- Không nên tạo các token có thời hạn quá lâu (Đa số các provider đều cho phép tạo token trong thời gian ngắn, nếu được bạn nên sử dụng các token này). Đối với trường hợp bắt buộc phải tạo no expiry token (VD: CI/CD) thì chỉ administrator có quyền được tạo và sau đó xóa khỏi bộ nhớ, không lưu vào bất kì nơi nào khác ngoài secret key storage (vault).
- Nên rotate token thay vì sử dụng token vĩnh viễn (Mặc dù có những tình huống cần phải sử dụng no expiry token nhưng theo mình thay vì sử dụng các token này thì bạn nên sử dụng các token ngắn và có một tác vụ để gia hạn và cập nhật token thường xuyên để đảm bảo an toàn)
- Không lưu token ở các máy tính bảo mật kém, push lên git, ...
- Nên giới hạn số lượng resources được tạo ra thay vì request quá nhiều (Thường thì các provider sẽ cho phép bạn tạo một số lượng giới hạn các instances, resources để tránh các tình huống đáng tiếc, bạn hoàn toàn có thể request thêm khi cần nhưng hãy cân nhắc request số lượng vừa phải, khi nào cần thì request thêm. Trong trường hợp mình mô tả ở trên thì công ty đã request 100 instances trong khi chỉ sử dụng có 30, và thừa tới 70 -> thiệt hại cũng khá nặng nề)
- Không nên hoảng hốt, tìm và đổ lỗi, thay vào đó hãy khoanh vùng và giải quyết ngay lập tức
- Liên hệ với nhà cung cấp đề nhờ họ hỗ trợ, đồng thời chia sẻ thiệt hại
- Cuối cùng hãy liên tục kiểm tra tình trạng sử dụng của các token để đảm bảo tài khoản trong tình trạng được bảo mật