Про захист даних у файлах MDB СУРДБ Access.

Маленький відступ. Що таке СУРБД? Це розшифровується як Система Управління Реляційними Базами Даних. А що таке – реляційні? Для простоти можна сказати, що це бази, засновані на таблицях. А що, бувають інші? Так, бувають. Бази знань, ієрархічні бази, об'єктно-орієнтовані бази даних. Є файлові бази, побудовані на індексно-послідовному методі доступу до даних (Indexed Sequential Access Method – ISAM). У таких системах кожна таблиця зберігається в окремому файлі, а назва ISAM походить від фізичного способу зберігання і доступу до даних. Прикладами баз даних ISAM можуть послужити dBase, FoxPro, Paradox, Excel. Одні теоретики відносять ISAM до реляційних баз даних, інші вважають, що повноцінна СУРДБ повинна не тільки зберігати і витягувати інформацію, а й забезпечувати її цілісність. Access, В цьому сенсі, знаходиться десь посередині. Вона може виконувати деякі контрольні функції, але до SQL серверів їй далеко. Є й інші різновиди баз даних, але це вже окрема розмова. І так, продовжимо. Більш-менш просунутий розробник ділить свою MDB базу на дві, а іноді і більше частин. Поділ на інтерфейсну і табличну частину треба проводити, коли програма готова до передачі в експлуатацію, а іноді й раніше (якщо Ви не пишете програму тільки для себе). Це полегшує супровід програми, що знаходиться у клієнтів. І це, практично, обов'язкова вимога при побудові файл-серверних багатокористувацьких систем. Про захист клієнтської частини тут уже піднімалось питання. Я ж хочу розглянути проблему захисту даних, що знаходяться в таблицях. Будемо розглядати файл-серверний варіант розміщення бази.



Перш, ніж почнемо розмову про захист, Ви повинні ясно уявити собі, від чого ви хочете захистити свої дані. Захисту бувають різних рівнів і складнощів. І може бути виконання вимоги «максимально захистити всі дані »перевищить за трудомісткістю розробку і налагодження самої бази. І пам'ятайте, що одна людина зробила, інший завжди зламати може. І ніяка захист не врятує від звичайного нехлюйства. Я зустрічав випадки, коли логін і пароль доступу писали на папірці, а потім цей папірець клеїли на монітор, «щоб не втратити». І це не анекдот. Справа в тому, що пересічному співробітнику фірми / відділу найчастіше немає ніякого діла до захисту інформації. Його завдання – відпрацювати призначені години, причому з найбільшим комфортом для себе. Звідси і виходить: роздаєш паролі доступу КОЖНОМУ співробітникові, а вони їх пишуть на папірці (загальним списком) і кладуть під скло. Таке «неподобство» зазвичай закінчується тим, що хтось чогось не туди ввів / видалив. Починаються розбирання – і тут до оператора доходить, що якби він не розголошував свій пароль, то, отже, ніхто не зміг би влізти в базу і «колупатися» там від його імені. Звідси висновок – захист бази, справа КЕРІВНИКА, а не операторів. Розглянемо тепер способи захисту.


Адміністративний метод.


Дозволяє захистити від несанкціонованого копіювання самої частини бази з таблицями. З комп'ютерів вилучаються для запису CD / DVD, FDD, Zip і JAZZ накопичувачі, магнітооптика, USB закриваються програмно системним адміністратором. Всі операції запису на носії може виконувати тільки певна людина. Якщо є вихід в і-нет, то відповідне настроюється проксі-сервер. У користувачів видаляються повні версії Access і встановлюються Run-time версії, відбираються права адміністратора. Таку ситуацію зараз можна побачити на багатьох фірмах з усталеною структурою та налагодженою роботою, і де персональні комп'ютери – дійсно персональні, а не як жартували раніше – «персональний комп'ютер колективного користування.
Іноді, на жаль, адміністративний захист перетворюється на фарс: «опломбували» (заклеїли) папірцями USB, на КПП охороні дали вказівку перевіряти вхідних / вихідних на наявність дискет (подумати тільки, який архаїзм – красти дискетами), дисків … А багато спокійно ходять з мобільниками, в яких вбудована Flash – карта. Ніщо не заважає акуратненько відклеїти папірець з USB і «поцупити» інформацію в телефон. Поцупити я поставив в лапках, тому що подібний захист застосовується зазвичай там, де і красти то нічого (кому потрібні допотопні креслення й безглузда документація). Зазвичай така картина спостерігається на держпідприємствах, і показує, що «захистом» займається людина вельми далекий від програмних справ. Взагалі, у відділах, що відповідають за захист, не завадило б повісити такий плакат:


