Kim jest mój gość i czego się dowiesz z wywiadu?
Jestem przekonany, że nie ma bardziej odpowiedniej osoby do rozmowy o bezpieczeństwie chmury niż człowiek, który tworzy platformę Cloud Computing – Kacper Dąbrowski – CEO vmgen . Zapraszam Was do ciekawej rozmowy, którą przeprowadziliśmy. Wciągniecie z niej wiele wartości i mam nadzieję, że lepiej poznacie nie tylko jego samego, ale również całą ideę stojącą za vmgen i ich wizję.
W trakcie tej rozmowy znajdziecie opinie i odpowiedzi na pytania:
- Jakie są główne obszary korzyści usług cloudowych?
- Jak Zero Trust pasuje do chmury?
- Jakie byś standardy bezpieczeństwa warto znać, aby móc rozumieć czego oczekiwać od bezpieczeństwa, jeśli chodzi o używanie chmury?
i na wiele innych.
Dostępność wywiadu
Wywiad jest dostępny na platformie YouTube na kanale Security Bez Tabu:
Również dostępny jako podcast:
Poniżej dostępna jest również transkrypcja dla tych, którzy lubią się wczytać. 🙂
Transkrypcja
Wojtek Ciemski: Cześć! Ja się nazywam Wojciech Ciemski i jestem założycielem serwisu Security Bez Tabu. Jest ze mną mój gość – Kacper Dąbrowski. Cześć Kacper.
Kacper Dąbrowski: Cześć. Dzięki za zaproszenie.
Wojtek: Dzisiaj będziemy rozmawiać o security bez tabu, a naszym tematem jest chmura. Zebrałem moim zdaniem interesujące pytania. Myślę, że Kacper jest właściwą osobą, żeby zadać mu właśnie te pytania o bezpieczeństwo chmury. Ale to wyjdzie zaraz po tym, jak Kacper się przedstawi. Więc, mógłbym Cię prosić o kilka słów o sobie?
Kacper: Pewnie. Ja od ponad 10 lat zajmuję się tematami wokół chmurowymi i wokół infrastruktury, cały czas jak najbardziej pamiętając o bezpieczeństwie. Nigdy nie miałem czasu, żeby stać się ekspertem w tej dziedzinie, ale zawsze było to blisko mojego serca. Przez parę lat rozwijałem firmę SingleBit, która rozwijała rozwiązania architektury, między innymi bezpieczeństwa trzech filarów, dobrze zrobionych rozwiązań architekturalnych, aplikacyjnych w chmurach i nie tylko. A teraz od niespełna roku mam wielką przyjemność rozwijać produkt chmury publicznej vmgen, gdzie właśnie z dużym naciskiem na tematy bezpieczeństwa dajemy użytkownikom możliwość stworzenia infrastruktury, na razie maszyn wirtualnych, a niebawem jeszcze większej liczby rzeczy.
Wojtek: Myślę, że w obecnych czasach, oczywiście mamy dedykowane działy bezpieczeństwa i to nie ulega wątpliwości, natomiast chyba wszyscy, którzy pracujemy w IT musimy się tym bezpieczeństwem interesować w mniejszym lub większym stopniu, bo należy to do naszych obowiązków i zadbania o nasze systemy, sieci i właściwie wszystko, co mamy podłączone do sieci Internet. I mam do Ciebie Kacper kilka pytań. Zaczynając od pierwszego, jakie są główne obszary korzyści usług cloudowych, czym się charakteryzują, jakbyś mógł przybliżyć.
Kacper: Jasne. Wiadomo, że to zależy od kontekstu i ciężko rozmawiać na tak wysokim poziomie ogólności. Dla każdego zespołu, projektu będą to inne korzyści. Więc ta lista, którą mam w głowie, jest listą jakby połączonych, największych korzyści dla usług chmurowych. To co na pewno łączy projekty, które tworzę, tworzyłem i pewnie będę tworzył, to przede wszystkim szybki start dla rozwijania produktów w chmurze.
W starej infrastrukturze odbywało się to tak, że najpierw trzeba było zrekrutować ludzi, znaleźć jakąś kolokację i (to jeszcze nie były czasy Kubernetesa, o których myślę) postawić jakieś rozwiązanie, dogadać kontrakty itd. Teraz z chmurą jest dużo łatwiej. Mamy pewne wspólne mianowniki, pewnego rodzaju standaryzacje i mamy tę infrastrukturę właściwie czekającą na nas. Wiatraki się kręcą i czekają, żebyśmy już uruchamiali nasze aplikacje.
Drugi aspekt to jest to, zwłaszcza w kontekście startupów myślę, (bo w Enterprisie jest troszkę inaczej – też właśnie z uwagi na bezpieczeństwo i że w Enterprisie lokalizacja, miejsce przechowywania danych ma ogromne znaczenie) ale w startupach, które często są finansowane unijnie, jest takie wymagane, że mają być globalne od pierwszego dnia. I teraz właśnie aspekt osiągnięcia tej globalności, to jest druga zaleta chmury na pewno. Czyli ta dostępność blisko klienta, przetwarzanie danych blisko klienta tak, żeby zyskać pewnego rodzaju przewagę biznesową. Może mam podobne funkcjonalności w swoim startupie, który służy do wyszukania restauracji, która przywiezie mi danie na lunch, ale działam dwa razy szybciej, bo właśnie jestem globalny. Jestem blisko użytkownika. I to staje się ciekawe dla mojego klienta, który nie chce czekać na zwrotkę z formularza zbyt długo, jak coś zamawia.
Kolejny aspekt to możliwość wyboru hardwearu, sposobu wirtualizacji, czy konteneryzacji technologii, która już jest tam dostępna w chmurze publicznej i używanie zasobów przez konkretny czas. Kiedyś musiałem zainwestować, od razu zrobić inwestycję w sprzęt, kiedy nie było chmury. A teraz mogę użyć przez krótki czas, który kiedy zwiększy się moja liczba użytkowników, requestów do moich serwisów, to mogę sobie to skalować na zewnątrz albo w chmurę, w zależności już od konkretnej architektury. Żyjemy w takich czasach, wierzę w to, że się Wojtek zgodzisz, że znaleźć specjalistów jest trudno. Po prostu jest mało osób zaangażowanych i chmura to skraca w jakiś sposób. W jakiś też nie, zależy jak na to patrzeć. Ale z jednej strony dostarczy nam managed serwisów, czyli coś, gdzie eksperci robią rzeczy dla nas i automatyzują. Z drugiej strony, żeby umieć je obsłużyć, to też trzeba mieć ekspertów. I trochę to jest zakręcone, no ale na pewno fajnie jest kliknąć „daj mi Kubernetesa” i go już mieć i wrzucać sobie komendy do deploymentu, nie wstawiać całego Kubernetesa.
Żeby spiąć jakąś klamrą tę odpowiedź, to powiedziałbym, że z mojej perspektywy jest fajnie mieć taki jeden wspólny mianownik dla infrastruktury, czyli w prosty sposób jakimiś callami do API, jakimiś może Infrastructure as a Code opisać sobie to, co się dzieje w mojej infrastrukturze. Tak to z mojej strony wygląda, jeżeli chodzi o największe zalety. Jest tego znacznie więcej, jak zarządzanie kosztami, trackowanie tych zasobów itd. Ale jeśli chodzi o główne, które spinają te projekty, z którymi ja przynajmniej pracowałem, to takie rzeczy tutaj widzę.
Wojtek: Trochę tak nawiązując do tego, bo wspominałeś, że rzeczywiście klik i mamy jakąś usługę, czy Kubernetesa, czy miejsce do tworzenia naszej aplikacji, hostowania usług, chciałbym Ciebie zapytać o rzeczy niższego poziomu, bardziej podstawowe, ale z punktu widzenia administratora ważne. Jakie są opcje dostarczania licencji na systemy operacyjne? Mamy np. Red Hat Enterprise Linux, którego chcielibyśmy zahostować w chmurze. I teraz jest pytanie, po której stronie ma ta licencja leżeć? Jak to robią ogólnie dostawcy chmury i który Twoim zdaniem sposób jest najbezpieczniejszy dla klienta?
Kacper: Jeśli chodzi w ogóle o sposoby zarządzania, żeby nasza rozmowa była zamknięta w jakichś ramach, wskazałbym trzy główne. Oczywiście tych sposobów licencjonowania jest na pewno więcej i każdy może jeszcze swój stworzyć, ale na wysokim poziomie ogólności to są: Bring Your Own License, Pay-as-you-go License, czy Licesing, Enterprise Licensing.
No i jeśli chodzi o ten enterprisowy , to to jest w sumie najmniej ciekawa opcja, bo po prostu podpisuje się umowę z dostawcą, negocjuje się rabaty i dostaje tę licencję. Często przez jakieś API można sobie te licencje zabierać i instalować albo w swoim data center, albo w chmurze. Czyli powiedziałbym, że to jest takie połączenie tych dwóch kolejnych z rabatami.
Natomiast najciekawsze różnice widać przy Pas-as-you-go i Bring Your Own License. No i teraz nie ma moim zdaniem złotego środka, to bardzo mocno zależy. Często się mówi, że każdy inżynier mówi „to zależy” i bierze dużo pieniędzy za godzinę. Trochę tak jest, że jak mam na przykład infrastrukturę i architekturę w data center, jakiegoś dużego gracza enterprisowego, to pewnie on by chciał przenieść te licencje, które ma, bo jest taniej przede wszystkim i nimi zarządza, ma nad nimi kontrolę. Wie na co ma licencje i o tym też trzeba pamiętać. Więc z punktu widzenia bezpieczeństwa to jest fajne.
Z drugiej strony jest Pay-as-you go, więc jak chcemy sobie skrócić tę ścieżkę i po prostu od razu używać gotowego rozwiązania i być bardzo tacy sasowi i tacy bardzo chmurowi, (nie chcę może mówić o cloud native w kontekście licencjonowania, bo to się nie łączy bezpośrednio) ale wtedy mamy drożej, jeśli chodzi o licencje w przeliczeniu na rok. Tak to wychodzi po prostu. Pewnie znajdą się licencje, gdzie ten stosunek będzie odwrotny, ale w ogólności tak to z mojego doświadczenia wygląda. Natomiast możemy kupić licencję niejako na czas. Czyli podobnie jak zasoby, razem z nimi kupujemy licencję.
Tutaj warto zaznaczyć też to, że jeśli chodzi o licencje, to nie tylko jest kwestia kasy, tylko to jest mega ważne z punktu widzenia bezpieczeństwa, co w tej licencji się znajduje. I zachęcam do rozważenia każdej opcji, jaką licencję dostarczy nam konkretnie dostawca danej chmury w środku, a co przychodzi razem z licencją, która jest kupiona na naszą firmę bezpośrednio. Bo może się okazać i znam takie przypadki produktów bardzo enterprisowych, np. jakieś proxy cacheujące itd., które bardzo dokładnie mówią o tym, co mogę zrobić na tej licencji, jeśli to moja, a co mogę zrobić, jeśli to jest licencja, która do kogoś należy, jestem w takim modelu multitenantowym, sharowanej licencji. No i się okazuje, że na tej licencji nie mogę już za bardzo budować rozwiązań hybrydowych, wysyłać tych danych do siebie itd.
Więc jakbym miał czas i możliwość zarządzania, to zachęcałbym – jeśli to są serwery chodzące cały czas, znowu duży poziom ogólności – do używania raczej swojej licencji.
Taka jedna uwaga, nie bezpośrednio z licencjami, ale to potem mocno w firmach widać, że to jest problem, żeby w czasach, które mamy teraz i świat też patrzy: hmm… jak jest ten Kubernetes, to warto może mieć hybrydowe, a wręcz może wrócić na swoje rozwiązania architektury. Więc wtedy fajnie mieć te licencje, mieć to zarządzane u siebie. Nie odpowiedziałem, że jest jedna, jakby nie wskazałem jednej metody, ale myślę, że w tych czasach ja bym się skłaniał w tych kierunkach.
W dużych firmach na pewno, w startupie powiedziałbym Pay-as-you-go. Zwaliduje się startup, wtedy zastanowimy się, co robimy.
No i uwaga na koniec, jak ktoś używa dużo SASa, którego się nie da hostować, a to nie jest takie oczywiste, że każdą usługę sasową da się później zahostować u siebie i mieć na to licencję on premise’ową, no to powiedziałbym, żeby z rozwagą wybierać te usługi z Pay-as-you-go, żeby później móc to przenieść do siebie po prostu.
Wojtek: Dziękuję Ci. I teraz może byśmy przeszli w tematy bardziej bezpiecznikowe. Istnieje i moim zdaniem obecnie nasila się, ruch w kierunku zero trust, jako najlepsze podejście do zabezpieczenia infrastruktury cyfrowej tej nowoczesnej – bo jest w miarę nowe stwierdzenie. Jak Twoim zdaniem zero trust pasuje do chmury?
Kacper: Dzięki za to pytanie, bo podejście zero trust jest bardzo bliskie mojemu sercu. Ja bym to pytanie odwrócił i zapytał, jak bardzo chmura pasuje do zero trust? Ale odpowiadając na Twoje pytanie, to z mojej perspektywy powiedziałbym, że już da się bardzo dużo rzeczy fajnie zrobić w chmurze. Nie jest tak, że nie da się nic zrobić w data center. Jak patrzę sobie na projekty, takie z życia, bo ja najbardziej lubię mówić o produkcji, nie lubię teoretyzować, to patrząc na podstawowe punkty, pryncypia można powiedzieć, zero trust i właśnie zarządzanie użytkownikami, autoryzacja tych użytkowników i później to, co się dzieje z maszynami, to lecąc tak po kolei: jeśli chodzi o zarządzanie kontami użytkowników, myślę, że chmura się świetnie integruje z serwisami SSO, jak choćby… możemy chyba nazwy wymieniać?
Wojtek: Ja już zacząłem z Red Hatem, więc…
Kacper: To na przykład Okta. Nie, że mam z nimi pakiet, żeby ich reklamować, tylko jest to po prostu fajnie zrobione. To popularne rozwiązanie i za naprawdę rozsądną kwotę na rok można sobie zarządzać w modelu chmurowym, bo oni też sobie tym chmurowo zarządzają. W jednym miejscu mieć tych wszystkich użytkowników i wrzucać im kolejne aplikacje chmurowe.
Jeśli chodzi o maszyny w chmurze, można bardzo fajnie sobie zarządzić tym, żeby nie trzymać haseł. I to też zależy od tego, jak bardzo legacy system jest, jak bardzo jest cloud native – ale jeśli jest bardziej cloud native niż nie, to możemy w teorii, w dużym uogólnieniu powiedzieć, że robimy to bez haseł. To nie jest tak, że robimy to całkowicie bez haseł, bo gdzieś tam pod spodem pojawiają się session tokeny i są one niejako hasłem per se, ale jest to zdecydowanie lepsze niż staromodne scp pliku enf na serwer i odpalanie haseł w plaintext. Więc na przykład da się w chmurze połączyć te bazy danych w ten sposób, żeby użyć jakiejś roli identity and access management i się z nią połączyć.
Ostatnio robiliśmy taki projekt SOC 2. I mam wrażenie, że w dzisiejszych czasach zrobienie bez chmury SOC 2 dla jakichś zestawów web aplikacji i bazy danych, nie wchodząc w szczegóły takiej typowej architektury, to mogę powiedzieć, że audytor jak widzi, że architektura nie jest w chmurze to mówi „ale to będzie mega ciężko w ogóle zrobić audyt, jak nie jesteście w chmurze!”.
Mega się świat zmienił z mojego doświadczenia. Myślę, że to też trochę odpowiada na Twoje pytanie. Mnie jest trochę smutno tak poza wszystkim, że w Kubrtesesie na przykład da się zrobić SSO i to żadna tajemnica, tych przełączników jest od groma. Potrzebny do tego zespół, jeszcze na koniec trzeba przetestować ileś open sourcowych rozwiązań, które trochę działają, trochę nie, trochę ten Multi Factor działa, trochę nie działa. A w chmurze jednak te rzeczy niestety i to mówię ze smutkiem, bo jestem takim człowiekiem, że chciałbym żeby to działało i on-prem i w chmurze, uważam, że jedno i drugie jest super tak naprawdę. Ale tu chmura moim zdaniem dla tych mechanizmów compliancowych, zbierania logów, bo to też jest ważne, access control dla aplikacji, nie będę ukrywał, że to jest wygodne, tylko potem wychodzenie z tego, co warto podkreślić, wyjście z tych systemów jest turbo trudne. Żeby to dalej było zero trust, ale zrobione gdzie indziej niż w danej chmurze, u danego dostawcy. Długo odpowiadałem, ale mam nadzieję, że coś w tym ciekawego jest.
Wojtek: Jest w tym dużo ciekawych aspektów. Odnosząc się do tego, co powiedziałeś, to jest problem, że przyzwyczajamy się do jakiegoś komfortu. Jesteśmy w chmurze, dostawca dba o logowania, o wszystkie mechanizmy, które traktujemy jak coś normalnego. Przecież loguje nam, daje informacje o jakimś niespodziewanym logowaniu, mamy jakiegoś firewalla, który nam blokuje większość rzeczy. I nagle biznes powiedzmy wymusi nam, bo zaczynamy przetwarzać jakieś dane, czy cokolwiek, żebyśmy to ściągnęli na on-prem do siebie, lokalnie. No i pojawia się problem, czy my jesteśmy świadomi tego wszystkiego, co się w chmurze działo, żebyśmy mogli powtórzyć, uzyskać jak nie ten sam, to bardzo podobny poziom bezpieczeństwa. I nagle nie ma wiedzy chociażby, co powinnyśmy monitorować.
Kacper: Co powinniśmy monitorować w chmurze?
Wojtek: Nie, to nie jest pytanie tylko dygresja. W chmurze mamy to „out of the box”, kliknęliśmy, dostajemy alerty, jak cokolwiek się wydarzy złego. Chmura myśli za nas, w tym sensie, że siadł zespół inżynierów, który wymyślił, co powinno być monitorowane. Natomiast my to wciągamy z powrotem do siebie, wychodzimy z chmury, bo coś to wymusza, albo musimy zrobić hybrydę i robi się zgrzyt, czy my w ogóle wiemy, co powinniśmy robić.
I to się dobrze łączy z kolejnym pytaniem. Jakie jest Twoim zdaniem największe wyzwanie, przed którym stoją dzisiejsze organizacje, jeśli chodzi o bezpieczeństwo w chmurze swoich systemów, czy aplikacji?
Kacper: Jeśli chodzi o największe wyzwania w kontekście bezpieczeństwa dla organizacji… Może to będzie niepopularne i niepoprawne politycznie, to co powiem, ale będzie bardzo szczere i znowu takie oparte o produkcję, a nie o teoretyzowanie i marketing porównujący stawianie bezpiecznych systemów do wizyty w kawiarni jakiejś sieciówki, bo teraz też już coraz więcej w necie jest.
Ja bym powiedział, że poza aspektem technologicznym, jest bardzo ważny aspekt mówienia, jak jest i tego w organizacjach, z którymi ja pracowałem i pracuję, nie widzę w dużym stopniu. To nie jest tak, że żadna organizacja taka nie jest, żeby tu zero-jedynkowo nie zabrzmieć. Ale mamy tendencje do uciekania przed tym i budowania pewnego rodzaju dokumentacji, która nie do końca koreluje z tym, jak jest naprawdę. I wydaje mi się, że to nie jest tak, że – nazwijmy to szeroko architekci, czy inżynierowie – nie chcą robić bezpiecznych systemów, tylko są stawiani pod presją, presją czasu najczęściej. No to powiedzmy w dużym uogólnieniu, że cały świat chciałby mieć Kubernetisa, trochę tak to wygląda, czy to w chmurze, czy też nie, to już mniej ważne, pewnie najchętniej wszędzie. Tylko się później orientuje, że Kubernetes tak agnostyczny nie jest. I teraz jest presja, nie ma ekspertów.
Pytałeś o największe wyzwania. Dla mnie na przykład największym wyzwaniem jest właśnie brak ekspertów. Stawiamy sobie taki klaster i się okazuje, że w zasadzie nie mamy czasu, żeby te nasze nowe aplikacje zabezpieczyć. Więc zanim w ogóle dojdziemy do aspektu technologicznego, który też jest wyzwaniem, to tak: brakuje nam ludzi z wiedzą, doświadczeniem, brakuje nam czasu, żeby to zrobić, więc tworzymy kreatywną dokumentację i to widzę w wielu organizacjach.
Wojtek: Bardzo dobre stwierdzenie: kreatywna dokumentacja.
Kacper: Tak jest. I mnie to boli, szczerze. Tak zwyczajnie mnie to boli, bo ja bym chciał, żeby było trochę inaczej. Nie to, że bym chciał, żeby świat zwolnił i trochę wolniej rozwijał systemy, ale… Ostatnio nawet kupowałem parę rzeczy do mieszkania, które wykańczam i w tych czasach, dostałem maila z hasłem w czystym tekście. Na szczęście robię sobie wszędzie inne hasła do innych sklepów. I zamawiając listwy do mieszkania, dostałem odpowiedź mailem, że konto jest założone. Tak więc poziom ignorancji też jest duży. Ostrzegłem, że będę musiał zgłosić ich do RODO, jeśli tego nie naprawią w sklepie internetowym. Także wykonałem pracę i wrócę do nich później z tym tematem. Bo to się nie powinno dziać, tak przy okazji.
Firmy w ogóle tego nie wiedzą, ale technologicznie, żeby nie było tak tylko teoretycznie, nie wyobrażam sobie, żeby było tak, że jeśli mamy powiedzmy nieskończone ilości zasobów w jakiejkolwiek chmurze i mamy nieograniczone ilości zasobów pieniężnych, czasu i wszystkiego, możemy sobie klonować inżynierów – do tego stopnia, nie musimy ich nawet rekrutować – osiągnięcie prawdziwie zero trust, czy SOC 2, już mówiąc jakimś standardem, że naprawdę mamy te backupy, metryki do każdej bazy są zrobione, wszystkie logi są zrobione, wszystkie logi są szyfrowane, klucze rotowane, spotykamy się raz na rok na duże sesje review, na wszystko mamy proces, to powiedziałbym tak: technologicznie ogarnięcie tych kontekstów, wskazanie, które role, zrozumienie tego, gdzie te pakiety lecą, jak to zrobić, jest ogromnym wyzwaniem. Bo mówimy sobie o DevSecOps żeby developerzy to ogarniali, ale oni mają z kolei presję tworzenia kolejnych feather’ów. Technologicznie myślę, że chmura daje te możliwości, tylko nie koniecznie umiemy i mamy czas z nich korzystać.
Także ja myślę, że to są największe wyzwania: brak ludzie, brak ekspertyzy. Technologicznie sama chmura jest na to gotowa. Problem technologiczny jaki jeszcze w chmurze istnieje, to jeśli użyć ich kilku, to ten przepływ danych między chmurami, którędy one wypływają. Zakładam, że jeśli ktoś ma wiedzę, to wie jak to zrobić, żeby wypływały kanałami, którymi powinny. Ale na przykład jakby chcieli zrobić aplikację w jednej chmurze, która gada do drugiej chmury i zrobić to w fajnym modelu ról IAM , to te chmury niekoniecznie chcą ze sobą rozmawiać. Teraz trzeba stworzyć rozwiązania technologiczne, żeby tłumaczyć uprawnienia jednego na drugie, albo rozpinać klastry pomiędzy chmurami. No, tam się dużo rzeczy ciekawych po drodze pojawia. Więc myślę sobie tak: z jednej strony chmura – super, z drugiej, wcale nie jest tak prosto i w chmurze trzeba architekturę też bardzo konkretnie zbudować.
Wojtek: Mówiłeś, że lubisz odnosić się do konkretów z życia wziętych. Czy mógłbyś nam zdradzić, w jaki sposób WAM udaje się pomóc waszym klientom w tym zadaniu utrzymania bezpieczeństwa?
Kacper: Ok. Myślę, że żaden produkt nie jest w stanie rozwiązać wszystkich problemów i wyzwań organizacji, jeśli chodzi o bezpieczeństwo. Chociażby z prostego powodu: nie powinniśmy mieć i nie mamy dostępu do kodu aplikacji, więc od tego zacznę.
No ale jak pomagamy? Nasz produkt jest rozwijany od dziewięciu miesięcy i jest tworzony w takim duchu, żeby w tym bezpieczeństwie pomagać. To żadna tajemnica, że używamy też innych chmur, znamy je, lubimy też wiele rzeczy u nich, absolutnie zero hejtu. Po prostu wierzymy, że da się różne rzeczy zrobić inaczej. Jedną z tych rzeczy, która jest bliska z naszego sercu, mając też serwerownie, które są zgodne ze standaryzacją bezpieczeństwa – wiadomo, każda serwerownia w innym zakresie ale pewnie jeszcze o tym też sobie porozmawiamy.
Myślę sobie, że kierunkowo, w tym roku, to mogę powiedzieć, będziemy dawać poza samym systemem audytowania architektury sieciowo i nazwijmy to też systemowo, do tego poziomu, do którego możemy, bo nie jesteśmy też w stanie wejść głębiej i nie powinniśmy też jako dostawca, to u nas będą wizzardy, które pozwolą komuś na podstawie wzorcowej, takiej blue printowej architektury, która w tym wizzardzie będzie prezentowana, tworzyć architekturę, dającą możliwość bycia zgodnym z SOC 2, PCI DSS, ISO itd.
Co to oznacza? Oznacza to, że nie musimy pierwszego dnia od razu zatrudniać super devopsa i security inżyniera. I będę mówił otwarcie tutaj, bo to nie jest tak, że sto procent rzeczy pokryjemy. Ale chociaż taka Zasada Pareto, że wyklikamy sobie, czy zautomatyzujemy z tego wzorca architekturę, która wymusi na nas konkretną komunikację sieciową, konkretny sposób zarządzania maszynami, jeśli są efemeryczne, to z jakąś analizą, czy są anomalie w zachowaniu tych maszyn. Jest zestaw takich fajnych rzeczy, które my możemy zautomatyzować. Tak samo będziemy to w tym właśnie roku robić: automatyzacja i rozwiązania sposobu szyfrowania, deweloper nie ma czasu na szyfrowanie logów i usuwanie haseł z tych logów, tak z naszego doświadczenia. A dla nas to jest jedna rzecz do zrobienia.
I patrząc, research’ując, rozmawiając z klientami, myślę sobie, że ten wizzardy to jest coś takiego – bo to jest nie tylko do security, chociaż właśnie w takim duchu to rozwijamy – na co wszyscy czekają, bo to będzie naprawdę duży wyróżnik naszej oferty, mówiąc wprost. Nie tylko się logując człowiek do nas, do konsoli, musi wiedzieć, co ma zrobić dalej, tylko może być przez nas poprowadzony za rękę, albo przez UI, albo przez automatyzację przez jakieś API, albo docelowo będziemy tworzyć teraz provider go lang’owy do terraforma, do Pulumi pewnie też niebawem, palybooki ansiblowe, więc kierunkowo tak działamy.
Ja jestem też bardzo ciekaw Twojej opinii, czy to jest coś fajnego, na podstawie audytowania i tworzenia systemów. Moim zdaniem to da też możliwość nauki, tak mówiąc wprost. Ktoś może sobie wyklikać architekturę, deweloper zobaczyć „aha to nie tak, że postawię jedną maszynę wirtualną i wszystko tam wrzucę”, tylko na dzień dobry, jak już robimy taki helpcare’owy projekt, to mam znacznie więcej, nie wszystkie decyzje technologiczne są fajne. Co myślisz? To jest coś fajnego, czy nie?
Wojtek: Dla mnie to jest coś bardzo fajnego. Tutaj może się ukazać mój brak wiedzy, bo ja nie ukrywam, nie jestem mocno chmurowy. Natomiast też zauważyłem w firmach, w których pracowałem – oczywiście nie we wszystkich i nie o to chodzi, żeby teraz sprawdzać, gdzie pracowałem -, również jak słyszę, to generalnie jest takie założenie, że „no my się tam nie certyfikujemy, jeżeli chodzi o ISO, bo mamy swoje usługi, serwery w chmurze u dużego dostawcy. Ten duży dostawca deklaruje, że jest zgodny z ISO27001 na przykład, czy z jakimś innym standardem”. Ale potem jak wychodzi, co jest w środku, bo te standardy mówią o infrastrukturze dostawcy, a nie mówią o tym, co my w środku zrobiliśmy z tymi maszynami, jak my nimi zarządzamy, co mieliśmy w głowie, żeby je skonfigurować.
I o takich rozwiązaniach, które właśnie pomogłyby sprawdzić, czy to co deklarujemy, czy myślimy, że jest zgodne ze stanem faktycznym, no to ja osobiście nie słyszałem o czymś takim. Fakt, że nie siedzę głęboko w chmurze, w tych tematach, ale nie słyszałem, żeby to było łatwo, czy w ogóle dostępne. Dla mnie to jest pewna nowość i z naprawdę bardzo dużym zaciekawieniem będę obserwował. I chyba tutaj odpowiedziałem na jedno z pytań, które przygotowałem dla Ciebie, ale też Ci je zadam. Jestem ciekaw Twojej opinii.
Czy na podstawie tego, że dostawca deklaruje zgodność z pewnym standardem, to czy my jako biznes możemy założyć, że w takim razie wszystko co do tej chmury wrzucimy, jest też z nim zgodne?
Kacper: Właśnie to jest to myślenie życzeniowe, o którym mówiłem wcześniej. Że użytkownicy, architekci może mniej, bo z mojego doświadczenia wynika, że są bardziej świadomi, w ogóle jako ludzie chcemy się skupiać naturalnie na pozytywie. I tak działa nasz mózg, skracamy sobie ścieżkę, dlatego często mamy przekłamane, niekompletne informacje w głowie. I wydaje mi się, że trochę jest tak z bezpieczeństwem. Chcemy wierzyć, że jak infrastruktura jest zgodna z jakąś certyfikacją, której potrzebujemy, to nasza aplikacja magicznie po przeniesieniu do chmury też jest. A paradoks tej sytuacji polega na tym, że często może być jeszcze mniej kompatybilna ze standaryzacją po przeniesieniu do tej zgodnej ze standaryzacją chmury, bo będzie zrobiona po staremu, będzie zrobimy lift&shift po prostu ze starego rozwiązania. No i się okazuje, że nie do końca. Jest jeszcze gorzej, bo hasło to sumie gdzieś leży w plain tekście na backend’zie, cały świat ma do niego dostęp i historia zna takie przypadki. Więc absolutnie nie możemy zakładać, że przeniesienie czegoś do chmury gwarantuje nam, w zasadzie kontekście standaryzacji security i poziomu bezpieczeństwa, poza może tym systemem autoryzacyjnym, który może być zgodny i to możemy wymusić, czy przy jakimś sposobie działania bazy danych.
Chociaż moje doświadczenie też jest takie i tego mi brakuje, bo szczerze my tworzymy ten produkt też patrząc na nasze doświadczenie i braki, które my widzimy. Ja chciałbym wejść do takiej usługi w chmurze, tak też będziemy to rozwijać, gdzie mogę kliknąć „daj mi bazę danych zgodną z tą standaryzacją dla tej sieci”. Nie oczekuję, że stanie się tyle i to będzie sto procent, bo żeby była jasność, też tego nie osiągniemy, ale chociaż pokazać, na przykład w wizzardzie podzielić się linkiem „zobacz, tu jest standard bezpieczeństwa” i to jest super ważne. Są fajne narzędzia SaS’owe teraz, przykładowo – i znowu, nie reklamuję teraz, tylko patrzę na nie, jak na fajne narzędzia)- jest taki serwis jak Drata. Oni mają fajne podejście do compliance’u. To jest startup finansowany przez Oktę, gdzie można połączyć się z kontem AWSowym, github’owym, czymkolwiek i oni przychodzą ze wszystkimi oczekiwaniami standaryzacji – SOC 2, PCI DSS i skanują naszego GitHuba, AWSa, security grupy itd. Bo to jest jakby po stworzonej architekturze. To jest właśnie ten kierunek, który ja obserwuję.
Tylko jak już wydam na devopsa, na kontraktora pewnie w startupie, – już nie chcę wchodzić w temat, ile kosztuje za godzinę, każdy może sobie UpWorka otworzyć, czy coś takiego zobaczyć – on mi coś stworzy, w sumie nie zrozumie do końca mojej aplikacji, stworzy coś, co dla niego będzie super, ale będzie działało dramatycznie. A my chcemy pomóc i w jednym i w drugi. Docelowo pewnie nie w tym roku, nie chcę obiecywać nie wiadomo czego. Kierunkowo moje marzenie jest takie, jako CEO w vmgen, żeby to było. Żeby dorzucać jakąś bibliotekę do kodów, czy kontenerów, rozwiązania site care’owe i żeby to było kompatybilne z naszym rozwiązaniem, ale my też nasz produkt tworzymy w takim modelu, żeby unikać, jak się da vender locka i nie zmuszać do tego, żeby ktoś u nas został za wszelką cenę. Chcemy robić vender locka jakościowego, a nie technologicznego, żeby zmuszać. Jak rozmawiam z zespołem, to często na siebie patrzymy jak na hydraulików – jesteśmy od tego, żeby łączyć rury, a niekoniecznie od tego, żeby mówić komuś, jak ma żyć. Więc nie, nie można zakładać, że moja aplikacja jest magicznie bezpieczna. Nie jest, może być nawet dużo mniej bezpieczna.
Wojtek: Przychodzi mi do głowy anegdotka z głębokim ukryciem. W zasadzie każdy z nas może na serwerze, wszystko jedno czy on-premisowym, czy w chmurze, zrobić głębokie ukrycie i liczyć na to, że jest to bezpieczne. Jeżeli ktoś nie wie, co to jest głębokie ukrycie, polecam wpisać sobie w przeglądarkę i poczytać. Naprawdę bardzo fajna anegdotka o bezpieczeństwie i myśleniu magicznym o bezpieczeństwie.
I przechodząc w zasadzie płynnie do kolejnego pytania. Bo powiedziałeś o bardzo fajnej rzeczy. Będę to obserwował z wielki zaciekawieniem, jak Wam to będzie właśnie wychodzić, odnośnie tego, żeby sprawdzić, czy moja infrastruktura w chmurze, albo chcę założyć taką zgodną z takim a takim standardem, to jak ona powinna wyglądać. Jakbyś mógł takie standardy wskazać dla osoby która chce na poważnie myśleć o bezpieczeństwie w chmurze. Nie chodzi o to, żeby teraz sypać wszystkim, bo tych standardów jest bardzo dużo, w zależności od tego czy jest firmą healthcare’ową, czy ma jakieś dane pacjentów. On wtedy wie, że dodatkowe rzeczy go obowiązują. Ale te podstawy, które przychodzą Ci do głowy, które będą na pewno.
Kacper: Nie wiem czy pytasz o standardy, czy bardziej o technologiczne rozwiązania.
Wojtek: Bardziej standardy. Żeby jakiś manager, czy osoba zarządzająca, bo to generalnie od nich jest to przeświadczenie, że skoro jesteśmy w chmurze, to jesteśmy bezpieczni. Co byś wskazał, z warto się zapoznać?
Kacper: Z mojego doświadczenia, z jednej strony patrząc technologicznie, a z drugiej procesowo, bo z procesowego standardu zgodności wynika też technologiczny. Zacznijmy może od procesowych, biznesowych standardów.
Jeśli mam płatności online, to PCI DSS jest na pewno standardem, z którym powinienem się zapoznać. On narzuca bardzo konkretne reguły gry. Można być wręcz przerażonym, jak się za to zabrać. To do czego ja zawsze zachęcam, to przeczytanie tego frameworku, jeśli jestem managerem, architektem, kimkolwiek. Są też świetne artykuły w Internecie, tylko nie polecam tych od firm audytorskich. One piszą jeden mały artykuł i piszą, że wszystko jest proste i przyjemne. Tylko naprawdę taką analizę tego, co siedzi w najnowszym PCI DSS. Bo tam wchodzą tematy rotowania haseł, szyfrowania dysków to jest w ogóle początek zabawy. Tam się bardzo dużo rzeczy dzieje, jeśli chodzi o multitenantowe rozwiązania i się okazuje, że tylko niektórzy, którzy podpiszą specjalne papiery, odnawiane co jakiś czas, mogą mieć dostęp tylko do tych zasobów. A niekoniecznie do tej architektury i bazy danych, tylko do bazy danych już nie. Token do jakichś integracji, na przykład ze Stripe’m już jest czymś, co powinno być inaczej przechowywane, rotowane co jakiś czas, z audyt logiem kto i kiedy, w jaki sposób go używał itd. Tak myślę, że jak otwieram startup, fajnie jak ma doświadczenie korporacyjne i to takiej, która w miarę serio traktuje tę standaryzację, niekoniecznie z dużą ilością kreatywnej dokumentacji i wiem, ile kasy będę musiał w to włożyć. Bo jak nie wiem, to przeczytawszy ten dokument przynajmniej będę wiedział więcej. I serio, to są często ogromne pieniądze, żeby zabezpieczyć swoją aplikację. To jest raz – PCI DSS.
Druga, na pewno HIPAA, jeśli chodzi o aspekt healthcare’owy i tam też bardzo konkretne rzeczy, zwłaszcza z danymi, i tam sieć też jest ważna.
Często architektury, które widzę w chmurach, za tym nie nadążają, czyli takie standardy bezpieczeństwa jak to, żeby mieć podział na subnety, mieć subnety do baz danych, do ruchu przychodzącego z zewnątrz do load balancer’a na przykład. Ja teraz lecę bardzo ogólnikowo. Subnety wewnętrzne do komunikacji takich zasobów w warstwie drugiej powiedzmy. Czyli pomiędzy bazą danych, a load balancer. I security grupy, NACL, żeby to wszystko było fajnie pokonfigurowane, faktycznie z tym podejściem list privilege. Zupełnie otwarcie mówiąc, to tego też często nie widzę. Jak wchodzę do nowego projektu, to zazwyczaj widzę pootwierane na cały świat i komunikację przez otwarty Internet bez IPSEC’a żadnego. I też otwarcie mówiąc, jeśli mam bazę danych w innym miejscu, lecę przez Internet i nie włączę TLSa, to co z tego, że w środku chmury mam super architekturę, jak jeden gość nie wiedział, jak się robi IPseci. Trochę tak to wygląda więc też HIPAA polecam
Jeżeli z kolei chodzi o standaryzację data center, to ISO, SOC 2, który jest zdecydowanie ciekawym tematem i warto też zajrzeć. ISO 27001. Ja wiele lat temu dostałem Zurychu certyfikat ISO 27001. Tak było dużo rzeczy, ale jedna się nie zmieniła i robią nam to wszyscy, zwłaszcza jakoś operatorzy sieci komórkowych to często stosują, Ty Wojciech na pewno to wiesz, ale jak ktoś nie słyszał, bo zakładam, że oglądają to nie tylko ludzie związani z bezpieczeństwem… Te standaryzacje są na zakresach i można sobie świetnie określić zakres takiego ćwiczenia i powiedzieć na przykład, że w sieci komórkowej komunikacja pomiędzy tym, a tym BTS’em, na takich protokołach na przykład, no jakkolwiek, taki szczegół implementacyjny już, bardzo konkretna, mała rzecz, jest zgodna z ISO 27001. I potem te firmy sobie przyklejają certyfikat ISO 27001. Więc tak też można. Tak nie robimy.
Jak mamy te wszystkie rzeczy, to z mojego doświadczenia, jestem też ciekaw, co Ty Wojtek myślisz, bo o tym nigdy nie gadaliśmy chyba, to co myślisz o tym, żeby używać takich mocno technologicznych dokumentów i też przeczytać? Myślę, że manager też mógłby przeczytać na przykład z OWASPa. Myślę, że OWASP ma fajne tule i fajnie to opisuje. Jest taki styk: nie jest tam bardzo jeszcze technologicznie na ich stronie, jest dużo fajnych prezentacji, a z drugiej strony już mówią, ile tej roboty będzie. To tak z mojego doświadczenia. Co myślisz, tak z ciekawości?
Wojtek: Musimy sobie podzielić osoby, które będą dbać o bezpieczeństwo managerów, ktokolwiek to będzie na te, które faktycznie chcą podnieść poziom bezpieczeństwa w systemach i sieciach i wtedy OWASP to takie podejście naprawdę z sercem do niego. Bo OWASP TOP 10 to są najczęstsze błędy w aplikacjach. I to, że nie zmienia się diametralnie przez te lata, bo teraz w zeszłym roku wyszła jego nowa wersja, to pokazuje, że te błędy dalej są bez względu na nasze pojęcie technologiczne. Pomimo że idziemy za nowymi technologiami, że mamy więcej specjalistów, chociaż jak powiedzieliśmy nadal są ich niedobory. A z drugiej strony mamy biznes, który chce się marketingowo chwalić. Tak jak powiedziałeś o tym certyfikacie, który sobie powiesimy, będziemy mówić klientom „mamy ISO 27001″, tylko pomiędzy tym a tym – ale o tym już za bardzo nie powiemy.
OWASP otwarcie mówi o tym, że nie wystawia certyfikacji do aplikacji. Nawet jak wspomnimy na stronie: robimy swoją aplikację i bierzemy pod uwagę OWASP TOP 10, albo z odpowiednim OWASP’owym standardem -zachęcam Was, żebyście spojrzeli ile OWASP robi różnych projektów i jak one dotyczą różnych aspektów produkcji oprogramowania, czy już samych aplikacji webowych i innych spraw – to biznes nie jest za bardzo zainteresowany czymś, czego nie może właśnie pokazać, wyświetlić, czy żeby to był np. jakiś dodatkowy argument w przetargach, czy rozmowach. I to jest bardzo problematyczne.
To jest jakiś tam mój żal, który myślę, że kiedyś opiszę i powstanie o tym artykuł, że są pewne certyfikacje, gdzie ten certyfikat jest wystawiany pomimo jakiejś niezgodności, bo jest sprawdzany pobieżnie. I wtedy to ta firma bierze na siebie wszystkie konsekwencje niedotrzymania standardu. Dla mnie to jest sytuacja niedopuszczalna. Trochę popłynąłem w inną stronę, mam świadomość. OWASP jest jak najbardziej na plus. Uważam, że byłoby bardzo dobrze, gdybyśmy mieli narzędzia, które pozwalają nam sprawdzać najczęstsze błędy. Chociaż może jest to marzenie ściętej głowy, bo aplikacje bardzo często są unikalna poza tym, że jest napisana w jakimś wspólnym języku. Ale będę oczekiwał go, bo uważam, że patrząc na poziom wiedzy… no też trudno być we wszystkim dobrym, to normalne. Na którymś etapie swojej kariery zawodowej człowiek sobie uświadamia, że nie będzie od wszystkiego i nie może być od wszystkiego.
Z drugiej strony od tych managerów, którzy sami jeszcze niedawno kodowali, albo są z takiego środowiska i nagle mają się przestawić na umiejętności managerskie i to im wychodzi, natomiast jeszcze dodatkowo wrzucamy ich w bezpieczeństwo. Gdzie oni o tym nie myśleli, albo nie programują komercyjnie od kilku lat i teraz mamy im to wrzucić na głowę – jest to trudne i wszystkie narzędzia, które mogą im w tym pomóc, ja będę obserwował, trzymał kciuki za te narzędzia. Jak tylko będę mógł się gdziekolwiek dołożyć, żeby coś takiego powstało to zrobię to bo myślę, że to będzie strzał w dziesiątkę dla bardzo wielu organizacji.
Powoli kończą nam się pytania, które chciałem Ci zadać. Jeszcze jedno natury filozoficznej. Rozmawiamy na dosyć dużym poziomie ogólności, żeby rozmawiać konkretnie musielibyśmy mieć konkretny case i pewnie odpalić share’owanie pulpitu, żeby omawiać. To jest bardziej uświadomienie dla takich osób chociażby jak ja, czyli administrator. Jest zainteresowanie cyberbezpieczeństwem, z tą chmurą nie było po drodze, żeby uświadomić sobie, jakie mogą być problemy, wyzwania. O czym warto byłoby pomyśleć, jeżeli chodzi o bezpieczeństwo chmury. Myślę, że to będzie dobre pytanie do kogoś, kto rozwija i jest w tym środowisku bardzo głęboko. Jak myślisz, jak chmura będzie wpływać na bezpieczeństwo w ciągu tych najbliższych lat?
Kacper: Nie wiem konkretnie, jak chmura jako taka będzie wpływać. Ale myślę sobie, że dzieją się dobre rzeczy, żeby nie było tak tylko pesymistycznie dzisiaj. Podoba mi się ruch devsecopsowy. Bo zaczynaliśmy od DevOps i cała ta narracja i dużo memów, że devops to taki admin, który nie umie bezpieczeństwa, no dużo było hejtu.
Wojtek: Ja najlepsze, takie które mi się najbardziej podoba określenie devopsów, usłyszałem to takie, że to jest słowo, która powstało, żeby programiści i administratorzy mogli razem pójść na piwo.
Kacper: Może tak być. Tego nie słyszałem jeszcze, ale dobre faktycznie. Jeśli chodzi o przyszłość, ona moim zdaniem już trochę się dzieje i wydaje mi się, że to jest akurat dobry ruch. Ogólnie nie jestem człowiekiem, który lubi bardzo silne standaryzacje. Jak prowadzę zespoły, czy rozwijam rozwiązania, czy myślę o strukturze pipeline’ów dla developerów, to nie lubię rozwiązań, w których narzucam jedyny słuszny sposób deploy’wania, jedyny słuszny sposób monitorowania. To jest trochę w kontrze do systemów bezpieczeństwa, bo jak każdemu pozwolimy na robienie wszystkiego jak chce, to tak realnie rzecz biorąc, trochę ciężko będzie nam to zabezpieczyć.
Bo na sam koniec, trzeba sobie powiedzieć jasno, że to nie jest tak, że mamy samych, full stacków, devsecopsów i samych, teraz już senior jest niemodny, teraz się chyba mówi principle engineer, samych wyekspionych 20+, 30+ lat doświadczenia ludzi. No i też mówiąc otwarcie, znam firmy i pracowałem w firmach, gdzie bezpieczeństwo było łamane przez osoby pracujące na przykład w HR, przez kontakt na FB, lub umówienie się na randkę z taką dziewczyną. I teraz trzeba zrobić coś, żeby osoby, które mają mniejszą świadomość – absolutnie nie chcę wybrzmieć jako osoba która chce kogoś obrazić, czy powiedzieć, że oni są głusi, czy gorsi, tylko po prostu mają mniejsze doświadczenie, nie dotknęli jeszcze tych tematów.
Tylko, że w bezpieczeństwie, czy to w banku, czy nawet startupach, które przetwarzają pieniądze… Bo pamiętajcie o tym, ze nawet jak to jest mały startupik do mierzenia pulsu, czy cokolwiek, to jak tam jest wasza karta kredytowa, to tak samo jest zabezpieczona lub nie w takim mały programiku i to jest trochę smutne. Ale do czego zmierzam? Tak patrząc na realia, na rekrutację, te wszystkie rzeczy, wyobrażam sobie jak taki, może nawet Kubernetis do bezpieczeństwa, że skoro nie mamy czasu, żeby rozmawiać i ustalać pipeline’y i sposoby monitoringu, robić to autorsko w każdej firmie -są firmy, które uważają, że mają ten czas, a później toną, tak też się zdarza, bo konkurencja ich wyprzedza, a parcie na coraz szybszy rozwój jest- to wyobrażam sobie, że powstanie taki wspólny słownik. On już trochę jest w Kubernetisie. Bo te yamle nudne strasznie i irytujące dla mnie okropnie, pisanie ogromnej liczby przełączników konfiguracji properties’ów i spec’ów, to nie jest zadanie, które lubię i wcale Helm Charts mi nie pomagają, żeby robić abstrakcję do abstrakcji , do abstrakcji i wcale moje życie nie staje się lepsze.
Moje marzenie i może znajdą się osoby, które będą zainteresowane, może Ty Wojtek, rozwijaniem takiego startupu i produktu, bo ja tak widzę przyszłość. A wiecie, jak to jest. Ktoś ma wizję, a potem trzeba ją zaimplementować. Od paru lat chodzi za mną ten pomysł i chcę, żeby ktoś to zaimplementował. A jak nikt tego nie zrobi, to może w końcu zrobi się zespół, który to zrobi. Są narzędzia do audytowania Kubernetisa – fajnie. Niekoniecznie są one fajnie rozwinięte jeśli chodzi o taki audyt SOC 2, PCI DSS. Ale skoro mamy wszystko w yamlach, skoro można by było przechowywać wszystkie config map’y, secrets’y, zarządzanie użytkownikami, to marzy mi się coś takiego, żeby była taka komenda a’la keep control, której przekazujemy na przykład listę etykiet obiektów, cały klaster, albo konfigurację klastra. Mówimy SOC2, mówimy PCI DSS i dostajemy wynik audytu. I tak sobie wyobrażam, odpowiadając na Twoje pytanie o przyszłość, że z uwagi na mikroserwisy, czy jak niektórzy już mówią nanoserwisy – ostatnio słyszałem od jednego klienta – i tego jest tak dużo, a Kubertetis, jak ktoś spojrzy, co robi w sieciach, często o to na rekrutacji pytam, jak działa Ingress, jakie regułki iptables są tworzone pod spodem dla Ingress’a kubernetes’owego, to zarządzanie tym w sieciach docker’owych, kontenerowych jest mega trudne.
Więc ja sobie wyobrażam, że będzie jeszcze więcej abstrakcji, będzie zarządzanie po etykietach, będą narzędzia do audytów działające na tych konfiguracjach. Kubernetes odwalił kawał świetnej roboty, bo w końcu mamy proste narzędzie do konfiguracji użytkownika, który to uruchamia, to fajnych network policies, jeśli dobrego CNI wybierzemy. Więc jest już więcej tych systemów rozproszonych i to jest bardzo fajny kierunek. Ale cały czas brakuje mi czegoś tak naprawdę na sterydach narzędzia do audytu, a może nawet docelowo. Może vmgen, absolutnie nie obiecuję tego na przyszły rok, jeśli ktoś ma takie nadzieje, to żeby pozbawił się tych nadziei jak najszybciej.
Wojtek: Przepraszam, że Ci się wtrącę, ale myślę, że jeśli ktoś ma nadzieję i chęć, to dobrze, żeby się skontaktował bezpośrednio, to może Ci pomoże.
Kacper: Ale wiesz, o co mi chodzi. Bo ja nie lubię myśleć życzeniowo. Kiedy prowadzę zespół, to też czasem im mówię: przestańcie brać do tego sprintu tak dużo rzeczy i tak tego nie dowieziecie, nie? A dowieźcie mniej i mnie zaskoczcie, jak weźmiecie coś więcej. I myślę sobie tak, ja nie wierzę, że standardy security, tak szczerze jak wierzę, że w data center da się je zrobić na tym poziomie, tak w kontekście mikroserwisów, systemów rozproszonych i takiej ilości komponentów i problemów z rekrutacją, jeśli chcielibyśmy sobie powiedzieć szczerze, to nie wierzę, że da się to zrobić w takiej skali.
Więc mówiąc otwarcie, mam takie założenie, żeby zrobić jak najwięcej się da i po prostu automatyzować jak najwięcej, robić to z głową, żeby na koniec dnia, albo na początek kolejnego stanąć, spojrzeć w lustro i nie wstydzić się tego, co się robi i jak się przechowuje dane klienta. I wierzę w to, że tylko automatyzacja i tylko, jak już idziemy w tę abstrakcję kubernetisową jako świat, a trochę tak jest, może nas uratować. Tak patrzę.
Wojtek: Ja mam nadzieję, że to się ziści i będziemy obserwować, że to taki kierunek obierze. Wiem, że monitoring jest trochę prostszy, jeżeli chodzi o abstrakcję. Ale skoro mamy już pewne narzędzia, które automatycznie dobierają czujki do systemu i wiedzą, co mają monitorować, zwłaszcza te droższe programy do monitorowania, to jest po prostu out of the box, pokazuje klaster vmware’owy i jak ma dostęp sieciowy, wszystko elegancko nam ubiera w dashboard i informuje, co zaczął monitorować, to mam nadzieję, że w tych tematach, które wymieniłeś, to będzie.
Myślę, że z takie pytania odnośnie bezpieczeństwa się wyczerpały. Mogę jeszcze zapewnić, że jeżeli pojawią się pytania od czytających, to zachęcam, żeby je zostawiać w komentarzu. Postaram się wszystkie na bieżąco Kacprowi przekazywać, jeżeli będzie mógł, to odpowie. I może takie zdanie podsumowujące, Kacper chciałbyś powiedzieć coś, spinającego klamrę? Bo nie chciałbym, żeby ten wywiad był depresyjny, że wszystko jest źle. Chociaż człowiek czasem skupia się na polach do doskonalenia, jak to się mówi w audycie. Na tym się przede wszystkim skupiamy. Mówimy o sprawach związanych z defensywą i w naszym przypadku jakieś jedno nasze niedopatrzenie może skutkować tym, że system/dane zostaną skompromitowane. Bardzo często po takim ciosie organizacja może się nie podnieść, dane klientów wyciekną i stracimy zaufanie, już o pieniądzach nie mówiąc.
Kacper: Zdanie spinające… Co rekomenduję, nie czego sobie życzę, ale o czym marzę. Kiedyś jak otwierałem firmę SingleBit, która przez wiele lat wspierała dużych, małych graczy, firmy z całego świata tak naprawdę jeśli chodzi o architekturę chmurową, to często mówiłem o jednej rzeczy. Jestem ciekaw Wojtek, czy się zgodzisz z tym podejściem, z taką propozycją. Że jak ktoś w ogóle idzie w chmurę i to nie chodziło konkretnie tylko o kontekst bezpieczeństwa, to żeby chwilę porozmawiał z człowiekiem, który zjadł na tym zęby i „sfailowal” wiele razy, nawet przez osiem godzin. Jasne, to świetnie buduje potencjały biznesowe, pewnie, że tak. Ja często jechałem z moim wspólnikiem Maćkiem do takiej firmy, to jeszcze było przed covidem, albo robiliśmy calla, nawet na dwa, czy trzy dni. I rozmawialiśmy sobie, taka naturalna rozmowa, żeby zobaczyć co druga strona wie, co planuje.
Zadawaliśmy trudne pytania, mówiliśmy o problemach. I w ten sposób tak naturalnie pokazywaliśmy, na co trzeba zwrócić uwagę, co wróci, jak trzeba prowadzić rekrutację i jak trzeba na to spojrzeć w taki realny sposób. To też budowało jakieś rzeczy do współpracy. Ale to były często bardzo pozytywnie oceniane rzeczy, że faktycznie ktoś mógł stanąć i pomyśleć: czy ja potrzebuję Kubernetisa, bo nie mam w ogóle ludzi, którzy go znają? A chyba musze mieć, bo ten manage service to nie jest tak, że rozwiąże moje problemy. Czyli to myślenie życzeniowe. Tak samo było z security, jak pokazywaliśmy IAM roles, takie rzeczy.
Ja bym spiął to klamrą i powiedział tak. Można wykonać bardzo małą ilość pracy, można zadzwonić do Wojtka, można zadzwonić do kogoś, kto na przykład w tematach architektury w jakiejś chmurze, mówię o aspektach niebezpieczeństwa, się tym zajmuje. Chwilę porozmawiać i bardzo dużo się dowiedzieć. Można wejść do Internetu i naprawdę przeczytać te standaryzacje bezpieczeństwa. I jak to często mówi się po amerykańsku, można zostać kowbojem i po prostu mieć to w nosie. Można, ja nie popieram takiego rozwiązania. No ale każdy na koniec decyduje, co robi. Więc polecam przeczytać, polecam znaleźć na to czas, naprawdę i później świadomie podjąć decyzję. Więc to jest jedna rzecz.
Marzę o tym, żeby ten starup ktoś zrobił. A najlepiej opensourceowe narzędzie, które takie audyty robi. Bo są narzędzia do audytu Kubernetisa, AWSa, różnych chmur, my też takie rzeczy tworzymy. Ale jak ktoś słyszał o takim narzędziu do compliance’u, ale niekoniecznie takim, które wybiera sobie 20 rzeczy typu: szeroko otwarte security grupy i hasła w plaintekście w yamlach, tylko takim naprawdę fajnym audycie, to niech da znać. A jakby chciał coś takiego rozwijać, to też niech da znać. I jak to, co dzisiaj mówiłem przemawia, bo w bezpieczeństwie każdy ma inne podejście i nie oczekuję, że się ze mną zgodzicie. Jak nie, to też piszcie.
A tak poza tym, tak spinając klamrą, to zwyczajnie Wojtek dziękuję za zaproszenie, bardzo miło. Nie wiem, kiedy nam ten czas upłynął, więc bardzo miło się rozmawiało i bardzo dzięki też za otwartość o podzielenie się Twoimi poglądami, jako eksperta do spraw bezpieczeństwa. Fajnie posłuchać opinii i też zobaczyć, że nie jest tak, jak mówili zawsze, że siedzicie w piwnicy, wszystkich nie lubicie i narzekacie na systemy. Mówiłeś o tym tonie depresyjnym. Tylko chcesz robić fajnie systemy i rozmawiać z ludźmi w pozytywnym duchu i też trzymasz kciuki za przyszłość dla bezpieczeństwa. Dzięki za to.
Wojtek: Mogę powiedzieć, że takie podejście wynika z tego, że pracowałem pięć lat na pierwszej linii wsparcia. I oczywiście można cytować te wszystkie dowcipy i komiksy pod tytułem: „jak ci wszyscy ludzie mogą nie wiedzieć takich prostych rzeczy”. Ale na koniec taka myśl, może nie związaną z wywiadem, że ci wszyscy ludzie przychodzą do pracy i mają swoje konkretne zadania, swoją konkretną robotę do zrobienia. Możemy to oczywiście uznać za ignorancję, ale oni często nie wiedzą, jak mają to robić, nie wiedzą dlaczego mają to robić, nie mają świadomości. Na szczęście jest całe spektrum bezpieczeństwa, nie każdy kto lubi obsługiwać SIEM, musi lubić tłumaczenie czegoś użytkownikowi. Ale trzeba po prostu tym ludziom to wszystko po prostu uświadamiać i mówić o tym.
Ja też Kacper Tobie dziękuję. Bardzo dużo rzeczy się dowiedziałem o chmurze. Dużo na pewno później sprawdzę i rozwinę. Myślę też, że powstało miejsce na bezpieczeństwo chmury w SecurityBezTabu, żeby można było o tym poczytać, dowiedzieć się czegoś więcej. Bardzo bym chciał się tym zająć, bo nie oszukujmy się, bardzo wiele firm, technologii albo już jest w chmurze, albo będą migrować i nie uciekną od tego.
Więc Kacper jeszcze raz Ci dziękuję. To była rozmowa z serii Security bez tabu i mam nadzieję, że niedługo do przeczytania!
