General Security Concepts

Cel

Po tym module masz rozumieć podstawowe koncepcje bezpieczeństwa tak, żeby nie uczyć się ich jako listy haseł, ale umieć użyć ich w scenariuszach egzaminacyjnych.

Po module powinieneś umieć:

• odróżnić kategorie kontroli: technical, managerial, operational i physical
• odróżnić typy kontroli: preventive, deterrent, detective, corrective, compensating i directive
• wyjaśnić model Confidentiality, Integrity, Availability (CIA)
• odróżnić authentication, authorization i accounting
• rozumieć non-repudiation
• wyjaśnić, po co istnieje Zero Trust
• wskazać sens change management
• dobrać właściwy mechanizm kryptograficzny do celu: poufność, integralność, niezaprzeczalność, ochrona danych lub weryfikacja tożsamości
• rozpoznawać typowe pułapki egzaminacyjne w domenie 1.0.

Wprowadzenie

Ten moduł tworzy język całego egzaminu Security+. Późniejsze tematy, takie jak incident response, zarządzanie podatnościami, architektura bezpieczeństwa, Identity and Access Management (IAM) czy governance, będą stale odwoływać się do tych samych fundamentów.

Security+ często nie pyta: „podaj definicję”. Częściej dostajesz scenariusz i musisz wybrać najlepszą kontrolę, najlepszy mechanizm kryptograficzny albo najlepsze następne działanie. Dlatego w tym module najważniejsze jest rozumienie: jaki problem dana koncepcja rozwiązuje, jak działa i z czym łatwo ją pomylić.

1. Kontrole bezpieczeństwa

Problem

Organizacja nie może chronić się samymi intencjami. Potrzebuje konkretnych mechanizmów, zasad, procedur i działań, które zmniejszają ryzyko. Tymi mechanizmami są kontrole bezpieczeństwa.

Bez kontroli bezpieczeństwa firma może mieć wartościowe zasoby, znać zagrożenia i podatności, ale nadal nie mieć praktycznego sposobu ograniczenia ryzyka. Przykład: jeśli firma wie, że hasła pracowników mogą zostać wykradzione, ale nie wdraża wieloskładnikowego uwierzytelniania, monitoringu ani szkoleń, sama świadomość problemu nie wystarcza.

Wyjaśnienie od podstaw

Kontrola bezpieczeństwa to mechanizm, proces, procedura, ustawienie, narzędzie lub działanie, które ma zmniejszyć ryzyko. Kontrola może działać przed zdarzeniem, w trakcie jego wykrywania albo po zdarzeniu.

CompTIA dzieli kontrole według kategorii oraz według funkcji. Kategorie mówią, jakiego obszaru dotyczy kontrola: technicznego, zarządczego, operacyjnego lub fizycznego. Funkcje mówią, co kontrola robi: zapobiega, odstrasza, wykrywa, koryguje, kompensuje albo nakazuje określone działanie.

Kategorie kontroli

Kontrole techniczne są wdrażane w systemach informatycznych. Przykładami są zapory sieciowe, szyfrowanie, Multi-Factor Authentication (MFA), listy kontroli dostępu, Endpoint Detection and Response (EDR) i systemy wykrywania włamań.

Kontrole zarządcze dotyczą decyzji, nadzoru, polityk i zarządzania ryzykiem. Przykładem jest polityka bezpieczeństwa, formalne zatwierdzanie zmian, analiza ryzyka albo wymaganie okresowego przeglądu uprawnień.

Kontrole operacyjne dotyczą codziennego sposobu pracy. Przykładem jest procedura obsługi incydentu, szkolenie pracowników, tworzenie kopii zapasowych według harmonogramu albo ręczna weryfikacja zgłoszenia.

Kontrole fizyczne chronią fizyczny dostęp do ludzi, urządzeń, budynków i pomieszczeń. Przykładami są identyfikatory, zamki, ogrodzenia, kamery, ochrona, oświetlenie i czujniki.

Typy kontroli

Kontrola preventive ma zapobiegać zdarzeniu. Przykład: MFA utrudnia przejęcie konta nawet wtedy, gdy hasło wycieknie.

Kontrola deterrent ma odstraszać. Przykład: widoczna kamera może zniechęcać do wejścia do chronionej strefy.

Kontrola detective ma wykrywać. Przykład: Security Information and Event Management (SIEM) może wykryć podejrzane logowania.

Kontrola corrective ma przywracać stan po problemie. Przykład: odtworzenie danych z backupu po awarii lub ransomware.

Kontrola compensating zastępuje lub uzupełnia inną kontrolę, gdy podstawowa nie może zostać wdrożona. Przykład: starszy system nie obsługuje MFA, więc firma ogranicza dostęp do niego przez sieć prywatną, jump server i dodatkowy monitoring.

Kontrola directive nakazuje lub wskazuje wymagane zachowanie. Przykład: polityka haseł, procedura zgłaszania incydentów albo znak „tylko dla upoważnionego personelu”.

Jak to działa krok po kroku

Organizacja identyfikuje zasób, np. bazę klientów.

Identyfikuje ryzyko, np. nieautoryzowany dostęp.

Dobiera kontrolę preventive, np. MFA i zasadę najmniejszych uprawnień.

Dodaje kontrolę detective, np. alerty logowania z nietypowych lokalizacji.

Przygotowuje kontrolę corrective, np. procedurę blokady konta i resetu poświadczeń.

Jeśli pełna kontrola nie jest możliwa, wdraża kontrolę compensating.

Dokumentuje wymagane zachowania jako kontrolę directive.

Regularnie sprawdza, czy kontrole działają.

Przykład praktyczny

Firma chce zabezpieczyć dostęp do panelu administratora.

Kontrola techniczna: MFA.

Kontrola zarządcza: polityka wymagająca osobnych kont administracyjnych.

Kontrola operacyjna: procedura okresowego przeglądu administratorów.

Kontrola fizyczna: dostęp do serwerowni tylko na identyfikator.

Kontrola preventive: blokowanie logowania spoza VPN.

Kontrola detective: alert przy logowaniu administratora poza godzinami pracy.

Kontrola corrective: procedura resetu poświadczeń i blokady konta po przejęciu.

Kontrola compensating: dodatkowy monitoring starszego systemu, który nie obsługuje MFA.

Przykład egzaminacyjny

Scenariusz

Firma ma starszą aplikację, której nie można zaktualizować przez trzy miesiące. Aplikacja musi działać, ale ma znaną podatność. Co jest najlepszym rozwiązaniem tymczasowym?

Najlepsza odpowiedź:

Wdrożyć kontrolę kompensacyjną, np. ograniczyć dostęp sieciowy, dodać monitoring, WAF, segmentację albo dodatkowe reguły detekcji.

Z czym nie mylić

Najczęstsza pomyłka to mieszanie kategorii i funkcji. „Firewall” jest kontrolą techniczną, ale jego funkcja może być preventive, jeśli blokuje niedozwolony ruch, albo detective, jeśli tylko loguje i alarmuje. Jedna kontrola może mieć więcej niż jedną funkcję.

Typowe błędy

Błąd pierwszy: zakładanie, że każda kontrola techniczna jest automatycznie preventive.

Błąd drugi: ignorowanie kontroli administracyjnych i operacyjnych, bo wydają się „mniej techniczne”.

Błąd trzeci: wybieranie najdroższej kontroli zamiast tej, która najlepiej pasuje do scenariusza.

Definicja do zapamiętania

Kontrola bezpieczeństwa to mechanizm, proces lub działanie, które zmniejsza ryzyko przez zapobieganie, wykrywanie, korygowanie, odstraszanie, kompensowanie lub nakazywanie określonego zachowania.

2. Confidentiality, Integrity, Availability (CIA)

Problem

Bezpieczeństwo nie oznacza tylko „żeby nikt się nie włamał”. Dane mogą być naruszone na kilka sposobów: ktoś może je ujawnić, zmienić albo sprawić, że przestaną być dostępne. Model Confidentiality, Integrity, Availability (CIA) pomaga uporządkować te trzy podstawowe cele ochrony.

Wyjaśnienie od podstaw

