bezpieczeństwo

Metryki bezpieczeństwa

Są takie książki do których trzeba się mentalnie i merytorycznie przygotować. A kiedy już się po nie sięgnie ich zawartość jest starannie czytana, ..i czytana ..i czytana, treść “obracana” w głowie, aż do pełnego zrozumienia. Ale też nie, że “Achaaa.. to tak działa!” i siup, następny rozdział. Trzeba to przerobić praktycznie.

Bezpieczna dostępność

Po wstępnych dywagacjach w poprzednim wpisie, pora podkasać rękawy i zabrać się do pracy. Naszymi dramatis personae będą stali bywalcy: Nomad, Consul i Vaulta oraz Traefik. Plan jest taki, aby mieć jeden ingress point (Traefik) dla mojej mikro-chmurki prywatnej, który nie tylko automatycznie wyniucha co w serwisach piszczy, a również automatycznie je obsłuży wraz z TLS.

Wstęp do wysokiej dostępności

Ostatnie dwa odcinki mojej domowej devopsowej epopei doprowadziły mnie do fajnie działającego deploymentu aplikacji z bazą danych. Uwzględniając zabezpieczenie wszelkich danych uwierzytelniających (kredek) - tak jak to powinno wyglądać, co do zasady. Ale to nie wszystko..

Kto schował kredki?

Odpowiedź może być jedna - Nomad. A konkretnie Nomad zintegrowany z Vaultem. Ogólnie to plan jest taki, aby kredki do bazy były bezpieczne, nie jakieś tam .env na laptopie developera (w najlepszym wypadku, i tak wrzucane do repo) czy, o zgrozo! w jakimś pliku .txt. Opcje są dwie - albo je przenieść jako secrets do GitHuba w repozytorium aplikacji albo zabezpieczyć tak, żeby nawet programista nie miał o nich pojęcia od początku do końca. Czyli trzeba mu je schować. Jako, że mam tendencje do utrudniania sobie życia, to zrobię to z wykorzystaniem integracji bazodanowego silnika Vaulta z MongoDB.

A do czego jest ta rura? cz.2

W poprzednim odcinku, opisałem czym jest macierz ryzyka i podstawowy problem z pomieszaniem pojęć. Ta istotna bariera w zrozumieniu czym ryzyko jest a czym nie jest, nie jest jedyną przeszkodą. Poniżej przedstawię kolejne istotne problemy, które są przynależne tej metodzie przedstawiania ryzyk.Są to częściowo moje własne spostrzeżenia jak również wnioski z pogłębionej analizy problemu w oparciu o dostępną literaturę. Będzie trochę srogo.. :)

A do czego jest ta rura? cz.1

Za dwa dni minie dokładnie rok od publikacji pierwszego wpisu(w zamyśle - odcinka!) dotyczącego zagadnień związanych z analizami ryzyka. Plany kontynuacji były wielkie, a skończyło się jak zawsze? No, prawie. Zrobię sobie chwilę przerwy od mozolnej budowy mojego DevOpsowego labu i podejmę challenge.

Czego nie widzi bezpiecznik cz. 2

W poprzednim wpisie, starałem się wyjaśnić podstawowe terminy związane z ryzykiem. Jakim ryzykiem - biznesowym. Zaniepokojeni radiosłuchacze wnet zakrzyczą redaktora prowadzącego: “a co z ryzykiem IT, ryzykiem bezpieczeństwa IT”?!

Czego nie widzi bezpiecznik cz. 1

W poprzednim wpisie przedstawiłem perspektywę klasycznego bezpiecznika, z działu bezpieczeństwa IT (czy cyberbezpieczeństwa, itd.), który odpowiada za klasyczny model zarządzania bezpieczeństwem w firmie, poprzez polityki, standardy, okresowe przeglądy, listy wymagań, skanery podatności, audyty i akceptacje.

DevOps wg bezpiecznika

Wygląda, że wszystko jest w porządku, systemy są na bieżąco skanowane i patchowane wg wydań producentów, kontrola dostępu do wszystkiego jest, o! nawet MFA jest, programiści nie mają roota ani lokalnego admina.

Back to Top ↑

devops

Bezpieczna dostępność

Po wstępnych dywagacjach w poprzednim wpisie, pora podkasać rękawy i zabrać się do pracy. Naszymi dramatis personae będą stali bywalcy: Nomad, Consul i Vaulta oraz Traefik. Plan jest taki, aby mieć jeden ingress point (Traefik) dla mojej mikro-chmurki prywatnej, który nie tylko automatycznie wyniucha co w serwisach piszczy, a również automatycznie je obsłuży wraz z TLS.

Wstęp do wysokiej dostępności

Ostatnie dwa odcinki mojej domowej devopsowej epopei doprowadziły mnie do fajnie działającego deploymentu aplikacji z bazą danych. Uwzględniając zabezpieczenie wszelkich danych uwierzytelniających (kredek) - tak jak to powinno wyglądać, co do zasady. Ale to nie wszystko..

