Bezpieczeństwo Home Assistant: co jest realnym zagrożeniem, a co straszeniem

Po module 7 możesz już korzystać z Home Assistant poza domem, na przykład przez Nabu Casa, VPN, Tailscale albo Cloudflare Tunnel. To wygodne, ale oznacza też większą odpowiedzialność. Panel, który wcześniej był dostępny tylko w domowej sieci, może teraz otwierać się również z telefonu korzystającego z internetu.

W tej lekcji nazwa aplikacja oznacza składnik instalowany obok Core w HAOS, dawniej nazywany dodatkiem. Integracja i aplikacja mobilna Companion są osobnymi pojęciami. Nie każda instalacja udostępnia aplikacje zarządzane przez Supervisor.

Zanim dodamy więcej urządzeń, Zigbee, ESPHome, panelów i automatyzacji, warto uporządkować podstawy bezpieczeństwa. Nie chodzi o budowanie skomplikowanych zabezpieczeń ani o straszenie atakami. Chodzi o proste nawyki, które później oszczędzają nerwy: osobne konta, mocne hasła, uwierzytelnianie wieloskładnikowe, kopie zapasowe i plan na awarię.

Na tę lekcję przeznacz około 25 minut. Nie musisz od razu naprawić wszystkiego. Sukcesem jest uczciwe ustalenie, które elementy są już uporządkowane, a które wymagają poprawy. To czas pierwszego przejścia przez zasady. Audyt własnych aplikacji i test powiadomień zaplanuj osobno, gdy masz działający dostęp lokalny.

Dlaczego Home Assistant wymaga szczególnej uwagi

Home Assistant nie jest zwykłą aplikacją pokazującą temperaturę. Z czasem może sterować oświetleniem, roletami, ogrzewaniem, bramą, zamkami, alarmem, energią i urządzeniami domowników. Może również przechowywać informacje o obecności, historii działania urządzeń oraz sposobie korzystania z domu.

Im więcej integracji dodasz, tym bardziej Home Assistant przypomina centralny panel sterowania. Konto administratora pozwala nie tylko przeglądać dane, lecz także zmieniać konfigurację, dodawać integracje, zarządzać użytkownikami i wpływać na działanie automatyzacji.

Dlatego bezpieczeństwo najlepiej uporządkować teraz, gdy system jest jeszcze niewielki. Zmiana wspólnego konta na osobne konta dla kilku osób jest łatwa. Porządkowanie tego samego po kilku latach, gdy z jednego konta korzysta cała rodzina, jest znacznie trudniejsze.

Bezpieczeństwo systemu a bezpieczeństwo domu

Bezpieczeństwo systemu obejmuje konta, hasła, MFA, aktualizacje, tokeny, kopie zapasowe, dostęp zdalny i możliwość odzyskania systemu po awarii.

Bezpieczeństwo domu obejmuje między innymi czujniki dymu, zalania, otwarcia drzwi, syreny, alarm oraz reakcje na niebezpieczne zdarzenia. Oba tematy są ważne, ale rozwiązują inne problemy.

Najczęstsze realne ryzyka

Początkujący najczęściej nie popełniają skomplikowanych błędów technicznych. Problemy wynikają raczej z kilku prostych zaniedbań, które długo pozostają niezauważone.

• słabe albo używane również w innych serwisach hasło administratora,
• brak MFA na koncie z największymi uprawnieniami,
• jedno wspólne konto dla całej rodziny,
• konto administratora na tablecie ściennym,
• niepotrzebnie przekierowany port prowadzący do HA,
• nieaktualny Home Assistant, aplikacje lub integracje niestandardowe,
• brak kopii zapasowej albo kopia przechowywana wyłącznie na tym samym dysku,
• tokeny i hasła wklejone do publicznego forum lub repozytorium,
• instalowanie aplikacji z przypadkowych źródeł,
• wklejanie konfiguracji YAML bez rozumienia jej działania,
• publikowanie kolejnych paneli administracyjnych tylko dlatego, że tunel już działa.

Nie każde ryzyko wymaga zaawansowanych narzędzi

