arrow_backWróć do field notes
CAREER CHANGE Opublikowano 19 lip 2026

Security Analyst vs Security Engineer: Jaki jest rzeczywisty podział?

Praktyczne wyjaśnienie, czym różnią się role analityka bezpieczeństwa i inżyniera bezpieczeństwa w pracy codziennej, umiejętnościach i ścieżkach kariery.

Te stanowiska są używane zamiennie w ogłoszeniach o pracę, ale praca na co dzień jest naprawdę inna. Jeśli wybierasz kierunek do nauki, zrozumienie podziału zaoszczędzi ci miesięcy zmarnowanego czasu na certyfikaty i umiejętności, które się nie sprawdzą.

Co analityk robi przez cały dzień

Analityk bezpieczeństwa spędza większość czasu obserwując, triage'ując i śledząc zagrożenia. To oznacza patrzenie na SIEM (Splunk, Sentinel, QRadar), pracę z kolejkami alertów i decyzję, czy flagowany proces na stacji roboczej to fałszywy alarm, czy początek incydentu. Dużą część pracy stanowi pisanie raportu z ustaleń na tyle jasno, że menadżer lub klient bez wiedzy o bezpieczeństwie zrozumie, co się stało.

Analytycy Tier 1 robią triage. Analytycy Tier 2/3 głębiej — wyciągają process trees, sprawdzają telemetrię EDR w czymś takim jak CrowdStrike czy Defender for Endpoint, korelują logi w firewall'ach i identity providerach, aby zbudować oś czasu. Praca ma charakter reaktywny: coś się dzieje, ustalasz, co to oznacza i co z tym zrobić.

Typowa lista zadań analityka: przejrzenie alertów z nocy, zamknięcie fałszywych alarmów z udokumentowanym uzasadnieniem, eskalacja podejrzanego wykonania PowerShell, aktualizacja runbooka po nowym wzorcu phishingu oraz udział w call'u incydentu. To praca śledcza i wymagająca komunikacji.

Co inżynier naprawdę buduje

Inżynier bezpieczeństwa buduje i utrzymuje systemy, na których polega analityk. To pisanie reguł detekcji w Sigma lub KQL, strojenie SIEM, aby nie zalewał kolejki szumem, wdrażanie i konfiguracja agentów EDR na 5000 endpointów, lub automatyzacja playbooку phishingu w platformie SOAR, takiej jak Tines czy Cortex XSOAR.

Inżynierowie pracują także przed incydentami: utwardzanie konfiguracji cloud'u w AWS czy Azure, konfiguracja segmentacji sieci, pisanie Terraform do wymuszania reguł security group, łatanie CI/CD pipeline'ów, aby sekrety nie przeciekały do git history. Wiele pracy inżynierskiej jest niewidoczne, dopóki się nie psuje — nikt nie zwróci uwagi na dobrze skonfigurowaną regułę WAF, ale wszyscy zwrócą, gdy jej brakuje.

Gdy analityk pyta „co się tu stało,

Napisane z pomocą AI, zweryfikowane i opublikowane przez Michal Pilch (CISSP), Korra Studio.

Gotowy na więcej?

To jedna notatka z bazy wiedzy Korra Studio — platforma łączy każdy temat z mentoringiem 1 na 1.

Zacznij za darmoarrow_forward