Настройка списков контроля доступа

от

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

Что такое списки контроля доступа (ACL)

Списки контроля доступа (Access Control Lists, ACL), это фундаментальный механизм информационной безопасности, который определяет правила взаимодействия между субъектами (пользователями, сервисами, процессами) и объектами (файлами, записями в базах данных, сетевыми ресурсами). Каждое правило в таком списке отвечает на простой вопрос: может ли конкретный субъект выполнить определённое действие (чтение, запись, выполнение) над конкретным объектом. В российской практике этот механизм является основным инструментом для выполнения требований по разграничению доступа, предъявляемых регуляторами.

Типичная ошибка: последствия отсутствия ACL

Рассмотрим классическую ситуацию в среднестатистической компании. В отделе продаж для «удобства» работы в CRM-системе всем 25 менеджерам были предоставлены административные права. В системе находились данные разной степени чувствительности.

Тип данных Уровень чувствительности Возможные последствия утечки Нарушенные требования
Персональные данные клиентов (номера телефонов, паспорта) Высокий Штрафы по 152-ФЗ, проверки Роскомнадзора ст. 19 152-ФЗ, РД.10 ФСТЭК
Коммерческие предложения и стратегии ценообразования Средний Утечка коммерческой тайны, потеря клиентов Политика конфиденциальности компании
Внутренняя переписка и история обсуждений Низкий Репутационные потери —

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

Правовые основы: что требуют регуляторы

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

  • 152-ФЗ «О персональных данных». Статья 19 обязывает оператора обеспечить разграничение доступа к персональным данным. ACL, это техническая реализация данного требования. Для систем уровня защищённости К2 и выше необходимо документально фиксировать основания для предоставления прав (приказ, служебная записка).
  • Приказ ФСТЭК России №21. Устанавливает требование реализации дискреционного управления доступом. Это означает, что права на объект определяются его владельцем (например, руководителем отдела — для данных отдела), а не централизованно одним администратором.
  • РД.10 ФСТЭК России (базовый набор мер). Жёстко запрещает использование общих и групповых учётных записей там, где требуется индивидуальная ответственность. Каждое действие в системе должно быть однозначно связано с конкретным сотрудником, что невозможно без персонифицированных ACL.

Техническая реализация ACL в разных средах

Принцип работы ACL един, но синтаксис и подходы различаются в зависимости от платформы.

Файловые системы и операционные системы

Windows (NTFS): Помимо базовых разрешений, поддерживает расширенные списки доступа (Advanced ACL), позволяющие задавать исключения. 

# Пример: Предоставление полного доступа группе "Продажи" к папке Data
icacls "C:Data" /grant "Sales_RW:(OI)(CI)F"
# Пример: Запрет удаления файлов для группы "Консультанты"
icacls "C:DataContracts" /deny "Consultants:(OI)(CI)D"

Linux (ext4, XFS с POSIX ACL): Позволяет гибко назначать права сверх стандартной модели user/group/other. 

# Дать пользователю ivanov права на чтение, запись и выполнение
setfacl -m u:ivanov:rwx /opt/app/data
# Дать группе auditors только право на чтение
setfacl -m g:auditors:r-- /opt/app/logs

Системы управления базами данных (СУБД)

PostgreSQL: Использует систему привилегий, основанную на ролях (ROLE), которые могут наследовать друг друга. 

-- Создание роли для чтения финансовых отчётов
CREATE ROLE finance_readonly;
GRANT CONNECT ON DATABASE company TO finance_readonly;
GRANT USAGE ON SCHEMA finance TO finance_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA finance TO finance_readonly;

Microsoft SQL Server: Помимо ролей сервера и базы данных, позволяет создавать пользовательские роли с гранулярными правами на уровне схемы или отдельных объектов. 

-- Создание схемы и предоставление прав только на неё
CREATE SCHEMA Sales;
GRANT SELECT, INSERT ON SCHEMA::Sales TO SalesManager;

Веб-приложения и бизнес-системы

На уровне приложения ACL часто реализуются через модель RBAC (Role-Based Access Control), где права привязаны не к пользователю, а к его роли в системе. 

// Пример аннотации в Spring Boot (Java)
@PreAuthorize("hasRole('ROLE_APPROVER') or hasAuthority('PAYMENT_APPROVE')")
public void approvePayment(Long paymentId) {
    // Метод доступен только утверждающим
}

// Пример в Django (Python) с использованием декораторов
from django.contrib.auth.decorators import permission_required

@permission_required('finance.view_invoice', raise_exception=True)
def invoice_details(request, invoice_id):
    # Просмотр счёта только с конкретным правом
    ...

Практический алгоритм внедрения и управления ACL

Внедрение ACL, это процесс, а не разовая настройка.

  1. Инвентаризация и классификация. Составьте реестр всех информационных активов: файловые серверы, базы данных, прикладные системы. Присвойте каждому ресурсу уровень конфиденциальности (например, открытый, для служебного пользования, конфиденциальный, строго конфиденциальный).
  2. Определение бизнес-ролей и матрицы доступа. Забудьте на время о технике. Совместно с руководителями подразделений определите, каким должностям для работы действительно нужны доступ к каким данным. Результат — матрица в Excel: роли по вертикали, ресурсы по горизонтали, а в ячейках — минимально необходимые права (R-чтение, W-запись, M-модификация).
  3. Техническая реализация. Перенесите утверждённую матрицу в ИТ-системы. Создавайте технические роли (AD группы, роли в СУБД) в соответствии с бизнес-ролями. Права назначайте группам/ролям, а не пользователям.
  4. Внедрение процессов жизненного цикла.
    • Выдача прав: Права предоставляются только на основании заявки от руководителя подразделения.
    • Ресертификация (пересмотр): Не реже раза в квартал руководитель подтверждает актуальность прав своих сотрудников. Автоматизируйте рассылку таких запросов.
    • Аудит: Регулярно (раз в месяц) с помощью скриптов или средств мониторинга проверяйте наличие «сиротских» прав (прав, назначенных напрямую пользователям, а не через роли) и прав администратора у рядовых сотрудников.

Принципы и лучшие практики

Принцип Что означает Практический пример
Минимальные привилегии (Least Privilege) Пользователь получает ровно те права, которые нужны для его задач, и ни одним битом больше. Бухгалтеру на авансовые отчёты даётся право ввода и редактирования, но не удаления. Право на удаление (закрытие) есть только у главного бухгалтера.
Разделение обязанностей (SoD) Критическая операция разделяется между несколькими людьми для предотвращения мошенничества или ошибок. В системе электронного документооборота один сотрудник создаёт проект договора, второй — его согласовывает, третий — подписывает. Один человек не может выполнить все три действия.
Своевременный доступ (JIT) Повышенные права (например, административные) выдаются на ограниченный срок для выполнения конкретной задачи, а затем автоматически отзываются. Разработчик получает права на запись в продакшен-базу данных только на 2 часа для проведения критического исправления, которые активируются по утверждённой заявке.

Что работает: ролевая модель (RBAC), регулярный пересмотр прав по запросу бизнеса, обязательное журналирование всех изменений в ACL, принцип «по умолчанию — запрет».

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

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

Оставьте комментарий