Разграничение доступа к серверу с персональными данными по 152-ФЗ

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

Зачем вообще разграничивать доступ, если данные и так на защищённом сервере?

Шифрование, антивирус и физическая охрана сервера защищают от внешних атак, но не от внутренних рисков. Большая часть утечек персональных данных происходит не из-за хакеров, а из-за того, что доступ к базе есть у сотрудников, которым он объективно не нужен: бухгалтер видит данные клиентов отдела продаж, стажёр — базу договоров, уволенный сотрудник — доступ так и не отозвали. Разграничение доступа снижает эту площадь риска до минимума.

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

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

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

Что такое матрица доступа и зачем она нужна на практике?

Матрица доступа — это таблица, где по одной оси перечислены сотрудники или роли (менеджер, бухгалтер, администратор), а по другой — информационные системы и типы данных. На пересечении указывается уровень доступа: чтение, редактирование, полный доступ или доступ отсутствует. Это простой и наглядный инструмент, который решает сразу три задачи:

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

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

Как разграничение доступа выглядит технически, на уровне сервера?

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

• индивидуальные логины и пароли для каждого сотрудника — общий доступ по одному паролю недопустим;
• двухфакторная аутентификация для доступа к критичным системам;
• ограничение доступа по IP-адресам или VPN, чтобы подключаться к серверу можно было только из корпоративной сети;
• автоматическая блокировка учётной записи при увольнении сотрудника.

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

А что делать с системными администраторами и ИТ-подрядчиками — у них же доступ ко всему?

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

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

Нужно ли фиксировать, кто и когда заходил в систему?

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

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

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

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

Интересный факт: сам закон «О персональных данных» действует в России уже двадцать лет — он был принят в 2006 году, и с тех пор требования к защите данных только ужесточались, в том числе в части контроля доступа внутри организаций.

Как упростить настройку разграничения доступа на практике?

Не у каждой компании есть штатный специалист по информационной безопасности, который выстроит ролевую модель и настроит журналирование с нуля. В сервисах вроде «Клауд АйСи» разграничение доступа к серверу и базам данных настраивается на уровне платформы: клиент получает готовые инструменты для создания ролей, индивидуальных учётных записей и контроля подключений, а не собирает эту защиту вручную из разрозненных компонентов. Это особенно удобно для малого и среднего бизнеса, у которого нет ресурсов на отдельную ИБ-службу, но есть обязанность соблюдать 152-ФЗ наравне с крупными компаниями.