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

Самая частая ситуация — слияние-поглощение, когда вы купили конкурента, а у него куча старого, но ещё хорошего железа. А у вас уже облачный подход. Или когда вы настолько круты, что у вас есть 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.

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

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

Самая большая голова Ленина в мире. Площадь Советов в Улан-Удэ

Когда ты берёшься за проект длиной два года с географией по всей стране, то ждёшь, проблем с согласованием, странных отношений с контрагентами, грузчиков с серверами в руках, непредоставленных портов по ТЗ и много другого. К этому меня жизнь готовила: всё это прекрасно описано в методологии подготовки проект-менеджеров.

Всё было не зря.

Такие истории очень хорошо рассказывать через пару лет в курилке, но не встречать на проектах.

Представьте себе человека, ночью выбегающего с криками из офисного центра и начинающего ломать бордюр. Женя раскачал камень ногами, оторвал его и занёс на руках назад в здание.



Этим наш дорогой коллега решал одну ИТ-проблему. Дело в том, что мы оснащали серверный узел в здании (маленький ЦОД на 20 стоек) серверами. Во время работ фальшпол начал гнуться — медленно так, с треском и вообще как в фильмах ужасов. Это оттого, что рядом поставили блоки ИБП, по 20 килограмм на юнит. Не проверив допуски.

Чтобы не было эффекта домино, Женя принял решение повытаскивать батарейные блоки. Это не особо помогло. Но с помощью бордюрного камня удалось чуть замедлить процесс. Ещё через час приехала команда подрядчиков, строивших этот ЦОД, с примерно 30 домкратами из автомагазина для ремонта. Три недели переделывали, только потом мы смогли продолжить.
В общении с иностранными коллегами мы описываем это как surprisingly amazing. Со своими есть более точный термин — «клоунада».

Воланд у М. Булгакова говорил, что «кирпич ни с того ни с сего никому и никогда на голову не свалится». Может, и так, но, когда два с половиной года назад меня спросили, хочу ли я познать OpenStack, это был тот самый хорошо завуалированный кирпич (а на старте даже не кирпич, а гранитная плита). Именно 2016 год стал для меня так называемой «точкой невозврата», положив начало стремительному освоению концепций открытого мира и в значительной степени повлияв на менталитет, – превратив мою дальнейшую жизнь в праздник. «Праздник», который всегда со мной.

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

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

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

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

Поэтому давайте чуть подробнее поговорим про некоторые риски проектов возросшие в последние годы. Часть из них не нова. Некоторые в реалиях нынешнего ИТ-рынка приобрели новые формы, окраску и монструозные черты.