«Мій день спрямований на те, щоб полегшити завдання іншим». Анастасія Войтова з Cossack Labs — про те, як змінила мобільну розробку на криптографію, ієрархію в команді та Women Who Code

Анастасія Войтова — Head of Customer Solutions та Security Software Engineer в Cossack Labs. Також вона Security Lead в неурядовій організації Women Who Code Kyiv.

У новому випуску рубрики «Що потім?» Анастасія розповіла, чому перейшла у сферу безпеки даних з розробки мобільних застосунків, як доросла до ролі Head of Customer Solutions, яким компаніям потрібні кастомні безпекові рішення та навіщо жінки об’єднуються у спільноту Women Who Code.

👉🏼У відео на YouTube проходить конкурс!

«Неможливо класний безпековий продукт інтегрувати в погану інфраструктуру й сказати, що результат буде відмінний». Про специфіку Cossack Labs і команди

Cossack Labs — це продуктова компанія, що розробляє спеціалізовані рішення з безпеки даних. Серед наших продуктів є й open source криптобібліотеки, і платні рішення. Наші клієнти мають багато даних і хвилюються, що їх можуть вкрасти. Інколи ми радимо взяти готовий інструмент, інколи кажемо, що для вирішення проблеми треба писати протоколи або розробити кастомне рішення, в якому буде і шифрування даних, і антифрод, і щось на бекенді — це вже рівень процесів.

Неможливо класний безпековий продукт інтегрувати в погану інфраструктуру й сказати, що результат буде відмінний. Тому інколи нам доводиться робити суто сервісні речі: перевірити, як у клієнтів працює екосистема, як вони вирішують бізнес-завдання з погляду безпеки. Ми не аутсорсер, радше solution provider.

За внутрішнім поділом у Cossack Labs є окрема команда, яка здебільшого займається продуктами; є інфраструктурна команда; а ще команда, яка розуміється на побудові security engineering & architecture. Також окреме crypto R&D — це люди зі спеціальною підготовкою, яких майже немає в Україні. Від них ми не очікуємо класного коду, але такі фахівці розуміють криптографію, як ніхто інший.

«Моя роль — знайти, як розв’язати проблему клієнта, або сказати: „Це не проблема для вас“». Про кар’єру в Cossack Labs і обов’язки Head of Customer Solutions

Спочатку [у 2017–2019 роках, коли влаштувалася на фултайм у Cossack Labs — ред.] я працювала як Product Engineer. Відповідала за те, щоб продукти реалізували. Ми багато комунікуємо з людьми та розуміємо, коли виникають проблеми, притаманні не одній компанії, а наше рішення може спростити життя багатьом. На цій позиції я опікувалася і розвитком продуктів, щоб вони вимагали мінімум зусиль, й давали максимум цінності.

Один з прикладів — криптографічна open source бібліотека Themis 14 мовами. Вона для розробників, які нічого не розуміють в криптографії, але яким треба зашифрувати дані. Спеціалісти не знають про шифри, режими, типові помилки, про те, який потрібен ключ абощо. Але можуть убезпечити дані завдяки цій бібліотеці, додавши її та виконавши два рядки коду.

А оскільки там 14 мов, бібліотека чудово підходить для кросплатформових застосунків. Наприклад, вам потрібно дані з iOS зашифрувати, на Android розшифрувати, ще й на бекенді порахувати. І для цього є одна наша бібліотека.

Для девелоперської частини є ніч, бо це не вимога бізнесу

З 2019-го моя позиція змінилася на Head of Customer Solutions і Security Software Engineer. Head of Customer Solutions — це середній менеджмент. На цьому ж рівні працюють Head of Product чи Head of Marketing. Вище стоять CTO, CFO та інші. Я відповідаю за напрями продуктів і кастомних рішень. Моя роль — знайти, як розв’язати проблему клієнта, або сказати: «Це не проблема для вас». Також я координую команди всередині компанії.

Мій день зазвичай доволі хаотичний. Але він спрямований на те, щоб полегшити завдання іншим. Частина моєї роботи — менеджерська, а частина — Individual contributor, такий собі супермікс.

