Podsumowanie prac Cloud Journey
CEL
Migracja bramki płatniczej do chmury. Projekt podzielony na dwa etapy:
etap compliance (działania związane z dostosowaniem umów z dostawcami chmurowymi, tj. AWS, GOOGLE, MS do wymogów przepisów prawa i wytycznych regulacyjnych, działania związane z pozyskaniem zgód na chmurę od kontrahentów),
etap techniczny (przebudowa architektury, postawienie środowiska w cloud, przepięcie partnerów/merchantów).
AKTUALNY HARMONOGRAM PRAC BRAMKA W CHMURZE
LISTA KONTRAHENTÓW DO POZYSKANIA ZGÓD NA CLOUD
SIDy - Weryfikacje bankowe (kontrahenci aktywni)
SIDy - Weryfikacje niebankowe (kontrahenci aktywni)
EPIC:ICT-1613
Podsumowanie prac 2022.12.05
Wątek aneksu chmurowego
Produkt nr 1, czyli opracowanie poziomu spełnienia komunikatu chmurowego przez dostawców oraz kierunki negocjacji z dostawcami dostarczone przez Marutę plus dostarczone analizy spełnienia wymagań RODO przez dostawców.
Produkt nr 2 – na bazie kierunków negocjacji opracowanych przez Marutę, w produkcie nr 2 chcemy te kierunki negocjacji (propozycje zmian zapisów umownych) wdrożyć do dokumentów chmurowych AWS, MS, Google. 14.11 wysłane te kierunki negocjacji do dostawców (AWS, Google), 16.11 do MS. Trochę kłopotu było z ustaleniem po stronie MS osób, do których możemy to zaadresować, bo NTI Polska nigdy w takich negocjacjach nie pośredniczyło. Obecnie stan jest następujący:
a) MS – 16.11 wysłane kierunki negocjacji do MS,
25.11 odbyło się spotkanie z członkiem zarządu MS w celu omówienia, czy propozycje zmian Maruty mogą być uwzględnione w umowie na chmurę Azure, tu jasna deklaracja ze strony MS, że tekst umowy głównej na Azure jest nie do ruszenia i że nie będą zmieniać zapisów pod Blue Media i że jest to ryzyko Blue Media, które BM albo zaakceptuje i podpisze umowę z MS w takim kształcie albo nie podpisze. Zaproponowali podesłanie nam dodatkowych materiałów, analiz (po podpisaniu umowy NDA), które pomogą w ocenie ryzyka niepełnej zgodności niektórych zapisów umowy z MS względem komunikatu chmurowego lub ustawy Prawo bankowe.
01.12 – podpisanie umowy NDA między BM a MS (Wojtek Murawski), podesłanie materiałów ze strony MS do BM i przesłanie tego samego dnia tych materiałów do analizy do Maruty. Obecnie czekamy na odpowiedź Maruty na analizę materiałów z MS.
Na bazie kierunków negocjacji opracowanych przez Marutę (plik powyżej) i negocjacji z MS nie uda się zamieścić następujących zapisów umownych w dokumentach chmurowych Microsoft i zidentyfikowano następujące ryzyka dla BM i banku:
Ryzyko dla BM | Uwagi |
|---|---|
Przekroczenie dopuszczalnej długości łańcucha outsourcingowego przy dostępie poddostawców Microsoft do danych BM/banku (art. 6 ust. 7 pkt 1 Prawa bankowego). | Można to zmitygować szyfrowaniem danych kluczami zarządzanymi przez BM, wtedy ani MS ani jego poddostawca nie będzie mógł odszyfrować danych BM/banku, bo nie będzie miał klucza szyfrującego. |
Brak możliwości przekazania kopii dokumentacji kontraktowej między Microsoft a BM na żądanie KNF skierowane do banku (naruszenie przez bank art. 6c ust. 4 pkt 1 Prawa bankowego). | |
Brak możliwości zmiany umowy podoutsourcingu bez konieczności wypowiedzenia przez bank umowy outsourcingu (naruszenie przez bank art. 6c ust. 5 Prawa bankowego). | |
Zawarcie przez bank umowy outsourcingu przewidującej tzw. outsourcing zagraniczny wymagający zezwolenia KNF, o którym mowa w art. 6d ust. 1 Prawa bankowego. | |
Naruszenie przez bank art. 104 Prawa bankowego – ujawnienie podmiotom nieuprawnionym informacji objętych tajemnicą bankową. Naruszenie przez BM art. 11 ust. 1 UUP – ujawnienie podmiotom nieuprawnionym informacji objętych tajemnicą zawodową. | |
Naruszenie przez BM art. 86 ust. 1 UUP – brak pisemności umowy outsourcingu. | |
Naruszenie przez BM art. 88 ust. 3 UUP – ograniczenie odpowiedzialności Microsoft za szkody wyrządzone użytkownikom lub posiadaczom pieniądza elektronicznego wskutek niewykonania lub nienależytego wykonania Umowy. | |
Naruszenie przez BM art. 103 ust. 4 UUP – brak określonych uprawnień przysługujących pracownikom organu nadzoru wykonującym kontrolę. | |
Brak możliwości pełnej realizacji przez bank czynności, których realizacji wymaga Komunikat UKNF - potwierdzenie, że dokumentacja kontraktowa MS-BM będzie mogła być przekazana do banku. | |
Brak zgodności z pkt VII.4.1. lit. a) Komunikatu UKNF - nieprawidłowa lub niepełna ocena ryzyka związanego z ciągłością działania- wskazanie właściwych źródeł postanowień stanowiących SLA dla wszystkich Usług wykorzystywanych przez BM. | |
Brak zgodności z pkt VII.4.1. lit. b) Komunikatu UKNF - brak pewności co do lokalizacji przetwarzania informacji oraz metod jej weryfikacji- zaproponowanie postanowień umownych wyraźnie określających lokalizację przechowywania danych; | |
Brak zgodności z pkt VII.4.1. lit. j) Komunikatu UKNF - brak pewności co do źródeł i trybu informowania o planowanych zmianach w Usługach. | |
Brak zgodności z pkt VII.4.1. lit. k) Komunikatu UKNF – brak pewności co do źródeł dokumentacji technicznej Usług. | |
Brak zgodności z pkt VII.4.1. lit. p) Komunikatu UKNF – niepewność co do trybu wprowadzania zmian w Umowie. | |
Brak zgodności z pkt VII.4.1. lit. r) Komunikatu UKNF – brak pewności co do zakresu świadczonych usług wsparcia. | |
Brak zgodności z pkt VII.4.1. lit. r) Komunikatu UKNF – brak pewności co do zakresu świadczonych usług wsparcia - normy ISO PN-ISO/IEC ISO 20000 dotyczące zarządzania usługami IT, wymagania dot. CPD zgodnie z Komunikatem UKNF: CPD dostawcy usług chmury obliczeniowej spełnia wymagania normy PN-EN 50600 (Wyposażenie i infrastruktura centrów przetwarzania danych) minimum klasy 3 lub ANSI/TIA-942 minimum Tier III, | |
Niezgodność z pkt VII.6.4 Komunikatu UKNF - niestosowanie wskazanych standardów bezpieczeństwa informacji i brak materiału do oceny ryzyka bezpieczeństwa przetwarzania danych. Wskazanie źródeł informacji w zakresie spełnienia przez Microsoft poniższych wymagań lub udostępnienie właściwych procedur określających: a. stosowanie domyślnej zasady braku dostępu do przetwarzanych informacji podmiotu nadzorowanego; b. stosowanie domyślnej zasady braku konta administracyjnego lub użytkownika na maszynach wirtualnych podmiotu nadzorowanego lub w innych uruchamianych usługach chmury obliczeniowej; c. wzorcowe konfiguracje lub opisy zasad, które w jednoznaczny sposób definiują separację przetwarzania oraz wskazują metody weryfikacji poprawności konfiguracji; d. domyślne uruchamianie nowego środowiska (lub usługi chmury obliczeniowej) separowanego od innych tenantów, z ustawieniami „secure-by-default”. | |
Brak informacji co do stosowanych sposobów szyfrowania danych – pkt VI.2.5 lit. d) – e), VII.7.1 – VII.7.3 Komunikatu UKNF. |
08.12.22 - Maruta podsyła podsumowanie porównania modeli licencjonowania AZURE (CSP vs. Enterprise Agreement). Korzystniejsze dla BM będzie skorzystanie z Enterprise Agreement (EA) - jest pisemna umowa MS a BM, wskazanie że w model EA możliwy jest przy zarządzaniu min. 500 userów/urządzeń w organizacji i 3 lata zobowiązania.
12.12.22 - informacja z MS Polska, żeby podpisać model EA trzeba wybrać sobie partnera MS z listy, który poprowadzi proces podpisania umowy. Wysyłka do kilku partnerów MS z listy zapytań mailowych o podjęcie współpracy (odpisał SoftwareOne). Kontakt z SoftwareOne, umówienie spotkania z przedstawicielem SoftwareOne na 21 grudnia 2022. Spotkanie 21.12.22 nie odbyło się, brak uczestnictwa przedstawiciela SoftwareOne mimo potwierdzenia przybycia na spotkanie. W związku z tym, rozesłanie mail o podjęcie współpracy z innymi partnerami MS z listy.
04.01.23 - kontakt z partnerem MS - Operatorem Chmury Krajowej (OCHK) - umówienie spotkania na 10.01.23
10.01.23 - spotkanie z przedstawicielami OCHK, wyjaśnienie kwestii zakupu AZURE w modelu EA, wyjaśnienie wymogów: kwestii min. 500 userów/urządzeń zarządzanych przez BM i 3 lata zobowiązania. Okazuje się, że jedynym wymogiem jest zobowiązanie po stronie BM do wykorzystania usług Azure na poziomie 12k USD rocznie (potwierdzone info w MS Polska). Dodatkowo informacja, że większość podmiotów finansowych w OCHK wybiera model CSP zamiast EA na Azure.
Po analizach i rozeznaniu wątku modeli AZURE CSP vs. EA, okazuje się, że model EA powiązany z liczbą min. 500 userów/urządzeń, odnosi się do Office365, a nie do Azure. Do zakupu Azure w modelu EA wymagane jest zobowiązanie zapłaty 12k USD za rok za usługi Azure, po roku, jeśli nie wydamy 12k USD, to będziemy musieli zapłacić różnicę do 12k USD. Zgodnie z ustaleniem z P. Ciesielski, idziemy na razie w model CSP w AZURE. Poinformowanie Maurty o wyborze modelu CSP zamiast EA.
16.01.23 - mail do OCHK w celu przesłania przez nich aktualnych dokumentów na usługę AZURE (MCA, MCA FSA) celem potwierdzenia dla Maruty, czy aktualne dokumenty są takie same, jak te, które kancelaria analizowała.
Mail od Maruty z podsumowaniem ryzyk niezgodności dla modelu CSP i dalszych kierunków działań.
18.01.23 - odesłanie przez OCHK aktualnych dokumentów na usługę Azure, plus umowa współpracy między OCHK jako partnerem MS a BM.
Wysłanie do Maruty dokumentów na usługę Azure (MCA, MCA FSA) oraz umowy współpracy między OCHK a BM.
19.01.23 - wysłane zapytanie do OCHK o usługę CustomerLockbox i plan w którym usługa ta jest dostępna, kwestia może być istotna z punktu widzenia compliance.
20.01.23 - Maruta odpisuje, że przeanalizuje przesłane dokumenty w przyszłym tygodniu.
b) GOOGLE
14.11 – wysłane kierunki negocjacji do Google
23.11 – Google odesłał swoje odpowiedzi do BM na kierunki negocjacji/propozycje zmian w umowie na GCP oraz dodatkowy załącznik „FSI End User European Fianacial Services Addendum” do analizy. Odpowiedzi i załącznik przesłane do Maruty 24.11.
28.11 - mail z Maruty, że analizują odpowiedzi oraz załącznik oraz że będzie potrzeba spotkania z Google.
05.12 – ping Maruty o status analizy.
20.12.22 - spotkanie negocjacyjne BM/Maruta - GOOGLE. Nie udało się przejść wszystkich punktów/zmian w umowach, potrzeba kolejnego spotkania.
02.01.23 - Maruta przesyła podsumowanie spotkania z 20.12.22 do Google, żeby wiedzieli, jakie ustalenia do omówionych zmian osiągnięto.
03.01.23 - Google podsyła nowy dokument dla instytucji finansowych do analiz (FSA).
05.01.23 - kolejne spotkanie negocjacyjne BM/Maruta - Google nad propozycjami zmian w umowach.
09.01.23 - mail Maurty do Google o przesłanie dokumentów: Services Schedule, pierwotny FSA z propozycjami zmian,Master Agreement.
11.01.23 - przesłąnie przez Google dokumentów: CMA+GCP+WS, FSA, FSA End User
20.01.23 - Maruta przesyła do BM analizy: Kierunki negocjacyjne z Google praz Listę kwestii do wewnętrznego potwierdzenia po Państwa stronie w zw. z korzystaniem z GCP. DO rozstrzygnięcia też, potwierdzenie czy charakter współpracy BM z bankami pozwala założyć, że BM zezwala bankom na korzystanie z programu informatycznego (software), który BM hostuje w GCP?(oczywiście pytamy zakładając, że BM rozpocznie wykorzystywanie usług GCP). Chciałbym to potwierdzić, aby mieć pewność, czy Banki współpracujące z Państwem będą mieścić się we wspomniane definicji „Customer End User” w aktualnym brzmieniu, czy wymaga ona dalszych wniosków o zmianę.
c) AWS
14.11 – wysłane kierunki negocjacji do AWS
17.11 – odpisali, że potrzebują czasu na analizy tych propozycji
23.11 – ping ze strony BM
24.11 – odpisali, że ich Prawny i Compliance pracuje nad odpowiedziami
01.12 – AWS przesłał odpowiedzi na nasze propozycje zmian w umowie, tego samego dnia przesłana informacja do Maruty do analizy. AWS jest otwarty na wprowadzenie części zmian opracowanych przez Marutę. Obecnie czekamy na odpowiedź Maruty na odpowiedzi AWS.
Przyczyny wydłużenia etapu/produktu nr 2:
Maruta zbyt optymistycznie założyła w swojej ofercie dla nas, że te negocjacje przebiegną gładko i bezproblemowo (mimo ich deklaracji, że nie raz z MS czy innymi negocjowali takie zapisy). Szacunkowo w ofercie założyli 10 godzin pracy na każdego z dostawców, ale chyba nie wzięli pod uwagę dostępności i mocy przerobowych procesowania tych uwag po stronie dostawców chmurowych. Dostawcy też potrzebują czasu po swojej stronie (Prawny, Compliance), żeby przeanalizować propozycje zmian w umowach przygotowane przez Marutę. Czasami trwa to ponad 2 tygodnie jak to było w przypadku AWS. Stąd poślizg w realizacji tego punktu.
Wątek klasyfikacji SIDów (Listy kontrahentów do negocjacji chmurowych)
Wykonane dwie aktualizacje listy sidów bankowych 18.11 i 30.11 (SecOps, Compliance – Adam Detmer).
Do wyjaśnienia pozostają następujące Sidy ze względu na brak umowy w Prawnym (prawdopodobnie nie dostarczone umowy przez biznes).
Lista bankowych:
- Karta kibica (alior akcept) - Luiza Bolda (Unlicensed) urlop 2.12 do dopytania
- Moja sprzedaż (credit agricole akcept) - Michał Stoltman (czekam na info)
- Nest Bank (raczej w porządku) - Krzysztof Ambroziak ( czekam na info)
- PaYu (akceptant credit agricole) - Michał Stoltman ( czekam na info)
Lista Niebankowych:
mbank (Nie ma tam opiekuna biznesowego wprowadzonego, jest to mBank, a weryfikacja oznaczona jako niebankowa) - zapytanie do DWS
1 koszyk (FSI) - nie ma umowy na webconie, ani w segregatorach (brak opiekuna biznesowego) - do ustalenia
Szczegóły zmian zapisane w komentarzach pod listami
SIDy - Weryfikacje bankowe (kontrahenci aktywni)
SIDy - Weryfikacje niebankowe (kontrahenci aktywni)