Một thực tiễn bảo mật tốt để lưu trữ cơ sở dữ liệu quan trọng trên máy tính xách tay của nhà phát triển là gì?

Chúng tôi có một vài givens:

1. Các nhà phát triển cần một bản sao của cơ sở dữ liệu sản xuất trên máy của họ.
2. Các nhà phát triển có mật khẩu để nói cơ sở dữ liệu trong các tệp App.config.
3. Chúng tôi không muốn dữ liệu trong cơ sở dữ liệu bị xâm phạm.

Một vài giải pháp được đề xuất và nhược điểm của chúng:

1. Mã hóa toàn bộ đĩa. Điều này giải quyết tất cả các vấn đề, nhưng làm giảm hiệu suất của máy tính xách tay và chúng tôi là một người khởi nghiệp, vì vậy đừng có tiền cho những con ngựa.
2. Tạo một VM với đĩa cứng được mã hóa và lưu trữ cơ sở dữ liệu trên nó. Nó hoạt động tốt, nhưng nó không giúp được gì nhiều, vì có mật khẩu trong Web.Config.
3. Giải pháp số 2 + yêu cầu nhà phát triển nhập mật khẩu cơ sở dữ liệu mỗi khi anh ta chạy bất cứ thứ gì. Nó giải quyết tất cả các vấn đề, nhưng nó thực sự cồng kềnh đối với các nhà phát triển đôi khi kích hoạt ứng dụng nhiều lần trong một phút. Ngoài ra, chúng tôi có nhiều ứng dụng kết nối với cùng một cơ sở dữ liệu và việc triển khai màn hình mật khẩu sẽ phải khác nhau ở mỗi ứng dụng.

Vì vậy, câu hỏi của tôi là, nếu có bất kỳ giải pháp chung cho vấn đề như vậy, hoặc bất kỳ đề xuất nào về cách làm cho bất kỳ giải pháp trên có thể thực hiện được?

Bạn không chỉ không muốn một bản sao của cơ sở dữ liệu sản xuất, nó thực sự có thể là bất hợp pháp. Ví dụ: ở Mỹ, bạn không thể di chuyển dữ liệu sản xuất ra khỏi môi trường sản xuất nếu nó chứa thông tin được quy định như dữ liệu sức khỏe cá nhân, dữ liệu tài chính hoặc thậm chí dữ liệu có thể được sử dụng trong hành vi trộm cắp danh tính. Nếu bạn làm như vậy, bạn có thể bị phạt, mất đi sự tuân thủ và do đó phải chịu các cuộc kiểm toán mạnh mẽ hơn, hoặc thậm chí được nêu tên trong một vụ kiện.

Nếu bạn cần dữ liệu ở quy mô sản xuất để thử nghiệm, bạn có một vài lựa chọn:

1. Tạo tất cả dữ liệu giả. Điều này là khó khăn hơn âm thanh. Thật khó khăn và tốn nhiều công sức để tạo ra dữ liệu tưởng tượng hợp lý.
2. Ẩn danh dữ liệu sản xuất của bạn. Điều này có thể dễ dàng hơn, nhưng tiến hành thận trọng.

Đối với tùy chọn # 2

• Trong môi trường sản xuất, quản trị viên cơ sở dữ liệu được ủy quyền tạo một bản sao của dữ liệu sản xuất.
• Vẫn trong môi trường sản xuất, cùng một quản trị viên được ủy quyền chạy một thói quen ẩn danh tất cả dữ liệu nhạy cảm. Nếu nghi ngờ, hãy ẩn danh.
• Chỉ sau đó dữ liệu mới được chuyển sang môi trường khác.

Ít nhất bạn có thể cung cấp cho các nhà phát triển VM trong trung tâm dữ liệu của bạn để họ có thể RD cho công việc này không? Mặc dù họ thực sự nên xử lý dữ liệu phi sản xuất, nhưng điều này sẽ an toàn hơn cho đến khi bạn có thể đến đó vì dữ liệu sẽ không được lưu trữ trên máy tính xách tay dễ bị đánh cắp.

Thay đổi cách làm việc của bạn nếu có thể.

