Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Организация безопасного доступа к РСУБД
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Изначально доступ клиентских мест к РСУБД осуществлялся посредством VPN соединения. Всё работает, всё прекрасно, но мы наступили на следующие грабли: 1. Корпоративные сети администрируются людьми, недостаточно компетентными. Админы не могут обеспечить подключение к VPN неделями. 2. Многие клиентские места работают via GPRS. Как показала практика VPN via GPRS в нашем регионе штука практически нереализуемая. Не прописанные правила для 47 и 1723 портов, усугублённые использованием GPRS в качестве каналообразующей среды, почти всегда приводят к невозоможности соединится с VPN. Поэтому сейчас приходится пересматривать концепцию безопасного доступа к РСУБД. Само собой, что выставлять сервер за пределами демилитаризованной зоны, даже используя SSL, это самоубийство. Напрашивается вывод, что нужно делать некую программную прослойку, между клиентом и сервером. На вскидку напрашивается решение использовать SSL - web сервер. Который будет перекидывать данные на сервер баз данных. Безопасность можно усилить за счёт использования ЭЦП. Подобного можно добиться, если использовать ZeBeDee. Но он мне не понравился тем, что мы не сможем закрывать порты на клиентских местах. И тем, что аутентификация либо отсутствует, либо реализуется на ключах. Должен сказать, что клиентские места кишат троянами. Стало быть стащить ключи не особая проблема. Уважаемые коллеги, а какие мысли у вас, по организации безопасного доступа к РСУБД? Может у кого есть какие готовые решения? Возможно, походив по граблям, у вас есть о чём предупредить ваших коллег? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2007, 16:09 |
|
||
|
Организация безопасного доступа к РСУБД
|
|||
|---|---|---|---|
|
#18+
> Изначально доступ клиентских мест к РСУБД осуществлялся посредством VPN соединения Для какой цели, можно поинтересоваться? > SSL - web сервер Нормальный application server c CAS религия не позволяет использовать? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2007, 16:42 |
|
||
|
Организация безопасного доступа к РСУБД
|
|||
|---|---|---|---|
|
#18+
>Для какой цели, можно поинтересоваться? Хм. Интересный вопрос. Для того, чтобы к VPN люди подключались только авторизованные. Шифрованный канал. Сервер БД на сером адресе. Наружу ничего не торчит. А вообще, в чём изъян такого подхода? >Нормальный application server c CAS религия не позволяет использовать? Ну я вообще-то атеист. Вероятно мешает незнание что это такое и с чем это едят. Использование гугла почти не пролило на эту тему света. Понял, что это что-то связанное с ключами. Если это был намёк, то нельзя ли поподробнее? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2007, 19:00 |
|
||
|
Организация безопасного доступа к РСУБД
|
|||
|---|---|---|---|
|
#18+
Пока я нашёл только вот это http://en.wikipedia.org/wiki/Central_Authentication_Service Прочтение данной статьи вызывает больше вопрос, чем даёт ответов. Напрмер, если ли CAS под FreeBSD? Каким образом будут коннектится гетерогенные приложения к этому CAS? Насколько это надёжно? Нет ли в этом CAS дыр и прочих потенциальных уязвимостей? Где хранятся логины и пароли у клиента? Легко ли их уволочь троянами? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2007, 19:20 |
|
||
|
Организация безопасного доступа к РСУБД
|
|||
|---|---|---|---|
|
#18+
> А вообще, в чём изъян такого подхода? Просто хочется понять, откуда такие требования. Была как-то эпопея с подключением к опсосу - там тоже был VPN и все было очень просто. Но СУБД-то при чем? Юзеры напрямую к ней коннектятся? Вы бы про задачу подробнее рассказали - что есть и что от кого нужно защищать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2007, 19:33 |
|
||
|
Организация безопасного доступа к РСУБД
|
|||
|---|---|---|---|
|
#18+
Задача приконектить клиентские места, написанные на Delphi, на которых работают сторонние для нашей организации люди, к серверу БД, который крутится на сером адресе 172.ХХХ. И сделать это максимально безопасно. Чтобы данные не увели, чтобы не осуществили подмену данных, чтобы к базе посторонние не приконектились, и чтобы даже возможности у них такой не было. Ну и т.д. и т.п. Соединение с нашим VPN сервером было неплохим решением. Если бы все умели правильно транслировать порты 47 и 1723. Но как показала практика порою это решение было просто нереализуемо. >> Но СУБД-то при чем? Юзеры напрямую к ней коннектятся? Участники VPN конектятся напрямую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2007, 19:41 |
|
||
|
Организация безопасного доступа к РСУБД
|
|||
|---|---|---|---|
|
#18+
> приконектить клиентские места, написанные на Delphi Нет ничего, что можно написать на Delphi и нельзя написать на Ajax. Это первое, что приходит в голову. Я так понял, что есть локалка, есть внешний адрес, есть сервер, на котором подняты соответствующие интерфейсы, которые пробрасываются на внутренний сервер с базой данных. Так? Плюс видится только один - шифрованный внешний трафик. А сами данные плохо или никак не защищены. Строить ограничение доступа только штатными средствами СУБД можно пока клиентов мало. Мое imho - полный резон переходить на нормальную архитектуру с сервером приложений, сервером бд и работать по https. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2007, 20:31 |
|
||
|
Организация безопасного доступа к РСУБД
|
|||
|---|---|---|---|
|
#18+
Это я, пароль на работе забыл :) >Нет ничего, что можно написать на Delphi и нельзя написать на Ajax. Это первое, что приходит в голову. Спорное утверждение. Например, я работаю с портом RS-232. Думаю, Ajax тут совершенно не катит. Далее, Ajax это всего лишь интерактивный интерфейс web-приложений. У меня приложение не только не web, но и более того, бОльшую часть времени сидит в оффлайн, спокойно работая по RS-232 с периферией. Передавая данные в конце рабочего дня скопом. Ну или по просту, у меня не web приложение. А интернет используется всего лишь, как транспорт. >Я так понял, что есть локалка, есть внешний адрес Внешний адрес безусловно есть. Локалка -- это слишком громко. Серверная площадка, с тремя серверами. > есть сервер, на котором подняты соответствующие интерфейсы, которые пробрасываются на внутренний сервер с базой данных. Так? Ну, можно сказать, что так. Рабочее место соединяется с VPN сервером. Далее, через файрволлы идёт соединение с сервером БД. >А сами данные плохо или никак не защищены. Раскройте фразу. Что значит плохо или никак не защищены? VPN прекрасно шифрует весь поток. А к серверу БД пройдут только те, кому положено, в соответствии с правилами файрвола. >Строить ограничение доступа только штатными средствами СУБД можно пока клиентов мало. Штатными средствами СУБД ограничение доступа мы вообще не строим. Роли и гранты безусловно розданы правильно. Например, если клиент только заливает данные, то его роль ограничивается доступом к двум функциям, которые заливают данные на сервер. Весь доступ идёт на аутентификации при подключении к VPN. Подключился к серверу VPN -- добро пожаловать. Нет -- отвали. >полный резон переходить на нормальную архитектуру с сервером приложений, сервером бд и работать по https. Я вижу резон переходить на другую архитектуру. Архитектура с VPN вполне нормальна. https -- вещь более ущербная, чем VPN. А CAS ущербнее, чем VPN сервер. Это конечно моё IMHO. Поясните, что в Вашем (или в академическом) понятии сервер приложений? Какие функции ему присущи, и какой круг задач он выполняет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2007, 22:33 |
|
||
|
Организация безопасного доступа к РСУБД
|
|||
|---|---|---|---|
|
#18+
[quot [Paramedic]]Это я, пароль на работе забыл :) >Нет ничего, что можно написать на Delphi и нельзя написать на Ajax. Это первое, что приходит в голову. Спорное утверждение. Например, я работаю с портом RS-232. Думаю, Ajax тут совершенно не катит. Далее, Ajax это всего лишь интерактивный интерфейс web-приложений. У меня приложение не только не web, но и более того, бОльшую часть времени сидит в оффлайн, спокойно работая по RS-232 с периферией. Передавая данные в конце рабочего дня скопом. Ну или по просту, у меня не web приложение. А интернет используется всего лишь, как транспорт. [/quot] Может вам тогда перейти на оффлайн? Типа заколбасить данные в файлик, криптануть его (ну к примеру открытым ключем) - и передать на сервер (например приложений). И уже там его обрабатывать. Мы такое по сути используем для "отваливающихся" клиентов, где соединение не факт что продержится на время необходимое для транзакции. Файл передать легче, и в некотором роде надежнее и безопаснее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2007, 17:29 |
|
||
|
Организация безопасного доступа к РСУБД
|
|||
|---|---|---|---|
|
#18+
Ух, как я ступил... отчего-то решил, что раз есть клиент - то есть гуй. > А интернет используется всего лишь, как транспорт. Тогда я не могу назвать альтернативу vpn. > к серверу БД пройдут только те, кому положено, в соответствии с правилами файрвола Это да. И получаются ограничения только пользователями бд. С таким подходом не сталкивался, не могу оценить, насколько это эффективно. > сервер приложений Приложение, которое разруливает рутинные задачи. Сессии, доступ к данным, кэш и прочая ботва. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2007, 18:12 |
|
||
|
Организация безопасного доступа к РСУБД
|
|||
|---|---|---|---|
|
#18+
www.openvpn.org Работает через gprs/cdma/data call. Пользуюсь давно жалоб никаких. Думаю нечего искать поросёнка в ванной.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2007, 20:20 |
|
||
|
Организация безопасного доступа к РСУБД
|
|||
|---|---|---|---|
|
#18+
Всем спасибо. Поковыряю OpenVPN. Пока поковырял ZeBeDeе -- прикольлная штука. Правда не лишена недостатков. При работе без аутентификации -- к серверу подключается любой ZeBeDee клиент, а при аутентификации на ключах, у ключей нет достойного хранилища. Любой троян сопрёт файл с ключом как два байта переслать. Мысль с шифрованием файла неплоха. Но на данном этапе я недостаточно хорошо владею CryptoAPI. Так что отложу её на десерт. + требуется некое приложение на сервере, которое всё расшифрует в изначальный вид. Опыта писания под никсы тоже кот наплакал. А вообще мы вернулись к идее, изложенной в первом посте. Подписать (зашифровать) сообщение, и отдать его web-серверу. Которое переадресует его скрипту/приложению. (Я так понял что именно это и называется сервером приложений). Насколько я понял, так работает e-port. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2007, 21:50 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=34657738&tid=2005282]: |
0ms |
get settings: |
6ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
42ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
31ms |
get tp. blocked users: |
1ms |
| others: | 222ms |
| total: | 323ms |

| 0 / 0 |
