Làm thế nào để bảo mật dữ liệu người dùng trong cơ sở dữ liệu với Rails?

Question

Tôi đang tạo một ứng dụng đường ray cần lưu trữ một lượng lớn dữ liệu nhạy cảm. Để đảm bảo với khách hàng của tôi rằng dữ liệu đang được bảo vệ, tôi muốn mã hóa nó trên cơ sở cho mỗi người dùng. Tôi đã thực hiện nghiên cứu tìm kiếm đá quý có thể thực hiện điều này. Cho đến nay tôi đã tìm thấy strongbox và safe. Cùng với nhau, điều này dường như cung cấp một giải pháp cho tôi.

Tuy nhiên, tôi tự hỏi liệu đây có phải là thực tiễn phổ biến hay không. Dường như hầu hết các ứng dụng đường ray đều có một số dữ liệu nhạy cảm để lưu trữ liên quan đến người dùng của họ. đang xử lý mã hóa mật khẩu của tôi, nhưng email và dữ liệu cá nhân khác cũng nhạy cảm. Có thực tế phổ biến để để các mục này không được mã hóa trong cơ sở dữ liệu và giả sử rằng nó sẽ không bao giờ bị xâm phạm? Tôi hiểu rằng cơ sở dữ liệu nằm trong một khu vực không thể giao tiếp với thế giới bên ngoài, nhưng một kẻ tấn công được xác định có thể dễ dàng thỏa hiệp điều này. Có thực tế phổ biến cho các nhà phát triển Rails để lại dữ liệu của họ không được mã hóa và chỉ đơn giản là tin tưởng vào bảo mật của máy chủ web của họ?

Answer 1

Vấn đề với mã hóa cơ sở dữ liệu của bạn là bất kỳ thứ gì bạn mã hóa không thể được sử dụng trong truy vấn SQL, và nó vẫn phải được giải mã trước khi nó có thể được sử dụng. Điều này có nghĩa là bạn cần đặt khóa giải mã gần cơ sở dữ liệu và trong hầu hết các trường hợp, nếu ai đó có thể xâm phạm cơ sở dữ liệu của bạn, điều đó có nghĩa là họ cũng đã xâm phạm khóa giải mã của bạn cùng một lúc. Do đó, bước mã hóa đã mua cho bạn rất ít. Với mật khẩu, không cần giải mã vì nó thực sự là hàm băm. Bạn đang tốt hơn hết để đảm bảo cơ sở dữ liệu không bao giờ bị xâm nhập ngay từ đầu.

Luôn giả định rằng nếu một hacker có thể xâm phạm bất kỳ phần nào của bảo mật của bạn, họ có thể thỏa hiệp tất cả. Chuỗi chỉ mạnh như liên kết yếu nhất của nó và tất cả.

Số thẻ tín dụng và số an sinh xã hội (may mắn là bạn không thường cần phải lập chỉ mục) có thể là ngoại lệ rõ ràng nhất cho điều này, nhưng nếu bạn phải đặt câu hỏi này, bạn không có lưu trữ các mặt hàng ở nơi đầu tiên. Có tất cả các loại rắc rối pháp lý bạn có thể xâm nhập vào để làm rối tung mọi thứ.

Answer 2

Số thẻ tín dụng, SSN, v.v ... phải luôn được mã hóa.

Mật khẩu phải luôn được lưu trữ được mã hóa, sử dụng băm một chiều. Điều này có nghĩa là khi người dùng cung cấp mật khẩu, bạn có thể xác định xem nó có khớp với những gì bạn đã lưu trong DB hay không, nhưng chỉ được biểu diễn bằng mã hóa trong DB, bạn không thể xác định mật khẩu của mình, thiếu các cuộc tấn công từ điển/bạo lực.

Tôi thấy rằng trong ứng dụng của mình, tôi muốn thêm người đọc và người viết không được mã hóa vào lớp học của mình, để xử lý biểu diễn được mã hóa không đau.

class User 
    # has db column encrypted_cc_number 
    def unencrypted_cc_number 
    WhateverEncryptionClassYouUse.decrypt(encrypted_cc_number) 
    end 
    def unencrypted_cc_number=(val) 
    self.encrypted_cc_number = WhateverEncryptionClassYouUse.encrypt(val) 
    end 
end 

Answer 3

Sử dụng cơ chế bảo mật lớp và mật mã mạnh là cách thực hành tốt nếu bạn lưu trữ một lượng lớn dữ liệu nhạy cảm. Nó được yêu cầu bởi Tiêu chuẩn bảo mật dữ liệu của ngành thẻ thanh toán (PCI DSS). Tôi khuyên bạn nên đọc tài liệu hướng dẫn sau: https://www.pcisecuritystandards.org/pdfs/pci_fs_data_storage.pdf.

Bạn chắc chắn không nên "giả định rằng nó sẽ không bao giờ bị xâm phạm"