Вдень у мене чимало клієнтських та внутрішніх зідзвонів, я допомагаю командам. Та, крім цього, я розробниця — все ще дуже люблю сама щось робити. І для девелоперської частини є ніч, бо це не вимога бізнесу.

Компанія хоч і не швидко, але зростає, з’являються нові виклики й виникають конфлікти інтересів, коли ви вже не можете бути одночасно і класним менеджером, і класним розробником. Тому бізнес хоче, щоб я більше делегувала обов’язки, а я хочу час від часу забруднити руки, так би мовити. Тобто вночі можу сидіти й займатися криптографією.

Я інтроверт і не завжди радію спілкуванню з іншими. Але розумію, для чого це роблю. Не люблю, коли раптово виникає реактивна робота. Тобто коли я спланувала день, втім щось зламалося і треба на це реагувати. Важко перемкнути контекст. Вдень я маю більше стратегічних завдань, а вночі інженерних. Для останніх потрібно більше часу й фокусування. Я дуже фруструю, коли три години в плані виділила на дослідження, а мене відволікають.

«Я створювала класні застосунки, але вони не були безпечними». Про перші мобільні застосунки й перехід у безпеку даних

Я закінчувала гімназію № 153 в Києві, де нас муштрували шість днів на тиждень. Але коли пішла до університету, зрозуміла, що мій рівень підготовки трохи вищий, ніж в інших, і це було прикольно. Я була студенткою Київського політехнічного інституту, факультет «Інформатика й обчислювальна техніка». Іспити склала так добре, що могла обирати, куди вступати. І керувалася принципом наближеності до дому. Університету ім. Шевченка, наприклад, не віддала перевагу просто тому, що до нього було складно доїжджати.

Коли навчалася, вже працювала: розробляла мобільні застосунки — це були дрібні халтурки. А коли закінчила чотири курси, потрапила в компанію Stanfy. Тоді це був суворий світ Objective-C та Java. У Stanfy мені пропонували позицію iOS Developer, а працювати треба було з Objective-C, яку ніхто не знав (зараз її вже ніхто не знає, а тоді ще ніхто не знав). Я, звісно, вчила С в університеті, готувалася до інтерв’ю і зрештою гарно відповіла на питання. Мене взяли, але перші місяці я ще вивчала Objective-C за туторіалами.

Те, що роблю, — класно, але й погано водночас

Згодом зрозуміла, що в моїй галузі дуже багато залежить від бекенду. Мобільні застосунки бувають різні, але часто це «товста» клієнтська апка, бо тут є чимало бізнес-логіки. Тож, аби програми були кращі, мені потрібен хороший бекенд. І я почала його писати на Node.js. Мої бекенди були просто мистецтвом (жартую). Втім продукти ставали більшими: і iOS, і Android, і бекенд — і в якийсь момент у мене з’явилася велика команда.

Та зрештою дійшла висновку: те, що роблю, — класно, але й погано водночас. Це сталося, щойно зрозуміла Dataflow: як дані з клієнтського застосунку потрапляють на бекенд, у базу, де відбувається бекап тощо. Я створювала класні застосунки, але вони не були безпечними. Наприклад, одним з проєктів був медичний — для лікаря у Нью-Йорку. І виходило так, що застосунок вже крутився в продакшені, а я могла зайти й побачити реальні дані реальних людей. Такого не має бути.

Я зрозуміла, що з цим треба щось робити. І на цьому етапі почалися проблеми. Адже якою б класною не була бутикова компанія, в неї немає продукту, про який можна сказати «це мій продукт». Інколи я щось переробляла чи доробляла з безпеки, тому що мені здавалося, що це важливо, навіть коли ми не виставляли за це рахунок клієнту. Але в мене було мало таких можливостей. А розповідати клієнтам, що безпека важлива — дивно, бо виходить, вчора це було неважливо, а сьогодні стало?

Так я почала придивлятися до теми інформаційної безпеки. Тоді ж друзі попросили допомогти з мобільними платформами в криптографічній бібліотеці. І це був хук — займаюся цим вже п’ятий рік для них. Хоча здебільшого до інформаційної безпеки я бачила багато спротиву. Мовляв, у нас і так все гарно. А якщо було таки негарно, то людей це просто не цікавило.

