Пускайте версии без страх в собствената си инфраструктура

Какво изисква нормата и какво не

Много институции държат системите и данните си в собствена инфраструктура — заради модела си на риск, договорите си или наследените си системи. Те не са малцинство: според проучването на CNCF от 2024 г. 59 % от участниците ползват собствена инфраструктура със самостоятелно управление, колкото и публичен облак със самостоятелно управление (750 участници от общността ѝ). Да работите у дома не е извинение да пускате версии без дисциплина.

Едно уточнение, което е добре да имате ясно пред всеки комитет: по принцип мексиканската регулация не налага инфраструктурата да бъде у дома. Разпоредбите на CNBV за банките допускат собствена инфраструктура или такава на трети страни, включително в чужбина, с изисквания, които зависят от услугата: предварително уведомление или разрешение, непрекъснатост при срив на доставчика и достъп на органа до информацията. Законът за личните данни също не определя задължително местоположение, но поставя условия за обработването и предаването им. Подробностите се проверяват за всяка организация и всяка услуга.

Това, което тези рамки искат, е да докажете контрол: доказателства и проследимост, съразмерни на риска. Собствената инфраструктура не го гарантира. Променя се отговорността: у дома целият контрол и цялото ограничаване на риска са Ваши. Ако пътят до продукция е изграден добре, този контрол се доказва с доказателства, а не с обещания.

Позволява ли сегашната Ви инфраструктура да докажете този контрол със същата дисциплина като в публичен облак? Облак и инфраструктура

Какво идва незащитено от завода

Клъстер, който минава функционалните тестове, може да не издържи одит за сигурност, ако е запазил фабричната си конфигурация. Според официалната документация на Kubernetes и ръководството за заздравяване на NSA и CISA няколко неща са така по подразбиране:

• Тайните се съхраняват некриптирани в базата на клъстера.
• Одитният дневник е изключен .
• Пространствата от имена не изолират мрежата: без изрични политики всичко общува с всичко.
• В клъстери, създадени с kubeadm, клиентските сертификати изтичат след една година по подразбиране. Подновяват се с обновленията или чрез изрична процедура; ако никой не го направи, клъстерът спира да отговаря в някой обикновен ден.

И има един физически параметър, който почти никой не измерва: хранилището за състоянието на клъстера (etcd) е много чувствително към забавянето на диска. Ръководството му за хардуер дава като ориентир 50 последователни операции в секунда и 500 за натоварени клъстери и препоръчва твърдотелен диск. При високо или силно променливо забавяне симптомът не е „бавно е“: това са изтекли времена за изчакване, избори на водач и спадове в наличността. Измерва се с представителни натоварващи тестове, преди продукция.

Може ли някой във Вашия екип да каже днес, без да търси, кога изтичат сертификатите на клъстера Ви?

Един-единствен път до продукция

От промяната на програмиста до продукция всичко минава по един и същи път и всяка контролна точка може да спре пускането:

1. Тестове, които спират. Задължителните тестове блокират преминаването; неубедителните сигнали се записват и се разглеждат по изрична политика. За спешен случай има процедура за изключение, с одобрение и следа.
2. Качество с видима причина. Контролната точка не се задоволява с „приключи добре“: казва кое условие е нарушено.
3. Сканиране по категории: код, зависимости, изложени тайни, образи и конфигурация, с прагове и проследими изключения. И различава „намери нещо“ от „не довърши проверката“: и двете спират пускането.
4. Изграждане веднъж, преминаване на същото. Това, което е тествано, е това, което стига до продукция; не се прекомпилира за всяка среда. Конфигурацията и тайните на всяка среда се контролират отделно, с версия и следа.
5. Неуспех рано и ясно. Ако на сървъра за изграждане му липсва нещо, се проваля още на първата стъпка и казва какво липсва.

Какво проверява днес процесът Ви, преди да стигне до продукция, и какво пропуска, без никой да забележи? DevSecOps

Без интернет скенерът също остарява

В изолирана мрежа най-пренебрегваната част е най-тихата: базата с уязвимости на скенера. Ако никой не я обновява, скенерът продължава да казва „няма находки“, защото не познава новото. Някои инструменти отказват да работят с база, по-стара от пет дни; други остават зелени със замразена база. Добре изграденият изолиран път носи собствено огледало на тези бази, с видима дата и сигнал, когато остарее.

Знае ли скенерът Ви за уязвимостите, публикувани тази седмица? DevSecOps

Три дестинации, един и същ критерий

Контролните точки и доказателствата се използват повторно между дестинациите; всяка дестинация запазва собствените си изисквания за внедряване, самоличност, мониторинг и възстановяване, а преминаването към Kubernetes налага да се проектират наново няколко от тях.

Коя от трите е Вашата днес и коя трябва да бъде след две години?

Грешки, които виждаме често

• Дублирани и неуправлявани процеси за пускане. Когато всеки екип поддържа собствено копие, копията се разминават тихо и доказателствата вече не са съпоставими. По-добре един споделен шаблон с версии.
• Ръчно инсталиране от инструмента за изграждане. Смесването на „който изгражда“ с „който инсталира“ оставя промени без следа. По-добре да се разделят и средата да се описва като код.
• Временни изключения, които стават постоянни. Контролът, пропуснат „само в разработка“, е този, който после се проваля в продукция.
• Разпръснати самоличности. Собствената директория на оркестратора, отделна от тази на компанията, трупа осиротели акаунти с високи права (NIST SP 800-190).

Други контроли, които често са от значение — управление на тайните, подпис и опис на това, което се пуска, одобрение от човек за продукция, разделяне на задълженията, възстановяване и съхранение — се определят според Вашия модел на риск.