Lista referencyjna bez Debiana: jak wybrać bazę pod SI

Od roku Twój zespół uruchamia agentów na Debianie. Jest stabilny, ludzie, którzy go utrzymują, są staranni, a każdą linijkę możesz przeczytać. Aż ktoś z bezpieczeństwa przesyła nową architekturę referencyjną NVIDIA dla bezpieczeństwa agentów, opublikowaną 21 października, i na spotkaniu zadaje jedno pytanie: dlaczego nas nie ma na liście?

Lista wymienia Canonical, SUSE i Red Hat dla Linuksa i Kubernetesa, Windows przez Microsoft Execution Containers oraz trzy duże chmury. Debiana na niej nie ma. Szkoda, bo Debian to jedna z najlepiej utrzymywanych baz, jakie istnieją. To też dobra lekcja, bo powód, dla którego go brakuje, nie ma nic wspólnego z jakością kodu.

Prawdziwa przyczyna: lista referencyjna to lista tych, którzy się podpisują

Architektura referencyjna to obietnica, że konkretne zestawienie ktoś złożył, przetestował i za nie odpowiada: to jądro, te sterowniki, to środowisko kontenerów, na tym sprzęcie, z kimś, do kogo zadzwonisz, gdy aktualizacja coś zepsuje. Nazwy na liście to firmy, które walidują, sprzedają wsparcie i biorą na siebie odpowiedzialność. Debian to projekt społeczności, za którym nie stoi jedna firma robiąca wszystkie trzy rzeczy naraz. Otwarty kod to warunek konieczny bazy, której można ufać. Nie jest warunkiem wystarczającym. Kod, który możesz przeczytać, to nie to samo co ktoś, kto przetestował Twoje zestawienie i odbiera telefon.

W przypadku agentów ma to większe znaczenie niż przy większości obciążeń. Agent, który godzinami działa w Twoim imieniu, ma Twój dostęp, czyta niezaufany tekst i na jego podstawie działa. Gdy coś pójdzie źle, „kod był otwarty” to początek dochodzenia, a nie odpowiedź.

Gdzie wybór bazy zwykle się psuje

Czytanie listy jak rankingu. Brak nazwy oznacza, że nikt nie podpisał się pod tym zestawieniem, a nie że jest niebezpieczne. Porzucenie dobrze prowadzonej bazy tylko po to, żeby pasować do listy, to zamiana znanego zachowania na logo.

Traktowanie otwartego kodu jak wsparcia. Możesz go przejrzeć, przebudować i sam załatać. Wszystkie trzy rzeczy to praca i ktoś musi być jej właścicielem, zanim nadejdzie noc, w której będzie potrzebna.

Wybór dostawcy i koniec tematu. Zwalidowana baza obejmuje bazę. Nie mówi nic o tym, co Twoi agenci mogą czytać, dokąd się łączyć i kto zatwierdza ich zapisy. Sam projekt Secure Agent Workspace nazywa swoje fazy kolejno dokładanymi efektami kontroli, a nie etykietami stanu wdrożenia: posiadanie właściwego systemu nie odhacza żadnej z nich.

Ufanie kontrolom wewnątrz gościa, że ochronią gościa. Ten sam projekt mówi to wprost: kontrole w czasie działania trzymają tylko tak długo, jak zaufany jest mechanizm, który je egzekwuje, a ochrona przed przejęciem roota albo jądra systemu gościa musi działać poza nim.

Brak właściciela odbudowy i odwołania. Nikt nie umie powiedzieć, jak szybko przejęta maszyna zostanie odbudowana ze znanego obrazu ani jak szybko wykradzione poświadczenie przestanie działać.

Czego wymagać od bazy zamiast tego

Rozdziel cztery rzeczy, które nazwa na liście wiąże w jedną, i pytaj o każdą osobno.

1. Walidacja: czy ktoś przetestował ten system na Twoim sprzęcie i sterownikach i czy możesz ten test powtórzyć sam?
2. Wsparcie: czy jest konkretna osoba albo firma, która odpowie, gdy aktualizacja zepsuje maszynę?
3. Odpowiedzialność: kto odpowiada na piśmie za awarię i co się dzieje, gdy przestanie?
4. Czytelność: czy możesz przeczytać, przebudować i zweryfikować to, co działa, bez pytania kogokolwiek o zgodę?

Potem użyj modelu dojrzałości z projektu Secure Agent Workspace jako listy kontrolnej dla systemu pod spodem, bo opisuje on dokładnie to, co musi robić system trzymający rój w celach.

Faza 0, podstawa. Znana konfiguracja, poprawki i zarządzanie podatnościami, ochrona obciążeń, zarządzane obrazy, telemetria, którą zespół bezpieczeństwa umie przeczytać, odbudowa i odwołanie. W KyberLinux to parter: obraz niezmienny, zweryfikowany i nudny, z atomowymi aktualizacjami, które da się wycofać.

Faza I, kontrola obwodu. Każdy agent w przestrzeni należącej do jednego użytkownika, na zatwierdzonym obrazie; jedno logowanie i broker dostępu; lista dozwolonych adresów; człowiek przeglądający zapisy; audyt na brzegu. W projekcie Kyber agenci jednej osoby działają w jej własnych celach, a KyberBot pyta Cię przed wszystkim, co wrażliwe.

Faza II, egzekwowanie wokół agenta. Kontrola procesów, plików i sieci wewnątrz systemu, ruch wychodzący domyślnie zablokowany, podpisane zasady sprawdzane przy każdym wywołaniu narzędzia, poświadczenia podawane przez pośrednika, więc agent nigdy ich nie trzyma, inferencja tylko zatwierdzonymi ścieżkami, a zasady pisane, podpisywane i rozsyłane centralnie i weryfikowane, zanim zaczną obowiązywać. Tym ma być cela KyberCell: ustalona przy tworzeniu, z siecią zamkniętą, z sekretami wstrzykiwanymi w punkcie docelowym i z każdym krokiem zapisanym. Od strony agenta celę opisuje KyberAgent w tekście czym jest KyberCell.

Bądźmy uczciwi co do luki, bo sami jesteśmy. KyberLinux też nie ma na tej liście. Jest przed startem, nikt go nie walidował i niczego z tego nie da się dziś zainstalować. Czytelność możemy obiecać z założenia projektu. Walidacja, wsparcie i odpowiedzialność biorą się z ludzi, a w rodzinie Kyber to zadanie KYBERTIS, który opisuje, co uczciwie znaczy SLA na otwartym stacku. Więcej o systemie jest na stronie głównej.

Test, który zrobisz dziś

Weź maszynę, na której dziś działają Twoi agenci, i narysuj trzy kolumny: Faza 0, Faza I, Faza II. W każdej wypisz punkty z listy powyżej i przy każdym postaw „tak”, „nie” albo nazwę: osobę lub firmę, dzięki której to jest prawdą.

Potem odpowiedz na pytanie, które rozstrzyga o bazie: jest trzecia w nocy, aktualizacja jądra właśnie zepsuła sterownik GPU i agenci stanęli. Do kogo dzwonisz? Jeśli możesz wpisać nazwę, masz bazę. Jeśli możesz wpisać tylko adres repozytorium z kodem, masz świetny kod i wakat.