Защита персональных данных в корпоративных системах Казахстана

С чего начинается проблема: где в компании живут персональные данные

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

Чаще всего в корпоративных системах оказываются ФИО, ИИН, телефоны, адреса, данные документов, сведения о зарплате и больничных, а также реквизиты для выплат. У многих компаний добавляются данные клиентов: договоры, заявки, история обращений, записи звонков.

Риск обычно появляется не из-за «хакеров», а из-за привычек сотрудников. Кто-то выгрузил список в Excel «на час», отправил себе на личную почту, переслал коллеге в чат или сохранил на рабочем столе. Потом файл попал в общую папку «для удобства», а доступ к нему остался навсегда.

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

За порядок не отвечает один человек. ИТ обычно ведет системы и доступы, информационная безопасность (ИБ) - правила и контроль, HR - кадровые данные, юристы - требования и согласия. Работает это только тогда, когда есть общий владелец процесса: кто решает, какие данные можно собирать, где хранить, кому выдавать доступ и как быстро его закрывать.

Карта данных: что именно нужно защищать и где это хранится

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

Персональными данными в повседневной работе становятся не только ИИН и паспорт. Это ФИО, телефон, адрес, личная почта, фото, запись разговора, данные пропуска, IP-адрес, а иногда и комбинации вроде «ФИО + должность + зарплата».

Чтобы не строить одинаково строгие правила для всего подряд, полезно разделить данные по чувствительности. Например:

• Базовые: контакты клиентов и сотрудников, списки телефонов, договорные контактные лица.
• Кадровые: анкеты, резюме, приказы, больничные, табели, оценка, дисциплинарные документы.
• Финансовые: зарплаты, банковские реквизиты, налоговые документы, счета и платежи с привязкой к человеку.
• Медицинские: справки, медосмотры, данные ДМС (если есть).

Дальше пройдитесь по системам, где это чаще всего живет: почта и вложения, 1С/ERP, CRM, сервис-деск, файловые серверы и сетевые папки, облачные диски, резервные копии, тестовые базы и выгрузки для отчетов.

В каждой точке карты назначьте владельца данных. Это не ИТ, а бизнес-ответственный (например, HR за кадровые данные, финдиректор за зарплаты, руководитель продаж за CRM). Владелец решает, кому и зачем нужен доступ, а ИТ настраивает права и помогает обеспечить соблюдение правил.

Разделение данных и ролей: простая модель, которая работает

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

Практичнее не раздавать права «по фамилии», а описать роли. Роль привязывают к должности, отделу и типовым задачам. Тогда при переводе сотрудника или отпуске права меняются вместе с ролью, а не вспоминаются вручную.

Роли, с которых удобно начать

Обычно хватает 4-6 ролей, чтобы навести порядок без сложных матриц:

• Кадры: доступ к анкетным данным и документам без доступа к зарплате.
• Бухгалтерия/расчет: доступ к начислениям и выплатам без доступа к лишним сканам документов.
• Руководитель подразделения: просмотр данных своей команды без выгрузки «всей базы».
• Служба безопасности/комплаенс: доступ по запросу и с фиксацией оснований.
• ИТ-администратор: управление системой без права читать содержимое персональных данных.

Чтобы ИТ не становилось «суперпользователем», разделяйте технические права (настройки, учетные записи, резервные копии) и бизнес-доступ (просмотр карточек, отчеты). Для чувствительных действий используйте отдельные админ-аккаунты и правило «двух пар глаз» при выдаче расширенных прав.

Отдельный момент - контуры. Тестовая среда должна быть отделена от рабочей, и в тест не должны попадать реальные ФИО, ИИН и контакты. Если нужно проверить интеграцию, используйте обезличенные наборы и ограниченные выгрузки.

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

Как настроить доступы: понятные правила и жизненный процесс

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

Первое правило: доступ выдается не «по просьбе в чате», а по понятному маршруту согласования. Обычно владелец данных (руководитель подразделения, которое отвечает за систему или процесс) подтверждает, что доступ действительно нужен. ИТ или ИБ проверяет, что запрос соответствует роли и уровню данных, и выполняет настройку.

