«Сбер» попросил сотрудников удалить Telegram с рабочих компьютеров из-за «уязвимости сервиса» — Forbes Статьи редакции

В качестве альтернативы предлагают корпоративный «Сберчат», говорят источники.

  • О просьбе удалить Telegram с рабочих компьютеров рассказали Forbes два сотрудника компании. Несколько месяцев назад банк запретил использовать на корпоративных устройствах WhatsApp и Zoom, а около месяца назад — и Telegram, рассказал один из источников.
  • Через сервисы «могут украсть информацию», объяснили в компании, говорит сотрудник. По его словам, банк проверяет исполнение запрета с помощью автоматического мониторинга программ. Если не удалить мессенджер, он всё равно исчезнет.
  • «Просто появится сообщение "обнаружено запрещенное ПО Telegram: удалите его, либо через 72 часа мы сами удалим"», — рассказывает источник. Для внутренней коммуникации сотрудники «Сбера» используют «Сберчат».
  • В пресс-службе «Сбера» не ответили на вопросы vc.ru о связанных с Telegram запретах для сотрудников.
  • О требованиях удалить Telegram сообщала и Baza. По данным издания, HR-отдел «Сбера» объяснил это «возможными проверками».
0
215 комментариев
Написать комментарий...
Илья Дёмин

Не очень понял комментаторов, которые так остро реагируют на данную новость и шутят шутки.

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

Причины, я думаю, очевидны:
1) Риск того, что телефон с ТГ потеряется\его украдут и посторонние лица смогут получить доступ к приватной инофрмации
2) При увольнении сотрудника гораздо удобнее, чтобы он тоже терял переписку и не имел доступа к старым сообщениям
3) Сотрудникам проще найти коллег во внутреннем мессенджере, где каждый человек правильно подписан и стоит понятное фото
4) Делиться чувствительной информацией в стороннем мессенджере не очень

Ответить
Развернуть ветку
Sergey

Меня, как сотрудника, не надо "стараться приучать", я не собака. Мне надо либо обьяснить, что к чему и зачем, либо не давать изначально свободы на устройстве делать то, что я захочу, вот и всё. А потом, если мне надо, я сам найду где и как мне общаться, без корпоративных сервисов. Вот в этом суть)

Ответить
Развернуть ветку
Alex

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

Ответить
Развернуть ветку
Bo.G

Это кто тебе такое сказал то? Что процессы должны меняться регулярно?
Какие процессы то? приведи примеры. прцесс выдачи кредитов или процесс разработкм ПО или процесс мониторинга или процесс ремонта машин..

Ответить
Развернуть ветку
Em

Бизнес процессы, дубина.

Ответить
Развернуть ветку
Bo.G

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

Ответить
Развернуть ветку
John Doe
они у вас меняются потому что вы ничерта не можете описать и стабилизировать.

стабилизированный процесс разработка ПО

Ответить
Развернуть ветку
Bo.G

по большому счету сейчас так и происходит. набрали детей, всучили им счеты в виде фреймворков. они с ними носятся и трясут "фичами"... шумят.. весело. но максимум что уиеют - склалывать и вычитать. а. ещё могут с дизайнерами их перекрашивать.. и менять с деревянных (php) на модные, пластиковые (python) и все довольны.

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

Ответить
Развернуть ветку
John Doe
по большому счету сейчас так и происходит. набрали детей, всучили им счеты в виде фреймворков

1. Не сейчас. Сборщик на конвейере ничего не понимает в том, как ковался металл, из которого он собирает что-то. А пару сотен назад лет хороший кузнец в этом прекрасно разбирался. И при этом заклепки мог ставить не хуже.
2. Объем выпуска в единицу времени у толпы детей несравнимо больше, чем у штучных высококвалифицированных программеров. Так что все логично, нужен объем — единицы высококвалифицированных его обеспечить не могут, а толпа детей — может.

тут, кстати не процесс разработки

Это был эвфемизм про стабилизированный

Ответить
Развернуть ветку
Bo.G

Конвейер хорош до тех пор, пока есть тактй кузнец Левша, которы и блоху подковать может. Все хотят такого "штучного" специалиста, который может решить практически любую задачу. Куча людей у конвейера даже не поймут о чем они. эти задачи. и впш конвейер встанет колом.
Но у нас с Левшами обращаются все так же, как и в повести Лескова.
Кругом одни эффективные менеджеры постоянно меняюшие процессы...

Ответить
Развернуть ветку
John Doe
Конвейер хорош до тех пор, пока есть тактй кузнец Левша

Зачем на конвейере Левша? У конвейера свои задачи — там одинокий Левша не особо полезен, но нужен хороший архитектор и девменеджер. А там где нужен Левша — там конвейер бессмысленен. Просто задач для Левшей все меньше и меньше.

Все хотят такого "штучного" специалиста, который может решить практически любую задачу.

"Штучный" будет полезен, если у Вас задач на команду в 3-4-5 разрабов. А если их на 100-200 и они стандартные, то одинокий Левша Вам погоду не сделает. Да и сбежит он быстро, неинтересно ему делать то, с чем дети с фреймворками справляются.

