Определение допустимого количества попыток регистрации.

Надежное хранение такой информации, как идентификатор пользователя и пароль.

Закрепление за каждым отдельным лицом одной учетной записи и одного пароля

Автора до сих пор не перестает шокировать такая ситуация, что в любой организации, где бы ему ни приходилось бывать, почти всегда имеется по крайней мере один глобальный пользователь - некоторая учетная запись для доступа к сети или конкретному приложению, идентификатор и пароль которой обычно известен почти каждому сотруднику отдела, а то и всей компании. Часто этому глобальному пользователю предоставляется буквально карт-бланш (иными словами, полный доступ). Что же касается СУБД SQL Server, то стала почти привычной ситуация, в которой после инсталляции никто не затрудняет себя тем, чтобы заменить пароль пользователя sa чем-то другим, кроме пустого пароля. А это действительно может повлечь за собой весьма неприятные последствия.

До выхода версии SQL Server 2000 по умолчанию для учетной записи sa пароль не быя задан; иными словами, он отсутствовал. К счастью, с выходом версии SQL Server 2000 не только было изменено это заданное по умолчанию значение, но и предусмотрен вывод программным обеспечением SQL Server сообщения о том, что применение пустого пароля является недопустимым; благодаря этому усилия коллектива разработчиков по распространению надлежащей культуры безопасности немного облегчаются. Единственное, о чем при этом следует помнить, - это о том, что в процессе разработки все же приходится задавать достаточно упрощенный пароль, поскольку в период разработки регистрация администратора в базе данных должна производиться слишком часто. Тем не менее перед передачей разработанной прикладной системы на производство следует обязательно заменить упрощенный пароль чем-то более сложным; кроме того, иногда сложный пароль приходится задавать с самого начала, если сервер, применяемый при разработке, доступен непосредственно через Интернет или если для доступа к нему используется какой-то другой способ, не заслуживающий доверия.

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

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

подключения будут использоваться собственные учетные записи, а не какая-то глобальная , известная всем учетная запись).

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

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

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

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

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

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

Истечение срока действия пароля

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

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

В версии SQL Server 2005 появилась даже возможность предписывать правила безопасности Windows непосредственно для паролей, применяемых в СУБД SQL Server. Еще один вариант состоит в том, что можно использовать средства обеспечения безопасности, предусмотренные в операционной системе Windows (дополнительная информация на эту тему приведена в следующем разделе).

Обоснование необходимости использования средств регламентации срока действия пароля

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