CompTIA SY0-701: Bezpieczeństwo chmury, wirtualizacji i kontenerów — Przewodnik do nauki

By Laurynas Brazys · 20 July 2026 · #comptia #sy0-701 #certification #exam-prep #study-guide

Część CompTIA Security+ SY0-701 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów CompTIA, albo rozwiąż testy na czas na ExamRoll.io.

Nowoczesne przedsiębiorstwa rzadko działają w jednym, samowystarczalnym centrum danych. Obciążenia robocze (workloads) obejmują dostawców chmury publicznej, prywatne klastry wirtualizacyjne, orkiestratory kontenerów i efemeryczne funkcje bezserwerowe. Każda warstwa abstrakcji zmienia model zagrożeń, powierzchnię kontroli i — co kluczowe — kto jest odpowiedzialny za poszczególne mechanizmy bezpieczeństwa.

Model Współdzielonej Odpowiedzialności

Każdy duży dostawca chmury publikuje model współdzielonej odpowiedzialności, który dzieli obowiązki w zakresie bezpieczeństwa między klienta a dostawcę usług chmurowych (CSP). Linia podziału przesuwa się w zależności od poziomu usługi.

W modelu Infrastruktura jako usługa (IaaS) — Amazon EC2, Azure Virtual Machines, Google Compute Engine — dostawca CSP zabezpiecza fizyczne obiekty, sprzęt, hiperwizor i infrastrukturę sieciową. Wszystko powyżej hiperwizora należy do klienta: system operacyjny gościa, jego łatanie, zapory sieciowe na hoście, oprogramowanie pośredniczące (middleware), środowisko uruchomieniowe, kod aplikacji, konfiguracja tożsamości i same dane. Jeśli firma wdraża bazę danych MySQL na instancji EC2, zabezpieczenie tej bazy danych jest w całości obowiązkiem klienta.

W modelu Platforma jako usługa (PaaS) — AWS RDS, Azure App Service, Google App Engine — dostawca dodatkowo zarządza systemem operacyjnym, łataniem silnika bazy danych i środowiskiem uruchomieniowym. Klient pozostaje odpowiedzialny za kod aplikacji, klasyfikację danych, kontrolę dostępu, reguły ekspozycji sieciowej i zarządzanie tożsamością.

W modelu Oprogramowanie jako usługa (SaaS) — Microsoft 365, Salesforce, Workday — dostawca zarządza niemal całym stosem technologicznym. Pozostałe obowiązki klienta nie są trywialne: przydzielanie i odbieranie dostępu do kont (provisioning i deprovisioning), wymuszanie MFA, klasyfikacja danych, uprawnienia do udostępniania, konfiguracja DLP oraz integracja z korporacyjnym dostawcą tożsamości. Błędnie skonfigurowana witryna SharePoint, która udostępnia dane płacowe „Wszystkim”, nie jest naruszeniem bezpieczeństwa po stronie Microsoftu — jest to błąd administratora dzierżawy (tenanta).

Utrwalonym błędnym przekonaniem jest to, że migracja do chmury przenosi całą odpowiedzialność za bezpieczeństwo na dostawcę. Naruszenia danych związane z błędnie skonfigurowanymi bucketami S3, publicznie dostępnymi klastrami Elasticsearch i wyciekami kluczy API niemal zawsze wynikają z błędów po stronie klienta, a nie z naruszenia bezpieczeństwa u dostawcy CSP.

Wirtualizacja i ryzyko związane z hiperwizorem

Wirtualizacja agreguje fizyczny sprzęt w logiczne systemy-gości za pomocą hiperwizora. Hiperwizory typu 1 (bare-metal), takie jak VMware ESXi, Microsoft Hyper-V i KVM, działają bezpośrednio na sprzęcie. Hiperwizory typu 2 (hosted), takie jak VirtualBox, działają na systemie operacyjnym ogólnego przeznaczenia i nie nadają się do zastosowań produkcyjnych.

Dominującymi zagrożeniami specyficznymi dla wirtualizacji są ucieczka z maszyny wirtualnej (VM escape) i kompromitacja hiperwizora. Ucieczka z maszyny wirtualnej (VM escape) ma miejsce, gdy złośliwy kod wewnątrz systemu-gościa wydostaje się poza granice wirtualizacji i jest wykonywany na hiperwizorze lub na sąsiedniej maszynie wirtualnej. Historyczne przykłady to CVE-2015-3456 (VENOM, w kontrolerze stacji dyskietek QEMU) i różne podatności w VMware Tools. Ponieważ pojedynczy hiperwizor może hostować setki obciążeń roboczych w wielu strefach zaufania, udana ucieczka zapewnia nieproporcjonalnie duży dostęp.