Closing thoughts on DevOps

Throughout my short DevOps team member and manager career I used to take notes. All in English. Hence this post in English. It outlines some thoughts and experience gathered along the line confronted with hints and knowledge taken from good readings I studied. The readings are listed at the end of this post.

Kto schował kredki?

Odpowiedź może być jedna - Nomad. A konkretnie Nomad zintegrowany z Vaultem. Ogólnie to plan jest taki, aby kredki do bazy były bezpieczne, nie jakieś tam .env na laptopie developera (w najlepszym wypadku, i tak wrzucane do repo) czy, o zgrozo! w jakimś pliku .txt. Opcje są dwie - albo je przenieść jako secrets do GitHuba w repozytorium aplikacji albo zabezpieczyć tak, żeby nawet programista nie miał o nich pojęcia od początku do końca. Czyli trzeba mu je schować. Jako, że mam tendencje do utrudniania sobie życia, to zrobię to z wykorzystaniem integracji bazodanowego silnika Vaulta z MongoDB.

Jak powiększyć krowie przestrzeń?

W ferworze walki o lepsze (bo zautomatyzowane) jutro, zacząłem ćwiczyć automatyzację dla szybkiego tworzenia i odpalania wirtualnej maszynki w KVMie. Okazało się, że obraz z bazowej Fedory Cloud 34 jest nieco za mały pod niektóre potrzeby (5GB). Padło, leninowskie “co robić?”.

Czego nie widzi bezpiecznik cz. 2

W poprzednim wpisie, starałem się wyjaśnić podstawowe terminy związane z ryzykiem. Jakim ryzykiem - biznesowym. Zaniepokojeni radiosłuchacze wnet zakrzyczą redaktora prowadzącego: “a co z ryzykiem IT, ryzykiem bezpieczeństwa IT”?!

Czego nie widzi bezpiecznik cz. 1

W poprzednim wpisie przedstawiłem perspektywę klasycznego bezpiecznika, z działu bezpieczeństwa IT (czy cyberbezpieczeństwa, itd.), który odpowiada za klasyczny model zarządzania bezpieczeństwem w firmie, poprzez polityki, standardy, okresowe przeglądy, listy wymagań, skanery podatności, audyty i akceptacje.

DevOps wg bezpiecznika

Wygląda, że wszystko jest w porządku, systemy są na bieżąco skanowane i patchowane wg wydań producentów, kontrola dostępu do wszystkiego jest, o! nawet MFA jest, programiści nie mają roota ani lokalnego admina.

Alternatywa dla Kubernetes.

Trwa szał na wdrażanie “kubków” (czyli Kubernetesa). Czasem mocno na siłę. Niepotrzebnie. Często zaniepokojeni radiosłuchacze pytają - “jeśli nie docker swarm, docker-compose, to co jak nie Kubernetesy?!”. Jest jeszcze Nomad.

Back to Top ↑

ryzyko

Metryki bezpieczeństwa

Są takie książki do których trzeba się mentalnie i merytorycznie przygotować. A kiedy już się po nie sięgnie ich zawartość jest starannie czytana, ..i czytana ..i czytana, treść “obracana” w głowie, aż do pełnego zrozumienia. Ale też nie, że “Achaaa.. to tak działa!” i siup, następny rozdział. Trzeba to przerobić praktycznie.

A do czego jest ta rura? cz.2

W poprzednim odcinku, opisałem czym jest macierz ryzyka i podstawowy problem z pomieszaniem pojęć. Ta istotna bariera w zrozumieniu czym ryzyko jest a czym nie jest, nie jest jedyną przeszkodą. Poniżej przedstawię kolejne istotne problemy, które są przynależne tej metodzie przedstawiania ryzyk.Są to częściowo moje własne spostrzeżenia jak również wnioski z pogłębionej analizy problemu w oparciu o dostępną literaturę. Będzie trochę srogo.. :)

A do czego jest ta rura? cz.1

Za dwa dni minie dokładnie rok od publikacji pierwszego wpisu(w zamyśle - odcinka!) dotyczącego zagadnień związanych z analizami ryzyka. Plany kontynuacji były wielkie, a skończyło się jak zawsze? No, prawie. Zrobię sobie chwilę przerwy od mozolnej budowy mojego DevOpsowego labu i podejmę challenge.

Czego nie widzi bezpiecznik cz. 2

W poprzednim wpisie, starałem się wyjaśnić podstawowe terminy związane z ryzykiem. Jakim ryzykiem - biznesowym. Zaniepokojeni radiosłuchacze wnet zakrzyczą redaktora prowadzącego: “a co z ryzykiem IT, ryzykiem bezpieczeństwa IT”?!

Czego nie widzi bezpiecznik cz. 1