Минимум, который стоит фиксировать: кто запросил, кому выдали, к чему именно, на какой срок и кто утвердил.

Чтобы процесс был устойчивым, привяжите его к кадровым событиям:

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

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

Отдельная важная практика - раздельные учетные записи. У администратора должна быть обычная «рабочая» учетка для почты и документов и отдельная админ-учетка только для задач администрирования. Так меньше шансов случайно выполнить опасное действие, попасть на фишинг и «подарить» злоумышленнику максимальные права.

Если вы выстраиваете защиту персональных данных в корпоративных системах Казахстана, начните с простого: роли, согласование, сроки и регулярная проверка прав (хотя бы раз в квартал). Это дает больше эффекта, чем редкие «большие» проверки раз в год.

Журналирование: что логировать, чтобы это помогало, а не мешало

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

Логируйте не все подряд, а действия, которые реально меняют риск:

• входы и неудачные попытки входа (в том числе под админом);
• просмотр карточек/записей с персональными данными;
• выгрузки и массовые операции (экспорт, печать, формирование отчетов);
• изменения прав доступа и ролей;
• удаление или правка критичных полей (ИИН, контакты, реквизиты).

Каждая запись должна отвечать на четыре вопроса: кто, когда, откуда и что сделал. Минимальный набор полей: учетная запись и роль, точное время, система и модуль, источник (компьютер, IP, филиал или сегмент сети), объект действия (какая запись или набор), результат (успех/ошибка) и краткая причина, если она вводится (например, «по запросу клиента»).

Важно, чтобы журналы нельзя было «подчистить». Доступ к ним обычно дают только ИБ и администраторам безопасности, но не тем, чьи действия записываются. Хорошая практика - хранить журналы отдельно от основной системы и включить уведомления на попытки отключить логирование.

По срокам хранения работает простая логика: «достаточно для разборов». Часто это 3-6 месяцев для оперативных расследований и до 12 месяцев, если у вас филиалы, высокая текучка или долгие внутренние проверки. Пример: если бухгалтерия раз в квартал делает выгрузки, журнал за 3 месяца может не показать предыдущую похожую операцию, а за год покажет повторяемость и автора.

Защита хранения и обмена: шифрование, файлы и «серые» каналы

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

Шифрование дисков на ПК и ноутбуках нужно везде, где могут появляться выгрузки и отчеты с персональными данными: у бухгалтерии, кадров, колл-центра, менеджеров в командировках. Если устройство потеряют или украдут, шифрование делает данные бесполезными без ключа.

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

«Серые» каналы обмена

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

Минимум, который можно внедрить за пару недель:

• Введите метки файлов: «ПДн», «внутренний», «публичный».
• Для «ПДн» запретите пересылку наружу без согласования и шифрования.
• Настройте автоправила: предупреждение при отправке «ПДн» по почте, блокировка загрузки в неизвестные облака.
• Храните «ПДн» в одном месте с понятными правами, а не на рабочих столах.
• Регулярно удаляйте временные выгрузки и папки вида «Отчет_финал_точно.xlsx».

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

Резервные копии: как хранить и проверять, чтобы восстановиться

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

Самое понятное правило - 3-2-1. Оно снижает риск того, что «умрут» и рабочие данные, и копии одновременно:

• 3 копии данных: рабочая и минимум две резервные.
• 2 разных носителя: например, хранилище на сервере и отдельный репозиторий/диск.
• 1 копия вне основной площадки: отдельная площадка или изолированное хранилище, недоступное из обычной сети.

Дальше помогает разделить копии по назначению. Рабочие копии нужны для быстрых откатов (удалили папку, испортили документ). Архивные - для требований по хранению и разборов «что было на дату». Отдельно держат копии для восстановления после шифрования (ransomware): они должны быть неизменяемыми или хотя бы изолированными, чтобы злоумышленник не смог удалить их вместе с серверами.

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