Nie zaczynam zabezpieczania domu od listy zaawansowanych narzędzi. VLAN-y, rozbudowana zapora, system wykrywania włamań czy serwer proxy mogą być przydatne, ale podstawowe problemy trzeba rozwiązać niezależnie od nich. Najpierw chcę wiedzieć, kto ma dostęp, jak chronione są konta i jak odzyskam system. Dopiero do rozpoznanej potrzeby dobieram kolejną warstwę ochrony.

• Cloudflare Tunnel nie przenosi Home Assistant do chmury. System nadal działa na Twoim serwerze.
• Nabu Casa nie jest automatycznie mniej bezpieczne tylko dlatego, że jest usługą zewnętrzną.
• VPN nie chroni przed każdym problemem, szczególnie gdy zgubiony telefon pozostaje odblokowany i ma aktywny profil.
• VLAN nie naprawi słabego hasła administratora.
• Cloudflare Access nie zastępuje kont i uprawnień w Home Assistant.

Dostęp lokalny i zdalny mają inny profil ryzyka

Dostęp lokalny oznacza, że panel działa w domowej sieci Wi-Fi albo po kablu. Osoba spoza domu zwykle nie może bezpośrednio otworzyć lokalnego adresu.

Dostęp zdalny pozwala połączyć się spoza domu. Może to być publiczny adres Nabu Casa lub Cloudflare albo prywatne połączenie VPN.

Publiczny adres zwiększa znaczenie mocnego logowania, ale dostęp tylko lokalny także wymaga porządku. Domownik, gość, zgubiony telefon albo niezablokowany tablet mogą stać się źródłem problemu bez udziału internetu.

Nie publikuj kolejnych paneli bez osobnego planu

Po skonfigurowaniu tunelu łatwo dojść do wniosku, że można szybko dodać kolejne subdomeny. Technicznie jest to możliwe, ale każda nowa usługa ma własne konto, mechanizm logowania, historię aktualizacji i potencjalne błędy.

• panel routera daje dostęp do ustawień całej sieci,
• Proxmox pozwala zarządzać maszynami wirtualnymi i kontenerami,
• NAS przechowuje pliki i często kopie zapasowe,
• panel kamer może ujawniać obraz z domu,
• narzędzia deweloperskie i bazy danych mogą nie być przeznaczone do publicznego internetu.

Minimum bezpieczeństwa na obecnym etapie

MFA jest najważniejsze na koncie administratora, ale warto włączyć je również na pozostałych kontach używanych poza domem. Zwykły użytkownik ma mniej uprawnień niż administrator, lecz nadal może widzieć dane o obecności, historię urządzeń i elementy panelu oraz sterować udostępnionymi urządzeniami.

Każdy użytkownik powinien korzystać z własnego konta. Dzięki temu po zgubieniu telefonu, odejściu domownika albo zmianie urządzenia możesz odebrać dostęp jednej osobie bez zmieniania hasła wszystkim pozostałym.

Szybki audyt na start

Odpowiedz na poniższe pytania bez zgadywania. Odpowiedź „nie wiem” jest cenna, ponieważ wskazuje rzecz, którą trzeba sprawdzić.

Zagrożenie z internetu i problem we własnym domu

Zagrożenie zewnętrzne to próba dostępu przez internet, skradzione hasło albo wykorzystanie błędu w nieaktualnym oprogramowaniu.

Zagrożenie wewnętrzne nie musi oznaczać celowego działania domownika. Może to być dziecko korzystające z tabletu zalogowanego jako administrator, gość mający dostęp do odblokowanego telefonu albo przypadkowe usunięcie integracji ze wspólnego konta.

Dlatego osobne konta i ograniczenie liczby administratorów chronią system nie tylko przed internetem. Chronią także przed zwykłymi pomyłkami.

Zalogowane urządzenia i zapisane sesje

Po zalogowaniu telefon zwykle otwiera panel bez ponownego pytania o hasło. Home Assistant rozpoznaje wcześniejsze logowanie dzięki tokenowi odświeżania, który podtrzymuje sesję urządzenia. To wygodne, ale oznacza, że sam odblokowany telefon może już dawać dostęp do domu. Dlatego przy przeglądzie bezpieczeństwa patrzę także na zapisane sesje, a nie tylko na siłę hasła.

To wygodne, ale ważne po zgubieniu telefonu albo sprzedaży starego tabletu. W profilu użytkownika można przejrzeć aktywne tokeny i usunąć ten należący do utraconego urządzenia. W lekcji 3 wykonamy tę procedurę krok po kroku.