Confidentiality, czyli poufność, oznacza, że dane są dostępne tylko dla uprawnionych osób, systemów lub procesów.

Integrity, czyli integralność, oznacza, że dane są poprawne, kompletne i nie zostały nieautoryzowanie zmienione.

Availability, czyli dostępność, oznacza, że systemy i dane są dostępne wtedy, gdy są potrzebne.

CIA jest jednym z najważniejszych modeli w Security+. Ułatwia rozpoznanie, jaki skutek ma dane zdarzenie. Ransomware może naruszać dostępność, bo blokuje dostęp do danych. Nieautoryzowana modyfikacja przelewu narusza integralność. Wyciek bazy klientów narusza poufność.

Jak to działa krok po kroku

Patrzysz na zasób, np. dokumentację medyczną.

Pytasz: czy dane mogą zostać ujawnione? To problem poufności.

Pytasz: czy dane mogą zostać zmienione? To problem integralności.

Pytasz: czy dane mogą być niedostępne? To problem dostępności.

Dobierasz kontrolę do celu ochrony.

Przykład praktyczny

System bankowy musi chronić wszystkie trzy elementy CIA.

Poufność: klient nie powinien widzieć danych innego klienta.

Integralność: saldo konta nie może zostać zmienione bez autoryzowanej transakcji.

Dostępność: klient powinien móc wykonać przelew wtedy, gdy system jest potrzebny.

Przykład egzaminacyjny

Scenariusz

Atakujący zmienił numer rachunku bankowego w systemie płatności, ale nie pobrał danych i nie wyłączył systemu. Który element CIA został najbardziej naruszony?

Poprawna odpowiedź:

Integrity, bo problemem jest nieautoryzowana zmiana danych.

Z czym nie mylić

Poufność nie oznacza integralności. Dane mogą być zaszyfrowane i nadal błędne. Integralność nie oznacza dostępności. Dane mogą być poprawne, ale system może być niedostępny. Dostępność nie oznacza braku zabezpieczeń — system dostępny dla wszystkich bez kontroli dostępu może być bardzo niebezpieczny.

Typowe błędy

Najczęstszy błąd to automatyczne wybieranie poufności jako odpowiedzi na każde pytanie o dane. Na egzaminie trzeba patrzeć na skutek: ujawnienie, zmiana czy brak dostępu.

Definicja do zapamiętania

CIA to model trzech podstawowych celów bezpieczeństwa: poufność chroni przed nieuprawnionym ujawnieniem, integralność przed nieuprawnioną zmianą, a dostępność przed brakiem dostępu do systemu lub danych.

3. Authentication, Authorization, Accounting (AAA)

Problem

System musi wiedzieć, kto próbuje uzyskać dostęp, co wolno tej osobie zrobić i jak zapisać jej działania. Bez tego nie da się bezpiecznie zarządzać dostępem ani później ustalić odpowiedzialności.

Wyjaśnienie od podstaw

Authentication, czyli uwierzytelnianie, odpowiada na pytanie: „Kim jesteś?”. Przykładami są hasło, certyfikat, token sprzętowy, biometria albo kod jednorazowy.

Authorization, czyli autoryzacja, odpowiada na pytanie: „Co wolno Ci zrobić?”. System sprawdza, czy konto ma prawo do pliku, aplikacji, funkcji lub operacji.

Accounting, czyli rozliczalność lub rejestrowanie aktywności, odpowiada na pytanie: „Co zrobiłeś?”. System zapisuje działania w logach.

Jak to działa krok po kroku

Użytkownik podaje login i hasło.

System sprawdza tożsamość — to authentication.

Użytkownik próbuje otworzyć raport.

System sprawdza uprawnienia — to authorization.

System zapisuje informację o logowaniu i dostępie do raportu — to accounting.

Przykład praktyczny

Administrator loguje się do panelu zarządzania. MFA potwierdza jego tożsamość. Role-Based Access Control (RBAC) pozwala mu zarządzać serwerami, ale nie pozwala zatwierdzać płatności. Logi zapisują, że administrator zmienił konfigurację zapory sieciowej o konkretnej godzinie.

Przykład egzaminacyjny

Scenariusz

Użytkownik zalogował się poprawnie, ale nie może usunąć pliku. Co należy sprawdzić?

Najlepsza odpowiedź:

Autoryzację, czyli uprawnienia do wykonania operacji.

Z czym nie mylić

Największa pułapka to mylenie authentication i authorization. Poprawne logowanie nie oznacza, że użytkownik ma dostęp do wszystkiego. Druga pułapka to ignorowanie accounting. Bez logów trudno wykazać, kto wykonał daną zmianę.

Typowe błędy

Częsty błąd w praktyce to używanie wspólnych kont administracyjnych. Jeśli pięć osób używa tego samego konta „admin”, accounting traci wartość, bo nie wiadomo, kto faktycznie wykonał działanie.

Definicja do zapamiętania

AAA oznacza: authentication potwierdza tożsamość, authorization określa dozwolone działania, a accounting zapisuje aktywność użytkownika lub systemu.

4. Non-repudiation

Problem

W niektórych sytuacjach trzeba móc udowodnić, że konkretna osoba lub system wykonał konkretne działanie. Bez tego użytkownik może zaprzeczyć wysłaniu wiadomości, zatwierdzeniu transakcji albo podpisaniu dokumentu.

Wyjaśnienie od podstaw

Non-repudiation, czyli niezaprzeczalność, oznacza możliwość powiązania działania z konkretnym podmiotem w sposób trudny do podważenia. W praktyce osiąga się ją przez podpisy cyfrowe, certyfikaty, kontrolę dostępu, logi, znaczniki czasu i właściwe zabezpieczenie kluczy prywatnych.

Niezaprzeczalność nie jest tym samym co poufność. Szyfrowanie może ukryć treść wiadomości, ale samo w sobie nie zawsze dowodzi, kto ją wysłał. Podpis cyfrowy pomaga potwierdzić autora i integralność.

Jak to działa krok po kroku

Nadawca ma klucz prywatny.

Tworzy podpis cyfrowy dla dokumentu lub wiadomości.

Odbiorca używa klucza publicznego nadawcy do weryfikacji podpisu.

Jeśli podpis pasuje, odbiorca wie, że dokument nie został zmieniony i że podpis pochodzi od posiadacza klucza prywatnego.

Logi i znaczniki czasu wzmacniają dowód.

Przykład praktyczny

Dyrektor zatwierdza elektronicznie umowę. System używa podpisu cyfrowego i zapisuje log: kto podpisał, kiedy, z jakiego konta i jaki dokument. Później dyrektorowi trudniej zaprzeczyć, że zatwierdził dokument.

Przykład egzaminacyjny

Scenariusz

Firma chce mieć pewność, że nadawca wiadomości nie będzie mógł później zaprzeczyć jej wysłaniu. Który mechanizm jest najlepszy?

Najlepsza odpowiedź:

Podpis cyfrowy.

Z czym nie mylić

Nie myl non-repudiation z encryption. Encryption chroni poufność. Digital signature wspiera integralność, uwierzytelnienie nadawcy i niezaprzeczalność.

Typowe błędy

Częsty błąd to twierdzenie, że samo hasło zapewnia non-repudiation. Jeśli konto jest współdzielone albo słabo chronione, trudno udowodnić, kto naprawdę wykonał działanie.

Definicja do zapamiętania

Non-repudiation to możliwość udowodnienia, że określony podmiot wykonał określone działanie, najczęściej dzięki podpisom cyfrowym, logom i właściwej ochronie tożsamości.

5. Zero Trust

Problem

Tradycyjne podejście zakładało często, że użytkownik lub system znajdujący się „w sieci firmowej” jest bardziej zaufany. To podejście słabo działa w środowiskach chmurowych, hybrydowych, z pracą zdalną i urządzeniami mobilnymi. Atakujący po przejęciu konta lub urządzenia może poruszać się wewnątrz sieci, jeśli system nadmiernie ufa lokalizacji.

Wyjaśnienie od podstaw