у нас с Левшами обращаются все так же, как и в повести Лескова

1. И сам и все, что у других видел, — на адекватных Левшей все молятся и в ножки кланяются. Но вот далеко не все Левши — адекватны. Умеренно неадекватных Левшей тоже можно успешно применять, но это требует сил и умения. Вот ТАКОЕ умение и желание редко встречается ИМХО. А если Левша сильно неадекватен, то конечно в расход. Он такой один, а атмосферу попортит во всем коллективе.
2. Стандартная проблема "звездных" разрабов и архитекторов — они живут своим техническим миром и не понимают общих бизнес-задачи, которые их и кормят. Но это нормально, если супер-разраб и техарк не отстаивает технически правильные решение, то он плохой разраб и техарк. А дальше если ему объяснять контекст, почему такое решение, а не другое, то как правило все ок. Но не так часто запариваются и все заканчивается конфликтом. Но это действительно плохие менеджеры, не выполняют свою прямую менеджерскую задачу убедить людей. Но иногда Левши совсем в своем космосе и сколько не убеждай, он оттуда не вернется. Тогда в расход.

Кругом одни эффективные менеджеры постоянно меняюшие процессы

В неадекватных конторах — согласен. А в адекватных девменеджеры — это всегда хорошие (по продуктивности, качеству кода и communication skills) бывшие разрабы с многолетним опытом, они прекрасно понимают, где нужно и где не нужно менять. Адекватные ПМы и начальство выше слушают своих хороших девменеджеров.

Ответить
Развернуть ветку
Bo.G

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

Ответить
Развернуть ветку
John Doe
Комментатором было однозначно утвержден тезис, что бизнес процессы должнф меняться регулярно. просто потому что.

1. Сбербанк/СБТ наверное :) У них так. Беготня ради беготни. Согласен с Вами.
2. Я бы сказал, что они не должны, но неизбежно меняются.

Ответить
Развернуть ветку
Akim Glushkov

Любые процессы. Операционные, бизнес процессы, политики безопасности и так далее.

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

Ответить
Развернуть ветку
Bo.G

и они по твоему - постоянно меняются? сами процессы. например, процесс авторизации пользователей... или процесс оформления первичных бухгалтерских документов...
как ты будешь менять процесс выплавления стали в доменной печи? постоянно...
вообще есть понимание термина "процесс"? или только субъективно-бытовое?

Ответить
Развернуть ветку
Alex

Процесс авторизации пользователей - если начинать с ввода email-пароля в форме, то потом идет двухфакторная авторизация, авторизация через сторонние сервисы, авторизация через мобильный телефон, авторизация по биометрии, с помощью другого устройства, где биометрия пройдена (часы), подтверждение входа с другого авторизованного устройства, с помощью капчи, sso, ограничения по авторизации из-за разных историй в виде страны входа, количество заходов с данного ip, в 2023 году Apple, Google, Microsoft внедрят единый формат авторизации через мобильный девайс. И это не говоря уже про то, что формат логина может быть разным. И не говоря, что могут быть подтверждения авторизации по флешке с ключом доступа. И много всего другого.

Ответить
Развернуть ветку
Chyvakoff

Ну вот процесс разработки ПО за последние 10 лет очень сильно поменялся. Раньше в TotalCommander скопировал файл на FTP - всё, релиз прошел. Сейчас релизят совсем не так.

Ответить
Развернуть ветку
Bo.G

кто тебе это сказал? ты каждый шаг процесса деплоя разобрал? или только знаешь команду его запускающую? сразу видно школьный опыт.
10 и 20 и 30 лет назад писались огромные проекты. все, чем вы сегодня пользуетесь сделано 25 и далее лет назад. и именно тогда были придуманы и реализованы эти процессы. механизмы могут меняться. но процессы.. если брать деплой то какими средствами доставки пользуется гит или меркуриал? не http,ftp и тд протоколами? а как происходит накат? не заменой ли файлов? смешные вы наши наивные. уж я точно знаю, что в любом супер надутом веб деплое если вдруг вылез баг то никто не будет собирать релиз... а потихому залезут в код и пофиксят на бою.
и этот, кстсти, тоже очень старый и стабильный процесс

Ответить
Развернуть ветку
Chyvakoff

Ну давайте ещё скажите, что как 30 лет назад были единицы и нули, так и сейчас они остались. И код программы на перфокарте в принципе не отличается от работы самой современной нейронной сети.
Кто сказал? а никто, я более 10 лет в разработке и прекрасно вижу разницу в том как писали или как деплоили раньше и сейчас.

Ответить
Развернуть ветку
Всвиторе

Проблема в том, что весь СОФТ нужно держать у себя, а не на рабочем устройстве, но практически никто не выдаёт устройства на руки сотрудникам.

Ответить
Развернуть ветку
Sergey

Что за дичь вы пишете)
" ты выполняешь все меняющиеся правила в компании"

Завтра выходит правило, что надо приходить на работу без штанов, вы придёте на работу без штанов или что?

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

Ответить
Развернуть ветку
212 комментариев
Раскрывать всегда