W poprzednim wpisie przedstawiłem perspektywę klasycznego bezpiecznika, z działu bezpieczeństwa IT (czy cyberbezpieczeństwa, itd.), który odpowiada za klasyczny model zarządzania bezpieczeństwem w firmie, poprzez polityki, standardy, okresowe przeglądy, listy wymagań, skanery podatności, audyty i akceptacje.

Back to Top ↑

Linux

Domowy lab - proaktywne BHP na budowie

Od ostatniego wpisu upłynęły prawie dwa dni. Tak to już jest, że każdy kolejny wpis jest katalizatorem i przyspieszaczem szarych komórek, powodującym, że “kuleczki” zaczynają się częściej zderzać (jeśli mają dość czasu, na takie fanaberie). :)

Domowy lab - na kursie i na ścieżce

Od ostatniego wpisu upłynęły ponad dwa miesiące. Cóż to się zadziało. Ano, zadziało się tyle, że wziąłem się za naukę programowania w JS, a konkretnie full-stack w express-ie, w dodatku jakimś tam MongoDB jeszcze. “Bleee” - mrukną niektórzy - “interpreter”. No tak, ale nie chciałem się rzucać od razu z motyką na Angulara. Aby nauczyć się pisać testy jednostkowe (ang. unit tests) w jest (dżestsie?!), czy akceptacyjne w Cypress-ie, muszę mieć jakąś aplikację której kod rozumiem. Więc wyszło mi tak, że musiałem ją sobie napisać sam.

Domowy lab - dodatek

Popełniając wpis na temat rejestru dockerowego, zrobiłem sobie przegląd poprzednich wpisów. Dotarło do mnie, że w sumie, przedstawiając mój pomysł na lab, nie przedstawiłem go do końca. Zabrakło obrazka jak widzę całość rozwiązania, chociażby z lotu wróbelka. Po drugie, primo - w tzw. międzyczasie, zmieniłem plany co do GitLaba-CE. Skoro od dłuższego czasu korzystam z GitHuba, to czas najwyższy zacząć używać ostatnio wdrożone funkcjonalności, jak: skanowanie kodu, mechanizm analizy zależności Dependabot i last, but not least.. GitHub Actions na lokalnie zainstalowanym GitHub runnerze.

Domowy lab cz.3

Docker registry jest kolejnym komponentem, który będzie użyteczny w moim mozolnie budowanym labie. Jest to rejestr obrazów dokerowych, które ściągnę lub zbuduję, a które będę miał dostępne niejako pod ręką. Co więcej, lokalny GitHub runner też będzie miał do niego dostep, aby zbudować aplikację i wypchnąć jej obraz do tegoż rejestru.

Domowy lab cz.2

W pierwszej części przedstawiłem zarys domowego labu DevOps-owego. Natomiast w tym wpisie, chciałbym przedstawić prostą instalację jednego z istotnych komponentów takiego labu - SonarQube’a.

Domowy lab cz.1

Kilka labów w domu sobie już zbudowałem. W międzyczasie, zacząłem się uczyć Ansibla i w ramach tej nauki, postanowiłem stawianie takiego labu zautomatyzować.

Jak powiększyć krowie przestrzeń?

W ferworze walki o lepsze (bo zautomatyzowane) jutro, zacząłem ćwiczyć automatyzację dla szybkiego tworzenia i odpalania wirtualnej maszynki w KVMie. Okazało się, że obraz z bazowej Fedory Cloud 34 jest nieco za mały pod niektóre potrzeby (5GB). Padło, leninowskie “co robić?”.

Back to Top ↑

vault

Szybki sposób zabezpieczenia kredek w Terraformie

Siedzę sobie nad projektem w AWSie, terraformując zawzięcie. Niczego wrażliwego nie publikuję na GitHubie, aczkolwiek pałętają mi się po dysku pliki stanu terraforma (terraform.tfstate). Gdybym miał w domu korporację, w której dbano by o security, cybersecurity, compliance, ochronę danych osobowych, danych wrażliwych, tajemnicę bankową, i wszelkie inne bardzo tajne i super-wrażliwe tajemnice, to musiałbym pewnie użyć (i zapłacić!) Terraform Cloud-a jako “provider-a” dla terraforma. Albo co najmniej szyfrowanego S3 z włączonym wersjonowaniem i własnym kluczem szyfrującym.

Bezpieczna dostępność

Po wstępnych dywagacjach w poprzednim wpisie, pora podkasać rękawy i zabrać się do pracy. Naszymi dramatis personae będą stali bywalcy: Nomad, Consul i Vaulta oraz Traefik. Plan jest taki, aby mieć jeden ingress point (Traefik) dla mojej mikro-chmurki prywatnej, który nie tylko automatycznie wyniucha co w serwisach piszczy, a również automatycznie je obsłuży wraz z TLS.

Wstęp do wysokiej dostępności

