Один логин на всех: почему общие учётные записи опасны для компании

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

Создаётся один логин, пароль передают нескольким людям — и кажется, что вопрос решён.

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

Почему общие учётные записи вообще появляются

Обычно причина не связана с намеренным нарушением безопасности.

Такая схема появляется постепенно.

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

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

Иногда общий логин создаётся для простоты:

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

Но удобство администратора в момент настройки потом превращается в проблему при любом инциденте.

Главная проблема — потеря персональной ответственности

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

Если используется общий логин, такой связи уже нет.

Допустим, в общей папке был удалён важный файл.

Журнал показывает, что действие выполнил пользователь office. Но под этим логином работают четыре сотрудника.

Технически система зафиксировала событие. Практически расследование упирается в вопрос: кто именно работал в этот момент?

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

Один логин делает аудит значительно слабее

Журналирование имеет смысл только тогда, когда событие можно связать с конкретным субъектом.

Например, Windows Security может фиксировать входы, изменение групп, работу с файлами и другие события.

Но если одна учётная запись принадлежит сразу нескольким людям, точность такого аудита резко снижается.

Это касается не только Windows.

Та же проблема возникает в:

• 1С;
• CRM;
• корпоративной почте;
• сетевых папках;
• VPN;
• RDP;
• облачных сервисах;
• административных панелях;
• системах видеонаблюдения и СКУД.

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

Особенно плохо это работает при RDP

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

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

Но если несколько сотрудников используют один и тот же логин, полезность этой информации резко снижается.

Мы подробно разбирали архитектуру удалённой работы в статье «RDP, AnyDesk и Radmin: как безопасно организовать удалённый доступ» .

Общий пароль быстро перестаёт быть секретом

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

У общей учётной записи пароль знают все, кому когда-либо понадобился доступ.

Со временем список таких людей может стать неизвестен даже администратору.

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

Через год никто уже не помнит, кому именно его сообщали.

Фактически такой пароль перестаёт выполнять функцию индивидуального секрета.

Что происходит при увольнении сотрудника

С персональной учётной записью всё относительно просто: сотрудник увольняется — его аккаунт блокируется.

При общем логине ситуация сложнее.

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

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

На практике это часто откладывают.

В результате бывший сотрудник теоретически может продолжать знать действующие реквизиты доступа.

Та же проблема возникает при смене подрядчика

Общие учётные записи часто используются не только сотрудниками, но и внешними специалистами.

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

Через несколько лет становится сложно понять, кто всё ещё знает пароль.

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

Это касается не только Windows, но и VPN, роутеров, NAS, хостинга, камер, AnyDesk и других систем.

Общий пользователь и административные права — особенно плохое сочетание

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

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

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

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

О рисках постоянных административных прав мы отдельно писали в статье «Локальный администратор на рабочем компьютере: почему это опасно и когда права действительно нужны» .

Один логин на нескольких компьютерах — другая, но похожая проблема

Стоит разделять две ситуации.

Первая — несколько людей используют одну учётную запись.

Вторая — один человек использует свою учётную запись на нескольких устройствах.

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

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

Общие учётные записи в 1С

Для корпоративных систем индивидуальные логины также важны.

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

При этом фактически действия выполняли разные люди.

Это особенно неудобно, когда необходимо разобраться:

• кто изменил документ;
• кто провёл операцию;
• кто изменил реквизиты;
• кто удалил или скорректировал данные;
• кто работал в системе в конкретное время.

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

Общие сетевые папки и доступ к файлам

Похожая ситуация возникает при доступе к сетевым ресурсам.

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

При включённом файловом аудите событие изменения или удаления файла будет связано именно с ней.

То есть журнал может показать:

User: shared_user
Action: Delete
File: report.xlsx

Но если под shared_user работало десять человек, этого недостаточно для уверенного определения автора действия.

Можно ли определить человека только по IP-адресу

Иногда персональные логины пытаются заменить анализом IP-адресов.

Это полезный дополнительный источник информации, но не полноценная замена.

IP может помочь определить устройство, с которого выполнялось подключение.

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

Поэтому надёжнее сопоставлять несколько признаков:

• персональную учётную запись;
• время события;
• IP-адрес;
• имя компьютера;
• тип входа;
• связанные события журнала.

Персональный логин не означает, что пароль можно передавать другому человеку

Иногда формально учётные записи отдельные, но сотрудники всё равно знают пароли друг друга.

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

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

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

MFA дополнительно усиливает персональную идентификацию

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

Особенно это важно для:

• корпоративной почты;
• VPN;
• облачных сервисов;
• административных панелей;
• критичных корпоративных систем.

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

Что делать со служебными аккаунтами

Не каждую общую учётную запись нужно автоматически считать ошибкой.

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

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

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

Как перейти от общего логина к персональным учётным записям

Для небольшой компании переход обычно не требует сложного проекта.

1. Найти общие учётные записи. Проверить Windows, RDP, VPN, 1С, сетевые папки и основные облачные сервисы.
2. Определить реальных пользователей. Понять, кто сейчас работает под каждым общим логином.
3. Создать персональные аккаунты. Каждому сотруднику предоставить собственную учётную запись.
4. Перенести права. Выдать сотрудникам только необходимый доступ к папкам, программам и системам.
5. Проверить работу. Убедиться, что бизнес-процессы работают под новыми аккаунтами.
6. Отключить общий логин. Не оставлять его «на всякий случай», если он больше не нужен.
7. Сменить старые пароли. Особенно если общие реквизиты использовались для административных или удалённых подключений.

Что проверить прямо сейчас

Персональные учётные записи упрощают расследование

Когда происходит инцидент, важен не только сам факт события.

Необходимо восстановить последовательность действий:

Чем лучше разделены пользователи, тем точнее можно восстановить эту цепочку.

Общий логин фактически уничтожает первый элемент — «кто».

А без него остальные журналы становятся заметно менее информативными.

Журнал должен храниться достаточно долго

Даже при персональных учётных записях аудит не поможет, если нужные события уже перезаписаны.

Например, журнал Security Windows может иметь слишком маленький максимальный размер и сохранять только короткий период истории.

Для оценки можно использовать наш калькулятор глубины журнала Windows Security .

Он помогает примерно оценить, сколько дней истории помещается в журнал при текущем объёме событий.

Персональный доступ — часть общей модели безопасности

Индивидуальные учётные записи не решают все проблемы информационной безопасности.

Они должны работать вместе с другими мерами:

• минимально необходимыми правами;
• MFA;
• контролем удалённого доступа;
• журналированием;
• регулярным обновлением систем;
• антивирусной защитой;
• резервным копированием;
• обучением сотрудников.

Но именно персональная учётная запись создаёт основу для нормального управления доступом и аудита.

С чего начать

Для небольшой организации первый шаг прост: выписать основные системы и проверить, не используются ли где-нибудь общие логины.

Начать стоит с критичных точек:

• Windows Server;
• RDP;
• 1С;
• VPN;
• сетевые папки;
• почта;
• облачные хранилища;
• административные панели.

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

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

WEB-LABS проводит техническое обследование IT-инфраструктуры , в рамках которого можно проверить учётные записи, административные права, RDP, сетевые ресурсы, журналы Windows и другие параметры, влияющие на контроль действий пользователей.