Plan modułu 8

W kolejnych lekcjach zajmiemy się konkretnymi elementami zabezpieczenia systemu:

• Lekcja 2: konta użytkowników, administratorzy i MFA,
• Lekcja 3: hasła, tokeny i reakcja na zgubiony telefon,
• Lekcja 4: kopie zapasowe lokalne i przechowywane poza serwerem,
• Lekcja 5: bezpieczne podejście do aktualizacji,
• Lekcja 6: opcjonalna dodatkowa warstwa Cloudflare Access,
• Lekcja 7: plan awaryjny i odzyskiwanie systemu.

Przykład: tunel działa, ale czy system jest zabezpieczony

Załóżmy, że masz Cloudflare Tunnel i adres ha.twojadomena.pl. Panel działa z telefonu przez LTE. To potwierdza zdalny dostęp, ale nie odpowiada jeszcze na kilka ważnych pytań:

• czy konto administratora ma MFA,
• czy domownicy mają osobne konta,
• czy tablet ścienny nie jest administratorem,
• czy istnieje kopia zapasowa poza serwerem,
• czy wiesz, co zrobić po utracie telefonu,
• czy token tunelu nie został zapisany w publicznym miejscu.

Działający dostęp zdalny jest dopiero pierwszą częścią układanki. Druga część to kontrola kont, urządzeń i możliwości odzyskania systemu.

Podobnie jest z kopią zapasową. Sam fakt, że plik kopii istnieje, nie gwarantuje jeszcze, że potrafisz go odnaleźć i przywrócić. W lekcji 4 sprawdzimy nie tylko tworzenie kopii, lecz także miejsce jej przechowywania i podstawowy plan odtworzenia systemu.

Dodatkowa ochrona przed wieloma próbami logowania

Home Assistant może blokować adres IP po określonej liczbie nieudanych prób. To uzupełnienie ochrony kont, a nie jej zastępstwo. Ustawienia serwera HTTP od wersji 2026.8 znajdziesz w Ustawieniach > System > Sieć. Włączanie blokad i próg prób to osobne ustawienia. Wartość -1 wyłącza automatyczne dodawanie nowych blokad po osiągnięciu progu.

Przed zmianą sprawdź działającą sesję lokalną i adres klienta widoczny przez HA. Nie traktuj 5 prób jako uniwersalnego zalecenia. Próg dobierasz świadomie do używanych klientów; stara aplikacja lub skrypt z nieważnym tokenem również może generować błędy. Mechanizm nie jest opisany jako licznik prób na minutę. Udane uwierzytelnienie lub restart HA zerują licznik nieudanych prób, ale restart nie usuwa już zapisanej blokady.

Za reverse proxy lub cloudflared prawidłowo skonfiguruj zaufanego pośrednika i przekazywanie adresu klienta zgodnie z architekturą z modułu 7. Nie wpisuj całego LAN ani 0.0.0.0/0 jako zaufanego proxy. Inaczej blokada może objąć adres pośrednika i odebrać zdalny dostęp wielu użytkownikom. Nabu Casa jest osobnym przypadkiem: nie dodajemy trusted_proxies tylko z powodu korzystania z tej usługi.

Od Home Assistant 2026.9 Remote UI Nabu Casa przekazuje rzeczywisty adres klienta. W starszych wersjach mógł być widoczny 127.0.0.1, więc jego zablokowanie wpływało na całą tę drogę. Nawet poprawny publiczny adres może być współdzielony przez operatora komórkowego. Automatyczna blokada nie rozróżnia wszystkich ludzi korzystających z takiego adresu.

Zapis ustawień HTTP może wymagać restartu i potwierdzenia nowej konfiguracji. Postępuj według komunikatu interfejsu, sprawdź panel i potwierdź w przewidzianym czasie. Nie wywołuj serii błędów z jedynego urządzenia administracyjnego, aby przetestować próg.

Starsza konfiguracja YAML: tylko do rozpoznania podczas migracji

Poniższy historyczny przykład pokazuje wcześniejsze nazwy opcji. Wartość 5 jest przykładem składni, nie zaleceniem dla każdej instalacji. W aktualnej wersji korzystaj z ustawień serwera HTTP i dokumentacji migracji.