Ostatnie dwa odcinki mojej domowej devopsowej epopei doprowadziły mnie do fajnie działającego deploymentu aplikacji z bazą danych. Uwzględniając zabezpieczenie wszelkich danych uwierzytelniających (kredek) - tak jak to powinno wyglądać, co do zasady. Ale to nie wszystko..

Kto schował kredki?

Odpowiedź może być jedna - Nomad. A konkretnie Nomad zintegrowany z Vaultem. Ogólnie to plan jest taki, aby kredki do bazy były bezpieczne, nie jakieś tam .env na laptopie developera (w najlepszym wypadku, i tak wrzucane do repo) czy, o zgrozo! w jakimś pliku .txt. Opcje są dwie - albo je przenieść jako secrets do GitHuba w repozytorium aplikacji albo zabezpieczyć tak, żeby nawet programista nie miał o nich pojęcia od początku do końca. Czyli trzeba mu je schować. Jako, że mam tendencje do utrudniania sobie życia, to zrobię to z wykorzystaniem integracji bazodanowego silnika Vaulta z MongoDB.

Back to Top ↑

hashicorp

Bezpieczna dostępność

Po wstępnych dywagacjach w poprzednim wpisie, pora podkasać rękawy i zabrać się do pracy. Naszymi dramatis personae będą stali bywalcy: Nomad, Consul i Vaulta oraz Traefik. Plan jest taki, aby mieć jeden ingress point (Traefik) dla mojej mikro-chmurki prywatnej, który nie tylko automatycznie wyniucha co w serwisach piszczy, a również automatycznie je obsłuży wraz z TLS.

Wstęp do wysokiej dostępności

Ostatnie dwa odcinki mojej domowej devopsowej epopei doprowadziły mnie do fajnie działającego deploymentu aplikacji z bazą danych. Uwzględniając zabezpieczenie wszelkich danych uwierzytelniających (kredek) - tak jak to powinno wyglądać, co do zasady. Ale to nie wszystko..

Kto schował kredki?

Odpowiedź może być jedna - Nomad. A konkretnie Nomad zintegrowany z Vaultem. Ogólnie to plan jest taki, aby kredki do bazy były bezpieczne, nie jakieś tam .env na laptopie developera (w najlepszym wypadku, i tak wrzucane do repo) czy, o zgrozo! w jakimś pliku .txt. Opcje są dwie - albo je przenieść jako secrets do GitHuba w repozytorium aplikacji albo zabezpieczyć tak, żeby nawet programista nie miał o nich pojęcia od początku do końca. Czyli trzeba mu je schować. Jako, że mam tendencje do utrudniania sobie życia, to zrobię to z wykorzystaniem integracji bazodanowego silnika Vaulta z MongoDB.

Back to Top ↑

nomad

Bezpieczna dostępność

Po wstępnych dywagacjach w poprzednim wpisie, pora podkasać rękawy i zabrać się do pracy. Naszymi dramatis personae będą stali bywalcy: Nomad, Consul i Vaulta oraz Traefik. Plan jest taki, aby mieć jeden ingress point (Traefik) dla mojej mikro-chmurki prywatnej, który nie tylko automatycznie wyniucha co w serwisach piszczy, a również automatycznie je obsłuży wraz z TLS.

Wstęp do wysokiej dostępności

Ostatnie dwa odcinki mojej domowej devopsowej epopei doprowadziły mnie do fajnie działającego deploymentu aplikacji z bazą danych. Uwzględniając zabezpieczenie wszelkich danych uwierzytelniających (kredek) - tak jak to powinno wyglądać, co do zasady. Ale to nie wszystko..

Kto schował kredki?

Odpowiedź może być jedna - Nomad. A konkretnie Nomad zintegrowany z Vaultem. Ogólnie to plan jest taki, aby kredki do bazy były bezpieczne, nie jakieś tam .env na laptopie developera (w najlepszym wypadku, i tak wrzucane do repo) czy, o zgrozo! w jakimś pliku .txt. Opcje są dwie - albo je przenieść jako secrets do GitHuba w repozytorium aplikacji albo zabezpieczyć tak, żeby nawet programista nie miał o nich pojęcia od początku do końca. Czyli trzeba mu je schować. Jako, że mam tendencje do utrudniania sobie życia, to zrobię to z wykorzystaniem integracji bazodanowego silnika Vaulta z MongoDB.

Back to Top ↑

psychologia

A do czego jest ta rura? cz.2

W poprzednim odcinku, opisałem czym jest macierz ryzyka i podstawowy problem z pomieszaniem pojęć. Ta istotna bariera w zrozumieniu czym ryzyko jest a czym nie jest, nie jest jedyną przeszkodą. Poniżej przedstawię kolejne istotne problemy, które są przynależne tej metodzie przedstawiania ryzyk.Są to częściowo moje własne spostrzeżenia jak również wnioski z pogłębionej analizy problemu w oparciu o dostępną literaturę. Będzie trochę srogo.. :)

