Chmura spotyka brzeg sieci: dlaczego cyberbezpieczeństwo staje się trudniejsze

Przez lata o „chmurze” mówiono jak o odległym centrum dowodzenia internetem: dane płyną do dużych serwerowni, tam są analizowane, a wyniki wracają do aplikacji. Ten obraz jest już niepełny. Coraz częściej część obliczeń odbywa się bliżej miejsca, w którym dane powstają — w urządzeniach, bramkach IoT, lokalnych serwerach, stacjach bazowych czy systemach przemysłowych. To właśnie nazywamy edge computingiem, czyli przetwarzaniem na brzegu sieci.

Artykuł opublikowany w International Journal of Cyberspace Security analizuje, co dzieje się z cyberbezpieczeństwem, gdy chmura i edge computing zaczynają działać jako jeden, rozproszony ekosystem. Autor nie przedstawia pojedynczego eksperymentu laboratoryjnego, lecz systematyczną analizę 135 publikacji naukowych oraz 52 opisanych publicznie incydentów z lat 2023–2025. Na tej podstawie proponuje ramę obrony adaptacyjnej — koncepcję, która ma łączyć ocenę ryzyka, zabezpieczenia techniczne, zgodność regulacyjną i wymianę informacji o zagrożeniach.

Dlaczego „brzeg sieci” stał się tak ważny

Cloud-edge computing, czyli połączenie chmury z przetwarzaniem brzegowym, odpowiada na bardzo praktyczny problem: nie wszystko da się wygodnie i szybko przetwarzać w odległym centrum danych. W autonomicznym transporcie, monitoringu przemysłowym, inteligentnych miastach czy niektórych systemach zdrowotnych liczą się milisekundy, a przesyłanie ogromnych ilości danych do chmury może być kosztowne i zbyt wolne.

W takim modelu chmura nadal zapewnia skalę: duże zasoby obliczeniowe, archiwizację, analitykę i zarządzanie. Edge odpowiada za szybkie działania lokalne: wstępne filtrowanie danych, reakcję na zdarzenia, obsługę urządzeń lub aplikacji działających blisko użytkownika. W teorii brzmi to jak rozsądny podział zadań. W praktyce oznacza jednak, że system przestaje mieć jeden wyraźny środek ciężkości.

Autor analizowanego artykułu zwraca uwagę, że właśnie ta rozproszona natura jest źródłem trudności. W jednym środowisku mogą działać małe urządzenia IoT, lokalne kontrolery przemysłowe, serwery brzegowe, sieci bezprzewodowe, platformy chmurowe i narzędzia do automatycznego zarządzania zasobami. Każdy element może mieć inne oprogramowanie, inną moc obliczeniową, inny cykl aktualizacji i inny poziom ochrony.

Cztery warstwy ryzyka, a nie jeden problem

Wyniki badania zostały uporządkowane w cztery główne obszary podatności: warstwę urządzeń brzegowych, komunikację, orkiestrację cloud-edge oraz cykl życia danych. To ważne rozróżnienie, bo pokazuje, że cyberbezpieczeństwo w takim środowisku nie sprowadza się do jednego „lepszego firewalla”.

Urządzenia brzegowe: najbliżej świata fizycznego

Do tej warstwy należą m.in. bramki IoT, lokalne serwery, kontrolery przemysłowe i urządzenia końcowe. Według analizy odpowiadały one za około 28% opisanych naruszeń w środowiskach cloud-edge. Autorzy omawianych źródeł wskazywali przede wszystkim na słabe uwierzytelnianie, przestarzałe oprogramowanie oraz ryzyko fizycznej ingerencji w sprzęt.

Problem jest intuicyjny: urządzenia działające „w terenie” bywają mniej chronione niż serwery w centrum danych. Mogą stać w fabryce, przy drodze, w budynku użyteczności publicznej albo w miejscu, do którego dostęp ma wiele osób. Jednocześnie nie zawsze mają wystarczające zasoby, by uruchamiać ciężkie narzędzia bezpieczeństwa. To sprawia, że standardowe rozwiązania znane z dużych systemów chmurowych nie zawsze pasują do realiów brzegu sieci.

Komunikacja: dane w ruchu

Największy udział w analizowanych incydentach przypisano warstwie komunikacyjnej — około 32%. Chodzi o kanały przesyłania danych między urządzeniami, lokalnymi węzłami i chmurą. W badaniu wskazano m.in. na używanie niezaszyfrowanych lub starszych protokołów, ataki typu man-in-the-middle oraz ryzyka wynikające z częstych przełączeń między węzłami i sieciami.

