Источник

Мобильная радиосвязь впервые была использована более века назад, в далёком 1921 году, полицией Детройта (USA). Но первая коммерческая сеть появилась только в 1946-м. Компании AT&T и Bell Telephone Laboratories развернули радиосеть обслуживания своих абонентов в Сент Луисе (USA) и его пригородах. Для соединения вызывающий абонент сначала сообщал голосом оператору коммутатора, с кем он хочет говорить. Вес абонентского оборудования достигал 36 килограммов, и это без учёта источника питания, поэтому первые мобильные телефоны использовались преимущественно в автомобилях.

Фактически это был просто радиоудлинитель проводной линии. Спустя год Дуглас Ринг и Рей Янг (Bell Laboratories) предложили концепцию коммерческой сотовой связи, но до привычного нам сервиса было ещё очень далеко.

С развитием элементной базы, в первую очередь полупроводниковых элементов, размеры и вес оборудования быстро сокращались. Действующий прототип первого привычного нам аппарата создал Мартин Купер (Motorola) в 1973 году. В одном корпусе удалось разместить всё оборудование. Вес аппарата составлял около килограмма. Его ещё нельзя было носить в кармане, но элемент питания уже был внутри и обеспечивал его работу более 15 минут!

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

Теперь можно получать обработку информации в реальном времени (и реагировать гибко и сразу на те же действия на сайте или в приложении), в агрегации данных (теперь банк знает, где вы живёте, какие у вас были диагнозы по чекам из аптеки и какие интернет-магазины вы предпочитаете по адресам посещаемых сайтов, от стратегического альянса с провайдером или сотовым оператором) и так далее.

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

Самая частая ситуация — слияние-поглощение, когда вы купили конкурента, а у него куча старого, но ещё хорошего железа. А у вас уже облачный подход. Или когда вы настолько круты, что у вас есть P-машины IBM либо какие-то особенные хранилища (бывают у телестудий и медицинских центров). В любом случае вы столкнетесь с ситуацией, когда есть безопасники в облаке, есть департамент ИБ на вашей стороне и куча костылей — посередине.

По данным Garnter, есть вероятность 90 %, что вопрос переезда в облако коснётся вас в этом или следующем году, поэтому стоит задуматься над кибербезопасностью уже сейчас.

Ниже в статье — базовые вещи на тот случай, чтобы можно было легче договориться с провайдером о зонах ответственности и внедрить лучшие практики обеспечения информационной безопасности. Соответственно разделение зон ответственности и практики по ИБ мы используем в Техносерв Cloud для заказчиков с гибридными средами и потому знаем, что и где может пойти не так.

Банк аутсорсит свои проекты многим подрядчикам. «Внешники» пишут код, потом передают результаты в не совсем удобном виде. Конкретно процесс выглядел так: они передавали проект, который прошёл функциональные тесты у них, а затем тестировался уже внутри банковского периметра на интеграцию, нагрузку и так далее. Часто обнаруживалось, что тесты фейлятся. Тогда всё уходило обратно внешнему разработчику. Как вы можете догадаться, это означало большие сроки исправления ошибок.

Банк решил, что можно и нужно перетащить весь пайплайн к себе «под крылышко» от коммитов до выпуска. Чтобы всё было единообразно и под контролем команд, отвечающих за продукт в банке. То есть как если бы внешний подрядчик просто работал где-то в соседней комнате офиса. На корпоративном стеке. Это обычный девопс.

Откуда появилось Sec? Безопасность банка выставила высокие требования к тому, как внешний подрядчик может работать в сетевом сегменте, какой у кого доступ, как и кто работает с кодом. Просто ИБ ещё не знала, что когда подрядчики работают снаружи, мало какие банковские стандарты соблюдаются. А тут за пару дней надо их начать соблюдать всем.

Одно простое откровение, что подрядчик имеет полный доступ к коду продукта, уже перевернуло их мир.

В этот момент и началась история DevSecOps, про которую я хочу рассказать.

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

Чтобы оптимизировать затраты, нужно начать со сбора хорошей статистики. Я попробую вкратце описать подходящие для этого инструменты.

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

Рассмотрим ситуации, когда выгоднее фиксированные тарифы, а когда — pay-as-you-go-концепция (PAYG). Плюс рассмотрим, что можно выключить лишнего, и где чаще всего впустую расходуются ресурсы. Пройдёмся по основным видам ресурсов: CPU, RAM, виртуальным дискам, сети и бэкапам.