A do czego jest ta rura? cz.1

Za dwa dni minie dokładnie rok od publikacji pierwszego wpisu(w zamyśle - odcinka!) dotyczącego zagadnień związanych z analizami ryzyka. Plany kontynuacji były wielkie, a skończyło się jak zawsze? No, prawie. Zrobię sobie chwilę przerwy od mozolnej budowy mojego DevOpsowego labu i podejmę challenge.

Back to Top ↑

GitHub

Domowy lab - proaktywne BHP na budowie

Od ostatniego wpisu upłynęły prawie dwa dni. Tak to już jest, że każdy kolejny wpis jest katalizatorem i przyspieszaczem szarych komórek, powodującym, że “kuleczki” zaczynają się częściej zderzać (jeśli mają dość czasu, na takie fanaberie). :)

Domowy lab - na kursie i na ścieżce

Od ostatniego wpisu upłynęły ponad dwa miesiące. Cóż to się zadziało. Ano, zadziało się tyle, że wziąłem się za naukę programowania w JS, a konkretnie full-stack w express-ie, w dodatku jakimś tam MongoDB jeszcze. “Bleee” - mrukną niektórzy - “interpreter”. No tak, ale nie chciałem się rzucać od razu z motyką na Angulara. Aby nauczyć się pisać testy jednostkowe (ang. unit tests) w jest (dżestsie?!), czy akceptacyjne w Cypress-ie, muszę mieć jakąś aplikację której kod rozumiem. Więc wyszło mi tak, że musiałem ją sobie napisać sam.

Domowy lab - dodatek

Popełniając wpis na temat rejestru dockerowego, zrobiłem sobie przegląd poprzednich wpisów. Dotarło do mnie, że w sumie, przedstawiając mój pomysł na lab, nie przedstawiłem go do końca. Zabrakło obrazka jak widzę całość rozwiązania, chociażby z lotu wróbelka. Po drugie, primo - w tzw. międzyczasie, zmieniłem plany co do GitLaba-CE. Skoro od dłuższego czasu korzystam z GitHuba, to czas najwyższy zacząć używać ostatnio wdrożone funkcjonalności, jak: skanowanie kodu, mechanizm analizy zależności Dependabot i last, but not least.. GitHub Actions na lokalnie zainstalowanym GitHub runnerze.

Back to Top ↑

KVM

Domowy lab cz.2

W pierwszej części przedstawiłem zarys domowego labu DevOps-owego. Natomiast w tym wpisie, chciałbym przedstawić prostą instalację jednego z istotnych komponentów takiego labu - SonarQube’a.

Domowy lab cz.1

Kilka labów w domu sobie już zbudowałem. W międzyczasie, zacząłem się uczyć Ansibla i w ramach tej nauki, postanowiłem stawianie takiego labu zautomatyzować.

Jak powiększyć krowie przestrzeń?

W ferworze walki o lepsze (bo zautomatyzowane) jutro, zacząłem ćwiczyć automatyzację dla szybkiego tworzenia i odpalania wirtualnej maszynki w KVMie. Okazało się, że obraz z bazowej Fedory Cloud 34 jest nieco za mały pod niektóre potrzeby (5GB). Padło, leninowskie “co robić?”.

Back to Top ↑

Ansible

Domowy lab cz.2

W pierwszej części przedstawiłem zarys domowego labu DevOps-owego. Natomiast w tym wpisie, chciałbym przedstawić prostą instalację jednego z istotnych komponentów takiego labu - SonarQube’a.

Domowy lab cz.1

Kilka labów w domu sobie już zbudowałem. W międzyczasie, zacząłem się uczyć Ansibla i w ramach tej nauki, postanowiłem stawianie takiego labu zautomatyzować.

Back to Top ↑

devsecops

O bezpieczeństwie domowego IoT

Na sam tytuł, moja żona wymownie przewraca oczami.. Kiedy mówię, że każde gniazdko ma swój login i hasło, puka się w głowę. Po prostu wie, że żyje z lekko stukniętym typem pod jednym dachem. Ale, jak to pisze mój kolega-filozof, janieotym.

Back to Top ↑

docker

O bezpieczeństwie domowego IoT

Na sam tytuł, moja żona wymownie przewraca oczami.. Kiedy mówię, że każde gniazdko ma swój login i hasło, puka się w głowę. Po prostu wie, że żyje z lekko stukniętym typem pod jednym dachem. Ale, jak to pisze mój kolega-filozof, janieotym.

Back to Top ↑

gosund

O bezpieczeństwie domowego IoT cz. 2

