# Notatki ze spotkania

## Spotkanie 1: Strategia patchowania i optymalizacja operacji

**Tematy dyskusji:**
- Zespół zdecydował o kontynuowaniu patchowania środowisk produkcyjnych i nieprodukcyjnych w okresie letnim, z wyjątkiem produkcji w Szwecji, Danii, Norwegii i Finlandii z powodu obecnych ograniczeń.
- Leszek wyjaśnił, że konieczna jest zmiana w projekcie automatyzacji, aby umożliwić zatrzymanie patchowania na konkretnych rynkach, i potwierdził, że jest to wykonalne.
- Omówiono potrzebę wykluczania lub nieustawiania niestandardowych polityk (w tym dynamicznych i statycznych) dla niektórych krajów.
- Zespoły inżynieryjne i platformowe współpracują nad optymalizacją wymiany certyfikatów w całej Europie, aby zmniejszyć obciążenie operacyjne ze względu na skracające się okresy ważności certyfikatów.

**Zgodność z RODO i Logowanie systemów:**
- Dyskutowano nad wdrażaniem logowania systemów dla wszystkich usług w Europie. Logi będą wysyłane do Splunka i przekazywane do działu bezpieczeństwa, z wyłączeniem danych chronionych przez RODO.
- Oleksandr wyraził obawy dotyczące niejasnych planów przyszłego gromadzenia logów – mogą one być zbierane bez odpowiedniej weryfikacji, co niesie ryzyko problemów ze zgodnością z RODO.
- Leszek podkreślił, że wszelkie zmiany w zbieraniu logów mające wpływ na produkcję muszą wymagać procedury Change Request (CR) i obejmować wszystkie dotknięte elementy konfiguracji.
- Zgodzono się na potrzebę ogólnoeuropejskiego rozwiązania zapewniającego zgodność logowania SecOps z RODO, unikając obsługiwania wyjątków na poziomie pojedynczych serwerów.
- Zasugerowano konsultacje z Larsem Gehringiem w sprawach definicji i wymogów RODO (które są omawiane na firmowych szkoleniach bezpieczeństwa). Lars ma poprowadzić dyskusje z działem prawnym i compliance, a wszelkie przyszłe zmiany w zbieraniu logów powinny być przez nich zatwierdzane.
- Uzgodniono, że konieczne jest dostarczenie przykładów chronionych danych oraz nazw plików do wykluczenia (zadanie ręczne, wymagające koordynacji z odpowiednim zespołem). Zgodzono się omówić kwestie zgodności RODO z Larsem na spotkaniu zaplanowanym na kolejny dzień.

**Migracja sieci:**
- Martin wyjaśnił, że ostatnia partia sieci serwerowych połączonych z backendowymi zaporami sieciowymi Checkpoint zostanie zmigrowana w środę o 3:00 rano. Ma to na celu zamknięcie przestarzałych zapór (End-of-Life) do końca czerwca.
- Migracje w Finlandii i Szwajcarii zostały już zakończone. Backendowe zapory w Szwecji będą zmigrowane w nadchodzącej partii, natomiast zapory zwrócone w stronę internetu zaplanowano na pierwsze okno serwisowe po przerwie letniej.

**Zadania następcze (Follow-up tasks):**
- Prześlij plany urlopowe na okres letni (wszyscy uczestnicy).
- Wdróż zmianę w projekcie automatyzacji, umożliwiającą zatrzymanie patchowania dla konkretnych rynków (Leszek).
- Wyklucz kraje nordyckie z patchowania w lipcu, kontynuując patchowanie w czerwcu i sierpniu (wszyscy uczestnicy).
- Przedstaw i wyślij konkretne przykłady danych chronionych przez RODO znalezionych w logach systemowych Dimie do analizy bezpieczeństwa (Oleksandr, wszyscy uczestnicy).
- Zaplanuj spotkanie z Larsem, aby przejrzeć zgody prawne i zgodności dotyczące zmian w gromadzeniu logów (Kamil, TEAMS RM STO Quantum).

---

## Spotkanie 2: Migracja serwerów (Paweł)

**Tematy dyskusji:**
- Paweł poinformował, że testy migracji zostały wstrzymane w oczekiwaniu na licencje, które mają zostać dostarczone przez Adriana.
- Paweł zadeklarował gotowość do wsparcia przy konfiguracji dostępu dla deweloperów oraz przygotowaniu środowiska przed migracją.

**Zadania następcze (Follow-up tasks):**
- Prześlij roadmapę projektu migracji oraz opisz, w jaki sposób zbudowana jest aplikacja i baza danych Oracle (Gregor).

---

## Spotkanie 3: Migracja i bazy danych (Gregor)

**Tematy dyskusji:**
- Gregor ma zgłosić Service Request (SR) o nadanie dostępu dla swoich użytkowników. Poinformowano go, że nie otrzyma uprawnień administratora systemu (sys admin), więc należy ustalić alternatywny sposób działania.
- Główne założenia i rola w projekcie: Zmiksowanie (migracja) 3 istniejących instancji oraz podłączenie nowych do serwera SQL.
- Harmonogram: Zespół Gregora ma rozpocząć pracę i wejść do projektu migracyjnego przed końcem czerwca.
- Ustalenia: Należy uzyskać od Gregora roadmapę całego przedsięwzięcia w celu ustosunkowania się i zaplanowania własnej pracy w ramach tego projektu.
- Podejście techniczne: Gregor wyjaśnił, że proces będzie specyficzny (równoległe wsparcie dla bazy Oracle i nowej SQL). Proces odłączania starych i przyłączania nowych systemów ma być płynny i "bardzo przyjazny dla użytkownika".