Sau anh Lê Nguyên Khang, chuyên gia bảo mật đang làm việc cho Google là Dương Ngọc Thái mới đây đã đã nêu ý kiến của mình về ứng dụng quản lý chi tiêu Money Lover (ML)
Mời bạn tham khảo thêm trường hợp của Money Lover: https://www.techsignin.com/cong-nghe/chuyen-gia-bao-mat-vccorp-nghi-ngo-money-lover/
Dưới đây là quan điểm của anh dương Ngọc Thái về một hướng để kiện toàn hệ thống lưu mật khẩu nhạy cảm của người dùng:
“Tôi thấy đây là một vấn đề thú vị. Có ý kiến cho rằng ML có thể hoàn toàn không lưu mật khẩu của user (http://linkhay.com/ngo-xuan-huy-founder-cua-money-lover-tra-loi-cac-cau-hoi-lien-quan-toi-vu-lum-xum-gan-day-946/1214923#c1314609), nhưng tôi nghĩ khó có khả năng ML thực hiện theo mô hình này, vì như vậy hệ thống chỉ có dữ liệu mới khi mà user mở app ra, rất khó hiện thực hóa các chức năng thiên về thống kê mà ML muốn làm.
Tôi nghĩ ML lưu mật khẩu của người dùng trên máy chủ của họ. Tôi nghĩ chuyện này cũng bình thường, vì nếu không lưu thì làm sao mà lấy dữ liệu từ ngân hàng về cho được. Có thể có vài ngân hàng triển khai các phương án như OAUTH, nhưng tôi nghĩ đa số ngân hàng không có động cơ để làm chuyện đó.
Câu hỏi mà chúng ta quan tâm ở đây là làm sao lưu mật khẩu cho an toàn. Đây là một vấn đề khó, muốn giải quyết phải thay đổi rất nhiều thứ, chuyện này không đơn giản là chỉ cần mã hóa mật khẩu. Hồi trước có lần một công ty làm game hỏi tôi làm thế nào để đảm bảo máy chủ chứa dữ liệu thẻ game của họ không bị chính mấy ông DBA vào chỉnh sửa chôm chỉa. Lúc đó tôi không có câu trả lời, nhưng bây giờ tôi nghĩ tôi biết chút ít.
Nếu tôi thiết kế hệ thống này, tôi sẽ chuyển toàn bộ mật khẩu vào lưu ở một nhóm server tách biệt, không làm gì khác, ngoại trừ việc lưu mật khẩu và gửi request đến các ngân hàng để lấy cookies, thông qua một API đơn giản gọn nhẹ. Chỉ có các máy chủ crawler mới có thể sử dụng API này (thông qua TCP/IP firewall hoặc các phương án Digital Signature hoặc MAC, như các API của Amazon hay làm).
Trên server lưu mật khẩu, tôi sẽ mã hóa các mật khẩu này sử dụng dịch vụ Amazon KMS. Nói cách khác nếu ai đó truy cập vào các máy chủ lưu mật khẩu, họ cũng không thể lấy toàn bộ mật khẩu, mà họ phải lần lượt gửi yêu cầu đến KMS để giải mã chúng. Ý tưởng này coi bộ đơn giản nhưng tôi nghĩ nó là mấu chốt trong việc phát hiện, phòng chống và phản ứng lại khi có xâm nhập.
Chúng ta muốn kẻ tấn công phải ở trong hệ thống của mình càng lâu càng tốt, với hy vọng ở càng lâu chúng sẽ tạo ra nhiều “tiếng ồn”, làm gia tăng cơ hội hệ thống giám sát an ninh mạng của chúng ta phát hiện ra chúng. Ví dụ như nếu tôi biết rằng máy chủ lưu mật khẩu chỉ gửi request đến Amazon KMS vào lúc 12h sáng (vì đó là lúc crawler chạy), tôi sẽ thấy hoài nghi khi thấy nhiều request đến KMS vào lúc 1h trưa.
Các crawler sẽ lấy cookies từ máy chủ lưu mật khẩu, dùng chúng để gửi request đến các ngân hàng, lưu dữ liệu giao dịch của khách hàng vào một nhóm máy chủ tách biệt với các máy chủ lưu mật khẩu (và thậm chí là các crawler). Với kiến trúc như vậy, chúng ta sẽ có thể hạn chế được ai truy cập vào đâu.
Ví dụ đội làm crawler chỉ có thể vào crawler, đội làm mật khẩu chỉ có thể vào máy chủ mật khẩu, đội làm transaction data chỉ có thể làm trên transaction data. Đây là nguyên tắc least privileged mà chúng ta điều biết.
Bây giờ nói đến chuyện làm sao ngay cả engineer hoặc sysadmin làm việc trên các máy chủ lưu mật khẩu cũng không thể nhìn thấy các mật khẩu của người dùng. Chỗ này nhiêu khê hơn nhiều. Về mặt nguyên tắc, chúng ta không thể loại trừ 100%, vì sẽ có lúc hệ thống gặp sự cố, phải cho sysadmin hoặc engineer vào để debug.
Nhưng đó sẽ là những tình huống ngoại lệ và mỗi phiên truy cập như vậy đều phải được một hệ thống trung gian ghi lại nhật ký một cách tự động. Ví dụ như muốn SSH vào server phải đến hỏi một server trung gian, server này sẽ ghi lại nhật ký và cấp cho một SSH certificate tạm thời. Nhật ký này sẽ được kiểm tra định kỳ hàng tháng. Nói cách khác, chúng ta trust-but-verify các kỹ sư (engineer). Ông nào làm bậy sẽ bị phát hiện, không sớm thì muộn.
Đối với những thao tác mang tính định kỳ như cập nhật hệ thống, deploy new code, điều quan trọng là phải có một hệ thống release management được tự động hóa. Ví dụ như khi lập trình viên viết code mới, code này phải được review bởi ít nhất một người khác, xong rồi mới được commit vào repository của công ty.
Cấu hình server cũng vậy, tất cả phải qua khâu review rồi mới được chấp nhận. Chuyện này phải trở thành văn hóa của công ty. Khi đã sẵn sàng để tải code mới lên hệ thống, một quy trình tự động sẽ lấy code từ repository, build ra binary, chuyển lên máy chủ để chạy. Trong suốt quá trình này, các kỹ sư có thể theo dõi tiến trình và can thiệp khi cần thiết, nhưng nếu mọi thứ diễn ra trơn tru, con người sẽ không cần phải đụng tay vào nữa.
Không thể xây dựng các hệ thống này ngày một ngày hai và trong một email ngắn khó có thể diễn ra được hết tất cả các vấn đề cần phải giải quyết. Đối với một công ty nhỏ như ML, thay vì tập trung giải quyết các vấn đề này tôi nghĩ họ nên tận dụng các giải pháp có sẵn và thuê tư vấn. ML đã rất sáng suốt khi sử dụng dịch vụ cloud computing của Amazon, tôi hi vọng là Amazon có các giải pháp cho các vấn đề mà tôi nói ở trên. Tôi làm ở Google nên tôi biết hầu hết các vấn đề này đều có thể được giải quyết bằng các công cụ được cung cấp trên Google Cloud Platform (https://cloud.google.com/products/).
Có người nói đưa dữ liệu lên cloud sợ Amazon hay Google sẽ lấy dữ liệu của họ. Tôi thấy chuyện này giống như lo sử dụng máy tính của Apple hay của Microsoft sợ các công ty này cài backdoor để lấy dữ liệu. Nhưng thôi, đây là chuyện khác, hôm khác nói.”
Việc dùng Amazon Key Management Service (KMS) như là nhà cung cấp dịch vụ mã hóa các mật khẩu là một ý tưởng rất lý thú và khả dĩ, đây kiểu đặt niềm tin vô một bên thứ 3 có uy tín được xác nhận bởi đa số.
(Tổng hợp)