Poprzedni odcinek mojej osobistej rozprawy z bezpieczeństwem IoT zakończyłem może nieco przedwcześnie. Ba! na pewno! Jeżeli jesteśmy jednak chociaż trochę zainteresowani metodyką MITRE ATT&CK to warto poświęcić jej cały kolejny wpis. Będzie to bowiem nakreślenie całkiem fajnej, logicznej, elastycznej i szybkiej metody podejścia do projektowania zabezpieczeń w świecie IT. Wyjście z profilu zagrożeń (scenariuszy) do nakreślenia architektury bezpieczeństwa rozwiązania i (mam nadzieję) zgrabne przejście do samych technikaliów w części trzeciej (kolejnym, ostatnim już wpisie o IoT). No tak, znowu miało być technicznie, a wyjdzie analitycznie. Bardzo jednak chcę wykonać to ćwiczenie z ATT&CK-iem, by nawet samemu sobie zademonstrować przydatność tej metodyki.

O bezpieczeństwie domowego IoT

Na sam tytuł, moja żona wymownie przewraca oczami.. Kiedy mówię, że każde gniazdko ma swój login i hasło, puka się w głowę. Po prostu wie, że żyje z lekko stukniętym typem pod jednym dachem. Ale, jak to pisze mój kolega-filozof, janieotym.

Back to Top ↑

iot

O bezpieczeństwie domowego IoT cz. 2

Poprzedni odcinek mojej osobistej rozprawy z bezpieczeństwem IoT zakończyłem może nieco przedwcześnie. Ba! na pewno! Jeżeli jesteśmy jednak chociaż trochę zainteresowani metodyką MITRE ATT&CK to warto poświęcić jej cały kolejny wpis. Będzie to bowiem nakreślenie całkiem fajnej, logicznej, elastycznej i szybkiej metody podejścia do projektowania zabezpieczeń w świecie IT. Wyjście z profilu zagrożeń (scenariuszy) do nakreślenia architektury bezpieczeństwa rozwiązania i (mam nadzieję) zgrabne przejście do samych technikaliów w części trzeciej (kolejnym, ostatnim już wpisie o IoT). No tak, znowu miało być technicznie, a wyjdzie analitycznie. Bardzo jednak chcę wykonać to ćwiczenie z ATT&CK-iem, by nawet samemu sobie zademonstrować przydatność tej metodyki.

O bezpieczeństwie domowego IoT

Na sam tytuł, moja żona wymownie przewraca oczami.. Kiedy mówię, że każde gniazdko ma swój login i hasło, puka się w głowę. Po prostu wie, że żyje z lekko stukniętym typem pod jednym dachem. Ale, jak to pisze mój kolega-filozof, janieotym.

Back to Top ↑

mqtt

O bezpieczeństwie domowego IoT cz. 2

Poprzedni odcinek mojej osobistej rozprawy z bezpieczeństwem IoT zakończyłem może nieco przedwcześnie. Ba! na pewno! Jeżeli jesteśmy jednak chociaż trochę zainteresowani metodyką MITRE ATT&CK to warto poświęcić jej cały kolejny wpis. Będzie to bowiem nakreślenie całkiem fajnej, logicznej, elastycznej i szybkiej metody podejścia do projektowania zabezpieczeń w świecie IT. Wyjście z profilu zagrożeń (scenariuszy) do nakreślenia architektury bezpieczeństwa rozwiązania i (mam nadzieję) zgrabne przejście do samych technikaliów w części trzeciej (kolejnym, ostatnim już wpisie o IoT). No tak, znowu miało być technicznie, a wyjdzie analitycznie. Bardzo jednak chcę wykonać to ćwiczenie z ATT&CK-iem, by nawet samemu sobie zademonstrować przydatność tej metodyki.

O bezpieczeństwie domowego IoT

Na sam tytuł, moja żona wymownie przewraca oczami.. Kiedy mówię, że każde gniazdko ma swój login i hasło, puka się w głowę. Po prostu wie, że żyje z lekko stukniętym typem pod jednym dachem. Ale, jak to pisze mój kolega-filozof, janieotym.

Back to Top ↑

prawdopodobieństwo

A do czego jest ta rura? cz.2

W poprzednim odcinku, opisałem czym jest macierz ryzyka i podstawowy problem z pomieszaniem pojęć. Ta istotna bariera w zrozumieniu czym ryzyko jest a czym nie jest, nie jest jedyną przeszkodą. Poniżej przedstawię kolejne istotne problemy, które są przynależne tej metodzie przedstawiania ryzyk.Są to częściowo moje własne spostrzeżenia jak również wnioski z pogłębionej analizy problemu w oparciu o dostępną literaturę. Będzie trochę srogo.. :)

Back to Top ↑

tasmota

O bezpieczeństwie domowego IoT cz. 2

