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

Требования к регистрации и процедуры регистрации

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

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

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

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

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

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

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

Приглашенные и прочие пользователи

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

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

Если принято решение использовать эти рекомендации, то можно записать в правила набор формулировок следующего характера.

Приглашенные noльзователи и прочие пользователи, не являющиеся сотрудниками организации, получают доступ к сети и ее ресурсам у поручителя организации и назначенного системного или сетевого администратора. Администратор разрабатывает процедуры для предоставления, отмены и пересмотра права доступа приглашенньм пользователям и прочим пользователям, не являющимся сотрудниками организации.
Поручитель предоставляет пользователям право доступа к пpaвилам безопасности организации и процедурам и разъясняет им, что они обязаны соблюдать эти правила. Поручитель и администратор отвечают за контроль соблюдения правил приглашенными пользователями.
Пользовательские имена должны присваиваться приглашенным пользователям только на то время, пока им необходим доступ в систему. Имена пользователей должны быть аннулированы, как только доступ им станет ненужным.

Регистрационные баннеры

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

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

Баннеры существуют не только для регистрации
Тем, кто разрабатывает правила применения регистрационных баннеров, важно помнить, что баннеры применяются не только при регистрации. Солидный баннер может быть строкой приветствия при отправлении электронной почты с помощью протокола SMTP (Simple Mai! Transfer Protocol - упрощенный протокол электронной почты). Большинство программ, отвечающих на запросы SMTP, выводят регистрационные баннеры, которые идентифицирует систему и даже версию используемого программного обеспечения. Хакер может использовать эту информацию, чтобы найти способ "протестировать" конфигурацию на предмет уязвимых мест. Несмотря на то, что какая-нибудь рабочая программа может быть предметом вашей гордости (особенно та, которая упаковала и отправила электронную почту), все-таки лучше ее спрятать от широкой публики.

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

Использование этой системы разрешено при условии соблюдения правил и методик компании.

Если одно из нечасто выполняемых действий выходит за рамки предписаний, то будет нелишне отразить это соответствующим пунктом правил. Обязательно нужно рассмотреть, желательно с привлечением юриста, возможные изменения существующих правил. Таким образом, мы можем модернизировать предыдущую формулировку правил, включив в нее предписание о неразглашении:

Баннеры, которые выводятся на экран при регистрации и аутентификации, должны содержать следующее сообщение: "Использование этой системы разрешено при условии соблюдения правил и методик компании."

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

Средства регистрации

Средства регистрации способствуют процессу аутентификации. Они обеспечивают выполнение инструкций для обеспечения положительного результата аутентификации (биометрия, PKI, Kerberos и т.д.), а также выбор многократных или однократных сеансов. В правилах положительной аутентификации не нужно конкретно определять протокол или тип сервиса, а только требования их наличия. Если не конкретизировать правила, разработчики и администраторы получают возможность использовать наилучший сервис для организации. Простая формулировка правил может выглядеть следующим образом.

Службы регистрации должны обеспечивать положительную аутентификацию. Это даст гарантию того, что законный пользователь получит доступ к системе или сетевому окружению.

Для некоторых организаций выбор однократных или многократных сеансов аутентификации не представляет особых проблем. В операционной среде сервера, обслуживающего типовые рабочие станции, система с сетевой структурой может инициировать многократные сеансы так, как требует операционное программное обеспечение. Однако, при использовании универсальной машины или любого другого сервера с разделением времени/монопольным сервером может возникнуть желание ограничить количество сеансов, которые может инициировать пользователь.

Пользователям с правом доступа к производственной сфере нельзя разрешать инициировать многократные сеансы аутентификации.

Отчетность при регистрации

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

Другое требование заключается в том, чтобы пользователь имел возможность определить, когда и откуда была сделана последняя попытка войти в систему. Несмотря на то, что многие пользователи игнорируют эту информацию, есть шанс, что необычные попытки получения доступа будут отмечены. Один из администраторов, с которым пришлось сотрудничать автору, пытался помочь пользователю, у которой были проблемы с рабочей станцией. Когда он стал протоколировать каждую регистрацию пользователя в системе, в сообщении о "последней регистрации" было обнаружено, что пользователь была зарегистрирована в 4 часа утра, в воскресенье. Это выглядело довольно странно, поскольку в это время она отсутствовала в городе, так как выезжала в горы кататься на лыжах. Администратор смог на основе этой информации определить, что кто-то взломал сеть. В документах политики безопасности этот момент не был учтен, поэтому, когда выяснилось, насколько легко пробить защиту, этот момент добавили в соответствующие правила.

Ограничение количества регистрации

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

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

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

Управление пользовательским доступом

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

• Обработка неиспользуемых имен пользователей.
• Инструкции, касающиеся уволенных служащих или служащих, которые временно не работают.
• Удаление или защита пользовательских имен, присвоенных "по умолчанию".
• Разрешение или запрет анонимных пользовательских имен (таких как анонимный ftp).
• Требование распределения пользователей по группам или выполняемым функциям.

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

Привилегированный режим работы

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

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