http:
  ip_ban_enabled: true
  login_attempts_threshold: 5

ip_ban_enabled odpowiada obsłudze blokad, a login_attempts_threshold progowi dodawania nowych adresów. Nie twórz drugiego bloku http i nie wklejaj tego fragmentu do aktualnego systemu jako dodatkowej warstwy.

Blokada jest zapisywana w ip_bans.yaml i nie wygasa automatycznie po ustalonym czasie. Jeśli zablokowano Twój adres, wejdź bezpieczną niezależną drogą, sprawdź przyczynę, usuń tylko właściwy wpis adresu wraz z jego danymi i zrestartuj HA. Zachowaj kopię pliku przed edycją. Nie kasuj wszystkich blokad bez ustalenia, co się wydarzyło. HTTP 403 może oznaczać blokadę, ale również odmowę w innej warstwie, dlatego sprawdzamy, kto zwrócił odpowiedź.

Od strachu do rejestru ryzyka

Zamiast próbować zabezpieczyć wszystko naraz, opisuję konkretną sytuację: co może wydarzyć się w moim domu, kto może do tego doprowadzić i po czym to zauważę? Nie każda luka kończy się włamaniem. Wspólne konto lub zapomniany token mogą jednak utrudnić odzyskanie kontroli. Taki opis pomaga wybrać poprawkę, która rozwiązuje rzeczywisty problem.

Tworzę rejestr na podstawie własnej instalacji, a nie nagłówków z internetu. Inaczej oceniam publiczny panel logowania, inaczej nieaktualny czujnik w odseparowanej sieci, a jeszcze inaczej zamek, alarm lub bramę. Ryzyko rośnie wraz z prawdopodobieństwem zdarzenia, skutkiem i trudnością wykrycia.

1. Wypisz powierzchnię ataku: adresy zdalne, otwarte porty, VPN, tunele, konta chmurowe, aplikacje, HACS, broker MQTT, router i urządzenia IoT.
2. Przy każdym elemencie zapisz właściciela, sposób aktualizacji, dane dostępowe, zakres uprawnień i miejsce logów.
3. Oznacz funkcje krytyczne, które muszą mieć ręczne sterowanie i bezpieczne zachowanie po utracie Home Assistant.
4. Nadaj priorytet pięciu realnym ryzykom. Dla każdego zapisz zabezpieczenie zapobiegawcze, sposób wykrycia oraz reakcję.
5. Usuń jedną niepotrzebną drogę dostępu albo nieużywany token i zachowaj dowód testu.

Nabu Casa zapowiedziała zmianę nazwy Home Assistant Cloud na Home Assistant Link na 2 grudnia 2026 r. W okresie przejściowym spotkasz obie nazwy. Nie oznaczają dwóch różnych metod zdalnego dostępu ani potrzeby zakładania drugiego konta. Informacja Nabu Casa o nazwie usługi.

Zapisz drogę dostępu, zanim oceniasz zabezpieczenia

Na początku biorę kartkę i zapisuję, jak naprawdę docieram do panelu. Przykładowo: telefon, internet komórkowy, Nabu Casa, lokalny Home Assistant. Albo: telefon, Tailscale, prywatny adres serwera. W trzecim domu będzie to przeglądarka, Cloudflare Access, Cloudflare Tunnel, serwer HTTP Home Assistant. Te drogi mają inne miejsca kontroli. Jeżeli korzystasz wyłącznie lokalnie, również zapisz tę decyzję. Kurs nie wymaga uruchamiania dostępu zdalnego.

Przy każdej drodze zaznaczam osobno konto dostawcy, urządzenie dopuszczone do połączenia i konto Home Assistant. Usunięcie telefonu z VPN nie usuwa automatycznie użytkownika HA. Zmiana hasła użytkownika HA nie obraca tokenu tunelu. Takie rozpisanie ułatwia później odebranie dostępu bez zgadywania, który przełącznik ma znaczenie.

Nie wystarczy stwierdzić, że port 8123 jest zamknięty. Router może przekazywać publiczny port 443 na inny port serwera, mieć włączoną funkcję DMZ albo regułę utworzoną przez UPnP. Przy IPv6 dostęp zależy również od zapory i nie wymaga takiego samego przekierowania jak przy IPv4. Przeglądam więc wszystkie reguły prowadzące do hosta HA, publiczne nazwy, tunele i zdalny panel routera. Nie zmieniam reguł używanych przez innych domowników bez ustalenia ich celu.

