Điện thoại là thiết bị riêng tư nhất mà một người sở hữu. Nó chứa danh bạ, vị trí, hình ảnh, thông tin thanh toán và cả thói quen sinh hoạt của chủ nhân. Khi người dùng cài một ứng dụng, họ ngầm trao cho nhà phát triển một phần niềm tin về những dữ liệu đó. Chỉ cần một sự cố rò rỉ, niềm tin ấy sụp đổ và rất khó xây lại. Với một công ty làm app, bảo mật không phải là tính năng cộng thêm để bán, mà là nền móng đạo đức và pháp lý của toàn bộ sản phẩm. Bài viết này điểm qua những lớp phòng thủ cơ bản mà bất kỳ dự án nghiêm túc nào cũng cần có.

Thu thập ít nhất có thể

Nguyên tắc quan trọng nhất lại là nguyên tắc dễ bị bỏ qua nhất: chỉ thu thập dữ liệu thực sự cần thiết cho chức năng. Nhiều ứng dụng xin quyền truy cập danh bạ, vị trí nền hay micro chỉ vì lập trình viên nghĩ rằng sau này có thể dùng đến. Đây là tư duy nguy hiểm. Dữ liệu bạn không lưu là dữ liệu không thể bị đánh cắp. Trước khi thêm bất kỳ trường thông tin hay quyền nào, đội ngũ nên tự hỏi tính năng nào cần đến nó, và nếu không có câu trả lời rõ ràng thì đừng thu thập.

Cách xin quyền cũng cần được thiết kế đúng thời điểm. Thay vì đòi hết mọi quyền ngay khi mở app lần đầu, hãy xin quyền vị trí ngay lúc người dùng bấm nút tìm cửa hàng gần nhất, xin quyền máy ảnh ngay khi họ muốn chụp ảnh sản phẩm. Ngữ cảnh rõ ràng làm tỷ lệ đồng ý tăng lên và cũng thể hiện sự tôn trọng với người dùng.

Mã hóa dữ liệu khi lưu trữ và khi truyền

Dữ liệu tồn tại ở hai trạng thái, và cả hai đều cần được bảo vệ. Khi truyền qua mạng, mọi kết nối đều phải đi qua giao thức mã hóa hiện đại, tuyệt đối không gửi thông tin nhạy cảm qua kết nối không được bảo vệ. Với những ứng dụng đòi hỏi mức an toàn cao như ngân hàng, có thể áp dụng thêm kỹ thuật ghim chứng chỉ để chống lại tấn công xen giữa, ngăn kẻ gian giả mạo máy chủ.

Khi lưu trên máy, dữ liệu nhạy cảm không bao giờ được để dưới dạng văn bản thuần. Các hệ điều hành đã cung cấp sẵn kho lưu trữ an toàn ở cấp phần cứng, đó là nơi duy nhất nên đặt token đăng nhập, khóa bí mật hay thông tin thanh toán. Một lỗi kinh điển là ghi mật khẩu hoặc khóa API vào tệp cấu hình hay log gỡ lỗi, để rồi lộ ra khi ai đó phân tích gói cài đặt.

Xác thực và quản lý phiên đúng cách

Cơ chế đăng nhập là cửa ngõ của mọi ứng dụng có tài khoản, nên nó phải được làm chắc chắn:

  • Không tự phát minh thuật toán băm mật khẩu mà dùng các chuẩn đã được kiểm chứng, luôn thêm chuỗi ngẫu nhiên cho từng mật khẩu để chống dò bảng.
  • Dùng token có thời hạn ngắn kèm cơ chế làm mới, để nếu token bị lộ thì thiệt hại cũng giới hạn trong khoảng thời gian ngắn.
  • Cho phép người dùng bật xác thực hai lớp và tận dụng vân tay hay khuôn mặt của thiết bị cho những thao tác nhạy cảm.
  • Cung cấp cách đăng xuất khỏi mọi thiết bị và thông báo khi có đăng nhập lạ.

Quan trọng không kém là mọi quyền hạn phải được kiểm tra ở phía máy chủ, không bao giờ tin tưởng phía client. Ứng dụng trên điện thoại có thể bị can thiệp, nên máy chủ luôn phải giả định mỗi yêu cầu gửi lên đều có thể đến từ một kẻ giả mạo và xác minh lại quyền truy cập tương ứng.

Bảo vệ phía máy chủ và giao diện lập trình

Phần lớn dữ liệu thực ra nằm ở phía máy chủ, nên đây mới là mục tiêu béo bở nhất. Các giao diện lập trình cần được rà soát để tránh những lỗ hổng phổ biến: chèn mã truy vấn cơ sở dữ liệu, tham chiếu trực tiếp tới đối tượng khiến người dùng này xem được dữ liệu của người dùng khác chỉ bằng cách đổi số thứ tự trên đường dẫn, hay để lộ thông tin thừa trong phản hồi. Cần đặt giới hạn số lần gọi để chống dò mật khẩu và chống lạm dụng, đồng thời ghi nhật ký truy cập để phát hiện hành vi bất thường.

Một thói quen tốt là định kỳ thuê kiểm thử xâm nhập từ bên thứ ba độc lập. Người ngoài với con mắt của kẻ tấn công thường thấy những điểm yếu mà đội phát triển đã quá quen nên bỏ qua.

Tuân thủ pháp lý và minh bạch với người dù

Bảo mật kỹ thuật phải đi cùng sự minh bạch. Ứng dụng cần có chính sách quyền riêng tư viết bằng ngôn ngữ dễ hiểu, nói rõ thu thập gì, dùng vào việc gì, chia sẻ với ai và lưu trong bao lâu. Với những thị trường có quy định chặt về dữ liệu cá nhân, người dùng còn có quyền yêu cầu tải về hoặc xóa toàn bộ dữ liệu của mình, và ứng dụng phải hỗ trợ được điều đó về mặt kỹ thuật.

Cuối cùng, cần chuẩn bị sẵn quy trình ứng phó sự cố trước khi sự cố xảy ra. Ai là người chịu trách nhiệm, các bước cô lập lỗ hổng, cách thông báo cho người dùng bị ảnh hưởng, thời hạn khai báo với cơ quan chức năng đều nên được viết ra từ trước. Một sự cố được xử lý nhanh, trung thực và có trách nhiệm đôi khi còn giúp giữ được niềm tin, trong khi sự che giấu luôn khiến mọi thứ tồi tệ hơn. Đầu tư cho bảo mật không mang lại tính năng hào nhoáng để quảng cáo, nhưng nó là thứ bảo vệ cả người dùng lẫn danh tiếng của doanh nghiệp trong dài hạn.