W klasycznej chmurze duża część kontroli koncentruje się w jednym dobrze zarządzanym środowisku. W modelu cloud-edge dane częściej przemieszczają się między wieloma punktami. Jeśli część transmisji nie jest właściwie zabezpieczona, rośnie ryzyko podsłuchania, podmiany lub utraty integralności informacji. Badanie przywołuje przykłady incydentów z obszaru inteligentnych sieci energetycznych i telemedycyny, ale należy traktować je jako ilustrację problemu, a nie dowód, że każda podobna usługa jest narażona w tym samym stopniu.

Orkiestracja: niewidzialny dyrygent systemu

Orkiestracja to zarządzanie tym, gdzie uruchamiane są usługi, jak przydzielane są zasoby, które urządzenia komunikują się z chmurą i jakie konfiguracje są wdrażane. Według analizowanego artykułu podatności w tej warstwie stanowiły około 22% naruszeń, ale ich skutki mogą być szerokie, ponieważ błąd w mechanizmach zarządzania może dotknąć wiele elementów naraz.

Autor wskazuje na trzy typowe źródła problemów: nieodpowiednio zabezpieczone interfejsy programistyczne, błędy konfiguracji oraz zbyt szerokie uprawnienia dostępu. To nie są nowe kategorie ryzyka w cyberbezpieczeństwie, ale w środowisku cloud-edge nabierają dodatkowego znaczenia. Jeden błędnie skonfigurowany mechanizm może wpływać na setki lub tysiące węzłów brzegowych.

Dane od zebrania do analizy

Ostatnia warstwa dotyczy całego cyklu życia danych: ich zbierania, przesyłania, przechowywania, przetwarzania i usuwania. W analizie odpowiadała za około 18% naruszeń. Wśród problemów wymieniono przechowywanie danych bez odpowiedniego szyfrowania, zbieranie większej ilości informacji niż jest potrzebna oraz niewystarczające mechanizmy kontroli dostępu.

To szczególnie istotne w sektorach, w których przetwarzane są informacje wrażliwe, np. w systemach zdrowotnych, przemysłowych lub konsumenckich usługach smart home. Artykuł nie daje podstaw do prostych uogólnień typu „edge jest niebezpieczny dla prywatności”. Pokazuje raczej, że im bardziej złożona droga danych, tym trudniej zachować pełną kontrolę nad tym, kto, gdzie i w jakim celu ma do nich dostęp.

Co już działa, a co nadal jest trudne

Autor analizuje trzy grupy rozwiązań ochronnych: wykrywanie zagrożeń bezpośrednio na brzegu sieci, bezpieczną orkiestrację oraz techniki przetwarzania danych z większą ochroną prywatności. W publikacji podkreślono, że każde z tych podejść ma obiecujące wyniki, ale żadne nie jest uniwersalnym lekarstwem.

Lekkie systemy wykrywania włamań dla urządzeń brzegowych mogą reagować szybciej niż rozwiązania, które wszystko wysyłają do chmury. W przywołanych badaniach osiągały dobre wyniki w wykrywaniu wybranych typów ataków, np. DDoS lub rozprzestrzeniania złośliwego oprogramowania. Ograniczeniem pozostaje jednak różnorodność urządzeń: to, co działa na mocniejszym serwerze brzegowym, może być zbyt obciążające dla małej bramki IoT.

Bezpieczna orkiestracja ma z kolei ograniczać błędy konfiguracji i lepiej kontrolować dostęp. W artykule omawiane są m.in. podejścia oparte na automatycznych kontrolach konfiguracji i protokołach wykorzystujących blockchain. Wyniki cytowanych badań sugerują poprawę w określonych scenariuszach, ale autor zaznacza problemy ze skalowalnością, integracją ze starszymi systemami i brakiem powszechnych standardów.

Trzecia grupa to rozwiązania ukierunkowane na prywatność, takie jak federated learning, szyfrowanie homomorficzne czy prywatność różnicowa. Ich wspólna idea polega na ograniczeniu potrzeby przesyłania surowych danych lub umożliwieniu analizy przy mniejszym ujawnianiu informacji. To kierunek ważny, ale technicznie kosztowny. Dla wielu urządzeń brzegowych dodatkowe obciążenie obliczeniowe i komunikacyjne nadal może być poważną barierą.

Adaptacyjna obrona: bardziej proces niż produkt

Najbardziej praktycznym elementem artykułu jest propozycja ramy adaptacyjnej obrony. Nie chodzi o jeden konkretny program, który można po prostu zainstalować, lecz o sposób myślenia o ochronie środowisk cloud-edge. Według autora zabezpieczenia powinny zmieniać się wraz z kontekstem: typem urządzenia, wrażliwością danych, aktualnym poziomem ryzyka, obciążeniem systemu i historią zagrożeń.

Proponowana rama obejmuje cztery filary:

• dynamiczną ocenę ryzyka — bieżące monitorowanie podatności, konfiguracji i znaczenia poszczególnych węzłów;
• wielowarstwowe zabezpieczenia techniczne — inne dla małych urządzeń, inne dla mocniejszych serwerów i platform chmurowych;
• uwzględnienie regulacji — mapowanie wymagań prawnych i branżowych na konkretne środki ochrony;
• współdzielenie wiedzy o zagrożeniach — wymianę informacji między dostawcami, instytucjami publicznymi, firmami bezpieczeństwa i środowiskiem naukowym.

Interpretacja wyników jest dość jasna: w środowisku, które stale się zmienia, statyczna lista zabezpieczeń może szybko się zestarzeć. Jeśli do systemu dołączane są nowe urządzenia, zmienia się obciążenie, pojawiają się inne trasy przesyłania danych i nowe aplikacje, to model ochrony również powinien reagować na te zmiany.

Warto jednak podkreślić ostrożnie: publikacja proponuje ramę koncepcyjną, a nie przedstawia długoterminowego testu jej skuteczności w wielu realnych wdrożeniach. To istotna różnica. Artykuł pokazuje kierunek i syntetyzuje dostępne dowody, ale nie dowodzi jeszcze, że zaproponowany model będzie równie skuteczny w każdej branży, skali i konfiguracji.

Najważniejszy wniosek: bezpieczeństwo musi nadążyć za architekturą

Analiza Narayana dobrze pokazuje zmianę, która wykracza poza samą technologię. Cloud-edge computing rozprasza odpowiedzialność: część ryzyka dotyczy producentów urządzeń, część operatorów chmury, część integratorów, część organizacji korzystających z takich rozwiązań, a część regulatorów. Ochrona takiego środowiska nie może być więc wyłącznie problemem jednego działu IT.

Najmocniejszym wnioskiem badania jest to, że podatności w cloud-edge są powiązane między warstwami. Słabe hasło na urządzeniu brzegowym może stać się punktem wejścia do większego systemu. Błąd orkiestracji może rozszerzyć skutki pojedynczej awarii. Niezaszyfrowana transmisja może osłabić nawet dobrze zaprojektowaną aplikację. Autorzy analizowanych prac sugerują, że skuteczniejsza ochrona wymaga koordynacji, a nie zbioru osobnych narzędzi.

Trzeba też pamiętać o ograniczeniach samego badania. Analiza opiera się na publikacjach i publicznie dostępnych raportach z lat 2023–2025, więc może pomijać incydenty nieujawnione lub opisane zbyt ogólnie. Ocena skuteczności technologii pochodzi z różnych badań, często prowadzonych w odmiennych warunkach. Proponowana rama wymaga dalszych testów, zwłaszcza w długich, rzeczywistych wdrożeniach i u mniejszych dostawców, którzy nie dysponują dużymi zespołami bezpieczeństwa.

Mimo tych zastrzeżeń artykuł jest użytecznym uporządkowaniem tematu. Pokazuje, że przyszłość usług cyfrowych nie będzie polegała wyłącznie na „większej chmurze”, lecz na coraz gęstszej sieci połączeń między chmurą, urządzeniami i lokalną infrastrukturą. A im bardziej obliczenia zbliżają się do świata fizycznego, tym bardziej cyberbezpieczeństwo staje się kwestią ciągłego zarządzania ryzykiem, a nie jednorazowej konfiguracji.

Źródła

• Narayan, R. K. (2026). Cybersecurity Challenges in Cloud-Edge Computing Convergence: A Systematic Analysis and Adaptive Defense Framework. International Journal of Cyberspace Security. DOI: 10.64797/ijcs.v1i1.93. URL: https://doi.org/10.64797/ijcs.v1i1.93
• Carter, M. S., et al. (2024). Systematic review of cloud-edge convergence vulnerabilities and mitigation strategies. Computers & Security, 131, 103215.
• Carter, M. S., et al. (2025). Automated configuration management for secure cloud-edge orchestration. IEEE Transactions on Cloud Computing, 13(2), 1245–1260.
• Cloud Security Alliance. (2024). Cloud-edge data protection trends report 2024. Wakefield, MA: CSA.
• Cybersecurity and Infrastructure Security Agency. (2023). Cloud-Edge Security Guidelines. Washington, DC: U.S. Department of Homeland Security.
• European Union Agency for Cybersecurity. (2024). Vulnerability severity classification guidelines for cloud-edge environments. Heraklion, Greece: ENISA.
• Lee, S. H., et al. (2025). Federated learning framework for privacy-preserving cloud-edge data processing. IEEE Internet of Things Journal, 12(4), 3890–3905.
• Petrov, E. V., et al. (2023). Lightweight ML-based intrusion detection for resource-constrained edge nodes. IEEE Transactions on Industrial Informatics, 19(8), 8765–8774.
• Zhang, L., et al. (2024). Blockchain-based secure orchestration protocol for cloud-edge convergence. Computers & Security, 133, 103289.