6.1.1.1. Соглашения об именовании

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

Каким именно будет ваше соглашение об именах, должно зависеть от нескольких факторов:

• размера организации

• структуры организации

• природы организации

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

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

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

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

• Имя (robert, indiana, eva и т.д.)

• Фамилия (smith, jones, brown и т. д.)

• Первая буква имени и фамилия (rsmith, ijones, ebrown и т. д.)

• Фамилия и код отдела (smith029, jones454, brown191 и т. д.)

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

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

6.1.1.2. Процедура изменения имени

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

Какова бы ни была причина, изменяя имя пользователя нужно помнить о нескольких моментах:

• Внести изменения на всех затронутых системах

• Сохранить идентификаторы пользователя на нижнем уровне без изменений

• Сменить владение всеми файлами или другими ресурсами пользователя (если это необходимо)

• Решить проблемы, связанные с электронной почтой.

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

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

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

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

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

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

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

Важно

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

6.1.2.1. Сильные пароли

Как было сказано ранее, слабый пароль не проходит одной из следующих проверок:

• Он секретный

• Он устойчив к угадыванию

• Он устойчив к атаке перебором.

Следующие разделы показывают, что делает пароли слабыми.

6.1.2.1.1. Короткие пароли

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

Длина пароля	Вариантов паролей
1	26
2	676
3	17 576
4	456 976
5	11 881 376
6	308 915 776

Таблица 6-1. Длина пароля и число вариантов паролей

Как вы видите, число вариантов паролей резко увеличивается с увеличением длины пароля.

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

6.1.2.1.3. Известные слова

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

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

6.1.2.2. Сильные пароли

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

6.1.2.2.3. Запоминаемые пароли

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

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

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

6.1.2.3. Срок действия пароля

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

Главный вопрос по поводу срока действия пароля, который встаёт перед многими системными администраторами, это вопрос выбора этого срока. Какими он должен быть?

При выборе срока жизни пароля есть два диаметрально противоположных направления:

• Удобство пользователя

• Безопасность

В одной крайней точке — при сроке действия пароля 99 лет у пользователя будет очень мало неудобств (если они вообще будут). Однако это также почти не улучшит безопасность (если вообще улучшит).

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

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

6.1.4.1. Новые сотрудники

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

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

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

• Разработать процедуру, согласно которой о приходе нового сотрудника вас уведомляет отдел кадров вашей организации.

• Создать форму, которую будет заполнить начальник этого сотрудника и передавать вам для создания учётной записи.

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

6.1.4.2. Прекращение работы

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

По меньшей мере, это должны быть следующие действия:

• Запрет доступа пользователей ко всем системам и связанным ресурсам (обычно для этого меняется или блокируется пароль пользователя)

• Копирование в архив файлов пользователя, если они содержат что-то, что может понадобится позже

• Координация доступа к файлам начальником пользователя

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

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

Подсказка

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

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

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

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

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

6.1.4.3. Переход на другую должность

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

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

• Вы

• Предыдущий начальник пользователя

• Новый начальник пользователя

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

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

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