Але насправді не лише мене бентежила безпека даних. Тоді ухвалили низку законів з безпеки й приватності. Я називаю це тиском ринку. Так у мене з’явилися причини, чому варто в цьому працювати.

«Трапляється, що компанії вдаються до тиску, аби додати страху й взяти більше грошей». Про те, чи кожен бізнес має думати про безпеку

Бентежитися щодо інформаційної безпеки всім компаніям точно не потрібно. Є така річ, як ризик-менеджмент: ми розуміємо, що кількість потрібної безпеки залежить від рівня ризику і тієї проблеми, яка може виникнути, раптом що. Безпека з погляду цифрових продуктів — це функція бізнесу. Ми можемо створити суперпараноїдальний і безпечний застосунок, але ним ніхто не буде користуватися.

Є різні види безпеки. Щоб фізично нашкодити, потрібно бути на певній відстані від людини чи об’єкта. А з погляду кібербезпеки зловмисник може сидіти в умовному підвалі, а впливати на світові корпорації, які розташовані на іншому континенті. Тобто можна вчинити багато поганого, незалежно від відстані, законів держави, тому що є технології, інтернет. Тому що розробники лажають.

Зрозуміло, якщо робите інстаграм для котиків і у вас немає жодних приватних даних людей, немає бізнесових даних компаній, вам, можливо, й не потрібен неабиякий рівень безпеки. А якщо йдеться про електростанції? Коли вранці люди вмикають світло в Києві, вони вже стикаються з малесеньким шматочком нашого криптографічного коду, який захищає обмін даними та командами в енергосистемах. І там інший рівень ризиків. Споживання і витрачання в енергомережі мають бути в балансі. Якщо дуже примітивно це пояснювати, то якщо надсилати неправильні дані про генерацію, то можна неправильно розрахувати й ту чи іншу станцію перевантажити. Буває, що компанії вдаються до тиску, аби отримати клієнта.

Однак трапляється, що компанії вдаються до тиску, аби отримати клієнта. На Вікіпедії є стаття про FUD. Це про психологічно-маніпулятивний прийом, яким користуються люди, щоб додати страху й взяти більше грошей. Серед вендорів, особливо великих, це поширена тема. Бо багато того, що відбувається у світі в галузі безпеки даних, пов’язано зі стандартами й комплаєнсом. Варто розрізняти checkbox security, коли є стандарти, навпроти яких потрібно просто проставити галочки, і pragmatic security, коли дивишся, що насправді може відбутися. Ці речі не завжди корелюють між собою.

«Багато хто не розуміє, що security — це парасольковий термін, він дуже широкий». Про підходи до впровадження безпеки в компаніях

Коли в компанії є Head of Security — це супер! Бо це означає, що команда вже стикнулася з проблемою і розуміє, яке рішення шукає. Хоча трапляється і видимість праці, коли для реальної безпеки нічого не роблять, бо це складно і незручно. Особливо це стосується маленьких компаній.

Часом буває, що продукт має певні проблеми. Це ще не баг, але може призвести до безпекової вразливості. Діяти в такому разі можна по-різному. Наприклад, сказати інженерам повністю переробити продукт, на що ніхто не пристане. Або запропонувати змінити модуль, додати валідацію inputs тощо. Це як робота з технічним боргом, і це про Security Engineering.

У Cossack Labs, наприклад, є команда Infrastructure Engineers, які опікуються питаннями операційної діяльності, частина з яких стосується безпеки. Але не в security-компаніях все по-іншому. Якщо це величезна продуктова компанія, в неї в неї Security Operations можуть займатися як інфраструктурою, так і процесами. І не лише вони. Є девелопери, які одночасно з основними завданнями розробляють безпекові фічі. Або архітектори, які стежать за тим, щоб про безпеку як про одну з нефункціональних вимог під час дизайну нових фіч не забули. Варіантів безліч. Security — це парасольковий термін, він дуже широкий. А людина, що займається безпекою, може працювати в багатьох сферах. Це як з адвокатом, який спеціалізується на певних питаннях.

