Управление учётными записями пользователей и доступом к ресурсам
Глава 6. Управление учётными записями пользователей и доступом к ресурсам
Управление учётными записями пользователей и группами — важная часть работы системного администратора в организации. Но что бы делать её эффективно, хороший системный администратор должен прежде всего понимать, что такое учётные записи пользователей и группы, и как они работают.
Основное предназначение учётных записей пользователей — идентифицировать человека, использующего компьютерную систему. Второе (но также важное) предназначение учётных записей пользователей — назначение каждому человеку ресурсов и прав доступа.
Ресурсами могут быть файлы, каталоги и устройства. Управление доступом к этим ресурсам составляет большую часть будничной работы системного администратора, и часто доступ к ресурсам организуется с помощью групп. Группы — это логические конструкции, с помощью которых можно объединить учётные записи пользователей для какой-то общей цели. Например, если в организации несколько системных администраторов, всех их можно поместить в одну группу системных администраторов. Затем этой группе можно дать разрешения на доступ к ключевым ресурсам системы. Таким образом, группы могут быть мощным инструментом управления ресурсами и доступом.
Более подробно учётные записи пользователей и группы обсуждаются в следующих разделах.
6.1. Учётные записи пользователей
Как было сказано ранее, учётные записи представляют собой средства идентификации пользователей и проверки их подлинности. Учётные записи пользователей имеют несколько компонентов. Первый компонент — имя пользователя. Второй — пароль, а затем идёт информация об управлении доступом.
Эти компоненты подробно рассматриваются в следующих разделах.
6.1.1. Имя пользователя
С точки зрения системы, имя пользователя является ответом на вопрос: «Кто вы?». А значит, главное требование, связанное с именами пользователей — они должны быть уникальными. Другими словами, имя каждого пользователя должно отличаться имён всех остальных пользователей данной системы.
Вследствие этого требования, крайне важно определить на будущее, как будут выбираться имена пользователей. В противном случае вы можете оказаться в положении, когда вам придётся что-то придумывать для каждого нового пользователя, которому нужна учётная запись.
Что вам нужно, так это соглашение об именовании учётных записей ваших пользователей.
6.1.1.1. Соглашения об именовании
Выбрав для себя соглашение об именах пользователей, вы можете избежать многих проблем. Вместо того, чтобы сочинять имена, каждый раз, как они понадобятся (при этом придумать подходящее имя будет всё труднее и труднее), вы думаете об этом заранее и разрабатываете соглашение для всех создаваемых впоследствии учётных записей. Ваше соглашение об именовании может быть очень простым, а может быть его описание займёт несколько страниц.
Каким именно будет ваше соглашение об именах, должно зависеть от нескольких факторов:
размера организации
структуры организации
природы организации
Размер вашей организации имеет значение, так как он определяет, для скольких пользователей должно быть разработано ваше соглашение об именах. Например, в очень маленькой организации, возможно, все могут использовать своё имя. Но для больших организаций это соглашение об именах не подойдёт.
Структура организации также может накладывать отпечаток на соглашение об именовании. Для организаций с чётко определённой структурой, возможно, будет уместно включить в соглашение об именовании элементы этой структуры. Например, вы можете включить в имя пользователя коды отделов вашей организации.
Кроме этого, одни соглашения об именовании могут быть более подходящими, чем другие, в зависимости от общей сущности вашей организации. Организация, которая имеет дело с сильно засекреченными данными, может выбрать соглашение, не позволяющее связать имя учётной записи пользователя с его настоящим именем. В такой организации Мэгги Мак-Оми может иметь имя пользователя LUH3417.
Ниже перечислены некоторые соглашения об именовании, которые используются в обычных организациях:
Имя (robert, indiana, eva и т.д.)
Фамилия (smith, jones, brown и т. д.)
Первая буква имени и фамилия (rsmith, ijones, ebrown и т. д.)
Фамилия и код отдела (smith029, jones454, brown191 и т. д.)
 | Подсказка |
|---|---|
Если ваше соглашение об именование подразумевает сложение имени пользователя из разных частей, подумайте о том, что результат сложения может быть обидным или смешным. Поэтому, даже если вы разработали автоматический процесс создания имён пользователей, будет мудро каким-то образом просматривать имена. |
В описанных здесь соглашениях об именовании есть один общий недостаток — есть вероятность, что когда-нибудь появятся два человека, которым, следуя выбранному соглашению, нужно будет дать одинаковое имя пользователя. Это называется конфликтом имён. Так как все имена пользователей должны быть уникальны, проблему конфликта имён необходимо решить. Следующий раздел рассказывает, как это сделать.
6.1.1.1.1. Разрешение конфликта имён
Конфликты имён в жизни неизбежны — как бы вы ни пытались, рано или поздно вам придётся с ними столкнуться. Вы должны учесть это в своём соглашении об именовании. Это можно сделать разными способами:
Добавлять в конфликтующие имена последовательные номера (smith, smith1, smith2 и т.д.)
Добавлять в конфликтующие имена какие-то атрибуты пользователя (smith, rsmith, rosmith и т. д.)
Добавлять в конфликтующие имена данные организационной структуры (smith, smith029, smith454 и т.д.)
Любое соглашение об именовании обязательно должно описывать порядок разрешения конфликтов. Однако для людей извне организации это сильно затрудняет точное определение имени пользователя. Поэтому недостатком большинства соглашений об именовании является возможность ошибки в имени получателя почты.
6.1.1.2. Процедура изменения имени
Если в вашей организации применяется соглашение об именовании, основанное на имени пользователей, вам неизбежно придётся столкнуться с необходимостью изменить имя. Даже если не меняется настоящее имя человека, время от времени требуется внести изменения в имя пользователя. Причины могут быть самыми разными: пользователю не нравится имя его учётной записи, или он занимает высокое положение в вашей организации и, используя его, желает получить «подобающее» имя пользователя.
Какова бы ни была причина, изменяя имя пользователя нужно помнить о нескольких моментах:
Внести изменения на всех затронутых системах
Сохранить идентификаторы пользователя на нижнем уровне без изменений
Сменить владение всеми файлами или другими ресурсами пользователя (если это необходимо)
Решить проблемы, связанные с электронной почтой.
Первое и самое главное, важно распространить изменения имени на все системы, в которых до этого использовалось старое имя. В противном случае, функции операционной системы, зависящие от имени пользователя, могут в одних системах работать, а в других — нет. В некоторых операционных системах средства управления доступом привязаны к именам пользователей, в таких системах проблемы, связанные с изменением имени, особенно актуальны.
Во многих операционных системах в большинстве функций, связанных с пользователями, используется некоторый код, идентифицирующий пользователя. Чтобы сократить число проблем, вызванных изменением имени пользователя, старайтесь сохранить идентификационный код от старого имени пользователя. Если код не сохраняется, часто возникает ситуация, когда пользователь больше не может обращаться к файлам и другим ресурсам, которыми он владел до этого с прежним именем пользователя.
Если избежать смены кода пользователя нельзя, необходимо также обновить данные владения для всех файлов и других ресурсов пользователя, чтобы на них отразилось это изменение. Выполнить это без ошибок сложно, потому что всегда в каком-нибудь забытом углу системы что-то остаётся без внимания.
Пожалуй, сложнее всего поменять имя, когда это касается электронной почты. Это объясняется тем, что если не были предприняты специальные меры, почта, отправленная по старому имени пользователя, не будет доставлена по новому имени.
К сожалению, проблемы, связанные с изменением имени пользователя, в контексте электронной почте приобретают многоплановый характер. По сути, изменение имени пользователя означает, что люди больше не будут знать правильное имя пользователя этого человека. На первый взгляд, это не кажется большой проблемой — нужно всего лишь сообщить об изменении всем сотрудникам вашей организации. Но как быть с теми, кто посылает этому человеку почту, но не работает в вашей организации? Как сообщить об изменении? И что делать со списками рассылки (внутренними и внешними)? Как обновить их?
Простого ответа на эти вопросы нет. Возможно, лучше всего будет создать псевдоним почтового ящика, чтобы вся почта, отправляемая по старому имени, автоматически перенаправлялась в ящик с новым именем. Затем можно попросить пользователя сообщить об изменении имени всем, с кем он ведёт переписку. Со временем по адресу псевдонима будет приходить всё меньше и меньше писем, и в конце концов этот псевдоним можно будет удалить.
Хотя псевдонимы, в некоторой степени, увековечивают неверное предположение (что пользователь, сейчас известный под именем esmith, по-прежнему известен под именем ejones) — это единственный способ гарантировать, что почта будет доходить до нужного человека.
 | Важно |
