Udostępnij za pośrednictwem


Zespoły ds. zabezpieczeń, role i funkcje

W tym artykule opisano role zabezpieczeń wymagane do zabezpieczeń w chmurze oraz funkcje, które wykonują, związane z infrastrukturą i platformami chmury. Te role ułatwiają zapewnienie, że zabezpieczenia są częścią każdego etapu cyklu życia chmury, od programowania do operacji i ciągłego ulepszania.

Diagram przedstawiający metodologie związane z wdrażaniem chmury. Diagram zawiera pola dla każdej fazy: zespoły i role, strategia, planowanie, gotowość, wdrażanie, zarządzanie i zarządzanie. Pole dla tego artykułu zostało wyróżnione.

Uwaga

Framework Cloud Adoption dla platformy Azure koncentruje się na infrastrukturze i platformach w chmurze, które obsługują różnorodne zadania. Aby uzyskać wskazówki dotyczące zabezpieczeń poszczególnych obciążeń, zobacz wskazówki dotyczące zabezpieczeń w strukturze Azure Well-Architected Framework.

W zależności od rozmiaru organizacji i innych czynników role i funkcje omówione w tym artykule mogą być spełnione przez osoby, które wykonują wiele funkcji (ról), a nie przez jedną osobę lub zespół. Przedsiębiorstwa i duże organizacje mają zwykle większe zespoły z bardziej wyspecjalizowanymi rolami, podczas gdy mniejsze organizacje mają tendencję do konsolidacji wielu ról i funkcji wśród mniejszej liczby osób. Określone obowiązki dotyczące zabezpieczeń różnią się również w zależności od platform technicznych i usług używanych przez organizację.

Niektóre zadania zabezpieczeń będą wykonywane bezpośrednio przez zespoły technologiczne i zespoły ds. chmury. Inne mogą być wykonywane przez wyspecjalizowane zespoły ds. zabezpieczeń, które działają wspólnie z zespołami technologicznymi. Niezależnie od rozmiaru i struktury organizacji osoby biorące udział w projekcie muszą mieć jasne zrozumienie zadań związanych z zabezpieczeniami, które należy wykonać. Każdy musi również pamiętać o wymaganiach biznesowych i tolerancji ryzyka bezpieczeństwa organizacji, aby mogli podejmować dobre decyzje dotyczące usług w chmurze, które uwzględniają i równoważą zabezpieczenia jako kluczowe wymaganie.

Skorzystaj ze wskazówek w tym artykule, aby ułatwić zrozumienie określonych funkcji, które zespoły i role wykonują, oraz sposób interakcji różnych zespołów w celu pokrycia całej organizacji zabezpieczeń w chmurze.

Przekształcanie ról zabezpieczeń

Role architektury zabezpieczeń, inżynierii i operacji przechodzą znaczącą transformację ich obowiązków i procesów. (Ta transformacja jest podobna do transformacji opartej na chmurze ról infrastruktury i platformy). Ta transformacja roli zabezpieczeń została oparta na wielu czynnikach:

  • Ponieważ narzędzia zabezpieczeń stają się coraz bardziej oparte na modelu SaaS, mniej trzeba projektować, implementować, testować i obsługiwać infrastruktury narzędzi zabezpieczeń. Te role nadal muszą obsługiwać pełny cykl życia konfigurowania usług i rozwiązań w chmurze (w tym ciągłego ulepszania), aby zapewnić spełnienie wymagań dotyczących zabezpieczeń.

  • Uznanie, że bezpieczeństwo jest zadaniem wszystkich osób, napędza bardziej wspólne i dojrzałe podejście, które umożliwia zespołom ds. zabezpieczeń i technologii współpracę:

    • Zespoły inżynierów technicznych są odpowiedzialny za zapewnienie efektywnego stosowania środków zabezpieczeń do swoich obciążeń. Ta zmiana zwiększa zapotrzebowanie na kontekst i wiedzę ze strony zespołów ds. zabezpieczeń na temat skutecznego i efektywnego spełnienia tych zobowiązań.

    • Zespoły ds. zabezpieczeń zmieniają się z roli kontroli jakości (nieco konfrontacyjnej) do roli, która umożliwia zespołom technicznym: sprawienie, aby bezpieczna ścieżka była najprostszą ścieżką. Zespoły ds. zabezpieczeń zmniejszają problemy i bariery przy użyciu automatyzacji, dokumentacji, szkolenia i innych strategii.

  • Zespoły ds. zabezpieczeń coraz częściej rozszerzają swoje umiejętności, aby przyjrzeć się problemom z zabezpieczeniami w wielu technologiach i systemach. Dotyczą one całego cyklu życia osoby atakującej, zamiast skupiać się na wąskich obszarach technicznych (na przykład zabezpieczenia sieci, zabezpieczenia punktów końcowych, zabezpieczenia aplikacji i zabezpieczenia chmury). Fakt, że platformy w chmurze ściśle integrują różne technologie, wzmacnia tę potrzebę opracowywania umiejętności.

  • Zwiększony współczynnik zmian zarówno technologii, jak i usług chmurowych związanych z bezpieczeństwem wymaga, aby procesy zabezpieczeń były ciągle aktualizowane, aby skutecznie pozostały w synchronii i zarządzały ryzykiem.

  • Zagrożenia bezpieczeństwa teraz niezawodnie pomijają mechanizmy kontroli zabezpieczeń oparte na sieci, dlatego zespoły ds. zabezpieczeń muszą przyjąć podejście Zero Trust obejmujące tożsamość, zabezpieczenia aplikacji, zabezpieczenia punktu końcowego, zabezpieczenia chmury, ciągłą integrację/ciągłe wdrażanie, edukację użytkowników i inne mechanizmy kontroli.

  • Wdrożenie procesów DevOps/DevSecOps wymaga zwiększenia elastyczności ról zabezpieczeń w celu natywnego zintegrowania zabezpieczeń z wynikowym przyspieszonym cyklem projektowania rozwiązań.

