Чи безпечніше пройти через 3-ту базу даних для підключення двох баз даних, використовуючи той самий логін?

У нас є така настройка:

• Кілька виробничих баз даних, що містять приватні дані, які використовуються програмним забезпеченням на робочому столі
• Веб-база даних для загальнодоступного веб-сайту, яка потребує деяких даних із приватних баз даних
• Посередницька база даних, яка містить кілька переглядів і збережених процедур, які витягують дані з приватних баз даних

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

Обліковий запис користувача має повний доступ до веб-бази даних та бази посередників, але може отримати доступ лише до певних представлень даних та збережених процедур та приватної бази даних

Це справді безпечніше, ніж просто змусити загальнодоступну базу даних підключитися безпосередньо до приватної?

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

Тут вискакує одне:

Весь процес використовує однаковий набір даних для входу

Проблема

Таким чином, гіпотетичний userX (будь-який м'ясозабірник, що використовує Excel, або IIS AppPool Identity) може бачити деякі погляди та код. Не має значення, в якій базі даних є ці перегляди та код, тому що userX все одно встановлений у 3 базах даних.

Однак ви втрачаєте таке прив’язання до власності.

Скажімо, WebDB.dbo.SomeProcдзвінки PrivateDB.dbo.SomeTable. UserX вимагає дозволу на обидва об'єкти. Якщо це OneDB.WebGUI.SomeProcвикористовувалося, OneDB.dbo.SomeTableтоді OneDB.WebGUI.SomeProcпотрібні лише дозволи. Дозволи на об'єкти, що посилаються, з тим самим власником не перевіряються.

Примітка. Я не надто глибоко придивився до ланцюжка власності міжбазових баз даних . Я знаю тільки просту стару «ланцюжок володіння» добре

Тепер, за коментарями, у вас дійсно є 2 бази даних, які можна комбінувати. Не 3, що спочатку малося на увазі. Однак проміжний і веб-сайт можуть поєднуватися.

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

Рішення?

Якщо додаткові бази даних є лише контейнерами з кодом, тоді схеми є кращою ідеєю.

Це здається, що ви використовували "Базу даних", де ви повинні використовувати "схему" (в сенсі SQL Server, а не в MySQL). У мене є схема WebGUI, схема Helper або Common (для заміни проміжної бази даних) і схема Desktop. Таким чином ви розділяєте дозволи на основі клієнтів і просто маєте одну базу даних

За допомогою однієї бази даних (окрім "ланцюжка власності") ви також можете почати розглядати індексовані представлення, СХЕМАННІСТЬ (я її завжди використовую) та такі, які неможливо зробити з окремими базами даних

Докладніше про схеми див. У цих питаннях:

• Дизайн схеми - найкращі практики?
• Над використанням / правильним використанням схем?

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

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

Якщо ні, я не думаю, що це додає нічого, крім складності.

Редагувати:

Здається, я неправильно прочитав ваше запитання, тож давайте подивимось, чи правильно я зрозумів зараз: IntermDb - це порожня база даних просто для підключення до PrivateDB АБО це БД, яка має власні подання / процедури, які підключаються до PrivateDB для отримання даних. ?

У першому випадку WTF? Відірвіть його. Це марно, якщо хтось не хоче його перевірити, щоб проглядати доступ до PrivateDB в більш лазерний спосіб (і зробити так, щоб розробники WebApp більше працювали). SQL Profiler може фільтрувати за допомогою DB_ID ...

У другому випадку я підтримую свою попередню відповідь.

EDIT: "Я все ще не бачу, наскільки це безпечніше, ніж підключення приватного db безпосередньо до загальнодоступного db, оскільки всі 3 бази даних у тому самому екземплярі SQL і вхід, що використовується для всіх 3 баз даних, однаковий, і отримати доступ до нього можна лише конкретні перегляди та збережені процедури в приватному DB будь-коли ".

Наявність посередника означає, що окупанту доведеться викопати ваш код знати про існування IntermDB - і йому доведеться викопати ваш код на ньому, щоб знати, що існує PrivateDB.

Якщо ви поставите PrivateDB на інший внутрішній для вашої організації LAN / WAN вашої організації (якщо це можливо), він може дати достатній час адміністратору виявити та заблокувати спробу вторгнення. Якщо ви використовуєте синоніми, цей хід є плавним, оскільки все, що у вас є, це відновити їх до існуючого коду і перейти в потрібне місце.

Також ви отримуєте інші переваги: ​​оскільки весь код повинен пройти через IntermDB для доступу до даних у PrivateDB, жоден розробник не спокуситься спробувати обійти його - і цю спробу можна легко помітити на Profiler SQL Server як DB_ID запиту даних PrivateDb. буде WebAppDb.