Яка частина ризику для безпеки публікується концептуальною схемою?

Я вимагав концептуальні схеми від інформаційної системи урядового відомства для проведення моїх досліджень. У моєму запиті відхилено на підставі ризику для безпеки.

Я не маю великого досвіду роботи з базою даних, тому не можу підтвердити цю претензію. Чи розкриття вашої схеми насправді є великим ризиком для безпеки? Я маю на увазі, що вони досить абстрактні та відірвані від апаратних та програмних реалізацій. Пояснення того, як зловмисник міг би використовувати концептуальні схеми, було б вдячно. Спасибі.

Погоджено з gbn (так +1), але я думаю, що у грі є дві інші можливості:

1. Цілком можливо, що їхня концептуальна схема сильно збігається з їх фізичною схемою. Знання назв таблиць дає вам гідний початок у плануванні атак на ін'єкцію SQL.

2. Цілком ймовірно, що їх концептуальна схема не зафіксована. Організації, які дозволяють програмістам проектувати власні бази даних, часто не мають жодної суворості в процесі проектування баз даних, переходячи безпосередньо до фізичної реалізації без будь-якого початкового проектування. Вони можуть не захотіти цього визнати, або вони не хочуть піти на час і проблеми, коли створюється концептуальний документ, який ніколи не існував.

Редагувати: ОП прокоментувало, що організація, яку запитують щодо їх концептуальної схеми, є органом управління. Це, на мій погляд, додає ще одну ймовірну можливість:

Державні службовці не відомі своєю любов'ю до ризику, і тому функціонер середнього рівня в урядовому департаменті навряд чи зможе стягнути шию і випустити інформацію на випадок, якщо це може привернути увагу чи неприємність когось із подальших ієрархій. .

Я все ще думаю, що №2 - це найімовірніше.

Я б припустив, що це ризик інтелектуальної власності, але вони не хотіли цього говорити

Я повністю погоджуюся, що концептуальна схема таємної інформації також повинна зберігатися в таємниці.

Якщо шпигуни збирають маленькі ласощі інформації, які якимось чином прослизають через щілини, все ще залишається проблема поставити ці примхливості в контекст. Концептуальна схема забезпечує контекст. Форма та вміст зібраних ласощів можуть суттєво відрізнятися від форми та змісту даних у базі даних, але конкретна схема дає чудовий посібник із розшифровки матеріалів.

Працюючи над відновленням даних для компаній, я завжди вважав надійною концептуальною схемою золоту шахту. Безумовно, ці проекти не передбачали шпигунства. Але легко можна побачити, як передається той же аналіз.

Дуже багато постачальників намагаються тримати схеми бази даних близько до своїх грудей. Як це часто ні, мова йде про те, щоб тримати кришку своїх брудних таємниць, як, наприклад, відсутність цілісності даних або очевидно поганий дизайн бази даних. Інші причини:

• Багато програмних продуктів мають погано розроблені схеми баз даних.

• Бажання не зазнавати навантаження на підтримку.

• Спроби змусити клієнтів купувати консультаційні послуги для роботи з інтеграцією систем.

• Бажання максимально збільшити витрати на вихід, щоб відмовити клієнтів від переходу на товари конкурентів.

На жаль, ти не працюєш для замовника, але якби ти був, ти можеш використати аргумент в порядку запитів, які саме архітектурні вади має програмне забезпечення, так що викриття схеми бази даних може бути ризиком для безпеки.