Nghe chuyên gia bảo mật có tiếng đang làm việc tại Mỹ nhận định "có nên dùng Money Lover không"

*Chúng tôi xin được trích dẫn nguyên văn ý kiến của một chuyên gia bảo mật người Việt, hiện đang làm việc cho Google tại Mỹ. Theo yêu cầu của tác giả, chúng tôi xin được phép giấu tên.

Tôi thấy đây là một vấn đề kỹ thuật thú vị.

Có ý kiến cho rằng ở trên thế giới không ai làm như ML. Tôi nghĩ thế giới rộng lớn lắm nên tôi không dám nói bừa. Tôi biết ở Mỹ có dịch vụ Mint.com rất phổ biến cũng lưu mật khẩu ngân hàng của khách hàng.

Cũng có ý kiến cho rằng ML có thể hoàn toàn không lưu mật khẩu của người dùng (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 người dùng chạy app, rất khó hiện thực hóa các chức năng 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ề được. Có thể có 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 đó.

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 máy chủ 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 yêu cầu đến các ngân hàng để lấy HTTP cookies, thông qua một API đơn giản gọn nhẹ.

Câu hỏi mà chúng ta quan tâm ở đây là làm sao bảo vệ mật khẩu. Đâ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 máy chủ 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 yêu cầu đến các ngân hàng để lấy HTTP 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 (cản lọc thông qua TCP/IP firewall hoặc các phương án xác thực API như của Amazon).

Trên máy chủ 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 hị 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 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 yêu cầu đế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 yêu cầu đến KMS vào lúc 1h trưa.

Bây giờ nói đến chuyện làm sao ngay cả kỹ sư 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 mật khẩu của người dùng. Chỗ này nhiêu khê hơn nhiều.

Các crawler sẽ lấy cookies từ máy chủ lưu mật khẩu, dùng chúng để gửi yêu cầu đế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í có thể tách ra hẳn 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 máy chủ crawler, đội làm mật khẩu chỉ có thể vào máy chủ mật khẩu, đội làm dữ liệu giao dịch chỉ có thể làm trên máy chủ lưu dữ liệu giao dịch. Đây là nguyên tắc quyền hạn tối thiểu (least privileged) mà chúng ta điều biết.

Bây giờ nói đến chuyện làm sao ngay cả kỹ sư 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 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 kỹ sư vào để gỡ rối. 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 máy chủ phải đến hỏi một máy chủ trung gian, máy chủ 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 tin tưởng nhưng kiểm tra (trust but verify) đội nhóm kỹ sư. Ai làm bậy sẽ bị phát hiện, không sớm thì muộn.

Một mẹo nhỏ là mỗi người nên có nhiều tài khoản và chỉ đưa vào ML các tài khoản liên quan đến chi tiêu, chứ đừng đưa vào đó tài khoản tiết kiệm hay những dạng tài khoản mà nếu mất mật khẩu mình có thể bị mất tiền.

Đối với những thao tác mang tính định kỳ như cập nhật hệ thống, phát hành phần mềm mới, điều quan trọng là phải tự động hóa. Ví dụ như khi lập trình viên viết mã mới, mã này phải được xem xét, đánh giá và đồng ý bởi ít nhất một người khác, xong rồi mới được chuyển vào kho mã của công ty. Cấu hình máy chủ cũng vậy, tất cả phải qua khâu kiểm duyệt 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 mã mới, một quy trình tự động sẽ lấy mã từ kho mã, đóng gói, 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ụ điện toán đám mây 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/ ).

Đối với người dùng bình thường, có nên sử dụng ML hay không?

Tôi nghĩ nên, vì nó là một cách tốt để quản lý chi tiêu, nhưng cũng phải cẩn thận. Một mẹo nhỏ là mỗi người nên có nhiều tài khoản và chỉ đưa vào ML các tài khoản liên quan đến chi tiêu, chứ đừng đưa vào đó tài khoản tiết kiệm hay những dạng tài khoản mà nếu mất mật khẩu mình có thể bị mất tiền.

Tôi không rõ ở VN như thế nào, nhưng ở Mỹ tôi có thể mở tài khoản thẻ tín dụng riêng, tách biệt với tài khoản nhận lương hay tài khoản tiết kiệm, tài khoản đầu tư. Bao nhiêu chi tiêu hàng ngày đi vào tài khoản thẻ tín dụng, ngoài ra không có gì khác. Nếu ai có mật khẩu của các tài khoản này tôi sẽ bị mất một ít thông tin cá nhân, nhưng sẽ không mất tiền.

Dẫu có sử dụng ML hay không, tôi nghĩ mỗi người nên yêu cầu xác thực hai lớp (two-factor authentication) cho các giao dịch chuyển tiền ra khỏi tài khoản. Điều này làm giảm rủi ro mất tiền nếu lỡ như mật khẩu bị đánh cắp. Tôi nghĩ đa số các ngân hàng ở Việt Nam đều hỗ trợ biện pháp bảo vệ này. Khi đã có xác thực hai lớp, sử dụng ML cũng bớt nguy hiểm hơn.