Якщо інформація записана – значить, її можна прочитати, якщо її можна прочитати – можна і скопіювати, якщо можна скопіювати – можна і вкрасти.


Маскування.


Як я писав раніше, розмова йде про розділеної базі даних. Частина з таблицями зазвичай зберігається на сервері. І всі користувачі повинні мати до неї доступ. Зазвичай на сервері створюється каталог share (ім'я може бути будь-яким) через який користувачі обмінюються файлами, де зберігаються документи загального користування тощо Ніхто не забороняє створити відповідний каталог і замаскувавши його під службовий, присвоївши яке-небудь високоумное назву. Помістити в нього базу даних (зазвичай, вже добре опрацьована і довго експлуатувати системи обростає купою додаткових каталогів, файлів, шаблонів і т.п.) і привласнити їй розширення, відмінне від MDB. При підключенні (лінкування) таблиць Ви вказуєте точний шлях і ім'я бази даних. І Access все одно, як називається файл, головне, щоб співпадала структура. Свого часу, в Донецьку, мені довелося зіткнутися з системою «Акцент» (бухгалтерська програма). Вона була написана на VC, а от в якості сховища даних в ній використовувалися MDB-файли, з розширенням – acc. Я зустрічав пропозиції взагалі міняти заголовок файлу, а перед лінковки підставляти правильний. Але я б не радив такого робити. Операції прямого запису деякі програми-сторожа (антивірусні монітори) визначають як вірусні атаки і блокують. Крім того, в багатокористувацької середовищі, достатньо підключитися до бази з таблицями одному з клієнтів, як змінений заголовок буде відновлений. Для того, щоб при простому перегляді клієнтської частини не можна було визначити шлях до бази з таблицями, шлях шифрується і відновлюється тільки у момент самого лінкування. Для того, щоб не можна було скопіювати лінки з клієнтського модуля, рекомендується наприкінці роботи відключати всі прілінкованние таблиці, а на початку – підключати. Але це добре для непрацюючого модуля. Варто тільки запустити клієнтську частину, як лінки на таблиці з даними будуть відновлені. А далі можна вже підключатися з чистої бази до працюючого клієнтського додатку та копіювати собі лінки на таблиці. Щоб цього не відбувалося, можна використовувати допоміжні програми-стартери. Наприклад, – ReleaseUpdate. Вона перевіряє наявність оновлень клієнтської частини, якщо вони є, то оновлює клієнтську частину, і запускає її на виконання. Клієнтську частину можна розташувати де-небудь в Program Files, в спеціальному каталозі, а шлях до неї, що знаходиться у внутрішніх таблицях програми ReleaseUpdate, можна зашифрувати. Є й інші готові аналогічні програми. Наприклад – MDBStarter.
На одному з підприємств мені показували таку систему. На сервері лежав каталог із загальним доступом і назвою типу SystemControlFS. Користувачі не могли там нічого видалити. У ньому була купа файлів і каталогів і файл SystemControlFS.exe. При спробі його запустити видавалося повідомлення, що у вас немає адміністраторських прав. База даних була замаскована під один з допоміжних файлів.


ПОПЕРЕДЖЕННЯ. Ніколи не надавайте базі розширення, зарезервовані для тимчасових файлів. Інакше програма очищення вінчестера може його видалити. Не присвоюйте розширення мультимедіа файлів. Інакше користувачі з цікавості весь час будуть намагатися його запустити, щоб глянути, що там адмін ховає на сервері?


Є ще одна можливість задурити користувача. Справа в тому, що в Access є три варіанти відображення об'єктів:


Системний об'єкт – Це вбудований об'єкт бази даних, визначений як системний, наприклад таблиця "MSysIndexes", або системні об'єкти, визначені користувачем. Для визначення системного об'єкта необхідно, що б його ім'я починалося з символів USys. Наприклад, додайте до назви форми, таблиці, звіту USys – і вони тут же «зникнуть», стануть системними, але звертатися до них з програми можна так само, як зазвичай. Щоб зробити об'єкт прихованим, потрібно виділити його, потім правою кнопкою – і в контекстному меню вибрати «Властивості» і задати параметр «Прихований».
Щоб побачити такі об'єкти, потрібно зробити наступне:

Сервіс – Параметри – Вкладка вигляд.

У групі Відображати виберіть потрібний варіант – поставте (заберіть) галочку «Приховані об'єкти», «Системні об'єкти» і т. д.
Багатьох користувачів така «захист» здатна буде збити з пантелику: навіть зумівши відкрити програму через Shift, вони з подивом виявлять, що якийсь форми або таблиці там немає, хоча при роботі вона видна. Але на професіоналів, звичайно, такий прийом не подіє – зрозуміло, вони знають про властивості об'єктів бази даних. Але, якщо врахувати, що більшість цікавих найчастіше кидають спроби «колупатися», якщо у них не вийшло з першого разу, то така «захист» заслуговує на увагу.


Захист на рівні доменних політик.


На форумі з Access, На сайті SQL.RU я зустрів таку замітку: «Всю свою трудову історію роботи з Аксесом, був твердо впевнений, що захистити ФС (файл-сервер) Аксеса (mdbmde) у мережі (та й не тільки Аксеса, а взагалі ФС) від несанкціонованого доступу до ладу неможливо. Поки один дуже сильний адмін у мого клієнта не продемонстрував мені таку штуку. Файл сервер, Аксес, домен, АТ, кулі (повний доступ, тому що це потрібно для ФС), додатки на клієнтських ПК (більше 20) працюють з файлом як зазвичай, штатно прілінкованние таблиці. Але … Ні в мережі, ні в консолі, навіть знаючи шлях до кулі і імена файлу, я не зміг скопіювати (смикнути) ф-л БД з сервера, ні відкрити ніякої зрозумілої програмою – привид. Тицявся, тикав … Уп-с. Чого він там Намудрували з політиками – не знаю, не коловся. Але факт, я не зміг отримати доступ до самого файлу БД. При цьому адмін працював штатними засобами віндового сервера. Після цього випадку я замислився. Про життя, про адміна, і про технології ФС, однією з гострих претензій до якої у мене була "незащіщаемость" сховища БД в мережі.
Якщо б мені це розповіли ДО цього випадку, якщо б я сам не намагався безуспішно "ломануть" свою ж АСУ, не повірив би. ». Подробиці не були розкриті, але один з перших читачів цієї статті, Малков Андрій Геннадійович, висловив таке міркування: «У користувача відбираються права на перегляд вмісту каталогу та пошук по каталогу де лежить база на сервері. І все.Юзер файл побачити не може, скопіювати не може, знайти не може, ярлик створити не може. АЛЕ! Може запросто з ним працювати, якщо йому дали дозвіл на зміну цього файла.І це не обов'язково це має бути сервер під Windows. На Nowell таке теж можливо запросто ». Я не є фахівцем з адміністрування Windows, але з особистого досвіду розповім таке. Коли виникла необхідність мені працювати з Developer SQL Server, то наш адмін встановив його в мене на компі, причому так, що я міг вільно працювати з базами, які перебували локально тут же на комп'ютері, знав розділ, де вони лежали, але не міг у нього зайти.

Захист за допомогою макросу AutoExec і блокування Shift.


Для побудови інтерфейсу захисту створимо два макроси: AutoExec, AutoKeys. AutoExec потрібен для перехоплення події «відкриття додатки», AutoKeys виконує схожу роль – перехоплює натиснення клавіш на клавіатурі. Щоб він їх перехоплював, він повинен називатися AutoKeys (зарезервоване ім'я в Access). З цієї ж причини AutoExec повинен називатися AutoExec. Ще один важливий момент – в меню Сервіс – Параметри запуску приберемо всі галочки, інакше обійти захист від Shift стане вельми просто: Вікно – Відобразити – Вікно БД. Якщо ж відключити все меню, то в пункті меню "Вікно" будуть виводиться тільки режими розташування вікон, а вікно бази виводиться не буде.
У макросі AutoExec дамо команду на запуск форми FrmStart, в макросі AutoKeys – форми ВклОткШіфт. Причому форма ВклОткШіфт буде запускатися при натисканні комбінації клавіш Ctrl + Q. Для цього в конструкторі задамо ім'я макросу – ^ Q.
Навіщо так мудро? Справа в тому, що якщо ми просто поставимо запуск форми в Сервіс – Параметри запуску, то при включенні захисту від Shift буде відкриватися пусте вікно Access. Ми закриємо базу взагалі для всіх, в тому числі і від себе! Для будь-якого замка повинен бути ключ: їм і виступає форма ВклОткШіфт – через неї встановлюється і знімається захист. А якщо її зробити прихованої (див. нижче) і запускати через макрос (Комбінацію клавіш) – ми ще більше заплутає цікавих юзерів. Саме включення відбувається через властивість бази


DBS.Properties ("AllowBypassKey") = True (або False)

У залежності від значення пароля, введеного в поле форми «ВклОткШіфт» цій властивості присвоюється True або False. Потім база закривається (щоб зміни вступили в силу)


DoCmd.Quit acPrompt


Приклад, як це все працює, Ви можете подивитися тут


Захист бази з таблицями трошки відрізняється від захисту бази з виконуваним кодом. Найчастіше стартова форма являє собою форму з попереджуючим написом типу «Таблиці з даними, Прямий доступ заборонено!» та встановленим таймером. Якщо після відкриття стартовою форми, протягом певного часу, не натиснута комбінація клавіш, що викликають форму відключення Shift, то додаток закривається. І тут фантазії розробників може розвернутися! Я зустрічав програму, де при спробі відкрити базу з таблицями, на весь екран розвертався чорний піратський прапор з черепом, зав'язаний червоною хусткою і пов'язкою на очниці, схрещеними шаблями і кривавої написом – «Тут Вас не чекають!». Можна через деякий час, перед закриттям бази пустити на динамік міліцейську сирену або зловісний регіт. Серед розробників БД є люди з гумором! Деякі «особливо злісні» програмери вбудовують ще команди перезавантаження і вимикання комп'ютера. А з урахуванням того, що клавіш багато, а висновок форми відключення захисту від Shift можна повісити і на більш складну комбінацію з декількох клавіш, то «експериментатору дуже скоро набридне наново включати комп'ютер
Зазвичай захист від Shift застосовують в комплексі з іншими методами: прив'язка до комп'ютера, вхід за паролем, шифрування даних і т. д.
А тепер додамо велику ложку дьогтю. Цей захист працює тільки для тих, хто вивчав Access по книгах типу «Access за 24 години», «Access для« чайників »» і т.п. Вона спрацьовує тільки в тому випадку, якщо Ви намагаєтеся відкрити базу MDB за допомогою програми Access. Проти звичайного підключення до неї інших програм вона не працює. Для цього можна використовувати ту ж Access. Досить створити чисту базу і пов'язати її з захищеною. Або імпортувати в неї весь вміст захищеної бази. Так у Вас виявиться точна копія захищеної бази зі знятим захистом. Крім того, в Інтернеті можна знайти програми, які заново включають Shift. А потім вантажі з натиснутим Shift і роби все, що завгодно.
Так, що переходимо до наступної захисту – захисту паролем.


Захист за допомогою пароля БД.


Даний спосіб захисту дозволяє встановити пароль на відкриття БД, для всіх користувачів. Для його створення необхідно відкрити файл БД в "монопольному" режимі і вибрати пункт меню Сервіс / Захист / Визначити пароль бази даних . Для роботи з такою базою даних в MS Access буде потрібно вводити пароль. Ось приклад роботи з файлом БД, використовуючи DAO або ADO.


Public Sub TestDAO()
    Dim mWS As DAO.Workspace
    Dim mDB As DAO.Database
    Set mWS = DBEngine.Workspaces(0)
    Set mDB = mWS.OpenDatabase _
        (“C:a97.mdb”, True, True, “;pwd=123”)
End Sub

Public Sub TestADO()
    Dim CnDB As New ADODB.Connection
    CnDB.Open “Provider=Microsoft.Jet.OLEDB.4.0” & _
              “;Data Source=C:a97.mdb” & _
              “;Jet OLEDB:Database Password=123”
End Sub


Це теж не самий надійний спосіб захисту баз даних. Існує достатня кількість безкоштовних і платних утиліт, що відображають пароль. У тому числі доступні вихідні коди коду на VB дозволяють прочитати такий пароль. В іншому не все так погано.
Справа в тому, що деякі розробники вважають, що крім англійської мови, інших мов не існує. Досить включити в пароль російські літери, щоб привести в ступор користувача, який використовує такі програми. Так, вони начебто й розкривають пароль, але те, що вони видають в якості пароля, розібрати неможливо.
Продовжимо ігри з паролем бази даних. Наприклад, можна використовувати в паролі недруковані символи. В першу чергу цей спосіб націлений на протидію визначення паролів за допомогою спеціальних програм. Стандартний спосіб встановлення і використання пароля БД передбачає його введення з клавіатури в діалоговому вікні. Якщо стоку пароля містить нецензурні символи, то вони не будуть коректно відображені програмою відкриває паролі БД. З іншого боку цей пароль можна ввести в діалоговому вікні при відкритті БД в MS Access.
Якби пароль містив символи табуляції, Esc або Enter, то стандартним чином Ви б не змогли їх ввести у віконце введення пароля. Спосіб заснований на тому, що пароль БД формату Access 2000 і 2002-2003 – текстова рядок у форматі Unicode (в Access 97 – ANSI). При цьому немає ніяких обмежень на її вміст. У специфікації баз даних і в довідці по DAO 3.60 зазначено, що максимальна кількість символів в паролі – 14. Але насправді їх може бути 20. При цьому і сам Access 97 не допускає введення рядків пароля більше 14 символів. У специфікації Access 2003 також сказано про 14 символів, але програма допускає введення всіх 20. Також можливе використання недрукованих символів, що приводить більшість програм зламували паролі в ступор.
Для установки такого пароля буде потрібно застосувати спеціальну програму, яка використовує метод CompactDatabase бібліотек ADOX або DAO.
Але, як мовиться, проти всього можна знайти лом. І такий захист розкривається.



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


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


Практично непрошібаемая захист. І клієнтська частина та база з таблицями знаходиться на сервері. У клієнта на комп'ютері емулюється термінал сервера. Немов ти за ним сидиш (в сенсі, за сервером). Можна налаштувати термінальний доступ так, що при запуску необхідної задачі (по ярлику), запиту відповідних паролів доступу до системи, відразу вантажиться необхідна база. При закриття бази термінал закривається. У самій базі прописана захист від шифту, відключені всі стандартні Access-івські меню і гарячі клавіші, відключено вікно бази. І нічого користувач ні затерти, ні скопіювати не може. Ні відкрити безпосередньо таблиці, ні отримати доступ до закритих для нього форм і звітів. Ще термінальний доступ називається, по-моєму, віддаленим робочим столом.
Недоліки цього способу – вся обробка даних лягає на сервер, зате в якості клієнтів можна використовувати слабкі машини.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*