Od Home Assistant 2026.8 domyślny port HAOS to 80, a Container pozostaje przy 8123. Własna konfiguracja może korzystać z innego numeru. W audycie zapisujesz rzeczywiście działający adres, protokół i port. Numer portu nie stanowi sam w sobie zabezpieczenia. Zmiana 8123 na przypadkową liczbę nie zastępuje uwierzytelniania ani kontroli dostępu.

Co oznacza zaufanie do kodu i do urządzenia

Integracja niestandardowa nie jest tylko kolejną ikoną. Może wykonywać kod w procesie Home Assistant i korzystać z danych dostępnych temu procesowi. Karta panelu uruchamia kod w przeglądarce. Aplikacja działająca obok Core może mieć dostęp do sieci, katalogów lub urządzeń zależnie od przyznanych uprawnień. Dlatego rozróżniam te elementy i nie traktuję instalacji przez HACS jako certyfikatu bezpieczeństwa.

Przed dodaniem sprawdzam oficjalny adres projektu, dokumentację, historię wydań, otwarte problemy oraz sposób usunięcia. Pojedyncza gwiazdka czy liczba pobrań nie rozstrzyga, czy kod jest bezpieczny. W początkującym domu najpierw szukam integracji wbudowanej. Jeżeli wybieram projekt społecznościowy, zapisuję, jaką potrzebę rozwiązuje i gdzie będę sprawdzał aktualizacje.

Podobnie oceniam dostęp fizyczny. Odblokowany tablet właściciela może dać dostęp mimo idealnej konfiguracji tunelu. Komputer z zapisanym hasłem i sekretem TOTP wymaga ochrony systemu operacyjnego oraz blokady ekranu. Serwer i nośniki z kopiami powinny znajdować się w miejscu, do którego przypadkowy gość nie ma swobodnego dostępu. To konkretne elementy ochrony tej samej instalacji.

MFA chroni proces logowania, lecz nie dodaje drugiego pytania do każdego wywołania API ani każdego webhooka. Token API i adres webhooka traktujesz zgodnie z ich rolą jako dane dostępowe. Nie zapisuj poufnych plików w katalogu udostępnianym przez /local/ tylko dlatego, że główny panel wymaga hasła. Dokumentacja HA opisuje dostęp do zasobów tego katalogu bez uwierzytelniania.

Rozróżnij awarię i podejrzenie przejęcia

Jeśli po aktualizacji nie ładuje się karta, zaczynam od logów i ostatniej zmiany. Jeśli widzę obcą sesję, opublikowany token lub nieznanego administratora, priorytetem staje się ograniczenie dostępu i unieważnienie zagrożonych danych. Czekanie na spokojny test nowego konta nie jest właściwe, gdy istnieją oznaki aktywnego nadużycia.

Nie każdy wpis o nieudanym logowaniu oznacza atak. Stara aplikacja, wygasłe dane w skrypcie albo błędny adres mogą dawać podobny objaw. Zapisz czas, adres widziany przez HA i usługę, której wpis dotyczy. Porównaj go z własnymi działaniami. Nie publikuj pełnych logów z tokenami lub lokalizacją, aby zapytać o jeden komunikat.

Sprawdź aplikacje HAOS, które mają dostęp do Twoich danych

Konto właściciela może być dobrze zabezpieczone, a obok Core nadal działać niepotrzebna usługa z dostępem do plików. Dlatego w Ustawieniach otwórz Aplikacje i zapisz, co jest zainstalowane, co uruchamia się automatycznie i które usługi wystawiają port w sieci. Jeżeli używasz Container, podobny przegląd wykonaj dla własnych kontenerów i hosta. Samo hasło do panelu HA nie zabezpiecza automatycznie każdej z tych usług.

