Можно прямо тут?
Кхм-кхм... Товарищи, я Пастернака не читал...

В общем всё ИМХО.

1.
Если это статья, а не сборник хинтов и историй, желателен более академический, строгий стиль изложения. По факту. Без сленга форума.

2.
Введение. Зачем оно? Тот кто будет читать статью уже должен знать что такое РСУБД. А кто не знает, тому рано читать такие статьи. Нужно просто изложить технические приёмы, приводящие к желательному результату. Это статья, нельзя объять необъятное.

3.
А что такое - реляционные? Для простоты можно сказать, что это базы, основанные на таблицах
Лучше приведите ссылку - определение

4.
Пункт про мимикрию с переименованиями и хитрыми именами я бы не рассматривал в основном разделе, это не серьёзно. Так у прочитавшего статью может возникнуть чувство ложной защищённости.

5.
То же про пункт с tbl001... там в ремарке сказано верно - это будет горе для фирмы. А злоумышленника не остановит.

6.
Подмена заголовков файла БД - не стоит внимания. Репайр-тулзы лечат. К тому же можно доиграться. Т.е. я имел ввиду, не стоит рассматривать полу-кустарные, на грани фола, методы в основной части статьи. Есть вполне леагльные, выработанные меры. А эти пустить обзорно, просто - де есть такие, но...

7.
Работа с привязкой серийных номеров вендора матери или хдд, их хранение и обработка. Т.н. санкционированный запуск РМ.

8.
Добавить вопрос о шифрованных областях (PGP, JBC) и бэкапов (автоматы). Блин, мы вторгаемся в область работы админа, если честно. Половина методов - не компетенция программиста на Аксесе. А вот шифрование БД штатными средствами Асксеса и что из этого получается - вполне кандидат на тему. Как и ограничения, вытекающие из оного.

9.
Файл групп mdw, управление группами, права объектов, виндоуз-аутентификация и апп-аутентификация, логирование, аудит... (меня понесло - тыгдым-тыгдым).

10.
В остальном, требуется более завершённая форма, что ли... Составьте тезисный план, не торопитесь. (Ну уж извините, вы взялись добровольно) :-) Вообще, не совсем понятна целевая аудитория статьи? Большинству состоявшихся разработчиков, она не интересна, ИМХО. Для начинающих - слишком много надо рассмотреть с нуля (например, что такое ACL, и как вы будете рассматривать понятия прав, не разъяснив сущности контрольного листа?), впрямую не относящегося к программированию и БД. Админам - тоже никуда. Т.е. получается, что частные вопросы в статье, файл рабочих групп, права-объекты и т.п. будут изложены в спец.литературе более полно и верно. Тот же Гетц 2 тома, MSDN и т.п.

Может, была бы полезнее компиляция из открытых источников, не только и не столько по форуму? Форум достаточно кривое зеркало. А так собрать в одном месте профессиональную информацию из разных источников и страниц. Копируйте с указанием источника и копирайта, для обзорной технической статьи это приемлимо.

Вы взялись за непростое дело. Удачи.

Зы:
Извините, поворчал.

2 Joss:
Начните с тезисов, детальным содержанием они наполнятся позже. Нужно сначала сделать рыбу. Чтобы понять - что писать. (И очень желательно перед тем как писать, ознакомиться с тем, а что же человечество уже написало на эту тему?)

JossВряд ли это будет статья в академическом смысле
Зря! Написание таких статей увлекательное дело. Не снижайте себе планку сразу, это не будет интересно ни вам, ни читателям статьи. Ведь вы и так уже знаете многое из того о чём собрались писать? А ради чего? Значит, поднимите немного планку, и тянитесь выше. Это - развитие в первую голову самого автора статьи. Известный в инженерии метод.

Например:


Видите? Стоит только задуматься, получается роман, а не памфлет. :-)

В любом случае, разработайте сначала ТЗ на статью. А статья потом сама напишется. Лишнее потом выкинете.

Тогда это будет, действительно, полезная работа. Думаю, многие из опытных посетителей форума могут подключиться и напишут по пункту-абзацу, можно прямо в тред и из собственного опыта, а вы потом скопируете в текст статьи. В общем, такой ОпенСорц на общественных началах. :-)

Зы: Это только пример! Дерзайте. Перед вами все пути!

ЗыЗы: А можете не дерзать, а просто выпить пива. Тяпница же!

2 Любопыт:
Охо-хо... Если будет время (!) вполне возможно помогу, чем смогу. Но, ничего не обещаю. Работы лом! Какие уж тут статьи?.. И вообще, это затеял Joss! :-)

