Ваш ребёнок не может отложить телефон. Финский учитель смог с этим справиться на уроках

Вы уже сто раз говорили: «Положи телефон». Ребёнок кивает, кладёт — и через три минуты снова смотрит в экран. Это не упрямство и не игнор. Это дофаминовый цикл, и работает он одинаково у детей, подростков и взрослых. 

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

В чём проблема на самом деле

Мозг не различает «нужно проверить сообщение» и «рука потянулась сама». Оба действия запускаются одним и тем же триггером — кратким дискомфортом: скукой, паузой в разговоре, ожиданием лифта. Телефон стал таблеткой от любого микро-дискомфорта. Это и есть зависимость.

Запрет убирает телефон из рук на час. Привычку не убирает никак.

10-дневная схема Сиекконена: как она устроена

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

Дни 1–4. Вопрос перед действием. Прежде чем разблокировать экран, нужно остановиться и ответить себе честно: зачем я беру телефон? Это конкретная задача — написать кому-то, найти адрес, проверить время — или просто рука потянулась? Детям это сначала кажется странным. Потом они начинают замечать, что большинство раз их ответ «не знаю». Это ломает дофаминовый цикл. На третий день дети перестанут хвататься просто так.

День 2–3. Чёрный экран вместо немедленной разблокировки. Взял телефон — подожди 10 секунд, глядя на тёмный экран. Звучит абсурдно. Работает именно потому, что 10 секунд ожидания показывают: большинство импульсов пропадают сами, без всякого удовлетворения.

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

День 7. Запрет на телефон в переходах. Никакого телефона в лифте, в коридоре, во время перехода из комнаты в комнату, пока ждёшь — еду, автобус, пока загружается игра. Именно эти короткие паузы и есть главный триггер зависимости. Они маленькие, их много, и именно на них уходит большая часть экранного времени за день. Когда убираешь телефон из переходных зон, то мозг начинает думать, а не заполнять пустоты.

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

Что здесь работает на самом деле

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

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

Как применить это с ребёнком без конфликта

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

Потом предложите попробовать вместе. Не «ты должен», а «давай посчитаем, сколько раз в день каждый из нас берёт телефон просто так». Соревнование работает лучше запрета — особенно с подростками.

Отключите лишние уведомления на своём телефоне и на телефоне ребёнка: каждое уведомление — это искусственно созданный триггер. Уберите оба телефона с обеденного стола физически, не как правило, а просто как привычное место хранения. Введите 10-минутную паузу как семейное правило, не как наказание.

Через десять дней сравните цифры. Разговор с данными в руках — это уже совсем другой разговор.

• На Android число разблокировок обычно смотрят через раздел Цифровое благополучие / Digital Wellbeing.
• На iPhone это обычно видно в Экранном времени: там в сводке активности есть раздел «Поднятия», где показывается число разблокировок и время первого поднятия устройства за день.

Подписывайтесь на Telegram-канал @safebdv — там о цифровой безопасности, AI и всём, что происходит с нашей жизнью в сети.

Ключ от всего здания навсегда: почему так больше нельзя делать с появлением Zero Standing Privileges

В прошлом году злоумышленники зашли в 84% организаций, просто используя украденные учётные данные. Не через дыры в коде и не через уязвимости в железе — просто взяли действующий пароль и вошли, как обычный сотрудник. IBM подсчитал: средняя цена одного такого инцидента — $4,44 млн (Cost of a Data Breach 2025). В половине случаев история одна и та же: кто-то получил доступ, выполнил задачу и ушёл, а доступ за ним не закрыли. Учётная запись продолжала существовать — с теми же правами, без владельца, без контроля. Вот через неё и вошли.

Именно эту структурную проблему решает концепция Zero Standing Privileges — ZSP. Только не путайте её с очередным обновлением PAM или маркетинговой надстройкой над существующими инструментами. ZSP — это отказ от базового допущения, на котором строится вся классическая безопасность доступа: что привилегии должны существовать заранее, до того как они понадобятся.