Zero Trust to model bezpieczeństwa oparty na zasadzie: nie ufaj domyślnie, stale weryfikuj. Dostęp powinien zależeć od tożsamości, stanu urządzenia, kontekstu, ryzyka, polityki i konkretnego zasobu, a nie tylko od tego, że ktoś jest „w środku sieci”.

W celach SY0-701 Zero Trust obejmuje elementy control plane i data plane, w tym adaptive identity, policy-driven access control, policy administrator, policy engine oraz policy enforcement point.

Jak to działa krok po kroku

Użytkownik lub system żąda dostępu do zasobu.

System sprawdza tożsamość użytkownika.

System ocenia kontekst, np. urządzenie, lokalizację, ryzyko, typ zasobu i zachowanie.

Policy engine podejmuje decyzję na podstawie polityk.

Policy administrator przekłada decyzję na działanie.

Policy enforcement point wymusza decyzję: pozwala, blokuje lub ogranicza dostęp.

Decyzja może być stale ponownie oceniana.

Przykład praktyczny

Pracownik loguje się do aplikacji finansowej z firmowego laptopa z aktualnym systemem, z typowej lokalizacji i po przejściu MFA. System pozwala na dostęp. Ten sam pracownik próbuje później zalogować się z nieznanego urządzenia z nietypowego kraju. Zero Trust może wymagać dodatkowej weryfikacji albo zablokować dostęp.

Przykład egzaminacyjny

Scenariusz

Firma chce ograniczyć ryzyko wynikające z przejętych kont i pracy zdalnej. Chce, aby dostęp był oceniany na podstawie tożsamości, stanu urządzenia i ryzyka, a nie tylko adresu IP. Który model najlepiej pasuje?

Poprawna odpowiedź:

Zero Trust.

Z czym nie mylić

Zero Trust nie jest jednym produktem. To model architektury i podejścia do kontroli dostępu. Produkt może wspierać Zero Trust, ale sam zakup narzędzia nie oznacza wdrożenia Zero Trust.

Nie myl też Zero Trust z całkowitym brakiem zaufania do użytkowników. Chodzi o brak domyślnego technicznego zaufania, a nie o kulturę podejrzliwości wobec ludzi.

Typowe błędy

Częsty błąd to myślenie, że Zero Trust oznacza wyłącznie MFA. MFA jest ważnym elementem, ale Zero Trust obejmuje też segmentację, polityki, ocenę ryzyka, urządzenia, monitoring i egzekwowanie decyzji dostępu.

Definicja do zapamiętania

Zero Trust to model bezpieczeństwa, w którym żaden użytkownik, system ani lokalizacja nie są zaufane domyślnie, a dostęp jest stale weryfikowany na podstawie polityki, tożsamości, kontekstu i ryzyka.

6. Bezpieczeństwo fizyczne

Problem

Cyberbezpieczeństwo nie kończy się na systemach informatycznych. Jeśli atakujący wejdzie do serwerowni, ukradnie laptopa, podłączy nieautoryzowane urządzenie albo podejrzy ekran pracownika, może ominąć wiele zabezpieczeń logicznych.

Wyjaśnienie od podstaw

Bezpieczeństwo fizyczne chroni ludzi, budynki, pomieszczenia, urządzenia i nośniki danych. W oficjalnych celach SY0-701 w domenie 1.2 pojawiają się m.in. bollards, access control vestibule, fencing, video surveillance, security guard, access badge, lighting i sensors.

Bollards to fizyczne słupki chroniące przed wjazdem pojazdu. Access control vestibule, często nazywany potocznie mantrap, to kontrolowana przestrzeń między dwoma drzwiami, która ogranicza wejście wielu osób naraz. Kamery i ochrona działają detekcyjnie i odstraszająco. Identyfikatory i zamki ograniczają dostęp.

Jak to działa krok po kroku

Organizacja identyfikuje fizycznie wrażliwe miejsca.

Ogranicza dostęp tylko do uprawnionych osób.

Dodaje monitoring, np. kamery i czujniki.

Wprowadza procedury wejścia, identyfikacji i eskortowania gości.

Rejestruje zdarzenia fizyczne.

Okresowo sprawdza skuteczność kontroli.

Przykład praktyczny

Serwerownia ma drzwi na kartę, kamerę, czujnik otwarcia drzwi i procedurę wpisu gości. Pracownik z działu marketingu nie może wejść samodzielnie, bo nie ma potrzeby biznesowej. Technik zewnętrzny może wejść tylko po zatwierdzeniu i pod opieką pracownika.

Przykład egzaminacyjny

Scenariusz

Firma chce zapobiec temu, aby jedna osoba z identyfikatorem wpuściła za sobą kilka nieuprawnionych osób. Która kontrola jest najlepsza?

Najlepsza odpowiedź:

Access control vestibule.

Z czym nie mylić

Nie myl kamer z kontrolą zapobiegawczą w ścisłym sensie. Kamera często działa jako detective i deterrent, ale sama fizycznie nie blokuje wejścia. Zamek lub access control vestibule lepiej pasują do kontroli preventive.

Typowe błędy

Częsty błąd to lekceważenie fizycznego bezpieczeństwa w egzaminie technicznym. Security+ traktuje ochronę fizyczną jako część całościowego programu bezpieczeństwa.

Definicja do zapamiętania

Bezpieczeństwo fizyczne to zestaw kontroli chroniących fizyczny dostęp do ludzi, urządzeń, pomieszczeń i nośników danych.

7. Deception and disruption technology

Problem

Organizacja chce nie tylko blokować ataki, ale też wykrywać podejrzaną aktywność, opóźniać atakującego i zbierać informacje o jego działaniach. Do tego służą technologie deception and disruption.

Wyjaśnienie od podstaw

Honeypot to wabik udający prawdziwy system lub usługę. Jego celem jest przyciągnięcie atakującego i wykrycie aktywności, która nie powinna się tam pojawić.

Honeynet to sieć honeypotów.

Honeyfile to plik-pułapka, np. dokument wyglądający jak lista haseł, którego otwarcie generuje alert.

Honeytoken to fałszywy element, np. nieprawdziwy klucz API, konto lub rekord danych, którego użycie wskazuje na podejrzaną aktywność.

Te technologie są wymienione w domenie 1.2 jako deception and disruption technology.

Jak to działa krok po kroku

Organizacja umieszcza wabik w kontrolowanym miejscu.

Normalni użytkownicy nie powinni go używać.

Ktoś próbuje wejść w interakcję z wabikiem.

System generuje alert.

Zespół bezpieczeństwa analizuje źródło aktywności.

Informacje pomagają wykryć intruza, błędną konfigurację lub nieuprawnione działania.

Przykład praktyczny

Firma tworzy fałszywy plik „admin_passwords.xlsx” w miejscu, do którego zwykli użytkownicy nie zaglądają. Plik nie zawiera prawdziwych haseł. Jeśli ktoś go otworzy, system generuje alert. To może wskazywać na malware, insider threat albo konto używane niezgodnie z przeznaczeniem.

Przykład egzaminacyjny

Scenariusz

Organizacja chce wykryć nieuprawnione przeglądanie udziałów sieciowych. Chce użyć pliku, który nie powinien być otwierany przez legalnych użytkowników. Co będzie najlepsze?

Poprawna odpowiedź:

Honeyfile.

Z czym nie mylić

Honeypot nie jest głównym systemem produkcyjnym. Nie powinien przechowywać prawdziwych danych klientów. Jego celem jest detekcja, analiza i opóźnienie, a nie świadczenie normalnej usługi biznesowej.

Typowe błędy

Częsty błąd to umieszczanie honeypota bez monitoringu. Wabik bez alertowania i analizy nie daje wartości bezpieczeństwa. Drugi błąd to tworzenie wabików, które mogą zaszkodzić środowisku produkcyjnemu.

Definicja do zapamiętania

Deception technology używa kontrolowanych wabików, takich jak honeypot, honeynet, honeyfile i honeytoken, aby wykrywać, analizować lub opóźniać podejrzaną aktywność.

8. Change management

Problem

