Не хотел, честно говоря, давать конкретные рекомендации, но раз уж зашла тема о безопасности админа... 8-)Знаком с вопросом очень хорошо, довелось поработать в _разных_ конторах, в том числе разрабатывал методики и инструкции по изъятию выч. техники, носителей информации и других вещественных доказательств. Иногда сам в этом процессе принимал участие.
В целом основные идеи изложены правильно, но упущено следующее:
1) если СБ компании _следует_ иметь "разведку", то у гос. структур она УЖЕ есть. Называется это - "оперативная работа". Если изъятие производится не по "горячим следам", то _всегда_ этому предшествуют оперативные мероприятия.
Прорабатывается персонал, используется агентурная сеть, выясняется внутренняя структура компании, используемые системы безопасности (охрана, сигнализация, видео и т.д.).
Как правило, используется и/или вербуется источник либо в самой компании либо каким-то образом с ней связанный (например, "друзья", "коллеги по бизнесу" - читай "конкуренты", это может быть работник компании с не очень "чистым" прошлым и т.д.).
После того как собрана более-менее целостная картина, осуществляется планирование операции либо, при необходимости, назначаются дополнительные мероприятия (прослушивание телефонов, интернет-трафика, установка жучков и/или троянов для сбора информации о внутренней сети, паролях и прочем).
И _только_ после этого, с учетом всей информации, в удобное для них (читай - неудобное для их клиентов) время приезжают люди в масках, по возможности в присутствии соответствующим образом подготовленных и оборудованных специалистов, владеющих всеми оперативными данными и координирующих действия оперативной группы.
Еще следует иметь в виду, что собственно появлению людей в масках предшествует, как правило, появление людей в штатском, чья задача и будет заключаться в том, что бы находясь на месте до появления оперативной группы, не допустить нажатия всяческих кнопок, проглатывания дискет и разбивания хардов.
2) Не следует недооценивать профессиональный уровень ИТ экспертов из гос. структур. Как это ни странно, но не смотря на унизительно низкий уровень зарплаты (парадокс, но иногда и благодаря этому) люди, которые там работают имеют массу возможностей для обучения и тренировки профессиональных навыков. В частности постоянно тренировать ум им помогает практически полное отсутствие необходимого бюджета, когда многие сложные задачи приходится решать весьма нетривиальными методами, плюс они _уже_ имеют опыт подобных мероприятий, знакомы с распространенными и не очень методами сокрытия информации и обладают развитой способностью к системному подходу и мышлению, что обусловлено самой службой в подобных учреждениях.
Так что распространенный штамп о том, что все менты "тупые" в данном случае, скорее всего, можно считать недействительным. Специалисты, которые осознают свой уровень подготовки, но продолжают работать за эти зарплаты, как правило делают это либо из принципиальных соображений либо из спортивного азарта к подобного рода противостояниям и профессионального интереса к решению подобных задач. В конце-концов они на этом нарабатывают _свой_ опыт и знания (где они потом смогут этот опыт применить предлагаю в данном трэде дальше не обсуждать, будет явный офф-топик 8-).
Так что, проектируя подобные системы защиты информации, следует безусловно иметь в виду все вышеизложенное мной и предыдущим автором.
Решения, заключающиеся исключительно в установке шифрованных дисков и раздаче паролей будут абсолютно неработоспособны (во всяком случае, с точки зрения реальной защиты от гос. структур, ни кто не говорит, что админ не сможет это запустить, продемонстрировать руководству и получить премию 8-).
Подобные вещи что называется "на коленках" не делаются, они действительно требуют комплексного подхода, разработки полной и целостной политики безопасности (куда, кстати, входит и защита от вирусов, резервное копирование и т.д.), серьезной работы с персоналом и целого ряда других специфических знаний и мер, обсуждать которые здесь считаю нецелесообразным.
Такие проекты "затачиваются" под конкретного клиента в индивидуальном порядке и, как правило, за совершенно индивидуальные деньги. 8-)
P.S. на тему бедного несчастного админа - намного целесообразнее провести оперативную работу с ним _заранее_, чем выбивать из него пароли и ключи _потом_, которых у него действительно может и не быть. Но кто сказал, что админ (или кто-то другой) не сможет поиметь всю информацию в тот момент, когда она будет находиться "в работе" (диски смонтированы, пароли введены)?..
Успехов в работе! 8-)
>Осмелюсь представить на ваш взгляд некоторые идеи по решению проблемы "Маски-Шоу". Меня
>подобная проблема занимает уже давно, правда, к счастью, чисто гипотетически. Однако
>я довольно неплохо все обдумал. Сразу извиняюсь, непосредственно о создании шифрованной
>ФС тут не будет ни слова. Однако я надеюсь, что вы
>найдете представленные ниже соображения достойными внимания. Итак:
>
>1. Решение должно быть комплексным, т.е. наихудший случай - это когда все
>ложится на плечи бедного админа, а проблема недопущения утечки информации решается
>в последний момент. У серьезной фирмы должна быть своя разведка, которая
>должна отслеживать "Политическую Ситуацию" вокруг фирмы, дабы заблаговременно (!!!) уведомить руководство
>об угрожающих моментах.
>2. Порядок работы фирмы можно разделить на три стадии: мирное время, обострение
>ситуации и конфликт. Если разведка засекла обострение ситуации, то надо заблаговременно(!!!)
>начинать готовиться к конфликту. Как можно больше данных следует зашифровать и
>в таком виде вообще вывести из обращения. Причем, дабы админу потом
>не прищемили дверью сами знаете что, следует исключить возможность того, что
>ему известен пароль - нужно сгенерировать его таким макаром, чтобы его
>знал только руководитель или вообще не знал никто. По моему, для
>выводимых из обращения данных лучше использовать симметричное шифрование с очень длинным
>ключем (допустим, что это компакт-диск с последовательностью случайных чисел), после чего
>ключ заныкать в одном месте. а зашифрованные данные в другом. Желательно,
>чтобы они были разделены географически и административно. Например мы отвозим ключ
>в швейцарский банк, а данные в секретное хранилище. Следует разделить исполнителей
>этого задания и исключить возможность обмена между ними информацией. Данные, без
>которых вообще нельзя обойтись, должны храниться в одном из вариантов зашифрованной
>файловой системы. Мне кажется, что лучше иметь несколько таких файловых систем,
>к которым бы имели доступ люди с разными привилегиями.
>3. В случае конфликта атакуемая сторона должна иметь время на принятие решения.
>Это достигается построением _многоуровневой_ системы ФИЗИЧЕСКОЙ защиты. Есть очень хорошая бумажная
>книга на русском языке на эту тему - ее написала американский
>эксперт, долгие годы работавшая на правительство США. Она вроде так и
>называется - системы физической защиты. Очень рекомендую купить и ознакомится. Там,
>в частности, приводятся сведения о времени преодоления различных заграждений. Систему безопасности
>следует строить таким образом, чтобы время преодоления препятствий атакующими было строго
>больше времени на принятие адекватных ситуации мер. Например, у нас сидит
>охранник на системе видеонаблюдения. Он засек, что началось маски-шоу. Он нажимает
>на кнопку на пульте (а таких кнопок следует иметь несколько в
>разных местах здания), что приводит к блокированию пути к серверной железныим
>решетками. Одновременно о происходящем ставится в известность админ - например при
>помощи сирены у него над ухом :) В принципе, можно присобачить
>на эту же кнопку некую программу, которая, будучи запущена, сильно поможет
>админу в его нелегком труде.
>В итоге, когда атакующие доберуться до серверной, мы будем иметь зашифрованные данные,
>не будем иметь ключа для их расшифровки, а атакующая сторона не
>сможет вытянуть ключ из админа, так как он его просто не
>знает. Идеальной защиты не бывает, и в конце концов при должном
>усердии атакующая сторона получит доступ к данным, однако случится это не
>скоро и вины сисадмина в этом уже не будет.
Вариант для распечатки
Скрипты, настройки и файлы конфигурации. (Public)
on 12-Окт-02, 15:49 