Рядом с двумя нашими зданиями, между которыми было 500 метров тёмной оптики, решили выкопать большую яму в земле. Для благоустройства территории (как завершающего этапа прокладки теплотрассы и строительства входа в новое метро). Для этого нужен экскаватор. С тех дней я не могу на них спокойно смотреть. В общем, случилось то, что неминуемо случается, когда в одной точке пространства встречается экскаватор и оптика. Можно сказать, что такова природа экскаватора и промахнуться он не мог.

В одном здании находилась наша основная серверная площадка, а в другом через полкилометра — офис. Резервным каналом был Интернет через VPN. Оптику мы положили между зданиями не по соображениям безопасности, не из банальной экономической эффективности (так трафик получался дешевле, чем через сервисы провайдера), а тогда — просто из-за скорости соединения. И просто потому, что мы те самые люди, которые могут и умеют класть оптику банкам. Но банки делают кольца, а при втором линке другим маршрутом вся экономика проекта посыпалась бы.

Собственно, именно в момент обрыва мы и перешли на удалёнку. В своём собственном офисе. Точнее, в двух сразу.

Любая крупная компания со временем сталкивается с проблемой появления неразберихи в применяемых методах, способах и средствах защиты информации.

Каждая компания решает проблему хаоса по-своему, но обычно одна из самых действенных мер — написание технического стандарта ИБ. Представьте, есть крупное производственное объединение, в которое входит несколько предприятий в разных местах страны, плюс обслуживающая инфраструктура: гостиница, ИТ-компания, транспортное депо, НПП, зарубежное представительство и столовые.

Первая задача — разобраться, что нужно защищать и как. Чтобы каждый руководитель как «отче наш» знал, какие конкретно меры защиты в отношении каких активов нужно принимать. Важно то, что набор применяемых мер защиты должен быть необходимым и достаточным. То есть безопасно и при этом в бюджете.

Вторая задача — стандартизовать технические решения. Каждая техническая мера защиты в идеале выполняется определённым образом с применением одного или нескольких конкретных средств. Если, например, применяете для защиты хостов антивирусы одного вендора, то можно с большей скидкой (из-за большого объёма) закупать лицензии, не надо держать штат специалистов, обладающих опытом работы с разными решениями. А если стандартизовать множество решений по ИБ, то можно создавать в разных компаниях похожие группы архитектуры и централизовать управление ими, тем самым практически отказаться от локальных подразделений.

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

Старый добрый советский светофор имеет два режима: работает и не работает. Его первая оптимизация — добавить в реле ночной и дневной режимы. Вторая — такая же: добавить утренний, вечерний и дневной, отличающиеся разными задержками таймера переключения ламп. И дальше — всё. Дальше нужны датчики и внешние потоки информации либо вообще связная сеть.

Самый простой пример того, что можно сделать, имея банальную индукционную петлю на дороге или инфракрасный датчик, — не переключать светофор на то направление, где сейчас никого нет. Это очень удобно в схеме «большая основная дорога через город и много второстепенных».

Но мы пошли чуть дальше: в городе Новомосковске (120 тысяч жителей) поставили на светофоры камеры, поменяли все контроллеры и связали всё это в одну сеть. Бюджет у города небольшой, поэтому правила пока эвристические без всякого космоса вроде data mining и машинного обучения, светофорных объектов не очень много (потому что даже поставить 21 камеру уже дорого), но мы смогли добиться вполне конкретных результатов.

Скорость прохождения перекрёстков с нашими «умными светофорами» и обычных перекрёстков рядом увеличилась. Мы научились приоритизировать поток машин утром на крупный завод, считать и обрабатывать транзитные фуры и даже замахнулись на ГЛОНАСС-датчики «скорой», чтобы убирать возможные заторы перед ними.

Оцените связки в средней части схемы. Ниже к ним вернёмся

В какой-то момент вы можете столкнуться с тем, что большие сложные сети на базе L2 неизлечимо больны. В первую очередь проблемами, связанными с обработкой BUM трафика и с работой протокола STP. Во вторую — в целом морально устаревшей архитектурой. Это вызывает неприятные проблемы в виде даунтаймов и неудобства управляемости.

У нас было два параллельных проекта, где заказчики трезво оценили все плюсы и минусы вариантов и выбрали два разных оверлейных решения, а мы их внедрили.

Была возможность сравнить именно реализацию. Не эксплуатацию, про неё стоит говорить года через два-три.

Итак, что такое сетевая фабрика с наложенными сетями и SDN?

