Vitaly Karasik

Устроиться на работу программистом и как бы ненавязчиво продвигать CI/CD.

По двору прошелся жулик и попытался хакнуть эксплойтом для "майбаха" (условно) все тачки в вашем дворе. Майбахов не нашлось, этот жулик пошел дальше и забыл уже про ваш дворик.

Надо ли защищаться от атаки, не релевантной вашему сетапу? Не надо.
Надо ли делать выводы об уязвимости того или иного оборудования? Надо.
Надо ли проверять свои конфигурации на эксплойты? Надо.
Надо ли реагировать на всякую нерелевантную хрень в логах с ошибками порядка 400? Не надо.
Надо ли позаботиться об оркестрации быстрого развёртывания ваших серверов на случай взломов или проблем с железом? Конечно надо!

Вообще, если ваш сетап на виртуальных машинах в повторяемой среде и с декларативной конфигурацией вроде кубера или докера, то вы легче сможете пережить всякие такие факапы.
Схема такая.
Есть признаки взлома - бэкап логов, снапшот базы, бэкап стораджа, остановка сервисов (если позволяет продакшн), анализ атаки и последствий. Устраняем уязвимость по вектору атаки (гугление по логам и курение тредов), правим конфиги развёртывания и запускаем прод. Потом долго и тщательно разбираемся по логам, снапшотам и бэкапам что затронуто. Делаем тестовый чистый сетап по старой конфигурации и сравниваем пофайлово с атакованной системой, выясняем в какие места вмешались злодеи. Дифаем базу и смотрим на подозрительные различия. Делаем выводы, объявляем об утекших данных, если есть такие признаки (чтобы не подставлять пользователей), принимаем превентивные меры против похожих векторов атак.

Итого, залог успеха - это хранение конфигураций в гит-репозитории, своевременные бэкапы, хранение бэкапов на отдельных изолированных стораджах, оркестрация и автоматизация развертывания, подробное эшелонирование логирование с бэкапами логов, смоук тесты на нестандартную активность в БД, по сетевым интерфейсам, трафику, процессору, памяти, файловым системам, логам...

Это взгляд дилетанта по безопасности, если чего пропустил -- поправьте. Если где не прав -- расскажите.

Первое что нужно сделать - смотреть слоулог, или хотя бы завести его, если еще нету. Можно поставить мониторинг и анализ запросов в какой-нибудь Percona или что-то типа, посмотреть что вообще происходит. Потом уже можно говорить что что-то лишнее или не хватает.

1. Agile - это про то что люди должны договариваться. По тому надо не намёки делать, а говорить прямо и предметно.

2. Вот вы говорите, что вам нужно ТЗ. А зачем вам оно нужно?
Вам не понятна та постановка, которая описывается в карточках?
Есть неоднозначность?
Уже есть примеры, когда от этой неоднозначности пострадал продукт (например из-за необходимости переделывать)?

Или вам нужно не ТЗ, а виденье того, чем в итоге должен стать продукт?
Не понятно, для чего вообще все эти карточки перекладываются?
Если так, то, вероятно, вам нужно не ТЗ, а какие-то OKR-ы, чтобы можно было от них отталкиваться при составлении задач.

Возможно, произошла мискоммуникация между вами и заказчиком. Возможно, заказчик действительно ожидает от вас (команды) самостоятельности при составлении задач - по сути сочетание в себе и менеджера и аналитика.
Это нормально, но нужно этот момент тоже прояснить.

Для начала, следует научиться запускать бота где-то на сервере руками.
Потом описать инструкцию что для этого делается (новая папка, редактирование конфига, запуск бота).
Затем реализовать эти команды в скрипте, который вызывается нажатой в веб-интерфейсе кнопкой.

Вообще вопрос немного неясен. Ответ как бы элементарный - установка и настройка бота.
Детальный ответ тут больше будет как выполненная за вас работа, а в этом случае вам на фриланс

На исполняемый файл будет указывать симлинк /proc/<pid>/exe
Все открытые процессом в данный момент файлы можно получить командой lsof -p <pid> /
Еще можно посмотреть слинкованные библиотеки командой ldd /путь/к/исполняемому/файлу, но это далеко не всегда вам поможет.

Но если вы скажете, что именно хотите сделать, можно будет ответить точнее.

То, что вы описали, называется kiosk mode и в Windows 10+ он есть

В приведённом варианте openssl создаёт самоподписанный сертификат. На что и будут регулярные жалобы.
Прямой вариант - выпустить нормальный сертификат например на letsencrypt с цепочкой удостоверяющих центров и т.п.
Ну или как минимум имитировать подобное создав свой псевдоудостоверяющий центр:
ca сертификат и им подписать серт для гитлаба, но тогда придётся ca прописывать всем клиентам как trusted ca

Тебе нужно проанализировать статистику по негативным ответам проверки прокси.
Если большая часть ответов - это socket timeout - то сделай таймаут не 5 секунд а 0.5 секунды.

"Какой-то сертификат" и у фишингового сайта будет.
Если начать копать, внезапно окажется, что сам термин "официальный сайт" довольно размыт. У крупных IT-корпораций, например, число совершенно официальных сайтов может исчисляться десятками. А локальная мелочь может иметь только страничку во ВКонтакте...

Задачу проще решать от противного - выделять не официальные сайты, а фишинговые.
Собственно, Гугль это давно делает и предлагает список таковых в своем API.

Я знаю два сильных пути оптимизации в БД.

1) Минимизация IOps. Тоесть уменшить число дисковых чтений. Для таблиц это достигается через
partitions by date. Вычисляешь экспериментально оптимальный размер partition (например 1 неделя).
И твои запросы по диапазону должны попадать в 1-2 partitions. Это исключает full-table-scan.
Ну и индекс попробуй построить по предикатам фильтров.

2) Материализация ответов. Для данных которые уже не будут изменяться ты строишь где-то такую
табличку (матрицу по сути) где хранишь уже заранее расчитанные данные. Эта технология по разному
может называться. Materialized View. OLAP cubes. Витрины данных. Но суть одна.

start_date    end_date     result 
01-02-2023    03-02-2023   { "1":"65", "2":"45" }

И индекс по двум датам.

Если нормально сформулировать вопрос, то речь идет о банальном деплое
И автору бы сначала поучиться разворачивать свое единственное приложение, а потом уже начинать мечтать про междупланетный шахматный центр на тыщу инстансов.

При том что задача в общем случае решается элементарно. Добавлением еще одной секции в плейбук того же Ansible. Что даст автору ту самую заветную "одну кнопку". А точнее две - развернуть новый инстанс и обновить все существующие.

А если еще внимательнее посмотреть на проблему, то возникает закономерный вопрос - а зачем автору вообще миллион виртуальных хостов, если речь идет о банальных поддоменах? Которые прекрасно реализуются в рамках единственного виртуального хоста. То есть можно либо добавить поддержку субдомена в текущее приложение, либо, на худой конец, сделать multi-tenant приложение, где у каждого поддомена будет своя БД.
При этом вся кнопка будет заключаться в добавлении имени субдомена в базу данных