Przy każdej aplikacji odpowiedz na trzy pytania: po co jej używasz, skąd pochodzi i jak odzyskasz potrzebne dane po jej zatrzymaniu? Wyłączaj najpierw elementy naprawdę zbędne. Nie zatrzymuj Mosquitto czy Zigbee2MQTT, gdy działające urządzenia od nich zależą. Zanim usuniesz aplikację, zapisz jej rolę i wykonaj odpowiednią kopię. Nie instalujemy w tej lekcji dodatkowych narzędzi tylko po to, aby mieć dłuższą listę zabezpieczeń.

W aplikacji Terminal & SSH rozróżnij terminal dostępny przez panel oraz serwer SSH słuchający w sieci. Jeśli korzystasz z połączenia SSH, preferuj klucz i pozostaw logowanie hasłem wyłączone po przetestowaniu klucza. Do authorized_keys wstawiasz klucz publiczny; prywatny zostaje na chronionym komputerze. Najpierw przetestuj połączenie w drugim oknie, a dopiero potem odbierz dotychczasową drogę. Jeśli zewnętrzny port SSH nie jest potrzebny, pozostaw go nieudostępniony.

Nie wyłączaj trybu ochrony aplikacji dlatego, że przypadkowa instrukcja chce większych uprawnień. Ustal, po co są potrzebne i czy dotyczą Twojego wariantu. Terminal aplikacji nie jest automatycznie konsolą fizyczną hosta. W szczególności nie zastępuje konsoli używanej do awaryjnego resetu hasła właściciela. Dostępu SSH nie przekierowuj do internetu jako zapasowej drogi do panelu.

W Samba share ustaw oddzielne dane do udziału, bez hasła właściciela HA. Dokumentacja aplikacji wyjaśnia, że to osobne poświadczenia. Ogranicz dozwolonych klientów i dostępne udziały do rzeczywistej potrzeby. Udostępnienie konfiguracji daje dostęp także do wrażliwych plików, a możliwość zapisu pozwala wpływać na system. Jeżeli Samba była potrzebna tylko do jednorazowego przeniesienia plików, zatrzymaj ją po zakończeniu.

Mosquitto broker z oficjalnego repozytorium nie obsługuje anonimowych logowań. Dla zewnętrznych klientów przygotuj osobne dane i zapisz ich przeznaczenie. Nie używaj właściciela HA jako wspólnego konta MQTT. Rozróżnij użytkowników lokalnych brokera od użytkowników HA: konto utworzone w HA może również pozwalać zalogować się do panelu. Osobne dane nie tworzą jeszcze ograniczeń tematów; takie ograniczenie wymaga świadomie skonfigurowanych ACL. Zachowaj uprawnienia kont wewnętrznych potrzebne HA.

W ESPHome sprawdź szyfrowanie API i ochronę aktualizacji OTA. Aktualna dokumentacja zaleca szyfrowane OTA; samo hasło uwierzytelnia wysyłającego, ale nie chroni poufności przesyłanego firmware. W istniejącym urządzeniu migrację wykonuj według dokumentacji wersji i z przygotowaną możliwością odzyskania. Nie łącz opcji password i encryption w jednym wariancie OTA. Utrata klucza lub jego wymiana może wymagać fizycznego dostępu, dlatego nie zmieniaj wszystkich urządzeń naraz.

Poniżej jest przykład fragmentu dla nowego urządzenia lub urządzenia prawidłowo przygotowanego do szyfrowanego OTA. Nie jest to pełna konfiguracja płytki. W secrets.yaml zapisz właściwy, unikalny dla urządzenia klucz Base64, wygenerowany zgodnie z dokumentacją API. Sprawdź zgodność używanej wersji przed wgraniem. Dla starszego urządzenia zachowaj istniejącą metodę do czasu wykonania wymaganych kroków migracji.

api:
  encryption:
    key: !secret czujnik_salon__encryption_key
ota:
  - platform: esphome
    encryption:

Jeżeli w urządzeniu działa serwer WWW, zabezpiecz go osobno i sprawdź, czy nie udostępnia dodatkowej, nieszyfrowanej drogi aktualizacji. Nie włączaj serwera WWW tylko dla wygody audytu. Wynik tej części to krótka lista potrzebnych usług, ich uprawnień oraz sposobu wycofania, a nie bezrefleksyjnie zaznaczone opcje.

Powiadomienie o błędzie logowania i nowej blokadzie IP