Сразу скажу: ZSP не убирает риски взлома сессий ваших пользователей полностью. Временные токены и сессии тоже атакуются — session hijacking никуда не делся. Но окно атаки сжимается радикально. В классической модели учётная запись с правами живёт 24 часа в сутки, 365 дней в году — пока её кто-нибудь не удалит или не взломает. В модели ZSP злоумышленнику доступен только узкий промежуток активной сессии: 10–30 минут. Это принципиально другая математика угрозы.

Хорошая аналогия — отель. Вам выдали ключ-карту. Вы ожидали что он только от вашего номера. Но по факту и от вашего номера, и от служебных коридоров, и от технических помещений и серверной, потому что карту никто под конкретного гостя не настраивал. Сдать её на ресепшн при выезде? Кто-то сдал, кто-то унёс с собой, кто-то потерял ещё в первый день. Настройки защиты после выезда никто не менял — слишком дорого и хлопотно. Читаете это и думаете: «у нас примерно так»? Правильно думаете. ZSP — это когда ключ-карта физически перестаёт существовать в момент выезда. Не «попросим вернуть» — исчезает сама.

Откуда взялась идея

В сентябре 2019 года аналитики Gartner — Феликс Гетгенс, Майкл Келли и Абхьюдай Дата — опубликовали исследование «Remove Standing Privileges Through a Just-in-Time PAM Approach». Центральный аргумент был таким: пока учётная запись с широкими правами существует постоянно, она постоянно уязвима — независимо от того, насколько хорошо защищён сам пароль. Хранилище паролей защищает секрет, но не убирает учётную запись с всеми ее правами из системы. Мишень остаётся на месте — просто немного защищённее.

Gartner назвал ZSP целевым состоянием, к которому должны стремиться все организации. Forrester поддержал: это новый обязательный стандарт, а не опциональная улучшенка. С тех пор тема не утихает, потому что количество взломов через привилегированные учётные записи не снижается — растёт.

По сути ZSP достраивает два давно известных принципа — наименьших привилегий и Zero Trust. Принцип наименьших привилегий говорит: давай только то, что нужно для задачи. Zero Trust добавляет: не доверяй никому, постоянно всегда проверяй. ZSP добавляет третье измерение — временнóе: никаких прав, которые существуют дольше, чем нужна конкретная задача.

Это не изобретение с нуля: AWS поддерживает временные учётные данные через STS с 2011 года, Microsoft добавил временное членство в группах AD с 2015-го. Gartner в 2019 году не придумал технологию — он дал имя концепции и поднял её до уровня стратегического требования.

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

PAM-системы появились давно, и логика у них была разумная: пароли от привилегированных учётных записей лежат в защищённом хранилище, пользователь берёт нужный пароль, делает работу, возвращает пароль обратно. Сразу оговорюсь: современные PAM-решения — CyberArk, BeyondTrust, Delinea — это не инструменты прошлого века. Они уже много лет пишут сессии, ограничивают конкретные команды и умеют выдавать JIT-доступ с удалением из групп по таймеру. Проблема не в том, что PAM плохой. Проблема в том, что даже хорошо настроенный PAM упирается в структурные ограничения, которые настройками не убрать — нужна другая архитектура.

Доступ — это всё или ничего. Классический PAM открывает доступ к сервису целиком, но не контролирует, что пользователь делает внутри. Получил доступ к серверу — делай с ним что хочешь: читай, пиши, удаляй, копируй. Взломали один аккаунт — под угрозой весь сервис, а не одна операция.

Согласование — это театр безопасности. Заявки на доступ одобряются вручную, права формально пересматриваются раз в квартал. В реальности никто не разбирается, зачем конкретному человеку конкретный доступ прямо сейчас — ставят подпись, потому что так принято. В итоге в любой крупной организации тихо живёт зоопарк: учётки «на всякий случай», admin-роли трёхлетней давности без единого пересмотра, shared-аккаунты без конкретного владельца, сервисные записи подрядчиков, которых уволили год назад. Все они имеют доступ и ждут. По данным Idira Identity Security Landscape 2026, у 96% пользователей прав больше, чем нужно для их реальной работы. Не у части — у подавляющего большинства.

