Techniczny opis rozwiązania dla wymiany komunikatów z wykorzystaniem standardu AS2

Podobne dokumenty
Stosowanie protokołu AS4 zgodnie z Interoperability Network Code

Orange Send MMS. Autoryzacja. Metoda HTTP. Parametry wywołania. API wyślij MMS dostarcza wiadomości MMS. Basic POST

Ministerstwo Finansów

Gatesms.eu Mobilne Rozwiązania dla biznesu

SSL (Secure Socket Layer)

TelCOMM Wymagania. Opracował: Piotr Owsianko Zatwierdził: IMIĘ I NAZWISKO

Ministerstwo Finansów

Systemy internetowe. Wykład 5 Architektura WWW. West Pomeranian University of Technology, Szczecin; Faculty of Computer Science

Wykład 4. Metody uwierzytelniania - Bezpieczeństwo (3) wg The Java EE 5 Tutorial Autor: Zofia Kruczkiewicz

Specyfikacja interfejsów usług Jednolitego Pliku Kontrolnego

Wykład 4. komputerowych Protokoły SSL i TLS główne slajdy. 26 października Igor T. Podolak Instytut Informatyki Uniwersytet Jagielloński

Podstawy Secure Sockets Layer

Zasady budowy i przekazywania komunikatów wykorzystywanych w Systemie IT KDPW_CCP

Specyfikacja techniczna. mprofi Interfejs API

Techniczny opis rozwiązania dla udostępniania danych pomiarowych i zagregowanych z wykorzystaniem standardu AS4

Specyfikacja HTTP API. Wersja 1.6

TelCOMM 4.0. Opracował: Michał Siatkowski Zatwierdził: IMIĘ I NAZWISKO

Specyfikacja API bramki SMS/MMS/TTS

Instrukcja integratora - obsługa dużych plików w epuap2

Opracowanie protokołu komunikacyjnego na potrzeby wymiany informacji w organizacji

ZiMSK. Konsola, TELNET, SSH 1

Zasady budowy i przekazywania komunikatów XML dla rynku OTC w systemie KDPW_CCP

Hosting WWW Bezpieczeństwo hostingu WWW. Dr Michał Tanaś (

Rozproszone systemy Internetowe

Kielce, dnia roku. HB Technology Hubert Szczukiewicz. ul. Kujawska 26 / Kielce

ROZPORZĄDZENIE MINISTRA FINANSÓW 1) z dnia 30 grudnia 2010 r.

ZABEZPIECZENIE KOMUNIKACJI Z SYSTEMEM E-PŁATNOŚCI

Połączenie VPN LAN-LAN IPSec X.509 (stały IP > stały IP)

WebNotarius. Specyfikacja techniczna komunikacji z usługą WebNotarius. wersja 1.1

TelCOMM Piotr Owsianko. Zatwierdził: IMIĘ I NAZWISKO

VPN Host-LAN IPSec X.509 z wykorzystaniem DrayTek Smart VPN Client

Zdalne logowanie do serwerów

System DiLO. Opis interfejsu dostępowego v. 2.0

Bezpieczne protokoły Materiały pomocnicze do wykładu

Dzień dobry Państwu, nazywam się Dariusz Kowal, jestem pracownikiem Śląskiego Centrum Społeczeństwa Informacyjnego, gdzie pełnię rolę inspektora ds.

Szczegółowy harmonogram rzeczowy realizacji prac systemu B2B

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Ogólnopolskie Repozytorium Prac Dyplomowych

WHEEL LYNX SSL/TLS DECRYPTOR. najszybszy deszyfrator ruchu SSL/TLS

