Здравейте на всички ! Казвам се Михаил Косинский, Senior DevSecOps Engineer в SoftServe. В тази статия ще си изясним следните неща:
• Защо DevOps задължително трябва да включва компонента сигурност.
• Чрез практически примери ще разгледаме какво се случва, когато тези две фази не са свързани помежду си.
• Ще разясним как DevOps си взаимодейства със сигурността в нашата компания.
Ще се постарая с прости думи и най-елементарно да опиша своя опит и наблюдения.
DevOps без Security в крайна сметка може да ни излезе твърде скъпо
Започнах кариерата си като системен администратор. Тази професия предполага познаване на най-новите аспекти на сигурността. След това преминах към DevOps, където първоначално се фокусирах върху съответствието на избраното за имплементация решение на поставената от клиента задача. С други думи, целта ми беше да направя така, че избраното решение да работи. Например при деплоймънт на приложение, моята задача беше компонентите на деплоймънт схемата да взимат код от хранилището, да го обработват и в крайна сметка да подават обновен код на сървъра. Ако тази схема функционира идеално, аз като специалист само по DevOps смятах, че задачата е изпълнена и проектът е завършен.
Но към момента на пускане на приложението в продукция, често от страна на нашия отдел или от страна на клиента, изникваха редица въпроси свързани със сигурността:
- съответства ли решението на HIPAA compliance (Закон за защита и достъп до медицинските данни на пациентите)
- PCI compliance (стандарт за сигурност за търговци и процесори на платежни карти)
- всички портове ли са затворени и т.н.
Ако има пропуски по отношение на сигурността, колкото и прекрасно да работи решението, то не бива да бъде внедрявано. И това се случва на практика, при това често.
Аз лично знам за такива случаи, при които разработчиците не са проверили дали се криптират логините и паролите при подаване на сървъра или не. Случва се и така, че те могат просто да се пазят в отделен файл във формата на открит текст или в базата данни в не криптиран вид. Тоест можеше да се влезе в сървъра и лесно да се получи достъп до тях. Имаше случай с мобилно приложение, когато конфиденциални данни на потребители можеха да бъдат извлечени чрез файлов редактор. Подобни грешки могат да доведат до съдебни дела, големи глоби, загуба на репутация за компанията пред клиентите и инвеститорите.
Пропуските по отношение на сигурността могат също да причинят преки финансови загуби. Ние работехме по един голям проект и клиентът не беше одобрил бюджет за сигурност, което в крайна сметка му коства доста повече пари. Разработихме цялата инфраструктура, като я описахме като код – пускаш един скрипт и след няколко минути се разгръщат множество клъстери, всичко това работи и взаимодейства помежду си. В процеса на UAT тестването, клиентът (за удобство) отваря един от портовете към интернет. Това не се отрази по никакъв начин на работата на самото приложение, но затова пък хакерите получиха възможност да разбият клъстера, който се занимава с обработка на голям обем данни, и да пристъпят към копаене на криптовалута. А тъй като по подразбиране имаше настройка за автоматично разширение при увеличаване на натоварването, процесорите „удариха тавана” и инфраструктурата се разшири, достигайки лимита на ресурсите на облаците. Клиентът забелязва това след два дни, когато получава сметка за повече от 10 000 долара за използване на облачна инфраструктура.
Носи ли отговорност за подобни случаи DevOps изцяло? По-скоро не, тъй като той не притежава компетенции, позволяващи качествен анализ на работата на приложението от гледна точка на сигурността, откриването на всички грешки и отстраняването им. Има ли смисъл всеки готов проект да се дава за доработване на инженерите по сигурността? Отново, по-скоро не. Нека се спрем на тези въпроси, преди да преминем към DevSecOps. Да изясним в какви случаи връзката DevOps Engineer+Security Engineer е необходима, и кога е неефективна.
Защо дуетът DevOps+Security не винаги е ефективен? В какви случаи не може без инженер по сигурността?
Преди всичко привличането на Security Engineer увеличава продължителността на работата по проекта – те се нуждаят средно от около две седмици да вникнат в това как е построена инфраструктурата на приложението, как компонентите взаимодействат помежду си,и да намерят пропуските в сигурността. Това води до увеличаване на бюджета на проекта, за което в повечето случаи клиентът не е готов.
Главната задача на Security Engineer е да затвори конкретните „дупки”. Проектирането на приложението и съпровождането на процеса на разработка (в който често клиентът нанася поправки и създава нови изходни данни) не е в неговата компетенция и сфера на отговорност.
По тази причина Security Engineer се привличат след приключване на работата върху приложението към момента на penetration-testing, когато е необходимо да се провери уязвимостта поради твърде сложна инфраструктура и повишен риск, или поради изначално неотчитане на необходимостта от подсигуряване на сигурността. Също така те са нужни, когато в проекта не е включен DevOps, който се ориентира във въпросите, свързани с нея.
Механизмът е следният: ако екипът, осъществяващ проекта, се съмнява в сигурността на разработеното решение, това се обсъжда с клиента. Ако клиентът няма вътрешни ресурси за извършване на security assessment, съгласуваме с него отделен бюджет за привличане на Security Team. За да се съкрати времето, необходимо на Security Engineers да се ориентират в тънкостите на работата на решението, те провеждат сесии с разработчиците, които им разказват как работи приложението, показват взаимовръзките между компонентите . След това Security Engineers могат качествено да тестват уеб приложението, също и мобилното приложение (проверяват отделно на всяка версия на платформата iOS и Android), за установяване на OWASP TOP-10 уязвимости:
- Injection
- Broken Authentication
- Sensitive data exposure
- XML External Entities (XXE)
- Broken Access control
- Security misconfigurations
- Cross-Site Scripting (XSS)
- Insecure Deserialization
- Using Components with known vulnerabilities
- Insufficient logging and monitoring
Неотдавна SoftServe закупи програма, която анализира пълния спектър на уязвимостите: самите приложения, базите данни, връзките между компонентите и т.н. Грубо казано, програмата провокира различни уязвимости у компонентите на приложението и чака какъв ще бъде отговорът. Ако програмата е установила „дупките“ в сигурността, Security Team съвместно с разработчиците работят по тяхното затваряне.
Ние проверяваме чрез тази услуга приложенията, в които се съмняваме,. За съжаление този процес отнема много време, затова, не се получава да пуснем през него няколкото хиляди проекта, по които сега работим. Освен това за клиента това е допълнително перо разходи, за което той не винаги е подготвен. По тези причини ние я използваме само при сложни проекти, които касаят стотици сървъри и микроуслуги – за компании, които се занимават с добив на нефт и газ, банкови услуги, здравеопазване.
От моя гледна точка проверката на приложението на етап разработка не е ефективна поради допълнителната загуба на време и финансови ресурси. Такъв подход към проекта е възможен, ако с клиента предварително бъде обсъден някакъв бюджет. Поначало няма смисъл да се губи време, и например да се затварят портовете за достъп. В процеса на разработка често клиентът изпраща нови изходни данни – да се добави някоя функционалност или още нещо. И всеки път трябва да се преразглежда влиянието на тези процеси върху сигурността. С наближаването на срока на пускането в продукция на проекта трябва да бъдат разбрани всички слаби места и да знаем какво да правим с тях.
Именно по тази причина не можем да привлечем в началния етап Security Team, когато проектът едва тръгва. По време на разработката исканията на клиента се променят дотолкова, че предполагаемите първоначални планове относно сигурността са кардинално различни преди пускането на на проекта в продукция. От това следва, че в началото на работата нямаме ясно разбиране как да бъде построено приложението, съответно Security Team няма пълна видимост относно най- правилните стъпки от към сигурност.

Нещо повече – на база практическия си опит, мога да кажа, че самият клиент рядко се замисля за сигурността, докато не се сблъска с някаква ситуация.
Решение на този проблем е развиването на компетенцията на DevSecOps, което в днешно време е световна тенденция.
SecDevOps vs. DevSecOps
SecDevOps подходът предполага имплементация на елементи на сигурността в хода на разработката на проекта. Според мен това не е ефективно по същата причина, по която няма смисъл да се привлича Security Team – към края може да се получи нещо, което е далеч от първоначално планираното.
Разбира се, има проекти, при които всичко е ясно от самото начало и още преди да стартира работата може да се обмисли сигурността. Това може да бъде разработка на приложение, когато имаш сървър, база данни, потребители, които се логват във уеб приложението и това приложение работи с тази база данни. Изначално са известни всички данни, тоест клиентът е сигурен, че няма нужда да се добавя нищо ново. В такива ситуации е необходим просто Continuous Integration & Continuous Delivery процес, за да се задейства кодът в Github или всяка друга Cloud Management System и той ще обнови сървъра.
Това са стандартни решения, в които няма никакви подводни камъни. Тук разбираш, че ще има криптиране между приложението и базата данни, а също по SSL сертификата. Скриваме сървърите в частна мрежа, отваряме към света Load balancer, защото по същността си той само разпределя натоварването по сървърите, които си обменят данни с обща база. Тук нищо ново не може да се измисли.
Случва се също така в процеса на разработка да се добавя нова функционалност и разбираме, че първоначалният избор на компонента на сигурност покрива тази функционалност . За да може изначално да бъде постигнато това, трябва да разбираме, че например медицинските компании са строго зависими от безопасното съхраняване на индивидуалните данни на пациентите. Но това се случва много рядко, защото ние се сблъскваме с много необичайни решения и искания на клиенти.
Веднъж разработвахме уеб приложение, което трябваше да бъде пуснато на голям клъстер. Поради липса на документация самият клиент не разбираше докрай как точно работеше то. Там бяха използвани бази данни, Big Data cluster и код, който задействаше всичко това и го разгръщаше. При това клиентът беше предоставил първоначалния код. В продължение на няколко седмици работихме върху кода и се опитвахме да възпроизведем работещо приложение, като в същото време премахваме бъговете в кода под формата на пароли за базата, записани в ясен вид. След няколко седмици се оказахме блокирани и не ни оставаше нищо друго освен да отидем при клиента и да му кажем, че не е възможно да задействаме кода, както и да се опитваме. Оказа се, че просто не са ни съобщили, че е нужен допълнителен компонент, за да сработи всичко − analytics engine for big data processing. В такива ситуации разбираш, че си си губил времето напразно. Сега трябва да се мисли как да го интегрираме. При това самият клиент не знае как да направи това, тъй като кодът е писан от двама души, които са напуснали компанията и няма възможност за консултация с тях. Тук проблемът явно е в самата разработка на приложението, тоест в DevOps. А представете си, че на всеки етап трябва да се включва Security Engineer? Например той ще каже, че същият Big Data cluster или analytics engine for big data processing не се покрива с решението, което е избрано първоначално. И тогава трябва да се мисли с какъв допълнителен компонент може да се затвори появилата се „дупка“, за да може работата на инфраструктурата да бъде в безопасност. Вие можете първоначално да изберете инструмент за осигуряване на сигурността, което да доведе до допълнителни инструменти и усложняване на инфраструктурата.
DevSecOps подходът, при който се финализира архитектурата на приложението, а след това се затварят „дупките“ в сигурността, е най-рационалният от гледна точка и на разпределение на ресурсите, и на осигуряване на сигурността на готовото приложение.
Как на практика е устроен DevSecOps?
Аз от DevOps се преквалифицирах в DevSecOps. За тази цел започнах да посещавам вътрешни обучения, които се организират от нашите Security Engineers, да проучвам допълнителна информация, за да разбирам какви уязвимости има, как могат да се затварят, на какво трябва да се обърне внимание, ако клиентът работи с медицински данни или разплащателни карти.
На етап pre-sale, в разговор с клиентите улавям неща, които могат да не са очевидни за Architecture, Sales Manager, Project Manager.
На етап разработка и деплоймънт на проекта аз работя като стандартен DevOps Engineer, като анализирам връзките между компонентите. По-нататък в зависимост от мащабите на проекта, аз или имплементирам решения, необходими за осигуряване на пълна сигурност на проекта, или работя във взаимодействие със Security Team. Нека разгледаме това с примери.
При нас дойде клиент с искане да пренесе потребителски форум, разработен от друга компания (който работеше зле и се съхраняваше в дата центъра на разработчика), в частен облачен акаунт на клиента, по възможност форумът да се настрои за работа с по-голям брой посетители. За да бъде изпълнена първата част от задачата, аз получих достъп до хранилището с код, към облачния акаунт на клиента, където ще бъдат разгърнати сървърите. Екипът на клиента разказа как се задейства и функционира приложението като цяло. След това компилирах кода локално, за да проверя дали работи и дали може да се задейства на друг сървър.
След като успешно пуснах форума локално, пристъпих към автоматизация. Това е един вид главоблъсканица:
- трябва да се помисли как да се свърже с хранилището, където ще се пази кода – да се измисли схема на задействането на процеса на обновяване на сървъра при внасяне на промени в кода.
След като логическата верига беше построена и процесът на автоматизация настроен, към проекта се включи тестващия екип, за да провери работата на приложението при натоварване, дали паметта е достатъчна, справят ли се процесорите и в случай на недостиг на ресурси да се разшири сървъра до необходимите показатели. Когато успяхме да настроим работата на форума и да формираме изисквания за сървърите с облака, можеше да се пристъпи към миграция в облачния клиентски акаунт. Препоръчително е това да се прави от същия човек, който е проектирал решението и го познава добре.
В този случай не беше нужно да изучавам как е била осигурена сигурността на старото решение, тъй като разработих изцяло нова схема. Когато правя това сам, стъпка по стъпка, впоследствие мога лесно да анализирам сигурността на крайния продукт, да открия рисковете и да ги затворя. В този конкретен случай разбирах, че най-важното е да спра достъпа до системата и да отстраня рисковете от пробив. Затова оставих възможността за включване към сървърите само от офиса на клиента и офиса на SoftServe. Отделът по сигурността на клиента провери новото решение за уязвимост и не откри слаби места.
Този проект успях да направя самостоятелно, тъй като в случая инфраструктурата се състоеше само от няколко сървъра.
Ако се разработва сложна система, която се състои от много сървъри, бази данни, взаимодействащи помежду си, е необходима поддръжка от Security Team. Първо, на един човек би отнело много време, второ DevSecOps-Engineer не работи ежедневно с програми за тестване на системата. В такива случаи моята роля е да помогна на екипа по сигурността да свърши работата по-бързо и по-просто, като им се обясни структурата на приложението и взаимовръзката между нейните компоненти. Това отнема около 3 дни, след което за една-две седмици те ще могат качествено да я тестват. Ако работят самостоятелно с непознат проект, това отнема повече от месец.
Мога да обобщя, че трябва да се мисли за сигурността на първо място, но да се прилагат правилата за сигурност върху готова инфраструктура, когато ясно и нагледно се вижда как компонентите взаимодействат помежду си, а инфраструктурата вече няма да се променя и преправя заради нови искания на клиента.
Mykhailo Kosynskyi (Михаил Косинский, Senior DevSecOps Engineer, SoftServe)
Михаил работи от 13 години в сферата на информационните технологии, има опит в бързото решаване на комплексни проблеми от различни сфери, свързани с натрупаните през времето умения. За себе си казва, че има логически и методически подход към постигане на работните цели, и че детайлите са от голямо значение в работата по различните проекти. Притежава редица сертификати, част от които са: AWS Solution Architect, GCP Cloud Professional Architect, Java EE, Jenkins CI For DevOps и други. Притежава магистърска диплома по компютърно инженерство.