Архив форумов ЦИТФорума

[Azid]

Доброго времени суток, тут интересная задачка всплыла.
Коротко: в конторе есть БД в которой ведутся критические данные, есть сеть с контроллером домена, есть админ домена никак не подконтрольный.
Требуется разместить БД на открытом ресурсе, таким образом, чтобы не пользователи домена, ни сам админ не смогли: - получить доступ, копировать, и т.д.
Соображения такие: БД - зашифрована, если ее и скопировали, то не вскроют. Подключение к ней по сети проходит по защищенному протоколу(SSL TLS).
Вопрос, какими инструментальными средствами это можно реализовать??? Может есть кто что знает, тогда подскажите

[Dragner]

[San_dok]

[Azid]

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

[bvvtver]

Если я понял задачу правильно, то необходимо развернуть БД не предоставляя доступ администратору домена (admin1), т.е. администрировать данную БД будет другой человек, админом в домене не являющийся(admin2).
Самое простое решение видится в развертывании отдельного сервера, не входящего в домен. СУБД и платформа принципиальной роли не играют, просто на примере Win+MSSQL получается, что на сервак и СУБД даем административные права админу2. Доступ юзерам давать на основе SQL аутентификации. Дополнительно шифровать в данном случае не требуется. Собственно все. Конечно придется схему доработать напильником и без участия admin1 не обойтись , например, выбрать IP, настроить доступ к серверу для доменных пользователей, вероятно зарегистрировать в DNS и/или Wins, решить вопрос с бэкапом. Но на мой взгляд все это решаемо.

[Dragner]

Не, вы, скорее всего, не правильно поняли задачу. Как я ее понял: необходимо спи... спереть базу данных, выложить на общий ресурс, чтобы админ (admin1) не имел доступа к ней. А имел доступ другой человек (admin2), который мог бы спокойно сливать инфу.

[San_dok]

Мое мнение имхо задача в таком ракурсе нерешаема.
Совершенно неясно, как можно доработать напильником ситуацию при крахе DC вторым админом. Даже при бекапе базы.
И второе. Это нифига уважаемый не житейская ситуация. Если вы не хотите, как вам сказали разворачивать свой сервер, а хотите на чужом выложить БД, неизвестно чего и кого, то почему вы думаете, что хост должен и будет нести за вас ответственность?
Разворачивайте благополучно у себя в сети ftp и наслаждайтесь полными правами.
_________________
В тёмной комнате завсегда имеются тёмные грабли.

[bvvtver]

Не дождался я комментария автора, поэтому опишу подробнее свое видение проблемы и ее решение.
Предположим гипотетически, что в конторе есть необходимость вести конфединциальную БД с ограниченным уровнем доступа. Это может быть зарплатная база, база ОК или черная бухгалтерия. По каким-то причинам руководство не считает, что admin1 должен иметь доступ к данной БД, что в принципе, при определенных обстоятельствах имеет смысл.
Из личного - работал в конторе среднего размера, где 5 админов и 3 программера были прекрасно осведомлены о зарплатах и бонусах топов, имели доступ к базе ОК и проч. Это все реалии сегодняшнего дня, т.к. политики безопасности зачастую просто нет, даже в зачаточном состоянии. Учитывая гроши, которые платили в IT, если бы гендир об этом знал, точнее хотя бы предположил, что этот факт имеет место быть - он был бы немного расстроен)) .
Продолжаю...Полномочия по администрированию данной БД хотят дать исключительно в руки другого лица или лиц (возможно избранного программиста, умеющего обращаться БД) находящихся в "круге первом".
Так вот - в данной ситуации речь идет между разделениями полномочий между двумя ролями admin1 и admin2 (личности опустим). Admin1 - администратор AD, сети, public BD и проч.
Admin2 - администратор private BD.
Данное разделение можно создать и в пределах одного домена, но я в качестве более простого решения предложил в своем предыдущем посте развертывание StandAlone сервера.
Хотелось бы услышать автора, для корректировки задачи, ибо я вполне мог уйти не в ту степь.