27
окружение, а потом по ошибке из production окружения попробовал под-
ключиться на такую же машину из соседней группы. Доступ ему не был
предоставлен, а уже через 5 минут его учётная запись была заблокирована,
а на рабочий телефон поступил звонок от сотрудника безопасности. Вот
такая история.
Дополнительно, как часть работ по обеспечению безопасности,
постоянно ведётся сканирование внутренних разработок, настройка и
запуск статических анализаторов поиска уязвимостей на кодовой базе
проектов.
Третья ветвь работы отдела информационной безопасности компа-
нии – это непосредственно работа с сотрудниками. Сюда входит: создание
обучающих материалов, в том числе и видеоматериалов для сотрудников
всех отделов, семинары, вводные и расширенные курсы информационной
безопасности, внутренние проверки. Так, например, в октябре на весь
месяц проводился ”Hactober”, суть которого заключалась в том, что со-
трудниками отдела безопасности были подготовлены различные векторы
атаки на отделы компании с целью проверки сотрудников. Все сотрудники
были оповещены о проходящих акциях, но даже этого было не достаточно.
По итогам ”Hactober” Vice President отдела безопасности озвучил неутеши-
тельные результаты. С его слов, даже небольшой ошибки по невниматель-
ности одного сотрудника достаточно, чтобы нанести компании, её финан-
сам, её имиджу существенный ущерб. А количество подобных инцидентов,
с вектором направленным на сотрудников, с каждым годом значительно
растёт. Поэтому приоритет отдела будет направлен в область работы с
сотрудниками.
В контексте данной дипломной работы службой информационной
безопасности компании были проведены работы по всём направления. На-
чиная с недельного курса основ информационной безопасности при проек-
28
тировании информационных систем, правилам обеспечения безопасности
пересылаемых по сети данных, особенно чувствительные данные поль-
зователей. Так же на созданный репозиторий были настроены системы
статического анализа кода,а используемые библиотеки проанализированы
на наличие известных уязвимостей.
С целью подтверждения отсутствия передачи третьим лицам данных
пользователей, служба безопасности провела полный аудит подготовлен-
ного проекта.
29
1.3 Анализ существующих разработок и выбор стратегии автома-
тизации ”КАК ДОЛЖНО БЫТЬ”
Для возможности внедрения проект должен соответствовать следу-
ющим предъявленным требованиям:
1. Отсутствия влияния на текущее mail-flow;
2. Высокая производительность решения, способная поддержать ре-
альную нагрузку. Передача данных в реальном времени;
3. Экономическая рентабельность;
1.3.1 Анализ возможных средств для решения задачи
В современных реалиях продуктовой разработки прежде чем при-
ступать к написанию свои собственных велосипедов необходимо провести
тщательный и доскональный разбор и анализ существующих на текущее
время решений. Вполне возможно, что подобные решения уже существуют
и не в едином исполнении, под любой вкус и цвет. Найденные решения
необходимо тщательно проанализировать на соответствие поставленным
требованиям по решаемой задаче. И даже если в итоге будет принято ре-
шение реализовывать собственный программный продукт, то полученный
ранее опыт и знания предыдущих коллег по цеху, о проблемах с которыми
предстоит столкнуться и способах их решения, позволит избежать боль-
ших накладных расходов при проектировании и реализации, и значительно
снизит риски.
Изначально реализацию задачи можно поделить на две независимые
группы.
Первая группа — по способу передачи информации от почтового
сервера к реализуемому программному компоненту:
– TCP — встроенными средствами почтового сервера
30
– UDP — парсинг журнальный записей(логов) почтовых серверов
Вторая группа — по платформе или языку программирования, на
базе которой будет реализовываться программный продукт:
– Использовать Milter на Perl, приложенный в документации партнёра
(Только STDIN);
– Использовать имеющийся на серверах milter на базе Java c подклю-
чённым расширением на Lua (Только TCP);
– Реализовать отдельный сервер на Python;
– Реализовать отдельный сервер на Golang;
Разберём отобранные решения в разрезе предъявленных требований.
1. Первым и ключевым требованием является – отсутствие влияния
(негативного) на текущее mail-flow. Другими словами итоговое решение не
должно нарушать существующую систему или как-то замедлять обработку
письма на почтовом сервере во время отправки необходимой информации
партнёру.
На платформу реализации ответной части данное требование не
накладывает никаких ограничений, поэтому данное требование рассмат-
риваем только со стороны способа передачи данных.
Встроенные средства почтового сервера позволяют асинхронно пе-
редать всю необходимую информацию по TCP и не дожидаясь ответа
закрыть соединение. Достоинством данного подхода является то, что он
гарантирует передачу всех необходимых данных единым запросом и суще-
ственно облегчает разработку ответной части сервиса. Недостатком этого
подхода является то, что на каждое пришедшее соединение почтовый
сервер будет создавать новое TCP соединение для передачи сервисной
информации ответной части. Создание TCP соединения крайне дорогосто-
ящая операция.
31
Другой подход предписывает, что ответная часть должна быть спо-
собна принять журнальные сообщения по UDP. Это накладывает следую-
щие ограничения:
– UPD не предоставляет гарантии передачи данных;
– Требуемая информация разбита на несколько слабосвязанных сооб-
щений (2-3);
– Требуются дополнительные ресурсы CPU/разработка/тестировани-
е/отладка для получения информации из лог-сообщений;
Всё выше перечисленное накладывает повышенные требования и силь-
но усложняет итоговую реализацию ответной части. Однако к достоин-
ствам можно отнести тот факт, что этот подход полностью соответствует
предъявленному требованию и облегчает поддержку итогового решения.
В случае возникновения проблем – нет необходимости как-либо изменять
конфигурацию почтовых серверов, перезагружать их, или каким-либо ещё
способом влиять на их работу. Достаточно перекрыть UDP-канал передачи
данных.
2. Второе требование в отличии от первого предъявляется к платфор-
ме.
Первое решение, представленное в документации партнёра пред-
ставляет из себя скрипт на Perl, который запускается почтовым сервером
на той же самой машине. Сервер ждёт когда скрипт отработает и не
зависимо от результата закрывает соединение. Изящество этого решения
заключается в том, что исходный код занимает чуть более полусотни строк
(66), а результат его выполнения уже провалидирован партнёром. Однако
недостатки этого подхода перекрывают все описанные достоинства. И од-
ним из самых ключевых недостатков, который не позволяет использовать
данный подход, является то, что скрипт должен запускается почтовым
32
сервером на той же самой машине, что априори противоречит первому
предъявленному требованию 1.. Остальные недостатки:
– Медленно. Непозволительно медленное при проектном уровне на-
грузки. Запуск интерпретатора Perl и всей машинерией связанной со
стартом нового системного процесса (выделение памяти, файловых
дескрипторов и т.д.)
– Не контролируемо. Единственный способ получить результат вы-
полнения - коды ошибок в логах почтового сервера.
– Замедляет обработку письма. Серверу необходимо дождаться завер-
шения исполнения скрипта. Не говоря уже о том, что работа скрипта
будет отнимать процессорное время у почтового сервера.
Вторым решением является подключаемым расширением на Lua для
milter реализованным на Java. Это решение лишено большинства недостат-
ков первого, не идеально. Рассмотрим подробнее.
Исполняемая среда при помощи собственного интерпретатора Lua и
Jit-компиляции запускает исполняемые процедуры в отдельных системных
потоках. Это решает проблему производительности и маштабирования.
Однако,так как milter работает на том же сервере, что и почтовый сервер,
высокая нагрузка и большое кол-во дополнительно запущенных систем-
ных потоков негативно влияет на работу всего сервера. Так же этот подход
не решает проблемы связанной с мониторингом, отсутствует гибкость в
принятии решения относительно передачи данных.
Третье решение представляет из себя реализацию нового сервиса на
Python. Python в свою очередь является главным языком программирова-
ния в команде, а это значит, что имеется высокая экспертиза, в отличии
от Perl или Lua. Помимо этого, это решает проблемы с мониторингом,
обработкой ошибок и выбором сетевой основы для реализации (TCP/UDP).
Однако тут имеются и свои недостатки:
33
– Время на разработку и тестирование. Как не странно реализация
собственного решения требует разработки с нуля.
– Производительность. Python интерпретируемый скриптовый язык,
целью разработки которого никогда не была высокая производитель-
ность.
– Маштабируемость. Необходимо запускать несколько процессов-
обработчиков для проектной нагрузки.
– Нюансы при мониторинге. В связи с принципами маштабирования
Python-приложений данная задача становится не тривиальной.
Четвёртое решение — реализация нового сервиса на компилируемом
высокоуровневом языке программирования Go(Golang) Данное решение
имеет практически те же самые достоинства и недостатки, что и преды-
дущее, связанные с разработкой нового сервиса. Однако имеет и свои
дополнительные, очень важные нюансы, связанные с платформой. Как
положительные, так и отрицательные.
Положительные:
– Производительность. Язык Go – статически типизированный и ком-
пилируемый, что делает программы на нём в десятки раз произво-
дительнее, чем на Python. При этом они так же требуют меньше
ресурсов.
– Маштабируемсть. Go современный язык программирования спро-
ектированный для работы многопроцессорных сестемах с большим
количеством ядер и потоков. Он не требует запуска дополнительный
системных процессов-обработчиков.
Отрицательные:
– Отсутствие экспертизы. Никто в команде с этим языком раньше не
работал.
– Усложнения экосистемы новыми инструментами.
– Повышенные риски при разработке и поддержке.
34
3. Третье требование — экономическая рентабельность накладывает
ограничения на представленные варианты реализации по следующим двум
основным пунктам:
– Сложность и дороговизна разработки, дополнительные риски при
разработке.
– Сложность и дороговизна поддержки, дополнительные риски при
поддержке.
Первая группа — по способу передачи данных:
– TCP – Существенно облегчает разработку и снижает сложность ре-
ализации.(В числовом представлнеии с месяца до недели). Но имеет
негативное влияние на поддержку. Как пример включение/отклю-
чение передачи данных на почтовых серверах, требует дополни-
тельных человеческих ресурсов и повышает риски дестабилизации
текущего mail-flow;
– UDP – Вдвое увеличивает сроки разработки и втрое сложность ито-
гового решения. Но не несёт практически никаких дополнительных
затрат на поддержку. Для отключения передачи данных требуется
нажать только одну кнопку, что никак не влияет на почтовые сервера.
Вторая группа — по платформе:
– На безе Perl скрипта. Не требует никакой разработки, но абсолютно
не пригодно для поддержки.
– На базе Lua расширения. Требует дополнительной разработки на не
профильной технологии; с серьёзными ограничениями к реализации
под имеющуюся платформу. Очень требовательно к поддержке как в
части внедрения/включения/отключения, так и в части дополнитель-
ного мониторинга;
– На базе Python. Самые низкие риски при разработке благодаря высо-
кой экспертизе. Но не минимальные, из-за отсутствия статической
35
типизации и принципам маштабирования. Низкие требования при
поддержке в плане людских ресурсов, но высокие в плане машинных.
– На базе Golang. Минимальные риски при разработке, тестировании
и поддержке связанные с особенностями языка. Такими как: строгая
статическая типизация, минималистичный синтаксис, простота обу-
чения. Так же низкие требования к машинным ресурсам.
1.3.2 Выбор и обоснование средства для решения задачи
Проведённый глубокий и детальный анализ в разрезе предъявленных
требований существенно упрощает выбор. Главным критерием является
максимальное соответствие требованиям. Первым кандидатом на вылет
является существующее решение предложенное в документации партнёра
– Perl-скрипт. Решение не соответствует большинству требований, ограни-
чивает возможности реализации и противопоказано к внедрению. Однако
разбор и анализ данного решения чрезвычайно познавателен в ключе:
а) Оценки других подходов;
б) Валидации и верификации итогового результата;
в) Общих принципов подготовки и обработки сообщений для отправки;
Хотя большая часть подходов и исходного кода совершенно неприме-
нима для решения поставленной задачи, разбор существующего решения,
как и было сказано выше, позволил в дальнейшем избежать части неожи-
данных и непредвиденных проблем.
В выборе между способами передачи данных от почтовых серверов
к новому приложению выбор пал на сокращение рисков при поддержке
решения, а не его разработки. Другими словами был выбран путь через
передачу данных в лог-сообщениях по UDP. Ключевым фактором для это-
го стало то, что для отправки данных через TCP, каждый раз создавалось
новое соединений. В рамках текущего проекта подобная реализация слиш-
36
ком ресусозатратна и несёт в себе скрытые риски. Такие как, например,
создание вдвое большего количества TCP соединений на одно письмо,
нежели чем было изначально. Количество файловых дескрипторов хоть и
велико, но не безгранично и трудно предсказать как быстро при текущей,
или возросшей нагрузке они закончатся. Данный поворот событий хоть
и мало вероятный, но ещё на этапе проектирования его хотелось бы
избежать.
В выборе между платформой и языком программирования для реа-
лизации было решено остановиться на написании нового сервера на языке
Go(Golang). Причина всё та же – как можно больше сократить издержки
на поддержку, как в плане человеческих, так и машинных ресурсов. Оп-
позиционным данному решению было решение на Python, но как было
сказано выше, решение на Python в десятки раз менее производительно
и требовательно к ресурсам. Чего так же хотелось избежать еще на этапе
проектирования, ведь чем меньше средств будет потрачено на издержки
по поддержке итогового результата, тем рентабельнее будет сам результат
проекта.