2.3 Политические проблемы

Существует ряд проблем, которые нужно решить при разработке ПРД. Вот они:

1. Кому разрешено использовать ресурсы?
2. Что такое правильное использование ресурсов?
3. Кто отвечает за предоставление доступа и надежное предоставление сервиса?
4. Кто может иметь привилегии системного администратора?
5. Каковы права и обязанности пользователей?
6. Каковы права и обязанности системного администратора по отношению к пользователям?
7. Что делать с конфиденциальной информацией?

Эти проблемы рассматриваются ниже. Кроме того, вы можете захотеть включить в ваши ПРД раздел, связанный с этикой использования СВТ и АС. Паpкеp, Своуп и Бейкеp [17, PARKER90], а также Фоpестеp и Моppисон[18,FORESTER] являются двумя полезными спpавочными pуководствами, описывающими этические вопpосы.

2.3.1 Кому разрешено использовать ресурсы?

Одним из действий, которые вы должны произвести при разработке ваших ПРД, - это определение тех лиц, кому разрешается использовать вашу АС и ваши сервисы. ПРД должны явно определять, кому официально разрешено использовать эти ресурсы.

2.3.2 Что такое правильное использование ресурсов ?

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

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

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

Следующие моменты следует учесть при разработке правил допустимого использования:

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

Ответом на большинство этих вопросов будет "НЕТ".

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

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

• какое лицензионное и защищенное авторскими правами программное обеспечение не может копироваться за исключением случая, когда явно сказано, что вы можете делать это;
• методы доведения информации о статусе разрешения копирования программ;
• фразу "Когда у вас возникли сомнения, НЕ КОПИРУЙТЕ".

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

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

Что вам следует отразить в этой части ПРД:

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

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

Вы можете также захотеть подрядить кого-либо для оценки защищенности ваших АС, что может включать их исследование. Вы можете захотеть отразить этот момент в ваших ПРД.

2.3.3. Кто отвечает за предоставление доступа и надежное предоставление услуг?

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

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

• Будете вы управлять предоставлением доступа из одного места или дадите это право нескольким местам?

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

• Какие методы вы будете использовать для регистрации новых пользователей и прекращения доступа?

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

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

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

2.3.4. Кто может иметь привилегии системного администратора?

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

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

2.3.5. Каковы права и обязанности пользователей?

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

• каковы рекомендации в отношении использования ресурсов (ограничиваются ли пользователи в чем-либо, и если это так, то каковы эти ограничения);
• что может явиться злоупотреблением с точки зрения производительности АС;
• разрешается ли нескольким пользователям использовать одно регистрационное имя или позволять другим использовать их имена;
• как "секретным" пользователям следует хранить свои пароли;
• как часто пользователям следует менять свои пароли, а также любые другие ограничения или требования в отношении паролей;
• будете ли вы производить резервные копии, или пользователям следует самим делать свои копии;
• запрет на разглашение информации, которая может являться частной собственностью;
• пункт о безопасности электронной почты(Акт о конфиденциальности электpонных коммуникаций);
• политика в отношении электронных коммуникаций: фальсификация почты.

Ассоциация электpонной почты финансиpовала публикацию о конфиденциальности электpонной почты в компаниях[4]. Их базовой рекомендацией в отношении электронной почты является то, что каждая организация должна иметь политику по защите частной собственности своих служащих. Также рекомендуется, чтобы организации установили политику в отношении частной собственности при использовании всех сред передачи информации, а не только электронной почты.

Предлагается пять критериев для оценки любой политики:

1. Согласуется ли политика с законами и требованиями общественных организаций?
2. Пытается ли политика найти компромисс между интересами служащих, руководства организации и общественных организаций?
3. Действует ли эта политика в жизни и требуют ли ее соблюдения?
4. Касается ли эта политика различных форм взаимодействия и хранения информации, имеющих место в организации?
5. Была ли эта политика известна заранее и согласована со всеми заинтересованными лицами?

2.3.6. Каковы права и обязанности системного администратора по отношению к пользователям?

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

• может ли администратор наблюдать за состоянием файлов пользователя или читать их по какой-либо причине?
• каковы при этом его обязательства?
• имеют ли право сетевые администраторы просматривать траффик сети или СВТ?

2.3.7. Что делать с конфиденциальной информацией?

Перед тем, как предоставить пользователям доступ к вашим службам, вам нужно определить, на каком уровне вы обеспечиваете секретность данных в вашей АС. Определив это, вы определите уровень секретности данных, которые пользователи могут хранить в вашей АС. Вы не должны позволять пользователям хранить очень важную информацию в АС, которую вы не собираетесь делать очень защищенной. Вам нужно сообщить пользователям, которые могут хранить конфиденциальную информацию, о том, какие службы, если они есть, более подходят для хранения конфиденциальной информации. Эта часть должна включать хранение данных различными способами (диски, магнитные ленты, файл-серверы и т.д.). Ваши ПРД в этой области должны быть скоординированы с ПРД в отношении прав системных администраторов (смотри раздел 2.3.6).

Назад | Содержание | Вперед