Смекни!
smekni.com

Методические рекомендации по обеспечению санкционированного участия в программах дистанционного обучения Начальник производства (стр. 3 из 7)

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

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

3.1.3 Атаки на фиксированные пароли

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

1) путем просмотра при введении с клавиатуры;

2) путем получения документов, содержащих эти пароли;

3) путем перехвата их из каналов связи, используемых пользователем для связи с системой, или из самой системы при использовании паролей в открытом виде.

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

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

Вместо тотального перебора всех возможных паролей противник может прибегнуть к их перебору в порядке убывания вероятности их использования. Этот метод — т.н. «атака с помощью словаря» — обычно эффективен в том случае, когда пароли выбираются пользователем и, как правило, являются не равновероятными. Обычные словари, как правило, содержат не более 150 тыс. слов, что намного меньше числа всех всего лишь 6-буквенных паролей.

3.1.4 «Запрос-ответ» (сильная аутентификация)

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

3.2 Авторизация

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

Авторизация — это проверка, в процессе которой выясняется круг доступных аутентифицированному участнику ресурсов и предоставляется доступ к ним. Как правило, права разных участников безопасности на доступ к ресурсу различается.

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

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

Если программой пользуется большое количество пользователей, то назначать права каждому пользователю становится неудобно. Тогда вводят понятие «группа пользователей». Сначала пользователей объединяют в группы (например, на территориальной основе, по возрастному признаку, совершеннолетние — несовершеннолетние), причем группа может быть включена в другие группы, а затем определяются права для групп. При этом при добавлении нового пользователя в систему вместо назначения ему прав достаточно просто добавить пользователя в нужную группу. Пользователи и группы в общем случае связаны отношением «многие ко многим». При этом иногда возникает потребность запретить какое-либо право отдельному пользователю группы. Кроме того, права могут назначаться как группам, так и отдельным пользователям. Для этого потребуется структура, представленная на рисунке 1.

Рисунок 1. Модель с использованием групп.

Если у программы много функций, которые удобно логически сгруппировать, то вводят понятие роль — набор функций, необходимых для выполнения некоторой работы.

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

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

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

Рисунок 2. Ролевая модель с возможностью назначения индивидуальных прав.

Рисунок 3. Ролевая модель без возможности назначения индивидуальных прав.

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

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

В итоге получается тетраэдр, в вершинах которого находятся пользователи, группы, роли и права, а на ребрах — таблицы для моделирования отношения «многие ко многим» (рисунок 4).

Рисунок 4. Модель с ролями и группами.

3.3 Аудит

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

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

4 Существующие модели защиты

Современное программное обеспечение позволяет осуществлять контроль доступа к информационным объектам как средствами операционной системы (ОС), так и средствами систем управления базами данных (СУБД). Рассмотрим модели защиты, применяемые в ОС и СУБД более подробно.