Omówienie ról i zespołów

Poniższe sekcje zawierają wskazówki dotyczące tego, które zespoły i role zwykle wykonują kluczowe funkcje zabezpieczeń w chmurze (gdy te funkcje są obecne w organizacji). Należy zamapować istniejące podejście, wyszukać luki i ocenić, czy organizacja może i powinna inwestować w celu rozwiązania tych luk.

Role, które wykonują zadania zabezpieczeń, obejmują następujące role.

  • Dostawca usług w chmurze

  • Zespoły infrastruktury/platformy (architektura, inżynieria i operacje)

  • Zespoły ds. architektury zabezpieczeń, inżynierii i zarządzania stanem:

    • Architekci zabezpieczeń i inżynierowie (zabezpieczenia danych, zarządzanie tożsamościami i dostępem ( IAM), zabezpieczenia sieci, serwery i zabezpieczenia kontenerów, zabezpieczenia aplikacji i DevSecOps)

    • Inżynierowie zabezpieczeń oprogramowania (zabezpieczenia aplikacji)

    • Zarządzanie posturą (zarządzanie lukami w zabezpieczeniach/zarządzanie powierzchnią ataków)

  • Operacje zabezpieczeń (SecOps/SOC):

    • Analitycy klasyfikacji (warstwa 1)

    • Analitycy badania (warstwa 2)

    • Wyszukiwanie zagrożeń

    • Analiza zagrożeń

    • Inżynieria wykrywania

  • Nadzór nad zabezpieczeniami, ryzyko i zgodność (GRC)

  • Szkolenia i świadomość zabezpieczeń

Niezwykle ważne jest zapewnienie, że wszyscy rozumieją swoją rolę w zakresie zabezpieczeń i sposobu pracy z innymi zespołami. Ten cel można osiągnąć, dokumentując procesy zabezpieczeń między zespołami i wspólny model odpowiedzialności dla zespołów technicznych. Dzięki temu można uniknąć ryzyka i strat związanych z lukami w zakresie pokrycia oraz z nakładających się wysiłków. Pomaga to również uniknąć typowych błędów (antywzorzec), takich jak zespoły wybierające słabe rozwiązania uwierzytelniania i kryptografii, a nawet próbujące utworzyć własne.

Uwaga

Model wspólnej odpowiedzialności jest podobny do modelu odpowiedzialny, rozliczany, konsultowany, informowany (RACI). Model wspólnej odpowiedzialności pomaga zilustrować współpracę w zakresie tego, kto podejmuje decyzje i jakie działania muszą podjąć zespoły, aby współpracować nad konkretnymi zadaniami i wynikami.

Dostawca usług w chmurze

Dostawcy usług w chmurze są skutecznie wirtualnymi członkami zespołu, którzy zapewniają funkcje zabezpieczeń i możliwości podstawowej platformy w chmurze. Niektórzy dostawcy usług w chmurze udostępniają również funkcje zabezpieczeń i możliwości, których zespoły mogą używać do zarządzania stanem zabezpieczeń i zdarzeniami. Aby uzyskać więcej informacji na temat działania dostawców usług w chmurze, zobacz Model wspólnej odpowiedzialności w chmurze.

Wielu dostawców usług w chmurze udostępnia informacje na temat praktyk zabezpieczeń i mechanizmów kontroli po żądaniu lub za pośrednictwem portalu, takiego jak portal zaufania usług firmy Microsoft.

Zespoły infrastruktury/platformy (architektura, inżynieria i operacje)

Zespoły ds. architektury infrastruktury/platformy, inżynierii i operacji implementują i integrują mechanizmy kontroli zabezpieczeń, prywatności i zgodności w chmurze w środowiskach infrastruktury chmury i platformy (między serwerami, kontenerami, siecią, tożsamością i innymi składnikami technicznymi).