|---|---|
Если вы используете псевдонимы, обязательно примите все меры для предотвращения повторного использования старых имён пользователей. Если вы этого не сделаете, и новый пользователь получит старое имя другого, доставка почты (и первоначального владельца имени, и нового) может быть нарушена. Как именно это будет выражаться, зависит от того, как в вашей операционной системе реализована доставка почты, но наиболее вероятны два варианта:
|
6.1.2. Пароли
Если имя пользователя даёт ответ на вопрос: «Кто вы?», пароль — ответ на неизбежно следующее за этим требованием:
«Докажите это!»
Говоря более формально, пароль даёт возможность подтвердить подлинность человека, заявляющего, что он является пользователем с заданным именем. Эффективность схемы проверки подлинности по паролю зависит от нескольких свойств пароля:
Секретность пароля
Устойчивость пароля к угадыванию
Устойчивость пароль к атаке перебором
Пароли, обладающие всеми этими свойствами, называются сильными, а не обладающие одним из этих свойств — слабыми. Создание сильных паролей имеет большое значение для безопасности организации, так как узнать или угадать сильный пароль гораздо сложнее. Обеспечить использование только сильных паролей можно двумя способами:
Системный администратор может сам назначать пароли всем пользователям.
Системный администратор может разрешить пользователям задавать пароли самостоятельно, но проверять, достаточно ли сильны эти пароли.
Назначение паролей для всех пользователей гарантирует, что пароли будут сильными, но это становится непосильной задачей по мере роста организации. При этом также увеличивается опасность того, что пользователи начнут записывать свои пароли.
Поэтому многие системные администраторы предпочитают, чтобы пользователи назначали себе пароли сами. Тем не менее, хороший системный администратор принимает меры для проверки, насколько сильны пароли.
За указаниями по назначению сильных паролей обратитесь к главе Безопасность рабочей станции в Руководстве по безопасности Red Hat Enterprise Linux.
Каждый системный администратор должен в полной мере осознавать необходимость сохранения паролей в секрете. Однако об этом совершенно не думают многие пользователи. На самом деле, многие пользователи вообще не видят различий между именами пользователей и паролями. Учитывая этот печальный факт, важно провести с пользователями разъяснительную работу, чтобы пользователи понимали, что пароль нужно хранить в секрете, так же, как и банковскую карту.
Пароли должны быть сложны, чтобы угадать их было невозможно. Сильным паролем считается пароль, угадать который злоумышленник не сможет, даже если он хорошо знает пользователя.
Атака на пароль методом перебора подразумевает систематический перебор (обычно с помощью программы, называемой взломщиком паролей) всех возможных комбинаций символов в надежде на то, что в конце концов нужный пароль будет найден. Сильный пароль должен быть образован таким образом, чтобы число потенциальных паролей, которые требовалось бы проверить, было очень большим, и на поиск пароля уходило бы очень много времени.
Сильные и слабые пароли рассматриваются подробнее в следующих разделах.
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.2. Ограниченный набор символов
Число различных символов, которые могут составлять пароль, в значительной мере влияет на возможность успешного проведения атаки перебором. Например, что будет, если к 26 разным буквам в нижнем регистре, которые мы могли использовать в пароле, мы добавим ещё и цифры? Это будет означать, что каждый символ в пароле может выбираться не из 26, а из 36 символов. В случае с паролем из шести символов, это увеличивает число возможных паролей с 308 915 776 до 2 176 782 336.
Но и это ещё не всё. Если мы рассмотрим алфавитно-цифровые пароли смешанного регистра (для тех операционных систем, которые это поддерживают), число возможных паролей из шести символов вырастет до 56 800 235 584. Добавление других символов (например, знаков препинания) ещё больше увеличивает число возможных паролей, что многократно усложняют атаку перебором.
Однако, надо помнить о том, что атака перебором — не единственный вид атаки для получения пароля. Следующие разделы рассказывают о других вариантах слабых паролей.
6.1.2.1.3. Известные слова
Многие атаки на пароли основаны на том факте, что людям больше всего нравятся пароли, которые они могут вспомнить. И для большинства людей запоминаемые пароли — те, что содержат слова. Поэтому большинство атака выполняется с применением словаря. Другими словами, взломщик использует списки слов, пытаясь найти слово или набор слов, составляющих пароль.
 | Замечание |
