Интеллектуальные компьютерные технологии защиты информации

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

Для регламентации доступа к ресурсам нужно дать ответы на следующие вопросы:

• Разрешается ли использование чужих ресурсов?

• Разрешается ли отгадывать чужие пароли?

• Разрешается ли разру

шать сервисы?

• Должны ли пользователи предполагать, что если файл доступен всем на чтение, то они имеютправо его читать?

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

• Должны ли пользователи разделять ресурсы?

В большинстве случаев ответы на подобные вопросы должны быть отрицательными.

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

Более точно, вы должны довести до сведения пользователей, что:

• копировать авторское и лицензионное программное обеспечение запрещено, за исключением явнооговоренных случаев;

• они всегда могут узнать авторский/лицензионный статус программного обеспечения;

• в случае сомнений копировать не следует.

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

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

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

• Разрешены ли вообще подобные исследования?

• Что именно разрешено: попытки проникновения, создание и/или запуск червей и вирусов и т.п.?

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

• Как защищены пользователи (в том числе внешние) от подобных исследований?

• Как получать разрешение на проведение исследований?

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

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

1.2.3.3 Кто наделен правом давать привилегии и разрешать использование?

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

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

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

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

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

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

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

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

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

 Скачать реферат