Wykrywanie zaczynam od zdarzeń, które system rzeczywiście udostępnia. HA tworzy trwałe powiadomienia o nieudanym uwierzytelnieniu i dodaniu blokady IP. Dla sprawdzonego wydania 2026.9.4 mają identyfikatory http-login i ip-ban. Korzystamy z wyzwalacza persistent_notification, a nie z nieistniejącej współczesnej encji persistent_notification.http_login ani z wymyślonego zdarzenia http.login_attempt.

Przed wklejeniem automatyzacji sprawdź odbiornik telefonu. W Narzędziach deweloperskich > Akcje wybierz swoją akcję powiadomień Mobile App i wykonaj zwykły test. W przykładzie zastąp notify.mobile_app_moj_telefon rzeczywistą nazwą. Następnie utwórz pustą automatyzację, przejdź do edytora YAML pojedynczej automatyzacji i wstaw poniższy blok. Nie dodawaj wokół niego klucza automation, który należy do innego sposobu zapisu.

alias: "Bezpieczeństwo: logowanie i blokada IP"
description: "Powiadomienie na podstawie trwałych powiadomień HA"
triggers:
  - trigger: persistent_notification
    update_type: [added, updated]
    notification_id: http-login
    id: login
  - trigger: persistent_notification
    update_type: [added, updated]
    notification_id: ip-ban
    id: ban
  - trigger: persistent_notification
    update_type: [added, updated]
    notification_id: marklabs_security_test
    id: test
conditions: []
actions:
  - action: notify.mobile_app_moj_telefon
    data:
      title: "Sprawdź bezpieczeństwo Home Assistant"
      message: >-
        {% if trigger is not defined %}
          Test samych akcji powiadomienia.
        {% elif trigger.id == "ban" %}
          Home Assistant zgłosił nową blokadę IP. Sprawdź panel i logi.
        {% elif trigger.id == "test" %}
          Test wyzwalacza zakończony. Sprawdź ślad automatyzacji.
        {% else %}
          Home Assistant zgłosił nieudane uwierzytelnienie. Sprawdź panel i logi.
        {% endif %}
mode: single
max_exceeded: silent

Do bezpiecznego testu otwórz Narzędzia deweloperskie > Akcje i wywołaj persistent_notification.create z poniższymi danymi. Używamy oddzielnego identyfikatora testowego, żeby nie udawać rzeczywistego ataku. Nie wykonuj wielu błędnych logowań i nie blokuj sobie jedynego adresu administratora.

action: persistent_notification.create
data:
  notification_id: marklabs_security_test
  title: "Test powiadomienia bezpieczeństwa"
  message: "To ćwiczenie, nie rzeczywista próba logowania."

Po teście sprawdź wiadomość telefonu i ślad wykonania automatyzacji. Usuń tylko powiadomienie testowe. Uruchomienie samych akcji w edytorze nie sprawdza wyzwalacza. Jeśli zmieniła się wersja HA, porównaj identyfikatory i mechanizm z dokumentacją oraz kodem tej wersji. Nie wysyłamy adresu IP, szczegółów domu ani pełnego logu na ekran blokady telefonu.

To powiadomienie sygnalizuje problem, nie dowodzi włamania i nie liczy niezależnie wszystkich żądań HTTP. Przy wielu zdarzeniach jednocześnie tryb single może pominąć kolejne uruchomienie, a dostawca powiadomień może stosować limity. Szczegóły pozostają w HA i logach. Nie filtruj informacji o blokadzie tylko do godzin nocnych. Konto może zostać przejęte również w południe. Tworzenie nowych użytkowników i tokenów sprawdzaj przez regularne porównanie list; nie zakładamy gotowego zdarzenia audytowego dla każdej takiej czynności.

Pierwszy krok segmentacji bez przebudowy domu

Osobna nazwa Wi-Fi nie musi oznaczać osobnej sieci ani reguł zapory. Jako pierwszy krok sprawdź sieć gościnną routera: czy ma dostęp wyłącznie do internetu, czy również do panelu HA, NAS-a i komputerów. Test wykonaj własnym urządzeniem. Nie przeprowadzaj go z telefonu nadal mającego połączenie VPN do domu, bo wynik może dotyczyć VPN zamiast izolacji gości.