|---|---|
Многие программы перебора пароля по словарю используют словари разных языков. Поэтому, не стоит считать, что у вас сильный пароль, только потому что он содержит не английские слова. |
6.1.2.1.4. Личные сведения
Пароли, содержащие личные сведения (имя или день рождения любимой, имя своего питомца или личный номер), возможно, и не будут раскрыты с помощью атаки по словарю. Однако, если злоумышленник знает вас лично (или настолько заинтересован в пароле, что изучил вашу личную жизнь), он сможет угадать ваш пароль практически без труда.
Помимо словарей, многие программы для взлома паролей также перебирают распространённые имена, даты и другие подобные сведения. Поэтому, даже если взломщик не знает, что вашу собаку зовут Gracie, с помощью хорошей программы взлома паролей они смогут узнать, что ваш пароль «mydogisgracie».
6.1.2.1.5. Простые фокусы со словами
Использование в качестве основы для пароля каких-то из упомянутых выше сведений, но с перестановкой символов наоборот, не сделать слабый пароль сильным. Большинство программ взлома пароля делают такие же фокусы с возможными паролями. В число таких фокусов входит замена определённых букв цифрами в распространённых словах. Вот некоторые примеры:
drowssaPdaB1
R3allyP00r
6.1.2.1.6. Один пароль в разных системах
Даже если у вас есть сильный пароль, использовать его в нескольких системах — плохая идея. Очевидно, что это вряд ли возможно, если все системы используют центральный сервер проверки подлинности, но в остальных случаях во всех системах следует использовать разные пароли.
6.1.2.1.7. Пароли, записанные на бумаге
Ещё один способ сделать сильный пароль слабым — записать его на бумаге. Если вы запишите его на бумаге, у вас больше не будет проблемы секретности, у вас будет проблема безопасности — теперь вы должны хранить этот листок бумаги в безопасном месте. Следовательно, записывать пароли на бумаге — очень плохая идея.
Однако в некоторых организациях правила требует записывать пароли. Например, некоторые организации хранят записанные пароли на случай потери ключевых сотрудников (например, системных администраторов). В таких случаях бумага с паролями хранится в физически защищённом месте, попасть в которое смогут только несколько определённых человек вместе. Часто для этого используются камеры хранения с несколькими замками и депозитные ящики в банке.
Любая организация, хранящая таким образом пароли на случай аварийной ситуации, должны понимать, что существование записанных на бумаге пароле привносит элемент риска в безопасности их систем, вне зависимости от того, насколько безопасно хранятся записанные пароли. Это особенно справедливо, когда хорошо известно, что пароли записываются на бумаге (и где они хранятся).
К сожалению, довольно часто встречаются записанные пароли, которые не входят в план восстановления и не хранятся в сейфах — это пароли обычных пользователей, которые хранятся в следующих местах:
В ящике письменного стола (закрывающемся или нет)
Под клавиатурой
В бумажнике
На бумаге, приклеенной сбоку к монитору.
Ни одно из этих мест совершенно не годится для записанного пароля.
6.1.2.2. Сильные пароли
Мы увидели, какие пароли являются слабыми, в следующих разделах обсуждаются свойства, которые характерны для всех сильных паролей.
6.1.2.2.1. Длинные пароли
Чем длиннее пароли, тем меньше вероятность того, что атака перебором закончится успешно. Поэтому если это поддерживает ваша операционная система, назначьте для своих пользователей довольно большую минимально допустимую длину пароля.
6.1.2.2.2. Расширенный набор символов
Постарайтесь добиться использования алфавитно-цифровых паролей со смешанным регистром, и настоятельно требуйте включать во все пароли как минимум один не алфавитно-цифровой символ:
t1Te-Bf,te
Lb@lbhom
6.1.2.2.3. Запоминаемые пароли
Пароль является сильным, только если его можно запомнить. Однако обычно запоминаемый пароль и легко угадываемый — почти синонимы. Поэтому дайте своим пользователям несколько советов, как следуют выбирать запоминаемые пароли, угадать которые будет не так просто.
Например, можно взять любимое изречение или какую-то фразу, и выбрать первые буквы каждого слова как основу для нового пароля. Результат будет запоминаемым (потому что фраза, из которой он получен, сама запоминаемая), но при этом он не будет содержать слов.
| Замечание |
|---|---|
Учтите, что если только взять первые буквы всех слов фразы, сильный пароль не получится. Всегда обязательно расширяйте набор символов пароля, добавляя алфавитно-цифровые символы и как минимум один специальный символ. |
6.1.2.3. Срок действия пароля
Если это вообще возможно, внедрите в своей организации ограничение срока действия пароля. Возможность ограничивать срок действия пароля (имеющаяся во многих операционных системах) накладывает ограничения на время, в течение которого пароль считается верным. В конце срока жизни пароля пользователю предлагается ввести новый пароль, который затем может быть использоваться, пока срок его жизни тоже не закончится.
Главный вопрос по поводу срока действия пароля, который встаёт перед многими системными администраторами, это вопрос выбора этого срока. Какими он должен быть?
При выборе срока жизни пароля есть два диаметрально противоположных направления:
Удобство пользователя
Безопасность
В одной крайней точке — при сроке действия пароля 99 лет у пользователя будет очень мало неудобств (если они вообще будут). Однако это также почти не улучшит безопасность (если вообще улучшит).
В другой крайней точке — при сроке действия пароля 99 минут пользователи испытают большие неудобства. Однако безопасность будет значительно улучшена.
Поэтому нужно найти баланс между интересами ваших пользователей, которым нужно удобство, и вашей организации, которой нужна безопасность. В большинстве организаций чаще всего используется срок жизни паролей, измеряемый неделями или месяцами.
6.1.3. Информация об управлении доступом
Помимо имени и пароля пользователя, учётные записи также содержат информации об управлении доступом. Эта информация принимает разные формы в зависимости от используемой операционной системы. Но чаще всего это следующая информация:
Информация уровня системы о пользователе
Информация уровня системы о группах
Список дополнительных групп/сущностей, членом которых является пользователь
Информация о доступе по умолчанию, применяемая ко всем создаваемым пользователем файлам и ресурсам.
В некоторых организациях, информация об управлении доступом может никогда не меняться. Чаще всего это имеет место на отдельных, личных рабочих станциях. В других же организациях, особенно в тех, где различные группы пользователей интенсивно используют общий доступ к сетевым ресурсам, информация об управлении доступом меняется очень часто.
Нагрузка, необходимая для поддержания информации об управлении доступом ваших пользователей, зависит от того, насколько интенсивно в вашей организации используются возможности управления доступом вашей операционной системы. Хотя использовать эти возможности вовсе не плохо (и на самом деле это может быть обязательно), это значит, что окружение вашей системы может потребовать больше усилий для поддержки и появится больше способов ошибиться в настройках каждой учётной записи.
Поэтому, если это необходимо в вашей организации, вы должны придать большое значение точному описанию действий, необходимых для создания и правильной настройки учётной записи. На самом деле, если существует несколько типов учётных записей пользователей, вы должны документировать каждую (создание новой учётной записи для нового пользователя финансового отдела, операционного отдела и т. д.).
6.1.4. Повседневное управление учётными записями и доступом к ресурсам
Как говорит старая мудрость, «Постоянны только изменения». И это также касается сообщества ваших пользователей. Одни люди приходят, другие уходят, а третьи переходят с одной должности на другую. Поэтому системные администраторы должны быть способны реагировать на изменения, которые являются обычными явлениями в повседневной работе вашей организации.
6.1.4.1. Новые сотрудники
Когда в организацию приходит новый человек, обычно ему разрешается доступ к различным ресурсам (в зависимости от его должности). Ему может быть выделено рабочее место, телефон и ключ от входной двери.
Ему также может быть разрешён доступ к одному или нескольким компьютерам в вашей организации. Ваша задача, как системного администратора, проконтролировать, что всё сделано правильно и своевременно. Как же решить эту задачу?
Прежде чем вы что-нибудь сделаете, вас должны уведомить о приходе нового сотрудника. В разных организациях это делается по-разному. Например, возможны следующие варианты:
Разработать процедуру, согласно которой о приходе нового сотрудника вас уведомляет отдел кадров вашей организации.
Создать форму, которую будет заполнить начальник этого сотрудника и передавать вам для создания учётной записи.
Разным организациям нужны разные подходы. Как бы это ни было организовано, крайне важно, чтобы у вас был чёткий порядок уведомлений о необходимости выполнения любых действий, связанных с учётными записями.
6.1.4.2. Прекращение работы
Уход людей из организации — неизбежное явление. Иногда это происходит при благоприятных обстоятельствах, а иногда — нет. В любом случае важно, чтобы вы предусмотрели эту ситуацию и могли предпринять соответствующие действия.
По меньшей мере, это должны быть следующие действия:
Запрет доступа пользователей ко всем системам и связанным ресурсам (обычно для этого меняется или блокируется пароль пользователя)
Копирование в архив файлов пользователя, если они содержат что-то, что может понадобится позже
Координация доступа к файлам начальником пользователя
Самое главное — защитить ваши системы от пользователя, прекратившего работу. Это особенно важно, если пользователь покинул организацию при таких обстоятельствах, при которых у него могло остаться недоброжелательное отношение к вашей организации. Но даже если обстоятельства более благоприятные, в интересах вашей организации, чтобы вы быстро и надёжно запретили доступ пользователю, прекратившему работу.
Это показывает, что вас должны уведомлять обо всех подобных событиях, и предпочтительнее до того, как сотрудник прекратит работу фактически. Чтобы получать информацию о предстоящих увольнениях заранее, вам следует сотрудничать с отделом кадров вашей организации.
| Подсказка |
|---|---|
Блокирование системы в ответ на уход сотрудника важно выполнять своевременно. Если система будет заблокирована после того, как процесс увольнения будет закончен полностью, существует вероятность того, что ушедший сотрудник сможет получить неавторизованный доступ. С другой стороны, если заблокировать систему до того, как начнётся процесс увольнения, этот сотрудник может воспринять это как признак грядущего увольнения, что усложнит этот процесс для всех сторон. Процесс увольнения обычно начинается на встрече увольняемого сотрудника, его начальника и представителя отдела кадров. Таким образом, если вы будете уведомлены о начале этой встрече, это время будет наиболее подходящим для блокировки. |
После того, как вы запретите доступ, сделайте копию файлов сотрудника, покидающего организацию. Эта копия может быть сделана в рамках стандартного резервного копирования, или в рамках специальной процедуры копирования в архив данных старых учётных записей. В определении наиболее подходящего способа выполнения резервной копии играют роль разные факторы, в частности, регламент сохранения данных, требования сохранения доказательств на случай судебных разбирательств и т. д.
В любом случае на данном этапе рекомендуется сделать резёрвную копию, так как на следующем этапе (предоставление начальнику доступа к файлам ушедшего сотрудника) они могут быть случайно удалены. В таких обстоятельствах, имея текущую копию, можно легко восстановить данные, что упрощает этот процесс и для начальника, и для вас.
Теперь вы должны определить, какой доступ к файлам ушедшего сотрудника нужен его начальнику. В зависимости от вашей организации и рода занятий ушедшего сотрудника, возможно, доступ не следует открывать вовсе, или, наоборот, разрешить доступ ко всему, что потребуется начальнику.
Если этот человек не только от случая к случаю пользовался почтой, скорее всего его начальнику придётся отсортировать файлы и определить, что следует оставить, а что может быть удалено. По завершению этого процесса как минимум некоторые файлы можно будет передать сотруднику или сотрудникам, которым перешли обязанности ушедшего сотрудника. Возможно, на этом, последнем этапе всего процесса потребуется ваша помощь, или начальник сможет справиться с этим сам. Это зависит от файлов и сущности работы, которую выполняет ваша организация.
6.1.4.3. Переход на другую должность
Удовлетворение запросов на создание учётных записей для новых пользователей и отработка последовательности событий для блокировки учётной записи при уходе сотрудника — достаточно простые процессы. Однако всё не так однозначно, когда сотрудник организации переходит на другую должность. Иногда при этом может потребоваться внести изменения в учётную запись, а иногда нет.
Есть как минимум три человека, которые должны обеспечить подходящую перенастройку учётную записи в соответствии с новой должностью:
Вы
Предыдущий начальник пользователя
Новый начальник пользователя
Между собой вы должны определить, что нужно сделать, чтобы полностью закрыть старые задачи пользователя, и что нужно сделать, чтобы подготовить учётную запись пользователю к новому кругу задач. Во многих отношениях этот процесс можно представить как отключение существующей учётной записи пользователя и создание новой. На самом деле в некоторых организациях именно так и происходят переводы сотрудников с одной должности на другую.
Однако, скорее всего, учётная запись пользователя будет сохранена и изменена в соответствии с его новым кругом задач. Этот подход означает, что вы должны внимательно проверить учётную запись, чтобы убедиться в том, что ему доступны только те ресурсы и назначены только те привилегии, что необходимы для новых задач.
Ещё больше усложняет эту ситуацию тот факт, что часто в процессе перехода пользователь временно выполняет задачи, связанные с обеими должностями. Здесь вы можете обратиться к предыдущему и новому начальникам, чтобы они определили длительность этого переходного периода.