George-IIIПодскажите вот такой момент: С целью повышения контроля за доступом к БД рекомендуют разделять таблицы по нескольким БД

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

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

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

itnovicealexeyvgТакая схема в принципе используется, если надо действительно хорошо защитить информацию.

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

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

Больше того, пункты типа 4, по моему мнению, даже увеличивают уязвимости, именно потому, что людям приходится записывать пароли на листочках.

iscrafmalexeyvgЛюбой админ может получить доступ к такой информации, которую мечтают узнать члены совета директоров. Непорядочек :-)

а кто разрешения раздает членам совета директоров или админу?Например, владелец компании.

Или, по другому говоря, разрешения должны устанавливаться некими правилами (неважно, кто конкретно их в данном случае установил, например, совет директоров или владелец компании, или госдума в принятом законе), после чего правила должны выполняться.

Вот и нужно обеспечить выполнение этих правил.

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

Соответственно, эти положения закона относятся и к директору, и к админу, же для них нет в законе исключений, правильно?

Если нет согласия человека, то админ и директор не должны иметь возможности, например, связать информацию о ходе лечения с каким-то физическим лицом.

И всякие бандиты с терморектальным криптоанализатором не должны иметь возможности получить эту информацию от таких "суперадминов".
itnoviceЕсли ИТ-шники не будут иметь возможность работать с данными, и админы не будут получать доступ к серверу тогда качество продукта, как минимум, сведеться к нулю.

Как наиболее распространенный вариант разработчики не имеют доступ к данным продакшен серверам, а тестовые сервера набиты неактуальными данными.

Хотя на самом деле, как говориться без бутылки тут все не объяснишь, и не расскажешь :)Конечно, это усложняет процесс разработки и поддержки.

Ну так и говорится, что такая схема более трудоёмка.

Кроме того, обычно в таких случаях идёт речь о разделении связанных блоков информации, так что с каждым из видов информации админы и разработчики могут работать более свободно.

Это, понимаете, переход защиты на новый уровень, или может быть возврат на старый, в те благословенные для ИТ-секюрити времена, когда ещё не появились микропроцессорные системы с понятием рута и сисадмина :-) То есть когда админ мог только администрировать свои железо и ОС, но доступа к данным и к приложениям не имел.

Siemarglitnovice,
Так сказать, как пример .

iscrafm, разрешения конечно дает начальник СБ. Независимый и от админа и от каждого учредителя. Бай дизайн.Во первых, независимых начальников СБ не бывает.

Во вторых, это изначально ущербный подход, придумывается исключительно начальниками службы СБ для повышения собственного статуса.
С чего это начальник службы СБ будет принимать такие решения??? Он что, рулит бизнесом, что бы принимать вообще какие-либо бизнес-решения? А решения, кому давать доступ, а кому нет - это бинес-решения.
Его дело - выполнять установленные правила и следить за тем, что бы другие их выполняли.

itnoviceБольше того, пункты типа 4, по моему мнению, даже увеличивают уязвимости, именно потому, что людям приходится записывать пароли на листочках.

Да действительно, этот пункт палка в 2-х концах, с одной стороны хорошо с другой плохо.Дык не лучьше ли не заставлять менять пароли раз в месяц???

Не понимаю, зачем это делают. Пароль за месяц что, протухает?

Причём заметьте, что такие правила устанавливают только для тех аккаунтов, которые не имеют никаких прав. Рутовые пароли, пароли запуска ключевых сервисов админам раз в месяц менять ломает :-)

itnoviceНо если информация предоставляет действительно очень большую ценность для компании, тогда проводиться очень серьезный процесс воспитательной работы сотрудников против атаки социальной инженерии начиная от предупреждений, и заканчивая штрафами и увольнением.Знаете, что с простого сотрудника возьмёшь? Максимом, убьют, а легче от этого не станет - сделанного-то уже не воротишь, бабло потеряно, а то и того хуже.

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

Запустят ракеты за маленькую денежку от терористов и кирдык миру. И даже уволить потом будет некого :-)

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

Siemarglalexeyvg, приехали, жертва голливуда )))):-)

Понятно, что в обычных системах все эти меры не нужны, достаточно более просхых решений.

Хотя вот отделение персональной информации встречается часто - решение простое, недорогое, увеличивает защищённость и облегчает администрирование.