Разбираем актуальные темы и тренды в рамках кибербезопасности и ИТ
Вебинары
Решения
Детальный анализ изменений 187-ФЗ и проекта Постановления Правительства РФ № 127
Укрепление безопасности КИИ
Услуги
Как бизнесу защититься от киберугроз и не раздуть бюджет
Кейс компании «ДОМА» и УЦСБ SOC
Сервисы
Apsafe
Облачная DevSecOps-платформа для непрерывного анализа защищенности приложений
Безопасная разработка — 2026: как 117 приказ ФСТЭК России меняет правила игры и что делать с ИИ
13 марта 2026
С 1 марта 2026 года вступили в силу требования 117 приказа ФСТЭК России, который пришел на смену 17 приказу. Параллельно развивается нормативная база в области искусственного интеллекта — появляются профильные ГОСТы для КИИ. Часть документов уже принята и вводится в действие в 2026 году, другие пока существуют в виде проектов, но вектор движения уже очевиден.
Разбираемся, как новые требования меняют «правила игры» для разработчиков, работающих с ГИС и КИИ, где грань между реальной защитой и «бумажной» безопасностью, и что делать с относительно новым контуром — безопасностью систем искусственного интеллекта.
С 1 марта 2026 года вступили в силу требования 117 приказа ФСТЭК России, который пришел на смену 17 приказу. Параллельно развивается нормативная база в области искусственного интеллекта — появляются профильные ГОСТы для КИИ. Часть документов уже принята и вводится в действие в 2026 году, другие пока существуют в виде проектов, но вектор движения уже очевиден.
Разбираемся, как новые требования меняют «правила игры» для разработчиков, работающих с ГИС и КИИ, где грань между реальной защитой и «бумажной» безопасностью, и что делать с относительно новым контуром — безопасностью систем искусственного интеллекта.
Нормативные требования: 117 приказ и новые стандарты
Когда документ официально утверждается государством, заказчики, особенно в госсекторе, начинают включать его требования в контракты. Это касается и 117 приказа, и профильных ГОСТов. Для заказной разработки это означает, что готовиться к новым требованиям нужно заранее, еще на стадии проектов.
Один из ключевых рисков — формальный подход. Чтобы избежать превращения требований ФСТЭК России в «бумажную безопасность», важно понимать структуру новых стандартов. Например, ГОСТ по ИИ в КИИ составлен с ориентацией на практику. В нем нет абстрактных указаний «сформировать нормативную базу», а есть конкретные технические и организационные требования.
Доказательствами выполнения работ служат не только бумажные отчеты, но и техническая документация, чек-листы, артефакты разработки ПО, результаты проводимых диагностик. Вместо того чтобы выстраивать новые процессы с нуля под каждый пункт, разумнее проанализировать, какой процент требований уже закрывается текущей деятельностью, и наращивать недостающее. Это не барьер, а возможность систематизировать работу и получить хорошее подспорье для развития процессов безопасной разработки.
Логичным завершением внедрения практик становится сертификация по ГОСТ Р 56939-2024. Важно понимать: наличие сертифицированного процесса разработки не дает стопроцентной гарантии безопасности конечного продукта — никто не застрахован от zero-day уязвимостей. Однако сертификация заставляет проходить через определенные проверки, оперативно устранять найденные уязвимости. Как итог — порог качества и безопасности продукта объективно повышается. Максимальный эффект достигается не тогда, когда сертификация делается «для галочки», а когда она накладывается на внутреннее желание компании выпускать безопасный продукт.
Один из ключевых рисков — формальный подход. Чтобы избежать превращения требований ФСТЭК России в «бумажную безопасность», важно понимать структуру новых стандартов. Например, ГОСТ по ИИ в КИИ составлен с ориентацией на практику. В нем нет абстрактных указаний «сформировать нормативную базу», а есть конкретные технические и организационные требования.
Доказательствами выполнения работ служат не только бумажные отчеты, но и техническая документация, чек-листы, артефакты разработки ПО, результаты проводимых диагностик. Вместо того чтобы выстраивать новые процессы с нуля под каждый пункт, разумнее проанализировать, какой процент требований уже закрывается текущей деятельностью, и наращивать недостающее. Это не барьер, а возможность систематизировать работу и получить хорошее подспорье для развития процессов безопасной разработки.
Логичным завершением внедрения практик становится сертификация по ГОСТ Р 56939-2024. Важно понимать: наличие сертифицированного процесса разработки не дает стопроцентной гарантии безопасности конечного продукта — никто не застрахован от zero-day уязвимостей. Однако сертификация заставляет проходить через определенные проверки, оперативно устранять найденные уязвимости. Как итог — порог качества и безопасности продукта объективно повышается. Максимальный эффект достигается не тогда, когда сертификация делается «для галочки», а когда она накладывается на внутреннее желание компании выпускать безопасный продукт.
Переход на российские инструменты
Для компаний, которые уже имели внедренные зарубежные инструменты безопасной разработки, переход на отечественные аналоги сопряжен с рисками. Как гарантировать, что новые решения не снизят качество выявления уязвимостей?
Ключевую роль здесь будет играть внутренняя экспертиза. В штате должен быть минимум один специалист (Security Champion), который понимает критерии качества работы инструмента и может объективно оценить, справляется ли конкретный сканер с поставленными задачами, — независимо от того, коммерческое это решение или опенсорсное. Также можно привлечь внешнего подрядчика для пилотирования и оценки качества предлагаемых инструментов.
Российские вендоры сегодня ориентированы на отечественные экосистемы, с которыми работают заказчики, и учитывают требования регуляторов. Многие из них собирают данные об уязвимостях из нескольких общедоступных источников. Для сравнения: отдельные западные решения могут быть ориентированы преимущественно на один фид, например, NVD.
Сравнение конкретных функций может показывать разную картину, однако по качеству экспертизы российские решения западным не уступают. А благодаря ориентации на локальные экосистемы и требования регуляторов они зачастую лучше адаптированы для работы в российских условиях.
Ключевую роль здесь будет играть внутренняя экспертиза. В штате должен быть минимум один специалист (Security Champion), который понимает критерии качества работы инструмента и может объективно оценить, справляется ли конкретный сканер с поставленными задачами, — независимо от того, коммерческое это решение или опенсорсное. Также можно привлечь внешнего подрядчика для пилотирования и оценки качества предлагаемых инструментов.
Российские вендоры сегодня ориентированы на отечественные экосистемы, с которыми работают заказчики, и учитывают требования регуляторов. Многие из них собирают данные об уязвимостях из нескольких общедоступных источников. Для сравнения: отдельные западные решения могут быть ориентированы преимущественно на один фид, например, NVD.
Сравнение конкретных функций может показывать разную картину, однако по качеству экспертизы российские решения западным не уступают. А благодаря ориентации на локальные экосистемы и требования регуляторов они зачастую лучше адаптированы для работы в российских условиях.
Тренды 2026: что ожидать от регуляторов
В мире наблюдается экспоненциальный рост количества требований к ПО и ИИ. Более 80 стран уже приняли национальные стратегии в области искусственного интеллекта. Российский подход тяготеет к «восточной» модели: регулирование идет не через один общий закон, как в Европе, а через отраслевые стандарты. Причем государственные информационные системы регулируются жестче, чем коммерческие. Это позволяет рынку расти, но тенденция к ужесточению сохранится.
Отдельные положения, касающиеся ИИ, содержатся в 117 приказе, который вступил в силу 1 марта 2026 года. Продолжается работа над нормативной базой в этой сфере: в конце 2025 года ФСТЭК России утвердила методику анализа защищенности и рекомендации по регистрации событий безопасности, а проект закона об искусственном интеллекте находится в стадии разработки.
В ближайшее время в требованиях к разработке ИИ появятся конкретные пункты:
Отдельные положения, касающиеся ИИ, содержатся в 117 приказе, который вступил в силу 1 марта 2026 года. Продолжается работа над нормативной базой в этой сфере: в конце 2025 года ФСТЭК России утвердила методику анализа защищенности и рекомендации по регистрации событий безопасности, а проект закона об искусственном интеллекте находится в стадии разработки.
В ближайшее время в требованиях к разработке ИИ появятся конкретные пункты:
- очистка и проверка данных на предмет отравления;
- проверка LLM-моделей и агентов на промпт-инъекции и джейлбрейки;
- контроль цепочек поставок (supply chain);
- требования к отказоустойчивости;
- учет человеческого фактора и социальной инженерии.
Процессы и инструменты DevSecOps
Внедрение инструментов анализа — это в первую очередь работа с людьми. Техническая часть — выбор опенсорсного или коммерческого решения — давно отработана, есть вся необходимая документация и кейсы.
Основные сложности возникают на этапе, когда в процесс включается человек. Требуется обосновать необходимость внедрения и запросить бюджет у руководства, согласовать с DevOps-командами способы и места встраивания инструментов в пайплайны. Разработчики же сталкиваются с валом срабатываний, на отработку которых в текущих процессах просто не заложено времени.
На каждом этапе важно доносить, что инструменты созданы не для контроля и увеличения объема работы для разработчиков, а для повышения качества продукта. Если в компании изначально нет культуры информационной безопасности, на выстраивание коммуникации уйдет значительно больше времени и ресурсов, чем на техническую реализацию.
Основные сложности возникают на этапе, когда в процесс включается человек. Требуется обосновать необходимость внедрения и запросить бюджет у руководства, согласовать с DevOps-командами способы и места встраивания инструментов в пайплайны. Разработчики же сталкиваются с валом срабатываний, на отработку которых в текущих процессах просто не заложено времени.
На каждом этапе важно доносить, что инструменты созданы не для контроля и увеличения объема работы для разработчиков, а для повышения качества продукта. Если в компании изначально нет культуры информационной безопасности, на выстраивание коммуникации уйдет значительно больше времени и ресурсов, чем на техническую реализацию.
Какой инструмент внедрять первым?
Практика показывает, что начинать внедрение безопасной разработки проще всего с композиционного анализа (SCA). Причины:
- Легковесность: движки SCA работают за считанные минуты, в отличие от тяжелых SAST-анализаторов.
- Простота анализа: разбор результатов по сторонним компонентам требует менее глубокой квалификации, чем анализ проприетарного кода. Нашел уязвимую библиотеку — оценил релевантность и обновил или заменил.
- Покрытие: SCA сразу закрывает большой пласт уязвимостей из публичных баз знаний, которые SAST может пропустить.
Автоматизация в ИБ: заменит ли она людей?
Современные инструменты (SAST, ASOC) заявляют об автоматизации разбора уязвимостей. С развитием мультиагентных систем на рынке уже появляются решения для автоматической проверки кода.
Роль специалиста в этих условиях будет трансформироваться: человек остается в контуре управления, но смещается в сторону оркестрации мультиагентных систем. К этому тренду нужно готовиться — объем данных растет по экспоненте, и автоматизация неизбежна.
Однако полностью заменить человека автоматизация не сможет. Во-первых, за системами нужен контроль: инструменты должны оставаться помощниками, а не заменителями. Во-вторых, существует риск «притупления взгляда»: когда специалист начинает слепо доверять выводам ИИ и перестает оттачивать собственные навыки, неверный вердикт модели может поставить под угрозу инфраструктуру компании.
Кроме того, любые модели на чем-то обучаются. Используя готовые решения, компания неявно опирается на чужие данные, включая информацию об уязвимостях других организаций. Создание закрытого контура, где модель обучается и работает исключительно на собственных данных компании без обращения к внешним сервисам, — процесс дорогой и доступный лишь единицам. Остальные же так или иначе остаются в зоне риска, связанного с качеством и происхождением обучающих данных, а также с возможностью промпт-инъекций при использовании публичных моделей.
Роль специалиста в этих условиях будет трансформироваться: человек остается в контуре управления, но смещается в сторону оркестрации мультиагентных систем. К этому тренду нужно готовиться — объем данных растет по экспоненте, и автоматизация неизбежна.
Однако полностью заменить человека автоматизация не сможет. Во-первых, за системами нужен контроль: инструменты должны оставаться помощниками, а не заменителями. Во-вторых, существует риск «притупления взгляда»: когда специалист начинает слепо доверять выводам ИИ и перестает оттачивать собственные навыки, неверный вердикт модели может поставить под угрозу инфраструктуру компании.
Кроме того, любые модели на чем-то обучаются. Используя готовые решения, компания неявно опирается на чужие данные, включая информацию об уязвимостях других организаций. Создание закрытого контура, где модель обучается и работает исключительно на собственных данных компании без обращения к внешним сервисам, — процесс дорогой и доступный лишь единицам. Остальные же так или иначе остаются в зоне риска, связанного с качеством и происхождением обучающих данных, а также с возможностью промпт-инъекций при использовании публичных моделей.
Безопасность искусственного интеллекта в КИИ
Безопасность систем искусственного интеллекта принципиально отличается от безопасности традиционного ПО. ИИ-системы непредсказуемы — на один запрос возможны разные ответы, их архитектура быстро усложняется, а спектр атак постоянно расширяется. К основным типам атак относятся:
При работе с моделями из внешних источников важно помнить о рисках цепочки поставок. Известны инциденты, когда на популярных платформах размещались отравленные модели. Если есть сомнения в безопасности модели, можно напрямую связаться с ее поставщиком, минуя промежуточную платформу. Разработчики часто готовы предоставить код напрямую, особенно если модель размещена в открытом репозитории. Это не отменяет необходимости анализа уязвимостей, но снижает риски, связанные с неконтролируемыми каналами распространения.
- Отравление данных (Data Poisoning): подмена или искажение данных, на которых обучается модель.
- Промпт-инъекции (Prompt Injection): манипуляция моделью через специально сформированные входные запросы для получения несанкционированного доступа или информации.
- Инверсия модели (Model Inversion): извлечение данных, на которых обучалась модель.
- Атаки типа «отказ в обслуживании» (DoS): отправка ресурсоемких запросов для вывода модели из строя.
- Состязательные атаки (Adversarial Attacks): незначительное изменение входных данных, приводящее к ошибочной классификации.
При работе с моделями из внешних источников важно помнить о рисках цепочки поставок. Известны инциденты, когда на популярных платформах размещались отравленные модели. Если есть сомнения в безопасности модели, можно напрямую связаться с ее поставщиком, минуя промежуточную платформу. Разработчики часто готовы предоставить код напрямую, особенно если модель размещена в открытом репозитории. Это не отменяет необходимости анализа уязвимостей, но снижает риски, связанные с неконтролируемыми каналами распространения.
Защита данных при обучении моделей
Поскольку отравление данных и инверсия модели напрямую связаны с обучающими данными, их защита становится критически важной. Ключевой принцип при работе с данными для обучения — минимизация. Модели нужно отдавать только те данные, которые действительно необходимы для решения задачи. Второй принцип — законность. Использование данных без согласия субъектов или с нарушением 152-ФЗ «О персональных данных» несет огромные репутационные риски. Известны случаи, когда компании приходилось откатывать модель из продакшна из-за неправильно оформленных согласий на обработку данных.
При проектировании системы нужно учитывать ресурсы, которые будут тратиться на ограничение модели (guardrails). Любые этические или законодательные рамки, например запрет на выдачу медицинских прогнозов, ограничения по религиозной или расовой тематике, «съедают» токены и снижают производительность и полезность модели. Это должно быть заложено в оценку эффективности с самого начала.
При проектировании системы нужно учитывать ресурсы, которые будут тратиться на ограничение модели (guardrails). Любые этические или законодательные рамки, например запрет на выдачу медицинских прогнозов, ограничения по религиозной или расовой тематике, «съедают» токены и снижают производительность и полезность модели. Это должно быть заложено в оценку эффективности с самого начала.
Доверие к ИИ: этика или техническая устойчивость?
В обсуждении доверия к искусственному интеллекту неизбежно встает вопрос: что важнее — этические нормы или техническая устойчивость к атакам?
Техническая устойчивость на данный момент важнее, поскольку речь идет о целенаправленных атаках, компрометации систем и конкретных инцидентах с измеримыми последствиями. Однако с каждым годом ситуация будет выравниваться: технические средства защиты станут совершеннее, а этика останется неизменным фактором, который нельзя игнорировать.
В отличие от технических атак, имеющих четкие векторы и измеримые последствия, этические нормы в сфере ИИ пока находятся в стадии формирования и не имеют устоявшихся единых стандартов. Понимание того, что считать этичным, варьируется от человека к человеку. Этика будет дополнять технику, но для ее встраивания в системы пока не хватает устоявшегося понимания и единых стандартов.
Техническая устойчивость на данный момент важнее, поскольку речь идет о целенаправленных атаках, компрометации систем и конкретных инцидентах с измеримыми последствиями. Однако с каждым годом ситуация будет выравниваться: технические средства защиты станут совершеннее, а этика останется неизменным фактором, который нельзя игнорировать.
В отличие от технических атак, имеющих четкие векторы и измеримые последствия, этические нормы в сфере ИИ пока находятся в стадии формирования и не имеют устоявшихся единых стандартов. Понимание того, что считать этичным, варьируется от человека к человеку. Этика будет дополнять технику, но для ее встраивания в системы пока не хватает устоявшегося понимания и единых стандартов.
Безопасность или скорость: что выберет бизнес?
От обсуждения технических аспектов безопасности ИИ перейдем к самому прагматичному вопросу — где безопасность встречается с деньгами, сроками и кадрами.
Выбор между безопасностью и скоростью вывода продукта на рынок зависит прежде всего от культуры компании. Существуют организации, которые работают по принципу «быстро выпустим, потом доработаем», но к техническому долгу они уже не возвращаются. Эта экономия на информационной безопасности впоследствии обходится в разы дороже — исправление уязвимостей на этапе эксплуатации может стоить в десять раз больше, чем на этапе разработки, а инциденты могут принести существенный ущерб бизнесу, вплоть до его остановки.
Бизнесу нужна скорость, и это объективная реальность. Современные условия требуют умения ускоряться эффективно — за счет лучших практик, автоматизации и, парадоксально, непрерывного повышения квалификации команд. Требования к ИТ-специалистам жестко растут: если несколько лет назад можно было войти в профессию после полугода обучения, то сейчас подготовка начинающего специалиста занимает годы. Время непрерывного обучения увеличивается, и это естественный процесс.
Облегчить поиск баланса между скоростью и безопасностью помогает появление в компании роли бизнес-лидера по информационной безопасности (BISO). Это человек, который уполномочен принимать риски, балансируя между безопасностью и сроками. Он может как остановить сборку или выкладку нового релиза, так и принять риск, взяв на себя ответственность за дальнейшую работу с техническим долгом. Пока в компании нет такого независимого человека, который не относится исключительно ни к безопасности, ни к ИТ, ни к бизнесу, а отвечает за все сразу, — достичь комфортного баланса значительно сложнее.
Выбор между безопасностью и скоростью вывода продукта на рынок зависит прежде всего от культуры компании. Существуют организации, которые работают по принципу «быстро выпустим, потом доработаем», но к техническому долгу они уже не возвращаются. Эта экономия на информационной безопасности впоследствии обходится в разы дороже — исправление уязвимостей на этапе эксплуатации может стоить в десять раз больше, чем на этапе разработки, а инциденты могут принести существенный ущерб бизнесу, вплоть до его остановки.
Бизнесу нужна скорость, и это объективная реальность. Современные условия требуют умения ускоряться эффективно — за счет лучших практик, автоматизации и, парадоксально, непрерывного повышения квалификации команд. Требования к ИТ-специалистам жестко растут: если несколько лет назад можно было войти в профессию после полугода обучения, то сейчас подготовка начинающего специалиста занимает годы. Время непрерывного обучения увеличивается, и это естественный процесс.
Облегчить поиск баланса между скоростью и безопасностью помогает появление в компании роли бизнес-лидера по информационной безопасности (BISO). Это человек, который уполномочен принимать риски, балансируя между безопасностью и сроками. Он может как остановить сборку или выкладку нового релиза, так и принять риск, взяв на себя ответственность за дальнейшую работу с техническим долгом. Пока в компании нет такого независимого человека, который не относится исключительно ни к безопасности, ни к ИТ, ни к бизнесу, а отвечает за все сразу, — достичь комфортного баланса значительно сложнее.
Стоит ли отказываться от Open Source ради безопасности?
Если скорость так важна для бизнеса, то использование открытого кода — один из ключевых факторов ускорения разработки. Однако новые требования 117 приказа и стандартов для КИИ заставляют задуматься: не проще ли вообще отказаться от Open Source-библиотек, чем пытаться проверять их все на наличие закладок и уязвимостей?
Полностью отказаться от открытого кода нереалистично и экономически нецелесообразно. Опенсорс критически ускоряет разработку за счет готовых функций и компонентов, и его запрет приведет к кратному удорожанию проектов. Переписывать существующие библиотеки собственными силами не только дороже, но и рискованнее: разработчики могут перенести в новый код те же уязвимости, которые уже были обнаружены и исправлены в опенсорсном оригинале.
Гораздо эффективнее выстроить процессы контроля цепочки поставок. Практика SCA и использование инструментов типа open-source firewall (прокси, проверяющего компоненты) решает задачу быстрее и дешевле, чем раздувание штата разработчиков для переписывания всего подряд. Снижая риски цепочки поставок одним способом, важно не создать себе новые риски другим.
Что касается отказа от зарубежных репозиториев вроде GitLab, на российском рынке уже существуют аналоги. Однако оценить, насколько полно они заменяют зарубежные решения, можно будет только после появления статистики о реальном переходе российских компаний на эти платформы.
Полностью отказаться от открытого кода нереалистично и экономически нецелесообразно. Опенсорс критически ускоряет разработку за счет готовых функций и компонентов, и его запрет приведет к кратному удорожанию проектов. Переписывать существующие библиотеки собственными силами не только дороже, но и рискованнее: разработчики могут перенести в новый код те же уязвимости, которые уже были обнаружены и исправлены в опенсорсном оригинале.
Гораздо эффективнее выстроить процессы контроля цепочки поставок. Практика SCA и использование инструментов типа open-source firewall (прокси, проверяющего компоненты) решает задачу быстрее и дешевле, чем раздувание штата разработчиков для переписывания всего подряд. Снижая риски цепочки поставок одним способом, важно не создать себе новые риски другим.
Что касается отказа от зарубежных репозиториев вроде GitLab, на российском рынке уже существуют аналоги. Однако оценить, насколько полно они заменяют зарубежные решения, можно будет только после появления статистики о реальном переходе российских компаний на эти платформы.
Всем ли подвластен SDL?
Влияние новых стандартов на рынок приведет к расслоению. Небольшие стартапы, которые разрабатывают лендинги или несложные сервисы, не работающие с критичными данными, могут продолжать игнорировать сложные процессы безопасной разработки — рынок для них сохранится.
Однако как только компания планирует выходить на уровень enterprise, госкорпораций или финтеха, соответствие стандартам становится обязательным условием выживания. Регулятор не придет с проверкой в старта, который разрабатывает условный Блокнот, но если стартап работает с деньгами или данными клиентов, соблюдение нормативов — это прямая защита бизнеса. Игроки, которые не заложат ИБ в бюджет и процессы, рискуют закрыться не из-за проверок, а потому что их продукты взломают, а репутация будет испорчена. Крупный бизнес и госзаказчики, в свою очередь, будут все чаще требовать от подрядчиков подтверждения зрелости процессов безопасной разработки.
Однако как только компания планирует выходить на уровень enterprise, госкорпораций или финтеха, соответствие стандартам становится обязательным условием выживания. Регулятор не придет с проверкой в старта, который разрабатывает условный Блокнот, но если стартап работает с деньгами или данными клиентов, соблюдение нормативов — это прямая защита бизнеса. Игроки, которые не заложат ИБ в бюджет и процессы, рискуют закрыться не из-за проверок, а потому что их продукты взломают, а репутация будет испорчена. Крупный бизнес и госзаказчики, в свою очередь, будут все чаще требовать от подрядчиков подтверждения зрелости процессов безопасной разработки.
Заключение
Требования 117 приказа и развитие стандартов для ИИ — это не разовая бюрократическая нагрузка, а новый этап эволюции разработки. Ключевые выводы:
- Готовиться нужно заранее. Требования из проектов ГОСТов скоро станут частью контрактов.
- Экспертиза важнее инструмента. Дорогой инструмент не спасет без понимания, как он работает. Опенсорс — хорошая точка входа для старта и оценки инструментов, но доведение его до уровня, закрывающего все потребности бизнеса, часто требует сопоставимых или больших вложений, чем использование готовых коммерческих решений.
- Безопасность ИИ — это новая специализация. Атаки на модели отличаются от классических уязвимостей, и защита требует новых знаний и инструментов.
- Баланс безопасности и скорости возможен. Для этого нужны встроенные процессы, автоматизация и понятное распределение ответственности за риски.
Подпишитесь на нашу рассылку
Вы будете получать только полезную информацию о кибербезопасности — никакого спама и рекламы
Нажимая кнопку «Подписаться», я даю свое согласие на обработку моих персональных данных, в соответствии с Федеральным законом от 27.07.2006 года №152-ФЗ «О персональных данных», на условиях и для целей, определенных в Согласии на обработку персональных данных