Права отозвали — сессия продолжается. Вот где классический PAM ломается особенно неприятно. Традиционные PAM-решения не интегрированы напрямую с корпоративными SSO-системами и облачными IAM. Как только система выдала SAML- или OAuth-токен — она передаёт управление сессией целевому приложению. Администратора уволили, права в Active Directory закрыли, запись в PAM деактивировали — но его активное облачное подключение продолжает работать, пока токен не истечёт сам по расписанию. Это не баг конкретного вендора — это архитектурное ограничение всей модели с долгоживущими сессиями.

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

PAM, JIT и ZSP — это не конкуренты, это этапы одного пути

Здесь часто путаются, поэтому скажу прямо: ZSP не заменяет PAM и не отменяет JIT. Без нормально настроенного PAM и механизмов JIT концепция ZSP вообще не заработает — нечем будет управлять временными учётными записями и некому их создавать.

PAM — это инфраструктура: хранилища, политики, аудит, управление жизненным циклом учётных записей. JIT (Just-In-Time) — это механизм: права выдаются ровно в тот момент, когда они нужны, а не хранятся постоянно. ZSP — это целевое состояние поверх них: постоянных привилегированных записей нет вообще, они создаются динамически под задачу и уничтожаются после.

Компания не выбирает между тремя колонками в таблице. Она проходит их последовательно: сначала наводит порядок в PAM — убирает зоопарк учёток, настраивает политики. Потом переходит на JIT — права выдаются по запросу, а не хранятся постоянно. Потом убирает постоянные учётные записи полностью — это и есть ZSP. Перепрыгнуть этапы не получится.

Критерий	Классический PAM	Just-In-Time (JIT)	Zero Standing Privileges
Что есть в системе по умолчанию	Постоянные учётные записи с широкими правами	Учётные записи есть, права урезаны до минимума	Привилегированных записей не существует вообще
Как получить доступ	Взять пароль из хранилища	Временно войти в нужную группу	Система создаёт одноразового пользователя прямо сейчас
Сколько живут права	Постоянно — пока кто-нибудь не удалит	Часы или дни — по таймеру	Ровно столько, сколько длится задача
Что происходит после работы	Пароль возвращается в хранилище, запись активна	Пользователя исключили из группы, сама запись осталась	Временная запись полностью удалена
Остаточный риск	Высокий: статические пароли можно перехватить в любой момент	Средний: запись уязвима вне рабочих окон	Минимальный: атаковать нечего — записи не существует

Как это реально работает в продуктах

Одноразовые пользователи в Active Directory. Инженер через Palo Alto Networks Idira запрашивает RDP-доступ к Windows-серверу. Система не извлекает пароль из хранилища для существующей учётки — она создаёт нового пользователя прямо в этот момент, добавляет его в нужные группы безопасности и строит сессию, не пуская инженера напрямую во внутреннюю сеть. Инженер закончил работу — пользователь удалён полностью. Не заморожен, не деактивирован — удалён. Здесь есть реальная техническая сложность: AD не предназначена для массового создания и удаления пользователей в реальном времени, репликация между контроллерами домена может занимать минуты, а удалённые объекты оставляют SID в журналах и ACL. Именно поэтому лучшие реализации ZSP для Windows, как у Teleport, вообще не трогают AD — работают через собственный прокси с сертификатами поверх неё.

Без хранилища паролей вообще. Teleport пошёл дальше и убрал хранилище как концепцию. Вместо статических паролей и SSH-ключей система выдаёт короткоживущие X.509-сертификаты, криптографически привязанные к конкретному человеку. Сессия закрылась — сертификат автоматически уничтожен. Некому случайно скопировать ключ в Telegram, некому забыть его сменить после увольнения коллеги.

Доступ отзывается в реальном времени, не по расписанию. Нормальные современные решения не просто выдают токен и ждут, пока он истечёт сам. Они непрерывно следят за контекстом: уволили сотрудника в HR-системе, устройство повело себя подозрительно, EDR зафиксировал аномалию — доступ отрубается мгновенно, не дожидаясь планового истечения токена.

ИИ-агенты — это новые сервисные учётки, только опаснее

Сервисные учётные записи всегда были головной болью безопасников: их создавали при запуске системы, давали широкий постоянный доступ к базам и API — и забывали про них на годы. Никто не пересматривал права, никто не проверял, кто ими пользуется. Типичный пример накопленного технического долга безопасности.

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