Wiele incydentów i awarii wynika nie z zaawansowanego ataku, ale ze źle przeprowadzonej zmiany. Ktoś zmienia regułę firewalla, aktualizuje aplikację, restartuje usługę albo modyfikuje konfigurację, nie sprawdzając wpływu na bezpieczeństwo i dostępność.

Wyjaśnienie od podstaw

Change management to proces kontrolowanego wprowadzania zmian. Ma zapewnić, że zmiany są uzasadnione, zatwierdzone, przetestowane, udokumentowane i możliwe do wycofania.

W celach SY0-701 change management obejmuje m.in. approval process, ownership, stakeholders, impact analysis, test results, backout plan, maintenance window, standard operating procedure, allow lists/deny lists, downtime, service restart, dependencies, dokumentację i version control.

Jak to działa krok po kroku

Ktoś zgłasza potrzebę zmiany.

Właściciel zmiany opisuje cel i zakres.

Interesariusze oceniają wpływ na systemy, użytkowników, bezpieczeństwo i zgodność.

Zespół wykonuje testy.

Zmiana zostaje zatwierdzona.

Ustalane jest okno serwisowe.

Przygotowywany jest backout plan, czyli plan wycofania.

Zmiana jest wdrażana.

Wynik jest weryfikowany.

Dokumentacja, diagramy, procedury i wersje konfiguracji są aktualizowane.

Przykład praktyczny

Administrator chce dodać regułę firewalla, która pozwoli nowej aplikacji komunikować się z bazą danych. Bez change management może przypadkowo otworzyć zbyt szeroki dostęp. Z change management musi określić, jaki adres źródłowy, jaki adres docelowy, jaki port, po co, na jak długo, kto zatwierdza i jak sprawdzić, czy reguła działa bez nadmiernego ryzyka.

Przykład egzaminacyjny

Scenariusz

Po zmianie konfiguracji zapory firma utraciła dostęp do aplikacji biznesowej. Nie ma planu wycofania ani dokumentacji poprzednich ustawień. Czego zabrakło?

Najlepsza odpowiedź:

Poprawnego procesu change management, szczególnie backout plan, impact analysis i dokumentacji.

Z czym nie mylić

Change management nie jest tym samym co patch management. Patch management dotyczy aktualizacji i poprawek. Change management jest szerszy i obejmuje każdą istotną zmianę w środowisku.

Nie myl też change management z biurokracją. Jego celem jest ograniczenie ryzyka technicznego, operacyjnego i bezpieczeństwa.

Typowe błędy

Częsty błąd to wdrażanie zmiany bez planu wycofania. Drugi błąd to nieuwzględnienie zależności, np. aplikacja działa, ale integracja z bazą danych przestaje działać. Trzeci błąd to brak aktualizacji dokumentacji po zmianie.

Definicja do zapamiętania

Change management to kontrolowany proces wprowadzania zmian, który zmniejsza ryzyko awarii, luk bezpieczeństwa i nieudokumentowanych konfiguracji.

9. Kryptografia i rozwiązania kryptograficzne

Problem

Dane trzeba chronić w różnych sytuacjach: gdy są zapisane na dysku, przesyłane przez sieć, podpisywane, porównywane, maskowane albo używane do potwierdzania tożsamości. Jedno narzędzie kryptograficzne nie rozwiązuje wszystkich problemów.

Wyjaśnienie od podstaw

Kryptografia to dziedzina związana z matematyczną ochroną informacji. W Security+ najważniejsze jest rozumienie, kiedy użyć szyfrowania, hashowania, saltingu, podpisu cyfrowego, certyfikatu, tokenizacji albo infrastruktury klucza publicznego.

Oficjalny cel 1.4 obejmuje m.in. Public Key Infrastructure (PKI), klucze publiczne i prywatne, key escrow, encryption, symmetric/asymmetric encryption, key exchange, Trusted Platform Module (TPM), Hardware Security Module (HSM), key management system, secure enclave, obfuscation, steganography, tokenization, data masking, hashing, salting, digital signatures, key stretching, blockchain, certificates, Certificate Authorities (CA), Certificate Revocation Lists (CRLs), Online Certificate Status Protocol (OCSP), Certificate Signing Request (CSR) i wildcard certificates.

9.1 Szyfrowanie

Problem

Jeśli dane zostaną przechwycone lub skradzione, nie powinny być czytelne dla osoby nieuprawnionej. Szyfrowanie rozwiązuje problem poufności.

Wyjaśnienie od podstaw

Szyfrowanie zamienia dane czytelne na nieczytelne przy użyciu klucza. Osoba lub system z właściwym kluczem może dane odszyfrować.

Szyfrowanie symetryczne używa tego samego klucza do szyfrowania i odszyfrowywania. Jest szybkie i dobre do dużych ilości danych.

Szyfrowanie asymetryczne używa pary kluczy: publicznego i prywatnego. Klucz publiczny można udostępnić, a prywatny trzeba chronić. Jest przydatne do wymiany kluczy, podpisów cyfrowych i certyfikatów.

Jak to działa krok po kroku

System wybiera dane do ochrony.

Dobiera algorytm i klucz.

Dane są szyfrowane.

Dane mogą być zapisane lub przesłane.

Uprawniony odbiorca używa właściwego klucza do odszyfrowania.

Przykład praktyczny

Laptop pracownika ma full-disk encryption. Jeśli laptop zostanie skradziony, dane na dysku nie powinny być czytelne bez klucza lub właściwego uwierzytelnienia.

Przykład egzaminacyjny

Scenariusz

Firma chce chronić dane zapisane na laptopach przed odczytem po kradzieży urządzenia. Co jest najlepsze?

Poprawna odpowiedź:

Full-disk encryption.

Z czym nie mylić

Nie myl szyfrowania z hashingiem. Szyfrowanie jest odwracalne przy użyciu klucza. Hashing jest jednokierunkowy.

Typowe błędy

Częsty błąd to myślenie, że zaszyfrowane dane zawsze są bezpieczne. Jeśli klucz jest źle chroniony, atakujący może odszyfrować dane. Ochrona kluczy jest równie ważna jak algorytm.

Definicja do zapamiętania

Szyfrowanie chroni poufność danych przez zamianę ich na postać nieczytelną bez właściwego klucza.

9.2 Hashing, salting i key stretching

Problem

Czasami nie chcemy przechowywać lub porównywać oryginalnych danych. Na przykład system nie powinien przechowywać haseł w postaci jawnej. Potrzebuje sposobu sprawdzenia hasła bez zapisywania samego hasła.

Wyjaśnienie od podstaw

Hashing tworzy skrót danych. Dla tych samych danych wejściowych wynik powinien być taki sam, ale z wyniku nie powinno dać się łatwo odtworzyć oryginału.

Salting dodaje losową wartość do danych przed hashowaniem. Dzięki temu dwa identyczne hasła nie muszą mieć takich samych hashy.

Key stretching celowo spowalnia obliczanie hashy haseł, aby utrudnić masowe zgadywanie.

Jak to działa krok po kroku

Użytkownik tworzy hasło.

System generuje losowy salt.

Hasło i salt są przetwarzane przez funkcję haszującą.

System zapisuje hash i salt, a nie hasło jawne.

Przy logowaniu system powtarza proces i porównuje wynik.

Przykład praktyczny

Dwóch użytkowników ma takie samo hasło. Bez saltingu ich hash mógłby wyglądać identycznie. Z saltingiem system przechowuje różne wyniki, co utrudnia ataki z użyciem gotowych tablic hashy.

Przykład egzaminacyjny

Scenariusz

Firma chce ograniczyć skutki wycieku bazy haseł. Które rozwiązanie jest najlepsze?

Poprawna odpowiedź:

Przechowywanie haseł jako salted hashes z mechanizmem key stretching.

Z czym nie mylić

Hashing nie zapewnia poufności w takim samym sensie jak szyfrowanie. Nie odszyfrowuje się hasha. Hash służy głównie do integralności i bezpiecznego porównywania.

Typowe błędy

Częsty błąd to mówienie „hasła są zaszyfrowane”, gdy w rzeczywistości powinny być hashowane i solone. Szyfrowanie haseł sugeruje możliwość odszyfrowania, co zwykle nie jest pożądane.