Hosting WWW Bezpieczeństwo hostingu WWW. Dr Michał Tanaś (

Szczegółowy opis przedmiotu zamówienia:

Instrukcja dla użytkowników Windows Vista Certyfikat Certum Basic ID

Certyfikat Certum Basic ID. Instrukcja dla użytkowników Windows Vista. wersja 1.3 UNIZETO TECHNOLOGIES SA

DOKUMENTACJA TECHNICZNA KurJerzyAPI wersja 1.0

Information sheet for the marketcommunication

DZIENNIK USTAW RZECZYPOSPOLITEJ POLSKIEJ. Warszawa, dnia 20 wrzeênia 2006 r. Nr 168

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 6 SEAP SPECYFIKACJA KANAŁ DLA PODMIOTÓW ZEWNĘTRZNYCH PL PROJEKT ECIP/SEAP

Technologie internetowe

Zasady budowy i przekazywania komunikatów XML w systemie kdpw_otc

Praktyczne aspekty stosowania kryptografii w systemach komputerowych

Załącznik nr 7 Wytyczne do wdrożenia rozwiązań technicznych

Specyfikacja wysyłek marketingowych v1.10

Bezpieczna poczta i PGP

Serwer SSH. Wprowadzenie do serwera SSH Instalacja i konfiguracja Zarządzanie kluczami

Wprowadzenie do PKI. 1. Wstęp. 2. Kryptografia symetryczna. 3. Kryptografia asymetryczna

Polityka Certyfikacji dla Certyfikatów PEMI

SSH - Secure Shell Omówienie protokołu na przykładzie OpenSSH

Warszawa, dnia 20 kwietnia 2016 r. Poz. 554 ROZPORZĄDZENIE MINISTRA FINANSÓW 1) z dnia 13 kwietnia 2016 r.

Problematyka bezpieczeństwa usług Web Services. Witold Andrzejewski

Wersja 1.0 TEL-STER 2016

GS2TelCOMM. Rozszerzenie do TelCOMM 2.0. Opracował: Michał Siatkowski Zatwierdził: IMIĘ I NAZWISKO

INTERNET - Wrocław Usługi bezpieczeństwa w rozproszonych strukturach obliczeniowych typu grid

Certyfikat niekwalifikowany zaufany Certum Silver. Instalacja i użytkowanie pod Windows Vista. wersja 1.0 UNIZETO TECHNOLOGIES SA

Serwery autentykacji w sieciach komputerowych

Java wybrane technologie

Dokumentacja. Wersja: 1.5 Ostatnio zmodyfikowano: Strona 1

Laboratorium nr 4 Sieci VPN

1. Wymagania dla lokalnej szyny ESB

VPN Virtual Private Network. Użycie certyfikatów niekwalifikowanych w sieciach VPN. wersja 1.1 UNIZETO TECHNOLOGIES SA

Wysyłka wniosko w ZUS - EKS. Instrukcja użytkownika aplikacji Wysyłka wniosków ZUS EKS

PGP - Pretty Good Privacy. Użycie certyfikatów niekwalifikowanych w programie PGP

Połączenie VPN Host-LAN IPSec z wykorzystaniem Windows Vista/7. 1. Konfiguracja routera. 2. Konfiguracja klienta VPN. 3. Zainicjowanie połączenia

Aplikacje WWW Wprowadzenie

Warszawa Specyfikacja techniczna. mprofi Interfejs API wersja 1.0.7

Procedura Walidacyjna Interfejs

Bezpieczeństwo i szyfrowanie poczty elektronicznej z wykorzystaniem certyfikatów kwalifikowanych i niekwalifikowanych

TelCOMM 3.0. Opracował: Michał Siatkowski Zatwierdził: IMIĘ I NAZWISKO

Poniżej znajduje się instrukcja konfiguracji najpopularniejszych programów do obsługi poczty.

TCP/IP. Warstwa aplikacji. mgr inż. Krzysztof Szałajko

Część I -ebxml. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz. UEK w Krakowie Janusz Stal & Grażyna Paliwoda-Pękosz

Wykład 4 Bezpieczeństwo przesyłu informacji; Szyfrowanie

DOKUMENTACJA TECHNICZNA SMS API MT

Marcin Szeliga Sieć

MINISTERSTWO FINANSÓW PLAN INTEGRACJI SYSTEMU ZAŁĄCZNIK NR 2 SEAP SPECYFIKACJA XML INTERFEJS WEBSERVICE DLA PODMIOTÓW ZEWNĘTRZNYCH PL

POLITYKA CERTYFIKACJI KIR dla ZAUFANYCH CERTYFIKATÓW NIEKWALIFIKOWANYCH

Dokumentacja Techniczna. Dokumentacja techniczna usługi płatności mobilnych

Wymagania bezpieczeństwa wobec statycznych bezpośrednich 1-fazowych i 3-fazowych liczników energii elektrycznej. Wymaganie techniczne

XML-RPC: Zdalne wykonywanie procedur

Bezpieczny system telefonii VoIP opartej na protokole SIP

SSL VPN Virtual Private Network with Secure Socket Layer. Wirtualne sieci prywatne z bezpieczną warstwą gniazd

Gatesms.eu Mobilne Rozwiązania dla biznesu

Materiały dodatkowe Krótka charakterystyka protokołu MODBUS

Zamiana porcji informacji w taki sposób, iż jest ona niemożliwa do odczytania dla osoby postronnej. Tak zmienione dane nazywamy zaszyfrowanymi.

Laboratorium Programowania Kart Elektronicznych

Podręcznik Integracji

Jarosław Kuchta Administrowanie Systemami Komputerowymi. Dostęp zdalny

Protokół IPsec. Patryk Czarnik

Poufność (słaba) Integralność (niekryptograficzna) Uwierzytelnienie (słabe) Brak kontroli dostępu Brak zarządzania kluczami

Transkrypt:

Techniczny opis rozwiązania dla wymiany komunikatów edig@s z wykorzystaniem standardu AS2 Strona 1 z 10

Lista załączników Numer załącznika Opis załącznika 1. Nomination and Matching 3 Process 2. Opis atrybutów: NOMINT, NOMRES, ACKNOW, DELORD, DELRES (Edig@s 5.1) Załącznik http://www.edigas.org/wpcontent/downloads/3nominationandmatchingprocess2-0.pdf http://www.gaz-system.pl/strefa-klienta/do-pobrania/wymianadanych/edigs/ Strona 2 z 10

Spis treści 1 WPROWADZENIE... 4 1.1 CEL PROJEKTU... 4 2 ZAŁOŻENIA OGÓLNE... 5 3 SPECYFIKACJA KOMUNIKACJI PRZY UŻYCIU AS2... 6 3.1 ENDPOINT AS2 DLA PODMIOTÓW ZEWNĘTRZNYCH... 6 3.2 OBSŁUGIWANE WZORCE KOMUNIKACJI... 6 3.2.1 Komunikaty HTTP w standardzie AS2... 6 3.3 BEZPIECZEŃSTWO PRZESYŁANYCH DANYCH... 8 3.3.1 Zabezpieczenia komunikacji na poziomie warstwy transportu... 8 3.3.2 Zabezpieczenia komunikacji na poziomie wiadomości... 9 3.4 INNE WYMAGANIA DOTYCZĄCE KOMUNIKACJI... 9 PROCEDURA PRZYŁĄCZENIA NOWEGO PODMIOTU... 10 3.5 PO STRONIE GAZ-SYSTEM... 10 3.6 PO STRONIE PRZYŁĄCZANEGO PODMIOTU... 10 Strona 3 z 10

1 Wprowadzenie 1.1 Cel projektu Udostępnienie interfejsu HTTP umożliwiającego wymianę dokumentów EDIG@S Nomination and Matching Process documents z wykorzystaniem standardu AS2. Strona 4 z 10

2 Założenia ogólne 1. Do komunikacji szyny danych z podmiotami zewnętrznymi wykorzystywany będzie standard EDIINT AS2, który zapewni bezpieczną komunikację przy użyciu protokołu HTTP, niezależną od wymienianych danych. 2. Interfejs umożliwiający składanie nominacji udostępniony podmiotom zewnętrznym będzie oparty na komunikatach EDIG@S 5.1: NOMINT, NOMRES, DELORD, DELRES i ACKNOW oraz EDIG@S 4.0 NOMINT, NOMRES, DELORD, DELRES i ACKNOW. W dokumencie wskazane są najnowsze obowiązujące releasy wersji standardów (5.1.3 i 4.0.9). Numery releasów wersji 5.1 i 4.0 zostaną dopasowane do wymagań klienta przed etapem implementacji, co będzie skutkowało odpowiednimi zmianami nazewnictwa folderów i dokumentów. 3. Sekwencje i semantyka wymienianych komunikatów NOMINT, NOMRES, DELORD, DELRES i ACKNOW jest zdefiniowana przez proces EDIG@AS 5.1: Nomination and Matching 3 Process v2. Strona 5 z 10

3 Specyfikacja komunikacji przy użyciu AS2 3.1 Endpoint AS2 dla podmiotów zewnętrznych Lokalizacja endpoint u obsługującego standard AS2 do wykorzystania przez podmioty zewnętrzne dla środowiska produkcyjnego i testowego zostanie przekazana przez stronę GAZ-SYSTEM w ramach procedury przyłączenia nowego podmiotu 3.2 Obsługiwane wzorce komunikacji EDIINT AS2 wspiera jednokierunkową komunikację z wykorzystaniem protokołu HTTP. Dane biznesowe (payload) mogą znajdować się jedynie w żądaniach HTTP (HTTP request) przesyłanych od partnera inicjującego komunikację. W odpowiedzi HTTP (HTTP response), partner odbierający komunikat AS2 zwraca jedynie kod statusu HTTP i opcjonalnie synchroniczne potwierdzenia odebrania wiadomości MDN (Message Disposition Notification). Komunikaty MDN mogą być też wysyłane asynchronicznie, w niezależnym żądaniu HTTP. 3.2.1 Komunikaty HTTP w standardzie AS2 Komunikaty w standardzie AS2 to żądanie HTTP POST składające się z załączników (MIME parts). Biznesowa zawartość komunikatów w poniższych przykładach jest skrócona. Specyfikacja komunikatów NOMINT, NOMRES, DELORD, DELRES i ACKNOW zawarta jest w załącznikach 1-4. Komunikat ACKNOW jest komunikatem opcjonalnym dla procesu Edigas 5.1 Nomination and Matching Processes. Jego wykorzystanie jest kwestią uzgodnienia między Gaz-Systemem, a podmiotem zewnętrznym. 3.2.1.1 Przykładowy komunikat AS2 przychodzący (Partner -> B2B, obsługiwane komunikaty: NOMINT, DELORD, DELRES i ACKNOW) Bez zabezpieczeń w warstwie wiadomości (z Basic Security): POST https://wm-b2b.gaz-system.pl:8888/invoke/wm.ediint/receive/ HTTP/1.1 Accept-Encoding: gzip,deflate Content-Type: multipart/mixed; boundary="----=_part_68_1058528664.1457099769435" MIME-Version: 1.0 Disposition-Notification-To: 21X000000001130S Message-ID: 2c1kkjhg49 AS2-To: 21X-PL-A-A0A0A-B_TMP AS2-Version: 1.2 AS2-From: 21X000000001130S Content-Length: 2723 ------=_Part_68_1058528664.1457099769435 Content-Type: application/xml; name="delres 27G v5.1.xml" Content-Transfer-Encoding: binary Content-Disposition: form-data; name="delres 27G v5.1.xml"; filename="delres 27G v5.1.xml" <?xml version="1.0" encoding="utf-8"?> <DeliveryResponse_Document release="3" xmlns="urn:easeegas.eu:edigas:nominationandmatching:deliveryresponsedocument:5:1">... </DeliveryResponse_Document> ------=_Part_68_1058528664.1457099769435 Z włączonymi zabezpieczeniami w warstwie wiadomości (podpisywanie): POST https://wm-b2b.gaz-system.pl:8888/invoke/wm.ediint/receive/ HTTP/1.1 Content-type: multipart/signed; micalg=sha-1; protocol="application/pkcs7- signature"; boundary="----=_part_0_409673203.1011470256738" Disposition-notification-to: http://administrator:manage@localhost:5555/invoke/wm.ediint/receive Disposition-notification-options: signed-receipt-protocol=optional, pkcs7- Strona 6 z 10

signature; signed-receipt-micalg=optional, SHA-1 AS2-From: 123456789 AS2-To: 987654321 Message-ID: <1687657971.1011470256928.JavaMail.zhouz@zhenzhou> Content-Length: 2534 ------=_Part_0_409673203.1011470256738 Content-Type: application/xml Content-Transfer-Encoding: binary <?xml version="1.0" encoding="utf-8"?> <DeliveryResponse_Document release="3" xmlns="urn:easeegas.eu:edigas:nominationandmatching:deliveryresponsedocument:5:1">... </DeliveryResponse_Document> ------=_Part_0_409673203.1011470256738 Content-Type: application/pkcs7-signature; name=smime.p7s webmethods Module for EDIINT Installation and User s Guide Version 8.2 SP1 73 5 Processing Inbound EDIINT Documents and MDNs Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAMYIBuDCCAbQC AQEwXjBZMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOd2ViTWV0aG9kcyBJbmMxDzANBgNVBAsTBlBE IEVESTEgMB4GA1UEAxMXRURJSU5UIHNhbXBsZSBTZW5kZXIgQ0ECAQEwCQYFKw4DAhoFAKCBsTAY BgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjAxMTcyMDM4MDhaMCMG CSqGSIb3DQEJBDEWBBQKbJZgrh/bit8BFmv1fuaWf40PjzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqG SIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUr DgMCBzANBgkqhkiG9w0BAQEFAASBgKRrXO1tX3oFfLTgJwuoWKhygMQzdyNpX1Z4xU7kjDqYS8gs yvarsl0s7d4wa3n1clgquk87yrcfqojpygrxyci0kagh1ny61gxkphuq2cp54m11wzgq9ogharba TJu8HWB1ETFBML+wIBGunkRcR3s5mEpxINmflEYNZlxmf78ZAAAAAAAA ------=_Part_0_409673203.1011470256738- Minimalny zestaw nagłówków AS2 dla poprawnego rozpoznania komunikatu EDIINT AS2 po stronie B2B to Content-Type, AS2-To, AS2-From, AS2-Version i Message-ID. W zależności od parametrów nagłówkowych zapytania (obecność nagłówka Content-disposition-to) serwer B2B zwróci potwierdzenie odebrania komunikatu (MDN) lub nie (niezalecane). Fragment MIME z zawartością biznesową (dokumenty NOMINT, NOMRES, DELORD, DELRES lub ACKNOW) muszą mieć ustawiony nagłówek Content-Type: application/xml (lub application/zip). 3.2.1.2 Przykładowy komunikat AS2 MDN wychodzący (B2B -> Partner) Dla powyższego komunikatu przychodzącego: AS2-From: 21X-PL-A-A0A0A-B_TMP AS2-To: 21X000000001130S AS2-Version: 1.2 Message-ID: <283919369.6864.1457099769564.JavaMail.WROB2B11$@WROB2B11> Content-Type: multipart/report; Report-Type=disposition-notification; =_Part_6859_2071722519.1457099769562" boundary="---- ------=_Part_6859_2071722519.1457099769562 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MDN for - Message ID: 2c1kkjhg49 From: 21X000000001130S To: 21X-PL-A-A0A0A-B_TMP Received on: 2016-03-04 at 14:56:09 (CET) Status: processed Comment: This is not a guarantee that the message has been completely processed or understood by the receiving translator ------=_Part_6859_2071722519.1457099769562 Content-Type: message/disposition-notification Content-Transfer-Encoding: 7bit Reporting-UA: webmethods Integration Server Original-Recipient: rfc822; 21X-PL-A-A0A0A-B_TMP Final-Recipient: rfc822; 21X-PL-A-A0A0A-B_TMP Original-Message-ID: 2c1kkjhg49 Received-content-MIC: mhx+/od5x6s5zjozyqfrtqbqrxc=, sha1 Disposition: automatic-action/mdn-sent-automatically; processed ------=_Part_6859_2071722519.1457099769562-- Strona 7 z 10

Możliwe jest zarówno synchroniczne jak i asynchroniczne odsyłanie komunikatów MDN. 3.2.1.3 Przykładowy komunikat AS2 wychodzący (B2B -> Partner, obsługiwane komunikaty: NOMRES, DELORD, DELRES i ACKNOW) POST https://partner.com:8080/as2/receive/ HTTP/1.1 Disposition-notification-to: 21X-PL-A-A0A0A-B AS2-From: 21X-PL-A-A0A0A-B AS2-To: 12X-0000001807-W AS2-Version: 1.2 ediint-features: multiple-attachments Message-ID: cb551392-67dc-4cee-8111-7e88d3d27fe0@gaz-system.pl Content-Type: application/xml <ns:acknowledgement_document release="2" xmlns:ns="urn:easeegas.eu:edigas:general:acknowledgementdocument:5:1">... </ns:acknowledgement_document 3.2.1.4 Przykładowy komunikat AS2 MDN przychodzący (Partner -> B2B) Dla powyższego komunikatu wychodzącego: Message-ID: 1234 AS2-To: 21X-PL-A-A0A0A-B AS2-From: 12X-0000001807-W Content-Type: multipart/report; Report-Type=disposition-notification; =_Part_1753_1868621486.1456399997955" Content-Length: 927 Server: Jetty(6.1.26) boundary="---- ------=_Part_1753_1868621486.1456399997955 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MDN for - Message ID: cb551392-67dc-4cee-8111-7e88d3d27fe0@gaz-system.pl From: 21X-PL-A-A0A0A-B To: 12X-0000001807-W Received on: 2016-02-25 at 12:33:17 (CET) Status: processed Comment: This is not a guarantee that the message has been completely processed or understood by the receiving translator ------=_Part_1753_1868621486.1456399997955 Content-Type: message/disposition-notification Content-Transfer-Encoding: 7bit Reporting-UA: webmethods Integration Server Original-Recipient: rfc822; 12X-0000001807-W Final-Recipient: rfc822; 12X-0000001807-W Original-Message-ID: cb551392-67dc-4cee-8111-7e88d3d27fe0@gaz-system.pl Received-content-MIC: +tceczop9ryqvxvflkrg+ds15cw=, sha1 Disposition: automatic-action/mdn-sent-automatically; processed ------=_Part_1753_1868621486.1456399997955 Minimalny zestaw nagłówków AS2 dla poprawnego rozpoznania komunikatu EDIINT AS2 MDN po stronie B2B to Content-Type, AS2-To, AS2-From, AS2-Version i Message-ID oraz fragment MIME z Content- Type: text/plain (zawierający strukturę MDN for -) i z Content-Type: message/dispositionnotification. 3.3 Bezpieczeństwo przesyłanych danych 3.3.1 Zabezpieczenia komunikacji na poziomie warstwy transportu Usługa umożliwiająca wymianę komunikatów w standardzie AS2 udostępniona będzie podmiotom zewnętrznych jedynie poprzez protokół HTTPS. Strona 8 z 10

Komunikacja podmiotu zewnętrznego z Gaz-Systemem w warstwie transportu zabezpieczona będzie przy pomocy protokołu min. TLS 1.1 z szyfrowaniem i autentykacją serwera z użyciem certyfikatu X.509 z kluczem o długości min. 2048 bit i sygnaturą SHA256. Klient (podmiot zewnętrzny) nie musi być autentykowany w warstwie transportu (tylko jeśli zastosowane będzie podpisywanie wiadomości) W ramach komunikacji HTTPS wykorzystane zostaną Cipher Suites o kluczu min. 128 bit, z zaimplementowaniem mechanizmu Forward Secrecy, bez wykorzystania RC4 i algorytmu Diffiego-Hellmana. Dodatkowo niedozwolona jest renegocjacja inicjowana przez klienta. 3.3.2 Zabezpieczenia komunikacji na poziomie wiadomości Komunikaty AS2 zabezpieczone będą z wykorzystaniem standardu S/MIME wersja 2. Usługa AS2 udostępniona przez Gaz-System umożliwia: Podpisywanie wiadomości przychodzących (do Gaz-Systemu) i wychodzących (do partnera) Szyfrowanie wiadomości przychodzących i wychodzących (dostępne algorytmy: RC2 40, RC2 64, RC2 128, DES, TripleDES) Podpisywanie i szyfrowanie wiadomości przychodzących do Gaz-Systemu i wychodzących do partnera Podpisywanie potwierdzeń MDN przychodzących do Gaz-Systemu i wychodzących do partnera Zakres zastosowanego poziomu zabezpieczeń w tej warstwie musi zostać uzgodniony z Gaz-Systemem. Jeśli w warstwie transportu nie zostanie wykorzystana autentykacja klienta w oparciu o certyfikat X.509 (Two-way SSL), należy zastosować co najmniej podpisywanie wiadomości i potwierdzeń MDN. 3.4 Inne wymagania dotyczące komunikacji Wiadomości mogą być kompresowane przy pomocy ZIP (application/zip). Strona 9 z 10

4 Procedura przyłączenia nowego podmiotu 4.1 Po stronie Gaz-System 1. Utworzenie profilu TN dla partnera wraz z definicją certyfikatów służących do szyfrowania i weryfikacji komunikatów (zadanie administracyjne): a. Ustawienie kodu EIC podmiotu jako ExternalID partnera (typ identyfikatora: EIC). b. Ustawienie kodu EIC podmiotu jako ExternalID partnera (typ identyfikatora: EDIINT AS2). c. Import certyfikatu (wystawionego dla Gaz-System) i klucza prywatny do podpisywania komunikatów S/MIME wysyłanych przez Gaz-System d. Import certyfikatu (wystawionego dla Gaz-System) i klucza prywatnego do deszyfrowania komunikatów S/MIME odbieranych przez Gaz-System e. Import certyfikatu (wystawionego dla podmiotu) do weryfikacji podpisu komunikatów AS2 odbieranych przez Gaz-System f. Import certyfikatu (wystawionego dla podmiotu) do szyfrowania komunikatów SOAP wysyłanych przez Gaz-System 2. Przekazanie do podmiotu zewnętrznego certyfikatu zapewniającego poufność komunikacji z usługą AS2 (i jej autentyczność) po stronie Gaz-Systemu (bezpieczeństwo warstwy transportu). 3. Przekazanie podmiotowi zewnętrznemu certyfikatów którymi wiadomości S/MIME będą podpisywane i szyfrowane (bezpieczeństwo warstwy wiadomości). 4. Przekazanie podmiotowi zewnętrznemu adresu usługi AS2. 4.2 Po stronie przyłączanego podmiotu 1. Przekazanie do Gaz-Systemu kodu EIC podmiotu, uzgodnienie parametrów komunikacji: a. Tryb odsyłania MDN b. Wykorzystanie kompresji komunikatów c. Poziom zabezpieczenia komunikatów MDN d. Poziom zabezpieczenia komunikatów e. Algorytmy generowania skróty wiadomości i szyfrowania 2. Upewnienie się że certyfikat serwera Gaz-Systemu lub jego CA jest zaufanym certyfikatem 3. Przekazanie do Gaz-Systemu certyfikatów którymi komunikaty S/MIME będą podpisywane i szyfrowane (bezpieczeństwo komunikatów S/MIME). 4. Implementacja klienta i usługi AS2 obsługującej komunikaty NOMINT, NOMRES, DELORD, DELRES i ACKNOW 5. Przekazanie do Gaz-Systemu adresu usługi AS2. Strona 10 z 10