Poprzedni odcinek mojej osobistej rozprawy z bezpieczeństwem IoT zakończyłem może nieco przedwcześnie. Ba! na pewno! Jeżeli jesteśmy jednak chociaż trochę zainteresowani metodyką MITRE ATT&CK to warto poświęcić jej cały kolejny wpis. Będzie to bowiem nakreślenie całkiem fajnej, logicznej, elastycznej i szybkiej metody podejścia do projektowania zabezpieczeń w świecie IT. Wyjście z profilu zagrożeń (scenariuszy) do nakreślenia architektury bezpieczeństwa rozwiązania i (mam nadzieję) zgrabne przejście do samych technikaliów w części trzeciej (kolejnym, ostatnim już wpisie o IoT). No tak, znowu miało być technicznie, a wyjdzie analitycznie. Bardzo jednak chcę wykonać to ćwiczenie z ATT&CK-iem, by nawet samemu sobie zademonstrować przydatność tej metodyki.

O bezpieczeństwie domowego IoT

Na sam tytuł, moja żona wymownie przewraca oczami.. Kiedy mówię, że każde gniazdko ma swój login i hasło, puka się w głowę. Po prostu wie, że żyje z lekko stukniętym typem pod jednym dachem. Ale, jak to pisze mój kolega-filozof, janieotym.

Back to Top ↑

Bayes

Back to Top ↑

Consul

Domowy lab cz.3

Docker registry jest kolejnym komponentem, który będzie użyteczny w moim mozolnie budowanym labie. Jest to rejestr obrazów dokerowych, które ściągnę lub zbuduję, a które będę miał dostępne niejako pod ręką. Co więcej, lokalny GitHub runner też będzie miał do niego dostep, aby zbudować aplikację i wypchnąć jej obraz do tegoż rejestru.

Back to Top ↑

Docker

Domowy lab cz.3

Docker registry jest kolejnym komponentem, który będzie użyteczny w moim mozolnie budowanym labie. Jest to rejestr obrazów dokerowych, które ściągnę lub zbuduję, a które będę miał dostępne niejako pod ręką. Co więcej, lokalny GitHub runner też będzie miał do niego dostep, aby zbudować aplikację i wypchnąć jej obraz do tegoż rejestru.

Back to Top ↑

Hashicorp

Alternatywa dla Kubernetes.

Trwa szał na wdrażanie “kubków” (czyli Kubernetesa). Czasem mocno na siłę. Niepotrzebnie. Często zaniepokojeni radiosłuchacze pytają - “jeśli nie docker swarm, docker-compose, to co jak nie Kubernetesy?!”. Jest jeszcze Nomad.

Back to Top ↑

MITRE

O bezpieczeństwie domowego IoT cz. 2

Poprzedni odcinek mojej osobistej rozprawy z bezpieczeństwem IoT zakończyłem może nieco przedwcześnie. Ba! na pewno! Jeżeli jesteśmy jednak chociaż trochę zainteresowani metodyką MITRE ATT&CK to warto poświęcić jej cały kolejny wpis. Będzie to bowiem nakreślenie całkiem fajnej, logicznej, elastycznej i szybkiej metody podejścia do projektowania zabezpieczeń w świecie IT. Wyjście z profilu zagrożeń (scenariuszy) do nakreślenia architektury bezpieczeństwa rozwiązania i (mam nadzieję) zgrabne przejście do samych technikaliów w części trzeciej (kolejnym, ostatnim już wpisie o IoT). No tak, znowu miało być technicznie, a wyjdzie analitycznie. Bardzo jednak chcę wykonać to ćwiczenie z ATT&CK-iem, by nawet samemu sobie zademonstrować przydatność tej metodyki.

Back to Top ↑

Nomad

Domowy lab cz.3

Docker registry jest kolejnym komponentem, który będzie użyteczny w moim mozolnie budowanym labie. Jest to rejestr obrazów dokerowych, które ściągnę lub zbuduję, a które będę miał dostępne niejako pod ręką. Co więcej, lokalny GitHub runner też będzie miał do niego dostep, aby zbudować aplikację i wypchnąć jej obraz do tegoż rejestru.

Back to Top ↑

Sonarqube

Domowy lab cz.2

W pierwszej części przedstawiłem zarys domowego labu DevOps-owego. Natomiast w tym wpisie, chciałbym przedstawić prostą instalację jednego z istotnych komponentów takiego labu - SonarQube’a.

Back to Top ↑

analizadanych

Metryki bezpieczeństwa

Są takie książki do których trzeba się mentalnie i merytorycznie przygotować. A kiedy już się po nie sięgnie ich zawartość jest starannie czytana, ..i czytana ..i czytana, treść “obracana” w głowie, aż do pełnego zrozumienia. Ale też nie, że “Achaaa.. to tak działa!” i siup, następny rozdział. Trzeba to przerobić praktycznie.

Back to Top ↑

aws

Szybki sposób zabezpieczenia kredek w Terraformie