Role inżynieryjne i operacyjne mogą skupiać się głównie na systemach w chmurze lub ciągłej integracji i ciągłego wdrażania (CI/CD) lub mogą działać w pełnym zakresie chmury, ciągłej integracji/ciągłego wdrażania, lokalnych i innych infrastruktur i platform.

Te zespoły są odpowiedzialne za spełnienie wszystkich wymagań dotyczących dostępności, skalowalności, zabezpieczeń, prywatności i innych wymagań dotyczących usług w chmurze organizacji hostujących obciążenia biznesowe. Współpracują one ze swoimi ekspertami w zakresie bezpieczeństwa, ryzyka, zgodności i prywatności, aby zwiększyć wyniki, które łączą i równoważą wszystkie te wymagania.

Zespoły ds. architektury zabezpieczeń, inżynierii i zarządzania posturą bezpieczeństwa

Zespoły ds. zabezpieczeń współpracują z rolami infrastruktury i platformy (i innymi), aby ułatwić tłumaczenie strategii zabezpieczeń, zasad i standardów na architektury, rozwiązania i wzorce projektowe. Zespoły te koncentrują się na umożliwieniu sukcesu zespołów ds. zabezpieczeń w chmurze, oceniając i wpływając na bezpieczeństwo infrastruktury oraz procesów i narzędzi używanych do zarządzania nimi. Poniżej przedstawiono niektóre typowe zadania wykonywane przez zespoły ds. zabezpieczeń dla infrastruktury:

  • Architekci zabezpieczeń i inżynierowie dostosowują zasady zabezpieczeń, standardy i wytyczne dotyczące środowisk chmury do projektowania i implementowania mechanizmów kontroli we współpracy z ich odpowiednikami infrastruktury/platformy. Architekci zabezpieczeń i inżynierowie pomagają w wielu różnych elementach, w tym:

    • Dzierżawy/subskrypcje.Architekci zabezpieczeń i inżynierowie współpracują z architektami infrastruktury i inżynierami i architektami dostępu (tożsamości, sieci, aplikacji i innych), aby pomóc w ustanowieniu konfiguracji zabezpieczeń dla dzierżaw, subskrypcji i kont w różnych dostawcach chmury (które są monitorowane przez zespoły zarządzania stanem zabezpieczeń).

    • IAM.Architekci dostępu (tożsamość, sieć, aplikacja i inne osoby) współpracują z inżynierami tożsamości i zespołami ds. operacji i infrastruktury/platform w celu projektowania, implementowania i obsługi rozwiązań do zarządzania dostępem. Te rozwiązania chronią przed nieautoryzowanym użyciem zasobów biznesowych organizacji, umożliwiając autoryzowanym użytkownikom śledzenie procesów biznesowych w celu łatwego i bezpiecznego uzyskiwania dostępu do zasobów organizacji. Zespoły te pracują nad rozwiązaniami, takimi jak katalogi tożsamości i rozwiązania logowania jednokrotnego, uwierzytelnianie bez hasła i uwierzytelnianie wieloskładnikowe (MFA), oparte na ryzyku rozwiązania dostępu warunkowego, tożsamości obciążeń, uprzywilejowane zarządzanie tożsamościami/dostępem (PIM/PAM), infrastruktura chmury i zarządzanie upoważnieniami (CIEM) i nie tylko. Te zespoły współpracują również z inżynierami sieci i operacjami w celu projektowania, implementowania i obsługi rozwiązań brzegowych (SSE) usług zabezpieczeń. Zespoły ds. obciążeń mogą korzystać z tych funkcji, aby zapewnić bezproblemowy i bardziej bezpieczny dostęp do poszczególnych składników obciążeń i aplikacji.

    • Bezpieczeństwo danych.Architekci zabezpieczeń i inżynierowie współpracują z architektami danych i inżynierami sztucznej inteligencji, aby pomóc zespołom infrastruktury/platformy w ustanowieniu podstawowych funkcji zabezpieczeń danych dla wszystkich danych i zaawansowanych funkcji, które mogą służyć do klasyfikowania i ochrony danych w poszczególnych obciążeniach. Aby uzyskać więcej informacji na temat podstawowych zabezpieczeń danych, zobacz Microsoftowy Benchmark ochrony danych. Aby uzyskać więcej informacji na temat ochrony danych w poszczególnych obciążeniach, zobacz Wskazówki dotyczące dobrze zaprojektowanej struktury.

    • Zabezpieczenia sieci.Architekci zabezpieczeń i inżynierowie współpracują z architektami sieci i inżynierami , aby pomóc zespołom infrastruktury/platformy w ustanawianiu podstawowych funkcji zabezpieczeń sieci, takich jak łączność z chmurą (linie prywatne/dzierżawione), strategie dostępu zdalnego i rozwiązania, zapory ruchu przychodzącego i wychodzącego, zapory aplikacji internetowych (WAFs) i segmentacja sieci. Te zespoły współpracują również z architektami tożsamości, inżynierami i operacjami w celu projektowania, implementowania i obsługi rozwiązań SSE. Zespoły ds. obciążeń mogą korzystać z tych możliwości, aby zapewnić dyskretną ochronę lub izolację poszczególnych składników obciążenia i aplikacji.

    • Serwery i zabezpieczenia kontenerów.Architekci zabezpieczeń i inżynierowie współpracują z architektami infrastruktury i inżynierami , aby pomóc zespołom infrastruktury/platformy w ustanowieniu podstawowych funkcji zabezpieczeń dla serwerów, maszyn wirtualnych, kontenerów, orkiestracji/zarządzania, ciągłej integracji/ciągłego wdrażania i powiązanych systemów. Zespoły te ustanawiają procesy identyfikacji i inwentaryzacji, konfiguracje bazowe lub testy porównawcze zabezpieczeń, procesy konserwacji i stosowania poprawek, listy dozwolonych wykonywalnych plików binarnych, obrazy szablonów, procesy zarządzania oraz inne. Zespoły ds. obciążeń mogą również korzystać z tych podstawowych funkcji infrastruktury w celu zapewnienia zabezpieczeń serwerów i kontenerów dla poszczególnych składników obciążeń i aplikacji.

    • Podstawy zabezpieczeń oprogramowania (na potrzeby zabezpieczeń aplikacji i metodyki DevSecOps).Architekci zabezpieczeń i inżynierowie współpracują z inżynierami ds. zabezpieczeń oprogramowania, aby pomóc zespołom ds. infrastruktury/platformy w tworzeniu możliwości zabezpieczeń aplikacji, które mogą być używane przez poszczególne obciążenia, skanowanie kodu, narzędzia do rozliczania materiałów (SBOM, software bill of materials), narzędzia WAFs i skanowanie aplikacji. Zobacz kontrole DevSecOps, aby uzyskać więcej informacji na temat sposobu ustanawiania cyklu życia projektowania zabezpieczeń (SDL). Aby uzyskać więcej informacji na temat korzystania z tych funkcji przez zespoły zajmujące się obciążeniami, zobacz wytyczne dotyczące Cyklu Życia Tworzenia Zabezpieczeń w Well-Architected Framework.

  • Inżynierowie ds. bezpieczeństwa oprogramowania oceniają kod, skrypty oraz inną zautomatyzowaną logikę używaną do zarządzania infrastrukturą, w tym infrastrukturą jako kod (IaC), przepływy pracy CI/CD oraz wszelkie inne niestandardowe narzędzia lub aplikacje. Inżynierowie ci powinni być zaangażowani w ochronę formalnego kodu w skompilowanych aplikacjach, skryptach, konfiguracjach platform automatyzacji oraz wszelkich innych formach kodu wykonywalnego lub skryptu, który może umożliwić osobom atakującym manipulowanie operacją systemu. Ta ocena może wiązać się z po prostu przeprowadzeniem analizy modelu zagrożeń systemu lub może obejmować przegląd kodu i narzędzia do skanowania zabezpieczeń. Aby uzyskać więcej informacji na temat ustanawiania SDL, zapoznaj się z wytycznymi dotyczącymi praktyk SDL.

  • Zarządzanie stanem (zarządzanie lukami w zabezpieczeniach/ zarządzanie obszarem ataków) to zespół ds. zabezpieczeń operacyjnych, który koncentruje się na włączaniu zabezpieczeń dla zespołów ds. operacji technicznych. Zarządzanie postawą pomaga tym zespołom priorytetyzować i wdrażać mechanizmy kontroli w celu blokowania lub łagodzenia technik ataku. Zespoły zarządzania stanem współpracują ze wszystkimi zespołami ds. operacji technicznych (w tym zespołami w chmurze) i często pełnią rolę podstawowych środków zrozumienia wymagań dotyczących zabezpieczeń, wymagań dotyczących zgodności i procesów ładu.

    Zarządzanie postawą często służy jako centrum doskonałości (CoE) dla zespołów ds. infrastruktury zabezpieczeń, podobnie jak inżynierowie oprogramowania często służą jako centrum doskonałości ds. zabezpieczeń dla zespołów programistycznych. Typowe zadania dla tych zespołów obejmują następujące zadania.

    • Monitorowanie stanu zabezpieczeń. Monitoruj wszystkie systemy techniczne przy użyciu narzędzi do zarządzania stanem zabezpieczeń, takich jak Microsoft Security Exposure Management, Microsoft Entra Permissions Management, narzędzia do zarządzania lukami bezpieczeństwa firm nie-Microsoft, zarządzanie zewnętrzną powierzchnią ataku (EASM), narzędzia CIEM oraz niestandardowe narzędzia i pulpity nawigacyjne dotyczące stanu zabezpieczeń. Ponadto zarządzanie postawą wykonuje analizę w celu dostarczania wglądu poprzez:

      • Przewidywanie wysoce prawdopodobnych i szkodliwych ścieżek ataków. Osoby atakujące "myślą w grafach" i szukają ścieżek do systemów o znaczeniu krytycznym dla działania firmy, łącząc wiele zasobów i luk w zabezpieczeniach w różnych systemach (na przykład naruszenie zabezpieczeń punktów końcowych użytkownika, a następnie przechwycenie poświadczeń administratora przy użyciu skrótu/biletu, a następnie uzyskanie dostępu do danych krytycznych dla działania firmy). Zespoły zarządzania stanem współpracują z architektami i inżynierami ds. zabezpieczeń, aby odkryć i ograniczyć te ukryte zagrożenia, które nie zawsze pojawiają się na listach technicznych i raportach.

      • Przeprowadzanie ocen zabezpieczeń w celu przeglądu konfiguracji systemu i procesów operacyjnych w celu uzyskania dokładniejszego zrozumienia i szczegółowych informacji poza danymi technicznymi z narzędzi do stanu zabezpieczeń. Oceny te mogą przybrać formę nieformalnych rozmów odkrywczych lub formalnych ćwiczeń związanych z modelowaniem zagrożeń.

    • Pomoc w określaniu priorytetów. Pomóż zespołom technicznym aktywnie monitorować swoje zasoby i ustalać priorytety pracy nad zabezpieczeniami. Zarządzanie postawą bezpieczeństwa pomaga umieścić pracę nad ograniczaniem ryzyka w kontekście, uwzględniając wpływ ryzyka na bezpieczeństwo (bazując na doświadczeniu, raportach z incydentów dotyczących operacji bezpieczeństwa, analizach zagrożeń, informacji biznesowej i innych źródłach) oprócz wymagań dotyczących zgodności z bezpieczeństwem.

    • Trenowanie, mentor i mistrz. Zwiększ wiedzę na temat zabezpieczeń i umiejętności zespołów inżynierów technicznych dzięki szkoleniu, mentoringowi i nieformalnym transferowi wiedzy. Role zarządzania postawą mogą również współpracować z rolami odpowiedzialnymi za gotowość organizacyjną/szkolenia oraz edukację i zaangażowanie w zakresie zabezpieczeń, nad formalnymi szkoleniami dotyczącymi zabezpieczeń i wdrażaniem zabezpieczeń w zespołach technicznych, które promują i edukują swoich kolegów w zakresie bezpieczeństwa.

    • Identyfikowanie luk i wstawianie się za poprawkami. Zidentyfikuj ogólne trendy, luki procesów, luki narzędzi i inne szczegółowe informacje na temat ryzyka i środków zaradczych. Role zarządzania postawą współpracują i komunikują się z architektami zabezpieczeń oraz inżynierami, aby opracowywać rozwiązania, tworzyć argumentację dla finansowania rozwiązań i pomagać w wdrażaniu poprawek.

    • Koordynowanie operacji zabezpieczeń (SecOps). Pomoc zespołom technicznym w pracy z rolami SecOps, takimi jak zespoły ds. inżynierii wykrywania i wyszukiwania zagrożeń. Ta ciągłość we wszystkich rolach operacyjnych pomaga zapewnić, że wykrycia są wdrożone i prawidłowo zaimplementowane, dane zabezpieczeń są dostępne do badania zdarzeń i wyszukiwania zagrożeń, procesy współpracy są na swoim miejscu i inne korzyści.

    • Podaj raporty. Udostępnianie terminowych i dokładnych raportów dotyczących zdarzeń zabezpieczeń, trendów i metryk wydajności starszym kierownictwu i uczestnikom projektu w celu zaktualizowania procesów ryzyka organizacyjnego.

    Zespoły zarządzania posturą często ewoluują z istniejących ról zarządzania lukami w zabezpieczeniach oprogramowania w celu rozwiązania pełnego zestawu funkcjonalnych, konfiguracji i operacyjnych typów luk w zabezpieczeniach opisanych w Modelu Referencyjnym Open Group Zero Trust. Każdy typ luki w zabezpieczeniach może zezwalać nieautoryzowanym użytkownikom (w tym osobom atakującym) na przejęcie kontroli nad oprogramowaniem lub systemami, umożliwiając im spowodowanie szkód w zasobach biznesowych.

    • Luki w zabezpieczeniach funkcjonalnych występują w projekcie lub implementacji oprogramowania. Mogą one zezwalać na nieautoryzowaną kontrolę nad oprogramowaniem, którego dotyczy problem. Te podatności mogą być wadami w oprogramowaniu opracowanym przez twoje zespoły lub wadami w oprogramowaniu komercyjnym lub open source (zwykle śledzone za pomocą identyfikatora CVE - Common Vulnerabilities and Exposures).

    • Luki w zabezpieczeniach konfiguracji to błędne konfiguracje systemów, które umożliwiają nieautoryzowany dostęp do funkcji systemu. Luki w zabezpieczeniach mogą występować podczas bieżących operacji, znanych również jako dryf konfiguracji. Można je również wprowadzić podczas początkowego wdrażania i konfiguracji oprogramowania i systemów lub przez słabe wartości domyślne zabezpieczeń od dostawcy. Do powszechnych przykładów należą:

      • Oddzielone obiekty, które umożliwiają nieautoryzowany dostęp do elementów, takich jak rekordy DNS i członkostwo w grupach.

      • Nadmierne role administracyjne lub uprawnienia do zasobów.

      • Używanie słabszego protokołu uwierzytelniania lub algorytmu kryptograficznego, który ma znane problemy z zabezpieczeniami.

      • Słabe konfiguracje domyślne lub domyślne hasła.

    • Luki w zabezpieczeniach operacyjnych są słabe w standardowych procesach operacyjnych i praktykach, które umożliwiają nieautoryzowany dostęp lub kontrolę systemów. Oto kilka przykładów:

      • Administratorzy korzystający z kont udostępnionych zamiast własnych kont indywidualnych do wykonywania zadań uprzywilejowanych.

      • Korzystanie z konfiguracji «browse-up», które tworzą ścieżki prowadzące do eskalacji uprawnień i mogą być nadużywane przez atakujących. Ta luka w zabezpieczeniach występuje, gdy konta administracyjne z wysokimi uprawnieniami logują się do urządzeń i stacji roboczych użytkowników o niższym zaufaniu (takich jak standardowe stacje robocze i urządzenia należące do użytkownika), czasami za pośrednictwem serwerów przesiadkowych, które nie skutecznie ograniczają tych zagrożeń. Aby uzyskać więcej informacji, zobacz Zabezpieczanie uprzywilejowanego dostępu i urządzeń z dostępem uprzywilejowanym.

