Безопасность БД

[Sparky]

Доброе время суток. Встал вопрос о выборе тему курсовой, решила взять что-нибудь связанное с безопасностью БД. Преподаватель предложил такую задачу, описание было очень не формальным поэтому привожу как было: в качестве СУБД firebird. Есть множество филиалов в каждом вертится свой сервер БД, необходимо обеспечить доступ пользователей одного сервера к другому.
У кого какие идеи?
Быть может как-то изменить тему пока не поздно, но тогда на какую? Направление: безопасность в БД

[Stilet]

У кого какие идеи?

В главной конторе пусть вращается БД с логинами и ролями пользователей.
А вообще огнептичка по-моему ролевым механизмом снабжена, проще ИМХО написать программу для администратора, которая позволит роли редактировать в определенном филиале.

[Sparky]

Вот тоже кажется что на курсовую не тянет. Может у кого есть идеи, что взять на курсовую по программно-аппаратным комплексам защиты информации? Хотелось бы что-то связанное с БД.

[Stilet]

Вот тоже кажется что на курсовую не тянет.

Фигасе не тянет!
Это же промышленная задача.

программно-аппаратным комплексам защиты информации?

Хм... Предположим так:

Когда-то обсуждали с начальством такое - Есть сервер, в него вставлено некое SCSI устройство (или аппаратный ключ типа флешки если брать попроще). В это устройство зашиты некоторые функции, без которых некая программа у клиентов не работает. Скажем так - основные функции работы. Сам клиент связан по TCP с сервером, и запрашивает выполнение сих функций некому драйверу (типа RPC схемы). Функции выполняются и возвращают результат. Естесственно каждый клиент снабжен шифратором. Смысл сего - вынести в удаленку всю главную работу клиента.

[Sparky]

для того-что написать практику по предложенному нужно обладать такими устройствами иначе будет все очень абстрактно
Хочется что-то связанное с БД.
Если вернуться к тому что предложил преподаватель как спасет наличие таблицы с логинами и паролями? Просто я даже не знаю от чего тут отталкнуться...

[Stilet]

как спасет наличие таблицы с логинами и паролями?

Странный вопрос... После получения логинов клиентская система сможет обращаться к базе другого клиента. У каждой БД будут свои отличные или точнее уникальные роли.

[Sparky]

т.е. ты предлагаешь следующую систему:
перед подключением к другой БД, пользователь подключается к головной БД забирает оттуда логин и пароль подходящий к БД, которой он хочет подключиться и уже с его помощью подключается к необходимой БД?
Насколько понимаю узким место будет как раз являться наличии таблицы логинов и паролей только на одном сервере БД, тогда стоит делать реплекацию данной таблицы, чтобы при падении головной БД возможность установления связи не терялась. Ну и плюч надо шифровать трафик между ними при передаче логинов и паролей. А то передавать их в открытом виде печально

[Stilet]

тогда стоит делать реплекацию данной таблицы

Ну это даже не оговаривается
Однозначно делать реплики.

Ну и плюч надо шифровать трафик между ними при передаче логинов и паролей. А то передавать их в открытом виде печально

Фтопку шифр. Лучше делать так: Как только некий клиент запросил у головного оффиса контакт с филлиалом ему и тому филиалу отправляется некий ключ-хэш, основанный на пароле и логине, соли, дате времени и случаном числе. Такой себе Session ID. Вот по нему пусть и общаются. Моня даже в целях паранойдальности время от времени в течении сеанса менять этот SID.

[Sparky]

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

Алгоритм работы:
1. когда пользователь обращается к БД другого филиала, он сначала просматривает свою таблицу, если необходимая запись там есть то пробует подключиться и забрать необходимые данные. Если нет или подключение не заканчивается успехом переходим к шагу 2
2. пользователь филиала подключается к ключевому серверу запрашивает логин, пароль и строку подключения и заносит данные в свою таблицу.

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

Насколько понимаю реализовывать стоит через хранимые процедуры.
Правильно ли рассуждаю в целом?
Насколько это имеет практическую значимость и потянет ли на курсовую?
Какая предметная область на это заточена, мне кажется это будет полезным для различных гос стуктур, когда достаточно получить только чуть-чуть данных от других и репликация не нужна.

[Stilet]

на нем в конфиг файле лежит строка соединения с сервером

Упаси боже. Какая нить школота обязательно захочет поатаковать сервер. Уж лучше тогда через ODBC настраивать. Не всякий о нем знает.

она заполняется по мере обращения к другим филиалам.

Тоже не в коем случаи. Реплики не должны выходить за пределы главного филиала, иначе какой смысл в безопасности? Всем будет все известно, ведь таблицы с паролями будут и на филиях.

2. пользователь филиала подключается к ключевому серверу запрашивает логин, пароль и строку подключения и заносит данные в свою таблицу.

Только так, с одной поправкой - никакие пароли он у себя не хранит, и при каждом подключении обязательно спрашивает разрешения у главного оффиса.

Насколько это имеет практическую значимость

Имеет. Почти так работают банки