Siedzę sobie nad projektem w AWSie, terraformując zawzięcie. Niczego wrażliwego nie publikuję na GitHubie, aczkolwiek pałętają mi się po dysku pliki stanu terraforma (terraform.tfstate). Gdybym miał w domu korporację, w której dbano by o security, cybersecurity, compliance, ochronę danych osobowych, danych wrażliwych, tajemnicę bankową, i wszelkie inne bardzo tajne i super-wrażliwe tajemnice, to musiałbym pewnie użyć (i zapłacić!) Terraform Cloud-a jako “provider-a” dla terraforma. Albo co najmniej szyfrowanego S3 z włączonym wersjonowaniem i własnym kluczem szyfrującym.

Back to Top ↑

cfssl

Domowy lab cz.1

Kilka labów w domu sobie już zbudowałem. W międzyczasie, zacząłem się uczyć Ansibla i w ramach tej nauki, postanowiłem stawianie takiego labu zautomatyzować.

Back to Top ↑

consul

Szybki sposób zabezpieczenia kredek w Terraformie

Siedzę sobie nad projektem w AWSie, terraformując zawzięcie. Niczego wrażliwego nie publikuję na GitHubie, aczkolwiek pałętają mi się po dysku pliki stanu terraforma (terraform.tfstate). Gdybym miał w domu korporację, w której dbano by o security, cybersecurity, compliance, ochronę danych osobowych, danych wrażliwych, tajemnicę bankową, i wszelkie inne bardzo tajne i super-wrażliwe tajemnice, to musiałbym pewnie użyć (i zapłacić!) Terraform Cloud-a jako “provider-a” dla terraforma. Albo co najmniej szyfrowanego S3 z włączonym wersjonowaniem i własnym kluczem szyfrującym.

Back to Top ↑

english

Closing thoughts on DevOps

Throughout my short DevOps team member and manager career I used to take notes. All in English. Hence this post in English. It outlines some thoughts and experience gathered along the line confronted with hints and knowledge taken from good readings I studied. The readings are listed at the end of this post.

Back to Top ↑

influxdb

O bezpieczeństwie domowego IoT

Na sam tytuł, moja żona wymownie przewraca oczami.. Kiedy mówię, że każde gniazdko ma swój login i hasło, puka się w głowę. Po prostu wie, że żyje z lekko stukniętym typem pod jednym dachem. Ale, jak to pisze mój kolega-filozof, janieotym.

Back to Top ↑

metryki

Metryki bezpieczeństwa

Są takie książki do których trzeba się mentalnie i merytorycznie przygotować. A kiedy już się po nie sięgnie ich zawartość jest starannie czytana, ..i czytana ..i czytana, treść “obracana” w głowie, aż do pełnego zrozumienia. Ale też nie, że “Achaaa.. to tak działa!” i siup, następny rozdział. Trzeba to przerobić praktycznie.

Back to Top ↑

python

Metryki bezpieczeństwa

Są takie książki do których trzeba się mentalnie i merytorycznie przygotować. A kiedy już się po nie sięgnie ich zawartość jest starannie czytana, ..i czytana ..i czytana, treść “obracana” w głowie, aż do pełnego zrozumienia. Ale też nie, że “Achaaa.. to tak działa!” i siup, następny rozdział. Trzeba to przerobić praktycznie.

Back to Top ↑

registry

Domowy lab cz.3

Docker registry jest kolejnym komponentem, który będzie użyteczny w moim mozolnie budowanym labie. Jest to rejestr obrazów dokerowych, które ściągnę lub zbuduję, a które będę miał dostępne niejako pod ręką. Co więcej, lokalny GitHub runner też będzie miał do niego dostep, aby zbudować aplikację i wypchnąć jej obraz do tegoż rejestru.

Back to Top ↑

terraform

Szybki sposób zabezpieczenia kredek w Terraformie

Siedzę sobie nad projektem w AWSie, terraformując zawzięcie. Niczego wrażliwego nie publikuję na GitHubie, aczkolwiek pałętają mi się po dysku pliki stanu terraforma (terraform.tfstate). Gdybym miał w domu korporację, w której dbano by o security, cybersecurity, compliance, ochronę danych osobowych, danych wrażliwych, tajemnicę bankową, i wszelkie inne bardzo tajne i super-wrażliwe tajemnice, to musiałbym pewnie użyć (i zapłacić!) Terraform Cloud-a jako “provider-a” dla terraforma. Albo co najmniej szyfrowanego S3 z włączonym wersjonowaniem i własnym kluczem szyfrującym.

Back to Top ↑

traefik

Bezpieczna dostępność

Po wstępnych dywagacjach w poprzednim wpisie, pora podkasać rękawy i zabrać się do pracy. Naszymi dramatis personae będą stali bywalcy: Nomad, Consul i Vaulta oraz Traefik. Plan jest taki, aby mieć jeden ingress point (Traefik) dla mojej mikro-chmurki prywatnej, który nie tylko automatycznie wyniucha co w serwisach piszczy, a również automatycznie je obsłuży wraz z TLS.

Back to Top ↑