Мессенджер МАКС и Теле2
Попал в следующую ситуацию.
Давно установил мессенджер «Макс» на старый телефон, зашел в веб-версию данного мессенджера, а телефон где-то затерялся дома. То есть пользуюсь только веб-версией.
Теперь суть. Зарегистрировался на сайте «Петровича», чтобы сделать заказ, оформил его и вышел из аккаунта. Дома нужно было перепроверить время доставки. Захожу на сайт «Петровича», ввожу номер телефона, нажимаю кнопку «Получить код из СМС», а СМС не приходит — приходит только код в мессенджер «Макс». Но есть нюанс: из веб-версии посмотреть код нельзя, а телефон, на котором установлен мессенджер, найти не могу.
Звоню в «Петрович», мне говорят: «Мы отправляем СМС оператору связи, никаких уведомлений в мессенджере "Макс" у нас нет».
Звоню в Tele2, и ОКАЗЫВАЕТСЯ, Tele2 автоматически ловит все СМС от магазина «Петрович» и перенаправляет их в мессенджер «Макс», причем отключить эту функцию нельзя. То есть я плачу деньги за то, чтобы получать входящие звонки и СМС, а они сами решили за меня перенаправлять часть СМС в «Макс». То есть сейчас возможности зайти в личный кабинет Петровича я просто не имею.
Сказать, что я в шоке, — ничего не сказать. Зачем пост? Чтобы все были в курсе, чем теперь занимается Tele2 как оператор связи.
Суд решил: работодатель имеет полное право требовать пароль от вашего ПК
Представьте: вы на больничном, мирно пьете чай с малиной, и тут приходит сообщение от начальника: «Срочно скинь пароль от своего рабочего компьютера, коллегам нужно продолжать работу».
Ваша первая реакция? Скорее всего, возмущение. «Это мое личное пространство!» или «Это нарушение приватности!». Но недавняя судебная практика расставила все точки над «i». И как налоговый консультант, который ежедневно видит, как мелкие нарушения регламентов превращаются в крупные проблемы, я хочу разобрать этот кейс подробно.
Компьютер — не ваша личная крепость
Недавно дошло до суда интересное дело. Сотрудница, находясь на больничном, получила требование от руководителя передать пароль. Она отказалась, посчитала это незаконным и подала в суд, требуя еще и компенсацию морального вреда.
Суды трех инстанций, включая Второй кассационный суд (определение от 23.07.2026 № 88-20666/2026), встали на сторону работодателя. Логика железная:
Офисный компьютер — это собственность компании, а не личная вещь сотрудника.
Работодатель вправе иметь беспрепятственный доступ к своему имуществу.
Рабочая техника не должна содержать личных данных (фото, переписки, закладки на развлекательные сайты).
Бизнес-процессы не должны вставать из-за болезни одного человека. Коллеги должны иметь возможность работать.
Более того, в этом деле директор изначально рекомендовал не ставить пароли на рабочие машины, чтобы обеспечить взаимозаменяемость. Так что требование передать доступ абсолютно законно.
Обратная сторона медали: стикеры и текстовые файлы
Но есть важный нюанс. Тот факт, что начальник имеет право знать ваш пароль, не означает, что вы можете хранить его как попало.
В другом свежем деле сотрудник хранил все свои пароли и ПИН-коды в обычном текстовом файле прямо на рабочем столе компьютера. Работодатель провел проверку, обнаружил это и объявил сотруднику замечание. Тот, разумеется, пошел в суд. Его аргумент: «Дверь в кабинет закрывается на ключ, пароль я никому не давал, угрозы не было».
Шестой кассационный суд (определение от 05.03.2026 № 88-3939/2026) с этим не согласился. И вот почему:
Хранение паролей в открытом виде прямо нарушало внутренние акты и должностную инструкцию, с которыми сотрудника ознакомили под роспись.
Сам факт наличия файла passwords.txt создает потенциальную угрозу утечки конфиденциальной информации.
Ответственность за информационную безопасность на рабочем месте лежит на сотруднике.
Итог: замечание оставили в силе. А в некоторых компаниях за такое можно запросто лишиться премии или заработать дисциплинарное взыскание, которое ляжет в личное дело.
Что делать, чтобы не попасть в ловушку?
Как специалист, который помогает бизнесу и людям избегать штрафов и проверок, даю три практических совета:
Разделяйте личное и рабочее. Никогда не храните личные фото, доступы к личным банкам или соцсетям на рабочем ноутбуке. Это собственность компании.
Читайте, что подписываете. Политика информационной безопасности и должностная инструкция — это не формальность. Если там написано «пароли хранить в менеджере паролей, а не на стикерах», значит, стикер на мониторе — это уже нарушение.
Передавайте доступы официально. Если пароль требуют, отправьте его по корпоративной почте или через корпоративный мессенджер с пометкой «Для обеспечения рабочего процесса». Это защитит вас от обвинений в неправомерной передаче данных.
Кстати, о правилах и нюансах. В своей практике я постоянно убеждаюсь: дьявол кроется в деталях. Маленькая небрежность в документах или регламентах часто приводит к большим финансовым потерям. Если вам интересно глубже разобраться в правовой и налоговой грамотности, чтобы чувствовать себя уверенно, загляните сюда.
А если вдруг проверка (не только внутренняя кадровая, но и налоговая) уже на пороге, и нужны четкие, профессиональные действия, а не гадание на кофейной гуще, обращайтесь: Помощь при налоговых проверках: https://taplink.cc/nalogpro
Работодатель имеет полное право требовать пароль от служебного компьютера. Но вы, как ответственный сотрудник, обязаны хранить этот пароль (и все остальные) в соответствии с внутренними правилами компании. Никаких стикеров на мониторе и текстовых файлов на рабочем столе.
А как у вас в компании решается вопрос с паролями? Начальство знает ваш доступ, или вы до последнего храните тайну за семью печатями? Делитесь опытом в комментариях!
Ответ PoceluyVsadnicu в «Безопасники, вы добились своего!»3
Тоже не понимаю в чем проблема, бесит - да, но мой пароль Март50...так дойду и до Март999
Решаем проблему с паролями
TLDR:
Набор цифр: "123456789"
Название сайта по частям: "ПИКА123456789бу"
Спецсимвол "ПИКА1234@56789бу"
Дата последней смены пароля: "ПИКА1234@56789бу2609"
Подробно
Делюсь способом, которым завожу пароли для сайтов:
Берём набор цифр - это всё что нам нужно будет запомнить. Это может быть 1234, дата рождения или почтовый индекс - не имеет значения, главное чтобы было легко запомнить. Для примера возьмём "123456789"
Берём название сайта для которого заводим пароль и делим на две части - по слогам или по середине, а в середину вставляем наши цифры. Получаем "ПИКА123456789бу". Первая часть - заглавными, вторая - строчными (или наоборот). Так мы сразу получаем пароль, который соответствует критериям длина, цифры, строчные и заглавные буквы. Тут также есть варианты - в первой части использовать латиницу, во второй - кириллицу, но для решения проблемы важно везде придерживаться одного алгоритма.
Добавляем спецсимвол. Это не обязательно, но если сайт просит указать, то в середину наших цифр (или перед ними или после) добавляем тот самый спецсимвол. Выберите для себя какой спецсимвол будете использовать и используйте его везде - ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _` { | }. Таким образом к критериям безопасности добавляется спецсимвол - "ПИКА1234@56789бу".
Если на работе требуют регулярно менять пароль (@apple.mary), то в конце пароля просто добавляем дату последней смены пароля, вы же помните - меняли пароль в этом месяце или в прошлом? Тогда пароль становится "ПИКА1234@56789бу2609" или "РА1234@56789бота2609".
Такие пароли:
Легко запомнить - нужно запомнить всего несколько цифр, которые только для вас имеют значение. И даже можно записать на бумажке - это тоже относительно безопасно если никто не знает про ваш личный спецсимвол (даже зная алгоритм).
Уникальные для каждого сайта -не повторяется.
Удовлетворяют всем требованиям по безопасности - цифры, заглавные и строчные буквы, спецсимволы.
Устойчивые к подбору - имеют большую длину
Ответ на пост «Безопасники, вы добились своего!»3
К сожалению, это почти родовая травма нашего инфобеза. Который много лет никто особо не развивал в массах, а когда жаренный петух клюнул - то его, вспомогательную и обеспечивающую сферу в рамках ИТ-технологий - начали выводить как основную и являющую основой для развития всего остального.
В нынешних условиях требования ИБ не помогают в работе пользователя и тем более разработчика, делая её более безопасными, а являются банальным стопором.
И "чистым" частникам тут еще более-менее живётся, т.к. на них сбросили только 152-ФЗ по персоналке, который более-менее логичен. На тех же, кто работает с государством или же на гос. органы последние пару лет валится столько, что просто рыдать хочется. При этом, почему-то головы в профильных высоких кабинетах даже минимально не задумываются о том, насколько исполнимо то, что принимается в сфере ИБ. И возня с паролями на этом фоне - это мизер из разряда "обидно, досадно, да ладно".
В ноябре прошлого года приняли изменения в КоАП, которые вводят санкции за размещение государственных, муниципальных и прочих около государственных информационных систем на площадках провайдеров, не прошедших лицензирование. Для тех кто предоставил - лям как с куста и столько же на муниципала, который систему разместил на таком ЦОДе2:
1. Осуществление деятельности по предоставлению вычислительной мощности для размещения информации в информационной системе, постоянно подключенной к информационно-телекоммуникационной сети "Интернет", провайдером хостинга, сведения о котором не включены в реестр провайдеров хостинга, -
влечет наложение административного штрафа на граждан в размере от пятидесяти тысяч до ста тысяч рублей; на должностных лиц - от двухсот тысяч до пятисот тысяч рублей; на юридических лиц - от шестисот тысяч до одного миллиона рублей.
И вроде всё бы хорошо и красиво - забота о безопасности, подконтрольные хостинги а не шарашкины конторы. Только возникает простой вопрос - а оплачивает банкет кто? Если ранее компании, разрабатывающие софт предоставляли у себя место для баз муниципалитета часто бесплатно, либо за сущие копейки, то сейчас размещение на сертифицированных ЦОДах - это от 250 тысяч только за специализированные системы (и это в условиях что это всё будет виснуть и тупить), не касаясь общего ПО типа 1ски, сайтов муниципалитетов и пр. И, как правило, эта проблема касается самых мелких муников, т.к. у них изначально нет денег на покупку даже слабенького сервера. А с учетом еще и педалируемого импортозамещения - сервак уже не слабенький нужен и порой не один. И это в условиях, что многие районы/округа 100-120 тысяч за своё спец. ПО каждый год ищут со слезами на глазах, потому что денег нет.
Сверху сюда же падает требование 117го приказа четко разделять продуктивную и тестовую среду. Я, как внедренец-сопровожденец - согласен, давайте делать так. А дальше начинаются классический вопрос - а мне, сопровожденцу, который на этом тестовом контуре будет ковыряться - кто и из чего выделит серверные мощности под оный контур? Папа Римский? И при этом да, естественно, контур будет не такой же по характеристикам, как прод, но он нужен и под него надо мощности где-то найти, которых у того же Усть-пердюйского аймака просто нет. И сверху на это нам вешают метод рекомендацию, что на тестовом контуре должны висеть копии БД с синтетическими данными - как минимум деперсонализированными, а в идеале и с "перемешанными" суммами. И если первое я хоть как-то понимаю, то второе - это просто дичь, из-за которой все тестирование будет заключаться только в проверке того, что после обновления в систему можно зайти, да что отдельные документы открываются. Проверить большие выборки или интеграционные механизмы? Да фиг там, не понимая реальность пришедших цифр - корректность не проверишь. А сидеть выстраивать массивы с данными и их выверять - без проблем, но за отдельную плату, т.к. потребует привлечение дополнительных специалистов. А на это заказчик почему-то не идет (и почему же это...). И при этом надо мной висит то, что у меня достаточно "творческая" сфера с большим простором вольности для исполнителей и из-за этого куча уникальных доработок на каждой отдельной базе.
Туда же, наш дорогой ФСТЭК в своих фантазиях рекомендует для соблюдения норм ИБ использовать PAM решения. Это уже вопрос не мелких районов, а крупных городов и субъектов т.к. цена вопроса - от 3-4 миллионов и до бесконечности. Великолепно, давайте работать так - там и двухфакторка и четко разграниченный доступ к серверам и прочие ограничения. И тут уже выходят "специалисты" на местах, которые отличным решением в сфере ИБ находят отключить буфер обмена между PAMом и аттестованной машиной разраба. Притом не ограничивая по размеру (что тоже достаточно сомнительная история, но хоть что-то), а тупо рубя. Забрать логи, закинуть скрипт? Держи родной чупа-чупс, что делать с ним - знаешь.
И над всем этим парит гениальная птица под названием "Аттестация по 117 приказу", которая теперь касается не только сами гос органы и организации, но и исполнителей. И даже для средней организации - это вопрос, выливающийся в миллионные затраты. Особенно PEN-тесты, которые стоят каких-то конских денег. И кто же за всю эту историю в итогу заплатит? На вопрос отвечает Александр Друзь:
А потом мы будет слушать регулярное нытье, что стоимость ПО перераздута и ИТ-сфера зажралась.
И на сегодняшний день текущий подход к ИБ - это тормоз развития ИТ-сферы и ухудшение жизни для всех участников, начиная от разработчика и заказчика и заканчивая конечного сотрудника или гражданина, который всем этим будет пользоваться. При этом я не призываю отказаться от ИБ полностью, но подход к нему должен быть адекватным, а не приводить к ситуации, когда лучший метод защиты - закрыть всё на лопату и уйти домой.





