Комментарии 15
Если хотите хорошей паблисити — публикуйте код. Где ваш аккаунт на гитхабе? Почему вы используете линукс, но ничего не даёте комьюнити назад?
Вот это, надеюсь, не ваш аккаунт? github.com/Sberbank?tab=repositories
Вот это, надеюсь, не ваш аккаунт? github.com/Sberbank?tab=repositories
Сотрудники Сбертеха активно контрибьютят в Apache Ignite. Причем делают это с личных аккаунтов под своими реальными именами. В отличие от того, как заведено в некоторых компаниях, когда с одного аккаунта в день публикуется сотни тысяч строк кода – понятно, что за этим аккаунтом стоит команда людей, вклад которых остается невидимым.
Примеры проектов:
github.com/apache/ignite
github.com/apache/kafka
В этом интервью лидер Open Source в Сбертехе рассказывает подробнее, как у нас это устроено
Примеры проектов:
github.com/apache/ignite
github.com/apache/kafka
В этом интервью лидер Open Source в Сбертехе рассказывает подробнее, как у нас это устроено
В прошлом году проходил проект по замене Windows на рабочих станциях на Linux, его результатом стала возможность официально установить себе Ubuntu Linux сотруднику Блока Т.
Именно Ubuntu или можно любой привычный дистрибутив?
Я уж не говорю о том, что для человека снаружи совершенно неясно, что означает фраза «сотрудник Блока Т»
Я очень надеюсь, что это шутка. Как вы себе представляете «любой привычный дистрибутив» в компании, которая хоть чуть-чуть думает о безопасности?
Безопасность рабочих мест имеет весьма отдаленное отношение к безопасности сервисов самого банка. Тем более, что сейчас внутренняя сеть предприятия представляет нечто достаточно большое, что по сути и превращает ее во «внешний» периметр. А ещё представьте, когда сотрудники работают из дому или удаленно. Даже с ВПН. Вспомним ещё, что сейчас ipv6 на подходе, хотя многие админы в него вообще не умеют. И мы поймём, что новые реалии требуют нового подхода к безопасности. А не «запрещать сторонние дистрибутивы»
И мы поймём, что новые реалии требуют нового подхода к безопасности.Засунуть себе в сеть троян — это очччееень новаторский подход к безопасности.
А не «запрещать сторонние дистрибутивы»Ну понятно, что запрет дистрибутивов «от дяди Васи» — не должен быть единственным средством. Но также понятно, что внутрь своей сети лучше трояны всё-таки не пускать.
Будь она хоть трижды «внешняя».
Лучше воспринимать внутреннюю локалку как такую же сеть, чем молиться на нее и считать доверенной априори. Очень многие проникновения основаны на том чтобы попасть во внутреннюю сеть, где грубо говоря можно творить что угодно.
Конечно, сделать так чтобы одиночный троян не мог вывести из строя всю систему значительно сложнее ))
Конечно, сделать так чтобы одиночный троян не мог вывести из строя всю систему значительно сложнее ))
Лучше воспринимать внутреннюю локалку как такую же сеть, чем молиться на нее и считать доверенной априориНе путайте тёплое с мягким. То, что ваш компьютер, чтобы его куда-то пустили, должен обладать демоном, который докажет серверу что да — ему-таки можно доверять и что не нужно просто слепо давать доступ тому, что в соответствующую Ethernet-дырку вставили — это понятно. Но это — совсем про другое.
Конечно, сделать так чтобы одиночный троян не мог вывести из строя всю систему значительно сложнее ))Особенно если этому трояну вы таки даёте доступ ко всем данным (а если не даёте — как вы собираетесь это использовать?).
Я как-то про сети, которые доверяют всему, что в них включено даже не подумал — это всё-таки уровень контор из трёх человек. Я имел в виду, что «рабочая станция на Linux» должна-таки быть, я извиняюсь, рабочей станцией… и на ней люди будут, что удивительно, работать — и как тогда вы собираетесь данные от неё защищать? Если доступа к данным нет — то работать не получится. А если есть — то это значит, что и у трояна, встроенного в «любой привычный дистрибутив» — они тоже будут.
Особенно если этому трояну вы таки даёте доступ ко всем данным (а если не даёте — как вы собираетесь это использовать?).
Есть существенно бОльшая проблема — доверие к конкретным людям. Где гарантии, что они не будут сливать данные или внедрять в код проекта вредоносный код? Если коммиты большие и есть практика ревью PR, то реально можно случайно пропустить "закладку"
Также — отдельная проблема доверия к поставщикам услуг. Операторам услуг связи, провайдерам облачной инфраструктуры etc.
Я как-то про сети, которые доверяют всему, что в них включено даже не подумал — это всё-таки уровень контор из трёх человек
Имеется в виду, что по умолчанию сеть доверенная. Это не означает, что для доступа к ресурсам не используются пароли )
А если есть — то это значит, что и у трояна, встроенного в «любой привычный дистрибутив» — они тоже будут.
Соглашусь. Но административно выпилить все возможности для разработчика устанавливать софт == полностью парализовать его работу.
что не нужно просто слепо давать доступ тому, что в соответствующую Ethernet-дырку вставили
Несомненно. Но у меня есть еще куча историй про неправильное использование port security и прочих "крутых" enterprise систем защит.
То, что ваш компьютер, чтобы его куда-то пустили, должен обладать демоном, который докажет серверу что да
раз это демон, то очевидно, что его можно взломать или подделать. Либо нужно идти до конца — и отбирать права администратора, возможность залезать в BIOS Setup etc.
Кратко мое мнение:
- защиты в виде полумер не работают, а скорее мешают, и, на самом деле, создают "театр безопасности" (т.е. видимость безопасности)
- внутренний периметр, где стоят рабочие машины с доступом в интернет — такой же внешний
- мы уже живем в эпоху IPv6, overlay сетей и прочих "веселых" технологий, поэтому нужно пересматривать способы защиты, а не пытаться выехать на старых вещах вроде "у нас NAT, поэтому нам файрволл не нужен"
- защита должна быть достаточно разумной, чтобы не мешать работе и соответствовать рискам (т.е. не быть слишком дорогой).
Можете докидать еще пунктов.
Но административно выпилить все возможности для разработчика устанавливать софт == полностью парализовать его работу.Не обязательно. Достаточно разрешить использовать софт только из доверенного репозитория — и заявку на добавление софта туда. Да, конечно, security team неспособна обнаружить все закладки… но какой-то аудит они провести могут. Если речь идёт о софте ограниченного объёма. Могут предложить запустить софт в сандбоксе определённого вида. Делать же аудит на целый дистрибутив, которым кто-то один из разработчиков возжелал воспользоваться — это уже перебор.
Есть существенно бОльшая проблема — доверие к конкретным людям. Где гарантии, что они не будут сливать данные или внедрять в код проекта вредоносный код?Нет гарантий. Но тот факт, что если будет доказоно, что вредоносный код был внесён сознательно, то «небо в клеточку» на несколько лет почти гарантированно — сильно снижает риски.
А вот заставить подписать бумагу, где было бы написано, что за случайное нанесение ущерба будут такие последствия — во-первых гораздо сложнее, во-вторых — не факт, что вообще законно.
Потому запрещать выходить в BIOS не стоит (разработчику это может понадобится), но вести мониторинг этих действий — может быть полезно (на самом деле мониторится не факт захода в BIOS, а факт обращения к серверу, где хранятся периодически меняющиеся пароли для BIOS'а).
раз это демон, то очевидно, что его можно взломать или подделать.Да, разумеется — но тут мы уже попадаем в область необходимого для работы и допустимого с точки зрения безопасности… приходится всегда какой-то компромис искать…
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Пингвин, виртуализация и $23 млрд: как и почему облачные технологии навсегда изменили ИТ-мир