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

      image

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

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

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

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



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

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

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

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

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



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

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

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

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



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

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

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



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

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

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

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

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



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

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

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

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