• Восстановите 1-2 типовых системы/папки (например, кадровые документы и базу заявок).
• Проверьте целостность: открываются ли файлы, запускается ли база, сходятся ли даты.
• Замерьте время восстановления и сравните с тем, что бизнес считает приемлемым.
• Запишите, что делали, и что пошло не так.

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

Пошаговый план внедрения на 30 дней (без сложных проектов)

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

План на 30 дней

• Дни 1-3: составьте реестр систем, где встречаются персональные данные (1С, CRM, кадровые, почта, файловые хранилища, мессенджеры). Для каждой системы назначьте владельца данных (кто отвечает за правила и согласует доступы).
• Неделя 1: опишите 5-7 типовых ролей и их потребности. Не делайте «доступ по фамилии». Делайте «доступ по работе»: бухгалтерия, HR, руководитель подразделения, оператор колл-центра, ИТ-администратор, служба безопасности.
• Неделя 2: включите журналирование действий в ключевых системах. Сразу договоритесь, кто и как разбирает события: ежедневный быстрый просмотр «красных флагов» и еженедельный разбор спорных случаев.
• Неделя 3: настройте резервное копирование по правилу 3-2-1 (несколько копий, разные носители, одна копия отдельно). Обязательно проведите тест восстановления на выбранной системе, иначе копии могут оказаться «мертвыми».
• Неделя 4: проведите короткое обучение сотрудников. Главное - не лекция, а понятные правила: куда можно выгружать списки, как передавать файлы, как маркировать данные и что делать при подозрении на утечку.

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

Если у вас есть интегратор или ИТ-подрядчик (например, при внедрении серверов и инфраструктуры), попросите помочь именно с регламентом и проверкой восстановления, а не только с «настройками по умолчанию».

Частые ошибки и ловушки, из-за которых случаются утечки

Самые неприятные утечки редко происходят из-за «хакеров». Чаще причина в мелочах: доступ выдали «на время», про это забыли, а данные продолжают жить в общих папках, выгрузках и копиях годами.

Одна из главных ловушек - доступ «на всякий случай». Сотруднику дали права на кадровую папку, CRM или выгрузки клиентов, потому что «попросили помочь», а потом не отозвали. Через полгода он уже в другой роли, но доступ остался. Если права не пересматриваются регулярно, система постепенно превращается в склад лишних разрешений.

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

Журналирование тоже нередко живет «для отчета»: логи включены, но никто не знает, какие события важны и кто должен реагировать. В итоге полезные следы тонут в шуме, а тревожные сигналы остаются без внимания.

Отдельный риск - резервные копии. Когда бэкапы лежат рядом с рабочими данными или доступны всем администраторам без разделения ролей, утечка превращается в «утечку всего сразу». Копии часто содержат больше, чем рабочие системы, и дольше хранятся.

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

Практики, которые закрывают большинство таких историй:

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

Если компания держит критичные данные на своих серверах (например, в корпоративной серверной), эти правила стоит закрепить не только в ИТ, но и в кадровых и операционных процессах. Тогда утечки перестают быть «случайностью» и становятся управляемым риском.

Быстрый чеклист: что проверить прямо сейчас

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

• Есть понятный список систем, где лежат ПДн (HR, бухгалтерия, CRM, почта, файловые папки, мессенджеры), и у каждой системы указан владелец, который отвечает за порядок.
• Доступы выдаются по ролям (например, кадровик, бухгалтер, руководитель отдела), а не точечно: «Пете добавьте, Маше уберите». Роль описана простыми словами: что можно смотреть, менять, выгружать.
• Увольнение и перевод сотрудника запускают отзыв доступов без ручных напоминаний: учетная запись блокируется, токены и VPN отключаются, доступ к общим папкам снимается.
• Журналирование включено для ключевых действий: входы, выдача прав, выгрузка списков, массовые изменения, удаление. Логи защищены от правок и доступны ограниченному кругу.
• Резервные копии шифруются, хранятся раздельно от основной системы и регулярно проверяются восстановлением (не «копия есть», а «восстановили и оно работает»).

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

