Płaszczyzna sterowania chmurą
Płaszczyzna sterowania chmurą to warstwa interfejsów, API i usług, która umożliwia tworzenie, konfigurowanie i zarządzanie infrastrukturą — w odróżnieniu od płaszczyzny danych, która faktycznie uruchamia obciążenia i przenosi ruch. Każdy dostawca ma własną; termin obejmuje też systemy zarządzające kilkoma dostawcami jako jedną płaszczyzną.
Każdy element infrastruktury ma dwie odrębne warstwy. Płaszczyzna danych to sama infrastruktura: maszyny wirtualne uruchamiające aplikację, sieć przesyłająca między nimi pakiety, dysk obsługujący odczyty i zapisy. Płaszczyzna sterowania to wszystko, czego używasz, by decydować, jak ta infrastruktura ma wyglądać, i by ją zmieniać — API, konsola, CLI, system uprawnień decydujący, kto może dokonać zmiany. Gdy tworzysz maszynę wirtualną w konsoli chmury, zmieniasz rozmiar dysku albo otwierasz port na zaporze sieciowej, obsługujesz płaszczyznę sterowania. Instancja, która się uruchamia, dodatkowe gigabajty, które stają się dostępne, ruch, który zaczyna płynąć — to płaszczyzna danych reagująca na to, co nakazała jej płaszczyzna sterowania.
To rozróżnienie staje się bardziej przydatne, gdy zespół korzysta z więcej niż jednego dostawcy. AWS ma swoją płaszczyznę sterowania. Podobnie Google Cloud, Azure, Hetzner i każdy inny dostawca — każdy z własną konsolą, własnym kształtem API, własnymi poświadczeniami, własnym pomysłem na to, jak nazywa się „security group” czy „firewall rule”. Zespół korzystający z trzech chmur i dwudziestu serwerów bare-metal w praktyce obsługuje trzy lub cztery odrębne płaszczyzny sterowania równolegle, plus cokolwiek, czego używa do zarządzania serwerami, które nie znajdują się w żadnej chmurze. Nic nie zmusza tych płaszczyzn sterowania, by się ze sobą zgadzały, i nic poza własnym procesem zespołu nie sprawia, że zmiana dokonana w jednej z nich jest widoczna dla kogoś patrzącego na inną.
Określenie „płaszczyzna sterowania chmurą” bywa też używane w węższym znaczeniu — w Kubernetesie płaszczyzną sterowania jest API server, scheduler i controller-manager, które decydują, gdzie uruchamiane są pody, w odróżnieniu od kubeletów i kontenerów, które faktycznie je uruchamiają na węzłach. „Multi-cloud” albo „zunifikowana” płaszczyzna sterowania rozszerza tę samą ideę na wielu dostawców: jedno miejsce, w którym można zobaczyć infrastrukturę fizycznie rozproszoną po kilku różnych kontach, regionach i dostawcach i działać na niej, zamiast osobnego interfejsu dla każdego dostawcy. Nie zastępuje ona bazowych płaszczyzn sterowania poszczególnych dostawców — żądanie i tak kończy się jako wywołanie API do AWS, Hetznera albo agenta floty na maszynie bare-metal — stoi przed nimi, dzięki czemu osoba wprowadzająca zmianę musi nauczyć się tylko jednego systemu.
Dlaczego to rozróżnienie ma znaczenie w praktyce
Większość incydentów infrastrukturalnych i luk w audycie ma źródło w problemach płaszczyzny sterowania, nie płaszczyzny danych: zmiana, której nikt nie zalogował, uprawnienie, którego nikt nie odwołał, reguła zapory otwarta w konsoli jednego dostawcy, której nikt inny w zespole nie widzi. Gdy każda chmura ma własną płaszczyznę sterowania i własny ślad audytowy, pytanie „kto to zmienił i kiedy” staje się czymś, na co odpowiada się, logując się do trzech lub czterech różnych konsol i ręcznie porównując znaczniki czasu — albo nie odpowiada się na nie wcale. Dla zespołów działających w ramach regulacji takich jak NIS2 ta luka to nie tylko niedogodność: historia zmian, kontrola dostępu i dowody incydentów to dokładnie to, o co audytor czy regulator pyta jako pierwsze, a rozdrobniona płaszczyzna sterowania jest powodem, dla którego takie dowody często nie istnieją w jednym miejscu.
Jak Sencai się w to wpisuje
Sencai to płaszczyzna sterowania działająca ponad natywnymi płaszczyznami poszczególnych dostawców: łączy się z kontami u jedenastu dostawców chmury oraz z serwerami on-premise i bare-metal za pomocą lekkiego agenta floty, i już w momencie podłączenia konta inwentaryzuje to, co już działa — bez konieczności migracji. Od tego momentu provisioning, uruchamianie, zatrzymywanie, zmiana rozmiaru i usuwanie instancji działa tak samo niezależnie od dostawcy. Możesz podłączyć istniejące konta (nic się nie przenosi, poświadczenia pozostają odwoływalne u dostawcy) albo pozwolić Sencai bezpośrednio udostępniać zasoby i je rozliczać, a także łączyć oba podejścia w ramach jednej organizacji. Każde działanie u każdego podłączonego dostawcy trafia do jednego dziennika audytu typu append-only, powiązanego łańcuchem skrótów (hash chain), więc „kto to zmienił i kiedy” to zapytanie, a nie dochodzenie.
Zobacz inwentaryzację i provisioning →