И вот тут разница с человеком принципиальная. Человек сделал что-то не то — остановился, заметил, исправил. Агент выполняет тысячи операций в минуту без пауз. Ошибка или намеренная инъекция промптов — когда злоумышленник подбрасывает агенту вредоносные инструкции через данные, которые тот обрабатывает — масштабируется мгновенно и без человеческого контроля.

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

IBM Cost of a Data Breach 2025 подтверждает это цифрой: 97% утечек, связанных с ИИ, произошли в средах, где не было контроля доступа и формализованных политик. Не в половине случаев — в девяноста семи процентах.

Где ZSP уже работает

Промышленность и SCADA. Внешний подрядчик приходит обслуживать оборудование на электростанции. В старой схеме он получает пароль от системы управления — и этот пароль потом живёт в его записной книжке, в телефоне, иногда на стикере на мониторе ещё лет пять после завершения контракта. В ZSP-схеме система сама подставляет учётные данные в сессию на время работ — подрядчик пароля не видит вообще, он просто работает. Контракт закончился — доступ исчез автоматически. По оценкам аналитиков, такой подход снижает вероятность успешной атаки на критическую инфраструктуру больше чем на 50%.

Здравоохранение. Врач видит карту пациента только во время своей смены и только в рамках запланированного приёма. Попытка получить доступ к базе в нерабочее время или к карте пациента, который к нему не записан — технически невозможна, это не вопрос политики, а вопрос архитектуры доступа. Это одновременно выполнение требований HIPAA и реальная защита от инсайдерских утечек, когда сотрудник сливает данные намеренно.

DevOps. Постоянные ключи к Kubernetes и облачным ресурсам исчезают из сборочных конвейеров — туда, где их чаще всего и крадут через утечки из репозиториев. Деплой проходит через временную роль, которая создаётся перед сборкой и уничтожается сразу после. Доступ привязан к конкретному тикету в Jira или ServiceNow: нет открытого тикета — система просто не выдаст роль.

Почему компании внедряют это медленно

ZSP звучит разумно, цифры убедительные — но внедряют медленно. Причины?

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

Вторая — разработчики говорят, что это тормозит деливери. Они привыкли, что доступ к среде есть всегда, и любое ожидание — это потеря темпа. На практике это решается автоматизацией: запрос доступа через Slack занимает 30 секунд. Но кто-то должен эту автоматизацию настроить, и кто-то должен выделить на это время.

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

Четвёртое — и об этом говорят реже всего. ZSP сокращает окно атаки, но не закрывает его полностью. Перехватил злоумышленник сессию в момент её работы — у него те же 10–30 минут с теми же правами. За это время можно сделать дамп базы или запустить вредоносный скрипт — и временность сессии не поможет. Поэтому ZSP без мониторинга действий внутри сессии — это половина защиты. Ещё одна реальная проблема — долгие операции: миграция данных на 2 часа, ночной бэкап, длинный ETL-процесс. Для них нужны отдельные политики с увеличенным окном сессии — и это место, где архитектура ZSP требует честного компромисса.

Как это выглядит на практике

Лучше всего разница видна на конкретном сценарии. Инженер получил задачу — обновить конфигурацию на продакшн-сервере.

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

ZSP-схема: инженер открывает Slack и нажимает кнопку запроса доступа. Система проверяет, что в трекере существует открытый тикет на эту задачу. Создаёт одноразового пользователя с правами ровно на нужную операцию. Инженер подключается, делает изменение, закрывает соединение. Пользователя уже нет. Следующий запрос создаст другого — с новым именем, новым токеном, новой записью в журнале аудита.

С чего начать

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

Шаг 1. Аудит того, что есть. Инвентаризация всех учётных записей с привилегированным доступом: кто создал, кому выдан, когда последний раз использовался. Запись без понятного владельца или без реальной бизнес-задачи отключается немедленно. Это неприятный разговор, но он необходим — именно эти «ничейные» учётки чаще всего становятся точкой входа.

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

Шаг 3. Автоматизация, иначе это не взлетит. Если получение временного доступа занимает больше двух минут — люди найдут обходной путь. Запросы через Slack или Teams, автоматическое создание записи в Active Directory или облаке, уведомление руководителя в случае нестандартного запроса. Один клик — и через несколько секунд человек работает.

