Không có cơ sở dữ liệu trung tâm

Tôi có một khách hàng đang tìm cách xây dựng một trang web / ứng dụng di động / ứng dụng máy tính để bàn xử lý dữ liệu rất nhạy cảm (nhạy cảm hơn chi tiết ngân hàng / thẻ). Do tính chất nhạy cảm của dữ liệu, họ không muốn lưu dữ liệu vào cơ sở dữ liệu trung tâm nhưng họ vẫn muốn ứng dụng của họ được đồng bộ hóa (giả sử tôi thêm một số dữ liệu vào ứng dụng di động của mình, sau đó tôi muốn có thể truy cập vào ứng dụng máy tính để bàn và xem dữ liệu tương tự).

Tôi không thể nghĩ ra một cách tốt đẹp, đáng tin cậy để làm điều này và tôi không chắc chắn có một cách. Đó là lý do tại sao tôi ở đây. Có ai biết làm thế nào tôi có thể đối phó với dữ liệu này?

Một giải pháp tôi đã nghĩ đến là có một cơ sở dữ liệu phía máy khách trên mỗi ứng dụng bằng cách nào đó sẽ đồng bộ hóa giữa các ứng dụng, tôi có thể thấy điều này rất không đáng tin cậy và mặc dù rất lộn xộn.

Rất nhiều thông tin nhạy cảm được lưu trữ trong cơ sở dữ liệu. Trong thực tế, một cơ sở dữ liệu trung tâm có lẽ là cách an toàn nhất để lưu trữ dữ liệu này. Cơ sở dữ liệu doanh nghiệp lớn có rất nhiều chức năng để thực hiện những việc như mã hóa thông tin nhạy cảm, để kiểm tra ai truy cập nó, để hạn chế hoặc ngăn mọi người bao gồm các DBA xem dữ liệu, v.v. rằng bạn không bị mất dữ liệu. Gần như chắc chắn việc thỏa hiệp dữ liệu được lưu trữ trên một số thiết bị di động hoặc máy tính xách tay ngẫu nhiên sẽ dễ dàng hơn nhiều so với việc xâm nhập một cơ sở hạ tầng bảo mật được thiết kế tốt và thỏa hiệp một cơ sở dữ liệu trung tâm thích hợp.

Bạn có thể thiết kế hệ thống với cơ sở dữ liệu trung tâm chỉ lưu trữ dữ liệu được mã hóa và lưu trữ khóa riêng của người dùng trên thiết bị của người dùng. Theo cách đó, ngay cả khi cơ sở dữ liệu trung tâm bị xâm phạm hoàn toàn, dữ liệu chỉ có thể được sử dụng bởi người dùng. Tất nhiên, điều đó có nghĩa là bạn không thể khôi phục dữ liệu của người dùng nếu họ bị mất chìa khóa (giả sử bản sao duy nhất có trên điện thoại của họ và điện thoại của họ bị hỏng). Và nếu ai đó xâm phạm khóa và, có lẽ, thông tin đăng nhập của họ, họ sẽ có thể xem dữ liệu.

Bạn cần sao lưu một vài bước và, tham khảo ý kiến ​​khách hàng của bạn, đưa ra mô hình mối đe dọa . (Vâng, đó là một liên kết đến một cuốn sách 600 trang; vâng, tôi thực sự khuyên bạn nên đọc toàn bộ.)

Một mô hình mối đe dọa bắt đầu bằng cách đặt câu hỏi như

• Tại sao ứng dụng cần lưu trữ dữ liệu nhạy cảm này ngay từ đầu?
  • Bạn có thể tránh lưu trữ nó ở tất cả?
  • Nó có thể được ném đi sau một thời gian ngắn?
  • Có thực sự cần phải truy cập vào nhiều thiết bị không?
  • Nếu nó phải được truy cập trên nhiều thiết bị, nó có cần được lưu trữ trên nhiều thiết bị không?
• Ai là người được phép xem dữ liệu nhạy cảm của mỗi người dùng?
  • Danh sách này có thể được thực hiện ngắn hơn?
• Ai là những người có thể tiếp xúc với dữ liệu nhạy cảm của mỗi người dùng trong khi cố gắng thực hiện công việc của họ, nhưng không cần biết điều đó?
  • Thể này danh sách được thực hiện ngắn hơn?
  • Dữ liệu có thể được hiển thị không thể truy cập được cho họ mà không làm tổn hại khả năng thực hiện công việc của họ không?
  • Nếu nó không thể truy cập được, ít nhất nó có thể được làm cho không thể hiểu được? (Đây là những gì mã hóa làm, trong bản tóm tắt: nó làm cho dữ liệu không thể hiểu được.)
