Много факторов влияет на этот процесс. Начиная от невозможности настроить тикетницу, как вы верно заметили, до наличия (или отсутствия) политической воли для построения процесса формирования, заведения и обработки заявок.
Конкретно я сталкивался с тем, что контора в основном заточена под разработку, и поэтому разработчики типа как главные, и поэтому сразу эскалируют проблему выше, если пытаешься от них добиться/дождаться необходимой для выполнения заявки информации, или внедрить шаблон сбора информации. Типа, «IT-отдел отмазывается формальными требованиями и тормозит выкатку релиза в прод!» Бывало, что и до техдира долетало, который давал указание IT-отделу (а не разработчикам) «разобраться и настроить». В итоге инженер IT-отдела тратил кучу времени, погружаясь в суть проекта с технологическим стеком, который от инфраструктуры бесконечно далёк. И полностью строил матрицу сетевых коммуникаций для всех компонентов проекта. Из-за чего, кстати, колом вставали заявки других проектов.
Рассуждать на тему того, что «нужно правильно строить процессы» и т. п. можно бесконечно. Но это рассуждения в духе «лучше быть богатым и здоровым, чем бедным и больным». Т. е. про идеальный мир. А в реальности получается по-всякому.
Попытка программиста научить инженера инфраструктуры управлять этой самой инфраструктурой :-)
У команды разработчиков конкретного проекта — десяток виртуалочек, и они в памяти держат, где и что работает. А у инженера инфраструктуры счёт виртуалок идёт на тысячи. И существенная часть этих виртуалок разворачивается мимо отдела инфраструктуры. И в dev/test-окружениях всё как раз работает. Именно потому, почему я говорил — разработчики сами настраивали своё окружение, и настроили его именно так, как я и говорил — полные доступы между машинами, отключенные файрволы и рутовые права у всей команды. Хорошо ещё если не одна пошаренная учётка на всех.
А потом: «Аааа, у нас релиз!», всё это выезжает на продуктовую инфраструктуру, где микросегментация, и у них ничего не работает. Потому что после отключения файрволов разработчики даже не удосужились провести аудит коммуникаций между компонентами своих систем, и понятия не имеют, какие сетевые доступы и куда нужны. У них даже необходимости такой не возникало — ведь везде и всё разрешено. И ещё до кучи SELinux или AppArmor отключены.
И начинается: «А пропилите дырочку вот здесь! Это очень срочно, у нас завтра показ для Борис Иваныча!», «ААААА, у нас не деплоится, нет доступа между X и Y». Конечно, в такой обстановке не до следования шаблонам сбора информации, надо десятками строчить заявки в духе «Нет доступа», не прикладывая не то что обоснований — даже минимальных данных, позволяющих идентифицировать сущности и требуемые им доступы, нет.
Только тут речь идет о том, что виза ИБ в описанном вами случае — бюрократия.
Разрабатывая банковский софт, вы считаете подключение отдела ИБ к вопросу о доступах в прод инфраструктуре бюрократией… Ну ок, что сказать.
И что? Я рад что вы знаете такие аббревиатуры, какое отношение они имеют к нашему разговору?
То, что разрешение доступов определяется настройками DFW. Именно он разрешает или запрещает соединения, например. И это не такая уж чтобы простая штука, нужно понимать, что ты делаешь. И зачем.
Ну так мы возвращаемся к жалобам на закрытие заявок по формальным требованиям :-) Шаблон — это и есть формальные требования. И инженер имеет полное право перевести в «won't do» заявку, которая требованиям не соответствует. Автора поста это неприятно удивило, и судя по обсуждению выше, многие это удивление разделяют.
Ваша проблема в том, что вы стянули на себя слишком много ответственности и теперь рассказываете как горит попа.
Вы правда считаете, что это инженеры «стягивают на себя ответственность»?
Неужели у проекта, у которого сотни сетей, у которого свои схемы наименования нет людей, которые смогут справиться с раздачей доступа?
Нет, таких людей среди разработчиков и DevOps нет. Потому что их единственный подход: «открыть все доступы для всех и дать всем рутовые права».
А для чего? Нет, серьезно, для чего вам это?
Вы шутите, что ли? Как вы собираетесь решать заявку, сформулированную в духе «предоставить доступ к серверу oiqwkjhqwe314234»? Не указано — кому предоставить. Не указано, какой доступ. Не написано, что это за сервер и в какой сети находится. Как вы собираетесь это решать?
Плюс ко всему, любые разрешения доступов должны быть завизированы ИБ. И в ЛЮБОМ СЛУЧАЕ, автор заявки должен эту информацию предоставить, т. к. без э того визу у ИБ не получить.
Ну например, чтобы доступ к серверу, если команда развернула свои виртуалки мог дать тот же самый инженер, который этот сервер развернул? Вы то тут при чем?
Я не знаю, кем вы работали в Дойче, но похоже, вы совершенно не представляете, как устроены большие инфраструктуры :-) Какой доступ на управление нужно предоставлять человеку, который является DevOps инженером, и максимум что он знает — это как развёртывать виртуалки в vSphere. Но понятия не имеет, что такое, например, NSX DFW, как он работает, где и по каких схемам предоставляются разрешения. А если требуются доступы между ЦОДами? Предлагаете разработчикам и инженерам девопс предоставить доступ на управление ядром сети? На оборудование, в котором они ни уха, ни рыла? Серьёзно?
Ну и кроме этого, могу повторить то, о чём сказал выше — есть доступами рулить будут сами разработчики или девопсы, то в итоге файрволы будут отключены вообще, и всем сотрудникам отделов будут заведены учётки на серверах, с рутовыми правами. А то и вообще все будут под одной учёткой ходить.
При чём тут «злые языки»? Почитайте про «Мюнхенский сговор», особенно обратив внимание на вопросы, касающиеся территорий. А также можно обратить внимание на даты событий. Когда был Мюнхенский сговор, и когда — пакт Молотова-Риббентропа.
Ну это действительно довольно часто встречающееся явление в крупных компаниях. Про тот же Яндекс тоже много полярных отзывов, от полного восторга до полного же трэша. Очень многое зависит от подразделения.
То, что исполнители запросов могут Ваш запрос закрыть по формальному признааку, правда. Но почему Вас удивляет, что среди 300 тысяч сотрудников есть лентяи и кого-то иногда скашивает комплекс вахтера?
Как человек, к которому часто прилетают подобные заявки, могу пояснить, почему я так иногда делаю. Заявок — сотни, есть определённые требования по SLA, а у инженеров помимо саппорта пользователей есть ещё и проектные задачи. Короче, попа в мыле, выражаясь литературным языком. И когда прилетает заявка в духе: «Прошу предоставить доступ к серверу „op45-frq114“, то есть два пути:
Тратить своё и так до предела спрессованное время на переписки с целью выяснения:
кому нужен доступ (т. к. если заявка от руководителя подразделения, то может статься, что доступы нужны не ему, а одному из его сотрудников);
откуда нужен доступ?
что это за сервер? (команды часто разворачивают свои виртуалки, имеют свои схемы именования, которые неизвестны инженерам, отвечающим за сетевую инфраструктуру);
по каким портам/протоколам нужен доступ?
на какой срок?
Закрыть заявку, т. к. конкретно этому человеку/подразделению уже 15 раз сказали, что следующая заявка, сформулированная подобным образом, будет просто закрыта ввиду недостатка информации для её решения. И если они хотят, чтобы их заявки делались, и делались в срок — пусть сразу предоставляют всю необходимую информацию.
А выяснять все эти подробности — бывает очень, очень долгим процессом. Иногда по объективным причинам, иногда — по субъективным. Объективные — это ты открываешь заявку, смотришь, что информации недостаточно, и задаёшь вопросы. Проходит какое-то время, пока автор заявки дойдёт до письма из тикетницы, прочитает и найдёт время ответить. Потом заявка ждёт, когда у меня в очередной раз дойдут до неё руки. Я прочитаю ответ, и как правило, информации опять недостаточно. Ну например, спрашиваешь, что за сервер, и в какой сети находится. Автор заявки отвечает: „Сервер отчётов проекта такого-то находится в сети площадки такой-то“. А я в душе не знаю, что это за проект, а сеть „той площадки“ — это около полутора сотен различных подсетей.
P/S/: Я не сотрудник Сбера или СБТ, если что, просто есть опыт работы инженером по инфраструктуре в крупных компаниях.
Почему не тянет?
«However, your full fingerprint is unique among the 907907 collected so far.» — полный профиль вашей системы уникален среди миллиона уже собраных профилей.
А виртуализация какая? Оно не умеет, как ESXi, делать promisc-порты в нужном влане? Это позволило бы без trafr обойтись, а напрямую в сурикату копию WAN-трафика WAN отдать.
Поддерживаю. Лично боролся с адварью в планшетах Oysters T72X и в каком-то Prestigio (знакомые приносили). Причём для Oysters прошивку качал с официального сайта. Там адварь сидела во встроенном приложении Youtube, и регулярно то софт ставила, то левые рекламные вкладки в браузере открывала.
Снапшоты, компрессия, дедупликация (правда, это очень специфическая фича, дома не нужно использовать), возможность увеличения объёма пула на лету (путём добавления дисков или замены дисков на более ёмкие), возможность хранения блоков отдельных датасетов в нескольких местах (настраиваемый replica factor на уровне датасета), ARC, возможность организации тонких блочных хранилищ (это скорее в сценарии хранилища под виртуализацию).
С точки зрения финансов этот закон реализовать просто невозможно. Например, при внешней полосе в 40 Гбит (скорость одного из крупнейших независимых провайдеров Москвы) для хранения трафика за месяц потребуется хранилище на 12 пебибайт. Стоимость только оборудования под эту систему хранения, по самым скромным оценкам будет составлять около 45 миллионов рублей.
И это не считая вопросов её эксплуатации, а также того, что граничные маршрутизаторы, как правило, могут находиться в нескольких точках обмена трафиком. Т. е. система хранения должна быть представлена в нескольких, географически разделённых местах.
Что делать какому-нибудь Ростелекому или Билайну — я вообще не представляю.
Возможно, ситуацию могла бы облегчить дедупликация, но с учётом объёма шифрованного трафика ничем она не поможет. В общем, закон полностью бредовый, и нереализуемый просто из-за объёма денег, который потребуется, чтобы создавать системы хранения подобных масштабов.
Как написали выше — при больших масштабах свои мощности становятся выгоднее, по многим аспектам. Финансы, больше контроля, безопасность. Как ни крути, своя сеть имеет более чётко очерченый периметр, чем сеть сервис-провайдера, в которой мало ли кто шарится — и пользователи размещённых сервисов снаружи, и «соседи» по аренде инфраструктуры.
Да и «нельзя просто так взять и поменять платформу». Смена поставщика для инфраструктуры — это всегда куча работы. Посчитать всё, продумать инфраструктуру в новых условиях, запилить тестовую инфраструктуру, расписать тестовые сценарии, прогнать их, переписать уже написанные скрипты деплоя/мониторинга/управления с учётом новых реалий и API другой облачной платформы. И если всё равно этим заниматься, то лучше уж действительно мигрировать на своё.
Вам не кажется, что это несколько не логично? Вы предъявляете претензии к СКАНЕРАМ, а в качестве альтернативы сигнатурному анализу рекомендуете песочницы. Но песочницы — это уже другая технология из комплекса мер противодействия угрозам ИБ. И свои минусы у неё тоже есть — например, большое время обработки файла по сравнению со сканером по сигнатурам.
Реализованы по-разному — что-то пытается разматывать потенциально вредоносные файлы локально, что-то — отправляет в облака вендора, и решение о рисках принимается уже там. Но факт в том, что они есть. Правда, не очень понял, почему вы считаете, что там нет «обнюхивателя» :-) Для чего же тогда песочница вообще нужна, как не для этого самого?
Идея не нова, что касается революционных решений — извините, а с каких пор идеи генерирует пользователь, платящий за лицензии, а не разработчик, получающий зарплату? ;)
Ну так если идея действительно окажется революционной, то вы можете неплохо поправить материальное благосостояние :-)
У сканеров нет другой возможности детектить вирусы, кроме как по сигнатурам. Открою страшную тайну — практически все системы анализа трафика или дискового содержимого делают это по сигнатурам. И SIEM'ы многие на сигнатурах работают.
Поэтому обеспечение безопасности — это комплексный процесс. От обучения пользователей не кликать на посторонние ссылки в левых письмах, до антивирусов, песочниц, DPI и SIEM.
Всем известно, что детект по сигнатурам полон недостатков, но пока никому ничего лучше придумать не удалось. Если у вас есть какие-то идеи, которые позволят выкинуть сигнатурный анализ на свалку истории — так поделитесь :-)
Технически — реалистичен вполне. Но, зная как идут дела в Мегафоне и связанных с ним операторах — я бы поставил на то, что конкретно этот инцидент является следствием кривых рук.
Конкретно я сталкивался с тем, что контора в основном заточена под разработку, и поэтому разработчики типа как главные, и поэтому сразу эскалируют проблему выше, если пытаешься от них добиться/дождаться необходимой для выполнения заявки информации, или внедрить шаблон сбора информации. Типа, «IT-отдел отмазывается формальными требованиями и тормозит выкатку релиза в прод!» Бывало, что и до техдира долетало, который давал указание IT-отделу (а не разработчикам) «разобраться и настроить». В итоге инженер IT-отдела тратил кучу времени, погружаясь в суть проекта с технологическим стеком, который от инфраструктуры бесконечно далёк. И полностью строил матрицу сетевых коммуникаций для всех компонентов проекта. Из-за чего, кстати, колом вставали заявки других проектов.
Рассуждать на тему того, что «нужно правильно строить процессы» и т. п. можно бесконечно. Но это рассуждения в духе «лучше быть богатым и здоровым, чем бедным и больным». Т. е. про идеальный мир. А в реальности получается по-всякому.
У команды разработчиков конкретного проекта — десяток виртуалочек, и они в памяти держат, где и что работает. А у инженера инфраструктуры счёт виртуалок идёт на тысячи. И существенная часть этих виртуалок разворачивается мимо отдела инфраструктуры. И в dev/test-окружениях всё как раз работает. Именно потому, почему я говорил — разработчики сами настраивали своё окружение, и настроили его именно так, как я и говорил — полные доступы между машинами, отключенные файрволы и рутовые права у всей команды. Хорошо ещё если не одна пошаренная учётка на всех.
А потом: «Аааа, у нас релиз!», всё это выезжает на продуктовую инфраструктуру, где микросегментация, и у них ничего не работает. Потому что после отключения файрволов разработчики даже не удосужились провести аудит коммуникаций между компонентами своих систем, и понятия не имеют, какие сетевые доступы и куда нужны. У них даже необходимости такой не возникало — ведь везде и всё разрешено. И ещё до кучи SELinux или AppArmor отключены.
И начинается: «А пропилите дырочку вот здесь! Это очень срочно, у нас завтра показ для Борис Иваныча!», «ААААА, у нас не деплоится, нет доступа между X и Y». Конечно, в такой обстановке не до следования шаблонам сбора информации, надо десятками строчить заявки в духе «Нет доступа», не прикладывая не то что обоснований — даже минимальных данных, позволяющих идентифицировать сущности и требуемые им доступы, нет.
Разрабатывая банковский софт, вы считаете подключение отдела ИБ к вопросу о доступах в прод инфраструктуре бюрократией… Ну ок, что сказать.
То, что разрешение доступов определяется настройками DFW. Именно он разрешает или запрещает соединения, например. И это не такая уж чтобы простая штука, нужно понимать, что ты делаешь. И зачем.
Вы правда считаете, что это инженеры «стягивают на себя ответственность»?
Нет, таких людей среди разработчиков и DevOps нет. Потому что их единственный подход: «открыть все доступы для всех и дать всем рутовые права».
Вы шутите, что ли? Как вы собираетесь решать заявку, сформулированную в духе «предоставить доступ к серверу oiqwkjhqwe314234»? Не указано — кому предоставить. Не указано, какой доступ. Не написано, что это за сервер и в какой сети находится. Как вы собираетесь это решать?
Плюс ко всему, любые разрешения доступов должны быть завизированы ИБ. И в ЛЮБОМ СЛУЧАЕ, автор заявки должен эту информацию предоставить, т. к. без э того визу у ИБ не получить.
Я не знаю, кем вы работали в Дойче, но похоже, вы совершенно не представляете, как устроены большие инфраструктуры :-) Какой доступ на управление нужно предоставлять человеку, который является DevOps инженером, и максимум что он знает — это как развёртывать виртуалки в vSphere. Но понятия не имеет, что такое, например, NSX DFW, как он работает, где и по каких схемам предоставляются разрешения. А если требуются доступы между ЦОДами? Предлагаете разработчикам и инженерам девопс предоставить доступ на управление ядром сети? На оборудование, в котором они ни уха, ни рыла? Серьёзно?
Ну и кроме этого, могу повторить то, о чём сказал выше — есть доступами рулить будут сами разработчики или девопсы, то в итоге файрволы будут отключены вообще, и всем сотрудникам отделов будут заведены учётки на серверах, с рутовыми правами. А то и вообще все будут под одной учёткой ходить.
Как человек, к которому часто прилетают подобные заявки, могу пояснить, почему я так иногда делаю. Заявок — сотни, есть определённые требования по SLA, а у инженеров помимо саппорта пользователей есть ещё и проектные задачи. Короче, попа в мыле, выражаясь литературным языком. И когда прилетает заявка в духе: «Прошу предоставить доступ к серверу „op45-frq114“, то есть два пути:
А выяснять все эти подробности — бывает очень, очень долгим процессом. Иногда по объективным причинам, иногда — по субъективным. Объективные — это ты открываешь заявку, смотришь, что информации недостаточно, и задаёшь вопросы. Проходит какое-то время, пока автор заявки дойдёт до письма из тикетницы, прочитает и найдёт время ответить. Потом заявка ждёт, когда у меня в очередной раз дойдут до неё руки. Я прочитаю ответ, и как правило, информации опять недостаточно. Ну например, спрашиваешь, что за сервер, и в какой сети находится. Автор заявки отвечает: „Сервер отчётов проекта такого-то находится в сети площадки такой-то“. А я в душе не знаю, что это за проект, а сеть „той площадки“ — это около полутора сотен различных подсетей.
P/S/: Я не сотрудник Сбера или СБТ, если что, просто есть опыт работы инженером по инфраструктуре в крупных компаниях.
Почему не тянет?
«However, your full fingerprint is unique among the 907907 collected so far.» — полный профиль вашей системы уникален среди миллиона уже собраных профилей.
… либо испонитель смог как-то рационализировать рабочий процесс, что привело к его (процесса) ускорению.
И это не считая вопросов её эксплуатации, а также того, что граничные маршрутизаторы, как правило, могут находиться в нескольких точках обмена трафиком. Т. е. система хранения должна быть представлена в нескольких, географически разделённых местах.
Что делать какому-нибудь Ростелекому или Билайну — я вообще не представляю.
Возможно, ситуацию могла бы облегчить дедупликация, но с учётом объёма шифрованного трафика ничем она не поможет. В общем, закон полностью бредовый, и нереализуемый просто из-за объёма денег, который потребуется, чтобы создавать системы хранения подобных масштабов.
Там ключ можно сгенерировать самому, и отдать только CSR.
Да и «нельзя просто так взять и поменять платформу». Смена поставщика для инфраструктуры — это всегда куча работы. Посчитать всё, продумать инфраструктуру в новых условиях, запилить тестовую инфраструктуру, расписать тестовые сценарии, прогнать их, переписать уже написанные скрипты деплоя/мониторинга/управления с учётом новых реалий и API другой облачной платформы. И если всё равно этим заниматься, то лучше уж действительно мигрировать на своё.
Песочницы, разумеется, есть уже если не во всех, то в большинстве современных антивирусов: safe.cnews.ru/news/top/kasperskij_obzavelsya_pesochnitsej
Реализованы по-разному — что-то пытается разматывать потенциально вредоносные файлы локально, что-то — отправляет в облака вендора, и решение о рисках принимается уже там. Но факт в том, что они есть. Правда, не очень понял, почему вы считаете, что там нет «обнюхивателя» :-) Для чего же тогда песочница вообще нужна, как не для этого самого?
Ну так если идея действительно окажется революционной, то вы можете неплохо поправить материальное благосостояние :-)
Поэтому обеспечение безопасности — это комплексный процесс. От обучения пользователей не кликать на посторонние ссылки в левых письмах, до антивирусов, песочниц, DPI и SIEM.
Всем известно, что детект по сигнатурам полон недостатков, но пока никому ничего лучше придумать не удалось. Если у вас есть какие-то идеи, которые позволят выкинуть сигнатурный анализ на свалку истории — так поделитесь :-)