Шаг 4. Мониторинг и автоматический отзыв. Время сессии вышло или система обнаружила аномалию — доступ закрывается автоматически, без ожидания, пока кто-то вручную нажмёт кнопку. Каждое действие пишется в журнал: аудиторы получают полную картину того, кто, когда и что делал.

И сразу отвечу на вопрос, который неизменно возникает: а что, совсем никаких постоянных прав не остаётся? Остаётся одна «аварийная» учётная запись — физически запечатана, хранится отдельно от основной инфраструктуры, используется только в случае полного отказа систем управления доступом. Её применение автоматически запускает расследование. Это не дыра в архитектуре — это огнетушитель за стеклом.

Рынок уже проголосовал

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

Цена промедления измеряется конкретно. По данным Idira Identity Security Landscape 2026: в прошлом году у 87 компаний из ста злоумышленники как минимум дважды успешно входили в системы через чужие учётные данные. Когда это происходило, команды безопасности в среднем теряли 12 часов только на то, чтобы выяснить — где именно произошёл взлом и через какую учётную запись. Потому что инструменты управления идентификацией были разрозненными и не давали единой картины.

В феврале 2026 года Palo Alto Networks закрыла сделку по покупке CyberArk и выпустила объединённую платформу Idira — PAM, IAM и управление агентскими идентичностями в одном месте. Это не случайное корпоративное решение: крупнейший вендор в области сетевой безопасности поставил управление идентификацией в центр своей стратегии, потому что именно здесь сейчас проходит основная линия атаки.

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

Что такое Большая языковая модель (LLM)

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

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

Что вы можете сделать с ИИ

 1. Работа с текстами:

• составление и редактирование деловых писем, отчётов, презентаций;

• подготовка черновиков статей, постов для соцсетей, пресс‑релизов;

• переформулировка текста — упрощение, усложнение, адаптация под аудиторию;

• сокращение текста с сохранением смысла (резюмирование);

• перевод текстов (в т. ч. с сохранением стиля);

• проверка орфографии, пунктуации и стилистики.

TEE - в вашем смартфоне живёт второй процессор. Он не доверяет первому

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

Эта архитектура называется TEE — Trusted Execution Environment, доверенная среда выполнения. Она есть в каждом современном смартфоне, в серверах Azure и Google Cloud, в ноутбуках с Windows Hello, в банкоматах и платёжных терминалах.

И это также большой рынок. Производители TEE в 2024 году заработали 3,5 миллиарда долларов. К 2033 году аналитики ждут 18 миллиардов. Большие деньги за технологию, которую никто не видит и мало кто понимает.

TEE — это бронированная комната внутри процессора. Основная ОС живёт снаружи: она получает задачи, управляет приложениями, иногда подхватывает вирусы. Бронированная комната работает параллельно, отвечает только на заранее разрешённые вопросы и не открывается изнутри — даже если снаружи получили права администратора. Вредоносное приложение, засевшее в Android, не может украсть ключи Apple Pay — их там нет. Они в комнате.

• Разблокировка ноутбука по лицу — TEE.
• Банковское приложение, которое отказывается работать на рутованном телефоне — TEE.
• Корпоративная VM в Azure, данные которой не видят администраторы дата-центра — TEE.
• Стриминговый сервис, проверяющий лицензию на 4K-контент — тоже TEE.

Одна архитектурная идея в основе всего: среда внутри процессора, которой доверяют больше, чем самой операционной системе.

Пять вопросов, которые отделяют надёжный сейф от красивой коробки

TEE: Процессор внутри процессора: как производители защищают ваши данные

TEE — это аппаратная область внутри процессора,

где полномочия обычной операционной системы заканчиваются

Когда вы прикладываете палец к смартфону, происходит любопытная вещь. Телефон не спрашивает Android: «это правильный отпечаток?». Вместо этого запрос уходит в отдельную изолированную среду внутри процессора. Android не видит сам отпечаток, не хранит его и не участвует в проверке.

Эта технология называется TEE — Trusted Execution Environment, доверенная среда выполнения.

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

Сегодня TEE уже используется почти везде:

