Архив метки: RHEL

Год с великого исхода западных вендоров: судьба специалиста

Год с великого исхода западных вендоров: судьба специалиста. С трудом уже верится, но раньше в РФ было возможно строить IT/ИБ системы, используя западные решения. 🙂 Более того, это был абсолютный мейнстрим. Как следствие, сотрудники российских компаний естественным образом развивались в крутых специалистов по продуктам Microsoft, Oracle, CISCO, PaloAlto, AWS, Tenable/Qualys/Rapid7 и т.д. 😉 Собирали комплекты вендорских сертификатов, выстраивали красивые CV-шки.

Безусловно, в этом была своя прелесть. Ты используешь те же решения, что и крупные компании во всем развитом мире, твои скилы также востребованы в общемировом масштабе. А значит релокация туда, где лучше, выглядит как вполне себе план Б (а у кого-то и как план А). Минусом шла привязка к западным вендорам и их судьбе в России. Но что с ними сделается-то? 😏

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

- продолжать делать то, что делали, а значит релоцироваться туда, где можно продолжать строить системы на западных решениях;
- остаться и строить системы на тех решениях, которые остались/появились в РФ;
- остаться, перестать строить системы и принять участие в копировании западных решений.

Релокация это всегда мероприятие на любителя. Тем более сейчас, когда "жить на 2 страны" стало совсем не так просто и комфортно. Переезд на запад теперь выглядит скорее как дорога в один конец.

Остаться и развиваться в чем-то другом это и потеря конкурентных преимуществ, и необходимость быстро учиться новому, и переход в новый локальный контекст. Опыт с Яндекс Клауд и Астра Линукс безусловно менее универсален, чем с AWS и RHEL. 🙂 Это нужно осознать и принять.

Никого не осуждаю, у всех свои ситуации. Но милей мне, безусловно, оставшиеся. Мы в одной лодке, выгребем. 🛶 🙂

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями?

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями?

Какие требования к вендорам отечественных Linux дистрибутивов можно было бы предъявить для упрощения Управления Уязвимостями? Если б я был регулятор. 🙂

1) Обновления безопасности должны быть. Критичная общелинуксовая уязвимость, должна быть пофикшена и в отечественном дистрибе. Или должно быть опубликовано обоснование, почему она неэксплуатируема.
2) Бюллетени безопасности должны быть. Клиенты должны как-то узнавать какую версию пакета нужно поставить, чтобы избавиться от критичной уязвимости.
3) Бюллетени безопасности должны быть публично доступны. Cпорный момент. Зависит от отношения к "security through obscurity". По мне закрытие доступ к бюллетеням усложняет жизнь исследователям, а злоумышленники все равно их получат через любого клиента.
4) Бюллетени безопасности должны быть доступны в машиночитаемом виде. Желательно в формате OVAL, раз уж он так распространен (RHEL, Suse, Ubuntu, Debian и даже отечественный RedOS)