Operacje zabezpieczeń (SecOps/SOC)

Zespół SecOps jest czasami nazywany Centrum Operacji Bezpieczeństwa (SOC). Zespół SecOps koncentruje się na szybkim znalezieniu i usunięciu niepożądanego dostępu do zasobów organizacji. Współpracują one w ścisłej współpracy z zespołami ds. operacji technologicznych i inżynierów. Role SecOps mogą współdziałać ze wszystkimi technologiami w organizacji, w tym tradycyjnymi technologiami IT, technologią operacyjną (OT) i Internetem rzeczy (IoT). Poniżej przedstawiono role SecOps, które najczęściej wchodzą w interakcje z zespołami w chmurze:

  • Analitycy klasyfikacji (warstwa 1). Reaguje na wykrywanie zdarzeń pod kątem dobrze znanych technik ataków i postępuje zgodnie z udokumentowanymi procedurami, aby szybko je rozwiązać (lub w razie potrzeby eskalować je do analityków badania). W zależności od zakresu i poziomu dojrzałości secOps może to obejmować wykrywanie i alerty z poczty e-mail, rozwiązań ochrony przed złośliwym kodem punktu końcowego, usług w chmurze, wykrywania sieci lub innych systemów technicznych.

  • Analitycy badania (warstwa 2). Odpowiada na badania incydentów o większej złożoności i większej ważności, które wymagają większej doświadczenia i wiedzy (poza dobrze udokumentowanymi procedurami rozwiązywania problemów). Ten zespół zwykle bada ataki przeprowadzane przez aktywnych przeciwników i ataki, które mają wpływ na wiele systemów. Współpracuje ona z zespołami ds. operacji technologicznych i inżynierów w celu zbadania zdarzeń i ich rozwiązania.

  • Wyszukiwanie zagrożeń. Aktywnie wyszukuje ukryte zagrożenia w obrębie majątku technicznego, które unikały standardowych mechanizmów wykrywania. Ta rola korzysta z zaawansowanych analiz i badań opartych na hipotezach.

  • Analiza zagrożeń. Zbiera i rozpowszechnia informacje o osobach atakujących i zagrożeniach dla wszystkich uczestników projektu, w tym firmy, technologii i bezpieczeństwa. Zespoły analizy zagrożeń przeprowadzają badania, dzielą się swoimi wynikami (formalnie lub nieformalnie) i rozpowszechniają je wśród różnych uczestników projektu, w tym do zespołu ds. zabezpieczeń w chmurze. Ten kontekst zabezpieczeń pomaga tym zespołom zwiększyć odporność usług w chmurze na ataki, ponieważ korzystają z rzeczywistych informacji o ataku w projekcie, implementacji, testowaniu i operacji oraz ciągłym ulepszaniu.

  • Inżynieria wykrywania. Tworzy niestandardowe wykrywanie ataków i dostosowuje wykrywanie ataków udostępniane przez dostawców i szerszą społeczność. Te niestandardowe wykrywanie ataków uzupełniają wykrywanie udostępniane przez dostawcę w przypadku typowych ataków, które są często spotykane w narzędziach rozszerzonego wykrywania i reagowania (XDR) oraz niektórych narzędzi do zarządzania informacjami i zdarzeniami zabezpieczeń (SIEM). Inżynierowie wykrywania współpracują z zespołami ds. zabezpieczeń w chmurze, aby zidentyfikować możliwości projektowania i implementowania wykrywania, danych wymaganych do ich obsługi oraz procedur reagowania/odzyskiwania na potrzeby wykrywania.

