W tym odcinku podcastu gościmy Katarzynę Brzozowską, Inżyniera DevSecOps, która dzieli się swoją inspirującą historią przebranżowienia się do IT. Kariera DevSecOps jest dostępna dla każdego! Kasia opowiada o drodze od pracy w Biurze Obsługi Klienta, przez backend development i administrację Linuxa, aż po osiągnięcie roli specjalisty DevSecOps. Podkreśla kluczowe znaczenie doświadczenia programistycznego lub administracyjnego, szczególnie z Linuxem, dla efektywnego działania w tej dziedzinie, choć zaznacza, że bezpośrednie wejście w tę rolę po studiach jest znacznie trudniejsze. Rozmowa dotyczy również roli narzędzi do monitoringu, takich jak Elastic Stack, Prometheus i Grafana, jako doskonałego punktu wyjścia do kariery w DevOps i cyberbezpieczeństwie.
W rozmowie m.in.:
- Automatyzacja Bezpieczeństwa w CI/CD: Kasia przedstawia praktyczne podejście do automatyzacji, obejmujące statyczną analizę kodu (SAST) z SonarCube, analizę zależności (SCA) za pomocą Snyk i Trivy, a także skanowanie obrazów Docker i klastrów Kubernetes. Podkreśla znaczenie czytelnych dashboardów (np. w Grafanie) dla deweloperów, pomagających priorytetyzować podatności.
- Waga Monitoringu i Narzędzi: Rozmowa eksponuje znaczenie Elastic Stack, Prometheus i Grafana jako fundamentalnych narzędzi do monitoringu, stanowiących solidny punkt wyjścia dla aspirujących specjalistów w DevOps i cyberbezpieczeństwie.
- Rozwój Kompetencji i Mentoring: Podkreślana jest rola mentoringu (np. w inicjatywach Django Girls, Girls Code Fun) oraz platform edukacyjnych, takich jak TryHackMe i Hack The Box, w budowaniu i rozwijaniu umiejętności w obszarze cyberbezpieczeństwa. Ten odcinek to skarbnica wiedzy dla operacyjnych specjalistów IT/Security oraz Team Leadów, którzy chcą efektywnie wdrażać DevSecOps i rozwijać swoje kompetencje.
Odcinek dostępny na YouTube, Spotify, Apple Podcasts i innych platformach.
Transkrypcja
Krzysztof: Witamy. Nasz kolejny gość, Katarzyna Brzozowska. Kasiu, bardzo serdecznie. jeszcze raz chciałbym cię powitać. Dzięki, że znalazłaś czas i chwilę, żeby nas tutaj odwiedzić w Poznaniu, w studiu.
Kasia: Cześć. Ja dziękuję za zaproszenie.
Krzysztof: Przeglądając Twój profil widzę, że doświadczenia w różnych dziedzinach związanych z IT Ci nie brakuje. Widziałem tutaj nawet jakiś mały romans z pracą, czy to bardziej wolontariatem w kierunku backenda. Widzę tutaj wskoczenie w kwestie związane z bezpieczeństwem w APSEC, SysOps, DevOps. Gdzieś też po drodze pojawia się Cloud. No właśnie, Kasiu, jak to jest? Może ty najlepiej opowiesz naszym słuchaczom czym obecnie się zajmujesz i jaki jest twój background.
Kasia: Ja generalnie jestem osobą, która się przebranżowiła. Nie miałam żadnych studiów stricte informatycznych, ale zawsze mnie do tego ciągnęło. Wcześniej pracowałam w Biurze Obsługi Klienta. No ale jednak jako introwertyk, powiem szczerze, rozmowy telefoniczne i odpisywanie na maile, może to niekoniecznie było coś, co mnie pasjonowało i szukałam czegoś nowego. No i tak zaczęła się ta przygoda z IT właśnie od tego co wspomniałeś, czyli przygody z backendem. Zaczynałam w ramach wolontariatu jako taka osoba, która robi jakieś małe funkcjonalności w Pythonie. No i później gdzieś po tych małych projektach przerodziło się to w kolejną pracę już taką na full etat i to była praca administratora, linux administrator, no i tam zapoznałam się po raz pierwszy z Cloudem, krótki epizod miałam z AWS-em, natomiast tam też poznałam osobę, która wkręciła mnie w kolejną firmę i tam zaczynałam jako junior SysOps. No i tam tak naprawdę zaczęłam tak mocno poznawać wszystkie rzeczy związane gdzieś tam z zabezpieczaniem infrastruktury, ze stawianiem tej infrastruktury. Jako, że to była mała firma stosunkowo, To wiadomo jak to w takich firmach bywa, dużo się tam robi. Niekoniecznie to, że jest się nazwanym sysopsem znaczy, że robi się tylko stricte sysopsowe rzeczy. Także i trochę sieci, trochę Kubernetesa było, CICD, Ansibla, no i trochę właśnie bezpieczeństwa. Także wszystko po trochu, no i gdzieś z tego sysopsa naturalną koleją rzeczy było przejście na DevOpsa, bo gdy zajmujesz się stawianiem infrastruktury, tam zresztą już zajmowałem się GCP, jeżeli chodzi o cloud, no to siłą rzeczy wkraczając w CICD, w Kubernetesa gdzieś prowadzić ta droga w kierunku DevOpsa. Także to był dosyć naturalny proces u mnie. No i później skończyła się współpraca z tą firmą, zbankrutowała i znalazłam nową pracę jako DevSecOps Inżynier. No i tutaj aktualnie pracuję cały czas na tym stanowisku, zajmuję się stricte narzędziami do analizy bezpieczeństwa, także mam bardzo wąską działkę, ale wiadomo, żeby te narzędzia mogły funkcjonować to i robi się trochę w Kubernetesie i trochę w CICD, jest trochę programowania w Pythonie, w Groovim, jest trochę administrowania na Linuxie. Także nadal nadal jest szeroko, że tak powiem.
Krzysztof: Patrząc na tą twoją podróż można powiedzieć, że takim naturalnym krokiem dla ciebie gdzieś było wskoczenie w to to security. Ono nie nastąpiło nagle, tylko to było w pewnym sensie rozwój twoich kompetencji wynikających właśnie z DevOps i z SysOps, więc masz Masz tych punktów spojrzeń, również gdzieś tam taki mały ten epizod z developmentem. Powiedz mi, czy uważasz, że da się tak wskoczyć w DevSecOps-a tak bezpośrednio, czy jednak to zaplecze w postaci takiego doświadczenia, czy to programistycznego, czy administratorki jest jednak tutaj wskazane?
Kasia: To jest pytanie, które wiele osób sobie zadaje. W mojej perspektywie myślę, że zdecydowanie najlepiej zacząć od dobrego poznania albo zawodu programisty, albo zawodu administratora. Najlepiej Żeby to był Linux, bo jednak większość tych narzędzi ma dużo wspólnego z Linuxem i jeżeli chodzi o Windowsa, to on oczywiście też się przydaje, ale ja na przykład w swojej karierze nigdy nie miałam potrzeby, żeby robić cokolwiek na Windowsie. Zależy do jakiej branży tak naprawdę się uderza, bo przykładowo w bankowości często spotyka się właśnie ten wymóg Windowsa. Także dobrze zacząć jako administrator myślę, bo w pracy DevOpsa jest bardzo dużo zadań, które odnoszą się do stawiania jakiejś infrastruktury, jakiegoś narzędzia. Trzeba wiele pracy samodzielnie wykonywać korzystając z Kubernetesa, z Dockerów. czy też w cloudzie. Także myślę, że najlepiej jako administrator, ale też programiści mają dosyć fajną ścieżkę i mogą przeskoczyć następnie właśnie w kierunku DevOpsa. Głównie dlatego, że Programiści, nieważne jaki język też znają, każdy jeden dobrze poznany język otwiera nam drzwi do tego, żeby dużo szybciej nauczyć się kolejnych. Więc na przykład programiści Java świetnie poradzą sobie z Groovym, który jest językiem, w którym tworzy się pipelines pod np. Jenkinsa. Też programiści do stworzenia gdzieś tam swojego środowiska, do pracy, korzystają z Dockera, też deployują wiele rzeczy samodzielnie. często, także mają gdzieś, zdobywają te doświadczenie, jeżeli chodzi o Jenkinsa, czy tam jakieś inne SEACD, też jak funkcjonuje Kubernetes, które się z tym zapoznają, więc myślę, że to jest fajna, naturalna ścieżka. ale znam osoby osobiście, które zaczynały od stanowiska junior devopsa od razu po studiach, nie mając jakiegoś większego doświadczenia. natomiast wydaje mi się, że jest po prostu ciężej. wtedy także wiadomo, wszyscy chcą gdzieś szybko, szybko ale tak samo jak osoby, które chcą się dostać w ogóle do cyberbezpieczeństwa często chcą od razu wskoczyć do cyberbezpieczeństwa. Nie mówię, że to jest niewykonalne, bo oczywiście jest. Można zaczynać od soka czy gdzieś na jakiś entry level stanowiska, natomiast Ktoś kto już w tym siedzi ma świadomość, że żeby wiedzieć jak coś złamać albo jak coś zabezpieczyć to trzeba bardzo dobrze rozumieć jak to działa. Dlatego jeżeli chcemy zabezpieczać infrastrukturę, żeby się do niej wyłamywać musimy wiedzieć jak one funkcjonują, jak są zbudowane i gdzie są jakieś luki. Tak samo, jeżeli chcemy specjalizować się w webowych, np. w pentestach, webowych aplikacji, no musimy wiedzieć, jak wygląda praca programisty, gdzie często programiści popełniają te błędy, więc gdzie jest możliwość, żeby gdzieś znaleźć tą lukę. Także myślę, że to dotyczy w większości stanowisk IT, takich kompleksowych, gdzie jest jednak wymagana znajomość Wielu rzeczy naraz, bo to dotyczy DevOps-a i tak samo to dotyczy cyberbezpieczeństwa, że tam trzeba naprawdę wiele narzędzi poznać.
Andrzej: Mi się bardzo podoba to, co powiedziałaś właśnie w ujęciu wskakiwania do cyberbezpieczeństwa, że oczywiście to nie jest niewykonalne, da się wskoczyć, da się zacząć też od bycia junior DevOps-em. Tylko po prostu jest trudniej i dużo łatwiej jest przejść do tej roli już będąc w IT, w jakiejś innej roli, przykładowo programisty czy administratora, czy nawet IT support technician, jeżeli myślimy o przejściu do SOC-a, a potem pięciu się w tej drabince, po prostu będzie łatwiej, tą drogę łatwiej przejść. A jeżeli coś łatwiej zrobić, to prawdopodobieństwo sukcesu po prostu rośnie. Więc nie jest tak, że się nie da, tylko jest trudniej, a jak jest trudniej, to niestety, ale szanse są przeciwko nam.
Kasia: Tak, jeszcze chciałabym dodać, bo tak mi przyszło teraz do głowy, że nie wspomina się o tym często, ale na przykład fajnie jest zacząć od takiej ścieżki specjalistów monitoringu, bo zarówno jeżeli chodzi o cyberbezpieczeństwo, jak i o dewopsowanie, no to Bardzo często jako wymaganie pojawia się znajomość narzędzi do monitoringu, a specjaliści od Elastik Staka, który jest ogromny, czy właśnie Prometeusz z Grafaną, czy jakieś inne rozwiązania są bardzo cenie. Te osoby też świetnie sobie dalej poradzą na stanowisku DevOps. Myślę, oczywiście będą dodawać jakieś kolejne umiejętności do tego monitorowania. W cyberbezpieczeństwie monitoring to jest tak naprawdę jedna z ważniejszych rzeczy. Także to może być też jeden z takich fajnych kierunków na start.
Krzysztof: Nasze oczy.
Kasia: Tak, tak, tak.
Andrzej: Po prostu daje visibility i w DevSecOps też dużą częścią jest spojrzenie na to co działa i jak działa. I jeżeli mówimy o bezpieczeństwie wypotoku i bezpieczeństwie samego potoku. To jedno i drugie.
Krzysztof: Tak, dokładnie. A powiedz mi, Kasiu, teraz pracując jako DevSecOps, gdybyś miała taki greenfieldowy, czysty projekt, w którym masz dowolność wdrożenia jakiejś praktyki bezpieczeństwa, właśnie powiedzmy w zakresie automatyzacji pewnych rzeczy z bezpieczeństwa, to co byś w taki pipeline jako pierwsze cisnęła, mówiąc kolokwialnie?
Kasia: No więc mamy jakby takie trzy zakresy. Po pierwsze to jest white box testing, jeżeli chodzi o tego typu analizy, no to myślę, że tutaj Jednym z narzędzi, które jest szeroko stosowane, dosyć popularne jest to np. SonarCube. To nie jest stricte takie narzędzie security, ale to jest narzędzie, które analizuje nam code quality, code sms, tego typu rzeczy, plus dodatkowo analizuje też nam kod pod względem tego, czy są tam jakieś podatności. Także myślę, że to by było pierwsze, co bym wrzuciła w pipeline, jeżeli chodzi stricte o DevSecOps. I kolejny krok to jest zawsze też analiza podatności w ramach dependencji, czyli tych Zależności. Zależności, tak. No i tutaj jest kilka narzędzi. Ja osobiście korzystam ze Snyka bądź Snajka. Różnie wygadają.
Andrzej: O, Snajk to Snajk.
Krzysztof: Pierwszy raz słyszę, ale…
Kasia: Snajk. Także to jest fajne narzędzie. Bardzo świetnie się sprawdza jeżeli chodzi o analizę zależności. Ma fajne funkcjonalności, na przykład automatyczne wystawianie pull requestów. Ładny dashboard, więc to jest coś co w łatwy sposób może dotrzeć do deweloperów, żeby nie musieli długo szukać. Jest to fajne narzędzie, tak samo z Sonar Cube też ma ten dashboard. Aczkolwiek tam muszę przyznać, ta strona wizualna nie jest może dopracowana, na pewno nie tak jak w Snyku. Ale te dwa narzędzia fajnie współgrają, gdzieś tam się uzupełniają. Taki trzeci, właściwie jeszcze jeden krok bym dodała, bo tu mówimy stricte o, na przykład mamy aplikację w Bitbuckecie, no i tam analizujemy ten kod, później te dependencji, no ale Później na przykład deployujemy tą aplikację na Kubernetesa, wykorzystujemy dockery. No i tutaj przydaje się jakieś narzędzie do analizy też tego bezpieczeństwa w ramach kubernetesowych klastrów, ale też bezpieczeństwa w samych tych imidżach, które tworzymy w docker file. I tutaj porównywałam kilka narzędzi. Robiłam taką analizę. Jest ich trochę na rynku, natomiast takie, które najczęściej chyba się pojawiają, no to jest m.in. też Snygg. Natomiast to jest płatne narzędzie. Także jeżeli chodzi o darmowe narzędzie, najlepiej jednak sprawdziło mi się Trivi. Też analizowałam Gripe. Albo grypę. Też, nie wiem jak się mówi. I Docker Scout. Natomiast Skupiłam się na Trivi, bo Trivi jest rozwiązaniem darmowym, bardzo łatwo jest je zdeployować, korzystamy z handchartów, także jest to dosyć proste i też mają bardzo fajną integrację z monitorowaniem, z wykorzystaniem Prometeusza Grafany. i mimo, że Trivi nie daje nam dashboardu, tak jak Snyk, to daje nam możliwość, żebyśmy sobie fajne dashboardy zrobili w grafanie. Ja coś takiego robiłam i to super wygląda. Także, mimo że jest darmowe, no to wiadomo, trochę więcej trzeba włożyć w to pracy, ale dobrze się sprawdza. Także to jeżeli chodzi o taką analizę środowisk takich jak Kubernetes czy Docker. No i ostatnia kwestia to takie blackbox testing. No to tutaj OWASP Zap albo Barbsuit też. Natomiast jeżeli chodzi o mnie, ja tutaj nie wdrażałam tego typu rozwiązań. Ja skupiałam się na tych pierwszych trzech, które omawiałam.
Andrzej: Jasne. To ja w takim wypadku mam jedno pytanie. Bo wspomniałaś o SonarCube, o czymś do dependencji, na przykład Snyku czy Trivi, ale mówiłaś o jakichś dashboardach, gdzie to agregujesz, czyli w zasadzie dobrze byłoby mieć jakiś dashboard, że jest to jakaś tam ważna część tej układanki, no bo samo narzędzie, na które jednak nie mogę spojrzeć, no nie za bardzo mi daje informacje, tak?
Kasia: No tak, bo wyobraźmy sobie, że deweloperzy deployują na przykład z Jenkinsa aplikację na Kubernetesa. No oczywiście, ja mogę wejść na Kubernetesa, gdzie mam zdeployowane te triwi operatora, który jedną komendą mogę sobie wylistować, co w danym namespace jest podatne. Natomiast oczywiście nie chcemy dawać dostępu deweloperom do wszystkich klastrów i nie ma takiej potrzeby. Zresztą Oni też nie muszą się na tym znać. My jesteśmy po to, żeby skonfigurować wszystko w taki sposób, żeby to było dla nich łatwe do użycia i widoczne od razu, co jest do zrobienia. No i też jeżeli chodzi w ogóle o analizę kontenerów, to zazwyczaj gdy ją się wdraża, to pojawia się cała masa podatności. Jest naprawdę tego ogromna ilość. Nie jesteśmy w stanie w ogóle naprawić tego wszystkiego. Dlatego ważne jest, żeby gdzieś te dashboardy tak skonfigurować, żeby też deweloper widział, nie wiem, na czerwono, że to jest po prostu ważne, że tutaj coś jest niezgodne z compliance, na przykład Trivi ma fajne analizy pod względem compliance z na przykład CIS Benchmark. My też po to jesteśmy, my jesteśmy takim wsparciem dla deweloperów, dla nich to wszystko robimy, żeby ta ich praca była łatwiejsza.
Andrzej: Mi się bardzo podoba to, co mówisz, bo ja mam dokładnie takie samo spojrzenie. Jako bezpieczeństwo jesteśmy po to, żeby pomagać deweloperom i ułatwiać ich pracę na tyle, na ile się da, bo wszyscy gramy do jednej bramki. To nie jest tak, że my jesteśmy kontra deweloperzy, czyli my bezpiecznicy kontra Devsi. My wszyscy jesteśmy w procesie, chcemy wytworzyć aplikacje jak najbezpieczniejsze i gramy do jednej bramki, a to nie jest kopanie się i przerzucanie problemami.
Krzysztof: Dokładnie, pomóc dostarczać im szybciej i też budować taki pozytywny developer experience, a nie stać jako bloker z pałką i ich tam mucić. Ja tylko jeszcze w kontekście Triviego powiem, że Trivi ma wiele zastosowań z takim scyzorykiem troszeczkę w kontekście bezpieczeństwa. I bardzo fajnie rezonuje ze mną to, co Kasiu powiedziałaś na temat budowania dashboardów, które mają znaczenie. Nie takich vanity dashboardów, które po prostu krzyczą na czerwono, że o, w tym obrazie jest 5 tysięcy podatności. I taki deweloper wchodząc na taki dashboard mówi nie, pierdziele.
Kasia: Nie dzisiaj, nie ma na to czasu. Właśnie to jest też jeden z problemów, że deweloperzy no nie mają, nie mają czasu na jakby w sprincie, na naprawienie jakichś podatności. To jest zazwyczaj coś, co jest daleko, daleko na końcu, głównie dlatego, że biznes nie rozpatruje naprawy takich błędów jako coś, co przynosi zysk, więc ważniejszy jest nowy feature czy poprawienie czegoś tam w aplikacji niż załatanie podatności.
Andrzej: Tak, tak, tak. To jest znana śpiewka. Bezpieczeństwo jest kosztem i nie generuje bezpośrednio zysków.
Krzysztof: Więc wracając właśnie do tego, jak udaje ci się, Kasiu, budować dashboardy, które mają znaczenie? Czy masz jakąś taką strategię, taktykę?
Andrzej: Na co zwracasz uwagę?
Kasia: To znaczy, jedyny dashboard, bo tak naprawdę w Snyku mamy by default dashboardy, one są zaprojektowane już przez deweloperów Snyka, jeżeli chodzi o Trivi, no to w Grafanie tak naprawdę Dashboardy kreuję w taki sposób, na co jest zapotrzebowanie w danym momencie, więc gdzieś tam robię ogólny pogląd tego, ile mam podatności jeżeli chodzi per konkretny image, ale też są tam odnośniki np. do CV, żeby można było sobie zobaczyć konkretnie. No bo niestety właśnie jeżeli chodzi o triwi musimy to wszystko zrobić jednak samemu w grafanie. Ale generalnie myślę, że ja jednak wrzucam te informacje jakie mam i staram się gdzieś kolorystycznie zaznaczać co jest najbardziej krytyczne do rozwiązania.
Andrzej: Tak, żeby szybko można było to zidentyfikować po wejściu.
Kasia: Tak, tak. Myślę, że nie mam tutaj jakiegoś takiego konkretnego podejścia, tak naprawdę wszystko zależy od tego jakie jest zapotrzebowanie i wtedy po prostu dostosowuję to.
Andrzej: A z tych dashboardów też mogą korzystać oczywiście deweloperzy, to jest tak, że mają do tego dostęp?
Kasia: Tak, jeżeli chodzi o dashboardy no to Grafana czy na przykład Kibana to są narzędzia stworzone po to, żeby właśnie można było tam dać dostęp deweloperowi. otrzymamy tam na przykład takie kibanie, deweloper może sobie wejść i przejrzeć logi. Nie musi wchodzić stricte na serwer, nie musi wiedzieć, który to jest serwer, tylko może sobie wpisać query i znaleźć po prostu to, czego potrzebuje. Także to są narzędzia stworzone po to, żeby właśnie, to jest to końcowa aplikacja, w której deweloper może mieć wszystko czarno na białym.
Krzysztof: Co więcej, my możemy mu te predefiniowane query już przygotować, żeby to było ready to use, w chwili kiedy on tego potrzebuje, żeby nie musiał się zastanowić nad tym, co ja teraz muszę tam w tym syntaksie wpisać, żeby to query zadziałało jak najbardziej. Pytam o budowanie tych dashboardów, które mają znaczenie, ponieważ ja wiem, jak ciężka jest to praca, żeby z takich dashboardów wyłuskać te perełki, które są najważniejsze w tym zalewie informacji, które spływają z tych wszystkich skanerów, które powpinał zespół security. Niestety.
Andrzej: Ja teraz trochę obrócę i odejdę od tego tematu, bo wspomniałaś o tym, ale ja też widziałem, że masz doświadczenie mentorskie, czyli mentorowałaś. Jakie masz w tym doświadczenie? W sensie taki odbiór. Podobało ci się to? Jak to wyglądało? Jakieś protipy dla ludzi, którzy chcieliby albo zostać mentorami, no albo chcieliby być mentorowani.
Kasia: Tu mam dosyć bogate doświadczenie. Moje pierwsze doświadczenie było parę lat temu na projekcie dla organizacji Django Girls. To były takie weekendowe warsztaty, gdzie mieliśmy przygotowane tutorial, były poszczególne lekcje i po prostu przerabialiśmy je razem z dziewczynami, które chciały nauczyć się programowania, ale było to o tyle fajnie zrealizowane, że najpierw było prowadzenie jak działa w ogóle wyszukiwarka, później było trochę HTML-a, trochę CSS-a i później wchodzimy w Django, czyli framework Pythonowy, no i tutaj trochę Pythona, trochę tego Django. To bardzo fajnie wyszło i ja w ogóle zaczęłam jako osoba, która brała udział w takich workshopach. I później już opanowałam ten materiał na tyle, że miałam możliwość też mentorować inne dziewczyny. Później długo, długo nic, bo zajmowałam się pracą, zdobywałam doświadczenie i w końcu doszłam do takiego momentu, gdzie stwierdziłam, że teraz już mogę dzielić się większą ilością wiedzy. Wzięłam udział w mentoringu Girls Code Fun. A to było z kolei skierowane stricte do nastolatek. To były młode dziewczyny gdzieś w okolicy 15 lat, które tak naprawdę nie wiedziały nic o tym świecie, ale czują, że chcą wejść w IT. No i to było wyzwanie, bo tak naprawdę one nie wiedziały czego chcą, nie wiedziały nawet za bardzo jakaś ścieżka, więc moją rolą było opracowanie, przyjrzenie się im, co one chciałyby robić, co by do nich pasowało, czy testowanie, czy programowanie, czy może bycie Scrum Masterem, czy analitykiem, jest tego naprawdę szeroka gama? Także mentoring tak wyglądał, że w pierwszej kolejności gdzieś robiliśmy jakieś testy predyspozycji, później opowiadały mi o tym, co one by chciały i ja gdzieś mając to doświadczenie byłam w stanie przyporządkować je do konkretnej roli, która może im się podobać. No i później ruszałyśmy z materiałem. Gdzieś tam, ale to naprawdę bardzo basic, bo to było dosłownie kilka godzin. No co można zrobić w kilka godzin? Głównie podzieliłam się z nimi bazą materiałów, gdzie one mogą dalej to zgłębiać. Także to jest bardzo ważne, żeby w ogóle jak się zaczyna mentoringi, myślę, że fajnie stworzyć sobie na przykład taki workspace na notion. Ja w ogóle jestem fanką notion.
Andrzej: Ja też, ja też. Notion all the way.
Kasia: No i mam tam właśnie taki workspace, mam podzielone działy i tam wrzucam sobie wartościowe materiały, jakieś linki do fajnych tutoriali, czy jakichś darmowych materiałów, czy nawet są darmowe książki czasami, bardzo fajne. I cały czas tak naprawdę na bieżąco, nawet jak nie zajmuję się mentoringiem, to coś mi wpadnie, wrzucam tam. Więc najlepiej zbudować sobie tą bazę, bo to jest coś bardzo, myślę, potrzebnego osobom, które zaczynają w IT, że one nie wiedzą od czego zacząć. I osoba, która jest mentorem musi im pokazać drogę. Bo jest tego taka ilość, szczególnie jeżeli ktoś chce iść w kierunku DevOpsa. No to wtedy i sieci, i trochę testowania, bo nierzadko zdarza się, że jak piszemy kod, to piszemy też test do tego kodu, tak zresztą jak programiści też piszą często testy do swojego kodu. No i trochę tego bezpieczeństwa trzeba znać, i trochę baz danych, i trochę z EICD, i clouda. No to są ogromne tematy, można się pogubić.
Krzysztof: Tak, no to przeciążenie poznawcze z roku na rok w IT jest coraz większe. Teraz dochodzi nam jeszcze machine learning i AI. Kto wie co przyniesie nam przyszłość.
Andrzej: Tak, jest już tylko coraz więcej tego. Ale chyba jeszcze nie skończyłaś.
Kasia: Tak, no i jeżeli chodzi o dziewczyny, to tak naprawdę w tym Gears Code Fun. dążyłam gdzieś tam odpowiedzieć im o podstawach Linuxa. Zawsze kieruję wszystkich na TryHack.me, bo tam jest po prostu świetny. Są fajne challenge’e, ale też jest fajna ścieżka, gdzie jest wprowadzenie w Linuxa. Jest wirtualka, którą można sobie odpalić. Większość ludzi ma Windowsa. jednak i to jest ta blokada, że oni chcą się nauczyć Linuxa, ale nie wiedzą gdzie, jak. Zainstalowanie Virtual Boxa jest czasami dużym wyzwaniem dla osób początkujących, także TryHack mi jest fajnym rozwiązaniem. Bo tutaj można wejść, logujesz się i masz w przeglądarce Virtual Boxa i to jest Kali Linux, więc w ogóle jest tam bardzo dużo fajnych narzędzi by default zainstalowanych. Można fajne rzeczy robić i trenować.
Krzysztof: Tak, tryhack.me to jest game changer, szczególnie na początku. Nie pamiętam jak ja zaczynałem te pięć, sześć lat temu. to kosztowało w granicach dziesięciu, może piętnastu dolarów za miesiąc jeżeli chciało mi się mieć tą wersję premium, bo ta wersja darmowa oczywiście działa.
Kasia: Teraz 60 złotych wychodzi mniej więcej na miesiąc.
Krzysztof: Tak, obiad na mieście dla jednej osoby.
Kasia: Bardzo warto.
Krzysztof: Więc mega, mega warto i szczególnie te learning pathy ułożone pod konkretne tematy, z których można naprawdę wiele wynieść i też otworzyć troszeczkę swoje horyzonty, więc nawet jeżeli ktoś niekoniecznie zaczyna, ale chciałby na przykład troszeczkę jako programista wskoczyć właśnie może w jakiś Blue Team czy Red Team. To jest fajne miejsce, gdzie można sobie tego tematu troszeczkę liznąć.
Kasia: Tak, tu może taki też tip dla osób właśnie zainteresowanych cyberbezpieczeństwem. TryHack.me jest super jako pierwsza platforma. tam można sobie właśnie przerobić ścieżkę Junior Pentester czy Security Engineer, co jest bardziej skierowane do osób, które chcą zabezpieczać właśnie infrastrukturę, coś co ja robię mniej więcej w tym kierunku i też na przykład Red Team, Blue Team, natomiast Jeżeli chodzi o… no bo tam jednak mamy też te challenge’e, ale one są dosyć… nie za bardzo odzwierciedlają faktyczny stan rzeczy. Jeżeli będziemy chcieli rozpocząć pracę jako pen tester, no to życie tak nie wygląda jak na TryHardMe. I tutaj wkracza Hack the Box. I Hack the Box jest fajne dla osób, które gdzieś dalej chcą się rozwijać i chcą trudniejszych wyzwań. I zobaczyć jak to faktycznie może wyglądać.
Andrzej: Tak, The Box jest już bardziej hands on, to są już faktycznie laboratoria, tam raczej nie ma żadnego, żadnej emulacji, tylko już działamy na czymś. No i to jest też kolejny krok w kierunku jakiegoś tam, no powiedzmy OSCP, takiego, takiego celu wielu, wielu osób, które idą w kierunku pentestingu. Jeszcze tam wyłapałem jedną rzecz, jak powiedziałaś, Czyli można byłoby to tak ująć, że weszłaś trochę do cego IT z taką pomocą od strony takiej bycia… w tym Django Girls.
Kasia: Od tego się zaczęło.
Andrzej: Ja pytam dlatego, że twoja ścieżka i kariera może być inspiracją dla innych i kobiet i mężczyzn, którzy chcą wejść do IT. I da się to też wykonać takim, bo ile dobrze kojarzę, Django Girls to jest darmowa inicjatywa.
Kasia: Tak. W ogóle moim pomysłem na przebranżowienie było to, żeby najpierw pochłaniać książki, więc pochłaniałam książki. Zaczęłam od SQL-a, bo SQL wydawał mi się prosty i myślałam, że bazy danej będą mi się podać. Później w ogóle nie poszłam w tym kierunku, ale wszystko jest warto czytać, ta wiedza zawsze się prędzej czy później przyda. No i ja postanowiłam poszukać jakichś darmowych warsztatów. Ponieważ myślę, że na początku nie ma sensu inwestować dużej ilości pieniędzy w kursy, dlatego że nam się może wydawać, że nas to interesuje i nam się to podoba, ale kompletnie zazwyczaj tak nie jest. Dlatego ja zaczęłam od baz danych, się okazało, że to w ogóle nie jest to. Ale kupiłam książki, nie kosztowało mnie to dużo, dlatego Dostałam się na warsztaty na początku z Javascriptu od Girls.js i później dostałam się na warsztaty właśnie w Django Girls jeżeli chodzi o Pythona ponieważ po Javascriptie stwierdziłam, że Frontend to nie jest to co… Jest w moim sercu.
Andrzej: Nie winie cię.
Kasia: Dlatego poszłam w kierunku backendu. Python. I się okazało, że Python jest bardziej ciekawy dla mnie. No i później już gdzieś to poszło. Już wiedziałam w jakim kierunku te moje zainteresowania idą. Więc to jest bardzo ważne, żeby na początku po prostu, jeżeli są jakieś darmowe, jest cała masa darmowych webinarów. Nie trzeba się ruszać z domu. Można kliknąć, posłuchać i zobaczyć czy mnie to w ogóle interesuje. Większość rzeczy raczej nie jest interesująca, ale trafi się właśnie to coś, co wyda się ciekawe, bo dla każdego coś innego. W IT jest naprawdę taka szeroka gama, że każdy coś dla siebie znajdzie.
Andrzej: Tak, 100% zgody, szczególnie z testowaniem różnych rzeczy i tym, czy rezonujemy z tym, czy nie. Bo jeżeli z czymś nie rezonujemy, to nie ma co się zmuszać, spróbować czegoś innego i w końcu dojdziemy do takiego tematu, z którym rezonujemy i wtedy faktycznie opłaca się wejść trochę trochę głębiej, a o tym Django Girls wspominam, bo widzisz, tak jak powiedziałem, masz inspirującą karierę. Ja też mam taką koleżankę, która też wskoczyła właśnie w IT od strony, to chyba właśnie nie było Django Girls, tylko właśnie coś związanego z Javascriptem, bo jest frontendowcem. Pozdrawiamy również Kasia, teraz już pracuje w dużej znanej polskiej firmie, która realizuje aukcje. Tak, i jest świetnym inżynierem i też wskakiwała właśnie od tej strony darmowych warsztatów. Co jej się spodobało, no i poszła dalej. Da się, da się, tylko trzeba po prostu chcieć i musi się temat spodobać.
Kasia: To od razu może mały tip. Ja aktualnie jestem w grupie Nerdscoding Gang. Założycielką jest Rita Łuczywek, która może niektórzy kojarzą z bloga Fly Nerd. Także zapraszam. Mamy grupę na Facebooku, można dołączyć. Mamy tam często jakieś wydarzenia, właśnie darmowe. Organizujemy też spotkania. Także, no niestety tylko w Poznaniu działamy, bo my wszystkie tu w Poznaniu siedzimy. Ale robimy też takie spotkania online. Chociażby ja robiłam ostatnio webinar 50 twarzy devopsa. I o tym, dlaczego devops musi wiedzieć wszystko.
Andrzej: Podlinkujemy podlinkujemy w opisie dla dla chętnych.
Krzysztof: A ja bym bardzo chciał zobaczyć tam pięćdziesiątą twarz.
Kasia: Tak, to właśnie zainspirowałam się tym filmem, ale sobie pomyślałam, że to tak świetnie pasuje pod względem tego, co robi DevOps, że po prostu DevOps robi wszystko i wiele osób boi się i nawet nie myśli, żeby iść w DevOps, a jak się dowiaduje ile technologii trzeba naraz rozumieć, ale nie dziwię się. To jest praca, dobrze płatna, ale też dosyć męcząca. Bo bardzo często trzeba się w ciągu dnia nawet switchować pomiędzy różnymi tematami. I to naprawdę nie jest dla każdego typu. Trzeba być osobą, która coś takiego lubi, wydaje mi się.
Krzysztof: Tak, ja myślę, że w ogóle o pracy DevOpsa i tego jak niektóre organizacje rozumieją czym jest DevOps i definiują to jako stanowisko, nie podejście. Moglibyśmy tutaj toczyć długą, filozoficzną dyskusję z tobą Kasią. Ja w tym momencie już chyba nie mam pytań.
Andrzej: Ja również się wypstrykałem, także z mojej strony bardzo dziękuję za rozmowę i ja jestem pewien, że sporo osób, które właśnie chciałoby, myśli o wskoczeniu w pewne ścieżki, wyciągnie z tej rozmowy dużo wartości.
Kasia: Mam nadzieję. Myślę, że będę pojawiać się jeszcze w social mediach z jakimiś prezentacjami związanymi z devopsowaniem, z DevSecOps’owaniem. Także można mnie obserwować na Linkedinie.
Andrzej: Oczywiście podlinkujemy do Linkedina Kasi w referencjach, bo wiemy, że Kasia jest aktywna na Linkedinie, a przynajmniej mi się tam przewija przez ścianę, więc link oczywiście będzie. Obserwujcie Kasię.
Krzysztof: Dziękujemy ci bardzo Kasia.