Если два и более пункта сейчас «скорее нет», начните с инвентаризации систем и ролей. Это даст основу, на которую потом ложатся и технические средства, и поддержка (например, в инфраструктуре, которую разворачивают и сопровождают системные интеграторы вроде GSE.kz).

Реалистичный пример: средняя компания с филиалами и общей сетью

Представим компанию на 400 сотрудников с головным офисом и 6 филиалами. Внутри - кадровая система с личными делами, CRM с контактами клиентов и общий файловый сервер, куда по привычке складывают все подряд: сканы удостоверений, договоры, медсправки, списки зарплат. Так обычно и начинается защита персональных данных в корпоративных системах Казахстана: данные есть везде, а доступы настроены «на всякий случай».

Первый шаг - разнести данные по смыслу и владельцам. HR отвечает за личные дела и заявления, бухгалтерия - за зарплату и ИИН в расчетах, продажи - за CRM, ИТ - за инфраструктуру, но не за просмотр содержимого. Важно, чтобы ИТ мог администрировать систему, не имея прав читать папки с чувствительными файлами.

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

• HR: полный доступ к кадровым папкам, запрет на финансовые реестры.
• Бухгалтерия: доступ к расчетным ведомостям, только чтение к нужным кадровым справкам.
• Продажи: доступ к CRM и коммерческим документам, запрет на кадровые и зарплатные данные.
• ИТ: админ-права на сервера и резервные копии без прав на «Кадры» и «Зарплата».
• Руководители: доступ по заявке и на срок, с обязательным журналированием.

Журналы должны помогать при подозрении на выгрузку. В первую очередь смотрят: кто и когда скачивал большие объемы, кто делал массовые копирования на сетевые папки, кто экспортировал из CRM, и были ли входы в нерабочее время или из непривычных филиалов. Полезно заранее договориться о «порогах» (например, 500 файлов за час или экспорт базы клиентов) и автоматически поднимать тревогу.

Копии организуют просто, но дисциплинированно: ежедневные - для быстрого отката, недельные - для защиты от тихих ошибок, и отдельное хранение - чтобы выжить после шифровальщика.

• Ежедневно: инкрементные копии ключевых систем (HR, CRM, файловый сервер).
• Раз в неделю: полный бэкап с проверкой восстановления.
• Отдельно: одна копия вне домена и с отдельными учетками доступа.
• Регулярно: тест «восстановили ли файл/базу за 30 минут».

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

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

Следующие шаги: как закрепить порядок и упростить поддержку

Когда базовые правила уже настроены (кто видит данные, что логируется, где лежат копии), важно сделать это обычной практикой, а не разовым проектом. Тогда безопасность не разваливается после смены сотрудников или обновления системы.

Начните с минимального пакета внутренних правил. Он не должен быть толстым, но должен быть понятным и применимым:

• классификация данных и уровни доступа (что можно, что нельзя);
• роли и ответственность: владелец данных, администратор, ИБ, руководитель подразделения;
• порядок выдачи и отзыва доступов (включая увольнение и перевод);
• требования к журналам и срокам хранения;
• правила резервного копирования и проверки восстановления.

Дальше выберите 2-3 самые «богатые» системы и доведите их до порядка до конца, прежде чем идти дальше. Обычно это HR, бухгалтерия, CRM и общий файлообмен. Критерий простой: где больше всего персональных данных и где доступы чаще всего выдаются вручную.

Чтобы поддержка не превращалась в ручной труд, запланируйте обновления рабочих мест и серверов под требования ИБ: централизованные политики, актуальные ОС, контроль дисков, единые шаблоны настроек. Например, если бухгалтерия хранит отчеты на сетевом ресурсе, важно, чтобы и рабочие ПК, и сервер поддерживали одинаковые правила шифрования, обновлений и резервного копирования.

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

В Казахстане часто важно и происхождение оборудования, и поддержка. В таких задачах могут помочь отечественные рабочие станции и ПК (L200, M200) и серверы (S200) от GSE.kz, а также внедрение инфраструктуры и поддержка 24/7, чтобы правила оставались рабочими и после изменений в сети или составе команды.