Urządzeń IoT nie przenosimy automatycznie do sieci gościnnej. Izolacja klientów może zablokować połączenie HA z czujnikiem lub komunikację między usługami. mDNS i inne mechanizmy wykrywania mogą nie przechodzić między segmentami. Przed zmianą wypisz, kto inicjuje połączenie, jaki jest cel i które usługi są potrzebne. Odróżnij drogę do MQTT od wykrywania radia Zigbee; Zigbee nie korzysta z domowego Wi-Fi w ten sam sposób.

Segmentacja może ograniczyć skutki przejęcia urządzenia, lecz nie naprawia wspólnego hasła ani ujawnionego tokenu. Do konfiguracji VLAN i zapory wróć do modułu 2. Tutaj sprawdzasz cel ochrony oraz wynik jednej zmiany. Jeśli po przeniesieniu urządzenia przestaje działać wykrywanie, nie otwieraj całego ruchu między wszystkimi sieciami. Cofnij próbę albo ustal brakującą, konkretną komunikację.

Rejestr aktywów: kto utrzymuje poszczególne elementy

W swoim notatniku zapisz element, osobę odpowiedzialną, drogę administracji, źródło aktualizacji, lokalizację kopii i skutek awarii. To lista odpowiedzialności, nie katalog haseł. Przy tunelu zapisz miejsce zarządzania tokenem, a nie jego treść. Przy koordynatorze odróżnij kopię konfiguracji integracji od możliwości wymiany samego radia.

Sprawdź rozumienie na trzech sytuacjach

Router nie przekierowuje portu 8123, ale przekierowuje 443 na serwer HA. Czy panel jest niewystawiony?

Pokaż odpowiedź i wyjaśnienie

Nie. Liczy się rzeczywista droga do usługi, także przez inne porty, IPv6 i tunele.

Czy MFA sprawi, że ujawniony token API przestanie działać?

Pokaż odpowiedź i wyjaśnienie

Nie. Token trzeba osobno unieważnić. MFA nie jest dodatkowym sprawdzeniem każdego żądania już uwierzytelnionego tokenem.

Nieznana sesja jest aktywna, a hasło wyciekło. Czy czekać do zaplanowanego przeglądu?

Pokaż odpowiedź i wyjaśnienie

Odbierz podejrzany dostęp od razu z zaufanego urządzenia, zabezpiecz konto i zachowaj potrzebne informacje o zdarzeniu.

Dokumentacja i data weryfikacji

Treść techniczna zweryfikowana 2 października 2026 r. Numery wersji odnoszą się do opisanych zmian, a nie do obowiązku instalowania konkretnego wydania. Przy późniejszym wdrożeniu sprawdź dokumentację swojej wersji. Przykłady z tej lekcji wymagają podstawienia własnych adresów i identyfikatorów.

HA: zabezpieczenie instalacji

HA: serwer HTTP i blokady IP

Nabu Casa: ograniczenia dostępu i adresy klienta

Źródła uzupełnień operacyjnych:

Terminal & SSH: dokumentacja aplikacji

Samba share: konta i dozwolone hosty

Mosquitto: uwierzytelnianie i ACL

ESPHome: praktyki bezpieczeństwa

ESPHome: OTA i migracja szyfrowania

HA: wyzwalacz trwałych powiadomień

HA 2026.9.4: identyfikatory powiadomień logowania i blokad

HA: wykrywanie usług i mDNS

Zadanie po lekcji

Utwórz w notatniku sekcję „Bezpieczeństwo Home Assistant” i wpisz:

Brama wyjścia

Bezpieczeństwo nie jest czynnością wykonywaną tylko raz. Po dodaniu nowego użytkownika, telefonu, tunelu, integracji albo serwera warto ponownie sprawdzić, kto ma dostęp, jakie sesje są aktywne, gdzie znajdują się kopie i czy stara konfiguracja nadal jest potrzebna.

Co dalej

W lekcji 2 uporządkujemy konta użytkowników. Sprawdzimy, kto naprawdę potrzebuje uprawnień administratora, dlaczego każdy domownik powinien mieć własne konto oraz jak włączyć MFA.

Jeżeli obecnie cała rodzina korzysta ze wspólnego konta administratora albo MFA jest wyłączone, nie traktuj tego jako porażki. To po prostu najlepszy punkt, od którego warto rozpocząć porządkowanie systemu.