2 Ёжик`:
Да вопрос-то не в мучении.
Сравнивать защищённость данных ФС и КС - неблагодарное занятие, по здравому размышлению. Тем более, надо смотреть "по месту применения" и конкретному решению на заданную точку отсчёта.

Но, действительно, зачастую, даже там где БД можно вполне защитить, разработчиками и админами не делается ничего вообще. А зачем? Незащищаемо-же! И живут годами мифы о "принципиальной невозможности" защиты данных и БД Аксеса. Если для ОС вида w98 в одноранговых сетях это ещё отчасти (!) справделиво, то при современном уровне развития ОС, файловых сетей и систем защиты, согласиться с таким утверждением нельзя! Вот и весь компот...

Иногда даже обидно, ёлки-палки. :-) Т.е. почти массовая профанация в этом вопросе автоматически ставит крест на вполне адекватных решениях на основе Аксеса. Тем более, никто не собирается "догонять и перегонять" СКЛ сервер по секурности - это ветряные мельницы. Но заранее отказываться от имеющихся возможностей - глупо. Тем более, такие вопросы возникают постоянно.

ЗЫ:
У Аксеса есть родимое пятно - это его ниша. РАД, ФС. Она его успех, она же и проклятие. Инструмент очень интересный, не такой простой, как кажется на поверхностный взгляд. Аксес - музыкальная шкатулка с секретом. Не без недостатков, но и не без достоинств. Но он - вечный полигон для новичков, ясли-сад, с очень низким порогом вхождения. Отсюда и реноме. Отсюда и, кхм-кхм, многие вопросы на форуме - вы же видите уровень! (Ничего против - начинают с нуля и учатся все, вопрос в том - чему и как) Матёрые спецы быстро теряют к Аксесу интерес, зачастую нифига не исчерпав его возможностей, и уходят на более хлебные технологии, более престижные, мейнстрим... Это нормально, такова жизнь. Смена поколений и снова с того же места... "Как занести в эту штучку эту ручечку, и не учите меня жить, а напишите, что мне скопировать и куда, и побыстрее". А через год оно уже научится произносить более сложные предложения: "больше 3-х коннектов к базе Аксес не тянет", и "принципиально невозможно защитить ФС БД", и "транзакций в Аксесе нет", и "более 200Мб Аксес не жилец", и "ссылочная целостность на ФС невозможна", и "в ВБА нет ООП", и...

В общем, на этом фоне усилия того же Joss - вполне мессионерство. И заслуживает внимания и поощрения.

Ёжик`(акс полюбому сломать можно имъо)
По-любому, сломать можно всё! И СКЛ сервер, и секурное ПО и... Абсолютных величин нет - всё есть взвешенная стоимость, баланс интереса и цены решения. ;-) А лень и беспечность наказуемы.

Любая система защиты ФС - это барьер первого удара. Не надо пропускать глупых плюх. Например, если стоимость защищаемой информации, её практическая ценность, на порядок меньше стоимости её взлома, защита работает. Она выполняет свою функцию. Как только баланс сдвигается - будут проблемы. Защита БД Аксеса в сети, для подавляющего большинства фирм малого и среднего бизнеса, использующего его для повседневной автоматизации, в этом разрезе имеет положительный баланс.

2 вадя:
Используют часто так-же BJC, PGP или вообще аппаратное шифрование на массивах. Это необходимо.

Но вопрос защиты шире - защита данных БД от человека который уже работает с АРМ-мом через интерфейс программы. Вот ему "не положено" ни видеть таблиц клиента (mde), ни знать о них чего-либо более, чем ему позволено правами его роли. И тут шифрование само по себе уже не... диск открыт-то.
Да и клиентов шифровать - лише, они не содержат данных. Шифровать нужно саму БД. А клиентов защищать средствами ОС и политиками.

Но как составляющая часть общей стратегии защиты данных - без шифрования БД не обойтись.

Зы: Кстати, на терминал-сервере клиентскую часть к БД тоже шифровать излишне - необоснованная нагрузка на сервер.

Joss, вам ещё интересна эта тема?
Вот вам в копилку метод получше жёсткого ограничения. Я тут проконсультировался с админом клиента на этот предмет.

Приём №3 (тезисно, по памяти)
Защиты файла .mde ФС Аксес штатными средствами ОС.

Приём рассматривается для рабочей станции WindowsXP Pro и сервера Windows 2003 Server как PDC, Active Directory, NTFS5.

Рабочая станция - учётная запись пользователя, ограниченная в возможностях администрирования и доступа к служебным инструментам. Желательно, чтобы на ПК пользователя не было полного Аксеса (только RunTime), и потенциально опасных средств разработки и скриптинга.

В данном примере использована способность современной ОС запускать в текущей сессии пользователя приложение под правами другого пользователя, пароль которого текущему пользователю неизвестен. (>runas /? консольный вариант.)

В АД создаётся учётная запись пользователя, например, MDE_User, задаётся стойкий пароль.