Definicja do zapamiętania

Hashing tworzy jednokierunkowy skrót danych, salting dodaje losowość, a key stretching utrudnia szybkie zgadywanie haseł.

9.3 Podpis cyfrowy

Problem

Odbiorca chce wiedzieć, czy wiadomość lub plik pochodzi od właściwego nadawcy i czy nie został zmieniony. Potrzebna jest integralność, potwierdzenie nadawcy i często niezaprzeczalność.

Wyjaśnienie od podstaw

Podpis cyfrowy używa kryptografii asymetrycznej. Nadawca podpisuje dane swoim kluczem prywatnym. Odbiorca weryfikuje podpis kluczem publicznym nadawcy.

Podpis cyfrowy nie musi ukrywać treści. Jego głównym celem jest potwierdzenie integralności i pochodzenia.

Jak to działa krok po kroku

System tworzy hash dokumentu.

Hash jest podpisywany kluczem prywatnym nadawcy.

Dokument i podpis trafiają do odbiorcy.

Odbiorca oblicza hash dokumentu.

Odbiorca weryfikuje podpis kluczem publicznym.

Jeśli wszystko się zgadza, dokument nie został zmieniony i pochodzi od posiadacza klucza prywatnego.

Przykład praktyczny

Dostawca oprogramowania podpisuje aktualizację. System klienta sprawdza podpis przed instalacją. Jeśli podpis jest nieprawidłowy, aktualizacja może zostać odrzucona.

Przykład egzaminacyjny

Scenariusz

Firma chce mieć pewność, że pakiet instalacyjny nie został zmodyfikowany przez osobę trzecią. Co powinna sprawdzić?

Poprawna odpowiedź:

Podpis cyfrowy pakietu.

Z czym nie mylić

Nie myl podpisu cyfrowego z szyfrowaniem. Podpis cyfrowy niekoniecznie ukrywa dane. Szyfrowanie ukrywa treść, ale samo nie zawsze potwierdza autora.

Typowe błędy

Częsty błąd to wybieranie szyfrowania, gdy pytanie dotyczy integralności i autora. Jeśli w scenariuszu pojawia się „verify the sender” albo „ensure the file has not been altered”, często chodzi o podpis cyfrowy lub hashing.

Definicja do zapamiętania

Podpis cyfrowy potwierdza integralność danych i pochodzenie od posiadacza klucza prywatnego.

9.4 Public Key Infrastructure (PKI) i certyfikaty

Problem

Kryptografia asymetryczna wymaga zaufania do kluczy publicznych. Skąd wiesz, że klucz publiczny naprawdę należy do danej strony, firmy lub osoby? Ten problem rozwiązuje Public Key Infrastructure (PKI).

Wyjaśnienie od podstaw

Public Key Infrastructure (PKI) to system zarządzania certyfikatami, kluczami i zaufaniem. Certyfikat cyfrowy wiąże klucz publiczny z konkretną tożsamością, np. domeną internetową lub organizacją.

Certificate Authority (CA) to urząd certyfikacji, który wystawia certyfikaty.

Certificate Signing Request (CSR) to żądanie podpisania certyfikatu, które zawiera m.in. informacje o podmiocie i klucz publiczny.

Certificate Revocation List (CRL) i Online Certificate Status Protocol (OCSP) służą do sprawdzania, czy certyfikat nie został unieważniony.

Self-signed certificate jest podpisany przez samego siebie, a nie przez zaufaną stronę trzecią. Może być użyteczny w laboratorium lub środowisku wewnętrznym, ale w publicznym Internecie zwykle powoduje problem z zaufaniem.

Jak to działa krok po kroku

Organizacja tworzy parę kluczy.

Generuje CSR.

CA weryfikuje informacje.

CA wystawia certyfikat.

Serwer używa certyfikatu, np. dla HTTPS.

Klient sprawdza, czy certyfikat jest ważny, zaufany i nieunieważniony.

Jeśli weryfikacja się powiedzie, można zestawić zaufaną komunikację.

Przykład praktyczny

Użytkownik otwiera bankowość internetową. Przeglądarka sprawdza certyfikat serwera. Jeśli certyfikat jest ważny, wystawiony dla właściwej domeny i podpisany przez zaufane CA, użytkownik może mieć większą pewność, że komunikuje się z właściwym serwerem.

Przykład egzaminacyjny

Scenariusz

Użytkownicy widzą ostrzeżenie przeglądarki, że certyfikat strony nie jest zaufany. Certyfikat został wygenerowany przez administratora i nie jest podpisany przez zaufany urząd. Co jest przyczyną?

Poprawna odpowiedź:

Self-signed certificate albo brak zaufanego CA.

Z czym nie mylić

Nie myl certyfikatu z kluczem prywatnym. Certyfikat zawiera klucz publiczny i informacje o tożsamości. Klucz prywatny musi pozostać tajny.

Nie myl CRL i OCSP z szyfrowaniem. One służą do sprawdzania statusu certyfikatu.

Typowe błędy

Częsty błąd to ignorowanie wygaśnięcia certyfikatu. W praktyce wygasły certyfikat może spowodować awarię aplikacji lub przerwanie integracji między systemami.

Definicja do zapamiętania

PKI to infrastruktura zaufania, która wiąże klucze publiczne z tożsamościami za pomocą certyfikatów i urzędów certyfikacji.

9.5 Tokenization, data masking, steganography i obfuscation

Problem

Nie zawsze trzeba albo można klasycznie zaszyfrować dane. Czasem trzeba ukryć część danych, zastąpić dane tokenem albo utrudnić ich zrozumienie.

Wyjaśnienie od podstaw

Tokenization zastępuje wrażliwą wartość tokenem. Przykład: numer karty płatniczej zostaje zastąpiony losowym tokenem, a prawdziwa wartość jest przechowywana w bezpiecznym systemie.

Data masking ukrywa część danych. Przykład: numer karty widoczny jako **** **** **** 1234.

Steganography ukrywa informację w innym nośniku, np. w obrazie.

Obfuscation utrudnia zrozumienie danych lub kodu, ale nie musi zapewniać tak silnej ochrony jak kryptografia.

Jak to działa krok po kroku

Organizacja identyfikuje dane wrażliwe.

Wybiera metodę: tokenizacja, maskowanie, obfuskacja lub szyfrowanie.

Dane są przekształcane.

Użytkownik lub aplikacja widzi tylko tyle, ile potrzebuje.

Prawdziwe dane są chronione lub ukryte.

Przykład praktyczny

Konsultant call center widzi tylko ostatnie cztery cyfry karty klienta. To wystarcza do weryfikacji, ale nie ujawnia pełnego numeru.

Przykład egzaminacyjny

Scenariusz

Aplikacja testowa potrzebuje realistycznych danych, ale programiści nie powinni widzieć prawdziwych numerów klientów. Co jest dobrym rozwiązaniem?

Poprawna odpowiedź:

Data masking lub tokenization, zależnie od scenariusza.

Z czym nie mylić

Maskowanie nie zawsze jest tym samym co szyfrowanie. Jeśli dane są tylko ukryte w interfejsie, ale nadal dostępne w bazie w postaci jawnej, nie jest to pełna ochrona kryptograficzna.

Typowe błędy

Częsty błąd to uznawanie obfuscation za silne zabezpieczenie kryptograficzne. Obfuskacja może utrudnić analizę, ale nie powinna być jedyną ochroną danych wrażliwych.

Definicja do zapamiętania

Tokenization zastępuje dane tokenem, data masking ukrywa część danych, steganography ukrywa dane w innym nośniku, a obfuscation utrudnia ich zrozumienie.

Kluczowe pojęcia

Przykłady

Przykład 1: Dobór kontroli do problemu

Firma ma problem z przejęciami kont po phishingu. Najlepszym zestawem kontroli nie jest jedna technologia, ale warstwowe podejście:

• MFA jako kontrola preventive
• szkolenie phishingowe jako kontrola operational i directive
• alerty logowania jako kontrola detective
• procedura blokowania konta jako kontrola corrective
• ograniczenie dostępu administratorów jako kontrola preventive
• dodatkowy monitoring starszych systemów jako kontrola compensating.
• Przykład 2: CIA w systemie medycznym

