Bezpieczeństwo MyBreederLine

Security Overview · wersja 1.0 · ostatnia aktualizacja: 2026-05-25

MyBreederLine to platforma SaaS dla hodowców kotów rasowych. Projektujemy ją z myślą o izolacji danych hodowli, minimalnym zakresie uprawnień i infrastrukturze w Unii Europejskiej. Poniżej — przejrzysty opis naszego podejścia do bezpieczeństwa.

Uwaga: Ten dokument ma charakter informacyjny dla klientów i partnerów. Nie ujawniamy szczegółów, które mogłyby ułatwić atak (konfiguracja wewnętrzna, reguły WAF, nazwy sekretów, schematy testów penetracyjnych).

Kontakt: support@kontakt.mybreederline.pl (techniczne) · rodo@kontakt.mybreederline.pl (RODO / incydenty danych)

1. Architektura w skrócie

| Warstwa | Rola | Region (orientacyjnie) | |---------|------|------------------------| | Aplikacja (Flutter Web / mobile) | interfejs hodowcy | CDN / hosting UE | | Supabase | baza PostgreSQL, uwierzytelnianie, magazyn plików, funkcje serwerowe | UE | | FastAPI (Render) | wąskie API produktowe (reguły hodowlane, cache) | Frankfurt (UE) | | Cloudflare | DNS, TLS, CDN, ochrona brzegu sieci | globalna sieć z punktami w UE | | Stripe | płatności i subskrypcje | Stripe Payments Europe | | Sentry | monitoring błędów i niezawodności | ingest UE (de.sentry.io) | | Resend | e-mail transakcyjny | zgodnie z polityką dostawcy |

Dane hodowlane i CRM domyślnie trafiają do Supabase z aplikacji klienta — z kontrolą dostępu po stronie bazy (RLS), a nie przez publiczne, szerokie API.

2. Izolacja danych (multi-tenant)

1. Jedno Konto = jedna hodowla. Dane każdego hodowcy są logicznie odseparowane od innych kont.

2. Row Level Security (RLS) w PostgreSQL — każde zapytanie z aplikacji hodowcy jest ograniczone do wierszy należących do zalogowanego użytkownika (owner_id). Hodowca nie ma technicznej możliwości odczytu danych innej hodowli przez standardowy interfejs aplikacji.

3. Tabele platformowe (ustawienia globalne, lista oczekujących) nie są dostępne bezpośrednio z aplikacji hodowcy — operacje wykonują wyłącznie kontrolowane procesy serwerowe.

4. Operatorzy platformy nie korzystają z interfejsu hodowcy do rutynowego przeglądania treści CRM — dostęp administracyjny jest warstwowy i ograniczony funkcjonalnie (patrz § 9).

3. Uwierzytelnianie i sesje

| Element | Podejście | |---------|-----------| | Hodowca | e-mail + hasło (Supabase Auth); hasła przechowywane jako hash — nie w postaci jawnej | | Sesja | token JWT; w aplikacji web — bezpieczne magazyny przeglądarki / urządzenia | | Reset hasła | mechanizm Supabase Auth; linki czasowe | | Rate limiting | limity po stronie dostawcy Auth oraz ochrona brzegu sieci (Cloudflare) | | Panel operatora | osobne konto; MFA TOTP (aplikacja Authenticator) obowiązkowe; dodatkowa warstwa brzegu sieci przed panelem administracyjnym |

Zalecamy silne, unikalne hasło i nieudostępnianie Konta osobom trzecim.

4. Szyfrowanie

| Obszar | Środek | |--------|--------| | Transmisja | TLS (HTTPS) na wszystkich publicznych endpointach | | Baza i Storage | szyfrowanie po stronie infrastruktury Supabase (standard dostawcy chmury) | | Płatności | dane karty nie przechodzą przez serwery MyBreederLine — obsługuje je Stripe (PCI DSS po stronie Stripe) |

5. Magazyn plików (Storage)

1. Zdjęcia kotów i logo hodowli przechowywane są w prywatnych bucketach — bez publicznego linku do pliku.

2. Dostęp wymaga uwierzytelnienia i polityk Storage powiązanych z tożsamością użytkownika (folder = identyfikator Konta).

3. Stosujemy limity rozmiaru i dozwolone typy plików (JPEG, PNG, WebP) — zarówno w konfiguracji magazynu, jak i w regułach aplikacji.

4. Przy usunięciu Konta aplikacja usuwa pliki użytkownika ze Storage przed usunięciem rekordów w bazie.

6. Bezpieczeństwo płatności (Stripe)

• Subskrypcje planów Standard i PRO obsługuje Stripe (Checkout, Customer Portal).
• MyBreederLine przechowuje wyłącznie identyfikatory klienta i subskrypcji oraz status billingowy — nie numery kart ani CVV.
• Webhooki Stripe weryfikowane są podpisem kryptograficznym; zdarzenia przetwarzane z idempotencją (brak podwójnego naliczania przy powtórzeniach).
• Pola billingowe w profilu hodowcy nie mogą być zmieniane z poziomu aplikacji — wyłącznie przez system płatności lub procesy operatorskie.

Szczegóły zwrotów: Polityka zwrotów.

7. API i logika serwerowa

1. FastAPI (Render) — wąski most API: uwierzytelnianie JWT Supabase, weryfikacja własności rekordów po owner_id, brak szerokiego dostępu do danych innych tenantów.

