Đây là phần thứ ba trong loạt bài gồm nhiều phần của chúng tôi về việc áp dụng các phương pháp tiếp cận bảo mật thông tin vào mô hình hóa dữ liệu. Loạt bài này sử dụng một mô hình dữ liệu đơn giản, một thứ để quản lý các câu lạc bộ xã hội và các nhóm sở thích, nhằm cung cấp nội dung mà chúng tôi muốn bảo mật. Sau đó, chúng tôi sẽ đề cập đến việc lập mô hình để ủy quyền và quản lý người dùng, cũng như các phần khác của việc triển khai cơ sở dữ liệu an toàn.
Trong các tình huống xã hội, thông thường "đọc giữa dòng" - suy ra các giả định và khẳng định không thành lời trong một cuộc trò chuyện. Điều tương tự cũng xảy ra trong việc tạo phần mềm và lưu trữ dữ liệu trong cơ sở dữ liệu. Hóa đơn được liệt kê với ID khách hàng được nhúng và có bao nhiêu thực thể dữ liệu sử dụng ngày-giờ như một phần của khóa? Thật khó để tưởng tượng việc ghi lại toàn bộ hoặc cấu trúc mọi thứ mà không có một số loại bỏ sót. Nhưng trong phần cuối cùng của chúng tôi, chúng tôi đã trải qua chính xác bài tập đó. Chúng tôi có thể xác định mức độ nhạy cảm đối với một số phần trong cơ sở dữ liệu câu lạc bộ xã hội của chúng tôi. Nhưng để định lượng và quản lý độ nhạy đó, chúng ta phải tăng cường cấu trúc mô hình dữ liệu của mình để làm cho dữ liệu nhạy cảm và các mối quan hệ của nó trở nên rõ ràng.
Đóng các khoảng trống của mô hình dữ liệu
Mô hình hóa dữ liệu cho bảo mật đòi hỏi một số thay đổi cấu trúc khác nhau. Chúng tôi đang lần lượt khám phá những điều này, sử dụng mô hình dữ liệu câu lạc bộ xã hội đơn giản (rất!) Làm cơ sở của chúng tôi cho loạt bài này. Khi chúng tôi tiếp tục, chúng tôi đã cải tiến mô hình với nhiều dữ liệu hơn. Trong phần trước, chúng tôi đã phân tích mô hình để xác định độ nhạy của dữ liệu ở nơi chúng tôi tìm thấy nó. Phân tích này cũng tiết lộ rằng có những nơi mà mô hình dữ liệu chỉ ra các liên kết không thực sự được nắm bắt rõ ràng trong các cột và các mối quan hệ chính. Người lập mô hình nên mong đợi điều này trong một phân tích bảo mật. Từ những khám phá này, chúng tôi sẽ làm cho các mối quan hệ này trở nên cụ thể và rõ ràng nhất có thể bằng cách xây dựng các bảng và mối liên hệ giữa chúng. Điều này sẽ cho phép chúng tôi đính kèm thêm các thuộc tính bảo mật.
Xây dựng mối quan hệ dữ liệu trong câu lạc bộ
Tất cả các mối quan hệ trong dữ liệu, cũng như bản thân các thực thể dữ liệu, phải có một số biểu diễn để thể hiện giá trị hoặc độ nhạy đối với chúng. Có thể cần các cột mới, khóa mới, tham chiếu mới, thậm chí cả bảng mới để thực hiện điều này. Khi chúng tôi phân tích các bảng và mối quan hệ của chúng trong bài đăng trước, chúng tôi đã tách riêng hai bảng chính với dữ liệu có độ nhạy cao:
-
Person -
Photo
Ngoài ra, chúng tôi có bốn dữ liệu chứa dữ liệu có độ nhạy vừa phải:
-
Member -
Club -
Office -
Club_Office
Các khía cạnh của độ nhạy này một phần là bản chất của mỗi bảng, nhưng các mối quan hệ không rõ ràng mang rất nhiều độ nhạy. Để đính kèm nó, chúng tôi bắt đầu ghi lại các mối quan hệ và tạo cho chúng một cấu trúc để chứa độ nhạy.
Các mối quan hệ được nhúng trong ảnh
Photo chứa rất nhiều mối quan hệ nhúng mà chúng ta cần nắm bắt. Chủ yếu, chúng tôi quan tâm đến mối quan hệ với Person . Để nắm bắt mối quan hệ Người-Ảnh, tôi đang thêm Photo_Content bảng:
Có rất nhiều khía cạnh khác nhau mà Person có thể liên quan đến Photo . Tôi quyết định thêm một bảng mới, Photo_Content_Role , để mô tả mối quan hệ của Ảnh với Người. Thay vì có các bảng riêng biệt cho từng loại mối quan hệ, chúng tôi sử dụng một bảng kết nối duy nhất và bảng Photo_Content_Role. Bảng này là danh sách tham chiếu với các mối quan hệ chuẩn như những gì chúng tôi đã lưu ý. Đây là tập dữ liệu ban đầu của chúng tôi cho Photo_Content_Role :
| Nhãn | Tối đa cho mỗi người | Mô tả |
|---|---|---|
| Nhiếp ảnh gia | 1 | Người thực sự chụp ảnh |
| Người được miêu tả | 1 | Một người có thể nhận ra trong ảnh |
| Chủ sở hữu bản quyền | 1 | Một người giữ bản quyền cho bức ảnh |
| Người cấp phép | 1 | Một bên đã cấp phép cho câu lạc bộ sử dụng ảnh này |
| Nhà môi giới bản quyền | 1 | Một bên đã giải quyết các vấn đề bản quyền cho ảnh này |
| Đối tượng được mô tả | không giới hạn | content_headline xác định đối tượng, content_detailed xây dựng nó |
| Nhận xét | không giới hạn |
OK, vì vậy đây là một mồi và chuyển đổi. Tôi đã nói Photo_Content sẽ liên quan đến mọi người đối với ảnh, vậy tại sao lại có điều gì đó về "đối tượng được mô tả"? Về mặt logic, sẽ có những bức ảnh mà chúng tôi sẽ mô tả nội dung mà không xác định Người . Tôi có nên thêm một bảng khác cho cái này không, với một tập hợp các vai trò nội dung riêng biệt? Tôi quyết định không. Thay vào đó, tôi sẽ thêm hàng người rỗng vào Person bảng dưới dạng dữ liệu gốc và có nội dung không liên quan đến người đó. (Vâng, các lập trình viên, nó còn nhiều việc hơn một chút. Xin chào.) ‘Null Person’ sẽ có id không (0).
Bài học chính số 1:
Thu nhỏ bảng có dữ liệu nhạy cảm bằng cách chồng các cấu trúc mối quan hệ tương tự vào một bảng.
Tôi dự đoán có thể có những mối quan hệ bổ sung sẽ được phát hiện ở hạ lưu. Và cũng có thể một câu lạc bộ xã hội có thể có các vai trò riêng để đăng ký một Người trong Ảnh . Vì lý do đó, tôi đã sử dụng khóa chính thay thế ‘thuần túy’ cho Photo_Content_Role và cũng đã thêm một khóa ngoại tùy chọn vào Club . Điều này sẽ cho phép chúng tôi hỗ trợ các mục đích sử dụng đặc biệt của các câu lạc bộ cá nhân. Tôi gọi sân là 'độc quyền' để chỉ ra rằng nó không được cung cấp cho các câu lạc bộ khác.
Bài học chính số 2:
Khi người dùng cuối có thể mở rộng danh sách cài sẵn, hãy cung cấp cho bảng của danh sách đó một khóa đại diện thuần túy để tránh xung đột dữ liệu.
Photo_Content_Role.max_per_person cũng có thể là bí ẩn. Bạn không thể thấy nó trong sơ đồ, nhưng Photo_Content_Role.id mang hạn chế duy nhất của riêng nó không có max_per_person . Về bản chất, khóa chính thực sự chỉ là id . Bằng cách thêm max_per_person thành id trong khóa chính, tôi buộc mỗi bảng tham chiếu phải thu nhận thông tin mà nó có thể (nên!) thực thi ràng buộc kiểm tra bản số. Đây là ràng buộc kiểm tra trong Photo_Content .
Bài học chính số 3:
Khi mỗi hàng của bảng có các giới hạn riêng, các bảng tham chiếu phải thêm một ràng buộc duy nhất mới, mở rộng một khóa tự nhiên với các trường ràng buộc. Yêu cầu bảng con tham chiếu đến khóa đó.
Hãy xem thêm một số tại Photo_Content . Đây chủ yếu là mối quan hệ giữa Photo và Person , với mối quan hệ được chỉ định bởi vai trò nội dung đính kèm. Tuy nhiên, như tôi đã lưu ý trước đây, đây là nơi chúng tôi lưu trữ tất cả thông tin mô tả về bức ảnh. Để phù hợp với kiểu kết thúc mở này, chúng tôi có content_headline tùy chọn và content_detailed cột. Những thứ này hiếm khi cần thiết cho một liên kết thông thường giữa Người và Ảnh. Nhưng một tiêu đề như ‘Bob Januskis Nhận được Giải thưởng Thành tựu Hàng năm’ thì rất dễ dự đoán. Ngoài ra nếu không có Người - ‘Đối tượng được mô tả’, Người 0 - chúng tôi phải yêu cầu một cái gì đó trong content_headline , chẳng hạn như ‘Dốc Tây Bắc của Núi Ararat.’
Mối quan hệ ảnh còn thiếu cuối cùng:Album
Cho đến nay, chúng tôi chưa thêm bất kỳ thứ gì liên quan đến Photo s tới Photo S. Đó là một điều quan trọng đối với các mạng xã hội và dịch vụ ảnh:Album S. Và bạn sẽ không muốn chúng trong hộp đựng giày tục ngữ, phải không? Vì vậy, chúng ta hãy lấp đầy khoảng trống rõ ràng này - nhưng chúng ta cũng hãy nghĩ về nó.
Album đính kèm Photo theo một cách khác với các mối quan hệ khác mà chúng tôi đã đề cập. Photo s có thể được liên kết bởi cùng một câu lạc bộ, một ngày tương tự, tọa độ GPS gần đó, cùng một nhiếp ảnh gia, v.v. Tuy nhiên, Album chỉ rõ rằng Photo s là một phần của một chủ đề hoặc một câu chuyện. Như vậy, các khía cạnh liên quan đến bảo mật của một Photo có thể được suy ra từ một cái khác trong Album . Ngoài ra, thứ tự có thể khuếch đại hoặc giảm bớt những suy luận đó. Vì vậy, đừng chỉ nghĩ đến Album như một bộ sưu tập vô thưởng vô phạt. Liên quan đến Photo s là bất cứ điều gì ngoại trừ.
Mặc dù không phải là vô hại từ quan điểm bảo mật, Album là một thực thể đơn giản có Id thuần túy khóa đại diện thuộc sở hữu của Club (không phải là Person ). Album_Photo cung cấp cho chúng tôi một bộ Photo s được sắp xếp theo Photo_Order . Bạn sẽ nhận thấy rằng tôi đã tạo Album id và order khóa chính. Mối quan hệ thực sự là giữa Photo và Album , vậy tại sao không đặt chúng làm khóa chính? Vì các trường hợp kỳ lạ yêu cầu Photo để lặp lại trong Album chắc chắn có thể. Vì vậy, tôi đặt Photo_Order vào khóa chính và sau một hồi suy nghĩ, quyết định thêm một khóa duy nhất thay thế với album và ảnh để ngăn Photo khỏi lặp lại trong Album . Nếu đủ kêu để lặp lại một Photo trong một Album phát sinh, một khóa duy nhất dễ xóa hơn khóa chính.
Bài học chính số 4:
Đối với khóa chính, hãy chọn khóa ứng viên ít có nguy cơ bị loại bỏ nhất sau này.
Siêu dữ liệu ảnh
Thông tin nhạy cảm cuối cùng cần thêm là siêu dữ liệu (thường được tạo bởi bất kỳ thiết bị nào đã chụp ảnh). Dữ liệu này không phải một phần của mối quan hệ, nhưng nó là nội tại của bức ảnh. Định nghĩa cơ bản của thông tin mà máy ảnh lưu trữ có ảnh là EXIF, một tiêu chuẩn công nghiệp của Nhật Bản (JEITA). EXIF có thể mở rộng và có thể hỗ trợ hàng chục hoặc hàng trăm trường, không trường nào có thể được yêu cầu từ hình ảnh đã tải lên của chúng tôi. Trạng thái không bắt buộc này là do các trường này không phổ biến đối với tất cả các định dạng ảnh và có thể bị xóa trước khi tải lên. Tôi đã tạo ra Photo với nhiều trường thường được sử dụng, bao gồm:
- camera_mfr
- camera_model
- camera_software_version
- image_x_resolution
- image_y_resolution
- image_resolution_unit
- image_exposure_time
- camera_aperture_f
- GPSLatitude
- GPSLongitude
- GPSAltitude
Các trường GPS đương nhiên là các trường bổ sung độ nhạy cao nhất cho Photo .
Mô hình của chúng tôi, với Tất cả dữ liệu nhạy cảm và có giá trị được xác định
Chúng tôi hoàn thành giai đoạn bảo mật cơ sở dữ liệu câu lạc bộ với những thay đổi này. Tất cả các kết nối và dữ liệu bổ sung cần thiết đều có sẵn, như được mô tả bên dưới. Tôi đã tạo Photo thông tin màu đỏ và Album màu ngọc lam nhạt để truyền đạt ý tưởng của tôi về các nhóm hợp lý. Việc tăng cường các phần tử dữ liệu là có thật, nhưng được giảm thiểu rất nhiều.
Kết luận
Việc đưa bất kỳ mô hình dữ liệu nào lên một nền tảng bảo mật tốt đòi hỏi phải áp dụng một cách có trật tự và có hệ thống các nguyên tắc bảo mật cũng như thực hành cơ sở dữ liệu quan hệ. Trong phần này, chúng tôi đã xem xét mô hình dữ liệu và cẩn thận điền vào cấu trúc còn thiếu đã được ngụ ý, nhưng không được thể hiện trong lược đồ. Chúng tôi không thể chỉ định giá trị hoặc cung cấp bảo vệ cho dữ liệu hiện có mà không thêm dữ liệu điền vào và liên kết chính xác các dữ liệu đó với nhau. Với điều này, chúng tôi sẽ tiến hành đính kèm các yếu tố định giá dữ liệu và độ nhạy của dữ liệu để cho phép chúng tôi nhìn thấy rõ ràng tất cả dữ liệu từ góc độ bảo mật hoàn chỉnh. Nhưng đó là trong bài viết tiếp theo của chúng tôi.