System medyczny przechowuje wyniki badań. Poufność oznacza, że pacjent A nie widzi danych pacjenta B. Integralność oznacza, że wynik badania nie został zmieniony bez autoryzacji. Dostępność oznacza, że lekarz ma dostęp do danych wtedy, gdy podejmuje decyzję medyczną.

Przykład 3: Change management w regule firewalla

Administrator chce otworzyć port do nowej aplikacji. Poprawny proces wymaga zgłoszenia zmiany, właściciela, analizy wpływu, zatwierdzenia, testów, okna serwisowego, planu wycofania i aktualizacji dokumentacji. Bez tego można przypadkowo otworzyć dostęp do wrażliwej usługi z całego Internetu.

Przykład 4: Wybór mechanizmu kryptograficznego

Chcesz ukryć dane na dysku: encryption.

Chcesz sprawdzić, czy plik się nie zmienił: hashing.

Chcesz potwierdzić autora i integralność: digital signature.

Chcesz bezpiecznie obsłużyć certyfikaty strony: PKI.

Chcesz ograniczyć widoczność numeru karty: masking lub tokenization.

Praktyczne zastosowania

Projektowanie warstwowych zabezpieczeń.

Analiza scenariuszy egzaminacyjnych typu „best control”.

Dobieranie mechanizmów kryptograficznych do celu.

Rozumienie, dlaczego sama technologia bez procesu nie wystarcza.

Przygotowanie do modułów IAM, vulnerability management, incident response, security architecture i governance.

Częste pomyłki

Typowe błędy

Uczenie się kontroli jako listy bez scenariuszy

Na egzaminie musisz dobrać kontrolę do problemu. To wymaga rozumienia funkcji kontroli.

Wybieranie najbardziej technicznej odpowiedzi

Security+ często premiuje rozwiązanie najtrafniejsze, nie najbardziej zaawansowane.

Mylenie celu kryptografii

Poufność, integralność, uwierzytelnienie i niezaprzeczalność to różne cele.

Ignorowanie procesów

Change management, dokumentacja i zatwierdzanie są równie ważne jak narzędzia.

Traktowanie Zero Trust jako MFA

MFA jest elementem, ale Zero Trust obejmuje szersze podejście do dostępu i polityki.

Co trzeba umieć na egzamin

W domenie 1.0 trzeba szczególnie umieć:

• klasyfikować kontrole według kategorii i funkcji
• rozpoznać, który element CIA został naruszony
• odróżnić authentication, authorization i accounting
• wybrać mechanizm zapewniający non-repudiation
• rozumieć elementy Zero Trust
• wskazać fizyczną kontrolę pasującą do scenariusza
• odróżnić honeypot, honeynet, honeyfile i honeytoken
• wskazać brakujący element change management
• dobrać encryption, hashing, salting, digital signature, certificate, tokenization lub masking do celu.

Checklista

User powinien umieć:

• Wyjaśnić, czym jest kontrola bezpieczeństwa.
• Odróżnić technical, managerial, operational i physical controls.
• Odróżnić preventive, deterrent, detective, corrective, compensating i directive controls.
• Wskazać, czy scenariusz narusza confidentiality, integrity czy availability.
• Odróżnić authentication, authorization i accounting.
• Wyjaśnić non-repudiation.
• Opisać podstawową zasadę Zero Trust.
• Wyjaśnić sens change management.
• Odróżnić szyfrowanie od hashowania.
• Wyjaśnić rolę saltingu i key stretching.
• Wyjaśnić podstawową rolę PKI, CA, CRL i OCSP.
• Dobrać mechanizm kryptograficzny do scenariusza.
• Pytania kontrolne
• Czym różni się kategoria kontroli od funkcji kontroli?
• Podaj przykład kontroli technicznej, zarządczej, operacyjnej i fizycznej.
• Czym różni się preventive control od detective control?
• Kiedy stosuje się compensating control?
• Jakie trzy cele obejmuje CIA?
• Czym różni się authentication od authorization?
• Co zapewnia accounting?
• Co oznacza non-repudiation?
• Dlaczego Zero Trust nie jest po prostu jednym produktem?
• Dlaczego change management ma znaczenie dla bezpieczeństwa?
• Czym różni się encryption od hashing?
• Po co stosuje się salting?
• Kiedy użyć digital signature?
• Jaka jest rola Certificate Authority?
• Czym różni się data masking od encryption?
• Odpowiedzi z wyjaśnieniami
• Kategoria mówi, jakiego obszaru dotyczy kontrola, a funkcja mówi, co kontrola robi.
• Firewall jest kontrolą techniczną, ale może pełnić funkcję preventive lub detective.
• Techniczna: MFA. Zarządcza: polityka bezpieczeństwa. Operacyjna: procedura backupu. Fizyczna: identyfikator dostępu.
• Każda z nich zmniejsza ryzyko w innym obszarze.
• Preventive control zapobiega, a detective control wykrywa.
• MFA utrudnia przejęcie konta, a SIEM może wykryć podejrzane logowanie.
• Compensating control stosuje się, gdy podstawowa kontrola nie może zostać wdrożona.
• Przykład: starszy system nie obsługuje MFA, więc ograniczasz dostęp sieciowo i dodajesz monitoring.
• CIA obejmuje confidentiality, integrity i availability.
• Poufność chroni przed ujawnieniem, integralność przed zmianą, dostępność przed brakiem dostępu.
• Authentication potwierdza tożsamość, authorization określa uprawnienia.
• Można się poprawnie zalogować i nadal nie mieć dostępu do pliku.
• Accounting zapisuje aktywność.
• Dzięki temu można ustalić, kto wykonał daną operację.
• Non-repudiation oznacza niezaprzeczalność działania.
• Pomagają w tym podpisy cyfrowe, logi, znaczniki czasu i ochrona kluczy.
• Zero Trust to model, a nie produkt.
• Obejmuje ciągłą weryfikację dostępu na podstawie tożsamości, kontekstu, polityki i ryzyka.
• Change management ogranicza ryzyko awarii i luk wynikających ze zmian.
• Wymaga analizy wpływu, testów, zatwierdzenia, planu wycofania i dokumentacji.
• Encryption jest odwracalne z kluczem, hashing jest jednokierunkowy.
• Encryption chroni poufność, hashing wspiera integralność i bezpieczne przechowywanie haseł.
• Salting dodaje losowość do hashowania.
• Utrudnia porównywanie hashy i użycie gotowych tablic.
• Digital signature stosuje się do potwierdzenia integralności i pochodzenia.
• Jest dobry do podpisywania dokumentów, kodu i wiadomości.
• Certificate Authority wystawia i podpisuje certyfikaty.
• Pomaga powiązać klucz publiczny z tożsamością.
• Data masking ukrywa część danych, a encryption szyfruje dane przy użyciu klucza.
• Maskowanie może być tylko prezentacyjne, a szyfrowanie zapewnia silniejszą ochronę poufności.
• Zadania praktyczne
• Laboratorium 1: Klasyfikacja kontroli bezpieczeństwa

Cel:

Nauczyć się rozróżniać kategorię i funkcję kontroli.

Kontekst:

Firma wdraża następujące zabezpieczenia:

Kroki:

• Dla każdej kontroli określ kategorię: technical, managerial, operational albo physical.
• Dla każdej kontroli określ funkcję: preventive, deterrent, detective, corrective, compensating albo directive.
• Uzasadnij każdą decyzję jednym zdaniem.
• Wskaż, które kontrole mogą mieć więcej niż jedną funkcję.

Oczekiwany rezultat:

Tabela z klasyfikacją i krótkim uzasadnieniem.

Kryteria zaliczenia:

• Poprawnie rozróżniono kategorię od funkcji.
• Nie przypisano automatycznie każdej kontroli technicznej jako preventive.
• Rozpoznano backup jako kontrolę głównie corrective.
• Rozpoznano dodatkowy monitoring starego systemu jako potencjalnie compensating.