Nadzór nad zabezpieczeniami, ryzyko i zgodność

Zarządzanie zabezpieczeniami, ryzyko i zgodność (GRC) to zestaw wzajemnie powiązanych dyscyplin, które integrują pracę techniczną zespołów ds. zabezpieczeń z celami i oczekiwaniami organizacji. Te role i zespoły mogą być hybrydą dwóch lub większej liczby dyscyplin lub mogą być rolami dyskretnymi. Zespoły w chmurze wchodzą w interakcje z każdą z tych dziedzin w trakcie cyklu życia technologii w chmurze:

  • Dyscyplina zarządzania to podstawowa kompetencja, która koncentruje się na zapewnieniu, że organizacja konsekwentnie wdraża wszystkie elementy bezpieczeństwa. Zespoły ds. ładu koncentrują się na prawach decyzyjnych (którzy podejmują decyzje) i strukturach procesów, które łączą się z zespołami i kierują nimi. Bez skutecznego ładu organizacja ze wszystkimi odpowiednimi mechanizmami kontroli, zasadami i technologią nadal może zostać naruszona przez osoby atakujące, które znalazły obszary, w których zamierzone zabezpieczenia nie są wdrażane dobrze, w pełni lub w ogóle.

  • Dyscyplina zarządzania ryzykiem koncentruje się na zapewnieniu, że organizacja skutecznie ocenia, rozumie i zmniejsza ryzyko. Role zarządzania ryzykiem współpracują z wieloma zespołami w całej organizacji, aby utworzyć wyraźną reprezentację ryzyka organizacji i zachować ją na bieżąco. Ponieważ wiele krytycznych usług biznesowych może być hostowanych na infrastrukturze i platformach w chmurze, zespoły ds. chmury i ryzyka muszą współpracować w celu oceny ryzyka organizacyjnego i zarządzania nim. Ponadto bezpieczeństwo łańcucha dostaw koncentruje się na zagrożeniach związanych z zewnętrznymi dostawcami, składnikami open source i partnerami.

  • Dyscyplina zgodności zapewnia zgodność systemów i procesów z wymaganiami prawnymi i zasadami wewnętrznymi. Bez tej dyscypliny organizacja może być narażona na ryzyko związane z niezgodnością z zobowiązaniami zewnętrznymi (grzywny, odpowiedzialność, utrata przychodów z niezdolności do działania na niektórych rynkach i nie tylko). Wymagania dotyczące zgodności zwykle nie mogą nadążyć za szybkością ewolucji osoby atakującej, ale są one jednak ważnym źródłem wymagań.