Środki zaradcze obejmują rygorystyczne łatanie hiperwizora, minimalizowanie dodatków dla gości (guest additions) i nieużywanego emulowanego sprzętu, rozdzielanie obciążeń roboczych według poziomu wrażliwości na oddzielne klastry oraz izolowanie płaszczyzny zarządzania (management plane). Serwer vCenter, interfejsy zarządzania ESXi i API klastra muszą znajdować się w dedykowanej sieci zarządzania, dostępnej tylko z uprzywilejowanych hostów pośredniczących (jump hosts) z MFA.

Dodatkowe problemy to niekontrolowany przyrost maszyn wirtualnych (VM sprawl) (osierocone, niełatane maszyny wirtualne gromadzące się z czasem) oraz ponowne wykorzystanie zasobów (resource reuse), gdy pamięć lub przestrzeń dyskowa z wycofanej maszyny wirtualnej nie jest odpowiednio wyzerowana przed przydzieleniem jej innemu najemcy (tenantowi).

Kontenery, mikrousługi i współdzielenie jądra systemu

Kontenery pakują aplikację wraz z jej zależnościami, ale w przeciwieństwie do maszyn wirtualnych współdzielą jądro systemu operacyjnego hosta. Docker, containerd i CRI-O zarządzają cyklem życia kontenerów; Kubernetes orkiestruje je na dużą skalę. Ta lekka izolacja jest zaletą — uruchamianie w milisekundach, gęste upakowanie — ale także głównym ryzykiem.

Izolacja kontenerów nie jest równoznaczna z izolacją maszyn wirtualnych. Podatność jądra systemu wykorzystana z wnętrza kontenera może skompromitować hosta i wszystkie inne kontenery na nim. Przestrzenie nazw (PID, network, mount, UTS, IPC, user) i cgroups zapewniają izolację, ale są to konstrukcje programowe współdzielące jedną powierzchnię ataku.

Bezpieczeństwo kontenerów wymaga kontroli na każdym etapie cyklu życia:

# Example: Pod security context enforcing hardening
securityContext:
  runAsNonRoot: true
  runAsUser: 10001
  readOnlyRootFilesystem: true
  allowPrivilegeEscalation: false
  capabilities:
    drop: ["ALL"]
  seccompProfile:
    type: RuntimeDefault

Obrazy muszą być skanowane pod kątem podatności przed wdrożeniem (Trivy, Snyk, Clair), budowane z minimalnych obrazów bazowych (distroless lub Alpine) i pobierane tylko z zaufanych rejestrów z wymuszonym podpisywaniem obrazów (Cosign, Notary). Narzędzia ochrony środowiska uruchomieniowego (Falco, Aqua, Sysdig) monitorują zachowanie kontenerów i alarmują o anomaliach, takich jak nieoczekiwane uruchomienie procesu lub nietypowe połączenia sieciowe.

Poziom bezpieczeństwa chmury (Cloud Security Posture) i IAM

Chmurowy IAM różni się od lokalnego Active Directory w istotny sposób. W AWS, polityki IAM to dokumenty JSON dołączane do użytkowników, grup lub ról, a obowiązujące uprawnienie jest częścią wspólną polityk opartych na tożsamości i polityk opartych na zasobach, przy czym jawne odmowy (explicit deny) zawsze mają pierwszeństwo:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::company-data/*",
    "Condition": {
      "StringEquals": {"aws:RequestedRegion": "us-east-1"}
    }
  }]
}

Narzędzia Cloud Security Posture Management (CSPM) stale skanują konfiguracje chmurowe pod kątem wzorców bezpieczeństwa (benchmarków), takich jak CIS AWS Foundations czy NIST, sygnalizując publiczne buckety S3, zbyt liberalne grupy bezpieczeństwa, wyłączone logowanie CloudTrail i niezaszyfrowane woluminy EBS. Narzędzia Cloud Access Security Brokers (CASB) działają jako pośrednik między użytkownikami a usługami chmurowymi, egzekwując polityki DLP, polityki dostępu i wykrywanie zagrożeń dla aplikacji SaaS.

← Bezpieczeństwo aplikacji i webowe · Wszystkie domeny · Bezpieczeństwo danych →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →