информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Портрет посетителяСетевые кракеры и правда о деле ЛевинаАтака на Internet
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / beginners
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Господа, будьте снисходительны, не бросайтесь сразу штрафовать за, как вам кажется, глупые вопросы - beginners на то и beginners.
Может пойти с другой стороны? 08.06.09 11:26  Число просмотров: 3201
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 08.06.09 12:52  Количество правок: 1
<"чистая" ссылка>
Задача не имеет общего решения мне кажется; все частные решения скорее всего будут несовершенны (отнять у базиста права одмина базы, дать ему только backup-operatora, отобрав права на select :) и/или логгировать его дствя, но тут замучаешься читать, да и это при большом желании сто пудов обходится минимальным взаимодействием с другими юзерами).

Можно подумать в другом направлении: маскировать\шифровать\как-нить ещё прятать критичную информацию из базы, т.е. сделать так, чтобы доступные данные были бы бесполезны, хотя бы относительно... Возможно переезд на трёхзвённую архитектуру с шифрованием во втором звене и защитой этого самого второго звена от копирования, переезд на SQL Server 2008 с TDE на борту, короче это просто мысли, тут надо смотреть частности ситуации.
<beginners>
Права администратора 05.06.09 16:29  
Автор: gig.Stg Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Уважаемые безопасники, подскажите, какими способами можно ограничить права системного администратора? Например есть обоснованное опасение, что могут быть скопированны базы данных
Очень широкая тема. Надо как минимум знать 1) что за базы, 2) где базы физически находятся и как осуществляется доступ к ним, 3) с какими правами осуществляется доступ 05.06.09 16:40  
Автор: Ustin <Ustin> Статус: Elderman
<"чистая" ссылка>
Базы SQL, находятся на 2х серваках, админы имеют доступ на... 06.06.09 11:31  
Автор: gig.Stg Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Базы SQL, находятся на 2х серваках, админы имеют доступ на всё... Грамотно вешают начальству, что только так работать можно, те запретить боятся, но и по ночам не спят.... Пытался на "тонкого клиента" перевести, но считают, что дорого.... Может быть хотябы теоретические соображения будут, а там как-нить домозгуем...?
Какую функцию выполняет системный администратор, которому требуется ограничить права? 06.06.09 15:31  
Автор: Den <Denis> Статус: The Elderman
Отредактировано 06.06.09 15:32  Количество правок: 2
<"чистая" ссылка>
Их двое, один специализируется на поддержке баз, другой... 07.06.09 11:45  
Автор: gig.Stg Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Их двое, один специализируется на поддержке баз, другой управляет доступами и "типа" безопасностью. В целом 3 базы, на 2х серваках.... (Клиенты, заказы, и полная каша внутренней инфы)
Если первый специализируется на поддержке баз, может делать... 07.06.09 19:59  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
Если первый специализируется на поддержке баз, может делать резервные копии этих баз, а следовательно может и утащить их. Второй может дать себе любые права на любые объекты, а следовательно, может делать резервные копии баз.
Ну и как вы себе представляете ограничение прав этих админов?
В том-то и дело... Есть лишь одна идея, но тоже... 08.06.09 11:15  
Автор: gig.Stg Статус: Незарегистрированный пользователь
<"чистая" ссылка>
В том-то и дело... Есть лишь одна идея, но тоже слабоватая... Запретить возможность копирования одному... Т.е. если копировать, то чтоб оба зашли в систему... Есть надежда, что договориться им между собой уже сложнее будет...
1. Либо у нас есть хотя бы один админ, которому мы доверяем... 08.06.09 11:49  
Автор: verik Статус: Незарегистрированный пользователь
<"чистая" ссылка>
1. Либо у нас есть хотя бы один админ, которому мы доверяем полностью (пусть даже он появляется раз в месяц). Он имеет абсолютные права и может делать все, а другим админам уже раздает права по крохам. Доверие - самый распространенный вариант для малых организаций.

2. Либо мы используем проприетарные решения с доработкой под заказ, тогда возможен вариант с несколькими админами, одновременно вводящими пароль и т.п. Такой вариант редко кто выбирает из-за его сложности. Цена вопроса - от десяток тыс. долларов. Каков, кстати, Ваш бюджет на этот проект? И какова ценность утраты данной информации?

3. Либо за админами следит Служба Безопасности. Она неспособна отследить факт копирования, но хороший не-ИТ безопасник способен отметить, когда админзахочеткопировать базу и будет пытаться еепродать А этим путем идут уже крупные организации.
Может пойти с другой стороны? 08.06.09 11:26  
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 08.06.09 12:52  Количество правок: 1
<"чистая" ссылка>
Задача не имеет общего решения мне кажется; все частные решения скорее всего будут несовершенны (отнять у базиста права одмина базы, дать ему только backup-operatora, отобрав права на select :) и/или логгировать его дствя, но тут замучаешься читать, да и это при большом желании сто пудов обходится минимальным взаимодействием с другими юзерами).

Можно подумать в другом направлении: маскировать\шифровать\как-нить ещё прятать критичную информацию из базы, т.е. сделать так, чтобы доступные данные были бы бесполезны, хотя бы относительно... Возможно переезд на трёхзвённую архитектуру с шифрованием во втором звене и защитой этого самого второго звена от копирования, переезд на SQL Server 2008 с TDE на борту, короче это просто мысли, тут надо смотреть частности ситуации.
Сегодня прошло совещание, результатом которого явились... 08.06.09 21:50  
Автор: gig.Stg Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Сегодня прошло совещание, результатом которого явились два...

Сегодня прошло совещание, результатом которого явились два варианта, на которые согласно начальство и админы. Теперь надо выбрать: 1) Тонкий клиент 2) Поскольку базы обновляются достаточно редко, то резервное копирование достаточно осуществлять раз в неделю, и в присутствии начальства. По тонкому клиенту вопросов нету, уже работали. Но вот по второму пункту посложнее (а изберут скорее всего именно его). Как лучше будет ограничить права админам, SQLными средствами, или покупать специализированный софт? (если есть в памяти привидите пример)
Забавно... 09.06.09 02:13  
Автор: Den <Denis> Статус: The Elderman
Отредактировано 09.06.09 02:22  Количество правок: 2
<"чистая" ссылка>
ИМХО, самый лучший вариант - "тонкий клиент" или "терминальный доступ". Но для этого потребуется дать такие права и настроить политики таким образом, чтобы админ SQL сервера не имел больших привелегий в самой системе (на которой крутится SQL) и не имел доступ к ресурсам сети, в т.ч. и при подключении терминальным клиентом.

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




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach