Wprowadzenie

Niniejszy artykuł jest ostatnim z cyklu artykułów traktujących o wykorzystaniu rozporządzenia eIDAS
i certyfikatów kwalifikowanych w kontekście dyrektywy PSD2. Opiszemy w nim rozwiązanie, które adresuje opisane dotychczas wymagania w obszarze bezpieczeństwa komunikacji między TPP i ASPSP. Jako referencyjne rozwiązanie wykorzystamy stworzony przez nas TPP Validator.

Realizacja wymagań bezpiecznej komunikacji między TPP i ASPSP

Zacznijmy od zebrania wszystkich wymagań opisanych w poprzednich artykułach naszego cyklu. Rozwiązanie zapewniające bezpieczną komunikację między TPP i ASPSP powinno spełniać wszystkie te wymagania. W naszym przypadku stawiamy się w roli APSPS, ponieważ na ASPSP, zgodnie z wymaganiami RTS, ciąży odpowiedzialność sprawdzenia TPP. Jako bank musimy spełnić co następuje:

  1. Wymagania
    1. Należy potwierdzić poprawność/ważność certyfikatów eIDAS wykorzystywanych przez TPP:
      1. QWAC przy zestawianiu kanału TLS (mTLS)
      2. QSealC przy sprawdzeniu podpisu wiadomości wysłanej przez TPP
    2. Należy sprawdzić czy TPP posiada odpowiednie role instytucji płatniczej
    3. Należy sprawdzić status licencji/wpisu do rejestru PSP, niezależnie od zawartości ról
      w certyfikacie
    4. Należy sprawdzić czy PSP posiada paszportyzację do wykonywania usług w danym kraju
    5. Czas sprawdzenia certyfikatu nie może być dłuższy niż ~100ms
    6. Czas sprawdzania paszportyzacji i statusu licencji nie może dłuży niż ~100ms
    7. Należy zapewnić integrację z istniejącymi w ASPSP rozwiązaniami sprzętowymi (Netscaler, F5) oraz oprogramowaniem (API Gateway), które zapewniają bezpieczeństwo w czasie:
      1. nawiązywania połączenia mTLS
      2. realizują żądania na podstawie podpisanych komunikatów
    8. Ograniczenia:
      1. Nie możemy wymagać rejestracji TPP w naszych systemach/API Portalu. Komunikacja między TPP i ASPSP musi być automatyczna i nie może wymagać ręcznych rejestracji w systemach ASPSP.
      2. Jawne ograniczenie stawiane przez RTS.

Opis realizacji powyższych wymagań/ograniczeń przedstawimy wykorzystując podejście zastosowane w naszym rozwiązaniu TPP Validator:

  • Zaimplementowaliśmy wsparcie dla standardów eIDAS (https://portal.etsi.org//TBSiteMap/ESI/ESIActivities.aspx). Pozwoliło to na walidację certyfikatów eIDAS/PSD2 zgodnych z wymaganiami rozporządzenia eIDAS i dyrektywy PSD2
  • Zaimplementowaliśmy wsparcie dla standardu ETSI TS 119 495, co pozwala na sprawdzenie ról PSP
  • Zaimplementowaliśmy integrację z rejestrem instytucji płatniczych EBA, co pozwala na sprawdzenie paszportyzacji TPP oraz potwierdzenie statusu licencji
  • Odpowiednie SLA zapewniliśmy dzięki „cache’owaniu” zawartości:
    • wszystkich list TSL
    • rejestru instytucji płatniczych EBA.
  • Integrację z istniejącymi w ASPSP rozwiązaniami zapewniającymi bezpieczeństwo (tj. sprzętowy/softwarowy gateway), uzyskano dzięki dostarczeniu usług OSCP dla walidacji certyfikatu eIDAS oraz usług REST dla pobrania informacji o licencji, paszportyzacji i ról TPP.
  • Automatyczne potwierdzanie tożsamości TPP w czasie:
    • nawiązywania połączenia TLS (mTLS) z ASPSP
    • sprawdzenia podpisu komunikatu przez ASPSP,

bez konieczności manualnej rejestracji TPP w systemie ASPSP zrealizowano dzięki integracji
z paneuropejskim PKI eIDAS.

Published by Marcin Parczewski

Założyciel i CEO Inteca oraz autor rozwiązania APILOGIC. Doświadczony architekt systemów, projektant zaawansowanych usprawnień biznesowych i praktyk cyfrowych transformacji w dużych korporacjach.

Leave a comment

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Szybki kontakt!
+
Wyślij!