To ćwiczenie wykonuj wyłącznie w legalnym, kontrolowanym środowisku laboratoryjnym. Nie stosuj go wobec cudzych systemów, sieci ani kont.

Laboratorium 2: Dobór mechanizmu kryptograficznego

Cel:

Nauczyć się dobierać właściwe rozwiązanie kryptograficzne do celu.

Kontekst:

Dopasuj rozwiązanie do wymagań:

Kroki:

• Dopasuj mechanizm: encryption, hashing, salting, key stretching, digital signature, data masking, PKI.
• Uzasadnij każdy wybór.
• Wskaż, które wymagania dotyczą poufności, integralności lub niezaprzeczalności.

Oczekiwany rezultat:

Poprawne dopasowanie mechanizmu do celu.

Kryteria zaliczenia:

• Nie pomylono encryption z hashingiem.
• Dla haseł wskazano hashing z saltingiem i key stretching.
• Dla autora dokumentu wskazano digital signature.
• Dla certyfikatu wskazano PKI/CA/status certyfikatu.

To ćwiczenie wykonuj wyłącznie w legalnym, kontrolowanym środowisku laboratoryjnym. Nie stosuj go wobec cudzych systemów, sieci ani kont.

Laboratorium 3: Analiza zmiany w firewallu

Cel:

Zrozumieć, jak change management zmniejsza ryzyko.

Kontekst:

Administrator chce dodać regułę firewalla umożliwiającą dostęp z Internetu do aplikacji testowej. Zmiana ma zostać wykonana szybko, bo zespół projektowy czeka na testy.

Kroki:

• Wypisz informacje, które powinny znaleźć się w zgłoszeniu zmiany.
• Określ właściciela zmiany i interesariuszy.
• Wskaż potencjalny wpływ bezpieczeństwa.
• Zaproponuj testy przed wdrożeniem.
• Przygotuj prosty backout plan.
• Wskaż, jaką dokumentację trzeba zaktualizować.

Oczekiwany rezultat:

Krótki plan change management dla reguły firewalla.

Kryteria zaliczenia:

• Uwzględniono approval process.
• Uwzględniono impact analysis.
• Uwzględniono maintenance window.
• Uwzględniono backout plan.
• Uwzględniono aktualizację dokumentacji.

To ćwiczenie wykonuj wyłącznie w legalnym, kontrolowanym środowisku laboratoryjnym. Nie stosuj go wobec cudzych systemów, sieci ani kont.

Mini-test

Pytanie 1

Która kontrola najlepiej pasuje do typu detective?

A. MFA blokujące logowanie bez drugiego składnika

B. SIEM generujący alert po nietypowym logowaniu

C. Backup używany do odtworzenia danych

D. Polityka nakazująca zgłaszanie incydentów

Poprawna odpowiedź:

B

Wyjaśnienie:

SIEM wykrywa podejrzane zdarzenia i generuje alerty, więc pełni funkcję detective.

Dlaczego pozostałe odpowiedzi są gorsze:

• A: To głównie preventive.
• C: To głównie corrective.
• D: To directive lub managerial/operational, zależnie od ujęcia.
• Pytanie 2

Atakujący zmienił dane przelewu, ale nie ujawnił danych i nie wyłączył systemu. Który element CIA został naruszony?

A. Confidentiality

B. Integrity

C. Availability

D. Accounting

Poprawna odpowiedź:

B

Wyjaśnienie:

Problemem jest nieautoryzowana zmiana danych, czyli naruszenie integralności.

Dlaczego pozostałe odpowiedzi są gorsze:

• A: Nie doszło do ujawnienia danych.
• C: System nadal działa.
• D: Accounting należy do AAA, nie CIA.
• Pytanie 3

Użytkownik zalogował się poprawnie, ale nie może otworzyć folderu. Co najprawdopodobniej zawiodło?

A. Authentication

B. Authorization

C. Hashing

D. Availability

Poprawna odpowiedź:

B

Wyjaśnienie:

Logowanie potwierdziło tożsamość. Problem dotyczy uprawnień do zasobu.

Dlaczego pozostałe odpowiedzi są gorsze:

• A: Authentication prawdopodobnie zadziałało.
• C: Hashing nie dotyczy dostępu do folderu.
• D: Folder może być dostępny, ale nie dla tego użytkownika.
• Pytanie 4

Firma nie może wdrożyć MFA w starszym systemie, ale ogranicza dostęp przez VPN, segmentację i dodatkowy monitoring. Jaki typ kontroli najlepiej opisuje te działania?

A. Compensating

B. Corrective

C. Deterrent

D. Physical

Poprawna odpowiedź:

A

Wyjaśnienie:

Kontrola compensating zastępuje lub uzupełnia kontrolę, której nie można wdrożyć bezpośrednio.

Dlaczego pozostałe odpowiedzi są gorsze:

• B: Corrective naprawia skutki zdarzenia.
• C: Deterrent odstrasza.
• D: Physical dotyczy fizycznej ochrony.
• Pytanie 5

Który mechanizm najlepiej zapewnia non-repudiation?

A. Szyfrowanie symetryczne

B. Podpis cyfrowy

C. Data masking

D. Backup

Poprawna odpowiedź:

B

Wyjaśnienie:

Podpis cyfrowy może potwierdzić autora i integralność danych, wspierając niezaprzeczalność.

Dlaczego pozostałe odpowiedzi są gorsze:

• A: Chroni poufność, ale nie zapewnia niezaprzeczalności.
• C: Ukrywa część danych.
• D: Pomaga w odtwarzaniu.
• Pytanie 6

Co najlepiej opisuje Zero Trust?

A. Pełne zaufanie do użytkowników w sieci firmowej

B. Model ciągłej weryfikacji dostępu bez domyślnego zaufania

C. Produkt do szyfrowania dysku

D. Procedura tworzenia kopii zapasowych

Poprawna odpowiedź:

B

Wyjaśnienie:

Zero Trust zakłada brak domyślnego zaufania i ocenę dostępu na podstawie polityki, tożsamości, kontekstu i ryzyka.

Dlaczego pozostałe odpowiedzi są gorsze:

• A: To przeciwieństwo Zero Trust.
• C: To pojedyncza technologia, nie model.
• D: To backup, nie Zero Trust.
• Pytanie 7

Co jest najważniejszym elementem change management, gdy zmiana może spowodować awarię?

A. Brak dokumentacji, żeby było szybciej

B. Backout plan

C. Wyłączenie logowania

D. Użycie self-signed certificate

Poprawna odpowiedź:

B

Wyjaśnienie:

Backout plan pozwala wycofać zmianę, jeśli wdrożenie spowoduje problem.

Dlaczego pozostałe odpowiedzi są gorsze:

• A: Brak dokumentacji zwiększa ryzyko.
• C: Nie jest standardowym elementem każdej zmiany.
• D: Nie dotyczy wycofania zmiany.
• Pytanie 8

Który mechanizm jest najlepszy do bezpiecznego przechowywania haseł?

A. Szyfrowanie odwracalne

B. Hashing z saltingiem i key stretching

C. Data masking

D. Steganography

Poprawna odpowiedź:

B

Wyjaśnienie:

Hasła powinny być przechowywane jako trudne do odwrócenia skróty z losową solą i spowolnieniem zgadywania.

Dlaczego pozostałe odpowiedzi są gorsze:

• A: Możliwość odszyfrowania haseł zwiększa ryzyko.
• C: Maskowanie nie jest właściwym sposobem przechowywania haseł.
• D: Steganografia ukrywa dane w nośniku, ale nie rozwiązuje problemu haseł.
• Pytanie 9

Użytkownicy widzą ostrzeżenie, że certyfikat strony nie jest zaufany. Certyfikat został wystawiony przez sam serwer. Co to oznacza?

A. Certyfikat jest self-signed

B. Certyfikat jest zawsze bardziej bezpieczny

C. Certyfikat jest CRL

D. Certyfikat jest hashem hasła

Poprawna odpowiedź:

A

Wyjaśnienie:

Self-signed certificate nie jest podpisany przez zaufane CA, więc przeglądarka może go nie ufać.

Dlaczego pozostałe odpowiedzi są gorsze:

• B: Brak zaufanego podpisu nie oznacza większego bezpieczeństwa.
• C: CRL to lista unieważnień.
• D: Certyfikat nie jest hashem hasła.
• Pytanie 10

Firma chce wykryć nieuprawnione otwieranie fałszywego pliku z nazwą „passwords.xlsx”. Które rozwiązanie najlepiej pasuje?

A. Honeypot

B. Honeyfile

C. CRL

D. Full-disk encryption

Poprawna odpowiedź:

B

Wyjaśnienie:

Honeyfile to plik-pułapka, którego użycie może wskazywać podejrzaną aktywność.

Dlaczego pozostałe odpowiedzi są gorsze:

• A: Honeypot to fałszywy system lub usługa, nie konkretny plik.
• C: CRL dotyczy certyfikatów.
• D: Full-disk encryption chroni dane na dysku, ale nie wykrywa otwarcia wabika.
• Fiszki

Obrazy do wygenerowania

IMG_M01_S01_SECURITY_CONTROL_MATRIX

Miejsce w materiale:

Sekcja „Wprowadzenie”, po wyjaśnieniu roli kontroli bezpieczeństwa.

Cel obrazu:

Pokazać różnicę między kategoriami kontroli i funkcjami kontroli.

Opis obrazu do wygenerowania:

Czytelna macierz 4 × 6. W wierszach: technical, managerial, operational, physical. W kolumnach: preventive, deterrent, detective, corrective, compensating, directive. W wybranych komórkach krótkie przykłady: MFA, policy, training, camera, backup, SIEM, access badge, backout plan. Dodaj legendę: „kategoria = obszar kontroli”, „funkcja = sposób działania kontroli”.

Styl:

Infografika techniczna / tabela wizualna.

Elementy obowiązkowe:

• cztery kategorie kontroli
• sześć funkcji kontroli
• krótkie przykłady
• czytelna legenda.

Elementy, których unikać:

• zbyt dużo tekstu
• ikony bez znaczenia
• losowe symbole cyberataków
• małe nieczytelne napisy.
• IMG_M01_S02_ZERO_TRUST_FLOW

Miejsce w materiale:

Sekcja „Zero Trust”, po definicji i przykładzie praktycznym.

Cel obrazu:

Wyjaśnić przepływ decyzji dostępu w modelu Zero Trust.

Opis obrazu do wygenerowania:

Diagram przepływu: subject/user/system → żądanie dostępu → sprawdzenie identity, device posture, location, risk, resource sensitivity → policy engine → policy administrator → policy enforcement point → allow / deny / step-up authentication / limited access. Dodaj krótką zasadę u góry: „Never trust by default, continuously verify”.

Styl:

Schemat blokowy techniczny.

Elementy obowiązkowe:

• subject/user/system
• identity
• device posture
• risk/context
• policy engine
• policy administrator
• policy enforcement point
• decyzje allow/deny/step-up.

Elementy, których unikać:

• przedstawianie Zero Trust jako jednego produktu
• nadmiar tekstu
• skomplikowana architektura chmurowa bez potrzeby.
• IMG_M01_S03_CHANGE_MANAGEMENT_FLOW

Miejsce w materiale:

Sekcja „Change management”, po opisie krok po kroku.

Cel obrazu:

Pokazać pełny proces kontrolowanej zmiany.

Opis obrazu do wygenerowania:

Diagram procesu: request → owner → stakeholders → impact analysis → testing → approval → maintenance window → implementation → validation → documentation update → version control. Dodaj boczną ścieżkę „backout plan” od implementation do rollback.

Styl:

Schemat blokowy / proces operacyjny.

Elementy obowiązkowe:

• request
• approval
• impact analysis
• test results
• backout plan
• maintenance window
• documentation
• version control.

Elementy, których unikać:

• ozdobniki
• nieczytelne strzałki
• pomijanie backout plan.
• IMG_M01_S04_CRYPTO_DECISION_MAP

Miejsce w materiale:

Sekcja „PKI i certyfikaty”, po omówieniu mechanizmów kryptograficznych.

Cel obrazu:

Pomóc dobrać mechanizm kryptograficzny do celu.

Opis obrazu do wygenerowania:

Mapa decyzyjna z pytaniami: „Czy chcesz ukryć dane?” → encryption. „Czy chcesz sprawdzić, czy dane się zmieniły?” → hashing. „Czy chodzi o hasła?” → salted hash + key stretching. „Czy chcesz potwierdzić autora?” → digital signature. „Czy chcesz powiązać klucz publiczny z tożsamością?” → certificate/PKI. „Czy chcesz ukryć część danych w interfejsie?” → data masking. „Czy chcesz zastąpić dane tokenem?” → tokenization.

Styl:

Algorytm decyzyjny / diagram edukacyjny.

Elementy obowiązkowe:

• encryption
• hashing
• salting
• key stretching
• digital signature
• certificate/PKI
• tokenization
• data masking.

Elementy, których unikać:

• wzory matematyczne
• szczegółowe nazwy algorytmów bez kontekstu
• skomplikowane ikony.
• Pokrycie wymagań egzaminacyjnych

Co warto powtórzyć przed przejściem dalej

Różnica między kategorią a funkcją kontroli.

CIA i przykłady naruszeń każdego elementu.

AAA, szczególnie authentication vs authorization.

Encryption vs hashing vs digital signature.

Rola PKI, CA, CRL i OCSP.

Elementy change management.

Zero Trust jako model, nie produkt.

Kontrola kompletności modułu

Zakres z konspektu pokryty:

• typy i kategorie kontroli bezpieczeństwa
• CIA
• AAA
• non-repudiation
• Zero Trust
• bezpieczeństwo fizyczne
• deception and disruption technology
• change management
• kryptografia, PKI, certyfikaty, hashing, salting, podpis cyfrowy, tokenizacja i maskowanie
• przykłady, ćwiczenia, mini-test, fiszki i obrazy.

Zakres wymagający pogłębienia:

• szczegółowe algorytmy kryptograficzne będą potrzebne tylko na poziomie rozpoznawania zastosowań, nie matematyki.
• IAM zostanie rozwinięte mocniej w module Security Operations I.
• Certificate management wróci przy architekturze i operacjach.
• Szczegółowe mechanizmy logowania i detekcji wrócą w Security Operations II.

Najważniejsze rzeczy do zapamiętania:

• Kontrolę klasyfikuj według kategorii i funkcji.
• CIA opisuje cele ochrony danych i systemów.
• AAA opisuje tożsamość, uprawnienia i rozliczalność.
• Zero Trust oznacza brak domyślnego zaufania.
• Change management zmniejsza ryzyko błędnych zmian.
• Szyfrowanie, hashing i podpis cyfrowy rozwiązują różne problemy.
• PKI służy do zarządzania zaufaniem do kluczy i certyfikatów.

Czy materiał wystarcza do opanowania tej części:

Tak, jako pełne wprowadzenie do domeny 1.0 General Security Concepts na poziomie od zera do egzaminacyjnego.

Potencjalne luki:

• Warto później zrobić dodatkową sesję z pytaniami tylko o kryptografię, bo to obszar często mylony.
• Warto wrócić do kontroli bezpieczeństwa po module 2, gdy pojawią się konkretne zagrożenia i mitygacje.

Rekomendowana powtórka:

• Rozwiąż mini-test bez patrzenia w odpowiedzi.
• Przerób fiszki.
• Wykonaj laboratorium 1 i 2.
• Samodzielnie napisz po jednym przykładzie dla każdego typu kontroli.
• Kontrola głębokości wyjaśnień
• Ważne pojęcia zostały rozwinięte, a nie tylko wymienione.
• Przy każdym kluczowym pojęciu pokazano problem, mechanizm, przykład praktyczny, pułapki i definicję.
• Dodano scenariusze egzaminacyjne.
• Dodano checklistę, pytania kontrolne, odpowiedzi, laboratoria, fiszki i opisy obrazów.
• Materiał jest zgodny ze strukturą generowania właściwego modułu: wyjaśnienia, przykłady, ćwiczenia, mini-test, fiszki i kontrola kompletności.