Google Search, YouTube, Gmail, Facebook, Instagram и WhatsApp са сред най-ценните софтуерни продукти в света. Зад тях стоят огромни количества програмен код, разработван в продължение на години от хиляди инженери. Това повдига един любопитен въпрос: как компании като Google и Meta предпазват най-ценните си технологични разработки от кражба или саботаж, след като толкова много служители работят с тях всеки ден?
Отговорът е донякъде изненадващ. Вместо да ограничават максимално достъпа до програмния код, двете компании позволяват на инженерите си да разглеждат големи части от него. Защитата е изградена не толкова около това кой може да прочете даден файл, а около това кой има право да го променя, как промените се проверяват и как достигат до действителните сървъри.
Милиарди редове код на едно място
Още през 2016 г. Google публикува научна статия с показателното заглавие „Защо Google съхранява милиарди редове код в едно хранилище“. В нея компанията описва архитектура, която позволява на десетки хиляди разработчици да работят върху обща програмна основа. Този подход е известен като monorepo – огромно централизирано хранилище, в което се съхранява кодът на множество различни проекти. Вместо всяка услуга да бъде напълно изолирана, разработчиците могат да използват общи библиотеки, инструменти и компоненти.
За да разберем предимството, нека си представим, че инженер открива сериозен проблем в библиотека, използвана от няколко продукта. При отделни хранилища поправката може да изисква координация между множество екипи. В общо хранилище е значително по-лесно да се проследи къде се използва проблемният компонент и да се подготвят необходимите промени.
Meta използва подобна философия. Компанията е разработила собствена система за управление на изходния код, наречена Sapling, която работи с изключително големи хранилища. В техническите си публикации Meta описва инфраструктура с десетки милиони файлове и огромна история от промени. Това не означава, че всеки служител има достъп абсолютно навсякъде. Част от проектите са отделени, а чувствителните компоненти подлежат на допълнителни ограничения. Но основният принцип е ясен: свободното сътрудничество между инженерите е по-ценно от пълната изолация на всеки екип.
Да виждаш кода не означава, че можеш да го променяш
Тук идва най-важната защита. Един разработчик може да открие грешка в компонент, за който не отговаря, и да предложи поправка. Това обаче не означава, че промяната му автоматично става част от програмата. В Google повечето промени трябва да преминат през процедура за преглед на кода (code review). Най-малко още един инженер трябва да ги одобри, а за съответния компонент е необходимо и одобрение от отговорните за него специалисти.
Така разработчик, който реши тайно да добави функция за кражба на пароли, например, не би трябвало да може самостоятелно да я включи в официалната версия на дадена услуга. Промените оставят история, могат да бъдат прегледани и подлежат на автоматизирани проверки. Meta също използва преглед на кода и инструменти, които позволяват на инженерите да подготвят и проверяват последователни промени. Разбира се, това не е абсолютна гаранция. Вторият инженер също може да допусне грешка или да не забележи внимателно прикрита уязвимост. Но системата прави едностранното и незабелязано въвеждане на злонамерен код значително по-трудно.
Дори одобреният код не може просто да бъде пуснат в GoogleОще по-интересна е следващата защитна бариера. Достъпът до програмния код е отделен от правото той да бъде изпълняван върху сървърите, които обслужват реалните потребители. Google описва тази система в техническата си документация за Binary Authorization for Borg (BAB). Тя е част от защитата срещу вътрешни злоупотреби и компрометирани служебни профили.
На практика процесът включва няколко последователни проверки. Кодът първо се преглежда и одобрява, след което се компилира в контролирана среда. Системата създава проверим запис за произхода на готовия софтуер – от кои файлове е създаден, какви зависимости са използвани и дали резултатът е бил променян впоследствие. Преди новата версия да бъде внедрена, инфраструктурата проверява дали тя отговаря на правилата за сигурност.
Това означава, че дори програмист да има достъп до изходния код, той не получава автоматично правото да замени програмата, работеща на сървърите на Google.
Съществува и допълнително разграничение между самоличността на служителя и тази на самата услуга. Програмите използват специални служебни идентичности и разрешения за достъп до други системи и потребителски данни. Инженерът, който пише кода, не получава непременно тези права. Подобни практики са особено важни, защото успешната атака срещу една голяма платформа може да засегне милиони хора.
А какво пречи на служител просто да копира всичко?Това всъщност е по-трудният проблем. Проверката на промените защитава целостта на софтуера, но сама по себе си не предотвратява копирането на изходния код. Затова големите организации използват и други средства: ограничения на достъпа до чувствителни проекти, регистриране и анализ на действията, защита на служебните устройства и системи за предотвратяване на изтичането на информация, известни като DLP.
Такива инструменти могат да засичат подозрителни опити за прехвърляне на големи количества данни към външни системи. В зависимост от настройките те могат да уведомят екипите по сигурността или да блокират дадено действие. Важно е обаче да не си представяме, че всяко отваряне на файл непременно задейства сложна проверка, или че съществува технология, която прави кражбата напълно невъзможна. Точните вътрешни правила на Google и Meta не са публично известни във всички подробности.
Освен това изходният код и потребителските данни са различни неща. Възможността да прочетеш програмата, която обработва дадена информация, не означава, че можеш да видиш личните съобщения, паролите или данните на потребителите.
Големият парадокс: повече свобода може да означава по-добра сигурностПодходът на Google и Meta показва важна промяна в начина, по който се изграждат големите софтуерни системи. Вместо да разчитат единствено на секретността, компаниите съчетават относително широк достъп за разработчиците със строг контрол върху промените и внедряването. Това има и чисто практически предимства. Колкото повече инженери разбират как работят взаимосвързаните системи, толкова по-лесно могат да откриват грешки, да подобряват производителността и да разработват нови функции.
Разбира се, нито една система за сигурност не е съвършена. Недобросъвестни служители, компрометирани профили и човешки грешки остават реални рискове дори за най-големите технологични компании. Но именно затова съвременната защита разчита на множество независими бариери, а не на една-единствена забрана.
Оказва се, че най-добрият начин да защитиш милиарди редове програмен код невинаги е да не позволяваш на никого да ги чете. По-важно е да си сигурен, че никой не може незабелязано да ги промени, използва неправомерно или прехвърли извън компанията.