Wszystkie trzy z tych dyscyplin działają we wszystkich technologiach i systemach w celu kierowania wynikami organizacyjnymi we wszystkich zespołach. Wszystkie trzy polegają również na kontekście uzyskanym od siebie nawzajem i znacznie korzystają z bieżących, dokładnych danych dotyczących zagrożeń, biznesu i środowiska technologicznego. Te dyscypliny opierają się również na architekturze, aby wyrazić możliwą do działania wizję, którą można zaimplementować, a także edukacji w zakresie zabezpieczeń i zasad w celu ustanowienia reguł i kierowania zespołami za pośrednictwem wielu codziennych decyzji.

Zespoły inżynieryjne i operacyjne w chmurze mogą współpracować z rolami zarządzania stanem , zespołami ds. zgodności i inspekcji , architekturą zabezpieczeń i inżynierią lub głównymi rolami dyrektora ds. zabezpieczeń informacji (CISO) w tematach GRC.

Edukacja i zasady dotyczące zabezpieczeń

Organizacje muszą mieć pewność, że wszystkie role mają podstawowe umiejętności w zakresie zabezpieczeń i wskazówki dotyczące tego, co mają robić w odniesieniu do zabezpieczeń i jak to zrobić. Aby osiągnąć ten cel, potrzebne jest połączenie pisemnej polityki i edukacji. Edukacja dla zespołów w chmurze może być nieformalnym mentorowaniem przez specjalistów ds. zabezpieczeń, którzy pracują bezpośrednio z nimi, lub może to być formalny program z udokumentowanym programem nauczania i wyznaczonymi mistrzami zabezpieczeń.