• Ai là người muốn xem dữ liệu nhạy cảm, nhưng không được phép?
  • Những cơ hội nào họ có được tại dữ liệu?
  • Họ muốn làm gì với dữ liệu khi họ có nó?
  • Họ sẽ tức giận như thế nào nếu họ không có được thứ họ muốn?
  • Họ sẵn sàng chi bao nhiêu tiền, thời gian, chu kỳ CPU và công sức của con người?
  • Họ có quan tâm nếu có ai biết họ đã xem dữ liệu không?
  • Họ có muốn truy cập dữ liệu nhạy cảm của người dùng cụ thể không , hay ai sẽ làm gì?
  • Họ đã biết gì?
  • Họ đã có quyền truy cập vào cái gì?

Một khi bạn biết câu trả lời cho những câu hỏi này, bạn sẽ ở một nơi tốt hơn nhiều để tìm ra những việc cần làm.

Hãy nhớ rằng có thể có nhiều hơn một câu trả lời cho mỗi bộ câu hỏi, đặc biệt là những câu hỏi liên quan đến những kẻ tấn công (những người muốn có dữ liệu nhạy cảm nhưng không được phép có nó). Nếu bạn không thể nghĩ ra ít nhất nửa tá những kẻ tấn công kiểu mẫu khác nhau , với những động lực, mục tiêu và tài nguyên khác nhau, có lẽ bạn đã bỏ lỡ điều gì đó.

Ngoài ra, hãy nhớ rằng những kẻ tấn công khiến bạn (và / hoặc khách hàng) gặp rắc rối nhất, có khả năng gây ra một vụ nổ lớn trên phương tiện truyền thông nếu cuộc tấn công của chúng thành công, hoặc gây ra thiệt hại tổng hợp lớn nhất , có lẽ là không phải những kẻ tấn công có thể gây ra tác hại lớn nhất cho người dùng cá nhân nếu cuộc tấn công của họ thành công. Công ty của khách hàng của bạn quan tâm một cách hợp lý hơn về thiệt hại tổng hợp, nhưng người dùng quan tâm hợp lý hơn về tác hại đối với chính họ.

Một tùy chọn để thực hiện đồng bộ hóa là thực hiện ngang hàng. Điều này vẫn sẽ yêu cầu một máy chủ trung tâm, nhưng máy chủ đó sẽ không xử lý bất kỳ dữ liệu nào.

Khi một thiết bị lên mạng, một máy chủ trung tâm sẽ nhận được thông báo với id người dùng. Khi một thiết bị thứ hai của cùng một người dùng trực tuyến, máy chủ sẽ gửi cho cả hai thiết bị địa chỉ IP của thiết bị kia. Các thiết bị sau đó có thể trao đổi dữ liệu trực tiếp. Hãy cẩn thận: một thiết bị cần hoạt động như một máy chủ, vì vậy ít nhất một thiết bị không thể đứng sau bộ định tuyến NAT.

Đừng quên rằng bạn sẽ cần xác thực và mã hóa mạnh mẽ cho cả cơ chế thông báo và trao đổi ngang hàng.

Làm cho nó trở thành vấn đề của người khác.

Lưu trữ dữ liệu cục bộ trong mỗi ứng dụng, sau đó cung cấp cho người dùng tùy chọn bật đồng bộ hóa bằng tài khoản của riêng họ với dịch vụ của bên thứ ba (Dropbox, Google Drive, v.v.). Ngoài ra, hãy suy nghĩ về việc mã hóa bất kỳ dữ liệu nào được tải lên dịch vụ của bên thứ ba (có những ưu và nhược điểm để thực hiện điều đó).

Điều này mang lại vẻ ngoài mà người dùng sở hữu dữ liệu của riêng họ, vì họ phải chọn tham gia đồng bộ hóa dữ liệu. Nó làm cho các ứng dụng hữu ích cho những người không muốn bất kỳ chia sẻ nào xảy ra. Và nó khiến người khác phải chịu trách nhiệm (về mặt kỹ thuật và, có khả năng, về mặt pháp lý) đối với những vấn đề đau đầu đang diễn ra là giữ bất kỳ dữ liệu chia sẻ nào an toàn.

Mối quan tâm của khách hàng của bạn dường như là về khả năng hiển thị của dữ liệu này. Câu hỏi đầu tiên để hỏi khách hàng của bạn là nếu dữ liệu được mã hóa, nó có thể được lưu trữ ở đâu? Sau đó, hãy hỏi khách hàng của bạn loại kiểm soát truy cập nào họ muốn tại chỗ trước khi dữ liệu có thể được giải mã và xử lý - khóa giải mã có thể được lưu trữ ở đâu? là một khóa riêng biệt cho mỗi người dùng? v.v ...

Nếu khách hàng của bạn không muốn dữ liệu được lưu trữ ở bất cứ đâu, họ có muốn người dùng nhập dữ liệu của tôi mỗi lần không?