2. Edge Functions (Supabase) — krytyczne operacje (billing, waitlist, webhooki, konserwacja danych) wykonywane po stronie serwera z service role i walidacją w kodzie; sekrety wyłącznie w zmiennych środowiskowych dostawcy.

3. Logi access API — metadane żądania (metoda, ścieżka, kod odpowiedzi, identyfikator użytkownika UUID); bez haseł, tokenów sesji w treści ani danych CRM w logach dostępu.

8. Ochrona brzegu sieci (Cloudflare)

• DNS i certyfikaty TLS — zarządzane centralnie.
• CDN — szybkie dostarczanie statycznych zasobów (landing, aplikacja web).
• WAF i rate limiting — ograniczenie nadużyć i automatycznych ataków na publiczne hosty (www, aplikacja, API, panel administracyjny).
• Szczegóły reguł nie są publikowane — to świadoma decyzja bezpieczeństwa.

9. Dostęp operatorów platformy

Panel administracyjny jest osobnym produktem z wielowarstwową kontrolą dostępu:

1. Warstwa brzegu sieci (Cloudflare) — weryfikacja tożsamości operatora.
2. Supabase Auth — e-mail, hasło, MFA TOTP.
3. Wpis w bazie platform_admins — autoryzacja roli operatora.
4. Operacje wrażliwe przez Edge Functions z weryfikacją uprawnień — nie przez bezpośredni dostęp do danych hodowców.

Operatorzy nie mają rutynowego dostępu do treści CRM hodowców przez UI aplikacji hodowcy.

Odzyskiwanie danych: na prośbę hodowcy operator może przywrócić kartotekę kota wycofaną przez użytkownika (soft delete). Do identyfikacji wpisu służy skrócony podgląd kartoteki w panelu admin — bez historii ważeń, dokumentów, rezerwacji i CRM. Przywrócenie wymaga audytowalnego powodu operacji.

10. Kopie zapasowe i ciągłość

| Element | Praktyka | |---------|----------| | Baza danych | codzienne kopie zapasowe Supabase; retencja ok. 7 dni | | Cel backupów | odtworzenie Usługi po awarii infrastruktury | | Usunięcie przez użytkownika | dane znikają z aktywnej bazy natychmiast po operacji; w backupie do końca okna retencji |

Retencja operacyjna danych (wagi, powiadomienia, timeline CRM) — zgodnie z Planem; szczegóły w Polityce prywatności.

11. Monitoring i niezawodność

• Sentry — raportowanie błędów aplikacji i API; identyfikacja problemów bez ujawniania danych hodowlanych w treści logów (minimalizacja PII).
• Alerty operacyjne — reakcja na awarie integracji (płatności, e-mail, baza).
• Środowiska — separacja development / test / produkcja; produkcja na osobnym projekcie Supabase i osobnych kluczach.

Nie publikujemy wewnętrznych dashboardów ani metryk SLA w tej wersji produktu — patrz Regulamin § 11.

12. Reagowanie na incydenty

1. Incydent bezpieczeństwa danych — po stwierdzeniu naruszenia ochrony danych osobowych działamy zgodnie z RODO: ocena ryzyka, informacja hodowców (jako administratorów danych CRM klientów, gdy dotyczy), współpraca z PUODO gdy wymagane.

2. Zgłoszenia od użytkowników: rodo@kontakt.mybreederline.pl (dane osobowe) · support@kontakt.mybreederline.pl (awarie, podejrzenie nieuprawnionego dostępu do Konta).

3. Czas reakcji — priorytet dla incydentów dotyczących poufności danych; cel operacyjny: pierwsza odpowiedź w ciągu 2 dni roboczych, incydenty krytyczne — szybciej w miarę możliwości.

4. Chargebacki / nadużycia płatnicze — procedura opisana w Polityce zwrotów.

13. RODO i prywatność

| Temat | Dokument | |-------|----------| | Przetwarzanie danych hodowcy | Polityka prywatności | | Dane klientów CRM (powierzenie) | Umowa powierzenia | | Cookies | Polityka cookies | | Prawa osób | dostęp, sprostowanie, usunięcie Konta, wnioski na rodo@ |

Hosting danych produkcyjnych: UE. Transfery poza EOG — standardowe klauzule umowne u podprocesorów (Render, Cloudflare, Resend, Sentry) — opis w Polityce prywatności.

14. Twoja rola jako hodowcy

Bezpieczeństwo to wspólna odpowiedzialność:

• używaj silnego hasła i nie udostępniaj Konta;
• informuj klientów CRM o przetwarzaniu danych — Ty jesteś administratorem ich danych;
• nie wprowadzaj do notatek danych wrażliwych bez podstawy prawnej;
• zgłaszaj podejrzenie nieuprawnionego dostępu na support@;
• regularnie eksportuj / archiwizuj dane hodowlane ważne dla Twojej działalności (funkcja eksportu rozwijana — wnioski na rodo@).

15. Co świadomie nie publikujemy

• szczegółów konfiguracji RLS, nazw polityk i procedur SQL;
• limitów rate limit i reguł WAF;
• listy sekretów, kluczy API i wewnętrznych identyfikatorów projektów;
• wyników testów penetracyjnych i mapy powierzchni ataku.

Pytania due diligence od partnerów B2B — support@kontakt.mybreederline.pl (case-by-case, NDA w razie potrzeby).

16. Zmiany tej strony

Aktualizujemy Security Overview przy istotnych zmianach architektury lub praktyk bezpieczeństwa. Data wersji na górze strony.

MyBreederLine — porządek w hodowli, z dbałością o bezpieczeństwo danych.