Như những người khác đã chỉ ra:

• Sử dụng dữ liệu sản xuất để phát triển không phải là thông lệ tốt.
• Có một mật khẩu được lưu trữ trong văn bản đơn giản là không tốt.

Cả hai điều này làm bạn gặp rủi ro đáng kể và nên được thay đổi nếu có thể. Ít nhất bạn nên nghiêm túc đánh giá chi phí thực hiện những thay đổi này sẽ là bao nhiêu. Nếu đây là một sự phụ thuộc bên ngoài mà bạn không có quyền thay đổi, hãy xem xét việc nâng cao điều này như một mối quan tâm đối với bất cứ ai có sức mạnh đó.

Tuy nhiên, trong thế giới thực, có thể thực sự không thể thay đổi điều này. Giả sử rằng những gì bạn đang làm là hợp pháp, bạn có thể phải sống với sự sắp xếp này (ít nhất là tạm thời).

Nếu điều này thực sự cần thiết, bạn chỉ cần thực hiện mã hóa toàn bộ đĩa.

Với các rủi ro, bạn cần sử dụng tùy chọn bảo mật khả dụng tốt nhất và đây là tùy chọn. Nếu có một màn trình diễn thành công, hãy sống với nó. Đó là một chi phí làm việc với dữ liệu nhạy cảm.

Nếu tôi là khách hàng của bạn, tôi sẽ không ấn tượng rằng bạn quyết định không sử dụng tùy chọn bảo mật tốt nhất có sẵn với dữ liệu của tôi, vì nó làm cho máy tính xách tay của bạn chậm hơn một chút.

Câu trả lời của Corbin March khá hay, tôi sẽ chỉ thêm một chi tiết, rằng bạn thường có hai loại dữ liệu trong cơ sở dữ liệu sản xuất của mình: siêu dữ liệu hệ thống / ứng dụng; và dữ liệu người dùng của khách hàng / dữ liệu giao dịch. Cái sau này KHÔNG BAO GIỜ được sử dụng trong môi trường phát triển "như hiện tại."

Thực sự rất hiếm khi bạn cần thông tin khách hàng sản xuất thực tế để phát triển.

Tuy nhiên, nếu vấn đề mà OP mô tả ở đây liên quan đến dữ liệu bí mật thương mại hoặc dữ liệu hệ thống độc quyền cao không liên quan đến dữ liệu khách hàng, thì đó là yêu cầu của các nhà phát triển ... phương pháp bảo mật phải liên quan đến một kế hoạch không có mật khẩu db được giữ trong Cleartext trong một tệp tài nguyên ở đâu đó. Cần phải có một cơ chế, ví dụ, để tạo lại mật khẩu hàng ngày, không được lưu trữ trên đĩa.

Bạn không nói cơ sở dữ liệu nào và môi trường nào.

Nếu bạn có thể sử dụng bảo mật tích hợp thì cơ sở dữ liệu không thể truy cập mà không đăng nhập như người dùng đó. Có nếu dữ liệu nằm trên đĩa cứng, nó có thể bị hack nhưng đây là phòng thủ cấp đầu tiên.

App.config làm cho tôi nghĩ rằng đây có thể là một .NET. Đặt cấu hình trong một ổ đĩa ngón tay cái và đọc nó từ ổ đĩa ngón tay cái. Nếu ổ đĩa không có thì làm cho người dùng nhập mật khẩu.

Có cách nào để lưu mật khẩu vào bộ nhớ lần đầu tiên được nhập và đọc không. Một lần nữa bạn không nói rõ môi trường. Tập tin đã ánh xạ bộ nhớ

Với một số TDE, bạn có thể lưu trữ khóa trên một thiết bị riêng biệt để họ chỉ cung cấp khóa khi máy chủ cơ sở dữ liệu được khởi động.

Một tùy chọn có thể là tạo một bản sao của cơ sở dữ liệu và xóa bản sao đó bằng một tập lệnh để bạn kết thúc với dữ liệu khác với những gì thực sự được sản xuất. Bạn sẽ không kết thúc với cùng một dữ liệu như sản xuất Nhưng bạn sẽ có cùng quy mô.