Bao nhiêu rủi ro bảo mật được công bố lược đồ khái niệm?

Tôi đã yêu cầu các lược đồ khái niệm từ hệ thống thông tin của cơ quan chính phủ cho nghiên cứu của tôi. Yêu cầu của tôi đã bị từ chối với lý do nó là một rủi ro bảo mật.

Tôi thực sự không có kinh nghiệm cơ sở dữ liệu rộng lớn vì vậy tôi không thể xác minh khiếu nại đó. Là tiết lộ lược đồ của bạn thực sự lớn của một rủi ro bảo mật? Ý tôi là, những thứ đó khá trừu tượng và tách biệt khỏi việc triển khai phần cứng và phần mềm. Một lời giải thích về cách một kẻ tấn công có thể khai thác các lược đồ khái niệm sẽ được đánh giá cao. Cảm ơn.

Đồng ý với gbn (nên +1), nhưng tôi nghĩ có hai khả năng khác khi chơi:

1. Hoàn toàn có khả năng là lược đồ khái niệm của họ có nhiều sự trùng lặp với lược đồ vật lý của họ. Biết tên bảng cung cấp cho bạn một khởi đầu tốt trong việc lập kế hoạch tấn công SQL SQL của bạn.

2. Rất có khả năng họ không có tài liệu về lược đồ khái niệm của họ. Các tổ chức cho phép lập trình viên thiết kế cơ sở dữ liệu của riêng họ thường không có bất kỳ sự nghiêm ngặt nào trong quy trình thiết kế cơ sở dữ liệu của họ, đi thẳng vào thực hiện vật lý mà không có bất kỳ thiết kế ban đầu nào. Họ có thể không muốn thừa nhận điều này, hoặc họ có thể không muốn đi vào thời điểm và rắc rối của việc tạo lại một tài liệu khái niệm chưa từng tồn tại.

Chỉnh sửa: OP đã nhận xét rằng tổ chức được yêu cầu cho lược đồ khái niệm của họ là một cơ quan quản trị. Điều này trong tâm trí tôi thêm một khả năng khác:

Các công chức không được biết đến vì họ thích mạo hiểm và vì vậy một chức năng cấp trung trong một cơ quan chính phủ khó có thể ló đầu ra và tiết lộ thông tin chỉ trong trường hợp nó có thể thu hút sự chú ý hoặc của một người nào đó lên cấp bậc .

Tôi vẫn nghĩ rằng # 2 là có khả năng nhất.

Tôi muốn đề xuất đó là rủi ro Sở hữu trí tuệ nhưng họ không muốn nói

Tôi hoàn toàn đồng ý rằng lược đồ khái niệm đằng sau thông tin bí mật cũng phải được giữ bí mật.

Nếu các điệp viên thu thập các mẩu thông tin nhỏ bằng cách nào đó lọt qua các vết nứt, vẫn còn vấn đề đặt các mẩu tin đó vào bối cảnh. Các lược đồ khái niệm cung cấp bối cảnh. Biểu mẫu và nội dung của các mẩu tin được thu thập có thể khác biệt đáng kể với biểu mẫu và nội dung của dữ liệu trong cơ sở dữ liệu, nhưng lược đồ ẩn cung cấp một hướng dẫn tuyệt vời để giải mã nội dung.

Khi làm việc về phục hồi dữ liệu cho các công ty, tôi luôn coi một lược đồ khái niệm đáng tin cậy là một mỏ vàng. Để chắc chắn, những dự án này không liên quan đến gián điệp. Nhưng có thể dễ dàng thấy cách phân tích tương tự mang lại.

Rất nhiều nhà cung cấp cố gắng giữ các lược đồ cơ sở dữ liệu của họ gần với ngực của họ. Như thường lệ, đó là về việc giữ một nắp trong những bí mật nhỏ bẩn thỉu của họ như loại bỏ sự thiếu toàn vẹn dữ liệu hoặc thiết kế cơ sở dữ liệu kém. Các lý do khác bao gồm:

• Nhiều sản phẩm phần mềm có sơ đồ cơ sở dữ liệu được thiết kế kém.

• Một mong muốn không phát sinh khối lượng công việc hỗ trợ.

• Nỗ lực buộc khách hàng mua dịch vụ tư vấn cho công việc tích hợp hệ thống.

• Mong muốn tối đa hóa chi phí xuất cảnh để ngăn cản khách hàng chuyển sang các sản phẩm của đối thủ cạnh tranh.

Thật không may, bạn không làm việc cho khách hàng, nhưng nếu bạn là bạn, bạn có thể sử dụng một đối số dọc theo các câu hỏi về lỗi kiến ​​trúc của phần mềm để lộ sơ đồ cơ sở dữ liệu có thể là một rủi ro bảo mật.