ops sec что это
Настройка Write Ahead Log для PostgreSQL
На производительность PostgreSQL оказывает существенное влияние производительность дисковой системы. В конфигурационном файле postgresql.conf есть несколько параметров, значения которых могут оказать существенное влияние на производительность
Не все методы доступны на определенных платформах. Выбор метода зависит от операционной системы под управлением, которой работает PostgreSQL.
Она выполняет серию дисковых тестов с использованием различных методов синхронизации. В результате этого теста получаются оценки производительности дисковой системы, по которым можно определить оптимальный метод синхронизации для данной опереционной системы
Пример результатов теста для Windows
Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux’s default)
open_datasync 133333.333 ops/sec
fsync 24.124 ops/sec
fsync_writethrough 25.109 ops/sec
Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux’s default)
open_datasync 64516.129 ops/sec
fsync 25.266 ops/sec
fsync_writethrough 26.440 ops/sec
Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write open_sync sizes.)
16kB open_sync write n/a
8kB open_sync writes n/a
4kB open_sync writes n/a
2kB open_sync writes n/a
1kB open_sync writes n/a
Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written on a different descriptor.)
write, fsync, close 26.643 ops/sec
write, close, fsync 26.484 ops/sec
Non-Sync’ed 8kB writes:
write 305.623 ops/sec
Пример результатов теста для Linux
2000 operations per test
O_DIRECT supported on this platform for open_datasync and open_sync.
Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux’s default)
open_datasync 5617.741 ops/sec
fdatasync 5266.734 ops/sec
fsync 5301.412 ops/sec
open_sync 5983.080 ops/sec
Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux’s default)
open_datasync 2632.597 ops/sec
fdatasync 3674.546 ops/sec
fsync 3767.003 ops/sec
open_sync 2640.051 ops/sec
Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write open_sync sizes.)
16kB open_sync write 4400.682 ops/sec
8kB open_sync writes 2349.649 ops/sec
4kB open_sync writes 1466.995 ops/sec
2kB open_sync writes 730.509 ops/sec
1kB open_sync writes 374.540 ops/sec
Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written on a different descriptor.)
write, fsync, close 5048.108 ops/sec
write, close, fsync 5198.964 ops/sec
Non-Sync’ed 8kB writes:
write 115154.307 ops/sec
Из результатов теста можно определить, что для Linux все варианты синхронизации примерно равноценны и проигрывают варианту с отключенной синхронизацией.
Следует учитывать, что в данном тесте использовалась дисковая система, состоящая из одного диска. При использовании RAID массива с большим количеством дисков картина может быть другой.
Количество памяти используемое в SHARED MEMORY для ведения транзакционных логов. При доступной памяти 1-4GB рекомендуется устанавливать 256-1024kb. Этот параметр стоит увеличивать в системах с большим количеством модификаций таблиц базы данных.
Oпределяет количество сегментов (каждый по 16 МБ) лога транзакций между контрольными точками. Для баз данных со множеством модифицирующих данные транзакций рекомендуется увеличение этого параметра. Критерием достаточности количества сегментов является отсутствие в логе предупреждений (warning) о том, что контрольные точки происходят слишком часто.
full_ page_ writes
Включение этого параметра гарантирует корректное восстановление, ценой увелечения записываемых данных в журнал транзакций. Отключение этого параметра ускоряет работу, но может привести к повреждению базы данных в случае системного сбоя или отключения питания.
Включает/выключает синхронную запись в лог файлы после каждой транзакции. Это защищает от возможной потери данных. Но это накладывает ограничение на пропускную способность сервера. Если не критична потенциально низкая возможность потери небольшого количества изменений при крахе системы, но важно обеспечить большую производительность по количеству транзакций в секунду. В этом случае устанавливайте этот параметр в off (отключение синхронной записи).
Еще одним способом увеличения производительности работы PostgreSQL является отделение перенос журнала транзакций( pg_ xlog ) на другой диск. Выделение для журнала транзакций отдельного дискового ресурса позволяет получить получить при этом существенный выигрыш в производительности 10%-12% для нагруженных OLTP систем.
Для Linux это делается с помощью создания символической ссылки на новое положение каталога с журналом транзакций.
Для Windows можно использовать для этих целей утилиту junction.
Последовательность действий:
1. Остановить postgresql.
2. Сделать бэкап C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog.
3. Скопировать C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog в D:\pg_xlog и удалить C:\Program Files\PostgreSQL\X.X.X\data\pg_xlog.
4. Распаковать программу junction в C:\Program Files\PostgreSQL\X.X.X\data.
6. Установить права на папку D:\pg_xlog пользователю postgres.
Ops sec что это
Если для проведения измерений существующая система не доступна, часто оказывается возможной примерная оценка, основанная на предполагаемом использовании системы. Выполнение такой оценки требует понимания того, каким объемом данных будет манипулировать клиент. Этот метод достаточно точен, если приложение попадает в категорию систем с интенсивным использованием данных. Некоторая разумная оценка обычно может быть также сделана и для среды с интенсивным использованием атрибутов, но множество факторов делает такую оценку несколько менее точной.
Оценка среды с интенсивным использованием данных
Первый шаг для получения такой оценки заключается в определении полностью активного запроса типового клиента. Для этого необходимо понимание поведения клиента. Если нагрузка интенсивная по данным, то имеет смысл просто просуммировать количество предполагаемых операций чтения и записи и взять это число в качестве нагрузки для каждого клиента. Операции с атрибутами обычно являются несущественными для рабочей нагрузки, в которой доминируют операции с данными (с одной стороны, они составляют лишь небольшой процент всех операций, а с другой стороны, эти операции задают серверу минимальное количество работы по сравнению с объемом работы, который необходимо выполнить для выборки данных).
Заметим, что при выборе конфигурации системы для приложений с интенсивным использованием данных вообще говоря не очень полезно сравнивать предполагаемые скорости запросов с рейтингом предполагаемого сервера по SPECsfs_097, поскольку смеси операций отличаются настолько, что нагрузки нельзя сравнивать. К счастью, такая оценка обычно оказывается достаточно точной.
Оценка среды с интенсивным использованием атрибутов
В предыдущем примере предполагалось, что нагрузка NFS от операций с атрибутами была пренебрежимо мала по сравнению с операциями с данными. Если же это не так, например, в среде разработки программного обеспечения, необходимо сделать некоторые предположения относительно предполагаемой смеси команд NFS. В отсутствии другой информации, в качестве образца можно принять, например, так называемую смесь Legato. В тесте SPECsfs_097 (известной также под названием LADDIS) используется именно эта смесь, в которой операции с данными включают 22% операций чтения и 15% операций записи.
Рассмотрим клиентскую рабочую станцию, наиболее интенсивная работа которой связана с перекомпиляцией программной системы, состоящей из исходного кода объемом 25 Мбайт. Известно, что рабочие станции могут скомпилировать систему примерно за 30 минут. В процессе компиляции генерируется примерно 18 Мбайт промежуточного объектного кода и двоичные коды. Из этой информации мы можем заключить, что клиентская система будет записывать на сервер 18 Мбайт и читать по крайней мере 25 Мбайт (возможно больше, поскольку почти треть исходного кода состоит из файлов заголовков, которые включены посредством множества исходных модулей). Для предотвращения повторного чтения этих файлов включений может использоваться кэширующая файловая система. Предположим, что используется CFS. Во время «конструирования» необходимо передать 33 Мбайт действительных данных, или 33 Мb х 125 ops/Mb = 4125 операций с данными за 30 минут (1800 секунд), что примерно соответствует скорости 2.3 ops/sec. (Здесь предполагается, что каждая операция выполняется с данными объемом 8 Kb, поэтому для пересылки 1 Mb данных требуется 125 операций). Поскольку эта работа связана с интенсивным использованием атрибутов, необходимо оценить существенное количество промахивающихся операций с атрибутами. Предположив, что смесь операций соответствует смеси Legato, общая скорость будет примерно равна:
В данном случае скорость равна: (25 Мb по чтению х 125ops/Mb) / 22% / 1800 секунд, или 7.89 ops/sec. Для проверки мы также имеем (18 Мb по записи х 125 ops/Mb) / 15% / 1800 секунд, или 8.33 ops/sec. В данном случае соотношение операций чтения и записи очень похоже на смесь Legato, но это может быть и не так, например, если были открыты файлы программы просмотра исходного текста (размер файлов программы просмотра исходного текста (source brouser files) часто в 4-6 раз превосходит размер исходного кода). В этом случае у нас нет способа оценки пиковой нагрузки.
Кто такие DevOps?
На данный момент это чуть ли не самая дорогая позиция на рынке. Суета вокруг «DevOps» инженеров превосходит все мыслимые пределы, а тем хуже с Senior DevOps инженерами.
Я работаю руководителем отдела интеграции и автоматизации, угадайте английскую расшифровку — DevOps Manager. Отражает ли именно английская расшифровка нашу повседневную деятельность — вряд ли, а вот русский вариант в данном случае более точен. По роду моей деятельности, естественно, что мне, необходимо собеседовать будущих членов моей команды и, за прошедший год, через меня прошло человек 50, а еще столько же срезалось на прескрине с моими сотрудниками.
Мы все еще находимся в поиске коллег, потому как за лейблом DevOps прячется очень большая прослойка разного рода инженеров.
Все написанное ниже является моим личным мнением, вы не обязаны соглашаться с ним, однако допускаю, что внесет оттенок в ваше отношение к теме. Несмотря на риск попасть в немилость, я публикую свое мнение, поскольку считаю что ему есть место быть.
Компании по-разному понимают кто такие DevOps инженеры и ради быстрого найма ресурса вешают этот лейбл всем. Ситуация достаточно странная, поскольку компании готовы платить нереальные вознаграждения этим людям, получая за них, в большинстве случаев, админа-тулзиста.
Так кто же такие DevOps инженеры?
Давайте начнем с истории появления — Development Operations появился как еще один шаг к оптимизации взаимодействия в малых командах для повышения скорости производства продукта, как ожидаемое следствие. Идея заключалась в том, чтобы усилить команду разработки знаниями о процедурах и подходах в управлении продуктовой средой. Иными словами, разработчик должен понимать и знать как его продукт работает в тех или иных условиях, должен понимать как деплоить его продукт, какие характеристики среды подкрутить, чтобы повысить производительность. Так, в течение некоторого времени, появились разработчики с DevOps подходом. DevOps разработчики писали скрипты сборки и упаковки для упрощения своей деятельности и работоспособности продуктивной среды. Однако, сложность архитектуры решений и взаимное влияние компонентов инфраструктуры с течением времени начало ухудшать рабочие показатели сред, с каждой итерацией требовались все более глубокие понимания тех или иных компонентов, снижая продуктивность самого разработчика из-за дополнительных затрат на понимание компонентов и тюнинга систем под конкретную задачу. Собственная стоимость разработчика росла, стоимость продукта вместе с ним, резко подскочили требования к новым разработчикам в команде, ведь им необходимо было также покрывать обязанности «звезды» разработки и, естественно, «звезды» становились все менее доступны. Также стоит отметить, что, по моему опыту, мало кому из разработчиков интересна специфика обработки пакетов ядром операционной системы, правила маршрутизации пакетов, аспекты безопасности хоста. Логичным шагом было привлечь администратора, который именно с этим знаком и возложить подобного формата обязанности именно на него, что, благодаря его опыту, позволило достичь тех же показателей меньшей стоимостью в сравнении со стоимостью «звезды» разработки. Таких администраторов помещали в команду и основной его задачей было управление тестовыми и продуктивными средами, на правилах конкретно взятой команды, с ресурсами выделенными именно этой команде. Так, собственно, и появились DevOps в представлении большинства.
Частично или полностью, со временем, данные системные администраторы начали понимать потребности именно этой конкретной команды в области разработки, как упростить жизнь разработчикам и тестировщикам, как выкатить обновление и не остаться ночевать в пятницу в офисе, исправляя ошибки деплоя. Время шло, теперь «звездами» становились системные администраторы, понимающие чего хотят разработчики. С целью минимизации импакта начали подтягиваться утилиты управления, все вспомнили старые и надежные методы изоляции уровня ОС, которые позволяли минимизировать требования по безопасности, управлению сетевой части, да и конфигурации хоста в целом и, как следствие снизить требования к новым «звездам».
Появилась «замечательная» вещь — docker. Почему замечательная? Да только лишь потому, что создание изоляции в chroot или jail, равно как OpenVZ, требовало нетривиальных знаний ОС, в контру утилите позволяющей элементарно создать изолированную среду приложения на неком хосте со всем необходимым внутри и передать бразды правления разработке вновь, а системному администратору управлять только лишь одним хостом, обеспечивая его безопасность и высокую доступность — логичное упрощение. Но прогресс не стоит на месте и системы вновь становятся все сложнее и сложнее, компонентов все больше и больше, один хост уже не удовлетворяет потребностям системы и необходимо строить кластеры, мы вновь возвращаемся к системным администраторам, которые способны построить данные системы.
Цикл за циклом, появляются различные системы упрощающие разработку и/или администрирование, появляются системы оркестрации, которые, ровно до тех пор, пока не требуется отойти от стандартного процесса, просты в использовании. Микросервисная архитектура также появилась с целью упрощения всего описанного выше — меньше взаимосвязей, проще в управлении. В своем опыте я не застал полностью микросервисную архитектуру, я бы сказал 50 на 50 — 50 процентов микросервисов, черные коробки, пришло на вход, вышло обработанное, другие 50 — разодранный монолит, сервисы неспособные работать отдельно от других компонентов. Все это вновь наложило ограничения на уровень знаний как разработчиков, так администраторов.
Подобные «качели» уровня экспертных знаний того или иного ресурса продолжаются и по сей день. Но мы немного отвлеклись, есть немало моментов которые стоит осветить.
Build Engineer/Release Engineer
Весьма узкоспециализированные инженеры, появившиеся как средство стандартизации процессов сборки ПО и его релизов. В процессе введения повального Agile казалось бы они перестали быть востребованы, однако это далеко не так. Эта специализация появилась как средство стандартизации именно сборки и поставки ПО в промышленных масштабах, т.е. используя стандартные техники для всех продуктов компании. С появлением DevOps разработчиков частично утратили функции, поскольку именно разработчики стали подготавливать продукт к поставке, а учитывая изменяющуюся инфраструктуру и подход в максимально быстрой поставке без оглядки на качество со временем превратились именно в стопор изменений, поскольку следование стандартам качества неизбежно замедляет поставки. Так, постепенно, часть функционала Build/Release инженеров перекочевала на плечи системных администраторов.
Ops’ы такие разные
DevOps — (в теории) персона, не понаслышке понимающая все процессы цикла разработки — разработку, тестирование, понимающая архитектуру продукта, способная оценить риски безопасности, знакомая с подходами и средствами автоматизации, хотя бы на высоком уровне, помимо этого понимающая также пред и пост-релизную поддержку продукта. Персона способная выступать адвокатом как Operations, так Development, что позволяет выстроить благоприятное сотрудничество между этими двумя столпами. Понимающая процессы планирования работ командами и управления ожиданиями заказчика.
Для выполнения подобного рода работ и обязанностей данная персона должна иметь средства управления не только процессами разработки, тестирования, но и управления инфраструктурой продукта, а также планирования ресурсов. DevOps в данном понимании не может находится ни в IT, ни в R&D, ни даже в PMO, он должен иметь влияние во всех этих областях — технический директор компании, Chief Technical Officier.
Так ли это в вашей компании? — Сомневаюсь. В большинстве случаев это или IT, или R&D.
Недостаток средств и возможности влияния хотя бы на одно из этих трех направлений деятельности произведет смещение веса проблем в сторону где эти изменения проще применить, как например применение технических ограничений на релизы в связи с «грязным» кодом по данным систем статического анализатора. То есть когда PMO устанавливает жесткий срок на выпуск функционала, R&D не может выдать качественный результат в эти сроки и выдает его как может, оставив рефакторинг на потом, DevOps относящийся к IT, техническими средствами блокирует релиз. Недостаток полномочий на изменение ситуации, в случае с ответственными сотрудниками ведет к проявлению гиперответственности за то, на что они не могут повлиять, тем паче если эти сотрудники понимают и видят ошибки, и как их исправить — «Счастье в неведении», и как следствие к выгоранию и потери этих сотрудников.
Рынок DevOps ресурсов
Давайте рассмотрим несколько вакансий на позицию DevOps от разных компаний.
Резюмируя по данной вакансии можно сказать, что ребятам достаточно Middle/Senior System Administrator.
Кстати, не стоит сильно разделять админов на Linux/Windows. Я конечно понимаю, что сервисы и системы этих двух миров различаются, но основа у всех одна и любой уважающий себя админ знаком как с одним, так и с другим, и даже если не знаком, то для грамотного админа не составит труда ознакомится с этим.
Рассмотрим иную вакансию:
Резюмируя — Middle/Senior System Administrator
Хотелось бы также оставить ремарку относительно 3 пункта, дабы укрепить понимание, почему этот пункт покрывается сисадмином. Kubernetes всего лишь оркестрация, тулза которая оборачивает прямые команды драйверам сети и хостам виртуализации/изоляции в пару команд и позволяет сделать общение с ними абстрактным, вот и все. Для примера возьмем ‘build framework’ Make, коего фреймворком я, к слову, не считаю. Да, я знаю про моду пихать Make куда угодно, где нужно и не нужно — обернуть Maven в Make например, серьезно?
По сути Make просто обертка над shell, упрощающая именно команды компиляции, линковки, окружения компиляции, так же как и k8s.
Однажды, я собеседовал парня, который использовал k8s в своей работе поверх OpenStack, и он рассказывал как развертывал сервисы на нем, однако, когда я спросил именно про OpenStack, оказалось, что он администрируется, равно как и подымается системными администраторами. Вы правда думаете, что человек поднявший OpenStack вне зависимости от того какую платформу он использует позади него не способен использовать k8s?=)
Данный соискатель на самом деле не DevOps, а такой же Системный Администратор и, чтобы быть точнее, Kubernetes Administrator.
Резюмируем в очередной раз — Middle/Senior System Administrator им будет достаточно.
Сколько вешать в граммах
Разброс предлагаемых зарплат для указанных вакансий — 90к-200к
Теперь хотелось бы провести параллель между денежными вознаграждениями Системных Администраторов и DevOps Engineers.
В принципе, для упрощения можно грейды по опыту работы раскидать, хоть это и не будет точным, для целей статьи хватит.
Сайт поиска сотрудников предлагает:
System Adminsitrators:
По стажу «DevOps»’ов использовался стаж, хоть как то затрагивающий SDLC.
Из вышеозначенного следует, что на самом деле компаниям не нужны DevOps’ы, а также что они могли сэкономить не менее 50 процентов от изначально запланированных затрат, наняв именно Администратора, более того, они могли бы четче определить обязанности искомого человека и быстрее закрыть потребность. Не стоит также забывать, что четкое разделение ответственности позволяет снизить требования к персоналу, а также создать более благоприятную атмосферу в коллективе, ввиду отсутствия пересечений. В подавляющем большинстве вакансии пестрят утилитами и DevOps лейблами, однако не имеющие в основе действительно требования к DevOps Engineer, лишь запросы на тулзового администратора.
Процесс обучения DevOps инженеров также ограничен лишь набором специфичных работ, утилит, не дает общего понимания процессов и их зависимостей. Это конечно хорошо, когда человек может используя Terraform задеплоить AWS EKS, в связке с Fluentd сайд-каром в этом кластере и AWS ELK стеком для системы логирования за 10 минут, используя лишь одну команду в консоли, но если он не будет понимать сам принцип обработки логов и для чего они нужны, не знать как собирать метрики по ним и отслеживать деградацию сервиса, то это будет все тот же эникей, умеющий использовать некоторые утилиты.
Спрос, однако, порождает предложение, и мы видим крайне перегретый рынок позиции DevOps, где требования не соответствуют реальной роли, а лишь позволяют системным администраторам зарабатывать больше.
Так кто же они? DevOps’ы или жадные системные администраторы? =)
Как дальше жить?
Работодателям — точнее формулировать требования и искать именно тех кто нужен, а не разбрасываться лейблами. Вы не знаете чем занимаются DevOps — они вам не нужны в таком случае.
Работникам — Учиться. Постоянно совершенствовать свои знания, смотреть на общую картину процессов и отслеживать путь к поставленной цели. Можно стать кем захочешь, надо лишь постараться.
Безопасная разработка: какую часть Sec занимает в DevSecOps
Всем привет! Меня зовут Тимур Гильмуллин, я руководитель направления по построению процессов безопасной разработки в компании Positive Technologies. Раньше я работал в DevOps-отделе, где инженеры занимаются автоматизацией различных процессов и помогают программистам и тестировщикам. В числе прочего мы проводили работы, связанные с внедрением инструментов безопасной разработки в CI/CD-конвейер. В этой статье я рассмотрю концепцию безопасной разработки DevSecOps (или SecDevOps) в целом: разберемся, что это за концепция, что она дает бизнесу, разработчикам, инженерам DevOps и безопасникам, какие инструменты можно при этом использовать и насколько трудоемко их внедрение.
Про DevSecOps
По версии компании «Майкрософт», методология DevSecOps подразумевает интеграцию процессов и внедрение инструментов безопасной разработки поверх уже выстроенных DevOps-процессов и работающих CI/CD-конвейеров.
Сами по себе идеи безопасной разработки и тестирования безопасности ПО не новы. Уже в конце 80-х годов в России существовали ГОСТы, например ГОСТ 28195-89, включающие в себя в том числе проверки на ошибки обслуживания, то есть нарушение порядка взаимодействия с программой со стороны пользователя, — фактически это были проверки безопасности. Аналогичные стандарты были и за рубежом. DevSecOps — это более современный подход к быстрой разработке надежного и безопасного продукта, учитывающий все последние технологические новинки в этой области.
Однако сами по себе процессы и безопасная разработка как сервис мало кого интересуют, важны лишь конечные результаты, к которым приводит внедрение идей и инструментов DevSecOps. К ним можно отнести:
быстрое и безопасное развертывание приложений в продакшн-окружении, то есть уменьшение времени time-to-market за счет автоматизации;
удешевление исправления ошибок и уязвимостей в ПО за счет их обнаружения на ранних этапах разработки;
снижение критических и неприемлемых рисков для вендора ПО, например, недопущение встраивания вредоносного кода в компоненты разрабатываемого продукта или защита инфраструктуры от атак типа supply chain.
Альтернативой процессам DevSecOps можно назвать только отказ от этих идей и возвращение к классическому подходу к разработке. Напомню, как это было до использования гибких методологий разработки и DevOps. Программисты писали код и сами же его собирали, тестировщики тестировали то, что им отдали программисты, а дальше инженеры по эксплуатации вручную устанавливали это на «боевые» серверы. Добавьте сюда различные регламенты и противоречивые требования команды безопасников. А еще — распределение всех этих команд по разным городам и разным часовым поясам. Разработка могла затянуться на месяцы и даже годы. Сейчас мало кто захочет вернуться к тем временам. Чтобы решать такие проблемы, нужно объединить всех участников в едином и понятном для них процессе. Это могут помочь сделать инженеры и идеологи подходов DevSecOps.
Построить DevOps-процессы и наладить автоматизацию разработки — задача сама по себе уже достаточно сложная и трудоемкая. Типовой процесс разработки включает в себя CI/CD-конвейер, который автоматизирует все этапы сборки продукта, деплой на тестовой инфраструктуре, проведение автотестов, продвижение продукта в релиз и его публикацию на серверах обновлений для дальнейшей доставки в инфраструктуру заказчика. Этот конвейер сопровождают на всех этапах DevOps-инженеры, к которым относятся инженеры по инфраструктуре и CI-инженеры. Они занимаются автоматизацией различных процессов разработки, помогают программистам и тестировщикам работать с продуктовыми конвейерами и инструментами автоматизации.
Security-часть необходимо внедрять в этот процесс комплексно, включая встраивание инструментов DevSecOps поверх конвейера разработки совместными усилиями инженеров IT, DevOps и специалистов-безопасников.
Про инструменты
Инструменты, обеспечивающие безопасность инфраструктуры и каждого из этапов разработки, могут быть различными. Есть множество вендоров, предлагающих отдельные технические инструменты, но очень мало тех, кто предлагает решения под ключ, обеспечивающие защиту всех этапов разработки, и в этом есть определенная проблема.
Кроме того, недостает и технических решений, тех же сканеров кода, которыми программист мог бы пользоваться самостоятельно. Я считаю, что в этом вопросе разработчикам сканеров следует двигаться в сторону исправления уязвимостей «одной кнопкой», без привлечения так называемых security champions — специалистов-безопасников. Программисты вряд ли захотят, чтобы такие специалисты постоянно сидели около них и объясняли, как исправлять уязвимости. Это как если бы рядом с пользователями редактора Word сажали учительницу русского языка, которая бы объясняла, почему редактор подчеркнул ошибку и как ее исправить 🙂 Но для этого сканер кода должен включать в себя достаточно обширную базу знаний по уязвимостям и типовые шаблоны их исправления для большинства языков программирования.
Хотелось бы отметить, что само по себе сканирование кода не дает результатов. Подход должен быть комплексным: сканирование должно быть встроено в CI/CD-процесс, должны быть настроены правила безопасности (security gates) для автоматической блокировки сборки в случае обнаружения уязвимостей, а разработчики — пользователи сканера — должны пройти обучение.
Насколько сложно внедрить в компании процесс безопасной разработки? На мой взгляд, трудоемкость внедрения инструментов DevSecOps в CI/CD зависит от множества факторов: от масштабов проекта, готовности инфраструктуры разработки, достаточной квалификации инженеров и принципиального желания самих разработчиков использовать внедряемые инструменты. Два последних фактора я считаю наиболее важными. Инженеры и разработчики должны быть сами заинтересованы в использовании инструментов безопасной разработки, эти инструменты должны им нравиться, быть удобными и легко интегрироваться в CI/CD-конвейеры корпоративной разработки.
В одной из наших прошлых статей мы подробно рассказали о внедрении анализатора исходного кода PT Application Inspector (комплексное решение SAST/DAST/IAST) в DevSecOps-процессы одного из наших продуктов и о том, с какими нюансами при этом столкнулись. Тогда это потребовало усилий двух CI-инженеров и одного инженера по инфраструктуре на протяжении нескольких месяцев работы, включая разработку архитектуры внедрения сканера. Но зато потом мы получили шаблоны и типовой процесс сканирования кода, тиражирование которых уже не занимает много времени. Все эти наработки, включая шаблоны сканирования, мы выложили в опенсорс-проект dohq-ai-best-practices.
Как же организовать процесс безопасной разработки? Во-первых, прежде чем выстраивать DevSecOps-процессы, компания сначала должна построить DevOps-процессы. Для автоматизации процессов может использоваться любой CI/CD-конвейер, их достаточно много (GitLab CI/CD, GitHub Actions, TeamCity, Travis CI, Jenkins, CI платформы Microsoft Azure, AWS и Google).
Во-вторых, необходимо на уровне CI/CD-конвейера обеспечить защиту каждого этапа разработки и развертывания ПО. Ведь, согласно концепции shit left, чем раньше будут найдены потенциальные уязвимости в коде и инфраструктуре, тем дешевле будет стоить исправление этих ошибок. А если они будут обнаружены только в продакшн-окружении у заказчика, их исправление может привести даже к переделке всей архитектуры приложения.
Использование продуктов Positive Technologies в качестве DevSecOps-инструментов на различных этапах CI/CD-конвейера
Расположение SEC на схеме подразумевает, что security-процесс должен рассматриваться как непрерывный — так же, как и процессы разработки, деплоя, тестирования и доставки. То есть безопасность должна обеспечиваться соответствующими инструментами на каждом этапе технологического процесса.
На этапах разработки и сборки продукта для этого могут использоваться различные сканеры кода (например, PT Application Inspector). После развертывания продукта в тестовой среде могут быть использованы сканеры black box (например, PT BlackBox Scanner в составе MaxPatrol 8), которые фактически имитируют внешний пентест приложения. И, наконец, после завершения всех тестов, исправления найденных уязвимостей и развертывания продукта в продакшн-окружении, он может быть защищен от хакерских атак межсетевым экраном (например, таким как PT Application Firewall). Кстати, PT Application Firewall может защитить не только разрабатываемый продукт, но и вообще любые корпоративные приложения и сервисы, в том числе от 0-day атак (например, он из коробки умеет предотвращать эксплуатацию критической уязвимости в Apache Log4j 2, затрагивающей большое число Java-проектов).
Дальнейший контроль за инфраструктурой и развернутым продуктом может вестись более комплексными системами аудита ИБ и SIEM-системами, такими как MaxPatrol SIEM, системой управления уязвимостями MaxPatrol VM, а также системами контроля трафика по всей сети, где развернуто приложение, для предотвращения хакерских атак. Например, системой анализа трафика PT Network Attack Discovery, которая умеет выявлять техники MITRE ATT&CK. Дополнительно обеспечить безопасность серверов можно при помощи PT Sandbox — песочницы для выявления сложных атак с применением вредоносного ПО, или системы антивирусной защиты PT MultiScanner.
В-третьих, необходимо обеспечить безопасное развертывание всей инфраструктуры, виртуальной или «железной». Для этого используется множество инструментов и подходов, в том числе написание сценариев подготовки и развертывания инфраструктуры через SaltStack, Ansible, Kubernetes или OpenShift. О технологических новинках из мира построения безопасной инфраструктуры можно узнавать на различных ресурсах, например, в канале DevSecOps Wine. Его автор, Денис Якимов, участвуя в одном исследовании нашей компании, подчеркнул важность правильного выбора подходов DevSecOps: «В погоне за маркетинговыми лозунгами shift left компании так увлеклись встраиванием сканеров в пайплайны, что забыли про не менее важную часть безопасности разработки — инфраструктуру и цепочку поставок».
Неизменяемая и версионированная инфраструктура также важна, потому что DevOps-инженерам необходимо обеспечивать повторяемость сборок для одного и того же коммита в кодовой базе. Оркестрация контейнеров сборки помогает избежать досадных проблем, которые могут возникать при ручном конфигурировании инфраструктуры (например, как это было в недавнем нашумевшем случае с «Фейсбуком»). Не менее важна и защита самих контейнеров сборки — минимальный базовый образ и использование минимальных привилегий для запуска приложений внутри контейнера, использование систем аудита для контроля запущенных процессов и сетевой активности.
Ко всем перечисленным инструментам можно добавить следующие:
внедрение в пайплайны сборки автоматизированных тестов безопасности (функции безопасности должны тестироваться так же качественно, как и основная функциональность продукта);
автоматическая проверка сторонних зависимостей (например, с помощью OWASP Dependency-Check);
внедрение ролевой модели доступа к ресурсам разрабатываемого продукта;
защита кодовой базы (например, подписывание коммитов в хранилище и использование верификации коммитов);
цифровая подпись собранных компонентов (например, при помощи SignTool) и ее проверка при формировании бандла (инсталлятора) продукта из этих компонентов.
О безопасной разработке в части процессов и инструментов много было сказано на встрече Positive Tech Press Club с экспертами в области DevOps, DevSecOps, AppSec и защиты инфраструктуры. Участники встречи рассказали о трендовых угрозах и примерах кибератак, которые стали возможны из-за брешей в исходном коде, а также обсудили, нужна ли компаниям безопасная разработка, как эксперты оценивают степень проникновения этого подхода в российский бизнес и какие результаты уже достигнуты.
Отдельной темой беседы стало обсуждение элементов DevSecOps и SSDL не только в плане технологий и инструментов, но и культуры безопасной разработки, подходов и принципов. Из важного стоит отметить, что мнения экспертов по поводу того, безопасность каких элементов процесса разработки необходимо обеспечить в первую очередь, разделились. Кто-то считает, что самое важное — защитить инфраструктуру разработки и эксплуатации, а другие, что инфраструктура вторична и что главное — это защитить само приложение и сделать безопасным код. То есть ключевые элементы DevSecOps — это безопасная инфраструктура для CI/CD-конвейера и процесс безопасной разработки, работающий поверх этой инфраструктуры.
Если обобщить мнения экспертов, то можно дать следующую комплексную формулу: DevSecOps = AppSec + SecDev + Infrastructure Security. В каждом из этих трех направлений кибербезопасности нужно, конечно же, исходить из лучших его практик.
Про культуру
По мнению специалистов «Тинькофф», «безопасность как сервис» часто интерпретируется только в контексте предоставления шаблонов подключения WAF/SAST/DAST и прочих инструментов ИБ, которые могут быть легко встроены в CI/CD-конвейер через IaC (infrastructure as code). При этом каждый разработчик может сам встроить все проверки безопасности отдельными шагами в свой сборочный процесс. Но здесь есть проблемы, тормозящие внедрение культуры безопасной разработки, с которыми часто сталкиваются крупные компании:
До сих пор в компаниях не везде есть единый согласованный CI, под который нужно писать шаблоны. Часто бывает «зоопарк» технологий: одновременно могут использоваться TeamCity, GitLab CI/CD, TFS, Jenkins и самописные системы сборки.
До сих пор есть разработчики, которые собирают код руками и выкладывают артефакты сборки в хранилище, вперемешку с артефактами, собранными автоматически.
Разработчики могут просто отключить шаги безопасности или не встраивать их в свой сборочный процесс, а у команды ИБ нет механизмов по своевременному выявлению таких ситуаций.
Все инструментальные решения имеют свой воркфлоу по работе с уязвимостями. Где-то проставляются комментарии и статусы в трекере или в системе контроля версий, а где-то таких механизмов в принципе нет. У многих инструментов вообще нет UI.
У каждого решения есть своя консоль управления и, соответственно, свой набор доступов, который нужно предоставлять для разработчиков и безопасников. А это приводит к большему усложнению и без того сложных ролевых политик компании.
Специалистов со стороны ИБ, как правило, всего несколько человек, а разработчиков сотни. Это приводит к классической проблеме «вас много, а я один», из-за чего разработчикам просто не хочется обращаться к безопасникам.
В итоге для решения указанных проблем команды разработчиков из крупных компаний с большой разношерстной инфраструктурой разработки постепенно приходят к концепции предоставления безопасности не просто в виде шаблонов, а в виде полноценного внутрикорпоративного SaaS-решения — платформе DevSecOps/AppSec, или «безопасности под ключ».
Тем не менее простое внедрение подходов и инструментов DevSecOps не приведет к одномоментной трансформации всей инфраструктуры компании в сторону большей безопасности. Здесь нет универсальных решений. Для успешного развития идей безопасной разработки в компании должны сложиться определенная культура разработки и тесное сотрудничество между безопасниками и различными группами инженеров. Однако многие компании по-прежнему ведут разработку, используя традиционные подходы, где инженеры по эксплуатации, разработчики и безопасники достаточно сильно изолированы друг от друга. Это подтверждается и нашим опросом о состоянии безопасной разработки в компаниях — вендорах ПО.
Только треть опрошенных инженеров сообщили, что компании, в которых они работают, включили меры по обеспечению безопасности в цикл разработки ПО. А половина опрошенных готовы участвовать в DevSecOps-процессах, только если у них появится понимание, что этот подход сможет защитить разрабатываемые продукты от хакеров. Здесь я бы рекомендовал инженерам, разработчикам и руководителям разработки ПО принимать участие в различных профильных конференциях по кибербезопасности, хакатонах и киберучениях (например, The Standoff или PHDays), где они смогут приобрести необходимые знания и навыки, в том числе по безопасной разработке.
Руководителям компаний и подразделений разработки также стоит поощрять культуру сотрудничества между инженерами служб ИБ, ИТ, DevOps и самими разработчиками. DevSecOps-специалисты, которые им помогают, должны быть хорошо знакомы с процессами и методологиями разработки, принятыми в конкретной компании. Кроме того, они должны не только очень хорошо разбираться в вопросах безопасности, но и уметь донести свое видение до всех участников процесса разработки.
DevSecOps — это не только про инструменты или конкретный набор технологий, но еще и про новое глобальное направление в компании. Для его развития нужен ответственный человек, который будет его идеологом, а также заинтересованные инженеры и программисты в командах. Понятно, что процессы разработки различаются в каждой компании, у всех есть своя специфика. Но, несмотря на все преимущества подходов безопасной разработки, многие компании все еще сомневаются в принятии DevSecOps. Как и DevOps, который когда-то изменил подходы к разработке ПО, идеи DevSecOps также требуют изменений в способе мышления. Современные компании должны понять, что ответственность за безопасность лежит на всех участниках процесса разработки, а не только на специалистах по информационной безопасности. Внедрить идеи DevSecOps будет непросто, но изменения того стоят.