W większej organizacji zespoły ds. zabezpieczeń współpracują z rolami gotowości organizacji / szkolenia oraz edukacji w zakresie zabezpieczeń i zaangażowania w formalne szkolenia w zakresie zabezpieczeń oraz tworzenie liderów zabezpieczeń w zespołach technicznych w celu informowania i edukowania swoich rówieśników o bezpieczeństwie.

Edukacja i polityka dotycząca zabezpieczeń muszą pomóc każdej roli zrozumieć:

  • Dlaczego. Pokaż każdą rolę, dlaczego bezpieczeństwo jest dla nich ważne i ich cele w kontekście ich obowiązków związanych z rolą. Jeśli ludzie nie rozumieją wyraźnie, dlaczego bezpieczeństwo ma dla nich znaczenie, ocenią to jako nieistotne i przejdziemy do czegoś innego.

  • Co. Podsumuj zadania zabezpieczeń, które muszą wykonać w języku, który już rozumie. Jeśli ludzie nie wiedzą, o co są proszeni, założą, że bezpieczeństwo nie jest ważne dla nich i przejdą do czegoś innego.

  • Jak. Upewnij się, że każda rola ma jasne instrukcje dotyczące stosowania wskazówek dotyczących zabezpieczeń w ich roli. Jeśli ludzie nie wiedzą, jak faktycznie wykonać to, co im się nakazuje robić (na przykład aktualizować serwery, sprawdzić, czy link jest phishingowy, prawidłowo zgłosić komunikat, przejrzeć kod lub wykonać model zagrożenia), poniosą porażkę i zajmą się czymś innym.