На сервере создаётся общий ресурс, например, MDE_Base. Права на этот ресурс даётся только для администратора и систменого пользователя MDE_User.

На локальном ПК создаётся каталог, например, MDE_Client, права на который даются только администратору и пользователю в АД MDE_User. В этом каталоге располагается собственно апп - клиент .mde (интерфейсная часть) для БД лежащей на сервере в каталоге MDE_Base.

На локальном ПК под рабочей учётной записью пользователя нужно найти исполнимый файл рунтайма с расширением .exe, правая кнопка мышки "Запуск от имени...". Указать пользователя АД MDE_User, ввести пароль, сохранить.
Теперь рунтайм будет исполняться в пространстве сессии MDE_User при запуске пользователем, пароль и пользователь сохранены в АД, вводить их больше не нужно. Сделайте ярлык на рабочем столе к этому рунтайму с указанием пути к апп .mde клиенту. Всё.

Теперь, пользователь запускает ярлык - запускается RunTime с клиентом .mde в пространстве и с правами пользователя MDE_User. Т.е. программа свободно пишет-читает в локальный каталог MDE_Client (поскольку у него есть на это права), свободно читает-пишет в серверный ресурс MDE_Base, где лежит БД с данными. Но сам пользователь, в обход апп под RunTime-ом, не имеет доступа ни к локальной папке, ни к папке на сервере. И не получит к нему доступ ни из интерпретатора командной строки cmd.exe (>COPY...), ни из любого другого кода, работающего в сеансе текущего пользователя (FileCopy...).

Этот приём можно использовать в сочетании с другими. Всё зависит от применения "по месту". Так же этот приём можно использовать для защиты локальной .mde на одном ПК. Только вместо политики АД в сети, будет выступть вкладка "Безопасность", для локальных учётных записей. В этом случае нужно помнить, что пользователь на локальном ПК не должен иметь прав админа.

ИМХО не сложно. Это "базовая техника", её можно развить в более развитую.

Примечание:

Тут, в догонку, уточнили, что иногда могут быть ситуации, когда "Запуск от имени..." не сохранит реквизиты запуска в АД (зависит от настроек чего-то там...) и тогда запуск с ярлыка запустит апп с текущей учёткой пользователя. Что нам по задаче не нужно, т.к. апп не получит доступа к папке MDB_Client.

Не беда.

Есть простой хинт. Существует мощная, бесплатная скрипт-машина AutoIt3. Это развитая среда для административных задач и для автоматизации рутинных процессов при установке и т.п. Я её часто использую и вам рекомендую. Язык у неё VB-Like, хороший хелп, полностью интегрируется с фри-редакторами типа CrimsonEditor (можно писать и в блокноте). Результат может быть скомпилирован в компактный самоисполняемый .exe малого размера, не требующий наличия самой скрипт-машины на целевом ПК.

Так вот, хинт в том, чтобы запустить наш РунТайм с нужной учёткой из стартового скрипта AutoIt3:
В хелпе скрипт-машины всё подробно описано.

Всё. Сам скрипт скомпилить, расположить на сервере вне MDB_Base, сделать доступным для группы пользователей .mde и доступным только на исполнение. На Десктопе пользователя расположить ярлык.

Зы: Можно применить любую другую скрипт-машину.
ЗыЗы: Можно применить консольную >runas ... (с небольшим бубном для ввода пароля в фоновом режиме)

AutoIt скрипты - введение и FAQ
По ссылке с этой страницы попадёте на сайт разработчика.

JossПравда пока вместо стройной статьи получается как бы сборник материала, который надо ещё причесывать.
"И путь в тысячу ли начинается с первого шага..." (с) Китайская поговорка.

По-моему, вы переоцениваете моё участие и значение в вашей статье. Это ваш труд более чем. Описываемые хинты и приёмы не тайна за семью печатями. Систематизация таких знаний - достойный труд.

Поймите правильно, пожалуйста. Если бы я хотел "засветиться", я бы, во-первых, зарегистрировался на форуме, а во-вторых, не под дурацким ником ЁхынПалыч! Может, когда-нибудь так и сделаю. ;-)

ByKiSА помойму нормально.
По-моему тоже. Добавить ссылку на sql.ru - форум многим помогает, но при этом остаётся достаточно обезличенной сущностью. Хотя, одни уважаемые мемберы вполне адресны, другие нет, есть вечные "гесты". Это не мешает и тем и другим вносить вклад в общую "базу знаний". Тоже стараюсь, по мере собственной дремучести... Но я не мемебер. На то свои причины.

"Всё равно какого цвета кошка, главное чтобы она ловила мышей..." (с) Ещё одна китайская поговорка.

2 ВС:
"Это точно!.." (с) т.Сухов. ;-)

Зы: Уважаемый Joss, вы можете со спокойным сердцем вписать любое понравившееся имя. :-)