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