Przykładowy scenariusz: typowe współdziałanie między zespołami

Gdy organizacja wdraża i operacjonalizuje zaporę aplikacyjną, kilka zespołów ds. bezpieczeństwa musi współpracować, aby zapewnić skuteczne wdrażanie, zarządzanie i integrację z istniejącą infrastrukturą bezpieczeństwa. Oto jak współdziałanie między zespołami może wyglądać w organizacji zabezpieczeń przedsiębiorstwa:

  1. Planowanie i projektowanie
    1. Zespół do spraw ładu identyfikuje potrzebę zwiększenia zabezpieczeń aplikacji internetowych i przydziela budżet na zaporę sieciową dla aplikacji internetowych.
    2. Architekt bezpieczeństwa sieciowego projektuje strategię wdrażania WAF, zapewniając, że bezproblemowo integruje się z istniejącymi mechanizmami kontroli bezpieczeństwa i odpowiada architekturze bezpieczeństwa organizacji.
  2. Implementacja
    1. Inżynier zabezpieczeń sieci wdraża zaporę aplikacji internetowych zgodnie z projektem architekta, konfigurując ją w celu ochrony określonych aplikacji internetowych i umożliwia monitorowanie.
    2. Inżynier IAM konfiguruje mechanizmy kontroli dostępu, zapewniając, że tylko autoryzowany personel może zarządzać zaporą aplikacji internetowej.
  3. Monitorowanie i zarządzanie
    1. Zespół do zarządzania postawą dostarcza instrukcje dla SOC dotyczące konfigurowania monitorowania i alertów dla WAF oraz ustawiania pulpitów nawigacyjnych do śledzenia aktywności WAF.
    2. Zespoły inżynierów analizy zagrożeń i wykrywania zagrożeń pomagają opracowywać plany reagowania na zdarzenia obejmujące zaporę aplikacji internetowej i przeprowadzać symulacje w celu przetestowania tych planów.
  4. Zgodność i zarządzanie ryzykiem
    1. Oficer ds. zarządzania zgodnością i ryzykiem przegląda wdrożenie zapory sieciowej, aby upewnić się, że spełnia ona wymagania prawne i przeprowadza okresowe audity.
    2. Inżynier ds. zabezpieczeń danych zapory aplikacji internetowej (WAF) zapewnia, że zasady rejestrowania i ochrony danych są zgodne z przepisami dotyczącymi prywatności danych.
  5. Ciągłe ulepszanie i szkolenie
    1. Inżynier DevSecOps integruje zarządzanie zaporą aplikacji internetowej z potokiem ciągłej integracji/ciągłego wdrażania, zapewniając, że aktualizacje i konfiguracje są zautomatyzowane i spójne.
    2. Specjalista ds. edukacji i zaangażowania w zakresie bezpieczeństwa opracowuje i dostarcza programy szkoleniowe, aby zapewnić, że wszyscy odpowiedni pracownicy rozumieją sposób efektywnego korzystania z zapory ogniowej aplikacji internetowych oraz zarządzania nią.
    3. Członek zespołu ds. ładu w chmurze przegląda procesy wdrażania i zarządzania zaporą aplikacji internetowej, aby upewnić się, że są zgodne z zasadami i standardami organizacji.

Dzięki efektywnej współpracy te role zapewniają prawidłowe wdrażanie WAF, a także, stałe monitorowanie, zarządzanie i ulepszanie w celu ochrony aplikacji internetowych organizacji przed zmieniającymi się zagrożeniami.

Następny krok