Polityka bezpieczeństwa

1. Zabezpieczenia techniczne

Szyfrowanie i transport

• TLS 1.2+ wymuszony dla wszystkich endpointów publicznych. TLS 1.0/1.1 wyłączone.
• HSTS preload z max-age=31536000, includeSubDomains, preload.
• Encryption at rest dla baz danych klienckich (AES-256). Backupy szyfrowane.
• Cloudflare przed każdą aplikacją publiczną — DDoS shield, WAF, edge encryption.

Architektura sieciowa

• Środowiska klientów fizycznie odseparowane (VLAN/VPC + firewall rules)
• VPN-only access (WireGuard / IPsec) do paneli admin i SSH
• Dostęp publiczny tylko przez load balancer / reverse proxy
• Brak bezpośredniego ruchu z internetu do baz danych

Hartowanie systemów

• Patche bezpieczeństwa — Oracle CPU (Critical Patch Update) kwartalnie, IBM Security Bulletin na bieżąco
• CIS Benchmarks alignment dla systemów Linux i WebSphere/WebLogic
• Vulnerability scans co 30 dni (OpenVAS / dedykowane narzędzia per technologia)
• Hosty produkcyjne bez zbędnych usług, minimal install

2. Zarządzanie dostępem

Authentication & authorization

• MFA wymagane dla wszystkich kont administracyjnych (TOTP / hardware keys)
• Polityka silnych haseł: bcrypt / Argon2 hashing po stronie aplikacji
• RBAC (Role-Based Access Control) — principle of least privilege na każdym poziomie
• Brak współdzielonych kont — każdy admin ma indywidualne credentialsy

Audit logs

• Wszystkie operacje administracyjne logowane (kto, co, kiedy, z jakiego IP)
• Logi przechowywane 90 dni online + 12 miesięcy w archiwum cold storage
• Tamper-evident — log integrity check (hash chain)
• Dostęp do logów ograniczony do roli "auditor"

3. Compliance i standardy

Klienci enterprise (T-Mobile, PZU, BASF, Samsung) podlegają dodatkowym wymogom kontraktowym. Indywidualne SLA, DPA i security questionnaires przygotowywane na żądanie.

4. Procesy operacyjne

Monitoring 24/7

• Dedykowany dyżur inżyniera — telefon, nie ticket-w-kolejce
• Monitoring uptime (Uptime Kuma + dedykowane probes na health endpointach klientów)
• Alerting przez SMS + email + Slack/Teams (klient wybiera kanał)
• Eskalacja w umowie 24/7: L1 (15 min) → L2 (30 min) → właściciel (60 min)

Backup i odzyskiwanie

• Backup codzienny z retencją 30 dni rolling + 12 miesięcy archive
• 3-2-1 rule: 3 kopie, 2 typy nośników, 1 off-site
• RTO < 15 minut dla środowisk produkcyjnych enterprise (przy umowie 24/7)
• RPO < 1 godzina przy ciągłej replikacji DB
• Test restore co kwartał (drill exercise)

5. Naruszenia bezpieczeństwa

Procedura zgodna z RODO art. 33-34:

6. Audyty i testy

• Penetration tests — coroczne, przez zewnętrzną firmę specjalizującą się w bezpieczeństwie aplikacji web/API
• Vulnerability scans — co 30 dni (OpenVAS, Nessus dla klientów enterprise)
• Code review — peer review dla każdej zmiany w kodzie produkcyjnym
• Tabletop exercises — symulacje incydentów co 6 miesięcy
• Compliance audits — wewnętrzne kwartalne, zewnętrzne na żądanie klienta

7. Zgłaszanie podatności (Responsible Disclosure)

Jeśli odkryłeś podatność w naszej infrastrukturze lub usługach nie publikuj jej publicznie przed zgłoszeniem nam. Współpracujemy konstruktywnie z badaczami bezpieczeństwa.

Kontakt

• Email: [email protected] — temat [SECURITY]
• Telefon: +48 606 464 264 (dla incydentów krytycznych — 24/7)
• PGP key fingerprint: na żądanie

Zakres

• W zakresie: infrastruktura FlexNet (flexnet.pl, new.flexnet.pl, dev.flexnet.pl), aplikacje hostowane przez nas, środowiska klientów (po koordynacji z klientem)
• Poza zakresem: third-party services (Cloudflare, Google Fonts), social engineering naszych pracowników, DoS / DDoS

Zasady

• Nie wykorzystuj podatności poza testem koncepcyjnym
• Nie uzyskuj dostępu do danych osobowych klientów ani nie modyfikuj danych
• Daj nam rozsądny czas na naprawę (typowo 90 dni od zgłoszenia)
• Po naprawie — pozwalamy na publikację (z wcześniejszą koordynacją wokół CVE / opis)

8. Kontakt