• в Face ID и сканерах отпечатков;
• в Apple Pay и Google Pay;
• в банковских приложениях;
• в шифровании смартфонов и ноутбуков;
• в облачных вычислениях;
• в системах защиты AI-моделей;
• в корпоративных виртуальных машинах.

Большинство пользователей никогда не слышали термин TEE. Но именно эта технология сегодня стоит между злоумышленником и вашими деньгами, биометрией или корпоративными данными.

Почему TEE внезапно стала стратегической технологией

Производительность самых мощных платформ у каждого производителя в России

Ideco EX

RusPoint RP28010

Check Point CP19200

Континет 4 IPS-R5000

UserGate F8010

Kaspersky KX-3500

PT 3050

API-ключ без срока жизни: почему ваша процедура увольнения ничего не значит

В пятницу вечером вы уволили разработчика. Заблокировали учётку в Yandex Cloud. Удалили из организации в VK Cloud. Отчитались перед HR — всё по регламенту. Молодцы.

В понедельник утром объектное хранилище тихо отдаёт терабайт ваших данных. Никакого взлома. Никакого фишинга. Просто у уволенного был API-ключ сервисного аккаунта, созданный полгода назад для автоматического деплоя. Ключ жив. Он никогда не умирает сам по себе. HR об этом не знает. Регламент увольнения соблюден.

Я занимаюсь информационной безопасностью больше двадцати лет. Эту историю слышал в разных вариациях десятки раз. Каждый раз компании удивляются. Потому что на бумаге всё было сделано правильно. А у уволенного сотрудника доступ к авторизованной когда-то ранее сессии в Контур.Толк еще остался.

Как стать CISO в России: четыре маршрута и ни одного простого.

Зарплаты топовых CISO достигли 1,3 млн рублей в месяц. Медиана по рынку 520 тыс. Но главное не цифры. Главное - это цена тревоги, которая вшита в эту профессию.

Эта заметка родилась во время того как я слушал ответы многих мною уважаемых коллег на CISO форуме.

Профессия ИБ-директора — одна из самых уважаемых сегодня. Генеральный директор делегирует CISO ответственность за самые неприятные операционные риски компании. Кассовый разрыв понятно как закрыть. Нехватку ИТ-ресурсов тоже. А вот множество угроз, способных остановить весь бизнес целиком, сегодня лежат именно в руках у директора по информационной безопасности.

На основной секции CISO Forum 2026 Георгий Руденко задал простой вопрос нескольким директорам по информационной безопасности: «Кто CISO вообще такой?» Ответы были честными, иногда горькими  и совсем не похожими на то, что написано в должностных инструкциях.

Дмитрий Гадарь сказал: «Это человек, который берёт на себя ответственность». Коротко. И именно в этом вся суть роли.

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

Миллион рублей — это реально, но не для всех

Полный список данных для обучения ИИ в кибербезопасности

Ниже будет объяснение для обывателя: каждый пункт раскрыт простым языком, без сложных терминов и жаргона. Это эксперимент - напишите, если вам понравилось.

1. Сетевые данные (что происходит в кабелях и эфире)

1.1. Сырые дампы трафика (pcap)

Что это: Полная запись всего, что передаётся по сети — как «видеорегистратор» всего цифрового движения. Пакеты, байты, заголовки.
Зачем ИИ: Чтобы научиться распознавать атаку по её «почерку» в реальном времени. Особенно новые виды вторжений, которых нет в базах сигнатур.
Для обывателя: Представьте, что каждая кибератака оставляет след, как отпечаток пальца. Сырые дампы — это как раз те самые отпечатки.

1.2. NetFlow / IPFIX (сжатая телеметрия)

Что это: Сводная статистика — кто с кем соединялся, когда, сколько передал данных, какие протоколы использовал. Без самого содержимого.
Зачем ИИ: Быстро замечать аномалии: внезапный всплеск трафика из отдела бухгалтерии в ночь, массированную отправку данных наружу.
Для обывателя: Если сырой дамп — это видеозапись, то NetFlow — это короткий отчёт: «водитель выехал из гаража, ехал 5 минут, передал 2 ГБ, вернулся». По отчёту тоже можно понять, что что-то не так.

1.3. DNS-телеметрия

