Существует ряд проблем, которые нужно решить при разработке ПРД. Вот они:
Эти проблемы рассматриваются ниже. Кроме того, вы можете захотеть включить в ваши ПРД раздел, связанный с этикой использования СВТ и АС. Паpкеp, Своуп и Бейкеp [17, PARKER90], а также Фоpестеp и Моppисон[18,FORESTER] являются двумя полезными спpавочными pуководствами, описывающими этические вопpосы.
Одним из действий, которые вы должны произвести при разработке ваших ПРД, - это определение тех лиц, кому разрешается использовать вашу АС и ваши сервисы. ПРД должны явно определять, кому официально разрешено использовать эти ресурсы.
После определения того, кому разрешен доступ к ресурсам системы, необходимо дать рекомендации по приемлемому использованию ресурсов. Вы можете давать различные рекомендации различным типам пользователей (например, студентам, сотрудникам факультета, внешним пользователям). ПРД должны определять, что такое допустимое использование, а также что такое недопустимое использование ресурсов. В них также следует включить определение типов использования ресурсов, применение которых может быть ограниченным.
Определите границы доступа к ресурсам и полномочия при доступе. Вам понадобится учесть уровень доступа, который будут иметь различные пользователи, а также то, какие ресурсы будут доступны или ограниченно доступны различным группам людей.
В отношении допустимого использования ресурсов ваши ПРД должны однозначно установить, что каждый человек отвечает за свои действия. Их обязанности существуют всегда, независимо от того, какие механизмы секретности действуют. Должно быть явно определено, что использование чужих паролей или обход защиты являются недопустимыми действиями.
Следующие моменты следует учесть при разработке правил допустимого использования:
Ответом на большинство этих вопросов будет "НЕТ".
Вы можете захотеть включить в ваши ПРД пункт, связанный с программным обеспечением, защищенным авторскими правами или лицензированным. Лицензионное соглашение с производителями может потребовать некоторых усилий от вас для того чтобы гарантировать отсутствие нарушений лицензии. Кроме того, вы можете захотеть проинформировать пользователей, что копирование программ, защищенных авторскими правами, является нарушением законов об авторских правах и запрещено.
В отношении программного обеспечения, которое является лицензионным или защищено авторскими правами, вы можете захотеть включить в ПРД следующую информацию:
Ваши правила допустимого использования очень важны. ПРД, которые явно не определяют, что запрещено, могут впоследствии не позволить вам доказать, что пользователь нарушает ПРД.
Существуют исключения, такие как пользователи или администраторы, желающие иметь "лицензию на хэккерство" - вы можете столкнуться с ситуацией, когда пользователи захотят исследовать ваши АС ради тестирования защищенности. Вы должны разработать ПРД, которые будут определять, можно ли вам разрешать такой тип исследований ваших сетевых служб и, если это так, каковы рекомендации при проведении таких исследований.
Что вам следует отразить в этой части ПРД:
В тех случаях, когда вы разрешили проведение таких исследований, вы должны изолировать тестируемую часть сети от основной сети. Сетевые вирусы и просто вирусы никогда не должны запускаться в реальной сети.
Вы можете также захотеть подрядить кого-либо для оценки защищенности ваших АС, что может включать их исследование. Вы можете захотеть отразить этот момент в ваших ПРД.
Ваши ПРД должны устанавливать, кто отвечает за предоставление разрешения на доступ к вашим службам. Более того, должно быть определено, какой тип доступа они могут предоставлять. Если вы не контролируете, кто дает разрешение на доступ к вашим АС, вы не контролируете, кто использует ваши АС. Контроль за тем, кто имеет право давать доступ, позволит также вам узнать, кто имел или не имел разрешение на доступ при последующих проблемах с защитой.
Существует много схем, которые можно использовать для управления распределением доступа к вашим службам. Далее приводятся факторы, которые вы должны учитывать при определении того, кто распределяет доступ к вашим службам:
У вас может быть одно центральное место для предоставления полномочий на доступ в распределенной системе, в которой различные ведомства независимо отвечают за предоставление полномочий на доступ. Нужен компромисс между защищенностью и удобством. Чем более это процесс централизован, тем более он защищен.
С точки зрения безопасности вам нужно знать механизм, который будет использован при регистрации новых пользователей. При самом незащищенном варианте люди, которые отвечают за регистрацию пользователей, могут просто войти в систему и создать нового пользователя вручную или с помощью механизма, определенного производителем. В общем случае эти механизмы доверяют человеку, запускающему их, и человек, запускающий их, обычно имеет большие привилегии. Если вы выбрали этот способ, вам нужно выбрать кого-либо, кто не подведет вас при решении этой задачи. Другим способом будет создание интегрированной системы, которая запускается людьми, отвечающими за регистрацию, или самими пользователями. Помните, что даже наличие самого защищенного средства создания новых пользователей не избавляет вас от возможности злоупотреблений им.
У вас должны быть разработаны специфические процедуры для добавления новых пользователей в АС. Эти процедуры должны быть хорошо документированы для предотвращения неоднозначных толкований и уменьшения числа ошибок. Уязвимость защиты при создании новых пользователей возникает не только из-за возможных злоупотреблений, но также из-за возможных ошибок. Просто и хорошо документированная процедура поможет быть уверенным, что ошибок не будет. Вы также должны быть уверены, что люди, которые исполняют эти процедуры, понимают вас.
Предоставление полномочий пользователю на доступ к АС - один из самых уязвимых моментов. Вы должны быть уверены, что пароль, выбранный вначале, не может быть легко угадан. Вы должны избегать использования в качестве начального пароля слова, производного от имени пользователя, являющегося частью имени пользователя, или некоторого алгоритмически сгенерированного пароля, который может быть легко угадан. Кроме того, вам не следует позволять пользователям продолжать использовать начальный пароль неопределенно долгое время. Если это возможно, вы должны заставлять пользователей менять начальный пароль при первом сеансе работы с АС. Учитывайте то, что некоторые пользователи могут так никогда и не войти в АС, что делает их пароли уязвимыми неопределенно долгое время. Некоторые организации приняли решение удалять пользователей, которые никогда не пользовались АС, и заставлять владельцев этих имен заново регистрироваться в списке пользователей.
Одним из решений в области защиты, которое нужно принимать очень тщательно, - это кто будет иметь привилегии системного администратора и доступ к паролям ваших служб. Естественно, что системные администраторы будут иметь такие права, но неизбежно и другие пользователи будут просить специальных привилегий. Ваши ПРД должны так или иначе решать эту проблему. Ограничение выдачи привилегий - один из способов защиты от угроз, исходящих от местных пользователей. Целью является компромисс между ограничением доступа ради большей безопасности и предоставлением привилегий тем людям, кому на самом деле нужны такие привилегии, чтобы они могли решать свои задачи. Одним из подходов к решению является предоставление только тех привилегий, которые необходимы для выполнения своих задач пользователем.
Кроме того, люди, владеющие особыми привилегиями, должны быть учтены специальным органом, и эта информация также должна зафиксирована в ПРД организации. Если человек, которому вы предоставили особые привилегии, не учтен сам по себе где-либо, вы рискуете потерять контроль за вашей АС и у вас возникнут трудности при управлении безопасностью.
Ваши ПРД должны включать пункты о правах и обязанностях пользователей в отношении использования СВТ и сервисов организации. Должно быть явно установлено, что пользователи отвечают за понимание и соблюдение правил безопасности в АС, которые они используют. Далее приводится список моментов, которые вы можете захотеть зафиксировать в этой области ПРД:
Ассоциация электpонной почты финансиpовала публикацию о конфиденциальности электpонной почты в компаниях[4]. Их базовой рекомендацией в отношении электронной почты является то, что каждая организация должна иметь политику по защите частной собственности своих служащих. Также рекомендуется, чтобы организации установили политику в отношении частной собственности при использовании всех сред передачи информации, а не только электронной почты.
Предлагается пять критериев для оценки любой политики:
Существует компромисс между правами пользователя на абсолютную частную собственность и необходимостью системным администраторам собирать информацию, необходимую для выявления причин возникновения проблемы. Также существует различие между необходимостью системного администратора собирать информацию для решения проблемы и исследованием причин нарушения защиты. ПРД должны определять, в какой степени системные администраторы могут исследовать пользовательские файлы для диагностики проблем или других целей, и какие права вы гарантируете пользователям. Вы можете также захотеть добавить утверждение относительно обязательств системных администраторов по сохранению в тайне информации, полученной ими при таких исследованиях. Для этого надо ответить на несколько вопросов:
Перед тем, как предоставить пользователям доступ к вашим службам, вам нужно определить, на каком уровне вы обеспечиваете секретность данных в вашей АС. Определив это, вы определите уровень секретности данных, которые пользователи могут хранить в вашей АС. Вы не должны позволять пользователям хранить очень важную информацию в АС, которую вы не собираетесь делать очень защищенной. Вам нужно сообщить пользователям, которые могут хранить конфиденциальную информацию, о том, какие службы, если они есть, более подходят для хранения конфиденциальной информации. Эта часть должна включать хранение данных различными способами (диски, магнитные ленты, файл-серверы и т.д.). Ваши ПРД в этой области должны быть скоординированы с ПРД в отношении прав системных администраторов (смотри раздел 2.3.6).
Назад | Содержание | Вперед