• У меня гибридное облако. Кто отвечает за ИБ, и какие новые угрозы появляются?

      image

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

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

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

      Ниже в статье — базовые вещи на тот случай, чтобы можно было легче договориться с провайдером о зонах ответственности и внедрить лучшие практики обеспечения информационной безопасности. Соответственно разделение зон ответственности и практики по ИБ мы используем в Техносерв Cloud для заказчиков с гибридными средами и потому знаем, что и где может пойти не так.
      Читать дальше →
      • +19
      • 3,4k
      • 2
    • DevOps vs DevSecOps: как это выглядело в одном банке



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

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

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

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

        В этот момент и началась история DevSecOps, про которую я хочу рассказать.
        Читать дальше →
        • +29
        • 7,4k
        • 4
      • На чём стоит экономить в облаке



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

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

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

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



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

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

            Собственно, именно в момент обрыва мы и перешли на удалёнку. В своём собственном офисе. Точнее, в двух сразу.
            Читать дальше →
            • +21
            • 8,5k
            • 8
          • Как писать техстандарт по защите информации для крупной компании



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

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

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

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

              Давайте расскажу, как это делали мы. Возможно, вы уже писали что-то подобное у себя, и наша история вам поможет структурировать такие вещи. Ну или просто даст пару идей, как это можно сделать.
              Читать дальше →
              • +16
              • 3,8k
              • 7
            • Боремся с пробками в маленьком городе за небольшой бюджет: результаты 6 месяцев проекта



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

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

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

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


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

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

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

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

                  Итак, что такое сетевая фабрика с наложенными сетями и SDN?
                  Читать дальше →
                  • +23
                  • 2,9k
                  • 3
                • Как не надо защищать свои системы в облаке

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

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



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

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

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

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

                      А между ними — пропасть. И её пытается заполнить DevOps. Этот супермен должен взять релиз (а в идеале — собрать в Дженкинсе или чём-то подобном), создать машину, развернуть там всё, проверить работу, может, провести пару претестов и отдать уже в QA.
                      Читать дальше →
                      • +28
                      • 4,8k
                      • 3
                    • Платформа автоматизированного реагирования на инциденты ИБ

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

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

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



                        Мы сделали такую надстройку, и это очень помогло снизить нагрузку на операторов. Потому что сразу запускаются скрипты сбора информации, и если есть типовые действия — они сразу же предпринимаются. То есть, если завести систему «в такой ситуации делаем так и так», то карточка будет открываться для оператора с уже проработанной ситуацией.
                        Читать дальше →
                        • +20
                        • 5,8k
                        • 3
                      • Обезл***вание д***ных — это не просто рандомизация



                          В банке есть проблема: нужно давать доступ к базе данных разработчикам и тестировщикам. Есть куча клиентских данных, которые по PCI DSS требованиям Центробанка и законам о персональных данных вообще нельзя использовать для раскрытия на отделы разработки и тестирования.

                          Казалось бы, достаточно просто поменять всё на какие-нибудь несимметричные хеши, и всё будет хорошо.

                          Так вот, не будет.

                          Дело в том, что база данных банка — это множество связанных между собой таблиц. Где-то они связаны по ФИО и номеру счёта клиента. Где-то по его уникальному идентификатору. Где-то (тут начинается боль) через хранимую процедуру, которая вычисляет сквозной идентификатор на основе этой и соседней таблицы. И так далее.

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

                          То есть прежде чем всё это обезличить, сначала надо разобраться в базе данных.
                          Читать дальше →
                        • Выбор архитектуры решения для маркетплейса услуг грузоперевозок

                          • Tutorial

                          Аgorafreight.com — первый в России сервис для онлайн-расчета стоимости и заказа авиа-, авто- и контейнерных перевозок, сборных грузов всеми видами транспорта, включая ставки «от двери до двери».


                          image

                          Об истории проекта Agorafreight рассказывает руководитель проектов Reksoft (входит в ГК «Техносерв») Дмитрий Долгих.


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

                          Читать дальше →
                        • Почему финансовые директора так хотят перевести капитальные расходы на ИТ в операционные



                            Современный бизнес строится по архитектуре микросервисов. Очень сильно упрощая, есть ещё некоторые сферы, которые до сих пор процедурные и написаны на старом добром C. Работает — не трогай. И есть современные коммерческие структуры, которые всё больше уходят в распределённые архитектуры. Примерно по тем же причинам, что и в разработке, — так гораздо быстрее делать большие проекты.

                            Следствие — несколько разные векторы у CFO и CIO. Выражается это в том, что ИТ-директор часто хочет принести всё «домой» и поставить стойку в офисе, а финансист не видит в этом решительно никакого смысла. И так уж получилось, что CIO косвенно подчиняется именно CFO, поэтому всё заканчивается переездом в облако.

                            Как написал kaichou в комментарии: «а потом, пару лет спустя, выясняется, что на облако в год тратится столько денег, сколько стоил весь собственный серверный парк». И эта ситуация вполне нормальна для финдиректора. Сейчас постараюсь объяснить, как он в такой ситуации мыслит.
                            Читать дальше →
                          • Реакция на аварию: растянутый кластер против DR-площадки



                              У нас есть два подхода к Disaster Recovery: «растянутый» кластер (active-active-инсталляция) и площадка с выключенными виртуальными машинами (репликами). Они имеют несколько точек сохранения снэпшотов.

                              Запрос на катастрофоустойчивость есть, и многим нашим клиентам это реально нужно. Поэтому мы начали прорабатывать обе схемы в рамках нашего продакшна.

                              У методов есть плюсы и минусы, сейчас про них расскажу.
                              Читать дальше →
                            • Обзор ЦОД IXcellerate (самый большой машзал в РФ)



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

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



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

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


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

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


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

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

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

                                    Такие истории очень хорошо рассказывать через пару лет в курилке, но не встречать на проектах.
                                    Читать дальше →
                                  • В информационных технологиях есть своя особая атмосфера

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



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

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

                                        Вот один из самых страшных экранов для тех, кто переезжает с физического железа:



                                        Шучу. Главный страх админа при переводе инфраструктуры в облако — это потеря собственной важности. Почти все боятся, что перестанут быть незаменимыми. Это иллюзия. Важно не знание технологий, а знание компании и её устройства. Технологии быстро доучиваются.

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

                                        Потому что с момента начала виртуализации надо забыть половину того, что ты знаешь, и начать ботать сеть.

                                        Если вы читали на ночь Олифера «Компьютерные сети» или книгу с таким же названием Таненбаума, то проблем не будет почти точно. Это когда-то было классикой админов в свитерах, а теперь стало классикой админов в галстуках.
                                        Читать дальше →
                                      • Дверь, которая с нами здоровается по именам и открывает только сотрудникам отдела


                                          У нас была пара дней промежутка между большими проектами, и мы решили поиздеваться над дверью руководителя подразделения. Just for fun. Потому что дроны нас в лицо уже узнают — чем дверь-то хуже?

                                          На момент старта IT-проекта у нас уже была накладная панель, напечатанная на 3D-принтере. За два дня из железа, готовых библиотек и какой-то матери мы сделали прототип устройства, которое учитывает сотрудников или позволяет проверять, что человек прошёл через турникет именно по своему пропуску.

                                          Никаких денег. Мы использовали только опенсорс.

                                          Вы можете повторить это минут за 15–20 с нашим скриптом.
                                          Читать дальше →

                                        Самое читаемое