Что это: Список всех запросов, которые компьютеры делают к доменной системе (DNS), чтобы превратить имя сайта в IP-адрес.
Зачем ИИ: Многие вирусы используют «генераторы случайных доменов» (DGA) — каждые несколько минут стучатся на новый, случайно сгенерированный адрес. ИИ учится их вычислять.
Для обывателя: Представьте, что ваш компьютер постоянно звонит на какие-то левые номера, каждый раз разные. DNS-телеметрия записывает эти звонки.

1.4. Метаданные зашифрованного трафика (JA3/JA4, TLS-отпечатки)

Суверенный ИИ: а где данные для обучения моделей для кибербезопасности в масштабе всей страны?

8 августа 2024 года Путин подписал Федеральный закон № 233-ФЗ об обезличенных данных. Минцифры разработало подзаконные акты. С 1 сентября 2025 года компании обязаны передавать обезличенные данные в государственную информационную систему. Это реальный прогресс — но сам Минцифры объясняет: платформа нужна чтобы понять, какие маршруты автобусов перегружены и где строить школы. Для кибербезопасности эта база не предназначена.

А где же данные для обучения моделей для кибербезопасности?

Каждый месяц на конференциях — от PHDays до Сетевой безопасности — звучит одно и то же: «нам нужен суверенный ИИ в ИБ». Никто не задаёт следующий вопрос. На каких данных его учить?

И я сегодня этот вопрос задам сам себе и поищу ответ.

Что мы вообще строим

Прежде чем говорить о данных — скажем о цели. Суверенный ИИ в кибербезопасности — это не чат-бот который отвечает на вопросы аналитика. Это автономная система, которая самостоятельно проводит тест на проникновение в защищаемую сеть, находит уязвимости которые ещё никто не знает, разбирает инциденты без участия человека и в реальном времени обновляет защиту по всей инфраструктуре страны. Китайская 360 Digital Security Group строит именно это. Американские лаборатории строят именно это. Без такой системы Россия остаётся в позиции вечно догоняющего — вне зависимости от количества конференций и деклараций.

Эта система требует одного: данных. Много данных. Реальных. Размеченных.

Вопрос видоизменился: где взять данные в нужном объёме и качестве?

Как учится искусственный интеллект

Один абзац для тех кто далёк от машинного обучения. ИИ не программируют вручную. Его обучают на примерах. Тысячи раз показывают: вот вредоносный файл, вот нормальный; вот атака, вот обычный трафик. Модель сама находит закономерности. Чем больше реальных примеров — тем точнее система. Чем менее реальные примеры — тем больше ложных срабатываний и пропущенных атак. Нет данных — нет обучения. Это не мистика, так работает математика.

Чего именно не хватает

Red Team в 2026: как находить слепые зоны, которые система создаёт сама

Большинство до сих пор считает, что red team — это поиск и эксплуатация уязвимостей. Поэтому важно изучать инструменты пентестеров и AI. На деле это поиск моментов, когда система начинает слишком сильно верить в собственную неуязвимость. И поэтому становится уязвимой.

Вот семь шагов мышления, которые используют зрелые red team-команды, с примерами из реальных корпоративных сценариев.

1. Сначала — карта доверия, а не поиск дыр

Зрелый специалист сначала спрашивает: где система доверяет сама себе без достаточных оснований.

Пример из жизни: в одном банке внутренний API мониторинга имел право запрашивать любые пользовательские данные “для диагностики”. Это не считалось доступом — это считалось “служебной функцией”. Именно через такие “служебные функции” часто и начинают продвигаться по сети злоумышленники.

Почему умные люди верят телефонным мошенникам: объясняет психология

Социальная инженерия / Психология

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

Кто жертва

Забудьте про миф, что разводят пенсионеров.

По данным колл-центров из Бердянска, чаще всего оставалась на трубке и переводила деньги группа людей 30–39 лет. Интерпол по Азии даёт ту же цифру. Банк России называет 25–40 лет. Самые активные, самые занятые, самые уверенные в себе.

Американские исследователи проверяли связь между уровнем образования, должностью и фактом потери денег мошенникам. Корреляции нет.

В 2024 году за два дня четыре женщины совершили поджоги по звонку незнакомцев. Студентка, кандидат наук, самозанятая, пациентка ПНД. Разные люди, одна и та же механика.

Почему это работает