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

от

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

Что такое списки контроля доступа (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 — это не столько техническая конфигурация, сколько отлаженный управленческий процесс, в котором ИТ-специалисты, руководители подразделений и служба безопасности говорят на одном языке. Ключевой метрикой успеха является не абсолютный ноль нарушений, а постоянное снижение доли пользователей с избыточными или нерегламентированными правами, выявляемое в ходе регулярных внутренних проверок.

Загрузка…

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