Có bất kỳ rủi ro bảo mật nào khi có nhiều khóa ngoại tham chiếu một bảng không?

Tôi có một giáo viên nói với tôi rằng có một cơ sở dữ liệu với một bảng được tham chiếu bởi khoảng 60% các bảng khác là không bảo mật. Vấn đề là anh ta đã không giải thích được tại sao đó là một rủi ro bảo mật.

Rủi ro - thuộc loại nào - tôi tin, là nếu bạn bỏ qua quyền TÀI LIỆU THAM KHẢO đối với một đối tượng khi từ chối tài khoản truy cập trực tiếp vào đối tượng, TÀI LIỆU THAM KHẢO có thể được sử dụng để đọc dữ liệu mà ai đó được cho là có thể đọc - từ cột khóa được tham chiếu, ít nhất. Và cột chính có thể là số tài khoản ngân hàng hoặc SSN. Ít nhất, bạn có thể khai thác nó để tìm xem giá trị dữ liệu ABCDEF có hoặc không có trong bảng. Tài liệu của Oracle nói rằng "cấp đặc quyền một cách bảo thủ", có nghĩa là không cấp cho họ chút nào, lý tưởng nhất là từ chối chúng một cách rõ ràng. Đặc biệt là để họ tránh xa tài khoản 'công khai' hoặc 'khách' mà không nhất thiết phải có sự cho phép trên cơ sở dữ liệu của bạn.

Trên máy chủ tiêu chuẩn cao (tôi sử dụng Microsoft SQL Server), điều này có thể được giảm nhẹ trong đó Bảng A được tham chiếu bởi Bảng B, và cả Bảng C đến Z, - nhưng chính các bảng khác có quyền tra cứu khóa ngoại trong Bảng A, đó không phải là quyền của người dùng. Trừ khi người dùng có thể cập nhật dữ liệu trong Bảng M, cho phép họ một lần nữa thăm dò các giá trị của dữ liệu được giữ trong Bảng A.

Đối với các rủi ro khác ngoài bảo mật ... Các khóa được đặt ở đó để được tham chiếu. Một máy chủ tốt không nên bị hỏng nếu tất cả các bảng được tham chiếu bởi tất cả các bảng khác, mặc dù trong "I Wrote My own SQL Server All In Javascript" (mà tôi hy vọng là tưởng tượng) có thể có lỗi. Chắc chắn nếu một cột chính đang được tham chiếu nhiều bởi các mối quan hệ và truy vấn, thì đặc điểm kỹ thuật và lập chỉ mục của nó phải được xem xét cẩn thận. Chẳng hạn, Microsoft SQL cho phép một chỉ mục trên các cột A và B hoạt động như một bản sao riêng của dữ liệu bảng và cũng có các cột C, D và E được bao gồm trong bảng doppelganger (từ khóa INCLUDE). Và trong khi đó, một chỉ mục khác cũng nằm trên các phím A và B với các cột F và G cũng được bao gồm. Nếu đó là hai truy vấn mà bạn thực hiện thường xuyên nhất, thì đó là một thiết kế cần xem xét.

Ngoài ra, từ kinh nghiệm, nếu khóa dữ liệu được tham chiếu nhiều của bạn cần được thay đổi, trong tất cả các bảng, trong khi vẫn giữ phần còn lại của dữ liệu giống nhau, điều đó rất bất tiện. Chẳng hạn, nếu đó là số điện thoại của khách hàng (giả sử đây là cơ sở dữ liệu của công ty điện thoại), thì bạn phải thay đổi số của khách hàng sau các cuộc gọi phiền toái. Chà, đây là một lý do để không sử dụng loại số đó làm khóa trong cơ sở dữ liệu - mặc dù việc tìm kiếm dữ liệu trong truy vấn trên bảng PDQOK rất thuận tiện. Hoặc, tệ hơn, khách hàng đó bỏ việc - sau đó, bạn cấp số của họ cho người khác ...

Điều này kéo dài giới hạn của sự tín nhiệm. Điều duy nhất tôi có thể nghĩ là bằng cách cố tình gây ra lỗi toàn vẹn tham chiếu, kẻ tấn công có thể thu thập các thông báo lỗi và lấy thông tin từ lược đồ bên dưới.

Tuy nhiên, nếu kẻ tấn công có thể làm điều đó bạn có những lo lắng lớn hơn.

Cho rằng bạn không cung cấp nhiều ngữ cảnh hơn những gì đã có, giáo viên của bạn đã sai.

Các lược đồ như vậy được gọi là lược đồ sao hoặc lược đồ bông tuyết trong cơ sở dữ liệu OLAP và là thực tiễn tốt nhất và tiêu chuẩn lựa chọn ở đó. Bạn sẽ cần một cái gì đó giống như Sales numbertrong bảng trung tâm và bạn sẽ có khách hàng và những thứ khác trong các bảng khác.

Nó phụ thuộc vào định nghĩa của giáo viên về rủi ro bảo mật.

Quản lý rủi ro CNTT theo một bài viết trên Wikipedia có định nghĩa sau:

Theo Risk IT, [1] nó không chỉ bao gồm tác động tiêu cực của hoạt động và cung cấp dịch vụ có thể mang lại sự phá hủy hoặc giảm giá trị của tổ chức, mà còn mang lại lợi ích \ value cho phép rủi ro liên quan đến việc bỏ lỡ cơ hội sử dụng công nghệ cho phép hoặc tăng cường kinh doanh hoặc quản lý dự án CNTT cho các khía cạnh như bội chi hoặc giao hàng trễ với tác động kinh doanh bất lợi.

Theo dõi bài viết bạn tìm thấy công thức sau:

Rủi ro = Đe dọa * Dễ bị tổn thương * Tài sản

Bây giờ bạn có thể tiếp tục và xác định dữ liệu bảng của mình là tài sản và rủi ro chung là rủi ro bảo mật, vì tài sản của bạn chứa dữ liệu nhạy cảm, khiến bạn phải chịu:

Rủi ro bảo mật = Mối đe dọa * Tính dễ bị tổn thương * Table_Data

Vì vậy, trong một ý nghĩa thực sự xa vời, Mối đe dọa kết hợp với Tính dễ bị tổn thương có thể dẫn đến vi phạm dữ liệu trong Table_Data của bạn . Và kết quả là bạn có một rủi ro bảo mật .

Bây giờ có tất cả các dữ liệu liên quan được tham chiếu trong bảng trung tâm của bạn có thể gây ra rủi ro bảo mật cao hơn từ quan điểm của giáo viên của bạn, nhưng điều đó rất xa vời.

Về cơ bản bất cứ điều gì có thể được định nghĩa là một rủi ro bảo mật. Nó phụ thuộc vào lập luận của bạn.