Також існують стандарти й регуляції. Є blue team — ті, хто будують, захищають системи й продукт. Є red team — Offensive Security — ті, хто ламають, шукають баги. Є ще purple team — це мікс двох попередніх. Адже ідея, що мають бути окремі люди, які займаються окремими речами — така собі. Це як розробники й тестувальники окремо. Нерідко компаніям потрібні спеціалісти, які працюють комплексно.

«Цінність безпеки — не набір фіч, процесів, не дискусія, який парольний менеджер обрати». Про те, чому безпека має бути скрізь

Для продуктів Cossack Labs суперважливо, щоб інженери добре знали фічу, розуміли, як її використовуватимуть і, головне, що ми будемо з нею робити за рік чи три. А є компанії, де це не важливо. Я не кажу про різницю між продуктом і аутсорсом. Це про ownership. Чи здатен інженер вести цілком продукт? Від початку до кінця. Це не означає писати 15 мовами. Це означає розуміти, як все створено та яку цінність дає. Це про те, щоб говорити з колегами, просити допомогти, пропонувати зробити нову фічу чи закрити стару, йти на конференції з доповідями, щоб дивитися фідбек.

Фіча — це не лінія коду

Кожна компанія сама обирає свій шлях. Деяким підходить варіант, де чітко поділені ролі й кожен робить щось своє. А деяким ні, інакше не було б таких ідей, як фіча-команди — рівень управління компанією, коли є не ієрархія з маленькими квадратиками, а більш стохастичні процеси.

В інтерв’ю з Preply на DOU мовилося про те, що класно, коли розробник повністю контролює фічу. Фіча — це не лінія коду. Як і цінність. Цінність — це функціональність, те, що спрощує життя. Тут так само: цінність безпеки — не набір фіч, процесів, не дискусія, який парольний менеджер обрати. Цінність у тому, щоби пушити це скрізь: в коді, інфраструктурі, в тому, як розробники працюють, і в тому, як писати криптографію.

«Приходять кандидати Senior-рівня, які гарно вміють робити руками, але дуже погано орієнтуються в тому, як працює інтернет». Про рекрутинг у Cossack Labs і власну інтернатуру

У Cossack Labs немає рекрутера. Люди, які відповідають за певний напрям, набирають собі спеціалістів. Спочатку ми дивимося резюме, далі — інтро (на цьому етапі розповідаємо про наш пайплайн), потім — тестове, а відтак технічне інтерв’ю.

Я беру участь в інтерв’ю, коли моя команда шукає людину. Наприклад, коли потрібен Infrastructure Engineer, я запитую про безпеку: що таке TLS, як він працює, яка версія актуальна, чому, які шифри. Інколи людина має колосальний досвід, працює з цим щодня, але навіть не замислюється, як усе функціонує. А в нас така сфера, де ці знання потрібні. Тому й інтерв’ю суворе.

Інколи ми питаємо, що таке POSIX signals, і робимо це не тому, що перевіряємо ерудицію кандидата, а тому, що в нас є софт, який відповідає на POSIX signals. А зараз приходять кандидати-девопси Senior-рівня, які гарно вміють робити руками, але дуже погано орієнтуються в тому, як працює інтернет, операційна система, де їхня частина роботи, як вона впливає на інше. Наш софт інтегрується в інші системи. І якщо не розумієш, як це все працює разом, буде просто важко.

Наймати людей складно через нашу специфіку. Але є ті, хто зацікавлений у співпраці з нами, й інколи ми зустрічаємося та спілкуємося з ними. Криптографія — вузька спеціалізація. В Україні це військова спеціалізація, бо мова про захист даних держави. Й це робить воронку тих, хто може до нас потрапити, ще більш вузькою. Наприклад, в нашій команді є криптограф, PhD, майор у минулому.

Крім того, є інтернатура, бо треба вирощувати своїх спеціалістів. Торік ми запустили першу криптографічну інтернатуру для студентів старших курсів, де пропонуємо опанувати професію в crypto R&D. Це розуміння наукової криптографії, математики, багато програмування. Ми платимо студентам, щоб вони вирішували модулі, здавали код, ми його перевіряли, вони робили дослідження і потім презентацію.

Одне з питань, яке ми ставили: чи можуть інтерни розказати не криптографам про те, що дізналися. Бо для нас важливо, як люди комунікують у команді. На першій інтернатурі було двоє студентів, одного ми найняли на парт-тайм, бо він ще в магістратурі.

«На моїх очах будуються кар’єри, бо дівчата спробували себе». Про значущість організації Women Who Code

Women Who Code — міжнародна глобальна неурядова організація. Я Security Lead у Women Who Code Kyiv, яка більше схожа на Women Who Code Ukraine, бо ця група об’єднує інженерок з усієї країни. Наша філія дуже незалежна. Глобальна організація не пов’язана з нашими локальними мітапами, бо Women Who Code радше допомагає та підтримує тим, що дає змогу, наприклад, їздити на інші івенти й повністю оплачує квиток на літак, проживання.

Спочатку в мене було неоднозначне ставлення до організації. І чотири роки тому, коли я потрапила на першу зустріч, думала, що це за лажа. А потім зрозуміла цінність. Це класне ком’юніті жінок, які працюють на технічних спеціальностях в різних компаніях. На івентах приємна атмосфера, доповідачки, аудиторія. Не було проявів сексизму, ніхто не ставив питань, щоб загнобити доповідача.

Цінність у тому, щоб показати жінкам, як може бути, і спростити процес найму. Коли жінки працюють у компаніях, де їм комфортно, вони починають шукати собі в команду інших жінок. Це про співдружність, яка розростається.

За роки існування нашої організації багато жінок стали виступати на конференціях, в яких раніше не брали участі. На моїх очах будуються кар’єри, бо дівчата спробували себе. Вони почали виходити на міжнародну сцену, їхній бренд став сильнішим, видимим. Наприклад, Юля Ващенко [macOS-розробниця, директорка Women Who Code Kyiv — ред.] зараз працює в Apple як Software Engineer. Я не кажу, що Women Who Code була причиною цього. Але таке середовище спонукає, надихає людей дивитися, що ще є, крім моєї компанії, де, наприклад, чимало сексизму.

«Коли самі собі кажете „ні“, постійно втрачаєте шанси». Про самолімітування

Інколи люди самі себе обмежують у тому, що їм робити, а що ні. Наприклад, щось написали, втім не публікуєте. Або хочете податися на конференцію, але відмовляєтесь, бо думаєте, що ви недостатньо хороший фахівець і не маєте про що розповісти. Та якщо розібратися, в цьому випадку частина відповідальності лежить на організаторах. Якщо спікер не справляється, це відповідальність організаторів, бо вони запросили людину, доповідь якої не бачили, не знають, як вона виступала раніше.

Вони мали б запропонувати порепетирувати, надати фідбек, щоб зробити доповідь кращою. Є щось, за що доповідач несе відповідальність (як подати контент, провести репетицію, отримати відгуки), а є те, що поза зоною його відповідальності. Наприклад, тема може підійти чи ні, але є позиціонування. Важливо правильно виставляти очікування: якщо тема для новачків, треба писати про це в описі. А просто відмовлятися виступати не слід.

Мені здається, це самолімітування. Я б такого не робила. Зрештою інші люди й так можуть вас у чомусь обмежити. Коли самі собі кажете «ні», постійно втрачаєте шанси.

«Треба було кидати писати мобільні застосунки раніше». Про помилки в кар’єрі

Я ні про що не шкодую. Але, думаю, могла б рухатися швидше.

Треба було кидати писати мобільні застосунки ще раніше. У світі безліч цікавого, а я стільки часу створювала продукти не для себе й ті, які не мали такої класної цілі та ідеї.
Я пробувала дуже різне. Наприклад, працювала за невеликим контрактами в Дубаї, розробляла на фрилансі. Мені здається, якби я раніше відійшла від написання коду й дивилася, що є ще, як я можу управляти цінністю продукту, було б краще.

Коли ознайомилася з софтверною архітектурою, подумала, що мені цього реально бракувало. Звичайно, в університеті ми вчили патерни програмування. Коли ознайомилася з System Design, софтверною архітектурою, подумала, що мені цього реально бракувало. Звичайно, в університеті ми вчили патерни програмування. Але який сенс на першому курсі опановувати це? У мене тоді не було релевантного досвіду. А коли я вже зробила класні й погані продукти, правильні й жахливі архітектури, тоді зрозуміла цінність.

«Мені важливо знати, що є свобода, що я можу щось зініціювати чи припинити». Про розвиток і принцип Пітера

Нині я працюю у продуктовій компанії, маю її частку й роблю все, щоб бізнес з часом заробляв мільйони. Тому, думаю, я можу отримати вдосталь грошей на життя й накопичити умовних п’ять мільйонів доларів.

Але мені здається, якщо хочете грошей, є простіші шляхи. Не треба писати код 15 мовами на 15 платформах. Можна поєднувати дві-три роботи, підвищувати погодинні рейти. Кількість грошей не непряму залежить від якості чи складності завдань. Якщо ставити за мету заробити п’ять мільйонів доларів, це можна зробити не в криптографії та навіть не в IT.

Мене завжди цікавила інфраструктура, тож інколи жартую, що могла б піти в DevOps. Якщо говорити не про технічні спеціальності, то сьогодні я заглиблена в маркетинг і трохи в продажі. Коли навчалася в університеті, думала, що маркетинг — це не цікаво. Але я помилялася.

Дуже цікаво довідуватися, як працювати з аудиторією, які є люди, які в них інтереси, навіщо їм розв’язувати проблеми з безпеки, які є інші способи розв’язати їх тощо. Я не займаюся цим фултайм, але дивлюся, як працює відділ, й інколи вношу свої корективи. Бо маркетинг у світі інформаційної безпеки — дуже технічна тема. Є чимало речей, які не можна говорити, а якщо й можна, то дуже обережно. Тому наш маркетинг працює в тісній комунікації з інженерами, зокрема безпековими.

Якби я не пішла в IТ, думаю, займалася б дослідженнями з генетики, біохімії. Я б писала не на JS, а мовою R

У новій роботі мене може зацікавити вплив на продукт і цінність компанії. Я не люблю виконувати те, що мені просто сказали, і виходить у мене це не дуже добре. Мені цікаво, коли можна мати власний беклог і потрохи його реалізовувати, синхронізуючись з менеджерами компанії. Мені важливо знати, що в мене є свобода, що я можу щось зініціювати та припинити. Якщо цього немає, мені точно буде нецікаво.

За п’ять років я бачу себе дуже заможною людиною, яка спить годин по вісім :) Напевно, на той час буду вже С-левелом у компанії — це органічний розвиток кар’єри. Далі, можливо, отримаю більш бізнесові сертифікації — зараз придивляюся до цього. Тобто органічно зростатиму з часом, щоб заробити більше грошей і робити менше завдань. Я думаю, що все ще буду зацікавлена в безпеці та криптографії просто тому, що це неабиякий величезний світ, а я дізналася лише маленьку частинку з нього.

Скільки працювати в компанії, аби не пересидіти, залежить від самої компанії. Я намагаюся відповідати за новий напрям кожні два-три роки. Це про зміни в компанії: змінюється вона й моя позиція в ній. Якщо ми все ще йдемо в одному напрямку, чому нам розходитися? Якщо минає два-три роки, а все лишається так, як було, або якщо процеси чи люди починають фруструвати, це класний дзвіночок, що, може, щось іде не так.

Найбільше мене турбує принцип Пітера [теза з однойменної книги Лоуренса Пітера: «В ієрархічній системі будь-який працівник підіймається до рівня своєї некомпетентності» — ред.]. Тобто я хочу зростати, але так, щоб раптом не опинитися на позиції, про яку я нічого не знаю, погано виконую роботу, але тримаюся за місце.


Підписуйтесь на наш YouTube, щоб не пропускати нові випуски.

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному2
Підписатись на автора
LinkedIn



6 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Завжди приємно бачити інтервʼю зі старими знайомими )

Класне інтерв’ю! І окреме дякую за те що років 5 назад, в лоббі на якийсь конфі в Києві, ти дуже зрозуміло та цікаво розповіла що таке та як використовуються асиметричне шифрування :)

Артууур! Хаха, так, було таке :)

Чудова гостя та інтерв’ю!

Підписатись на коментарі