Часто, когда я говорю кому-то про уязвимость, на меня смотрят как на сумасшедшего с табличкой «Покайтесь, ибо конец света близок»!

Сейчас все бегают в панике и пытаются организовать «удалёнку», совершая простейшие ошибки, собирая все возможные грабли, поэтому я решил поделиться некоторыми драматическими историями с участием цыганских хакеров, незакрытых CVE и профессиональных, но немного наивных девопсов. Конечно, какие-то детали мне пришлось опустить или даже намеренно исказить, чтобы не расстраивать заказчиков. По большей части это практика не с текущей работы в Техносерве, но пусть этот пост будет небольшой памяткой о том, как делать не надо, даже если очень хочется.

Пару лет назад мы чувствовали себя в каком-то сюрреалистическом сне. Все вокруг шли в облако для тестирования (удобно же разворачивать-сворачивать тестовые среды), а мы пытались выяснить, какие инструменты «из коробки» нужно поставлять. Для этого мы вместе с заказчиками разбирались, как устроены процессы девопса. И оказалось, что только единичные компании в России как-то грамотно применяют автоматизацию.

Сразу поясню, что мы по большей части общались или с теми, кто занимается разработкой в компании до 150–200 человек, или с производствами, где с ИТ традиционно тяжело. У компаний крупнее обычно есть и процесс, и собственное облако, и к нам они приходят за резервным размещением.

Производство обычно хорошо отлажено. Есть цикл, план релизов, есть цель, код идёт к цели вместе с разработчиками.

Тестирование и QA тоже хорошо отлажены чаще всего.

А между ними — пропасть. И её пытается заполнить DevOps. Этот супермен должен взять релиз (а в идеале — собрать в Дженкинсе или чём-то подобном), создать машину, развернуть там всё, проверить работу, может, провести пару претестов и отдать уже в QA.

Представьте себе обычный ситуационный центр по ИБ в крупной компании. В идеальном мире софт детектирует подозрительную активность, и команда «белых хакеров» начинает стучать руками по клавиатуре. И так происходит раз в месяц.

В реальном мире это сотни ложноположительных срабатываний и усталые сотрудники поддержки. Они вынуждены разбираться с каждым инцидентом, когда пользователь забыл пароль, не может скачать игру с торрента, очередной порнофильм в формате *.exe, смотреть за сбоями Сети и вообще расследовать множество ситуаций.

SIEM-системы помогают систематизировать и коррелировать события от источников. И генерируют срабатывания, с каждым из которых нужно разбираться. Из этих «каждых» большая часть — ложные. Можно подойти к вопросу и с другой стороны, заведя скрипты на обработку тревог. Каждый раз, когда что-то срабатывает, хорошо было бы иметь не просто причину тревоги, а потом лезть за разными данными в четыре-пять систем, а сразу автоматически собирать весь диагноз.



Мы сделали такую надстройку, и это очень помогло снизить нагрузку на операторов. Потому что сразу запускаются скрипты сбора информации, и если есть типовые действия — они сразу же предпринимаются. То есть, если завести систему «в такой ситуации делаем так и так», то карточка будет открываться для оператора с уже проработанной ситуацией.

Самое главное — тут после машзала подают горячие влажные салфетки, как в японских ресторанах. Это не имеет никакого отношения к технической части, но по-человечески приятно.

А это гитара с автографом Пола Маккартни, и да, она у них висит на входе в машзал:



У этого ЦОДа есть определённое настроение.

Выглядит всё это как огромный ангар в промзоне около метро «Отрадное». Высота ангара — 14 метров, внутри построен ЦОД высотой 9 метров. Оставшееся пространство играет роль теплоизолятора, что сказывается на местных особенностях охлаждения. Здание выбиралось так, чтобы не выходило на дорогу краями (по протоколам сертификации нельзя получить высокие уровни, если в машзал можно попасть на грузовике, протаранив стену, — видимо, были случаи), имело два разных маршрута заезда и было относительно недалеко от метро. Там же рядом открыли станцию МЦК, но дорога идёт по таким весёлым местам….

Мы делаем проект облака для разработки — платформу, способную максимально упростить жизнь девопсам, разработчикам, тестировщикам, тимлидам и другим вовлеченным в процесс разработки специалистам. Это продукт не для сейчас и не для завтра, и потребность в нём только-только формируется.

Основная идея — вы можете разворачивать конвейер с уже преднастроенными инструментами, но при этом с возможностью внесения целого ряда настроек, и вам останется только деплоить код.