Управление на кръстосано четене на бази данни, изгледи или разрешения в MySql

Ще имам множество таблици, използвани от различни проекти на един и същ mySql сървър. Голяма част от данните са чувствителни и трябва да бъдат зад стената с разрешения. Много от таблиците с чувствителни данни обаче разчитат на таблици с нечувствителни данни за информация за потребителите и отделите. Така че виждам три варианта пред себе си и не съм сигурен кой да избера.

Всичко в една база данни с разрешения на ниво таблица

Най-простото от всички решения, с изключение на това, че аз не контролирам разрешенията на сървъра на базата данни, традиционно екипът на сървъра прави само разрешения на ниво база данни и да ги накарам да разрешат това е политическа битка, която може да нямам влиянието да спечеля, и следене на всички разрешенията биха били болка.

В множество бази данни, с разрешения на ниво база данни

Мога да разделя таблиците на зони на база данни, така че информацията за целия отдел, като данните за персонала, може да бъде в собствената база данни и инструментите, които редактират данните за персонала, могат да имат достъп UPDATE&INSERT до базата данни на отдела. Други инструменти биха искали достъп до части от списъка на персонала, публичната директория на персонала има SELECT достъп до таблиците на персонала, но части от таблиците на персонала ще трябва да останат лични, като лична информация за контакт, кодове за копиране или индекси за фактуриране. Ще трябва да разделя таблиците на служителите на публични или частни таблици, но отново ще остана с разрешения на ниво таблица. Така че ще трябва да разделя базата данни на отдела на споделена и частна база данни на отдел.

Изгледи на различни бази данни Бих създал изгледи в база данни, която изтегля данни от други бази данни, до които акаунтът няма достъп. Така че мога да поставя цялата информация за персонала в базата данни на отдела, след което да създам изглед в уеб базата данни, който изтегля само колоните, които трябва да бъдат публично достъпни (име, отдел, разширение). Това би ми позволило всъщност да имам SELECT права на ниво колона, без да се налага да се занимавам с разрешения. Притеснението ми ще бъде скоростта. Оригиналната таблица, от която се изтеглят данните, ще бъде напълно индексирана, но документацията изглежда противоречива, независимо дали колоните ще бъдат индексирани или не при запитване към изгледа.

Някой друг използвал ли е някоя от тези три опции? Имате ли по-добри, за които не съм се сетил? Какви са капаните, които можете да видите отвъд това, което посочих за всяка от опциите?


person Tyson of the Northwest    schedule 05.03.2010    source източник


Отговори (1)


Изгледите и съхранените процедури са най-добрият ви залог. Изгледите могат да се използват за предоставяне на общ достъп, но ако някои заявки не се изпълняват, пренапишете ги, за да използват съхранени процедури, заобикаляйки изгледа за производителност.

person Martin    schedule 06.03.2010
comment
Съхранените процедури също ще преминат ли бариерата за разрешения, за да мога да настроя процедурите с висок акаунт, след което да преглеждам данните с нисък акаунт? - person Tyson of the Northwest; 08.03.2010
comment
да - една от основните характеристики на съхранените процедури е, че позволяват по-добро управление на привилегиите. Акаунтът, под който са дефинирани съхранените процедури, би бил по-добър като локален акаунт - например 'sp_owner'@'localhost' - за намаляване на риска от отдалечен потребител да получи мощен достъп под акаунта, ако разбие паролата. Най-гъвкавото споразумение е, ако вашите съхранени процедури са дефинирани като create definer=current_user procedure ..., тогава решението за това под кой акаунт са дефинирани те може да бъде отложено до момента на зареждане. - person Martin; 09.03.2010